Re: GCC build causes panic: page already inserted
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
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 inserted I 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 r...@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 r...@uugrn.org http://rabe.uugrn.org/ GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpeqlW0RKPEi.pgp Description: PGP signature
Re: GCC build causes panic: page already inserted
On Thu, Mar 19, 2009 at 12:34:56AM +0100, Raphael Becker wrote: 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 r...@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 Some more details ... maybe someone will get somethin interesing from this: [r...@top /usr/obj/usr/src_RELENG_7/sys/TOP]# kgdb kernel.debug /var/crash/vmcore.0 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... Unread portion of the kernel message buffer: panic: vm_page_insert: page already inserted cpuid = 1 Uptime: 1h41m26s Physical memory: 2034 MB Dumping 234 MB: 219 203 187 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x186a0 fault code = supervisor read, page not present instruction pointer = 0x20:0x186a0 stack pointer = 0x28:0xe571da48 frame pointer = 0x28:0xe571da68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) trap number = 12 panic: page fault cpuid = 1 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boot/kernel/logo_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/logo_saver.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:196 196 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07d3a87 in boot (howto=260) at /usr/src_RELENG_7/sys/kern/kern_shutdown.c:418 #2 0xc07d3d59 in panic (fmt=Variable fmt is not available.) at /usr/src_RELENG_7/sys/kern/kern_shutdown.c:574 #3 0xc0a1d4ca in vm_page_insert (m=0xc3735b20, object=0xc1461200, pindex=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/vm/vm_page.c:665 #4 0xc0a1da29 in vm_page_alloc (object=0xc1461200, pindex=5785959, req=546) at /usr/src_RELENG_7/sys/vm/vm_page.c:1171 #5 0xc083bd6b in allocbuf (bp=0xc51fe0c8, size=16384) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:2895 #6 0xc083f62d in getblk (vp=0xc58969b4, blkno=46287648, size=16384, slpflag=0, slptimeo=0, flags=Variable flags is not available.) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:2666 #7 0xc083ffe4 in breadn (vp=0xc58969b4, blkno=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:786 #8 0xc084011c in bread (vp=0xc58969b4, blkno=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:734 #9 0xc09edecb in ffs_vgetf (mp=0xc5852b40, ino=2897024, flags=2, vpp=0xe83338e8, ffs_flags=Variable ffs_flags is not available.) at /usr/src_RELENG_7/sys/ufs/ffs/ffs_vfsops.c:1477 #10 0xc09ee09e in ffs_vget (mp=0xc5852b40, ino=2897024, flags=2, vpp=0xe83338e8) at /usr/src_RELENG_7/sys/ufs/ffs/ffs_vfsops.c:1379 #11 0xc09fa44b in ufs_lookup (ap=0xe8333930) at /usr/src_RELENG_7/sys/ufs/ufs/ufs_lookup.c:600 #12 0xc0aeada2 in VOP_CACHEDLOOKUP_APV (vop=0xc0c5ff00, a=0xe8333930) at vnode_if.c:153 #13 0xc084178c in vfs_cache_lookup (ap=0xe83339b4) at vnode_if.h:83 #14 0xc0aeca76 in VOP_LOOKUP_APV (vop=0xc0c60420, a=0xe83339b4) at vnode_if.c:99 #15 0xc08481b1 in lookup (ndp=0xe8333b7c) at vnode_if.h:57 #16 0xc0848eff in namei (ndp=0xe8333b7c) at /usr/src_RELENG_7/sys/kern/vfs_lookup.c:215 #17 0xc08600c7 in vn_open_cred (ndp=0xe8333b7c, flagp=0xe8333c78, cmode=0, cred=0xc635cb00, fp=0xca134804) at /usr/src_RELENG_7/sys/kern/vfs_vnops.c:188 #18 0xc0860393 in vn_open (ndp=0xe8333b7c,
Re: GCC build causes panic: page already inserted
On Mon, Mar 16, 2009 at 5:47 PM, Dan Allen danalle...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
On Mon, 16 Mar 2009 17:23:09 -0600 Dan Allen danalle...@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. r...@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 r...@kg-work2.kg4.no:/usr/obj/usr/src/sys/SX270 i386 r...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
On Mon, Mar 16, 2009 at 12:59 PM, Dan Allen danalle...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen danalle...@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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
On 16 Mar 2009, at 3:42 PM, Patrick Lamaizière wrote: Le Mon, 16 Mar 2009 14:49:43 -0600, Dan Allen danalle...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC build causes panic: page already inserted
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
