linux-kernel - [PATCH 1/1] aacraid: fix Sunrise Lake reset handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <AE4F746F2AECFC4DA4AADD66A1DFEF01C5B438@otce2k301.adaptec.com>
Date:	Fri, 27 Jul 2007 10:29:26 -0400
From:	"Salyzyn, Mark" <mark_salyzyn@...ptec.com>
To:	<linux-scsi@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Cc:	"Yinghai Lu" <yhlu.kernel@...il.com>,
	"Vivek Goyal" <vgoyal@...ibm.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: [PATCH 1/1] aacraid: fix Sunrise Lake reset handling

The patch is *much* smaller than the description. I am attempting to
answer to those that want to understand an issue that was reported in
May this year.

If a Sunrise Lake based card that requires an alternate reset mechanism
is set up to ignore the commanded IOP_RESET it reports 0x00000010
(IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism
to reset all cores), and thus the reset platform function decides to
switch to IOP_RESET_ALWAYS because the reset platform function
parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS
then responds with the 0x3803000F return code, but alas we treat this as
an error instead of using the alternate reset mechanism (put a 0x03 into
the register offset 0x38). The reset fails, but the fact that the
IOP_RESET_ALWAYS command was issued has put the card in a purposeful
shutdown state in preparation for the alternate hardware reset to be
applied. Yuck.

IOP_RESET is ignored in internal production cards, typically to ensure
that we catch all adapter lockup issues without the driver progressing
further, so this would not appear to be a field issue and thus this
patch was destined to be only in the internal Adaptec source tree.
IOP_RESET_ALWAYS is reserved for
kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as
expected in any case. Also in the past we have had OEMs specifically
request that cards not be resetable after a BlinkLED/FirmwareAssert for
one reason or another and To head off the possibility that the Sunrise
Lake based cards would suffer a similar fate, we propose the enclosed
fix.

Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when
he reported an issue to the linux kernel list back in May regarding a
kexec problem resulting from this reset being ignore. His fix was to
update the Firmware to one that did not ignore the IOP_RESET. Previous
kernels did not attempt to reset the adapter and that is why it surfaced
as a regression in his hands.

The current list of aacraid based cards that use Sunrise Lake:

9005:0285:9005:02b5     Adaptec 5445
9005:0285:9005:02b6     Adaptec 5805
9005:0285:9005:02b7     Adaptec 5085
9005:0285:9005:02c3     Adaptec 51205
9005:0285:9005:02c4     Adaptec 51605
9005:0285:9005:02ce     Adaptec 51245
9005:0285:9005:02cf     Adaptec 51645
9005:0285:9005:02d0     Adaptec 52445
9005:0285:9005:02d1     Adaptec 5405
9005:0285:9005:02b8     ICP     ICP5445SL
9005:0285:9005:02b9     ICP     ICP5085SL
9005:0285:9005:02ba     ICP     ICP5805SL
9005:0285:9005:02c5     ICP     ICP5125SL
9005:0285:9005:02c6     ICP     ICP5165SL
9005:0285:108e:7aac     SUN     STK RAID REM
9005:0285:108e:0286     SUN     STK RAID INT
9005:0285:108e:0287     SUN     STK RAID EXT
9005:0285:108e:7aae     SUN     STK RAID EM

All of these are publicly released with IOP_RESET enabled. So there is
no immediate need for this patch.

This attached patch is against July 11 2007 scsi-misc-2.6, still applies
today.

ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patch attachments.

Signed-off-by: Mark Salyzyn <aacraid@...ptec.com>

 /drivers/scsi/aacraid/rx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Yinghai Lu [mailto:yhlu.kernel@...il.com] 
Sent: Tuesday, May 29, 2007 10:00 PM
To: Andrew Morton; Vivek Goyal; Eric W. Biederman; AACRAID
Cc: Linux Kernel Mailing List
Subject: kexec and aacraid broken

latest tree, can not use kexec to load 2.6.22-rc3 at least.

got:

AAC0: adapter kernel panic'd fffffffd
AAC0: adapter kernel failed to start, init status=0

but can load 2.6.21.3

YH

Download attachment "aacraid_voodoo_reset.patch" of type "application/octet-stream" (507 bytes)