Hi, our company uses a 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. (Check attachment, those are for the OpenSuse 11.1 2.6.27.7-pae 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 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) public. 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 recompilation, thus we can use the plain, vanilla kernel delivered on the standard 11.2 distro * the changes still work as our patches work 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 printer (on the HUB)?) Must highlight that naturally we are not sticking to kernel solution, any user space solution would do the trick if that behaves the same way. * Also have to mention that some might think that first we should fix the printer if that gets frozen is certain circumstances. Sadly the situation is not that crystal-clear, as we have cca. 10 thousand Uniboard based printers deployed to different customers and only a few (below 100) fails like this. And it complicates the case that even swapping printers do not help, so we could not figure out a better solution than this. Thanks in advance, Tibor Harsszegi
Attachment:
hub.c.patch
Description: hub.c.patch
Attachment:
ftdi_sio.c.patch
Description: ftdi_sio.c.patch
