Re: FreeBSD 11.1-RELEASE-p13 fatal trap 12: page fault while in kernel mode
After upgrading to 11.2-RELEASE-p2, the server constantly reboots instead of hanging at the crash-dump. Still, I don’t get a crash dump in /var/crash kern.corefile: %N.core kern.coredump_devctl: 0 kern.nodump_coredump: 0 kern.coredump: 1 kern.capmode_coredump: 0 kern.sugid_coredump: 0 kern.coredump_pack_vmmapinfo: 1 kern.coredump_pack_fileinfo: 1 debug.ncores: 5 debug.elf32_legacy_coredump: 0 debug.elf64_legacy_coredump: 0 hw.ixl.core_debug_mask: 0 (server ) 0 # grep dump /etc/rc.conf # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev=„AUTO" (server ) 0 # cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/mirror/swapnoneswapsw 0 0 The server is zfs-only, all the drives hang on said SemiMicro smartpqi controller. I actually have two of these and both randomly reboot every couple of hours. Or more like every hour. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.1-RELEASE-p13 fatal trap 12: page fault while in kernel mode
On Sun, Sep 9, 2018 at 3:59 AM Rainer Duffner wrote: > > > > Am 09.09.2018 um 11:08 schrieb Eugene Grosbein : > > > > This list strips attachments, so you should upload it somewhere and post > a link. > > > > Well actually, the text you get when you post one says it’s awaiting > moderator approval. > > But I found a way to upload it without signing up for some site: > > https://ibb.co/nHK9LU > Actually, what gets stripped is attachments that are not text/plain. "text/plain gets through just fine. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.1-RELEASE-p13 fatal trap 12: page fault while in kernel mode
> Am 09.09.2018 um 11:08 schrieb Eugene Grosbein : > > This list strips attachments, so you should upload it somewhere and post a > link. Well actually, the text you get when you post one says it’s awaiting moderator approval. But I found a way to upload it without signing up for some site: https://ibb.co/nHK9LU ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.1-RELEASE-p13 fatal trap 12: page fault while in kernel mode
09.09.2018 5:35, Rainer Duffner wrote: > Hi, > > I got a kernel panic > > This a a HP Gen10 system. > It has this new Microsemi SAS HBA that only got the driver with 11.2. > > It’s running a syslog-server (syslog-ng) > > I have attached a screenshot of the panic, hopefully it comes through. > > > dumpdev is set to „AUTO“, but I don’t find any crashdumps in /var/crash. > > dmesg also says it can’t find any crashdumps. This list strips attachments, so you should upload it somewhere and post a link. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 11.1-RELEASE-p13 fatal trap 12: page fault while in kernel mode
Hi, I got a kernel panic This a a HP Gen10 system. It has this new Microsemi SAS HBA that only got the driver with 11.2. It’s running a syslog-server (syslog-ng) I have attached a screenshot of the panic, hopefully it comes through. dumpdev is set to „AUTO“, but I don’t find any crashdumps in /var/crash. dmesg also says it can’t find any crashdumps. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
11.0: Fatal trap 12: page fault while in kernel mode
http://eis.bris.ac.uk/~mexas/core.txt.9 vmcore.9 is >450MB: http://cmplx.uk/pic/vmcore.9 Thanks Anton ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 17:35:32 Gardner Bell wrote: > On Tue, Apr 26, 2011 at 04:25:26PM +0200, Bernhard Schmidt wrote: > > On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote: > > > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt > > > wrote: > > > > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: > > > >> Downloading a torrent with many peers on a toshiba satellite notebook > > > >> using an Atheros AR5006 wireless nic caused the following panic. This > > > >> is an i386 system running 8.2-STABLE from around April 06. > > > > > > > > Can you reproduce that? > > > > > > So far I've not been able to reproduce this. > > > > Ok. I assume this only happens when loosing the connection and trying > > to re-associate. At least that is the only possible scenario I can > > think of where a timeout for mgmt frames is involved. Probably we > > aren't bumping a refcount correctly or something. Actually that sounds > > rather plausible as it panics exactly when trying to access ni which > > should, for a station, always point to iv_bss, which can in turn be > > free'd almost unconditionally if someone's telling net80211 to > > associate to another (or even the same) network. Hmm.. tracing refcount > > it is. > > > > Were you running wpa_supplicant at that point? Any messages before > > the panic happened? > > > > Yes, I'm running wpa_supplicant with the following settings: > > network={ > ssid="x" > psk="x" > } > > Other settings for the wireless card I have in rc.conf: > > wlans_ath0="wlan0" > ifconfig_wlan0="WPA DHCP" > ifconfig_wlan0_alias0="inet 192.168.0.12 netmask 0x" > > > The last messages seen on the console before the panic are wlan0: > ieee80211_new_state_locked: pending SCAN -> AUTH transition lost > and several UP/DOWN events. That's what I expected, thanks. I'll try to come up with something. -- Bernhard ___ 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: Fatal trap 12: page fault while in kernel mode
On Tue, Apr 26, 2011 at 04:25:26PM +0200, Bernhard Schmidt wrote: > On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote: > > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt > > wrote: > > > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: > > >> Downloading a torrent with many peers on a toshiba satellite notebook > > >> using an Atheros AR5006 wireless nic caused the following panic. This > > >> is an i386 system running 8.2-STABLE from around April 06. > > > > > > Can you reproduce that? > > > > So far I've not been able to reproduce this. > > Ok. I assume this only happens when loosing the connection and trying > to re-associate. At least that is the only possible scenario I can > think of where a timeout for mgmt frames is involved. Probably we > aren't bumping a refcount correctly or something. Actually that sounds > rather plausible as it panics exactly when trying to access ni which > should, for a station, always point to iv_bss, which can in turn be > free'd almost unconditionally if someone's telling net80211 to > associate to another (or even the same) network. Hmm.. tracing refcount > it is. > > Were you running wpa_supplicant at that point? Any messages before > the panic happened? > Yes, I'm running wpa_supplicant with the following settings: network={ ssid="x" psk="x" } Other settings for the wireless card I have in rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" ifconfig_wlan0_alias0="inet 192.168.0.12 netmask 0x" The last messages seen on the console before the panic are wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost and several UP/DOWN events. > -- > Bernhard -- Gardner Bell ___ 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: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote: > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt > wrote: > > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: > >> Downloading a torrent with many peers on a toshiba satellite notebook > >> using an Atheros AR5006 wireless nic caused the following panic. This > >> is an i386 system running 8.2-STABLE from around April 06. > > > > Can you reproduce that? > > So far I've not been able to reproduce this. Ok. I assume this only happens when loosing the connection and trying to re-associate. At least that is the only possible scenario I can think of where a timeout for mgmt frames is involved. Probably we aren't bumping a refcount correctly or something. Actually that sounds rather plausible as it panics exactly when trying to access ni which should, for a station, always point to iv_bss, which can in turn be free'd almost unconditionally if someone's telling net80211 to associate to another (or even the same) network. Hmm.. tracing refcount it is. Were you running wpa_supplicant at that point? Any messages before the panic happened? -- Bernhard ___ 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: Fatal trap 12: page fault while in kernel mode
On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt wrote: > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: >> Downloading a torrent with many peers on a toshiba satellite notebook >> using an Atheros AR5006 wireless nic caused the following panic. This >> is an i386 system running 8.2-STABLE from around April 06. > > Can you reproduce that? So far I've not been able to reproduce this. > > A comment about the relevant code says: > /* > * XXX what happens if !acked but response shows up before callback? > */ > > Guess we now know.. ;) > > -- > Bernhard > ___ 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: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: > Downloading a torrent with many peers on a toshiba satellite notebook > using an Atheros AR5006 wireless nic caused the following panic. This > is an i386 system running 8.2-STABLE from around April 06. Can you reproduce that? A comment about the relevant code says: /* * XXX what happens if !acked but response shows up before callback? */ Guess we now know.. ;) -- Bernhard ___ 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: Fatal trap 12: page fault while in kernel mode
on 26/04/2011 02:09 Gardner Bell said the following: > #6 0xc0bcbebc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #7 0xc0999329 in ieee80211_tx_mgt_timeout (arg=0xc647a000) > at /usr/src/sys/net80211/ieee80211_output.c:2478 Looks like an issue in wireless code... -- Andriy Gapon ___ 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"
Fatal trap 12: page fault while in kernel mode
Downloading a torrent with many peers on a toshiba satellite notebook using an Atheros AR5006 wireless nic caused the following panic. This is an i386 system running 8.2-STABLE from around April 06. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc647a000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0999329 stack pointer = 0x28:0xc51c1c18 frame pointer = 0x28:0xc51c1c24 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 = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc08e0d07 at kdb_backtrace+0x47 #1 0xc08b1dc7 at panic+0x117 #2 0xc0be4b43 at trap_fatal+0x323 #3 0xc0be4dc0 at trap_pfault+0x270 #4 0xc0be5305 at trap+0x465 #5 0xc0bcbebc at calltrap+0x6 #6 0xc08c508a at softclock+0x22a #7 0xc088903b at intr_event_execute_handlers+0x13b #8 0xc088a75b at ithread_loop+0x6b #9 0xc0886d51 at fork_exit+0x91 #10 0xc0bcbf34 at fork_trampoline+0x8 Uptime: 6m15s Physical memory: 2026 MB Dumping 99 MB: 84 68 52 36 20 4 #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc08b1b63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc08b1e00 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc0be4b43 in trap_fatal (frame=0xc51c1bd8, eva=3326582784) at /usr/src/sys/i386/i386/trap.c:946 #4 0xc0be4dc0 in trap_pfault (frame=0xc51c1bd8, usermode=0, eva=3326582784) at /usr/src/sys/i386/i386/trap.c:859 #5 0xc0be5305 in trap (frame=0xc51c1bd8) at /usr/src/sys/i386/i386/trap.c:532 #6 0xc0bcbebc in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc0999329 in ieee80211_tx_mgt_timeout (arg=0xc647a000) at /usr/src/sys/net80211/ieee80211_output.c:2478 #8 0xc08c508a in softclock (arg=0xc0df90e0) at /usr/src/sys/kern/kern_timeout.c:430 #9 0xc088903b in intr_event_execute_handlers (p=0xc55497f8, ie=0xc5591d00) at /usr/src/sys/kern/kern_intr.c:1220 #10 0xc088a75b in ithread_loop (arg=0xc5548070) at /usr/src/sys/kern/kern_intr.c:1233 #11 0xc0886d51 in fork_exit (callout=0xc088a6f0 , arg=0xc5548070, frame=0xc51c1d28) at /usr/src/sys/kern/kern_fork.c:845 #12 0xc0bcbf34 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 (kgdb) ___ 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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On Sun, 21 Mar 2010 00:39:01 -0400 jhell wrote: > DDB as I have heard can be configured AFAIR to textdump but I have no > knowledge of that. ddb_enable="YES" in /etc/rc.conf would be enough. But I also remove "textdump set" in kdb.enter.panic script (/etc/ddb.conf) as I prefer normal dumps (with output of ddb scripts in capture buffer) to textdumps. You can't debug textdump and crashinfo will fail too. And all info provided in textdump is retrieved from vmcore capture buffer by crashifo utility automatically. -- Mikolaj Golub ___ 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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On Thu, 18 Mar 2010 17:02, O. Hartmann wrote: In Message-Id: <4ba294f7.4030...@mail.zedat.fu-berlin.de> On 03/16/10 00:04, O. Hartmann wrote: On 03/15/10 18:30, Matthew Fleming wrote: Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew Hello. I will do as soon as possible. The box is in production at the moment and I've less time to put everything into debugging to provide more details. Just in case: does the kernel automatically save the screen with the dump information? If not, I have no other terminal facility to get a dump via the classical way. Regards, Oliver Since yesterday, this problem went away! This is mystical. After deactivating radeon.ko and the virtual box stuff I tried again with a new build of world and - voila! - everything worked again. This is strange ... Oliver If possible set a dump device and use the following in your rc.conf: crashinfo_enable="YES" dumpdev="ADD-DEVICE-HERE" After the crash happens look for core.txt.N files in /var/crash. You will probably want to look over the crash info and scrub it of vital information to comply with your companies policies. It is very verbose. DDB as I have heard can be configured AFAIR to textdump but I have no knowledge of that. Good Luck, -- jhell ___ 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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On 03/16/10 00:04, O. Hartmann wrote: On 03/15/10 18:30, Matthew Fleming wrote: Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew Hello. I will do as soon as possible. The box is in production at the moment and I've less time to put everything into debugging to provide more details. Just in case: does the kernel automatically save the screen with the dump information? If not, I have no other terminal facility to get a dump via the classical way. Regards, Oliver Since yesterday, this problem went away! This is mystical. After deactivating radeon.ko and the virtual box stuff I tried again with a new build of world and - voila! - everything worked again. This is strange ... Oliver ___ 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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On 03/15/10 18:30, Matthew Fleming wrote: Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew Hello. I will do as soon as possible. The box is in production at the moment and I've less time to put everything into debugging to provide more details. Just in case: does the kernel automatically save the screen with the dump information? If not, I have no other terminal facility to get a dump via the classical way. Regards, Oliver ___ 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: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
> Since the last update and make world on Friday, 12th March I get a crash > on one of my FreeBSD SMP boxes (it is always the same core message), > saying something about > > Fatal trap 12: page fault while in kernel mode [...] current process: 12 > (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew ___ 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"
Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) I'm sorry not providing more informations at this moment, the box is in heavy duty at the moment and I'm stuck with the kernel stuff from a day before. The box is a Intel Q6600 based box with 8 GB of memory. I use FreeBSD 8.0-STABLE/amd64 with the new AHCI/CAM facility, see dmesg attached. Regards, Oliver Copyright (c) 1992-2010 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 8.0-STABLE #13 r204911: Tue Mar 9 15:07:06 CET 2010 r...@telesto.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/TELESTO amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (3010.38-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8256184320 (7873 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xd000-0xdfff,0xfe8e-0xfe8e irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 hdac0: mem 0xfe8fc000-0xfe8f irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] uhci0: port 0xa800-0xa81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xa880-0xa89f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xac00-0xac1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfe7ffc00-0xfe7f irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac1: mem 0xfe7f8000-0xfe7fbfff irq 22 at device 27.0 on pci0 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] pcib2: irq 17 at device 28.0 on pci0 pci4: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 ahci0: mem 0xfeafe000-0xfeaf irq 16 at device 0.0 on pci3 ahci0: [ITHREAD] ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f at device 0.1 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib4: irq 16 at device 28.5 on pci0 pci2: on pcib4 mskc0: port 0xc800-0xc8ff mem 0xfe9fc000-0xfe9f irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1d:60:a6:fa:74 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] uhci3: port 0xa080-0xa09f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xa400-0xa41f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xa480-0xa49f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfe7ff800-0xfe7ffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib5: at device 30.0 on pci0 pci5: on pcib5 pci5: at device 3.0 (no driver attached) pci5: at device 4.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x941f mem 0xfe7fe800-0xfe7fefff irq 22 at device 31.2 on pci0 ahci1: [ITHREAD] ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich2: [ITHREAD] ahcich3: at channel 1 on ahci1 ahcich3: [ITHREAD] ahcich4: at chan
Re: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but not 7.0
On Fri, Mar 06, 2009 at 05:01:12PM -0500, Boris Kochergin wrote: > Gavin Atkinson wrote: > >On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote: > > > >>Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started > >>getting a bunch of these at a pretty high frequency (a few hours to a > >>day apart): > >> > >>http://acm.poly.edu/~spawk/IMG00033.jpg > >> > >>The "current process" is always httpd. They're particularly annoying > >>because the machine doesn't actually ever reboot, requiring manual > >>intervention. Reverting the kernel back to 7.0 makes the panic go away, > >>and the machine had been happily running 7.0 for about a year > >>beforehand. I realize that the photo hardly contains any useful > >>debugging information, but I was hoping it might look familiar to > >>someone. If not, I guess I'll come back with a backtrace. > >> > > > >A backtrace will almost certainly be necessary to figure out what this > >issue is, although there is a possibility that the output of > >"addr2line -e /boot/kernel/kernel.symbols 0x8:0x802d7010" > >might help, assuming you've not recompiled your kernel yet. (That > >number should be the same as the "instruction pointer" shown by the > >panic, but as the photo is quite blurred there's a chance I've got it > >wrong, if you have a better picture of it or wrote it down then use > >that) > > > >Gavin > >___ > >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" > > > Here it is, with some additional information afterward: > > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x30 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0x80293faf > stack pointer = 0x10:0x9cbaea70 > frame pointer = 0x10:0xff000fc14000 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= resume, IOPL = 0 > current process = 881 (httpd) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 1m51s > Physical memory: 8185 MB > Dumping 328 MB: 313 297 281 265 249 233 217 201 185 169 153 137 121 105 > 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:195 > #1 0xff000fc14000 in ?? () > #2 0x8025eba9 in boot (howto=260) at > /usr/src-7.1/sys/kern/kern_shutdown.c:418 > #3 0x8025efb2 in panic (fmt=0x104 bounds>) at /usr/src-7.1/sys/kern/kern_shutdown.c:574 > #4 0x803df5c3 in trap_fatal (frame=0xff000fc14000, > eva=Variable "eva" is not available. > ) at /usr/src-7.1/sys/amd64/amd64/trap.c:764 > #5 0x803e018f in trap (frame=0x9cbae9c0) at > /usr/src-7.1/sys/amd64/amd64/trap.c:290 > #6 0x803c5c4e in calltrap () at > /usr/src-7.1/sys/amd64/amd64/exception.S:209 > #7 0x80293faf in turnstile_broadcast (ts=0x0, queue=0) at > /usr/src-7.1/sys/kern/subr_turnstile.c:836 > #8 0x8025256a in _mtx_unlock_sleep (m=0x80593538, > opts=Variable "opts" is not available. > ) at /usr/src-7.1/sys/kern/kern_mutex.c:619 > #9 0x80275ed3 in __umtx_op_cv_wait (td=0x1ee, uap=Variable > "uap" is not available. > ) at /usr/src-7.1/sys/kern/kern_umtx.c:312 > #10 0x803dfb78 in syscall (frame=0x9cbaec80) at > /usr/src-7.1/sys/amd64/amd64/trap.c:907 > #11 0x803c5e5b in Xfast_syscall () at > /usr/src-7.1/sys/amd64/amd64/exception.S:330 > #12 0x000800f5354c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > The dump was difficult to acquire--the system would often lock up after > dumping only a portion of the memory it wanted to save. I can also now > trigger the panic pretty reliably using this bit of script: > > #!/usr/local/bin/bash > > for i in {1..900} > do > wget --quiet -O /dev/null http://acm.poly.edu/wiki/Hosting & > done > > ...where the URL is a MediaWiki installation on the afflicted machine. Can you, please, recompile the kernel with debugging options, and provoke the panic on it ? We need at least options INVARIANTS, INVARIANT_SUPPORT and WITNESS. pgpRs7poemfsA.pgp Description: PGP signature
Re: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but not 7.0
Gavin Atkinson wrote: On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote: Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started getting a bunch of these at a pretty high frequency (a few hours to a day apart): http://acm.poly.edu/~spawk/IMG00033.jpg The "current process" is always httpd. They're particularly annoying because the machine doesn't actually ever reboot, requiring manual intervention. Reverting the kernel back to 7.0 makes the panic go away, and the machine had been happily running 7.0 for about a year beforehand. I realize that the photo hardly contains any useful debugging information, but I was hoping it might look familiar to someone. If not, I guess I'll come back with a backtrace. A backtrace will almost certainly be necessary to figure out what this issue is, although there is a possibility that the output of "addr2line -e /boot/kernel/kernel.symbols 0x8:0x802d7010" might help, assuming you've not recompiled your kernel yet. (That number should be the same as the "instruction pointer" shown by the panic, but as the photo is quite blurred there's a chance I've got it wrong, if you have a better picture of it or wrote it down then use that) Gavin ___ 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" Here it is, with some additional information afterward: Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x8:0x80293faf stack pointer = 0x10:0x9cbaea70 frame pointer = 0x10:0xff000fc14000 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 881 (httpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 1m51s Physical memory: 8185 MB Dumping 328 MB: 313 297 281 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xff000fc14000 in ?? () #2 0x8025eba9 in boot (howto=260) at /usr/src-7.1/sys/kern/kern_shutdown.c:418 #3 0x8025efb2 in panic (fmt=0x104 bounds>) at /usr/src-7.1/sys/kern/kern_shutdown.c:574 #4 0x803df5c3 in trap_fatal (frame=0xff000fc14000, eva=Variable "eva" is not available. ) at /usr/src-7.1/sys/amd64/amd64/trap.c:764 #5 0x803e018f in trap (frame=0x9cbae9c0) at /usr/src-7.1/sys/amd64/amd64/trap.c:290 #6 0x803c5c4e in calltrap () at /usr/src-7.1/sys/amd64/amd64/exception.S:209 #7 0x80293faf in turnstile_broadcast (ts=0x0, queue=0) at /usr/src-7.1/sys/kern/subr_turnstile.c:836 #8 0x8025256a in _mtx_unlock_sleep (m=0x80593538, opts=Variable "opts" is not available. ) at /usr/src-7.1/sys/kern/kern_mutex.c:619 #9 0x80275ed3 in __umtx_op_cv_wait (td=0x1ee, uap=Variable "uap" is not available. ) at /usr/src-7.1/sys/kern/kern_umtx.c:312 #10 0x803dfb78 in syscall (frame=0x9cbaec80) at /usr/src-7.1/sys/amd64/amd64/trap.c:907 #11 0x803c5e5b in Xfast_syscall () at /usr/src-7.1/sys/amd64/amd64/exception.S:330 #12 0x000800f5354c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) The dump was difficult to acquire--the system would often lock up after dumping only a portion of the memory it wanted to save. I can also now trigger the panic pretty reliably using this bit of script: #!/usr/local/bin/bash for i in {1..900} do wget --quiet -O /dev/null http://acm.poly.edu/wiki/Hosting & done ...where the URL is a MediaWiki installation on the afflicted machine. -Boris ___ 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: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but not 7.0
On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote: > Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started > getting a bunch of these at a pretty high frequency (a few hours to a > day apart): > > http://acm.poly.edu/~spawk/IMG00033.jpg > > The "current process" is always httpd. They're particularly annoying > because the machine doesn't actually ever reboot, requiring manual > intervention. Reverting the kernel back to 7.0 makes the panic go away, > and the machine had been happily running 7.0 for about a year > beforehand. I realize that the photo hardly contains any useful > debugging information, but I was hoping it might look familiar to > someone. If not, I guess I'll come back with a backtrace. A backtrace will almost certainly be necessary to figure out what this issue is, although there is a possibility that the output of "addr2line -e /boot/kernel/kernel.symbols 0x8:0x802d7010" might help, assuming you've not recompiled your kernel yet. (That number should be the same as the "instruction pointer" shown by the panic, but as the photo is quite blurred there's a chance I've got it wrong, if you have a better picture of it or wrote it down then use that) Gavin ___ 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: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but not 7.0
On Thu, Mar 05, 2009 at 07:55:30PM -0500, Boris Kochergin wrote: > Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started > getting a bunch of these at a pretty high frequency (a few hours to a > day apart): > > http://acm.poly.edu/~spawk/IMG00033.jpg > > The "current process" is always httpd. They're particularly annoying > because the machine doesn't actually ever reboot, requiring manual > intervention. Reverting the kernel back to 7.0 makes the panic go away, > and the machine had been happily running 7.0 for about a year > beforehand. I realize that the photo hardly contains any useful > debugging information, but I was hoping it might look familiar to > someone. If not, I guess I'll come back with a backtrace. You need to provide the backtrace from kgdb. pgpifKOEedU0J.pgp Description: PGP signature
"Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but not 7.0
Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started getting a bunch of these at a pretty high frequency (a few hours to a day apart): http://acm.poly.edu/~spawk/IMG00033.jpg The "current process" is always httpd. They're particularly annoying because the machine doesn't actually ever reboot, requiring manual intervention. Reverting the kernel back to 7.0 makes the panic go away, and the machine had been happily running 7.0 for about a year beforehand. I realize that the photo hardly contains any useful debugging information, but I was hoping it might look familiar to someone. If not, I guess I'll come back with a backtrace. -Boris ___ 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"
Fatal trap 12: page fault while in kernel mode (swi6: task queue)
Can anyone help understanding the reason? # uname -rsm FreeBSD 6.4-STABLE i386 # kgdb kernel.debug /var/crash/vmcore.7 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: acd0: WARNING - PREVENT_ALLOW read data overrun 18>0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0541da5 stack pointer = 0x28:0xe5928c00 frame pointer = 0x28:0xe5928c18 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 17 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 4h16m22s Physical memory: 2031 MB Dumping 204 MB: 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/logo_saver.ko... done. Loaded symbols for /boot/kernel/logo_saver.ko #0 doadump () at pcpu.h: 165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc054d7d9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc054dba6 in panic (fmt=0xc0736cc9 "% s") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc071812c in trap_fatal (frame=0xe5928bc0, eva=0) at /usr/src/sys/i386/i386/trap.c:838 #4 0xc07177e4 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960560384, tf_esi = 4, tf_ebp = -443380712, tf_isp = -443380756, tf_ebx = -942867596, tf_edx = 6, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068229211, tf_cs = 32, tf_eflags = 65538, tf_esp = -942867596, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:270 #5 0xc06ff98a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc0541da5 in _mtx_lock_sleep (m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 #7 0xc054ca79 in _sema_post (sema=0xc7ccfb74, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79 #8 0xc04705e3 in ata_completed (context=0xc7ccfb28, dummy=1) at /usr/src/sys/dev/ata/ata-queue.c:481 #9 0xc057547d in taskqueue_run (queue=0xc6c8a000) at /usr/src/sys/kern/subr_taskqueue.c:257 #10 0xc0575793 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:299 #11 0xc052ff1b in ithread_execute_handlers (p=0xc6bef860, ie=0xc6c44e80) at /usr/src/sys/kern/kern_intr.c:682 #12 0xc0530077 in ithread_loop (arg=0xc6c62510) at /usr/src/sys/kern/kern_intr.c:766 #13 0xc052e800 in fork_exit (callout=0xc0530010 , arg=0x1, frame=0x1) at /usr/src/sys/kern/kern_fork.c:788 #14 0xc06ff9ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) frame 6 #6 0xc0541da5 in _mtx_lock_sleep (m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 546 owner = (struct thread *)(v & MTX_FLAGMASK); (kgdb) list 541 #if defined(SMP) && !defined (NO_ADAPTIVE_MUTEXES) 542 /* 543 * If the current owner of the lock is executing on another 544 * CPU, spin instead of blocking. 545 */ 546 owner = (struct thread *)(v & MTX_FLAGMASK); 547 #ifdef ADAPTIVE_GIANT 548 if (TD_IS_RUNNING(owner)) { 549 #else 550 if (m != &Giant && TD_IS_RUNNING (owner)) { ___ 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"
Fatal trap 12: page fault while in kernel mode
Yay, crash dumps! How else can I help? FreeBSD eyrie.homenet 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Sun Dec 30 21:50:28 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ RC20071223 i386 2) eyrie:/usr/obj/usr/src/sys/RC20071223# kgdb kernel.debug /var/crash/ vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x35000214 fault code = supervisor write, page not present instruction pointer = 0x20:0xc080c74f stack pointer = 0x28:0xd7d25b4c frame pointer = 0x28:0xd7d25b5c 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 = 3422 (java) trap number = 12 panic: page fault Uptime: 25d0h1m6s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc074873d in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc0748cd3 in panic (fmt=0xc0b8a6e0 "page fault") at /usr/src/sys/ kern/kern_shutdown.c:565 #3 0xc0a1bf24 in trap_fatal (frame=0xd7d25b0c, eva=889192980) at /usr/ src/sys/i386/i386/trap.c:838 #4 0xc0a1c1dd in trap_pfault (frame=0xd7d25b0c, usermode=0, eva=889192980) at /usr/src/sys/i386/i386/trap.c:745 #5 0xc0a1c5d0 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1012545064, tf_esi = -1061606752, tf_ebp = -674079908, tf_isp = -674079944, tf_ebx = -1012545064, tf_edx = 889192976, tf_ecx = -1001224928, tf_eax = 394565837, tf_trapno = 12, tf_err = 2, tf_eip = -1065302193, tf_cs = 32, tf_eflags = 66050, tf_esp = -674079908, tf_ss = -1066157083}) at / usr/src/sys/i386/i386/trap.c:435 #6 0xc0a0778a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc080c74f in in_pcbremlists (inp=0xc3a5c9d8) at /usr/src/sys/ netinet/in_pcb.c:1155 #8 0xc080c7dd in in_pcbdetach (inp=0xc3a5c9d8) at /usr/src/sys/ netinet/in_pcb.c:709 #9 0xc0834de7 in udp_detach (so=0x178498cd) at /usr/src/sys/netinet/ udp_usrreq.c:1071 #10 0xc078f3c7 in soclose (so=0xc485542c) at /usr/src/sys/kern/ uipc_socket.c:459 #11 0xc077a200 in soo_close (fp=0xc4aa5ca8, td=0xc50bca80) at /usr/src/ sys/kern/sys_socket.c:317 #12 0xc071abd3 in fdrop_locked (fp=0xc4aa5ca8, td=0xc50bca80) at file.h:296 #13 0xc071b0e2 in closef (fp=0xc4aa5ca8, td=0xc50bca80) at /usr/src/ sys/kern/kern_descrip.c:1933 #14 0xc071bca9 in kern_close (td=0xc50bca80, fd=57) at /usr/src/sys/ kern/kern_descrip.c:1023 #15 0xc0a1ca20 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 376516096, tf_esi = 0, tf_ebp = -1112515544, tf_isp = -674079388, tf_ebx = 672784448, tf_edx = 1, tf_ecx = -2147482943, tf_eax = 6, tf_trapno = 0, tf_err = 2, tf_eip = 672723975, tf_cs = 51, tf_eflags = 535, tf_esp = -1112515572, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984 #16 0xc0a077df in Xint0x80_syscall () at /usr/src/sys/i386/i386/ exception.s:200 #17 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 14 #14 0xc071bca9 in kern_close (td=0xc50bca80, fd=57) at /usr/src/sys/ kern/kern_descrip.c:1023 1023error = closef(fp, td); (kgdb) l 1018 * for the new fd. 1019 */ 1020knote_fdclose(td, fd); 1021FILEDESC_UNLOCK(fdp); 1022 1023error = closef(fp, td); 1024if (holdleaders) { 1025FILEDESC_LOCK_FAST(fdp); 1026fdp->fd_holdleaderscount--; 1027if (fdp->fd_holdleaderscount == 0 && (kgdb) frame 15 #15 0xc0a1ca20 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 376516096, tf_esi = 0, tf_ebp = -1112515544, tf_isp = -674079388, tf_ebx = 672784448, tf_edx = 1, tf_ecx = -2147482943, tf_eax = 6, tf_trapno = 0, tf_err = 2, tf_eip = 672723975, tf_cs = 51, tf_eflags = 535, tf_esp = -1112515572, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984 984 erro
Re: Fatal trap 12: page fault while in kernel mode
Kai Storbeck wrote: > Hi all, > > Somewhere our IMAP software triggers this panic, and after some > searching on my part I've found this report: kern/113823 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=113823&cat=kern) > > The software I am running is Dovecot serving IMAP to endusers and > webmail clients. > > Perhaps one of the mutex hackers can dive into this problem, I can > help with more details if needed. > > > Kind regards, > Kai > > > 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: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 06 > fault virtual address = 0x104E > fault code = supervisor read, page not presentx > instruction pointer = 0x20:0xc0668f3dp > stack pointer = 0x28:0xe8916c70e > frame pointer = 0x28:0xe8916c7cn > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= resume, IOPL = 0s > current process = 9 (thread taskq)i > trap number = 12v > panic: page faulte > cpuid = 2 > timeout(9) function: 0xc071a560(0) 0.028705867 s > Uptime: 2d20h58m42s > Dumping 3327 MB (2 chunks) > chunk 0: 1MB (154 pages) ... ok > chunk 1: 3327MB (851568 pages) 3311 3295 3279 3263 3247 3231 3215 > 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 > 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 > 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 > 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 > 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 > 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 > 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 > 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 > 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 > 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 > 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 > 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 > 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 > 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0670918 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 > #2 0xc0670bfa in panic (fmt=0xc08d0a0d "%s") > at ../../../kern/kern_shutdown.c:565 > #3 0xc087819c in trap_fatal (frame=0xe8916c30, eva=260) > at ../../../i386/i386/trap.c:837 > #4 0xc087794a in trap (frame= > {tf_fs = -393150456, tf_es = -1064959960, tf_ds = -393150424, > tf_edi = -935090688, tf_esi = -900488032, tf_ebp = -393122692, tf_isp > = -393122724, tf_ebx = 4, tf_edx = 6, tf_ecx = 2, tf_eax = 1, > tf_trapno = 12, tf_err = 0, tf_eip = -1067020483, tf_cs = 32, > tf_eflags = 65538, tf_esp = 1714, tf_ss = -1064340051}) > at ../../../i386/i386/trap.c:270 > #5 0xc08649ea in calltrap () at ../../../i386/i386/exception.s:139 > #6 0xc0668f3d in _mtx_lock_sleep (m=0xca53a4a0, tid=3359876608, opts=0, > file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714) > at ../../../kern/kern_mutex.c:546 > #7 0xc0668b93 in _mtx_lock_flags (m=0x2, opts=0, > file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714) > at ../../../kern/kern_mutex.c:288 > #8 0xc06b204b in unp_gc (arg=0x0, pending=1) > at ../../../kern/uipc_usrreq.c:1714 > #9 0xc068f7c0 in taskqueue_run (queue=0xc843ca80) > at ../../../kern/subr_taskqueue.c:257 > #10 0xc068fb3e in taskqueue_thread_loop (arg=0x1) > at ../../../kern/subr_taskqueue.c:376 > #11 0xc065d184 in fork_exit (callout=0xc068faf4 , > arg=0xc09df4e8, frame=0xe8916d38) at ../../../kern/kern_fork.c:821 > #12 0xc0864a4c in fork_trampoline () at > ../../../i386/i386/exception.s:208 > (kgdb) > I was getting this exact panic pretty much every week, I had 6.2-RELEASE installed on about 10 machines. The one machine which was getting the panic most often I upgraded to 6.2-STABLE on 'Mon Ap
Re: Fatal trap 12: page fault while in kernel mode
Hi all, Somewhere our IMAP software triggers this panic, and after some searching on my part I've found this report: kern/113823 (http://www.freebsd.org/cgi/query-pr.cgi?pr=113823&cat=kern) The software I am running is Dovecot serving IMAP to endusers and webmail clients. Perhaps one of the mutex hackers can dive into this problem, I can help with more details if needed. Kind regards, Kai 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: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x104E fault code = supervisor read, page not presentx instruction pointer = 0x20:0xc0668f3dp stack pointer = 0x28:0xe8916c70e frame pointer = 0x28:0xe8916c7cn code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0s current process = 9 (thread taskq)i trap number = 12v panic: page faulte cpuid = 2 timeout(9) function: 0xc071a560(0) 0.028705867 s Uptime: 2d20h58m42s Dumping 3327 MB (2 chunks) chunk 0: 1MB (154 pages) ... ok chunk 1: 3327MB (851568 pages) 3311 3295 3279 3263 3247 3231 3215 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0670918 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc0670bfa in panic (fmt=0xc08d0a0d "%s") at ../../../kern/kern_shutdown.c:565 #3 0xc087819c in trap_fatal (frame=0xe8916c30, eva=260) at ../../../i386/i386/trap.c:837 #4 0xc087794a in trap (frame= {tf_fs = -393150456, tf_es = -1064959960, tf_ds = -393150424, tf_edi = -935090688, tf_esi = -900488032, tf_ebp = -393122692, tf_isp = -393122724, tf_ebx = 4, tf_edx = 6, tf_ecx = 2, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067020483, tf_cs = 32, tf_eflags = 65538, tf_esp = 1714, tf_ss = -1064340051}) at ../../../i386/i386/trap.c:270 #5 0xc08649ea in calltrap () at ../../../i386/i386/exception.s:139 #6 0xc0668f3d in _mtx_lock_sleep (m=0xca53a4a0, tid=3359876608, opts=0, file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714) at ../../../kern/kern_mutex.c:546 #7 0xc0668b93 in _mtx_lock_flags (m=0x2, opts=0, file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714) at ../../../kern/kern_mutex.c:288 #8 0xc06b204b in unp_gc (arg=0x0, pending=1) at ../../../kern/uipc_usrreq.c:1714 #9 0xc068f7c0 in taskqueue_run (queue=0xc843ca80) at ../../../kern/subr_taskqueue.c:257 #10 0xc068fb3e in taskqueue_thread_loop (arg=0x1) at ../../../kern/subr_taskqueue.c:376 #11 0xc065d184 in fork_exit (callout=0xc068faf4 , arg=0xc09df4e8, frame=0xe8916d38) at ../../../kern/kern_fork.c:821 #12 0xc0864a4c in fork_trampoline () at ../../../i386/i386/exception.s:208 (kgdb) -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [vfs_bio] Re: Fatal trap 12: page fault while in kernel mode (with potential cause)
On Sun, Jun 24, 2007 at 12:30:20AM -0400, Adam McDougall wrote: On Mon, Apr 23, 2007 at 11:55:52AM -0400, Kris Kennaway wrote: On Mon, Apr 23, 2007 at 05:35:47PM +0200, Kai wrote: > On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: > > On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > > > > > Hello all, > > > > > > We're running into regular panics on our webserver after upgrading > > > from 4.x to 6.2-stable: > > > > Hi all, > > To continue this story, a colleague wrote a small program in C that launches > 40 threads to randomly append and write to 10 files on an NFS mounted > filesystem. > > If I keep removing the files on one of the other machines in a while loop, > the first system panics: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06bdefa > stack pointer = 0x28:0xeb9f69b8 > frame pointer = 0x28:0xeb9f69c4 > 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 = 73626 (nfscrash) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3h2m14s > > Sounds like a nice denial of service problem. I can hand the program to > developers on request. Please send it to me. Panics are always much easier to get fixed if they come with a test case that developer can use to reproduce it. Kris I have been working on this problem all weekend and I have a strong hunch at this point that it is a result of 1.424 of sys/kern/vfs_bio.c which was between FreeBSD 5.1 and 5.2. This hunch is currently being verified by a system that was cvsupped to code just before 1.424, and it has been running about 7 times longer than the usual time required to crash. I am currently attempting to craft a patch for 6.2 that essentially backs out the change to see if that works, but if this information can help send a FreeBSD developer down the right trail to a proper fix, great. I will follow up with more detailed findings and results tonight or soon. links: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.423;r2=1.424 related to 1.424: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.420&r2=1.421 Commit emails: http://docs.freebsd.org/cgi/mid.cgi?200311150845.hAF8jawU027349 http://docs.freebsd.org/cgi/mid.cgi?20030445.hAB4jbYw093253 ___ If I turn on invariants, I get the following panic instead, much quicker, and happens with at least as far back as 5.0-RELEASE: panic: bundirty: buffer 0x8e2e95f8 still on queue 1 cpuid = 1 Uptime: 35s Dumping 511 MB (2 chunks) chunk 0: 1MB (153 pages) ... ok chunk 1: 511MB (130816 pages) 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x8028d699 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x8028d12b in panic (fmt=0x80443458 "bundirty: buffer %p still on queue %d") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0x802e1e78 in bundirty (bp=0x8e2e95f8) at /usr/src/sys/kern/vfs_bio.c:1055 #4 0x802e3eb1 in brelse (bp=0x8e2e95f8) at /usr/src/sys/kern/vfs_bio.c:1370 #5 0x803550e8 in nfs_writebp (bp=0x8e2e95f8, force=0, td=0x0) at /usr/src/sys/nfsclient/nfs_vnops.c:3005 #6 0x802e5197 in getblk (vp=0xff000c23e5d0, blkno=0, size=14400, slpflag=256, slptimeo=0, flags=0) at buf.h:412 #7 0x80344f13 in nfs_getcacheblk (vp=0xff000c23e5d0, bn=0, size=14400, td=0xff0015b274c0) at /usr/src/sys/nfsclient/nfs_bio.c:1252 #8 0x8034616c in nfs_write (ap=0x0) at /usr/src/sys/nfsclient/nfs_bio.c:1068 #9 0x80405ee4 in VOP_WRITE_APV (vop=0x805a0260, a=0x976bfa10) at vnode_if.c:698 #10 0x80303d2c in vn_write (fp=0xff000f524000, uio=0x976bfb50, active_cred=0x0, flags=0, td=0xff0015b274c0) at vnode_if.h:372 #11 0x802ba2e5 in dofilewrite (td=0xff0015b274c0, fd=3, fp=0xff000f524000, auio=0x976bfb50, offset=0, flags=0) at file.h:253 #12 0x802ba5e1 in kern_writev (td=0xff0015b274c0, fd=3, auio=0x976bfb50) at /us
[vfs_bio] Re: Fatal trap 12: page fault while in kernel mode (with potential cause, fix?)
On Mon, Apr 23, 2007 at 11:55:52AM -0400, Kris Kennaway wrote: On Mon, Apr 23, 2007 at 05:35:47PM +0200, Kai wrote: > On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: > > On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > > > > > Hello all, > > > > > > We're running into regular panics on our webserver after upgrading > > > from 4.x to 6.2-stable: > > > > Hi all, > > To continue this story, a colleague wrote a small program in C that launches > 40 threads to randomly append and write to 10 files on an NFS mounted > filesystem. > > If I keep removing the files on one of the other machines in a while loop, > the first system panics: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06bdefa > stack pointer = 0x28:0xeb9f69b8 > frame pointer = 0x28:0xeb9f69c4 > 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 = 73626 (nfscrash) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3h2m14s > > Sounds like a nice denial of service problem. I can hand the program to > developers on request. Please send it to me. Panics are always much easier to get fixed if they come with a test case that developer can use to reproduce it. Kris I have been working on this problem all weekend and I have a strong hunch at this point that it is a result of 1.424 of sys/kern/vfs_bio.c which was between FreeBSD 5.1 and 5.2. This hunch is currently being verified by a system that was cvsupped to code just before 1.424, and it has been running about 7 times longer than the usual time required to crash. I am currently attempting to craft a patch for 6.2 that essentially backs out the change to see if that works, but if this information can help send a FreeBSD developer down the right trail to a proper fix, great. I will follow up with more detailed findings and results tonight or soon. links: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.423;r2=1.424 related to 1.424: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.420&r2=1.421 Commit emails: http://docs.freebsd.org/cgi/mid.cgi?200311150845.hAF8jawU027349 http://docs.freebsd.org/cgi/mid.cgi?20030445.hAB4jbYw093253 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Mon, Apr 23, 2007 at 05:35:47PM +0200, Kai wrote: > On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: > > On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > > > > > Hello all, > > > > > > We're running into regular panics on our webserver after upgrading > > > from 4.x to 6.2-stable: > > > > Hi all, > > To continue this story, a colleague wrote a small program in C that launches > 40 threads to randomly append and write to 10 files on an NFS mounted > filesystem. > > If I keep removing the files on one of the other machines in a while loop, > the first system panics: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06bdefa > stack pointer = 0x28:0xeb9f69b8 > frame pointer = 0x28:0xeb9f69c4 > 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 = 73626 (nfscrash) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3h2m14s > > Sounds like a nice denial of service problem. I can hand the program to > developers on request. Please send it to me. Panics are always much easier to get fixed if they come with a test case that developer can use to reproduce it. Kris pgplSEXbF4bW4.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode
On Mon, Apr 23, 2007 at 01:27:27PM +0100, Tom Judge wrote: > Kai wrote: > >On Thu, Apr 19, 2007 at 04:14:23PM +0200, Christian Walther wrote: > > > >>On 19/04/07, Kai <[EMAIL PROTECTED]> wrote: > >> > >>>On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > >>> > >>>>Hello all, > >>>> > >>>>We're running into regular panics on our webserver after upgrading > >>>>from 4.x to 6.2-stable: > >>>> > >>>Hi Again, > >>> > >>>The panics keep happening, so I'm trying alternate kernel setups. This > >>>is a > >>>trace of a panic on a default SMP kernel with debugging symbols. > >>> > >>>I'm At a loss on how to progress at this point, perhaps someone can help > >>>me > >>>please? > >>> > >>[snip] > >> > >>>Fatal trap 12: page fault while in kernel mode > >>>cpuid = 0; apic id = 00 > >>>fault virtual address = 0x34 > >>>fault code = supervisor read, page not present > >>>instruction pointer = 0x20:0xc06bdefa > >>>stack pointer = 0x28:0xeb9cf938 > >>>frame pointer = 0x28:0xeb9cf944 > >>>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 = 13577 (perl5.8.8) > >>>trap number = 12 > >>>panic: page fault > >>> > >>Is this perl derived from ports? And if so, did you rebuild it after you > >>upgraded to 6.2? Or is maybe FreeBSD 4.x binary compatibility missing from > >>your kernel? > >> > > > >Hi Chris, > > > >Thanks for your reply; The upgrade i'm talking about is just a term > >describing that we switched from FreeBSD 4.10 to 6.2. Its new hardware; its > >hardware on which FreeBSD 4.10 will not run. > >So in effect its not an upgrade, though the symptoms did not show on > >apache-1.3.37 + nfsmounted homepages under FreeBSD 4.10. > > > >If perl would be the problem, the OS shouldn't panic IMHO. Perl in this > >case > >is writing a fairly large guestbook file (eg. 2 Mb), and does this through > >perls own: > > open(BOOK, "+<$file") or die; > > > >This $file is located on an NFS mounted filesystem. It'll get read and > >written. > > > >The NFS filesystem is mounted with "rw,nosuid,intr,bg,resvport,nfsv3". I > >have tried mounting without intr, but panics keep happening. The NFS server > >is a Netapp filer. > > > >This is a production environment, so I can't go updating to the latest > >current. > > > >Kai > > > > Just a me too, however I seem to get these crashes from random applications. > > See my last post for back traces. Just to clarify, your problem appears to have nothing to do with the above report. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: > On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > > > Hello all, > > > > We're running into regular panics on our webserver after upgrading > > from 4.x to 6.2-stable: > Hi all, To continue this story, a colleague wrote a small program in C that launches 40 threads to randomly append and write to 10 files on an NFS mounted filesystem. If I keep removing the files on one of the other machines in a while loop, the first system panics: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06bdefa stack pointer = 0x28:0xeb9f69b8 frame pointer = 0x28:0xeb9f69c4 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 = 73626 (nfscrash) trap number = 12 panic: page fault cpuid = 1 Uptime: 3h2m14s Sounds like a nice denial of service problem. I can hand the program to developers on request. Regards, Kai Storbeck -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > Hello all, > > We're running into regular panics on our webserver after upgrading > from 4.x to 6.2-stable: Hi Again, The panics keep happening, so I'm trying alternate kernel setups. This is a trace of a panic on a default SMP kernel with debugging symbols. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 ^ fault code = supervisor read, page not present ^^^ #7 0xc06bdefa in vfs_vmio_release (bp=0xdbec2560) at atomic.h:146 #8 0xc06be728 in getnewbuf (slpflag=0, slptimeo=0, size=6585, maxsize=8192) at ../../../kern/vfs_bio.c:1779 #9 0xc06bfccc in getblk (vp=0xca2cfdd0, blkno=8438, size=6585, slpflag=0, slptimeo=0, flags=0) at ../../../kern/vfs_bio.c:2497 #10 0xc075ad41 in nfs_getcacheblk (vp=0xca2cfdd0, bn=8438, size=6585, td=0xc8cd1c00) at ../../../nfsclient/nfs_bio.c:1261 #11 0xc075a978 in nfs_write (ap=0x0) at ../../../nfsclient/nfs_bio.c:1069 #12 0xc089fde6 in VOP_WRITE_APV (vop=0xc0984440, a=0xeb9cfbec) at vnode_if.c:698 #13 0xc06dbb26 in vn_write (fp=0xc8940e10, uio=0xeb9cfcbc, active_cred=0xc89ee880, flags=0, td=0xc8cd1c00) at vnode_if.h:372 #14 0xc0698f63 in dofilewrite (td=0xc8cd1c00, fd=5, fp=0xc8940e10, auio=0xeb9cfcbc, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:252 #15 0xc0698e07 in kern_writev (td=0xc8cd1c00, fd=5, auio=0xeb9cfcbc) at ../../../kern/sys_generic.c:402 #16 0xc0698d2d in write (td=0xc8cd1c00, uap=0xc8cd1c00) at ../../../kern/sys_generic.c:326 I believe I am seeing the same panic on my samba servers, sometimes from NFS and sometimes from FFS. I see it on i386 and amd64 alike. I do not know how to manually trigger it, but I do have two servers sitting in DDB from after the panic, waiting for more experienced hands to continue the debugging from what I have already done. I filed a PR with as much details as I could think of, and it would be wonderful if someone could look at it and either tell me what else to do in DDB, or I could provide remote access to the existing DDB session to a developer. Both servers crashed in vfs_vmio_release but one was through NFS and one through FFS. pr 111831 http://docs.freebsd.org/cgi/mid.cgi?200704181924.l3IJOMUL088901 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
Kai wrote: On Thu, Apr 19, 2007 at 04:14:23PM +0200, Christian Walther wrote: On 19/04/07, Kai <[EMAIL PROTECTED]> wrote: On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: Hello all, We're running into regular panics on our webserver after upgrading from 4.x to 6.2-stable: Hi Again, The panics keep happening, so I'm trying alternate kernel setups. This is a trace of a panic on a default SMP kernel with debugging symbols. I'm At a loss on how to progress at this point, perhaps someone can help me please? [snip] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06bdefa stack pointer = 0x28:0xeb9cf938 frame pointer = 0x28:0xeb9cf944 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 = 13577 (perl5.8.8) trap number = 12 panic: page fault Is this perl derived from ports? And if so, did you rebuild it after you upgraded to 6.2? Or is maybe FreeBSD 4.x binary compatibility missing from your kernel? Hi Chris, Thanks for your reply; The upgrade i'm talking about is just a term describing that we switched from FreeBSD 4.10 to 6.2. Its new hardware; its hardware on which FreeBSD 4.10 will not run. So in effect its not an upgrade, though the symptoms did not show on apache-1.3.37 + nfsmounted homepages under FreeBSD 4.10. If perl would be the problem, the OS shouldn't panic IMHO. Perl in this case is writing a fairly large guestbook file (eg. 2 Mb), and does this through perls own: open(BOOK, "+<$file") or die; This $file is located on an NFS mounted filesystem. It'll get read and written. The NFS filesystem is mounted with "rw,nosuid,intr,bg,resvport,nfsv3". I have tried mounting without intr, but panics keep happening. The NFS server is a Netapp filer. This is a production environment, so I can't go updating to the latest current. Kai Just a me too, however I seem to get these crashes from random applications. See my last post for back traces. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Thu, Apr 19, 2007 at 04:14:23PM +0200, Christian Walther wrote: > On 19/04/07, Kai <[EMAIL PROTECTED]> wrote: > >On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > >> > >> Hello all, > >> > >> We're running into regular panics on our webserver after upgrading > >> from 4.x to 6.2-stable: > > > >Hi Again, > > > >The panics keep happening, so I'm trying alternate kernel setups. This is a > >trace of a panic on a default SMP kernel with debugging symbols. > > > >I'm At a loss on how to progress at this point, perhaps someone can help me > >please? > [snip] > > > >Fatal trap 12: page fault while in kernel mode > >cpuid = 0; apic id = 00 > >fault virtual address = 0x34 > >fault code = supervisor read, page not present > >instruction pointer = 0x20:0xc06bdefa > >stack pointer = 0x28:0xeb9cf938 > >frame pointer = 0x28:0xeb9cf944 > >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 = 13577 (perl5.8.8) > >trap number = 12 > >panic: page fault > > Is this perl derived from ports? And if so, did you rebuild it after you > upgraded to 6.2? Or is maybe FreeBSD 4.x binary compatibility missing from > your kernel? Hi Chris, Thanks for your reply; The upgrade i'm talking about is just a term describing that we switched from FreeBSD 4.10 to 6.2. Its new hardware; its hardware on which FreeBSD 4.10 will not run. So in effect its not an upgrade, though the symptoms did not show on apache-1.3.37 + nfsmounted homepages under FreeBSD 4.10. If perl would be the problem, the OS shouldn't panic IMHO. Perl in this case is writing a fairly large guestbook file (eg. 2 Mb), and does this through perls own: open(BOOK, "+<$file") or die; This $file is located on an NFS mounted filesystem. It'll get read and written. The NFS filesystem is mounted with "rw,nosuid,intr,bg,resvport,nfsv3". I have tried mounting without intr, but panics keep happening. The NFS server is a Netapp filer. This is a production environment, so I can't go updating to the latest current. Kai -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On 19/04/07, Kai <[EMAIL PROTECTED]> wrote: On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > Hello all, > > We're running into regular panics on our webserver after upgrading > from 4.x to 6.2-stable: Hi Again, The panics keep happening, so I'm trying alternate kernel setups. This is a trace of a panic on a default SMP kernel with debugging symbols. I'm At a loss on how to progress at this point, perhaps someone can help me please? [snip] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06bdefa stack pointer = 0x28:0xeb9cf938 frame pointer = 0x28:0xeb9cf944 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 = 13577 (perl5.8.8) trap number = 12 panic: page fault Is this perl derived from ports? And if so, did you rebuild it after you upgraded to 6.2? Or is maybe FreeBSD 4.x binary compatibility missing from your kernel? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > Hello all, > > We're running into regular panics on our webserver after upgrading > from 4.x to 6.2-stable: Hi Again, The panics keep happening, so I'm trying alternate kernel setups. This is a trace of a panic on a default SMP kernel with debugging symbols. I'm At a loss on how to progress at this point, perhaps someone can help me please? System info: uname -a reports FreeBSD webserver 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #0: Thu Apr 19 11:37:34 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SMP i386 Backtrace: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06bdefa stack pointer = 0x28:0xeb9cf938 frame pointer = 0x28:0xeb9cf944 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 = 13577 (perl5.8.8) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h37m29s Dumping 3070 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3071MB (786016 pages) 3055 3039 3023 3007 2991 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc067550a in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc0675831 in panic (fmt=0xc08e46dd "%s") at ../../../kern/kern_shutdown.c:565 #3 0xc088e29c in trap_fatal (frame=0xeb9cf8f8, eva=52) at ../../../i386/i386/trap.c:837 #4 0xc088dfdb in trap_pfault (frame=0xeb9cf8f8, usermode=0, eva=52) at ../../../i386/i386/trap.c:745 #5 0xc088dc15 in trap (frame= {tf_fs = 8, tf_es = -606142424, tf_ds = -926089176, tf_edi = #-605280928, tf_esi = -605280928, tf_ebp = -342034108, tf_isp = -342034140, tf_ebx = -605280928, tf_edx = 4, tf_ecx = -926082048, tf_eax = 0, tf_trapno #= 12, tf_err = 0, tf_eip = -1066672390, tf_cs = 32, tf_eflags = 66050, tf_esp = -605280928, tf_ss = -605280928}) at ../../../i386/i386/trap.c:435 #6 0xc0879d4a in calltrap () at ../../../i386/i386/exception.s:139 #7 0xc06bdefa in vfs_vmio_release (bp=0xdbec2560) at atomic.h:146 #8 0xc06be728 in getnewbuf (slpflag=0, slptimeo=0, size=6585, maxsize=8192) at ../../../kern/vfs_bio.c:1779 #9 0xc06bfccc in getblk (vp=0xca2cfdd0, blkno=8438, size=6585, slpflag=0, slptimeo=0, flags=0) at ../../../kern/vfs_bio.c:2497 #10 0xc075ad41 in nfs_getcacheblk (vp=0xca2cfdd0, bn=8438, size=6585, td=0xc8cd1c00) at ../../../nfsclient/nfs_bio.c:1261 #11 0xc075a978 in nfs_write (ap=0x0) at ../../../nfsclient/nfs_bio.c:1069 #12 0xc089fde6 in VOP_WRITE_APV (vop=0xc0984440, a=0xeb9cfbec) at vnode_if.c:698 #13 0xc06dbb26 in vn_write (fp=0xc8940e10, uio=0xeb9cfcbc, active_cred=0xc89ee880, flags=0, td=0xc8cd1c00) at vnode_if.h:372 #14 0xc0698f63 in dofilewrite (td=0xc8cd1c00, fd=5, fp=0xc8940e10, auio=0xeb9cfcbc, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:252 #15 0xc0698e07 in kern_writev (td=0xc8cd1c00, fd=5, auio=0xeb9cfcbc) at ../../../kern/sys_generic.c:402 #16 0xc0698d2d in write (td=0xc8cd1c00, uap=0xc8cd1c00) at ../../../kern/sys_generic.c:326 #17 0xc088e5e3 in syscall (frame= {tf_fs = 136970299, tf_es = 673775675, tf_ds = -1078001605, tf_edi = #137019392, tf_esi = 673803768,
6.2-RELEASE + MPD 4.1 = Fatal trap 12: page fault while in kernel mode
Hi! Yesterday I've updated my FreeBSD 6.0-RELEASE + mpd-4.0b4 up to FreeBSD 6.2-RELEASE + mpd-4.1. And today I have a Fatal Trap. Could you please help me to figure out what the problem consists in? I folowed instructions described in handbook: [intel][root]~# kgdb /usr/obj/usr/src/sys/router/kernel.debug /var/crash/vmcore.77 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: <6>external: promiscuous mode enabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0596202 stack pointer = 0x28:0xe4fabb18 frame pointer = 0x28:0xe4fabb4c 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 = 12 (swi4: clock sio) Dumping 2047 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 2047MB (524032 pages) 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04772e7 in db_fncall (dummy1=-1067884030, dummy2=0, dummy3=1, dummy4=0xe4fab92c "") at /usr/src/sys/ddb/db_command.c:492 #2 0xc0477780 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350 #3 0xc0479600 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #4 0xc0572252 in kdb_trap (type=0, code=0, tf=0xe4fabad8) at /usr/src/sys/kern/subr_kdb.c:473 #5 0xc06ffae4 in trap_fatal (frame=0xe4fabad8, eva=12) at /usr/src/sys/i386/i386/trap.c:828 #6 0xc06ffdeb in trap_pfault (frame=0xe4fabad8, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:745 #7 0xc0700235 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1352, tf_esi = 0, tf_ebp = -453330100, tf_isp = -453330172, tf_ebx = -940045504, tf_edx = 20, tf_ecx = 1396, tf_eax = 44, tf_trapno = 12, tf_err = 0, tf_eip = -1067884030, tf_cs = 32, tf_eflags = 66054, tf_esp = 256, tf_ss = -453330040}) at /usr/src/sys/i386/i386/trap.c:435 #8 0xc06ec0ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0596202 in m_copym (m=0x0, off0=1396, len=1376, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:397 #10 0xc061804a in ip_fragment (ip=0xcd365820, m_frag=0xe4fabc20, mtu=-940045504, if_hwassist_flags=0, sw_csum=3073) at /usr/src/sys/netinet/ip_output.c:975 #11 0xc061a846 in ip_output (m=0xc6894300, opt=0xcd365820, ro=0xe4fabbec, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:804 #12 0xc0609742 in dummynet_send (m=0xc66b9e00) at /usr/src/sys/netinet/ip_dummynet.c:771 #13 0xc0609a32 in dummynet (unused=0x0) at /usr/src/sys/netinet/ip_dummynet.c:753 #14 0xc0563590 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #15 0xc053a15f in ithread_loop (arg=0xc6391760) at /usr/src/sys/kern/kern_intr.c:682 #16 0xc0538cbd in fork_exit (callout=0xc053a040 , arg=0x2c, frame=0x2c) at /usr/src/sys/kern/kern_fork.c:821 #17 0xc06ec14c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) list *0xc0596202 0xc0596202 is in m_copym (/usr/src/sys/kern/uipc_mbuf.c:400). 395 MBUF_CHECKSLEEP(wait); 396 if (off == 0 && m->m_flags & M_PKTHDR) 397 copyhdr = 1; 398 while (off > 0) { 399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 400 if (off < m->m_len) 401 break; 402 off -= m->m_len; 403 m = m->m_next; 404 } kernel config file== machine i386 cpu I686_CPU ident router makeopti
6.2-RELEASE + MPD 4.1 = Fatal trap 12: page fault while in kernel mode
Hi! Yesterday I've updated my FreeBSD 6.0-RELEASE + mpd-4.0b4 up to FreeBSD 6.2-RELEASE + mpd-4.1. And today I have a Fatal Trap. Could you please help me to figure out what the problem consists in? I folowed instructions described in handbook: [intel][root]~# kgdb /usr/obj/usr/src/sys/router/kernel.debug /var/crash/vmcore.77 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: <6>external: promiscuous mode enabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0596202 stack pointer = 0x28:0xe4fabb18 frame pointer = 0x28:0xe4fabb4c 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 = 12 (swi4: clock sio) Dumping 2047 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 2047MB (524032 pages) 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04772e7 in db_fncall (dummy1=-1067884030, dummy2=0, dummy3=1, dummy4=0xe4fab92c "") at /usr/src/sys/ddb/db_command.c:492 #2 0xc0477780 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350 #3 0xc0479600 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #4 0xc0572252 in kdb_trap (type=0, code=0, tf=0xe4fabad8) at /usr/src/sys/kern/subr_kdb.c:473 #5 0xc06ffae4 in trap_fatal (frame=0xe4fabad8, eva=12) at /usr/src/sys/i386/i386/trap.c:828 #6 0xc06ffdeb in trap_pfault (frame=0xe4fabad8, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:745 #7 0xc0700235 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1352, tf_esi = 0, tf_ebp = -453330100, tf_isp = -453330172, tf_ebx = -940045504, tf_edx = 20, tf_ecx = 1396, tf_eax = 44, tf_trapno = 12, tf_err = 0, tf_eip = -1067884030, tf_cs = 32, tf_eflags = 66054, tf_esp = 256, tf_ss = -453330040}) at /usr/src/sys/i386/i386/trap.c:435 #8 0xc06ec0ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0596202 in m_copym (m=0x0, off0=1396, len=1376, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:397 #10 0xc061804a in ip_fragment (ip=0xcd365820, m_frag=0xe4fabc20, mtu=-940045504, if_hwassist_flags=0, sw_csum=3073) at /usr/src/sys/netinet/ip_output.c:975 #11 0xc061a846 in ip_output (m=0xc6894300, opt=0xcd365820, ro=0xe4fabbec, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:804 #12 0xc0609742 in dummynet_send (m=0xc66b9e00) at /usr/src/sys/netinet/ip_dummynet.c:771 #13 0xc0609a32 in dummynet (unused=0x0) at /usr/src/sys/netinet/ip_dummynet.c:753 #14 0xc0563590 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #15 0xc053a15f in ithread_loop (arg=0xc6391760) at /usr/src/sys/kern/kern_intr.c:682 #16 0xc0538cbd in fork_exit (callout=0xc053a040 , arg=0x2c, frame=0x2c) at /usr/src/sys/kern/kern_fork.c:821 #17 0xc06ec14c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) list *0xc0596202 0xc0596202 is in m_copym (/usr/src/sys/kern/uipc_mbuf.c:400). 395 MBUF_CHECKSLEEP(wait); 396 if (off == 0 && m->m_flags & M_PKTHDR) 397 copyhdr = 1; 398 while (off > 0) { 399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 400 if (off < m->m_len) 401 break; 402 off -= m->m_len; 403 m = m->m_next; 404 } kernel config file== machine i386 cpu I686_CPU ident router makeopti
Re: Fatal trap 12: page fault while in kernel mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm up and running on the patch now as well ... - --On Sunday, January 07, 2007 17:02:40 -0800 Kevin Oberman <[EMAIL PROTECTED]> wrote: >> Date: Sun, 7 Jan 2007 14:03:41 + (GMT) >> From: Robert Watson <[EMAIL PROTECTED]> >> Sender: [EMAIL PROTECTED] >> >> On Sat, 6 Jan 2007, Marc G. Fournier wrote: >> >> > Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17> >> > 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core > >> > if there is information that I can provide out of it ... >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address = 0x18c >> > fault code = supervisor read, page not present >> > instruction pointer = 0x8:0x801f9053 >> > stack pointer = 0x10:0xb5c78b30 >> > frame pointer = 0x10:0xb5c78b60 >> > code segment= base 0x0, limit 0xf, type 0x1b >> >= DPL 0, pres 1, long 1, def32 0, gran 1 >> > processor eflags= resume, IOPL = 0 >> > current process = 5 (thread taskq) >> > trap number = 12 >> > panic: page fault >> > cpuid = 0 >> > Uptime: 8d22h25m40s >> > >> > (kgdb) where >> > # 0 doadump () at pcpu.h:172 >> > # 1 0x80203955 in boot (howto=260) at >> > /usr/src/sys/kern/kern_shutdown.c:409 >> > # 2 0x80204065 in panic (fmt=0xff019b667720 >> > "X\223f\233\001???\020?c\233\001???") at >> > /usr/src/sys/kern/kern_shutdown.c:565 >> > # 3 0x803287a6 in trap_fatal (frame=0xc, eva=1844674298110007> >> > # 4784) at >> > /usr/src/sys/amd64/amd64/trap.c:660 >> > # 4 0x80328cd8 in trap (frame= >> > {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx => >> > 3221225730, tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, >> > tf_rbx = - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, >> > tf_r11 > = 0, tf_r12 = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, >> > tf_trapno > = 12, tf_addr = 396, tf_flags = -2145197496, tf_err = 0, >> > tf_rip = -2145415085, tf_c> s = 8, tf_rflags = 65538, tf_rsp = >> > -1245213888, tf_ss = 16}) at >> > /usr/src/sys/amd64/amd64/trap.c:238 >> > # 5 0x80313c6b in calltrap () at >> > /usr/src/sys/amd64/amd64/exception.S:168 >> > # 6 0x801f9053 in _mtx_lock_sleep (m=0xff009d31f0d0, >> > tid=18446742981100074784, opts=6, file=0xc102 02 >> > out of bounds>, line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 >> > # 7 0x8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at >> > /usr/src/sys/kern/uipc_usrreq.c:1714 >> > # 8 0x8022c314 in taskqueue_run (queue=0xff844800) at >> > /usr/src/sys/kern/subr_taskqueue.c:257 >> > # 9 0x8022d0e7 in taskqueue_thread_loop (arg=0x70) at >> > /usr/src/sys/kern/subr_taskqueue.c:376 >> > # 10 0x801e7b76 in fork_exit (callout=0x8022d060 >> > , arg=0x805030d0, frame=0xb5c7> >> > 8c50) at /usr/src/sys/kern/kern_fork.c:821 >> > # 11 0x80313fce in fork_trampoline () at >> > /usr/src/sys/amd64/amd64/exception.S:394 >> >> This is a NULL pointer dereference in the UNIX domain socket code. John >> Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT> >> , with an MFC planned in the near future. The fix won't make 6.2-RELEASE, >> bu> t assuming it tests out well over the next few weeks, we will cut an >> errata> patch/announcement for it. I believe you can pull down his >> 6-STABLE versio> n at: >> >>http://people.FreeBSD.org/~jhb/patches/unp_gc.patch >> >> This same patch is currently in texting on mx1.FreeBSD.org. >> >> (John CC'd) >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge > > I have installed this on my system, but the panics have always been very > erratic, so it may be a while before I am sure whether this fixes it. At > the moment the system has been up for 7 days, although I have had > multiple crashes in a single day. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFobPh4QvfyHIvDvMRAuGBAJ4vwJoVIRmbdHK6wqBxneuUzjekfACgr4Ys 2DSldX3rTRAHkng3UqKO+8U= =FtuJ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
> Date: Sun, 7 Jan 2007 14:03:41 + (GMT) > From: Robert Watson <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > On Sat, 6 Jan 2007, Marc G. Fournier wrote: > > > Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17> > > 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core > > > if > > there is information that I can provide out of it ... > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x18c > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0x801f9053 > > stack pointer = 0x10:0xb5c78b30 > > frame pointer = 0x10:0xb5c78b60 > > code segment= base 0x0, limit 0xf, type 0x1b > >= DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= resume, IOPL = 0 > > current process = 5 (thread taskq) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > Uptime: 8d22h25m40s > > > > (kgdb) where > > #0 doadump () at pcpu.h:172 > > #1 0x80203955 in boot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0x80204065 in panic (fmt=0xff019b667720 > > "X\223f\233\001ÿÿÿ\020µc\233\001ÿÿÿ") at > > /usr/src/sys/kern/kern_shutdown.c:565 > > #3 0x803287a6 in trap_fatal (frame=0xc, eva=1844674298110007> > > 4784) at > > /usr/src/sys/amd64/amd64/trap.c:660 > > #4 0x80328cd8 in trap (frame= > > {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx => > > 3221225730, > > tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, tf_rbx = > > - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, tf_r11 > = 0, > > tf_r12 > > = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, tf_trapno > = 12, > > tf_addr = > > 396, tf_flags = -2145197496, tf_err = 0, tf_rip = -2145415085, tf_c> s = 8, > > tf_rflags = 65538, tf_rsp = -1245213888, tf_ss = 16}) at > > /usr/src/sys/amd64/amd64/trap.c:238 > > #5 0x80313c6b in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:168 > > #6 0x801f9053 in _mtx_lock_sleep (m=0xff009d31f0d0, > > tid=18446742981100074784, opts=6, file=0xc102 02 out > > of > > bounds>, line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 > > #7 0x8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at > > /usr/src/sys/kern/uipc_usrreq.c:1714 > > #8 0x8022c314 in taskqueue_run (queue=0xff844800) at > > /usr/src/sys/kern/subr_taskqueue.c:257 > > #9 0x8022d0e7 in taskqueue_thread_loop (arg=0x70) at > > /usr/src/sys/kern/subr_taskqueue.c:376 > > #10 0x801e7b76 in fork_exit (callout=0x8022d060 > > , arg=0x805030d0, frame=0xb5c7> > > 8c50) at > > /usr/src/sys/kern/kern_fork.c:821 > > #11 0x80313fce in fork_trampoline () at > > /usr/src/sys/amd64/amd64/exception.S:394 > > This is a NULL pointer dereference in the UNIX domain socket code. John > Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT> > , > with an MFC planned in the near future. The fix won't make 6.2-RELEASE, bu> > t > assuming it tests out well over the next few weeks, we will cut an errata> > patch/announcement for it. I believe you can pull down his 6-STABLE versio> > n > at: > >http://people.FreeBSD.org/~jhb/patches/unp_gc.patch > > This same patch is currently in texting on mx1.FreeBSD.org. > > (John CC'd) > > Robert N M Watson > Computer Laboratory > University of Cambridge I have installed this on my system, but the panics have always been very erratic, so it may be a while before I am sure whether this fixes it. At the moment the system has been up for 7 days, although I have had multiple crashes in a single day. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpMYoyJA65XW.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Working on upgrading and applying patch right now ... thanks ... - --On Sunday, January 07, 2007 14:03:41 + Robert Watson <[EMAIL PROTECTED]> wrote: > > On Sat, 6 Jan 2007, Marc G. Fournier wrote: > >> Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17 >> 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core if >> there is information that I can provide out of it ... >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x18c >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0x801f9053 >> stack pointer = 0x10:0xb5c78b30 >> frame pointer = 0x10:0xb5c78b60 >> code segment= base 0x0, limit 0xf, type 0x1b >>= DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= resume, IOPL = 0 >> current process = 5 (thread taskq) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> Uptime: 8d22h25m40s >> >> (kgdb) where >> # 0 doadump () at pcpu.h:172 >> # 1 0x80203955 in boot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:409 >> # 2 0x80204065 in panic (fmt=0xff019b667720 >> "X\223f\233\001ÿÿÿ\020µc\233\001ÿÿÿ") at >> /usr/src/sys/kern/kern_shutdown.c:565 >> # 3 0x803287a6 in trap_fatal (frame=0xc, eva=18446742981100074784) >> # at >> /usr/src/sys/amd64/amd64/trap.c:660 >> # 4 0x80328cd8 in trap (frame= >> {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx = 3221225730, >> tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, tf_rbx = >> - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, tf_r11 = 0, >> tf_r12 = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, tf_trapno = 12, >> tf_addr = 396, tf_flags = -2145197496, tf_err = 0, tf_rip = -2145415085, >> tf_cs = 8, tf_rflags = 65538, tf_rsp = -1245213888, tf_ss = 16}) at >> /usr/src/sys/amd64/amd64/trap.c:238 >> # 5 0x80313c6b in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:168 >> # 6 0x801f9053 in _mtx_lock_sleep (m=0xff009d31f0d0, >> tid=18446742981100074784, opts=6, file=0xc102 > bounds>, line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 >> # 7 0x8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at >> /usr/src/sys/kern/uipc_usrreq.c:1714 >> # 8 0x8022c314 in taskqueue_run (queue=0xff844800) at >> /usr/src/sys/kern/subr_taskqueue.c:257 >> # 9 0x8022d0e7 in taskqueue_thread_loop (arg=0x70) at >> /usr/src/sys/kern/subr_taskqueue.c:376 >> # 10 0x801e7b76 in fork_exit (callout=0x8022d060 >> , arg=0x805030d0, frame=0xb5c78c50) at >> /usr/src/sys/kern/kern_fork.c:821 >> # 11 0x80313fce in fork_trampoline () at >> /usr/src/sys/amd64/amd64/exception.S:394 > > This is a NULL pointer dereference in the UNIX domain socket code. John > Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT, > with an MFC planned in the near future. The fix won't make 6.2-RELEASE, but > assuming it tests out well over the next few weeks, we will cut an errata > patch/announcement for it. I believe you can pull down his 6-STABLE version > at: > >http://people.FreeBSD.org/~jhb/patches/unp_gc.patch > > This same patch is currently in texting on mx1.FreeBSD.org. > > (John CC'd) > > Robert N M Watson > Computer Laboratory > University of Cambridge - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFoQ8w4QvfyHIvDvMRAuTzAKDrPBUZ0dRgdujdSzQjbFyh2xiYcACgm8Oa adOhc5QuzI99WsjjjWaSi64= =lmyP -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Sat, 6 Jan 2007, Marc G. Fournier wrote: Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core if there is information that I can provide out of it ... Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18c fault code = supervisor read, page not present instruction pointer = 0x8:0x801f9053 stack pointer = 0x10:0xb5c78b30 frame pointer = 0x10:0xb5c78b60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 5 (thread taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 8d22h25m40s (kgdb) where #0 doadump () at pcpu.h:172 #1 0x80203955 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x80204065 in panic (fmt=0xff019b667720 "X\223f\233\001ÿÿÿ\020µc\233\001ÿÿÿ") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0x803287a6 in trap_fatal (frame=0xc, eva=18446742981100074784) at /usr/src/sys/amd64/amd64/trap.c:660 #4 0x80328cd8 in trap (frame= {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx = 3221225730, tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, tf_rbx = - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, tf_r11 = 0, tf_r12 = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, tf_trapno = 12, tf_addr = 396, tf_flags = -2145197496, tf_err = 0, tf_rip = -2145415085, tf_cs = 8, tf_rflags = 65538, tf_rsp = -1245213888, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:238 #5 0x80313c6b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #6 0x801f9053 in _mtx_lock_sleep (m=0xff009d31f0d0, tid=18446742981100074784, opts=6, file=0xc102 , line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 #7 0x8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at /usr/src/sys/kern/uipc_usrreq.c:1714 #8 0x8022c314 in taskqueue_run (queue=0xff844800) at /usr/src/sys/kern/subr_taskqueue.c:257 #9 0x8022d0e7 in taskqueue_thread_loop (arg=0x70) at /usr/src/sys/kern/subr_taskqueue.c:376 #10 0x801e7b76 in fork_exit (callout=0x8022d060 , arg=0x805030d0, frame=0xb5c78c50) at /usr/src/sys/kern/kern_fork.c:821 #11 0x80313fce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 This is a NULL pointer dereference in the UNIX domain socket code. John Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT, with an MFC planned in the near future. The fix won't make 6.2-RELEASE, but assuming it tests out well over the next few weeks, we will cut an errata patch/announcement for it. I believe you can pull down his 6-STABLE version at: http://people.FreeBSD.org/~jhb/patches/unp_gc.patch This same patch is currently in texting on mx1.FreeBSD.org. (John CC'd) Robert N M Watson Computer Laboratory University of Cambridge___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core if there is information that I can provide out of it ... Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18c fault code = supervisor read, page not present instruction pointer = 0x8:0x801f9053 stack pointer = 0x10:0xb5c78b30 frame pointer = 0x10:0xb5c78b60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 5 (thread taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 8d22h25m40s (kgdb) where #0 doadump () at pcpu.h:172 #1 0x80203955 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x80204065 in panic (fmt=0xff019b667720 "X\223f\233\001ÿÿÿ\020µc\233\001ÿÿÿ") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0x803287a6 in trap_fatal (frame=0xc, eva=18446742981100074784) at /usr/src/sys/amd64/amd64/trap.c:660 #4 0x80328cd8 in trap (frame= {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx = 3221225730, tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, tf_rbx = - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, tf_r11 = 0, tf_r12 = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, tf_trapno = 12, tf_addr = 396, tf_flags = -2145197496, tf_err = 0, tf_rip = -2145415085, tf_cs = 8, tf_rflags = 65538, tf_rsp = -1245213888, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:238 #5 0x80313c6b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #6 0x801f9053 in _mtx_lock_sleep (m=0xff009d31f0d0, tid=18446742981100074784, opts=6, file=0xc102 , line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546 #7 0x8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at /usr/src/sys/kern/uipc_usrreq.c:1714 #8 0x8022c314 in taskqueue_run (queue=0xff844800) at /usr/src/sys/kern/subr_taskqueue.c:257 #9 0x8022d0e7 in taskqueue_thread_loop (arg=0x70) at /usr/src/sys/kern/subr_taskqueue.c:376 #10 0x801e7b76 in fork_exit (callout=0x8022d060 , arg=0x805030d0, frame=0xb5c78c50) at /usr/src/sys/kern/kern_fork.c:821 #11 0x80313fce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 #12 0x in ?? () #13 0x in ?? () #14 0x0001 in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x in ?? () #24 0x in ?? () #25 0x in ?? () #26 0x in ?? () #27 0x in ?? () #28 0x in ?? () #29 0x in ?? () #30 0x in ?? () #31 0x in ?? () #32 0x in ?? () #33 0x in ?? () #34 0x in ?? () #35 0x in ?? () #36 0x in ?? () #37 0x in ?? () #38 0x in ?? () #39 0x in ?? () #40 0x in ?? () #41 0x in ?? () #42 0x in ?? () #43 0x in ?? () #44 0x006bc000 in ?? () #45 0x805054c0 in turnstile_chains () #46 0x0001 in ?? () #47 0xff019b669358 in ?? () #48 0xff008d5bc720 in ?? () #49 0xb5c78aa0 in ?? () #50 0xb5c78a78 in ?? () #51 0xff019b667720 in ?? () #52 0x8021a69f in sched_switch (td=0x805030d0, newtd=0x8022d060, flags=0) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFn02U4QvfyHIvDvMRArpcAJ9O14aZsWCJ97wQeLKvxKd9DW6bTQCfWSMm nm/uEw6zK2jBPXN6/0OTC34= =4IGH -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode
On Thu, 2006-06-15 at 16:22 -0700, David Wolfskill wrote: > I had one of these a couple of weeks ago or so; I had been distracted by > some more urgent matters that came up (the panic was on a machine under > test; the more urgent matters were little things like needing to deploy > a handful of resolvers on our network because existing ones were running > on systems that had provided evidence of being prone to imminent > failure). > > Anyway: I updated the 2 boxen under test to 6.1-STABLE as of this > morning, and finally(!) had a chance to re-try the failing operation. > > It went "kaboom!" again. :-{ (Well, there's something to be said for > consistency. :-}) > > It seems to run OK (albeit slowly) for a couple of minutes; then the > serial console reports: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 06 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xf09b3b98 > frame pointer = 0x28:0xf09b3bcc > 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 = 23782 (ecelerity) > [thread pid 23782 tid 100120 ] > Stopped at 0: *** error reading from address 0 *** > db> trace > Tracing pid 23782 tid 100120 td 0xcc445180 > db> OK, seeing as nobody has offered any advice, I'll have a go. Have you got a debug kernel? If so, get a kernel dump. Load it into kgdb. Chances are "bt" won't work as the instruction pointer is zero, so instead you need to display the stack directly: (kgdb) x/80xw 0xf09b3b98 Look for any addresses in the 0xc0xx range - these will probably be pointers to kernel functions. Drop out of kgdb, and try to find out which functions these belong to: addr2line 0xc0639bd6 -e kernel.debug /usr/src/sys/kern/tty.c:1653 You can build up a backtrace and knowledge of atguments given to functions this way. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode
On Thu, 15 Jun 2006 16:22:40 -0700 David Wolfskill <[EMAIL PROTECTED]> wrote: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 06 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xf09b3b98 frame pointer = 0x28:0xf09b3bcc 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 = 23782 (ecelerity) [thread pid 23782 tid 100120 ] Stopped at 0: *** error reading from address 0 *** I had similar problems when updating from 5.4 to 6.1 because of nvidia-driver. After changing the card, the system worked like a charm. Later on recompiling nvidia-driver (forgot to deinstall it) resulted in the machine crashing and rebooting itself. This happened with a non-nvidia graphic adapter installed. I remember hearing that optimizations might be the cause of the driver failing. Hope this helps. Regards, Sampsa Suoninen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help? 6.1-S: Fatal trap 12: page fault while in kernel mode
I had one of these a couple of weeks ago or so; I had been distracted by some more urgent matters that came up (the panic was on a machine under test; the more urgent matters were little things like needing to deploy a handful of resolvers on our network because existing ones were running on systems that had provided evidence of being prone to imminent failure). Anyway: I updated the 2 boxen under test to 6.1-STABLE as of this morning, and finally(!) had a chance to re-try the failing operation. It went "kaboom!" again. :-{ (Well, there's something to be said for consistency. :-}) The setup is thus: * On machine "C", I run smtp-sink (one of the test programs from Postfix). * On machine "B" (the machine & software under test), I fire up the software being tested, which acts as an SMTP relay, accepting mail and relaying it to machine C (where it gets counted and discarded). * On machine "A", I have installed the mail/postal port; I run "postal," directing it to send mail to the SMTP server on machine B (the machine under test). It seems to run OK (albeit slowly) for a couple of minutes; then the serial console reports: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 06 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xf09b3b98 frame pointer = 0x28:0xf09b3bcc 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 = 23782 (ecelerity) [thread pid 23782 tid 100120 ] Stopped at 0: *** error reading from address 0 *** db> trace Tracing pid 23782 tid 100120 td 0xcc445180 db> Now, the software being tested apparently exercises threads quite a bit. The hardware (for machine B) is a dual Xeon @ 3 GHz & 4 GB RAM. The kernel config is pretty simple: -%< snip! --- include PAE options SMP # Symmetric MultiProcessor Kernel nodevicehptmv nodevicebce options MAXDSIZ="(2000UL*1024*1024)" options KDB options KDB_TRACE options DDB options IPFIREWALL options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=0 #do not limit verbosity options DUMMYNET options IPDIVERT -%< snip! --- So: I have a pair of these machines, configured identically. Each is connected to a terminal server for access to the serial console. I have a private mirror of the FreeBSD CVS repository; I'm tracking RELENG_6 & HEAD on my laptop daily; I could try building CURRENT on one of these boxen if it would help get the problem solved. The software under test was built for FreeBSD 5.x; I have the misc/compat5x port installed. The vendor claims that they don't have this kind of problem with "Linux," and if I can't get it to run without letting the magic smoke leak out, I'll probably end up trying to hack my way through installing some flavor of Linux on one of the machines, which prospect I find remarkably unappealing. Maybe the DTrace stuff would help? Could someone please work with me on this, so we can have a software vendor recommending that their customers deploy their software on FreeBSD, rather than recommending against it? Thanks! Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Doing business with spammers only encourages them. Please boycott spammers. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpFlp2QD0gyn.pgp Description: PGP signature
panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi, I experienced lots of kernel panic after I installed openwebmail on my mail server. The environment is : [Mail Server] <=> [Mail Spool Server] nfs Mail Server: 6.1-RELEASE (panic 3 times a day) Mail Spool Server: 6.0-RELEASE I also installed www/apache20, mail/postfix. The mount options is rw, quota (Yes, I used quota) I have tried to replace my kernel, but GENERIC and custom kernels panic, too. Please give me some advice :) == Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc050f162 stack pointer = 0x28:0xd12519b8 frame pointer = 0x28:0xd12519c4 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 = 4254 (perl5.8.8) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29 panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8 trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6 trap_pfault(d1251978,0,34) at trap_pfault+0x1d3 trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 --- vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12 getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0 getblk(c29b4770,19,0,8000,0) at getblk+0x35c nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81 nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983 nfs_read(d1251bf4) at nfs_read+0x33 VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38 vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196 dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85 kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36 read(c24b4600,d1251d04,3,27,202) at read+0x45 syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp = 0xbfbfe28c, ebp = 0xbfbfe2c8 --- Uptime: 14h32m59s Dumping 255 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc04c8fc4 in panic (fmt=0xc0620009 "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc0602201 in trap (frame= {tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136, tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp = -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs = 32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146 #8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768) at /usr/src/sys/kern/vfs_bio.c:1779 #9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2486 #10 0xc206631d in ?? () #11 0xc29b4770 in ?? () #12 0x0019 in ?? () #13 0x in ?? () #14 0x8000 in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0xc7025860 in ?? () #20 0xc29b4830 in ?? () #21 0x in ?? () #22 0xc1e28400 in ?? () #23 0xd1251a94 in ?? () #24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at /usr/src/sys/kern/vfs_bio.c:2141 #25 0xc20685ff in ?? () #26 0x0019 in ?? () #27 0x in ?? () #28 0x8000 in ?? () #29 0xc24b4600 in ?? () #30 0x8000 in ?? () #31 0x1dba5906 in ?? () #32 0x in ?? () #33 0x8853088c in ?? () #34 0x0019 in ?? () #35 0x in ?? () #36 0x004ba000 in ?? () #37 0x in ?? () #38 0x8000 in ?? () #39 0x in ?? () #40 0x000c8000 in ?? () #41 0x in ?? () #42 0x in ?? () #43 0x in ?? () #44 0x in ?? () #45 0x in ?? () #46 0x005e in ?? () #47 0x8000 in ?? () #48 0x0018 in ?? () #49 0x in ?? () #50 0xc24295a0 in ?? () #51 0xc24b4600 in ?? () #52 0x in ?? () #53 0x8000 in ?? () #54 0xc22e58fc in ?? () #55 0xc0674d80 in vop_getattr_vp_offsets () #56 0xc29b4770 in ?? () #57 0xd1251b2c in ?? () #58 0xc2353b00 in ?? () #59 0xc24b4600 in ?? () #
panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi, I experienced lots of kernel panic after I installed openwebmail on my mail server. The environment is : [Mail Server] <=> [Mail Spool Server] nfs Mail Server: 6.1-RELEASE (panic 3 times a day) Mail Spool Server: 6.0-RELEASE I also installed www/apache20, mail/postfix. The mount options is rw, quota (Yes, I used quota) I have tried to replace my kernel, but GENERIC and custom kernels panic, too. Please give me some advice :) == Fatal trap 12: page fault while in kernel mode fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc050f162 stack pointer = 0x28:0xd12519b8 frame pointer = 0x28:0xd12519c4 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 = 4254 (perl5.8.8) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29 panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8 trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6 trap_pfault(d1251978,0,34) at trap_pfault+0x1d3 trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 --- vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12 getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0 getblk(c29b4770,19,0,8000,0) at getblk+0x35c nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81 nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983 nfs_read(d1251bf4) at nfs_read+0x33 VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38 vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196 dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85 kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36 read(c24b4600,d1251d04,3,27,202) at read+0x45 syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp = 0xbfbfe28c, ebp = 0xbfbfe2c8 --- Uptime: 14h32m59s Dumping 255 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc04c8fc4 in panic (fmt=0xc0620009 "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc0602201 in trap (frame= {tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136, tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp = -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs = 32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146 #8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768) at /usr/src/sys/kern/vfs_bio.c:1779 #9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2486 #10 0xc206631d in ?? () #11 0xc29b4770 in ?? () #12 0x0019 in ?? () #13 0x in ?? () #14 0x8000 in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0xc7025860 in ?? () #20 0xc29b4830 in ?? () #21 0x in ?? () #22 0xc1e28400 in ?? () #23 0xd1251a94 in ?? () #24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at /usr/src/sys/kern/vfs_bio.c:2141 #25 0xc20685ff in ?? () #26 0x0019 in ?? () #27 0x in ?? () #28 0x8000 in ?? () #29 0xc24b4600 in ?? () #30 0x8000 in ?? () #31 0x1dba5906 in ?? () #32 0x in ?? () #33 0x8853088c in ?? () #34 0x0019 in ?? () #35 0x in ?? () #36 0x004ba000 in ?? () #37 0x in ?? () #38 0x8000 in ?? () #39 0x in ?? () #40 0x000c8000 in ?? () #41 0x in ?? () #42 0x in ?? () #43 0x in ?? () #44 0x in ?? () #45 0x in ?? () #46 0x005e in ?? () #47 0x8000 in ?? () #48 0x0018 in ?? () #49 0x in ?? () #50 0xc24295a0 in ?? () #51 0xc24b4600 in ?? () #52 0x in ?? () #53 0x8000 in ?? () #54 0xc22e58fc in ?? () #55 0xc0674d80 in vop_getattr_vp_offsets () #56 0xc29b4770 in ?? () #57 0xd1251b2c in ?? () #58 0xc2353b00 in ?? () #59 0xc24b4600 in ?? () #
Re: 6.1-STABLE; Fatal trap 12: page fault while in kernel mode; kgdb isn't working??!?
David Wolfskill wrote: In testing a vendor's product, I managed (as I had been warned might happen) to crash the machine on which the product was running. It's a moderately-recent 6.1-STABLE: mx-out05# uname -a FreeBSD mx-out05.lab.example.org 6.1-STABLE FreeBSD 6.1-STABLE #3: Sun May 7 10:06:44 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP_PAE i386 mx-out05# Hardware-wise, it's a dual 3 GHz Xeon box with 4 GB RAM. In case it's relevant: mx-out05# mount; df; swapinfo /dev/aacd0s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/aacd0s2d on /usr (ufs, local, soft-updates) /dev/aacd0s3d on /home (ufs, local, soft-updates) /dev/aacd0s3e on /var (ufs, local, soft-updates) /dev/aacd1s1d on /var/spool (ufs, local, noatime) devfs on /var/named/dev (devfs, local) /dev/md0 on /tmp (ufs, local, soft-updates) Filesystem1K-blocksUsedAvail Capacity Mounted on /dev/aacd0s2a507630 37008 430012 8%/ devfs 1 10 100%/dev /dev/aacd0s2d 2280880 1676226 42218480%/usr /dev/aacd0s3d 5077038 50950 4619926 1%/home /dev/aacd0s3e 7270492 949650 573920414%/var /dev/aacd1s1d 34678048 14136 31889670 0%/var/spool devfs 1 10 100%/var/named/dev /dev/md09159102 16 8426358 0%/tmp Device 1K-blocks UsedAvail Capacity /dev/aacd0s3b167772160 16777216 0% mx-out05# Yes, swap is ridiculously huge (but note that /tmp is swap-backed). So are a few other allocations (huge, that is); in general, I prefer to avoid exhausting resources. :-} The crash appears to be quite reproducible by using ports/benchmarks/postal. It's fairly likely that I need to configure some resource-consumption constraints so the application doesn't go completely berserk. I note that running postal using the same parameters against a similar box running Postfix just chugs along, no problem at all. Here's a typical complaint as extracted from /var/log/messages: May 31 16:02:13 mx-out05 kernel: Fatal trap 12: page fault while in kernel mode May 31 16:02:13 mx-out05 kernel: cpuid = 0; apic id = 00 May 31 16:02:13 mx-out05 kernel: fault virtual address May 31 16:02:13 mx-out05 kernel: = 0x0 May 31 16:02:13 mx-out05 kernel: fault code = supervisor read, page not present May 31 16:02:13 mx-out05 kernel: instruction pointer= 0x20:0x0 May 31 16:02:13 mx-out05 kernel: stack pointer = 0x28:0xf06f8b98 May 31 16:02:13 mx-out05 kernel: frame pointer = 0x28:0xf06f8bcc May 31 16:02:13 mx-out05 kernel: code segment = base 0x0, limit 0xf May 31 16:02:13 mx-out05 kernel: f I did manage to set things up to get a kernel crash dump, and I'm about as certain as I can be that the kernel, userland, and crash dump are all in sync. Still, when I cd /usr/obj/usr/src/sys/SMP_PAE/ && kgdb kernel.debug /var/crash/vmcore.0 I get a repeating: kgdb: kvm_read: invalid address (0xc9ff5624) kgdb: kvm_read: invalid address (0xc9ff8600) kgdb: kvm_read: invalid address (0xc9ff5624) kgdb: kvm_read: invalid address (0xc9ff8600) The pattern repeats until I interrupt it. Now, this box is in a lab; it is for testing (at this time), so I have rather more flexibility than I might for a production system. The product was built for FreeBSD 5.x; I have the ports/misc/compat-5x port installed, and the product does run -- at least, until I start stress-testing it. :-} I could bring the box up to a more recent -STABLE fairly easily; for that matter, I could probably bring it up to -CURRENT fairly easily, but I have no intent to be running a production service on -CURRENT. (My laptop? Sometimes. A production box in a colo? Uhh... maybe I'm just not sufficiently daring, but no thanks. :-}) I'd appreciate suggestions (or pointers to same) as to how I might proceed to determine what I can do to get the product to run reliably iin a FreeBSD environment. (The vendor has suggested eithe rRed Hat or Suse Linux as more stable platforms, and has complained about an inability to get debugging information from FreeBSD. I have pointe dout that there's been some progress of late on getting DTrace ported to FreeBSD, and they've seemed at least somewhat interested, but in the mean time) Anyway, I'll plan on summarizing off-list responses that are relevant. Thanks! Peace, david kgdb seems to be more broken than not. COuld you enable KDB+DDB and at least get a stack trace from the fault? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.1-STABLE; Fatal trap 12: page fault while in kernel mode; kgdb isn't working??!?
In testing a vendor's product, I managed (as I had been warned might happen) to crash the machine on which the product was running. It's a moderately-recent 6.1-STABLE: mx-out05# uname -a FreeBSD mx-out05.lab.example.org 6.1-STABLE FreeBSD 6.1-STABLE #3: Sun May 7 10:06:44 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP_PAE i386 mx-out05# Hardware-wise, it's a dual 3 GHz Xeon box with 4 GB RAM. In case it's relevant: mx-out05# mount; df; swapinfo /dev/aacd0s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/aacd0s2d on /usr (ufs, local, soft-updates) /dev/aacd0s3d on /home (ufs, local, soft-updates) /dev/aacd0s3e on /var (ufs, local, soft-updates) /dev/aacd1s1d on /var/spool (ufs, local, noatime) devfs on /var/named/dev (devfs, local) /dev/md0 on /tmp (ufs, local, soft-updates) Filesystem1K-blocksUsedAvail Capacity Mounted on /dev/aacd0s2a507630 37008 430012 8%/ devfs 1 10 100%/dev /dev/aacd0s2d 2280880 1676226 42218480%/usr /dev/aacd0s3d 5077038 50950 4619926 1%/home /dev/aacd0s3e 7270492 949650 573920414%/var /dev/aacd1s1d 34678048 14136 31889670 0%/var/spool devfs 1 10 100%/var/named/dev /dev/md09159102 16 8426358 0%/tmp Device 1K-blocks UsedAvail Capacity /dev/aacd0s3b167772160 16777216 0% mx-out05# Yes, swap is ridiculously huge (but note that /tmp is swap-backed). So are a few other allocations (huge, that is); in general, I prefer to avoid exhausting resources. :-} The crash appears to be quite reproducible by using ports/benchmarks/postal. It's fairly likely that I need to configure some resource-consumption constraints so the application doesn't go completely berserk. I note that running postal using the same parameters against a similar box running Postfix just chugs along, no problem at all. Here's a typical complaint as extracted from /var/log/messages: May 31 16:02:13 mx-out05 kernel: Fatal trap 12: page fault while in kernel mode May 31 16:02:13 mx-out05 kernel: cpuid = 0; apic id = 00 May 31 16:02:13 mx-out05 kernel: fault virtual address May 31 16:02:13 mx-out05 kernel: = 0x0 May 31 16:02:13 mx-out05 kernel: fault code = supervisor read, page not present May 31 16:02:13 mx-out05 kernel: instruction pointer= 0x20:0x0 May 31 16:02:13 mx-out05 kernel: stack pointer = 0x28:0xf06f8b98 May 31 16:02:13 mx-out05 kernel: frame pointer = 0x28:0xf06f8bcc May 31 16:02:13 mx-out05 kernel: code segment = base 0x0, limit 0xf May 31 16:02:13 mx-out05 kernel: f I did manage to set things up to get a kernel crash dump, and I'm about as certain as I can be that the kernel, userland, and crash dump are all in sync. Still, when I cd /usr/obj/usr/src/sys/SMP_PAE/ && kgdb kernel.debug /var/crash/vmcore.0 I get a repeating: kgdb: kvm_read: invalid address (0xc9ff5624) kgdb: kvm_read: invalid address (0xc9ff8600) kgdb: kvm_read: invalid address (0xc9ff5624) kgdb: kvm_read: invalid address (0xc9ff8600) The pattern repeats until I interrupt it. Now, this box is in a lab; it is for testing (at this time), so I have rather more flexibility than I might for a production system. The product was built for FreeBSD 5.x; I have the ports/misc/compat-5x port installed, and the product does run -- at least, until I start stress-testing it. :-} I could bring the box up to a more recent -STABLE fairly easily; for that matter, I could probably bring it up to -CURRENT fairly easily, but I have no intent to be running a production service on -CURRENT. (My laptop? Sometimes. A production box in a colo? Uhh... maybe I'm just not sufficiently daring, but no thanks. :-}) I'd appreciate suggestions (or pointers to same) as to how I might proceed to determine what I can do to get the product to run reliably iin a FreeBSD environment. (The vendor has suggested eithe rRed Hat or Suse Linux as more stable platforms, and has complained about an inability to get debugging information from FreeBSD. I have pointe dout that there's been some progress of late on getting DTrace ported to FreeBSD, and they've seemed at least somewhat interested, but in the mean time) Anyway, I'll plan on summarizing off-list responses that are relevant. Thanks! Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Doing business with spammers only encourages them. Please boycott spammers. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpl9MOoJollE.pgp Description: PGP signature
Fatal trap 12: page fault while in kernel mode
Hi, got the following trap on an i386 SMP system running with recent RELENG_6 sources. The system was doing copies from/to geli encrypted disks, using hifn(4) hardware crypto. Core and debug kernel are available, but the trace appears to be corrupted. - Christian Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc43cb554 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07854fe stack pointer = 0x28:0xd44c1c34 frame pointer = 0x28:0xd44c1c5c 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 = 32 (irq19: hifn0) [thread pid 32 tid 100033 ] Stopped at generic_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db> tr generic_bcopy(c4ebe118,ff0,10,c43cb554,c4ebe0a0) at generic_bcopy+0x1a hifn_callback(c351e800,c3d2e000,0,868,0) at hifn_callback+0x333 hifn_intr(c351e800,d44c1cd8,c05a0e8d,c084a8a0,1) at hifn_intr+0x2a7 ithread_execute_handlers(c33f1a3c,c3345400,c07d243c,30f,c3310780) at ithread_execute_handlers+0x128 ithread_loop(c35260f0,d44c1d38,c07d220e,31d,dfff) at ithread_loop+0x84 fork_exit(c0590a00,c35260f0,d44c1d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd44c1d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc43cb554 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07854fe stack pointer = 0x28:0xd44c1c34 frame pointer = 0x28:0xd44c1c5c 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 = 32 (irq19: hifn0) Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130796 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc048f326 in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xd44c1a14 "`\027\204À\f") at /data/build/STABLE/src/sys/ddb/db_command.c:492 #2 0xc048f0a2 in db_command (last_cmdp=0xc0840e64, cmd_table=0x0, aux_cmd_tablep=0xc07fbbc0, aux_cmd_tablep_end=0xc07fbbc4) at /data/build/STABLE/src/sys/ddb/db_command.c:350 #3 0xc048f1b5 in db_command_loop () at /data/build/STABLE/src/sys/ddb/db_command.c:458 #4 0xc04913a5 in db_trap (type=12, code=0) at /data/build/STABLE/src/sys/ddb/db_main.c:221 #5 0xc05cb1be in kdb_trap (type=0, code=0, tf=0xd44c1bf4) at /data/build/STABLE/src/sys/kern/subr_kdb.c:473 #6 0xc0787e1b in trap_fatal (frame=0xd44c1bf4, eva=0) at /data/build/STABLE/src/sys/i386/i386/trap.c:827 #7 0xc0787ac2 in trap_pfault (frame=0xd44c1bf4, usermode=0, eva=3292312916) at /data/build/STABLE/src/sys/i386/i386/trap.c:744 #8 0xc078766d in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1002654380, tf_esi = -991182864, tf_ebp = -733209508, tf_isp = -733209568, tf_ebx = 16, tf_edx = 4080, tf_ecx = 4, tf_eax = -11471516, tf_trapno = 12, tf_err = 2, tf_eip = -1065855746, tf_cs = 32, tf_eflags = 66066, tf_esp = 16, tf_ss = -991174344}) at /data/build/STABLE/src/sys/i386/i386/trap.c:434 #9 0xc07713da in calltrap () at /data/build/STABLE/src/sys/i386/i386/exception.s:139 #10 0xc07854fe in generic_bcopy () at /data/build/STABLE/src/sys/i386/i386/support.s:489 Previous frame inner to this frame (corrupt stack?) -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp2UdzA7D9eX.pgp Description: PGP signature
Fatal trap 12: page fault while in kernel mode
Hi, I had 6 crash in 3 hours with exactly the same messages is my aac controler dead ? aac0: COMMAND 0xc4c9d900 TIMEOUT AFTER 512 SECONDS aac0: WARNING! Controller is no longer running! code= 0x100 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0x5a fault code = supervisor read, page not present instruction pointer = 0x20:0xc0876cb3 stack pointer = 0x28:0xe35c39fc frame pointer = 0x28:0xe35c3ae8 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 = 14 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 19m19s Dumping 1023 MB (2 chunks) chunk 0: 1MB (157 pages) ... ok chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06df54c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc06df944 in panic (fmt=0xc094761b "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc08f993c in trap_fatal (frame=0xe35c39bc, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc08f95e2 in trap_pfault (frame=0xe35c39bc, usermode=0, eva=90) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc08f917d in trap (frame= {tf_fs = -1073151992, tf_es = -1056636888, tf_ds = -1056636888, tf_edi = -1073102848, tf_esi = -1056571392, tf_ebp = -480494872, tf_isp = -480495128, tf_ebx = 0, tf_edx = 7, tf_ecx = -480494972, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1064866637, tf_cs = 32, tf_eflags = 67142, tf_esp = -480494964, tf_ss = -1073102848}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc08e278a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0876cb3 in vm_fault (map=0xc106, vaddr=3221864448, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:295 #8 0xc08f9587 in trap_pfault (frame=0xe35c3b74, usermode=0, eva=3221868542) at /usr/src/sys/i386/i386/trap.c:733 #9 0xc08f917d in trap (frame= {tf_fs = -1064501240, tf_es = -1062993880, tf_ds = 40, tf_edi = -1073098754, tf_esi = -995508226, tf_ebp = -480494632, tf_isp = -480494688, tf_ebx = -1072984162, tf_edx = -3996, tf_ecx = 1073713177, tf_eax = -77590528, tf_trapno = 12, tf_err = 3, tf_eip = -1064341523, tf_cs = 32, tf_eflags = 67218, tf_esp = 1999, tf_ss = -1062940344}) at /usr/src/sys/i386/i386/trap.c:434 #10 0xc08e278a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #11 0xc08f6fed in generic_bcopy () at /usr/src/sys/i386/i386/support.s:513 Previous frame inner to this frame (corrupt stack?) Copyright (c) 1992-2006 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 6.1-PRERELEASE #10: Fri Mar 24 20:34:13 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CED ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (789.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 1073676288 (1023 MB) avail memory = 1041563648 (993 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ - AE_AML_INVALID_RESOURCE_TYPE Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1208-0x120b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 fxp0: port 0x1800-0x183f mem 0xf4001000-0xf4001fff,0xf410-0xf41f irq 17 at device 3.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:03:47:3a:97:a5 fxp1: port 0x1840-0x187f mem 0xf4002000-0xf4002fff,0xf420-0xf42f irq 18 at device 4.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:30:6e:06:8b:10 pci0: at device 5.0 (no driver attached) isab0: port 0x1040-0x104f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib1: on acpi0 pci3: on pcib1 pcib2: at device 2.0 on pci3 pci4: on pcib2 amr0: mem 0xf601-0xf601 irq 20 at d
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
in case someone is keep tracking this - I can confirm that the issue seems to went away since about week old RELENG_6. -- Vlad On 3/17/06, Vlad <[EMAIL PROTECTED]> wrote: > and here comes another fresh one > > # kgdb kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > 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 "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x80263071 > stack pointer = 0x10:0xa52fe8d0 > frame pointer = 0x10:0xff002a2144c0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= resume, IOPL = 0 > current process = 12 (swi1: net) > trap number = 12 > panic: page fault > Uptime: 25m3s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (152 pages) ... ok > chunk 1: 1023MB (261888 pages) 1008 992 976 960 944 928 912 896 880 > 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 > 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 > 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 > 16 > > #0 doadump () at pcpu.h:172 > 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) list *0x80263071 > 0x80263071 is in propagate_priority > (../../../kern/subr_turnstile.c:235). > > 230 /* > 231 * Pick up the lock that td is blocked on. > 232 */ > 233 ts = td->td_blocked; > 234 MPASS(ts != NULL); > 235 tc = TC_LOOKUP(ts->ts_lockobj); > 236 mtx_lock_spin(&tc->tc_lock); > 237 > 238 /* Resort td on the list if needed. */ > 239 if (!turnstile_adjust_thread(ts, td)) { > (kgdb) > 240 mtx_unlock_spin(&tc->tc_lock); > 241 return; > 242 } > 243 mtx_unlock_spin(&tc->tc_lock); > 244 } > 245 } > 246 > 247 /* > 248 * Adjust the thread's position on a turnstile after its > priority has been > 249 * changed. > (kgdb) backtrace > #0 doadump () at pcpu.h:172 > #1 0x0004 in ?? () > #2 0x8023c133 in boot (howto=260) at > ../../../kern/kern_shutdown.c:402 > #3 0x8023c736 in panic (fmt=0xff003dc19be0 "@\203(c)=") > at ../../../kern/kern_shutdown.c:558 > #4 0x8037fa22 in trap_fatal (frame=0xff003dc19be0, > eva=18446742975233884992) > at ../../../amd64/amd64/trap.c:660 > #5 0x8037ff46 in trap (frame= > {tf_rdi = -1098804804416, tf_rsi = 40, tf_rdx = 4294967294, > tf_rcx = -1098475529184, tf_r8 = 1, tf_r9 = 0, tf_rax = 180, tf_rbx = > -1098475529248, tf_rbp = -1098804804416, tf_r10 = -1098804804414, > tf_r11 = 0, tf_r12 = -1098475529248, tf_r13 = -2143389918, tf_r14 = 0, > tf_r15 = 40, tf_trapno = 12, tf_addr = 72, tf_flags = -2144456830, > tf_err = 0, tf_rip = -2144980879, tf_cs = 8, tf_rflags = 65666, tf_rsp > = -1523586848, tf_ss = 0}) at ../../../amd64/amd64/trap.c:238 > #6 0x8036e32b in calltrap () at ../../../amd64/amd64/exception.S:168 > #7 0x80263071 in propagate_priority (td=0xff002a2144c0) > at ../../../kern/subr_turnstile.c:233 > #8 0x8026386f in turnstile_wait (lock=0x80554de0, > owner=0x0) at ../../../kern/subr_turnstile.c:628 > #9 0x80232369 in _mtx_lock_sleep (m=0x80554de0, > tid=18446742975234022368, opts=-2, > file=0xff003dc19c20 "ю$h'", line=1) at ../../../kern/kern_mutex.c:565 > #10 0x80288d56 in sf_buf_mext (addr=0xff002a2144c0, > args=0xff003ecf8260) > at ../../../kern/uipc_syscalls.c:1710 > #11 0x8027cb39 in mb_free_ext (m=0xff003d910e00) at > ../../../kern/uipc_mbuf.c:272 > #12 0x80283216 in s
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
I have a similar crash from 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #1: Sun Mar 19 13:28: On Fri, Mar 17, 2006 at 09:01:05PM -0600, Vlad wrote: i > Ok, thanks for Joe's hint I was able to get stuff captured: > > # kgdb kernel.debug /var/crash/vmcore.0 ... > #9 0x8037ee2b in calltrap () at ../../../amd64/amd64/exception.S:168 > #10 0x8026d5f6 in propagate_priority (td=0xff003a5e94c0) > at ../../../kern/subr_turnstile.c:233 > #11 0x8026de2f in turnstile_wait (lock=0x805710c0, > owner=0x0) at ../../../kern/subr_turnstile.c:628 > #12 0x8023b4a9 in _mtx_lock_sleep (m=0x805710c0, > tid=18446742975234022368, opts=180, > file=0xfffe , My panic. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x808080f4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0513ff5 stack pointer = 0x28:0xda6e4c0c frame pointer = 0x28:0xda6e4c10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 3984 (sh) [thread pid 3984 tid 100242 ] Stopped at turnstile_setowner+0xd: movl0x74(%ecx),%eax db> bt Tracing pid 3984 tid 100242 td 0xc41fb780 turnstile_setowner(c41fe840,80808080,c07a5c58,c079f3e0,c41fb780) at turnstile_se towner+0xd turnstile_wait(c079f3e0,80808080) at turnstile_wait+0xa5 _mtx_lock_sleep(c079f3e0,c41fb780,0,c0674893,25e) at _mtx_lock_sleep+0xc4 _mtx_lock_flags(c079f3e0,0,c0674893,25e,c44b37f8) at _mtx_lock_flags+0x30 fork1(c41fb780,14,0,da6e4cd4,c41fb780) at fork1+0xb2a fork(c41fb780,da6e4d04,0,0,246) at fork+0x18 syscall(3b,3b,3b,0,8068000) at syscall+0x25f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (2, FreeBSD ELF32, fork), eip = 0x2813ca33, esp = 0xbfbfe5ec, ebp = 0xbfbfe608 - -- - [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
and here comes another fresh one # kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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 "amd64-marcel-freebsd". Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0x80263071 stack pointer = 0x10:0xa52fe8d0 frame pointer = 0x10:0xff002a2144c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault Uptime: 25m3s Dumping 1023 MB (2 chunks) chunk 0: 1MB (152 pages) ... ok chunk 1: 1023MB (261888 pages) 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0x80263071 0x80263071 is in propagate_priority (../../../kern/subr_turnstile.c:235). 230 /* 231 * Pick up the lock that td is blocked on. 232 */ 233 ts = td->td_blocked; 234 MPASS(ts != NULL); 235 tc = TC_LOOKUP(ts->ts_lockobj); 236 mtx_lock_spin(&tc->tc_lock); 237 238 /* Resort td on the list if needed. */ 239 if (!turnstile_adjust_thread(ts, td)) { (kgdb) 240 mtx_unlock_spin(&tc->tc_lock); 241 return; 242 } 243 mtx_unlock_spin(&tc->tc_lock); 244 } 245 } 246 247 /* 248 * Adjust the thread's position on a turnstile after its priority has been 249 * changed. (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0x0004 in ?? () #2 0x8023c133 in boot (howto=260) at ../../../kern/kern_shutdown.c:402 #3 0x8023c736 in panic (fmt=0xff003dc19be0 "@\203(c)=") at ../../../kern/kern_shutdown.c:558 #4 0x8037fa22 in trap_fatal (frame=0xff003dc19be0, eva=18446742975233884992) at ../../../amd64/amd64/trap.c:660 #5 0x8037ff46 in trap (frame= {tf_rdi = -1098804804416, tf_rsi = 40, tf_rdx = 4294967294, tf_rcx = -1098475529184, tf_r8 = 1, tf_r9 = 0, tf_rax = 180, tf_rbx = -1098475529248, tf_rbp = -1098804804416, tf_r10 = -1098804804414, tf_r11 = 0, tf_r12 = -1098475529248, tf_r13 = -2143389918, tf_r14 = 0, tf_r15 = 40, tf_trapno = 12, tf_addr = 72, tf_flags = -2144456830, tf_err = 0, tf_rip = -2144980879, tf_cs = 8, tf_rflags = 65666, tf_rsp = -1523586848, tf_ss = 0}) at ../../../amd64/amd64/trap.c:238 #6 0x8036e32b in calltrap () at ../../../amd64/amd64/exception.S:168 #7 0x80263071 in propagate_priority (td=0xff002a2144c0) at ../../../kern/subr_turnstile.c:233 #8 0x8026386f in turnstile_wait (lock=0x80554de0, owner=0x0) at ../../../kern/subr_turnstile.c:628 #9 0x80232369 in _mtx_lock_sleep (m=0x80554de0, tid=18446742975234022368, opts=-2, file=0xff003dc19c20 "ю$h'", line=1) at ../../../kern/kern_mutex.c:565 #10 0x80288d56 in sf_buf_mext (addr=0xff002a2144c0, args=0xff003ecf8260) at ../../../kern/uipc_syscalls.c:1710 #11 0x8027cb39 in mb_free_ext (m=0xff003d910e00) at ../../../kern/uipc_mbuf.c:272 #12 0x80283216 in sbdrop_locked (sb=0xff00089603c0, len=0) at mbuf.h:486 #13 0x802e5576 in tcp_input (m=0xff002b27ac00, off0=27399968) at ../../../netinet/tcp_input.c:2136 #14 0x802dc280 in ip_input (m=0xff002b27ac00) at ../../../netinet/ip_input.c:786 #15 0x802c7c8b in netisr_processqueue (ni=0x8054ffd0) at ../../../net/netisr.c:236 #16 0x802c7f2d in swi_net (dummy=0xff002a2144c0) at ../../../net/netisr.c:349 #17 0x80223a06 in ithread_loop (arg=0xff0246c0) at ../../../kern/kern_intr.c:673 #18 0x80222533 in fork_exit (callout=0x802238c0 , arg=0xff0246c0, frame=0xa52fec50) at .
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
Ok, thanks for Joe's hint I was able to get stuff captured: # kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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 "amd64-marcel-freebsd". Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0x8026d5f6 stack pointer = 0x10:0xa52ee870 frame pointer = 0x10:0xa52ee8b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 12 (swi1: net) panic: from debugger Uptime: 4h15m12s Dumping 1023 MB (2 chunks) chunk 0: 1MB (152 pages) ... ok chunk 1: 1023MB (261888 pages) 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0x802456c3 in boot (howto=260) at ../../../kern/kern_shutdown.c:402 #2 0x80245cf7 in panic (fmt=0xff003dc19be0 "@\203(c)=") at ../../../kern/kern_shutdown.c:558 #3 0x8017eaa2 in db_panic (addr=0, have_addr=0, count=0, modif=0x0) at ../../../ddb/db_command.c:438 #4 0x8017efe5 in db_command_loop () at ../../../ddb/db_command.c:350 #5 0x80180ef3 in db_trap (type=-1523653024, code=0) at ../../../ddb/db_main.c:221 #6 0x8026386b in kdb_trap (type=12, code=0, tf=0xa52ee7c0) at ../../../kern/subr_kdb.c:473 #7 0x803909cd in trap_fatal (frame=0xa52ee7c0, eva=18446742975234022368) at ../../../amd64/amd64/trap.c:651 #8 0x80390f48 in trap (frame= {tf_rdi = -1098532350784, tf_rsi = 40, tf_rdx = 180, tf_rcx = 4294967294, tf_r8 = -1098696124736, tf_r9 = 0, tf_rax = 40, tf_rbx = -1098475529248, tf_rbp = -1523652432, tf_r10 = -1098532350782, tf_r11 = 0, tf_r12 = -1098532350784, tf_r13 = -1098475529248, tf_r14 = -2143307873, tf_r15 = 0, tf_trapno = 12, tf_addr = 72, tf_flags = -1098685787648, tf_err = 0, tf_rip = -2144938506, tf_cs = 8, tf_rflags = 65666, tf_rsp = -1523652480, tf_ss = 16}) at ../../../amd64/amd64/trap.c:238 #9 0x8037ee2b in calltrap () at ../../../amd64/amd64/exception.S:168 #10 0x8026d5f6 in propagate_priority (td=0xff003a5e94c0) at ../../../kern/subr_turnstile.c:233 #11 0x8026de2f in turnstile_wait (lock=0x805710c0, owner=0x0) at ../../../kern/subr_turnstile.c:628 #12 0x8023b4a9 in _mtx_lock_sleep (m=0x805710c0, tid=18446742975234022368, opts=180, file=0xfffe , line=815503040) at ../../../kern/kern_mutex.c:565 #13 0x80293f03 in sf_buf_mext (addr=0xff003a5e94c0, args=0xff003f059328) at ../../../kern/uipc_syscalls.c:1710 #14 0x80287aa4 in mb_free_ext (m=0xff003d909600) at ../../../kern/uipc_mbuf.c:272 #15 0x8028e328 in sbdrop_locked (sb=0xff000c8ce3c0, len=540) at mbuf.h:486 #16 0x8029099a in sbdrop (sb=0xff000c8ce3c0, len=1460) at ../../../kern/uipc_socket2.c:1208 #17 0x802f02de in tcp_input (m=0xff0029ebe300, off0=668661232) at ../../../netinet/tcp_input.c:1212 #18 0x802e7e70 in ip_input (m=0xff0029ebe300) at ../../../netinet/ip_input.c:786 #19 0x802d3778 in netisr_processqueue (ni=0x8056c290) at ../../../net/netisr.c:236 #20 0x802d3a4d in swi_net (dummy=0xff003a5e94c0) at ../../../net/netisr.c:349 #21 0x8022c262 in ithread_loop (arg=0xff0246c0) at ../../../kern/kern_intr.c:673 #22 0x8022ad56 in fork_exit (callout=0x8022c100 , arg=0xff0246c0, frame=0xa52eec50) at ../../../kern/kern_fork.c:789 #23 0x8037f18e in fork_trampoline () at ../../../amd64/amd64/exception.S:394 #24 0x in ?? () Previous frame identical to this frame (corrupt stack?) (kgdb) list *0x8026d5f6 0x8026d5f6 is in propagate_priority (../../../kern/subr_turnstile.c:235). 230 /* 231 * Pick up the lock that td is blocked on. 232 */ 233
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
On Fri, Mar 17, 2006 at 11:41:58AM -0600, Vlad wrote: > no, nothing like that. and it reboots several times a day. > > also, I have my swap twice less than physical mem, so I can't get a > dump (btw, there was a patch for to gzip core before it stores it into > swap, so it can be fit in swap of smaller size - anyone has it?) > You could try setting hw.physmem to an appropriate size. Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
On Fri, Mar 17, 2006 at 11:46:03AM -0600, Vlad wrote: > I have Putty logging stuff and I guess it's either part of its > keepalive packets. OK, thanks. Kris pgp9bQOumoHeI.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
I have Putty logging stuff and I guess it's either part of its keepalive packets. On 3/17/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Fri, Mar 17, 2006 at 11:41:58AM -0600, Vlad wrote: > > no, nothing like that. and it reboots several times a day. > > Where do the online/offline messages come from? > > Kris > > > -- Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
On Fri, Mar 17, 2006 at 11:41:58AM -0600, Vlad wrote: > no, nothing like that. and it reboots several times a day. Where do the online/offline messages come from? Kris pgptmL30y88dA.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
no, nothing like that. and it reboots several times a day. also, I have my swap twice less than physical mem, so I can't get a dump (btw, there was a patch for to gzip core before it stores it into swap, so it can be fit in swap of smaller size - anyone has it?) On 3/17/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Fri, Mar 17, 2006 at 10:59:40AM -0600, Vlad wrote: > > this is 6.0-STABLE as for Mar 17. > > Are you using kernel mode ppp? If so, don't. > > Kris > > > -- Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
On Fri, Mar 17, 2006 at 10:59:40AM -0600, Vlad wrote: > this is 6.0-STABLE as for Mar 17. Are you using kernel mode ppp? If so, don't. Kris pgp3tycV8zjpL.pgp Description: PGP signature
Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
line 00:05 Online 00:06 Online 00:07 Online 00:08 Online 00:09 Online 00:10 Online 00:11 Online 00:12 Online 00:13 Online 00:14 Online 00:15 Online 00:16 Online 00:17 Online 00:18 Online 00:19kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address= 0x48 fault code= supervisor read, page not present instruction pointer= 0x8:0x8026d586 stack pointer= 0x10:0xb18ec8a0 frame pointer= 0x10:0xb18ec8e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process= 12 (swi1: net) [thread pid 12 tid 11 ] Stopped at propagate_priority+0x66:movq0x48(%r15),%rdi db> Online 00:20 Online 00:21 Online 00:22 Online 00:23 Online 00:24 Online 00:25 Online 00:26 Online 00:27 Online 00:28 Online 00:29 Online 00:30 Online 00:31 Online 00:32trace Tracing pid 12 tid 11 td 0xff007b959be0 propagate_priority() at propagate_priority+0x66 turnstile_wait() at turnstile_wait+0x20f _mtx_lock_sleep() at _mtx_lock_sleep+0x89 sf_buf_mext() at sf_buf_mext+0xa3 mb_free_ext() at mb_free_ext+0x64 sbdrop_locked() at sbdrop_locked+0xb8 tcp_input() at tcp_input+0x255e ip_input() at ip_input+0x100 netisr_processqueue() at netisr_processqueue+0x78 swi_net() at swi_net+0x14d ithread_loop() at ithread_loop+0x162 fork_exit() at fork_exit+0x86 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb18ecd00, rbp = 0 --- db> Online 00:33show reg cs 0x8 ss0x10 rax 0x28 rcx 0xfffe rdx 0xcd rbx 0xff007b959be0 rsp 0xb18ec8a0 rbp 0xb18ec8e0 rsi 0x28 rdi 0xff004ae4a000 r8 0xff004ae4a0d0 r9 0 r10 0xff007b959c20 r11 0xff757400 r12 0xff004ae4a000 r13 0xff007b959be0 r14 0x803fb45f vm_object_check_cmd+0x13f r15 0 rip 0x8026d586 propagate_priority+0x66 rflags 0x10082 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 propagate_priority+0x66:movq0x48(%r15),%rdi db> ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 8390 ff004b20b340 1002 8389 408 400 [SLPQ user map 0xff004a2d7950][SLP] sh 8389 ff004b20b680 1002 1796 408 0004000 [SLPQ wait 0xff004b20b680][SLP] sh 7902 ff0049e3c340 1002 408 408 100 [SLPQ accept 0xff0060c632c6][SLP] httpd 7901 ff004a256680 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7900 ff0049e3c000 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7899 ff00610b5000 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7896 ff004ae0c9c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7895 ff005dd819c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7888 ff005fb379c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7874 ff004734 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7864 ff005cb5 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7623 ff005dc78000 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7619 ff005cabc680 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7605 ff005cabc340 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7594 ff005dd81680 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7586 ff004a256340 1002 408 408 100 [SLPQ accept 0xff0060c632c6][SLP] httpd 7500 ff0060afb680 1002 408 408 100 [SLPQ accept 0xff0060c632c6][SLP] httpd 7497 ff005ca96000 1002 408 408 100 [SLPQ accept 0xff0060c632c6][SLP] httpd 7494 ff005cb509c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7486 ff005cb50340 1002 408 408 100 [SLPQ accept 0xff0060c632c6][SLP] httpd 7485 ff0047340340 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7473 ff004af2d000 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 7463 ff005cb50680 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 6968 ff0060afb9c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 6960 ff0047340680 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 6871 ff007b615340 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 6869 ff005cabc9c0 1002 408 408 100 [SLPQ select 0x80569bf0][SLP] httpd 6856 ff005fd0e680 1002 408 408 100 [SL
Fatal trap 12: page fault while in kernel mode tc_windup()
After a cvsup to RELENG_6 today I got the following trap while encoding some videos with Avidemux. I'm going to leave the machine at the ddb prompt since the following trace information doesn't seem very helpful. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffbb80551f10 fault code = supervisor read, page not present instruction pointer = 0x8:0x802371c4 stack pointer = 0x10:0x9634bb90 frame pointer = 0x10:0x9634bbf0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 19381 (avidemux2) [thread pid 19381 tid 100115 ] Stopped at tc_windup+0x24: movl0x50(%r13),%eax db> db> bt Tracing pid 19381 tid 100115 td 0xff001cb0b980 tc_windup() at tc_windup+0x24 hardclock() at hardclock+0x17 lapic_handle_timer() at lapic_handle_timer+0x11c Xtimerint() at Xtimerint+0x76 -- Anish Mistry pgpSSCEArdCAU.pgp Description: PGP signature
Re[2]: [panic] Fatal trap 12: page fault while in kernel mode
Hello Peter, Friday, February 10, 2006, 7:10:50 PM, you has on mind: > Please don't cross-post. A problem with 6-RELEASE is not appropriate > for [EMAIL PROTECTED] I apologize. > On Fri, 2006-Feb-10 14:48:39 +0100, Daniel Gerzo wrote: >> I've just got installed a brand new box, and I can say that it's >> hanging on regular basis, around every 10 minutes. > Is the panic always at the same place or does it move around? __qdivrem() > hasn't been touched for just under two years and it seems unlikely that > it would suddenly start triggering panics. yes. the bactrace is the same all the time. > Since you mention that this is a brand new box, are you certain that it > isn't a hardware fault? I suggest running (eg) memtest86 on it for a > few hours and see if that picks anything up. we upgraded our power supply to the stronger one and we can get 1+ hours of uptime before crash. I've run sysutils/memtest and it didn't fail in any way. I can provide more info if anybody tell me how :-) -- Best regards Daniel Gerzo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [panic] Fatal trap 12: page fault while in kernel mode
Please don't cross-post. A problem with 6-RELEASE is not appropriate for [EMAIL PROTECTED] On Fri, 2006-Feb-10 14:48:39 +0100, Daniel Gerzo wrote: > I've just got installed a brand new box, and I can say that it's > hanging on regular basis, around every 10 minutes. Is the panic always at the same place or does it move around? __qdivrem() hasn't been touched for just under two years and it seems unlikely that it would suddenly start triggering panics. Since you mention that this is a brand new box, are you certain that it isn't a hardware fault? I suggest running (eg) memtest86 on it for a few hours and see if that picks anything up. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[panic] Fatal trap 12: page fault while in kernel mode
Hello, I've just got installed a brand new box, and I can say that it's hanging on regular basis, around every 10 minutes. The backtrace is included, as well as the dmesg. Any help with this will be appreciated. Thank you. -- Sincerely, Daniel Gerzo bigbang# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa9b2d30c fault code = supervisor write, page not present instruction pointer = 0x20:0xc0810407 stack pointer = 0x28:0xe33b9b58 frame pointer = 0x28:0xe33b9be0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle) trap number = 12 panic: page fault Uptime: 17m32s Dumping 1007 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1007MB (257776 pages) 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) list *0xc0810407 0xc0810407 is in __qdivrem (/usr/src/sys/libkern/qdivrem.c:251). 246 u[i + j] = LHALF(t); 247 t = HHALF(t); 248 } 249 u[j] = LHALF(u[j] + t); 250 } 251 q[j] = qhat; 252 } while (++j <= m); /* D7: loop on j. */ 253 254 /* 255 * If caller wants the remainder, we have to calculate it as (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc0638202 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0638498 in panic (fmt=0xc084e5a2 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0807c30 in trap_fatal (frame=0xe33b9b18, eva=2847068940) at /usr/src/sys/i386/i386/trap.c:831 #4 0xc08073d2 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 606, tf_esi = 0, tf_ebp = -482632736, tf_isp = -482632892, tf_ebx = 0, tf_edx = 0, tf_ecx = -1447898356, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1065286649, tf_cs = 32, tf_eflags = 589894, tf_esp = 55296, tf_ss = 55930}) at /usr/src/sys/i386/i386/trap.c:267 #5 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc0810407 in __qdivrem (uq=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/libkern/qdivrem.c:251 #7 0xc081050e in __udivdi3 (a=9223372036854775808, b=3579545) at /usr/src/sys/libkern/udivdi3.c:47 #8 0xc0640e5d in tc_windup () at /usr/src/sys/kern/kern_tc.c:491 #9 0xc064132d in tc_ticktock () at /usr/src/sys/kern/kern_tc.c:756 #10 0xc060ec50 in hardclock (frame=0xe33b9c98) at /usr/src/sys/kern/kern_clock.c:243 #11 0xc07fcbe5 in lapic_handle_timer (frame= {cf_vec = 0, cf_fs = -1037828088, cf_es = -1067319256, cf_ds = 40, cf_edi = -1036617472, cf_esi = -1036617448, cf_ebp = -482632484, cf_ebx = 0, cf_edx = 0, cf_ecx = 1000, cf_eax = 1000, cf_eip = -1062831147, cf_cs = 32, cf_eflags = 524870, cf_esp = -482632452, cf_ss = -1062848970}) at /usr/src/sys/i386/i386/local_apic.c:630 #12 0xc07f73b0 in Xtimerint () at apic_vector.s:137 #13 0xc0a67bd5 in ?? () #14 0xe33b9d04 in ?? () #15 0xc07fe487 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1134 Previous frame inner to this frame (corrupt stack?) (kgdb) list 256 * u[m..m+n] >> d (this is at most n digits and thus fits in 257 * u[m+1..m+n], but we may need more source digits). 258 */ 259 if (arq) { 260 if (d) { 261 for (i = m + n; i > m; --i) 262 u[i] = (u[i] >> d) | 263 LHALF(u[i - 1] << (HALF_BITS - d)); 264 u[i] = 0; 265 } (kgdb) backtrace full #0 doadump () at pcpu.h:165 No locals. #1 0xc0638202 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 first_buf_printf = 1 #2 0xc0638498 in panic (fmt=0xc084e5a2 "
Fatal trap 12: page fault while in kernel mode
Hello. While copying a few directories from one machine to my new notebook (tar over ssh over wireless connection [if_iwi]), the notebook paniced with the following: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x52535307 fault code = supervisor read, page not present instruction pointer = 0x20:0xc078bc08 stack pointer = 0x28:0xde4ae95c frame pointer = 0x28:0xde4ae984 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 = 761 (bsdtar) trap number = 12 panic: page fault Uptime: 11m20s Dumping 502 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 502MB (128464 pages) 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0638202 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0638498 in panic (fmt=0xc084e5a2 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0807c30 in trap_fatal (frame=0xde4ae91c, eva=1381192455) at /usr/src/sys/i386/i386/trap.c:831 #4 0xc080799b in trap_pfault (frame=0xde4ae91c, usermode=0, eva=1381192455) at /usr/src/sys/i386/i386/trap.c:742 #5 0xc08075d9 in trap (frame= {tf_fs = 8, tf_es = -565575640, tf_ds = -1065943000, tf_edi = -565515340, tf_esi = -1043806720, tf_ebp = -565515900, tf_isp = -565515960, tf_ebx = -1039299392, tf_edx = 170, tf_ecx = 1, tf_eax = 1381191775, tf_trapno = 12, tf_err = 0, tf_eip = -1065829368, tf_cs = 32, tf_eflags = 66051, tf_esp = -1064527936, tf_ss = -565515812}) at /usr/src/sys/i386/i386/trap.c:432 #6 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc078bc08 in ufsdirhash_lookup (ip=0xc20ec318, name=0xc1c45810 "UPCII.TTF", namelen=9, offp=0x5253505f, bpp=0x5253505f, prevoffp=0x0) at /usr/src/sys/ufs/ufs/ufs_dirhash.c:409 #8 0xc078d480 in ufs_lookup (ap=0xde4aea80) at /usr/src/sys/ufs/ufs/ufs_lookup.c:209 #9 0xc0816d64 in VOP_CACHEDLOOKUP_APV (vop=0x5253505f, a=0xaa) at vnode_if.c:150 #10 0xc0682c9e in vfs_cache_lookup (ap=0x5253505f) at vnode_if.h:82 #11 0xc0816cf3 in VOP_LOOKUP_APV (vop=0xc08fbf40, a=0xde4aeb18) at vnode_if.c:99 #12 0xc068722d in lookup (ndp=0xde4aeba0) at vnode_if.h:56 #13 0xc0686b6e in namei (ndp=0xde4aeba0) at /usr/src/sys/kern/vfs_lookup.c:203 #14 0xc0694367 in kern_lstat (td=0xc1fea900, path=0xaa , pathseg=170, sbp=0xde4aec74) at /usr/src/sys/kern/vfs_syscalls.c:2102 #15 0xc0694303 in lstat (td=0xc1fea900, uap=0xde4aed04) at /usr/src/sys/kern/vfs_syscalls.c:2086 #16 0xc0807f47 in syscall (frame= {tf_fs = 59, tf_es = 4259899, tf_ds = -1078001605, tf_edi = -1077941792, tf_esi = -1077941248, tf_ebp = -1077941560, tf_isp = -565514908, tf_ebx = 134672409, tf_edx = 134586905, tf_ecx = 25, tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 672111379, tf_cs = 51, tf_eflags = 658, tf_esp = -1077941860, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:976 #17 0xc07f6e1f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #18 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) The notebook runs GENERIC kernel of 6.0-RELEASE. I don't know if it's known issue or not, nor it is reproducible. If dmesg would be helpful, I can post it as well. I will keep the vmcore.0 for a while, too, just in case. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Wednesday 07 December 2005 02:47 am, Yuri Khotyaintsev wrote: > On Friday 02 December 2005 14.54, John Baldwin wrote: > > On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote: > > > I have the following panic occurring several times a week. The machine > > > is an NFS server, and it usually panics early in the morning, when > > > first people try to access it. After reboot it may work OK for 1-2 > > > days, and then panics again. I have tried changing memory and replacing > > > disk which was exported via NFS, but nothing helped :( > > > > > > Any suggestion on how to fix this panic will be very much appreciated ! > > > > This panic (in propagate_priority) is usually caused when a thread goes > > to sleep while holding a mutex (which is forbidden). If you enable > > INVARIANTS and/or WITNESS you should get a better panic, and with WITNESS > > you will even be warned when a thread goes to sleep while holding a > > mutex. However, these options do introduce considerable execution > > overhead, and sometimes that overhead changes the timing enough to hide > > the race. :( > > Here are the two panics which I got with INVARIANTS and WITNESS enabled. > > Unread portion of the kernel message buffer: > Memory modified after free 0xc4759e00(508) val=0 @ 0xc4759e00 > panic: Most recently used by UFS dirhash Well, this isn't the panic I was expecting, but it points to something trashing free'd memory via a stale pointer or some such. You might be able to use MEMGUARD to track this down. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 14.54, John Baldwin wrote: > On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote: > > I have the following panic occurring several times a week. The machine is > > an NFS server, and it usually panics early in the morning, when first > > people try to access it. After reboot it may work OK for 1-2 days, and > > then panics again. I have tried changing memory and replacing disk which > > was exported via NFS, but nothing helped :( > > > > Any suggestion on how to fix this panic will be very much appreciated ! > > This panic (in propagate_priority) is usually caused when a thread goes to > sleep while holding a mutex (which is forbidden). If you enable INVARIANTS > and/or WITNESS you should get a better panic, and with WITNESS you will > even be warned when a thread goes to sleep while holding a mutex. However, > these options do introduce considerable execution overhead, and sometimes > that overhead changes the timing enough to hide the race. :( Here are the two panics which I got with INVARIANTS and WITNESS enabled. # kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.8 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Memory modified after free 0xc4759e00(508) val=0 @ 0xc4759e00 panic: Most recently used by UFS dirhash Uptime: 11h8m36s Dumping 511 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0510043 in panic (fmt=0xc06dccbb "Most recently used by %s\n") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0648ccf in mtrash_ctor (mem=0xc4759e00, size=0, arg=0x0, flags=2) at /usr/src/sys/vm/uma_dbg.c:137 #4 0xc06469c1 in uma_zalloc_arg (zone=0xc104d980, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1850 #5 0xc05043cd in malloc (size=400, mtp=0xc06fb700, flags=2) at uma.h:275 #6 0xc063fba9 in ufs_readdir (ap=0xd56eaaec) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1846 #7 0xc06a61cc in VOP_READDIR_APV (vop=0x0, a=0xd56eaaec) at vnode_if.c:1427 #8 0xc0607716 in nfsrv_readdir (nfsd=0xc4368c00, slp=0x0, td=0xc3326780, mrq=0xd56eac80) at vnode_if.h:746 #9 0xc060fa5b in nfssvc_nfsd (td=0x0) at /usr/src/sys/nfsserver/nfs_syscalls.c:472 #10 0xc060f280 in nfssvc (td=0xc3326780, uap=0xd56ead04) at /usr/src/sys/nfsserver/nfs_syscalls.c:181 #11 0xc069b6b0 in syscall (frame= ---Type to continue, or q to quit--- {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0, tf_ebp = -1077941464, tf_isp = -714166940, tf_ebx = 0, tf_edx = -1077936144, tf_ecx = 1, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671852067, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941492, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 #12 0xc068947f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #13 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit # kgdb /usr/obj/usr/src/sys/HEM.DEBUG/kernel.debug vmcore.9 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Memory modified after free 0xc5172800(508) val=0 @ 0xc5172800 panic: Most recently used by UFS dirhash Uptime: 1d1h7m17s Dumping 511 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc050fd4f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0510043 in panic (fmt=0xc06dccbb "Most recently used by %s\n") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0648ccf in mtrash_ctor (mem=0xc5172800,
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 14.54, John Baldwin wrote: > On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote: > > I have the following panic occurring several times a week. The machine is > > an NFS server, and it usually panics early in the morning, when first > > people try to access it. After reboot it may work OK for 1-2 days, and > > then panics again. I have tried changing memory and replacing disk which > > was exported via NFS, but nothing helped :( > > > > Any suggestion on how to fix this panic will be very much appreciated ! > > This panic (in propagate_priority) is usually caused when a thread goes to > sleep while holding a mutex (which is forbidden). If you enable INVARIANTS > and/or WITNESS you should get a better panic, and with WITNESS you will > even be warned when a thread goes to sleep while holding a mutex. However, > these options do introduce considerable execution overhead, and sometimes > that overhead changes the timing enough to hide the race. :( I am compiling a new kernel with INVARIANTS and WITNESS now. Will wait for a "better" panic ;-) -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote: > I have the following panic occurring several times a week. The machine is > an NFS server, and it usually panics early in the morning, when first > people try to access it. After reboot it may work OK for 1-2 days, and then > panics again. I have tried changing memory and replacing disk which was > exported via NFS, but nothing helped :( > > Any suggestion on how to fix this panic will be very much appreciated ! This panic (in propagate_priority) is usually caused when a thread goes to sleep while holding a mutex (which is forbidden). If you enable INVARIANTS and/or WITNESS you should get a better panic, and with WITNESS you will even be warned when a thread goes to sleep while holding a mutex. However, these options do introduce considerable execution overhead, and sometimes that overhead changes the timing enough to hide the race. :( -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
I have the following panic occurring several times a week. The machine is an NFS server, and it usually panics early in the morning, when first people try to access it. After reboot it may work OK for 1-2 days, and then panics again. I have tried changing memory and replacing disk which was exported via NFS, but nothing helped :( Any suggestion on how to fix this panic will be very much appreciated ! /Yuri [EMAIL PROTECTED]/var/crash]# uname -a FreeBSD XXX.irfu.se 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Nov 29 13:31:15 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HEM i386 [EMAIL PROTECTED]/var/crash]# kgdb /usr/obj/usr/src/sys/HEM/kernel.debug vmcore.7 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x74 fault code = supervisor read, page not present instruction pointer = 0x20:0xc053a426 stack pointer = 0x28:0xd56c0b88 frame pointer = 0x28:0xd56c0b8c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 77 (vnlru) trap number = 12 panic: page fault Uptime: 2d12h22m11s Dumping 511 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc051577a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0515a84 in panic (fmt=0xc06ce475 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc06b4815 in trap_fatal (frame=0xd56c0b48, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc06b3f2d in trap (frame= {tf_fs = 1133445128, tf_es = 40, tf_ds = 40, tf_edi = -1017997312, tf_esi = -1020120704, tf_ebp = -714339444, tf_isp = -714339468, tf_ebx = -1012942272, tf_edx = -1020120704, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068260314, tf_cs = 32, tf_eflags = 589831, tf_esp = -1020120704, tf_ss = -714339408}) at /usr/src/sys/i386/i386/trap.c:269 #5 0xc06a24fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc053a426 in turnstile_setowner (ts=0xc39fba40, owner=0x0) at /usr/src/sys/kern/subr_turnstile.c:417 #7 0xc053a752 in turnstile_wait (lock=0xc461fe00, owner=0x0) at /usr/src/sys/kern/subr_turnstile.c:576 #8 0xc050b511 in _mtx_lock_sleep (m=0xc461fe00, tid=3274846592, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:555 #9 0xc064becd in ufsdirhash_free (ip=0xc4a33840) at /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 #10 0xc064de66 in ufs_reclaim (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:175 #11 0xc06bef38 in VOP_RECLAIM_APV (vop=0x0, a=0xc3323180) at vnode_if.c:1589 #12 0xc057adfe in vgonel (vp=0xc3cf3aa0) at vnode_if.h:818 #13 0xc0577530 in vtryrecycle (vp=0xc3cf3aa0) at /usr/src/sys/kern/vfs_subr.c:840 #14 0xc0576ec6 in vnlru_free (count=1376) at /usr/src/sys/kern/vfs_subr.c:668 #15 0xc0577019 in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:703 #16 0xc04fc310 in fork_exit (callout=0xc0576f24 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 #17 0xc06a255c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) quit -- Dr. Yuri Khotyaintsev Institutet för rymdfysik (IRF), Uppsala ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wednesday 29 June 2005 16:42, Dominic Marks wrote: > Hello, > > I'm trying to use graid3 to create a raid volume from three > 250GB SATA discs. I can successfully label, format, and mount > the disc. The problem arises when I try and migrate some data > on to the new volume. I'm using rsync to do this from over the > local network, unfortunately this seems to be produce an > immediate and reproduceable panic (hand copied): > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xc30f8000 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc05e9783 > stack pointer = 0x10:0xd8030c38 > frame pointer = 0x10:0xd8030c80 > 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 = 617 (g_raid3 raid) > trap number = 12 > panic: page fault Having recompiled I can no longer produce the panic. I think I may have caused it myself, I had forgotten that I had been tinkering with some values in sys/sys/param.h last week, but it didn't ring a bell when the system went down. I'd been running with MAXPHYS and DFLTPHYS at 256 and it seems graid3 does not like one of those paramters being raised, I suspect its DFLTPHYS and that perhaps graid3 depends on its value for some calculations. This is pure speculation. My apologies for the incorrect report. > Other programs (touch, ls, diskinfo, etc) do not seem to provoke > the panic, but rsync will kill the system within a second. > > I got a dump (once), but I think it is corrupt in some way > because I have not been able to get a backtrace or any other > useful data from it. > > # kgdb kernel.debug /usr/crash/vmcore.0 > kgdb: kvm_read: invalid address (f9) > > (This line is printed again, and again, and again ...) > > This may be because I compiled my debugging kernel after I had > installed the system, although it should have been an identical > source tree ... I'm currently rebuilding the system to > the freshest available -STABLE in the hope that may give a > full backtrace. > > FreeBSD mrt.helenmarks.co.uk 5.4-STABLE FreeBSD 5.4-STABLE #0 > Mon Jun 27 09:34:02 BST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV i386 > > The only thing slightly odd about the machine is that each > disc is one its own SATA controller. One disc is attached to an > Intel ICH6 the other two are attached two Silicon Image (3112) > based cards. The root device is ad2, since the additional cards > have pushed themselves to the front. This is a temporary setup > to facilitate migration of data from system to system. > > If I can do anything to help track the problem down, please say. > I really want this to work, and I have some time in which to run > tests. > > * A side note, I have noticed that the panic is often accompanied by > a ATA DMA timeout (ad1). Could this cause the panic to occur? > > Copyright (c) 1992-2005 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 5.4-STABLE #0: Mon Jun 27 09:34:02 BST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 2.53GHz (2527.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PB >E> real memory = 526958592 (502 MB) > avail memory = 509628416 (486 MB) > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > lapic0: Forcing LINT1 to edge trigger > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pci0: at device 2.0 (no driver attached) > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > bge0: mem > 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:11:11:c3:2c:91 > pcib3: irq 17 at device 28.1 on pci0 > pci3: on pcib3 > p
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wednesday 29 June 2005 18:14, Kris Kennaway wrote: > On Wed, Jun 29, 2005 at 04:42:49PM +0100, Dominic Marks wrote: > > This may be because I compiled my debugging kernel after I had > > installed the system, although it should have been an identical > > source tree ... I'm currently rebuilding the system to > > the freshest available -STABLE in the hope that may give a > > full backtrace. > > Yes, you can have this kind of problem if you compile a kernel.debug > "after the fact" and it doesn't quite match. Good to know, thank you. I've just built a fresh -stable system, so I will attempt to get the panic again with some useful information this time. > Kris Cheers, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
On Wed, Jun 29, 2005 at 04:42:49PM +0100, Dominic Marks wrote: > This may be because I compiled my debugging kernel after I had > installed the system, although it should have been an identical > source tree ... I'm currently rebuilding the system to > the freshest available -STABLE in the hope that may give a > full backtrace. Yes, you can have this kind of problem if you compile a kernel.debug "after the fact" and it doesn't quite match. Kris pgpOEvifiGsMv.pgp Description: PGP signature
graid3 + rsync + 5.4-STABLE repeatable panic (Fatal trap 12: page fault while in kernel mode)
Hello, I'm trying to use graid3 to create a raid volume from three 250GB SATA discs. I can successfully label, format, and mount the disc. The problem arises when I try and migrate some data on to the new volume. I'm using rsync to do this from over the local network, unfortunately this seems to be produce an immediate and reproduceable panic (hand copied): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc30f8000 fault code = supervisor write, page not present instruction pointer = 0x8:0xc05e9783 stack pointer = 0x10:0xd8030c38 frame pointer = 0x10:0xd8030c80 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 = 617 (g_raid3 raid) trap number = 12 panic: page fault Other programs (touch, ls, diskinfo, etc) do not seem to provoke the panic, but rsync will kill the system within a second. I got a dump (once), but I think it is corrupt in some way because I have not been able to get a backtrace or any other useful data from it. # kgdb kernel.debug /usr/crash/vmcore.0 kgdb: kvm_read: invalid address (f9) (This line is printed again, and again, and again ...) This may be because I compiled my debugging kernel after I had installed the system, although it should have been an identical source tree ... I'm currently rebuilding the system to the freshest available -STABLE in the hope that may give a full backtrace. FreeBSD mrt.helenmarks.co.uk 5.4-STABLE FreeBSD 5.4-STABLE #0 Mon Jun 27 09:34:02 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV i386 The only thing slightly odd about the machine is that each disc is one its own SATA controller. One disc is attached to an Intel ICH6 the other two are attached two Silicon Image (3112) based cards. The root device is ad2, since the additional cards have pushed themselves to the front. This is a temporary setup to facilitate migration of data from system to system. If I can do anything to help track the problem down, please say. I really want this to work, and I have some time in which to run tests. * A side note, I have noticed that the panic is often accompanied by a ATA DMA timeout (ad1). Could this cause the panic to occur? Copyright (c) 1992-2005 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 5.4-STABLE #0: Mon Jun 27 09:34:02 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEV WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.53GHz (2527.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff real memory = 526958592 (502 MB) avail memory = 509628416 (486 MB) ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci0: at device 2.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 bge0: mem 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:11:c3:2c:91 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 atapci0: port 0xdce0-0xdcef,0xdcb4-0xdcb7,0xdcc8-0xdccf,0xdcb0-0xdcb3,0xdcc0-0xdcc7 mem 0xdfaffc00-0xdfaffdff irq 17 at device 1.0 on pci4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0xdcf0-0xdcff,0xdcbc-0xdcbf,0xdcd8-0xdcdf,0xdcb8-0xdcbb,0xdcd0-0xdcd7 mem 0xdfaffe00-0xdfaf irq 18 at device 2.0 on pci4 ata4: channel #0 on atapci1 ata5: channel #1 on atapci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 16 at device 31.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 atapci3: port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 20 at device 31.2 on pci0 ata6: channel #0 on atapci3 ata7: channel #1 on atapci3 ichsmb0: port 0xece0-0xecff irq 17 at device 31.3 on pci0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0:
Re: panic: Fatal trap 12: page fault while in kernel mode
On Thu, 17 Feb 2005, Rong-En Fan wrote: > On Wed, 16 Feb 2005 15:36:25 -0800 (PST), Doug White > <[EMAIL PROTECTED]> wrote: > > On Wed, 16 Feb 2005, Rong-En Fan wrote: > > > > > Hello, > > > > > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > > > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > > > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > > > /da0/ I can *reproduce* this panic again and again: > > > (I'm getting a dump now, let me fsck first) > > > kernel conf & dmesg (boot -v) are at > > > http://rafan.infor.org/tmp/236/ > > > > I only have an 2x244 Opteron box so I'm not sure if this is a problem with > > KSE or with hyperthreading. I'll try the benchmark anyway and see if I > > can reproduce. > > > > Looks like I'll need to rebuild first, I'm getting the "exiting from > > __thread_start" error... I got a good -CURRENT build and run this test. It appears to get stuck in an endless loop at the end but no panics result. I also ran it on a i386 -CURRENT machine for comparison and that completed, so this program appears to have 64-bit cleanliness problems. I'll see if I can build a RELENG_5 or 5.3 amd64 box and run the same diagnostic. Its possible its a bug thats been fixed in CURRENT but not backported yet. > If I use machdep.hlt_logical_cpus=1, I got the same panic. > And when I use kgdb to read the kernel dump, I see only > #1 ?? (??) in backtrace. > > I just reinstall the system to 5.3-p5, i386. It does not > panic and finsih the test two times. I'll run more to see if is > panics. > > Regards, > Rong-En Fan > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Fatal trap 12: page fault while in kernel mode
On Wed, 16 Feb 2005 15:36:25 -0800 (PST), Doug White <[EMAIL PROTECTED]> wrote: > On Wed, 16 Feb 2005, Rong-En Fan wrote: > > > Hello, > > > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > > /da0/ I can *reproduce* this panic again and again: > > (I'm getting a dump now, let me fsck first) > > kernel conf & dmesg (boot -v) are at > > http://rafan.infor.org/tmp/236/ > > I only have an 2x244 Opteron box so I'm not sure if this is a problem with > KSE or with hyperthreading. I'll try the benchmark anyway and see if I > can reproduce. > > Looks like I'll need to rebuild first, I'm getting the "exiting from > __thread_start" error... If I use machdep.hlt_logical_cpus=1, I got the same panic. And when I use kgdb to read the kernel dump, I see only #1 ?? (??) in backtrace. I just reinstall the system to 5.3-p5, i386. It does not panic and finsih the test two times. I'll run more to see if is panics. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Fatal trap 12: page fault while in kernel mode
On Wed, 16 Feb 2005, Rong-En Fan wrote: > Hello, > > This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM > and a LSI 21320 rmpt(4) running at 160MB/s with a hardware > RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on > /da0/ I can *reproduce* this panic again and again: > (I'm getting a dump now, let me fsck first) > kernel conf & dmesg (boot -v) are at > http://rafan.infor.org/tmp/236/ I only have an 2x244 Opteron box so I'm not sure if this is a problem with KSE or with hyperthreading. I'll try the benchmark anyway and see if I can reproduce. Looks like I'll need to rebuild first, I'm getting the "exiting from __thread_start" error... > > any suggestions are welcome. :) > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 06 > fault virtual address = 0x88 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x80235b0b > stack pointer = 0x10:0xb1bd5a50 > frame pointer = 0x10:0xb1bd5a70 > code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 96 (pagedaemon) > [thread 100114] > Stopped at thread_fini+0xab: subl0x88(%ebx),%eax > db> trace > thread_fini() at thread_fini+0xab > zone_drain() at zone_drain+0x22d > zone_foreach() at zone_foreach+0x76 > uma_reclaim() at uma_reclaim+0x15 > vm_pageout_scan() at vm_pageout_scan+0x170 > vm_pageout() at vm_pageout+0x38e > fork_exit() at fork_exit+0xaa > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- > db> ps > pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd > 615 ff00603348b8 b43b50000 568 615 000c082 > (threaded) blogbench > thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d19c40][SLP] > thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d37640][SLP] > thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a373640][SLP] > thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a2d8b40][SLP] > thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f1c140][SLP] > thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a104e40][SLP] > thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff0059594c80][SLP] > thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a237740][SLP] > thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff00087c1500][SLP] > thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99ee8e40][SLP] > thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d86840][SLP] > thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] > thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99fbb440][SLP] > thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99a01640][SLP] > thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a069140][SLP] > thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f9c540][SLP] > thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99d7c940][SLP] > thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99f22d40][SLP] > thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99a6c140][SLP] > thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs > 0xff0059112500][SLP] > thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a315440][SLP] > thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99ff1d40][SLP] > thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99fe2140][SLP] > thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x999d1340][SLP] > thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x9a2bc040][SLP] > thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99bc8440][SLP] > thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord > 0x99c2ed40][SLP] > thread 0xff
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99dc3440][SLP] thread 0xff00
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0xf
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
In message <[EMAIL PROTECTED]>, Peter Jeremy wri tes: >On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: >> I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic >> occurs seems to happen when I'm running rsync of large directories >> possibly in combination with reading or writing to a compact flash >> attached to USB. > >Having just looked into an identical panic, the problem is an >interface bug between bus_dmamem_alloc() and contigmalloc(). It's >nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x. The USB code is not entirely free of blame here however. It allocates numerous big chunks of contiguous memory for tranfer buffers instead of using the (admittedly limited) scatter-gather capabilities of the USB host controllers. Try applying the change from revision 1.6 of usb_mem.c. This fixed one particularly inefficient memory use behaviour in the USB code. That change is already in 5.x and 6.x, but wasn't merged to 4.x. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_mem.c Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: > I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic > occurs seems to happen when I'm running rsync of large directories > possibly in combination with reading or writing to a compact flash > attached to USB. Having just looked into an identical panic, the problem is an interface bug between bus_dmamem_alloc() and contigmalloc(). It's nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x. The relevant part of my backtrace looks like: #15 0xc028aaef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -980715140, tf_ebp = -1070676940, tf_isp = -1070676996, tf_ebx = 0, tf_edx = 6867008, tf_ecx = -1056660992, tf_eax = 7261248, tf_trapno = 12, tf_err = 0, tf_eip = -1072225192, tf_cs = 8, tf_eflags = 66118, tf_esp = -1065633592, tf_ss = 0}) at /home/src/sys/i386/i386/trap.c:466 #16 0xc0172458 in tsleep (ident=0xc58b797c, priority=4, wmesg=0xc02bfd27 "swwrt", timo=0) at /home/src/sys/kern/kern_synch.c:436 #17 0xc021e60f in swap_pager_putpages (object=0xd03c6e04, m=0xc02ec50c, count=1, sync=1, rtvals=0xc02ec4b0) at /home/src/sys/vm/swap_pager.c:1431 #18 0xc021ceaf in default_pager_putpages (object=0xd03c6e04, m=0xc02ec50c, c=1, sync=0, rtvals=0xc02ec4b0) at /home/src/sys/vm/default_pager.c:133 #19 0xc0228ca4 in vm_pageout_flush (mc=0xc02ec50c, count=1, flags=0) at /home/src/sys/vm/vm_pager.h:147 #20 0xc02285c9 in contigmalloc1 (size=36864, type=0xc02f4340, flags=1, low=0, high=4294967295, alignment=1, boundary=0, map=0xc03372ac) at /home/src/sys/vm/vm_page.c:1855 #21 0xc022887f in contigmalloc (size=36864, type=0xc02f4340, flags=1, low=0, high=4294967295, alignment=1, boundary=0) at /home/src/sys/vm/vm_page.c:1980 #22 0xc027bd3b in bus_dmamem_alloc (dmat=0xc176b4c0, vaddr=0xc1231a48, flags=1, mapp=0xc1231a44) at /home/src/sys/i386/i386/busdma_machdep.c:351 #23 0xc0231be2 in usb_block_allocmem (tag=0x0, size=36864, align=1, dmap=0xc17d8d3c) at /home/src/sys/dev/usb/usb_mem.c:186 ... #35 0xc022d4ea in uhci_intr (arg=0xc104f000) at /home/src/sys/dev/usb/uhci.c:1175 #36 0xc02841f2 in cpu_idle () at /home/src/sys/i386/i386/machdep.c:1000 Basically, the USB code is trying to allocate ~36KB RAM within an interrupt handler. usb_block_allocmem() invokes bus_dmamem_alloc() with BUS_DMA_NOWAIT (advising that sleep()ing is not allowed). Since more than one page of memory is requested, bus_dmamem_alloc() uses contigmalloc() to allocate the requested memory. The BUS_DMA_NOWAIT flag is mapped to M_NOWAIT but contigmalloc() does not support M_NOWAIT. Unfortunately, I don't know enough about the VM code to be able to suggest a fix. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_5: Fatal trap 12: page fault while in kernel mode
I got this when I tried to blank a CD with burncd, and I can reproduce it. Most of it is written by hand, and I'm no debugger guru, so here goes... This is RELENG_5, cvsup'ed and built today (dmesg is attached): # uname -a FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Jan 1 14:36:28 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WRK i386 # burncd -f /dev/acd0 blank fixate blanking CD - 100% done fixating CD, please wait.. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfffc fault code = supervisor read, page not present instruction pointer = 0x8:0xc052cb63 stack pointer = 0x10:0xd5453c08 frame pointer = 0x10:0xd5453c28 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 6 (thread taskq) [thread 100047] Stopped at turnstile_wait+0xa3:movl0(%edx),%eax db> trace turnstile_wait(0,c1c1c368,fffc,220,c1c1c368) at turnstile_wait+0xa3 _mtx_lock_sleep(c1c1c368,c1a3baf0,0,c06d246a,4f) at _mtx_lock_sleep +0x12c _mtx_lock_flags(c1c1c368,0,c06d246a,4f,1) at _mtx_lock_flags+0xbf _sema_post(c1c1c368,c06c1ac2,18b,c1a29c58) at _sema_post+0x2a ata_completed(c1c1c320,1,c06d524a,bd,c1a29c58) at ata_completed+0x44b taskqueue_run(c1a29c40,c1a29c58,5c,c06cc2f9,0) at taskqueue_run+0xb2 taskqueue_thread_loop(c0733148,d5453d48,c06cfc49,31f,c0733148) at taskqueue_thread_loop+0x3b fork_exit(c052b620,c0733148,d5453d48) at fork_exit+0xc6 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd5453d7c, ebp = 0 --- db> show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0 ecx0x1 edx 0xfffc ebx 0xc1c1c368 esp 0xd5453c08 ebp 0xd5453c28 esi 0xc1a3baf0 edi 0 eip 0xc052cb63 turnstile_wait+oxa3 efl0x10006 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 turnstile_wait+0xa3:movl0(%edx),%eax db> call doadump Dumping 511 MB panic: blockable sleep lock (sleep mutex) taskqueue @ /usr/src/sys/kern/subr_taskqueue.c:132 Uptime: 13:50s I reproduced the original panic again, and did this at the prompt: db> cont panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/i386/i386/ trap.c:699 KDB: enter: panic [thread 100047] Stopped at kdb_enter+0x30: leave db> call doadump Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 Dump complete 0xf db> reset So, kgdb gives me this: # kgdb kernel.debug vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "p s_pglobal_lookup"] 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". doadump () at pcpu.h:159 (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc044e695 in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xd5453928 "@ar@") at /usr/src/sys/ddb/db_command.c:531 #2 0xc044e412 in db_command (last_cmdp=0xc07258c4, cmd_table=0x0, aux_cmd_tablep=0xc06f19ec, aux_cmd_tablep_end=0xc06f19f0) at /usr/src/sys/ddb/db_command.c:349 #3 0xc044e51a in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0450515 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0523bf7 in kdb_trap (type=0, code=0, tf=0xd5453a74) at /usr/src/sys/kern/subr_kdb.c:418 #6 0xc0694a8a in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1066575188, tf_ebp = -716883268, tf_isp = -716883296, tf_ebx = -7168832 at /usr/src/sys/i386/i386/trap.c:576 #7 0xc0682c1a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0x0018 in ?? () #9 0x0010 in ?? () #10 0x0010 in ?? () #11 0x0001 in ?? () #12 0xc06d5aac in ?? () #13 0xd5453abc in ?? () #14 0xd5453aa0 in ?? () #15 0xd5453af4 in ?? () #16 0x0001 in ?? () #17 0xc1015000 in ?? () #18 0x0012 in ?? () #19 0x0003 in ?? () #20 0x in ?? () #21 0xc0523900 in kdb_enter (msg=0x0) at cpufunc.h:56 #22 0xc050874c in panic ( fmt=0xc06d5aac "blockable sleep lock (%s) %s @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:550 #23 0xc052e03e in witness_checkorder (lock=0xc1a3a3f4, flags=9, file=0xc06
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: > > I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic > occurs seems to happen when I'm running rsync of large directories > possibly in combination with reading or writing to a compact flash > attached to USB. > > I've attached the panic message, dmesg output, and gdb output. > > If there's any additional informtion I can provide to try and resolve > the problem, please ask. I'm willing to put some effort into fixing the > problem. > > Any and all help is greatly appreciated. Yeah, looks like the USB code is implicated. You might like to try 5.3 or RELENG_5, I think there was some work done there to clean it up a bit. Kris pgpZbF4rqLSAB.pgp Description: PGP signature
4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic occurs seems to happen when I'm running rsync of large directories possibly in combination with reading or writing to a compact flash attached to USB. I've attached the panic message, dmesg output, and gdb output. If there's any additional informtion I can provide to try and resolve the problem, please ask. I'm willing to put some effort into fixing the problem. Any and all help is greatly appreciated. -- Scott Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0100 fault virtual address = 0x70 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0172b0c stack pointer = 0x10:0xffc11cf0 frame pointer = 0x10:0xffc11d14 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 = Idle interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Copyright (c) 1992-2004 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 4.10-RELEASE-p3 #1: Thu Nov 11 20:54:12 PST 2004 [EMAIL PROTECTED]:/usr/src/sys/compile/LILO Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (930.39-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 4227858432 (4128768K bytes) config> di bt0 No such device: bt0 Invalid command or syntax. Type `?' for help. config> di aic0 No such device: aic0 Invalid command or syntax. Type `?' for help. config> di aha0 No such device: aha0 Invalid command or syntax. Type `?' for help. config> di adv0 No such device: adv0 Invalid command or syntax. Type `?' for help. config> q avail memory = 4119408640 (4022860K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc03af000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03af09c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00f51d0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #1 intpin 6 -> irq 2 IOAPIC #1 intpin 4 -> irq 9 IOAPIC #1 intpin 5 -> irq 10 IOAPIC #0 intpin 10 -> irq 11 pci0: on pcib0 pci0: at 1.0 irq 2 fxp0: port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafe000-0xfeafefff irq 9 at device 4.0 on pci0 fxp0: Ethernet address 00:e0:81:02:11:cc inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xd000-0xd03f mem 0xfe70-0xfe7f,0xfeafd000-0xfeafdfff irq 10 at device 5.0 on pci0 fxp1: Ethernet address 00:e0:81:02:11:cd inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfeafc000-0xfeafcfff irq 11 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered umass0: vendor 0x55aa USB 2.0 7-2-2, rev 2.00/2.00, addr 2 pcib1: on motherboard pci1: on pcib1 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff on isa0 pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port not found. APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 SMP: AP CPU #1 Launched! ad0: 238475MB [484521/16/63] at ata0-master UDMA33 ad1: 238475MB [484521/16/63] at ata0-slave UDMA33 acd0: DVD-R at ata1-master UD
Re: Resolution of Fatal trap 12: page fault while in kernel mode
* Ernst de Haan ([EMAIL PROTECTED]): > The most obvious possibility seems to be 'maxusers 0' No. This just means to autoconfigure a value according to the amount of memory present at configure time. --Thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Fatal trap 12: page fault while in kernel mode
On Wed, Feb 19, 2003 at 04:40:58PM +0100, Mario Pranjic wrote: > > Is there a possibility that a memory chip is dead (or should I say > > deadish)? > > As I said, the memory died. :) > The Memtest86 returned a lot of errors. I've replaced the memory module > and now it seems all right. It's so nice when problems are easily resolved :) Kris msg53814/pgp0.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode
> Is there a possibility that a memory chip is dead (or should I say > deadish)? As I said, the memory died. :) The Memtest86 returned a lot of errors. I've replaced the memory module and now it seems all right. Mario Pranjic, dipl.ing. sistem administrator Knjiznica, Institut Rudjer Boskovic - e-mail: [EMAIL PROTECTED] ICQ: 72059629 tel: +385 1 45 60 954 (interni: 1293) - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [JUPITER] Fatal trap 12: page fault while in kernel mode (Was:Re: Woo hoo ... it crashed!! )
(adding the general list back in!) : :On Thu, 5 Sep 2002, Matthew Dillon wrote: : :> Whew! These are big! :-). I've got jupiter's files downloaded, now :> it's working on venus. : :Ya, both are 4gig servers :) That was why netdump was so critical, cause :they are also both production servers, so choking it back at 2gig *really* :hurt ;) : Ok, you are running out of KVM! Yes indeed, that is what is happening. It must be happening quickly or that while loop diagnostic you did would have caught it. (kgdb) print kernel_vm_end $77 = 0xff40 I'm not entirely sure but I believe SMP boxes reserve more page table pages then non-SMP boxes (e.g. an extra segment or two, and each segment represents 4MB of VM). So this could be hitting the limit. I'm going to dump a bunch of statistics first, then I'll analyize them: (kgdb) zlist 0xc943e780 NFSNODE0 init + 56109152 dyn = 56109152 0xc943e800 NFSMOUNT 0 init +83776 dyn =83776 0xc92db580 PIPE 0 init + 799680 dyn = 799680 0xc92b4a80 SWAPMETA37282560 init + 1044480 dyn = 38327040 0xc92b4f80 unpcb 0 init + 40 dyn = 40 0xc9254000 ripcb2949120 init + 8064 dyn = 2957184 0xc9254080 syncache 2457440 init +16320 dyn = 2473760 0xc9254100 tcpcb8355840 init + 1114112 dyn = 9469952 0xc9254180 udpcb2949120 init +81792 dyn = 3030912 0xc9254200 socket 2949120 init + 794496 dyn = 3743616 0xc9254280 DIRHASH0 init + 2007040 dyn = 2007040 0xc9254300 KNOTE 0 init +12288 dyn =12288 0xc9032d00 VNODE 0 init + 45344256 dyn = 45344256 0xc9032d80 NAMEI 0 init + 139264 dyn = 139264 0xc6302a80 VMSPACE0 init + 700416 dyn = 700416 0xc6302b00 PROC 0 init + 1528800 dyn = 1528800 0xc0228e40 DP fakepg 0 init +0 dyn =0 0xc0239b40 PV ENTRY92320648 init + 28901124 dyn = 121221772 0xc0228fc0 MAP ENTRY 0 init + 5334624 dyn = 5334624 0xc0228f60 KMAP ENTRY 1218 init + 673776 dyn = 12853776 0xc0229020 MAP0 init + 1080 dyn = 1080 0xc022c700 VM OBJECT 0 init + 26998656 dyn = 26998656 TOTAL ZONE KMEM RESERVED: 132546560 init + 147156992 dynamic = 279703552 Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) linux 7 1K 1K102400K70 0 32 NFS hash 1 512K512K102400K10 0 512K NQNFS Lease 1 1K 1K102400K10 0 1K NFSV3 srvdesc28 1K 4K102400K3144846270 0 16,256 NFSV3 diroff 14573K355K102400K418170 0 512 NFS daemon69 7K 7K102400K 690 0 64,256,512 NFS req 1 1K 3K102400K1573775730 0 64 NFS srvsock 1 1K 1K102400K10 0 256 atkbddev 2 1K 1K102400K20 0 32 memdesc 1 4K 4K102400K10 0 4K mbuf 124K 24K102400K10 0 32K isadev 4 1K 1K102400K40 0 64 ZONE16 2K 2K102400K 160 0 128 VM pgdata 1 128K128K102400K10 0 128K file desc 3174 913K 1280K102400K 5035340 0 256,512,1K,2K,4K,8K UFS dirhash 1593 636K 1158K102400K 2234400 0 16,32,64,128,256,512,1K,4K,8K UFS mount1559K 59K102400K 150 0 512,2K,8K,32K UFS ihash 1 512K512K102400K10 0 512K FFS node210654 52664K 58024K102400K1226980880 0 256 dirrem 130 5K952K102400K 4808900 0 32 mkdir 0 0K 7K102400K 16120 0 32 diradd 130 5K101K102400K 4181370 0 32 freefile62 2K727K102400K 2488610 0 32 freeblks7410K 2493K102400K 2133100 0 128 freefrag 6 1K 23K102400K 1420180 0 32 allocindir 1 1K289K102400K 4413310 0 64 indirdep 2 1K 81K102400K132490 0 32,8K allocdirect24 2K124K102400K 3383100 0 64 bmsafemap26 1K 5K102400K 2040680 0 32 newblk 1 1K 1K102400K 7796420 0 32,256 inodedep 262 545K 4055K102400K 6011350 0 128,512K pagedep 175 139K277K102400K 2985940 0 64,128K p1003.1b 1 1K 1K102400K10 0 16 syncache 1 8K 8K10
Fatal trap 12: page fault while in kernel mode.
I think i have the same problem that described in other mails like 4.5-STABLE softupdates brokeness: repeated panics and lockups and others on this mailing list. It has come just after a software and hardware upgrade of my server to 4.5-STABLE. I've tried diferent things to solve that: Tried changing All of the hardware except the hard-drives used for data. I've use A7V266-E, A7A266 and an old P2L97 motherboards with different processors and memory, diferents SCSIi (ahc), LANi(de & fxp), and VGA cards and another box. My server always reboot with the same Fatal Trap 12 on process find, cvsup or cvsupd. I actualy solved this problem by using 4.4-RELEASE-p9 kernel with my -stable userland, the box seem to run fine running repeated find. I can't stop this server because this is {ftp2|www|cvsup}.fr.freebsd.org but i can set up a config that crashes with the hardware that i've tested to get traces. -- Olivier Girard -=- Service réseau de l'université d'Angers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message