On 14.02.2018 15:06, Samuel Sadok wrote:
Thanks for the patches.
However no luck yet, the usb device still doesn't reinitialize.
Logs:
https://gist.github.com/90ccb390c5777b9e2d5dc595f44d50da
Can I somehow check if it is at all possible to bring back this
particular device after hub power loss?
For instance would you expect reloading all USB modules to bring back
the device? I tried that and it didn't help:
I'm starting to run out if ideas, maybe powering port off and on again
in the logical disconnect could be worth a shot, or maybe trying
to disable->re-enable port a bit earlier, before the disconnect
-Mathias
#!/bin/bash
echo "Unload modules..."
echo 1 > /sys/bus/pci/devices/0000\:00\:14.0/remove
rmmod xhci_pci
rmmod xhci_hcd
rmmod usbhid
rmmod bcm5974
rmmod btusb
rmmod uas
rmmod usb_storage
rmmod usbcore
rmmod usb_common
echo "wait"
sleep 2
echo "Reload modules..."
modprobe usb_common
modprobe usbcore
modprobe usb_storage
modprobe uas
modprobe btusb
modprobe bcm5974
modprobe usbhid
modprobe xhci_hcd
modprobe xhci_pci
echo 1 > /sys/bus/pci/rescan
2018-02-13 17:07 GMT+01:00 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>:
On 12.02.2018 16:03, Mathias Nyman wrote:
On 10.02.2018 02:01, Samuel Sadok wrote:
Thanks Mathias for looking into this.
2018-02-06 18:32 GMT+01:00 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>:
Does reverting
37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
devices
help?
Unfortunately not, the card reader is still missing after resume.
Here's the dmesg and usbmon (as previously, doing one suspend-resume
cycle):
https://gist.github.com/anonymous/5aea8eddf97e1b964bffd75ed88793fd
For this log I also increased the usbmon buffer size as suggested by
Alan (to about 2MB). This (seemingly) resolved the issue with the log
gaps.
Ok, one reason reverting didn't help is that it we still don't really
disable and re-enable:
[ 100.771564] usb usb2-port4: logical disconnect
...
[ 100.771586] usb usb2-port4: Not disabling port; link state is RxDetect
The reset resume of device "usb 2-4" (the device in question) happens
around [100.77].
In the usbmon log there is no activity at that exact time, only ~50ms
before and after. Can we infer from this that the issue is independent
from the actual device and must stem from some faulty state in the
kernel or USB controller?
Btw I also added/modified some debug lines for my own understanding,
those are tagged with "[CUSTOM LOG]".
* check that root cause for failing USB3 device reset after resume is
not
that several
xhci slots are in Default state at the same time. xHC can't handle
this.
In normal device enumeration usb core has a mutex protecting it, not
sure
it works here,
maybe usb core and xhci are out of sync after xHC reset?
I find this line in particular interesting:
[ 100.771536] xhci_hcd 0000:00:14.0: [CUSTOM LOG] xHCI
xhci_urb_enqueue called with unaddressed device, slot_id = 1
This comes from xhci_check_args(). Since udev->slot_id == 1 is
non-zero this implies that xhci->devs[udev->slot_id] must be NULL for
this particular device (usb 2-4), which I guess is not good. So to me
this does indeed look like the usb core and xhci are out of sync.
However I'm not familiar with the code (for instance what is slot_id
is for, who uses it, should it always be 0 on resume?) but based on
the log and what you wrote I guess this sounds like a good point:
xhci uses slot_id to identify different usb devices connected to it.
xHC hw gives each enabled attached usb device a slot_id.
When usb core asks xhci host to do something to a device xhci driver knows
which device based on udev->slot_id
when xhci controller is reset, all xhci slots are disabled and freed, but
usb core still has udev->slot_id pointers set.
In normal resume case the xHC controller is not reset, but if something
goes wrong,
or power is cut from xHC during suspend then we recover by resetting xHC
at resume.
I'll try to write some quick testpatches that:
- removes LPM and LTM disabling from usb_reset_and_verify_device
- zeroes udev->slot_id when slot is disabled and freed in xhci
- forces a disable/enable port after port reset failed a few times.
A series for testing can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
port-disable-test
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=port-disable-test
Based on 4.15
Can you try it out?
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
