On Wed, Jan 20, 2010 at 07:20:56AM +0100, H?rsszegi Tibor wrote: > 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). Minor nit, patches should be in '-u' format so we can read them better, and apply them. Also, can you break out the 'new device id' portion of this patch, and resend it with a proper signed-off-by: to me so that I can apply it to the kernel tree so you don't have to keep changing that part of the driver? There's no reason that can't go into the kernel now. > 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 We can work to find the root cause of this problem, yes. > * 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. Like someone stated, this might be a hub problem. Also, if you do find a broken system, is it usually the host that always has it, as you say switching the printer fixes the issue. And if so, can you run 'usbmon' to get a trace of what is happening on the wire to see what is really going on here? thanks, greg k-h -- 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
