[opensuse-kernel] USB HUB reset within FTDI_SIO is needed
Hi, our company uses the FTDI_SIO based USB 2.0 printer. This printer has "ill habits" so that sometimes it gets stuck and no longer replies to usb_control_msg()-es. We had a "fix" for this behaviour to change 2 USB related modules within the Linux kernel. 1.) FTDI_SIO, we changed this to "overrule" the regular usb_control_msg() with our own wrapper. Within this wrapper we counted within 60 second the number of unacked usb_control_msg()s and if that reached 10, we restarted the complete USB HUB owning our printer (we had to kickstart the HUB instead of the printer as restarting the printer didn't help). 2.) HUB.C, To be able to restart the HUB we had to change this as well to make usb_kick_khubd (as that was used within FTDI to restart the HUB). Both of these changes seemd to flawlessly work without full kernel recompilation as both of the affected codes were built by default as "modules" into the OpenSuse kernels. But it has changed in 11.2 because of USB/boot speed-up purposes. Can any of you propose any alternative solution to our problem so that we : * don't need to do a full kernel recompliation, thus we can use the plain, vanilla kernel delivered on the standard 11.2 distro * the changes still work as our patch works now, i.e. without any kind of user interaction, automatically we can kickstart a given USB HUB which owns a given device (no clue, but maybe we could sniff /proc/bus/usb/devices and do a USBDEVFS_RESET on the owner of our device?) Thanks in advance, Tibor Harsszegi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Mon, Jan 18, 2010 at 02:34:34PM +0100, H?rsszegi Tibor wrote:
Hi,
our company uses the FTDI_SIO based USB 2.0 printer. This printer has "ill habits" so that sometimes it gets stuck and no longer replies to usb_control_msg()-es. We had a "fix" for this behaviour to change 2 USB related modules within the Linux kernel.
Why not send these fixes to the upstream developers so you do not have to constantly rebuild things for new kernels? That's the best way to resolve this issue. Oh, and it sounds like you should really fix your printer's firmware, it seems quite broken. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Hi,
Why not send these fixes to the upstream developers so you do not have to constantly rebuild things for new kernels? That's the best way to resolve this issue. 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()).
Oh, and it sounds like you should really fix your printer's firmware, it seems quite broken.
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). Thanks, Tibor -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Jan 19, 2010 at 07:11:27AM +0100, H?rsszegi Tibor wrote:
Hi,
Why not send these fixes to the upstream developers so you do not have to constantly rebuild things for new kernels? That's the best way to resolve this issue. 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()).
How about sending your patches to the linux-usb@vger.kernel.org mailing list and we can discuss it there? That's the proper place for this. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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
On Wed, Jan 20, 2010 at 09:00:07AM +0100, Stefan Seyfried wrote:
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...
No, you can not reliably do this from software, not all hardware allows this to happen, sorry. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Greg KH -
Hársszegi Tibor -
Stefan Seyfried