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

For what it's worth, there does seem to be something amiss with USB. An RPI2 at r355446 is having difficulty finding its USB devices on a hands-off reboot. The problem wasn't apparent until this most recent upgrade. Here's the console output: DRAM: 944MB Number of U-Boot devices: 1 U-Boot env:

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

On 06.12.2019 21:08, Steve Kargl wrote: > On Fri, Dec 06, 2019 at 07:09:55PM -0500, Alexander Motin wrote: >> On 06.12.2019 18:41, Steve Kargl wrote: >>> On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: On 06.12.2019 17:52, Steve Kargl wrote: > On Fri, Dec 06, 2019 at

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

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 >

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

On Fri, Dec 06, 2019 at 07:09:55PM -0500, Alexander Motin wrote: > On 06.12.2019 18:41, Steve Kargl wrote: > > On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: > >> On 06.12.2019 17:52, Steve Kargl wrote: > >>> On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: > On

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

On Fri, Dec 6, 2019 at 4:41 PM Steve Kargl wrote: > On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: > > On 06.12.2019 17:52, Steve Kargl wrote: > > > On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: > > >> On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl < >

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

On 2019-12-07 01:09, Alexander Motin wrote: On 06.12.2019 18:41, Steve Kargl wrote: On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: On 06.12.2019 17:52, Steve Kargl wrote: On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl

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

On 06.12.2019 18:41, Steve Kargl wrote: > On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: >> On 06.12.2019 17:52, Steve Kargl wrote: >>> On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl wrote: > The

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

On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: > On 06.12.2019 17:52, Steve Kargl wrote: > > On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: > >> On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl > >> > >> wrote: > >> > >>> On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve

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

On 06.12.2019 17:52, Steve Kargl wrote: > On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: >> On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl >> >> wrote: >> >>> On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: I updates /usr/src to r355452, and updated by kernel and

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

On Fri, Dec 06, 2019 at 02:52:31PM -0800, Steve Kargl wrote: > > The commit message for 355010 states: > >Devices appearing on USB bus later may still require setting >kern.cam.boot_delay, but hopefully those are minority. > > There is no statement about "where" kern.cam.boot_delay

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

On Fri, Dec 06, 2019 at 05:44:55PM -0500, Alexander Motin wrote: > > Yes, I made the change, and it was supposed to improve USB > inter-operation, but after reading this email I still have no clue what > could be wrong, so ideas welcome. Sorry about the initial vagueness. It took a couple of

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

On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: > On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl > wrote: > > > On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: > > > I updates /usr/src to r355452, and updated by kernel and > > > world. Upon rebooting, verbose boot messages

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

On 06.12.2019 17:33, Warner Losh wrote: > On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl > > wrote: > > On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: > > I updates /usr/src to r355452, and updated by kernel and > > world.  Upon

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

On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl wrote: > On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: > > I updates /usr/src to r355452, and updated by kernel and > > world. Upon rebooting, verbose boot messages susgests > > the system is hanging when USB starts to attach. With > >

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

On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: > I updates /usr/src to r355452, and updated by kernel and > world. Upon rebooting, verbose boot messages susgests > the system is hanging when USB starts to attach. With > the 3-week kernel verbose boot shows: > > ... > pcm4: at nid

Re: USB causing boot to hang

On Fri, Dec 06, 2019 at 09:32:01PM +, Bjoern A. Zeeb wrote: > On 6 Dec 2019, at 20:23, Steve Kargl wrote: > > > I updates /usr/src to r355452, and updated by kernel and > > world. Upon rebooting, verbose boot messages susgests > > the system is hanging when USB starts to attach. With > >

Re: USB causing boot to hang

On 6 Dec 2019, at 20:23, Steve Kargl wrote: I updates /usr/src to r355452, and updated by kernel and world. Upon rebooting, verbose boot messages susgests the system is hanging when USB starts to attach. With the 3-week kernel verbose boot shows: ... pcm4: at nid 30 on hdaa1 pcm4: Playback:

USB causing boot to hang

I updates /usr/src to r355452, and updated by kernel and world. Upon rebooting, verbose boot messages susgests the system is hanging when USB starts to attach. With the 3-week kernel verbose boot shows: ... pcm4: at nid 30 on hdaa1 pcm4: Playback: pcm4: Stream cap: 0x0005 AC3 PCM

Re: kernel module code coverage

I didn't realize it was going to get updated so soon, but the versions on that page were at "8.16.5" for the Windows and Linux versions when I sent my email a couple days ago. It also appears the versions for the OSs aren't all updated at the same time (.6 seems to only includes Windows/macOS

Re: kernel module code coverage

Eric Joyner wrote: > I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD > support? Do you have a link to something that shows that? > > I still see a FreeBSD tarball in their download archive page for the newest > version of their tool, which seems to be 8.16.5. It appears