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-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230424152833.1334136-1-peter.maydell@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.