From owner-freebsd-scsi@freebsd.org Thu Dec 10 16:16:01 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 442979D6E38 for ; Thu, 10 Dec 2015 16:16:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 174E61C57 for ; Thu, 10 Dec 2015 16:16:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by obciw8 with SMTP id iw8so62493051obc.1 for ; Thu, 10 Dec 2015 08:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BYxfcj/XkpwCa9WP7HHVId7295cAvJXJCkH6hUG5MzQ=; b=pjRsAMaiTL+7BkJODeS1kSU7MHtu8OteXXYRNfxL5cI63rapuNI2L5ZpDzDpjCS+8P FVsVBJvPNRs2INQHS/FUk/gZnyUcYLjxs5816QZPIoDO6A1RsfRyqGk2zvk4YyKOBxNa s+Skz0D9AKEo9U3HfSzmpf66hZ2N1MLhUtD6jpohbvK15rEXM45qtLIGzbU2n8ojiEXB t/NPNyZX2EXNA0xnCIRKG23mL+2NsCDhP5yrNJTXatcseb2+XYbIdYWRbn2VP6oN+sxQ DKtNJnSHsJhBVV9cvk5j6MI6w6gl00+GCUVbgsb3piVsiQiOPZIf8c+3fYWVBUHxUIOh yqcA== MIME-Version: 1.0 X-Received: by 10.182.106.13 with SMTP id gq13mr10359026obb.38.1449764159335; Thu, 10 Dec 2015 08:15:59 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.0.7 with HTTP; Thu, 10 Dec 2015 08:15:59 -0800 (PST) In-Reply-To: References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> Date: Thu, 10 Dec 2015 09:15:59 -0700 X-Google-Sender-Auth: 0pOjLrSYOwLHLli-FMBo7rUoUYo Message-ID: Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify From: Alan Somers To: "Pokala, Ravi" Cc: Kevin Bowling , Ravi Pokala , "freebsd-scsi@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 16:16:01 -0000 On Thu, Dec 10, 2015 at 9:10 AM, Pokala, Ravi wrote: > -----Original Message----- > > > From: Kevin Bowling > Date: 2015-12-10, Thursday at 04:58 > To: Ravi Pokala > Cc: "freebsd-scsi@freebsd.org" , Sean Bruno > Subject: Re: Accessing static drive info w/o ATA identify and lockup with= camcontrol identify > >>Thanks Ravi! >> >>Rotation rate is probably the most important thing and thankfully easy as= you suggested: >> >>https://reviews.freebsd.org/D4483. Would be nice to land that in 10.3 so= I can swap the SaltStack module over to it. > > As I just commented there, I was actually going to look at this this week= end. My concern is that the d_rotation_rate does not strictly map to the ac= tual rotation rate - there are some special cases and reserved values. I wa= s thinking something more like this: > > sbuf_printf(sb, "%s", indent); > if (dp->d_rotatation_rate =3D=3D 0) > sbuf_printf(sb, "unknown"); > else if (dp->d_rotation_rate =3D=3D 1) > sbuf_printf(sb, "0"); > else if ((dp->d_rotation_rate >=3D 0x041) && (dp->d_rotation_rate <= =3D 0xfffe)) > sbuf_printf(sb, "%u", dp->d_rotation_rate); > else > sbuf_printf(sb, "invalid"); > sbuf_printf(sb, "\n"); > > > That would be more accurate, but slightly harder to parse (depending on w= hat's parsing the XML). I don't have a strong feeling about this; what do o= ther people think? Should it just return the value provided by the drive, o= r should it do some interpretation? > >>Next in priority would be getting firmware version.. >> >>In 'camcontrol identify' it looks like: 'firmware revision DXM9203Q' >> >>In 'camcontrol inquiry' it's part of the device string like: 'pass0: ACS-2 ATA SATA 3.x device' >> >>Do you have any suggestions for wiring that into geom disk? > > Interesting. I never noticed that firmware wasn't already included in "st= ruct disk", like drive model and serial number already are. It should be tr= ivial to add, but keeping a copy of the string will of course make "struct = disk" larger. That might have implications on KBI compatibility for out-of-= tree drivers...? Again, I'm not sure. This information is already perserved in CAM, if not in GEOM. For SCSI disks, look at (struct cam_device).inq_data.revision. For ATA disks, look at (struct ccb_getdev).ident_data.revision. > > >>And lastly, yes bus speeds would be nice (especially to spot hard/soft mi= sconfiguration). It shows up like 'protocol ATA/ATAPI-9 SATA = 3.x' in camcontrol identify and can be seen in the inquiry string above too= . Do you have design suggestions on that? > > I'm sure the string that's generated by CAM at attach-time could be prese= rved. Again, there's the memory and KBI issues of adding another string to = "struct disk". > > -Ravi > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"