Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
ee or otherwise corrupted callout
> structure. Unfortunately the backtrace does not tell what was the
> callout. When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry Rosenman wrote:
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
>> main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
>> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> amd64
>>
>> VMCORE *IS* available.
>>
>>
>>
>>
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 20
>> fault virtual address = 0x0
>> fault code = supervisor write data, page not present
>> instruction pointer = 0x20:0x804e0db4
>> stack pointer = 0x0:0xfffffe0434de4e10
>> frame pointer = 0x0:0xfe0434de4e70
>> 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 = 82990 (c++)
>> trap number = 12
>> panic: page fault
>> cpuid = 0
>> time = 163998
>> KDB: stack backtrace:
>> #0 0x8050fc95 at kdb_backtrace+0x65
>> #1 0x804c468f at vpanic+0x17f
>> #2 0x804c4503 at panic+0x43
>> #3 0x807a2195 at trap_fatal+0x385
>> #4 0x807a21ef at trap_pfault+0x4f
>> #5 0x80779c78 at calltrap+0x8
>> #6 0x8045ddb8 at handleevents+0x188
>> #7 0x8045ea3e at timercb+0x24e
>> #8 0x807ca9eb at lapic_handle_timer+0x9b
>> #9 0x8077b9b1 at Xtimerint+0xb1
>> Uptime: 2h28m57s
>> Dumping 12829 out of 131023
>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>>
>> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
>> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
>> (offsetof(struct pcpu,
>> (kgdb) #0 __curthread () at
/usr/src/sys/amd64/include/pcpu_aux.h:55
>> #1 doadump (textdump=)
>> at /usr/src/sys/kern/kern_shutdown.c:399
>> #2 0x804c428c in kern_reboot (howto=260)
>> at /usr/src/sys/kern/kern_shutdown.c:487
>> #3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
>> ap=) at /usr/src/sys/kern/kern_shutdown.c:920
>> #4 0x804c4503 in panic (fmt=)
>> at /usr/src/sys/kern/kern_shutdown.c:844
>> #5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50,
eva=0)
>> at /usr/src/sys/amd64/amd64/trap.c:946
>> #6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
>> usermode=false, signo=, ucode=)
>> at /usr/src/sys/amd64/amd64/trap.c:765
>> #7
>> #8 0x804e0db4 in callout_process
>> (now=now@entry=38385536922300)
>> at /usr/src/sys/kern/kern_timeout.c:488
>> #9 0x8045ddb8 in handleevents
(now=now@entry=38385536922300,
>> fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
>> #10 0x8045ea3e in timercb (et=0x80d475e0 ,
>> arg=) at /usr/src/sys/kern/kern_clocksource.c:357
>> #11 0x807ca9eb in lapic_handle_timer
>> (frame=0xfe0434de4f40)
>> at /usr/src/sys/x86/x86/local_apic.c:1364
>> #12
>> #13 0x00080df42bb6 in ?? ()
>> Backtrace stopped: Cannot access memory at address 0x7def2c90
>> (kgdb)
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
lable.
>>
>>
>>
>>
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 20
>> fault virtual address = 0x0
>> fault code = supervisor write data, page not present
>> instruction pointer = 0x20:0x804e0db4
>> stack pointer = 0x0:0xfe0434de4e10
>> frame pointer = 0x0:0xfe0434de4e70
>> 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 = 82990 (c++)
>> trap number = 12
>> panic: page fault
>> cpuid = 0
>> time = 163998
>> KDB: stack backtrace:
>> #0 0x8050fc95 at kdb_backtrace+0x65
>> #1 0x804c468f at vpanic+0x17f
>> #2 0x804c4503 at panic+0x43
>> #3 0x807a2195 at trap_fatal+0x385
>> #4 0x807a21ef at trap_pfault+0x4f
>> #5 0x80779c78 at calltrap+0x8
>> #6 0x8045ddb8 at handleevents+0x188
>> #7 0x8045ea3e at timercb+0x24e
>> #8 0x807ca9eb at lapic_handle_timer+0x9b
>> #9 0x8077b9b1 at Xtimerint+0xb1
>> Uptime: 2h28m57s
>> Dumping 12829 out of 131023
>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>>
>> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
>> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
>> (offsetof(struct pcpu,
>> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
>> #1 doadump (textdump=)
>> at /usr/src/sys/kern/kern_shutdown.c:399
>> #2 0x804c428c in kern_reboot (howto=260)
>> at /usr/src/sys/kern/kern_shutdown.c:487
>> #3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
>> ap=) at /usr/src/sys/kern/kern_shutdown.c:920
>> #4 0x804c4503 in panic (fmt=)
>> at /usr/src/sys/kern/kern_shutdown.c:844
>> #5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50,
eva=0)
>> at /usr/src/sys/amd64/amd64/trap.c:946
>> #6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
>> usermode=false, signo=, ucode=)
>> at /usr/src/sys/amd64/amd64/trap.c:765
>> #7
>> #8 0x804e0db4 in callout_process
>> (now=now@entry=38385536922300)
>> at /usr/src/sys/kern/kern_timeout.c:488
>> #9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
>> fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
>> #10 0x8045ea3e in timercb (et=0x80d475e0 ,
>> arg=) at /usr/src/sys/kern/kern_clocksource.c:357
>> #11 0x807ca9eb in lapic_handle_timer
>> (frame=0xfe0434de4f40)
>> at /usr/src/sys/x86/x86/local_apic.c:1364
>> #12
>> #13 0x00080df42bb6 in ?? ()
>> Backtrace stopped: Cannot access memory at address 0x7def2c90
>> (kgdb)
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
On 12/17/2021 1:36 pm, Mark Johnston wrote: On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote: 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 14-2021_12_09-1957 NR / 121G 2021-12-09 19:57 If that's any help I can't tell what this is saying. A kernel built on the 7th does not crash, or...? Which revision did you update from before you started seeing crashes? From a kgdb session it'd be useful to see output from (kgdb) frame 8 (kgdb) p/x *tmp to start. Correct, the 7th didn't panic, but the 9th did, and yesterday's too. Grrr ler in borg in /mnt on ☁️ (us-east-1) ❯ kgdb -c /var/crash/vmcore.0 /mnt/boot/kernel/kernel GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /mnt/boot/kernel/kernel... (No debugging symbols found in /mnt/boot/kernel/kernel) Failed to open vmcore: /var/crash/vmcore.0: Permission denied (kgdb) bt No stack. quitb) ler in borg in /mnt on ☁️ (us-east-1) took 6s ❯ sudo chmod +r /var/crash/* ler in borg in /mnt on ☁️ (us-east-1) ❯ kgdb -c /var/crash/vmcore.0 /mnt/boot/kernel/kernel GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /mnt/boot/kernel/kernel... (No debugging symbols found in /mnt/boot/kernel/kernel) /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: internal-error: void switch_to_thread(thread_info *): Assertion `thr != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: internal-error: void switch_to_thread(thread_info *): Assertion `thr != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Command aborted. (kgdb) bt No thread selected. (kgdb) fr 8 No thread selected. (kgdb) On 12/10/2021 10:36 am, Alexander Motin wrote: > Hi Larry, > > This looks like some use-after-free or otherwise corrupted callout > structure. Unfortunately the backtrace does not tell what was the > callout. When was the previous update to look what could change? > > On 10.12.2021 11:24, Larry Rosenman wrote: >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >> main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021 >> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL >> amd64 >> >> VMCORE *IS* available. >> >> >> >> >> Unread portion of the kernel message buffer: >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 20 >> fault virtual address = 0x0 >> fault code = supervisor write data, page not present >> instruction pointer = 0x20:0x804e0db4 >> stack pointer = 0x0:0xfe0434de4e10 >> frame pointer = 0x0:0xfe0434de4e70 >> 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 = 82990 (c++)
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:
> 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17
> 14-2021_12_09-1957 NR / 121G 2021-12-09 19:57
>
> If that's any help
I can't tell what this is saying. A kernel built on the 7th does not
crash, or...? Which revision did you update from before you started
seeing crashes?
>From a kgdb session it'd be useful to see output from
(kgdb) frame 8
(kgdb) p/x *tmp
to start.
> On 12/10/2021 10:36 am, Alexander Motin wrote:
> > Hi Larry,
> >
> > This looks like some use-after-free or otherwise corrupted callout
> > structure. Unfortunately the backtrace does not tell what was the
> > callout. When was the previous update to look what could change?
> >
> > On 10.12.2021 11:24, Larry Rosenman wrote:
> >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
> >> main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
> >> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
> >> amd64
> >>
> >> VMCORE *IS* available.
> >>
> >>
> >>
> >>
> >> Unread portion of the kernel message buffer:
> >> kernel trap 12 with interrupts disabled
> >>
> >>
> >> Fatal trap 12: page fault while in kernel mode
> >> cpuid = 0; apic id = 20
> >> fault virtual address = 0x0
> >> fault code = supervisor write data, page not present
> >> instruction pointer = 0x20:0x804e0db4
> >> stack pointer = 0x0:0xfe0434de4e10
> >> frame pointer = 0x0:0xfe0434de4e70
> >> 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 = 82990 (c++)
> >> trap number = 12
> >> panic: page fault
> >> cpuid = 0
> >> time = 163998
> >> KDB: stack backtrace:
> >> #0 0x8050fc95 at kdb_backtrace+0x65
> >> #1 0x804c468f at vpanic+0x17f
> >> #2 0x804c4503 at panic+0x43
> >> #3 0x807a2195 at trap_fatal+0x385
> >> #4 0x807a21ef at trap_pfault+0x4f
> >> #5 0x80779c78 at calltrap+0x8
> >> #6 0x8045ddb8 at handleevents+0x188
> >> #7 0x8045ea3e at timercb+0x24e
> >> #8 0x807ca9eb at lapic_handle_timer+0x9b
> >> #9 0x8077b9b1 at Xtimerint+0xb1
> >> Uptime: 2h28m57s
> >> Dumping 12829 out of 131023
> >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> >>
> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> >> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
> >> (offsetof(struct pcpu,
> >> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> >> #1 doadump (textdump=)
> >> at /usr/src/sys/kern/kern_shutdown.c:399
> >> #2 0x804c428c in kern_reboot (howto=260)
> >> at /usr/src/sys/kern/kern_shutdown.c:487
> >> #3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
> >> ap=) at /usr/src/sys/kern/kern_shutdown.c:920
> >> #4 0x804c4503 in panic (fmt=)
> >> at /usr/src/sys/kern/kern_shutdown.c:844
> >> #5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
> >> at /usr/src/sys/amd64/amd64/trap.c:946
> >> #6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
> >> usermode=false, signo=, ucode=)
> >> at /usr/src/sys/amd64/amd64/trap.c:765
> >> #7
> >> #8 0x804e0db4 in callout_process
> >> (now=now@entry=38385536922300)
> >> at /usr/src/sys/kern/kern_timeout.c:488
> >> #9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
> >> fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
> >> #10 0x8045ea3e in timercb (et=0x80d475e0 ,
> >> arg=) at /usr/src/sys/kern/kern_clocksource.c:357
> >> #11 0x807ca9eb in lapic_handle_timer
> >> (frame=0xfe0434de4f40)
> >> at /usr/src/sys/x86/x86/local_apic.c:1364
> >> #12
> >> #13 0x00080df42bb6 in ?? ()
> >> Backtrace stopped: Cannot access memory at address 0x7def2c90
> >> (kgdb)
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
On 12/16/2021 9:03 pm, Larry Rosenman wrote:
On 12/10/2021 10:43 am, Larry Rosenman wrote:
14-2021_12_07-1217 - - 1.87G 2021-12-07
12:17
14-2021_12_09-1957 NR / 121G 2021-12-09
19:57
If that's any help
On 12/10/2021 10:36 am, Alexander Motin wrote:
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at
/usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50,
eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process
(now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents
(now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer
(frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
'
I got a new crash on a today's current:
❯ more core.txt.1
borg.lerctr.org dumped core - see /var/crash/vmcore.1
Thu Dec 16 17:01:37 CST 2021
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22
main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64
panic: page fault
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in ker
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
On 12/10/2021 10:43 am, Larry Rosenman wrote:
14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR / 121G 2021-12-09 19:57
If that's any help
On 12/10/2021 10:36 am, Alexander Motin wrote:
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50,
eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process
(now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer
(frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
'
I got a new crash on a today's current:
❯ more core.txt.1
borg.lerctr.org dumped core - see /var/crash/vmcore.1
Thu Dec 16 17:01:37 CST 2021
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22
main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64
panic: page fault
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual add
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR / 121G 2021-12-09 19:57
If that's any help
On 12/10/2021 10:36 am, Alexander Motin wrote:
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process
(now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer
(frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
> main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64
>
> VMCORE *IS* available.
>
>
>
>
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 20
> fault virtual address = 0x0
> fault code = supervisor write data, page not present
> instruction pointer = 0x20:0x804e0db4
> stack pointer = 0x0:0xfe0434de4e10
> frame pointer = 0x0:0xfe0434de4e70
> 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 = 82990 (c++)
> trap number = 12
> panic: page fault
> cpuid = 0
> time = 163998
> KDB: stack backtrace:
> #0 0x8050fc95 at kdb_backtrace+0x65
> #1 0x804c468f at vpanic+0x17f
> #2 0x804c4503 at panic+0x43
> #3 0x807a2195 at trap_fatal+0x385
> #4 0x807a21ef at trap_pfault+0x4f
> #5 0x80779c78 at calltrap+0x8
> #6 0x8045ddb8 at handleevents+0x188
> #7 0x8045ea3e at timercb+0x24e
> #8 0x807ca9eb at lapic_handle_timer+0x9b
> #9 0x8077b9b1 at Xtimerint+0xb1
> Uptime: 2h28m57s
> Dumping 12829 out of 131023
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
> (offsetof(struct pcpu,
> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=)
> at /usr/src/sys/kern/kern_shutdown.c:399
> #2 0x804c428c in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:487
> #3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
> ap=) at /usr/src/sys/kern/kern_shutdown.c:920
> #4 0x804c4503 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:844
> #5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
> at /usr/src/sys/amd64/amd64/trap.c:946
> #6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
> usermode=false, signo=, ucode=)
> at /usr/src/sys/amd64/amd64/trap.c:765
> #7
> #8 0x804e0db4 in callout_process (now=now@entry=38385536922300)
> at /usr/src/sys/kern/kern_timeout.c:488
> #9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
> fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
> #10 0x8045ea3e in timercb (et=0x80d475e0 ,
> arg=) at /usr/src/sys/kern/kern_clocksource.c:357
> #11 0x807ca9eb in lapic_handle_timer (frame=0xfe0434de4f40)
> at /usr/src/sys/x86/x86/local_apic.c:1364
> #12
> #13 0x00080df42bb6 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7def2c90
> (kgdb)
>
>
>
--
Alexander Motin
Panic: Page Fault in Kernel: Yesterday's CURRENT
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process (now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer (frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: "panic: page fault" in iwn signal handler(?) at r367127
On Fri, 2020-10-30 at 05:37 -0700, David Wolfskill wrote:
> I've copied the dump and core.txt files to
> http://www.catwhisker.org/~david/FreeBSD/head/r367127/
>
> Here's a copy/paste of the stack trace (from the core.txt.3 file):
> p 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address = 0xf8084000
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80495f03
> stack pointer = 0x0:0x8241d748
> frame pointer = 0x0:0x8241d7a0
> 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 = 12 (irq36: iwn0)
> trap number = 12
> panic: page fault
> cpuid = 4
> time = 1604056852
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x804a69db =
> db_trace_self_wrapper+0x2b/frame 0x8241d3f0
> vpanic() at 0x80baf802 = vpanic+0x182/frame
> 0x8241d440
> panic() at 0x80baf5c3 = panic+0x43/frame 0x8241d4a0
> trap_fatal() at 0x8102c2f7 = trap_fatal+0x387/frame
> 0x8241d500
> trap_pfault() at 0x8102c397 = trap_pfault+0x97/frame
> 0x8241d560
> trap() at 0x8102b98b = trap+0x2ab/frame 0x8241d670
> calltrap() at 0x80fffa08 = calltrap+0x8/frame
> 0x8241d670
> --- trap 0xc, rip = 0x80495f03, rsp = 0x8241d748, rbp
> = 0x8241d7a0 ---
> rijndaelEncrypt() at 0x80495f03 = rijndaelEncrypt+0x233/frame
> 0x8241d7a0
> ccmp_decap() at 0x80d08bc1 = ccmp_decap+0x421/frame
> 0x8241d8b0
> ieee80211_crypto_decap() at 0x80d07955 =
> ieee80211_crypto_decap+0x125/frame 0x8241d900
> sta_input() at 0x80d41dec = sta_input+0x43c/frame
> 0x8241d9a0
> iwn_notif_intr() at 0x8069949c = iwn_notif_intr+0x137c/frame
> 0x8241dab0
> iwn_intr() at 0x8068f4f8 = iwn_intr+0x2b8/frame
> 0x8241db20
> ithread_loop() at 0x80b6dbb9 = ithread_loop+0x279/frame
> 0x8241dbb0
> fork_exit() at 0x80b6a690 = fork_exit+0x80/frame
> 0x8241dbf0
> fork_trampoline() at 0x81000a5e = fork_trampoline+0xe/frame
> 0x8241dbf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
>
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
> #2 0x804a3cea in db_dump (dummy=,
> dummy2=, dummy3=,
> dummy4=)
> at /usr/src/sys/ddb/db_command.c:575
> #3 0x804a3ab0 in db_command (last_cmdp=,
> cmd_table=, dopager=1) at
> /usr/src/sys/ddb/db_command.c:482
> #4 0x804a380d in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:535
> #5 0x804a6b26 in db_trap (type=,
> code=)
> at /usr/src/sys/ddb/db_main.c:270
> #6 0x80bfb5c4 in kdb_trap (type=3, code=0, tf= out>)
> at /usr/src/sys/kern/subr_kdb.c:699
> #7 0x8102be9e in trap (frame=0x8241d320)
> at /usr/src/sys/amd64/amd64/trap.c:576
> #8
> #9 kdb_enter (why=0x8120d701 "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:486
> #10 0x80baf81e in vpanic (fmt=, ap= out>)
> at /usr/src/sys/kern/kern_shutdown.c:901
> #11 0x80baf5c3 in panic (
> fmt=0x81c79aa8
> "\362\357\034\201\377\377\377\377")
> at /usr/src/sys/kern/kern_shutdown.c:838
> #12 0x8102c2f7 in trap_fatal (frame=0x8241d680,
> eva=18446735313050009600) at /usr/src/sys/amd64/amd64/trap.c:915
> #13 0x8102c397 in trap_pfault (frame=0x8241d680,
> usermode=, signo=, ucode= out>)
> at /usr/src/sys/amd64/amd64/trap.c:732
> #14 0x8102b98b in trap (frame=0x8241d680)
> at /usr/src/sys/amd64/amd64/trap.c:398
> #15
> #16 rijndaelEncrypt (rk=, Nr=,
> pt=,
> ct=0x8241d830
> "\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\0
> 25c\266n\325\305\205]\251%\001\002\004\030\326!\"\037")
> at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:1000
> #17 0x80d08bc1 in ccmp_decrypt (key=0xfe106978a160,
> pn=25627,
> m=0xf8010ffc9b00, hdrlen=)
> at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623
> #18 ccmp_decap (k=, m=,
> hdrlen=)
> at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284
> #19 0x80d07955 in ieee8021
Re: "panic: page fault" in iwn signal handler(?) at r367127
On Fri, 2020-10-30 at 05:37 -0700, David Wolfskill wrote:
> I've copied the dump and core.txt files to
> http://www.catwhisker.org/~david/FreeBSD/head/r367127/
>
> Here's a copy/paste of the stack trace (from the core.txt.3 file):
> p 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address = 0xf8084000
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80495f03
> stack pointer = 0x0:0x8241d748
> frame pointer = 0x0:0x8241d7a0
> 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 = 12 (irq36: iwn0)
> trap number = 12
> panic: page fault
> cpuid = 4
> time = 1604056852
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x804a69db =
> db_trace_self_wrapper+0x2b/frame 0x8241d3f0
> vpanic() at 0x80baf802 = vpanic+0x182/frame
> 0x8241d440
> panic() at 0x80baf5c3 = panic+0x43/frame 0x8241d4a0
> trap_fatal() at 0x8102c2f7 = trap_fatal+0x387/frame
> 0x8241d500
> trap_pfault() at 0x8102c397 = trap_pfault+0x97/frame
> 0x8241d560
> trap() at 0x8102b98b = trap+0x2ab/frame 0x8241d670
> calltrap() at 0x80fffa08 = calltrap+0x8/frame
> 0x8241d670
> --- trap 0xc, rip = 0x80495f03, rsp = 0x8241d748, rbp
> = 0x8241d7a0 ---
> rijndaelEncrypt() at 0x80495f03 = rijndaelEncrypt+0x233/frame
> 0x8241d7a0
> ccmp_decap() at 0x80d08bc1 = ccmp_decap+0x421/frame
> 0x8241d8b0
> ieee80211_crypto_decap() at 0x80d07955 =
> ieee80211_crypto_decap+0x125/frame 0x8241d900
> sta_input() at 0x80d41dec = sta_input+0x43c/frame
> 0x8241d9a0
> iwn_notif_intr() at 0x8069949c = iwn_notif_intr+0x137c/frame
> 0x8241dab0
> iwn_intr() at 0x8068f4f8 = iwn_intr+0x2b8/frame
> 0x8241db20
> ithread_loop() at 0x80b6dbb9 = ithread_loop+0x279/frame
> 0x8241dbb0
> fork_exit() at 0x80b6a690 = fork_exit+0x80/frame
> 0x8241dbf0
> fork_trampoline() at 0x81000a5e = fork_trampoline+0xe/frame
> 0x8241dbf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
>
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
> #2 0x804a3cea in db_dump (dummy=,
> dummy2=, dummy3=,
> dummy4=)
> at /usr/src/sys/ddb/db_command.c:575
> #3 0x804a3ab0 in db_command (last_cmdp=,
> cmd_table=, dopager=1) at
> /usr/src/sys/ddb/db_command.c:482
> #4 0x804a380d in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:535
> #5 0x804a6b26 in db_trap (type=,
> code=)
> at /usr/src/sys/ddb/db_main.c:270
> #6 0x80bfb5c4 in kdb_trap (type=3, code=0, tf= out>)
> at /usr/src/sys/kern/subr_kdb.c:699
> #7 0x8102be9e in trap (frame=0x8241d320)
> at /usr/src/sys/amd64/amd64/trap.c:576
> #8
> #9 kdb_enter (why=0x8120d701 "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:486
> #10 0x80baf81e in vpanic (fmt=, ap= out>)
> at /usr/src/sys/kern/kern_shutdown.c:901
> #11 0x80baf5c3 in panic (
> fmt=0x81c79aa8
> "\362\357\034\201\377\377\377\377")
> at /usr/src/sys/kern/kern_shutdown.c:838
> #12 0x8102c2f7 in trap_fatal (frame=0x8241d680,
> eva=18446735313050009600) at /usr/src/sys/amd64/amd64/trap.c:915
> #13 0x8102c397 in trap_pfault (frame=0x8241d680,
> usermode=, signo=, ucode= out>)
> at /usr/src/sys/amd64/amd64/trap.c:732
> #14 0x8102b98b in trap (frame=0x8241d680)
> at /usr/src/sys/amd64/amd64/trap.c:398
> #15
> #16 rijndaelEncrypt (rk=, Nr=,
> pt=,
> ct=0x8241d830
> "\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\0
> 25c\266n\325\305\205]\251%\001\002\004\030\326!\"\037")
> at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:1000
> #17 0x80d08bc1 in ccmp_decrypt (key=0xfe106978a160,
> pn=25627,
> m=0xf8010ffc9b00, hdrlen=)
> at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623
> #18 ccmp_decap (k=, m=,
> hdrlen=)
> at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284
> #19 0x80d07955 in ieee8021
"panic: page fault" in iwn signal handler(?) at r367127
I've copied the dump and core.txt files to
http://www.catwhisker.org/~david/FreeBSD/head/r367127/
Here's a copy/paste of the stack trace (from the core.txt.3 file):
p 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0xf8084000
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80495f03
stack pointer = 0x0:0x8241d748
frame pointer = 0x0:0x8241d7a0
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 = 12 (irq36: iwn0)
trap number = 12
panic: page fault
cpuid = 4
time = 1604056852
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804a69db =
db_trace_self_wrapper+0x2b/frame 0x8241d3f0
vpanic() at 0x80baf802 = vpanic+0x182/frame 0x8241d440
panic() at 0x80baf5c3 = panic+0x43/frame 0x8241d4a0
trap_fatal() at 0x8102c2f7 = trap_fatal+0x387/frame 0x8241d500
trap_pfault() at 0x8102c397 = trap_pfault+0x97/frame 0x8241d560
trap() at 0x8102b98b = trap+0x2ab/frame 0x8241d670
calltrap() at 0x80fffa08 = calltrap+0x8/frame 0x8241d670
--- trap 0xc, rip = 0x80495f03, rsp = 0x8241d748, rbp =
0x8241d7a0 ---
rijndaelEncrypt() at 0x80495f03 = rijndaelEncrypt+0x233/frame
0x8241d7a0
ccmp_decap() at 0x80d08bc1 = ccmp_decap+0x421/frame 0x8241d8b0
ieee80211_crypto_decap() at 0x80d07955 =
ieee80211_crypto_decap+0x125/frame 0x8241d900
sta_input() at 0x80d41dec = sta_input+0x43c/frame 0x8241d9a0
iwn_notif_intr() at 0x8069949c = iwn_notif_intr+0x137c/frame
0x8241dab0
iwn_intr() at 0x8068f4f8 = iwn_intr+0x2b8/frame 0x8241db20
ithread_loop() at 0x80b6dbb9 = ithread_loop+0x279/frame
0x8241dbb0
fork_exit() at 0x80b6a690 = fork_exit+0x80/frame 0x8241dbf0
fork_trampoline() at 0x81000a5e = fork_trampoline+0xe/frame
0x8241dbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2 0x804a3cea in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3 0x804a3ab0 in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4 0x804a380d in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5 0x804a6b26 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:270
#6 0x80bfb5c4 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:699
#7 0x8102be9e in trap (frame=0x8241d320)
at /usr/src/sys/amd64/amd64/trap.c:576
#8
#9 kdb_enter (why=0x8120d701 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80baf81e in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:901
#11 0x80baf5c3 in panic (
fmt=0x81c79aa8 "\362\357\034\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:838
#12 0x8102c2f7 in trap_fatal (frame=0x8241d680,
eva=18446735313050009600) at /usr/src/sys/amd64/amd64/trap.c:915
#13 0x8102c397 in trap_pfault (frame=0x8241d680,
usermode=, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:732
#14 0x8102b98b in trap (frame=0x8241d680)
at /usr/src/sys/amd64/amd64/trap.c:398
#15
#16 rijndaelEncrypt (rk=, Nr=,
pt=,
ct=0x8241d830
"\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\025c\266n\325\305\205]\251%\001\002\004\030\326!\"\037")
at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:1000
#17 0x80d08bc1 in ccmp_decrypt (key=0xfe106978a160, pn=25627,
m=0xf8010ffc9b00, hdrlen=)
at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623
#18 ccmp_decap (k=, m=, hdrlen=)
at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284
#19 0x80d07955 in ieee80211_crypto_decap (ni=,
m=0xf8010ffc9b00, hdrlen=26, key=0x8241d920)
at /usr/src/sys/net80211/ieee80211_crypto.c:684
#20 0x80d41dec in sta_input (ni=,
m=0xf8010ffc9b00, rxs=, rssi=,
nf=) at /usr/src/sys/net80211/ieee80211_sta.c:773
#21 0x8069949c in iwn_rx_done (sc=0xfe1033319000,
desc=, data=)
at /usr/src/sys/dev/iwn/if_iwn.c:3191
#22 iwn_notif_intr (sc=) at /usr/src/sys/dev/iwn/if_iwn.c:4018
#23 0x8068f4f8 in iwn_intr (arg=0xfe1033319000)
at /usr/src/sys/dev/iwn/if_iwn.c:4337
#24 0x80b6dbb9 in intr_event_execute_handle
Re: panic: page fault head/amd64 @r361830
On Fri, Jun 05, 2020 at 06:41:27AM -0700, David Wolfskill wrote: > My build machine had no issues with the upgrade from r361784 to r361830, > but my laptop panicked during the transition from single- to multi-user > mode, just after bpf was attached. > . Thanks to Hans Petter Selasky (who asked a follow-up question about any kernel modules that may have not been rebuilt) and Adrian Chadd (who identified a bug and committed r361834 to fix it). I hand-applied the r361834 fix, rebuilt (& installed) the kernel; reboot was successful. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org "... we distance ourselves from the incendiary language of this President." -- Bishop Mariann Edgar Budde of the Episcopal Diocese of Washington See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: panic: page fault head/amd64 @r361830
On 2020-06-05 15:41, David Wolfskill wrote:
My build machine had no issues with the upgrade from r361784 to r361830,
but my laptop panicked during the transition from single- to multi-user
mode, just after bpf was attached.
Rebooting from the old kernel worked; trying to boot from r361830
failed again with similar symptoms, and the laptop normally runs
stable/12 (r361761 yesterday; r361831 today), so it seems to be an
issue in head.
The build machine isn't a DHCP client, and doesn't run ipfw; the laptop
differs (in both respects).
The backtrace (from the core.txt file:
...
<118>Mounting local filesystems:
linprocfs registered
<118>.
<118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
/usr/local/lib/R/lib /usr/local/lib/compat /usr/local/lib/gcc9 /usr/l
ocal/lib/graphviz /usr/local/lib/mysql /usr/local/lib/perl5/5.30/mach/CORE
/usr/local/lib/qt5 /usr/local/llvm80/lib /usr/local/llvm90/lib
/usr/local/share/chromium
<118>32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat
/usr/local/lib32/compat
<118>Setting hostname: localhost.
<118>Setting up harvesting:
PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
<118>Feeding entropy: .
<6>wlan0: bpf attached
<6>wlan0: bpf attached
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x0
fault code = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer = 0x28:0xfe0fc08c3b08
frame pointer = 0x28:0xfe0fc08c3b80
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 = 0 (iwn0 net80211 taskq)
trap number = 12
panic: page fault
cpuid = 3
time = 1591362374
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804a4afb =
db_trace_self_wrapper+0x2b/frame 0xfe0fc08c37b0
vpanic() at 0x80b93452 = vpanic+0x182/frame 0xfe0fc08c3800
panic() at 0x80b93203 = panic+0x43/frame 0xfe0fc08c3860
trap_fatal() at 0x81069b07 = trap_fatal+0x387/frame 0xfe0fc08c38c0
trap_pfault() at 0x81069ba9 = trap_pfault+0x99/frame 0xfe0fc08c3920
trap() at 0x810691a5 = trap+0x2a5/frame 0xfe0fc08c3a30
calltrap() at 0x8103edb8 = calltrap+0x8/frame 0xfe0fc08c3a30
--- trap 0xc, rip = 0, rsp = 0xfe0fc08c3b08, rbp = 0xfe0fc08c3b80 ---
??() at 0/frame 0xfe0fc08c3b80
taskqueue_thread_loop() at 0x80bf3214 =
taskqueue_thread_loop+0x94/frame 0xfe0fc08c3bb0
fork_exit() at 0x80b503c0 = fork_exit+0x80/frame 0xfe0fc08c3bf0
fork_trampoline() at 0x8103fdfe = fork_trampoline+0xe/frame
0xfe0fc08c3bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2 0x804a1eaa in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3 0x804a1c6c in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4 0x804a19dd in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5 0x804a4c48 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:253
#6 0x80bdde34 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:699
#7 0x810696b8 in trap (frame=0xfe0fc08c36e0)
at /usr/src/sys/amd64/amd64/trap.c:578
#8
#9 kdb_enter (why=0x8122ff12 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80b93203 in panic (
fmt=0x81c7f298 "\326/\037\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:839
#2 0x804a1eaa in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3 0x804a1c6c in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4 0x804a19dd in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5 0x804a4c48 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:253
#6 0x80bdde34 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:699
#7 0x810696b8 in trap (frame=0xfe0fc08c36e0)
at /usr/src/sys/amd64/amd64/trap.c:578
#8
#9 kdb_enter (why=0x8122ff12 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
at /usr/
panic: page fault head/amd64 @r361830
My build machine had no issues with the upgrade from r361784 to r361830,
but my laptop panicked during the transition from single- to multi-user
mode, just after bpf was attached.
Rebooting from the old kernel worked; trying to boot from r361830
failed again with similar symptoms, and the laptop normally runs
stable/12 (r361761 yesterday; r361831 today), so it seems to be an
issue in head.
The build machine isn't a DHCP client, and doesn't run ipfw; the laptop
differs (in both respects).
The backtrace (from the core.txt file:
...
<118>Mounting local filesystems:
linprocfs registered
<118>.
<118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
/usr/local/lib/R/lib /usr/local/lib/compat /usr/local/lib/gcc9 /usr/l
ocal/lib/graphviz /usr/local/lib/mysql /usr/local/lib/perl5/5.30/mach/CORE
/usr/local/lib/qt5 /usr/local/llvm80/lib /usr/local/llvm90/lib
/usr/local/share/chromium
<118>32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat
/usr/local/lib32/compat
<118>Setting hostname: localhost.
<118>Setting up harvesting:
PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
<118>Feeding entropy: .
<6>wlan0: bpf attached
<6>wlan0: bpf attached
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x0
fault code = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer = 0x28:0xfe0fc08c3b08
frame pointer = 0x28:0xfe0fc08c3b80
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 = 0 (iwn0 net80211 taskq)
trap number = 12
panic: page fault
cpuid = 3
time = 1591362374
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804a4afb =
db_trace_self_wrapper+0x2b/frame 0xfe0fc08c37b0
vpanic() at 0x80b93452 = vpanic+0x182/frame 0xfe0fc08c3800
panic() at 0x80b93203 = panic+0x43/frame 0xfe0fc08c3860
trap_fatal() at 0x81069b07 = trap_fatal+0x387/frame 0xfe0fc08c38c0
trap_pfault() at 0x81069ba9 = trap_pfault+0x99/frame 0xfe0fc08c3920
trap() at 0x810691a5 = trap+0x2a5/frame 0xfe0fc08c3a30
calltrap() at 0x8103edb8 = calltrap+0x8/frame 0xfe0fc08c3a30
--- trap 0xc, rip = 0, rsp = 0xfe0fc08c3b08, rbp = 0xfe0fc08c3b80 ---
??() at 0/frame 0xfe0fc08c3b80
taskqueue_thread_loop() at 0x80bf3214 =
taskqueue_thread_loop+0x94/frame 0xfe0fc08c3bb0
fork_exit() at 0x80b503c0 = fork_exit+0x80/frame 0xfe0fc08c3bf0
fork_trampoline() at 0x8103fdfe = fork_trampoline+0xe/frame
0xfe0fc08c3bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2 0x804a1eaa in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3 0x804a1c6c in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4 0x804a19dd in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5 0x804a4c48 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:253
#6 0x80bdde34 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:699
#7 0x810696b8 in trap (frame=0xfe0fc08c36e0)
at /usr/src/sys/amd64/amd64/trap.c:578
#8
#9 kdb_enter (why=0x8122ff12 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80b93203 in panic (
fmt=0x81c7f298 "\326/\037\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:839
#2 0x804a1eaa in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3 0x804a1c6c in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4 0x804a19dd in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5 0x804a4c48 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:253
#6 0x80bdde34 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:699
#7 0x810696b8 in trap (frame=0xfe0fc08c36e0)
at /usr/src/sys/amd64/amd64/trap.c:578
#8
#9 kdb_enter (why=0x8122ff12 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80b93203 in pan
panic: page fault (on 10.0-RELEASE-p7)
Info at http://slexy.org/raw/s21qACK3qQ. On the 1st boot after the panic, the crash dump failed due to insufficient amount of space on /. Then I removed some files, restarted the system, and the dump was redone. Is it correct to assume that the dump was not damaged? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: page fault
On Friday, December 21, 2012 05:47:26 AM Ivan Klymenko wrote: В Tue, 14 Aug 2012 14:04:07 -0400 John Baldwin j...@freebsd.org пишет: On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: http://privatepaste.com/147286442b It is easier to reply if the messages are inline (for future reference). The panic and relevant bit of backtrace are below. Sadly, trying to cut and paste this destroyed the formatting, so I've tried to fix it by hand. :( Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80933e07 stack pointer = 0x28:0xff823025b660 frame pointer = 0x28:0xff823025b6c0 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 = 12 (irq256: bce0) trap number = 12 panic: page fault #6 0x80bb5e53 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80933e07 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0x809f8b76 in ip_fragment (ip=0xfe004b2f3980, m_frag=0xff823025b7c8, mtu=Variable mtu is not available. ) at /usr/src/sys/netinet/ip_output.c:822 #9 0x809f948a in ip_output (m=0xfe004b2f3900, opt=Variable opt is not available. ) at /usr/src/sys/netinet/ip_output.c:654 #10 0x809f59fa in ip_forward (m=0xfe004b2f3900, srcrt=Variable srcrt is not available. ) at /usr/src/sys/netinet/ip_input.c:1494 #11 0x809f6dc6 in ip_input (m=0xfe004b2f3900) at /usr/src/sys/netinet/ip_input.c:702 I apologize for not having answered - no more required files... At that time it was not possible to fulfill your request ... Now I have gained a number of similar panic's and i ready to provide the results. Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p m0', and 'p *m0'? kgdb.log in attach Looks like this attachment was lost unfortunately. Can you reply with the output inline (and include the output from the other kgdb commands below)? Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? What kind of shell should I use for this? Ah, those are meant to be run while you are in kgdb. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: page fault
On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: http://privatepaste.com/147286442b It is easier to reply if the messages are inline (for future reference). The panic and relevant bit of backtrace are below. Sadly, trying to cut and paste this destroyed the formatting, so I've tried to fix it by hand. :( Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80933e07 stack pointer = 0x28:0xff823025b660 frame pointer = 0x28:0xff823025b6c0 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 = 12 (irq256: bce0) trap number = 12 panic: page fault #6 0x80bb5e53 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80933e07 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0x809f8b76 in ip_fragment (ip=0xfe004b2f3980, m_frag=0xff823025b7c8, mtu=Variable mtu is not available. ) at /usr/src/sys/netinet/ip_output.c:822 #9 0x809f948a in ip_output (m=0xfe004b2f3900, opt=Variable opt is not available. ) at /usr/src/sys/netinet/ip_output.c:654 #10 0x809f59fa in ip_forward (m=0xfe004b2f3900, srcrt=Variable srcrt is not available. ) at /usr/src/sys/netinet/ip_input.c:1494 #11 0x809f6dc6 in ip_input (m=0xfe004b2f3900) at /usr/src/sys/netinet/ip_input.c:702 Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p m0', and 'p *m0'? Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: page fault
http://privatepaste.com/147286442b ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PANIC: PAGE FAULT
On Wed, 3 Dec 2003, Ganbaa wrote: I'm trying to install FreeBSD-5.1 on the PC with PIII,512MB SDRAM, 30GB Barracuda II Model ST330630A. But following error has occured. We're in the throes of preparing FreeBSD 5.2 for release, which includes a large number of bug fixes (although potentially a fair number of bugs, as we're still in the beta). I think it might make sense to try grabbing the 5.2-ISO from the FTP site and see if you can install that. If you run into the same bug, it includes a kernel.debug and debugging information we can use to debug the problem. If you run into a different bug, we can work to fix that, or better yet, it might just work :-). Regardless of whether you stick with 5.2 during the test cycle, the results would be very helpful to make sure 5.2 will work on your hardware even if 5.1 doesn't. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code= supervisor read, page not present instruction pointer = 0x8:0xc035eb26 stack pointer = 0x10:0xdba72bb8 frame pointer = 0x10:0xdba72c2c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (sh) trap number = 12 panic: page fault syncing disks, buffers remaining... 184 184 184 184 184 184 184 184 184 184 184 184 184 184 giving up on 148 buffers Uptime: 16s Terminate ACPI PLEASE HELP ME!!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PANIC: PAGE FAULT
Hi all, I'm trying to install FreeBSD-5.1 on the PC with PIII,512MB SDRAM, 30GB Barracuda II Model ST330630A. But following error has occured. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc035eb26 stack pointer = 0x10:0xdba72bb8 frame pointer = 0x10:0xdba72c2c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 80 (sh) trap number = 12 panic: page fault syncing disks, buffers remaining... 184 184 184 184 184 184 184 184 184 184 184 184 184 184 giving up on 148 buffers Uptime: 16s Terminate ACPI PLEASE HELP ME!!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
On 1 Dec, Stefan Ehmann wrote:
On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
Can you reproduce this problem without bktr?
snip
You are getting a double panic, with the second happening during the
file system sync. The code seems to be be tripping over the same mount
list entry each time. Maybe the mount list is getting corrupted. Are
you using amd? Print *lkp in the lockmgr() stack frame.
You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.
No, I'm not using amd.
(kgdb) print *lkp
$1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
= 0,
lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0,
lk_lockholder = 0x0, lk_newlock = 0x0}
This is indeed just NULLs.
I haven't tried without bktr yet but I hope I'll have time for that (and
the KASSERT) tomorrow.
The panic only seems to happen when accessing my read-only mounted ext2
partition. Today I tried not to access any data there and uptime is
14h30min now. The panic always happened after a few hours. So this is
probably the core of the problem.
What about ther file system types, like nullfs, unionfs, cd9660? I
created an ext2 partition, filled it with data, and mounted it
read-only. So far I am unable to reproduce this problem.
I'm also running with the DEBUG_VFS_LOCKS and the following patch in an
attempt to catch the bug closer to its origin. Be forwarned that
DEBUG_VFS_LOCKS sometimes gets triggered by procfs and linprocfs, but
you can just continue in DDB.
Index: sys/kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.472
diff -u -r1.472 vfs_subr.c
--- sys/kern/vfs_subr.c 9 Nov 2003 09:17:24 - 1.472
+++ sys/kern/vfs_subr.c 1 Dec 2003 13:34:23 -
@@ -282,6 +282,9 @@
void
assert_vop_locked(struct vnode *vp, const char *str)
{
+ if (vp vp-v_mount)
+ KASSERT(vp-v_mount-mnt_lock.lk_interlock != NULL,
+ (assert_vop_locked: vnode mount entry interlock is null));
if (vp !IGNORE_LOCK(vp) !VOP_ISLOCKED(vp, NULL))
vfs_badlock(is not locked but should be, str, vp);
}
@@ -289,6 +292,9 @@
void
assert_vop_unlocked(struct vnode *vp, const char *str)
{
+ if (vp vp-v_mount)
+ KASSERT(vp-v_mount-mnt_lock.lk_interlock != NULL,
+ (assert_vop_unlocked: vnode mount entry interlock is null));
if (vp !IGNORE_LOCK(vp)
VOP_ISLOCKED(vp, curthread) == LK_EXCLUSIVE)
vfs_badlock(is locked but should not be, str, vp);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA panic: page fault
This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)
Here's one from today:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer = 0x10:0xd7f2ea88
frame pointer = 0x10:0xd7f2eaa4
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 = 1253 (esd)
trap number = 12
panic: page fault
syncing disks, buffers remaining...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0505b53
stack pointer = 0x10:0xd7f2e89c
frame pointer = 0x10:0xd7f2e8b8
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 = 1253 (esd)
trap number = 12
panic: page fault
Uptime: 1h19m23s
Dumping 383 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0681d63 in trap (frame=
{tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06743d8 in calltrap () at {standard input}:94
#7 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#8 0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#9 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#10 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#11 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#12 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#13 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#14 0xc0681d63 in trap (frame=
{tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip
Re: 5.2-BETA panic: page fault
On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)
Here's one from today:
As per request I made a (hopefully more useful) backtrace with a patched
gdb version:
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f5a2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc068248c in trap_fatal (frame=0xd7f2e85c, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc0682152 in trap_pfault (frame=0xd7f2e85c, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0681d63 in trap (frame=
{tf_fs = -1066729448, tf_es = 16, tf_ds = -1066205168, tf_edi =
-104931, tf_esi = 228, tf_ebp = -671946568, tf_isp = -671946616,
tf_ebx = 0, tf_edx = 16842753, tf_ecx = -1011687424, tf_eax =
-1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = -671946560, tf_ss = -1068475264}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06743d8 in calltrap () at {standard input}:94
#7 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#8 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#9 0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:132
#11 0xc050f0f6 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#15 0xc0681d63 in trap (frame=
{tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
/usr/src/sys/i386/i386/trap.c:420
#16 0xc06743d8 in calltrap () at {standard input}:94
#17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#20 0xc056374c in lookup (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:559
#21 0xc0562fde in namei (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:183
#22 0xc05726ef in kern_mkdir (td=0xc3b34780, path=)
at /usr/src/sys/kern/vfs_syscalls.c:3230
#23 0xc0572699 in mkdir (td=0x0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:3214
#24 0xc06827c0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134546513, tf_esi =
-1077941929, tf_ebp = -1077944248, tf_isp = -671945356, tf_ebx = 0,
tf_edx = 134543200, tf_ecx = 134578233, tf_eax = 136, tf_trapno = 12,
tf_err = 2, tf_eip = 672183855, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077944500, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#25 0xc067442d in Xint0x80_syscall () at {standard input}:136
#26 0x2810b62f in ?? ()
(kgdb)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
On 30 Nov, Stefan Ehmann wrote:
On Sun, 2003-11-30 at 11:13, Stefan Ehmann wrote:
This happens to me several times a day (cvsup from yesterday didn't
change anything). The panic message is always the same, the backtrace is
different though (but always seems to be file system related in some
way)
Here's one from today:
As per request I made a (hopefully more useful) backtrace with a patched
gdb version:
(kgdb) bt
#12 0xc050f8f8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#13 0xc068248c in trap_fatal (frame=0xd7f2ea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#14 0xc0682152 in trap_pfault (frame=0xd7f2ea48, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#15 0xc0681d63 in trap (frame=
{tf_fs = -672006120, tf_es = -672006128, tf_ds = -1068105712,
tf_edi = -104931, tf_esi = 228, tf_ebp = -671946076, tf_isp =
-671946124, tf_ebx = 0, tf_edx = 16777217, tf_ecx = -1011687424, tf_eax
= -1011660928, tf_trapno = 12, tf_err = 0, tf_eip = -1068475565, tf_cs =
8, tf_eflags = 66178, tf_esp = 2, tf_ss = -1011660928}) at
/usr/src/sys/i386/i386/trap.c:420
#16 0xc06743d8 in calltrap () at {standard input}:94
#17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#20 0xc056374c in lookup (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:559
It seems pretty clear that the panic is caused by passing a null pointer
to mtx_lock(). That is pretty clear from the eva=0 argument to
trap_pfault() and the m=0x0 argument to _mtx_lock_flags(). If you have
INVARIANTS defined, the first thing that _mtx_lock_flags() does is to
dereference m-mtx_object, which is at beginning of struct mtx.
There appears to be some stack spammage happening, and it is pretty much
consistent between this stack trace and the previous one displayed by
the unpatched version of gdb. Notice how all the arguments to
vfs_busy() are NULL/0, but td and interlkp are passed directly to
lockmgr(), which has a non-NULL td and interlkp arguments, though the
interlkp argument looks seriously bogus. Looking at the lockmgr() call
in vfs_busy(), I don't see how the flags argument to lockmgr() could be
0. If the mp argument to vfs_busy() were really NULL, vfs_busy() would
have paniced before calling lockmgr().
I wonder if an interrupt handler is stomping on the stack ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
Can you reproduce this problem without bktr?
#6 0xc06743d8 in calltrap () at {standard input}:94
#7 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#8 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#9 0xc0566d87 in vfs_busy (mp=0x0, flags=16, interlkp=0xc075d0e0,
td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#10 0xc056cfff in sync (td=0xc0730dc0, uap=0x0)
#16 0xc06743d8 in calltrap () at {standard input}:94
#17 0xc0505b53 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc06bfc1d /usr/src/sys/kern/kern_lock.c, line=228)
at /usr/src/sys/kern/kern_mutex.c:214
#18 0xc0502b54 in lockmgr (lkp=0xc3b2e028, flags=0, interlkp=0xe4,
td=0xc06bfc1d) at /usr/src/sys/kern/kern_lock.c:228
#19 0xc0566d87 in vfs_busy (mp=0x0, flags=0, interlkp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:527
#20 0xc056374c in lookup (ndp=0xd7f2ec00) at
/usr/src/sys/kern/vfs_lookup.c:559
You are getting a double panic, with the second happening during the
file system sync. The code seems to be be tripping over the same mount
list entry each time. Maybe the mount list is getting corrupted. Are
you using amd? Print *lkp in the lockmgr() stack frame.
You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
Can you reproduce this problem without bktr?
snip
You are getting a double panic, with the second happening during the
file system sync. The code seems to be be tripping over the same mount
list entry each time. Maybe the mount list is getting corrupted. Are
you using amd? Print *lkp in the lockmgr() stack frame.
You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.
No, I'm not using amd.
(kgdb) print *lkp
$1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
= 0,
lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0,
lk_lockholder = 0x0, lk_newlock = 0x0}
This is indeed just NULLs.
I haven't tried without bktr yet but I hope I'll have time for that (and
the KASSERT) tomorrow.
The panic only seems to happen when accessing my read-only mounted ext2
partition. Today I tried not to access any data there and uptime is
14h30min now. The panic always happened after a few hours. So this is
probably the core of the problem.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA panic: page fault
On 1 Dec, Stefan Ehmann wrote:
On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
Can you reproduce this problem without bktr?
snip
You are getting a double panic, with the second happening during the
file system sync. The code seems to be be tripping over the same mount
list entry each time. Maybe the mount list is getting corrupted. Are
you using amd? Print *lkp in the lockmgr() stack frame.
You might want to add
KASSERT(mp-mnt_lock.lk_interlock !=NULL, vfs_busy: NULL mount
pointer interlock);
at the top of vfs_busy() and right before the lockmgr() call.
No, I'm not using amd.
(kgdb) print *lkp
$1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
= 0,
lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0,
lk_lockholder = 0x0, lk_newlock = 0x0}
This is indeed just NULLs.
Not good. Nothing should be writing to lk_interlock once it has been
initialized. Either something is stomping on an active struct mount,
we're still using it after it has been put on the free list, or
dp-v_mountedhere is pointing somewhere bogus. I don't suspect the
latter because the second panic() in the sync() code doesn't follow this
path to get to the struct mount.
I haven't tried without bktr yet but I hope I'll have time for that (and
the KASSERT) tomorrow.
The panic only seems to happen when accessing my read-only mounted ext2
partition. Today I tried not to access any data there and uptime is
14h30min now. The panic always happened after a few hours. So this is
probably the core of the problem.
That sounds like a possibility. I might be able to try that here when I
have some idle time on my -CURRENT box.
Can you print *dp-v_mountedhere in the lookup() frame? That should
show the mount point information and might show if anything else in
struct mount is damaged.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: page fault (using ppp ipv6cp)
Hello,
I upgraded my machine to CURRENT of today. It was paniced at while the
ppp process was making the IPv6 tunnel. When I rebooted it several
times, the problem occurred in the same place (currnet process = ppp).
Now I'm using an older kernel(cvsuped October 2). This older kernel
works fine.
My setting of ppp is as follows.
## ppp.conf
default:
set log Phase Chat LCP IPCP CCP tun command
set server /tmp/pppctl 0177
allow users yoshi
tun6:
set escape 0xff
set device xxx.xxx.xxx.xxx:6669
set dial
set timeout 0 0
set authname tun
set authkey
enable ipv6cp
disable ipcp
## rc.conf
ppp_enable=YES
ppp_profile=tun6
ppp_mode=ddial
ipv6_enable=YES
ipv6_network_interfaces=em0
ipv6_gateway_enable=YES
ipv6_static_routes=default
ipv6_route_default=default -interface tun0
ipv6_prefix_em0=2001:268:304:9b00
panic message and backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x1
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc058331c
stack pointer = 0x10:0xe5638a24
frame pointer = 0x10:0xe5638a90
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 = 271 (ppp)
panic: from debugger
cpuid = 0; lapic.id =
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0501d46 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0502198 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0444232 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0444192 in db_command (last_cmdp=0xc06fede0, cmd_table=0x0,
aux_cmd_tablep=0xc06cfc8c, aux_cmd_tablep_end=0xc06cfc90)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc04442d5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc04472f5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc0662ccc in kdb_trap (type=12, code=0, regs=0xe56389e4)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc067cd16 in trap_fatal (frame=0xe56389e4, eva=0)
at /usr/src/sys/i386/i386/trap.c:815
#9 0xc067c9b2 in trap_pfault (frame=0xe56389e4, usermode=0, eva=1)
at /usr/src/sys/i386/i386/trap.c:734
#10 0xc067c50d in trap (frame=
{tf_fs = -969277416, tf_es = -964100080, tf_ds = -446496752, tf_edi = 0, tf_esi
= 56, tf_ebp = -446461296, tf_isp = -446461424, tf_ebx = -969272576, tf_edx = 0,
tf_ecx = -968655616, tf_eax = -968655616, tf_trapno = 12, tf_err = 0, tf_eip =
-1067961572, tf_cs = 8, tf_eflags = 66182, tf_esp = -967892080, tf_ss = -446461340})
at /usr/src/sys/i386/i386/trap.c:419
#11 0xc06646c8 in calltrap () at {standard input}:103
#12 0xc0584bd5 in rt_setgate (rt=0xc6437d00, dst=0xc6307a80, gate=0x0)
at /usr/src/sys/net/route.c:997
#13 0xc0585fef in route_output (m=0xc239d800, so=0xc66b8b00)
at /usr/src/sys/net/rtsock.c:451
#14 0xc0583073 in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc64f2390) at /usr/src/sys/net/raw_usrreq.c:257
#15 0xc0585865 in rts_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0x0) at /usr/src/sys/net/rtsock.c:241
#16 0xc0541b8d in sosend (so=0xc66b8b00, addr=0x0, uio=0xe5638c6c,
top=0xc239d800, control=0x0, flags=0, td=0xc64f2390)
at /usr/src/sys/kern/uipc_socket.c:714
#17 0xc0530b97 in soo_write (fp=0x0, uio=0xe5638c6c, active_cred=0xc688e980,
flags=0, td=0xc64f2390) at /usr/src/sys/kern/sys_socket.c:115
#18 0xc052a5c8 in dofilewrite (td=0xc64f2390, fp=0xc66a9154, fd=0,
buf=0xbfbfec80, nbyte=0, offset=0, flags=0) at /usr/src/sys/sys/file.h:249
#19 0xc052a3fe in write (td=0xc64f2390, uap=0xe5638d10)
at /usr/src/sys/kern/sys_generic.c:330
#20 0xc067d100 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = 2, tf_ebp =
-1077941144, tf_isp = -446460556, tf_ebx = 176, tf_edx = -1077941120,---Type return
to continue, or q return to quit---
_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 673729887, tf_cs = 31, tf_eflags = 531,
tf_esp = -1077941188, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1009
#21 0xc066471d in Xint0x80_syscall () at {standard input}:145
---
Yoshihide Sonoda
E-mail: [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
IPv6 panic page fault nd6_cache_lladdr/nd6_ns_input
Hello,
After upgrading a system to -CURRENT of yesterday night, making IPv6
connections to another host in the same subnet does not work (remains in
[connec] state). Some messing about with routes solved that, but it
panicked quickly thereafter. After a reboot it panicked again with a
similar panic. I'm running an older kernel now.
The machine is a dual Athlon MP 2000+, 1GB RAM.
Relevant lines from /etc/rc.conf:
ipv6_enable=YES
ipv6_ifconfig_xl1='2001:610:1108:5012::2 prefixlen 64'
ipv6_network_interfaces=auto
ipv6_static_routes=nfsrtfix
ipv6_route_nfsrtfix=2001:610:1108:5012::/64 -iface xl1
ipv6_firewall_enable=YES
ipv6_firewall_type=/etc/ip6fw.rules
The IPv6 firewall rules are very simple (no stateful stuff in there).
Also we do in /etc/rc.local:
sysctl net.inet6.ip6.accept_rtadv=1
rtsol xl0
Results from gdb (first panic, second is very similar, except that it
has softupdate trouble after getting the initial page fault):
Script started on Mon Oct 6 15:21:34 2003
# gdb -k kernel.debug.9 vmcore.9
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0xac
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0599601
stack pointer = 0x10:0xe0084a8c
frame pointer = 0x10:0xe0084ad8
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 = 15 (swi1: net)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks, buffers remaining... 2384 2384 2384 2384 2384 2384 2384 2384 2384 2384
2384 2384 2384 2384 2384 2384 2384 2384 2384 2384
giving up on 809 buffers
Uptime: 11m17s
Dumping 1023 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 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/fdescfs/fdescfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/fdescfs/fdescfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04d6ff1 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04d7448 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0655cd6 in trap_fatal (frame=0xe0084a4c, eva=0)
at /usr/src/sys/i386/i386/trap.c:819
#4 0xc0655952 in trap_pfault (frame=0xe0084a4c, usermode=0, eva=172)
at /usr/src/sys/i386/i386/trap.c:733
#5 0xc06554ad in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -536327200, tf_ebp =
-536327464, tf_isp = -536327560, tf_ebx = 0, tf_edx = -1034105584, tf_ecx = 4, tf_eax
= -1034105584, tf_trapno = 12, tf_err = 2, tf_eip = -1067870719, tf_cs = 8, tf_eflags
= 66050, tf_esp = -950171904, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:418
#6 0xc063d678 in calltrap () at {standard input}:103
#7 0xc059a774 in nd6_cache_lladdr (ifp=0xc6544000, from=0x0,
lladdr=0xc3275852 , lladdrlen=8, type=135, code=0)
at /usr/src/sys/netinet6/nd6.c:1654
#8 0xc059ba3d in nd6_ns_input (m=0xc25ef100, off=40, icmp6len=-965550080)
at /usr/src/sys/netinet6/nd6_nbr.c:306
#9 0xc058072b in icmp6_input (mp=0x0, offp=0xe0084c68, proto=58)
at /usr/src/sys/netinet6/icmp6.c:790
#10 0xc0591e1b in ip6_input (m=0xc25eef00)
at /usr/src/sys/netinet6/ip6_input.c:825
#11 0xc0554b59 in netisr_processqueue (ni=0xc06e7538)
---Type return to continue, or q return to quit---
at /usr/src/sys/net/netisr.c:140
#12 0xc0555048 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:246
#13 0xc04c0d88 in ithread_loop (arg=0xc25c9c00)
at /usr/src/sys/kern/kern_intr.c:534
#14 0xc04bf9c1 in fork_exit (callout=0xc04c0bb0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) frame 7
#7 0xc059a774
Re: panic: page fault on FreeBSD 5.1 -RELEASE
On Wed, 11 Jun 2003, Nick Twaddell wrote: I downloaded the 5.1 -RELEASE isos yesterday and tried to install them on my server. My server is an IBM Xseries 330 server with an IBM ServeRAID 4LX Raid card. I tried it with and without ACPI kernels and both resulted in a panic. Here is the error.. Fatal trap 12: page fault while in kernel mode Fault code= supervisor read, page not present Instruction pointer = 0x8:0xc29ee760 Stack pointer = 0x10:0xcd33fce4 Frame pointer = 0x10:0xcd33fd0c Code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 Processor eflags = interupt enabled, resume, IOPL = 0 Current process = 29 (irq9: ahc0 ips0) Trap number = 12 Panic = page fault Did I do something wrong or is there a problem with the driver? :( I can't see an invalid eip, ebp, or esp in the above page fault. It would really help if you could get a backtrace (tr when you have DDB enabled). BTW, re@ people: could we add an option (under a sysctl but on by default in the release) that does a backtrace on page fault? We already have the backtrace code accessible w/o DDB I believe. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: page fault (apparently caused by mount_mfs)
Yep! The patch seems to have fixed the problem! :-)
Thanks Luoqi!!
Bob
On Mon, May 17, 1999 at 11:42:21PM -0400, Luoqi Chen wrote:
I have been making world each time after cvsupping so I would expect the
mfs kld module to be getting rebuilt and it appears to be up-to-date:
-r-xr-xr-x 1 root wheel 12778 May 17 13:34 /modules/mfs.ko
Also, both my custom kernel config file and the GENERIC config file
include options MFS so mfs should not be getting loaded, right?
Thanks,
Bob
-lq
--
Bob Willcox The man who follows the crowd will usually get no
b...@luke.pmr.comfurther than the crowd. The man who walks alone is
Austin, TX likely to find himself in places no one has ever
been.-- Alan Ashley-Pitt
Would you try this patch?
Index: kern_conf.c
===
RCS file: /home/ncvs/src/sys/kern/kern_conf.c,v
retrieving revision 1.39
diff -u -r1.39 kern_conf.c
--- kern_conf.c 1999/05/12 13:06:34 1.39
+++ kern_conf.c 1999/05/18 03:27:36
@@ -182,7 +182,7 @@
uintptr_t i = (uintptr_t)x;
#ifdef DEVT_FASCIST
- return(253 - ((i 8) 0xff));
+ return(255 - ((i 8) 0xff));
#else
return((i 8) 0xff);
#endif
@@ -200,7 +200,7 @@
makedev(int x, int y)
{
#ifdef DEVT_FASCIST
-return ((dev_t) (((253 - x) 8) | y));
+return ((dev_t) (((255 - x) 8) | y));
#else
return ((dev_t) ((x 8) | y));
#endif
--
Bob Willcox The man who follows the crowd will usually get no
b...@luke.pmr.comfurther than the crowd. The man who walks alone is
Austin, TX likely to find himself in places no one has ever
been.-- Alan Ashley-Pitt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
panic: page fault (apparently caused by mount_mfs)
Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code = Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 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 = 40 (mount_mfs) interrupt mask = trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
I use mfs a lot and have had no trouble whatsoever. I'm using: swap/tmpmfs rw,-s=200 0 Do you suppose that the usage of /dev/da0s1b directly is what's causing some trouble? On Mon, 17 May 1999, Bob Willcox wrote: Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code= Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 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 = 40 (mount_mfs) interrupt mask= trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
On Mon, May 17, 1999 at 01:03:50PM -0700, Matthew Jacob wrote: I use mfs a lot and have had no trouble whatsoever. I'm using: swap/tmpmfs rw,-s=200 0 Do you suppose that the usage of /dev/da0s1b directly is what's causing some trouble? Don't know, but I will change it and see what happens. Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code= Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 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 = 40 (mount_mfs) interrupt mask= trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt How about recompile mfs kld module and try again? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
On Mon, May 17, 1999 at 01:03:50PM -0700, Matthew Jacob wrote: I use mfs a lot and have had no trouble whatsoever. I'm using: swap/tmpmfs rw,-s=200 0 Do you suppose that the usage of /dev/da0s1b directly is what's causing some trouble? Unfortunately, changing from /dev/da0s1b to swap didn't help. I also tried it without the nosuid option but it still panics. Bob On Mon, 17 May 1999, Bob Willcox wrote: Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code = Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 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 = 40 (mount_mfs) interrupt mask = trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
On Mon, May 17, 1999 at 01:47:59PM -0700, Matthew Jacob wrote: I use mfs a lot and have had no trouble whatsoever. I'm using: swap/tmpmfs rw,-s=200 0 Do you suppose that the usage of /dev/da0s1b directly is what's causing some trouble? Unfortunately, changing from /dev/da0s1b to swap didn't help. I also tried it without the nosuid option but it still panics. Hmm. Is MFS a module as Luoqi keeps mentioning? How much real memory do you have? I believe it is in the kernel (the GENERIC kernel includes it as well as my customized kernel config file). This system has 256MB. See- it's been working fine for me! Yep. I am going to try re-checking out all of the current sources and see if that helps. Perhaps something is hosed with my source tree. Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
On Mon, May 17, 1999 at 04:34:50PM -0400, Luoqi Chen wrote: Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code = Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 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 = 40 (mount_mfs) interrupt mask = trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt How about recompile mfs kld module and try again? I have been making world each time after cvsupping so I would expect the mfs kld module to be getting rebuilt and it appears to be up-to-date: -r-xr-xr-x 1 root wheel 12778 May 17 13:34 /modules/mfs.ko Also, both my custom kernel config file and the GENERIC config file include options MFS so mfs should not be getting loaded, right? Thanks, Bob -lq -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Latest VM changes cause panic: page fault
It happens with plain UFS, I have no NFS. Pre-new-VM kernel not cause page fault -- Andrey A. Chernov a...@null.net MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
New socket code hits again! (was: Latest VM changes cause panic: page fault)
On Sun, Jan 31, 1999 at 02:27:17PM +0300, Andrey A. Chernov wrote: Pre-new-VM kernel not cause page fault Sorry for false alarm - it seems that new socket code hits again and not new VM: #4 0xf019cc3e in trap () #5 0xf013aa20 in soclose () #6 0xf01314e2 in soo_close () #7 0xf011c456 in closef () #8 0xf011ba8f in close () #9 0xf019d4fc in syscall () #10 0xf019456c in Xint0x80_syscall () -- Andrey A. Chernov a...@null.net MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
