RE: USB HUB reset within FTDI_SIO is needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----Original Message-----
From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Hársszegi Tibor
Sent: Wednesday, January 20, 2010 11:51 AM
To: linux-usb@xxxxxxxxxxxxxxx
Subject: USB HUB reset within FTDI_SIO is needed

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).

Did you try replacing hubs ?


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.

Same did you try replacing hub ?

Thanks in advance,

Tibor Harsszegi




______________________________________________________________________

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________
��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux