From owner-freebsd-scsi@FreeBSD.ORG Thu May 8 00:49:07 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 A7579106567A for ; Thu, 8 May 2008 00:49:07 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 790E78FC0C for ; Thu, 8 May 2008 00:49:07 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 41C961C8042; Wed, 7 May 2008 17:49:07 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19960-08; Wed, 7 May 2008 17:49:05 -0700 (PDT) Received: from iago.office.miralink.com (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 8D89F1C803D; Wed, 7 May 2008 17:49:05 -0700 (PDT) Message-ID: <48224E01.4030907@miralink.com> Date: Wed, 07 May 2008 17:49:05 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Scott Long References: <48222930.2010808@miralink.com> <48223940.5090109@samsco.org> <482240FF.4030704@miralink.com> <48224361.10809@samsco.org> In-Reply-To: <48224361.10809@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed May 7 17:49:06 2008 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 48224e02153291186327471 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: 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 00:49:07 -0000 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