From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751982AbdAaLkG (ORCPT <rfc822;w@1wt.eu>);
        Tue, 31 Jan 2017 06:40:06 -0500
Received: from mga09.intel.com ([134.134.136.24]:22842 "EHLO mga09.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751042AbdAaLjl (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 31 Jan 2017 06:39:41 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,314,1477983600"; 
   d="scan'208";a="59484283"
Subject: Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after
 suspend-resume (pm? i915? cpu/hotplug?)
To: imre.deak@intel.com
References: <CA+icZUVydvidHHeWn7=ni1Kxr0y1kaRLKMWCPQi2YY5c_xNL_Q@mail.gmail.com>
 <CAJZ5v0gp_BwxR+B3wtoLRh2B_ojY7cd9E5shJ8zsBeGL_LtnGg@mail.gmail.com>
 <CA+icZUVwTRCAGiO-5Q2uo8SETjHwwSmJ2Pxh56niWsbEVZfV7w@mail.gmail.com>
 <7e7ccb13-1db8-af76-9585-ca7bbdd04c55@intel.com>
 <20170131105800.GA8598@ideak-desk.fi.intel.com>
Cc: sedat.dilek@gmail.com, "Rafael J. Wysocki" <rafael@kernel.org>,
        Jani Nikula <jani.nikula@intel.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        intel-gfx <intel-gfx@lists.freedesktop.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>,
        Linux PM <linux-pm@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Chris Wilson <chris@chris-wilson.co.uk>
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Organization: Intel Technology Poland Sp. z o. o., KRS 101882, ul. Slowackiego
 173, 80-298 Gdansk
Message-ID: <147578c1-7b21-7dee-372b-e0f1eb8541f4@intel.com>
Date: Tue, 31 Jan 2017 12:39:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170131105800.GA8598@ideak-desk.fi.intel.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/31/2017 11:58 AM, Imre Deak wrote:
> Hi Rafael,

Hi,

> On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
>> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
>>> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I have already reported this issue in [1].
>>>>> One of the issue was solved.
>>>>> Unfortunately, it looks like there is still a different problem here
>>>>> (Ubuntu/precise AMD64).
>>>>>
>>>>> I tried v4.10-rc1 and latest Linus tree up to...
>>>>>
>>>>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
>>>>> "mm/filemap: fix parameters to test_bit()"
>>>>>
>>>>> Here we go...
>>>>>
>>>>> [   29.636047] BUG: sleeping function called from invalid context at
>>>>> drivers/base/power/runtime.c:1032
>>>>> [   29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
>>>>> [   29.636058] 1 lock held by Xorg/1500:
>>>>> [   29.636060]  #0:  (&dev->struct_mutex){+.+.+.}, at:
>>>>> [<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>>>> [   29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
>>>>> 4.10.0-rc1-6-iniza-amd64 #1
>>>>> [   29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>>>> [   29.636111] Call Trace:
>>>>> [   29.636120]  dump_stack+0x85/0xc2
>>>>> [   29.636124]  ___might_sleep+0x196/0x260
>>>>> [   29.636127]  __might_sleep+0x53/0xb0
>>>>> [   29.636131]  __pm_runtime_resume+0x7a/0x90
>>>>> [   29.636159]  intel_runtime_pm_get+0x25/0x90 [i915]
>>>>> [   29.636189]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>>>>> [   29.636220]  i915_vma_bind+0xaf/0x1e0 [i915]
>>>>> [   29.636248]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>>>>> [   29.636272]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>>>>> [   29.636275]  ? trace_hardirqs_on+0xd/0x10
>>>>> [   29.636294]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
>>>>> [   29.636316]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>>>>> [   29.636342]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>>>>> [   29.636347]  ? __might_fault+0x4e/0xb0
>>>>> [   29.636373]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>>>>> [   29.636376]  ? __might_fault+0x4e/0xb0
>>>>> [   29.636395]  drm_ioctl+0x206/0x450 [drm]
>>>>> [   29.636420]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>>>>> [   29.636425]  ? __fget+0x5/0x200
>>>>> [   29.636429]  do_vfs_ioctl+0x91/0x6f0
>>>>> [   29.636431]  ? __fget+0x111/0x200
>>>>> [   29.636433]  ? __fget+0x5/0x200
>>>>> [   29.636436]  SyS_ioctl+0x79/0x90
>>>>> [   29.636441]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>>>>
>>>>> On suspend/resume I see the same call trace.
>>>>> [2] points to the "BUG" line.
>>>> Well, this appears to be an i915 issue, but not a serious one.
>>>>
>>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
>>>> intel_runtime_pm_get()) is called with disabled interrupts.  If I
>>>> understand the code correctly, though, it actually is not going to
>>>> sleep in this particular case, because pm_runtime_get_sync() has
>>>> already been called once for this device in the same code path which
>>>> means that this particular instance will return immediately, so this
>>>> is a false-positive (most likely).
> Not sure what's the root cause, but thought to clarify the above:
>
> Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
> things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
> the device on this path. This isn't a guarantee though,
> aliasing_gtt_bind_vma() could be called from other places without an RPM
> reference. So preemption being disabled at that point is not
> intentional. I also can't see where on the above path it would get
> disabled due to a bug or otherwise.

The i915 code is correct AFAICS, but the core complains about a nested 
invocation of pm_runtime_get_sync() with disabled interrupts (which 
looks OK though), so the complaint is a false positive.

As I said, the way to go here appears to be to tweak the core, which I'm 
going to do.

Thanks,
Rafael

From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [Linux v4.10.0-rc1+] Still call-traces after
 suspend-resume (pm? i915? cpu/hotplug?)
Date: Tue, 31 Jan 2017 12:39:35 +0100
Message-ID: <147578c1-7b21-7dee-372b-e0f1eb8541f4@intel.com>
References: <CA+icZUVydvidHHeWn7=ni1Kxr0y1kaRLKMWCPQi2YY5c_xNL_Q@mail.gmail.com>
 <CAJZ5v0gp_BwxR+B3wtoLRh2B_ojY7cd9E5shJ8zsBeGL_LtnGg@mail.gmail.com>
 <CA+icZUVwTRCAGiO-5Q2uo8SETjHwwSmJ2Pxh56niWsbEVZfV7w@mail.gmail.com>
 <7e7ccb13-1db8-af76-9585-ca7bbdd04c55@intel.com>
 <20170131105800.GA8598@ideak-desk.fi.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Content-Transfer-Encoding: base64
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
In-Reply-To: <20170131105800.GA8598@ideak-desk.fi.intel.com>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: imre.deak@intel.com
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Jani Nikula <jani.nikula@intel.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx <intel-gfx@lists.freedesktop.org>, the arch/x86 maintainers <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>, Linux PM <linux-pm@vger.kernel.org>, sedat.dilek@gmail.com, Thomas Gleixner <tglx@linutronix.de>
List-Id: linux-pm@vger.kernel.org

T24gMS8zMS8yMDE3IDExOjU4IEFNLCBJbXJlIERlYWsgd3JvdGU6Cj4gSGkgUmFmYWVsLAoKSGks
Cgo+IE9uIE1vbiwgSmFuIDMwLCAyMDE3IGF0IDExOjQ0OjM3UE0gKzAxMDAsIFJhZmFlbCBKLiBX
eXNvY2tpIHdyb3RlOgo+PiBPbiAxLzI0LzIwMTcgMjozMyBBTSwgU2VkYXQgRGlsZWsgd3JvdGU6
Cj4+PiBPbiBGcmksIERlYyAzMCwgMjAxNiBhdCAzOjAyIFBNLCBSYWZhZWwgSi4gV3lzb2NraSA8
cmFmYWVsQGtlcm5lbC5vcmc+IHdyb3RlOgo+Pj4+IE9uIEZyaSwgRGVjIDMwLCAyMDE2IGF0IDEy
OjQwIFBNLCBTZWRhdCBEaWxlayA8c2VkYXQuZGlsZWtAZ21haWwuY29tPiB3cm90ZToKPj4+Pj4g
SGksCj4+Pj4+Cj4+Pj4+IEkgaGF2ZSBhbHJlYWR5IHJlcG9ydGVkIHRoaXMgaXNzdWUgaW4gWzFd
Lgo+Pj4+PiBPbmUgb2YgdGhlIGlzc3VlIHdhcyBzb2x2ZWQuCj4+Pj4+IFVuZm9ydHVuYXRlbHks
IGl0IGxvb2tzIGxpa2UgdGhlcmUgaXMgc3RpbGwgYSBkaWZmZXJlbnQgcHJvYmxlbSBoZXJlCj4+
Pj4+IChVYnVudHUvcHJlY2lzZSBBTUQ2NCkuCj4+Pj4+Cj4+Pj4+IEkgdHJpZWQgdjQuMTAtcmMx
IGFuZCBsYXRlc3QgTGludXMgdHJlZSB1cCB0by4uLgo+Pj4+Pgo+Pj4+PiBjb21taXQgOTg0NzNm
OWYzZjliZDQwNDg3M2NkMTE3OGM4YmU3ZDZkNjE5ZjBkMQo+Pj4+PiAibW0vZmlsZW1hcDogZml4
IHBhcmFtZXRlcnMgdG8gdGVzdF9iaXQoKSIKPj4+Pj4KPj4+Pj4gSGVyZSB3ZSBnby4uLgo+Pj4+
Pgo+Pj4+PiBbICAgMjkuNjM2MDQ3XSBCVUc6IHNsZWVwaW5nIGZ1bmN0aW9uIGNhbGxlZCBmcm9t
IGludmFsaWQgY29udGV4dCBhdAo+Pj4+PiBkcml2ZXJzL2Jhc2UvcG93ZXIvcnVudGltZS5jOjEw
MzIKPj4+Pj4gWyAgIDI5LjYzNjA1NV0gaW5fYXRvbWljKCk6IDEsIGlycXNfZGlzYWJsZWQoKTog
MCwgcGlkOiAxNTAwLCBuYW1lOiBYb3JnCj4+Pj4+IFsgICAyOS42MzYwNThdIDEgbG9jayBoZWxk
IGJ5IFhvcmcvMTUwMDoKPj4+Pj4gWyAgIDI5LjYzNjA2MF0gICMwOiAgKCZkZXYtPnN0cnVjdF9t
dXRleCl7Ky4rLisufSwgYXQ6Cj4+Pj4+IFs8ZmZmZmZmZmZhMDY4MGMxMz5dIGk5MTVfbXV0ZXhf
bG9ja19pbnRlcnJ1cHRpYmxlKzB4NDMvMHgxNDAgW2k5MTVdCj4+Pj4+IFsgICAyOS42MzYxMDdd
IENQVTogMCBQSUQ6IDE1MDAgQ29tbTogWG9yZyBOb3QgdGFpbnRlZAo+Pj4+PiA0LjEwLjAtcmMx
LTYtaW5pemEtYW1kNjQgIzEKPj4+Pj4gWyAgIDI5LjYzNjEwOV0gSGFyZHdhcmUgbmFtZTogU0FN
U1VORyBFTEVDVFJPTklDUyBDTy4sIExURC4KPj4+Pj4gNTMwVTNCSS81MzBVNEJJLzUzMFU0Qkgv
NTMwVTNCSS81MzBVNEJJLzUzMFU0QkgsIEJJT1MgMTNYSyAwMy8yOC8yMDEzCj4+Pj4+IFsgICAy
OS42MzYxMTFdIENhbGwgVHJhY2U6Cj4+Pj4+IFsgICAyOS42MzYxMjBdICBkdW1wX3N0YWNrKzB4
ODUvMHhjMgo+Pj4+PiBbICAgMjkuNjM2MTI0XSAgX19fbWlnaHRfc2xlZXArMHgxOTYvMHgyNjAK
Pj4+Pj4gWyAgIDI5LjYzNjEyN10gIF9fbWlnaHRfc2xlZXArMHg1My8weGIwCj4+Pj4+IFsgICAy
OS42MzYxMzFdICBfX3BtX3J1bnRpbWVfcmVzdW1lKzB4N2EvMHg5MAo+Pj4+PiBbICAgMjkuNjM2
MTU5XSAgaW50ZWxfcnVudGltZV9wbV9nZXQrMHgyNS8weDkwIFtpOTE1XQo+Pj4+PiBbICAgMjku
NjM2MTg5XSAgYWxpYXNpbmdfZ3R0X2JpbmRfdm1hKzB4YWEvMHhmMCBbaTkxNV0KPj4+Pj4gWyAg
IDI5LjYzNjIyMF0gIGk5MTVfdm1hX2JpbmQrMHhhZi8weDFlMCBbaTkxNV0KPj4+Pj4gWyAgIDI5
LjYzNjI0OF0gIGk5MTVfZ2VtX2V4ZWNidWZmZXJfcmVsb2NhdGVfZW50cnkrMHg1MTMvMHg2ZjAg
W2k5MTVdCj4+Pj4+IFsgICAyOS42MzYyNzJdICBpOTE1X2dlbV9leGVjYnVmZmVyX3JlbG9jYXRl
X3ZtYS5pc3JhLjM0KzB4MTg4LzB4MjUwIFtpOTE1XQo+Pj4+PiBbICAgMjkuNjM2Mjc1XSAgPyB0
cmFjZV9oYXJkaXJxc19vbisweGQvMHgxMAo+Pj4+PiBbICAgMjkuNjM2Mjk0XSAgPyBpOTE1X2dl
bV9leGVjYnVmZmVyX3Jlc2VydmVfdm1hLmlzcmEuMzErMHgxNTIvMHgxZjAgW2k5MTVdCj4+Pj4+
IFsgICAyOS42MzYzMTZdICA/IGk5MTVfZ2VtX2V4ZWNidWZmZXJfcmVzZXJ2ZS5pc3JhLjMyKzB4
MzcyLzB4M2EwIFtpOTE1XQo+Pj4+PiBbICAgMjkuNjM2MzQyXSAgaTkxNV9nZW1fZG9fZXhlY2J1
ZmZlci5pc3JhLjM4KzB4YTcwLzB4MWE0MCBbaTkxNV0KPj4+Pj4gWyAgIDI5LjYzNjM0N10gID8g
X19taWdodF9mYXVsdCsweDRlLzB4YjAKPj4+Pj4gWyAgIDI5LjYzNjM3M10gIGk5MTVfZ2VtX2V4
ZWNidWZmZXIyKzB4YzUvMHgyNjAgW2k5MTVdCj4+Pj4+IFsgICAyOS42MzYzNzZdICA/IF9fbWln
aHRfZmF1bHQrMHg0ZS8weGIwCj4+Pj4+IFsgICAyOS42MzYzOTVdICBkcm1faW9jdGwrMHgyMDYv
MHg0NTAgW2RybV0KPj4+Pj4gWyAgIDI5LjYzNjQyMF0gID8gaTkxNV9nZW1fZXhlY2J1ZmZlcisw
eDM0MC8weDM0MCBbaTkxNV0KPj4+Pj4gWyAgIDI5LjYzNjQyNV0gID8gX19mZ2V0KzB4NS8weDIw
MAo+Pj4+PiBbICAgMjkuNjM2NDI5XSAgZG9fdmZzX2lvY3RsKzB4OTEvMHg2ZjAKPj4+Pj4gWyAg
IDI5LjYzNjQzMV0gID8gX19mZ2V0KzB4MTExLzB4MjAwCj4+Pj4+IFsgICAyOS42MzY0MzNdICA/
IF9fZmdldCsweDUvMHgyMDAKPj4+Pj4gWyAgIDI5LjYzNjQzNl0gIFN5U19pb2N0bCsweDc5LzB4
OTAKPj4+Pj4gWyAgIDI5LjYzNjQ0MV0gIGVudHJ5X1NZU0NBTExfNjRfZmFzdHBhdGgrMHgyMy8w
eGM2Cj4+Pj4+Cj4+Pj4+IE9uIHN1c3BlbmQvcmVzdW1lIEkgc2VlIHRoZSBzYW1lIGNhbGwgdHJh
Y2UuCj4+Pj4+IFsyXSBwb2ludHMgdG8gdGhlICJCVUciIGxpbmUuCj4+Pj4gV2VsbCwgdGhpcyBh
cHBlYXJzIHRvIGJlIGFuIGk5MTUgaXNzdWUsIGJ1dCBub3QgYSBzZXJpb3VzIG9uZS4KPj4+Pgo+
Pj4+IENsZWFybHksIGEgZnVuY3Rpb24gdGhhdCBtYXkgc2xlZXAgKHBtX3J1bnRpbWVfZ2V0X3N5
bmMoKSBpbgo+Pj4+IGludGVsX3J1bnRpbWVfcG1fZ2V0KCkpIGlzIGNhbGxlZCB3aXRoIGRpc2Fi
bGVkIGludGVycnVwdHMuICBJZiBJCj4+Pj4gdW5kZXJzdGFuZCB0aGUgY29kZSBjb3JyZWN0bHks
IHRob3VnaCwgaXQgYWN0dWFsbHkgaXMgbm90IGdvaW5nIHRvCj4+Pj4gc2xlZXAgaW4gdGhpcyBw
YXJ0aWN1bGFyIGNhc2UsIGJlY2F1c2UgcG1fcnVudGltZV9nZXRfc3luYygpIGhhcwo+Pj4+IGFs
cmVhZHkgYmVlbiBjYWxsZWQgb25jZSBmb3IgdGhpcyBkZXZpY2UgaW4gdGhlIHNhbWUgY29kZSBw
YXRoIHdoaWNoCj4+Pj4gbWVhbnMgdGhhdCB0aGlzIHBhcnRpY3VsYXIgaW5zdGFuY2Ugd2lsbCBy
ZXR1cm4gaW1tZWRpYXRlbHksIHNvIHRoaXMKPj4+PiBpcyBhIGZhbHNlLXBvc2l0aXZlIChtb3N0
IGxpa2VseSkuCj4gTm90IHN1cmUgd2hhdCdzIHRoZSByb290IGNhdXNlLCBidXQgdGhvdWdodCB0
byBjbGFyaWZ5IHRoZSBhYm92ZToKPgo+IFllcywgaTkxNV9nZW1fZG9fZXhlY2J1ZmZlcigpIGRv
ZXMgdGFrZSBhbiBSUE0gcmVmZXJlbmNlIHRvIG9wdGltaXplCj4gdGhpbmdzLCBzbyB0aGUgUlBN
IGdldCBpbiBhbGlhc2luZ19ndHRfYmluZF92bWEoKSB3b24ndCBuZWVkIHRvIHJlc3VtZQo+IHRo
ZSBkZXZpY2Ugb24gdGhpcyBwYXRoLiBUaGlzIGlzbid0IGEgZ3VhcmFudGVlIHRob3VnaCwKPiBh
bGlhc2luZ19ndHRfYmluZF92bWEoKSBjb3VsZCBiZSBjYWxsZWQgZnJvbSBvdGhlciBwbGFjZXMg
d2l0aG91dCBhbiBSUE0KPiByZWZlcmVuY2UuIFNvIHByZWVtcHRpb24gYmVpbmcgZGlzYWJsZWQg
YXQgdGhhdCBwb2ludCBpcyBub3QKPiBpbnRlbnRpb25hbC4gSSBhbHNvIGNhbid0IHNlZSB3aGVy
ZSBvbiB0aGUgYWJvdmUgcGF0aCBpdCB3b3VsZCBnZXQKPiBkaXNhYmxlZCBkdWUgdG8gYSBidWcg
b3Igb3RoZXJ3aXNlLgoKVGhlIGk5MTUgY29kZSBpcyBjb3JyZWN0IEFGQUlDUywgYnV0IHRoZSBj
b3JlIGNvbXBsYWlucyBhYm91dCBhIG5lc3RlZCAKaW52b2NhdGlvbiBvZiBwbV9ydW50aW1lX2dl
dF9zeW5jKCkgd2l0aCBkaXNhYmxlZCBpbnRlcnJ1cHRzICh3aGljaCAKbG9va3MgT0sgdGhvdWdo
KSwgc28gdGhlIGNvbXBsYWludCBpcyBhIGZhbHNlIHBvc2l0aXZlLgoKQXMgSSBzYWlkLCB0aGUg
d2F5IHRvIGdvIGhlcmUgYXBwZWFycyB0byBiZSB0byB0d2VhayB0aGUgY29yZSwgd2hpY2ggSSdt
IApnb2luZyB0byBkby4KClRoYW5rcywKUmFmYWVsCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBs
aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h
bi9saXN0aW5mby9pbnRlbC1nZngK