Accessing static drive info w/o ATA identify and lockup with camcontrol identify

[Kevin Bowling]

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 <rpokala at mac.com> 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 <rpokala at panasas.com>
> Date: 2015-12-10, Thursday at 08:10
> To: Kevin Bowling <kevin.bowling at kev009.com>, Ravi Pokala <rpokala at mac.com
> >
> Cc: "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, Sean Bruno <
> sbruno at freebsd.org>
> Subject: Re: Accessing static drive info w/o ATA identify and lockup with
> camcontrol identify
>
> >-----Original Message-----
> >
> >From: Kevin Bowling <kevin.bowling at kev009.com>
> >Date: 2015-12-10, Thursday at 04:58
> >To: Ravi Pokala <rpokala at mac.com>
> >Cc: "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, Sean Bruno <
> sbruno at 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<rotationrate>", 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, "</rotationrate>\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:
> <SAMSUNG MZ7WD480HCGM-00003 DXM9203Q> 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
>
>