On 6/3/23 10:46, Michael Tokarev wrote:
03.06.2023 18:03, Guenter Roeck wrote:
Hi,
On Tue, May 02, 2023 at 01:14:55PM +0100, Peter Maydell wrote:
The Allwinner PIC model uses set_bit() and clear_bit() to update the
values in its irq_pending[] array when an interrupt arrives. However
it is using these functions wrongly: they work on an array of type
'long', and it is passing an array of type 'uint32_t'. Because the
code manually figures out the right array element, this works on
little-endian hosts and on 32-bit big-endian hosts, where bits 0..31
in a 'long' are in the same place as they are in a 'uint32_t'.
However it breaks on 64-bit big-endian hosts.
Remove the use of set_bit() and clear_bit() in favour of using
deposit32() on the array element. This fixes a bug where on
big-endian 64-bit hosts the guest kernel would hang early on in
bootup.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-id: 20230424152833.1334136-1-peter.mayd...@linaro.org
In v8.0.2, the cubieboard emulation running Linux crashes during reboot
with a hung task error. Tested with mainline Linux (v6.4-rc4-78-g929ed21dfdb6)
and with v5.15.114. Host is AMD Ryzen 5900X.
Requesting system reboot
[ 61.927460] INFO: task kworker/0:1:13 blocked for more than 30 seconds.
[ 61.927896] Not tainted 5.15.115-rc2-00038-g31e35d9f1b8d #1
[ 61.928144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 61.928419] task:kworker/0:1 state:D stack: 0 pid: 13 ppid: 2
flags:0x00000000
[ 61.928972] Workqueue: events_freezable mmc_rescan
[ 61.929739] [<c13734f0>] (__schedule) from [<c1373c98>] (schedule+0x80/0x15c)
[ 61.930041] [<c1373c98>] (schedule) from [<c137ad64>]
(schedule_timeout+0xd4/0x12c)
[ 61.930270] [<c137ad64>] (schedule_timeout) from [<c137477c>]
(do_wait_for_common+0xa0/0x154)
[ 61.930523] [<c137477c>] (do_wait_for_common) from [<c1374870>]
(wait_for_completion+0x40/0x4c)
[ 61.930764] [<c1374870>] (wait_for_completion) from [<c1044cd0>]
(mmc_wait_for_req_done+0x6c/0x90)
[ 61.931012] [<c1044cd0>] (mmc_wait_for_req_done) from [<c1044e34>]
(mmc_wait_for_cmd+0x70/0xa8)
[ 61.931252] [<c1044e34>] (mmc_wait_for_cmd) from [<c10512a0>]
(sdio_reset+0x58/0x124)
[ 61.931478] [<c10512a0>] (sdio_reset) from [<c1046328>]
(mmc_rescan+0x294/0x30c)
[ 61.931692] [<c1046328>] (mmc_rescan) from [<c036be10>]
(process_one_work+0x28c/0x720)
[ 61.931924] [<c036be10>] (process_one_work) from [<c036c308>]
(worker_thread+0x64/0x53c)
[ 61.932153] [<c036c308>] (worker_thread) from [<c03753e0>]
(kthread+0x15c/0x180)
[ 61.932365] [<c03753e0>] (kthread) from [<c030015c>]
(ret_from_fork+0x14/0x38)
[ 61.932628] Exception stack(0xc31ddfb0 to 0xc31ddff8)
This was not seen with v8.0.0. Bisect points to this patch. Reverting it
fixes the problem.
Does this happen on master too, or just on stable-8.0 ?
It does. Tested with v8.0.0-1542-g848a6caa88.
Here is my command line in case you want to give it a try:
qemu-system-arm -M cubieboard -kernel arch/arm/boot/zImage -no-reboot \
-initrd rootfs-armv5.cpio -m 512 \
--append "panic=-1 rdinit=/sbin/init earlycon=uart8250,mmio32,0x1c28000,115200n8
console=ttyS0" \
-dtb arch/arm/boot/dts/sun4i-a10-cubieboard.dtb -nographic \
-monitor null -serial stdio
initrd is
https://github.com/groeck/linux-build-test/blob/master/rootfs/arm-v7/rootfs-armv5.cpio.gz
This is with multi_v7_defconfig with some debug options added. If necessary
I'll be happy to provide the exact configuration.
Guenter
