On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote: > 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 > Mathias, any ideas? -- 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
