Re: [PATCH] usb_storage: make usb-stor-scan task non-freezable

[Alan Stern]

On Sat, 23 Jul 2011, Seth Forshee wrote:

> After experimenting with this device more I came to the conclusion that
> the normal behavior with this machine is for the card reader to be
> disconnected from the USB bus unless there's a card in the slot. During
> a normal boot with an empty card slot the card reader never shows up on
> the bus.

Weird.  Then the reader would never be usable.  Unless it connects 
itself to the bus when a card is inserted?

>  But for some reason after S4 it shows up, but then some
> transaction errors happen due to no card being present (I can trigger
> the same errors by quickly inserting and removing a card) and the device
> is disconnected. This is only after S4 though -- if I set the
> hibernation mode to reboot or shutdown the errors don't happen. And I do
> not see the errors if I hibernate and then boot up with noresume, so
> it's not something that happens as a result of the restore process.
> 
> So at this point I'm pretty convinced that this is some kind of firmware
> issue and that there isn't much hope of fixing it. It's not even
> something that can be fixed by patching the AML, as no GPEs or AML
> methods are coming into play when all this happens.
> 
> > Maybe it would be better to come up with a freezable version of 
> > wait_for_completion().  You should ask for advice on the linux-pm 
> > mailing list.
> 
> I tried this, and it doesn't work. Well, it works in the sense of
> freezing khubd, but then khubd is frozen holding the mutex for the
> device, and the restore hangs later while trying to suspend devices.

Ah yes.  So much for that idea.

> The only solution I've come up with is to leave usb-stor-scan freezable
> without allowing it to actually freeze. We can request a fake signal be
> sent when freezing and use interruptible sleep to abort the wait early
> and finish up the thread's processing. This is implemented in the patch
> below. Does this approach look reasonable? It's rather subtle, but it
> does seem to work. I done numerous S4 cycles with and without a card
> inserted and didn't get any failures.

This runs the risk of failing to suspend if scanning takes too long.  

On the other hand, many systems nowadays use async scanning anyway.
And that combination of events isn't too likely to happen, whereas 
you're facing a real problem right now.  So I guess this is okay.

Alan Stern

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