diff options
| author | Salyzyn, Mark <mark_salyzyn@adaptec.com> | 2007-07-27 10:29:26 -0400 |
|---|---|---|
| committer | James Bottomley <jejb@mulgrave.localdomain> | 2007-07-28 10:11:32 -0400 |
| commit | 9859c1aa7e16822c574e1be89d61fbfe6188b50f (patch) | |
| tree | adb8dcd33a391e4ed043e35cb748dcf41b000804 /drivers/scsi | |
| parent | b90f90d2303f27b9b241ab78419a07b41de5ac62 (diff) | |
[SCSI] 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.
Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'drivers/scsi')
| -rw-r--r-- | drivers/scsi/aacraid/rx.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c index ebc65b9fea92..73eef3dc5dc6 100644 --- a/drivers/scsi/aacraid/rx.c +++ b/drivers/scsi/aacraid/rx.c @@ -472,7 +472,7 @@ static int aac_rx_restart_adapter(struct aac_dev *dev, int bled) else { bled = aac_adapter_sync_cmd(dev, IOP_RESET_ALWAYS, 0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL); - if (!bled && (var != 0x00000001)) + if (!bled && (var != 0x00000001) && (var != 0x3803000F)) bled = -EINVAL; } if (bled && (bled != -ETIMEDOUT)) |