Re: CAM breaks USB [was Re: USB causing boot to hang]

From: Steve Kargl <sgk_at_troutmask.apl.washington.edu>
Date: Mon, 9 Dec 2019 10:52:39 -0800
On Fri, Dec 06, 2019 at 06:11:48PM -0800, Steve Kargl wrote:
> On Sat, Dec 07, 2019 at 01:16:13AM +0100, Hans Petter Selasky wrote:
> > 
> > There is an option you can compile into the kernel which will allow the 
> > keyboard to enter the debugger.
> > 
> > options	ALT_BREAK_TO_DEBUGGER
> > 
> > Sounds to me like either a leaked refcount or that one thread is 
> > spinning blocking execution of other threads.
> > 
> 
> I tried setting the sysctls
> 
> hw.usb.umass.debug: 1
> hw.usb.xhci.debug: 1
> hw.usb.uhci.debug: 1
> hw.usb.ohci.debug: 1
> hw.usb.ehci.debug: 1
> 
> but when I rebooted I forgot to request a verbose boot.
> There was no apparent debugging output to the console.
> I try again on Monday to get additional information.
> 

keyboard isn't available prior to the hang.

A kernel built at 355010 hangs.  This includes kernels
built with and without INVARIANTS, INVARIANT_SUPPORT,
WITNESS, and WITNESS_SKIPSPIN.  This includes adding
"kern.cam.boot_delay=30000" to /boot/loader.conf.
Adding "hw.usb.debug=1", "hw.usb.umass.debug=1", 
"hw.usb.ctrl.debug=1", "hw.usb.xhci.debug=1", 
"hw.usb.uhci.debug=1", "hw.usb.ohci.debug=1", and
"hw.usb.ehci.debug=1" shows no usb related output on
the console when booting the 355010 kernel; whereas, a
355009 kernel floods the console. 

Unfortunately, I'm not a kernel hacker and I have run
out of time trying to report an issue.

-- 
Steve
Received on Mon Dec 09 2019 - 17:52:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC