On 04-Oct-2002 Juli Mallett wrote: > * De: Stefan Farfeleder <[EMAIL PROTECTED]> [ Data: 2002-10-04 ] > [ Subjecte: Re: Junior Kernel Hacker page updated... ] >> On Thu, Oct 03, 2002 at 04:41:46PM +0200, Poul-Henning Kamp wrote: >> > >> > Hi Stefan, >> > >> > I tried this patch and it paniced my (almost-) current machine with >> > a pagefault in the kqueue code: Bravo! >> > >> > I can see that there is some amount of #ifdef stuff in your patch, >> >> The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH. >> Is anybody using them? Building with -DREMOTE doesn't compile and with >> -DRMT_WILL_WATCH the linker is complaining about the lack of the >> functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of >> those defines? I understand Juli Mallett wants to rewrite make, so maybe >> this effort would be wasted. >> >> > in light of that, would it be possible to make an #ifdef'ed version >> > of your patch which we could commit ? >> >> Ok, the new patch is attached. Compile with -DUSE_KQUEUE to use the new >> code. >> >> > That way we give the kqueue hackers a good testcase, and we can >> > easily enable when they have solved the problem. >> >> After Don Lewis fixed the 'could sleep with' problem (thanks!), I'm >> still encountering freezes and panics. Here's one I caught: >> >> [warning: parts are typed in] >> %%% >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; lapic.id = 00000000 >> fault virtual address = 0x8 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc01a1212 >> stack pointer = 0x10:0xe5226c14 >> frame pointer = 0x10:0xe5226ca0 >> 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 = 56525 (make) >> >> kernel: type 12 trap, code = 0 >> >> Stopped at kqueue_scan+0x242: cmpl $0,0x8(%ebx) >> db> trace >> kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242 >> kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1 >> syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be >> %%% > > Run the kqueue source file through gcc with -fverbose-asm -S and then > look at the resulting .s file, grep for cmpl.*0x8( and look for > what's being dereferenced without being checked for NULL.
Even better, pop up gdb on kernel.debug and do 'l *kqueue_scan+0x242' to look at the offending line of code. addr2line can also be useful here similarly. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
