linux-kernel - Re: [PATCH v2] usb: xhci: print xhci->xhc_state when queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250725120329.2b6e3813@foxbook>
Date: Fri, 25 Jul 2025 12:03:29 +0200
From: Michał Pecio <michal.pecio@...il.com>
To: Su Hui <suhui@...china.com>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v2] usb: xhci: print xhci->xhc_state when queue_command
 failed

Hi,

On Fri, 25 Jul 2025 14:01:18 +0800, Su Hui wrote:
> When encounters some errors like these:
> xhci_hcd 0000:4a:00.2: xHCI dying or halted, can't queue_command
> xhci_hcd 0000:4a:00.2: FIXME: allocate a command ring segment
> usb usb5-port6: couldn't allocate usb_device
> 
> It's hard to know whether xhc_state is dying or halted.

Is it truly a problem? This is the only place which sets
XHCI_STATE_DYING that I found in the whole drivers/ tree:

        xhci_err(xhci, "xHCI host controller not responding, assume dead\n");
        xhci->xhc_state |= XHCI_STATE_DYING;

And AFAIK such state can only be exited by unbinding the driver.
Are there really cases when it's unclear if the HC is dying or not?

> So it's better to print xhc_state's value which can help locate the
> resaon of the bug.

Hmm, any chance you came across bugs that upstream should know about?

Regards,
Michal