Panic in recent 7.2-Stable
Hello, I'm having a panic with the latest kernel build of my -Stable file server (sources cvsupped around yesterday evening, CEST). The panic happens soon after entering multi-user : panic: vm_phys_paddr_to_vm_page: paddr 0xf is not in any segment KDB: enter: panic [thread pid 1005 tid 100154 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db where Tracing pid 1005 tid 100154 td 0x8ecad480 kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at kdb_enter_why+0x3a panic(80bc1ad6,f,0,8ecad480,0,...) at panic+0xd1 vm_phys_paddr_to_vm_page(f,f,fb301ad8,1,80a36a78,...) at vm_phys_paddr_to_vm_page+0x4d dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at dev_pager_getpages+0xe1 vm_fault(89267bfc,33d9,1,0,89b0b50c,...) at vm_fault+0x1020 trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b trap(fb301d38) at trap+0x247 An excerpt of the dmesg is : Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #35: Sun Sep 6 10:04:40 CEST 2009 x...@yyy:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0x8101a000. Preloaded elf module /boot/kernel/zfs.ko at 0x8101a188. Preloaded elf module /boot/kernel/opensolaris.ko at 0x8101a230. Preloaded elf module /boot/kernel/snd_cmi.ko at 0x8101a2e0. Preloaded elf module /boot/kernel/sound.ko at 0x8101a38c. Preloaded /boot/zfs/zpool.cache /boot/zfs/zpool.cache at 0x8101a438. Preloaded elf module /boot/kernel/acpi.ko at 0x8101a490. The previous kernel is older (around 22 august) and works as expected. Some idents for the panic kernel are : (ie after SVN rev 196838) $FreeBSD: src/sys/i386/i386/pmap.c,v 1.594.2.20 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/kern/kern_mbuf.c,v 1.32.2.6 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/device_pager.c,v 1.84.2.3 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.7 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_page.c,v 1.357.2.10 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_phys.c,v 1.4.2.2 2009/09/04 19:59:32 jhb Exp $ Cheers TfH ___ 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: Panic in recent 7.2-Stable
Thierry Herbelot wrote: Hello, I'm having a panic with the latest kernel build of my -Stable file server (sources cvsupped around yesterday evening, CEST). The panic happens soon after entering multi-user : panic: vm_phys_paddr_to_vm_page: paddr 0xf is not in any segment KDB: enter: panic [thread pid 1005 tid 100154 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db where Tracing pid 1005 tid 100154 td 0x8ecad480 kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at kdb_enter_why+0x3a panic(80bc1ad6,f,0,8ecad480,0,...) at panic+0xd1 vm_phys_paddr_to_vm_page(f,f,fb301ad8,1,80a36a78,...) at vm_phys_paddr_to_vm_page+0x4d dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at dev_pager_getpages+0xe1 vm_fault(89267bfc,33d9,1,0,89b0b50c,...) at vm_fault+0x1020 trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b trap(fb301d38) at trap+0x247 Similar panic here. I believe, the panic introduced in SVN revision 196838. For us, the panic is caused by the `dmidecode' program. The dmidecode program mmap /dev/mem at offset 0xf and reads on... ___ 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: Panic in recent 7.2-Stable
On Sun, Sep 06, 2009 at 11:02:39AM +0200, Thierry Herbelot wrote: Hello, I'm having a panic with the latest kernel build of my -Stable file server (sources cvsupped around yesterday evening, CEST). The panic happens soon after entering multi-user : panic: vm_phys_paddr_to_vm_page: paddr 0xf is not in any segment KDB: enter: panic [thread pid 1005 tid 100154 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db where Tracing pid 1005 tid 100154 td 0x8ecad480 kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at kdb_enter_why+0x3a panic(80bc1ad6,f,0,8ecad480,0,...) at panic+0xd1 vm_phys_paddr_to_vm_page(f,f,fb301ad8,1,80a36a78,...) at vm_phys_paddr_to_vm_page+0x4d dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at dev_pager_getpages+0xe1 vm_fault(89267bfc,33d9,1,0,89b0b50c,...) at vm_fault+0x1020 trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b trap(fb301d38) at trap+0x247 An excerpt of the dmesg is : Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #35: Sun Sep 6 10:04:40 CEST 2009 x...@yyy:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0x8101a000. Preloaded elf module /boot/kernel/zfs.ko at 0x8101a188. Preloaded elf module /boot/kernel/opensolaris.ko at 0x8101a230. Preloaded elf module /boot/kernel/snd_cmi.ko at 0x8101a2e0. Preloaded elf module /boot/kernel/sound.ko at 0x8101a38c. Preloaded /boot/zfs/zpool.cache /boot/zfs/zpool.cache at 0x8101a438. Preloaded elf module /boot/kernel/acpi.ko at 0x8101a490. The previous kernel is older (around 22 august) and works as expected. Some idents for the panic kernel are : (ie after SVN rev 196838) $FreeBSD: src/sys/i386/i386/pmap.c,v 1.594.2.20 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/kern/kern_mbuf.c,v 1.32.2.6 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/device_pager.c,v 1.84.2.3 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.7 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_page.c,v 1.357.2.10 2009/09/04 19:59:32 jhb Exp $ $FreeBSD: src/sys/vm/vm_phys.c,v 1.4.2.2 2009/09/04 19:59:32 jhb Exp $ I expect that the following patch, that is the partial merge of r194459, would fix it. It patches sys/vm/vm_phys.c. Index: vm_phys.c === --- vm_phys.c (revision 194458) +++ vm_phys.c (revision 194459) @@ -382,8 +382,7 @@ if (pa = seg-start pa seg-end) return (seg-first_page[atop(pa - seg-start)]); } - panic(vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment, - (uintmax_t)pa); + return (NULL); } /* pgpVPiOjOExg1.pgp Description: PGP signature
Re: Panic in recent 7.2-Stable
Le Sunday 06 September 2009, Kostik Belousov a écrit : I expect that the following patch, that is the partial merge of r194459, would fix it. It patches sys/vm/vm_phys.c. Index: vm_phys.c === --- vm_phys.c (revision 194458) +++ vm_phys.c (revision 194459) @@ -382,8 +382,7 @@ if (pa = seg-start pa seg-end) return (seg-first_page[atop(pa - seg-start)]); } - panic(vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment, - (uintmax_t)pa); + return (NULL); This seems indeed the missing part : I should have looked in -current Thanks TfH } /* ___ 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: Panic in recent 7.2-Stable
On Sun, Sep 06, 2009 at 05:37:52PM +0200, A.J. Fonz van Werven wrote: Kostik Belousov wrote: I expect that the following patch, that is the partial merge of r194459, would fix it. It patches sys/vm/vm_phys.c. Index: vm_phys.c === --- vm_phys.c (revision 194458) +++ vm_phys.c (revision 194459) @@ -382,8 +382,7 @@ if (pa = seg-start pa seg-end) return (seg-first_page[atop(pa - seg-start)]); } - panic(vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment, - (uintmax_t)pa); + return (NULL); } /* Hi, A quick grep on the file in question revealed that there are two functions that may panic() with page not in any segment: the vm_phys_paddr_to_vm_page() being patched and also the next function vm_phys_paddr_to_segind(). I'm not exactly current with the memory management code so this may be a very stupid question, but I'll ask it anyway: don't both functions need to be patched? vm_phys_paddr_to_segind is used during vm bootstrap, the call sequence is vm_page_startup-vm_phys_add_page-vm_phys_paddr_to_segind. vm_page_startup calls vm_phys_add_page only for pages that should not cause the mentioned panic in vm_phys_paddr_to_segind, since it iterates over the pages of the segments created by vm_phys_create_seg() in vm_phys_init(). pgpx2GFet22ty.pgp Description: PGP signature
Re: Panic in recent 7.2-Stable
Le Sunday 06 September 2009, A.J. Fonz van Werven a écrit : Kostik Belousov wrote: I expect that the following patch, that is the partial merge of r194459, would fix it. It patches sys/vm/vm_phys.c. Index: vm_phys.c === --- vm_phys.c (revision 194458) +++ vm_phys.c (revision 194459) @@ -382,8 +382,7 @@ if (pa = seg-start pa seg-end) return (seg-first_page[atop(pa - seg-start)]); } - panic(vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment, - (uintmax_t)pa); + return (NULL); } /* Hi, A quick grep on the file in question revealed that there are two functions that may panic() with page not in any segment: the vm_phys_paddr_to_vm_page() being patched and also the next function vm_phys_paddr_to_segind(). I'm not exactly current with the memory management code so this may be a very stupid question, but I'll ask it anyway: don't both functions need to be patched? My apologies if I'm way off the mark here, but I'm just trying to help. you are right : there seems the vm handling has been recently updated and maybe even those who know may not have reviewed/updated all panic conditions (removing the panic in vm_phys_paddr_to_vm_page at least allows correct operation of a -Stable kernel, like under -Current) TfH Regards, Alphons ___ 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: Panic in recent 7.2-Stable
Kostik Belousov wrote: I expect that the following patch, that is the partial merge of r194459, would fix it. It patches sys/vm/vm_phys.c. Index: vm_phys.c === --- vm_phys.c (revision 194458) +++ vm_phys.c (revision 194459) @@ -382,8 +382,7 @@ if (pa = seg-start pa seg-end) return (seg-first_page[atop(pa - seg-start)]); } - panic(vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment, - (uintmax_t)pa); + return (NULL); } /* Hi, A quick grep on the file in question revealed that there are two functions that may panic() with page not in any segment: the vm_phys_paddr_to_vm_page() being patched and also the next function vm_phys_paddr_to_segind(). I'm not exactly current with the memory management code so this may be a very stupid question, but I'll ask it anyway: don't both functions need to be patched? My apologies if I'm way off the mark here, but I'm just trying to help. Regards, Alphons -- All right, that does it Bill [Donahue]. I'm pretty sure that killing Jesus is not very Christian. -- Pope Benedict XVI, Southpark season 11 episode 5 ___ 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
