Looks to me like a race condition somewhere is unmapping
a page before raid0 is finished with it.
Also, what you *don't* see, is that writes to raid0 drives
may be silently corrupted. Not too frequent, but happens
enough to ruin some every now and then.
To reproduce the Ooops, just create a dual-drive RAID0
(I used cfdisk to create 128MB partitions), and then do:
mke2fs /dev/md0
mkdir /u
mount /dev/md0 /u
cp /dev/zero /u
od -x /u/zero <-- dies with Ooops.
I have seen a report of this RAID0 Ooops on an all-SCSI system,
and on my own SCSI-free system, so it's probably not a disk-driver bug.
Interestingly, RAID0 had *never* worked reliably for me, until about
three months ago in the 2.1.xxx stream. Now it's back to the old ways..
-ml
Nick wrote:
>
> For the past week, I've been having solid lockups on a SMP box here at
> work. This server has been running 2.1.x SMP since 2.1.90 with success
> and now since 2.1.127 it's been locking up at least twice a day.
>
> All that gets printed on the screen is:
>
> Unable to handle NULL kernel pointer dereference_
>
> And the cursor is stuck at the _ character.
>
> The box is used as a news server and is running inn-2.2b since yesterday,
> prior it was running inn-2.1
>
> The setup is this:
>
> Asus P2L97D w/ 256MB RAM
> 2 x Pentium2 266Mhz
> SYM53C875 Controller
> 3 * 9GB Harddrives in Raid-0
> Kingston KNE-100TX Tulip card
>
> The kernel is using:
> V0.90 of tulip.c
> V 0.15 of pre-sym53C8XX driver
> Raid0145-19981110-2.1.127
>
> Any help or hints would be appreciated in solving this matter!
>
> Cheers,
>
> Nick
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-- mlord@pobox.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/