Messages in this thread | | | Date | Wed, 9 Mar 2022 01:08:17 +0000 | From | "Russell King (Oracle)" <> | Subject | Re: boot flooded with unwind: Index not found |
| |
On Wed, Mar 09, 2022 at 12:01:26AM +0000, Russell King (Oracle) wrote: > To reinterate what I've just put on IRC - we have not got to the bottom > of this problem yet - it still very much exists. > > There seems to be something of a fundamental issue with the unwinder, > it now appears to be going wrong and failing to unwind beyond a > couple of functions, and the address it's coming out with appears to > be incorrect. I've only just discovered this because I created my very > own bug, and yet again, the timing sucks with the proximity of the > merge window. > > I'm getting: > > [ 13.198803] [<c0017728>] (unwind_backtrace) from [<c0012828>] (show_stack+0x10/0x14) > [ 13.198820] [<c0012828>] (show_stack) from [<c2be78d4>] (0xc2be78d4) > > for the WARN_ON() stacktrace, and that address that apparently called > show_stack() is most definitely rubbish and incorrect. This makes any > WARN_ON() condition undebuggable. > > This is with both 9183/1 and 9184/1 applied on top of pulling your > "arm-ftrace-for-rmk" tag and also with just the "arm-vmap-stacks-v6" > tag. This seems to point at one of these patches breaking the > unwinder: > > a1c510d0adc6 ARM: implement support for vmap'ed stacks > 532319b9c418 ARM: unwind: disregard unwind info before stack frame is set up
The above commit appears to be what's breaking the unwinder. Without this I get sane stacktraces. With it, the unwinder spits out stupid function addresses.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |