Date: Wed, 11 Jun 2008 14:22:55 -0500 From: eculp <eculp@casasponti.net> To: "Kris Kennaway" <kris@FreeBSD.org> Cc: questions@freebsd.org Subject: Re: reboot after panic : page fault for two consecutive days now with FreeBSD stable 7.0 Message-ID: <20080611142255.15431txbrywv1csg@intranet.casasponti.net> In-Reply-To: <4850203A.5080805@FreeBSD.org> References: <20080611133220.198644ite5u5r778@intranet.casasponti.net> <4850203A.5080805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Kris Kennaway" <kris@FreeBSD.org>: > eculp wrote: >> This is on a relatively new Dell dualcore with 4G of ram running up =20 >> to date stable. I'm not on site so I have no idea what might be =20 >> provoking these crashes. In fact in many years of running FreeBSD =20 >> I've not seen something just happen like this. It is a =20 >> simi-production machine that cvsups daily and builds and installs a =20 >> new world and kernel. Ports are updated about once a week and =20 >> haven't seen any issues previously. It has been running 24/7 since =20 >> 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 >> root@casasponti.net:/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 =20 >> on line at a moments notice. I think that what I need is probably =20 >> a crash course on debugging a crash and I really don't know where =20 >> to start since after over 10 years with freebsd I've never needed =20 >> 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 =20 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 =20 kernel.debug only got to Cannot access memory at address 0x4b55. =20 Which means I have to wait for another crash. I have already compiled a new kernelwith debuging and will reboot =20 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 =20 > system that has been stable for a while with no OS or workload =20 > changes made, are usually due to the hardware starting to fail. > > Kris >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080611142255.15431txbrywv1csg>