It does look from the trace like the in-direction is getting to the device first. You could enable the "urb tracing" in the javax.usb.properties file to get more detailed tracing about each URB, but I'm pretty sure everything looks right from the javax.usb perspective.
To get a bus trace, you need a USB bus tracer (hardware trace machine). They unfortunately are very expensive :( You could add debugging to the Linux kernel to see if it's getting the missing data, but I really, really doubt that is the case. I strongly suspect the device is not sending your first response that you're looking for. I don't know why, it's possible the device spec would tell you, or maybe it's device firmware bug. Sometimes different vendors making the same type device will all use common firmware. Do you have the device's spec? Are you absolutely sure you should be getting the first response that you're missing? On Mon, 9 May 2005, Dmitri Kostioukov wrote: >Quoting Dan Streetman <[EMAIL PROTECTED]>: > >> >> Your emailer is line-wrapping the JNI trace...can you resend as an >> attachment? > >Attached > >> I just want to verify with the JNI trace that the in-direction buffer is >> getting submitted before the out-direction buffer. It looked like, from >> the JNI trace you sent, that the out-direction buffer was getting sent out >> before the in-direction buffer. > >I'm not sure which is out and which is in-direction in the trace. > >> Remember that creating threads takes time, so if you're doing: >> >> inThread.start(); >> outPipe.syncSubmit(buffer); > >Just to elliminate this issue, I put it to sleep for 3 seconds after starting >threads. I think it should be enough time. > >With all that in mind, it's quite possible that something is going on in my >kernel that causes it which is why I'd like to run some kind of sniffer if I >knew how. > >> chances are the out-direction buffer will ALWAYS get to the device well >> before the in-direction buffer. If you're using a seperate Thread >> to manage the in-direction buffer(s), maybe you should add a 10ms (or >> more) delay to make sure the in-direction buffer(s) get to the device >> before submitting the out-direction buffer? >> >> >> On Mon, 9 May 2005, Dmitri Kostioukov wrote: >> >> >Quoting Dan Streetman <[EMAIL PROTECTED]>: >> > >> >> >> >> I have to assume the device is really not sending the first response you >> >> are expecting. Without knowing the device protocol, I have no idea why >> >> your device would skip that. >> > >> >At first I assumed it was a problem with a device itself. But like I >> mentioned >> >earlier - it happens with 3 different devices by 2 different manufacturers >> with >> >independent communication protocol. I can send pretty much and command and >> even >> >if the command itself is acknowledged by the device, I still do not the the >> very >> >first 8 byte response. >> > >> > >> >> If you can get a USB bus trace, you could check if the device was actually >> >> >> sending the first response (and so show that javax.usb is dropping/losing >> >> >> the response). However I think it's much more likely the device just >> >> isn't sending that response. >> > >> >What's the easiest way to do it? I'll try. >> > >> >> On Mon, 2 May 2005, Dmitri Kostioukov wrote: >> >> >> >> >Quoting Dan Streetman <[EMAIL PROTECTED]>: >> >> > >> >> >> >> >> >> If it's an interrupt pipe then you have to submit your buffer before >> you >> >> >> send the command down. Interrupt pipes are only polled when you pass a >> >> >> > >> >> >I definitely do. >> >> > >> >> >> buffer to the USB subsystem to use (i.e. to put poll data in). You >> need >> >> >> to submit several buffers so the USb subsystem always has a buffer to >> put >> >> >> >> >> data in, and can thus maintain the spec-required polling interval for >> >> >> interrupt endpoints. >> >> > >> >> >What I do is start a separate threat which does nothing but submits the >> >> >in-buffer but just in case it could be the root of the problem, I >> modified >> >> it to >> >> >start multiple threads instead. The problem still exists. The output is >> >> below: >> >> > >> >> >Device found >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Listening >> >> >Out: 8b 0 0 0 0 0 0 0 >> >> >Sent >> >> >In: 0 4 0 0 0 0 0 0 >> >> >Done >> >> >Out: 8b 0 0 0 0 0 0 0 >> >> >Sent >> >> >In: 0 0 3 0 0 1 1 2 >> >> >Done >> >> >In: 0 4 0 0 0 0 0 0 >> >> >Done >> >> > >> >> > >> > >> >> -- >> Dan Streetman >> [EMAIL PROTECTED] >> --------------------- >> 186,272 miles per second: >> It isn't just a good idea, it's the law! >> > > > -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
