Re: BUG: kernel crash report, odd...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/07/07, Charles Shannon Hendrix <[email protected]> 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 <[email protected]>
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux