Date: Tue, 22 Oct 2002 15:53:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Diego Wentz Antunes <devlware@terra.com.br> Cc: hackers@FreeBSD.org Subject: Re: Kernel Panic Problems Message-ID: <3DB5D6FB.BCE4051A@mindspring.com> References: <XFMail.20021022094654.jhb@FreeBSD.org> <3DB5A201.BF8B34C1@mindspring.com> <3DB5BA49.40908@terra.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Diego Wentz Antunes wrote: > No Terry there are no modifications from me to local files. I realy > don't know why the information is incomplete > but I didn't make any modifications. The incompleteness is because you didn't do a backtrace in ddb at the time of the crash, and only did it in gdb on the system dump image; as John explained, gdb sometimes messes up stack frames for assembly functions, and leaves information out. The reason I suggested that there would be modifications is totally different. The reason is that the line numbers of the source files for the backtrace do not match the correct function names in 4.4, 4.6, and -current source code. This doesn't necessarily mean your code has local modifications. But it does mean that you aren't giving us enough information to be able to properly anayze the backtrace, because you haven't given us enough information so that the source code we can look at is the same as your source code. We don't know if you are running a -RELEASE version, and, if you are, *which* version you are running. You never told us. > Its possible that a memory problem cause this errors? It's possible, but unlikely, if the errors didn't happen before, and they are happening now. Have you had a lightning storm, are you overclocking, or has an atomic weapon gone off nearby? 8-). If the answer is "no", then the MTBF for solid state devices that have survived burn-in is pretty much longer than man has been on the planet. > Again, last > night the computer stop running 3 times without > an apparent cause. This afternoon the first time a turnned on the > computer it panics again with a fatal trap 12. I'll try > to change this memory just to eliminate the possibility of hardware > problem then if it continues i'll do a hard study on > gdb and try to find some info. > Could you provide some good source of information to gdb? There's an O'Reilly book; most gdb references aren't very useful (IMO). In practice, it's better to know how the problem *could* happen, then to try to back track from when it *did* happen. This means that the most important thing you can do is get the problem to be repeatable. It would also help if you were to look at the source code where the problem starts happening; without your source code, we can only give you an educated guess as to the problem, based on what we think the source code should be. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB5D6FB.BCE4051A>