Date: Fri, 4 Dec 2015 02:13:31 -0700 From: Kevin Bowling <kevin.bowling@kev009.com> To: freebsd-scsi@freebsd.org Subject: Accessing static drive info w/o ATA identify and lockup with camcontrol identify Message-ID: <CAK7dMtDw7-eFL0HDik3X6O=QA0jKsbuH9wSOTjDiiQdmJhmKJg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
This email is two parts that are somewhat related #1 I have seen two cases where camcontrol identify can lock up a box. On a system I have control over, I can downgrade the LSI firmware on a machine with a SAS1008 and dispatch camcontrol identify to all the disks in a loop. I/O on the system will hang silently in the background fairly quickly, but there is no indication as to how low the freeze is. I'm not sure if it's kernel side or firmware. You wont initially notice it, but then zfs will hang waiting for txgs and the machine is out to lunch. On this box, if I upgrade firmware I don't see the lockup. I got another report where a user is seeing this on AHCI https://github.com/saltstack/salt/issues/28518 with the same cause and effect. This user's lockup raises the spidy senses and makes me want to dig deeper and make sure there isn't a loose end in kernel. #2 This all came about because I want to poll device information like disk model, serial number, speeds, etc. Common use cases would be configuration management systems and inventory databases. Issuing an ATA identify seems a bit much and could trigger unwanted HW errata like above. I'm wondering if it would be better to cache the data on interface change in sysctls or something. The data is static, read only, but we need to account for disk swaps. Regards, Kevin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK7dMtDw7-eFL0HDik3X6O=QA0jKsbuH9wSOTjDiiQdmJhmKJg>