RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-04 Thread Duane Cox
By bad... 'interrpt' typo

-Original Message-
From: Duane Cox 
Sent: Monday, April 02, 2007 3:04 PM
To: 'Salyzyn, Mark'; Judith Lebzelter
Cc: James Bottomley; linux-scsi@vger.kernel.org
Subject: RE: [PATCH] aacraid: Panics during init time reset (Was:
[PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod'
for kexec test)

Attempted to compile 2.6.20.3 kernel results in...

   CC  drivers/scsi/aacraid/rx.o
drivers/scsi/aacraid/rx.c: In function '_aac_rx_init':
drivers/scsi/aacraid/rx.c:869: error: 'aac_rx_disable_interrpt'
undeclared (first use in this function)
drivers/scsi/aacraid/rx.c:869: error: (Each undeclared identifier is
reported only once
drivers/scsi/aacraid/rx.c:869: error: for each function it appears in.)
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

-Original Message-
From: Salyzyn, Mark [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 2:57 PM
To: Judith Lebzelter
Cc: James Bottomley; linux-scsi@vger.kernel.org; Duane Cox
Subject: RE: [PATCH] aacraid: Panics during init time reset (Was:
[PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod'
for kexec test)

Judith, another layer on this onion also discovered by Duane, the
interrupt enable handler also needed to be set ... The interrupt enable
was called from within the synchronous command handler.

My private email with the fix was sent a whole 5 minutes ahead of yours
;-> Here is the jist of it for the observers:

/* Failure to reset here is an option ... */
dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
+   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
dev->OIMR = status = rx_readb (dev, MUnit.OIMR);

Yes, the disable interrupt method patched into the enable int platform
function. Later init code will reset it accordingly.

Sincerely -- Mark Salyzyn


> -Original Message-
> From: Judith Lebzelter [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 02, 2007 3:44 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; James Bottomley; linux-scsi@vger.kernel.org; 
> Duane Cox
> Subject: Re: [PATCH] aacraid: Panics during init time reset
> (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 
> 'insmod' for kexec test)
> 
> 
> On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > Duane discovered in the scsi-misc-2.6 code that the reset
> handler could
> > be called without the sync command handler set up resulting
> in a panic.
> > Judith discovered this issue within minutes and has
> recently reported
> > it. Here is a fix.
> 
> Mark,
> 
> I applied this patch and ran a kexec test again and I still got a
> panic:
> 
> Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M ko module^M
> ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level,
> low) -> IRQ 3^M Unable to handle kernel NULL pointer dereference at 
>  RIP: ^M  [<>]^M PGD 4791067 PUD
> 473c067 PMD 0 ^M
> Oops: 0010 [1] ^M
> CPU 0 ^M
> Modules linked in: aacraid^M
> Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> RIP: 0010:[<>]  [<>]^M
> RSP: :81000474dbf0  EFLAGS: 00010246^M
> RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M
> RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M
> RBP: fffee138 R08: 81001c20 R09: 8143593e^M
> R10: 810004c537a0 R11:  R12: 81000474dc7c^M
> R13:  R14:  R15: ^M
> FS:  0057b850(0063) GS:814d6000() 
> knlGS:^M
> CS:  0010 DS:  ES:  CR0: 8005003b^M
> CR2:  CR3: 04745000 CR4: 06e0^M 
> Process insmod (pid: 977, threadinfo 81000474c000, task 
> 81000443cf40)^M
> Stack:  88008e82 3e00fc1f  
> 810004fe4cd8^M  810004fe4800  8800a6dd

> 0032^M  88008c3b  

> 81000474dc7c^M Call Trace:^M  [] 
> :aacraid:rx_sync_cmd+0x15c/0x16a^M
>  [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
>  [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
>  [] :aacraid:aac_probe_one+0x1a2/0x457^M
>  [] pci_device_probe+0x4c/0x75^M 
> [] really_probe+0xc4/0x148^M  [] 
> __driver_attach+0x6d/0xab^M  [] 
> __driver_attach+0x0/0xab^M  [] 
> __driver_attach+0x0/0xab^M  [] 
> bus_for_each_dev+0x43/0x6e^M  [] 
> bus_add_driver+0x6b/0x18d^M  [] 
> __pci_register_driver+0x72/0xa7^M  [] 
> :aacraid:aac_init+0x3a/0x75^M  [] 
> sys_init_module+0x1195/0

RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-04 Thread Duane Cox
Attempted to compile 2.6.20.3 kernel results in...

   CC  drivers/scsi/aacraid/rx.o
drivers/scsi/aacraid/rx.c: In function '_aac_rx_init':
drivers/scsi/aacraid/rx.c:869: error: 'aac_rx_disable_interrpt'
undeclared (first use in this function)
drivers/scsi/aacraid/rx.c:869: error: (Each undeclared identifier is
reported only once
drivers/scsi/aacraid/rx.c:869: error: for each function it appears in.)
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

-Original Message-
From: Salyzyn, Mark [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 02, 2007 2:57 PM
To: Judith Lebzelter
Cc: James Bottomley; linux-scsi@vger.kernel.org; Duane Cox
Subject: RE: [PATCH] aacraid: Panics during init time reset (Was:
[PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod'
for kexec test)

Judith, another layer on this onion also discovered by Duane, the
interrupt enable handler also needed to be set ... The interrupt enable
was called from within the synchronous command handler.

My private email with the fix was sent a whole 5 minutes ahead of yours
;-> Here is the jist of it for the observers:

/* Failure to reset here is an option ... */
dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
+   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
dev->OIMR = status = rx_readb (dev, MUnit.OIMR);

Yes, the disable interrupt method patched into the enable int platform
function. Later init code will reset it accordingly.

Sincerely -- Mark Salyzyn


> -Original Message-
> From: Judith Lebzelter [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 02, 2007 3:44 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; James Bottomley; linux-scsi@vger.kernel.org; 
> Duane Cox
> Subject: Re: [PATCH] aacraid: Panics during init time reset
> (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 
> 'insmod' for kexec test)
> 
> 
> On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > Duane discovered in the scsi-misc-2.6 code that the reset
> handler could
> > be called without the sync command handler set up resulting
> in a panic.
> > Judith discovered this issue within minutes and has
> recently reported
> > it. Here is a fix.
> 
> Mark,
> 
> I applied this patch and ran a kexec test again and I still got a 
> panic:
> 
> Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M ko module^M
> ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, 
> low) -> IRQ 3^M Unable to handle kernel NULL pointer dereference at 
>  RIP: ^M  [<>]^M PGD 4791067 PUD 
> 473c067 PMD 0 ^M
> Oops: 0010 [1] ^M
> CPU 0 ^M
> Modules linked in: aacraid^M
> Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> RIP: 0010:[<>]  [<>]^M
> RSP: :81000474dbf0  EFLAGS: 00010246^M
> RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M
> RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M
> RBP: fffee138 R08: 81001c20 R09: 8143593e^M
> R10: 810004c537a0 R11:  R12: 81000474dc7c^M
> R13:  R14:  R15: ^M
> FS:  0057b850(0063) GS:814d6000() 
> knlGS:^M
> CS:  0010 DS:  ES:  CR0: 8005003b^M
> CR2:  CR3: 04745000 CR4: 06e0^M 
> Process insmod (pid: 977, threadinfo 81000474c000, task 
> 81000443cf40)^M
> Stack:  88008e82 3e00fc1f  
> 810004fe4cd8^M  810004fe4800  8800a6dd

> 0032^M  88008c3b  

> 81000474dc7c^M Call Trace:^M  [] 
> :aacraid:rx_sync_cmd+0x15c/0x16a^M
>  [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
>  [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
>  [] :aacraid:aac_probe_one+0x1a2/0x457^M
>  [] pci_device_probe+0x4c/0x75^M  
> [] really_probe+0xc4/0x148^M  [] 
> __driver_attach+0x6d/0xab^M  [] 
> __driver_attach+0x0/0xab^M  [] 
> __driver_attach+0x0/0xab^M  [] 
> bus_for_each_dev+0x43/0x6e^M  [] 
> bus_add_driver+0x6b/0x18d^M  [] 
> __pci_register_driver+0x72/0xa7^M  [] 
> :aacraid:aac_init+0x3a/0x75^M  [] 
> sys_init_module+0x1195/0x12e6^M  [] 
> system_call+0x7e/0x83^M ^M ^M
> Code:  Bad RIP value.^M
> RIP  [<>]^M
>  RSP ^M
> CR2: ^M
> 
> There is an extra line in the call trace for the 'rx_sync_cmd'.
> 
> Judith
> 
> > 
> > IMHO, this needs to be applied immediately regardless of
> the status of
> > 

Re: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Judith Lebzelter
On Mon, Apr 02, 2007 at 04:29:35PM -0400, Salyzyn, Mark wrote:
> Cool! Look forward to your results.
> 
> Sorry for being so snitty sounding with the 5 minute comment, I was just
> admiring the pace of activity!

No problem.  I thought it was funny.:)

Judith
> 
> Sincerely -- Mark Salyzyn
> 
> > -Original Message-
> > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, April 02, 2007 4:17 PM
> > To: Salyzyn, Mark
> > Cc: Judith Lebzelter; James Bottomley; 
> > linux-scsi@vger.kernel.org; Duane Cox
> > Subject: Re: [PATCH] aacraid: Panics during init time reset 
> > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> > during 'insmod' for kexec test)
> > 
> > 
> > On Mon, Apr 02, 2007 at 03:56:50PM -0400, Salyzyn, Mark wrote:
> > > Judith, another layer on this onion also discovered by Duane, the
> > > interrupt enable handler also needed to be set ... The 
> > interrupt enable
> > > was called from within the synchronous command handler.
> > > 
> > > My private email with the fix was sent a whole 5 minutes 
> > ahead of yours
> > > ;-> Here is the jist of it for the observers:
> > 
> > I saw it the second I hit 'submit'.
> > 
> > > 
> > > /* Failure to reset here is an option ... */
> > > dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
> > > +   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
> > > dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
> > > 
> > > Yes, the disable interrupt method patched into the enable 
> > int platform
> > > function. Later init code will reset it accordingly.
> > > 
> > > Sincerely -- Mark Salyzyn
> > 
> > Yes, that works now.  I will run a series to check if the 
> > other IRQ interrupt 
> > problem is resolved.
> > 
> > Judith
> > 
> > > 
> > > 
> > > > -----Original Message-
> > > > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> > > > Sent: Monday, April 02, 2007 3:44 PM
> > > > To: Salyzyn, Mark
> > > > Cc: Judith Lebzelter; James Bottomley; 
> > > > linux-scsi@vger.kernel.org; Duane Cox
> > > > Subject: Re: [PATCH] aacraid: Panics during init time reset 
> > > > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> > > > during 'insmod' for kexec test)
> > > > 
> > > > 
> > > > On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > > > > Duane discovered in the scsi-misc-2.6 code that the reset 
> > > > handler could
> > > > > be called without the sync command handler set up resulting 
> > > > in a panic.
> > > > > Judith discovered this issue within minutes and has 
> > > > recently reported
> > > > > it. Here is a fix.
> > > > 
> > > > Mark,
> > > > 
> > > > I applied this patch and ran a kexec test again and I still 
> > > > got a panic:
> > > > 
> > > > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> > > > ko module^M
> > > > ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 
> > > > (level, low) -> IRQ 3^M
> > > > Unable to handle kernel NULL pointer dereference at 
> > > >  RIP: ^M
> > > >  [<>]^M
> > > > PGD 4791067 PUD 473c067 PMD 0 ^M
> > > > Oops: 0010 [1] ^M
> > > > CPU 0 ^M
> > > > Modules linked in: aacraid^M
> > > > Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> > > > RIP: 0010:[<>]  [<>]^M
> > > > RSP: :81000474dbf0  EFLAGS: 00010246^M
> > > > RAX: c201 RBX: 810004fe4cd8 RCX: 
> > 5b540e96^M
> > > > RDX: c201 RSI: 81000443cf40 RDI: 
> > 810004fe4cd8^M
> > > > RBP: fffee138 R08: 81001c20 R09: 
> > 8143593e^M
> > > > R10: 810004c537a0 R11:  R12: 
> > 81000474dc7c^M
> > > > R13:  R14:  R15: 
> > ^M
> > > > FS:  0057b850(0063) GS:814d6000() 
> > > > knlGS:^M
> > > > CS:  0010 DS:  ES:  CR0: 8005003b^M
> > > > CR2:  CR3: 04745000 CR4: 
> > 0

RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Salyzyn, Mark
Cool! Look forward to your results.

Sorry for being so snitty sounding with the 5 minute comment, I was just
admiring the pace of activity!

Sincerely -- Mark Salyzyn

> -Original Message-
> From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 02, 2007 4:17 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; James Bottomley; 
> linux-scsi@vger.kernel.org; Duane Cox
> Subject: Re: [PATCH] aacraid: Panics during init time reset 
> (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> during 'insmod' for kexec test)
> 
> 
> On Mon, Apr 02, 2007 at 03:56:50PM -0400, Salyzyn, Mark wrote:
> > Judith, another layer on this onion also discovered by Duane, the
> > interrupt enable handler also needed to be set ... The 
> interrupt enable
> > was called from within the synchronous command handler.
> > 
> > My private email with the fix was sent a whole 5 minutes 
> ahead of yours
> > ;-> Here is the jist of it for the observers:
> 
> I saw it the second I hit 'submit'.
> 
> > 
> > /* Failure to reset here is an option ... */
> > dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
> > +   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
> > dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
> > 
> > Yes, the disable interrupt method patched into the enable 
> int platform
> > function. Later init code will reset it accordingly.
> > 
> > Sincerely -- Mark Salyzyn
> 
> Yes, that works now.  I will run a series to check if the 
> other IRQ interrupt 
> problem is resolved.
> 
> Judith
> 
> > 
> > 
> > > -Original Message-
> > > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> > > Sent: Monday, April 02, 2007 3:44 PM
> > > To: Salyzyn, Mark
> > > Cc: Judith Lebzelter; James Bottomley; 
> > > linux-scsi@vger.kernel.org; Duane Cox
> > > Subject: Re: [PATCH] aacraid: Panics during init time reset 
> > > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> > > during 'insmod' for kexec test)
> > > 
> > > 
> > > On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > > > Duane discovered in the scsi-misc-2.6 code that the reset 
> > > handler could
> > > > be called without the sync command handler set up resulting 
> > > in a panic.
> > > > Judith discovered this issue within minutes and has 
> > > recently reported
> > > > it. Here is a fix.
> > > 
> > > Mark,
> > > 
> > > I applied this patch and ran a kexec test again and I still 
> > > got a panic:
> > > 
> > > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> > > ko module^M
> > > ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 
> > > (level, low) -> IRQ 3^M
> > > Unable to handle kernel NULL pointer dereference at 
> > >  RIP: ^M
> > >  [<>]^M
> > > PGD 4791067 PUD 473c067 PMD 0 ^M
> > > Oops: 0010 [1] ^M
> > > CPU 0 ^M
> > > Modules linked in: aacraid^M
> > > Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> > > RIP: 0010:[<>]  [<>]^M
> > > RSP: :81000474dbf0  EFLAGS: 00010246^M
> > > RAX: c201 RBX: 810004fe4cd8 RCX: 
> 5b540e96^M
> > > RDX: c201 RSI: 81000443cf40 RDI: 
> 810004fe4cd8^M
> > > RBP: fffee138 R08: 81001c20 R09: 
> 8143593e^M
> > > R10: 810004c537a0 R11:  R12: 
> 81000474dc7c^M
> > > R13:  R14:  R15: 
> ^M
> > > FS:  0057b850(0063) GS:814d6000() 
> > > knlGS:^M
> > > CS:  0010 DS:  ES:  CR0: 8005003b^M
> > > CR2:  CR3: 04745000 CR4: 
> 06e0^M
> > > Process insmod (pid: 977, threadinfo 81000474c000, task 
> > > 81000443cf40)^M
> > > Stack:  88008e82 3e00fc1f  
> > > 810004fe4cd8^M
> > >  810004fe4800  8800a6dd 
> 0032^M
> > >  88008c3b   
> 81000474dc7c^M
> > > Call Trace:^M
> > >  [] :aacraid:rx_sync_cmd+0x15c/0x16a^M
> > >  [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
> > >  [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
> > >  [

Re: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Judith Lebzelter
On Mon, Apr 02, 2007 at 03:56:50PM -0400, Salyzyn, Mark wrote:
> Judith, another layer on this onion also discovered by Duane, the
> interrupt enable handler also needed to be set ... The interrupt enable
> was called from within the synchronous command handler.
> 
> My private email with the fix was sent a whole 5 minutes ahead of yours
> ;-> Here is the jist of it for the observers:

I saw it the second I hit 'submit'.

> 
> /* Failure to reset here is an option ... */
> dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
> +   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
> dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
> 
> Yes, the disable interrupt method patched into the enable int platform
> function. Later init code will reset it accordingly.
> 
> Sincerely -- Mark Salyzyn

Yes, that works now.  I will run a series to check if the other IRQ interrupt 
problem is resolved.

Judith

> 
> 
> > -Original Message-
> > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, April 02, 2007 3:44 PM
> > To: Salyzyn, Mark
> > Cc: Judith Lebzelter; James Bottomley; 
> > linux-scsi@vger.kernel.org; Duane Cox
> > Subject: Re: [PATCH] aacraid: Panics during init time reset 
> > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> > during 'insmod' for kexec test)
> > 
> > 
> > On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > > Duane discovered in the scsi-misc-2.6 code that the reset 
> > handler could
> > > be called without the sync command handler set up resulting 
> > in a panic.
> > > Judith discovered this issue within minutes and has 
> > recently reported
> > > it. Here is a fix.
> > 
> > Mark,
> > 
> > I applied this patch and ran a kexec test again and I still 
> > got a panic:
> > 
> > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> > ko module^M
> > ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 
> > (level, low) -> IRQ 3^M
> > Unable to handle kernel NULL pointer dereference at 
> >  RIP: ^M
> >  [<>]^M
> > PGD 4791067 PUD 473c067 PMD 0 ^M
> > Oops: 0010 [1] ^M
> > CPU 0 ^M
> > Modules linked in: aacraid^M
> > Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> > RIP: 0010:[<>]  [<>]^M
> > RSP: :81000474dbf0  EFLAGS: 00010246^M
> > RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M
> > RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M
> > RBP: fffee138 R08: 81001c20 R09: 8143593e^M
> > R10: 810004c537a0 R11:  R12: 81000474dc7c^M
> > R13:  R14:  R15: ^M
> > FS:  0057b850(0063) GS:814d6000() 
> > knlGS:^M
> > CS:  0010 DS:  ES:  CR0: 8005003b^M
> > CR2:  CR3: 04745000 CR4: 06e0^M
> > Process insmod (pid: 977, threadinfo 81000474c000, task 
> > 81000443cf40)^M
> > Stack:  88008e82 3e00fc1f  
> > 810004fe4cd8^M
> >  810004fe4800  8800a6dd 0032^M
> >  88008c3b   81000474dc7c^M
> > Call Trace:^M
> >  [] :aacraid:rx_sync_cmd+0x15c/0x16a^M
> >  [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
> >  [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
> >  [] :aacraid:aac_probe_one+0x1a2/0x457^M
> >  [] pci_device_probe+0x4c/0x75^M
> >  [] really_probe+0xc4/0x148^M
> >  [] __driver_attach+0x6d/0xab^M
> >  [] __driver_attach+0x0/0xab^M
> >  [] __driver_attach+0x0/0xab^M
> >  [] bus_for_each_dev+0x43/0x6e^M
> >  [] bus_add_driver+0x6b/0x18d^M
> >  [] __pci_register_driver+0x72/0xa7^M
> >  [] :aacraid:aac_init+0x3a/0x75^M
> >  [] sys_init_module+0x1195/0x12e6^M
> >  [] system_call+0x7e/0x83^M
> > ^M
> > ^M
> > Code:  Bad RIP value.^M
> > RIP  [<>]^M
> >  RSP ^M
> > CR2: ^M
> > 
> > There is an extra line in the call trace for the 'rx_sync_cmd'.
> > 
> > Judith
> > 
> > > 
> > > IMHO, this needs to be applied immediately regardless of 
> > the status of
> > > the kexec patch as this issue is present in the 
> > scsi-misc-2.6 driver for
> > > all existing init-time recovery actions. This patch in 
> > principal would
> > > not be different w/o the kexec patch.
> > > 
> > > 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 <[EMAIL PROTECTED]>
> > > 
> > > ---
> > > 
> > > Sincerely -- Mark Salyzyn
> > 
> > 
> > 
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Salyzyn, Mark
Judith, another layer on this onion also discovered by Duane, the
interrupt enable handler also needed to be set ... The interrupt enable
was called from within the synchronous command handler.

My private email with the fix was sent a whole 5 minutes ahead of yours
;-> Here is the jist of it for the observers:

/* Failure to reset here is an option ... */
dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
+   dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
dev->OIMR = status = rx_readb (dev, MUnit.OIMR);

Yes, the disable interrupt method patched into the enable int platform
function. Later init code will reset it accordingly.

Sincerely -- Mark Salyzyn


> -Original Message-
> From: Judith Lebzelter [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 02, 2007 3:44 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; James Bottomley; 
> linux-scsi@vger.kernel.org; Duane Cox
> Subject: Re: [PATCH] aacraid: Panics during init time reset 
> (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver 
> during 'insmod' for kexec test)
> 
> 
> On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> > Duane discovered in the scsi-misc-2.6 code that the reset 
> handler could
> > be called without the sync command handler set up resulting 
> in a panic.
> > Judith discovered this issue within minutes and has 
> recently reported
> > it. Here is a fix.
> 
> Mark,
> 
> I applied this patch and ran a kexec test again and I still 
> got a panic:
> 
> Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
> ko module^M
> ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 
> (level, low) -> IRQ 3^M
> Unable to handle kernel NULL pointer dereference at 
>  RIP: ^M
>  [<>]^M
> PGD 4791067 PUD 473c067 PMD 0 ^M
> Oops: 0010 [1] ^M
> CPU 0 ^M
> Modules linked in: aacraid^M
> Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
> RIP: 0010:[<>]  [<>]^M
> RSP: :81000474dbf0  EFLAGS: 00010246^M
> RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M
> RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M
> RBP: fffee138 R08: 81001c20 R09: 8143593e^M
> R10: 810004c537a0 R11:  R12: 81000474dc7c^M
> R13:  R14:  R15: ^M
> FS:  0057b850(0063) GS:814d6000() 
> knlGS:^M
> CS:  0010 DS:  ES:  CR0: 8005003b^M
> CR2:  CR3: 04745000 CR4: 06e0^M
> Process insmod (pid: 977, threadinfo 81000474c000, task 
> 81000443cf40)^M
> Stack:  88008e82 3e00fc1f  
> 810004fe4cd8^M
>  810004fe4800  8800a6dd 0032^M
>  88008c3b   81000474dc7c^M
> Call Trace:^M
>  [] :aacraid:rx_sync_cmd+0x15c/0x16a^M
>  [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
>  [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
>  [] :aacraid:aac_probe_one+0x1a2/0x457^M
>  [] pci_device_probe+0x4c/0x75^M
>  [] really_probe+0xc4/0x148^M
>  [] __driver_attach+0x6d/0xab^M
>  [] __driver_attach+0x0/0xab^M
>  [] __driver_attach+0x0/0xab^M
>  [] bus_for_each_dev+0x43/0x6e^M
>  [] bus_add_driver+0x6b/0x18d^M
>  [] __pci_register_driver+0x72/0xa7^M
>  [] :aacraid:aac_init+0x3a/0x75^M
>  [] sys_init_module+0x1195/0x12e6^M
>  [] system_call+0x7e/0x83^M
> ^M
> ^M
> Code:  Bad RIP value.^M
> RIP  [<>]^M
>  RSP ^M
> CR2: ^M
> 
> There is an extra line in the call trace for the 'rx_sync_cmd'.
> 
> Judith
> 
> > 
> > IMHO, this needs to be applied immediately regardless of 
> the status of
> > the kexec patch as this issue is present in the 
> scsi-misc-2.6 driver for
> > all existing init-time recovery actions. This patch in 
> principal would
> > not be different w/o the kexec patch.
> > 
> > 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 <[EMAIL PROTECTED]>
> > 
> > ---
> > 
> > Sincerely -- Mark Salyzyn
> 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Judith Lebzelter
On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote:
> Duane discovered in the scsi-misc-2.6 code that the reset handler could
> be called without the sync command handler set up resulting in a panic.
> Judith discovered this issue within minutes and has recently reported
> it. Here is a fix.

Mark,

I applied this patch and ran a kexec test again and I still 
got a panic:

Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M
ko module^M
ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> IRQ 
3^M
Unable to handle kernel NULL pointer dereference at  RIP: ^M
 [<>]^M
PGD 4791067 PUD 473c067 PMD 0 ^M
Oops: 0010 [1] ^M
CPU 0 ^M
Modules linked in: aacraid^M
Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M
RIP: 0010:[<>]  [<>]^M
RSP: :81000474dbf0  EFLAGS: 00010246^M
RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M
RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M
RBP: fffee138 R08: 81001c20 R09: 8143593e^M
R10: 810004c537a0 R11:  R12: 81000474dc7c^M
R13:  R14:  R15: ^M
FS:  0057b850(0063) GS:814d6000() knlGS:^M
CS:  0010 DS:  ES:  CR0: 8005003b^M
CR2:  CR3: 04745000 CR4: 06e0^M
Process insmod (pid: 977, threadinfo 81000474c000, task 81000443cf40)^M
Stack:  88008e82 3e00fc1f  810004fe4cd8^M
 810004fe4800  8800a6dd 0032^M
 88008c3b   81000474dc7c^M
Call Trace:^M
 [] :aacraid:rx_sync_cmd+0x15c/0x16a^M
 [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M
 [] :aacraid:_aac_rx_init+0x7b/0x2fc^M
 [] :aacraid:aac_probe_one+0x1a2/0x457^M
 [] pci_device_probe+0x4c/0x75^M
 [] really_probe+0xc4/0x148^M
 [] __driver_attach+0x6d/0xab^M
 [] __driver_attach+0x0/0xab^M
 [] __driver_attach+0x0/0xab^M
 [] bus_for_each_dev+0x43/0x6e^M
 [] bus_add_driver+0x6b/0x18d^M
 [] __pci_register_driver+0x72/0xa7^M
 [] :aacraid:aac_init+0x3a/0x75^M
 [] sys_init_module+0x1195/0x12e6^M
 [] system_call+0x7e/0x83^M
^M
^M
Code:  Bad RIP value.^M
RIP  [<>]^M
 RSP ^M
CR2: ^M

There is an extra line in the call trace for the 'rx_sync_cmd'.

Judith

> 
> IMHO, this needs to be applied immediately regardless of the status of
> the kexec patch as this issue is present in the scsi-misc-2.6 driver for
> all existing init-time recovery actions. This patch in principal would
> not be different w/o the kexec patch.
> 
> 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 <[EMAIL PROTECTED]>
> 
> ---
> 
> Sincerely -- Mark Salyzyn


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)

2007-04-02 Thread Salyzyn, Mark
Duane discovered in the scsi-misc-2.6 code that the reset handler could
be called without the sync command handler set up resulting in a panic.
Judith discovered this issue within minutes and has recently reported
it. Here is a fix.

IMHO, this needs to be applied immediately regardless of the status of
the kexec patch as this issue is present in the scsi-misc-2.6 driver for
all existing init-time recovery actions. This patch in principal would
not be different w/o the kexec patch.

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 <[EMAIL PROTECTED]>

---

Sincerely -- Mark Salyzyn


aacraid_kexec_2.patch
Description: aacraid_kexec_2.patch


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

2007-04-01 Thread 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


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2007-03-30 Thread 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:[EMAIL PROTECTED] 
> Sent: Friday, March 30, 2007 2:38 PM
> To: Salyzyn, Mark
> Cc: Judith Lebzelter; [EMAIL PROTECTED]; 
> 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:[EMAIL PROTECTED] 
> > > Sent: Friday, March 30, 2007 1:10 PM
> > > To: Salyzyn, Mark
> > > Cc: [EMAIL PROTECTED]; 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 agains

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

2007-03-30 Thread 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:[EMAIL PROTECTED] 
> > Sent: Friday, March 30, 2007 1:10 PM
> > To: Salyzyn, Mark
> > Cc: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]>
> > > 
> > > ---
> > > 
> > > Sincerely -- Mark Salyzyn
> > > 
> > > > -Original Message-
> > > > From: Vivek Goyal [mailto:[EMAIL PROTECTED] 
> > > > 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
> > > > >

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

2007-03-30 Thread Salyzyn, Mark
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:[EMAIL PROTECTED] 
> Sent: Friday, March 30, 2007 1:10 PM
> To: Salyzyn, Mark
> Cc: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]>
> > 
> > ---
> > 
> > Sincerely -- Mark Salyzyn
> > 
> > > -Original Message-
> > > From: Vivek Goyal [mailto:[EMAIL PROTECTED] 
> > > 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
> > > 
> 
> 
> 


aacraid_kexec.patch
Description: aacraid_kexec.patch


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

2007-03-30 Thread 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 <[EMAIL PROTECTED]>
> 
> ---
> 
> Sincerely -- Mark Salyzyn
> 
> > -Original Message-
> > From: Vivek Goyal [mailto:[EMAIL PROTECTED] 
> > 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
> > 


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2007-03-30 Thread Salyzyn, Mark
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 <[EMAIL PROTECTED]>

---

Sincerely -- Mark Salyzyn

> -Original Message-
> From: Vivek Goyal [mailto:[EMAIL PROTECTED] 
> 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
> 


aacraid_kexec.patch
Description: aacraid_kexec.patch


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

2007-03-29 Thread 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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2007-03-29 Thread 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:[EMAIL PROTECTED] 
> 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 :03:0e.0[A] -> Link [LNKC] -> GSI 3 
> (level, low) -> IRQ 3^M
> > general protection fault:  [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:[]  [] 
> :aacraid:aac_intr_normal+0x17a/0x1b1^M
> > RSP: :81523ed8  EFLAGS: 00010006^M
> > RAX: 810004102000 RBX: 8100014f01e0 RCX: 0086^M
> > RDX: 810004041540 RSI: 8100014f01e0 RDI: ^M
> > RBP: 810004702cd8 R08: a6037e6c R09: 0016001562d7^M
> > R10: 0023 R11:  R12: 0011^M
> > R13: 810004702cd8 R14: 810004001400 R15: ^M
> > FS:  () GS:814d5000() 
> knlGS:^M
> > CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b^M
> > CR2: 006ba5a0 CR3: 0474d000 CR4: 06e0^M
> > Process swapper (pid: 0, threadinfo 814e4000, task 
> 81470360)^M
> > Stack:  0011 810004702cd8 0100 
> 0003^M
> >  0001 88009470  
> 810004041540^M
> >  814d5080 810428f4  
> 814d5080^M
> > Call Trace:^M
> >[] 
> :aacraid:aac_rx_intr_message+0x2c/0x60^M
> >  [] note_interrupt+0xd3/0x1db^M
> >  [] handle_level_irq+0x7e/0xab^M
> >  [] do_IRQ+0xd7/0x132^M
> >  [] mwait_idle+0x0/0x43^M
> >  [] ret_from_intr+0x0/0xa^M
> >[] mwait_idle+0x3f/0x43^M
> >  [] cpu_idle+0x3d/0x5c^M
> >  [] start_kernel+0x28f/0x29b^M
> >  [] _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  [] :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
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2007-03-28 Thread 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 :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, low) -> 
> IRQ 3^M
> general protection fault:  [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:[]  [] 
> :aacraid:aac_intr_normal+0x17a/0x1b1^M
> RSP: :81523ed8  EFLAGS: 00010006^M
> RAX: 810004102000 RBX: 8100014f01e0 RCX: 0086^M
> RDX: 810004041540 RSI: 8100014f01e0 RDI: ^M
> RBP: 810004702cd8 R08: a6037e6c R09: 0016001562d7^M
> R10: 0023 R11:  R12: 0011^M
> R13: 810004702cd8 R14: 810004001400 R15: ^M
> FS:  () GS:814d5000() knlGS:^M
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b^M
> CR2: 006ba5a0 CR3: 0474d000 CR4: 06e0^M
> Process swapper (pid: 0, threadinfo 814e4000, task 81470360)^M
> Stack:  0011 810004702cd8 0100 0003^M
>  0001 88009470  810004041540^M
>  814d5080 810428f4  814d5080^M
> Call Trace:^M
>[] :aacraid:aac_rx_intr_message+0x2c/0x60^M
>  [] note_interrupt+0xd3/0x1db^M
>  [] handle_level_irq+0x7e/0xab^M
>  [] do_IRQ+0xd7/0x132^M
>  [] mwait_idle+0x0/0x43^M
>  [] ret_from_intr+0x0/0xa^M
>[] mwait_idle+0x3f/0x43^M
>  [] cpu_idle+0x3d/0x5c^M
>  [] start_kernel+0x28f/0x29b^M
>  [] _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  [] :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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html