[Bug 1403] New: 2.6.0-test8 oops: Unable to handle kernel paging request - free_pages_bulk

From: Martin J. Bligh
Date: Wed Oct 22 2003 - 18:36:17 EST


http://bugme.osdl.org/show_bug.cgi?id=1403

Summary: 2.6.0-test8 oops: Unable to handle kernel paging request
- free_pages_bulk
Kernel Version: 2.6.0-test8
Status: NEW
Severity: normal
Owner: akpm@xxxxxxxxx
Submitter: plars@xxxxxxxxxxxxxx
CC: sglass@xxxxxxxxxx


Distribution: RedHat 7.3
Hardware Environment:
I'm including a little extra detail about the swap setup because it's different
than most people seem to have and may or may not be relevant.

8-way PIII-700
total used free shared buffers cached
Mem: 16281176 432284 15848892 0 124088 57900
-/+ buffers/cache: 250296 16030880
Swap: 14691152 0 14691152
Filename Type Size Used Priority
/dev/sda3 partition 1020116 0 -1
/dev/sda9 partition 2048248 0 -2
/dev/sda5 partition 2048248 0 -3
/dev/sda6 partition 2048248 0 -4
/dev/sda7 partition 2048248 0 -5
/dev/sda10 partition 2048248 0 -6
/dev/sda11 partition 1381548 0 -7
/dev/sda8 partition 2048248 0 -8

Software Environment:
gcc 2.96, binutils 2.13.90

Problem Description:
I encountered the following oops and hang after 1 to 4 hours of running the test
proceedure described below. I have encountered this on 2.6.0-test5, test7, and
test8.

Unable to handle kernel paging request at virtual address 00100104
printing eip:
c0139e44
*pde = 123b6001
Oops: 0002 [#1]
CPU: 7
EIP: 0060:[<c0139e44>] Not tainted
EFLAGS: 00010002
EIP is at free_pages_bulk+0x1a4/0x220
eax: 00100100 ebx: 0001a262 ecx: c14aa8e0 edx: 00200200
esi: 00006898 edi: c14aa8d8 ebp: fffffffe esp: e0197d68
ds: 007b es: 007b ss: 0068
Process mmap3 (pid: 8059, threadinfo=e0196000 task=f6aa72f0)
Stack: 00000000 c14aa904 c038b8c8 00000002 c102c000 c038b8c8 00000082 ffffffff
c040b268 0000000a 00000046 c012182b 00000046 0000001c 0bd15f60 e0197dd4
c038b880 c150dedc c038bc00 00000282 c013a39a c038b6c0 0000000d c038bc10
Call Trace:
[<c012182b>] do_softirq+0x6b/0xd0
[<c013a39a>] free_hot_cold_page+0xba/0xf0
[<c0109a1a>] apic_timer_interrupt+0x1a/0x20
[<c013a8fb>] __pagevec_free+0x1b/0x30
[<c013f43a>] release_pages+0x10a/0x150
[<c0135c19>] remove_from_page_cache+0x29/0x30
[<c013f49a>] __pagevec_release+0x1a/0x30
[<c013fafe>] truncate_inode_pages+0xee/0x300
[<c0143800>] unmap_page_range+0x60/0x80
[<c016ad91>] generic_delete_inode+0x51/0xd0
[<c016afa3>] iput+0x63/0x70
[<c016840c>] dput+0x14c/0x180
[<c01861d6>] ext3_release_file+0x16/0x50
[<c0153dd7>] __fput+0xb7/0xe0
[<c015278c>] filp_close+0x5c/0x70
[<c01527f3>] sys_close+0x53/0x70
[<c010902b>] syscall_call+0x7/0xb

Code: 89 50 04 89 02 c7 47 08 00 01 10 00 c7 41 04 00 02 20 00 83
Steps to reproduce:
I was running a vmm stress workload comprised of a subset of tests from LTP. I
ran two copies of Pan (the ltp test driver) in parallel with the following tests.
First copy: mtest01 -p60 -w
This one is basically just a load generator for memory. It allocates memory
until it hits 60% of the total memory (phys+swap) and writes to it. This is
sufficient to ensure that swapping has occurred on this system.

Second copy:
mmap1
mmap2
mmap3
mallocstress

It always seems to be in mmap3 when it dies. The mmap3 test does a lot of
map/write/unmaps of random sizes by multiple threads.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/