From: Michal Pecio <michal.pecio@gmail.com>
To: Anders Thomson <andtho888@gmail.com>
Cc: linux-usb@vger.kernel.org, Mathias Nyman <mathias.nyman@intel.com>
Subject: Re: renesas 1912:0014 failures
Date: Tue, 12 May 2026 12:27:19 +0200 [thread overview]
Message-ID: <20260512122719.51338042.michal.pecio@gmail.com> (raw)
In-Reply-To: <CAGwGCQ+YFkxxnnbSKbSWC7wsh5ORAT=5riqHJrwsimtqFCuKYw@mail.gmail.com>
On Wed, 6 May 2026 14:58:44 +0200, Anders Thomson wrote:
> Hi,
>
> I've received a Renesas pcie usb3 card which fails to suspend (to ram)
> correctly.
>
> Regular boots appear to be working fine, but upon resuming from
> suspend, I get this log:
>
> [ 461.824899] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 461.824902] rcu: 3-...0: (3 ticks this GP)
> idle=0884/1/0x4000000000000000 softirq=2388/2389 fqs=5249
> [ 461.824907] rcu: (detected by 1, t=21002 jiffies, g=5201, q=24 ncpus=4)
> [ 461.824910] Sending NMI from CPU 1 to CPUs 3:
> [ 461.824917] NMI backtrace for cpu 3
> [ 461.824922] CPU: 3 UID: 0 PID: 513 Comm: kworker/u18:6 Tainted: G S
> 7.0.3 #2 PREEMPT(full)
> [ 461.824926] Tainted: [S]=CPU_OUT_OF_SPEC
> [ 461.824927] Hardware name: HP-Pavilion FJ422AA-UUW
> a6551.sc/Benicia, BIOS 5.32 10/23/2008
> [ 461.824929] Workqueue: async async_run_entry_fn
> [ 461.824936] RIP: 0010:xhci_resume+0x3fe/0x5a0
> [ 461.824941] Code: 04 f6 c4 08 74 5a 41 bd 7b 6f 98 00 eb 21 49 83
> ed 01 0f 84 a0 01 00 00 bf c7 10 00 00 e8 1a fa 3e 00 f3 90 48 8b 04
> 24 8b 00 <f6> c4 08 74 31 83 f8 ff 75 da b8 ed ff ff ff 48 8b 0b 89 c2
> 48 c7
> [ 461.824943] RSP: 0000:ffff9ed3003ebd68 EFLAGS: 00000082
> [ 461.824945] RAX: 0000000000000801 RBX: ffff9112c241a250 RCX: ffff9ed30043e024
> [ 461.824947] RDX: 0000000000000987 RSI: 0000000000000003 RDI: 0000000bf69fa402
> [ 461.824948] RBP: ffff9112c241a000 R08: 0000000000000960 R09: 0000000000000003
> [ 461.824950] R10: 0000000000000003 R11: ffffffff95258f20 R12: 0000000000000000
> [ 461.824951] R13: 0000000000268925 R14: ffff9112c241a290 R15: 0000000000000000
> [ 461.824952] FS: 0000000000000000(0000) GS:ffff9113e6604000(0000)
> knlGS:0000000000000000
> [ 461.824954] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 461.824956] CR2: 0000000000000000 CR3: 000000000faeb000 CR4: 00000000000006f0
> [ 461.824957] Call Trace:
> [ 461.824960] <TASK>
> [ 461.824963] resume_common+0x89/0xd0
> [ 461.824968] ? __pfx_pci_pm_resume+0x10/0x10
> [ 461.824973] dpm_run_callback+0x3d/0x160
> [ 461.824977] ? dpm_wait_for_superior+0xf7/0x150
> [ 461.824981] device_resume+0x158/0x250
> [ 461.824984] async_resume+0x14/0x20
> [ 461.824987] async_run_entry_fn+0x21/0xa0
> [ 461.824991] process_one_work+0x163/0x370
> [ 461.824994] worker_thread+0x18f/0x300
> [ 461.824997] ? __pfx_worker_thread+0x10/0x10
> [ 461.824999] kthread+0xda/0x110
> [ 461.825003] ? __pfx_kthread+0x10/0x10
> [ 461.825006] ret_from_fork+0x1af/0x2b0
> [ 461.825009] ? __pfx_kthread+0x10/0x10
> [ 461.825012] ret_from_fork_asm+0x1a/0x30
> [ 461.825017] </TASK>
> [ 462.302911] rcu: INFO: rcu_preempt detected expedited stalls on
> CPUs/tasks: { 3-...D } 21425 jiffies s: 365 root: 0x8/.
> [ 462.302917] rcu: blocking rcu_node structures (internal RCU debug):
> [ 462.302919] Sending NMI from CPU 1 to CPUs 3:
> [ 462.302922] NMI backtrace for cpu 3
> [ 462.302925] CPU: 3 UID: 0 PID: 513 Comm: kworker/u18:6 Tainted: G S
> 7.0.3 #2 PREEMPT(full)
> [ 462.302928] Tainted: [S]=CPU_OUT_OF_SPEC
> [ 462.302929] Hardware name: HP-Pavilion FJ422AA-UUW
> a6551.sc/Benicia, BIOS 5.32 10/23/2008
> [ 462.302930] Workqueue: async async_run_entry_fn
> [ 462.302933] RIP: 0010:xhci_resume+0x3fe/0x5a0
> [ 462.302936] Code: 04 f6 c4 08 74 5a 41 bd 7b 6f 98 00 eb 21 49 83
> ed 01 0f 84 a0 01 00 00 bf c7 10 00 00 e8 1a fa 3e 00 f3 90 48 8b 04
> 24 8b 00 <f6> c4 08 74 31 83 f8 ff 75 da b8 ed ff ff ff 48 8b 0b 89 c2
> 48 c7
> [ 462.302938] RSP: 0000:ffff9ed3003ebd68 EFLAGS: 00000082
> [ 462.302940] RAX: 0000000000000801 RBX: ffff9112c241a250 RCX: ffff9ed30043e024
> [ 462.302941] RDX: 0000000000000987 RSI: 0000000000000003 RDI: 0000000c3b0074cb
> [ 462.302943] RBP: ffff9112c241a000 R08: 0000000000000960 R09: 0000000000000003
> [ 462.302944] R10: 0000000000000003 R11: ffffffff95258f20 R12: 0000000000000000
> [ 462.302945] R13: 000000000023f18b R14: ffff9112c241a290 R15: 0000000000000000
> [ 462.302947] FS: 0000000000000000(0000) GS:ffff9113e6604000(0000)
> knlGS:0000000000000000
> [ 462.302949] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 462.302950] CR2: 0000000000000000 CR3: 000000000faeb000 CR4: 00000000000006f0
> [ 462.302951] Call Trace:
> [ 462.302952] <TASK>
> [ 462.302953] resume_common+0x89/0xd0
> [ 462.302957] ? __pfx_pci_pm_resume+0x10/0x10
> [ 462.302961] dpm_run_callback+0x3d/0x160
> [ 462.302964] ? dpm_wait_for_superior+0xf7/0x150
> [ 462.302967] device_resume+0x158/0x250
> [ 462.302970] async_resume+0x14/0x20
> [ 462.302974] async_run_entry_fn+0x21/0xa0
> [ 462.302977] process_one_work+0x163/0x370
> [ 462.302980] worker_thread+0x18f/0x300
> [ 462.302983] ? __pfx_worker_thread+0x10/0x10
> [ 462.302985] kthread+0xda/0x110
> [ 462.302988] ? __pfx_kthread+0x10/0x10
> [ 462.302991] ret_from_fork+0x1af/0x2b0
> [ 462.302993] ? __pfx_kthread+0x10/0x10
> [ 462.302997] ret_from_fork_asm+0x1a/0x30
> [ 462.303001] </TASK>
> [ 468.932307] xhci-pci-renesas 0000:03:00.0: Controller not ready at
> resume -110
> [ 468.932332] clocksource: Long readout interval, skipping watchdog
> check: cs_nsec: 26925372067 wd_nsec: 26925364392
> [ 468.932394] xhci-pci-renesas 0000:03:00.0: PCI post-resume error -110!
> [ 468.932401] xhci-pci-renesas 0000:03:00.0: HC died; cleaning up
> [ 468.932429] xhci-pci-renesas 0000:03:00.0: PM: dpm_run_callback():
> pci_pm_resume returns -110
> [ 468.932434] xhci-pci-renesas 0000:03:00.0: PM: failed to resume
> async: error -110
That's waiting 10 seconds with IRQs disabled for USBSTS.CNR to clear.
Sadly, a70bcbc322837 doesn't explain why such long timeout was used.
That being said, this bit should clear, so something is wrong.
Similar 0015 controllers have the RESET_ON_RESUME quirk applied. Sadly
again, the reason isn't documented in all detail we could wish for.
The quirk would apparently try a reset without looking at CNR (which is
frankly a spec violation) and only then test CNR.
Wonder if xhci_hcd.quirks=0x80 boot parameter would make a difference?
> This is on vanilla 7.0.3. If I add the firmware (renesas_usb_fw.mem,
> sha256=177560c224c73...) it fails to load on boot and I get a massive
> stall in bootup:
>
> [ 0.374764] pci 0000:00:1c.1: enabling device (0106 -> 0107)
> [ 6.295099] pci 0000:03:00.0: xHCI HW not ready after 5 sec (HC
> bug?) status = 0x801
> [ 6.295198] pci 0000:03:00.0: quirk_usb_early_handoff+0x0/0x700
> took 5781678 usecs
That's early boot, presence of FW files shouldn't have any effect.
Perhaps it happens *after* failing to load FW or loading wrong one,
then rebooting without power cycle or something like that?
Regards,
Michal
next prev parent reply other threads:[~2026-05-12 10:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 12:58 renesas 1912:0014 failures Anders Thomson
2026-05-12 10:27 ` Michal Pecio [this message]
2026-05-12 14:40 ` Anders Thomson
2026-05-12 17:02 ` Michal Pecio
2026-05-12 22:34 ` Anders Thomson
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=20260512122719.51338042.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=andtho888@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.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