[BUG] PCI: spacemit-k1: port C probe hard-hangs a CPU with one endpoint on Milk-V Jupiter

[Manivannan Sadhasivam]

On Tue, Aug 25, 2026 at 07:22:49AM +0200, Bruno Banelli wrote:
> Hi,
> 
> On a Milk-V Jupiter, probing the PCIe controller at ca800000 (port C, the
> card slot) permanently wedges the CPU that runs the probe when one
> particular add-in card is installed.  The CPU stops responding to NMI, and
> because the probe is asynchronous, kernel_init() then blocks forever in
> async_synchronize_full() and the machine never finishes booting.
> 
> The same card, in the same slot, on the same board, does *not* hang the
> vendor 6.6 kernel -- it reports "Phy link never came up" and boots normally.
> Six other cards do not hang mainline either.  So whatever the electrical
> cause, this looks like a robustness problem in pcie-spacemit-k1: an endpoint
> should not be able to hang a host-side DBI register access.
> 
> 
> HARDWARE
> --------
>   Milk-V Jupiter v1.1, SpacemiT M1 (socinfo: CPU[M1-8571] REV[C] DRO[130]),
>   16 GiB LPDDR4X.
>   Firmware: stock vendor U-Boot 2022.10 (k1-bl-v2.2.9), unmodified.
>   Port B (ca400000, M.2) has a Samsung PM9B1 NVMe and works throughout.
>   Port C (ca800000) is the card slot -- an x8-length connector, silkscreened
>   PCIE_X2, wired x2.
> 
> 
> REPRODUCED ON
> -------------
>   v7.1 and v7.2, riscv defconfig (plus PHY_SPACEMIT_K1_USB2, USB_DWC3,
>   SPACEMIT_K1_TSENSOR, IGB, IGC, NVMe/ext4 built in).
>   gcc 13.3.0 (cross) and gcc 16.2.0 (native, Debian sid).
>   Identical failure in all combinations.  Not a regression -- port C has
>   never worked with this card on mainline.
> 
> Command line:
>   console=ttyS0,115200 earlycon root=/dev/nvme0n1p2 rootwait rw
>   swiotlb=65536 clk_ignore_unused pd_ignore_unused
> 
> 
> SYMPTOM
> -------
> Port C prints its address ranges and then never speaks again.  (Log below is
> from a run with port B disabled in DT, so nothing is interleaved.)
> 
>   [ 1.290074] spacemit-k1-pcie ca800000.pcie: host bridge /soc/pcie-bus/pcie at ca800000 ranges:
>   [ 1.297283] spacemit-k1-pcie ca800000.pcie:       IO 0x00b7002000..0x00b7101fff -> 0x0000000000
>   [ 1.312783] spacemit-k1-pcie ca800000.pcie:      MEM 0x00a0000000..0x00afffffff -> 0x00a0000000
>   [ 1.326753] spacemit-k1-pcie ca800000.pcie:      MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000
>   [22.348490] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
>   [22.351764] rcu:     4-...0: (12 GPs behind) idle=051c/1/0x4000000000000000 softirq=43/43 fqs=1908
>   [22.367040] Sending NMI from CPU 2 to CPUs 4:
>   [32.367049] After 10 seconds, these CPUS still haven't responded to the NMI: 4
> 
> The CPU ignoring an NMI for ten seconds is why I read this as an MMIO access
> that never receives a completion rather than a spin or a deadlock.
> 
> 
> LOCALISATION
> ------------
> I added a dev_info() before each step of k1_pcie_init() (patch at the end of
> this mail).  The last marker port C prints is the one immediately before the
> first DBI access:
> 
>   [1.347050] spacemit-k1-pcie ca800000.pcie: K1DBG 1 toggle_soft_reset
>   [1.362635] spacemit-k1-pcie ca800000.pcie: K1DBG 2 enable_resources
>   [1.370918] spacemit-k1-pcie ca800000.pcie: K1DBG 3 first DBI write (vendor/device ID)
>   <nothing further>

Sounds weird that an endpoint is causing DBI write hang.

Can Alex or someone from Spacemit look into this issue?

- Mani

-- 
மணிவண்ணன் சதாசிவம்