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.
> 

It is a waste in that I was going to spend the day working on powl().
My next window of time for powl() hacking is probably sometime in
mid to late December.

-- 
Steve