On Tue, Jul 11, 2017 at 10:47 AM, Michael Butler <i...@protected-networks.net
> On 7/11/17 10:32 AM, Warner Losh wrote:
>> On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill <da...@catwhisker.org>
>>> 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
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"