[Bug 234026] [panic] [dummynet] Repeatable panic in dummynet due to locking issues and use-after-free

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026

--- Comment #3 from Stanislav Trofimov  ---
(In reply to Stanislav Trofimov from comment #1)

Latest p6 update fixed my problem

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 234026] [panic] [dummynet] Repeatable panic in dummynet due to locking issues and use-after-free

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026

Dmitry  changed:

   What|Removed |Added

 CC||dkun...@gmail.com

--- Comment #2 from Dmitry  ---
Hi
Same problem on FreeBSD 12.0-RELEASE-p5 r347890

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 234026] [panic] [dummynet] Repeatable panic in dummynet due to locking issues and use-after-free

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026

Stanislav Trofimov  changed:

   What|Removed |Added

 CC||norespo...@yandex.ru

--- Comment #1 from Stanislav Trofimov  ---
Hi
Same problem on FreeBSD 12.0-RELEASE-p3 GENERIC

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xfe003ee448d0
frame pointer   = 0x28:0xfe003ee44950
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 (dummynet)
trap number = 12
panic: page fault
cpuid = 0
time = 1551299285
KDB: stack backtrace:
#0 0x80be7977 at kdb_backtrace+0x67
#1 0x80b9b563 at vpanic+0x1a3
#2 0x80b9b3b3 at panic+0x43
#3 0x8107496f at trap_fatal+0x35f
#4 0x810749c9 at trap_pfault+0x49
#5 0x81073fee at trap+0x29e
#6 0x8104f435 at calltrap+0x8
#7 0x80d26cdd at ip_input+0x45d
#8 0x80cbc576 at netisr_dispatch_src+0xd6
#9 0x82e6ea1e at dummynet_send+0x1ae
#10 0x82e6e3af at dummynet_task+0x2ef
#11 0x80bf9cb4 at taskqueue_run_locked+0x154
#12 0x80bfae18 at taskqueue_thread_loop+0x98
#13 0x80b5bf33 at fork_exit+0x83

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 234026] [panic] [dummynet] Repeatable panic in dummynet due to locking issues and use-after-free

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026

Bug ID: 234026
   Summary: [panic] [dummynet] Repeatable panic in dummynet due to
locking issues and use-after-free
   Product: Base System
   Version: 11.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: n...@freebsd.org
  Reporter: eu...@freebsd.org

Hi!

I run multiple routers using FreeBSD 11.2-STABLE/amd64 r336962, ipfw+dummynet
and net/mpd5 daemon that dynamically creates/destroys ngXXX interfaces for
multiple PPPoE clients. If an interface ngXXX is destroyed while dummynet
pipe/queue keeps mbuf with m_pkthdr.rcvif pointing to freed struct ifnet,
kernel panices when taskqueue runs
dummynet_task/dummynet_send/netisr_dispatch_src/ip_input sequence and I have
crashdump.

kgdb session follows:

Script started on Sat Dec 15 06:47:49 2018
Command: kgdb kernel.debug /home/nanobsd/pppoe/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 "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
stack pointer   = 0x28:0xfe01244bb920
frame pointer   = 0x28:0xfe01244bb9a0
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 (dummynet)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at 0x802fc89b =
db_trace_self_wrapper+0x2b/frame 0xfe01244bb5d0
vpanic() at 0x804f0ac7 = vpanic+0x177/frame 0xfe01244bb630
panic() at 0x804f0943 = panic+0x43/frame 0xfe01244bb690
trap_fatal() at 0x8076f2af = trap_fatal+0x35f/frame 0xfe01244bb6e0
trap_pfault() at 0x8076f309 = trap_pfault+0x49/frame 0xfe01244bb740
trap() at 0x8076eae4 = trap+0x2d4/frame 0xfe01244bb850
calltrap() at 0x8074ff3c = calltrap+0x8/frame 0xfe01244bb850
--- trap 0xc, rip = 0x804ec893, rsp = 0xfe01244bb920, rbp =
0xfe01244bb9a0 ---
__rw_rlock_hard() at 0x804ec893 = __rw_rlock_hard+0xf3/frame
0xfe01244bb9a0
ip_input() at 0x806444ca = ip_input+0x53a/frame 0xfe01244bba30
netisr_dispatch_src() at 0x8060ebe8 = netisr_dispatch_src+0xa8/frame
0xfe01244bba80
dummynet_send() at 0x806723dd = dummynet_send+0x10d/frame
0xfe01244bbab0
dummynet_task() at 0x80671e1c = dummynet_task+0x2ec/frame
0xfe01244bbb20
taskqueue_run_locked() at 0x80548a54 = taskqueue_run_locked+0x154/frame
0xfe01244bbb80
taskqueue_thread_loop() at 0x80549bb8 =
taskqueue_thread_loop+0x98/frame 0xfe012440
fork_exit() at 0x804ba803 = fork_exit+0x83/frame 0xfe01244bbbf0
fork_trampoline() at 0x80750eee = fork_trampoline+0xe/frame
0xfe01244bbbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 57d17h28m40s
Dumping 467 out of 4073 MB:..4%..11%..21%..31%..42%..52%..62%..72%..83%..93%

Reading symbols from /boot/modules/tmpfs.ko...done.
Loaded symbols for /boot/modules/tmpfs.ko
#0  doadump (textdump=1) at pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:230
#1  0x804f06c0 in kern_reboot (howto=260) at
/home/src/sys/kern/kern_shutdown.c:383
#2  0x804f0b01 in vpanic (fmt=, ap=)
at /home/src/sys/kern/kern_shutdown.c:776
#3  0x804f0943 in panic (fmt=)
at /home/src/sys/kern/kern_shutdown.c:707
#4  0x8076f2af in trap_fatal (frame=0xfe01244bb860,
eva=274877908504)
at /home/src/sys/amd64/amd64/trap.c:877
#5  0x8076f309 in trap_pfault (frame=0xfe01244bb860, usermode=0) at
pcpu.h:230
#6  0x8076eae4 in trap (frame=0xfe01244bb860) at
/home/src/sys/amd64/amd64/trap.c:415
#7  0x8074ff3c in calltrap () at
/home/src/sys/amd64/amd64/exception.S:231
#8  0x804ec893 in __rw_rlock_hard (rw=0xf80092e78190,
td=0xf80001d02620,
v=) at /home/src/sys/kern/kern_rwlock.c:493
#9  0x806444ca in ip_input (m=)
at /home/src/sys/netinet/ip_input.c:795
#10 0x8060ebe8 in netisr_dispatch_src (proto=1, source=,
m=) at /home/src/sys/net/netisr.c:1120
#11 0x806723dd in dummynet_send (m=0x0) at
/home/src/sys/netpfil/ipfw/ip_dn_io.c:774
#12 0x80671e1c in dummynet_task (context=,
pending=) at /home/src/sys/netpfil/ipfw/ip_dn_io.c:729
#13

[Bug 162558] [dummynet] [panic] seldom dummynet panics

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162558

Eugene Grosbein  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|In Progress |Closed
   Assignee|freebsd-net@FreeBSD.org |eu...@freebsd.org
 CC||eu...@freebsd.org

--- Comment #4 from Eugene Grosbein  ---
Seems to be duplicate of 220078 (unlocked access to INADDR_TO_IFP in the
multicast handling code).

*** This bug has been marked as a duplicate of bug 220078 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

Eugene Grosbein  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|In Progress |Closed
   Assignee|freebsd-net@FreeBSD.org |eu...@freebsd.org
 CC||eu...@freebsd.org

--- Comment #9 from Eugene Grosbein  ---
Known problem in ng_iface(4) described in the PR 220076 believed to be source
of this problem too.

*** This bug has been marked as a duplicate of bug 220076 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

Andrey V. Elsukov a...@freebsd.org changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #7 from Andrey V. Elsukov a...@freebsd.org ---
(In reply to dblais from comment #2)
 #6  0x80cdbd13 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:232
 #7  0x8090adb0 in _rw_rlock (rw=0xfe013aade5a8, file=0x0, 
 line=485069968) at /usr/src/sys/kern/kern_rwlock.c:382
 #8  0x809c5959 in bpf_mtap2 (bp=0xfe013aade580, 
 data=0xff88826429bc, dlen=4, m=0xfe0300f46700)
 at /usr/src/sys/net/bpf.c:2197
 #9  0x8188e11a in ng_iface_bpftap (ifp=value optimized out, m=0x0, 
 family=144 '\220')
 at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:444
 #10 0x8188eb11 in ng_iface_output (ifp=0xfe014566a000, 
 m=0xfe0300f46700, dst=0xff8882642aac, ro=value optimized out)
 at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:394

This panic looks different. Probably an interface has gone away and BPF's
interface departure handler already destroyed bif_lock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

--- Comment #6 from eu...@grosbein.net ---
(In reply to Hiren Panchasara from comment #4)

This PR is probably duplicate of my later PR *195102* that contains more
details.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

--- Comment #5 from eu...@grosbein.net ---
(In reply to Hiren Panchasara from comment #4)

This PR is probably duplicate of my later PR 149513 that contains more details.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

--- Comment #8 from dbl...@interplex.ca ---
I just opened a new bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096 since my error is
similar but different.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

dbl...@interplex.ca changed:

   What|Removed |Added

 CC||dbl...@interplex.ca

--- Comment #2 from dbl...@interplex.ca ---
Hi,

We have the very same issue here on FreeBSD 9.2 RELEASE on different hardware
(HP DL360 G6 and HP Microserver G7). I suggest someone change Importance to
something else than Normal Affects Only me because we have at least 8 such
servers with the same issue. It happens more often when there's more load
(customers and/or traffic). Don't know how it scales exactly (linear, quadratic
or exponential) nor if it scales with traffic or the amount of pppoe clients
but it sure if one of them of a mix of them.


Here's the kernel dump:

FreeBSD hiden_host 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26
22:50:31 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC 
amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...

Unread portion of the kernel message buffer:
current process = 0 (dummynet)
trap number = 12
panic: page fault
cpuid = 7
KDB: stack backtrace:
#0 0x80947986 at kdb_backtrace+0x66
#1 0x8090d9ae at panic+0x1ce
#2 0x80cf20d0 at trap_fatal+0x290
#3 0x80cf2431 at trap_pfault+0x211
#4 0x80cf29e4 at trap+0x344
#5 0x80cdbd13 at calltrap+0x8
#6 0x809c5959 at bpf_mtap2+0x89
#7 0x8188e11a at ng_iface_bpftap+0x2a
#8 0x8188eb11 at ng_iface_output+0xf1
#9 0x80a3a104 at ip_output+0xd74
#10 0x81864edc at dummynet_send+0x13c
#11 0x81865467 at dummynet_task+0x1b7
#12 0x80954554 at taskqueue_run_locked+0x74
#13 0x80955506 at taskqueue_thread_loop+0x46
#14 0x808db67f at fork_exit+0x11f
#15 0x80cdc23e at fork_trampoline+0xe
Uptime: 21d19h53m27s
Dumping 1450 out of 16359 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/if_carp.ko...Reading symbols from
/boot/kernel/if_carp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_carp.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from
/boot/kernel/ipfw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipfw.ko
Reading symbols from /boot/kernel/dummynet.ko...Reading symbols from
/boot/kernel/dummynet.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dummynet.ko
Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from
/boot/kernel/ng_socket.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from
/boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from
/boot/kernel/ng_mppc.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_mppc.ko
Reading symbols from /boot/kernel/rc4.ko...Reading symbols from
/boot/kernel/rc4.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/rc4.ko
Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from
/boot/kernel/ng_ether.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from
/boot/kernel/ng_pppoe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_pppoe.ko
Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from
/boot/kernel/ng_tee.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_tee.ko
Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from
/boot/kernel/ng_iface.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_iface.ko
Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from
/boot/kernel/ng_ppp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ppp.ko
#0  doadump (textdump=value optimized out) at pcpu.h:234
234 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=value optimized out) at pcpu.h:234
#1  0x8090d486 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2  0x8090d987 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3  0x80cf20d0 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:879
#4  0x80cf2431 in trap_pfault (frame=0xff8882642700, 

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

--- Comment #3 from dbl...@interplex.ca ---
Sorry, some errors in my previous post:


Don't know how it scales exactly (linear, quadratic or exponential) nor if it
scales with traffic or the amount of pppoe clients but it sure if one of them
of a mix of them. should be:

I don't know how it scales exactly (linear, quadratic or exponential) nor if
it scales with traffic or the amount of pppoe clients but it sure is one of
them or a mix of them.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Bug 171711] [dummynet] [panic] Kernel panic in dummynet

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711

--- Comment #4 from Hiren Panchasara hi...@freebsd.org ---
(In reply to dblais from comment #2)
I cannot look into this right now but noticed that what you are reporting looks
different than the original post. That seems double free and what you are
seeing is locking issue in bpf. I don't know the code very well but that's my
understanding.

1 more suggestion, if you have many servers with the exact same panic, what is
the frequency of the panics? Can you provide any more info? It'd be really
helpful if you can run -current or stable10/release10 on one of those machines
as those branches are actively being worked on and there are higher chances
that what you are seeing _might_ have been fixed there. 

my 2 c.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/162558: [dummynet] [panic] seldom dummynet panics

[Eugene Grosbein]

The following reply was made to PR kern/162558; it has been noted by GNATS.

From: Eugene Grosbein egrosb...@rdtc.ru
To: bug-follo...@freebsd.org
Cc: Luigi Rizzo ri...@iet.unipi.it
Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics
Date: Tue, 22 Jan 2013 12:33:51 +0700

 Hi!
 
 The same problem had repeated 20 January with FreeBSD 8.3-STABLE
 built from late October 2012 sources. This time I've got nice crashdump
 with backtrace. That's with net.isr.bindthreads=1, net.isr.direct=1 and
 net.isr.direct_force=1.
 
 Full crashinfo, kernel.debug and crashdump are available here:
 http://www.grosbein.net/freebsd/crash/20130120/core.0.txt
 http://www.grosbein.net/freebsd/crash/20130120/kernel.debug.xz (8.4M)
 http://www.grosbein.net/freebsd/crash/20130120/vmcore.0.xz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/171711: [dummynet] [panic] Kernel panic in dummynet

[linimon]

Synopsis: [dummynet] [panic] Kernel panic in dummynet

Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Oct 5 03:50:42 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=171711
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/162558: [dummynet] [panic] seldom dummynet panics

[Eugene Grosbein]

The following reply was made to PR kern/162558; it has been noted by GNATS.

From: Eugene Grosbein egrosb...@rdtc.ru
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics
Date: Wed, 15 Feb 2012 19:25:43 +0700

 Hi!
 
 The source of this problem seems to be famous 'dangling pointer' problem:
 - mbufs with packets from PPPoE users sometimes stall within dummynet queues,
 - then user disconnects, its ngX interface get destroyed,
 - then dummynet attempts to dereference its ifp pointer and panic occurs.
 
 There is workaround consisting of several tunnables eliminating races:
 
 - net.isr.bindthreads=1 in /boot/loader.conf;
 - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf
   (default)
 
 Plus, use recent 8.2-STABLE as it contains some netgraph fixes
 for bugs that lead to panics in 8.2-RELEASE and early 8.2-STABLE versions.
 
 With these precautions I run my routers rock stable for months.
 
 Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Repeating kernel panic within dummynet

[Eugene Grosbein]

Hi!

My FreeBSD 8.2/amd64 routers use dummynet heavily
and keep panic with the *same* KDB backtrace:

dummynet: bad switch -256!


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xff81229d9a10
frame pointer   = 0x28:0xff81229d9a40
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 (dummynet)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801aaaca = db_trace_self_wrapper+0x2a
kdb_backtrace() at 0x80329667 = kdb_backtrace+0x37
panic() at 0x802f6cb7 = panic+0x187
trap_fatal() at 0x804d8b50 = trap_fatal+0x290
trap_pfault() at 0x804d8f2f = trap_pfault+0x28f
trap() at 0x804d940f = trap+0x3df
calltrap() at 0x804c0b44 = calltrap+0x8
--- trap 0xc, rip = 0, rsp = 0xff81229d9a10, rbp = 0xff81229d9a40 ---
uart_z8530_class() at 0
mb_dtor_pack() at 0x802e4787 = mb_dtor_pack+0x37
uma_zfree_arg() at 0x8049ba5a = uma_zfree_arg+0x3a
m_freem() at 0x803556a7 = m_freem+0x37
dummynet_send() at 0x803e909d = dummynet_send+0x2d
dummynet_task() at 0x803e93c6 = dummynet_task+0x1c6
taskqueue_run_locked() at 0x80335a65 = taskqueue_run_locked+0x85
taskqueue_thread_loop() at 0x80335bfe = taskqueue_thread_loop+0x4e
fork_exit() at 0x802ca4bf = fork_exit+0x11f
fork_trampoline() at 0x804c108e = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff81229d9d00, rbp = 0 ---
Uptime: 2d5h17m39s
Dumping 4087 MB (4 chunks)
  chunk 0: 1MB (150 pages) ... ok
  chunk 1: 3575MB (915072 pages) 3559 3543 3527 3511 3495 3479


It does not finish writing dump and hangs until IPMI watchdog reboots the box.
I've tried to use debug.minidump=1 but it still hangs while crashdumps is 
generating
and stops responding to Ctrl-Alt-ESC meantime.

Sadly, I cannot add options INVARIANTS to the kernel because it makes my 
mpd-based
routers to panic very often (every 2-3 hours) due to famous 'dangling pointer'
problem - PPPoE user disconnects, its ngXXX interface got removed, then its 
traffic
goes out various system queues (netisr, dummynet etc.) and another kind of panic
occurs due to INVARIANTS' references to non-existent ifp.

Please help.

Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Repeating kernel panic within dummynet

[Eugene Grosbein]

11.07.2011 18:45, Vlad Galu пишет:
 
 On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote:
 
 Hi!

 My FreeBSD 8.2/amd64 routers use dummynet heavily
 and keep panic with the *same* KDB backtrace:

 dummynet: bad switch -256!

Forgot to mention that I use io_fast dummynet mode
and have increased pipe lengths:

net.inet.ip.dummynet.pipe_slot_limit=1000
net.inet.ip.dummynet.io_fast=1

Distinct pipes do really use long lengths.

 Sadly, I cannot add options INVARIANTS to the kernel because it makes my 
 mpd-based
 routers to panic very often (every 2-3 hours) due to famous 'dangling 
 pointer'
 problem - PPPoE user disconnects, its ngXXX interface got removed, then its 
 traffic
 goes out various system queues (netisr, dummynet etc.) and another kind of 
 panic
 occurs due to INVARIANTS' references to non-existent ifp.
 
 Hi Eugene,
 If your ISR threads aren't already bound to CPUs, you can bind them and try 
 using INVARIANTS.

Please explain how to bind them. I have 4-core boxes with 4 NICs grouped to 2 
laggs,
one lagg(4) for uplink and another one for downlink.

Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Repeating kernel panic within dummynet

[Vlad Galu]

On Jul 11, 2011, at 1:51 PM, Eugene Grosbein wrote:

 11.07.2011 18:45, Vlad Galu пишет:
 
 On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote:
 
 Hi!
 
 My FreeBSD 8.2/amd64 routers use dummynet heavily
 and keep panic with the *same* KDB backtrace:
 
 dummynet: bad switch -256!
 
 Forgot to mention that I use io_fast dummynet mode
 and have increased pipe lengths:
 
 net.inet.ip.dummynet.pipe_slot_limit=1000
 net.inet.ip.dummynet.io_fast=1
 
 Distinct pipes do really use long lengths.
 
 Sadly, I cannot add options INVARIANTS to the kernel because it makes my 
 mpd-based
 routers to panic very often (every 2-3 hours) due to famous 'dangling 
 pointer'
 problem - PPPoE user disconnects, its ngXXX interface got removed, then its 
 traffic
 goes out various system queues (netisr, dummynet etc.) and another kind of 
 panic
 occurs due to INVARIANTS' references to non-existent ifp.
 
 Hi Eugene,
 If your ISR threads aren't already bound to CPUs, you can bind them and try 
 using INVARIANTS.
 
 Please explain how to bind them. I have 4-core boxes with 4 NICs grouped to 2 
 laggs,
 one lagg(4) for uplink and another one for downlink.
 

net.isr.bindthreads=1

I'm not sure how and if that would help your particular setup, but it did so in 
Adrian Minta's recent netgraph/mpd experiments. According to an off-list chat I 
had with him, the machine would panic unless the ISRs were bound.

 Eugene Grosbein

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Repeating kernel panic within dummynet

[Eugene Grosbein]

11.07.2011 19:02, Vlad Galu пишет:

 net.isr.bindthreads=1
 
 I'm not sure how and if that would help your particular setup, but it did so 
 in Adrian Minta's recent netgraph/mpd experiments. According to an off-list 
 chat I had with him, the machine would panic unless the ISRs were bound.

I disable ISR parallelism for my mpd routers using:

net.isr.direct=1
net.isr.direct_force=1

At the other hand, there are other queues where traffic got delayed, not ISR 
only.
Dummynet itself is an example. The router still panices with INVARIANTS too 
often.

Eugene Grosbein

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Repeating kernel panic within dummynet

[Vlad Galu]

On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote:

 Hi!
 
 My FreeBSD 8.2/amd64 routers use dummynet heavily
 and keep panic with the *same* KDB backtrace:
 
 dummynet: bad switch -256!
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0x0
 fault code  = supervisor read instruction, page not present
 instruction pointer = 0x20:0x0
 stack pointer   = 0x28:0xff81229d9a10
 frame pointer   = 0x28:0xff81229d9a40
 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 (dummynet)
 trap number = 12
 panic: page fault
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper() at 0x801aaaca = db_trace_self_wrapper+0x2a
 kdb_backtrace() at 0x80329667 = kdb_backtrace+0x37
 panic() at 0x802f6cb7 = panic+0x187
 trap_fatal() at 0x804d8b50 = trap_fatal+0x290
 trap_pfault() at 0x804d8f2f = trap_pfault+0x28f
 trap() at 0x804d940f = trap+0x3df
 calltrap() at 0x804c0b44 = calltrap+0x8
 --- trap 0xc, rip = 0, rsp = 0xff81229d9a10, rbp = 0xff81229d9a40 ---
 uart_z8530_class() at 0
 mb_dtor_pack() at 0x802e4787 = mb_dtor_pack+0x37
 uma_zfree_arg() at 0x8049ba5a = uma_zfree_arg+0x3a
 m_freem() at 0x803556a7 = m_freem+0x37
 dummynet_send() at 0x803e909d = dummynet_send+0x2d
 dummynet_task() at 0x803e93c6 = dummynet_task+0x1c6
 taskqueue_run_locked() at 0x80335a65 = taskqueue_run_locked+0x85
 taskqueue_thread_loop() at 0x80335bfe = taskqueue_thread_loop+0x4e
 fork_exit() at 0x802ca4bf = fork_exit+0x11f
 fork_trampoline() at 0x804c108e = fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff81229d9d00, rbp = 0 ---
 Uptime: 2d5h17m39s
 Dumping 4087 MB (4 chunks)
  chunk 0: 1MB (150 pages) ... ok
  chunk 1: 3575MB (915072 pages) 3559 3543 3527 3511 3495 3479
 
 
 It does not finish writing dump and hangs until IPMI watchdog reboots the box.
 I've tried to use debug.minidump=1 but it still hangs while crashdumps is 
 generating
 and stops responding to Ctrl-Alt-ESC meantime.
 
 Sadly, I cannot add options INVARIANTS to the kernel because it makes my 
 mpd-based
 routers to panic very often (every 2-3 hours) due to famous 'dangling pointer'
 problem - PPPoE user disconnects, its ngXXX interface got removed, then its 
 traffic
 goes out various system queues (netisr, dummynet etc.) and another kind of 
 panic
 occurs due to INVARIANTS' references to non-existent ifp.

Hi Eugene,
If your ISR threads aren't already bound to CPUs, you can bind them and try 
using INVARIANTS.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/157802: [dummynet] [panic] kernel panic in dummynet

[ae]

Synopsis: [dummynet] [panic] kernel panic in dummynet

State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Fri Jun 17 11:33:59 UTC 2011
State-Changed-Why: 
Feedback requested.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157802
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/157802: [dummynet] [panic] kernel panic in dummynet

[Andrey V. Elsukov]

The following reply was made to PR kern/157802; it has been noted by GNATS.

From: Andrey V. Elsukov a...@freebsd.org
To: bug-follo...@freebsd.org, alexey_kovale...@inbox.ru
Cc:  
Subject: Re: kern/157802: [dummynet] [panic] kernel panic in dummynet
Date: Thu, 16 Jun 2011 15:05:59 +0400

 Hi, Alexey
 
 can you provide exact commands to reproduce this?
 
 -- 
 WBR, Andrey V. Elsukov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: kern/157802: [dummynet] [panic] kernel panic in dummynet

[linimon]

Old Synopsis: kernel panic in dummynet
New Synopsis: [dummynet] [panic] kernel panic in dummynet

Responsible-Changed-From-To: freebsd-amd64-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jun 12 21:53:36 UTC 2011
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157802
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: panic in dummynet

[Sergey Kandaurov]

On 21 March 2011 12:43, Sergey Kandaurov pluk...@gmail.com wrote:
 Hi.

 This is a 8.1 box, not very much loaded.
 It has two simple dummynet rules.
 That's the first time it panics there. Any hints?

 db x/s *panicstr
 0:      *** error reading from address 0 ***
 db bt
 Tracing pid 0 tid 100116 td 0xff000ab057c0
 m_copym() at m_copym+0x37
 ip_fragment() at ip_fragment+0x132
 ip_output() at ip_output+0xeef
 dummynet_send() at dummynet_send+0x14c
 dummynet_task() at dummynet_task+0x1b7
 taskqueue_run() at taskqueue_run+0x93
 taskqueue_thread_loop() at taskqueue_thread_loop+0x46
 fork_exit() at fork_exit+0x118
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 ---


Hmm.. Another crash today.
Looks like it might be due to race with bce intr handler.

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:0x80611587
stack pointer   = 0x28:0xff82b41da960
frame pointer   = 0x28:0xff82b41da9c0
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 (dummynet)

db bt
Tracing pid 0 tid 100121 td 0xff00094177c0
m_copym() at m_copym+0x37
ip_fragment() at ip_fragment+0x132
ip_output() at ip_output+0xeef
dummynet_send() at dummynet_send+0x14c
dummynet_task() at dummynet_task+0x1b7
taskqueue_run() at taskqueue_run+0x93
taskqueue_thread_loop() at taskqueue_thread_loop+0x46
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff82b41dad30, rbp = 0 ---

cpuid= 0
curthread= 0xff00094177c0: pid 0 dummynet
cpuid= 1
curthread= 0xff00029a23e0: pid 12 irq257: bce1
cpuid= 2
curthread= 0xff00026fc3e0: pid 12 swi4: clock

100039   Run CPU 1   [irq257: bce1]
100038   RunQ[irq256: bce0]
100012   Run CPU 2   [swi4: clock]

db bt 100039
Tracing pid 12 tid 100039 td 0xff00029a23e0
cpustop_handler() at cpustop_handler+0x40
ipi_nmi_handler() at ipi_nmi_handler+0x30
trap() at trap+0x175
nmi_calltrap() at nmi_calltrap+0x8
--- trap 0x13, rip = 0x805c62e4, rsp = 0xff852fe0, rbp = 0xf
f82b155d7b0 ---
callout_lock() at callout_lock+0x54
callout_reset_on() at callout_reset_on+0x43
tcp_do_segment() at tcp_do_segment+0x508
tcp_input() at tcp_input+0xd22
ip_input() at ip_input+0xad
netisr_dispatch_src() at netisr_dispatch_src+0x7e
ether_demux() at ether_demux+0x14d
ether_input() at ether_input+0x17b
ether_demux() at ether_demux+0x6f
ether_input() at ether_input+0x17b
bce_intr() at bce_intr+0x3b0
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x8e
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 ---

db bt 100038
Tracing pid 12 tid 100038 td 0xff00029a27c0
sched_switch() at sched_switch+0xea
mi_switch() at mi_switch+0x16f
ithread_loop() at ithread_loop+0x1d0
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 ---

db bt 100012
Tracing pid 12 tid 100012 td 0xff00026fc3e0
cpustop_handler() at cpustop_handler+0x40
ipi_nmi_handler() at ipi_nmi_handler+0x30
trap() at trap+0x175
nmi_calltrap() at nmi_calltrap+0x8
--- trap 0x13, rip = 0x808a8270, rsp = 0xff859fe0, rbp
= 0xff8c9bd0 ---
Xinvlpg() at Xinvlpg
ithread_loop() at ithread_loop+0x142
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8c9d30, rbp = 0 ---


-- 
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: panic in dummynet

[Luigi Rizzo]

On Thu, Mar 24, 2011 at 12:02:03PM +0300, Sergey Kandaurov wrote:
 On 21 March 2011 12:43, Sergey Kandaurov pluk...@gmail.com wrote:
  Hi.
 
  This is a 8.1 box, not very much loaded.
  It has two simple dummynet rules.
  That's the first time it panics there. Any hints?
 
  db x/s *panicstr
  0: ? ? ?*** error reading from address 0 ***
  db bt
  Tracing pid 0 tid 100116 td 0xff000ab057c0
  m_copym() at m_copym+0x37
  ip_fragment() at ip_fragment+0x132
  ip_output() at ip_output+0xeef
  dummynet_send() at dummynet_send+0x14c
  dummynet_task() at dummynet_task+0x1b7
  taskqueue_run() at taskqueue_run+0x93
  taskqueue_thread_loop() at taskqueue_thread_loop+0x46
  fork_exit() at fork_exit+0x118
  fork_trampoline() at fork_trampoline+0xe
  --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 ---
 
 
 Hmm.. Another crash today.
 Looks like it might be due to race with bce intr handler.

it is possible, but i wonder if this is a device-specific issue.

Otherwise this kind of race would be present in every machine using
dummynet -- all packets delayed by dummynet are sent out from the
taskqueue using the above path.

cheers
luigi

 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:0x80611587
 stack pointer   = 0x28:0xff82b41da960
 frame pointer   = 0x28:0xff82b41da9c0
 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 (dummynet)
 
 db bt
 Tracing pid 0 tid 100121 td 0xff00094177c0
 m_copym() at m_copym+0x37
 ip_fragment() at ip_fragment+0x132
 ip_output() at ip_output+0xeef
 dummynet_send() at dummynet_send+0x14c
 dummynet_task() at dummynet_task+0x1b7
 taskqueue_run() at taskqueue_run+0x93
 taskqueue_thread_loop() at taskqueue_thread_loop+0x46
 fork_exit() at fork_exit+0x118
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff82b41dad30, rbp = 0 ---
 
 cpuid= 0
 curthread= 0xff00094177c0: pid 0 dummynet
 cpuid= 1
 curthread= 0xff00029a23e0: pid 12 irq257: bce1
 cpuid= 2
 curthread= 0xff00026fc3e0: pid 12 swi4: clock
 
 100039   Run CPU 1   [irq257: bce1]
 100038   RunQ[irq256: bce0]
 100012   Run CPU 2   [swi4: clock]
 
 db bt 100039
 Tracing pid 12 tid 100039 td 0xff00029a23e0
 cpustop_handler() at cpustop_handler+0x40
 ipi_nmi_handler() at ipi_nmi_handler+0x30
 trap() at trap+0x175
 nmi_calltrap() at nmi_calltrap+0x8
 --- trap 0x13, rip = 0x805c62e4, rsp = 0xff852fe0, rbp = 
 0xf
 f82b155d7b0 ---
 callout_lock() at callout_lock+0x54
 callout_reset_on() at callout_reset_on+0x43
 tcp_do_segment() at tcp_do_segment+0x508
 tcp_input() at tcp_input+0xd22
 ip_input() at ip_input+0xad
 netisr_dispatch_src() at netisr_dispatch_src+0x7e
 ether_demux() at ether_demux+0x14d
 ether_input() at ether_input+0x17b
 ether_demux() at ether_demux+0x6f
 ether_input() at ether_input+0x17b
 bce_intr() at bce_intr+0x3b0
 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
 ithread_loop() at ithread_loop+0x8e
 fork_exit() at fork_exit+0x118
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 ---
 
 db bt 100038
 Tracing pid 12 tid 100038 td 0xff00029a27c0
 sched_switch() at sched_switch+0xea
 mi_switch() at mi_switch+0x16f
 ithread_loop() at ithread_loop+0x1d0
 fork_exit() at fork_exit+0x118
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 ---
 
 db bt 100012
 Tracing pid 12 tid 100012 td 0xff00026fc3e0
 cpustop_handler() at cpustop_handler+0x40
 ipi_nmi_handler() at ipi_nmi_handler+0x30
 trap() at trap+0x175
 nmi_calltrap() at nmi_calltrap+0x8
 --- trap 0x13, rip = 0x808a8270, rsp = 0xff859fe0, rbp
 = 0xff8c9bd0 ---
 Xinvlpg() at Xinvlpg
 ithread_loop() at ithread_loop+0x142
 fork_exit() at fork_exit+0x118
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff8c9d30, rbp = 0 ---
 
 
 -- 
 wbr,
 pluknet
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

panic in dummynet

[Sergey Kandaurov]

Hi.

This is a 8.1 box, not very much loaded.
It has two simple dummynet rules.
That's the first time it panics there. Any hints?

db x/s *panicstr
0:  *** error reading from address 0 ***
db bt
Tracing pid 0 tid 100116 td 0xff000ab057c0
m_copym() at m_copym+0x37
ip_fragment() at ip_fragment+0x132
ip_output() at ip_output+0xeef
dummynet_send() at dummynet_send+0x14c
dummynet_task() at dummynet_task+0x1b7
taskqueue_run() at taskqueue_run+0x93
taskqueue_thread_loop() at taskqueue_thread_loop+0x46
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 ---

-- 
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Kernel panic within dummynet-code(?)

[Sebastian Inacker]

Hello Ruslan.

On 2/23/06, Ruslan Ermilov [EMAIL PROTECTED] wrote:
  I got a kernel panic on FreeBSD 6.0-RELEASE, which is probably caused
  by a not initialised pointer p = (void *) 0x0 within the
  dummynet-code. [...]
 There were several dummynet(4) fixes in RELENG_6, try with them
 first.  One that can be responsible for what you're seeing was
 insufficient locking.

Thanks for your information. I'll try ip_dummynet.h 1.36.2.2 and
ip_dummynet.c 1.93.2.4 from cvs[1].

Unfortunately I will not know immediately, whether it helped or not -
so I can't give an instant it worked for the archive.

[1] For the archive: http://www.freebsd.org/cgi/cvsweb.cgi/
Path within cvs: src / sys / netinet

Sebastian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Kernel panic within dummynet-code(?)

[Sebastian Inacker]

Hello Networkers.

I got a kernel panic on FreeBSD 6.0-RELEASE, which is probably caused
by a not initialised pointer p = (void *) 0x0 within the
dummynet-code.

I analysed the crash dump and got

  (kgdb) f 9
  #9  0xc06d3670 in dummynet (unused=0x0) at ../../../netinet/ip_dummynet.c:785

  (kgdb) i loc
  p = (void *) 0x0
  h = (struct dn_heap *) 0x4
  heaps = {0xc093cf40, 0xc093cf60, 0xc093cf50}
  i = 22
  pe = (struct dn_pipe *) 0x4

(see backtrack[1] of the crash dump).

Some frames before I do have problems with subr_turnstile.c and
kern_mutex.c, which could be caused by a problem in dummynet - but I'm
not sure.

The machine does use dummynet (with DUMMYNET and HZ=1000) for
bandwidth management, but the problem - if it is within dummynet -
have to be a special case, because it crashes not as regulary as it
would do in other cases.

I'd be glad, if someone can help me.
I would be glad also if I could help to fix a maybe existing bug.

[1] To save bandwidth: The complete backtrack of that kernel panic is on
URL:http://www.inacker.de/data/freebsd-kgdb-debug4.txt, if that's
helpfull. Just ask for more informations if needed.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Kernel panic within dummynet-code(?)

[Ruslan Ermilov]

On Thu, Feb 23, 2006 at 11:07:06AM +0100, Sebastian Inacker wrote:
 Hello Networkers.
 
 I got a kernel panic on FreeBSD 6.0-RELEASE, which is probably caused
 by a not initialised pointer p = (void *) 0x0 within the
 dummynet-code.
 
 I analysed the crash dump and got
 
   (kgdb) f 9
   #9  0xc06d3670 in dummynet (unused=0x0) at 
 ../../../netinet/ip_dummynet.c:785
 
   (kgdb) i loc
   p = (void *) 0x0
   h = (struct dn_heap *) 0x4
   heaps = {0xc093cf40, 0xc093cf60, 0xc093cf50}
   i = 22
   pe = (struct dn_pipe *) 0x4
 
 (see backtrack[1] of the crash dump).
 
 Some frames before I do have problems with subr_turnstile.c and
 kern_mutex.c, which could be caused by a problem in dummynet - but I'm
 not sure.
 
 The machine does use dummynet (with DUMMYNET and HZ=1000) for
 bandwidth management, but the problem - if it is within dummynet -
 have to be a special case, because it crashes not as regulary as it
 would do in other cases.
 
 I'd be glad, if someone can help me.
 I would be glad also if I could help to fix a maybe existing bug.
 
There were several dummynet(4) fixes in RELENG_6, try with them
first.  One that can be responsible for what you're seeing was
insufficient locking.


Cheers,
-- 
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer


pgpUJ317IUsdQ.pgp
Description: PGP signature

4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC

[Yusuf Goolamabbas]

Hi, Similar to what Ceri describes in this message

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-stable

I have observed a 4.4-stable box panicing whenever bridging is turned
on. This was cvsup'ed today morning. I have other boxes cvsup'ed at
the same time except that they don't have dummynet/bridging configured
in them and they work pretty well

I replaced the box with an another 4.3-RC box and the same rules
enclosed here work just fine

${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass ARP
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
${fwcmd} add 500 pass all from ip_range to any in via fxp0
${fwcmd} add 800 pipe 1 ip from ip_range to any in via fxp1
${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50 

Basically, fxp1 is connected to a switch and every machine on that
switch is rate limited to 512Kbit/s individually

I had configured the box with DDB but didn't have serial console so I
transcribed everything at the db prompt

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa4
fault code= superviser read, page not present
instruction pointer = 0x8:0xc0199164
strack pointer  = 0x10:0xc9889b5c
frame pointer   = 0x10:0xc9889bac
code segment = base 0x0, limit 0xfff type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 55 (sh)
interrupt mask  =
kernel: type 12 trap, code = 0
stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax)

db t
in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158
arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112
swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next
trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe
trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f
calltrap() at calltrap+0x11
trap 0xc : eip  - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88
copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37
exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba
execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c
syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5
Xinit0x80_syscall() + Xint-x80_syscall+0x25

Hope this helps

Regards, Yusuf

-- 
Yusuf Goolamabbas
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message

Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC

[Luigi Rizzo]

On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
  
  How repeatable is the problem ? It shouldn't be hard to track, it looks
  like a null pointer dereference.
 
 100% repeatable. The strange part is that the same rules including the
 ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly
 with 4.3-RC

the rule is just useless. do you have a sample case to trigger the
problem so i can try and see what is going on ?

thanks
luigi
--+-
 Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
--+-

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message

Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC

[Yusuf Goolamabbas]

On Thu, Dec 20, 2001 at 11:08:14PM -0800, Luigi Rizzo wrote:
 On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
   
   How repeatable is the problem ? It shouldn't be hard to track, it looks
   like a null pointer dereference.
  
  100% repeatable. The strange part is that the same rules including the
  ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly
  with 4.3-RC
 
 the rule is just useless. do you have a sample case to trigger the
 problem so i can try and see what is going on ?
 

range and office are edited out

This is what I have, the basic idea is that fxp1 is connected to a
switch and I want each machine on the switch to be restricted to 512kb/s

${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass
ARP
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
${fwcmd} add 500 pass all from ${range} to any in via fxp0
${fwcmd} add 800 pipe 1 ip from ${range} to not ${office} in via fxp1
${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message