From owner-freebsd-questions Wed Nov 19 15:21:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA11512 for questions-outgoing; Wed, 19 Nov 1997 15:21:08 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11484 for ; Wed, 19 Nov 1997 15:21:00 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA25227; Wed, 19 Nov 1997 15:16:00 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd025224; Wed Nov 19 15:15:51 1997 Message-ID: <347372AB.2F1CF0FB@whistle.com> Date: Wed, 19 Nov 1997 15:13:47 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Jonathan Chen CC: Doug White , Brian Somers , freebsd-questions@freebsd.org Subject: Re: Kernel panic in 2.2.2R with ppp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Chen wrote: > > On Wed, 19 Nov 1997, Doug White wrote: > > > On Wed, 19 Nov 1997, Brian Somers wrote: > > > > > Seriously, as you already suspect, it can't really be ppp that's > > > causing the problem. I'd suspect a memory problem. Is the > > > instruction pointer the same each time ? If so, the only way to > > > diagnose this is to rebuild your kernel with symbols (-g), wait for > > > it to crash again, and try to find out where the instruction pointer > > > is pointing. > > > > Whihc of these should I be looking at? Using `nm /kernel | grep xxx', the > > fault virtual addr doesn't point to anything but the instruction pointer > > is in the middle of the msdosfs code. > > Hmm. That'd be because it's a custom kernel (with only 8Mb, one has to > take out as much as possible..). However, using the: > `nm /kernel | grep xxxx' > technique (I didn't know you could do that!) on the instruction pointer to > 6 significant characters, the sorted output is: > > f013d050 t _rn_walktree_from yes this is the bug I fixed in 2.2.5 > f013d15c t _rn_walktree > f013d1f4 T _rn_inithead > f013d308 T _rn_init > f013d3e0 F raw_cb.o > f013d3e0 T _raw_attach > f013d44c T _raw_detach > f013d48c T _raw_disconnect > f013d4b0 F raw_usrreq.o > f013d4b0 T _raw_init > f013d4cc T _raw_input > f013d624 T _raw_ctlinput > f013d634 T _raw_usrreq > f013d820 F route.o > f013d820 t _rtable_init > f013d860 T _route_init > f013d874 T _rtalloc > f013d8a4 T _rtalloc_ign > f013d8d4 T _rtalloc1 > f013da08 T _rtfree > f013daf8 T _ifafree > f013db28 T _rtredirect > f013dca0 T _rtioctl > f013dcb4 T _ifa_ifwithroute > f013dd80 T _rtrequest > > However, as Brian has pointed out, it may be a memory problem. I'll > have to wait for the next crash (a 2 month wait?) to see whether the > results are of any significance... > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > fault virtual address = 0xf057a000 > > > > > fault code = supervisor read, page not present > > > > > instruction pointer = 0x8:0xf013d087 > > > > > stack pointer = 0x10:0xefbffd80 > > > > > frame pointer = 0x10:0xefbffd9c > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > current process = 24356 (ppp) > > > > > interrupt mask = > > > > > panic: page fault > -- > Jonathan Chen | "Vini, vidi, velcro... > | I came, I saw, I stuck around"