Alan Stern wrote:
> On Wed, 13 Dec 2006, Garrett D'Amore wrote:
>
>
>> I've done some more debugging. I've not had success in getting a debug
>> kernel built that will boot my system (Ubuntu) yet, and I don't know why
>> _that_ is a problem, but it takes ~4 hours per attempt (compiling Linux
>> is _slow_ on this Via 1GHz system), so I took a different tack.
>>
>
> You know, you don't need to recompile an entire kernel from scratch every
> time you make one little change. Don't do "make clean" in between; the
> kernel build system will then recompile only the files that need it.
> Building a kernel the first time might take a long while, but making small
> changes should take only a minute or two.
>
Yeah, except that I think I have to reconfigure with a different
"version number" in order to make the kernel work with Ubuntu.
(Apparently the root disk image has a specific kernel version encoded in
it. :-( Coming from NetBSD and Solaris, the Linux kernel module
versioning scheme is a real PITA.
I'll have another go at it in a little bit. (Too bad I can't just load
a module with the debug facility in it. :-(
>
>> I started using the ioctls directly, and specifically the USBDEVFS_BULK
>> ioctl. I _think_ the Linux framework is dropping bulk-in packets. More
>> below:
>>
>> This is for a mass storage device.
>>
>> The results I'm seeing look like:
>>
>> Bulk-Write 31 bytes (CBW)
>> dCBWDataTransferLength = 36
>> bmCBWFlags = 0x80 (transfer from device to host)
>> bCBWLUN = 0
>> bCBWCBLength = 06
>> CBWCB = 21 data bytes
>>
>
> I hope you mean 16 here, not 21. If the CBWCB were 21 bytes then the
> total length of the CBW packet would be 36 bytes instead of 31. Not to
> mention that you would greatly confuse the mass-storage device.
>
Yeah, sorry about that. I counted the bytes incorrectly.
>
>> Bulk-Read, requested 36 data bytes (expected SCSI data), did not arrive
>>
>> instead
>>
>> Bulk-Read, got 13 data bytes (instead of 36), corresponding to CSW
>> - all values other than dCSWSignature are 0
>>
>> So instead of getting my 36 byte data packet, followed by the 13 byte
>> CSW, I instead just get the 13 byte CSW.
>>
>> I _think_ that the first 36 byte bulk-in packet is getting
>> dropped/overwritten by the second bulk-in packet.
>>
>
> You don't have to guess about these things. Use usbmon; that's what it's
> for (instructions in Documentation/usb/usbmon.txt).
>
Again, the problem is getting a kernel built with the necessary debug
facilities. As I indicated, I think this may be my own Linux (or maybe
Ubuntu) kernel ineptitude. I'll have another go, though.
>
>> Is this normal,
>> expected behavior?
>>
>
> Of course not.
>
_That_ is good news. Now I just need to figure out what is happening to
the 36-byte packet.
>
>> Do I need to just spawn a reaper thread that hangs
>> around picking up bulk-in packets and puts them in a userland queue?
>>
>
> No.
>
>
>> I
>> had heretofore assumed that I could just do the bulk ioctls (I've seen
>> similar behavior using libusb, which uses submiturb and reapurbndelay)
>> and pick up the data when I'm ready for it. Am I misunderstanding
>> something?
>>
>
> No, your understanding is correct.
>
Whew. That's a good thing. I wasn't looking forward to rewriting my
code yet again. :-)
Thanks for your help. I'll get back to you with what I find once I get
a debug kernel that works in Ubuntu.
-- Garrett
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
