![]() | |||||||||||||
Messages in this thread |
>>> "J. Bruce Fields" <bfields@fieldses.org> 20.08.06 03:31 >>> >As of 2.6.18-rc3, one of my test machines stopped booting. I'm not >seeing the whole OOPS (I could probably set up a serial console if >necessary), but it ends in something like: > >trace_hardirqs_on >idesci_pc_intr >ide_intr >handle_IRQ_event >__do_IRQ >do_IRQ >common_interrupt >default_idle >apm_cpu_idle >cpu_idle >rest_init >start_kernel >0xc0100199 >DWARF2 unwinder stuck at 0xc0100199 >Leftover inexact backtrace: > ======================= > BUG: unable to handle kernel paging request at virtual address 0000b034 > printing eip: >c0103712 >*pde = 00000000 >Recursive die() failure, output suppressed > <0>Kernel panic - not syncing: Fatal exception in interrupt > >Bisecting, it looks like this starts happening after c97d20a..., >"[PATCH] i386: Do backtrace fallback too", though it's a little tricky >since the compile is broken near there for a little while. > >Kernel config appended; let me know if anything else would be useful. The 'stuck' unwinder issue at hand already has a fix, though planned to be merged for 2.6.19 only. The crash after switching to the legacy stack trace code is bad, though, but has little to do with the unwinder additions/changes. The way that code reads the stack is just inappropriate in contexts where things must be expected to be broken. Finally, there is no visible correlation between the original problem (in or from trace_hardirqs_on) and the unwinder - once that problem is fixed, you're not likely to see the recursive die failure anymore either. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-08-21 06:51 [W:0.497 / U:0.160 seconds] ©2003-2008 Jasper Spaans | |||||||||||||