linux-kernel - Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <44E97353.76E4.0078.0@novell.com>
Date:	Mon, 21 Aug 2006 08:48:19 +0200
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	"Andi Kleen" <ak@...e.de>, <linux-kernel@...r.kernel.org>
Subject: Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"

>>> "J. Bruce Fields" <bfields@...ldses.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/