linux-kernel - Re: 4.14 regression - hang on shutdown (VIA longhaul related?)

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]

Date:   Mon, 27 Nov 2017 14:26:32 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Meelis Roos <mroos@...ux.ee>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: 4.14 regression - hang on shutdown (VIA longhaul related?)

Hi,

On Mon, Nov 27, 2017 at 11:53 AM, Meelis Roos <mroos@...ux.ee> wrote:
> On my Via EPIA-M min-ITX computer, 4.13 works reliably but 4.14
> shutdown or reboot hangs with message "sda: synchronizing cache".
> Longhaul cpufreq has been enable manually with "longhaul.enable=1" and
> it work but ocassionally logs th efollowing in dmesg:
>
> longhaul: Warning: Timeout while waiting for idle PCI bus
> cpufreq: __target_index: Failed to change cpu frequency: -16
>
> It took time to bisect because with bad kernels, it does not happen each
> time. Bisecting finally leads to the following commit. Reverting just
> this commit makes it work again.
>
> e948bc8fbee077735c2b71b991a5ca5e573f3506 is the first bad commit
> commit e948bc8fbee077735c2b71b991a5ca5e573f3506
> Author: Viresh Kumar <viresh.kumar@...aro.org>
> Date:   Thu Aug 17 09:12:27 2017 +0530
>
>     cpufreq: Cap the default transition delay value to 10 ms
>
>     If transition_delay_us isn't defined by the cpufreq driver, the default
>     value of transition delay (time after which the cpufreq governor will
>     try updating the frequency again) is currently calculated by multiplying
>     transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then
>     converting this time to usec. That gives the exact same value as
>     transition_latency, just that the time unit is usec instead of nsec.
>
>     With acpi-cpufreq for example, transition_latency is set to around 10
>     usec and we get transition delay as 10 ms. Which seems to be a
>     reasonable amount of time to reevaluate the frequency again.
>
>     But for platforms where frequency switching isn't that fast (like ARM),
>     the transition_latency varies from 500 usec to 3 ms, and the transition
>     delay becomes 500 ms to 3 seconds. Of course, that is a pretty bad
>     default value to start with.
>
>     We can try to come across a better formula (instead of multiplying with
>     LATENCY_MULTIPLIER) to solve this problem, but will that be worth it ?
>
>     This patch tries a simple approach and caps the maximum value of default
>     transition delay to 10 ms. Of course, userspace can still come in and
>     change this value anytime or individual drivers can rather provide
>     transition_delay_us instead.
>
>     Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> :040000 040000 7bb8dafb58b703b36fc43d3a081c1a4677a4afde 084c10fa24028461048bcf4b8be5360f36aedd05 M      drivers

Please try to replace the 10000 in
cpufreq_policy_transition_delay_us() with a greater number (say 20000
or 50000) and see if that helps.

Thanks,
Rafael