<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Using smartmontools-5.38 with series 2/5/5Z controllers with firmware 17380 onwards</title>
	<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/</link>
	<description></description>
	<pubDate>Wed, 17 Mar 2010 21:15:37 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: Phil Wilson</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-328</link>
		<author>Phil Wilson</author>
		<pubDate>Tue, 24 Nov 2009 08:20:15 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-328</guid>
		<description>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;thanks, Phil&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>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).</p>
<p>thanks, Phil</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil Wilson</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-322</link>
		<author>Phil Wilson</author>
		<pubDate>Thu, 19 Nov 2009 09:58:27 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-322</guid>
		<description>Hi 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.

&lt;pre&gt;&lt;code&gt;
--- 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  0x8 /* alternate CHECK CONDITION indication */
+#define LSCSI_DID_ERROR 0x7 /* Need to work around aacraid driver quirk */
 #define LSCSI_DRIVER_TIMEOUT  0x6
 #define LSCSI_DID_TIME_OUT  0x3
 #define LSCSI_DID_BUS_BUSY  0x2
@@ -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)
&lt;/code&gt;&lt;/pre&gt;

thanks, Phil</description>
		<content:encoded><![CDATA[<p>Hi 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.</p>
<pre><code>
--- 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  0x8 /* alternate CHECK CONDITION indication */
+#define LSCSI_DID_ERROR 0x7 /* Need to work around aacraid driver quirk */
 #define LSCSI_DRIVER_TIMEOUT  0x6
 #define LSCSI_DID_TIME_OUT  0x3
 #define LSCSI_DID_BUS_BUSY  0x2
@@ -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)
</code></pre>
<p>thanks, Phil</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ondhest</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-321</link>
		<author>ondhest</author>
		<pubDate>Wed, 18 Nov 2009 23:57:37 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-321</guid>
		<description>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.rej

Anyone know what to do?</description>
		<content:encoded><![CDATA[<p>I get this message when trying to patch:<br />
Hunk #2 FAILED at 788.<br />
1 out of 2 hunks FAILED &#8212; saving rejects to file os_linux.cpp.rej</p>
<p>Anyone know what to do?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: norrs</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-251</link>
		<author>norrs</author>
		<pubDate>Thu, 13 Aug 2009 16:35:18 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-251</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>Thanks for your reply Phil.<br />
I&#8217;ll keep watching this nice blog for an update so we know when we can fetch a patch <img src='http://linux.adaptec.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Thanks in advance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil Wilson</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-246</link>
		<author>Phil Wilson</author>
		<pubDate>Wed, 12 Aug 2009 13:01:58 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-246</guid>
		<description>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</description>
		<content:encoded><![CDATA[<p>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&#8217;t work. </p>
<p>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.</p>
<p>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&#8217;ll post back here once I have some more news on this.</p>
<p>thanks, Phil</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: norrs</title>
		<link>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-240</link>
		<author>norrs</author>
		<pubDate>Fri, 07 Aug 2009 17:14:32 +0000</pubDate>
		<guid>http://linux.adaptec.com/2009/07/24/using-smartmontools-538-with-series-255z-controllers-with-firmware-17380-onwards/#comment-240</guid>
		<description>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 available

I 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 :-)</description>
		<content:encoded><![CDATA[<p>I guess this is why we&#8217;ve had issues with smartctl on our 5805 raid-card.<br />
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.</p>
<p>dmesg shows us:</p>
<p>[877834.182094] scsi 0:1:4:0: [sg5] Sense Key : Recovered Error [current] [descriptor]<br />
[877834.182100] Descriptor sense data with sense descriptors (in hex):<br />
[877834.182103]         72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00<br />
[877834.182112]         00 4f 00 c2 00 50<br />
[877834.182116] scsi 0:1:4:0: [sg5] Add. Sense: ATA pass through information available</p>
<p>I guess this relate to the problem described above.</p>
<p>Do you suggest us flashing back to an older firmware? Will this be fine?</p>
<p>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&#8217;t want to go back to older and &#8220;hacky&#8221; firmware that actually worked). </p>
<p>ETA on new kernel driver? </p>
<p>Thanks<br />
Yet Another Tech <img src='http://linux.adaptec.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
</channel>
</rss>
