4.9 panic AGAIN!!!!

[Peter Radcliffe]

Doug White <dwhite at 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 at pir.net                 pir-sig at net.tufts.edu