Subject: kern/8380: Bug in `extent_free' causes panics after heavy load. Maybe it's PR 7481
To: None <email@example.com>
From: None <Reinoud.Zandijk@ismaelda.netbsd.org>
Date: 09/12/1999 04:20:56
>Synopsis: Bug in `entent_free' causes panics after heavy load. Maybe related to PR 7481
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Sun Sep 12 04:20:00 1999
>Originator: Reinoud Zandijk
>Release: NetBSD-release 11 september 1999 <NetBSD-current source date>
Acorn RiscPC, ARM710, 16+8Mb DRAM, 2Mb VRAM, NetBSD 1.4.1 userland + kernel, Atomwide Etherlan 3.
System: NetBSD ismaelda 1.4.1 NetBSD 1.4.1 (config.ismaelda) #0: Sat Sep 11 22:24:29 CEST 1999 root@ismaelda:/usr/sources/release/src/sys/arch/arm32/compile/config.ismaelda arm32
The problem shows itself as a kernel-panic after being subjected to heavy load. It occures very often and since I was upgrading my system to 1.4.1, I recompiled lots of stuff since no precompiled binarys were present.
Since I've compiled the inkernel debugger, the panic results in a debugger session, regretfully without a core dump. I managed to squeeze the following information out of it:
One crash :
extent 'swap 0x0000' (0x0 - 0xf617), flags = 0x0
0x0 - 0x2b0
0x0 - 0x0
extent_free : start 0x49b, end 0x49b
panic: extent_free : region not found
another crash :
[u]vmfault (0xf0116ed4,0,3,0) -> 1
unhandled trap (frame=0xf3478d4c
Data abort: 'Permission error (page)' status 00f
address = 000072c
pc = f0024c1c
stopped in pagedeamon at _extent_destroy + 0x12c: streq r3,[r14, #0x00c]
and in all others I get `just' the page fault somewhere in `extent_free'. I've tried to figure out the exact location and found the kernel crashed at line 964 : "LIST_INSERT_AFTER(rp, nrp, er_link)" in /usr/src/sys/kern/subr_extend.c.
My guess is that memory is getting more and more fragmented and as a result some table is running out of space or reaches a prrotected page and is thus running out of space??
Curious is that it may be related to screen handling since most of the errors occured when switching to another virtual terminal and typing in a command. When the command starts or ends executing, the system falls over.
I managed, without intend.., to reproduce the error several times. Start with a new system, untar f.e. a huge tar file, say a kernel-source, delete an old kernelsource tree and compile the new one. Also a Sun-SLC was compiling it's new kernel on the RiscPC.
Silly: Don't stress the machine this hard....
Serious: I really dont know.... it maybe the combination between the port-code and the kernel code.....