RELENG_5 PAE panic
fmc at reanimators.org
Fri Jul 29 00:34:34 GMT 2005
Intel SE7320VP2 motherboard with single Xeon 2.8GHz, 4GB RAM, and an
80GB disk and a CD-ROM drive connected to motherboard ATA. 1GB of the
RAM appears above 4GB which suggested building a PAE kernel. So,
imagine 5.4-RELEASE with a kernel config file that goes like this:
It boots, but often panics while starting a rather modified named
(based on BIND 8, and running just fine on other 4.x and 5.x systems
with similar kernel configuration but no PAE). Sometimes it doesn't
panic right away, but it usually does.
Boot from /boot/kernel.old/kernel (no PAE), add KDB/DDB options to
PAE kernel configuration, build and install kernel and try some more.
See that it is panicking in propagate_priority(). No crash dumps, it
reliably dumps 3552MB and then loses with an NMI.
s/PAE/GENERIC/ and it runs, but ignores 1GB RAM.
That was last night. This morning I found
which could be describing a related problem (though I have no ips-type
hardware in my picture), and Scott Long seemed to be interested.
And I looked through the commit logs and saw a commit to
sys/kern/kern_switch.c that looked like it could perhaps have some
bearing. (Rev 1.112, MFCd as 126.96.36.199, basing this on the commit
message for 1.112.)
So, hmm. cvsup using stable-supfile, buildworld, buildkernel, &c.
It didn't help. A kernel with PAE still got me a panic during named
startup (this time by hand after having logged in as root following
--- begin paste ---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc03db1cf
stack pointer = 0x10:0xeb328c64
frame pointer = 0x10:0xeb328c78
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 70 (pagedaemon)
[thread pid 70 tid 100080 ]
Stopped at 0xc03db1cf = propagate_priority+0x7f: movl 0x24(%eax),%eax
Tracing pid 70 tid 100080 td 0xc6a89000
propagate_priority(c6a89000,c0628280,c0636c60,c6a89000,c6cdaa82) at 0xc03db1cf = propagate_priority+0x7f
turnstile_wait(c6a6f240,c0636c60,c6cdaa80) at 0xc03db84a = turnstile_wait + 0x266
_mtx_lock_sleep(c0636c60,c6a89000,0,0,0) at 0xc03b4c25 = _mtx_lock_speed+0xad
msleep(c0637104,c0636c60,44,c059aa74,1f4) at 0xc03c37ea = msleep+0x39a
vm_pageout(0,eb328d38) at 0xc04fb0e4 = vm_pageout+0x280
fork_exit(c04fae64,0,eb328d38) at 0xc03a8680 = fork_exit+0x74
fork_trampoline() at 0xc0539d9c = fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xeb328d6c, ebp = 0 ---
--- end paste ---
"panic" to force a dump continues to lose with an NMI after 3552MB.
Um, help? Pretty please? My clues about this part of the kernel are
a bit stale. I don't know how long I have to play, and don't think I
can give remote access, but I'm willing to try stuff and be remote
eyes, hands, and as much of a brain as I can while I can.
More information about the freebsd-stable