Quoting "Kris Kennaway" <[EMAIL PROTECTED]>:
eculp wrote:
This is on a relatively new Dell dualcore with 4G of ram running up
to date stable. I'm not on site so I have no idea what might be
provoking these crashes. In fact in many years of running FreeBSD
I've not seen something just happen like this. It is a
simi-production machine that cvsups daily and builds and installs a
new world and kernel. Ports are updated about once a week and
haven't seen any issues previously. It has been running 24/7 since
new, about 8 months.
3 files were generated info, bounds and vmcore. The info file follows:
Dump header from device /dev/mfid0s1b
Architecture: i386
Architecture Version: 2
Dump Length: 341225472B (325 MB)
Blocksize: 512
Dumptime: Wed Jun 11 12:34:24 2008
Hostname: casasponti.net
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 7.0-STABLE #258: Tue Jun 10 05:54:42 CDT 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENCONTACTO
Panic String: page fault
Dump Parity: 2395754794
Bounds: 2
Dump Status: good
the vmcore is about 300M so I'm not attaching it;) I could put it
on line at a moments notice. I think that what I need is probably
a crash course on debugging a crash and I really don't know where
to start since after over 10 years with freebsd I've never needed
it. Any help, suggestions, etc. would be greatly appreciated.
See the developers' handbook chapter on kernel debugging.
Thanks Kris. I did that and I'm assuming that since debugging was not
enabled in my kernel I got:
/usr/obj/usr/src/sys/ENCONTACTO # kgdb kernel.debug /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Cannot access memory at address 0x0
(kgdb)
I assume it will only work with the new kernel because the
kernel.debug only got to Cannot access memory at address 0x4b55.
Which means I have to wait for another crash.
I have already compiled a new kernelwith debuging and will reboot
tonight to install the kernel and hopefully will never need to test it.
Thanks for your help,
ed
However, panics that "suddenly" start happening frequently on a
system that has been stable for a while with no OS or workload
changes made, are usually due to the hardware starting to fail.
Kris
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
