USB drive serial numbers

[Scott Long]

Sean Bruno wrote:
> Scott Long wrote:
>> Sean Bruno wrote:
>>> Can someone send me the output of "camcontrol inquiry daX" where daX 
>>> is a usb attached hard drive?  I'm interested to know if the USB 
>>> external hard drives report a serial number as the USB flash drives I 
>>> currently have in my possession do not report one.
>>>
>>> eg:  SCSI hard drive:
>>> sudo camcontrol inquiry da0
>>> pass0: <SEAGATE ST373207LC D701> Fixed Direct Access SCSI-3 device
>>> pass0: Serial Number 3KT17YJL
>>> pass0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged 
>>> Queueing Enabled
>>>
>>>
>>> eg: USB flash drive:
>>> sudo camcontrol inquiry da3
>>> pass4: <TOSHIBA TransMemory 5.00> Removable Direct Access SCSI-0 device
>>> pass4: Serial Number
>>> pass4: 40.000MB/s transfers
>>>
>>
>> CAM used to assume that all DA devices supported the serial number EVPD
>> page.  I recently changed it to query the device for the list of pages
>> it does support, and only ask for the serial number page if it does
>> (which in turns cuts down on a whole lot of kernel printf noise).  My
>> experience is that some devices do, but most devices don't.  If you want
>> to check your devices manually, do:
>>
>> camcontrol cmd pass0 -v -c "12 01 00 00 255 00" -i 255 "-" | hd
>>
>> If 0x80 appears after the 4th byte, the device claims support for
>> querying the serial number.  The serial number can then be fetched with
>>
>> camcontrol cmd pass0 -v -c "12 01 80 00 255 00" -i 255 "-" | hd
>>
>> Or via
>>
>> camcontrol inq pass0 -S
>>
>>
>> Scott
> 
> Hrm....it looks like asking for page 0x80 directly is returning the same
> as requesting page 0x80 or asking for all pages:
> 
> sudo camcontrol devlist
> <SEAGATE ST373207LC D701>          at scbus0 target 0 lun 0 (da0,pass0)
> <SEAGATE ST373207LC 0003>          at scbus0 target 1 lun 0 (da1,pass1)
> <PE/PV 1x2 SCSI BP 1.0>            at scbus0 target 6 lun 0 (ses0,pass2)
> <Rorke GalaxyHD 342D>              at scbus1 target 1 lun 0 (da2,pass3)
> <TOSHIBA TransMemory 5.00>         at scbus2 target 0 lun 0 (pass4,da3)
> 
> sudo camcontrol cmd pass4 -v -c "12 01 00 00 255 00" -i 255 "-" | hd
> 00000000  00 80 00 01 1f 00 00 00  54 4f 53 48 49 42 41 20  
> |........TOSHIBA |
> 00000010  54 72 61 6e 73 4d 65 6d  6f 72 79 20 20 20 20 20  
> |TransMemory     |
> 00000020  35 2e 30 30 50 4d 41 50  31 32 33 34 00 00 00 00  
> |5.00PMAP1234....|
> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
> |................|
> *
> 000000f0
> 
> sudo camcontrol cmd pass4 -v -c "12 01 80 00 255 00" -i 255 "-" | hd
> 00000000  00 80 00 01 1f 00 00 00  54 4f 53 48 49 42 41 20  
> |........TOSHIBA |
> 00000010  54 72 61 6e 73 4d 65 6d  6f 72 79 20 20 20 20 20  
> |TransMemory     |
> 00000020  35 2e 30 30 50 4d 41 50  31 32 33 34 00 00 00 00  
> |5.00PMAP1234....|
> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
> |................|
> *

Wow, that's just fantastically broken.  It's completely ignoring the
EVPD bit in the request and simply reporting standard inq data.  I
guess the only thing that keeps CAM from exploding on this is that it
sees the length field in byte 4 as 0x01, so it doesn't search too far
into what it thinks is the response.  I'll have to read the spec some
more to see if there's a standard way to report that the device supports
the EVPD bit that FreeBSD should be checking.

Scott