From owner-freebsd-scsi@freebsd.org Wed Jan 13 20:58:20 2016 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 A22B9A80795 for ; Wed, 13 Jan 2016 20:58:20 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 6BA6D1822 for ; Wed, 13 Jan 2016 20:58:20 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-yk0-x22c.google.com with SMTP id v14so409799902ykd.3 for ; Wed, 13 Jan 2016 12:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FxbVIGZq7Y56xy2NUN9tsplCy2Gz43mdlnNEmiJwoZE=; b=TxUIaQED0ij/E9wRsAaPKp+Hq6uldMGHgYaoB5porkfc01Y/M4KzhwYRMhM2qQOY2X xWI4R02bfjBTwRQe1mmApePkF4A2VOp7xBKotE0vdcwOZETt49+PHCjzDmEQRwfmJ8Nj tRpQUjvYtL8H6EWkbUo3NAkDnpf81Bv0TsUV8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FxbVIGZq7Y56xy2NUN9tsplCy2Gz43mdlnNEmiJwoZE=; b=QUbBUfdi9Sz94/d15IqVbHHVjUIFOulO6pCMujsMeqsrksRYiDcmYMZyZ+sN1viWgR CqUSD7lG9V3Uv8mhsC7MN+gSYOcgaacztvGXerNA1nvnckbqbF2Jy42ZLamawfrnvMD0 6uksO5ifgLDIx3tOOP7OZSScmtD+wYaNSjF7WdC5/qDhJodBNEYYGRvPXXX2FtsWBp8C m7KkeH015zatOGGm8zfXkmmyonb5qdMrbvjbcXwMy3jyt71mqkaw8iHLGjibk6f74ALw Q3tzLzQs06sr610d5ww16spT7nHyMbBujcrsrjrKpvX6hpcNDPHfJ+vDw5X1meDuWsna Y+Ug== X-Gm-Message-State: ALoCoQn/2Lt3SLcHMOtboPfDk9hL/KPdMAEtST+ekleRkmRT4ELNs4RZBZ1sdqD3D3Imh7+fvskkNiGbUBh+xWVLW5nXz04Vqw== MIME-Version: 1.0 X-Received: by 10.129.55.193 with SMTP id e184mr352731ywa.162.1452718699373; Wed, 13 Jan 2016 12:58:19 -0800 (PST) Received: by 10.37.6.66 with HTTP; Wed, 13 Jan 2016 12:58:19 -0800 (PST) In-Reply-To: References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> Date: Wed, 13 Jan 2016 13:58:19 -0700 Message-ID: Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify From: Kevin Bowling To: Ravi Pokala Cc: "freebsd-scsi@freebsd.org" , Sean Bruno Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 13 Jan 2016 20:58:20 -0000 Can you integrate the rotation rate patch in time for 10.3? I'd like to switch saltstack away from using camcontol since at least one person is complaining of machine hangs. Regards, On Mon, Dec 14, 2015 at 8:40 PM, Ravi Pokala wrote: > 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 < > sbruno@freebsd.org> > 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 < > sbruno@freebsd.org> > >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 > >