Fwd: the Rbc abominations - op x1A ModeSense(6)

Pat LaVarre LAVARRE at iomega.com
Thu Mar 28 12:57:04 PST 2002

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
[[[ Some Sbp3 folk tell me t10 folk would be less bored by this topic than other folk? ]]]

>>> Pat LaVarre 03/28/02 12:02PM >>>

Anybody here yet made sense of how Microsoft WinMe mangles op x1A ModeSense(6) on the way to 1394 Sbp2 Rbc devices?

Here now I'm looking at a device whose op x12 Inquiry data says x 0E 00 04 02 1F ... i.e. x04 Spc2 x0E Rbc, ...

>From this device, thru an unfiltered driver, the ModeSense(6) Cdb -x 1A 08:3F:00 12 0 -i x12 copies in the bytes x 11:00:00:00 86:0B:00:02 00:00:02:54 29:80:00:01 00:00.

Ok, granted this is a creatively designed device.  We have the four byte header x 11:00:00:00, the page x 86:0B:00:02 00:00:02:54 29:80:00:01 00 with its rude not-a-multiple-of-four-thank-you standard length x0D, but then we have a final spurious zeroed byte.

But what's really bizarre is how this looks thru Microsoft WinME console Aspi.

There the data copied in arrives with residue accurately reported, so we know it's not coming from Spb2.  But the actual bytes copied in are x 88:0C:04:00 00:00:00:00 00:00:00:00 00:00:00:00 00:00.  This looks like data for a variation of mode page x0C NotchAndPartition that contains only x0A bytes rather than the usual x18, except this data is bereft of its four byte header and includes EIGHT spurious x00 bytes at the end.

Anybody have any idea what Microsoft thinks they are trying to accomplish here?  How can such filtering possibly make sense?

Curiously yours,

x4402 Pat LaVarre   p.lavarre at ieee.org 

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list