On Mon, Mar 7, 2016 at 12:13 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 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?
>
I'm adding a couple Dell people.
Hi, Dell people-
Your latest DSDT has this blatantly buggy method:
Method (_Q66, 0, NotSerialized) // _Qxx: EC Query
{
Acquire (PATM, 0x0064)
If ((ECRD != One))
{
Return (Zero)
}
NEVT ()
Release (PATM)
Return (Zero)
}
At some point during boot (presumably), this runs with ECRD == 0,
causing PATM to be acquired and never released. Later on, something
involved in USB-C hotplug (I think -- I can occasionally trigger
errors during hotplug) breaks when it can't acquire PATM.
Could you ask your BIOS team to please add the obviously missing Release (PATM)?
I don't know if fixing this bug will solve all the USB-C issues, but
it seems unlikely to hurt. I'm going to try to get it to work with a
custom method, but I may or may not succeed.
--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
