On Tue, 19 Jan 2010 07:11:27 +0100 Hársszegi Tibor <Tibor.Harsszegi@scientificgames.hu> wrote:
I would hardly call these fixes. We just a find a way to vanish/handle 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 device 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 ;-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org