Re: dtrace ustack kernel panic
on 30/07/2011 00:27 maestro something said the following: Hi, trying to do so I don't really find my way around. This is what I get when I run kgdb On startup the assert frame is #7 and the probe frame is #8. [snip] kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address= 0x108 fault code= supervisor write, page not present instruction pointer= 0x20:0xc11012d7 stack pointer= 0x28:0xcd3ed9f4 frame pointer= 0x28:0xcd3eda0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process= 1132 (nc) trap number= 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at calltrap+0x6 #6 0xc10e992b at dtrace_panic+0x1b #7 0xc10e995d at dtrace_assfail+0x2d #8 0xc10fb28c at dtrace_probe+0x135c #9 0xc1237f72 at systrace_probe+0x62 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 Uptime: 3m0s Physical memory: 239 MB Dumping 79 MB: 64 48 32 16 [snip] #0 doadump () at pcpu.h:231 231__asm(movl %%fs:0,%0 : =r (td)); once I'm in the kgdb console i type where and all of a sudden the stack trace has only 7 frames... that does not seem correct. Furthermore, the Previous frame inner to this frame (corrupt stack?) error message is not too encuraging either. (kgdb) where #0 doadump () at pcpu.h:231 #1 0xc08d17a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc08d1a40 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc0c158c3 in trap_fatal (frame=0xcd3ed9b4, eva=264) at /usr/src/sys/i386/i386/trap.c:946 #4 0xc0c15bc0 in trap_pfault (frame=0xcd3ed9b4, usermode=0, eva=264) at /usr/src/sys/i386/i386/trap.c:859 #5 0xc0c1612a in trap (frame=0xcd3ed9b4) at /usr/src/sys/i386/i386/trap.c:532 #6 0xc0bfc97c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc11012d7 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko Previous frame inner to this frame (corrupt stack?) (kgdb) what am I doing wrong and what do I have to do to get the specific assert that fails? I am not quite sure. Apparently there is some issue with either what information we store in a crash dump and how, or with how kgdb interprets that information, or with a combination of both... Perhaps this is a result of -O2 optimization and -O1 would improve the situation - not sure again... Meanwhile, there is something simple that you can do without much hassle: (kgdb) list *dtrace_probe+0x135c where the address is taken from the backtrace printed by panic(9). On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon a...@freebsd.org mailto:a...@freebsd.org wrote: on 26/07/2011 04:20 maestro something said the following: Hi, when using the ustack action on the latest FreeBSD8.2 i386 the kernel panics. Here is the information I could gather: let me know if I can provide more information. (i.e., i have the full crash information 80+mbs handy) Use kgdb on the crash dump, go to the dtrace_probe frame and see which exactly assert fails and why. Here is the backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x108 fault code = supervisor write, page not present instruction pointer = 0x20:0xc11012d7 stack pointer = 0x28:0xcd3ed9f4 frame pointer = 0x28:0xcd3eda0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1132 (nc) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at calltrap+0x6 #6 0xc10e992b at dtrace_panic+0x1b #7 0xc10e995d at dtrace_assfail+0x2d #8 0xc10fb28c at dtrace_probe+0x135c #9 0xc1237f72 at systrace_probe+0x62 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 Uptime: 3m0s Physical memory: 239 MB Dumping 79 MB: 64 48 32 16 Steps To reproduce: the dtrace program (i.e., test.d) was: #!/usr/sbin/dtrace -s syscall::accept:return / execname == nc /
Re: dtrace ustack kernel panic
on 30/07/2011 00:27 maestro something said the following: on 30/07/2011 10:50 Andriy Gapon said the following: #7 0xc11012d7 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko Previous frame inner to this frame (corrupt stack?) (kgdb) what am I doing wrong and what do I have to do to get the specific assert that fails? I am not quite sure. Apparently there is some issue with either what information we store in a crash dump and how, or with how kgdb interprets that information, or with a combination of both... Or maybe it's because dtrace_panic_trigger is a function implemented in assembly and we do not provide enough debug information to (k)gdb in that case. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around. This is what I get
when I run
kgdb
On startup the assert frame is #7 and the probe frame is #8.
[snip]
kernel trap 12 with interrupts disabled
I am not quite sure. Apparently there is some issue with either what
information we store in a crash dump and how, or with how kgdb interprets
that
information, or with a combination of both...
Perhaps this is a result of -O2 optimization and -O1 would improve the
situation
I guess I have to recompile the kernel without -O then ... does that work
for freebsd (I remember linux has issues i.e., does not compile without any
-O)
How would I do that the in the most straight forward way?
Meanwhile, there is something simple that you can do without much hassle:
(kgdb) list *dtrace_probe+0x135c
True there was not a lot hassle involved. However the result is not really
satisfactory either :-)
(kgdb) list *dtrace_probe+0x135c
No source file for address 0xc10fb28c.
The address is in accordance with the stack-trace (i.e., frame #8)
where the address is taken from the backtrace printed by panic(9).
cheers
--m
On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 26/07/2011 04:20 maestro something said the following:
Hi,
when using the ustack action on the latest FreeBSD8.2 i386 the
kernel
panics.
Here is the information I could gather:
let me know if I can provide more information. (i.e., i have the
full crash
information 80+mbs handy)
Use kgdb on the crash dump, go to the dtrace_probe frame and see
which exactly
assert fails and why.
Here is the backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x108
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc11012d7
stack pointer = 0x28:0xcd3ed9f4
frame pointer = 0x28:0xcd3eda0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 1132 (nc)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xc09036a7 at kdb_backtrace+0x47
#1 0xc08d1a07 at panic+0x117
#2 0xc0c158c3 at trap_fatal+0x323
#3 0xc0c15bc0 at trap_pfault+0x2f0
#4 0xc0c1612a at trap+0x48a
#5 0xc0bfc97c at calltrap+0x6
#6 0xc10e992b at dtrace_panic+0x1b
#7 0xc10e995d at dtrace_assfail+0x2d
#8 0xc10fb28c at dtrace_probe+0x135c
#9 0xc1237f72 at systrace_probe+0x62
#10 0xc090f63f at syscallenter+0x47f
#11 0xc0c15c14 at syscall+0x34
#12 0xc0bfca11 at Xint0x80_syscall+0x21
Uptime: 3m0s
Physical memory: 239 MB
Dumping 79 MB: 64 48 32 16
Steps To reproduce:
the dtrace program (i.e., test.d) was:
#!/usr/sbin/dtrace -s
syscall::accept:return
/ execname == nc /
{
printf(%s accept:return\n, execname);
ustack();
}
% dtrace -s test.d
then running
% nc -vl 8080
on one shell and
% nc localhost 8080
on another would make the kernel panic
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
on 30/07/2011 21:19 maestro something said the following:
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around. This is what I get
when
I run
kgdb
On startup the assert frame is #7 and the probe frame is #8.
[snip]
kernel trap 12 with interrupts disabled
I am not quite sure. Apparently there is some issue with either what
information we store in a crash dump and how, or with how kgdb interprets
that
information, or with a combination of both...
Perhaps this is a result of -O2 optimization and -O1 would improve the
situation
I guess I have to recompile the kernel without -O then ... does that work for
freebsd (I remember linux has issues i.e., does not compile without any -O)
Not sure about -O0; -O1/-O should work fine.
How would I do that the in the most straight forward way?
See man make.conf: CFLAGS, etc.
Meanwhile, there is something simple that you can do without much hassle:
(kgdb) list *dtrace_probe+0x135c
True there was not a lot hassle involved. However the result is not really
satisfactory either :-)
(kgdb) list *dtrace_probe+0x135c
No source file for address 0xc10fb28c.
The address is in accordance with the stack-trace (i.e., frame #8)
where the address is taken from the backtrace printed by panic(9).
Have you started kgdb with the correct kernel and core file?
If yes, then I am out of ideas.
On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org
mailto:a...@freebsd.org mailto:a...@freebsd.org wrote:
on 26/07/2011 04:20 maestro something said the following:
Hi,
when using the ustack action on the latest FreeBSD8.2 i386 the
kernel
panics.
Here is the information I could gather:
let me know if I can provide more information. (i.e., i have the
full crash
information 80+mbs handy)
Use kgdb on the crash dump, go to the dtrace_probe frame and see
which
exactly
assert fails and why.
Here is the backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x108
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc11012d7
stack pointer = 0x28:0xcd3ed9f4
frame pointer = 0x28:0xcd3eda0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 1132 (nc)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xc09036a7 at kdb_backtrace+0x47
#1 0xc08d1a07 at panic+0x117
#2 0xc0c158c3 at trap_fatal+0x323
#3 0xc0c15bc0 at trap_pfault+0x2f0
#4 0xc0c1612a at trap+0x48a
#5 0xc0bfc97c at calltrap+0x6
#6 0xc10e992b at dtrace_panic+0x1b
#7 0xc10e995d at dtrace_assfail+0x2d
#8 0xc10fb28c at dtrace_probe+0x135c
#9 0xc1237f72 at systrace_probe+0x62
#10 0xc090f63f at syscallenter+0x47f
#11 0xc0c15c14 at syscall+0x34
#12 0xc0bfca11 at Xint0x80_syscall+0x21
Uptime: 3m0s
Physical memory: 239 MB
Dumping 79 MB: 64 48 32 16
Steps To reproduce:
the dtrace program (i.e., test.d) was:
#!/usr/sbin/dtrace -s
syscall::accept:return
/ execname == nc /
{
printf(%s accept:return\n, execname);
ustack();
}
% dtrace -s test.d
then running
% nc -vl 8080
on one shell and
% nc localhost 8080
on another would make the kernel panic
--
Andriy Gapon
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
On Sat, Jul 30, 2011 at 11:27 AM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 21:19 maestro something said the following:
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around. This is what I
get when
I run
kgdb
On startup the assert frame is #7 and the probe frame is #8.
[snip]
kernel trap 12 with interrupts disabled
I am not quite sure. Apparently there is some issue with either what
information we store in a crash dump and how, or with how kgdb
interprets that
information, or with a combination of both...
Perhaps this is a result of -O2 optimization and -O1 would improve
the situation
I guess I have to recompile the kernel without -O then ... does that work
for
freebsd (I remember linux has issues i.e., does not compile without any
-O)
Not sure about -O0; -O1/-O should work fine.
How would I do that the in the most straight forward way?
See man make.conf: CFLAGS, etc.
Looking into that as I type.
Meanwhile, there is something simple that you can do without much
hassle:
(kgdb) list *dtrace_probe+0x135c
True there was not a lot hassle involved. However the result is not
really
satisfactory either :-)
(kgdb) list *dtrace_probe+0x135c
No source file for address 0xc10fb28c.
The address is in accordance with the stack-trace (i.e., frame #8)
where the address is taken from the backtrace printed by panic(9).
Have you started kgdb with the correct kernel and core file?
If yes, then I am out of ideas.
I hope so, I only recompiled the kernel once according to the DTRACE wiki
instructions and I certainly only have one /var/crash/vmcore.* file.
I'll try recompiling the kernel with -O1 and try again. In the meantime, I'm
wondering whether I'm really the only/first one that ran into this problem
or if there are people that actually successfully used the ustack() target
on freebsd-8.2?
cheers
--m
On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org
mailto:a...@freebsd.org mailto:a...@freebsd.org wrote:
on 26/07/2011 04:20 maestro something said the following:
Hi,
when using the ustack action on the latest FreeBSD8.2 i386
the kernel
panics.
Here is the information I could gather:
let me know if I can provide more information. (i.e., i have
the
full crash
information 80+mbs handy)
Use kgdb on the crash dump, go to the dtrace_probe frame and
see which
exactly
assert fails and why.
Here is the backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x108
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc11012d7
stack pointer = 0x28:0xcd3ed9f4
frame pointer = 0x28:0xcd3eda0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 1132 (nc)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xc09036a7 at kdb_backtrace+0x47
#1 0xc08d1a07 at panic+0x117
#2 0xc0c158c3 at trap_fatal+0x323
#3 0xc0c15bc0 at trap_pfault+0x2f0
#4 0xc0c1612a at trap+0x48a
#5 0xc0bfc97c at calltrap+0x6
#6 0xc10e992b at dtrace_panic+0x1b
#7 0xc10e995d at dtrace_assfail+0x2d
#8 0xc10fb28c at dtrace_probe+0x135c
#9 0xc1237f72 at systrace_probe+0x62
#10 0xc090f63f at syscallenter+0x47f
#11 0xc0c15c14 at syscall+0x34
#12 0xc0bfca11 at Xint0x80_syscall+0x21
Uptime: 3m0s
Physical memory: 239 MB
Dumping 79 MB: 64 48 32 16
Steps To reproduce:
the dtrace program (i.e., test.d) was:
#!/usr/sbin/dtrace -s
syscall::accept:return
/ execname == nc /
{
printf(%s accept:return\n, execname);
ustack();
}
% dtrace -s test.d
then running
% nc -vl 8080
on one shell and
% nc localhost 8080
on another would make the kernel panic
--
Andriy Gapon
Re: dtrace ustack kernel panic
Hi, Have you started kgdb with the correct kernel and core file? If yes, then I am out of ideas. I hope so, I only recompiled the kernel once according to the DTRACE wiki instructions and I certainly only have one /var/crash/vmcore.* file. I'll try recompiling the kernel with -O1 and try again. In the meantime, I'm wondering whether I'm really the only/first one that ran into this problem or if there are people that actually successfully used the ustack() target on freebsd-8.2? I could not get the information even after recompiling the kernel here is the relevant (I think information). fb82i386# cat /etc/make.conf CFLAGS= -O (accodring to man make.conf only -O and -O2 is supported for CFLAGS anyways) kernel.debug is the newly compiled kernel (according to the timestamp) fb82i386# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address= 0x108 fault code= supervisor write, page not present instruction pointer= 0x20:0xc1100847 stack pointer= 0x28:0xcd39a9e4 frame pointer= 0x28:0xcd39a9fc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process= 1060 (nc) trap number= 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at calltrap+0x6 #6 0xc10e99db at dtrace_panic+0x1b #7 0xc10e9a0d at dtrace_assfail+0x2d #8 0xc10fa6a6 at dtrace_probe+0xfd6 #9 0xc1237ce4 at systrace_probe+0x84 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 Uptime: 2m39s Physical memory: 239 MB Dumping 78 MB: 63 47 31 15 (kgdb) where #0 doadump () at pcpu.h:231 #1 0xc08d17a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc08d1a40 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc0c158c3 in trap_fatal (frame=0xcd39a9a4, eva=264) at /usr/src/sys/i386/i386/trap.c:946 #4 0xc0c15bc0 in trap_pfault (frame=0xcd39a9a4, usermode=0, eva=264) at /usr/src/sys/i386/i386/trap.c:859 #5 0xc0c1612a in trap (frame=0xcd39a9a4) at /usr/src/sys/i386/i386/trap.c:532 #6 0xc0bfc97c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc1100847 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko Previous frame inner to this frame (corrupt stack?) (kgdb) list *dtrace_probe+0xfd6 No source file for address 0xc10fa6a6. So I'm stuck at the same point. any other ideas? cheers --m cheers --m On Tue, Jul 26, 2011 at 4:05 AM, Andriy Gapon a...@freebsd.org mailto:a...@freebsd.org mailto:a...@freebsd.org mailto:a...@freebsd.org wrote: on 26/07/2011 04:20 maestro something said the following: Hi, when using the ustack action on the latest FreeBSD8.2 i386 the kernel panics. Here is the information I could gather: let me know if I can provide more information. (i.e., i have the full crash information 80+mbs handy) Use kgdb on the crash dump, go to the dtrace_probe frame and see which exactly assert fails and why. Here is the backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x108 fault code = supervisor write, page not present instruction pointer = 0x20:0xc11012d7 stack pointer = 0x28:0xcd3ed9f4 frame pointer = 0x28:0xcd3eda0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1132 (nc) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at
UDP Packet reassembly
Hello List, Didn't see this show up in the mailing list so I am resending. Could someone enlighten me as to when FreeBSD 6.3 does UDP packet reassembly? I am having a problem where I am getting a fragmented udp packet (2 pieces) everthing is fine if I get the first frag first. but if the second frag comes first then both fragments get dropped. I am using ipfilter and a bimap to redirect these packets to a host inside of the FreeBSD box, so I suspicion it is ipfilter causing the drops. I know, I know 6.3 is ancient history, but any insight would be appreciated. Thank, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
On Sat, Jul 30, 2011 at 12:05:33PM -0700, maestro something wrote: Hi, Have you started kgdb with the correct kernel and core file? If yes, then I am out of ideas. I hope so, I only recompiled the kernel once according to the DTRACE wiki instructions and I certainly only have one /var/crash/vmcore.* file. I'll try recompiling the kernel with -O1 and try again. In the meantime, I'm wondering whether I'm really the only/first one that ran into this problem or if there are people that actually successfully used the ustack() target on freebsd-8.2? I could not get the information even after recompiling the kernel here is the relevant (I think information). fb82i386# cat /etc/make.conf CFLAGS= -O (accodring to man make.conf only -O and -O2 is supported for CFLAGS anyways) kernel.debug is the newly compiled kernel (according to the timestamp) fb82i386# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address= 0x108 fault code= supervisor write, page not present instruction pointer= 0x20:0xc1100847 stack pointer= 0x28:0xcd39a9e4 frame pointer= 0x28:0xcd39a9fc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process= 1060 (nc) trap number= 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at calltrap+0x6 #6 0xc10e99db at dtrace_panic+0x1b #7 0xc10e9a0d at dtrace_assfail+0x2d #8 0xc10fa6a6 at dtrace_probe+0xfd6 #9 0xc1237ce4 at systrace_probe+0x84 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 Uptime: 2m39s Physical memory: 239 MB Dumping 78 MB: 63 47 31 15 (kgdb) where #0 doadump () at pcpu.h:231 #1 0xc08d17a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc08d1a40 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc0c158c3 in trap_fatal (frame=0xcd39a9a4, eva=264) at /usr/src/sys/i386/i386/trap.c:946 #4 0xc0c15bc0 in trap_pfault (frame=0xcd39a9a4, usermode=0, eva=264) at /usr/src/sys/i386/i386/trap.c:859 #5 0xc0c1612a in trap (frame=0xcd39a9a4) at /usr/src/sys/i386/i386/trap.c:532 #6 0xc0bfc97c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc1100847 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko Previous frame inner to this frame (corrupt stack?) (kgdb) list *dtrace_probe+0xfd6 No source file for address 0xc10fa6a6. So I'm stuck at the same point. any other ideas? This is i386, right ? I think the cause is that assembler routine panic_trigger does not establish the standard i386 frame. Basically, you need either this, or dwarf annotations, for gdb to be able to walk over the frame. You need to add the standard prologue pushl %ebp movl%esp,%ebp and standard epilogue leave to the function. No idea whether it will continue to operate correctly after. pgpTmrHqEp6po.pgp Description: PGP signature
Re: dtrace ustack kernel panic
on 30/07/2011 22:05 maestro something said the following:
fb82i386# cat /etc/make.conf
CFLAGS= -O
(accodring to man make.conf only -O and -O2 is supported for CFLAGS anyways)
kernel.debug is the newly compiled kernel (according to the timestamp)
fb82i386# kgdb kernel.debug /var/crash/vmcore.0
Is vmcore.0 also new (i.e. produced with the new kernel)?
Does 'list ...' command still produces no useful output?
P.S. Also, hmm, I think that you shouldn't run kgdb on kernel.debug, just to
avoid any confusion... I think that you should run something like kgdb
/boot/${your installed kernel}/kernel /var/crash/vmcore.0; the debug symbols are
automatically picked up from *.symbols files in the kernel directory.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
Hi,
On Sat, Jul 30, 2011 at 12:52 PM, Andriy Gapon a...@freebsd.org wrote:
on 30/07/2011 22:05 maestro something said the following:
fb82i386# cat /etc/make.conf
CFLAGS= -O
(accodring to man make.conf only -O and -O2 is supported for CFLAGS
anyways)
kernel.debug is the newly compiled kernel (according to the timestamp)
fb82i386# kgdb kernel.debug /var/crash/vmcore.0
Is vmcore.0 also new (i.e. produced with the new kernel)?
Does 'list ...' command still produces no useful output?
As mentioned before, the list command still gives the same error message:
P.S. Also, hmm, I think that you shouldn't run kgdb on kernel.debug, just
to
avoid any confusion... I think that you should run something like kgdb
/boot/${your installed kernel}/kernel /var/crash/vmcore.0; the debug
symbols are
automatically picked up from *.symbols files in the kernel directory.
Same result when using /boot/kernel/kernel
(kgdb) list *dtrace_probe+0xfd6
No source file for address 0xc10fa6a6.
cheers
--m
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
on 30/07/2011 23:03 maestro something said the following: (kgdb) list *dtrace_probe+0xfd6 No source file for address 0xc10fa6a6. Are the sources on the same machine? This is probably the last idea from me. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
Hi, on 30/07/2011 23:03 maestro something said the following: (kgdb) list *dtrace_probe+0xfd6 No source file for address 0xc10fa6a6. Are the sources on the same machine? This is probably the last idea from me. Yes all is done on the same (virtual 32bit) machine. Sources are there too. If i do make installkernel KERNCONF=MYKERNEL the kernel should be installed right? (I assume so b/c /boot/kernel/kernel has the correct new timestamp) cheers -m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
Hi, This is i386, right ? I think the cause is that assembler routine panic_trigger does not establish the standard i386 frame. Basically, you need either this, or dwarf annotations, for gdb to be able to walk over the frame. You need to add the standard prologue pushl %ebp movl%esp,%ebp and standard epilogue leave to the function. No idea whether it will continue to operate correctly after. my panic_trigger looks like this now: /* int panic_trigger(int *tp) */ ENTRY(panic_trigger) pushl %ebp movl%esp,%ebp xorl%eax, %eax movl$0xdefacedd, %edx lock xchgl %edx, (%edi) cmpl$0, %edx je 0f movl$0, %eax leave ret 0: movl$1, %eax leave ret END(panic_trigger) same result, (actually too same as the address in the stack trace is still the same, is that possible?) cheers --m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dtrace ustack kernel panic
Hi, This is i386, right ? I think the cause is that assembler routine panic_trigger does not establish the standard i386 frame. Basically, you need either this, or dwarf annotations, for gdb to be able to walk over the frame. You need to add the standard prologue pushl %ebp movl%esp,%ebp and standard epilogue leave to the function. No idea whether it will continue to operate correctly after. my panic_trigger looks like this now: /* int panic_trigger(int *tp) */ ENTRY(panic_trigger) pushl %ebp movl%esp,%ebp xorl%eax, %eax movl$0xdefacedd, %edx lock xchgl %edx, (%edi) cmpl$0, %edx je 0f movl$0, %eax leave ret 0: movl$1, %eax leave ret END(panic_trigger) same result, (actually too same as the address in the stack trace is still the same, is that possible?) KDB: stack backtrace: #0 0xc09036a7 at kdb_backtrace+0x47 #1 0xc08d1a07 at panic+0x117 #2 0xc0c158c3 at trap_fatal+0x323 #3 0xc0c15bc0 at trap_pfault+0x2f0 #4 0xc0c1612a at trap+0x48a #5 0xc0bfc97c at calltrap+0x6 #6 0xc10e99db at dtrace_panic+0x1b #7 0xc10e9a0d at dtrace_assfail+0x2d #8 0xc10fa6a6 at dtrace_probe+0xfd6 #9 0xc1237ce4 at systrace_probe+0x84 #10 0xc090f63f at syscallenter+0x47f #11 0xc0c15c14 at syscall+0x34 #12 0xc0bfca11 at Xint0x80_syscall+0x21 I tried playing around with kgdb a bit. It finds source files until frame #10 (i.e., syscallenter + 0x47f) (kgdb) list *syscallenter+0x47f 0xc090f63f is in syscallenter (/usr/src/sys/kern/subr_trap.c:328). 323 * If the systrace module has registered it's probe 324 * callback and if there is a probe active for the 325 * syscall 'return', process the probe. 326 */ 327if (systrace_probe_func != NULL sa-callp-sy_return != 0) 328(*systrace_probe_func)(sa-callp-sy_return, sa-code, 329sa-callp, sa-args); 330#endif 331CTR4(KTR_SYSC, syscall: p=%p error=%d return %#lx %#lx, 332p, error, td-td_retval[0], td-td_retval[1]); (kgdb) list *systrace_probe+0x84 No source file for address 0xc1237ce4. Thus, it seems that the first frame where kgdb cannot find a source file is #9 (i.e., systrace_probe + 0x84) As far as I understand that's when the (imho) function pointer systrace_probe_func gets invoked. Therefore, it seems that kgdb has a hard time finding the source file for the function invoked through that pointer. Is this complete nonsense, or does that actually sound familiar to anyone? And still I'm wondering whether anybody ever successfully used the ustack action on Freebsd-8.2 i386 cheers --m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UDP Packet reassembly
On Sat, Jul 30, 2011 at 03:11:35PM -0400, Stephen Clark wrote: Didn't see this show up in the mailing list so I am resending. It showed up, and people have responded. Search for UDP Packet reassembly and you'll see. http://lists.freebsd.org/pipermail/freebsd-stable/2011-July/thread.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UDP Packet reassembly
In message 4e345767.5070...@earthlink.net, Stephen Clark writes: Hello List, Didn't see this show up in the mailing list so I am resending. Could someone enlighten me as to when FreeBSD 6.3 does UDP packet reassembly? I am having a problem where I am getting a fragmented udp packet (2 pieces) everthing is fine if I get the first frag first. but if the second frag comes first then b oth fragments get dropped. I am using ipfilter and a bimap to redirect these packets to a host inside of the FreeBSD box, so I suspicion it is ipfilter causing the drops. I know, I know 6.3 is ancient history, but any insight would be appreciated. Know issue, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/82806 Thank, Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
