Date: Wed, 19 Nov 1997 15:13:47 -0800 From: Julian Elischer <julian@whistle.com> To: Jonathan Chen <jonc@pinnacle.co.nz> Cc: Doug White <dwhite@resnet.uoregon.edu>, Brian Somers <brian@awfulhak.org>, freebsd-questions@freebsd.org Subject: Re: Kernel panic in 2.2.2R with ppp Message-ID: <347372AB.2F1CF0FB@whistle.com> References: <Pine.SGI.3.96.971120093703.1777A-100000@tui.pinnacle.co.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jonc@pinnacle.co.nz> | "Vini, vidi, velcro... > | I came, I saw, I stuck around"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?347372AB.2F1CF0FB>