> Did you try replacing hubs ? Actually not, will try to ask our customer to rewire at least one affected configuration. Thanks, Tibor > -----Original Message----- > From: Viral Mehta [mailto:Viral.Mehta@xxxxxxxxxxxxxxx] > Sent: Wednesday, January 20, 2010 7:42 AM > To: Hársszegi Tibor; linux-usb@xxxxxxxxxxxxxxx > Subject: RE: USB HUB reset within FTDI_SIO is needed > > > > -----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. > > ______________________________________________________________________ > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
