Re: USB locks up system -- WAS Re: shutdown or acpi problem

On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote:
> On 15 November 2014 21:41, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
> > On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote:
> >> On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
> >> > On 11/13/14 19:15, Steve Kargl wrote:
> >> > > On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
> >> > >> On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
> >> > >>> On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
> >> > >>>> I have a kernel/world from r274273 sources, which is exhibiting a new
> >> > >>>> issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
> >> > >>>> work.  I get to the end of shutdown and see for example
> >> > >>>>
> >> > >>>> All buffers synced
> >> > >>>> Uptime: 4h23m15s
> >> > >>>>
> >> > >>>> and then the laptop just sits there.  It does not power off with
> >> > >>>> the -p option nor does it reboot with the -r.  Has anyone else
> >> > >>>> seen this behavior?
> >> > >>>>
> >> > >>>
> >> > >>> The problem appears to be related to a recent change in the
> >> > >>> USB stack.  If I have the following drive plugged into a
> >> > >>> usb port, the above behavior is observed on shutdown.
> >> > >>>
> >> > >
> >> > > Adding
> >> > >
> >> > > hw.usb.no_shutdown_wait: 1
> >> > >
> >> > > to /boot/loader.conf appears to work around the 'shutdown -p now'
> >> > > and 'shutdown -r now' issue.  Unfortunately, the bricking of the
> >> > > laptop is not affected by this sysctl.  Once a device is plugged
> >> > > into a usb, it must remain plugged in.
> >> > >
> >> >
> >> > Hi,
> >> >
> >> > Is using this sysctl/tunable a suitable solution for you?
> >> >
> >>
> >> The sysctl is a suitable solution for the shutdown issues.
> >> It is not suitable solution for the general use of using
> >> a memory stick to for example quickly transfer files.  Once
> >> the memory stick is plugged into the usb port, it must
> >> remain there unless one wants to reboot the system.
> >>
> >> I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
> >> I need to wade through a rather large /var/log/messages
> >> to see if anything appears unusual.
> >>
> >
> > Well, this has been a waste of a day.  The problem is caused
> > by r273872.  This is the recent random device patch.  I have no
> > idea why removing a usb device would cause the system to lock
> > up other than random is probably trying to harvest some entropy.
> 
> + des / markm
> 
> That's a good catch! It's not a waste of a day. Thankyou for digging
> into it and finding out what introduced the failure.
> 
> Hopefully between Hans, des and markm a solution can be found.
> 

Shooting into the dark.  I added 'options RANDOM_DEBUG' to my
kernel.  Plugging in a USB device shows

kernel: ugen6.2: <USBest Technology> at usbus6
kernel: umass0: <USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus6
kernel: random: device_attach(): feeding 4 bit(s) of entropy from umass0
kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
kernel: da0: <  0.00> Removable Direct Access SCSI-2 device 
kernel: da0: Serial Number 08102201c42413
kernel: da0: 40.000MB/s transfers
kernel: da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C)
kernel: da0: quirks=0x2<NO_6_BYTE>

in /var/log/messages.  Now, when I immediately pull the device from
the USB port, I get

kernel: ugen6.2: <USBest Technology> at usbus6 (disconnected)
kernel: umass0: at uhub6, port 1, addr 2 (disconnected)
kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
kernel: da0: <  0.00> s/n 08102201c42413 detached

followed by a bricked laptop, which requires a depression of the
power button.

Is there a 'random: device_detach():' missing between the 'umass0'
and 'da0' messages in the last 4 lines.

-- 
Steve