USB drive serial numbers

[Scott Long]

Sean Bruno wrote:
> Scott Long wrote:
>> 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
> Any chance you have a USB hard drive lying around that you could run a 
> "camcontrol inq"?
> 
> Sean

A thumb drive that I have lying around has the same problem, it ignores
the EVPD bit and happily returns std inq data for all requests.  An
ATA->USB+Firewire enclosure works correctly; it doesn't support any
VPD pages, but returns a sense error in response, as it should.  Given
that Firewire is more explicit in its implementation of SBP/SPC, I'm not
too surprised that it worked correctly (I tested this over the USB port,
though).  I have another ATA->USB enclosure lying around, but I can't
find the power cord for it right now.

Scott