Hello all,
Without a full dump are there any telltale signs from the panic message
that can give me some sign of whether I'm dealing with a hardware or
software issue? I have a box that has been running 4.11-p10 for quite
some time with no problems. I upgraded a number of ports
(apache/php/mysql) and since then I've had two panics. Of course userland
apps shouldn't cause this, but that's the only change I see.
I can't get a kernel dump since it fails like this each time:
dumping to dev #da/0x20001, offset 2097152
dump 1024 1023 1022 1021 Aborting dump due to I/O error.
status == 0xb, scsi status == 0x0
failed, reason: i/o error
The meat of my question though, what are these lines telling me:
(panic 1)
instruction pointer = 0x8:0xc028b053
stack pointer = 0x10:0xe138eefc
frame pointer = 0x10:0xe138ef2c
(panic 2)
instruction pointer = 0x8:0xc028b053
stack pointer = 0x10:0xe138eefc
frame pointer = 0x10:0xe138ef2c
Are those physical memory addresses where the code that caused the panic
resides? If so, does that point to bad RAM?
Thanks,
Charles
Here's more info if anyone is curious:
[-- MARK -- Mon Oct 23 06:00:00 2006]
Fatal trap 12: page fault while in kernel mode
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
fault virtual address = 0xc327c614
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc028b053
stack pointer = 0x10:0xe138eefc
frame pointer = 0x10:0xe138ef2c
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 = 8 (syncer)
interrupt mask = none <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
boot() called on cpu#0
syncing disks... panic: rslock: cpu: 0, addr: 0xc0391ccc, lock: 0x00000001
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
boot() called on cpu#0
Uptime: 441d9h31m5s
dumping to dev #da/0x20001, offset 2097152
dump 1024 1023 1022 1021 Aborting dump due to I/O error.
status == 0xb, scsi status == 0x0
failed, reason: i/o error
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset called on cpu#0
cpu_reset: Stopping other CPUs
[-- MARK -- Tue Oct 24 09:00:00 2006]
Fatal trap 12: page fault while in kernel mode
mp_lock = 01000002; cpuid = 1; lapic.id = 01000000
fault virtual address = 0xc29d2b94
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc028b053
stack pointer = 0x10:0xe138eefc
frame pointer = 0x10:0xe138ef2c
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 = 8 (syncer)
interrupt mask = none <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 01000002; cpuid = 1; lapic.id = 01000000
boot() called on cpu#1
syncing disks... panic: rslock: cpu: 1, addr: 0xc0391ccc, lock: 0x01000001
mp_lock = 01000002; cpuid = 1; lapic.id = 01000000
boot() called on cpu#1
Uptime: 1d2h55m38s
dumping to dev #da/0x20001, offset 2097152
dump 1024 1023 1022 1021 Aborting dump due to I/O error.
status == 0xb, scsi status == 0x0
failed, reason: i/o error
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Stopping other CPUs
cpu_reset: Restarting BSP
cpu_reset_proxy: Grabbed mp locckp uf_re sBeStP:
BSP did not grab mp lock
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
