On Tue, Jul 11, 2017 at 10:47 AM, Michael Butler <imb_at_protected-networks.net > wrote: > On 7/11/17 10:32 AM, Warner Losh wrote: > >> On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill <david_at_catwhisker.org> >> wrote: >> >>> I believe that each of the machines has an MMC slot, but I also believe >>> that in each case, it is empty. >>> >>> Is there anything else I might be able to do to help resolve this? >>> >>> >> Try building a kernel without sdhci in it. >> >> It's looking like the scans for ata devices are returning errors on the >> desktop machine you have, which shouldn't have been happening. >> >> Also, can you try a 100% clean build of GENERIC to make sure there's not a >> meta-mode bug? >> > > On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") refuses > to find /dev/ada0 :-( > Take sdhci out of the kernel and try again. If that works, it tells us one thing (need to troubleshoot sdhci stuff more). If not it tells us another (need to troubleshoot CAM more), do we get errors with the ATA_IDENTIFY command? Does it try multiple times per AHCI port? What AHCI device do you have? You may need to scroll back with the screen-lock / pageup keys to see these messages. Plus we know we have at least one bug in meta-mode rebuilding since not everything is being rebuilt that should be across this change. The change itself didn't change CAM except for copying one set of data it didn't used to, into a structure whose size grew (which is why we're seeing crashes / failures for a 'cross-threaded' rebuild). There's nothing else that changed (especially after I removed the bogus debug printfs) that I can see in auditing the change. I was really hoping David's machine would exhibit the behavior since we're co-workers and have a shared infrastructure for debugging we can leverage. WarnerReceived on Tue Jul 11 2017 - 15:09:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC