possible (kernel) bug with zebra
From: Roman Sidnev (sirok_at_mail.ru)
Date: 12/25/03
- Previous message: Dmitry Pryanishnikov: "Re: [SOLVED] RE: [Backtrace] 4.9 and 5.1-RELEASE occasionly panic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 26 Dec 2003 03:58:54 +0500 To: freebsd-stable@freebsd.org
Hello,
>I don't know if my machine has some hardware problem, but I've noticed this
>strange behavior with zebra 0.93b_7 on 4.9-STABLE.
I think it not hardware problem, i have same problem
with gre and tun(vtund) interfaces and quagga. Panics occurs sometimes
when interface state changes (up/down). Sometimes kernel dont panics, but
zebra (quagga) dies. I don't know any solution. I had the same problem
with 4.8-STABLE.
>The first problem is zebra's inconsistent(?) handling of routing information,
>especialy when it comes to point-to-point interfaces (like tun) and ones
>handled by ppp(8).
>When ppp shuts down a link, it first deletes all routes, including the
>route to the remote host. Then it downs the interface. Zebra gets confused
>about this, because it gets the RTM_DELETE messages, but not the RTM_DELADDR
>message it seems to expect. (Which happens if you just do ifconfig -alias,
>there is a RTM_DELETE and then RTM_DELADDR)
>As a result, the zebra's routing table becomes bogus and the advertised
>routes are not correct. To fix this for now, I've put a script to do a
>ifconfig -alias which is run from ppp.linkdown.
>So far so good, but the kernel starts to panic :/
>Attached are the results from two consecutive panics
>I can provide more information/do more tests if someone finds this
>interesting :) Any help is appreciated, of course
-- Best regards, Roman mailto:sirok@mail.ru _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
- Previous message: Dmitry Pryanishnikov: "Re: [SOLVED] RE: [Backtrace] 4.9 and 5.1-RELEASE occasionly panic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: 6.0BETA3 panic in ip_output (vlan/RIP related?)
... this occurs when an interface is removed while ... > IP multicast membership
is still present for multicast groups on the ... over when it stumbled over the invalid mutex
in the destroyed vlan. ... I have coredumps from both the panics if they will help at all,
... (freebsd-current) - Panics with if_bridge(4)
... I'm experiencing panics when configuring if_bridge interface on a debug ...
bridge0: bpf attached ... both from the INVARIANTS panic and from ... (freebsd-current) - Re: Fatal trap 12: page fault while in kernelmode(subr_turnstile.c) w/ trace
... ngctl -f /tmp/ngctl.cmd ... ifconfig ngeth0 link '00:bd:03:11:25:01'
... the panics, I wondered if it might be responsible/involved/something. ... >
interface attaching and detatching and I have not kept up with it.. ... (freebsd-current) - Re: Multicast problems
... The new code phases out the hack which this define refers to, which is to encode 24 bits of
an interface index in 0.0.0.0/8. ... I didn't roll a patch for Quagga as
it's not part of the base system. ... It is probably easier for the purposes of Quagga to use
the Linux-derived ip_mreqn extension to the IP_MULTICAST_IF ioctl for interface selection, as
ospf should be using a locally-scoped address -- although the MCAST_JOIN_GROUP ioctl is the one to use
if one needs to bind to an interface by index and be sure that it actually worked. ... (freebsd-current) - Re: Detecting process death for anycast named process monitoring
... process detect that process unexpectedly dying? ... we want to shut down the
interface ... which causes Quagga to inject the anycast route. ...
(Linux-Kernel)