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

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.



-adrian