On Fri, Jun 17, 2016 at 12:25 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Fri, Jun 17, 2016 at 11:46 AM, <Mario_Limonciello@xxxxxxxx> wrote: >>> -----Original Message----- >>> From: Andy Lutomirski [mailto:luto@xxxxxxxxxxxxxx] >>> Sent: Thursday, June 16, 2016 1:41 PM >>> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> >>> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Andy Lutomirski >>> <luto@xxxxxxxxxx>; Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>; USB >>> list <linux-usb@xxxxxxxxxxxxxxx>; Mathias Nyman >>> <mathias.nyman@xxxxxxxxx>; Dominguez, Jared >>> <Jared_Dominguez@xxxxxxxx> >>> Subject: Re: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake) >>> >>> On Sun, Mar 13, 2016 at 7:29 PM, Mario Limonciello >>> <mario_limonciello@xxxxxxxx> wrote: >>> > >>> > >>> > On 03/12/2016 02:33 PM, Andy Lutomirski wrote: >>> >> On Sat, Mar 12, 2016 at 11:35 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> >>> wrote: >>> >> Got it. I was barking up the wrong tree. >>> >> >>> >> Q: What happens if _Q66 runs concurrently with itself: >>> >> >>> >> A: >>> >> >>> >> Method (_Q66, 0, NotSerialized) // _Qxx: EC Query >>> >> { >>> >> Acquire (PATM, 0x0064) >>> >> If ((ECRD != One)) >>> >> { >>> >> Return (Zero) >>> >> } >>> >> >>> >> NEVT () >>> >> Release (PATM) >>> >> Return (Zero) >>> >> } >>> >> >>> >> The first one acquires PATM. The second one fails to acquire PATM due >>> >> to the timeout, does something potentially harmful when it reenters >>> >> NEVT (not sure -- maybe it's fine), then blows up when it tries to >>> >> release PATM, which it doesn't hold. >>> >> >>> >> --Andy >>> > Andy, >>> > >>> > Our team has confirmed this mistake and will issue a fix in a future >>> > BIOS. For now if you want to build your own DSDT to see if this is >>> > causing your type-C problems the Release(PATM) will be inserted in the >>> > obvious location. >>> > >>> > FWIW this issue will affect many platforms in this generation. (XPS >>> > 9550, XPS 9350, Precision 5510, and more) >>> > >>> >>> FYI: the H_EC.CHRG issue seems to be fixed in 1.4.3. The PATM issue >>> is still there by inspection of the code, although I haven't gotten >>> unlucky enough to trigger it yet. >> >> Thanks for the heads up. I'll poke the team and find out if it was pushed >> out, or it was a different fix than previously planned. If you trigger it and >> it's still leading to any problems let me know. >> > > > I hit it again. I haven't seen any observable problem yet, but I also > don't have anything connected to the USB-C port right now. (I don't > know what _Q66 is used for, so maybe it has nothing to do with USB-C. > But it's certainly not doing whatever it's supposed to do correctly > given this bug. > > [ +0.037295] ACPI Error: Cannot release Mutex [PATM], not acquired > (20160108/exmutex-393) > > [ +0.000011] No Local Variables are initialized for method [_Q66] > > [ +0.000002] No Arguments are initialized for method [_Q66] > > [ +0.000003] ACPI Error: Method parse/execution failed > [\_SB.PCI0.LPCB.ECDV._Q66] (Node ffff8802760ec8c0), AE_AML_MUTEX_NOT_A > > --Andy I got a DA200 adapter. When I plugged it in, it said: [106415.096022] ACPI Error: [SPRT] Namespace lookup failure, AE_ALREADY_EXISTS (20160108/dswload2-330) [106415.096050] No Local Variables are initialized for method [_E42] [106415.096057] No Arguments are initialized for method [_E42] [106415.096063] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160108/psobject-227) [106415.096071] ACPI Error: Method parse/execution failed [\_GPE._E42] (Node ffff8802760dbe38), AE_ALREADY_EXISTS (20160108/psparse-542) [106415.096085] ACPI Error: Method parse/execution failed [\_GPE._E42] (Node ffff8802760dbe38), AE_ALREADY_EXISTS (20160108/psparse-542) [106415.096104] ACPI Exception: AE_ALREADY_EXISTS, while evaluating GPE method [_E42] (20160108/evgpe-592) Other than that, it seems to work, at least as far as I can tell without connecting the other end to anything. --Andy -- 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
