[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a8748490707091519g3a0a098dx1e9188083c5a74b4@mail.gmail.com>
Date: Tue, 10 Jul 2007 00:19:54 +0200
From: "Jesper Juhl" <jesper.juhl@...il.com>
To: "Charles Shannon Hendrix" <shannon@...omaker.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: BUG: kernel crash report, odd...
On 10/07/07, Charles Shannon Hendrix <shannon@...omaker.com> wrote:
>
> A system I was using a few minutes ago dumped this to the syslog:
>
> Jul 9 17:50:38 daydream kernel: [76022.613000] BUG: unable to handle
> kernel NUL
> L pointer dereference at virtual address 00000010
> Jul 9 17:50:38 daydream kernel: [76022.613000] printing eip:
> Jul 9 17:50:38 daydream kernel: [76022.613000] c01ace66
> Jul 9 17:50:38 daydream kernel: [76022.613000] *pde = 00000000
> Jul 9 17:50:38 daydream kernel: [76022.613000] Oops: 0000 [#1]
>
>
> There was no other information either before or after.
>
> What I saw was my KDE desktop stopped responding to events.
>
> Machine didn't respond to power switch.
>
> Unfortunately, that's all I know.
>
> In the past when I had bugs like this, I got a fairly extensive kernel
> error message, but this time the above is the only thing I saw.
>
It does look a little short... probably the rest just didn't make it to disk...
> I have not had kernel bugs like this until I started running 2.6.20 on a
> new Kubuntu install.
>
> Same hardware, but Slackware and my own custom 2.6.19 kernel never
> crashed.
>
Different kernel source version, different configuration, probably
different compiler, Slackware doesn't patch the vanilla kernel - I
believe (k)ubuntu does. All in all that equals a significantly
different kernel binary you have been running in those two cases.
> Is there anything I can do, in case this happens again, to try and
> capture more information?
>
0. Make sure the kernels loglevel is set so that you get all messages.
1. Make sure syslog is setup to capture all kernel messages, both
errors, warnings, notices, debug messages etc.
2. If you can, check output of 'dmesg' instead of just what made it to syslog.
3. If you have a second PC, setup serial console or netconsole to
capture kernel messages on that second box. This can sometimes capture
messages that don't make it to disk.
4. Build a custom kernel with some (or all) of the debug options under
the Kernel Hacking menu enabled.
5. Even when the system hangs you may in some cases be able to get
some info (or just sync the disks and do a reboot) via magic sysrq.
--
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists