Date: Thu, 08 May 2008 00:36:47 -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: <48229F7F.6040602@samsco.org> In-Reply-To: <48224E01.4030907@miralink.com> References: <48222930.2010808@miralink.com> <48223940.5090109@samsco.org> <482240FF.4030704@miralink.com> <48224361.10809@samsco.org> <48224E01.4030907@miralink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48229F7F.6040602>