Hi, > 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. Ok, will do that. > > (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. Sorry, might have been not quite clear. Swapping the printers do NOT help. > 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? We are currently under a discussion with the customer to see whether we can get a clear statement about: a.) Whether the issue is reproducible with a certain machine b.) If yes can we get the machine Cheers, t. > -----Original Message----- > From: Greg KH [mailto:greg@xxxxxxxxx] > Sent: Wednesday, January 20, 2010 3:43 PM > To: Hársszegi Tibor > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: USB HUB reset within FTDI_SIO is needed > > 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
