On Tue, Feb 05, 2013 at 08:08:28AM +0100, Alexander Holler wrote: > 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. What do you mean by that? The urb is being sent back to your driver, right? If not, that's a bug, but please be sure that your urb callback isn't really being called. thanks, greg k-h -- 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
