Bug 2298659

1. Fedora does not boot on Rock Pi 4 B+ after kernel upgrade. I have two of these boards and the issue reproduces on both. When I plug in HDMI, it boots 20% of the time. When HDMI is unplugged, it never boots. When it does not boot, it just halts on a certain stage, not responding to any key press. No kernel panic message is printed, but sometimes instead of a complete halt the following message is printed:

```
[  560.064818] watchdog: BUG: soft lockup - CPU#4 stuck for 510s! [(udev-worker):378]
[  560.065504] Modules linked in: rtc_rk808(+) clk_rk808 ulpi mmc_block(+) udc_core dwmac_rk(+) crct10dif_ce rockchipdrm(+) governor_simpleondemand polyval_ce panfrost drm_dma_helper rk8xx_i2c polyval_generic stmmac_platform ghash_ce des_generic dwc3_of_simple rk_crypto dw_wdt analogix_dp rk8xx_core ohci_platform libdes spi_rockchip phy_rockchip_typec stmmac dw_mipi_dsi gpu_sched ohci_hcd sdhci_of_arasan dw_hdmi sdhci_pltfm dw_mmc_rockchip phy_rockchip_emmc drm_display_helper phy_rockchip_inno_usb2 dw_mmc_pltfm pcs_xpcs rockchip_dfi pl330 sdhci io_domain nvmem_rockchip_efuse dw_mmc phylink pwm_rockchip ehci_platform cec cqhci scsi_dh_rdac scsi_dh_emc scsi_dh_alua
[  560.070925] CPU: 4 PID: 378 Comm: (udev-worker) Tainted: G             L     6.9.9-200.fc40.aarch64 #1
[  560.071759] Hardware name: radxa Radxa ROCK Pi 4A/Radxa ROCK Pi 4A, BIOS 2024.04 04/01/2024
[  560.072506] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  560.073135] pc : smp_call_function_many_cond+0x198/0x668
[  560.073625] lr : smp_call_function_many_cond+0x1b4/0x668
[  560.074112] sp : ffff800086203be0
[  560.074417] x29: ffff800086203be0 x28: ffff0000f557e580 x27: ffff0000f557e580
[  560.075074] x26: ffff8000831cf9d0 x25: ffff8000831d4fa0 x24: ffff0000f55bd000
[  560.075730] x23: ffff8000831cefd8 x22: ffff80008038fc68 x21: ffff8000831d4fa0
[  560.076386] x20: ffff0000f554f000 x19: 0000000000000000 x18: 0000000000000000
[  560.077042] x17: 68637261612e3034 x16: 63662e3030322d39 x15: 0074696e695f7968
[  560.077698] x14: 0f1c4f16170a1e12 x13: 0000000000000007 x12: 0000000000000003
[  560.078354] x11: 0101010101010101 x10: 0000000000000004 x9 : ffff800080b38640
[  560.079009] x8 : ffff8000827f2580 x7 : 0000000000000004 x6 : ffff8000831cf000
[  560.079665] x5 : 0000000000000000 x4 : 0000000000000003 x3 : ffff0000f554f008
[  560.080320] x2 : 0000000000000003 x1 : 0000000000000011 x0 : 0000000000000000
[  560.080976] Call trace:
[  560.081204]  smp_call_function_many_cond+0x198/0x668
[  560.081662]  kick_all_cpus_sync+0x4c/0x80
[  560.082037]  load_module+0x438/0x7e8
[  560.082370]  __do_sys_init_module+0x13c/0x168
[  560.082772]  __arm64_sys_init_module+0x24/0x40
[  560.083180]  invoke_syscall+0x74/0x100
[  560.083529]  el0_svc_common.constprop.0+0xc8/0xf0
[  560.083960]  do_el0_svc+0x24/0x38
[  560.084269]  el0_svc+0x3c/0x158
[  560.084570]  el0t_64_sync_handler+0x120/0x138
[  560.084977]  el0t_64_sync+0x194/0x198
```

When comparing good and bad boots, it looks like on the bad boot it always halts just before the following line:
```
dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
```


2. Last tested: 6.9.9-200.fc40.aarch64 (issue exists)


3. Last working kernel: 6.4.12-200.fc38.aarch64 (I can still boot with it as a workaround)
   Issue first noticed with kernel 6.6.11-100.fc38.aarch64.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
   1. Unplug HDMI
   2. Boot Fedora

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
   Not tested, but since the issue is not new, the chances are low.


6. Are you running any modules that not shipped with directly Fedora's kernel?:
   I am using a wi-fi module (8852au), but I don't think it is loaded at this stage. Also tested without the module.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

   Will attach UART capture as a follow-up message.

Reproducible: Always