Re: renesas 1912:0014 failures

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 18 May 2026 14:36:18 +0200, Anders Thomson wrote:
> On Mon, May 18, 2026 at 10:41 AM Anders Thomson <andtho888@gmail.com> wrote:
> >  
> 
> > > I see you still have the quirk, but it doesn't matter, the chip is
> > > stuck and doesn't work either way.  
> >
> > The machine hangs on boot with the quirk. Without quirk i get:
> > [    2.293602] cdrom: Uniform CD-ROM driver Revision: 3.20
> > [    2.303526] sr 5:0:0:0: Attached scsi CD-ROM sr0
> > [    2.303603] sr 5:0:0:0: Attached scsi generic sg4 type 5
> > [   28.493779] xhci-pci-renesas 0000:03:00.0: xHCI Host Controller
> > [   28.493891] xhci-pci-renesas 0000:03:00.0: new USB bus registered,
> > assigned bus number 9
> > [   28.499338] xhci-pci-renesas 0000:03:00.0: hcc params 0x014051cf
> > hci version 0x100 quirks 0x0000000100000090
> >
> > Those 28.xxx  renesas lines never show up with the quirk applied.
> > The machine works (waiting 10 minutes I get a logs from other kernel
> > threads), but the boot process is stopped. By the looks of it, no
> > usb probing completes.
> >  
> Some advances, perhaps. I _did_ get (twice) the boot to succeed with
> the quirk (still with the 26 sec pause) . Both times was after a full
> power cycle (PSU on/off). After a regular I/O Button press during, the
> boot stalls. I'll run this a few times more to verify.

xhci_hcd.quirks=0x80 should have no effect on anything besides
suspend/resume. If you see differences in boot behavior, it probably
is an effect of suspend/resume cycles performed or attempted during
the previous boot. It seems that the chip gets into some bad state
which requires a power cycle to fix. BTW, do you mean just turning off
the computer, or disconnecting the PSU to remove standby power?

FYI, the quirk performs full xHCI reset during resume and prevents
selectively suspending the chip when all its USB devices are suspended
but the system is running (not going to sleep). It doesn't prevent
suspending when no USB devices are connected at all. And either way,
runtime PM may be turned off, see if this is 'on' or 'auto':

cat /sys/bus/pci/devices/0000:03:00.0/power/control

> After successful boot with quirk, 1st suspend/resume without
> peripherals attached, yielded:
> [...]
> 
> After the second suspend/resume, we got this:
> [...]
> [ 1697.224087] xhci-pci-renesas 0000:03:00.0: // Reset the HC
> [...]
> [ 1725.214860] xhci-pci-renesas 0000:03:00.0: PCI post-resume error -110!
> [ 1725.214863] xhci-pci-renesas 0000:03:00.0: HC died; cleaning up
> [ 1725.214875] xhci-pci-renesas 0000:03:00.0: PM: dpm_run_callback():
> pci_pm_resume returns -110
> [ 1725.214879] xhci-pci-renesas 0000:03:00.0: PM: failed to resume

I have no idea why it works the first time but not the second.
Not what happens if the same is done without the quirk?
Maybe try s2idle ("freeze") instead of S3 sleep? But that doesn't
provide the same power saving on older HW.

Regards,
Michal