pcie-rcar: rcu stall during s2ram

pcie-rcar: rcu stall during s2ram

[Geert Uytterhoeven]

Hi Marek, Shimoda-san,

I got the following rcu stall on Salvator-X with R-Car M3-W ES1.0 during
resume from s2idle:

    rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
    rcu:     1-....: (524 ticks this GP) idle=ffa/1/0x4000000000000000
softirq=23053/23053 fqs=2437
     (detected by 3, t=6505 jiffies, g=39321, q=46)
    Task dump for CPU 1:
    task:kworker/u12:0   state:R  running task     stack:    0 pid:
943 ppid:     2 flags:0x0000000a
    Workqueue: events_unbound async_run_entry_fn
    Call trace:
     __switch_to+0xa8/0x10c
     0x0
    watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kworker/u12:0:943]
    Modules linked in:
    irq event stamp: 0
    hardirqs last  enabled at (0): [<0000000000000000>] 0x0
    hardirqs last disabled at (0): [<ffffffc010074960>]
copy_process+0x54c/0x12b8
    softirqs last  enabled at (0): [<ffffffc010074960>]
copy_process+0x54c/0x12b8
    softirqs last disabled at (0): [<0000000000000000>] 0x0
    CPU: 1 PID: 943 Comm: kworker/u12:0 Not tainted
5.11.0-rc1-salvator-x-00727-g2e798beeefcc #877
    Hardware name: Renesas Salvator-X board based on r8a77960 (DT)
    Workqueue: events_unbound async_run_entry_fn
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
    pc : arch_local_irq_restore+0x4/0x8
    lr : _raw_spin_unlock_irqrestore+0x58/0x80
    sp : ffffffc013963b10
    x29: ffffffc013963b10 x28: 0000000000000000
    x27: ffffffc010f3f938 x26: 0000000000000000
    x25: 0000000000000000 x24: 0000000000000000
    x23: ffffffc013963bd4 x22: 0000000000000000
    x21: 0000000000000ffc x20: ffffffc0110da208
    x19: 0000000000000000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000
    x15: 000000000000000a x14: 7265776f70206567
    x13: 6e6168632074276e x12: 6f683344206d6f72
    x11: 6620657461747320 x10: 206769666e6f6328
    x9 : 203044206f742074 x8 : 0000000000000000
    x7 : 0000000000000001 x6 : 0000000000000000
    x5 : ffffffc013963b30 x4 : 0000000000000001
    x3 : ffffffc013bf7fb0 x2 : 0000000000000000
    x1 : 0000000000000027 x0 : 0000000000000000
    Call trace:
     arch_local_irq_restore+0x4/0x8
     pci_bus_read_config_dword+0x8c/0xc8
     pci_read_config_dword+0x38/0x40
     pci_find_next_ext_capability+0xc0/0xe0
     pci_find_ext_capability+0x14/0x1c
     pci_restore_aspm_l1ss_state+0x24/0x74
     pci_restore_state+0x80/0x2dc
     pci_pm_resume_noirq+0x8c/0xf8
     dpm_run_callback+0x64/0xd4
     device_resume_noirq+0xc8/0x174
     async_resume_noirq+0x24/0x54
     async_run_entry_fn+0x4c/0x124
     process_one_work+0x2f8/0x490
     worker_thread+0x1d0/0x274
     kthread+0xfc/0x10c
     ret_from_fork+0x10/0x18
    rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
    rcu:     1-....: (2094 ticks this GP)
idle=ffa/1/0x4000000000000000 softirq=23053/23053 fqs=9936
     (detected by 5, t=26010 jiffies, g=39321, q=90)
    Task dump for CPU 1:
    task:kworker/u12:0   state:R  running task     stack:    0 pid:
943 ppid:     2 flags:0x0000000a
    Workqueue: events_unbound async_run_entry_fn
    Call trace:
     __switch_to+0xa8/0x10c
     0x0

This is a board with an Intel E1000 Ethernet card installed, and
firmware including the L1 link state fix (else s2idle would crash
always).

Tree is based on renesas-drivers-2020-12-29-v5.11-rc1 with the following
patches applied:

    PCI: rcar: Always allocate MSI addresses in 32bit space
    PCI: rcar: Add L1 link state fix into data abort hook (shouldn't matter as

Compared with v5.11-rc1, above are the only changes to drivers/pci.
The second one shouldn't matter, as all code changes are protected by
#ifdef CONFIG_ARM, while this report is on arm64, which handles that
inside ATF.

This happened once, I couldn't reproduce it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds