Re: kernel NULL pointer
On Tue, Apr 17, 2001 at 12:20:58PM -0700, Karsten M. Self wrote:
> on Tue, Apr 17, 2001 at 12:38:17AM +0200, David Jardine (jardine@tesionmail.de) wrote:
> > Following a re-compilation of my kernel (2.0.36) pon is
> > behaving erratically, to say the least. After a reboot
> > it works quite often the first time, less often the
> > second, rarely the third... and once it's failed, it
> > always fails after that.
> >
> > When it fails, it spews out a couple of screenfuls of
> > something too fast to capture and then hangs - sometimes
> > ^C kills it, sometimes ^D, sometimes I have to reboot.
> >
> > The straces of failed and successful connections seem
> > identical (except for pids and times, of course).
> >
> > This is the syslog account (the same every time, I think):
> >
> > Apr 17 00:17:07 gennes kernel: Unable to handle kernel NULL pointer dereference at virtual address c0000000
> > Apr 17 00:17:07 gennes kernel: current->tss.cr3 = 00101000, %cr3 = 00101000
> > Apr 17 00:17:07 gennes kernel: *pde = 00102067
> > Apr 17 00:17:07 gennes kernel: *pte = 00000000
> > Apr 17 00:17:07 gennes kernel: Oops: 0000
> > Apr 17 00:17:07 gennes kernel: CPU: 0
> > Apr 17 00:17:07 gennes kerneld: error: exit: Identifier removed
> >
> > If anyone recognizes the symptoms, I'd be most grateful
> > for pointers in the direction of a solution.
>
> It's a bug ;-)
Don't kid me. I can bring the stablest of systems crashing
round my ears by sheer stupidity.
Anyway, I'm ashamed to say that I've decided to try potato again.
(Ashamed because of the trouble you took to help me, for which
many thanks.)
May I ask one more stupid question? I don't understand the
exact connection between kernel versions and distribution
versions. I tried to upgrade from slink to potato but found
that the one thing I really needed (jdk) had been replaced by
something else (jikes and kaffe) that I couldn't get working.
Will I have problems if I try to install the stuff from my
slink CDs on my potato system?
Thanks
>
> Sounds like you're getting a few oopses before the system dies entirely.
>
> You'll want to roll through your kernel and debug logs to see what else
> is going, as well as capture some additional information. There's a
> guide to reporting kernel-level information in
> /usr/src/linux/REPORTING-BUGS. I've converted this to a self-generating
> report as a shell script, attached.
>
> You're going to want a couple of utilities on your search path which may
> not be there, ksymoops is the biggie. Note also that you can grab
> kernel debugging info from several places. If the system locks or
> crashes immediately after the event, /var/log/kern.log is going to do
> you more good than dmesg, which is regenerated on boot and won't have
> much interesting data in it.
>
> If you can get this to trigger automatically (say, with swatch -- don't
> ask me, I haven't done this but think it can be done), you might
> actually catch system state following one of the oopses.
>
> Hunting through Google or newsgroup archives is probably a good attack
> strategy.
>
> Cheers.
>
> --
> Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
> What part of "Gestalt" don't you understand? There is no K5 cabal
> http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
> #!/bin/bash
>
> # Kernel bug report generator script
> # Script generated from prior bug report form by Karsten M. Self
> # $Revision: 1.3 $ $Date: 2000/05/13 07:48:36 $ $Author: root $
>
>
> # ------------------------------------------------------------------------
> # [Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
> #
> # What follows is a suggested procedure for reporting Linux bugs. You
> # aren't obliged to use the bug reporting format, it is provided as a guide
> # to the kind of information that can be useful to developers - no more.
> #
> # If the failure includes an "OOPS:" type message in your log or on
> # screen please read "Documentation/oops-tracing.txt" before posting your
> # bug report. This explains what you should do with the "Oops" information
> # to make it useful to the recipient.
> #
> # Send the output the maintainer of the kernel area that seems to
> # be involved with the problem. Don't worry too much about getting the
> # wrong person. If you are unsure send it to the person responsible for the
> # code relevant to what you were doing. If it occurs repeatably try and
> # describe how to recreate it. That is worth even more than the oops itself.
> # The list of maintainers is in the MAINTAINERS file in this directory.
> #
> # If you are totally stumped as to whom to send the report, send it to
> # linux-kernel@vger.rutgers.edu. (For more information on the linux-kernel
> # mailing list see http://www.tux.org/lkml/).
> #
> # This is a suggested format for a bug report sent to the Linux kernel mailing
> # list. Having a standardized bug report form makes it easier for you not to
> # overlook things, and easier for the developers to find the pieces of
> # information they're really interested in. Don't feel you have to follow it.
> #
> # First run the ver_linux script included as scripts/ver_linux or
> # at <URL:ftp://ftp.sai.msu.su/pub/Linux/ver_linux> It checks out
> # the version of some important subsystems. Run it with the command
> # "sh scripts/ver_linux"
> #
> # Use that information to fill in all fields of the bug report form, and
> # post it to the mailing list with a subject of "PROBLEM: <one line
> # summary from [1.]>" for easy identification by the developers
> # ------------------------------------------------------------------------
>
> # indent by one tabstop
> function tabout () { sed -e '/^/s// /'; }
>
> kversion=$( uname -r )
> dmesg=dmesg
> dmesg="cat /var/log/kern.log" # for debugging only
> oops_number=$( $dmesg | grep Oops | tail -1 | sed -e '/^.*:/s///' )
> oops_module=$( $dmesg | grep EIP | tail -1 | sed -e '/^.*:/s///' )
>
> cat <<EOF
>
> This is a script-generated kernel bug report.
>
> The system administrator/developer should provide additional information
> where appropriate.
>
> kernel-bug-report: $Revision: 1.3 $ $Date: 2000/05/13 07:48:36 $ $Author: root $
>
> [1.] One line summary of the problem:
>
> PROBLEM: $1 oops $oops_number in $oops_module, $kversion kernel
>
> [2.] Full description of the problem/report:
>
> n/a
>
> [3.] Keywords (i.e., modules, networking, kernel):
>
> linux kernel $kversion oops $oops_number $oops_module
>
> [4.] Kernel version (from /proc/version):
>
> $( cat /proc/version | tabout )
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
>
> $( $dmesg | ksymoops -k /proc/ksyms | tabout )
>
> [6.] A small shell script or example program which triggers the
> problem (if possible)
>
> n/a
>
> [7.] Environment
>
> $( set | tabout )
>
> [7.1.] Software (add the output of the ver_linux script here)
>
> $( sh -f /usr/src/linux/scripts/ver_linux | tabout )
>
> [7.2.] Processor information (from /proc/cpuinfo):
>
> $( cat /proc/cpuinfo | tabout )
>
> [7.3.] Module information (from /proc/modules):
>
> $( cat /proc/modules | tabout )
>
> [7.4.] SCSI information (from /proc/scsi/scsi)
>
> $( cat /proc/scsi/scsi | tabout )
>
> [7.5.] Other information that might be relevant to the problem
> (please look in /proc and include all information that you
> think to be relevant):
>
> System memory (at time of oops):
> $( cat /proc/meminfo | tabout )
>
> System uptime:
> $( uptime | tabout )
>
> [X.] Other notes, patches, fixes, workarounds:
> EOF
>
Reply to: