From owner-freebsd-scsi@freebsd.org Tue Dec 15 04:40:41 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 3371EA43A0A for ; Tue, 15 Dec 2015 04:40:41 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp003.me.com (mr11p00im-asmtp003.me.com [17.110.69.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC3D1D0E; Tue, 15 Dec 2015 04:40:41 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from [172.17.133.77] (dip-cali.panasas.com [64.80.217.3]) by mr11p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0NZD00MZ7RJS2M10@mr11p00im-asmtp003.me.com>; Tue, 15 Dec 2015 03:40:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-15_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1512150068 User-Agent: Microsoft-MacOutlook/0.0.0.151105 Date: Mon, 14 Dec 2015 19:40:39 -0800 Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify From: Ravi Pokala Sender: "Pokala, Ravi" To: Kevin Bowling Cc: "freebsd-scsi@freebsd.org" , Sean Bruno Message-id: Thread-topic: Accessing static drive info w/o ATA identify and lockup with camcontrol identify References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> In-reply-to: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit 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: Tue, 15 Dec 2015 04:40:41 -0000 Does anyone have any thoughts about this? If not, then I'll code up a patch and throw it on Phabricator. -Ravi -----Original Message----- From: Ravi Pokala Date: 2015-12-10, Thursday at 08:10 To: Kevin Bowling , Ravi Pokala Cc: "freebsd-scsi@freebsd.org" , Sean Bruno Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify >-----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 weekend. My concern is that the d_rotation_rate does not strictly map to the actual rotation rate - there are some special cases and reserved values. I was thinking something more like this: > > sbuf_printf(sb, "%s", indent); > if (dp->d_rotatation_rate == 0) > sbuf_printf(sb, "unknown"); > else if (dp->d_rotation_rate == 1) > sbuf_printf(sb, "0"); > else if ((dp->d_rotation_rate >= 0x041) && (dp->d_rotation_rate <= 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 what's parsing the XML). I don't have a strong feeling about this; what do other people think? Should it just return the value provided by the drive, or 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 "struct disk", like drive model and serial number already are. It should be trivial 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. > > >>And lastly, yes bus speeds would be nice (especially to spot hard/soft misconfiguration). 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 preserved. Again, there's the memory and KBI issues of adding another string to "struct disk". > >-Ravi