Re: System hangs at boot in xhci0

On Fri, Dec 09, 2016 at 03:45:30PM -0800, Steven G. Kargl wrote:
> On Fri, Dec 09, 2016 at 11:58:21PM +0100, Hans Petter Selasky wrote:
> > On 12/09/16 22:09, Steve Kargl wrote:
> > > I updated my system to
> > >
> > > % svn info /usr/src
> > > Revision: 309748
> > >
> > > Built a shiny new kernel, which hangs during boot.
> > > There is no panic.  Using the dmesg from kernel.old/kernel,
> > > the last few reported are
> > >
> > >
> > > pci2: <ACPI PCI bus> on pcib2
> > > xhci0: <XHCI (generic) USB 3.0 controller> mem 0xfe900000-0xfe900fff
> > > irq 48 at device 0.0 on pci2
> > > xhci0: 32 bytes context size, 64-bit DMA
> > >
> > > At this point, the system is completely unresponse and
> > > needs to be power cycled.
> > >
> > 
> > Hi,
> > 
> > What is the next message in the old kernel which is printed? There has 
> > been zero changes in the XHCI driver recently.
> > 
> > Can you copy /boot/kernel.old to /boot/kernel.works
> > 
> > Then add this option to the GENERIC kernel config:
> > 
> > options VERBOSE_SYSINIT
> > 
> > What are the last few messages in dmesg when you boot with the above flag?
> > 
> 
> With a boot_verbose of the new kernel I get the following output:
> 
> xhci0: 32 bytes context size, 64-bit DMA
> xhci0: attempting to allocate 1 MSI vectors (4 supported)
> msi: routing MSI IRQ 260 to local APIC 16 vector 55
> xhci0: using IRQ 260 for MSI
> xhci0: MSI enabled
> usbus0 on xhci0
> xhci0: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus0
> random: harvesting attach, 8 bytes (4 bits) from xhci0
> random: harvesting attach, 8 bytes (4 bits) from pci2
> random: harvesting attach, 8 bytes (4 bits) from pcib2
> 
> and then the system locks up.  With the old kernel (circa
> Oct 10th sources), next few lines from dmesg are 
> 
> pcib3: <ACPI PCI-PCI bridge> irq 54 at device 10.0 on pci0
> pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib3
> pcib0: allocated type 3 (0xfe800000-0xfe8fffff) for rid 20 of pcib3
> pcib3:   domain            0
> pcib3:   secondary bus     3
> pcib3:   subordinate bus   3
> pcib3:   I/O decode        0xd000-0xdfff
> pcib3:   memory decode     0xfe800000-0xfe8fffff
> pci3: <ACPI PCI bus> on pcib3
> 
> I think that hang isn't caused by xhci, but rather is a 
> victim on being the last successfully probed device.  In the last
> weeks there have been a few commits (309588, 309400, and 308953)
> that touched ACPI.  I'm currently reverting these changes to test
> if one is causing the problem.
> 
> I did see that one of these revisions specific mentions the
> ALASKA AMI bios, which I happen to have.  However, that commit
> also mentions a skylake processor while I have an AMD FX-8350.
> 

Well, I reverted each of the above indicated revisions.  No luck.
New kernel still locks up.  I guess it's time to do a bisection.
Unfortunately, this cross a llvm 3.8 to 3.9 boundary.

:(

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
https://www.youtube.com/watch?v=6hwgPfCcpyQ