Panics for AACRAID driver during 'insmod' for kexec test.

Panics for AACRAID driver during 'insmod' for kexec test.

[Judith Lebzelter]

Hello, 

I have been running a series of kexec tests using LKDTT on the 
aacraid driver on this card (ASR-4805SAS (Marauder-E)) on x86_64
using the latest top of scsi-misc git-tree(as of yesterday), and 
I have found that it is not coming up consistantly when booted 
through kexec.

I have included 4 different types of failures I found here because 
I assume they might be related, and thought maybe there could 
be an issue with the card's state on reboot (through kexec).

The most common problem is this oops/panic, which has happened 
with various types of crash points (6 times out of 40):

Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
ko module^M
ACPI: PCI Interrupt 0000:03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> IRQ 3^M
general protection fault: 0000 [1] ^M
CPU 0 ^M
Modules linked in: aacraid^M
Pid: 0, comm: swapper Not tainted 2.6.21-rc3-kdump #1^M
RIP: 0010:[<ffffffff88008a99>]  [<ffffffff88008a99>] :aacraid:aac_intr_normal+0x17a/0x1b1^M
RSP: 0000:ffffffff81523ed8  EFLAGS: 00010006^M
RAX: ffff810004102000 RBX: ffff8100014f01e0 RCX: 0000000000000086^M
RDX: ffff810004041540 RSI: ffff8100014f01e0 RDI: cccccccccccccccc^M
RBP: ffff810004702cd8 R08: 00000000a6037e6c R09: 00000016001562d7^M
R10: 0000000000000023 R11: 0000000000000000 R12: 0000000000000011^M
R13: ffff810004702cd8 R14: ffff810004001400 R15: 0000000000000000^M
FS:  0000000000000000(0000) GS:ffffffff814d5000(0000) knlGS:0000000000000000^M
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b^M
CR2: 00000000006ba5a0 CR3: 000000000474d000 CR4: 00000000000006e0^M
Process swapper (pid: 0, threadinfo ffffffff814e4000, task ffffffff81470360)^M
Stack:  0000000000000011 ffff810004702cd8 0000000000000100 0000000000000003^M
 0000000000000001 ffffffff88009470 0000000000000000 ffff810004041540^M
 ffffffff814d5080 ffffffff810428f4 0000000000000000 ffffffff814d5080^M
Call Trace:^M
 <IRQ>  [<ffffffff88009470>] :aacraid:aac_rx_intr_message+0x2c/0x60^M
 [<ffffffff810428f4>] note_interrupt+0xd3/0x1db^M
 [<ffffffff8104319b>] handle_level_irq+0x7e/0xab^M
 [<ffffffff8100b0b1>] do_IRQ+0xd7/0x132^M
 [<ffffffff810085a1>] mwait_idle+0x0/0x43^M
 [<ffffffff81009651>] ret_from_intr+0x0/0xa^M
 <EOI>  [<ffffffff810085e0>] mwait_idle+0x3f/0x43^M
 [<ffffffff81008540>] cpu_idle+0x3d/0x5c^M
 [<ffffffff814e78d2>] start_kernel+0x28f/0x29b^M
 [<ffffffff814e7140>] _sinittext+0x140/0x144^M
^M
^M
Code: ff 53 38 eb 20 9c 58 fa 83 7b 30 00 75 07 c7 43 30 01 00 00 ^M
RIP  [<ffffffff88008a99>] :aacraid:aac_intr_normal+0x17a/0x1b1^M
Kernel panic - not syncing: Aiee, killing interrupt handler!^M
 

Another failure:   for crash point 'TIMERADD-bug' I got this error 
loading insmod:

Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
ko module^M
ACPI: PCI Interrupt 0000:03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> IRQ 3^M
input: ImExPS/2 Generic Explorer Mouse as /class/input/input3^M
aacraid: aac_fib_send: adapter blinkLED 0xc2.^M
Usually a result of a serious unrecoverable hardware problem^M
aac_fib_free, XferState != 0, fibptr = 0xffff8100014f0000, XferState = 0x810ad^M
aacraid: probe of 0000:03:0e.0 failed with error -14^M


Yet another Failure: for crash point 'TIMERADD-panic' I got this error 
during insmod:

Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
ko module^M
ACPI: PCI Interrupt 0000:03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> IRQ 3^M
input: ImExPS/2 Generic Explorer Mouse as /class/input/input3^M
Ecr^H ^H^H ^H^H ^HBUG: soft lockup detected on CPU#0!^M
^M
Call Trace:^M
 <IRQ>  [<ffffffff8102bcbb>] update_process_times+0x3b/0x5f^M
 [<ffffffff8100bebf>] main_timer_handler+0x2f/0x1ae^M
 [<ffffffff8102b504>] run_timer_softirq+0x14/0x161^M
 [<ffffffff8100c050>] timer_interrupt+0x12/0x27^M
 [<ffffffff81041f9c>] handle_IRQ_event+0x25/0x53^M
 [<ffffffff81028c1b>] __do_softirq+0x46/0x90^M
 [<ffffffff81043186>] handle_level_irq+0x69/0xab^M
 [<ffffffff8100b0b1>] do_IRQ+0xd7/0x132^M
 [<ffffffff81009651>] ret_from_intr+0x0/0xa^M
 <EOI>  [<ffffffff811229ed>] __delay+0x8/0x10^M
 [<ffffffff88007c68>] :aacraid:aac_fib_send+0x1ba/0x234^M
 [<ffffffff880048aa>] :aacraid:aac_get_adapter_info+0x76/0x536^M
 [<ffffffff88002bb3>] :aacraid:aac_probe_one+0x236/0x457^M
 [<ffffffff8112bd6d>] pci_device_probe+0x4c/0x75^M
 [<ffffffff8117d0da>] really_probe+0xc4/0x148^M
 [<ffffffff8117d30b>] __driver_attach+0x6d/0xab^M
 [<ffffffff8117d29e>] __driver_attach+0x0/0xab^M
 [<ffffffff8117d29e>] __driver_attach+0x0/0xab^M
 [<ffffffff8117c5b2>] bus_for_each_dev+0x43/0x6e^M
 [<ffffffff8117c8f4>] bus_add_driver+0x6b/0x18d^M
 [<ffffffff8112bf0b>] __pci_register_driver+0x72/0xa7^M
 [<ffffffff8801203a>] :aacraid:aac_init+0x3a/0x75^M
 [<ffffffff8103bafc>] sys_init_module+0x1195/0x12e6^M
 [<ffffffff8100913e>] system_call+0x7e/0x83^M
^M
BUG: soft lockup detected on CPU#0!^M

One last error I got for INT_TASKLET_ENTRY-exception was this
after the filesystem is mounted and I am copying the vmcore 
file to it:

Copying the dump
aacraid: Host adapter abort request (4,0,0,0)
aacraid: Host adapter abort request (4,0,0,0)
aacraid: Host adapter reset request. SCSI hang ?
[-- MARK -- Tue Mar 27 15:30:00 2007]
sd 4:0:0:0: [sdc] 143132672 512-byte hardware sectors (73284 MB)
sd 4:0:0:0: [sdc] Assuming Write Enabled
sd 4:0:0:0: [sdc] Assuming drive cache: write through
EXT3-fs error (device sdc1): ext3_new_block: Allocating block in system
zone - blocks from 1802240, length 1
EXT3-fs error (device sdc1): ext3_new_block: Allocating block in system
zone - blocks from 1802241, length 1
journal_bmap: journal block not found at offset 2184 on sdc1
Aborting journal on device sdc1.
ext3_abort called.
EXT3-fs error (device sdc1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device sdc1): ext3_free_blocks: Freeing blocks in system
zones - Block = 1802241, count = 1
EXT3-fs error (device sdc1) in ext3_free_blocks_sb: Journal has aborted
/bin/dd: writing to `/dump/dumpfile': Read-only file system
13190265+0 r__journal_remove_journal_head: freeing b_committed_data
ecords in
13190__journal_remove_journal_head: freeing b_frozen_data
264+0 records out
6753415168 bytes (6.8 GB) copied, 745.436 s, 9.1 MB/s
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data


That file size should be 8.5G.

Thanks,
Judith

Re: Panics for AACRAID driver during 'insmod' for kexec test.

[Vivek Goyal]

On Wed, Mar 28, 2007 at 02:54:32PM -0700, Judith Lebzelter wrote:
> Hello, 
> 
> I have been running a series of kexec tests using LKDTT on the 
> aacraid driver on this card (ASR-4805SAS (Marauder-E)) on x86_64
> using the latest top of scsi-misc git-tree(as of yesterday), and 
> I have found that it is not coming up consistantly when booted 
> through kexec.
> 
> I have included 4 different types of failures I found here because 
> I assume they might be related, and thought maybe there could 
> be an issue with the card's state on reboot (through kexec).
> 
> The most common problem is this oops/panic, which has happened 
> with various types of crash points (6 times out of 40):
> 
> Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> ko module^M
> ACPI: PCI Interrupt 0000:03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> IRQ 3^M
> general protection fault: 0000 [1] ^M
> CPU 0 ^M
> Modules linked in: aacraid^M
> Pid: 0, comm: swapper Not tainted 2.6.21-rc3-kdump #1^M
> RIP: 0010:[<ffffffff88008a99>]  [<ffffffff88008a99>] :aacraid:aac_intr_normal+0x17a/0x1b1^M
> RSP: 0000:ffffffff81523ed8  EFLAGS: 00010006^M
> RAX: ffff810004102000 RBX: ffff8100014f01e0 RCX: 0000000000000086^M
> RDX: ffff810004041540 RSI: ffff8100014f01e0 RDI: cccccccccccccccc^M
> RBP: ffff810004702cd8 R08: 00000000a6037e6c R09: 00000016001562d7^M
> R10: 0000000000000023 R11: 0000000000000000 R12: 0000000000000011^M
> R13: ffff810004702cd8 R14: ffff810004001400 R15: 0000000000000000^M
> FS:  0000000000000000(0000) GS:ffffffff814d5000(0000) knlGS:0000000000000000^M
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b^M
> CR2: 00000000006ba5a0 CR3: 000000000474d000 CR4: 00000000000006e0^M
> Process swapper (pid: 0, threadinfo ffffffff814e4000, task ffffffff81470360)^M
> Stack:  0000000000000011 ffff810004702cd8 0000000000000100 0000000000000003^M
>  0000000000000001 ffffffff88009470 0000000000000000 ffff810004041540^M
>  ffffffff814d5080 ffffffff810428f4 0000000000000000 ffffffff814d5080^M
> Call Trace:^M
>  <IRQ>  [<ffffffff88009470>] :aacraid:aac_rx_intr_message+0x2c/0x60^M
>  [<ffffffff810428f4>] note_interrupt+0xd3/0x1db^M
>  [<ffffffff8104319b>] handle_level_irq+0x7e/0xab^M
>  [<ffffffff8100b0b1>] do_IRQ+0xd7/0x132^M
>  [<ffffffff810085a1>] mwait_idle+0x0/0x43^M
>  [<ffffffff81009651>] ret_from_intr+0x0/0xa^M
>  <EOI>  [<ffffffff810085e0>] mwait_idle+0x3f/0x43^M
>  [<ffffffff81008540>] cpu_idle+0x3d/0x5c^M
>  [<ffffffff814e78d2>] start_kernel+0x28f/0x29b^M
>  [<ffffffff814e7140>] _sinittext+0x140/0x144^M
> ^M
> ^M
> Code: ff 53 38 eb 20 9c 58 fa 83 7b 30 00 75 07 c7 43 30 01 00 00 ^M
> RIP  [<ffffffff88008a99>] :aacraid:aac_intr_normal+0x17a/0x1b1^M
> Kernel panic - not syncing: Aiee, killing interrupt handler!^M
>  
> 

I don't much about the aacraid code but looking little bit, it looks like
the typical case where driver in second kernel receives the pending
interrupt from the device and in the interrupt handler it accesses some
data structures which are not even initialized yet. This interrupt must
have been pending from crashed kernel's context.

Either we should reset the device before doing request_irq(), so that
interrupts are cleared or do some kind of ABORT, FLUSH messages or
whatever the card firmware supports to clear the pending interrupts and 
flush exisiting commands before doing request_irq().

Thanks
Vivek

RE: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test.

[Salyzyn, Mark]

I have been working on a patch to the driver to do just this, reset the
adapter during init if necessary. We want to limit the adapter's reset
as it takes time (an additional 45 seconds or longer) for the Firmware
to cycle... I will bump the priority of the testing for this patch.

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> Sent: Wednesday, March 28, 2007 11:12 PM
> To: Judith Lebzelter
> Cc: linux-scsi@vger.kernel.org; AACRAID; fastboot@lists.osdl.org
> Subject: Re: [Fastboot] Panics for AACRAID driver during 
> 'insmod' for kexec test.
> 
> 
> On Wed, Mar 28, 2007 at 02:54:32PM -0700, Judith Lebzelter wrote:
> > Hello, 
> > 
> > I have been running a series of kexec tests using LKDTT on the 
> > aacraid driver on this card (ASR-4805SAS (Marauder-E)) on x86_64
> > using the latest top of scsi-misc git-tree(as of yesterday), and 
> > I have found that it is not coming up consistantly when booted 
> > through kexec.
> > 
> > I have included 4 different types of failures I found here because 
> > I assume they might be related, and thought maybe there could 
> > be an issue with the card's state on reboot (through kexec).
> > 
> > The most common problem is this oops/panic, which has happened 
> > with various types of crash points (6 times out of 40):
> > 
> > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> > ko module^M
> > ACPI: PCI Interrupt 0000:03:0e.0[A] -> Link [LNKC] -> GSI 3 
> (level, low) -> IRQ 3^M
> > general protection fault: 0000 [1] ^M
> > CPU 0 ^M
> > Modules linked in: aacraid^M
> > Pid: 0, comm: swapper Not tainted 2.6.21-rc3-kdump #1^M
> > RIP: 0010:[<ffffffff88008a99>]  [<ffffffff88008a99>] 
> :aacraid:aac_intr_normal+0x17a/0x1b1^M
> > RSP: 0000:ffffffff81523ed8  EFLAGS: 00010006^M
> > RAX: ffff810004102000 RBX: ffff8100014f01e0 RCX: 0000000000000086^M
> > RDX: ffff810004041540 RSI: ffff8100014f01e0 RDI: cccccccccccccccc^M
> > RBP: ffff810004702cd8 R08: 00000000a6037e6c R09: 00000016001562d7^M
> > R10: 0000000000000023 R11: 0000000000000000 R12: 0000000000000011^M
> > R13: ffff810004702cd8 R14: ffff810004001400 R15: 0000000000000000^M
> > FS:  0000000000000000(0000) GS:ffffffff814d5000(0000) 
> knlGS:0000000000000000^M
> > CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b^M
> > CR2: 00000000006ba5a0 CR3: 000000000474d000 CR4: 00000000000006e0^M
> > Process swapper (pid: 0, threadinfo ffffffff814e4000, task 
> ffffffff81470360)^M
> > Stack:  0000000000000011 ffff810004702cd8 0000000000000100 
> 0000000000000003^M
> >  0000000000000001 ffffffff88009470 0000000000000000 
> ffff810004041540^M
> >  ffffffff814d5080 ffffffff810428f4 0000000000000000 
> ffffffff814d5080^M
> > Call Trace:^M
> >  <IRQ>  [<ffffffff88009470>] 
> :aacraid:aac_rx_intr_message+0x2c/0x60^M
> >  [<ffffffff810428f4>] note_interrupt+0xd3/0x1db^M
> >  [<ffffffff8104319b>] handle_level_irq+0x7e/0xab^M
> >  [<ffffffff8100b0b1>] do_IRQ+0xd7/0x132^M
> >  [<ffffffff810085a1>] mwait_idle+0x0/0x43^M
> >  [<ffffffff81009651>] ret_from_intr+0x0/0xa^M
> >  <EOI>  [<ffffffff810085e0>] mwait_idle+0x3f/0x43^M
> >  [<ffffffff81008540>] cpu_idle+0x3d/0x5c^M
> >  [<ffffffff814e78d2>] start_kernel+0x28f/0x29b^M
> >  [<ffffffff814e7140>] _sinittext+0x140/0x144^M
> > ^M
> > ^M
> > Code: ff 53 38 eb 20 9c 58 fa 83 7b 30 00 75 07 c7 43 30 01 00 00 ^M
> > RIP  [<ffffffff88008a99>] :aacraid:aac_intr_normal+0x17a/0x1b1^M
> > Kernel panic - not syncing: Aiee, killing interrupt handler!^M
> >  
> > 
> 
> I don't much about the aacraid code but looking little bit, 
> it looks like
> the typical case where driver in second kernel receives the pending
> interrupt from the device and in the interrupt handler it 
> accesses some
> data structures which are not even initialized yet. This 
> interrupt must
> have been pending from crashed kernel's context.
> 
> Either we should reset the device before doing request_irq(), so that
> interrupts are cleared or do some kind of ABORT, FLUSH messages or
> whatever the card firmware supports to clear the pending 
> interrupts and 
> flush exisiting commands before doing request_irq().
> 
> Thanks
> Vivek
> 

Re: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test.

[Vivek Goyal]

On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> I have been working on a patch to the driver to do just this, reset the
> adapter during init if necessary. We want to limit the adapter's reset
> as it takes time (an additional 45 seconds or longer) for the Firmware
> to cycle... I will bump the priority of the testing for this patch.
> 
Hi,

Thanks for looking into this. You can make device reset conditional. Now
one command line parameter "reset_devices" has been defined for the kernel.
You can reset the device only if the user has passed reset_devices command
line option otherwise you can continue to boot normaly.

I have introduced this parameter to handle the concern that in normal
BIOS boot total boot time will increase.

kexec/kdump will pass this parameter to second kernel so that device will
be reset during initialization and normal BIOS boot will reamin unaffected.

Thanks
Vivek

[PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test.

[Salyzyn, Mark]

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

Thanks for the info.

Attached is the patch I feel will address this issue. As an added 'perk' I have also added the code to detect if the controller was previously initialized for interrupted operations by ANY operating system should the reset_devices kernel parameter not be set and we are dealing with a naïve kexec without the addition of this kernel parameter. The reset handler is also improved. Related to reset operations, but not pertinent specifically to this issue, I have also altered the handling somewhat so that we reset the adapter if we feel it is taking too long (three minutes) to start up.

We have not unit tested the reset_devices flag propagation to this driver code, nor have we unit tested the check for the interrupted operations under the conditions of a naively issued kexec. We are submitting this modified driver to our Q/A department for integration testing in our current programs. I would appreciate an ACK to this patch should it resolve the issue described in this thread...

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

This attached patch is against current scsi-misc-2.6
 
Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>

---

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> Sent: Friday, March 30, 2007 2:06 AM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; linux-scsi@vger.kernel.org; AACRAID; 
> fastboot@lists.osdl.org
> Subject: Re: [Fastboot] Panics for AACRAID driver during 
> 'insmod' for kexec test.
> 
> 
> On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> > I have been working on a patch to the driver to do just 
> this, reset the
> > adapter during init if necessary. We want to limit the 
> adapter's reset
> > as it takes time (an additional 45 seconds or longer) for 
> the Firmware
> > to cycle... I will bump the priority of the testing for this patch.
> > 
> Hi,
> 
> Thanks for looking into this. You can make device reset 
> conditional. Now
> one command line parameter "reset_devices" has been defined 
> for the kernel.
> You can reset the device only if the user has passed 
> reset_devices command
> line option otherwise you can continue to boot normaly.
> 
> I have introduced this parameter to handle the concern that in normal
> BIOS boot total boot time will increase.
> 
> kexec/kdump will pass this parameter to second kernel so that 
> device will
> be reset during initialization and normal BIOS boot will 
> reamin unaffected.
> 
> Thanks
> Vivek
> 

[-- Attachment #2: aacraid_kexec.patch --]
[-- Type: application/octet-stream, Size: 2776 bytes --]

diff -ru a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c
--- a/drivers/scsi/aacraid/rx.c	2007-03-30 10:10:30.757394619 -0400
+++ b/drivers/scsi/aacraid/rx.c	2007-03-30 10:10:35.811757528 -0400
@@ -294,7 +294,7 @@
  *	Start up processing on an i960 based AAC adapter
  */
 
-void aac_rx_start_adapter(struct aac_dev *dev)
+static void aac_rx_start_adapter(struct aac_dev *dev)
 {
 	struct aac_init *init;
 
@@ -467,16 +467,19 @@
 	if (bled)
 		printk(KERN_ERR "%s%d: adapter kernel panic'd %x.\n",
 			dev->name, dev->id, bled);
-	else
+	else {
 		bled = aac_adapter_sync_cmd(dev, IOP_RESET_ALWAYS,
 		  0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL);
-	if (bled)
+		if (!bled && (var != 0x00000001))
+			bled = -EINVAL;
+	}
+	if (bled && (bled != -ETIMEDOUT))
 		bled = aac_adapter_sync_cmd(dev, IOP_RESET,
 		  0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL);
-	if (bled)
+	if (bled && (bled != -ETIMEDOUT))
 		return -EINVAL;
-	if (var == 0x3803000F) { /* USE_OTHER_METHOD */
+	if (bled || (var == 0x3803000F)) { /* USE_OTHER_METHOD */
 		rx_writel(dev, MUnit.reserved2, 3);
 		msleep(5000); /* Delay 5 seconds */
 		var = 0x00000001;
@@ -526,6 +529,7 @@
 {
 	unsigned long start;
 	unsigned long status;
+	int restart = 0;
 	int instance = dev->id;
 	const char * name = dev->name;
 
@@ -534,15 +538,19 @@
 		goto error_iounmap;
 	}
 
+	/* Failure to reset here is an option ... */
+	dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
+	if ((((status & 0xff) != 0xff) || reset_devices) &&
+	  !aac_rx_restart_adapter(dev, 0))
+		++restart;
 	/*
 	 *	Check to see if the board panic'd while booting.
 	 */
 	status = rx_readl(dev, MUnit.OMRx[0]);
 	if (status & KERNEL_PANIC) {
-		if ((status = aac_rx_check_health(dev)) <= 0)
-			goto error_iounmap;
-		if (aac_rx_restart_adapter(dev, status))
+		if (aac_rx_restart_adapter(dev, aac_rx_check_health(dev)))
 			goto error_iounmap;
+		++restart;
 	}
 	/*
 	 *	Check to see if the board failed any self tests.
@@ -565,11 +573,23 @@
 	 */
 	while (!((status = rx_readl(dev, MUnit.OMRx[0])) & KERNEL_UP_AND_RUNNING))
 	{
-		if(time_after(jiffies, start+startup_timeout*HZ)) {
+		if ((restart &&
+		  (status & (KERNEL_PANIC|SELF_TEST_FAILED|MONITOR_PANIC))) ||
+		  time_after(jiffies, start+HZ*startup_timeout)) {
 			printk(KERN_ERR "%s%d: adapter kernel failed to start, init status = %lx.\n", 
 					dev->name, instance, status);
 			goto error_iounmap;
 		}
+		if (!restart &&
+		  ((status & (KERNEL_PANIC|SELF_TEST_FAILED|MONITOR_PANIC)) ||
+		  time_after(jiffies, start + HZ *
+		  ((startup_timeout > 60)
+		    ? (startup_timeout - 60)
+		    : (startup_timeout / 2))))) {
+			if (likely(!aac_rx_restart_adapter(dev, aac_rx_check_health(dev))))
+				start = jiffies;
+			++restart;
+		}
 		msleep(1);
 	}
 	/*

Re: [PATCH] aacraid: Panics for AACRAID driver during 'insmod' for kexec test.

[Judith Lebzelter]

On Fri, Mar 30, 2007 at 10:30:48AM -0400, Salyzyn, Mark wrote:
> Thanks for the info.
> 
> Attached is the patch I feel will address this issue. As an added 'perk' I have also added the code to detect if the controller was previously initialized for interrupted operations by ANY operating system should the reset_devices kernel parameter not be set and we are dealing with a naïve kexec without the addition of this kernel parameter. The reset handler is also improved. Related to reset operations, but not pertinent specifically to this issue, I have also altered the handling somewhat so that we reset the adapter if we feel it is taking too long (three minutes) to start up.
> 
> We have not unit tested the reset_devices flag propagation to this driver code, nor have we unit tested the check for the interrupted operations under the conditions of a naively issued kexec. We are submitting this modified driver to our Q/A department for integration testing in our current programs. I would appreciate an ACK to this patch should it resolve the issue described in this thread...
> 

Mark; 

I am getting an error applying this patch:

-bash-3.1# patch -p1 < ../../aacraid_kexec.patch
patching file drivers/scsi/aacraid/rx.c
patch: **** malformed patch at line 36: @@ -526,6 +529,7 @@

Do you think you could regenerate it?

Thanks;
Judith

> ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patches.
> 
> This attached patch is against current scsi-misc-2.6
>  
> Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
> 
> ---
> 
> Sincerely -- Mark Salyzyn
> 
> > -----Original Message-----
> > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > Sent: Friday, March 30, 2007 2:06 AM
> > To: Salyzyn, Mark
> > Cc: Judith Lebzelter; linux-scsi@vger.kernel.org; AACRAID; 
> > fastboot@lists.osdl.org
> > Subject: Re: [Fastboot] Panics for AACRAID driver during 
> > 'insmod' for kexec test.
> > 
> > 
> > On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> > > I have been working on a patch to the driver to do just 
> > this, reset the
> > > adapter during init if necessary. We want to limit the 
> > adapter's reset
> > > as it takes time (an additional 45 seconds or longer) for 
> > the Firmware
> > > to cycle... I will bump the priority of the testing for this patch.
> > > 
> > Hi,
> > 
> > Thanks for looking into this. You can make device reset 
> > conditional. Now
> > one command line parameter "reset_devices" has been defined 
> > for the kernel.
> > You can reset the device only if the user has passed 
> > reset_devices command
> > line option otherwise you can continue to boot normaly.
> > 
> > I have introduced this parameter to handle the concern that in normal
> > BIOS boot total boot time will increase.
> > 
> > kexec/kdump will pass this parameter to second kernel so that 
> > device will
> > be reset during initialization and normal BIOS boot will 
> > reamin unaffected.
> > 
> > Thanks
> > Vivek
> > 

RE: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test.

[Salyzyn, Mark]

[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]

Resending patch file.

I looked at the submission that showed on the list, and the original email, and a blank line dropped away at line 20 of the patch (!)

Dunno, hope this comes through this second time. But if not, please add the blank line as referenced.

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: Judith Lebzelter [mailto:judith@linux-foundation.org] 
> Sent: Friday, March 30, 2007 1:10 PM
> To: Salyzyn, Mark
> Cc: vgoyal@in.ibm.com; Judith Lebzelter; 
> linux-scsi@vger.kernel.org; fastboot@lists.osdl.org
> Subject: Re: [PATCH] aacraid: [Fastboot] Panics for AACRAID 
> driver during 'insmod' for kexec test.
> 
> 
> On Fri, Mar 30, 2007 at 10:30:48AM -0400, Salyzyn, Mark wrote:
> > Thanks for the info.
> > 
> > Attached is the patch I feel will address this issue. As an 
> added 'perk' I have also added the code to detect if the 
> controller was previously initialized for interrupted 
> operations by ANY operating system should the reset_devices 
> kernel parameter not be set and we are dealing with a naïve 
> kexec without the addition of this kernel parameter. The 
> reset handler is also improved. Related to reset operations, 
> but not pertinent specifically to this issue, I have also 
> altered the handling somewhat so that we reset the adapter if 
> we feel it is taking too long (three minutes) to start up.
> > 
> > We have not unit tested the reset_devices flag propagation 
> to this driver code, nor have we unit tested the check for 
> the interrupted operations under the conditions of a naively 
> issued kexec. We are submitting this modified driver to our 
> Q/A department for integration testing in our current 
> programs. I would appreciate an ACK to this patch should it 
> resolve the issue described in this thread...
> > 
> 
> Mark; 
> 
> I am getting an error applying this patch:
> 
> -bash-3.1# patch -p1 < ../../aacraid_kexec.patch
> patching file drivers/scsi/aacraid/rx.c
> patch: **** malformed patch at line 36: @@ -526,6 +529,7 @@
> 
> Do you think you could regenerate it?
> 
> Thanks;
> Judith
> 
> > ObligatoryDisclaimer: Please accept my condolences 
> regarding Outlook's handling of patches.
> > 
> > This attached patch is against current scsi-misc-2.6
> >  
> > Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
> > 
> > ---
> > 
> > Sincerely -- Mark Salyzyn
> > 
> > > -----Original Message-----
> > > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > > Sent: Friday, March 30, 2007 2:06 AM
> > > To: Salyzyn, Mark
> > > Cc: Judith Lebzelter; linux-scsi@vger.kernel.org; AACRAID; 
> > > fastboot@lists.osdl.org
> > > Subject: Re: [Fastboot] Panics for AACRAID driver during 
> > > 'insmod' for kexec test.
> > > 
> > > 
> > > On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> > > > I have been working on a patch to the driver to do just 
> > > this, reset the
> > > > adapter during init if necessary. We want to limit the 
> > > adapter's reset
> > > > as it takes time (an additional 45 seconds or longer) for 
> > > the Firmware
> > > > to cycle... I will bump the priority of the testing for 
> this patch.
> > > > 
> > > Hi,
> > > 
> > > Thanks for looking into this. You can make device reset 
> > > conditional. Now
> > > one command line parameter "reset_devices" has been defined 
> > > for the kernel.
> > > You can reset the device only if the user has passed 
> > > reset_devices command
> > > line option otherwise you can continue to boot normaly.
> > > 
> > > I have introduced this parameter to handle the concern 
> that in normal
> > > BIOS boot total boot time will increase.
> > > 
> > > kexec/kdump will pass this parameter to second kernel so that 
> > > device will
> > > be reset during initialization and normal BIOS boot will 
> > > reamin unaffected.
> > > 
> > > Thanks
> > > Vivek
> > > 
> 
> 
> 

[-- Attachment #2: aacraid_kexec.patch --]
[-- Type: application/octet-stream, Size: 2694 bytes --]

diff -ru a/rx.c b/rx.c
--- a/rx.c	2007-03-30 10:10:30.757394619 -0400
+++ b/rx.c	2007-03-30 13:16:57.869791252 -0400
@@ -294,7 +294,7 @@
  *	Start up processing on an i960 based AAC adapter
  */
 
-void aac_rx_start_adapter(struct aac_dev *dev)
+static void aac_rx_start_adapter(struct aac_dev *dev)
 {
 	struct aac_init *init;
 
@@ -467,16 +467,19 @@
 	if (bled)
 		printk(KERN_ERR "%s%d: adapter kernel panic'd %x.\n",
 			dev->name, dev->id, bled);
-	else
+	else {
 		bled = aac_adapter_sync_cmd(dev, IOP_RESET_ALWAYS,
 		  0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL);
-	if (bled)
+		if (!bled && (var != 0x00000001))
+			bled = -EINVAL;
+	}
+	if (bled && (bled != -ETIMEDOUT))
 		bled = aac_adapter_sync_cmd(dev, IOP_RESET,
 		  0, 0, 0, 0, 0, 0, &var, NULL, NULL, NULL, NULL);
 
-	if (bled)
+	if (bled && (bled != -ETIMEDOUT))
 		return -EINVAL;
-	if (var == 0x3803000F) { /* USE_OTHER_METHOD */
+	if (bled || (var == 0x3803000F)) { /* USE_OTHER_METHOD */
 		rx_writel(dev, MUnit.reserved2, 3);
 		msleep(5000); /* Delay 5 seconds */
 		var = 0x00000001;
@@ -526,6 +529,7 @@
 {
 	unsigned long start;
 	unsigned long status;
+	int restart = 0;
 	int instance = dev->id;
 	const char * name = dev->name;
 
@@ -534,15 +538,19 @@
 		goto error_iounmap;
 	}
 
+	/* Failure to reset here is an option ... */
+	dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
+	if ((((status & 0xff) != 0xff) || reset_devices) &&
+	  !aac_rx_restart_adapter(dev, 0))
+		++restart;
 	/*
 	 *	Check to see if the board panic'd while booting.
 	 */
 	status = rx_readl(dev, MUnit.OMRx[0]);
 	if (status & KERNEL_PANIC) {
-		if ((status = aac_rx_check_health(dev)) <= 0)
-			goto error_iounmap;
-		if (aac_rx_restart_adapter(dev, status))
+		if (aac_rx_restart_adapter(dev, aac_rx_check_health(dev)))
 			goto error_iounmap;
+		++restart;
 	}
 	/*
 	 *	Check to see if the board failed any self tests.
@@ -565,11 +573,23 @@
 	 */
 	while (!((status = rx_readl(dev, MUnit.OMRx[0])) & KERNEL_UP_AND_RUNNING))
 	{
-		if(time_after(jiffies, start+startup_timeout*HZ)) {
+		if ((restart &&
+		  (status & (KERNEL_PANIC|SELF_TEST_FAILED|MONITOR_PANIC))) ||
+		  time_after(jiffies, start+HZ*startup_timeout)) {
 			printk(KERN_ERR "%s%d: adapter kernel failed to start, init status = %lx.\n", 
 					dev->name, instance, status);
 			goto error_iounmap;
 		}
+		if (!restart &&
+		  ((status & (KERNEL_PANIC|SELF_TEST_FAILED|MONITOR_PANIC)) ||
+		  time_after(jiffies, start + HZ *
+		  ((startup_timeout > 60)
+		    ? (startup_timeout - 60)
+		    : (startup_timeout / 2))))) {
+			if (likely(!aac_rx_restart_adapter(dev, aac_rx_check_health(dev))))
+				start = jiffies;
+			++restart;
+		}
 		msleep(1);
 	}
 	/*

Re: [PATCH] aacraid: Panics for AACRAID driver during 'insmod' for kexec test.

[Judith Lebzelter]

On Fri, Mar 30, 2007 at 01:21:33PM -0400, Salyzyn, Mark wrote:
> Resending patch file.
> 
> I looked at the submission that showed on the list, and the original email, and a blank line dropped away at line 20 of the patch (!)
> 
> Dunno, hope this comes through this second time. But if not, please add the blank line as referenced.
> 

Now I got this error which does not seem to be the result of the missing line:

Hunk #3 FAILED at 529.
Hunk #4 succeeded at 541 (offset 3 lines).
Hunk #5 FAILED at 576.


I tried manually editing in those two hunks and got an error on compile:

C [M]  drivers/scsi/aacraid/rx.o
drivers/scsi/aacraid/rx.c: In function '_aac_rx_init':
drivers/scsi/aacraid/rx.c:641: warning: ISO C90 forbids mixed declarations and code
drivers/scsi/aacraid/rx.c:650: error: expected declaration or statement at end of input
drivers/scsi/aacraid/rx.c:650: warning: control reaches end of non-void function
make[3]: *** [drivers/scsi/aacraid/rx.o] Error 1
make[2]: *** [drivers/scsi/aacraid] Error 2
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

I am pretty sure that I pasted okay, it is not that big a hunk and 
I tried it twice.  Are you sure that the git tree you used is up to date?  
I am not sure why this is failing; it doesn't look off.  Line 641 is actually
the start of the next function aac_rx_init(), not _aac_rx_init().

Judith

> 
> > -----Original Message-----
> > From: Judith Lebzelter [mailto:judith@linux-foundation.org] 
> > Sent: Friday, March 30, 2007 1:10 PM
> > To: Salyzyn, Mark
> > Cc: vgoyal@in.ibm.com; Judith Lebzelter; 
> > linux-scsi@vger.kernel.org; fastboot@lists.osdl.org
> > Subject: Re: [PATCH] aacraid: [Fastboot] Panics for AACRAID 
> > driver during 'insmod' for kexec test.
> > 
> > 
> > On Fri, Mar 30, 2007 at 10:30:48AM -0400, Salyzyn, Mark wrote:
> > > Thanks for the info.
> > > 
> > > Attached is the patch I feel will address this issue. As an 
> > added 'perk' I have also added the code to detect if the 
> > controller was previously initialized for interrupted 
> > operations by ANY operating system should the reset_devices 
> > kernel parameter not be set and we are dealing with a naïve 
> > kexec without the addition of this kernel parameter. The 
> > reset handler is also improved. Related to reset operations, 
> > but not pertinent specifically to this issue, I have also 
> > altered the handling somewhat so that we reset the adapter if 
> > we feel it is taking too long (three minutes) to start up.
> > > 
> > > We have not unit tested the reset_devices flag propagation 
> > to this driver code, nor have we unit tested the check for 
> > the interrupted operations under the conditions of a naively 
> > issued kexec. We are submitting this modified driver to our 
> > Q/A department for integration testing in our current 
> > programs. I would appreciate an ACK to this patch should it 
> > resolve the issue described in this thread...
> > > 
> > 
> > Mark; 
> > 
> > I am getting an error applying this patch:
> > 
> > -bash-3.1# patch -p1 < ../../aacraid_kexec.patch
> > patching file drivers/scsi/aacraid/rx.c
> > patch: **** malformed patch at line 36: @@ -526,6 +529,7 @@
> > 
> > Do you think you could regenerate it?
> > 
> > Thanks;
> > Judith
> > 
> > > ObligatoryDisclaimer: Please accept my condolences 
> > regarding Outlook's handling of patches.
> > > 
> > > This attached patch is against current scsi-misc-2.6
> > >  
> > > Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
> > > 
> > > ---
> > > 
> > > Sincerely -- Mark Salyzyn
> > > 
> > > > -----Original Message-----
> > > > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > > > Sent: Friday, March 30, 2007 2:06 AM
> > > > To: Salyzyn, Mark
> > > > Cc: Judith Lebzelter; linux-scsi@vger.kernel.org; AACRAID; 
> > > > fastboot@lists.osdl.org
> > > > Subject: Re: [Fastboot] Panics for AACRAID driver during 
> > > > 'insmod' for kexec test.
> > > > 
> > > > 
> > > > On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> > > > > I have been working on a patch to the driver to do just 
> > > > this, reset the
> > > > > adapter during init if necessary. We want to limit the 
> > > > adapter's reset
> > > > > as it takes time (an additional 45 seconds or longer) for 
> > > > the Firmware
> > > > > to cycle... I will bump the priority of the testing for 
> > this patch.
> > > > > 
> > > > Hi,
> > > > 
> > > > Thanks for looking into this. You can make device reset 
> > > > conditional. Now
> > > > one command line parameter "reset_devices" has been defined 
> > > > for the kernel.
> > > > You can reset the device only if the user has passed 
> > > > reset_devices command
> > > > line option otherwise you can continue to boot normaly.
> > > > 
> > > > I have introduced this parameter to handle the concern 
> > that in normal
> > > > BIOS boot total boot time will increase.
> > > > 
> > > > kexec/kdump will pass this parameter to second kernel so that 
> > > > device will
> > > > be reset during initialization and normal BIOS boot will 
> > > > reamin unaffected.
> > > > 
> > > > Thanks
> > > > Vivek
> > > > 
> > 
> > 
> > 

Re: [PATCH] aacraid: Panics for AACRAID driver during 'insmod' for kexec test.

[Salyzyn, Mark]

My tree I am working on is 'more advanced' as it includes the series of other patches submitted over the past week :-( We have some interference going on. I suggest pulling this patch until the others have cleared.

I will submit a patch to you privately to work this issue shortly ...

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: Judith Lebzelter [mailto:judith@linux-foundation.org] 
> Sent: Friday, March 30, 2007 2:38 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; vgoyal@in.ibm.com; 
> linux-scsi@vger.kernel.org; fastboot@lists.osdl.org
> Subject: Re: [PATCH] aacraid: [Fastboot] Panics for AACRAID 
> driver during 'insmod' for kexec test.
> 
> 
> On Fri, Mar 30, 2007 at 01:21:33PM -0400, Salyzyn, Mark wrote:
> > Resending patch file.
> > 
> > I looked at the submission that showed on the list, and the 
> original email, and a blank line dropped away at line 20 of 
> the patch (!)
> > 
> > Dunno, hope this comes through this second time. But if 
> not, please add the blank line as referenced.
> > 
> 
> Now I got this error which does not seem to be the result of 
> the missing line:
> 
> Hunk #3 FAILED at 529.
> Hunk #4 succeeded at 541 (offset 3 lines).
> Hunk #5 FAILED at 576.
> 
> 
> I tried manually editing in those two hunks and got an error 
> on compile:
> 
> C [M]  drivers/scsi/aacraid/rx.o
> drivers/scsi/aacraid/rx.c: In function '_aac_rx_init':
> drivers/scsi/aacraid/rx.c:641: warning: ISO C90 forbids mixed 
> declarations and code
> drivers/scsi/aacraid/rx.c:650: error: expected declaration or 
> statement at end of input
> drivers/scsi/aacraid/rx.c:650: warning: control reaches end 
> of non-void function
> make[3]: *** [drivers/scsi/aacraid/rx.o] Error 1
> make[2]: *** [drivers/scsi/aacraid] Error 2
> make[1]: *** [drivers/scsi] Error 2
> make: *** [drivers] Error 2
> 
> I am pretty sure that I pasted okay, it is not that big a hunk and 
> I tried it twice.  Are you sure that the git tree you used is 
> up to date?  
> I am not sure why this is failing; it doesn't look off.  Line 
> 641 is actually
> the start of the next function aac_rx_init(), not _aac_rx_init().
> 
> Judith
> 
> > 
> > > -----Original Message-----
> > > From: Judith Lebzelter [mailto:judith@linux-foundation.org] 
> > > Sent: Friday, March 30, 2007 1:10 PM
> > > To: Salyzyn, Mark
> > > Cc: vgoyal@in.ibm.com; Judith Lebzelter; 
> > > linux-scsi@vger.kernel.org; fastboot@lists.osdl.org
> > > Subject: Re: [PATCH] aacraid: [Fastboot] Panics for AACRAID 
> > > driver during 'insmod' for kexec test.
> > > 
> > > 
> > > On Fri, Mar 30, 2007 at 10:30:48AM -0400, Salyzyn, Mark wrote:
> > > > Thanks for the info.
> > > > 
> > > > Attached is the patch I feel will address this issue. As an 
> > > added 'perk' I have also added the code to detect if the 
> > > controller was previously initialized for interrupted 
> > > operations by ANY operating system should the reset_devices 
> > > kernel parameter not be set and we are dealing with a naïve 
> > > kexec without the addition of this kernel parameter. The 
> > > reset handler is also improved. Related to reset operations, 
> > > but not pertinent specifically to this issue, I have also 
> > > altered the handling somewhat so that we reset the adapter if 
> > > we feel it is taking too long (three minutes) to start up.
> > > > 
> > > > We have not unit tested the reset_devices flag propagation 
> > > to this driver code, nor have we unit tested the check for 
> > > the interrupted operations under the conditions of a naively 
> > > issued kexec. We are submitting this modified driver to our 
> > > Q/A department for integration testing in our current 
> > > programs. I would appreciate an ACK to this patch should it 
> > > resolve the issue described in this thread...
> > > > 
> > > 
> > > Mark; 
> > > 
> > > I am getting an error applying this patch:
> > > 
> > > -bash-3.1# patch -p1 < ../../aacraid_kexec.patch
> > > patching file drivers/scsi/aacraid/rx.c
> > > patch: **** malformed patch at line 36: @@ -526,6 +529,7 @@
> > > 
> > > Do you think you could regenerate it?
> > > 
> > > Thanks;
> > > Judith
> > > 
> > > > ObligatoryDisclaimer: Please accept my condolences 
> > > regarding Outlook's handling of patches.
> > > > 
> > > > This attached patch is against current scsi-misc-2.6
> > > >  
> > > > Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
> > > > 
> > > > ---
> > > > 
> > > > Sincerely -- Mark Salyzyn
> > > > 
> > > > > -----Original Message-----
> > > > > From: Vivek Goyal [mailto:vgoyal@in.ibm.com] 
> > > > > Sent: Friday, March 30, 2007 2:06 AM
> > > > > To: Salyzyn, Mark
> > > > > Cc: Judith Lebzelter; linux-scsi@vger.kernel.org; AACRAID; 
> > > > > fastboot@lists.osdl.org
> > > > > Subject: Re: [Fastboot] Panics for AACRAID driver during 
> > > > > 'insmod' for kexec test.
> > > > > 
> > > > > 
> > > > > On Thu, Mar 29, 2007 at 10:17:18AM -0400, Salyzyn, Mark wrote:
> > > > > > I have been working on a patch to the driver to do just 
> > > > > this, reset the
> > > > > > adapter during init if necessary. We want to limit the 
> > > > > adapter's reset
> > > > > > as it takes time (an additional 45 seconds or longer) for 
> > > > > the Firmware
> > > > > > to cycle... I will bump the priority of the testing for 
> > > this patch.
> > > > > > 
> > > > > Hi,
> > > > > 
> > > > > Thanks for looking into this. You can make device reset 
> > > > > conditional. Now
> > > > > one command line parameter "reset_devices" has been defined 
> > > > > for the kernel.
> > > > > You can reset the device only if the user has passed 
> > > > > reset_devices command
> > > > > line option otherwise you can continue to boot normaly.
> > > > > 
> > > > > I have introduced this parameter to handle the concern 
> > > that in normal
> > > > > BIOS boot total boot time will increase.
> > > > > 
> > > > > kexec/kdump will pass this parameter to second kernel so that 
> > > > > device will
> > > > > be reset during initialization and normal BIOS boot will 
> > > > > reamin unaffected.
> > > > > 
> > > > > Thanks
> > > > > Vivek
> > > > > 
> > > 
> > > 
> > > 
> 
> 
> 

Re: [PATCH] aacraid: Panics for AACRAID driver during 'insmod' for kexec test.

[James Bottomley]

On Fri, 2007-03-30 at 14:48 -0400, Salyzyn, Mark wrote:
> My tree I am working on is 'more advanced' as it includes the series of other patches submitted over the past week :-( We have some interference going on. I suggest pulling this patch until the others have cleared.

It applies OK for me (modulo the first make function static which
already went in) to scsi-misc-2.6

I've put it in scsi-misc-2.6 ... you can either pull it from there or
try -mm in a few days when Andrew refreshes from the maintainer trees.

Mark .. this also alters the way it gets treated ... since it's now on
upstream track, you need to tell me to pull it out if it has any
failures in testing, otherwise it will go into the vanilla kernel in
2.6.21

James