Date: Wed, 17 Sep 2003 20:26:11 -0400 From: Peter Radcliffe <pir@pir.net> To: freebsd-stable@freebsd.org Subject: Re: 4.9 panic AGAIN!!!! Message-ID: <20030918002611.GA15292@pir.net> In-Reply-To: <20030917171337.R25425@carver.gumbysoft.com> References: <20030916025858.GA1772@krel.org> <20030917171337.R25425@carver.gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug White <dwhite@gumbysoft.com> probably said:
> gdb works better if you use the debugging kernel built during the kernel
> build process instead of the stripped kernel that the crashdump grabs.
> This trace isn't very useful without it. See the Handbook for details.
I'm also getting PRERELEASE panics on my IBM X30 laptop. I do have a
debugging kernel built and have this from the last crashdump;
IdlePTD at phsyical address 0x0041e000
initial pcb at physical address 0x0033fe00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02a03e3
stack pointer = 0x10:0xec2ebd9c
frame pointer = 0x10:0xec2ebdd4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 3260 (kldload)
interrupt mask = net
trap number = 12
panic: page fault
syncing disks... 23 7 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc0194eff in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc019533d in panic (fmt=0xc02fd24c "%s") at ../../kern/kern_shutdown.c:595
#3 0xc02a1dc7 in trap_fatal (frame=0xec2ebd5c, eva=0)
at ../../i386/i386/trap.c:974
#4 0xc02a1a75 in trap_pfault (frame=0xec2ebd5c, usermode=0, eva=0)
at ../../i386/i386/trap.c:867
#5 0xc02a161b in trap (frame={tf_fs = -1070989296, tf_es = 6684688,
tf_ds = -938541040, tf_edi = 0, tf_esi = -938487808,
tf_ebp = -332481068, tf_isp = -332481144, tf_ebx = -938487808,
tf_edx = 24576, tf_ecx = 512, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1070988317, tf_cs = 8, tf_eflags = 66054, tf_esp = -938487496,
tf_ss = -920107022}) at ../../i386/i386/trap.c:466
#6 0xc02a03e3 in generic_bzero ()
#7 0xc928320f in ?? ()
#8 0xc9287c75 in ?? ()
#9 0xc0127be2 in DEVICE_ATTACH (dev=0xc8088a00) at device_if.c:63
#10 0xc019cea7 in device_probe_and_attach (dev=0xc8088a00)
at ../../kern/subr_bus.c:1153
#11 0xc019de60 in bus_generic_driver_added (dev=0xc8088e00, driver=0xc9289c78)
at ../../kern/subr_bus.c:2025
#12 0xc0127df1 in BUS_DRIVER_ADDED (dev=0xc8088e00, driver=0xc9289c78)
at bus_if.c:91
#13 0xc019c17a in devclass_add_driver (dc=0xc203bc00, driver=0xc9289c78)
at ../../kern/subr_bus.c:322
#14 0xc019e263 in driver_module_handler (mod=0xc842e040, what=0,
arg=0xc9289c94) at ../../kern/subr_bus.c:2310
#15 0xc018420f in module_register_init (arg=0xc9289cac)
at ../../kern/kern_module.c:109
#16 0xc01847db in linker_file_sysinit (lf=0xc84b2d80)
at ../../kern/kern_linker.c:153
#17 0xc018495c in linker_load_file (filename=0xc82ec400 "if_an",
result=0xec2ebf24) at ../../kern/kern_linker.c:288
#18 0xc01851a6 in kldload (p=0xec16f380, uap=0xec2ebf80)
at ../../kern/kern_linker.c:680
#19 0xc02a2091 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = 0, tf_ebp = -1077936784, tf_isp = -332480556,
tf_ebx = -1077936692, tf_edx = 0, tf_ecx = -1077936546, tf_eax = 304,
tf_trapno = 12, tf_err = 2, tf_eip = 134514084, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077936828, tf_ss = 47})
at ../../i386/i386/trap.c:1175
#20 0xc0295295 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbffd70.
The symptoms for this are that something causes a lot of disk
activity, mozilla is taking up a little CPU and a lot of the rest is
gone to the system. I kill mozilla and the machine panics. I'm not
even using an0 when the machine paniced, I was using fxp0.
I'm having several problems with this machine right now other than the
random panics, I can no longer switch from X to a text vty without
crashing the machine. Re-attaching the cisco mini-pci card after
suspend/resume fails one in 10 times or so (hangs the machine for a
while and then returns, this can be worked around with
kldunload/kldload and I've talked a little with Doug Ambrisko about it
but he's mostly switched over to -CURRENT) ...
The hardware seems ok, I can run it through a dozen buildworlds with
no ill effects, no odd signal 11 deaths or similar, memtest86 reports
no problems, XP runs fine. 4.9 isn't looking too good from here.
P.
--
pir pir-sig@pir.net pir-sig@net.tufts.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030918002611.GA15292>