On Thu, Sep 03, 2009 at 07:08:17PM +0800, Gergely Imreh wrote: > 2009/9/3 Gergely Imreh <imrehg@xxxxxxxxx>: > > 2009/9/3 Greg KH <greg@xxxxxxxxx>: > >> On Thu, Sep 03, 2009 at 09:09:54AM +0800, Gergely Imreh wrote: > >>> Dear Christoph, > >>> > >>> 2009/9/2 Zimmermann Christoph <christoph.zimmermann@xxxxxx>: > >>> > hi gergely > >>> > > >>> > please read the mailing list archives before you ask a question. > >>> > yes you are absolutely right, the behaviour you see is what we also reported here on the mailinglist. i'm a usbtmc driver user, not a kernel hacker, so i follow the mailing list and wait for patches to test. > >>> > >>> Yes, I read the archives before posting and I've seen two messages in > >>> the last few months with similar issues. > >>> 1) "Is anyone maintaining (or even using) usbtmc?" thread in the > >>> beginning of August which ended with no conclusion, just a guess that > >>> maybe the firmware is wrong. I know that it is not the case here. > >>> 2) "usbtmc driver" thread - I think by you in June, where with a > >>> usbmon log, but then left the further questions unanswered (at least > >>> they are not on the list). > >> > >> Hm, I do have a number of usbtmc patches queued up for the next kernel > >> release that might resolve some of these issues. Could you run the > >> latest linux-next release to see if that resolves them? > >> > > > > Tried it with: > > echo "*IDN?" > /dev/usbtmc0 > > cat /dev/usbtmc0 > > > > On the visible side, all the same (timeout error, occasional no > > answer). Using usbmon, there's a little difference, the trace now > > loooks like this > > > > f660f480 4084277869 S Bo:3:003:6 -115 20 = 0126d900 06000000 01000000 > > 2a49444e 3f0a0000 > > f660f480 4084279150 C Bo:3:003:6 0 20 > > > f660f480 4087365550 S Bo:3:003:6 -115 12 = 0227d800 f1070000 000a0000 > > f660f480 4087366642 C Bo:3:003:6 0 12 > > > f660f480 4087366672 S Bi:3:003:5 -115 2048 < > > f660f480 4087373634 C Bi:3:003:5 0 60 = 0227d800 30000000 01000000 > > 54454b54 524f4e49 582c5444 53203130 3132422c > > f660f480 4087373691 S Bo:3:003:6 -115 12 = 0228d700 f1070000 000a0000 > > f660f480 4087374630 C Bo:3:003:6 0 12 > > > f660f480 4087374661 S Bi:3:003:5 -115 2048 < > > f660f480 4087384632 C Bi:3:003:5 -2 0 > > > > Here the difference compared to the one in the thread start is that > > previously the conversation ended with something like: > > f672ae00 2503575589 S Ci:3:113:0 s a2 03 002b 0085 0002 2 < > > f672ae00 2503583450 C Ci:3:113:0 -2 0 > > which is now not present. Not sure if this signifies anything. > > > > I've been trying to get the agilent usbtmc driver to work so there 's > > someting to compare with, but it fails at the moment... > > > > Cheers, > > Greg > > > > Got the Agilent driver working, the same command: > echo "*IDN?" > /dev/usbtmc0 > cat /dev/usbtmc0 > > Output of usbmon: > f6b4fe80 1957891403 S Bo:3:003:6 -115 20 = 0106f900 06000000 01000000 > 2a49444e 3f0a0000 > f6b4fe80 1957892450 C Bo:3:003:6 0 20 > > f6809380 1959423246 S Bo:3:003:6 -115 12 = 0207f800 e20f0000 000a0000 > f6809380 1959425195 C Bo:3:003:6 0 12 > > f6809380 1959425301 S Bi:3:003:5 -115 4096 < > f6809380 1959432199 C Bi:3:003:5 0 60 = 0207f800 30000000 01000000 > 54454b54 524f4e49 582c5444 53203130 3132422c > > Seems to have larger buffer, and not sending an extra read to the device? Yes, looks that way, the usbtmc driver is using 2048 as a buffer size. If you change the #define at the start of the driver to 4096, does it work better for you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
