[lkml]   [2007]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG: kernel crash report, odd...
On 10/07/07, Charles Shannon Hendrix <> 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 <>
Don't top-post
Plain text mails only, please
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-10 00:23    [W:0.041 / U:2.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site