Re: firmware download competes with system sleep

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 19 Jun 2010, Marek Vasut wrote:

> Dne Pá 18. Ä?ervna 2010 23:30:12 Paul Fox napsal(a):
> > i'm not sure this is really a libertas issue -- it might
> > be more of a USB issue.  in any case, on an XO-1 laptop
> > running the OLPC variant of 2.6.31, there's a problem if a firmware
> > download is happening at the time that the system tries to suspend.
> > the firmware task refuses to be "frozen", and the system hangs
> > with:
> > [  375.148013] Freezing of tasks failed after 20.00 seconds (1 tasks
> > refusing to freeze):
> > 
> > there's a full log attached to http://dev.laptop.org/ticket/10176,
> > where you can see that device (re)discovery starts in the middle
> > of the system trying to suspend.

Yes, a nasty race.  The khubd thread was waiting for the firmware 
transfer to complete before it would freeze, and the transfer didn't 
occur because userspace was already frozen.

That's why we have timeouts.  Setting the firmware transfer timeout 
to something below 20 seconds would have helped.

> > as i implied above -- i'm not really sure where to start on this.
> > the XO is a little bit unique in that we do a hard reset of the
> > wlan device when we detect excessive command timeouts.  it's
> > possible that this changes the sequencing of device discovery, but
> > i'd think any device insertion while the system is heading to sleep
> > might be an issue.

Mostly when device discovery depends on userspace doing something,
like sending a firmware update to the device.  But there are other 
things that can cause delays.  USB device initialization in particular 
has so many nested retry loops that a really badly behaved device can 
monopolize khubd for several minutes before the system gives up.

One possible solution to the problem at hand is to make threads check
whether they should freeze while waiting for a firmware transfer to
complete.  But how well do devices tend do work if they get suspended
in the middle of a firmware transfer?  Maybe aborting the transfer
(if it has already started) would be better than freezing.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux