On Fri, 8 Jul 2005, Jonathan Selby wrote:

> 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.

That's usbfs; its old name was usbdevfs.  devfs was something quite 
different, now obsolete.

Sending URBs through usbfs shouldn't be different in any significant way 
from submitting them directly from your 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

Is the driver loaded and running at the time you run your script?  Or do
you run the script first and then load the driver afterwards?  Does the
driver start sending out iso transfers as soon as the probe routine
finishes, or does it wait until a user process opens the device?  Does
your script send the control request at the same time as the driver is
unsuccessfully trying to do iso transfers (which then suddenly start to 
succeed)?


> > 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.

Does it make a difference if instead of sending that control request from
within your probe routine, you use schedule_delayed_work so that the
request gets sent after your probe has finished?  That would mimic more
closely what happens when you run the script by hand.


> > 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.

That is another very strong indication that this isn't related to any of
the kernel drivers (something you already suspected because of the debian
behavior) but has to do with the device itself.


> > 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.

And 2.6.11 from kernel.org didn't work with SuSE 9.3?

> 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.

It might be worth giving this a try with the SuSE 9.3 machine.  If your 
driver works in a bare-bones environment with essentially no other user 
programs running, then the problem must be triggered by some program or 
daemon installed by the distribution.  I've seen several examples of 
strange behavior caused by the hald program, for instance.

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

Reply via email to