John Baldwin wrote: > > Panic #1: > > --- > > > > Is this a full backtrace? I don't see any way that the stack > > could have started with "trap_pfault"... it had to be running > > something to cause a page fault. > > It's a fault from userland perhaps.
Panic #3 was a fault in userland, and it showed the process in the stack backtrace. This one also isn't, because the 'usermode' argument to trap_pfault is 0. > > Panic #2: > > --- > >#9 0xc02607aa in generic_bcopy () > >#10 0xc0247c30 in scstart (tp=0xc0879b00) at ../../dev/syscons/syscons.c:1285 [ ... ] > generic_bcopy() is an asm function which may not have a full frame. > Thus, when gdb walks back over the stacktrace, it may skip the frame > that called generic_bcopy() and go to the previous frame. ddb sometimes > does a better job with backtraces for some reason. This is a good point. He should take a backtrace from ddb, at the time of the panic. There is still the little problem of the line numbers not matching the FreeBSD source code. If he can't provide at least a CVS timestamp to use to check out a source tree identical to his, I'm feeling pretty strongly that he's running with local modifications that he's not telling us about, and that these modifications are likely the source of his problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
