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).
So the change from down_timeout() to down_interruptible() in
dlfb_free_urb_list() with commit
33077b8d3042e01da61924973e372abe589ba297 only results in that the
following code (thus the break there) will never be reached if an urb
got missed (because of a disconnect).
And the accompanying comment (... at shutdown) is misleading, because on
shutdown, the kernel thread which calls dlfb_free_urb_list() never gets
a signal, so the interruption just never happens.
As I've experienced the "missing urb on disconnect" problem quiet often,
I've changed that down_interruptible() to down_timeout() (in v1 and in
v2 to down_timeout_interruptible, because I wasn't aware that no signal
arrives on shutdown).
Hmm, ok, that explanation isn't much shorter. ;)
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
