Date: Thu, 10 Dec 2015 09:15:59 -0700 From: Alan Somers <asomers@freebsd.org> To: "Pokala, Ravi" <rpokala@panasas.com> Cc: Kevin Bowling <kevin.bowling@kev009.com>, Ravi Pokala <rpokala@mac.com>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org> Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify Message-ID: <CAOtMX2je1o26g8DXjUopJZOT=uSqEnWz=rWe4a02vJRHShWdjg@mail.gmail.com> In-Reply-To: <E7955294-60BE-45B9-9197-33767EBD3DEA@panasas.com> References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> <CAK7dMtBmMdOMs4vdPy0otprfWTVREJCyrVaeVtXj2gw-3BFQGA@mail.gmail.com> <E7955294-60BE-45B9-9197-33767EBD3DEA@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 10, 2015 at 9:10 AM, Pokala, Ravi <rpokala@panasas.com> wrote: > -----Original Message----- > > > From: Kevin Bowling <kevin.bowling@kev009.com> > Date: 2015-12-10, Thursday at 04:58 > To: Ravi Pokala <rpokala@mac.com> > Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, Sean Bruno <sb= runo@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 week= end. My concern is that the d_rotation_rate does not strictly map to the ac= tual rotation rate - there are some special cases and reserved values. I wa= s thinking something more like this: > > sbuf_printf(sb, "%s<rotationrate>", indent); > if (dp->d_rotatation_rate =3D=3D 0) > sbuf_printf(sb, "unknown"); > else if (dp->d_rotation_rate =3D=3D 1) > sbuf_printf(sb, "0"); > else if ((dp->d_rotation_rate >=3D 0x041) && (dp->d_rotation_rate <= =3D 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 w= hat's parsing the XML). I don't have a strong feeling about this; what do o= ther people think? Should it just return the value provided by the drive, o= r 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: <SAM= SUNG 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 "st= ruct disk", like drive model and serial number already are. It should be tr= ivial 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 mi= sconfiguration). 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 prese= rved. Again, there's the memory and KBI issues of adding another string to = "struct disk". > > -Ravi > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2je1o26g8DXjUopJZOT=uSqEnWz=rWe4a02vJRHShWdjg>