DragonFlyBSD

On 13.03.2006, at 10:43, Francis Gudin wrote:

i posted this as a blog entry on GoBSD.com because of the lack of
useful
details to build a bug-report. I still think this is a bug (a badly
configured userland program leads to a kernel panic):
http://gobsd.com/node/225

could you please post such things nevertheless on the mailing lists,
even if just for archiving purposes.

thanks
simon

On 13-03-2006, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:

could you please post such things nevertheless on the mailing lists,=20
even if just for archiving purposes.

thanks
simon

Yep, here's a wild snarf/paste from gobsd:

I worked around an annoying bug this morning by cleaning up my ppp.conf.
As my only storage is ips, i can't provide any dump; hence, i decided to
post this here instead of bothering the developpers with an almost
useless bug-report. It's a bit of a reminder, and i also wish it could
avoid a nervous breakdown to anyone facing the same problem, maybe. Now
the story:

My system is a dual-cpu, DragonFly 1.5.1 and i use userland ppp in PPPoE
mode. When booting from my -DEVELOPMENT slice, i regularly experimented
panics (something like 1 out of 20 boots) and inconsistencies with the
route tables (default route entries missing because ppp couldn't "add
default HISADDR"). Until now, i just did this on startup:route delete
default && route add default -interface tun0
This morning, i decided to have a look closer at this issue. The problem
was that in single-user mode, panic'ing was 1/1 ! If this may help,
here's a transcript:
#/etc/rc.d/ppp-user start
Starting ppp as "root"
Warning: Add! route failed: ff02:: errno: Operation not supported
Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
Note: panic took place two seconds after the shell prompted again.
db> trace
Debugger(c02cc075) at Debugger+0x3d
panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
lwkt_exit() at lkwt_exit

At complete random, i had a look at ppp(8) and found my set ifaddr line
quite wrong:
set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
After fixing that to:
set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
i no longer see panics, even in the 100% reproductible case (single-user
mode), and my route tables are ok. ppp properly adds default routes (i
have a native ipv6 link, thanks Nerim!), though it still warns about the
"ff02::" route entry, which i'll investigate later on.

If anyone really want it thoroughly debugged, i can provide informations
with kgdb instead of a dump, just let me know.

Francis.

:...
:#/etc/rc.d/ppp-user start
:Starting ppp as "root"
:Warning: Add! route failed: ff02:: errno: Operation not supported
:Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
:#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
:Note: panic took place two seconds after the shell prompted again.
:db> trace
:Debugger(c02cc075) at Debugger+0x3d
:panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
:rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
:rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
:lwkt_exit() at lkwt_exit
:
:At complete random, i had a look at ppp(8) and found my set ifaddr line
:quite wrong:
:set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
:After fixing that to:
:set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
:i no longer see panics, even in the 100% reproductible case (single-user
:mode), and my route tables are ok. ppp properly adds default routes (i
:have a native ipv6 link, thanks Nerim!), though it still warns about the
:"ff02::" route entry, which i'll investigate later on.
:
:If anyone really want it thoroughly debugged, i can provide informations
:with kgdb instead of a dump, just let me know.
:
:Francis.

This is going to be hard to find without a dump.  I know there are 
    definitely issues related to the default route and also issues with IPV6.

That particular panic occurs if a route table request succeeds on cpu #0
    but then fails on cpu #1's route table, indicating a synchronization 
    issue between the replicated route tables.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On 3/13/06, Matthew Dillon <dillon@apollo.backplane.com> wrote:

:...
:#/etc/rc.d/ppp-user start
:Starting ppp as "root"
:Warning: Add! route failed: ff02:: errno: Operation not supported
:Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
:#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
:Note: panic took place two seconds after the shell prompted again.
:db> trace
:Debugger(c02cc075) at Debugger+0x3d
:panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
:rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
:rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
:lwkt_exit() at lkwt_exit
:
:At complete random, i had a look at ppp(8) and found my set ifaddr line
:quite wrong:
:set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
:After fixing that to:
:set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
:i no longer see panics, even in the 100% reproductible case (single-user
:mode), and my route tables are ok. ppp properly adds default routes (i
:have a native ipv6 link, thanks Nerim!), though it still warns about the
:"ff02::" route entry, which i'll investigate later on.
:
:If anyone really want it thoroughly debugged, i can provide informations
:with kgdb instead of a dump, just let me know.
:
:Francis.

This is going to be hard to find without a dump. I know there are
definitely issues related to the default route and also issues with IPV6.

That particular panic occurs if a route table request succeeds on cpu #0
but then fails on cpu #1's route table, indicating a synchronization
issue between the replicated route tables.

-Matt

On my machine I can trigger a panic just like this by doing `sh
/etc/rc` on a machine that is already booted and has ifconfig
information in /etc/rc.conf.

-DR