Forgot a few things, see below...
On 10/07/07, Jesper Juhl <[email protected]> wrote:
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.
A different userspace could also be the cause. In theory, userspace
should never be able to crash the kernel, but in real life bugs happen
and sometimes userspace manages to cause a kernel crash. So, a
different userspace environment in your new distribution could in
theory expose a bug that didn't surface with your previous
distribution.
> 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.
0.5. Perhaps increase the size of the kernels log buffer (the
LOG_BUF_SHIFT config option)
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]
