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 bschm...@freebsd.org
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 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
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 Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt bschm...@freebsd.org 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 15:15:45 Gardner Bell wrote: On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt bschm...@freebsd.org 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 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 bschm...@freebsd.org
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
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 ithread_loop, 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
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8256184320 (7873 MB) ACPI APIC Table: A_M_I_ OEMAPIC 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 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: software crypto on motherboard acpi0: A_M_I_ OEMXSDT 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: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xb000-0xb0ff mem 0xd000-0xdfff,0xfe8e-0xfe8e irq 16 at device 0.0 on pci1 drm0: ATI Radeon HD 4770 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: ATI RV730 High Definition Audio Controller mem 0xfe8fc000-0xfe8f irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] uhci0: Intel 82801I (ICH9) USB controller port 0xa800-0xa81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port 0xa880-0xa89f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: Intel 82801I (ICH9) USB controller on uhci1 uhci2: Intel 82801I (ICH9) USB controller port 0xac00-0xac1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: Intel 82801I (ICH9) USB controller on uhci2 ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xfe7ffc00-0xfe7f irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: Intel 82801I (ICH9) USB 2.0 controller on ehci0 hdac1: Intel 82801I High Definition Audio Controller mem 0xfe7f8000-0xfe7fbfff irq 22 at device 27.0 on pci0 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci4: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0 pci3: ACPI PCI bus on pcib3 ahci0: JMicron JMB363 AHCI SATA controller 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: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 1 on ahci0 ahcich1: [ITHREAD] atapci0: JMicron JMB363 UDMA133 controller port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f at device 0.1 on pci3 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci2: ACPI PCI bus on pcib4 mskc0: Marvell Yukon 88E8056 Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe9fc000-0xfe9f irq 17 at device 0.0 on pci2 msk0: Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03 on mskc0 msk0: Ethernet address: 00:1d:60:a6:fa:74 miibus0: MII bus on msk0 e1000phy0: Marvell 88E1149 Gigabit PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
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
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 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 Address 0x104 out of
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
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
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
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 Address 0x104 out of
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
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 180
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 ithread_loop, 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 error = (*callp-sy_call)(td, args);
(kgdb) l
979 STOPEVENT(p, S_SCE, narg);
980
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=113823cat=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 taskqueue_thread_loop,
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 Apr 2 13:53:14 PDT
2007' and it's been up for 108 days now without any issues. I've
submited this time and time again to the mailing lists and never found a
real answer, finally I just resorted to trying this 6.2-STABLE, now
since last month I updated the other 9 machines and haven't had this
panic at all.
Here is one of the original threads I started regarding this issue:
http://monkey.org/freebsd/archive/freebsd-hackers/200703/msg00127.html
Cheers,
Scott Oertel
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=113823cat=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 taskqueue_thread_loop,
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.420r2=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 /usr/src/sys/kern/sys_generic.c:402
#13 0x802ba6da in write (td=0x0, uap=0x0) at
/usr/src/sys/kern/sys_generic.c:326
#14 0x803c6db2 in syscall (frame=
{tf_rdi = 3, tf_rsi = 140737488344336
[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.420r2=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 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
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 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. 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 ^^^ #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
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 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 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
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, tf_ebp = -1077942616, tf_isp = -342033052,
tf_ebx = 673713536, tf_edx = 4096, tf_ecx = 0, tf_eax = 4, tf_trapno = 0,
#tf_err
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]
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:
6external: 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 ithread_loop, 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
makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
options KDB
options DDB
options
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:
6external: 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 ithread_loop, 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
makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
options KDB
options DDB
options
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 Address 0xc102 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
taskqueue_thread_loop, 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]
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 Address 0xc102 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
taskqueue_thread_loop, 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
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 Address 0xc1 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
taskqueue_thread_loop, 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
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 Address 0xc1 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
taskqueue_thread_loop, 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]
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 Address 0xc102 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
taskqueue_thread_loop, 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 ?? ()
#60 0xc24b4600 in ?? ()
#61
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 ?? ()
#60 0xc24b4600 in ?? ()
#61
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
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]
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: PTLTDAPIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel Pentium III (789.10-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
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 Version 1.1 irqs 0-15 on motherboard
ioapic1 Version 1.1 irqs 16-31 on motherboard
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTD HWPC20A 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: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
fxp0: Intel 82559 Pro/100 Ethernet port 0x1800-0x183f mem
0xf4001000-0xf4001fff,0xf410-0xf41f irq 17 at device 3.0 on pci0
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:03:47:3a:97:a5
fxp1: Intel 82559 Pro/100 Ethernet port 0x1840-0x187f mem
0xf4002000-0xf4002fff,0xf420-0xf42f irq 18 at device 4.0 on pci0
miibus1: MII bus on fxp1
inphy1: i82555 10/100 media interface on miibus1
inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:30:6e:06:8b:10
pci0: display, VGA at device 5.0 (no driver attached)
isab0: PCI-ISA bridge port 0x1040-0x104f
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 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
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 Address 0xfffe out of bounds, 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]
Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
check on apache22 configuration: Syntax OK Starting apache22. [Fri Mar 17 11:15:48 2006] [warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter Starting smartd. Mar 17 11:15:49 defweb smartd[413]: In the system's table of devices NO devices found to scan Starting proftpd. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial amd64 initialization:. Additional ABI support:. Starting cron. Local package initialization:. Additional TCP options:. Starting background file system checks in 60 seconds. Fri Mar 17 11:15:50 UTC 2006 Online 00:00 Offline FreeBSD/amd64 (..) (ttyd0) login: Online 00:00 Online 00:01 Online 00:02 Online 00:03 Online 00:04 Online 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
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
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 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)
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: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)
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)
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 Address 0xfffe out of bounds,
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
ithread_loop, 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 ts = td-td_blocked;
234 MPASS(ts
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
ithread_loop, arg=0xff0246c0,
frame=0xa52fec50) at ../../../kern/kern_fork.c:789
#19 0x8036e68e in fork_trampoline () at
../../../amd64/amd64/exception.S:394
#20
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]
[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 %s) at
/usr/src/sys/kern/kern_shutdown.c:555
td = (struct thread *) 0xc2247780
bootopt = 260
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]
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 Address 0xaa out of bounds, 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 return to continue, or q return 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, size=0, arg=0x0, flags=257)
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 vnlru_proc, 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: 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]
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]
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: DELL PESC420 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 526958592 (502 MB) avail memory = 509628416 (486 MB) ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PESC420 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: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci0: display, VGA at device 2.0 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 bge0: Broadcom BCM5751 Gigabit Ethernet, ASIC rev. 0x4001 mem 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:11:c3:2c:91 pcib3: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.3 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 atapci0: SiI 3112 SATA150 controller 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: SiI 3112 SATA150 controller 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
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
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 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: DELL PESC420 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, PGE,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 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PESC420 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: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci0: display, VGA at device 2.0 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 bge0: Broadcom BCM5751 Gigabit Ethernet, ASIC rev. 0x4001 mem 0xdfdf-0xdfdf irq 16 at device 0.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:11:11:c3:2c:91 pcib3: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB
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 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
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
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 0xff005cd927b0 ksegrp
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]
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]
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=0xc06ec8d0 /usr/src/sys/i386/i386/trap.c, line=699)
at /usr/src/sys/kern/subr_witness.c:714
#24 0xc04fe57a
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=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE 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: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks NB6635 3.0LE host to PCI bridge 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: PCI bus on pcib0 pci0: ATI Mach64-GR graphics accelerator at 1.0 irq 2 fxp0: Intel 82559 Pro/100 Ethernet 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: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel 82559 Pro/100 Ethernet 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: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: ServerWorks IB6566 PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 ATA33 controller port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: OHCI (generic) USB controller mem 0xfeafc000-0xfeafcfff irq 11 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller 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: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci1: PCI bus on pcib1 orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff on isa0 pmtimer0 on isa0 fdc0: NEC 72065B or clone 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: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0
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
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
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: 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: [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
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
