> Given ... your opinion that it's a firmware problem
We didn't just lose our test hardware, did we? Tell
me no? Please?
(-: As a firmware engineer, I'm prepared to claim,
"it's nearly always a host problem, not a firmware
problem". :-) Even objectively speaking, we know here
talking enough like Windows works.
> > > Would just sending one read command via SG_IO,
> > > rather than going for the whole mount of a
> > > volume, teach us anything?
> >
> > 'dd if=/dev/scsi/.../disc ...' succeeds on a
> > freshly-inserted card. Further reads tend to fail.
>
> Really? I'd like to see a log of that....
Me too!
A log including at least the first failure, and the
last success before that, please?
> > "usb-storage: > usb_stor_transfer_partial(): xfer 4096 bytes"
> >
> > AIUI this message is logged before any data moves
> > and just indicates how much information is
> > expected.
>
> ... means a request for copying 4096 bytes. After
> the transfer completes a status line is printed
> showing what actually happened.
Ah, thanks, in the fuller log sent since now I see
such context as:
usb-storage: Command INQUIRY (6 bytes)
usb-storage: 12 00 00 00 ff 00 00 00 6b 01 00 00
usb-storage: Bulk command S 0x43425355 T 0x1 Trg 0 LUN 0 L 255 F 128 CL 6
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 255 bytes
usb-storage: usb_stor_bulk_msg() returned -32 xferred 64/255
I'm a little surprised. I guess here we're back at a
level of Linux not yet tweaked to talk op x12 like
Windows does? Specifically, here we see
"-x 12 00 00 00 FF 00" -i xFF and not
"-x 12 00 00 00 24 00" -i x24?
> > How about sending a read command to an Lba beyond
> > the capacity?
>
> In other words, a command that should fail
> immediately rather than try to access the media?
> Interesting thought....
Not just any command that should fail, but a command
that should fail that the kernel will expect to
stream blocks quickly, presuming the kernel makes
such distinctions among commands without regard to
the parameters of the command.
> > Linux `dd` can... be persuaded to try reading
> > from a volume that hasn't yet been mounted?
>
> Yes, it can. But since dd will go through sd.c,
> I don't see much point.
If a given SCSI command works anywhere in Linux, then
divining why it doesn't work during mount grows
easier?
> bInterfaceProtocol does, in fact, = x06 SCSI.
Ah, later I received the log line:
bInterface Class:SubClass:Protocol = 08:06:50
bInterfaceProtocol x06 may mean Windows sends
bCBWCBLength in x 06 0A 0C 10 rather than always x0C.
I have no idea what the effect on zero padding is.
> anyone know what Mac OS X does
Not me. Mac Open Firmware boot Forth works ok, but
OS X currently has no SCSI pass thru i.e. no analogue
of Linux SG_IO, for the bootable PDT's x 00 05 07 0E.
> my recent suggestion that he try 8020 instead of
> SCSI, where such padding is done.
I replied before I received that, sorry.
> > "L 4096" here might mean
> > dCBWDataTransferLength = x1000 (4096)
> > = x00:08 * x200.
>
> Yes.
Thanks for saying.
Still I wonder if "CL = 10" means bCWBCBLength in a bus trace.
> ...
Cheers, Pat LaVarre
N�HY隊X���'���u���*m�(Z�W��謞�(���z�+i�"��v����^��y�+����)�n�
�)�~�ڝ�ay�Z�Ǩ��)�jp)�W�>�a����l���q���z�܂&���v*�r�e���M�zyb��n��^��e��l���q���z��{.n�+�����azV���+����֭��i����l���q���z���l�X��)ߣ�b��n��^��
