答复: [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister

Hi Michal,

quoted

quoted

quoted

But xhci_discover_or_reset_device() is called: before
hub_port_init() calls problematic hub_enable_device() /
hub_address_device() functions, it calls hub_port_reset(),
which calls hcd->driver->reset_device().

To me it looks like both drv->pre_reset and
xhci_discover_or_reset_device() are called in this path.

Yes, you are right. I mistakenly looked at the "warm reset, port only"
case but there seems to be no possibility of falling into this path.

BTW, SuperSpeed audio devices do exist. Basically, any audio function
in a larger device which needs the bandwidth. Similar thing with HID.

quoted

Your code tracing is correct. drv->pre_reset() IS called at
hub.c:6412 before usb_reset_and_verify_device(), and
xhci_discover_or_reset_device() IS called via hub_port_reset() →
hcd->driver->reset_device() inside hub_port_init().

However, this path is not the actual crash path. I apologize —
my earlier call chain referencing usb_reset_device() was an
assumption, not from the actual crash dump.

Note that xhci_setup_device() is involved, which is called from
hub_enable_device() and hub_set_address(), and these are called
from hub_port_init(), which is used by hub_port_connect() and
usb_reset_and_verify_device(). So something happens there.

Is this reproducible? Then add to xhci_free_virt_device():

	if (dev->sideband)
		dump_stack()

and we will know how it happens.

Unfortunately, no. The reproduction rate is very low, and we have
not yet found a stable way to reproduce it — it requires the
device to be in a specific state where the port is disabled after
autosuspend resume, which happens rarely in the field.

Regards,
Lianqin