Bug 63908 - Kernel Panic With Adaptec ATA RAID 2400A Controller
Summary: Kernel Panic With Adaptec ATA RAID 2400A Controller
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-21 16:56 UTC by Need Real Name
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:39:31 UTC
Embargoed:


Attachments (Terms of Use)
complete dmesg output (14.95 KB, text/plain)
2002-04-21 16:57 UTC, Need Real Name
no flags Details

Description Need Real Name 2002-04-21 16:56:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326

Description of problem:
Since I added the Adaptec ATA RAID 2400A to the computer, I am getting kernel
panics and some mild FS corruption (an e2fsck will recover the data).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot
2. Wait
3. Kernel panics after about 24 hours.

Additional info:

I have an Adaptec ATA RAID 2400A controller with two 120GB Maxtor drives in
Promise Super Swap chassis configured as a RAID-1 array. The file system (/home)
on the array is ext3fs and is served out by NFS.

The kernel is from the Red Hat 2.4.9-31 RPM. The machine has two 400MHz Pentium
II processors, but I am running the uniprocessor kernel because the SMP kernel
completely hangs (not even magic sysrq can save me) when it panics.

The machine has 576MB of RAM and 1152MB of swap. The swap (and the root file
system) is on a separate, plain old IDE drive.

Here is some relevant text from dmesg:

attempt to access beyond end of device
08:01: rw=2, want=134217732, limit=120053713
EXT3-fs error (device sd(8,1)): ext3_readdir: bad entry in directory #9994481:
directory entry across blocks - offset=504, inode=9994499, rec_len=16408,
name_len=13
Unable to handle kernel NULL pointer dereference at virtual address 000000d2
 printing eip:
000000d2
*pde = 00000000
Oops: 0000
Kernel 2.4.9-31
CPU:    0
EIP:    0010:[<000000d2>]    Not tainted
EFLAGS: 00010206
EIP is at Using_Versions [] 0xd1 
eax: 000000d2   ebx: cfbb7ae0   ecx: c1d973a0   edx: cfb372e0
esi: e07e9f7c   edi: 00000003   ebp: bfffef38   esp: e07e9f28
ds: 0018   es: 0018   ss: 0018
Process updatedb (pid: 2584, stackpage=e07e9000)
Stack: c013d2b1 cfb372e0 cfb372e0 e07e9f48 c013d451 c1d973a0 cfb372e0 e07e9f7c 
       cfb372e0 c1d973a0 3c9d06b4 00000000 004c80c3 00000008 00000001 0805e5dc 
       e07e9f7c 0805e6a4 c013d9b1 0805e684 e07e9f7c 004c80c3 81000801 d0320001 
Call Trace: [<c013d2b1>] do_getattr [kernel] 0x21 
[<c013d451>] vfs_lstat [kernel] 0x31 
[<c013d9b1>] sys_lstat64 [kernel] 0x11 
[<c0106f3b>] system_call [kernel] 0x33

Comment 1 Need Real Name 2002-04-21 16:57:38 UTC
Created attachment 54785 [details]
complete dmesg output

Comment 2 Bugzilla owner 2004-09-30 15:39:31 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/



Note You need to log in before you can comment on or make changes to this bug.