Quick ping here: this is still busted on 4.5-rc6. On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman > <mathias.nyman@xxxxxxxxxxxxxxx> wrote: >> On 17.02.2016 07:19, Andy Lutomirski wrote: >>> >>> On Tue, Feb 16, 2016 at 6:33 PM, Greg Kroah-Hartman >>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>> >>>> On Tue, Feb 16, 2016 at 10:01:13AM -0800, Andy Lutomirski wrote: >>>>> >>>>> I get some warnings at boot on all kernels I've tried. On 4.5-rc4, I >>>>> see: >>>>> >> ... >> >>>>> [ 1.061036] hub 1-0:1.0: power on to power good time: 20ms >>>>> [ 1.061109] hub 1-0:1.0: local power source is good >>>>> [ 1.084337] usb usb1-port3: DeviceRemovable is changed to 1 >>>>> according to platform information. >>>>> [ 1.084339] usb usb1-port4: DeviceRemovable is changed to 1 >>>>> according to platform information. >>>>> [ 1.084341] usb usb1-port5: DeviceRemovable is changed to 1 >>>>> according to platform information. >> >> ... >>>>> >>>>> [ 1.085684] usb usb2-port1: peered to usb1-port1 >>>>> [ 1.086356] usb usb2-port2: peered to usb1-port2 >>>>> [ 1.087004] usb usb2-port3: peered to usb1-port6 >>>>> [ 1.087713] usb: failed to peer usb2-port4 and usb1-port6 by >>>>> location (usb2-port4:none) (usb1-port6:usb2-port3) >>>>> [ 1.087715] usb usb2-port4: failed to peer to usb1-port6 (-16) >>>>> [ 1.087716] usb: port power management may be unreliable >>>>> [ 1.088377] usb: failed to peer usb2-port5 and usb1-port6 by >>>>> location (usb2-port5:none) (usb1-port6:usb2-port3) >>>>> [ 1.088379] usb usb2-port5: failed to peer to usb1-port6 (-16) >>>>> [ 1.089017] usb: failed to peer usb2-port6 and usb1-port6 by >>>>> location (usb2-port6:none) (usb1-port6:usb2-port3) >>>>> [ 1.089018] usb usb2-port6: failed to peer to usb1-port6 (-16) >>>> >>>> >>>> Other than your internal hub not liking to be a peer (which seems like a >>>> BIOS/ACPI issue, right Mathias), I don't see an error here. Are things >>>> working properly? > > No, actually. > > The USB 3.0 ports seem to work fine, although I haven't tried > suspending with a device inserted. > > The USB Type C port is presently screwed up. I have a Realtek USB C > to Ethernet adapter. If I plug it in, nothing shows up in the logs at > all. If I suspend while it's plugged in, the screen turns off and the > system freezes hard without going to sleep. > > The Realtek adapter used to work, but that was on an older kernel > (4.3?) and a different BIOS version. > >> >> >> Probably. >> The "by location" message in the log reveals that the peering >> is based on ACPI DSDT table _PLD entries (Physical Device Location). >> >> usb2 ports 3-6 are all peered with usb1 port6. >> First two ports appear to be sane (usb1_port1 <->usb2_port1) >> >> How many physical ports does the DELL XPS have visible and connectable? > > There are: > > - Two Super Speed ports. (If I'm understanding correctly, one is 1-1 > and one is 1-2.) > - One USB Type C port (Alpine Ridge) > - Two internal M.2 ports > > One of the M.2 ports has an Intel 7265 plugged in, and that's the > Bluetooth device. The other one has an nvme device plugged in, and I > have no idea whether USB is wired up. > > The Intel 7265 is "removable" in the sense that I personally inserted > it into the port (with the power off, of course). > >> >> The ACPI DSDt _UPC entry describes if a port is hardwired or hotplug, and >> the >> hub descriptor DeviceRemovable field are also involved in all this. >> The log also shows changing the built in bluetooth and webcam to removable >> which >> is a bit suspicious >> >> >>> >>> >>> I think so, but I haven't tested with a USB device plugged in across >>> suspend/resume. I do get this on resume, though: >>> >>> [ +0.008245] ACPI: Waking up from system sleep state S3 >>> [ +0.137335] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI >>> [ +0.000117] PM: noirq resume of devices complete after 12.890 msecs >>> [ +0.011969] PM: early resume of devices complete after 11.890 msecs >>> [ +0.000345] usb usb1: root hub lost power or was reset >>> [ +0.000005] usb usb2: root hub lost power or was reset >>> [ +0.005946] rtc_cmos 00:01: System wakeup disabled by ACPI >>> [ +0.364455] usb 1-3: reset full-speed USB device number 2 using xhci_hcd >>> [ +0.318243] usb 1-5: reset high-speed USB device number 3 using xhci_hcd >>> [ +0.208028] PM: resume of devices complete after 896.974 msecs >>> [ +0.000109] usb 1-3:1.0: rebind failed: -517 >>> [ +0.000007] usb 1-3:1.1: rebind failed: -517 >> >> >> was usb 1-3 the bluetooth device? > > [ +0.044127] usb 1-3: new full-speed USB device number 2 using xhci_hcd > [ +0.166395] usb 1-3: New USB device found, idVendor=8087, idProduct=0a2a > [ +0.000009] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > > So, yes, I think so. Right now, 1-3:1.0 and 1-3:1.1 are both bound by btusb. > > I attached the DSDT. > > I have the ACPI debugger working, so I can dump things if that would be helpful. > > --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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
