On Thursday 03 November 2005 12:40 am, Victor Snezhko wrote: > Vladimir Kushnir <vkushnir_at_i.kiev.ua> writes: > > On Thu, 3 Nov 2005, Max Laier wrote: > >>> Here it is: right before panic it prints > >>> > >>> For 0xffffff0017531100 -1 ticks > >>> For 0xffffff0017531100 -1 ticks > >> > >> This results in two consecutive callout_stop() calls, but shouldn't hurt > >> as callout_stop is protected against that. > >> > >> Do you get a dump for this? Can you compare this pointer to the global > >> llinfo_nd6 and see if "c" from the softclock() frame is related (or > >> maybe the previous item in the list TAILQ). > > > > Sorry I'm not very goot at debugging. Would you please give me some > > instructions (lamer's level, preferably :-)). And anyway I'll be able > > to do it tomorrow only. > > In the meantime, I want to debug this too. I would insert a panic() > call somewhere in the beginning of nd6_llinfo_settimer(), but there is > a problem. nd6_llinfo_settimer() is called not only when I start ppp, > but at bootup too (at bootup - once, I think that this is due to > initializing lo0 interface, which has a default ipv6 address). Could I > somehow make the kernel not panic at boot time and panic later, when I > call ppp? You can either add a sysctl that starts off as 0 and only panic if the sysctl is 1. You can then boot, change the sysctl to 1, and then run ppp. Alternatively, you could use kdb_enter() to enter the debugger instead of panic(). You could then just continue using 'c' when you drop into ddb during boot. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Thu Nov 03 2005 - 13:50:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC