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. 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). 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. > 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. > > 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. -- Sebastian
Attachment:
signature.asc
Description: Digital signature
