From owner-freebsd-scsi@FreeBSD.ORG Thu May 8 06:36:51 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE301065670 for ; Thu, 8 May 2008 06:36:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 650E98FC12 for ; Thu, 8 May 2008 06:36:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m486alls058473; Thu, 8 May 2008 00:36:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48229F7F.6040602@samsco.org> Date: Thu, 08 May 2008 00:36:47 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Sean Bruno References: <48222930.2010808@miralink.com> <48223940.5090109@samsco.org> <482240FF.4030704@miralink.com> <48224361.10809@samsco.org> <48224E01.4030907@miralink.com> In-Reply-To: <48224E01.4030907@miralink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: USB drive serial numbers X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 06:36:51 -0000 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: 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: 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 >>> at scbus0 target 0 lun 0 (da0,pass0) >>> at scbus0 target 1 lun 0 (da1,pass1) >>> at scbus0 target 6 lun 0 (ses0,pass2) >>> at scbus1 target 1 lun 0 (da2,pass3) >>> 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