Any Linux Distribution based on kernel 2.6.39 or greater should contain this updated driver and inbox (or in kernel) driver support should be available for Series 6 Adaptec controllers.  §  Please be aware, there is the possibility that a particular vendor may choose not to include our driver in their particular distribution, so the above point is more a guideline than a rule. Listed below are the major distributions we officially support and the current inbox support for Series 6.

RedHat - RedHat Enterprise Linux (and RHEL derivatives, such as CentOS and Scientific Linux):    The Series 6 driver is not inbox with any currently available version of RHEL, this includes 4.x, 5.x, or 6.x. We are actively working with RedHat to get an updated driver inbox that will support Series 6 as quickly as possible.

Fedora: With the recent release of Fedora 16 (based on a 3.1 kernel), our 28000 driver is inbox.  For Fedora 15 users, the latest security updated kernel released is based on 2.6.40, which includes our 28000 driver inbox.

SUSE – SuSe Linux Enterprise Server: The Series 6 driver is not inbox with any currently available version of SLES. However, our 28000 driver will be included in the SP2 update for SLES 11. 

Debian - Debian. Our 28000 driver has been backported into Debian 6.0.2, (based on 2.6.32-39).   

Canonical - Ubuntu. With the recent release of Ubuntu 11.10, based on a 3.0 kernel, our 28000 driver is inbox. No other supported version of Ubuntu currently includes our 28000 driver (11.04, 10.10, or 10.04LTS) We are actively working with Canonical on what options are available getting our updated 28000 driver included with these older kernels.

…………………………………………………………………………………….

In a continued effort to improve our Linux support with Series 6, we have begun providing minimally tested drivers. These minimally tested drivers do not undergo the same rigorous qualification testing as our full release drivers, but occur more frequently allowing greater synchronized support for currently available versions of Linux we support.The tarball archive below contains driver files and instructions for RHEL/CentOS 5.2, 5.3, 5.7 & 6.0, 6.1, 6.2, and XenServer 6. To download this archive, please use the information below:http://www.adaptec.com/en-us/support/files/

Filename: aacraid_linux_drivers_min_v1.1.7-28700.tgz

Password: LETTER (all CAPS)If you experience any issues with the provided files, or have questions regarding additional supported Linux versions, please contact our Technical Support team.

Alternatively, if you are using a distribution with a kernel that is not mentioned here as supported / minimally supported, then you can compile drivers yourself using the Adaptec  source code and DKMS package from the support site http://www.adaptec.com/en-us/downloads/.

Hi folks, in the last few days I have come across an issue running smartmontools-5.38 with the series 2, 5 and 5Z controllers on firmware 17380 onwards with SATA drives.

Just a bit of background ..

By default (configurable using the expose_physicals module options parameter), the aacraid driver exposes the physical disks attached to the controller to the operating system but prevents the disk driver from attaching them by setting the no_uld_attach flag. The disks can be accessed via the SCSI generic driver though dangerous operations are blocked (e.g. writes).

Programs like smartctl are then able to send SMART commands to a physical disks via the associated SCSI generic device node. If the disk is SATA (-d sat specified) then smartctl makes use of SAT (SCSI ATA translation) to “wrap up” the SMART command in a SCSI CDB (command descriptor block) which is then sent via the SCSI generic and aacraid driver to the controller firmware.

The problem

From controller firmware 17380 onwards, the SAT layer (in the controller firmware) more completely implements the SAT specification, particularly with regard to commands that are sent where the host application (for example smartctl) requires the ATA register information to be read back. Typically the commands that would require this are ATA non-data protocol.

Specifically with smartctl, there are two commands used where the application needs to see the ATA registers to determine the status of the drive.

ATA_CHECK_POWER_MODE (ATA command 85h – smartctl needs to see COUNT in the register information to determine the power mode)

ATA_RETURN_STATUS (SMART command B0 with features DAh – smartctl needs to see the LBA mid and high values to determine if the drive is reporting a SMART threshold exceeded error – for example using smartctl -H …).

When a SAT CDB is issued and the host application wishes to see the ATA register information, it sets the CK_COND (check condition) bit in the SAT passthrough CDB. This indicates to the SATL that the ATA register information should be returned in an ATA status return descriptor. Firmware 17380 now implements this as per the SAT specification which requires the SATL code to generate a check condition and in response to a request sense (or in this case using autosense), the  sense key set to RECOVERED ERROR and additional sense qualifier to ATA PASSTHROUGH INFORMATION AVAILABLE, the ATA status return descriptor is then included in the sense data.

Unfortunately, the CHECK CONDITION causes the aacraid driver to also return a “host_status” indicating a controller internal error occurred (DID_ERROR). This propagates back to smartctl which exits. My colleague is currently looking at the aacraid driver to see how to avoid this but in case it helps anyone here is a temporary workaround (modification of smartctl behaviour) – note this will ignore host_status SG_ERR_DID_ERROR which isn’t desirable long-term. From the smartmontools-5.38 source dir …

patch -p1 < diff below  os_linux.cpp


662a663
> #define LSCSI_DID_ERROR 0x7 /* Need to work around aacraid driver quirk */
787c788,791
< return -EIO; /* catch all */
---
> /* Check for DID_ERROR - workaround for aacraid driver quirk */
> if (LSCSI_DID_ERROR != io_hdr.host_status) {
> return -EIO; /* catch all if not DID_ERR */
> }


… and recompile

I’ll post back soon as I know more from my colleague.

thanks, Phil.

This entry was posted on Friday, July 24th, 2009 and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

9 Responses to “Using smartmontools-5.38 with series 2/5/5Z controllers with firmware 17380 onwards”

1. norrs Says:
   August 7th, 2009 at 5:14 pm I guess this is why we’ve had issues with smartctl on our 5805 raid-card.
   After we flashed from stock retail firmware (Adaptec RAID 5805 Firmware/BIOS Update Ver. 5.2.0 Build 16501 – 18.feb09) to 24.jun09 17380 firmware ( Adaptec RAID 5805 Firmware/BIOS Update Ver. 5.2.0 Build 17380) we had issues reading of smart values from our sata disks.dmesg shows us:[877834.182094] scsi 0:1:4:0: [sg5] Sense Key : Recovered Error [current] [descriptor]
   [877834.182100] Descriptor sense data with sense descriptors (in hex):
   [877834.182103] 72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
   [877834.182112] 00 4f 00 c2 00 50
   [877834.182116] scsi 0:1:4:0: [sg5] Add. Sense: ATA pass through information availableI guess this relate to the problem described above.

   Do you suggest us flashing back to an older firmware? Will this be fine?

   Should we patch smartmontools and use a local copy until a new kernel driver is released? (since I assume your firmware is actually implemented the standards correctly, and we don’t want to go back to older and “hacky” firmware that actually worked).

   ETA on new kernel driver?

   Thanks
   Yet Another Tech

2. Phil Wilson Says:
   August 12th, 2009 at 1:01 pm Hi Norrs, sorry for the very long delay in coming back to you on this. I wanted to try this with the older firmware to see what was happening and have just been able to get into my lab after vacation. With the earlier firmware, it appears that the CK_COND bit in the SAT CDB is ignored and no sense data is returned so in other words, SMART RETURN STATUS doesn’t work.I think, under these circumstances, smartctl relies on the attribute values (first 362 bytes of the device SMART data structure) returned in response to SMART READ DATA and does a comparison for attributes flagged as pre-fail against the thresholds (returned in response to SMART READ ATTRIBUTE THRESHOLDS). If SMART RETURN STATUS had worked, the drive would have done this by itself.I would suggest using the newer firmware and a modified local copy of smartmontools. It would take some time to get this fixed in the driver and then it would need to be approved and merged with the driver at kernel.org before filtering through to distributions. I’ll post back here once I have some more news on this.thanks, Phil
3. norrs Says:
   August 13th, 2009 at 4:35 pm Thanks for your reply Phil.
   I’ll keep watching this nice blog for an update so we know when we can fetch a patch Thanks in advance.
4. ondhest Says:
   November 18th, 2009 at 11:57 pm I get this message when trying to patch:
   Hunk #2 FAILED at 788.
   1 out of 2 hunks FAILED — saving rejects to file os_linux.cpp.rejAnyone know what to do?
5. Phil Wilson Says:
   November 19th, 2009 at 9:58 amHi Ondhest, sorry about that – would you be able to try this. If it doesn’t help (works on my machine) let me know and I can email you directly.
   — os_linux.cpp.orig   2009-11-19 10:12:48.000000000 +0000
   +++ os_linux.cpp        2009-11-19 10:52:24.000000000 +0000
   @@ -660,6 +660,7 @@
    #define SG_IO_RESP_SENSE_LEN 64 /* large enough see buffer */
    #define LSCSI_DRIVER_MASK  0xf /* mask out “suggestions” */
    #define LSCSI_DRIVER_SENSE  0×8 /* alternate CHECK CONDITION indication */
   +#define LSCSI_DID_ERROR 0×7 /* Need to work around aacraid driver quirk */
    #define LSCSI_DRIVER_TIMEOUT  0×6
    #define LSCSI_DID_TIME_OUT  0×3
    #define LSCSI_DID_BUS_BUSY  0×2
   @@ -784,7 +785,10 @@
                    (LSCSI_DID_TIME_OUT == io_hdr.host_status))
                    return -ETIMEDOUT;
                else
   -                return -EIO;    /* catch all */
   +               /* Check for DID_ERROR – workaround for aacraid driver quirk */
   +               if (LSCSI_DID_ERROR != io_hdr.host_status) {
   +                       return -EIO;    /* catch all if not DID_ERR */
   +               }
            }
            if (0 != masked_driver_status) {
                if (LSCSI_DRIVER_TIMEOUT == masked_driver_status)
   thanks, Phil
6. Phil Wilson Says:
   November 24th, 2009 at 8:20 am Hi folks, just to add, the latest driver on the Adaptec support website 1.1.5-24900 fixes the driver issue (returning DID_ERROR instead of DID_OK when a SAT command with CC set causes a target to return a CC).thanks, Phil
7. Rick Says:
   April 4th, 2010 at 11:40 am useful article
8. yoann Says:
   April 26th, 2010 at 1:44 pm Folks,I have just tried the ASR 5805 with the latest driver update and the previous one (v1.1.5-26400 and v1.1.5-24900)
   Unfortunately , S.M.A.R.T does not seem to work. I am using the smartmontools-5.38-2 version on a x86_64 system.
   I have an error message :
   “Terminate command early due to bad response to IEC mode page” .I am surprise since the ASR support SMART and the discs (Seagates Savvio® 15K.2 SAS) do as well.Do you have any idea ?

   Thks

   Yoann

9. yoann Says:
   April 26th, 2010 at 3:29 pm ok sorry I have found by myself,
   smartctl –all /dev/sg1 -T permissive is working perfectlycheers

26 Responses to “Smartmontools and Adaptec RAID controllers”

1. Me Says:
   October 7th, 2008 at 10:26 am Um I need to…what exactly?
2. Phil Wilson Says:
   October 7th, 2008 at 11:40 am Oops, I’m very sorry for that ..I was intending to say that you need to make sure the physical devices attached to the raid controller are visible to the OS. A cat of /proc/scsi/scsi should confirm this. If they aren’t then check if the driver module supports the parameter expose_physicals=X (where X is 0 for don’t, -1 which for most distributions is the default which exposes them but sets the no_uld_attach flag, or 1 which exposes them and doesn’t protect them which is dangerous).

   Assuming the physical devices are visible, you need the SCSI generic driver loaded and then you can use smartctl with the SCSI generic device node corresponding to the disk of interest. Note that you have to tell smartctl the device type using -d sat || scsi ..

   for SATA disks
   smartctl --all /dev/sg<x> -d sat

   for SAS disks
   smartctl --all /dev/sg<x> -d scsi

   I also like the excellent sg_utils package – sg_scan -i will give you a list of all the devices with their inquiry / identify data.

   Just to reiterate, this works with the series 2 and series 5 controllers but not with the series 3 and older products.

   thanks, Phil

3. Mohsin Raza Says:
   December 15th, 2008 at 1:04 pm @Philwhat about 2820SA?

   I followed your instructions but smartctl is still not working on 2820SA Raid Controller, anything else required for this to work?

4. Phil Wilson Says:
   December 15th, 2008 at 1:15 pm Hi Mohsin, I’m sorry about this but smartmontools needs full pass-through support which was only introduced with the series-2 and series-5 controllers (probably the nearest equivalent to the 2820 would be the 5805). It isn’t possible on earlier models. We did have a look at how hard it would be to implement the firmware changes but it just wasn’t practical.best regards, Phil
5. Mohsin Raza Says:
   December 15th, 2008 at 1:20 pm Thanks for your help!Regards,

   Mohsin

6. Marcel Says:
   January 15th, 2009 at 10:14 am Hi,and what about the 2405? It’s a Series-2-Controller, but there is no explicit mention of pass-through or something similar.

   Regards

7. Phil Wilson Says:
   January 15th, 2009 at 10:35 am Hi Marcel, yes the series-2 (2405 and 2045) would work okay too. It uses a lower power version of the processor on the series-5 (less memory too) but the firmware and drivers are the same.best regards, Phil
8. Marcel Says:
   January 15th, 2009 at 1:13 pm Hello,that sounds very good!

   Thank you!

9. Philip Tait Says:
   March 6th, 2009 at 4:55 pm How about an Adaptec 2010 ZCR, using the dpt_i2o driver (kernel 2.4)? Can this work?
10. Phil Wilson Says:
    March 13th, 2009 at 7:55 am Hi Philip, sorry for the long delay in replying to you. I think it is pretty unlikely that this would work. The mechanism takes advantage of the fact the aacraid driver and ARC firmware allow the physical devices to be visible to the OS as SCSI generic devices. I don’t think the same feature was available in the older “B-code” firmware and dpt_i2o driver. If you can see the physical devices in /proc/scsi/scsi and they have SCSI generic device nodes associated with them it would be worth a try. Unfortunately I don’t have this hardware available to test myself.Sorry not to be more help, Phil
11. Markus Says:
    May 8th, 2009 at 11:54 am Hi Philip,can you tell me if the Adaptec 5445, 5805 or 5085 will work with smartmontools?

    Thanks
    Markus

12. Vladimir Says:
    May 12th, 2009 at 8:54 am Hi !How to use smartctl for getting smart-info from sata disk atached to adaptec sas 3405 adapter ?

    If I run “smartctl -a -d sat /dev/sg” or “smartctl -a -d scsi /dev/sg” smart-info is not shown.

    with sas disks is all good.

13. Vladimir Says:
    May 12th, 2009 at 8:56 am Some changes:If I run “smartctl -a -d sat /dev/sgX” or “smartctl -a -d scsi /dev/sgX” smart-info is not shown.
14. Phil Wilson Says:
    May 14th, 2009 at 12:43 pm Hi Vladimir, I’m sorry for the long delay – been travelling to our head office and then stuck in all day meetings so I’m trying to catch up.The way that this works is that smartctl generates an ATA command to retrieve the smart information but because the underlying transport is based on SCSI, it uses the SCSI ATA translation (SAT) command to create a standard SCSI command descriptor block with the ATA command embedded inside it.

    The later generation series-2 and series-5 controllers understand this command (op code 85h) and process the embedded SATA command however the firmware for the series-3 controllers doesn’t support it.

    I went round this with our design engineering group to see if it was possible to add support to the series-3 but it would require a lot of development effort. Its a shame because SAT support adds capability like being able to download microcode to SATA disks through the controllers which has been important to our data centre customers.

    Just as an aside, the next version of the ASM GUI and arcconf CLI program provides new menu options allowing you to download disk microcode to SAS and SATA disks on series-2 and 5 controllers.

    Just a quick heads up for series-2 and series-5 customers who have updated to firmware 16507 (which is only available by contacting our tech support team). This includes some changes to support the new disk firmware flash capabiltiy but has introduced a glitch with smartctl. I’m investigating this but for the time being, if you are using this firmware then you need to add -T permissive to the end of your smartctl command.

    Hope this is a help – welcome any feedback.
    thanks, Phil

15. Mike Says:
    May 30th, 2009 at 5:53 pm Hello,I have a ICP5085BL and it does not work for me. OS is Ubuntu 9.10, newest firmware.

    mike@host:/dev$ sudo smartctl –all -d sat /dev/sg10
    smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
    Home page is http://smartmontools.sourceforge.net/

    === START OF INFORMATION SECTION ===
    Device Model: [No Information Found]
    Serial Number: [No Information Found]
    Firmware Version: [No Information Found]
    Device is: Not in smartctl database [for details use: -P showall]
    ATA Version is: 1
    ATA Standard is: Exact ATA specification draft version not indicated
    Local Time is: Sat May 30 20:54:03 2009 CEST
    SMART is only available in ATA Version 3 Revision 3 or greater.
    We will try to proceed in spite of this.
    SMART support is: Ambiguous – ATA IDENTIFY DEVICE words 82-83 don’t show if SMART supported.
    Checking for SMART support by trying SMART ENABLE command.
    SMART ENABLE appeared to work! Continuing.
    SMART support is: Ambiguous – ATA IDENTIFY DEVICE words 85-87 don’t show if SMART is enabled.
    A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.

    Any ideas?

    Kind regards
    Mike

16. Mike Says:
    May 30th, 2009 at 5:58 pm Oh Ubuntu version is 9.04
17. Phil Wilson Says:
    June 2nd, 2009 at 11:47 am Hi Mike, sorry for the delay. The ICP 5085BL is a different model to the Adaptec controllers and doesn’t follow the same model numbering convention. It has higher performance but is based on the same code base as the Adaptec series-3. Unfortunately this code base doesn’t support the SAT opcode as mentioned in my previous note. Consequently smartctl would work with SAS disks but not with SATA.The controller will still forward any SMART warnings or errors generatedb by the drive to the management software / operating system.

    Sorry for not being clearer over the model numbers – I remember thinking it would be challenging when the Adaptec series-5 controllers were launched.

    many thanks, Phil

18. Ryan Says:
    August 30th, 2009 at 2:07 pm Is it possible to use smartctl with a 2420S? If not, what other ways can the health of the individual SCSI drives be monitored?
19. Ryan Says:
    August 30th, 2009 at 2:13 pm I answered my own question: modprobe sg and use the /dev/sgX devices instead.
20. Patrick Says:
    September 12th, 2009 at 1:44 pm Hey, I was just wondering if this was also possible for the Adaptec ASR-2420SA.
    Reading the information from /dev/sgX results in this message:# smartctl –all /dev/sg0 -d sat -T
    smartctl version 5.38 [i486-slackware-linux-gnu] Copyright (C) 2002-8 Bruce Allen
    Home page is http://smartmontools.sourceforge.net/

    =======> ARGUMENT REQUIRED FOR OPTION: T
    =======> VALID ARGUMENTS ARE: normal, conservative, permissive, verypermissive

21. Phil Wilson Says:
    September 14th, 2009 at 4:44 pm Hi Patrick, sorry for the delay. I’m not sure about this – I’ll have to give it a try (travelling at the moment so it would be later this week). You could try adding -T permissive on the end. It depends whether the firmware of the 2420 supports the SAT command. If you try – let me know what happens.thanks, Phil
22. Joel Franco Says:
    October 22nd, 2009 at 11:08 am Thank You by this information.I didn’t know that could be possible to take the information passtrough the raid board.

    It could be cool if you publish a table with the raid boards that this method supports; it’s dificul to us, users, to know how to get information from the raid device without open source consolidated tools.

23. Phil Wilson Says:
    October 30th, 2009 at 1:02 pm Hi Joel, good point, I’ll try to put together a list of what controllers have which passthrough features. It might take a bit of time as I’ll have to try some of them to determine what is supported.The latest controllers – series 2 and series 5 – support SCSI and SAT passthrough and will work with smartmontools for both SATA and SAS disks. There is a driver bug which appears when using the latest firmware documented here with a temporary workaround until a driver fix makes it into distributions.

    http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/

    Series-3 controllers support SCSI passthrough but in the standard code as shipped in the channel (non-OEM), do not support SAT passthough smartmontools will work with SAS but not SATA disks.

    many thanks, Phil

24. Paul Says:
    November 2nd, 2009 at 11:50 pm Patrick, you did not pass any parameter to the -T option.Try -T verypermissive
25. Rob Mangiafico Says:
    February 19th, 2010 at 4:32 pm Is it safe to run smartctl tests on an Adaptec 3404 controller with SAS drives with commands such as:
    smartctl -t short /dev/sg2
    smartctl -t long /dev/sg2We would like to catch the uncorrectable errors, as the controller is not failing out failing drives automatically, which is resulting in failed stripes in a RAID-1 array many times.

    Just want to make sure it’s safe to run tests against the physical drives with smartctl when using an Adaptec 3405 controller. Thanks! Rob

26. fri23368 Says:
    February 22nd, 2010 at 10:53 am Hello Rob,smartmon tools are officially supported on Adaptec Series-2/5/5Z cards.

    Support for Series-3 has been added recently but only for specific accounts so this has not been officially validated by Adaptec.

    You can download the neccessary firmware here:

    http://www.adaptec.com/support/files/

    Filenames:
    3085_fw_b17335.exe
    3405_fw_b17335.exe
    3805_fw_b17335.exe
    31205_fw_b17335.exe
    31605_fw_b17335.exe

    Password for all files: phoenix

    Regards
    Juergen