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

[Pokala, Ravi]

-----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