Please see comments in text:
Alan Stern wrote: >> 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? Using calls ioctl(fd, USBDEVFS_CONTROL, &ctrl) the file descriptor was found in /proc/bus/usb searching on PID and VID rather than using the driver. >> >> > >>>> 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? None at all - using the in (correctly formatting the call) results in identical output to the VMWARE call and the driver starts working. Jul 8 08:35:08 bluelinux kernel: usb 1-1: usbdev_ioctl: CONTROL Jul 8 08:35:08 bluelinux kernel: usb 1-1: control read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 Jul 8 08:35:08 bluelinux kernel: usb 1-1: control read: data 04 03 09 04 >> >> 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? Good question - I put up to 10 seconds msleep both before and after the ctrl transfer and this made no difference. >> >> 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? >> No Change packets are still returned with -84 and after running my script everything works fine. >> > >>>>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. >> >> Agreed. >>>>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? >> 2.6.10 and 2.6.12 were clean kernels from kernel.org. 2.6.10 worked 2.6.12 did not. The debian 2.6.11 is from the knoppix 2.8.2 distro. I beleve this is fairly untouched. >> 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 >> >> >> ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
