I saw that someone else had this happen last week... It is not a hardware failure. While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a core dump with the message vm_page_insert: page already inserted I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 GB RAM, 160 GB HD, plenty of free space, RELENG_7). I have never seen this until today. Just before building this port I completely built the kernel and world and installed them, so I am as up-to-date as you could be. I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ vm_meter.c or vm_page.c ? The compressed core dump is 41 MB. Dan
On Mon, Mar 16, 2009 at 12:59 PM, Dan Allen <danallen46@airwired.net> wrote:> I saw that someone else had this happen last week... It is not a hardware > failure. >I have not seen that. I have only seen an assertion failure that would have nothing to do with your reported panic.> > While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a core > dump with the message > > vm_page_insert: page already inserted > > I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 GB > RAM, 160 GB HD, plenty of free space, RELENG_7). I have never seen this > until today. Just before building this port I completely built the kernel > and world and installed them, so I am as up-to-date as you could be. > > I suspect recent changes to vm code... perhaps in > /usr/src/sys/vm/vm_meter.c or vm_page.c ? > > The compressed core dump is 41 MB. >For now, can you just provide the stack trace? Regards, Alan
On 16 Mar 2009, at 1:01 PM, Alan Cox wrote:> For now, can you just provide the stack trace?How do I do this? Is there a tool that I run against the core dump? BTW, I just did the same gcc-4.4 build on my Mac and it built fine without any core dumps... Dan
Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen <danallen46@airwired.net>:> > For now, can you just provide the stack trace? > > How do I do this? Is there a tool that I run against the core dump?See http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Regards.
On 16 Mar 2009, at 3:42 PM, Patrick Lamaizi?re wrote:> Le Mon, 16 Mar 2009 14:49:43 -0600, > Dan Allen <danallen46@airwired.net>: > >>> For now, can you just provide the stack trace? >> >> How do I do this? Is there a tool that I run against the core dump? > > See > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > Regards.Thanks! It turns out that one must have a debug kernel around. I use STABLE as a production system. There is no "kernel.debug" on my system. I guess I therefore cannot provide a stack trace. Sorry. Dan
On 16 Mar 2009, at 1:01 PM, Alan Cox wrote:> For now, can you just provide the stack trace?As I mentioned, I am unable to do so - I have no kernel.debug. However, I am trying to reproduce the bug again. (It takes a while.) Although it has not yet crashed, I noticed another unusual behavior: Normally during my gcc builds the 1 GB of swap space is never touched. My main 1 GB of RAM is sufficient and there is always at least 100 MB of free memory. Today I saw a STATE listed when running top that I have never seen, called "wdrain". This happened when I saw my free memory plummet down to only 20 MB free (out of 1 GB). This state appears to be set in / usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace(). This file also was modified March 1st. I do not know if there is a connection... The last time I built gcc-4.4 was probably just before this. (I build gcc whenever there is a new version, within a couple of days of it being added to ports. There was about two weeks with no new versions this first half of March so it has been a couple of weeks...) I am tempted to go back to about Feb 28th kernel-wise and try the gcc build again and see if it works or panics. Any suggestions as to how I can help narrow this down? Dan
On Mon, Mar 16, 2009 at 5:47 PM, Dan Allen <danallen46@airwired.net> wrote:> > On 16 Mar 2009, at 1:01 PM, Alan Cox wrote: > >> For now, can you just provide the stack trace? > > As I mentioned, I am unable to do so - I have no kernel.debug. > > However, I am trying to reproduce the bug again. ?(It takes a while.) > ?Although it has not yet crashed, I noticed another unusual behavior: > > Normally during my gcc builds the 1 GB of swap space is never touched. ?My > main 1 GB of RAM is sufficient and there is always at least 100 MB of free > memory. > > Today I saw a STATE listed when running top that I have never seen, called > "wdrain". ?This happened when I saw my free memory plummet down to only 20 > MB free (out of 1 GB). ?This state appears to be set in > /usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace(). ?This > file also was modified March 1st. ?I do not know if there is a connection... > > The last time I built gcc-4.4 was probably just before this. ?(I build gcc > whenever there is a new version, within a couple of days of it being added > to ports. ?There was about two weeks with no new versions this first half of > March so it has been a couple of weeks...) > > I am tempted to go back to about Feb 28th kernel-wise and try the gcc build > again and see if it works or panics. > > Any suggestions as to how I can help narrow this down?- Which platform are you using: i386 or amd64? - Is there a particular file that it tries to compile when it runs out of memory? - What are your CFLAGS in make.conf? Thanks, -Garrett
On Mon, 16 Mar 2009 17:23:09 -0600 Dan Allen <danallen46@airwired.net> wrote:> It turns out that one must have a debug kernel around. I use STABLE > as a production system. There is no "kernel.debug" on my system. I > guess I therefore cannot provide a stack trace.Have you disbled building of the kernel.debug then? It is enabled as default on -STABLE. root@kg-work2# uname -a FreeBSD kg-work2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #4: Sun Feb 8 20:56:08 CET 2009 root@kg-work2.kg4.no:/usr/obj/usr/src/sys/SX270 i386 root@kg-work2# locate kernel.debug /usr/obj/usr/src/sys/GENERIC/kernel.debug /usr/obj/usr/src/sys/SX270/kernel.debug HTH -- Regards, Torfinn Ingolfsen
On Monday 16 March 2009 1:59:25 pm Dan Allen wrote:> I saw that someone else had this happen last week... It is not a > hardware failure. > > While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a > core dump with the message > > vm_page_insert: page already inserted > > I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 > GB RAM, 160 GB HD, plenty of free space, RELENG_7). I have never seen > this until today. Just before building this port I completely built > the kernel and world and installed them, so I am as up-to-date as you > could be. > > I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ > vm_meter.c or vm_page.c ? > > The compressed core dump is 41 MB.When I have seen this panic on machines in the past it was caused by bad RAM or another hardware problem. -- John Baldwin
On 18 Mar 2009, at 10:02 AM, John Baldwin wrote:> On Monday 16 March 2009 1:59:25 pm Dan Allen wrote: >> I saw that someone else had this happen last week... It is not a >> hardware failure. >> >> While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a >> core dump with the message >> >> vm_page_insert: page already inserted >> >> I build this port every week on a Toshiba laptop (1.8GHz Core 2 >> Duo, 1 >> GB RAM, 160 GB HD, plenty of free space, RELENG_7). I have never >> seen >> this until today. Just before building this port I completely built >> the kernel and world and installed them, so I am as up-to-date as you >> could be. >> >> I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ >> vm_meter.c or vm_page.c ? >> >> The compressed core dump is 41 MB. > > When I have seen this panic on machines in the past it was caused by > bad RAM > or another hardware problem.Well, I have not been able to reproduce it. I ran builds on two different machines, and everything now works fine. I will keep my eye open for another occurrence, but for now we are at the end of the line on this. At least I am... Thanks to everyone for their help and ideas. Dan
On Mon, Mar 16, 2009 at 11:59:25AM -0600, Dan Allen wrote:> I saw that someone else had this happen last week... It is not a > hardware failure. > > While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a > core dump with the message > > vm_page_insert: page already insertedI had the same thing on 7.1-STABLE with sources @2009-03-14 (last Saturday). The machine had no hardware failures running 6.x...6.4 in the last 3 years running about 20..25 Jails. Therefore I don't think it is a hardware error. The crash happened during someone recompiling most of his packages in jail while running cvsup on /usr/ports in another jail. So there was pretty much I/O and CPU usage. After crash the geom_mirror was degraded on ad4 (ad6 working). I guess a) the vmcore was successfully written to the SWAP b) geom_mirror is unstable under heavy load, maybe it's the origin of the crash. swap resides on that geom_mirror, too. I'm not yet able to get some useful information out of the 230MB vmcore.0 Maybe I may provide useful information about the crash if someone can tell me about how to get theese from vmcore.0. info.0 says: Dump header from device /dev/label/TOPSWAP Architecture: i386 Architecture Version: 2 Dump Length: 246185984B (234 MB) Blocksize: 512 Dumptime: Sat Mar 14 22:43:46 2009 Hostname: top.uugrn.org Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.1-STABLE #0: Sat Mar 14 20:06:04 CET 2009 root@top.uugrn.org:/usr/obj/usr/src_RELENG_7/sys/TOP Panic String: vm_page_insert: page already inserted Dump Parity: 31664128 Bounds: 0 Dump Status: good Regards Raphael Becker -- Raphael Becker <rabe@uugrn.org> http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/fbf63adc/attachment.pgp