paging oops with 2.4.20-rc2

I'm experiencing frequent oops when doing much of anything cpu/memory/disk intensive. I've yet to get through a kernel compilation on this machine.

The hardware is a new kt400 based motherboard (Gigabyte GA-7VAX with VIA chipset)with an athlon XP. I upgraded to 2.4.20-rc2 in order to get DMA support for the VIA 8235 chipset, and that appears to work. However, this version did introduce frequent oops(as shown below), all involving kernel paging requests. I've included a ksymoops processed log below. Please let me know if you need more information, as this is the first kernel bug report I've made.

Some notable things about the machine:
1)Every partition is reiserfs 3.6
2) Every partition except /boot is on a software raid-0 + LVM setup.

Thanks
-Tupshin

Unable to handle kernel paging request at virtual address db7c7cd8
c01a76f9
*pde = 1b40e9e3
Oops: 0009
CPU:    0
EIP:    0010:[do_journal_end+1513/2720]    Not tainted
EFLAGS: 00010206
eax: db7c7cc0   ebx: 00000024   ecx: d572b000   edx: 8005003b
esi: d6f1e000   edi: d572b000   ebp: e0bb41a8   esp: c15b5f3c
ds: 0018   es: 0018   ss: 0018
Process kupdated (pid: 6, stackpage=c15b5000)
Stack: c15b5fa0 df5dec00 0000001f 3ddd5019 00002c98 00000004 00000002 00000000
      000000c5 000000e8 00000bd4 d5969140 d5712440 d554b000 d5968000 
e0b9db10
      c01a6b0f c15b5fa0 df5dec00 00000001 00000006 df5dec00 df5dec44 
c15b424b
Call Trace:    [flush_old_commits+287/320] [reiserfs_write_super+21/32] [sync_supers+191/240] [sync_old_buffers+12/64] [kupdate+213/256]
Code: 8b 40 18 a9 00 00 01 00 0f 84 89 00 00 00 8b 44 24 48 8b 54

Using defaults from ksymoops -t elf32-i386 -a i386

Code; 00000000 Before first symbol
00000000 <_EIP>:

Code;  00000000 Before first symbol
  0:   8b 40 18                  mov    0x18(%eax),%eax
Code;  00000003 Before first symbol
  3:   a9 00 00 01 00            test   $0x10000,%eax
Code;  00000008 Before first symbol
  8:   0f 84 89 00 00 00         je     97 <_EIP+0x97>
Code;  0000000e Before first symbol
  e:   8b 44 24 48               mov    0x48(%esp,1),%eax
Code;  00000012 Before first symbol
 12:   8b 54 00 00               mov    0x0(%eax,%eax,1),%edx

Hello!

Is the oops always the same and looks like the one you've posted here? Or is it different from time to time?
If it always the same, can you please try to compile your kernel with CONFIG_REISERFS_CHECK (reiserfs debug) option enabled and see what happens?

Thank you.

Bye,
Oleg

Well after looking more at my logs, I realize that I'm hitting a kernel BUG in page_alloc.c more often than the previous oops that I posted, and always as a (not necessarily immediate) precursor. Here's the log:

kernel BUG at page_alloc.c:100!

invalid operand: 0000
CPU:    0
EIP:    0010:[__free_pages_ok+54/656]    Not tainted
EFLAGS: 00010282
eax: c1404914   ebx: c141d15c   ecx: c141d178   edx: c140782c
esi: 00000000   edi: c864079c   ebp: 085e4000   esp: d7619e30
ds: 0018   es: 0018   ss: 0018
Process cc1 (pid: 20387, stackpage=d7619000)
Stack: c141d15c 00003000 c864079c 085e4000 c0378900 00000000 c031bdf4 c102c01c
      c031be0c 00000213 ffffffff 00016ef5 0000b77a c012b47b c012b873 
c141d15c
      c0120d90 c141d15c 0021c000 c01211b3 17ef0067 c85a96c0 c8aef2c0 
081e4000
Call Trace:    [__free_pages+27/32] [free_page_and_swap_cache+51/64] [__free_pte+64/80] [zap_page_range+403/576] [exit_mmap+181/288]
Code: 0f 0b 64 00 d3 d2 2b c0 83 7b 08 00 74 08 0f 0b 66 00 d3 d2

Using defaults from ksymoops -t elf32-i386 -a i386

Code; 00000000 Before first symbol
00000000 <_EIP>:

Code;  00000000 Before first symbol
  0:   0f 0b                     ud2a  
Code;  00000002 Before first symbol
  2:   64                        fs
Code;  00000003 Before first symbol
  3:   00 d3                     add    %dl,%bl
Code;  00000005 Before first symbol
  5:   d2 2b                     shrb   %cl,(%ebx)
Code;  00000007 Before first symbol
  7:   c0 83 7b 08 00 74 08      rolb   $0x8,0x7400087b(%ebx)
Code;  0000000e Before first symbol
  e:   0f 0b                     ud2a  
Code;  00000010 Before first symbol
 10:   66                        data16
Code;  00000011 Before first symbol
 11:   00 d3                     add    %dl,%bl
Code;  00000013 Before first symbol
 13:   d2 00                     rolb   %cl,(%eax)

kernel BUG at page_alloc.c:100!

invalid operand: 0000
CPU:    0
EIP:    0010:[__free_pages_ok+54/656]    Not tainted
EFLAGS: 00010282
eax: 0100000d   ebx: c141d15c   ecx: c141d15c   edx: 00000000
esi: 00000000   edi: 00000000   ebp: c0194a90   esp: c15b5f78
ds: 0018   es: 0018   ss: 0018
Process kupdated (pid: 6, stackpage=c15b5000)
Stack: c141d15c d76db230 00000000 c0194a90 d76db230 00000000 c8aef080 c15b5fc8
      00027557 c0194aad c141d15c df5de000 c141d15c c012b47b c0124071 
00000004
      d76db180 df5de060 df5de000 c0142c1c d76db230 c15b4000 c02bde17 
c15b424b
Call Trace:    [reiserfs_writepage+0/48] [reiserfs_writepage+29/48] [__free_pages+27/32] [filemap_fdatasync+129/144] [sync_unlocked_inodes+140/384]
Code: 0f 0b 64 00 d3 d2 2b c0 83 7b 08 00 74 08 0f 0b 66 00 d3 d2

Code; 00000000 Before first symbol
00000000 <_EIP>:

Code;  00000000 Before first symbol
  0:   0f 0b                     ud2a  
Code;  00000002 Before first symbol
  2:   64                        fs
Code;  00000003 Before first symbol
  3:   00 d3                     add    %dl,%bl
Code;  00000005 Before first symbol
  5:   d2 2b                     shrb   %cl,(%ebx)
Code;  00000007 Before first symbol
  7:   c0 83 7b 08 00 74 08      rolb   $0x8,0x7400087b(%ebx)
Code;  0000000e Before first symbol
  e:   0f 0b                     ud2a  
Code;  00000010 Before first symbol
 10:   66                        data16
Code;  00000011 Before first symbol
 11:   00 d3                     add    %dl,%bl
Code;  00000013 Before first symbol
 13:   d2 00                     rolb   %cl,(%eax)

kernel BUG at page_alloc.c:100!

invalid operand: 0000
CPU:    0
EIP:    0010:[__free_pages_ok+54/656]    Not tainted
EFLAGS: 00010282
eax: 01000008   ebx: c141d15c   ecx: c141d15c   edx: 00000000
esi: 00000000   edi: d76db230   ebp: 00000001   esp: d3bd3ef8
ds: 0018   es: 0018   ss: 0018
Process ld (pid: 21231, stackpage=d3bd3000)
Stack: c141d15c 00001000 d76db230 00000001 00000018 ffffffff c0124fda 00000010
      00010216 c141d15c dfeb8778 d76db230 00000000 c012b47b c0124b53 
d3bd3f8c
      c141d15c 00000000 00001000 00000000 d9703640 00000000 40013000 
00001000
Call Trace:    [file_read_actor+90/144] [__free_pages+27/32] [do_generic_file_read+499/1024] [generic_file_read+127/272] [file_read_actor+0/144]
Code: 0f 0b 64 00 d3 d2 2b c0 83 7b 08 00 74 08 0f 0b 66 00 d3 d2

Code; 00000000 Before first symbol
00000000 <_EIP>:

Code;  00000000 Before first symbol
  0:   0f 0b                     ud2a  
Code;  00000002 Before first symbol
  2:   64                        fs
Code;  00000003 Before first symbol
  3:   00 d3                     add    %dl,%bl
Code;  00000005 Before first symbol
  5:   d2 2b                     shrb   %cl,(%ebx)
Code;  00000007 Before first symbol
  7:   c0 83 7b 08 00 74 08      rolb   $0x8,0x7400087b(%ebx)
Code;  0000000e Before first symbol
  e:   0f 0b                     ud2a  
Code;  00000010 Before first symbol
 10:   66                        data16
Code;  00000011 Before first symbol
 11:   00 d3                     add    %dl,%bl
Code;  00000013 Before first symbol
 13:   d2 00                     rolb   %cl,(%eax)

Well, after further examination and manipulations, I determined that both the paging oops and the report of BUG page_alloc.c that I was getting are eliminated after moving my swap partition off of the raid0+lvm volume that it was on and onto a separate disk.

Still a bug, but a fairly obscure one. It's obviously not necessary for performance reasons since the kernel stripes swaps itself, but it certainly caused me a lot of headache until I figured out what was going on.

-Tupshin