* Sebastian Reichel <sre@xxxxxxxxxx> [150403 09:37]: > Hi, > > On Wed, Apr 01, 2015 at 12:47:36PM -0700, Tony Lindgren wrote: > > > > OK I think debian is using v3.16 kernel > > > > > > Yes. It will be used for Debian jessie (not yet released) and the > > > N900 related drivers are enabled in the armmp flavour. Unfortunately > > > it does not work together with thumb using userland because the > > > errata 430973 workaround is not enabled. > > > > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768890 > > > > Hmm I believe many ARMv8 boards will be randomly oopsing > > with armhf without that. I sort of recall random oopses just > > with running apt-get update on ARMv8 omaps on armhf without that: > > Since I don't know of any ARMv8 omaps, I will read ARMv8 as ARMv7. Sorry right, s/ARMv8/Cortex-A8/ :) > And yes, for armhf userland one gets random oopses at least on the > Nokia N900. AFAIK this is not true for all ARMv7 processors > (especially non omaps), though. > > > http://www.spinics.net/lists/linux-omap/msg108511.html > > > > See also 5c86c5339c56 ("ARM: omap2plus_defconfig: Enable ARM erratum > > 430973 for omap3"). > > For me the random oopses occur without this config flag and are > fixed by it. The workaround is not very suitable for multi platform > kernels, though, since its enabled also for unaffected platforms. > > As far as I can see the CONFIG_ARM_ERRATA_430973 flag is checked > in proc-v7.S and in proc-v7-2level.S. I think the first file is > irrelevant, since it can be fixed later (see workaround in > nokia_n900_legacy_init in pdata-quirks.c). Yes so it seems, and the bootloaders should really set it. It's also disabled for multiplatform builds. > So basically the problem comes down to proc-v7-2level.S > > > I wonder if the ARMv8 revision range might be wrong 430973 in > > kernel or errata? > > what revision range? I think the errata is enabled unconditionally > or disabled completly. The Cortex-A8 range claimed to be affected in Kconfig is listed as r1p0..r1p2. But I recall seeing this also on omap3 (37xx) which is r3p2. Also searching for r3p2 430973 produces: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/254742/891611 And that points to Siarhei's test program that should expose it run together with other processes: https://cloud.github.com/downloads/ssvb/ssvb.github.com/ssvb-cpuburn-a8.S > > Also I recall that 430973 change to the > > arch/arm/mm/proc-v7-2level.S fixed the issue, this should be > > verified though. > > If I understand the errata correctly the BTAC/BTB flushing is > important. It would be nice if it could be limited to affected > devices, though. Agreed. > > > I guess it should be tried to change the workaround, so that it does > > > only change the behaviour of affected platforms. Otherwise its a > > > hard decision for distributions to enable the workaround. > > > > Well we should figure out first why flush BTAC/BTB is needed in > > cpu_v7_switch_mm.. And if what I'm describing above is still > > reproducable. > > Reading the help text in the kernel the flushing is the actual > workaround. The other changes only make it possible to do the > flushing. > > Maybe an option would be to provide two cpu_v7_switch_mm > implementations (one with the errata and one without). Then > the system can start with the simple implementation. Once > the boot as progressed far enough to know, that the hardware > is affected by the errata, it could switch to the implementation > with the flushing. That seems like a good way to deal with it but we should first verify it Siarhei's test program. Also, I think that the armel distro did not have these issue while armhf did, so there may something more to this bug. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
