foss-for-synopsys-dwc-arc-processors / linux

Helpful resources for users & developers of Linux kernel for ARC
22 stars 13 forks source link

Possible race condition in the Linux kernel #83

Open shahab-vahedi opened 2 years ago

shahab-vahedi commented 2 years ago

After the commit Fixed issue related to Zephyr in QEMU, I've noticed my linux image is behaving weirdly. At random points in time, usually within the first minute, it starts spinning. Sometimes it's during the boot, sometimes a user application (specially if they call the sleep function).

I have to say, I've looked into QEMU change and it seems OK and does solve another kernel's (Zephyr) problem. That's why I filed a tentative issue here.

# revisions
qemu     (master): 5d8f256223    Print name of unimplemented instruction
linux     (arc64): 22aa9396bdf0  ARC: Add missing CC_NAMEs for ARC32
glibc     (arc64): f4964381d1    ARC: Synopsys ARC700 support
gcc       (arc64): 5f3d74a91ec   arc64: Fix DWARF2 alternate CFA column patch
binutils  (arc64): 02e39211276   [arc32/gdb] Add baremetal support

# QEMU flag
FTP     := hostfwd=tcp::30021-:21
SSH     := hostfwd=tcp::30022-:22
TLN     := hostfwd=tcp::30023-:23
QFLAGS  := -M virt                                            \
           -nographic                                         \
           -no-reboot                                         \
           -global cpu.freq_hz=50000000                       \
           -cpu hs6x                                          \
           -netdev user,id=net0,$(FTP),$(SSH),$(TLN)          \
           -device virtio-net-device,netdev=net0              \
           -append nokaslr                                    \
           -kernel $(LNXIMG)

configs.zip loader.zip

cupertinomiranda commented 2 years ago

I don't see it as a tentative issue, but rather as a placeholder for an investigation why the kernel is currently locking in QEMU. My perception is that there might be some race in timers / interrupts within the kernel.

abrodkin commented 1 year ago

@kolerov could you please check if anything needs to be done here from QEMU standpoint, if not let's just close it.