[lkml]   [2007]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2/3] 2.6.22-rc2: known regressions v2
Ingo Molnar wrote:

>A BUG_ON() has a (much) lower likelyhood of being reported back - for
>most users it is a "X just hung hard, there was nothing in the syslog, i
>had to switch back to the older kernel" experience, and they do not have
>a serial console to hook up (newer hardware often doesnt even have a
>serial port). With the WARN_ON()s we have a _chance_ that despite the
>seriousness of the bug, the message makes it to the syslog, until the
>system comes to a screeching halt due to side-effects of the bug.
>in that sense i am part of the problem: i was adding WARN_ON()s that
>werent true 'warnings' but 'bugs'. So i'd very much like to fix that
>problem, but i'd also like to solve the (very serious and existing)
>problem of BUG_ON()s making it less likely to get bugs reported back.
There is a fundamental problem in getting a decent log to debug a
crashed kernel. Maybe we should take a hint from Solaris.
If the kernel crashes Solaris dumps core to swap and sets a flag.
At the next boot this image is copied to /var/adm/crashdump where
it is preserved for future debugging. Obviously swap needs to be
larger than core, but this is usually the case.

On Sun machines this is fairly easy because the dump can be
performed by the OBP, on other architectures it may be more
difficult to still have enough working kernel to achieve the dump
after a kernel panic.

Just a thought .......

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-05-25 14:29    [W:0.133 / U:0.464 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site