Hello,
enclosed the kernel panic we obtain after boot with a slightly patched
upstream kernel (4.5.2).
(as well as the patchset applied to the upstream kernel, so that you can
know which code we are talking about. Too bad we cannot use the upstream
kernel but we had no choice about this + we're no experts so we rely on
provided patches, adapted to our bootloader and hardware for this)
Reproduce:
boot on kernel on an armada375 module, connect to it, launch a top in
commandline
As seen with Marcin Wojtas, reverting commit
e864b4c7b184bde36fa6a02bb3190983d2f796f9 fixes this issue.
Reporting upstream so that you can decide what should be done next
Tell me if you need more information
Regards
Raphael
Hello,
On Mon, 2 May 2016 11:46:46 +0200, Raphael G wrote:
enclosed the kernel panic we obtain after boot with a slightly patched
upstream kernel (4.5.2).
(as well as the patchset applied to the upstream kernel, so that you can
know which code we are talking about. Too bad we cannot use the upstream
kernel but we had no choice about this + we're no experts so we rely on
provided patches, adapted to our bootloader and hardware for this)
Reproduce:
boot on kernel on an armada375 module, connect to it, launch a top in
commandline
As seen with Marcin Wojtas, reverting commit
e864b4c7b184bde36fa6a02bb3190983d2f796f9 fixes this issue.
Reporting upstream so that you can decide what should be done next
Thanks for your report. I have finally submitted a fix for this issue.
You can find it at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473989.html
If you have the time to test it and report back, it would be very
useful.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com