kern/42030: panic when zebra works on detaching tun interface
tedm at toybox.placo.com
Thu Sep 18 21:50:08 PDT 2003
The following reply was made to PR kern/42030; it has been noted by GNATS.
From: "Ted Mittelstaedt" <tedm at toybox.placo.com>
To: "Pawel Malachowski" <pawmal-posting at freebsd.lublin.pl>
Cc: <freebsd-gnats-submit at FreeBSD.org>
Subject: RE: kern/42030: panic when zebra works on detaching tun interface
Date: Thu, 18 Sep 2003 21:42:52 -0700
OK, your right, I was being too simplistic.
It is a kernel problem - but only insofar that what the FreeBSD kernel
be doing is be smart enough to recognize that Zebra is doing something
wrong and make it dump core. Same with Linux - the Linux kernel
(which also panics with Zebra doing the same thing) should be doing
Basically your going about this backwards - your trying to get a FreeBSD
kernel hacker to fix FreeBSD and tell you exactly what the Zebra program
is doing wrong, so you can go to the Zebra people and the work of chasing
the bug is done for them. This is understandable given the total lack of
response of Kunihiro to fixing bugs in Zebra unless they are handed to
him on a silver platter. But morally, since Zebra makes both Linux and
FreeBSD kernels panic (totally different kernels, mind) when doing this,
the Zebra maintainer should be the one to do the work fixing the Zebra code
first, don't you think?
Setting aside that, even if a FreeBSD kernel hacker does look into this, the
result is not going to help you - the only thing that's going to happen is
the FreeBSD kernel won't panic anymore. But the Zebra program will
still be broken. Since the goal of most people is to get a working
it seems that the speedier way to this goal is to get the Zebra
(ie: Quagga) people to fix it. Then once they do, they can tell you exactly
what causes the panic - then you can write a nice little test code fragment
and retitle the PR something such as "FreeBSD kernel doesen't
handle this XYZ condition properly"
More information about the freebsd-bugs