lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANAwSgTbhYPBdiiO0qcHDN2eVJS+NLJXKK1eqRF50mzVi-Tycg@mail.gmail.com>
Date:   Sat, 17 Dec 2016 13:01:41 +0530
From:   Anand Moon <linux.amoon@...il.com>
To:     Markus Reichl <m.reichl@...etechno.de>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Doug Anderson <dianders@...omium.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Arjun K V <arjun.kv@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Andreas Faerber <afaerber@...e.de>,
        Thomas Abraham <thomas.ab@...sung.com>,
        Ben Gamari <ben@...rt-cactus.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Alim <alim.akhtar@...sung.com>
Subject: Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hi Markus,

On 16 December 2016 at 14:38, Markus Reichl <m.reichl@...etechno.de> wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>   (unfortunately Inderpal's email is no longer working). ]
>>>>
>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>> IOW if the problem exists it is already present in the mainline
>>>> kernel.
>>>
>>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>>> needed...  Note that one might naively look at
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>
>>> 1362500, /* L0  2100 */
>>> 1312500, /* L1  2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead.  See
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>
>>> { 2100000,
>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>> 1275000, 1262500, 1250000, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>>                     1200000, 1187500, 1175000, 1162500, 1150000,
>>                            1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.

[snip]

As per my knowlegde Odroid XU3/4 can throttle at much high temperature.

https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/thermal/exynos_thermal.c#L1629

The device tree binding for thermal-zone is kept bit low alert
temperature values
in-order to avoid reaches critical temperature and board shutdown
when compiling the source code. We need t fix this thermal-zone

Their could be some race in thermal or the step wise governor for
exynos is not working correctly.

Better option is to print the cpufreq for cpu0 and cpu4 and respective temp
and plot a graph along timeline. It will give us clear idea on how much
time is spend on high frequency on stress testing.

#!/bin/bash
t=0
while true :
do
 a=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
 b=`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`
 c=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`
 d=`cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq`
 e=`cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_cur_freq`
 (( t += 5 ))
 echo $t,$a,$b,$d,$e
 sleep 1
done

Best Regards
-Anand Moon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ