On Thu, 7 Jul 2005, Jonathan Selby wrote: > OK we are narrowing this down. > > If I put the ctrl transfers in my driver at the PROBE they work but the > ISO transfers still fail with a -84 at the transfer buffer level in the > call back. > > I wrote a script to access the device via DEVFS
You mean via usbfs? > and generate similar > messages to the VMware log. As you can see the direction is different > from VMware and of course my ctrl transfer fails but that one attempt is > enough to kick start the process and my driver works perfectly henceforth. > > Jul 7 08:56:46 bluelinux kernel: usb 1-1: usbdev_ioctl: CONTROL > Jul 7 08:56:46 bluelinux kernel: usb 1-1: control write: bRequest=80 > bRrequestType=06 wValue=0300 wIndex=0000 > Jul 7 08:56:46 bluelinux kernel: usb 1-1: control write: data: 00 00 00 00 > Jul 7 08:56:46 bluelinux kernel: usb 1-1: usbfs: USBDEVFS_CONTROL > failed cmd ctrl_in rqt 6 rq 128 len 4 ret -110 Does it make any difference if you use an IN transfer in your script (like VMware did) rather than an OUT transfer? Why do you think doing this from a script should be any different from doing it during your driver's probe routine? The only difference I can think of is timing. Does it help if you add a few seconds delay to your probe before sending that control request? Or afterward, but before you begin submitting the ISO transfers? All these tests were done using the EHCI driver, right? Does anything change if you rmmod ehci-hcd and run at full speed instead of high speed? > Two problems with this approach. > > 1 The script has to be run as root and as such is not customer friendly. If you get the equivalent functionality to work from your driver then you won't need the script. > 2 While this "band aids" the problem, I would like to know why this > happens. Perhaps some memory space is being freed up or something. The two possibilities seem to be that something gets changed in the EHCI driver or that something gets changed in the device's internal state. > Perhaps I am missing some initialization step that slipped through the > cracks on earlier SuSE configurations. > > Any suggestions or approaches anyone may have for investigating this > would be much appreciated. > > As some history we have nailed this partly to not being a kernel issue > directly as it runs on a Debian machine running 2.6.11. I think you said earlier that SuSE 9.3 would work with 2.6.10 and not with 2.6.11. Is that correct? And yet the driver does work with Debian and 2.6.11. Were these kernels modified by the distributions or did they come directly from kernel.org? One way you might be able to minimize the effects of the different distributions is to boot into single-user mode. Or even better (although it's not so easy to do this correctly), boot with "init=/bin/bash" and set up the entire environment by hand. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
