tests/kernel/threads/no-multithreading: kernel.threads.no-multithreading failing on nrf52_pca10040 and qemu_x86 with boot delay

[spoorthik]

Execution log:

***** delaying boot 1000ms (per build configuration) *****
***** USAGE FAULT *****
  Illegal load of EXC_RETURN into PC
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0x401af3

Platforms tested: nrf52_pca10040: arm, sam_e70_xplained:arm

[AdithyaBaglody]

This seems to have risen due to enabling the interrupts in main(). commit id : 17e9d62
This is seen because the userspace is enabled and it seems to have found some issue in the implementation of scheduler. @andyross can you please look into this.

[nashif]

fails on xtensa as well, in qemu:

***** Booting Zephyr OS v1.13.0-rc1-113-gdb55ce579 *****
It works
===================================================================
PROJECT EXECUTION SUCCESSFUL
 ** FATAL EXCEPTION
 ** CPU 0 EXCCAUSE 29 PS 0x00060720 PC 0x60001069 VADDR 0x0000004c
 **  A0 0xa0000a6d  SP 0x60001b20  A2 0x63ffff80  A3 0x60001cec
 **  A4 0x63ffffa0  A5 0x00000004  A6 0x00000000  A7 0x00000000
 **  A8 0x00000000  A9 0x60001af0 A10 0x00000001 A11 0x00000001
 ** A12 0x60001cec A13 0x00000001 A14 0x63ffffa0 A15 0x00000000
 ** SAR 0x00000001
Current thread ID = 0x00000000
Faulting instruction address = 0xdeaddead

do not think this is related to userspace.

[AdithyaBaglody]

@nashif yep this is not a userspace related issue at all. But I am not able to exactly pin point the issue here. Maybe the timer interrupt is causing something (a very crude guess).

[nashif]

looks like the xtensa exception has always been there but was never captured by sanitycheck. I am excluding xtensa from this test for now and will keep tracking the issue here.

[nashif]

on nrf52_pca10040

***** Booting Zephyr OS v1.13.0-rc1-126-g8c92433190 *****
It works
===================================================================
***** MPU FAULT *****
  Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0x20000b48

can't reproduce it on sam_e70_xplained

[nashif]

with mpu disable on nrf52 I get:

***** Booting Zephyr OS v1.13.0-rc1-126-g8c92433190 *****
It works
===================================================================
***** USAGE FAULT *****
  Illegal use of the EPSR
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0x20000b00

[MaureenHelm]

I can reproduce on mimxrt1050_evk and frdm_kw41z, but not on frdm_k64f

[nashif]

@MaureenHelm can you try #9740?

[MaureenHelm]

@MaureenHelm can you try #9740?

It fixes both mimxrt1050_evk and frdm_kw41z.

[nashif]

#9740 fixes this issue

[spoorthik]

The test case fails on nrf51_pca10028 even after the fix #9740.

Latest commit: 19b7eaa

Execution log:

 ******* delaying boot 1000ms (per build configuration) ****
***** HARD FAULT *****
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0x8000

[nniranjhana]

It also fails on qemu_x86 with General Protection Fault on the latest RC2 tag.

Error console log:

***** delaying boot 1000ms (per build configuration) *****
***** General Protection Fault
***** Exception code: 0x0
Current thread ID = 0x00000000
eax: 0x00000000, ebx: 0x00009500, ecx: 0x00000000, edx: 0x00000000
esi: 0x00003560, edi: 0x004037c8, ebp: 0x004037f0, esp: 0x0040380c
eflags: 0x00000096 cs: 0x0008
call trace:
eip: 0x00001b80
Terminate emulator due to fatal kernel error

and hangs on qemu_nios2, quark_se_c1000_devboard and quark_d2000_crb with CONFIG_BOOT_DELAY=1000, displaying just below mentioned message on console output :

***** delaying boot 1000ms (per build configuration) *****

[nashif]

this is because of the delayed boot

[spoorthik]

The test still crashes on 1.13 RC3 (8250b3e) with delayed boot of 1000ms:

Tested on: qemu_xtensa, Altera Max10, qemu_nios2, minnowboard, quark_se_c1000_devboard and quark_d2000_crb.

Execution log:

 ** FATAL EXCEPTION
 ** CPU 0 EXCCAUSE 29 PS 0x00060120 PC 0x60001099 VADDR 0x0000004c
 **  A0 0xa0000a8d  SP 0x60001e50  A2 0x63ffff60  A3 0x6000201c
 **  A4 0x0000000f  A5 0x009184e7  A6 0x4e72a000  A7 0x00000000
 **  A8 0x00000000  A9 0x60001e20 A10 0x00000001 A11 0x00000001
 ** A12 0x6000201c A13 0x00000001 A14 0x00000000 A15 0x00000000
 ** SAR 0x00000003
Current thread ID = 0x00000000
Faulting instruction address = 0xdeaddead

[andyross]

As mentioned, BOOT_DELAY requires a working k_busy_wait(), which in the general case requires a working timer driver (though AFAIK x86 shouldn't be one of those -- it can do it with the TSC alone), which won't work without interrupts. We should probably add an appropriate depends-on to kconfig to enforce this.

Are there circumstances other than CONFIG_BOOT_DELAY where this is failing?

[nashif]

Do not think this should be tracked under the same bug, this issue always existed it seems, i can reproduce this on qemu_xtensa on the same commit the test was introduced.

CONFIG_BOOT_DELAY is test related, so I am lowering the priority of this.

[nashif]

can't reproduce