On Sat, 3 Jun 2023 at 19:06, Guenter Roeck <li...@roeck-us.net> wrote: > > 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.
If you can provide a link to the zImage and the dtb to reproduce as well, that would be helpful. thanks -- PMM
