Date: Thu, 5 Jun 1997 22:34:27 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: page fault Message-ID: <19970605223427.LN28350@uriah.heep.sax.de> In-Reply-To: <199706050940.MAA27014@shadows.aeon.net>; from mika ruohotie on Jun 5, 1997 12:40:12 %2B0300 References: <19970604174918.CS56609@uriah.heep.sax.de> <199706050940.MAA27014@shadows.aeon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
As mika ruohotie wrote: > > Be careful to not accidentally load this bloated kernel into > > memory. :) > > it's only about 9 mgs. why not? Because you're bloating physical memory with a symbol table you're never going to make _any_ use of. (DDB can't use the local symbols and various strings anyway.) It's not too hard to say ``strip -d /kernel'' before rebooting, is it? :) > > the same optimization level), but add -g. NB: you gotta replace the > > COPTS ?= line by an absolute one. Then, i remove the .o files i wanna > > force to rebuild, and just rebuild this part of the kernel. After > > this, you can usually analyze the stacktrace. > > hmm, but you still need to know which .o's you need to nuke, and for > a person without the internal knowledge it's hard to decide... It's not too hard. As long as you've got a basic clue to which subsystem (net, netinet, cd9660 etc.) the functions belong, you can just use grep. For all files which at least basically conform to style(9), the function names always start in column 1 (and now you know one reason why :), so if you look for functions foobar() and mumble(), in the netinet subsystem, say: grep -E '^(foobar|mumble)' /sys/netinet/*.c Also, now that we've got global(1) support in the tree, you should be able to use tags. > and wouldnt i fuck up the recompiling anyway if i've > cvsup:ed after i did the kernel? (i cvsup far more often than i > make worlds/kernels) Well, if you cvsup the source tree, yes. (I mirror the CVS tree, so i will only foobar the tree if i cvs update it.) > btw, last time my machine crashed on this: > #5 0xf0103e2c in cd9660_getattr (ap=0x0) > at ../../isofs/cd9660/cd9660_vnops.c:253 > > it doesnt list more. but, the thing got my eye is the fact i do _not_ > have cdrom attached, it's few miles from the machine currently. sure, > the kernel has support, but... is that suspicious? It looks suspicious regarding your hardware. If you never touched the cd9660 filesystem code (which would at least require a previous mount -t cd9660), this function should never be called. It's called in some VOP_GETATTR() macro, but of course, its argument pointer should never be zero. Also, the missing stack frame beyond this call might be an indication that something really stinks in your system. It's normal for the inlined vnode operations that they stomp a little on the stack backtrace, so you're often missing one function call when looking at it in the debugger, but it's not normal that you don't see anything in the upper layers. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970605223427.LN28350>