linux-kernel - Re: Banana Pi-R1 stabil

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: <20190227092023.nvr34byfjranujfm@flea>
Date:   Wed, 27 Feb 2019 10:20:23 +0100
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Gerhard Wiesinger <lists@...singer.com>
Cc:     arm@...ts.fedoraproject.org, Chen-Yu Tsai <wens@...e.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Florian Fainelli <f.fainelli@...il.com>, filbar@...trum.cz
Subject: Re: Banana Pi-R1 stabil

On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote:
> Hello,
> 
> I've 3 Banana Pi R1, one running with self compiled kernel
> 4.7.4-200.BPiR1.fc24.armv7hl and old Fedora 25 which is VERY STABLE, the 2
> others are running with Fedora 29 latest, kernel 4.20.10-200.fc29.armv7hl. I
> tried a lot of kernels between of around 4.11
> (kernel-4.11.10-200.fc25.armv7hl) until 4.20.10 but all had crashes without
> any output on the serial console or kernel panics after a short time of
> period (minutes, hours, max. days)
> 
> Latest known working and stable self compiled kernel: kernel
> 4.7.4-200.BPiR1.fc24.armv7hl:
> 
> https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/
> 
> With 4.8.x the DSA b53 switch infrastructure has been introduced which
> didn't work (until ca8931948344c485569b04821d1f6bcebccd376b and kernel
> 4.18.x):
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/dsa/b53?h=v4.20.12
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/dsa/b53?h=v4.20.12
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/dsa/b53?h=v4.20.12&id=ca8931948344c485569b04821d1f6bcebccd376b
> 
> I has been fixed with kernel 4.18.x:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/dsa/b53?h=linux-4.18.y
> 
> 
> So current status is, that kernel crashes regularly, see some samples below.
> It is typically a "Unable to handle kernel paging request at virtual addres"
> 
> Another interesting thing: A Banana Pro works well (which has also an
> Allwinner A20 in the same revision) running same Fedora 29 and latest
> kernels (e.g. kernel 4.20.10-200.fc29.armv7hl.).
> 
> Since it happens on 2 different devices and with different power supplies
> (all with enough power) and also the same type which works well on the
> working old kernel) a hardware issue is very unlikely.
> 
> I guess it has something to do with virtual memory.
> 
> Any ideas?

> [47322.960193] Unable to handle kernel paging request at virtual addres 5675d0

That line is a bit suspicious

Anyway, cpufreq is known to cause those kind of errors when the
voltage / frequency association is not correct.

Given the stack trace and that the BananaPro doesn't have cpufreq
enabled, my first guess would be that it's what's happening. Could you
try using the performance governor and see if it's more stable?

If it is, then using this:
https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test

will help you find the offending voltage-frequency couple.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com