Alan Stern wrote:
> 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)?
>
>
The driver is loaded and running. When the device is first plugged in it
has a different PID. Using a hotplug script, firmware is loaded and the
device re-enumerates, At this point the driver is loaded automatically.
After the probe returns, I run the script.
The device driver then stays idle until the host application software is
run.
The host software can then be loaded at any time after that - in reality
a few minutes later. Bulk out packets are successfully sent and then the
ISO transfers start.
I just ran an experiment to run the script while the bad iso transfers
are occurring. If this is done the problem clears itself up and the
packets are returned properly.
>
>
> 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.
>
>
I will try this and report back.
>
> 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.
>
>
>
>
> And 2.6.11 from kernel.org didn't work with SuSE 9.3?
I have not tried this though I did have the same problems with 2.6.12.1
from kernel.org
>
>
>
> 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.
>
I agree this seems to be the root of the problem. I will do some
selective killing and see if we can narrow this down. To run the
software I do need a working X environment.
All The Best
Jonathan
> 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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
