Add Highpoint RocketRAID support (hptiop)

[noobsauce80]

I mainly work with FreeNAS systems, but I found an issue that I think can be resolved here.

I have a RocketRAID 4520 controller(latest generation from Highpoint). When I use the command smartctl -a -d hpt,1/1/1 /dev/hptiop0 I get the error "Smartctl: Device Read Identity Failed: Bad address'.

It appears that this issue was previously documented in ticket:71. That ticket was closed since nobody had this controller. I have a controller from each of the 35xx, 43xx, and 45xx family of controllers. AFAIK the only way to get any SMART data and run any tests is via the Highpoint CLI available as a binary only. My guess is that all 3 families of controller mentioned above and the 44xx will all work with the same appropriate fix.

I have a system that I can give SSH and FTP access to on request. I only have the 45xx until the end of the year however(on loan to help facilitate support for FreeNAS).

You can read additional information on this issue provided by me at the FreeNAS ticket ​https://support.freenas.org/ticket/1932.

I listed the priority as major since so many generations of cards are included with this ticket.

[Christian Franke]

It appears that this issue was previously documented in ticket:71. That ticket was closed since nobody had this controller.

Ticket #71 is unrelated and still open. Fixing it would enhance the existing pass-through functionality for non-SMART and 48-bit ATA commands (for e.g. "smartctl -s apm,128 -l xerror -d hpt,...").

You can read additional information on this issue provided by me at the FreeNAS ticket ​https://support.freenas.org/ticket/1932.

​This comment suggests that the hptiop driver does not provide any documented ATA pass-through functionality. If this is the case, we cannot fix this.

[noobsauce80]

I wrote that comment. I'm 75% sure there is no ability to fix this issue. I'm still so new to FreeBSD I don't have the know-how to prove for certainty that it can't be fixed. I've only been using FreeBSD for about 10 months.

If you are fairly sure from my comments and the info I provided as output from the command line pastes I provided that it can't be fixed that's fine. I was just hoping someone with more knowledge than myself could take a look and verify this is truly the case before I abandon all hope.

[Christian Franke]

Let's keep the ticket open until some expert can answer this. I don't have experience with such controllers.

If the Highpoint CLI is able to display SMART info, some limited pass-through functionality must exist in the driver. Unfortunately the hptiop FreeBSD driver isn't open source, so documentation is required.

[shahar]

is this the kind of documentation you're looking for?
​http://www.mjmwired.net/kernel/Documentation/scsi/hptiop.txt

Although it is for the linux version but shouldn't the addresses be similar?

[noobsauce80]

The hptiop driver is open source now unless there's a part that's closed source. The driver previously was closed source, but I added support for the 3560 a few months back because the driver had never been updated to support the controller.

[Alex Samorukov]

I can try to look on this (i added areca support in FreeBSD in the past). Please contact me via samm [at] os2.kiev.ua e-mail.

[Alex Samorukov]

What i can try to do is to trace vendor utility using strace (with LD_PRELOAD ioctl handler) or dtrace (will need custom FreeBSD kernel) to find which transport (ioctl, CAM) it using to get smart values, and if it is high level (e.g. ioctl to get only smart block) or low level (using ata commends) API. With some luck it should not be very hard to implement some kind of smartctl support after this.

[Gabriele Pohl]

Replying to noobsauce80:

The hptiop driver is open source now unless there's a part that's closed source. The driver previously was closed source, but I added support for the 3560 a few months back because the driver had never been updated to support the controller.

FreeBSD Source: ​https://svnweb.freebsd.org/base/head/sys/dev/hptiop/hptiop.c?view=markup

[mryoon]

What i can try to do is to trace vendor utility using strace (with LD_PRELOAD ioctl handler) or dtrace (will need custom FreeBSD kernel) to find which transport (ioctl, CAM) it using to get smart values, and if it is high level (e.g. ioctl to get only smart block) or low level (using ata commends) API. With some luck it should not be very hard to implement some kind of smartctl support after this.

[Alex Samorukov]

We do not have access to the specific hardware, so i am closing this ticket for now. If you can provide such access (SSH should be enough) - please reopen this ticket.