> From: BLACKSON Jim [mailto:[EMAIL PROTECTED]] ... > I wonder if the dropped packet was lost on the > wire, or perhaps due to wrong data toggle (so first > packet was dropped).
Ah, that sounds like the early days of Usb1 FS. :-) > the (extra 13 bytes) CSW ended up in the users > buffer, which isn't supposed to happen in BBB > Bulk-only Prot=50. :-) I have trouble swallowing the "n't supposed" here? I read your ":-)" as meaning ... Anything can happen with any protocol, given the right bug. To design a usb storage protocol, we have to guess which bugs are too common to ignore. The DWG published CBI first, BBB later. BBB, as written, lets the host choke off control pipe byte/s, lets the host fall off the thin diagonal, and lets the host track devices by serial number. CBI not. But BBB, as implemented, is far less robust. Sure, on paper, only CBI guarantees indefinite NAK in places off the thin diagonal. But actual devices have been seen to choke in places off the thin diagonal. Also to forge serial numbers. Hence the push for a compliance test. In CBI, failing to function off the thin diagonal isn't a compliance failure. Nor is forging a serial number. Hence the push to obsolete CBI. (At least, these are My reasons for Not fighting that push.) Cheers, Pat LaVarre -----Original Message----- From: BLACKSON Jim [mailto:[EMAIL PROTECTED]] Sent: Thu 12/12/2002 1:09 AM To: USB Developers; 'Matthew Dharm'; Pat LaVarre Cc: Greg KH; David Brownell; USB Storage List Subject: RE: [usb-storage] Re: [linux-usb-devel] Re: PATCH: usb-storage: make internal structs more consistent Matthew Dharm wrote: > Oh... excellent observation, Pat. A dropped packet would produce almost > exactly this sort of thing... Yes. (But in this case the (extra 13 bytes) CSW ended up in the users buffer, which isn't supposed to happen in BBB Bulk-only Prot=50. :-) I wonder if the dropped packet was lost on the wire, or perhaps due to wrong data toggle (so first packet was dropped). You know, that 13-byte short packet at the end of the bulk data stream worked pretty well to terminate the data transfer. Maybe BBB 2.0 should always terminate the data phase with a short/null packet. Makes for a nice marker on the wire. Then every phase of BBB: command, data, status terminates with a short packet. Might be able to eliminate some stalls that way. :-) Best regards, jimb. Jim Blackson ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
