On Wed, Oct 31, 2018 at 04:21:30PM +0100, Marek Szyprowski wrote: > Hi Russell, > > On 2018-10-30 11:50, Russell King - ARM Linux wrote: > > On Fri, Oct 05, 2018 at 10:46:19AM +0100, Russell King - ARM Linux wrote: > >> On Fri, Oct 05, 2018 at 11:09:40AM +0200, Marek Szyprowski wrote: > >>> This patch causes lots of kernel 'BUG' messages on all Samsung Exynos > >>> boards. It started to appear since it has been merged to linux-next > >>> on 20181002. I wonder if this issue is Exynos specific or there are > >>> some patches missing in linux-next, which should fix those 'BUGS'. > >>> If this is Exynos specific, please let us know what should be changed > >>> in Exynos platform code to avoid this issue. > >> Thanks for the report. > >> > >> It looks like my solution for big.Little isn't possible... back to > >> the drawing board, and big.Little will have to remain vulnerable to > >> Spectre for another release cycle. > > I've pushed out a new version in my build branch for the autobuilders > > to chew on, but I've little confidence in validating that the problem > > is fixed because the boot results are completely unreliable. > > > > It really doesn't help that kernelci.org flags boot logs as "green" > > and "successful" when they contain such stuff as: > > > > 01:08:40.181846 [ 9.309984] Unable to handle kernel paging request at virtual address e7fddef0 > > > > which is the kernel hitting a BUG() - for the full log, see: > > > > https://storage.kernelci.org/rmk/to-build/v4.16-38-g9fa10446d304/arm/multi_v7_defconfig/lab-collabora/boot-exynos5800-peach-pi.html > > > > This means the only way to check is to _manually_ go through reading > > each and every boot log - to see if your reported BUG: messages are > > there - no thanks. > > > > If kernelci thinks that a boot which hits a kernel BUG(), but still > > manages to get to a shell prompt is successful, it's giving very > > misleading boot results. What about a WARN_ON() or an oops that > > still allows it to reach a shell prompt. > > > > Yes, these may be "successful" in so far as reaching the shell prompt, > > but they should at least be flagged for further inspection, not > > effectively marked as "there is nothing wrong here". > > I've run my own tests on various Exynos SoC based boards and your > 'for-next' branch works fine and don't cause any regressions. The code isn't in for-next because we're in a merge window, and linux-next is supposed to be stable for the duration of that, only accepting bug fixes. It was added briefly to for-next (carefully timed and discussed with Stephen to ensure it didn't appear in linux-next), to try and get fuller builder coverage, which is when the above issue was found. If you want to test, please use its separate branch, 'spectre'. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
