On Tue, 19 Jan 2010 07:11:27 +0100
Hársszegi Tibor <Tibor.Harsszegi(a)scientificgames.hu> wrote:
I would hardly call these fixes. We just a find a way
our problem. However what we are unsure about is whether our fixes
"fine" enough (i.e. they integrate into the kernel infrastructure
"well"), or is there any other way to do it better (that is why I
was thinking about the USBDEVFS_RESET ioctl()).
Maybe it would be "good enough" to just disconnect ("eject") the
from userspace, removing the need for a kernel hack?
I have no Idea if you can "reconnect" the device without actually
physically unplugging / replugging it, but maybe Greg knows...
Sadly I can't agree on that, as it happens
"rarely" (naturally because
of that ONLY it could well be a firmware issue) and definetely
not all printers are affected (talking about cca. ten-thousand
deployed Uniboard printers overall, and talking about a few (below
100) "failing" pieces, and naturally swapping printers do not help,
so it is hard to blame the printer itself only, it might be that we
have a kind of "disturbance in the force" somewhere).
Yeah, or a USB controller that's a bit crappy (or the driver is a bit
crappy). I remember having "fun" with USB on ATI chipsets on notebooks
in a former life... ;)
Or a bad cable. Or EMI interference (my 3 USB-Serial dongles used as
serial-console monitore tend to disconnect and reconnect themselves
when I have to power cycle one of the embedded systems they monitor)...
... in the end, it does not really matter. You need a way to properly
reset the device if it's not functioning correctly anymore.
Good luck ;-)
"Any ideas, John?"
"Well, surrounding them's out."
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org