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=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 4C706C43387 for ; Mon, 14 Jan 2019 09:25:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 09B5920660 for ; Mon, 14 Jan 2019 09:25:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726522AbfANJZQ (ORCPT ); Mon, 14 Jan 2019 04:25:16 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56512 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbfANJZP (ORCPT ); Mon, 14 Jan 2019 04:25:15 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B5D2FA78; Mon, 14 Jan 2019 01:25:14 -0800 (PST) Received: from [10.1.196.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 729153F5AF; Mon, 14 Jan 2019 01:25:12 -0800 (PST) Subject: Re: [PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability To: Samuel Holland , Catalin Marinas , Will Deacon , Maxime Ripard , Chen-Yu Tsai , Rob Herring , Mark Rutland , Daniel Lezcano , Thomas Gleixner Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com References: <20190113021719.46457-1-samuel@sholland.org> <20190113021719.46457-2-samuel@sholland.org> From: Marc Zyngier Openpgp: preference=signencrypt Autocrypt: addr=marc.zyngier@arm.com; prefer-encrypt=mutual; keydata= mQINBE6Jf0UBEADLCxpix34Ch3kQKA9SNlVQroj9aHAEzzl0+V8jrvT9a9GkK+FjBOIQz4KE g+3p+lqgJH4NfwPm9H5I5e3wa+Scz9wAqWLTT772Rqb6hf6kx0kKd0P2jGv79qXSmwru28vJ t9NNsmIhEYwS5eTfCbsZZDCnR31J6qxozsDHpCGLHlYym/VbC199Uq/pN5gH+5JHZyhyZiNW ozUCjMqC4eNW42nYVKZQfbj/k4W9xFfudFaFEhAf/Vb1r6F05eBP1uopuzNkAN7vqS8XcgQH qXI357YC4ToCbmqLue4HK9+2mtf7MTdHZYGZ939OfTlOGuxFW+bhtPQzsHiW7eNe0ew0+LaL 3wdNzT5abPBscqXWVGsZWCAzBmrZato+Pd2bSCDPLInZV0j+rjt7MWiSxEAEowue3IcZA++7 ifTDIscQdpeKT8hcL+9eHLgoSDH62SlubO/y8bB1hV8JjLW/jQpLnae0oz25h39ij4ijcp8N t5slf5DNRi1NLz5+iaaLg4gaM3ywVK2VEKdBTg+JTg3dfrb3DH7ctTQquyKun9IVY8AsxMc6 lxl4HxrpLX7HgF10685GG5fFla7R1RUnW5svgQhz6YVU33yJjk5lIIrrxKI/wLlhn066mtu1 DoD9TEAjwOmpa6ofV6rHeBPehUwMZEsLqlKfLsl0PpsJwov8TQARAQABtCNNYXJjIFp5bmdp ZXIgPG1hcmMuenluZ2llckBhcm0uY29tPokCOwQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AFAk6NvYYCGQEACgkQI9DQutE9ekObww/+NcUATWXOcnoPflpYG43GZ0XjQLng LQFjBZL+CJV5+1XMDfz4ATH37cR+8gMO1UwmWPv5tOMKLHhw6uLxGG4upPAm0qxjRA/SE3LC 22kBjWiSMrkQgv5FDcwdhAcj8A+gKgcXBeyXsGBXLjo5UQOGvPTQXcqNXB9A3ZZN9vS6QUYN TXFjnUnzCJd+PVI/4jORz9EUVw1q/+kZgmA8/GhfPH3xNetTGLyJCJcQ86acom2liLZZX4+1 6Hda2x3hxpoQo7pTu+XA2YC4XyUstNDYIsE4F4NVHGi88a3N8yWE+Z7cBI2HjGvpfNxZnmKX 6bws6RQ4LHDPhy0yzWFowJXGTqM/e79c1UeqOVxKGFF3VhJJu1nMlh+5hnW4glXOoy/WmDEM UMbl9KbJUfo+GgIQGMp8mwgW0vK4HrSmevlDeMcrLdfbbFbcZLNeFFBn6KqxFZaTd+LpylIH bOPN6fy1Dxf7UZscogYw5Pt0JscgpciuO3DAZo3eXz6ffj2NrWchnbj+SpPBiH4srfFmHY+Y LBemIIOmSqIsjoSRjNEZeEObkshDVG5NncJzbAQY+V3Q3yo9og/8ZiaulVWDbcpKyUpzt7pv cdnY3baDE8ate/cymFP5jGJK++QCeA6u6JzBp7HnKbngqWa6g8qDSjPXBPCLmmRWbc5j0lvA 6ilrF8m5Ag0ETol/RQEQAM/2pdLYCWmf3rtIiP8Wj5NwyjSL6/UrChXtoX9wlY8a4h3EX6E3 64snIJVMLbyr4bwdmPKULlny7T/R8dx/mCOWu/DztrVNQiXWOTKJnd/2iQblBT+W5W8ep/nS w3qUIckKwKdplQtzSKeE+PJ+GMS+DoNDDkcrVjUnsoCEr0aK3cO6g5hLGu8IBbC1CJYSpple VVb/sADnWF3SfUvJ/l4K8Uk4B4+X90KpA7U9MhvDTCy5mJGaTsFqDLpnqp/yqaT2P7kyMG2E w+eqtVIqwwweZA0S+tuqput5xdNAcsj2PugVx9tlw/LJo39nh8NrMxAhv5aQ+JJ2I8UTiHLX QvoC0Yc/jZX/JRB5r4x4IhK34Mv5TiH/gFfZbwxd287Y1jOaD9lhnke1SX5MXF7eCT3cgyB+ hgSu42w+2xYl3+rzIhQqxXhaP232t/b3ilJO00ZZ19d4KICGcakeiL6ZBtD8TrtkRiewI3v0 o8rUBWtjcDRgg3tWx/PcJvZnw1twbmRdaNvsvnlapD2Y9Js3woRLIjSAGOijwzFXSJyC2HU1 AAuR9uo4/QkeIrQVHIxP7TJZdJ9sGEWdeGPzzPlKLHwIX2HzfbdtPejPSXm5LJ026qdtJHgz BAb3NygZG6BH6EC1NPDQ6O53EXorXS1tsSAgp5ZDSFEBklpRVT3E0NrDABEBAAGJAh8EGAEC AAkFAk6Jf0UCGwwACgkQI9DQutE9ekMLBQ//U+Mt9DtFpzMCIHFPE9nNlsCm75j22lNiw6mX mx3cUA3pl+uRGQr/zQC5inQNtjFUmwGkHqrAw+SmG5gsgnM4pSdYvraWaCWOZCQCx1lpaCOl MotrNcwMJTJLQGc4BjJyOeSH59HQDitKfKMu/yjRhzT8CXhys6R0kYMrEN0tbe1cFOJkxSbV 0GgRTDF4PKyLT+RncoKxQe8lGxuk5614aRpBQa0LPafkirwqkUtxsPnarkPUEfkBlnIhAR8L kmneYLu0AvbWjfJCUH7qfpyS/FRrQCoBq9QIEcf2v1f0AIpA27f9KCEv5MZSHXGCdNcbjKw1 39YxYZhmXaHFKDSZIC29YhQJeXWlfDEDq6nIhvurZy3mSh2OMQgaIoFexPCsBBOclH8QUtMk a3jW/qYyrV+qUq9Wf3SKPrXf7B3xB332jFCETbyZQXqmowV+2b3rJFRWn5hK5B+xwvuxKyGq qDOGjof2dKl2zBIxbFgOclV7wqCVkhxSJi/QaOj2zBqSNPXga5DWtX3ekRnJLa1+ijXxmdjz hApihi08gwvP5G9fNGKQyRETePEtEAWt0b7dOqMzYBYGRVr7uS4uT6WP7fzOwAJC4lU7ZYWZ yVshCa0IvTtp1085RtT3qhh9mobkcZ+7cQOY+Tx2RGXS9WeOh2jZjdoWUv6CevXNQyOUXMM= Organization: ARM Ltd Message-ID: <472c5450-1b60-6ac7-b242-805c2a2f3272@arm.com> Date: Mon, 14 Jan 2019 09:25:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20190113021719.46457-2-samuel@sholland.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Samuel, On 13/01/2019 02:17, Samuel Holland wrote: > The Allwinner A64 SoC is known[1] to have an unstable architectural > timer, which manifests itself most obviously in the time jumping forward > a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a > timer frequency of 24 MHz, implying that the time went slightly backward > (and this was interpreted by the kernel as it jumping forward and > wrapping around past the epoch). > > Investigation revealed instability in the low bits of CNTVCT at the > point a high bit rolls over. This leads to power-of-two cycle forward > and backward jumps. (Testing shows that forward jumps are about twice as > likely as backward jumps.) Since the counter value returns to normal > after an indeterminate read, each "jump" really consists of both a > forward and backward jump from the software perspective. > > Unless the kernel is trapping CNTVCT reads, a userspace program is able > to read the register in a loop faster than it changes. A test program > running on all 4 CPU cores that reported jumps larger than 100 ms was > run for 13.6 hours and reported the following: > > Count | Event > -------+--------------------------- > 9940 | jumped backward 699ms > 268 | jumped backward 1398ms > 1 | jumped backward 2097ms > 16020 | jumped forward 175ms > 6443 | jumped forward 699ms > 2976 | jumped forward 1398ms > 9 | jumped forward 356516ms > 9 | jumped forward 357215ms > 4 | jumped forward 714430ms > 1 | jumped forward 3578440ms > > This works out to a jump larger than 100 ms about every 5.5 seconds on > each CPU core. > > The largest jump (almost an hour!) was the following sequence of reads: > 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000 > > Note that the middle bits don't necessarily all read as all zeroes or > all ones during the anomalous behavior; however the low 10 bits checked > by the function in this patch have never been observed with any other > value. > > Also note that smaller jumps are much more common, with backward jumps > of 2048 (2^11) cycles observed over 400 times per second on each core. > (Of course, this is partially explained by lower bits rolling over more > frequently.) Any one of these could have caused the 95 year time skip. > > Similar anomalies were observed while reading CNTPCT (after patching the > kernel to allow reads from userspace). However, the CNTPCT jumps are > much less frequent, and only small jumps were observed. The same program > as before (except now reading CNTPCT) observed after 72 hours: > > Count | Event > -------+--------------------------- > 17 | jumped backward 699ms > 52 | jumped forward 175ms > 2831 | jumped forward 699ms > 5 | jumped forward 1398ms > > Further investigation showed that the instability in CNTPCT/CNTVCT also > affected the respective timer's TVAL register. The following values were > observed immediately after writing CNVT_TVAL to 0x10000000: > > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error > --------------------+------------+--------------------+----------------- > 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 > 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 > 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 > 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000 > > The pattern of errors in CNTV_TVAL seemed to depend on exactly which > value was written to it. For example, after writing 0x10101010: > > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error > --------------------+------------+--------------------+----------------- > 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 > 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 > 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 > 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 > 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 > 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000 > > I was also twice able to reproduce the issue covered by Allwinner's > workaround[4], that writing to TVAL sometimes fails, and both CVAL and > TVAL are left with entirely bogus values. One was the following values: > > CNTVCT | CNTV_TVAL | CNTV_CVAL > --------------------+------------+-------------------------------------- > 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) > > ======================================================================== > > Because the CPU can read the CNTPCT/CNTVCT registers faster than they > change, performing two reads of the register and comparing the high bits > (like other workarounds) is not a workable solution. And because the > timer can jump both forward and backward, no pair of reads can > distinguish a good value from a bad one. The only way to guarantee a > good value from consecutive reads would be to read _three_ times, and > take the middle value only if the three values are 1) each unique and > 2) increasing. This takes at minimum 3 counter cycles (125 ns), or more > if an anomaly is detected. > > However, since there is a distinct pattern to the bad values, we can > optimize the common case (1022/1024 of the time) to a single read by > simply ignoring values that match the error pattern. This still takes no > more than 3 cycles in the worst case, and requires much less code. As an > additional safety check, we still limit the loop iteration to the number > of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods. > > For the TVAL registers, the simple solution is to not use them. Instead, > read or write the CVAL and calculate the TVAL value in software. > > Although the manufacturer is aware of at least part of the erratum[4], > there is no official name for it. For now, use the kernel-internal name > "UNKNOWN1". > > [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9 > [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/ > [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26 > [4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272 nit: In general, I'm not overly keen on URLs in commit messages, as they may vanish without notice and the commit message becomes less useful. In the future, please keep those in the cover letter (though in this particular case, the commit message explains the issue pretty well, so no harm done once GitHub dies a horrible death... ;-). The fix itself looks pretty solid, and will hopefully make the "AllLoosers" HW more usable. Reviewed-by: Marc Zyngier Daniel, please consider this for v5.1. Thanks, M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability Date: Mon, 14 Jan 2019 09:25:10 +0000 Message-ID: <472c5450-1b60-6ac7-b242-805c2a2f3272@arm.com> References: <20190113021719.46457-1-samuel@sholland.org> <20190113021719.46457-2-samuel@sholland.org> Reply-To: marc.zyngier-5wv7dgnIgG8@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20190113021719.46457-2-samuel-RkNLwX/CsU9g9hUCZPvPmw@public.gmane.org> Content-Language: en-US List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Samuel Holland , Catalin Marinas , Will Deacon , Maxime Ripard , Chen-Yu Tsai , Rob Herring , Mark Rutland , Daniel Lezcano , Thomas Gleixner Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Id: devicetree@vger.kernel.org Hi Samuel, On 13/01/2019 02:17, Samuel Holland wrote: > The Allwinner A64 SoC is known[1] to have an unstable architectural > timer, which manifests itself most obviously in the time jumping forward > a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a > timer frequency of 24 MHz, implying that the time went slightly backward > (and this was interpreted by the kernel as it jumping forward and > wrapping around past the epoch). >=20 > Investigation revealed instability in the low bits of CNTVCT at the > point a high bit rolls over. This leads to power-of-two cycle forward > and backward jumps. (Testing shows that forward jumps are about twice as > likely as backward jumps.) Since the counter value returns to normal > after an indeterminate read, each "jump" really consists of both a > forward and backward jump from the software perspective. >=20 > Unless the kernel is trapping CNTVCT reads, a userspace program is able > to read the register in a loop faster than it changes. A test program > running on all 4 CPU cores that reported jumps larger than 100 ms was > run for 13.6 hours and reported the following: >=20 > Count | Event > -------+--------------------------- > 9940 | jumped backward 699ms > 268 | jumped backward 1398ms > 1 | jumped backward 2097ms > 16020 | jumped forward 175ms > 6443 | jumped forward 699ms > 2976 | jumped forward 1398ms > 9 | jumped forward 356516ms > 9 | jumped forward 357215ms > 4 | jumped forward 714430ms > 1 | jumped forward 3578440ms >=20 > This works out to a jump larger than 100 ms about every 5.5 seconds on > each CPU core. >=20 > The largest jump (almost an hour!) was the following sequence of reads: > 0x0000007fffffffff =E2=86=92 0x00000093feffffff =E2=86=92 0x000000800= 0000000 >=20 > Note that the middle bits don't necessarily all read as all zeroes or > all ones during the anomalous behavior; however the low 10 bits checked > by the function in this patch have never been observed with any other > value. >=20 > Also note that smaller jumps are much more common, with backward jumps > of 2048 (2^11) cycles observed over 400 times per second on each core. > (Of course, this is partially explained by lower bits rolling over more > frequently.) Any one of these could have caused the 95 year time skip. >=20 > Similar anomalies were observed while reading CNTPCT (after patching the > kernel to allow reads from userspace). However, the CNTPCT jumps are > much less frequent, and only small jumps were observed. The same program > as before (except now reading CNTPCT) observed after 72 hours: >=20 > Count | Event > -------+--------------------------- > 17 | jumped backward 699ms > 52 | jumped forward 175ms > 2831 | jumped forward 699ms > 5 | jumped forward 1398ms >=20 > Further investigation showed that the instability in CNTPCT/CNTVCT also > affected the respective timer's TVAL register. The following values were > observed immediately after writing CNVT_TVAL to 0x10000000: >=20 > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error > --------------------+------------+--------------------+----------------- > 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 > 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 > 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 > 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000 >=20 > The pattern of errors in CNTV_TVAL seemed to depend on exactly which > value was written to it. For example, after writing 0x10101010: >=20 > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error > --------------------+------------+--------------------+----------------- > 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 > 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 > 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 > 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 > 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 > 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000 >=20 > I was also twice able to reproduce the issue covered by Allwinner's > workaround[4], that writing to TVAL sometimes fails, and both CVAL and > TVAL are left with entirely bogus values. One was the following values: >=20 > CNTVCT | CNTV_TVAL | CNTV_CVAL > --------------------+------------+-------------------------------------- > 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Because the CPU can read the CNTPCT/CNTVCT registers faster than they > change, performing two reads of the register and comparing the high bits > (like other workarounds) is not a workable solution. And because the > timer can jump both forward and backward, no pair of reads can > distinguish a good value from a bad one. The only way to guarantee a > good value from consecutive reads would be to read _three_ times, and > take the middle value only if the three values are 1) each unique and > 2) increasing. This takes at minimum 3 counter cycles (125 ns), or more > if an anomaly is detected. >=20 > However, since there is a distinct pattern to the bad values, we can > optimize the common case (1022/1024 of the time) to a single read by > simply ignoring values that match the error pattern. This still takes no > more than 3 cycles in the worst case, and requires much less code. As an > additional safety check, we still limit the loop iteration to the number > of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods. >=20 > For the TVAL registers, the simple solution is to not use them. Instead, > read or write the CVAL and calculate the TVAL value in software. >=20 > Although the manufacturer is aware of at least part of the erratum[4], > there is no official name for it. For now, use the kernel-internal name > "UNKNOWN1". >=20 > [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9 > [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/ > [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26 > [4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/driv= ers/clocksource/arm_arch_timer.c#L272 nit: In general, I'm not overly keen on URLs in commit messages, as they may vanish without notice and the commit message becomes less useful. In the future, please keep those in the cover letter (though in this particular case, the commit message explains the issue pretty well, so no harm done once GitHub dies a horrible death... ;-). The fix itself looks pretty solid, and will hopefully make the "AllLoosers" HW more usable. Reviewed-by: Marc Zyngier Daniel, please consider this for v5.1. Thanks, M. --=20 Jazz is not dead. It just smells funny... --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. 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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 F3BF1C43387 for ; Mon, 14 Jan 2019 09:25:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C490E2086D for ; Mon, 14 Jan 2019 09:25:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iZymZG9W" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C490E2086D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JHumoaoCwKsweHW8ZP1lVCBGQBQTnyUnyvYpnU9Malo=; b=iZymZG9WQxTybf a5BN88s9JVjbM7aY/LaCxqZUh75GsUnpvZVoa+N30hRkX6Id37zGTd3ET60JMjjelAOXhsZCjW8gs 2xKzBDskntWqASjYvMoHeyN+1ctiHd/Sp1ya/OaTSTBIZwdZTaO12emo9b5zlZUUJlzyRLu0xQmWC CfmuOnbR3vWJxgmW/WnChaxFbMqHyF7cV/BmljrMNXVyyjmVIXlyRfr/8R7iwvhCCl0aWW6w39Yb+ IBUj9HxVg5Eq6LRQIw1OzcHLDXfP5rJ/vNmnRZv98iY2NU4HRxCjmxK/vC683nHS5GdgPoqm9saTN GEiSZeEzSSIN5+07Ugjw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1giyUl-0000la-9T; Mon, 14 Jan 2019 09:25:23 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1giyUh-0000kt-It for linux-arm-kernel@lists.infradead.org; Mon, 14 Jan 2019 09:25:21 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B5D2FA78; Mon, 14 Jan 2019 01:25:14 -0800 (PST) Received: from [10.1.196.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 729153F5AF; Mon, 14 Jan 2019 01:25:12 -0800 (PST) Subject: Re: [PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability To: Samuel Holland , Catalin Marinas , Will Deacon , Maxime Ripard , Chen-Yu Tsai , Rob Herring , Mark Rutland , Daniel Lezcano , Thomas Gleixner References: <20190113021719.46457-1-samuel@sholland.org> <20190113021719.46457-2-samuel@sholland.org> From: Marc Zyngier Openpgp: preference=signencrypt Autocrypt: addr=marc.zyngier@arm.com; prefer-encrypt=mutual; keydata= mQINBE6Jf0UBEADLCxpix34Ch3kQKA9SNlVQroj9aHAEzzl0+V8jrvT9a9GkK+FjBOIQz4KE g+3p+lqgJH4NfwPm9H5I5e3wa+Scz9wAqWLTT772Rqb6hf6kx0kKd0P2jGv79qXSmwru28vJ t9NNsmIhEYwS5eTfCbsZZDCnR31J6qxozsDHpCGLHlYym/VbC199Uq/pN5gH+5JHZyhyZiNW ozUCjMqC4eNW42nYVKZQfbj/k4W9xFfudFaFEhAf/Vb1r6F05eBP1uopuzNkAN7vqS8XcgQH qXI357YC4ToCbmqLue4HK9+2mtf7MTdHZYGZ939OfTlOGuxFW+bhtPQzsHiW7eNe0ew0+LaL 3wdNzT5abPBscqXWVGsZWCAzBmrZato+Pd2bSCDPLInZV0j+rjt7MWiSxEAEowue3IcZA++7 ifTDIscQdpeKT8hcL+9eHLgoSDH62SlubO/y8bB1hV8JjLW/jQpLnae0oz25h39ij4ijcp8N t5slf5DNRi1NLz5+iaaLg4gaM3ywVK2VEKdBTg+JTg3dfrb3DH7ctTQquyKun9IVY8AsxMc6 lxl4HxrpLX7HgF10685GG5fFla7R1RUnW5svgQhz6YVU33yJjk5lIIrrxKI/wLlhn066mtu1 DoD9TEAjwOmpa6ofV6rHeBPehUwMZEsLqlKfLsl0PpsJwov8TQARAQABtCNNYXJjIFp5bmdp ZXIgPG1hcmMuenluZ2llckBhcm0uY29tPokCOwQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AFAk6NvYYCGQEACgkQI9DQutE9ekObww/+NcUATWXOcnoPflpYG43GZ0XjQLng LQFjBZL+CJV5+1XMDfz4ATH37cR+8gMO1UwmWPv5tOMKLHhw6uLxGG4upPAm0qxjRA/SE3LC 22kBjWiSMrkQgv5FDcwdhAcj8A+gKgcXBeyXsGBXLjo5UQOGvPTQXcqNXB9A3ZZN9vS6QUYN TXFjnUnzCJd+PVI/4jORz9EUVw1q/+kZgmA8/GhfPH3xNetTGLyJCJcQ86acom2liLZZX4+1 6Hda2x3hxpoQo7pTu+XA2YC4XyUstNDYIsE4F4NVHGi88a3N8yWE+Z7cBI2HjGvpfNxZnmKX 6bws6RQ4LHDPhy0yzWFowJXGTqM/e79c1UeqOVxKGFF3VhJJu1nMlh+5hnW4glXOoy/WmDEM UMbl9KbJUfo+GgIQGMp8mwgW0vK4HrSmevlDeMcrLdfbbFbcZLNeFFBn6KqxFZaTd+LpylIH bOPN6fy1Dxf7UZscogYw5Pt0JscgpciuO3DAZo3eXz6ffj2NrWchnbj+SpPBiH4srfFmHY+Y LBemIIOmSqIsjoSRjNEZeEObkshDVG5NncJzbAQY+V3Q3yo9og/8ZiaulVWDbcpKyUpzt7pv cdnY3baDE8ate/cymFP5jGJK++QCeA6u6JzBp7HnKbngqWa6g8qDSjPXBPCLmmRWbc5j0lvA 6ilrF8m5Ag0ETol/RQEQAM/2pdLYCWmf3rtIiP8Wj5NwyjSL6/UrChXtoX9wlY8a4h3EX6E3 64snIJVMLbyr4bwdmPKULlny7T/R8dx/mCOWu/DztrVNQiXWOTKJnd/2iQblBT+W5W8ep/nS w3qUIckKwKdplQtzSKeE+PJ+GMS+DoNDDkcrVjUnsoCEr0aK3cO6g5hLGu8IBbC1CJYSpple VVb/sADnWF3SfUvJ/l4K8Uk4B4+X90KpA7U9MhvDTCy5mJGaTsFqDLpnqp/yqaT2P7kyMG2E w+eqtVIqwwweZA0S+tuqput5xdNAcsj2PugVx9tlw/LJo39nh8NrMxAhv5aQ+JJ2I8UTiHLX QvoC0Yc/jZX/JRB5r4x4IhK34Mv5TiH/gFfZbwxd287Y1jOaD9lhnke1SX5MXF7eCT3cgyB+ hgSu42w+2xYl3+rzIhQqxXhaP232t/b3ilJO00ZZ19d4KICGcakeiL6ZBtD8TrtkRiewI3v0 o8rUBWtjcDRgg3tWx/PcJvZnw1twbmRdaNvsvnlapD2Y9Js3woRLIjSAGOijwzFXSJyC2HU1 AAuR9uo4/QkeIrQVHIxP7TJZdJ9sGEWdeGPzzPlKLHwIX2HzfbdtPejPSXm5LJ026qdtJHgz BAb3NygZG6BH6EC1NPDQ6O53EXorXS1tsSAgp5ZDSFEBklpRVT3E0NrDABEBAAGJAh8EGAEC AAkFAk6Jf0UCGwwACgkQI9DQutE9ekMLBQ//U+Mt9DtFpzMCIHFPE9nNlsCm75j22lNiw6mX mx3cUA3pl+uRGQr/zQC5inQNtjFUmwGkHqrAw+SmG5gsgnM4pSdYvraWaCWOZCQCx1lpaCOl MotrNcwMJTJLQGc4BjJyOeSH59HQDitKfKMu/yjRhzT8CXhys6R0kYMrEN0tbe1cFOJkxSbV 0GgRTDF4PKyLT+RncoKxQe8lGxuk5614aRpBQa0LPafkirwqkUtxsPnarkPUEfkBlnIhAR8L kmneYLu0AvbWjfJCUH7qfpyS/FRrQCoBq9QIEcf2v1f0AIpA27f9KCEv5MZSHXGCdNcbjKw1 39YxYZhmXaHFKDSZIC29YhQJeXWlfDEDq6nIhvurZy3mSh2OMQgaIoFexPCsBBOclH8QUtMk a3jW/qYyrV+qUq9Wf3SKPrXf7B3xB332jFCETbyZQXqmowV+2b3rJFRWn5hK5B+xwvuxKyGq qDOGjof2dKl2zBIxbFgOclV7wqCVkhxSJi/QaOj2zBqSNPXga5DWtX3ekRnJLa1+ijXxmdjz hApihi08gwvP5G9fNGKQyRETePEtEAWt0b7dOqMzYBYGRVr7uS4uT6WP7fzOwAJC4lU7ZYWZ yVshCa0IvTtp1085RtT3qhh9mobkcZ+7cQOY+Tx2RGXS9WeOh2jZjdoWUv6CevXNQyOUXMM= Organization: ARM Ltd Message-ID: <472c5450-1b60-6ac7-b242-805c2a2f3272@arm.com> Date: Mon, 14 Jan 2019 09:25:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20190113021719.46457-2-samuel@sholland.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190114_012519_638035_11E4A618 X-CRM114-Status: GOOD ( 25.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgU2FtdWVsLAoKT24gMTMvMDEvMjAxOSAwMjoxNywgU2FtdWVsIEhvbGxhbmQgd3JvdGU6Cj4g VGhlIEFsbHdpbm5lciBBNjQgU29DIGlzIGtub3duWzFdIHRvIGhhdmUgYW4gdW5zdGFibGUgYXJj aGl0ZWN0dXJhbAo+IHRpbWVyLCB3aGljaCBtYW5pZmVzdHMgaXRzZWxmIG1vc3Qgb2J2aW91c2x5 IGluIHRoZSB0aW1lIGp1bXBpbmcgZm9yd2FyZAo+IGEgbXVsdGlwbGUgb2YgOTUgeWVhcnNbMl1b M10uIFRoaXMgY29pbmNpZGVzIHdpdGggMl41NiBjeWNsZXMgYXQgYQo+IHRpbWVyIGZyZXF1ZW5j eSBvZiAyNCBNSHosIGltcGx5aW5nIHRoYXQgdGhlIHRpbWUgd2VudCBzbGlnaHRseSBiYWNrd2Fy ZAo+IChhbmQgdGhpcyB3YXMgaW50ZXJwcmV0ZWQgYnkgdGhlIGtlcm5lbCBhcyBpdCBqdW1waW5n IGZvcndhcmQgYW5kCj4gd3JhcHBpbmcgYXJvdW5kIHBhc3QgdGhlIGVwb2NoKS4KPiAKPiBJbnZl c3RpZ2F0aW9uIHJldmVhbGVkIGluc3RhYmlsaXR5IGluIHRoZSBsb3cgYml0cyBvZiBDTlRWQ1Qg YXQgdGhlCj4gcG9pbnQgYSBoaWdoIGJpdCByb2xscyBvdmVyLiBUaGlzIGxlYWRzIHRvIHBvd2Vy LW9mLXR3byBjeWNsZSBmb3J3YXJkCj4gYW5kIGJhY2t3YXJkIGp1bXBzLiAoVGVzdGluZyBzaG93 cyB0aGF0IGZvcndhcmQganVtcHMgYXJlIGFib3V0IHR3aWNlIGFzCj4gbGlrZWx5IGFzIGJhY2t3 YXJkIGp1bXBzLikgU2luY2UgdGhlIGNvdW50ZXIgdmFsdWUgcmV0dXJucyB0byBub3JtYWwKPiBh ZnRlciBhbiBpbmRldGVybWluYXRlIHJlYWQsIGVhY2ggImp1bXAiIHJlYWxseSBjb25zaXN0cyBv ZiBib3RoIGEKPiBmb3J3YXJkIGFuZCBiYWNrd2FyZCBqdW1wIGZyb20gdGhlIHNvZnR3YXJlIHBl cnNwZWN0aXZlLgo+IAo+IFVubGVzcyB0aGUga2VybmVsIGlzIHRyYXBwaW5nIENOVFZDVCByZWFk cywgYSB1c2Vyc3BhY2UgcHJvZ3JhbSBpcyBhYmxlCj4gdG8gcmVhZCB0aGUgcmVnaXN0ZXIgaW4g YSBsb29wIGZhc3RlciB0aGFuIGl0IGNoYW5nZXMuIEEgdGVzdCBwcm9ncmFtCj4gcnVubmluZyBv biBhbGwgNCBDUFUgY29yZXMgdGhhdCByZXBvcnRlZCBqdW1wcyBsYXJnZXIgdGhhbiAxMDAgbXMg d2FzCj4gcnVuIGZvciAxMy42IGhvdXJzIGFuZCByZXBvcnRlZCB0aGUgZm9sbG93aW5nOgo+IAo+ ICBDb3VudCB8IEV2ZW50Cj4gLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAg IDk5NDAgfCBqdW1wZWQgYmFja3dhcmQgICAgICA2OTltcwo+ICAgIDI2OCB8IGp1bXBlZCBiYWNr d2FyZCAgICAgMTM5OG1zCj4gICAgICAxIHwganVtcGVkIGJhY2t3YXJkICAgICAyMDk3bXMKPiAg MTYwMjAgfCBqdW1wZWQgZm9yd2FyZCAgICAgICAxNzVtcwo+ICAgNjQ0MyB8IGp1bXBlZCBmb3J3 YXJkICAgICAgIDY5OW1zCj4gICAyOTc2IHwganVtcGVkIGZvcndhcmQgICAgICAxMzk4bXMKPiAg ICAgIDkgfCBqdW1wZWQgZm9yd2FyZCAgICAzNTY1MTZtcwo+ICAgICAgOSB8IGp1bXBlZCBmb3J3 YXJkICAgIDM1NzIxNW1zCj4gICAgICA0IHwganVtcGVkIGZvcndhcmQgICAgNzE0NDMwbXMKPiAg ICAgIDEgfCBqdW1wZWQgZm9yd2FyZCAgIDM1Nzg0NDBtcwo+IAo+IFRoaXMgd29ya3Mgb3V0IHRv IGEganVtcCBsYXJnZXIgdGhhbiAxMDAgbXMgYWJvdXQgZXZlcnkgNS41IHNlY29uZHMgb24KPiBl YWNoIENQVSBjb3JlLgo+IAo+IFRoZSBsYXJnZXN0IGp1bXAgKGFsbW9zdCBhbiBob3VyISkgd2Fz IHRoZSBmb2xsb3dpbmcgc2VxdWVuY2Ugb2YgcmVhZHM6Cj4gICAgIDB4MDAwMDAwN2ZmZmZmZmZm ZiDihpIgMHgwMDAwMDA5M2ZlZmZmZmZmIOKGkiAweDAwMDAwMDgwMDAwMDAwMDAKPiAKPiBOb3Rl IHRoYXQgdGhlIG1pZGRsZSBiaXRzIGRvbid0IG5lY2Vzc2FyaWx5IGFsbCByZWFkIGFzIGFsbCB6 ZXJvZXMgb3IKPiBhbGwgb25lcyBkdXJpbmcgdGhlIGFub21hbG91cyBiZWhhdmlvcjsgaG93ZXZl ciB0aGUgbG93IDEwIGJpdHMgY2hlY2tlZAo+IGJ5IHRoZSBmdW5jdGlvbiBpbiB0aGlzIHBhdGNo IGhhdmUgbmV2ZXIgYmVlbiBvYnNlcnZlZCB3aXRoIGFueSBvdGhlcgo+IHZhbHVlLgo+IAo+IEFs c28gbm90ZSB0aGF0IHNtYWxsZXIganVtcHMgYXJlIG11Y2ggbW9yZSBjb21tb24sIHdpdGggYmFj a3dhcmQganVtcHMKPiBvZiAyMDQ4ICgyXjExKSBjeWNsZXMgb2JzZXJ2ZWQgb3ZlciA0MDAgdGlt ZXMgcGVyIHNlY29uZCBvbiBlYWNoIGNvcmUuCj4gKE9mIGNvdXJzZSwgdGhpcyBpcyBwYXJ0aWFs bHkgZXhwbGFpbmVkIGJ5IGxvd2VyIGJpdHMgcm9sbGluZyBvdmVyIG1vcmUKPiBmcmVxdWVudGx5 LikgQW55IG9uZSBvZiB0aGVzZSBjb3VsZCBoYXZlIGNhdXNlZCB0aGUgOTUgeWVhciB0aW1lIHNr aXAuCj4gCj4gU2ltaWxhciBhbm9tYWxpZXMgd2VyZSBvYnNlcnZlZCB3aGlsZSByZWFkaW5nIENO VFBDVCAoYWZ0ZXIgcGF0Y2hpbmcgdGhlCj4ga2VybmVsIHRvIGFsbG93IHJlYWRzIGZyb20gdXNl cnNwYWNlKS4gSG93ZXZlciwgdGhlIENOVFBDVCBqdW1wcyBhcmUKPiBtdWNoIGxlc3MgZnJlcXVl bnQsIGFuZCBvbmx5IHNtYWxsIGp1bXBzIHdlcmUgb2JzZXJ2ZWQuIFRoZSBzYW1lIHByb2dyYW0K PiBhcyBiZWZvcmUgKGV4Y2VwdCBub3cgcmVhZGluZyBDTlRQQ1QpIG9ic2VydmVkIGFmdGVyIDcy IGhvdXJzOgo+IAo+ICBDb3VudCB8IEV2ZW50Cj4gLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KPiAgICAgMTcgfCBqdW1wZWQgYmFja3dhcmQgICAgICA2OTltcwo+ICAgICA1MiB8 IGp1bXBlZCBmb3J3YXJkICAgICAgIDE3NW1zCj4gICAyODMxIHwganVtcGVkIGZvcndhcmQgICAg ICAgNjk5bXMKPiAgICAgIDUgfCBqdW1wZWQgZm9yd2FyZCAgICAgIDEzOThtcwo+IAo+IEZ1cnRo ZXIgaW52ZXN0aWdhdGlvbiBzaG93ZWQgdGhhdCB0aGUgaW5zdGFiaWxpdHkgaW4gQ05UUENUL0NO VFZDVCBhbHNvCj4gYWZmZWN0ZWQgdGhlIHJlc3BlY3RpdmUgdGltZXIncyBUVkFMIHJlZ2lzdGVy LiBUaGUgZm9sbG93aW5nIHZhbHVlcyB3ZXJlCj4gb2JzZXJ2ZWQgaW1tZWRpYXRlbHkgYWZ0ZXIg d3JpdGluZyBDTlZUX1RWQUwgdG8gMHgxMDAwMDAwMDoKPiAKPiAgQ05UVkNUICAgICAgICAgICAg IHwgQ05UVl9UVkFMICB8IENOVFZfQ1ZBTCAgICAgICAgICB8IENOVFZfVFZBTCBFcnJvcgo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLQo+ICAweDAwMDAwMGQ0YTJkOGJmZmYgfCAweDEwMDAzZmZmIHwgMHgwMDAw MDBkNGIyZDhiZmZmIHwgKzB4MDAwMDQwMDAKPiAgMHgwMDAwMDBkNGEyZDk0MDAwIHwgMHgwZmZm ZmZmZiB8IDB4MDAwMDAwZDRiMmQ5N2ZmZiB8IC0weDAwMDA0MDAwCj4gIDB4MDAwMDAwZDRhMmQ5 N2ZmZiB8IDB4MTAwMDNmZmYgfCAweDAwMDAwMGQ0YjJkOTdmZmYgfCArMHgwMDAwNDAwMAo+ICAw eDAwMDAwMGQ0YTJkOWMwMDAgfCAweDBmZmZmZmZmIHwgMHgwMDAwMDBkNGIyZDlmZmZmIHwgLTB4 MDAwMDQwMDAKPiAKPiBUaGUgcGF0dGVybiBvZiBlcnJvcnMgaW4gQ05UVl9UVkFMIHNlZW1lZCB0 byBkZXBlbmQgb24gZXhhY3RseSB3aGljaAo+IHZhbHVlIHdhcyB3cml0dGVuIHRvIGl0LiBGb3Ig ZXhhbXBsZSwgYWZ0ZXIgd3JpdGluZyAweDEwMTAxMDEwOgo+IAo+ICBDTlRWQ1QgICAgICAgICAg ICAgfCBDTlRWX1RWQUwgIHwgQ05UVl9DVkFMICAgICAgICAgIHwgQ05UVl9UVkFMIEVycm9yCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tCj4gIDB4MDAwMDAxYWMzZWZmZmZmZiB8IDB4MTExMDEwMGYgfCAweDAw MDAwMWFjNGYxMDEwMGYgfCArMHgxMDAwMDAwCj4gIDB4MDAwMDAxYWM0MDAwMDAwMCB8IDB4MTAx MDEwMGYgfCAweDAwMDAwMWFjNTExMDEwMGYgfCAtMHgxMDAwMDAwCj4gIDB4MDAwMDAxYWM1OGZm ZmZmZiB8IDB4MTExMDEwMGYgfCAweDAwMDAwMWFjNjkxMDEwMGYgfCArMHgxMDAwMDAwCj4gIDB4 MDAwMDAxYWM2NjAwMDAwMCB8IDB4MTAxMDEwMGYgfCAweDAwMDAwMWFjNzcxMDEwMGYgfCAtMHgx MDAwMDAwCj4gIDB4MDAwMDAxYWM2YWZmZmZmZiB8IDB4MTExMDEwMGYgfCAweDAwMDAwMWFjN2Ix MDEwMGYgfCArMHgxMDAwMDAwCj4gIDB4MDAwMDAxYWM2ZTAwMDAwMCB8IDB4MTAxMDEwMGYgfCAw eDAwMDAwMWFjN2YxMDEwMGYgfCAtMHgxMDAwMDAwCj4gCj4gSSB3YXMgYWxzbyB0d2ljZSBhYmxl IHRvIHJlcHJvZHVjZSB0aGUgaXNzdWUgY292ZXJlZCBieSBBbGx3aW5uZXIncwo+IHdvcmthcm91 bmRbNF0sIHRoYXQgd3JpdGluZyB0byBUVkFMIHNvbWV0aW1lcyBmYWlscywgYW5kIGJvdGggQ1ZB TCBhbmQKPiBUVkFMIGFyZSBsZWZ0IHdpdGggZW50aXJlbHkgYm9ndXMgdmFsdWVzLiBPbmUgd2Fz IHRoZSBmb2xsb3dpbmcgdmFsdWVzOgo+IAo+ICBDTlRWQ1QgICAgICAgICAgICAgfCBDTlRWX1RW QUwgIHwgQ05UVl9DVkFMCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gIDB4MDAwMDAwZDRhMmQ2MDE0YyB8 IDB4OGZiZDU3MjEgfCAweDAwMDAwMGQxMzI5MzVmZmYgKDYxNXMgaW4gdGhlIHBhc3QpCj4gCj4g PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Cj4gCj4gQmVjYXVzZSB0aGUgQ1BVIGNhbiByZWFkIHRoZSBDTlRQQ1Qv Q05UVkNUIHJlZ2lzdGVycyBmYXN0ZXIgdGhhbiB0aGV5Cj4gY2hhbmdlLCBwZXJmb3JtaW5nIHR3 byByZWFkcyBvZiB0aGUgcmVnaXN0ZXIgYW5kIGNvbXBhcmluZyB0aGUgaGlnaCBiaXRzCj4gKGxp a2Ugb3RoZXIgd29ya2Fyb3VuZHMpIGlzIG5vdCBhIHdvcmthYmxlIHNvbHV0aW9uLiBBbmQgYmVj YXVzZSB0aGUKPiB0aW1lciBjYW4ganVtcCBib3RoIGZvcndhcmQgYW5kIGJhY2t3YXJkLCBubyBw YWlyIG9mIHJlYWRzIGNhbgo+IGRpc3Rpbmd1aXNoIGEgZ29vZCB2YWx1ZSBmcm9tIGEgYmFkIG9u ZS4gVGhlIG9ubHkgd2F5IHRvIGd1YXJhbnRlZSBhCj4gZ29vZCB2YWx1ZSBmcm9tIGNvbnNlY3V0 aXZlIHJlYWRzIHdvdWxkIGJlIHRvIHJlYWQgX3RocmVlXyB0aW1lcywgYW5kCj4gdGFrZSB0aGUg bWlkZGxlIHZhbHVlIG9ubHkgaWYgdGhlIHRocmVlIHZhbHVlcyBhcmUgMSkgZWFjaCB1bmlxdWUg YW5kCj4gMikgaW5jcmVhc2luZy4gVGhpcyB0YWtlcyBhdCBtaW5pbXVtIDMgY291bnRlciBjeWNs ZXMgKDEyNSBucyksIG9yIG1vcmUKPiBpZiBhbiBhbm9tYWx5IGlzIGRldGVjdGVkLgo+IAo+IEhv d2V2ZXIsIHNpbmNlIHRoZXJlIGlzIGEgZGlzdGluY3QgcGF0dGVybiB0byB0aGUgYmFkIHZhbHVl cywgd2UgY2FuCj4gb3B0aW1pemUgdGhlIGNvbW1vbiBjYXNlICgxMDIyLzEwMjQgb2YgdGhlIHRp bWUpIHRvIGEgc2luZ2xlIHJlYWQgYnkKPiBzaW1wbHkgaWdub3JpbmcgdmFsdWVzIHRoYXQgbWF0 Y2ggdGhlIGVycm9yIHBhdHRlcm4uIFRoaXMgc3RpbGwgdGFrZXMgbm8KPiBtb3JlIHRoYW4gMyBj eWNsZXMgaW4gdGhlIHdvcnN0IGNhc2UsIGFuZCByZXF1aXJlcyBtdWNoIGxlc3MgY29kZS4gQXMg YW4KPiBhZGRpdGlvbmFsIHNhZmV0eSBjaGVjaywgd2Ugc3RpbGwgbGltaXQgdGhlIGxvb3AgaXRl cmF0aW9uIHRvIHRoZSBudW1iZXIKPiBvZiBtYXgtZnJlcXVlbmN5ICgxLjIgR0h6KSBDUFUgY3lj bGVzIGluIHRocmVlIDI0IE1IeiBjb3VudGVyIHBlcmlvZHMuCj4gCj4gRm9yIHRoZSBUVkFMIHJl Z2lzdGVycywgdGhlIHNpbXBsZSBzb2x1dGlvbiBpcyB0byBub3QgdXNlIHRoZW0uIEluc3RlYWQs Cj4gcmVhZCBvciB3cml0ZSB0aGUgQ1ZBTCBhbmQgY2FsY3VsYXRlIHRoZSBUVkFMIHZhbHVlIGlu IHNvZnR3YXJlLgo+IAo+IEFsdGhvdWdoIHRoZSBtYW51ZmFjdHVyZXIgaXMgYXdhcmUgb2YgYXQg bGVhc3QgcGFydCBvZiB0aGUgZXJyYXR1bVs0XSwKPiB0aGVyZSBpcyBubyBvZmZpY2lhbCBuYW1l IGZvciBpdC4gRm9yIG5vdywgdXNlIHRoZSBrZXJuZWwtaW50ZXJuYWwgbmFtZQo+ICJVTktOT1dO MSIuCj4gCj4gWzFdOiBodHRwczovL2dpdGh1Yi5jb20vYXJtYmlhbi9idWlsZC9jb21taXQvYTA4 Y2Q2ZmU3YWU5Cj4gWzJdOiBodHRwczovL2ZvcnVtLmFybWJpYW4uY29tL3RvcGljLzM0NTgtYTY0 LWRhdGV0aW1lLWNsb2NrLWlzc3VlLwo+IFszXTogaHR0cHM6Ly9pcmNsb2cud2hpdGVxdWFyay5v cmcvbGludXgtc3VueGkvMjAxOC0wMS0yNgo+IFs0XTogaHR0cHM6Ly9naXRodWIuY29tL0FsbHdp bm5lci1Ib21sZXQvSDYtQlNQNC45LWxpbnV4L2Jsb2IvbWFzdGVyL2RyaXZlcnMvY2xvY2tzb3Vy Y2UvYXJtX2FyY2hfdGltZXIuYyNMMjcyCgpuaXQ6IEluIGdlbmVyYWwsIEknbSBub3Qgb3Zlcmx5 IGtlZW4gb24gVVJMcyBpbiBjb21taXQgbWVzc2FnZXMsIGFzIHRoZXkKbWF5IHZhbmlzaCB3aXRo b3V0IG5vdGljZSBhbmQgdGhlIGNvbW1pdCBtZXNzYWdlIGJlY29tZXMgbGVzcyB1c2VmdWwuIElu CnRoZSBmdXR1cmUsIHBsZWFzZSBrZWVwIHRob3NlIGluIHRoZSBjb3ZlciBsZXR0ZXIgKHRob3Vn aCBpbiB0aGlzCnBhcnRpY3VsYXIgY2FzZSwgdGhlIGNvbW1pdCBtZXNzYWdlIGV4cGxhaW5zIHRo ZSBpc3N1ZSBwcmV0dHkgd2VsbCwgc28Kbm8gaGFybSBkb25lIG9uY2UgR2l0SHViIGRpZXMgYSBo b3JyaWJsZSBkZWF0aC4uLiA7LSkuCgpUaGUgZml4IGl0c2VsZiBsb29rcyBwcmV0dHkgc29saWQs IGFuZCB3aWxsIGhvcGVmdWxseSBtYWtlIHRoZQoiQWxsTG9vc2VycyIgSFcgbW9yZSB1c2FibGUu CgpSZXZpZXdlZC1ieTogTWFyYyBaeW5naWVyIDxtYXJjLnp5bmdpZXJAYXJtLmNvbT4KCkRhbmll bCwgcGxlYXNlIGNvbnNpZGVyIHRoaXMgZm9yIHY1LjEuCgpUaGFua3MsCgoJTS4KLS0gCkphenog aXMgbm90IGRlYWQuIEl0IGp1c3Qgc21lbGxzIGZ1bm55Li4uCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlz dApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==