On Tue, Oct 05, 2004 at 11:16:06AM -0400, Alan Stern wrote: > > One of my control messages is returning 'EPIPE' when my system is under > > heavy load. I'm stumped; does anyone have any suggestions? > > You're working on a kernel driver for this device, right? What does the > device do?
The driver lets you mount the device as a filesystem. (The device is *not* a mass-storage device.) You can browse the source code online: http://cvs.sourceforge.net/viewcvs.py/ifp-driver/linux-filesystem/ Or download the latest release: http://prdownloads.sourceforge.net/ifp-driver/iriverfs-r0.1.0.0pre7.patch.gz?download > > It's not an endpoint stall (clear_halt() fails). > > What do you mean by that? I don't think there's any way to get -EPIPE > other than by receiving a STALL token. And what do you mean, clear_halt() > fails? In what way does it fail? (Not that there's generally much point > in doing clear_halt() for endpoint 0.) After the control message returns -EPIPE, I've tried recovering by calling usb_clear_halt() but that also returns -EPIPE. I gather from the USB and kernel documentation that this signals a "protocol stall".. whatever that means. > > 90% of the time, I can > > work around by re-issuing the request (once). But the other 10% of the > > time, *both* requests succeed--even the original one that returned > > -EPIPE. > > How do you know the request succeeded? What _was_ the request anyway? Good question: I know because I've pulled my hair out trying to debug it. ;) The request is "please send me the next x bytes of data". Normally, you would issue a bulk transfer immediately after the control message to fetch the actual data. If you don't, it just skips those x bytes. You can tell when two requests succeeded because "end of file" arrives early, and the downloaded file is completely missing a block. > > Here are the details. It happens: > > > > -under heavy load (high disk activity) > > -uhcl chipset only (ohcl and ehcl behave) > > -linux 2.6.x (2.6.8.1, 2.6.9-rc3) > > -iRiver iFP-5xx device > > -usb_control_msg() > > -always the same control message. (One requesting bulk data.) > > I can't imagine that disk activity has anything to do with it -- unless > the iFP-5xx is a USB mass storage device and you're doing disk I/O to it > at the same time as your driver is running. That sort of combination is > known to cause problems in some devices. Of course, it wouldn't depend on > which host controller you use. I don't know enough about the usb subsystem to speculate.. but a busy disk would keep the system bus and interrupt controller busy. Could that be it? Thanks Alan, Geoff -- PGP fingerprint: 8ADC 92E1 6782 D034 E0E3 8EF4 EA4D 25E3 C17C 48D2 "If you want to learn more about guns, get a job at [an American] convenience store or visit our website at ... " --Michael Moore ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
