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 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 Two problems with this approach. 1 The script has to be run as root and as such is not customer friendly. 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. 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. Jonathan Selby Director - Software Development Xaxero Marine Software Engineering Ltd at skype.com - xaxjon Satellite Phone (00) 88163 142 9922 Cell Argentina (54) 929 0160 2064 (00) 64 (0)9 412 7580 fax (00) 64 (0)9 412 7579 http://www.xaxero.com Software for extending your horizon.... Alan Stern wrote: > On Mon, 4 Jul 2005, jon wrote: > > >>OK Here is the new DMSG output with the unit connected > > > This shows VMware sending three messages to the device, which might be > enough to get it working properly. Those three messages are: > > Get-Descriptor request for string descriptor 0, length 4 > (i.e., get the default language code) > > Get-Descriptor request for string descriptor 1, length 514 (?) > > Get-Descriptor request for string descriptor 2, length 514 (?) > > Presumably those last two requests are attempts to fetch the > Manufacturer and Product strings. They didn't work, maybe because of the > peculiar lengths or maybe because they used the wrong descriptor index > numbers. (lsusb -v will show what the correct index numbers are, and > evidently Linux was able to read the strings okay because they showed up > in your /proc/bus/usb/devices file.) > > You can see those requests near the end of the log file you sent. Look > for the three sections that start with a line saying: > > usb 2-1: usbdev_ioctl: CONTROL > > Perhaps if you send equivalent requests at the start of your driver, the > device will start working. > > 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
