Subject: Re: kern/28514: READ_FORMAT_CAPACITIES reply has 32-bit block count
To: None <jpk@panix.com>
From: Jason Thorpe <thorpej@shagadelic.org>
List: netbsd-bugs
Date: 12/02/2004 20:47:12
--Apple-Mail-22--812019029
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Dec 2, 2004, at 1:21 PM, jpk@panix.com wrote:

> When an Apple Xserve-RAID 2.8TB is plugged into an LSILogic
> LSI7202XP-LC fibre channel PCI-X card, the resulting drive, sd0, does
> not work and gives the following error:
> sd0(mpt0:0:0:0):  Check Condition on CDB: 0x23 00 00 00 00 00 00 00 0c
> 00
>     SENSE KEY:  Illegal Request
>      ASC/ASCQ:  Invalid Command Operation Code
>
>
>> How-To-Repeat:
> boot a system with above configuration
>
>> Fix:
> thorej suggested:
> It might require our sd driver to issue a different command to read the
> capacity, because the READ_FORMAT_CAPACITIES reply only has a 32-bit
> block count.

Ok, I looked at the latest SBC-2 draft.  For direct-access deviecs, 
0x23 is a vendor-specific opcode, so it's not surprising that not all 
vendors support it.  It was added in the following commit to 
scsipi_disk.h:

----------------------------
revision 1.9
date: 2003/09/17 23:33:43;  author: mycroft;  state: Exp;  lines: +31 -4
If READ CAPACITY fails, try a READ FORMAT CAPACITIES.  Separate this 
into
another function, always doing a page 0 MODE SENSE to get the block
descriptor if we use READ CAPACITY, and use SMS_DBD on the page 4/5 MODE
SENSE.  This does one extra command in some cases, but it separates and
simplifies the code a little.

Why do we prefer READ CAPACITY over READ FORMAT CAPACITIES?  Two 
reasons:
1) It's much older and is much less likely to have had its command code
abused, and is thus "safer" to try first.  2) ALL of my USB flash 
readers
and pen drives screw up their capacity descriptors -- mostly off-by-one
errors in the size (they return the maximum LBA number instead, a la 
READ
CAPACITY, which has *never* been how READ FORMAT CAPACITIES was 
documented
in the MMC spec), and one returns the "no media" code on slots that have
media inserted (despite returning almost-correct data otherwise)!

F*** me with a chainsaw.
----------------------------

Now, there is a new READ CAPACITY command ... there's the old 10-byte 
CDB and a new 16-byte CDB version.  The latter can return 64-bit block 
numbers.  I am still investigating.

         -- Jason R. Thorpe <thorpej@shagadelic.org>


--Apple-Mail-22--812019029
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBr+/QOpVKkaBm8XkRAiotAJ9POX+NmPBS6CZNlB1SUCcP03JsTACePMnZ
4BQflCSOTdiLJBQ98F1GFMk=
=fqva
-----END PGP SIGNATURE-----

--Apple-Mail-22--812019029--