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

[Alan Somers]

On Thu, Dec 10, 2015 at 9:10 AM, Pokala, Ravi <rpokala at panasas.com> wrote:
> -----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.


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 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
>
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"