Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 30 Sept 2021 at 12:34, abhijeet inamdar
wrote:
> Actually the ELF generates the .bin file which is being used to run on the
> target (hardware). It's address starts from zero when I see the starting
> frames of it. As follows:
>
> IN:
> 0x0002: c0de stm r0!, {r1, r2, r3, r4, r6, r7}
> 0x0004: 0003 movs r3, r0
> 0x0006: movs r0, r0
> 0x0008: 0001 movs r1, r0
> 0x000a: movs r0, r0
> 0x000c: 0002 movs r2, r0
> 0x000e: movs r0, r0
> 0x0010: 0168 lsls r0, r5, #5
> 0x0012: movs r0, r0
> 0x0014: 5838 ldr r0, [r7, r0]
This clearly isn't code; it's some kind of data. It's not
a vector table, because it starts
0xc0de
0x0003
0x0001
0x0002
0x0168
and those aren't plausible looking addresses.
The guest CPU loads the reset SP and PC. The reset PC
is 0x0003, so we start at address 0x0002 in Thumb
mode. The data at that address is not a sensible instruction
(it's that "stm r0!..."), but we execute it. r0 is 0, so this
is going to store new random data all over the existing
data that we were incorrectly executing. The inevitable
result is that we take an exception, and this time the
vector table is full of zeros, so now we try to execute
from 0x0 in non-Thumb mode, which means we take another exception,
which is Lockup.
The solution remains the same: you need to load a guest
image which puts a valid vector table in guest memory
at the address where the CPU expects it (which looks like
0x0 in this case). Until you do this, your guest code
will crash in mysterious-looking ways because you are
not running what you think you are running.
-- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> 0x70849406: 4c 8d 05 66 fd ff ff leaq -0x29a(%rip), %r8 > 0x7084940d: 41 50pushq%r8 > 0x7084940f: ff 25 db 00 00 00jmpq *0xdb(%rip) > 0x70849415: 48 8b fd movq %rbp, %rdi > 0x70849418: 41 8b d5 movl %r13d, %edx > 0x7084941b: b9 21 00 00 00 movl $0x21, %ecx > 0x70849420: 4c 8d 05 81 fd ff ff leaq -0x27f(%rip), %r8 > 0x70849427: 41 50pushq%r8 > 0x70849429: ff 25 c1 00 00 00jmpq *0xc1(%rip) > 0x7084942f: 48 8b fd movq %rbp, %rdi > 0x70849432: 41 8b d5 movl %r13d, %edx > 0x70849435: b9 21 00 00 00 movl $0x21, %ecx > 0x7084943a: 4c 8d 05 9c fd ff ff leaq -0x264(%rip), %r8 > 0x70849441: 41 50pushq%r8 > 0x70849443: ff 25 a7 00 00 00jmpq *0xa7(%rip) > 0x70849449: 48 8b fd movq %rbp, %rdi > 0x7084944c: 41 8b d5 movl %r13d, %edx > 0x7084944f: b9 21 00 00 00 movl $0x21, %ecx > 0x70849454: 4c 8d 05 b7 fd ff ff leaq -0x249(%rip), %r8 > 0x7084945b: 41 50pushq%r8 > 0x7084945d: ff 25 8d 00 00 00jmpq *0x8d(%rip) > 0x70849463: 48 8b fd movq %rbp, %rdi > 0x70849466: 41 8b d6 movl %r14d, %edx > 0x70849469: b9 21 00 00 00 movl $0x21, %ecx > 0x7084946e: 4c 8d 05 d2 fd ff ff leaq -0x22e(%rip), %r8 > 0x70849475: 41 50pushq%r8 > 0x70849477: ff 25 73 00 00 00jmpq *0x73(%rip) > 0x7084947d: 48 8b fd movq %rbp, %rdi > 0x70849480: ba 21 00 00 00 movl $0x21, %edx > 0x70849485: 48 8d 0d 28 fe ff ff leaq -0x1d8(%rip), %rcx > 0x7084948c: ff 15 76 00 00 00callq*0x76(%rip) > 0x70849492: 44 8b f0 movl %eax, %r14d > 0x70849495: e9 1a fe ff ff jmp 0x708492b4 > 0x7084949a: 48 8b fd movq %rbp, %rdi > 0x7084949d: ba 21 00 00 00 movl $0x21, %edx > 0x708494a2: 48 8d 0d 5b fe ff ff leaq -0x1a5(%rip), %rcx > 0x708494a9: ff 15 59 00 00 00callq*0x59(%rip) > 0x708494af: 44 8b f8 movl %eax, %r15d > 0x708494b2: e9 4d fe ff ff jmp 0x70849304 > 0x708494b7: 48 8b fd movq %rbp, %rdi > 0x708494ba: ba 01 00 00 00 movl $1, %edx > 0x708494bf: 48 8d 0d c1 fe ff ff leaq -0x13f(%rip), %rcx > 0x708494c6: ff 15 2c 00 00 00callq*0x2c(%rip) > 0x708494cc: 8b d8movl %eax, %ebx > 0x708494ce: e9 b4 fe ff ff jmp 0x70849387 > 0x708494d3: 48 8b fd movq %rbp, %rdi > 0x708494d6: ba 01 00 00 00 movl $1, %edx > 0x708494db: 48 8d 0d d2 fe ff ff leaq -0x12e(%rip), %rcx > 0x708494e2: ff 15 10 00 00 00callq*0x10(%rip) > 0x708494e8: 8b d8movl %eax, %ebx > 0x708494ea: e9 c5 fe ff ff jmp 0x708493b4 > 0x708494ef: 90 nop > 0x708494f0: .quad 0x558bd6fd > 0x708494f8: .quad 0x558bc898 > 0x70849500: .quad 0x55a70e01 > 0x70849508: .quad 0x558bca00 > > > IN: > 0x: andeqr0, r0, r0 > > OUT: [size=64] > 0x70849640: 8b 5d f0 movl -0x10(%rbp), %ebx > 0x70849643: 85 dbtestl%ebx, %ebx > 0x70849645: 0f 8c 1f 00 00 00jl 0x7084966a > 0x7084964b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) > 0x70849652: 48 8b fd movq %rbp, %rdi > 0x70849655: be 12 00 00 00 movl $0x12, %esi > 0x7084965a: ba 00 00 00 02 movl $0x200, %edx > 0x7084965f: b9 01 00 00 00 movl $1, %ecx > 0x70849664: ff 15 0e 00 00 00callq*0xe(%rip) > 0x7084966a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax > 0x70849671: e9 a2 f9 ff ff jmp 0x70849018 > 0x70849676: 90 nop > 0x70849677: 90 nop > 0x70849678: .quad 0x55a70e01 > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00= R01=ff5d R02=0018 R03=0018 > R04=c0dec314 R05=ff49 R06= R07=0048 > R08= R09= R10= R11= > R12= R13=c0dec0b8 R14=fff9 R15= > XPSR=8003 N--- A handler > FPSCR: > > Thank you, > Abhijeet. > > On Thu, Sep 30, 2021, 10:57 Peter Maydell > wrote: > >> On Thu, 30 Sept 2021 at 07:17, abhijeet inamdar >> wrote: >> > >> > But this very ELF file runs on the target(real hardware) perfectly. So >> how different should it be to emulate? >> >> Real hardware doesn't have a magic ELF file loader. The >> details of what a debug environment or whatever mechanism >> you're using to put the ELF file on the target or an >> emulator expect from an ELF file vary. QEMU wants you to >> provide a vector table. (I imagine that the mechanism you're >> using with the real hardware starts execution at the ELF >> entry point.) >> >> -- PMM >> >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
jmpq *0x8d(%rip) 0x70849463: 48 8b fd movq %rbp, %rdi 0x70849466: 41 8b d6 movl %r14d, %edx 0x70849469: b9 21 00 00 00 movl $0x21, %ecx 0x7084946e: 4c 8d 05 d2 fd ff ff leaq -0x22e(%rip), %r8 0x70849475: 41 50pushq%r8 0x70849477: ff 25 73 00 00 00jmpq *0x73(%rip) 0x7084947d: 48 8b fd movq %rbp, %rdi 0x70849480: ba 21 00 00 00 movl $0x21, %edx 0x70849485: 48 8d 0d 28 fe ff ff leaq -0x1d8(%rip), %rcx 0x7084948c: ff 15 76 00 00 00callq*0x76(%rip) 0x70849492: 44 8b f0 movl %eax, %r14d 0x70849495: e9 1a fe ff ff jmp 0x708492b4 0x7084949a: 48 8b fd movq %rbp, %rdi 0x7084949d: ba 21 00 00 00 movl $0x21, %edx 0x708494a2: 48 8d 0d 5b fe ff ff leaq -0x1a5(%rip), %rcx 0x708494a9: ff 15 59 00 00 00callq*0x59(%rip) 0x708494af: 44 8b f8 movl %eax, %r15d 0x708494b2: e9 4d fe ff ff jmp 0x70849304 0x708494b7: 48 8b fd movq %rbp, %rdi 0x708494ba: ba 01 00 00 00 movl $1, %edx 0x708494bf: 48 8d 0d c1 fe ff ff leaq -0x13f(%rip), %rcx 0x708494c6: ff 15 2c 00 00 00callq*0x2c(%rip) 0x708494cc: 8b d8movl %eax, %ebx 0x708494ce: e9 b4 fe ff ff jmp 0x70849387 0x708494d3: 48 8b fd movq %rbp, %rdi 0x708494d6: ba 01 00 00 00 movl $1, %edx 0x708494db: 48 8d 0d d2 fe ff ff leaq -0x12e(%rip), %rcx 0x708494e2: ff 15 10 00 00 00callq*0x10(%rip) 0x708494e8: 8b d8movl %eax, %ebx 0x708494ea: e9 c5 fe ff ff jmp 0x708493b4 0x708494ef: 90 nop 0x708494f0: .quad 0x558bd6fd 0x708494f8: .quad 0x558bc898 0x70849500: .quad 0x55a70e01 0x70849508: .quad 0x558bca00 IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849640: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849643: 85 dbtestl%ebx, %ebx 0x70849645: 0f 8c 1f 00 00 00jl 0x7084966a 0x7084964b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849652: 48 8b fd movq %rbp, %rdi 0x70849655: be 12 00 00 00 movl $0x12, %esi 0x7084965a: ba 00 00 00 02 movl $0x200, %edx 0x7084965f: b9 01 00 00 00 movl $1, %ecx 0x70849664: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084966a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849671: e9 a2 f9 ff ff jmp 0x70849018 0x70849676: 90 nop 0x70849677: 90 nop 0x70849678: .quad 0x55a70e01 qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00= R01=ff5d R02=0018 R03=0018 R04=c0dec314 R05=ff49 R06= R07=0048 R08= R09= R10= R11= R12= R13=c0dec0b8 R14=fff9 R15= XPSR=8003 N--- A handler FPSCR: Thank you, Abhijeet. On Thu, Sep 30, 2021, 10:57 Peter Maydell wrote: > On Thu, 30 Sept 2021 at 07:17, abhijeet inamdar > wrote: > > > > But this very ELF file runs on the target(real hardware) perfectly. So > how different should it be to emulate? > > Real hardware doesn't have a magic ELF file loader. The > details of what a debug environment or whatever mechanism > you're using to put the ELF file on the target or an > emulator expect from an ELF file vary. QEMU wants you to > provide a vector table. (I imagine that the mechanism you're > using with the real hardware starts execution at the ELF > entry point.) > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 30 Sept 2021 at 07:17, abhijeet inamdar wrote: > > But this very ELF file runs on the target(real hardware) perfectly. So how > different should it be to emulate? Real hardware doesn't have a magic ELF file loader. The details of what a debug environment or whatever mechanism you're using to put the ELF file on the target or an emulator expect from an ELF file vary. QEMU wants you to provide a vector table. (I imagine that the mechanism you're using with the real hardware starts execution at the ELF entry point.) -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
But this very ELF file runs on the target(real hardware) perfectly. So how different should it be to emulate? Thank you, Abhijeet. On Wed, Sep 29, 2021 at 10:31 PM Peter Maydell wrote: > On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar > wrote: > > > > I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: > > 'int,exec,cpu' are probably also helpful. > > > [New Thread 0x7fffe700 (LWP 44283)] > > > > IN: > > 0x: andeqr0, r0, r0 > > We started at address 0 in not-thumb mode. Your ELF file is > almost certainly not correct (ie it does not include a suitable > vector table for the CPU to get its reset PC and SP from). > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar wrote: > > I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: 'int,exec,cpu' are probably also helpful. > [New Thread 0x7fffe700 (LWP 44283)] > > IN: > 0x: andeqr0, r0, r0 We started at address 0 in not-thumb mode. Your ELF file is almost certainly not correct (ie it does not include a suitable vector table for the CPU to get its reset PC and SP from). -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: PROLOGUE: [size=45] 0x70849000: 55 pushq%rbp 0x70849001: 53 pushq%rbx 0x70849002: 41 54pushq%r12 0x70849004: 41 55pushq%r13 0x70849006: 41 56pushq%r14 0x70849008: 41 57pushq%r15 0x7084900a: 48 8b ef movq %rdi, %rbp 0x7084900d: 48 81 c4 78 fb ff ff addq $-0x488, %rsp 0x70849014: ff e6jmpq *%rsi 0x70849016: 33 c0xorl %eax, %eax 0x70849018: 48 81 c4 88 04 00 00 addq $0x488, %rsp 0x7084901f: c5 f8 77 vzeroupper 0x70849022: 41 5fpopq %r15 0x70849024: 41 5epopq %r14 0x70849026: 41 5dpopq %r13 0x70849028: 41 5cpopq %r12 0x7084902a: 5b popq %rbx 0x7084902b: 5d popq %rbp 0x7084902c: c3 retq [New Thread 0x7fffe700 (LWP 44283)] IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849100: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849103: 85 dbtestl%ebx, %ebx 0x70849105: 0f 8c 1f 00 00 00jl 0x7084912a 0x7084910b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849112: 48 8b fd movq %rbp, %rdi 0x70849115: be 12 00 00 00 movl $0x12, %esi 0x7084911a: ba 00 00 00 02 movl $0x200, %edx 0x7084911f: b9 01 00 00 00 movl $1, %ecx 0x70849124: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084912a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849131: e9 e2 fe ff ff jmp 0x70849018 0x70849136: 90 nop 0x70849137: 90 nop 0x70849138: .quad 0x55a70e01 IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849240: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849243: 85 dbtestl%ebx, %ebx 0x70849245: 0f 8c 1f 00 00 00jl 0x7084926a 0x7084924b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849252: 48 8b fd movq %rbp, %rdi 0x70849255: be 12 00 00 00 movl $0x12, %esi 0x7084925a: ba 00 00 00 02 movl $0x200, %edx 0x7084925f: b9 01 00 00 00 movl $1, %ecx 0x70849264: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084926a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849271: e9 a2 fd ff ff jmp 0x70849018 0x70849276: 90 nop 0x70849277: 90 nop 0x70849278: .quad 0x55a70e01 qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00= R01= R02= R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13=ffe0 R14=fff9 R15= XPSR=4003 -Z-- A handler FPSCR: Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe700 (LWP 44283)] 0x75f31438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) n [Thread 0x7fffe700 (LWP 44283) exited] [Thread 0x73049700 (LWP 44282) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) it aborts in the next step only. How can I proceed? Thank you, Abhijeet. On Fri, Sep 17, 2021 at 11:11 AM Peter Maydell wrote: > On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar > > wrote: > > > > Is there any way/s to check where actually is it failing or point which > file? > > Use the usual debugging facilities -- gdbstub or -d debug logging. > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar wrote: > > Is there any way/s to check where actually is it failing or point which file? Use the usual debugging facilities -- gdbstub or -d debug logging. -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
Is there any way/s to check where actually is it failing or point which file? Thank you, Abhijeet. On Thu, Sep 16, 2021 at 8:49 PM Peter Maydell wrote: > On Thu, 16 Sept 2021 at 19:46, Peter Maydell > wrote: > > > > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar > > wrote: > > > How do I fix it ? it's for cortex-m3 and the below is the gdb trace > when I load ELF. > > > > > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority > -1) > > > > > > R00= R01= R02= R03= > > > R04= R05= R06= R07= > > > R08= R09= R10= R11= > > > R12= R13=ffe0 R14=fff9 R15= > > > XPSR=4003 -Z-- A handler > > > FPSCR: > > > This particular case is "we needed to take a HardFault exception, > > but we were already in a HardFault exception". The most common > > cause of this is that your code has crashed hard on startup > > (eg it tries to read from unreadable memory or jumps off into nowhere: > > if this happens before it has set up exception handling for HardFault > > then you get this. This also happens if its attempt to handle > > HardFaults is buggy and crashes.) > > Oh, and note that the PC is zero and the Thumb bit is not set: > this means that your guest code did something that caused the > CPU to try to take an exception, but your ELF file didn't > provide an exception vector table, and so the vector table > entry for the exception was 0. That means that the CPU will > attempt to execute from address 0 with the Thumb bit clear, > which provokes an immediate UsageFault exception, usually leading > to the exception-in-an-exception Lockup case above. > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 19:46, Peter Maydell wrote: > > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar > wrote: > > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I > > load ELF. > > > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > > > R00= R01= R02= R03= > > R04= R05= R06= R07= > > R08= R09= R10= R11= > > R12= R13=ffe0 R14=fff9 R15= > > XPSR=4003 -Z-- A handler > > FPSCR: > This particular case is "we needed to take a HardFault exception, > but we were already in a HardFault exception". The most common > cause of this is that your code has crashed hard on startup > (eg it tries to read from unreadable memory or jumps off into nowhere: > if this happens before it has set up exception handling for HardFault > then you get this. This also happens if its attempt to handle > HardFaults is buggy and crashes.) Oh, and note that the PC is zero and the Thumb bit is not set: this means that your guest code did something that caused the CPU to try to take an exception, but your ELF file didn't provide an exception vector table, and so the vector table entry for the exception was 0. That means that the CPU will attempt to execute from address 0 with the Thumb bit clear, which provokes an immediate UsageFault exception, usually leading to the exception-in-an-exception Lockup case above. -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar wrote: > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I > load ELF. > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00= R01= R02= R03= > R04= R05= R06= R07= > R08= R09= R10= R11= > R12= R13=ffe0 R14=fff9 R15= > XPSR=4003 -Z-- A handler > FPSCR: If the CPU goes into Lockup this indicates that something has gone very badly wrong with your guest code, and the situation is not recoverable. In real hardware the CPU sits there doing absolutely nothing forever more[*]. QEMU doesn't actually emulate the CPU being in Lockup state, so it just treats it as a fatal error. (Check the M-profile architecture reference for more information on Lockup and the various kinds of guest bug that can get you there.) This particular case is "we needed to take a HardFault exception, but we were already in a HardFault exception". The most common cause of this is that your code has crashed hard on startup (eg it tries to read from unreadable memory or jumps off into nowhere: if this happens before it has set up exception handling for HardFault then you get this. This also happens if its attempt to handle HardFaults is buggy and crashes.) You should approach this by debugging your guest and looking at what it is doing before it gets to this point. [*] Technically there are ways to get yourself out of Lockup state on a real CPU, such as having an external watchdog that resets the CPU, or some extremely esoteric tricks used only by code that's trying to test how Lockup state behaves. -- PMM
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
Hi, How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I load ELF. qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00= R01= R02= R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13=ffe0 R14=fff9 R15= XPSR=4003 -Z-- A handler FPSCR: Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe700 (LWP 54005)] 0x75f31438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x75f31438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x75f3303a in __GI_abort () at abort.c:89 #2 0x5583cb2a in cpu_abort (cpu=0x56bee620, fmt=0x56052660 "Lockup: can't escalate %d to HardFault (current priority %d)\n") at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/exec.c:1247 #3 0x55912542 in do_armv7m_nvic_set_pending (opaque=0x56b8e2b0, irq=3, secure=false, derived=false) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/hw/intc/armv7m_nvic.c:640 #4 0x559125c0 in armv7m_nvic_set_pending (opaque=0x56b8e2b0, irq=6, secure=false) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/hw/intc/armv7m_nvic.c:658 #5 0x55a9020e in arm_v7m_cpu_do_interrupt (cs=0x56bee620) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/target/arm/m_helper.c:2075 #6 0x558d35ea in cpu_handle_exception (cpu=0x56bee620, ret=0x7fffefffe84c) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/accel/tcg/cpu-exec.c:503 #7 0x558d3c62 in cpu_exec (cpu=0x56bee620) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/accel/tcg/cpu-exec.c:711 #8 0x5589203a in tcg_cpu_exec (cpu=0x56bee620) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/cpus.c:1473 #9 0x55892890 in qemu_tcg_cpu_thread_fn (arg=0x56bee620) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/cpus.c:1781 #10 0x55f29b63 in qemu_thread_start (args=0x56c12bf0) at /home/ocp/vcpu-playground/vcpu_on_qemu/qemu-4.2.0/util/qemu-thread-posix.c:519 #11 0x762cd6ba in start_thread (arg=0x7fffe700) at pthread_create.c:333 #12 0x7600351d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thank you, Abhijeet.
