Pete Zaitcev ([info]zaitcev) wrote,
@ 2008-04-19 12:18:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:linux

Random dmesg errors

I always was against kernel spewing user-generated errors into dmesg, like this:

npviewer.bin[4393]: segfault at f6712030 ip 67e7a0 sp ff9c39ec error 4 in libpthread-2.8.so[677000+15000]

Not helpful, not interesting.

However, the other day my desktop keeled over in a strange way... The /var/log/messages contained this (followed by a stack trace):

Apr 13 18:19:14 niphredil kernel: Xorg: page allocation failure. order:3, mode:0x4020

It looks like a bug in SLUB (does not seem registering with anyone who has the power to track it down though). But my point is, without the printout I would need to find what was happening by other means, and that would probably take forever.

Hmm... My world is shaken.

P.S. kgdb was merged into 2.6.26. The sky is falling.



(Post a new comment)


[info]deviant_
2008-04-19 07:43 pm UTC (link)
Seriously, for early userland work the segfault kernel message is one of the most useful debugging tools I have.

(Reply to this)(Thread)


[info]sneakums
2008-04-20 01:27 am UTC (link)
Plus there's the kernel.print-fatal-signals sysctl. Registerlicious!

(Reply to this)(Parent)


[info]ninjaseg
2008-04-19 08:18 pm UTC (link)
To a paranoid server admin, any segfault is likely an active hacking attempt (stack smash), or an opening for one in the future. Thus such people want them logged system wide.

(Reply to this)


(Anonymous)
2008-04-24 10:23 pm UTC (link)
Moved from 2.6.25-rc9 to 2.6.25 four days ago and immediately started seeing page allocation failures similar to yours. So far, 20 have appeared within that 4 day period. The machine appears to be stable though, so I'm not sure if the messages indicate a serious problem or what. Here's a couple just for reference:

j-e: page allocation failure. order:3, mode:0x4020
Pid: 13565, comm: j-e Not tainted 2.6.25.20080420 #1
..
swapper: page allocation failure. order:3, mode:0x4020
Pid: 0, comm: swapper Not tainted 2.6.25.20080420 #1

Now my 2.6.25-rc9 .config was very similar to my 2.6.25 one. I'm using the default allocator, SLUB, in both. About the only real change I do see is that the i/o scheduler changed from anticipatory to cfq, but I don't think that had anything to do with this issue.

So I left wondering what was introduced since rc9 that is causing this.
robh@rut.org

(Reply to this)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…