From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA695C432C0 for ; Fri, 22 Nov 2019 00:13:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 969D620674 for ; Fri, 22 Nov 2019 00:13:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LUn0xest" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726698AbfKVANs (ORCPT ); Thu, 21 Nov 2019 19:13:48 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:40827 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726038AbfKVANs (ORCPT ); Thu, 21 Nov 2019 19:13:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574381625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uN54nyKovZpjX15ad46fYr/x8ehKgPmORA/aMiVni9I=; b=LUn0xestKOl0kI7IqOgh42JRTaKemfrklycFY85iqrr/nG/TskSn4cfSlXgpVCOwjDx8vC eXL8kjaibfbUG1sEmbZjt4TwAJgSrjispBQvNb8iFvgErpDGy7ezPJ3Su73t/5lzD35cuX yViCgJDlB7QSJPiyWbIjQQ2iUEme4po= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-66-JmWsWDb5NFaxsFsZva95JA-1; Thu, 21 Nov 2019 19:13:44 -0500 Received: by mail-qv1-f69.google.com with SMTP id m12so3506347qvv.8 for ; Thu, 21 Nov 2019 16:13:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zw+Oguaqsrzx3D3QkM2PFuC8jKyKAZCHmY4jQUCNjDs=; b=cyQbKv8wOgFbyW6XdremzvyNnPcLWiDBBWnj3EyAAHC6BOL/y7yxWiiTSUJIaMWwRc nC5PbVeNWicIxoUW+20jOQ2lwXA7JPN9KjSitX2/vHCbRRil4eNK3xJ00hg+zCNWOgFE /3BaeqxxGiMr2ahocTJKlKucBlhn3w9+c/JqRRySO8D67FcdHs2zQF3Fz3JE0nsSH36o Rhjj+maedCHbgBO6ygIo/TfCgLds5SVB2qgqT3tP8FuZP3PRml2ynoZHpuPhZOOsckdh nS+b73aeQZ2O2ql0DO81unHYflqJf9ppkjUUZlpt0PxorIbSGq9RuQWLN2Lo/jr5eUQC IUfw== X-Gm-Message-State: APjAAAWGWiFcy6tUe+dQGIzlZ0B7DRfCmEmzSOTO2bNPByhnvlPfBdZr P8FogwCPo7DiaUlSB4y2eXJG5L1APSyAejGMvXW+XNIy4r2zFbBSdbOtNw1ErVjYWvxYccpIMQK qXzvhhu3uXAYu9tun6ddqeIqfhMri2ZiYbrPb9hcS X-Received: by 2002:a0c:baad:: with SMTP id x45mr10952472qvf.230.1574381623549; Thu, 21 Nov 2019 16:13:43 -0800 (PST) X-Google-Smtp-Source: APXvYqxQeNbFPjt9g+SPOPeQ04yvEr8s+o4BozjzIBZZ3TrnGaEiSiHTX2apI5nYqFjPEWJt1G9UpqEUlJOEWQETsLY= X-Received: by 2002:a0c:baad:: with SMTP id x45mr10952438qvf.230.1574381622981; Thu, 21 Nov 2019 16:13:42 -0800 (PST) MIME-Version: 1.0 References: <20191120155301.GL11621@lahna.fi.intel.com> <20191121112821.GU11621@lahna.fi.intel.com> <20191121114610.GW11621@lahna.fi.intel.com> <20191121125236.GX11621@lahna.fi.intel.com> <20191121194942.GY11621@lahna.fi.intel.com> In-Reply-To: From: Karol Herbst Date: Fri, 22 Nov 2019 01:13:31 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: "Rafael J. Wysocki" Cc: Mika Westerberg , Bjorn Helgaas , LKML , Lyude Paul , "Rafael J . Wysocki" , Linux PCI , Linux PM , dri-devel , nouveau , Dave Airlie , Mario Limonciello X-MC-Unique: JmWsWDb5NFaxsFsZva95JA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org so while trying to test with d3cold disabled, I noticed that I run into the exact same error. And I verified that the \_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be turned on. On Thu, Nov 21, 2019 at 11:50 PM Karol Herbst wrote: > > On Thu, Nov 21, 2019 at 11:39 PM Rafael J. Wysocki wr= ote: > > > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > > wrote: > > > > > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wro= te: > > > > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki= wrote: > > > > > > > > > > last week or so I found systems where the GPU was under= the "PCI > > > > > > > > > > Express Root Port" (name from lspci) and on those syste= ms all of that > > > > > > > > > > seems to work. So I am wondering if it's indeed just th= e 0x1901 one, > > > > > > > > > > which also explains Mikas case that Thunderbolt stuff w= orks as devices > > > > > > > > > > never get populated under this particular bridge contro= ller, but under > > > > > > > > > > those "Root Port"s > > > > > > > > > > > > > > > > > > It always is a PCIe port, but its location within the SoC= may matter. > > > > > > > > > > > > > > > > Exactly. Intel hardware has PCIe ports on CPU side (these a= re called > > > > > > > > PEG, PCI Express Graphics, ports), and the PCH side. I thin= k the IP is > > > > > > > > still the same. > > > > > > > > > > > > > > > > > Also some custom AML-based power management is involved a= nd that may > > > > > > > > > be making specific assumptions on the configuration of th= e SoC and the > > > > > > > > > GPU at the time of its invocation which unfortunately are= not known to > > > > > > > > > us. > > > > > > > > > > > > > > > > > > However, it looks like the AML invoked to power down the = GPU from > > > > > > > > > acpi_pci_set_power_state() gets confused if it is not in = PCI D0 at > > > > > > > > > that point, so it looks like that AML tries to access dev= ice memory on > > > > > > > > > the GPU (beyond the PCI config space) or similar which is= not > > > > > > > > > accessible in PCI power states below D0. > > > > > > > > > > > > > > > > Or the PCI config space of the GPU when the parent root por= t is in D3hot > > > > > > > > (as it is the case here). Also then the GPU config space is= not > > > > > > > > accessible. > > > > > > > > > > > > > > Why would the parent port be in D3hot at that point? Wouldn'= t that be > > > > > > > a suspend ordering violation? > > > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > > > OK > > > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the G= PU > > > itself is not described in ACPI tables at all. > > > > OK > > > > > > > > then the root port and then turn > > > > > > off the power resource (which is attached to the root port) res= ulting > > > > > > the topology entering D3cold. > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > port's _PR3 power resource or something else? > > > > > > The root port's _OFF method for the power resource returned by its _P= R3. > > > > OK, so without the $subject patch we (1) program the downstream > > component (GPU) into D3hot, then we (2) program the port holding it > > into D3hot and then we (3) let the AML (_OFF for the power resource > > listed by _PR3 under the port object) run. > > > > Something strange happens at this point (and I guess that _OFF doesn't > > even reach the point where it removes power from the port which is why > > we see a lock-up). > > > > it does though. I will post the data shortly (with the change in power > consumption), as I also want to do the ACPI traces now. > > > We know that skipping (1) makes things work and we kind of suspect > > that skipping (3) would make things work either, but what about doing > > (1) and (3) without (2)? > > > > > > > Basically the difference is that when Windows 7 or Linux (the _RE= V=3D=3D5 > > > > > check) then we directly do link disable whereas in Windows 8+ we = invoke > > > > > LKDS() method that puts the link into L2/L3. None of the fields t= hey > > > > > access seem to touch the GPU itself. > > > > > > > > So that may be where the problem is. > > > > > > > > Putting the downstream component into PCI D[1-3] is expected to put > > > > the link into L1, so I'm not sure how that plays with the later > > > > attempt to put it into L2/L3 Ready. > > > > > > That should be fine. What I've seen the link goes into L1 when > > > downstream component is put to D-state (not D0) and then it is put ba= ck > > > to L0 when L2/3 ready is propagated. Eventually it goes into L2 or L3= . > > > > Well, that's the expected behavior, but the observed behavior isn't as > > expected. :-) > > > > > > Also, L2/L3 Ready is expected to be transient, so finally power sho= uld > > > > be removed somehow. > > > > > > There is GPIO for both power and PERST, I think the line here: > > > > > > \_SB.SGOV (0x01010004, Zero) > > > > > > is the one that removes power. > > > > OK > > > > > > > LKDS() for the first PEG port looks like this: > > > > > > > > > > P0L2 =3D One > > > > > Sleep (0x10) > > > > > Local0 =3D Zero > > > > > While (P0L2) > > > > > { > > > > > If ((Local0 > 0x04)) > > > > > { > > > > > Break > > > > > } > > > > > > > > > > Sleep (0x10) > > > > > Local0++ > > > > > } > > > > > > > > > > One thing that comes to mind is that the loop can end even if P0L= 2 is > > > > > not cleared as it does only 5 iterations with 16 ms sleep between= . Maybe > > > > > Sleep() is implemented differently in Windows? I mean Linux may b= e > > > > > "faster" here and return prematurely and if we leave the port int= o D0 > > > > > this does not happen, or something. I'm just throwing out ideas := ) > > > > > > > > But this actually works for the downstream component in D0, doesn't= it? > > > > > > It does and that leaves the link in L0 so it could be that then the > > > above AML works better or something. > > > > That would be my guess. > > > > > That reminds me, ASPM may have something to do with this as well. > > > > Not really if D-states are involved. > > > > > > Also, if the downstream component is in D0, the port actually shoul= d > > > > stay in D0 too, so what would happen with the $subject patch applie= d? > > > > > > Parent port cannot be lower D-state than the child so I agree it shou= ld > > > stay in D0 as well. However, it seems that what happens is that the > > > issue goes away :) > > > > Well, at least this is kind of out of the spec. > > > > Note that pci_pm_suspend_noirq() won't let the port go into D3 if the > > downstream device is in D0, so the $subject patch will not work as > > expected in the suspend-to-idle case. > > > > Also we really should make up our minds on whether or not to force > > PCIe ports to stay in D0 when downstream devices are in D0 and be > > consequent about that. Right now we do one thing during system-wide > > suspend and the other one in PM-runtime, which is confusing. > > > > The current design is mostly based on the PCI PM Spec 1.2, so it would > > be consequent to follow system-wide suspend in PM-runtime and avoid > > putting PCIe ports holding devices in D0 into any low-power states. > > but that would make the approach in the $subject patch ineffective. > > > > Moreover, the fact that there are separate branches for "Windows 7" > > and "Windows 8+" kind of suggest a change in the expected behavior > > between Windows 7 and Windows 8, from the AML perspective. I would > > guess that Windows 7 followed PCI PM 1.2 and Windows 8 (and later) > > does something else. Now, the structure of the "Windows 8+" branch > > described by you suggests that, at least in the cases when it is going > > to remove power from the port eventually, it goes straight for the > > link preparation (the L2/L3 Ready transition) and power removal > > without bothering to program the downstream device and port into D3hot > > (because that's kind of redundant). > > > > That hypothetical "Windows 8+" approach may really work universally, > > because it doesn't seem to break any rules (going straight from D0 to > > D3cold is not disallowed and doing that for both a port and a > > downstream device at the same time is kind of OK either, as long as > > the link is ready for that). > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CB4AC432C0 for ; Fri, 22 Nov 2019 00:13:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 672CA20674 for ; Fri, 22 Nov 2019 00:13:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 672CA20674 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C8D686E1D2; Fri, 22 Nov 2019 00:13:47 +0000 (UTC) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7AA416E1D2 for ; Fri, 22 Nov 2019 00:13:46 +0000 (UTC) Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-82-K__jvD8qMuqYECK7h_vfuA-1; Thu, 21 Nov 2019 19:13:44 -0500 Received: by mail-qv1-f72.google.com with SMTP id m43so3487003qvc.17 for ; Thu, 21 Nov 2019 16:13:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zw+Oguaqsrzx3D3QkM2PFuC8jKyKAZCHmY4jQUCNjDs=; b=m3iG4Zg8nMewLCci+i2vv6sMmly8EynhfKYholNFeXtYdrkuJ35WSzlMBpbvMZ2D2B L6tqebH4613OaEwcrXocPn12CWJsA6vtunoDrwLtZsYO+3xFYjwmsMQ7TMlBegT5aWi5 ZCBG71Y0NIc0sdpgKU+NMuwBl43N/IAtJDg+XajGkvo68KL2yNV9E1awYHmBbyYesTAF +YmOINRIiEhlyKem0wEB2MsLHceid/Pm13iPsuffzqbeVVnbSDK1X7ANr9vWj+FJX/uV iRbWlPYte6y0vm/QD/8eRSVOtrifm39Y54QUKj8VCvRW2xoveEjLrHr0CaDhnAy2WXtY Na1Q== X-Gm-Message-State: APjAAAUYmKVKf0e1t/cmrF4yCR3DTINRYkp2FrUSywO1d5tb50Q+Zi2T fjrB+LA30EuTTyVCWg4ijSSqfaWRQ7hDOU9JJAmZN+ZE0MRW7PvFi3yrxCrn6alrXzVOb6lhFKn PRqoasox/QDiIhml4KZ2DB46fo7dXNAxBOmx13Q7o6qos X-Received: by 2002:a0c:baad:: with SMTP id x45mr10952479qvf.230.1574381623554; Thu, 21 Nov 2019 16:13:43 -0800 (PST) X-Google-Smtp-Source: APXvYqxQeNbFPjt9g+SPOPeQ04yvEr8s+o4BozjzIBZZ3TrnGaEiSiHTX2apI5nYqFjPEWJt1G9UpqEUlJOEWQETsLY= X-Received: by 2002:a0c:baad:: with SMTP id x45mr10952438qvf.230.1574381622981; Thu, 21 Nov 2019 16:13:42 -0800 (PST) MIME-Version: 1.0 References: <20191120155301.GL11621@lahna.fi.intel.com> <20191121112821.GU11621@lahna.fi.intel.com> <20191121114610.GW11621@lahna.fi.intel.com> <20191121125236.GX11621@lahna.fi.intel.com> <20191121194942.GY11621@lahna.fi.intel.com> In-Reply-To: From: Karol Herbst Date: Fri, 22 Nov 2019 01:13:31 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: "Rafael J. Wysocki" X-MC-Unique: K__jvD8qMuqYECK7h_vfuA-1 X-Mimecast-Spam-Score: 0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574381625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uN54nyKovZpjX15ad46fYr/x8ehKgPmORA/aMiVni9I=; b=LUn0xestKOl0kI7IqOgh42JRTaKemfrklycFY85iqrr/nG/TskSn4cfSlXgpVCOwjDx8vC eXL8kjaibfbUG1sEmbZjt4TwAJgSrjispBQvNb8iFvgErpDGy7ezPJ3Su73t/5lzD35cuX yViCgJDlB7QSJPiyWbIjQQ2iUEme4po= X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux PM , Linux PCI , Mika Westerberg , Mario Limonciello , "Rafael J . Wysocki" , LKML , dri-devel , Bjorn Helgaas , nouveau Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Message-ID: <20191122001331.lKgyeyNkp7T8AjFIpNv18Oeo_cN0xmnRsdVfD_0_lBw@z> c28gd2hpbGUgdHJ5aW5nIHRvIHRlc3Qgd2l0aCBkM2NvbGQgZGlzYWJsZWQsIEkgbm90aWNlZCB0 aGF0IEkgcnVuCmludG8gdGhlIGV4YWN0IHNhbWUgZXJyb3IuIEFuZCBJIHZlcmlmaWVkIHRoYXQg dGhlClxfU0IuUENJMC5QRUcwLlBHMDAuX1NUQSByZXR1cm5zIDEsIHdoaWNoIGluZGljYXRlcyBp dCBzaG91bGQgc3RpbGwgYmUKdHVybmVkIG9uLgoKT24gVGh1LCBOb3YgMjEsIDIwMTkgYXQgMTE6 NTAgUE0gS2Fyb2wgSGVyYnN0IDxraGVyYnN0QHJlZGhhdC5jb20+IHdyb3RlOgo+Cj4gT24gVGh1 LCBOb3YgMjEsIDIwMTkgYXQgMTE6MzkgUE0gUmFmYWVsIEouIFd5c29ja2kgPHJhZmFlbEBrZXJu ZWwub3JnPiB3cm90ZToKPiA+Cj4gPiBPbiBUaHUsIE5vdiAyMSwgMjAxOSBhdCA4OjQ5IFBNIE1p a2EgV2VzdGVyYmVyZwo+ID4gPG1pa2Eud2VzdGVyYmVyZ0BpbnRlbC5jb20+IHdyb3RlOgo+ID4g Pgo+ID4gPiBPbiBUaHUsIE5vdiAyMSwgMjAxOSBhdCAwNDo0MzoyNFBNICswMTAwLCBSYWZhZWwg Si4gV3lzb2NraSB3cm90ZToKPiA+ID4gPiBPbiBUaHUsIE5vdiAyMSwgMjAxOSBhdCAxOjUyIFBN IE1pa2EgV2VzdGVyYmVyZwo+ID4gPiA+IDxtaWthLndlc3RlcmJlcmdAaW50ZWwuY29tPiB3cm90 ZToKPiA+ID4gPiA+Cj4gPiA+ID4gPiBPbiBUaHUsIE5vdiAyMSwgMjAxOSBhdCAwMTo0NjoxNFBN ICswMjAwLCBNaWthIFdlc3RlcmJlcmcgd3JvdGU6Cj4gPiA+ID4gPiA+IE9uIFRodSwgTm92IDIx LCAyMDE5IGF0IDEyOjM0OjIyUE0gKzAxMDAsIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+ID4g PiA+ID4gPiA+IE9uIFRodSwgTm92IDIxLCAyMDE5IGF0IDEyOjI4IFBNIE1pa2EgV2VzdGVyYmVy Zwo+ID4gPiA+ID4gPiA+IDxtaWthLndlc3RlcmJlcmdAaW50ZWwuY29tPiB3cm90ZToKPiA+ID4g PiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiBPbiBXZWQsIE5vdiAyMCwgMjAxOSBhdCAxMToyOToz M1BNICswMTAwLCBSYWZhZWwgSi4gV3lzb2NraSB3cm90ZToKPiA+ID4gPiA+ID4gPiA+ID4gPiBs YXN0IHdlZWsgb3Igc28gSSBmb3VuZCBzeXN0ZW1zIHdoZXJlIHRoZSBHUFUgd2FzIHVuZGVyIHRo ZSAiUENJCj4gPiA+ID4gPiA+ID4gPiA+ID4gRXhwcmVzcyBSb290IFBvcnQiIChuYW1lIGZyb20g bHNwY2kpIGFuZCBvbiB0aG9zZSBzeXN0ZW1zIGFsbCBvZiB0aGF0Cj4gPiA+ID4gPiA+ID4gPiA+ ID4gc2VlbXMgdG8gd29yay4gU28gSSBhbSB3b25kZXJpbmcgaWYgaXQncyBpbmRlZWQganVzdCB0 aGUgMHgxOTAxIG9uZSwKPiA+ID4gPiA+ID4gPiA+ID4gPiB3aGljaCBhbHNvIGV4cGxhaW5zIE1p a2FzIGNhc2UgdGhhdCBUaHVuZGVyYm9sdCBzdHVmZiB3b3JrcyBhcyBkZXZpY2VzCj4gPiA+ID4g PiA+ID4gPiA+ID4gbmV2ZXIgZ2V0IHBvcHVsYXRlZCB1bmRlciB0aGlzIHBhcnRpY3VsYXIgYnJp ZGdlIGNvbnRyb2xsZXIsIGJ1dCB1bmRlcgo+ID4gPiA+ID4gPiA+ID4gPiA+IHRob3NlICJSb290 IFBvcnQicwo+ID4gPiA+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gPiBJdCBhbHdheXMgaXMg YSBQQ0llIHBvcnQsIGJ1dCBpdHMgbG9jYXRpb24gd2l0aGluIHRoZSBTb0MgbWF5IG1hdHRlci4K PiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiBFeGFjdGx5LiBJbnRlbCBoYXJkd2FyZSBo YXMgUENJZSBwb3J0cyBvbiBDUFUgc2lkZSAodGhlc2UgYXJlIGNhbGxlZAo+ID4gPiA+ID4gPiA+ ID4gUEVHLCBQQ0kgRXhwcmVzcyBHcmFwaGljcywgcG9ydHMpLCBhbmQgdGhlIFBDSCBzaWRlLiBJ IHRoaW5rIHRoZSBJUCBpcwo+ID4gPiA+ID4gPiA+ID4gc3RpbGwgdGhlIHNhbWUuCj4gPiA+ID4g PiA+ID4gPgo+ID4gPiA+ID4gPiA+ID4gPiBBbHNvIHNvbWUgY3VzdG9tIEFNTC1iYXNlZCBwb3dl ciBtYW5hZ2VtZW50IGlzIGludm9sdmVkIGFuZCB0aGF0IG1heQo+ID4gPiA+ID4gPiA+ID4gPiBi ZSBtYWtpbmcgc3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhl IFNvQyBhbmQgdGhlCj4gPiA+ID4gPiA+ID4gPiA+IEdQVSBhdCB0aGUgdGltZSBvZiBpdHMgaW52 b2NhdGlvbiB3aGljaCB1bmZvcnR1bmF0ZWx5IGFyZSBub3Qga25vd24gdG8KPiA+ID4gPiA+ID4g PiA+ID4gdXMuCj4gPiA+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gPiA+IEhvd2V2ZXIsIGl0 IGxvb2tzIGxpa2UgdGhlIEFNTCBpbnZva2VkIHRvIHBvd2VyIGRvd24gdGhlIEdQVSBmcm9tCj4g PiA+ID4gPiA+ID4gPiA+IGFjcGlfcGNpX3NldF9wb3dlcl9zdGF0ZSgpIGdldHMgY29uZnVzZWQg aWYgaXQgaXMgbm90IGluIFBDSSBEMCBhdAo+ID4gPiA+ID4gPiA+ID4gPiB0aGF0IHBvaW50LCBz byBpdCBsb29rcyBsaWtlIHRoYXQgQU1MIHRyaWVzIHRvIGFjY2VzcyBkZXZpY2UgbWVtb3J5IG9u Cj4gPiA+ID4gPiA+ID4gPiA+IHRoZSBHUFUgKGJleW9uZCB0aGUgUENJIGNvbmZpZyBzcGFjZSkg b3Igc2ltaWxhciB3aGljaCBpcyBub3QKPiA+ID4gPiA+ID4gPiA+ID4gYWNjZXNzaWJsZSBpbiBQ Q0kgcG93ZXIgc3RhdGVzIGJlbG93IEQwLgo+ID4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiA+ IE9yIHRoZSBQQ0kgY29uZmlnIHNwYWNlIG9mIHRoZSBHUFUgd2hlbiB0aGUgcGFyZW50IHJvb3Qg cG9ydCBpcyBpbiBEM2hvdAo+ID4gPiA+ID4gPiA+ID4gKGFzIGl0IGlzIHRoZSBjYXNlIGhlcmUp LiBBbHNvIHRoZW4gdGhlIEdQVSBjb25maWcgc3BhY2UgaXMgbm90Cj4gPiA+ID4gPiA+ID4gPiBh Y2Nlc3NpYmxlLgo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gV2h5IHdvdWxkIHRoZSBwYXJl bnQgcG9ydCBiZSBpbiBEM2hvdCBhdCB0aGF0IHBvaW50PyAgV291bGRuJ3QgdGhhdCBiZQo+ID4g PiA+ID4gPiA+IGEgc3VzcGVuZCBvcmRlcmluZyB2aW9sYXRpb24/Cj4gPiA+ID4gPiA+Cj4gPiA+ ID4gPiA+IE5vLiBXZSBwdXQgdGhlIEdQVSBpbnRvIEQzaG90IGZpcnN0LAo+ID4gPiA+Cj4gPiA+ ID4gT0sKPiA+ID4gPgo+ID4gPiA+IERvZXMgdGhpcyBpbnZvbHZlIGFueSBBTUwsIGxpa2UgYSBf UFMzIHVuZGVyIHRoZSBHUFUgb2JqZWN0Pwo+ID4gPgo+ID4gPiBJIGRvbid0IHNlZSBfUFMzIChu b3IgX1BTMCkgZm9yIHRoYXQgb2JqZWN0LiBJZiBJIHJlYWQgaXQgcmlnaHQgdGhlIEdQVQo+ID4g PiBpdHNlbGYgaXMgbm90IGRlc2NyaWJlZCBpbiBBQ1BJIHRhYmxlcyBhdCBhbGwuCj4gPgo+ID4g T0sKPiA+Cj4gPiA+ID4gPiA+IHRoZW4gdGhlIHJvb3QgcG9ydCBhbmQgdGhlbiB0dXJuCj4gPiA+ ID4gPiA+IG9mZiB0aGUgcG93ZXIgcmVzb3VyY2UgKHdoaWNoIGlzIGF0dGFjaGVkIHRvIHRoZSBy b290IHBvcnQpIHJlc3VsdGluZwo+ID4gPiA+ID4gPiB0aGUgdG9wb2xvZ3kgZW50ZXJpbmcgRDNj b2xkLgo+ID4gPiA+ID4KPiA+ID4gPiA+IEkgZG9uJ3Qgc2VlIHRoYXQgaGFwcGVuaW5nIGluIHRo ZSBBTUwgdGhvdWdoLgo+ID4gPiA+Cj4gPiA+ID4gV2hpY2ggQU1MIGRvIHlvdSBtZWFuLCBzcGVj aWZpY2FsbHk/ICBUaGUgX09GRiBtZXRob2QgZm9yIHRoZSByb290Cj4gPiA+ID4gcG9ydCdzIF9Q UjMgcG93ZXIgcmVzb3VyY2Ugb3Igc29tZXRoaW5nIGVsc2U/Cj4gPiA+Cj4gPiA+IFRoZSByb290 IHBvcnQncyBfT0ZGIG1ldGhvZCBmb3IgdGhlIHBvd2VyIHJlc291cmNlIHJldHVybmVkIGJ5IGl0 cyBfUFIzLgo+ID4KPiA+IE9LLCBzbyB3aXRob3V0IHRoZSAkc3ViamVjdCBwYXRjaCB3ZSAoMSkg cHJvZ3JhbSB0aGUgZG93bnN0cmVhbQo+ID4gY29tcG9uZW50IChHUFUpIGludG8gRDNob3QsIHRo ZW4gd2UgKDIpIHByb2dyYW0gdGhlIHBvcnQgaG9sZGluZyBpdAo+ID4gaW50byBEM2hvdCBhbmQg dGhlbiB3ZSAoMykgbGV0IHRoZSBBTUwgKF9PRkYgZm9yIHRoZSBwb3dlciByZXNvdXJjZQo+ID4g bGlzdGVkIGJ5IF9QUjMgdW5kZXIgdGhlIHBvcnQgb2JqZWN0KSBydW4uCj4gPgo+ID4gU29tZXRo aW5nIHN0cmFuZ2UgaGFwcGVucyBhdCB0aGlzIHBvaW50IChhbmQgSSBndWVzcyB0aGF0IF9PRkYg ZG9lc24ndAo+ID4gZXZlbiByZWFjaCB0aGUgcG9pbnQgd2hlcmUgaXQgcmVtb3ZlcyBwb3dlciBm cm9tIHRoZSBwb3J0IHdoaWNoIGlzIHdoeQo+ID4gd2Ugc2VlIGEgbG9jay11cCkuCj4gPgo+Cj4g aXQgZG9lcyB0aG91Z2guIEkgd2lsbCBwb3N0IHRoZSBkYXRhIHNob3J0bHkgKHdpdGggdGhlIGNo YW5nZSBpbiBwb3dlcgo+IGNvbnN1bXB0aW9uKSwgYXMgSSBhbHNvIHdhbnQgdG8gZG8gdGhlIEFD UEkgdHJhY2VzIG5vdy4KPgo+ID4gV2Uga25vdyB0aGF0IHNraXBwaW5nICgxKSBtYWtlcyB0aGlu Z3Mgd29yayBhbmQgd2Uga2luZCBvZiBzdXNwZWN0Cj4gPiB0aGF0IHNraXBwaW5nICgzKSB3b3Vs ZCBtYWtlIHRoaW5ncyB3b3JrIGVpdGhlciwgYnV0IHdoYXQgYWJvdXQgZG9pbmcKPiA+ICgxKSBh bmQgKDMpIHdpdGhvdXQgKDIpPwo+ID4KPiA+ID4gPiA+IEJhc2ljYWxseSB0aGUgZGlmZmVyZW5j ZSBpcyB0aGF0IHdoZW4gV2luZG93cyA3IG9yIExpbnV4ICh0aGUgX1JFVj09NQo+ID4gPiA+ID4g Y2hlY2spIHRoZW4gd2UgZGlyZWN0bHkgZG8gbGluayBkaXNhYmxlIHdoZXJlYXMgaW4gV2luZG93 cyA4KyB3ZSBpbnZva2UKPiA+ID4gPiA+IExLRFMoKSBtZXRob2QgdGhhdCBwdXRzIHRoZSBsaW5r IGludG8gTDIvTDMuIE5vbmUgb2YgdGhlIGZpZWxkcyB0aGV5Cj4gPiA+ID4gPiBhY2Nlc3Mgc2Vl bSB0byB0b3VjaCB0aGUgR1BVIGl0c2VsZi4KPiA+ID4gPgo+ID4gPiA+IFNvIHRoYXQgbWF5IGJl IHdoZXJlIHRoZSBwcm9ibGVtIGlzLgo+ID4gPiA+Cj4gPiA+ID4gUHV0dGluZyB0aGUgZG93bnN0 cmVhbSBjb21wb25lbnQgaW50byBQQ0kgRFsxLTNdIGlzIGV4cGVjdGVkIHRvIHB1dAo+ID4gPiA+ IHRoZSBsaW5rIGludG8gTDEsIHNvIEknbSBub3Qgc3VyZSBob3cgdGhhdCBwbGF5cyB3aXRoIHRo ZSBsYXRlcgo+ID4gPiA+IGF0dGVtcHQgdG8gcHV0IGl0IGludG8gTDIvTDMgUmVhZHkuCj4gPiA+ Cj4gPiA+IFRoYXQgc2hvdWxkIGJlIGZpbmUuIFdoYXQgSSd2ZSBzZWVuIHRoZSBsaW5rIGdvZXMg aW50byBMMSB3aGVuCj4gPiA+IGRvd25zdHJlYW0gY29tcG9uZW50IGlzIHB1dCB0byBELXN0YXRl IChub3QgRDApIGFuZCB0aGVuIGl0IGlzIHB1dCBiYWNrCj4gPiA+IHRvIEwwIHdoZW4gTDIvMyBy ZWFkeSBpcyBwcm9wYWdhdGVkLiBFdmVudHVhbGx5IGl0IGdvZXMgaW50byBMMiBvciBMMy4KPiA+ Cj4gPiBXZWxsLCB0aGF0J3MgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLCBidXQgdGhlIG9ic2VydmVk IGJlaGF2aW9yIGlzbid0IGFzCj4gPiBleHBlY3RlZC4gOi0pCj4gPgo+ID4gPiA+IEFsc28sIEwy L0wzIFJlYWR5IGlzIGV4cGVjdGVkIHRvIGJlIHRyYW5zaWVudCwgc28gZmluYWxseSBwb3dlciBz aG91bGQKPiA+ID4gPiBiZSByZW1vdmVkIHNvbWVob3cuCj4gPiA+Cj4gPiA+IFRoZXJlIGlzIEdQ SU8gZm9yIGJvdGggcG93ZXIgYW5kIFBFUlNULCBJIHRoaW5rIHRoZSBsaW5lIGhlcmU6Cj4gPiA+ Cj4gPiA+ICAgXF9TQi5TR09WICgweDAxMDEwMDA0LCBaZXJvKQo+ID4gPgo+ID4gPiBpcyB0aGUg b25lIHRoYXQgcmVtb3ZlcyBwb3dlci4KPiA+Cj4gPiBPSwo+ID4KPiA+ID4gPiA+IExLRFMoKSBm b3IgdGhlIGZpcnN0IFBFRyBwb3J0IGxvb2tzIGxpa2UgdGhpczoKPiA+ID4gPiA+Cj4gPiA+ID4g PiAgICBQMEwyID0gT25lCj4gPiA+ID4gPiAgICBTbGVlcCAoMHgxMCkKPiA+ID4gPiA+ICAgIExv Y2FsMCA9IFplcm8KPiA+ID4gPiA+ICAgIFdoaWxlIChQMEwyKQo+ID4gPiA+ID4gICAgewo+ID4g PiA+ID4gICAgICAgICBJZiAoKExvY2FsMCA+IDB4MDQpKQo+ID4gPiA+ID4gICAgICAgICB7Cj4g PiA+ID4gPiAgICAgICAgICAgICBCcmVhawo+ID4gPiA+ID4gICAgICAgICB9Cj4gPiA+ID4gPgo+ ID4gPiA+ID4gICAgICAgICBTbGVlcCAoMHgxMCkKPiA+ID4gPiA+ICAgICAgICAgTG9jYWwwKysK PiA+ID4gPiA+ICAgIH0KPiA+ID4gPiA+Cj4gPiA+ID4gPiBPbmUgdGhpbmcgdGhhdCBjb21lcyB0 byBtaW5kIGlzIHRoYXQgdGhlIGxvb3AgY2FuIGVuZCBldmVuIGlmIFAwTDIgaXMKPiA+ID4gPiA+ IG5vdCBjbGVhcmVkIGFzIGl0IGRvZXMgb25seSA1IGl0ZXJhdGlvbnMgd2l0aCAxNiBtcyBzbGVl cCBiZXR3ZWVuLiBNYXliZQo+ID4gPiA+ID4gU2xlZXAoKSBpcyBpbXBsZW1lbnRlZCBkaWZmZXJl bnRseSBpbiBXaW5kb3dzPyBJIG1lYW4gTGludXggbWF5IGJlCj4gPiA+ID4gPiAiZmFzdGVyIiBo ZXJlIGFuZCByZXR1cm4gcHJlbWF0dXJlbHkgYW5kIGlmIHdlIGxlYXZlIHRoZSBwb3J0IGludG8g RDAKPiA+ID4gPiA+IHRoaXMgZG9lcyBub3QgaGFwcGVuLCBvciBzb21ldGhpbmcuIEknbSBqdXN0 IHRocm93aW5nIG91dCBpZGVhcyA6KQo+ID4gPiA+Cj4gPiA+ID4gQnV0IHRoaXMgYWN0dWFsbHkg d29ya3MgZm9yIHRoZSBkb3duc3RyZWFtIGNvbXBvbmVudCBpbiBEMCwgZG9lc24ndCBpdD8KPiA+ ID4KPiA+ID4gSXQgZG9lcyBhbmQgdGhhdCBsZWF2ZXMgdGhlIGxpbmsgaW4gTDAgc28gaXQgY291 bGQgYmUgdGhhdCB0aGVuIHRoZQo+ID4gPiBhYm92ZSBBTUwgd29ya3MgYmV0dGVyIG9yIHNvbWV0 aGluZy4KPiA+Cj4gPiBUaGF0IHdvdWxkIGJlIG15IGd1ZXNzLgo+ID4KPiA+ID4gVGhhdCByZW1p bmRzIG1lLCBBU1BNIG1heSBoYXZlIHNvbWV0aGluZyB0byBkbyB3aXRoIHRoaXMgYXMgd2VsbC4K PiA+Cj4gPiBOb3QgcmVhbGx5IGlmIEQtc3RhdGVzIGFyZSBpbnZvbHZlZC4KPiA+Cj4gPiA+ID4g QWxzbywgaWYgdGhlIGRvd25zdHJlYW0gY29tcG9uZW50IGlzIGluIEQwLCB0aGUgcG9ydCBhY3R1 YWxseSBzaG91bGQKPiA+ID4gPiBzdGF5IGluIEQwIHRvbywgc28gd2hhdCB3b3VsZCBoYXBwZW4g d2l0aCB0aGUgJHN1YmplY3QgcGF0Y2ggYXBwbGllZD8KPiA+ID4KPiA+ID4gUGFyZW50IHBvcnQg Y2Fubm90IGJlIGxvd2VyIEQtc3RhdGUgdGhhbiB0aGUgY2hpbGQgc28gSSBhZ3JlZSBpdCBzaG91 bGQKPiA+ID4gc3RheSBpbiBEMCBhcyB3ZWxsLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHdoYXQg aGFwcGVucyBpcyB0aGF0IHRoZQo+ID4gPiBpc3N1ZSBnb2VzIGF3YXkgOikKPiA+Cj4gPiBXZWxs LCBhdCBsZWFzdCB0aGlzIGlzIGtpbmQgb2Ygb3V0IG9mIHRoZSBzcGVjLgo+ID4KPiA+IE5vdGUg dGhhdCBwY2lfcG1fc3VzcGVuZF9ub2lycSgpIHdvbid0IGxldCB0aGUgcG9ydCBnbyBpbnRvIEQz IGlmIHRoZQo+ID4gZG93bnN0cmVhbSBkZXZpY2UgaXMgaW4gRDAsIHNvIHRoZSAkc3ViamVjdCBw YXRjaCB3aWxsIG5vdCB3b3JrIGFzCj4gPiBleHBlY3RlZCBpbiB0aGUgc3VzcGVuZC10by1pZGxl IGNhc2UuCj4gPgo+ID4gQWxzbyB3ZSByZWFsbHkgc2hvdWxkIG1ha2UgdXAgb3VyIG1pbmRzIG9u IHdoZXRoZXIgb3Igbm90IHRvIGZvcmNlCj4gPiBQQ0llIHBvcnRzIHRvIHN0YXkgaW4gRDAgd2hl biBkb3duc3RyZWFtIGRldmljZXMgYXJlIGluIEQwIGFuZCBiZQo+ID4gY29uc2VxdWVudCBhYm91 dCB0aGF0LiAgUmlnaHQgbm93IHdlIGRvIG9uZSB0aGluZyBkdXJpbmcgc3lzdGVtLXdpZGUKPiA+ IHN1c3BlbmQgYW5kIHRoZSBvdGhlciBvbmUgaW4gUE0tcnVudGltZSwgd2hpY2ggaXMgY29uZnVz aW5nLgo+ID4KPiA+IFRoZSBjdXJyZW50IGRlc2lnbiBpcyBtb3N0bHkgYmFzZWQgb24gdGhlIFBD SSBQTSBTcGVjIDEuMiwgc28gaXQgd291bGQKPiA+IGJlIGNvbnNlcXVlbnQgdG8gZm9sbG93IHN5 c3RlbS13aWRlIHN1c3BlbmQgaW4gUE0tcnVudGltZSBhbmQgYXZvaWQKPiA+IHB1dHRpbmcgUENJ ZSBwb3J0cyBob2xkaW5nIGRldmljZXMgaW4gRDAgaW50byBhbnkgbG93LXBvd2VyIHN0YXRlcy4K PiA+IGJ1dCB0aGF0IHdvdWxkIG1ha2UgdGhlIGFwcHJvYWNoIGluIHRoZSAkc3ViamVjdCBwYXRj aCBpbmVmZmVjdGl2ZS4KPiA+Cj4gPiBNb3Jlb3ZlciwgdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUg c2VwYXJhdGUgYnJhbmNoZXMgZm9yICJXaW5kb3dzIDciCj4gPiBhbmQgIldpbmRvd3MgOCsiIGtp bmQgb2Ygc3VnZ2VzdCBhIGNoYW5nZSBpbiB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IKPiA+IGJldHdl ZW4gV2luZG93cyA3IGFuZCBXaW5kb3dzIDgsIGZyb20gdGhlIEFNTCBwZXJzcGVjdGl2ZS4gIEkg d291bGQKPiA+IGd1ZXNzIHRoYXQgV2luZG93cyA3IGZvbGxvd2VkIFBDSSBQTSAxLjIgYW5kIFdp bmRvd3MgOCAoYW5kIGxhdGVyKQo+ID4gZG9lcyBzb21ldGhpbmcgZWxzZS4gIE5vdywgdGhlIHN0 cnVjdHVyZSBvZiB0aGUgIldpbmRvd3MgOCsiIGJyYW5jaAo+ID4gZGVzY3JpYmVkIGJ5IHlvdSBz dWdnZXN0cyB0aGF0LCBhdCBsZWFzdCBpbiB0aGUgY2FzZXMgd2hlbiBpdCBpcyBnb2luZwo+ID4g dG8gcmVtb3ZlIHBvd2VyIGZyb20gdGhlIHBvcnQgZXZlbnR1YWxseSwgaXQgZ29lcyBzdHJhaWdo dCBmb3IgdGhlCj4gPiBsaW5rIHByZXBhcmF0aW9uICh0aGUgTDIvTDMgUmVhZHkgdHJhbnNpdGlv bikgYW5kIHBvd2VyIHJlbW92YWwKPiA+IHdpdGhvdXQgYm90aGVyaW5nIHRvIHByb2dyYW0gdGhl IGRvd25zdHJlYW0gZGV2aWNlIGFuZCBwb3J0IGludG8gRDNob3QKPiA+IChiZWNhdXNlIHRoYXQn cyBraW5kIG9mIHJlZHVuZGFudCkuCj4gPgo+ID4gVGhhdCBoeXBvdGhldGljYWwgIldpbmRvd3Mg OCsiIGFwcHJvYWNoIG1heSByZWFsbHkgd29yayB1bml2ZXJzYWxseSwKPiA+IGJlY2F1c2UgaXQg ZG9lc24ndCBzZWVtIHRvIGJyZWFrIGFueSBydWxlcyAoZ29pbmcgc3RyYWlnaHQgZnJvbSBEMCB0 bwo+ID4gRDNjb2xkIGlzIG5vdCBkaXNhbGxvd2VkIGFuZCBkb2luZyB0aGF0IGZvciBib3RoIGEg cG9ydCBhbmQgYQo+ID4gZG93bnN0cmVhbSBkZXZpY2UgYXQgdGhlIHNhbWUgdGltZSBpcyBraW5k IG9mIE9LIGVpdGhlciwgYXMgbG9uZyBhcwo+ID4gdGhlIGxpbmsgaXMgcmVhZHkgZm9yIHRoYXQp Lgo+ID4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRy aS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRw czovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbA==