From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Marek Vasut <marek.vasut+renesas@gmail.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-pci <linux-pci@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: pcie-rcar: rcu stall during s2ram
Date: Wed, 30 Dec 2020 09:34:26 +0100 [thread overview]
Message-ID: <CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com> (raw)
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
reply other threads:[~2020-12-30 8:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut+renesas@gmail.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).