Am 04.02.2013 20:25, schrieb Greg KH: > On Mon, Feb 04, 2013 at 08:17:04PM +0100, Alexander Holler wrote: >> Am 04.02.2013 13:05, schrieb Alexander Holler: >>> Am 04.02.2013 02:14, schrieb Greg KH: >>> >>>> So you are right in that your driver will wait for forever for a >>>> disconnect() to happen, as it will never be called. I don't understand >>>> the problem that this is causing when it happens. What's wrong with >>>> udlfb that having the cpu suddently reset as the powerdown happened >>>> without it knowing about it? >>> >>> There is nothing wrong with that. I've just explained why a problem >>> doesn't occur on shutdown but on disconnect (of the device). >> >> Maybe my explanation before was just to long and I try to explain it >> a bit shorter: >> >> If a device gets disconnected, the disconnect in udlfb might wait >> forever in down_interruptible() (because it waits for an urb it >> never receives). This even prevents a shutdown afterwards, because >> that down_interruptible() never receives a signal (at shutdown, >> because kernel threads don't get such). > > Where was that urb when the disconnect happened? The USB core should > call your urb callback for any outstanding urbs at that point in time, > with the proper error flag being set, are you handling that properly? I don't know where that urb is as I don't handle it. I just know that _interruptible doesn't make any sense and _timeout is necessary here. But as nobody else seems to have a problem, nobody else see seems to see the problem there and I seem to be unable to explain it, just ignore that patch. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
