> Do you have the device's spec? Are you absolutely sure you should be > getting the first response that you're missing?
All devices are request/response. You send a request and get one or more 8 bytes response buffers. In this specific case (8b) I'm requesting a status, which is supposed to return 2 buffers. The first time around I only get 1 buffer back, all successive request work fine. So I'm pretty sure the first response is missing. It is thoretically possible that all 3 devices use the same chipset, which has this bug but for some reason I don't think so. Plus, I'm pretty sure it works with original software in windows. I'll try to get windows sniffer to work and verify it. > You could add debugging to the Linux kernel to see if it's getting the Can you tell me where to add those? I could simply work around this issue but I really want to get it fixed. > 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 Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
