Date: Wed, 07 May 2008 18:03:45 -0600 From: Scott Long <scottl@samsco.org> To: Sean Bruno <sbruno@miralink.com> Cc: freebsd-scsi@freebsd.org Subject: Re: USB drive serial numbers Message-ID: <48224361.10809@samsco.org> In-Reply-To: <482240FF.4030704@miralink.com> References: <48222930.2010808@miralink.com> <48223940.5090109@samsco.org> <482240FF.4030704@miralink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48224361.10809>