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

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.

-- 
Steve