Hi all,
I'm using the cpqarray driver for a Compaq Smart Arrat 3100ES
controller on a Compaq Proliant 7000. Today I tried upgrading the kernel to
2.4.14. Soon after the upgrade I though about making a small change in the
kernel however as soon as I tried doing a "make dep" the system oopsed and
froze. This repeated itself a couple of times. Initially I though it may
have been the ext3 patch which I had tried and I then tried mounting my
drives as ext2 to see if that fixed the problem. It didn't. After writing
down the oops and doing a ksymoops on it I noticed that the kernel appeared
to die in the ida interrupt handler (ida is the device name the cpqarray
driver uses). Remembering that the cpqarray driver had been upgraded in
2.4.14 I decided to try downgrading the cpqarray driver. So I copied the
cpqarray.[ch], ida_cmd.h, and ida_ioctl.h file from drivers/block from a
linux 2.4.13-ac8 source directory I had from the previously working kernel.
I then recompiled the 2.4.14 linux kernel (with ext3 patch) using the
downgraded cpqarray driver source files. The resulting kernel now works
perfectly on this machine. Even doing a higher stress test with make -j 10
didn't cause the crash to occur again. From my investigate I must conclude
the the cpqarray driver included in the 2.4.14 source tarball must be broken
somehow.
Other fact that might be relevent about this machine. This system has
1.5 GB of memory and I am using the 4GB high memory option in the kernel. I
also included the latest ext3 patch as I needed this after moving away from
the ac kernels.
I've attached the oops (typed out by me), the ksymoops output, and my
kernel configuration file. If anyone has anymore questions please ask away,
though I won't have access to this machine again til after the weekend.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--- linux/drivers/block/cciss.c~ Thu Nov 8 11:36:24 2001
+++ linux/drivers/block/cciss.c Thu Nov 8 11:37:03 2001
@@ -1307,6 +1307,8 @@
if (( c = cmd_alloc(h, 1)) == NULL)
goto startio;
+ blkdev_dequeue_request(creq);
+
spin_unlock_irq(&io_request_lock);
c->cmd_type = CMD_RWREQ;
@@ -1386,12 +1388,6 @@
spin_lock_irq(&io_request_lock);
- blkdev_dequeue_request(creq);
-
- /*
- * ehh, we can't really end the request here since it's not
- * even started yet. for now it shouldn't hurt though
- */
addQ(&(h->reqQ),c);
h->Qdepth++;
if(h->Qdepth > h->maxQsinceinit)
Hi,
Thanks a lot for the help. Any particular reason to use the new driver
now or should I just wait until 2.4.15 is release?
Guess I didn't need to do all that debugging. Bug may have already been
caught. 8-)
However I did notice something. The patch you've included below covers
the cciss.c file? My system is using the cpqarray driver. And I fixed the
problem by replacing the cpqarray.[ch], ida_cmd.h, and ida_ioctl.h files. I
don't think the patch below would have done anything for me as I'm pretty
sure the cciss.c file isn't used by the cpqarray driver and since I didn't
change out the cciss.c file in my now working kernel source tree (linux
2.4.14-lkd1 8-D).
----- Original Message -----
From: "J Sloan" <[email protected]>
To: "Linux Kernel Developer" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 08, 2001 10:45 PM
Subject: Re: CPQARRAY driver horribly broken in 2.4.14
> Linux Kernel Developer wrote:
>
> > Hi all,
> >
> > I'm using the cpqarray driver for a Compaq Smart Arrat 3100ES
> > controller on a Compaq Proliant 7000. Today I tried upgrading the
kernel to
> > 2.4.14. Soon after the upgrade I though about making a small change in
the
> > kernel however as soon as I tried doing a "make dep" the system oopsed
and
> > froze.
>
> Been there, done that, bought the t-shirt.
>
> The attached patch courtesy of Jens Axboe
> fixed my Compaq 6500 which was giving me
> fits - basically in 2.4.14 it had a nasty habit of
> scribbling on the disk and then locking up,
> requiring a power cycle, manual fsck and
> file restoration to get it running again.
>
> With this patch 2.4.14 has been solid.
>
> cu
>
> jjs
>
>
>
----------------------------------------------------------------------------
----
> --- linux/drivers/block/cciss.c~ Thu Nov 8 11:36:24 2001
> +++ linux/drivers/block/cciss.c Thu Nov 8 11:37:03 2001
> @@ -1307,6 +1307,8 @@
> if (( c = cmd_alloc(h, 1)) == NULL)
> goto startio;
>
> + blkdev_dequeue_request(creq);
> +
> spin_unlock_irq(&io_request_lock);
>
> c->cmd_type = CMD_RWREQ;
> @@ -1386,12 +1388,6 @@
>
> spin_lock_irq(&io_request_lock);
>
> - blkdev_dequeue_request(creq);
> -
> - /*
> - * ehh, we can't really end the request here since it's not
> - * even started yet. for now it shouldn't hurt though
> - */
> addQ(&(h->reqQ),c);
> h->Qdepth++;
> if(h->Qdepth > h->maxQsinceinit)
>
On Fri, Nov 09 2001, Linux Kernel Developer wrote:
> Hi,
>
> Thanks a lot for the help. Any particular reason to use the new driver
> now or should I just wait until 2.4.15 is release?
>
> Guess I didn't need to do all that debugging. Bug may have already been
> caught. 8-)
>
> However I did notice something. The patch you've included below covers
> the cciss.c file? My system is using the cpqarray driver. And I fixed the
> problem by replacing the cpqarray.[ch], ida_cmd.h, and ida_ioctl.h files. I
> don't think the patch below would have done anything for me as I'm pretty
> sure the cciss.c file isn't used by the cpqarray driver and since I didn't
> change out the cciss.c file in my now working kernel source tree (linux
> 2.4.14-lkd1 8-D).
You needed the cciss equivalent of the one posted, attached.
--
Jens Axboe