date:20110730

Re: UDP Packet reassembly

2011-07-30 Thread Mark Andrews


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"

Re: UDP Packet reassembly

2011-07-30 Thread Jeremy Chadwick

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: dtrace ustack kernel panic

2011-07-30 Thread maestro something

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: dtrace ustack kernel panic

2011-07-30 Thread maestro something

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

2011-07-30 Thread maestro something

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

2011-07-30 Thread Andriy Gapon

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

2011-07-30 Thread maestro something

Hi,


On Sat, Jul 30, 2011 at 12:52 PM, Andriy Gapon  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

2011-07-30 Thread Andriy Gapon

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

2011-07-30 Thread Kostik Belousov

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

UDP Packet reassembly

2011-07-30 Thread Stephen Clark


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

2011-07-30 Thread maestro something

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 > > 
>> > > >> 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
>> >

Re: dtrace ustack kernel panic

2011-07-30 Thread maestro something

On Sat, Jul 30, 2011 at 11:27 AM, Andriy Gapon  wrote:

> on 30/07/2011 21:19 maestro something said the following:
> >
> >
> > On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon  > > 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  > 
> > > >> 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 ac

Re: dtrace ustack kernel panic

2011-07-30 Thread Andriy Gapon

on 30/07/2011 21:19 maestro something said the following:
> 
> 
> On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon  > 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  
> > >> 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

2011-07-30 Thread maestro something

On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon  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  > > 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

2011-07-30 Thread Andriy Gapon

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

2011-07-30 Thread Andriy Gapon

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  > 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
> >
> >
> > Step

Re: UDP Packet reassembly

Re: UDP Packet reassembly

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

UDP Packet reassembly

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

Re: dtrace ustack kernel panic

16 matches

Site Navigation

Mail list logo

Footer information