From nobody@FreeBSD.org  Tue Jun  9 09:02:35 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D3BBB106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  9 Jun 2009 09:02:35 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id C0F1C8FC15
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  9 Jun 2009 09:02:35 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n5992ZIU075981
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 9 Jun 2009 09:02:35 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n5992ZGe075980;
	Tue, 9 Jun 2009 09:02:35 GMT
	(envelope-from nobody)
Message-Id: <200906090902.n5992ZGe075980@www.freebsd.org>
Date: Tue, 9 Jun 2009 09:02:35 GMT
From: Michael Gmelin <freebsdusb@bindone.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Adaptec 5405 RAID (aac) controller hanging under high load +suggested fix
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         135408
>Category:       kern
>Synopsis:       [aac] Adaptec 5405 RAID controller hanging under high load +suggested fix
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    emaste
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 09 09:10:03 UTC 2009
>Closed-Date:    Sat Feb 20 13:09:28 UTC 2010
>Last-Modified:  Sat Feb 20 13:09:28 UTC 2010
>Originator:     Michael Gmelin
>Release:        7.2-RELEASE amd64, 7.1-RELEASE amd64, 7.2 RC2 amd64, 8-CURRENT amd64
>Organization:
/bin/done digital solutions GmbH
>Environment:
FreeBSD srv02 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Thu May 14 00:07:23 UTC 2009     root@srv02:/usr/src/sys/amd64/compile/GENERIC  amd64
FreeBSD srv04 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun  2 18:01:36 UTC 2009     root@srv04:/usr/src/sys/amd64/compile/GENERIC  amd64

>Description:
The affected machines sometimes lose the Adaptec 5405 RAID controller under high load, stating:

aac0: COMMAND 0xffffffffxxxxxxxxx TIMEOUT AFTER nn SECONDS
(x changing, n getting higher)

This goes on up to a point where it states "WARNING! Controller is no longer running! code=xxxxx".

At that point the machine cannot recover and needs a hard reset.

This is reproducable on all the BSD versions stated above (the drivers haven't changed in quite a while), the code triggering this is in aac.c (lines 2375ff).

I suspect this is a problem related to command timeouts (see "Fix to the problem" below). There have been various threads going on about similar issues on aacraid based controllers in the past, but none of them was concolusive, so I hope this can be resolved asap :)
>How-To-Repeat:
Put high load on the I/O subsystem, e.g. by doing
make -j16 buildworld
(depending on your hardware, dual quad core xeon here) or run
a benchmark (e.g. /usr/ports/benchmarks/blogbench).

The time required to crash the machine varies, it seems to be easier to crash directly after a reboot (but that's highly speculative).
>Fix:
I've been wondering if this is somehow related to the following article in the adaptec knowledge base:

http://ask.adaptec.com/scripts/adaptec_tic.cfg/php.exe/enduser/std_adp.php?p_faqid=15357&p_created=1225366599&p_sid=NqNtKZrj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPSZwX3NvcnRfYnk9JnBfZ3JpZHNvcnQ9JnBfcm93X2NudD0yNjk3LDI2OTcmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT0x&p_li=&p_topview=1

It states:
"AACRAID based controllers have an underlying timeout/recovery cycle that is 35 seconds long. 

The default in some SCSI subsystems was 60 seconds in the past, but is now standardized at 30 seconds which results in an interference pattern between the controller and the L*n*x SCSI subsystem."

(I copy and pasted the entire article at the end of this post).

Since sys/dev/aac/aacvar.h sets AAC_CMD_TIMEOUT to 30 seconds I've been wondering if this is somehow related (there are also timeouts for immediate commands and the period check for timeouts interval - not sure how they're used in aac.c and too lazy to check).

The bottom line is, that adaptec states that their AACRAID based controllers may sometimes need >35 seconds to process a command under normal operational circumstances, if the controller is going through an "error correction cycle on the SAS/SATA bus" and they recommend to increase the timeouts on the OS side to 45 seconds.

(which might also explain why the take required to reproduce the problem varies heavily).

----------- Entire knowledge base article (see link above) ---------------
AACRAID based controllers have an underlying timeout/recovery cycle that is 35 seconds long. 

The default in some SCSI subsystems was 60 seconds in the past, but is now standardized at 30 seconds which results in an interference pattern between the controller and the L*n*x SCSI subsystem. 

The alternate workaround is for the user to adjust the timeout in SYSFS if it is shorter than 35 seconds. 

Changing the timeout values for a L*n*x block device can be done via SYSFS. For example, if /dev/sdc , /dev/sdd and /dev/sde are the device LUNs on a given Linux host, then the following commands need to be issued: 
echo 45 > /sys/block/sdc/device/timeout 
echo 45 > /sys/block /sdd/device/timeout 
echo 45 > /sys/block/sde/device/timeout 
In this example the timeout is 45 seconds which should be enough. 

Note: Any AACRAID based controller is going through an error correction cycle on the SAS/SATA bus that is delaying the completion of I/O beyond the L*n*x default timeout set for the device, this may be a hardware issue or a problem with the default timeout value as outlined above. If changing the timeout value doesn't solve the problem then please follow the steps we recommend to trouble shoot "Host adapter reset request. SCSI hang ?" messages: 
Check for any updated firmware for the motherboard, controller, targets and enclosure on the respective manufacturer's web sites.
Check per-device queue depth in SYSFS to make sure it is reasonable.
Engage disk drive manufacturer's technical support department to check through compatibility or drive class issues.
Engage enclosure manufacturer's technical support department to check through compatibility issues.


>Release-Note:
>Audit-Trail:

From: Mark Linimon <linimon@lonesome.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
	high load +suggested fix
Date: Thu, 25 Jun 2009 01:10:16 -0500

 ----- Forwarded message from Yuri Gorchakov <yuri.gorchakov@point-group.ru> -----
 
 From: Yuri Gorchakov <yuri.gorchakov@point-group.ru>
 To: freebsd-bugs@FreeBSD.org
 Subject: kern/135408: [aac] Adaptec 5405 RAID controller hanging under high
 	load +suggested fix
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Dear FreeBSD team,
 
 this is a comment to kern/135408: [aac] Adaptec 5405 RAID controller
 hanging under high load +suggested fix
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=135408)
 
 The suggested fix does not fix the problem. Please note!
 May be the post should be corrected?
 See the original message to the author of the PR.
 
 Yuri G.
 
 - -------- Original Message --------
 Subject: Adaptec 5405 + FreeBSD issue
 Date: Thu, 25 Jun 2009 12:12:51 +0700
 From: Yuri Gorchakov <yuri.gorchakov@point-group.ru>
 To: freebsdusb@bindone.de
 
 Dear Michael Gmelin,
 
 I have the same issue with FreeBSD 7.2 amd64 and Adaptec 5405 controller
 as posted at http://www.freebsd.org/cgi/query-pr.cgi?pr=135408
 I have tried the suggested fix by setting sys/dev/aac/aacvar.h
 AAC_CMD_TIMEOUT to 45 seconds and it did set the hang moment a little
 bit higher (I was able to run make -j12 buildworld twice and blogbench
 with 10 iterations), but didn't fix the problem completely - the
 controller died while running blogbench with 100 iterations.
 
 Have you managed to find the solution on your systems?
 
 Yuri.
 
 - --
 С уважением,
 Горчаков Юрий.
 Группа компаний "POiNT".
 Email: yuri.gorchakov@point-group.ru
 Web: http://point-group.ru
 
 Для передачи конфиденциальной информации мне
 вы можете воспользоваться ключом шифрования PGP, скачав его
 http://point-group.ru/yuri.gorchakov@point-group.ru.pub.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.11 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iEYEARECAAYFAkpDCbQACgkQj73gq1Rwjyh6QgCeOO8sGR/u/j9GHxBjqsy8Varn
 iJYAn3mmiTFUFGSbpMMi2R6NKcdheNdh
 =x+i2
 -----END PGP SIGNATURE-----
 
 ----- End forwarded message -----

From: Aleksandr Stankevic <alexiukas@gmail.com>
To: bug-followup@FreeBSD.org, freebsdusb@bindone.de, msmith@freebsd.org, 
	scottl@freebsd.org
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under 
	high load +suggested fix
Date: Fri, 26 Jun 2009 13:16:44 +0300

 Hi there,
 
 I've been having the same problem with aac on FreeBSD 7.2/amd64.
 We bought some Sun Fire X4150 servers which have Adaptec Raid
 controller and use aac driver.
 
 The suggested fix (increasing the timeouts to 45+ seconds) didn't
 help. It delayed the crash for a bit, but didn't completely fix it.
 
 I'm also sending some screenshots of the errors (without debugging,
 and with debugging), bootup screenshot and dmesg output of the system.
 
 If needed, it's possible to grant access to the server via Sun eLOM.
 
 
 -- 
 Aleksandr Stankevic
 Email: alexiukas@gmail.com
 ICQ: 214480900
 MSN: alex@braske.net
 Y!M: freelancealex@yahoo.com
 
 See: http://dev.fw.lt/freebsd/

From: Michael <freebsdusb@bindone.de>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
 	high load +suggested fix
Date: Fri, 26 Jun 2009 18:05:03 +0200

 Aleksandr Stankevic wrote:
 > The following reply was made to PR kern/135408; it has been noted by GNATS.
 > 
 > From: Aleksandr Stankevic <alexiukas@gmail.com>
 > To: bug-followup@FreeBSD.org, freebsdusb@bindone.de, msmith@freebsd.org, 
 > 	scottl@freebsd.org
 > Cc:  
 > Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under 
 > 	high load +suggested fix
 > Date: Fri, 26 Jun 2009 13:16:44 +0300
 > 
 >  --0016e65a0dc421977e046d3da3e1
 >  Content-Type: text/plain; charset=ISO-8859-1
 >  Content-Transfer-Encoding: 7bit
 >  
 >  Hi there,
 >  
 >  I've been having the same problem with aac on FreeBSD 7.2/amd64.
 >  We bought some Sun Fire X4150 servers which have Adaptec Raid
 >  controller and use aac driver.
 >  
 >  The suggested fix (increasing the timeouts to 45+ seconds) didn't
 >  help. It delayed the crash for a bit, but didn't completely fix it.
 >  
 >  I'm also sending some screenshots of the errors (without debugging,
 >  and with debugging), bootup screenshot and dmesg output of the system.
 >  
 >  If needed, it's possible to grant access to the server via Sun eLOM.
 >  
 >  
 >  -- 
 >  Aleksandr Stankevic
 >  Email: alexiukas@gmail.com
 >  ICQ: 214480900
 >  MSN: alex@braske.net
 >  Y!M: freelancealex@yahoo.com
 
 > _______________________________________________
 > freebsd-bugs@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
 
 I can confirm that the suggested fix was a red herring. We experience
 the same crashes here, tried tweaking everything, the best we could do
 was delaying the crash a little bit. This also happens with the aacu
 drivers provided directly by adaptec (they're incredibly slow, which
 basically helps delaying the crash by 1-2 hours). I would assume this is
 some problem with the controller/firmware (the firmware version shipped
 is newer than the BSD driver version provided by adaptec).
 
 Yuri Gorchakov just fowarded me this piece of information - adaptec just
 released a new firmware for this controller:
 
 "Hello Yuri,
 Hello from Adaptec,
 This message is in response to the problems that you are experiencing
 when using the Adaptec 5405 in your FreeBSD system.
 Adaptec recently posted a firmware upgrade for the Adaptec 5405 and the
 release notes doe mention a couple of fixes for FreeBSD.  You may want
 to try this to see if this might help to resolve your issues.
 The most recent firmware download is available at the link below.
 http://www.adaptec.com/en-US/speed/raid/asr/fw_bios/5405_fw_b17380_exe.htm
 Adaptec Technical Support"
 
 Maybe this helps you (even so the release notes don't look that
 promising and the number of severe problems fixed makes me wonder if I
 ever want to use adaptec again :).
 
 Michael
 
 

From: yuri.gorchakov@point-group.ru
To: bug-followup@FreeBSD.org
Cc: "Michael" <freebsdusb@bindone.de>
Subject: kern/135408: [aac] Adaptec 5405 RAID controller hanging under high 
     load +suggested fix
Date: Mon, 29 Jun 2009 13:18:14 +0700 (NOVST)

 Dear all,
 
 I've tested new firmware from Adaptec
 (http://www.adaptec.com/en-US/speed/raid/asr/fw_bios/5405_fw_b17380_exe.htm) and was able to
 heavily load the I/O subsystems on the server for 2-3 hours with blogbench at various loads
 and make -j16 buildworld, everything worked smoothly, but at some point the controller locked
 up same way as before.
 The firmware didn't fix the issue, may be prolonged the lock up for little bit.
 
 Yuri.
 
 
 

From: Gavin Atkinson <gavin@FreeBSD.org>
To: Michael Gmelin <freebsdusb@bindone.de>,
        Yuri Gorchakov <yuri.gorchakov@point-group.ru>,
        Aleksandr Stankevic <alexiukas@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
	high load +suggested fix
Date: Mon, 29 Jun 2009 14:34:46 +0100

 If any of you have a serial console attached to the machine, could you
 please recompile your kernel with "options AAC_DEBUG", and when the
 problem next occurs, please provide the first few pages of output.
 
 Thanks!
 
 Gavin

From: Aleksandr Stankevic <alexiukas@gmail.com>
To: Gavin Atkinson <gavin@freebsd.org>
Cc: Michael Gmelin <freebsdusb@bindone.de>, Yuri Gorchakov <yuri.gorchakov@point-group.ru>, 
	bug-followup@freebsd.org
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under 
	high load +suggested fix
Date: Mon, 29 Jun 2009 16:36:46 +0300

 Hi,
 
 Already done that, you can see the output here:
 
 http://dev.fw.lt/freebsd/aac_errors_2.jpg
 
 And some more stuff (dmesg, error without AAC_DEBUG and etc.) here:
 
 http://dev.fw.lt/freebsd/
 
 On Mon, Jun 29, 2009 at 4:34 PM, Gavin Atkinson<gavin@freebsd.org> wrote:
 > If any of you have a serial console attached to the machine, could you
 > please recompile your kernel with "options AAC_DEBUG", and when the
 > problem next occurs, please provide the first few pages of output.
 >
 > Thanks!
 >
 > Gavin
 >
 
 
 
 -- 
 Aleksandr Stankevic
 Email: alexiukas@gmail.com
 ICQ: 214480900
 MSN: alex@braske.net
 Y!M: freelancealex@yahoo.com

From: Mark Linimon <linimon@lonesome.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
	high load +suggested fix
Date: Thu, 16 Jul 2009 18:01:18 -0500

 ----- Forwarded message from Yuri Gorchakov <yuri.gorchakov@point-group.ru> -----
 
 From: Yuri Gorchakov <yuri.gorchakov@point-group.ru>
 To: Aleksandr Stankevic <alexiukas@gmail.com>
 Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
 	high load +suggested fix
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Hi all,
 
 yesterday I received a driver which shortly must by available online on
 Adaptec site and should fix the issue. Here I'm attaching it. I
 personally have't tried it yet in a production.
 
 Aleksandr Stankevic wrote:
 > On a 16 gb machine that's nothong near a real solution to me. Loosing
 > 13gb of ram is not what i want.
 > Also, i've tried using (previously i was using raid10) RAID5 on a test
 > box, and have run a lot of stress on it ( buildworld -j16, iozone,
 > bonnie++, backups and etc). It didn't crash on me yet. I'm in process of
 > moving the box to production to see if it won't crash there.
 > But even if it works, raid1/raid10 is what i, and imho most people, use,
 > so we need it fixed anyway.
 > 
 > On 2009.07.14, at 08:21, Yuri Gorchakov <yuri.gorchakov@point-group.ru>
 > wrote:
 > 
 > Hi all,
 > 
 > yesterday I received a reply from a manager I bought the controller
 > from. He was emailing with Adaptec technical support in Russia and
 > suggested couple of things:
 >    as a temporary workaround you can setup your BIOS to disable "Host
 > system Memory Mapped I/O above 4GB" , but note that not all BIOSes may
 > support it. Disadvantage of this is that RAM from 3,5  to 4GB will be
 > unavailable most probably.
 >    Adaptec is now working on a release of 2.2.8-16891 driver which
 > suppose
 > to fix the issue. They promise to post it on their web site ASAP.
 
 - --
 С уважением,
 Юрий Александрович Горчаков
 технический специалист
 компания "iT POiNT"
 Росиия, г.Томск
 ул.Рабочая 11а, 634050
 
 Email:	yuri.gorchakov@point-group.ru
 	info@point-group.ru
 WWW:	http://point-group.ru
 
 ****
 Для передачи конфиденциальной информации мне
 вы можете воспользоваться ключом шифрования PGP, скачав его
 http://point-group.ru/yuri.gorchakov@point-group.ru.pub.asc
 
 To send me confidencial information you may use PGP encryption key from
 http://point-group.ru/yuri.gorchakov@point-group.ru.pub.asc
 ****
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.12 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iEYEARECAAYFAkpdUdAACgkQj73gq1RwjyjoqwCffF6FrzVp67ptb1djNvUWQ/dL
 +t0An2ARMc45ZraeIpSgrmIowafvGvQD
 =C/kT
 -----END PGP SIGNATURE-----
 
 ----- End forwarded message -----

From: Yuri Gorchakov <yuri.gorchakov@point-group.ru>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under,high
 load +suggested fix
Date: Thu, 30 Jul 2009 00:38:34 +0700

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Hi all, again
 
 the driver which I attached did show on the web, so I put it on the ftp
 server - ftp://point-group.ru/Temp/Driver_2.2.8-16891_for_FreeBSD.zip
 - --
 С уважением,			Sincerely,
 Юрий Горчаков			Yuri Gorchakov
 технический специалист		technical specialist
 компания "iT POiNT"		"iT POiNT" company
 Росиия, г.Томск 		11a Rabochaya st.,
 ул.Рабочая 11а, 634050		Tomsk, Russia, 634050
 
 Email:	yuri.gorchakov@point-group.ru
 	info@point-group.ru
 WWW:	http://point-group.ru
 
 ****
 Для передачи конфиденциальной информации мне
 вы можете воспользоваться ключом шифрования PGP, скачав его
 http://point-group.ru/yuri.gorchakov@point-group.ru.pub.asc
 
 To send me confidencial information you may use PGP encryption key from
 http://point-group.ru/yuri.gorchakov@point-group.ru.pub.asc
 ****
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.12 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAkpwiRoACgkQj73gq1RwjyhNJACdHamkKYE6WtN25BybGTgNyEsw
 ok0An3m2PyaQjqMRtsEvQMaWBuET4uTV
 =GS9w
 -----END PGP SIGNATURE-----

From: Yuri Gorchakov <yuri.gorchakov@ittomsk.ru>
To: bug-followup@FreeBSD.org, freebsdusb@bindone.de
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under
 high load +suggested fix
Date: Tue, 08 Dec 2009 21:38:08 +0600

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Hi all,
 
 I'm still having this issue with the controller, latest firmware (5.2-0
 (17517)) and drivers (2.2-8 (17517)) don't fix the problem, but Adaptec
 suggested me to turn off write cache (switch it into write throught) on
 the controller (smth like arcconf SETCACHE 1 LOGICALDRIVE 0 wt) - so I
 did that and now I'm able to highly load the server with no problems.
 Current uptime after this change is 15 days.
 I didn't measure the performance penalty though.
 - --
 С уважением,
 Юрий Александрович Горчаков
 директор "Информационные технологии - Томск"
 
 Адрес:	634050, г.Томск, пер.Нахановича, д.12, оф.502
 Тел.:	+7 (3822) 332-382
 e-mail:	info@ittomsk.ru
 	yuri.gorchakov@ittomsk.ru
 www:	http://ittomsk.ru
 PGP:	http://ittomsk.ru/yuri.gorchakov@ittomsk.ru.pub.asc
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.13 (FreeBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQEcBAEBAgAGBQJLHnLgAAoJEHVbG2nsBnbiH9oH/RowqbsEwz6XoHEwCA05CSEQ
 wz15UF7qv9NTOGxcSOQYj1fnzMQSe+mVb1BollA8/KK5RPqMQmGsO8kjN2pFKDT9
 1ksxqDRXh+ybzRqJYi4hiC0XHByfVHjJ04sthnAcMBUUw7UpIzvNXGtHDpj+GyhL
 jL7qK2a0OiTg4iUBZM6EpJ4mokwq2UWv/CVJki8/ta7lZ/aIy9QjrhQlaoSthxbo
 xtutpsoBeB8ZHjWR/ItS8xE+g22cCwk4ozqZLMQLwabC8NkhNOpr0XlcV4LKHX7D
 7bVc9e/+osZWFAmJTyLAJ72Wgo1yQTzAGjKIIxS4ByDFZbNpybr6b4EP297EUfo=
 =GHZj
 -----END PGP SIGNATURE-----
State-Changed-From-To: open->feedback 
State-Changed-By: emaste 
State-Changed-When: Sun Jan 17 14:22:38 UTC 2010 
State-Changed-Why:  
Suggested firmware from Adaptec that may address the issue, and asked for 
feedback on the results of testing. 


Responsible-Changed-From-To: freebsd-bugs->emaste 
Responsible-Changed-By: emaste 
Responsible-Changed-When: Sun Jan 17 14:22:38 UTC 2010 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135408 

From: Ed Maste <emaste@freebsd.org>
To: bug-followup@FreeBSD.org, freebsdusb@bindone.de
Cc:  
Subject: Re: kern/135408: [aac] Adaptec 5405 RAID controller hanging under high load +suggested fix
Date: Sun, 17 Jan 2010 09:22:30 -0500

 Try contacting Adaptec support for firmware revision 17547 (or a later
 version except 17675).  It is supposed to have a fix for these hangs,
 and so far in my testing the hang has not been reproducible with it.
 
 If you are able to test with this version please follow up with your
 results.
 
 Thanks,
 Ed
State-Changed-From-To: feedback->closed 
State-Changed-By: emaste 
State-Changed-When: Sat Feb 20 13:07:29 UTC 2010 
State-Changed-Why:  
Further testing and information from Adaptec confirms that firmware 
revision 17547 fixes the bug commonly causing controller hangs on 
5xxx controllers. 

This firmware is not available on Adaptec's download page yet, you 
will have to contact Adaptec support directly to obtain it. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=135408 
>Unformatted:
