From owner-freebsd-questions Wed Nov 19 12:46:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24936 for questions-outgoing; Wed, 19 Nov 1997 12:46:20 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from mail.iconz.co.nz (mail.iconz.co.nz [202.14.100.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24916 for ; Wed, 19 Nov 1997 12:46:12 -0800 (PST) (envelope-from jonc@pinnacle.co.nz) Received: from news.iconz.co.nz (status.gen.nz [202.14.100.1]) by mail.iconz.co.nz (8.8.7/8.8.7) with ESMTP id JAA269900879972351; Thu, 20 Nov 1997 09:45:51 +1300 (NZDT) Received: (from uucp@localhost) by news.iconz.co.nz (8.8.5/8.8.5) with UUCP id JAA01347; Thu, 20 Nov 1997 09:45:51 +1300 Received: from tui.pinnacle.co.nz (tui.pinnacle.co.nz [202.37.163.3]) by kakapo.pinnacle.co.nz (8.8.8/8.8.7) with ESMTP id JAA06092; Thu, 20 Nov 1997 09:43:46 +1300 (NZDT) Received: from localhost (jonc@localhost) by tui.pinnacle.co.nz (8.8.8/8.8.8) with SMTP id JAA01788; Thu, 20 Nov 1997 09:43:46 +1300 (NZDT) X-Authentication-Warning: tui.pinnacle.co.nz: jonc owned process doing -bs Date: Thu, 20 Nov 1997 09:43:46 +1300 (NZDT) From: Jonathan Chen To: Doug White cc: Brian Somers , freebsd-questions@FreeBSD.ORG Subject: Re: Kernel panic in 2.2.2R with ppp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 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"