Date: Mon, 15 Dec 1997 07:59:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: pb@fasterix.freenix.org (Pierre Beyssac) Cc: tlambert@primenet.com, totii@est.is, pb@fasterix.freenix.org, freebsd-current@FreeBSD.ORG Subject: Re: panics when stopping pppd Message-ID: <199712150759.AAA28908@usr09.primenet.com> In-Reply-To: <19971214024134.PL39369@@> from "Pierre Beyssac" at Dec 14, 97 02:41:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> [ crash when disconnecting PPP ] > > If you have a local ethernet, look at the variables that exist on your > > stack to see if your local ethernet MAC address is there somewhere; > > this looks remarkably similar to a crash I saw, but have not yet been > > able to reproduce. > > I have a local ethernet, but apparently no MAC address on the stack > (I might have missed it though). > > On the other hand, I can reproduce the crash almost at will. > It happens only when I have dynamic routes _and_ they are removed > when PPP is down; if I stop gated before I stop PPP, there is no > crash at all even when gated routes are removed. It occurred to me (after I posted this) that the issue might actually be a copyout to the wrong address. This is especially likely with the "recieve the address in the recvfrom()" case. It may be that you will want to look at sleeps with timouts wating for interrupt wakeups. This seems a logical place for this type of problem to actually be occurring. > If I spray a few printf in the rtrequest code for RTM_DELETE to > figure out what happens, it doesn't crash anymore. There might be > a race condition somewhere. Or you might be sticking a process in core for long enough that the same stack is in place, or the same copyout() occurs, etc.. Not really a race condition, but it will behave like one. > rtrequest() appears to at least sometimes return with an error > before crashing, because in_ifadownkill managed to log the following > once (from strings vmcore | tail -100): > > <4>in_ifadownkill: error 3 > > The instruction pointer is 0x6e655000 every time I've been able to > see it: > > instruction pointer = 0x8:0x6e655000 Look at yuor ARP table' look for "6e65" in any of the addresses.. this is a bit suspiciously like a MAC addr. If it's the copyout(), it could be anywhere. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712150759.AAA28908>