Re: [PULL 31/35] hw/intc/allwinner-a10-pic: Don't use set_bit()/clear_bit()

[Peter Maydell <peter.maydell@linaro.org>]

On Sat, 3 Jun 2023 at 19:06, Guenter Roeck <linux@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-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.
> >
> > 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