[General Omni Discussion] Lanchon:
been reading the news. the problem in my mind with interrupts and timers is, given that there is no code in the kernel that touches the FPU, i can't figure out a credible scenario for FP corruption as a result of a bug in that area.

unless the bug affects the trap that does the lazy FPU state restore. but i imagine that this code depends exclusively on arm IP, not exynos peripheral weirdness, so i discount that. (disclaimer: i dont know the linux kernel, the arm arch, and much less exynos.) i'm also assuming that the cores work well when they are not transitioning to/from a power saving state; i think i saw enough evidence for this.

basically i imagine 2 scenarios (feel free to add):

-fpu state crosstalk between userland processes

-plain old clobbering with random (external) data

to differentiate we need to view the corruption in action. now that people are working on this again, i'll mod my corruption detector over the weekend to sleep between checks, and hopefully it will work this time. the detector will clearly show if there's crosstalk and the extent, and also the values if it is just clobbering.

my hunch here is we'll find clobbering.

assuming it's clobbering, these are the possible scenarios i can think of (feel free to add):

#1) the state is not restored correctly

one scenario would be this: bug in silicon: the (FPU?) core is powered up and the kernel starts using it. but the voltages are not stable enough when the kernel restores the FPU state and very few times the state is corrupted. in this case we would likely see mostly 00s or FFs in the registers.

how to test: in the code that loads the fpu state from ram, we immediately test after loading it by comparing against the copy in ram.

for the record, this is very very unlikely to be the cause i think.

#2) the state is not saved correctly

one scenario, bug in silicon: the kernel saves the FPU state to ram. the save is a "big" block of ram, maybe fills a cache line or more, and thus the write is handled differently by the hardware than other writes. then the core is powered down before the core-local cache state is fully flushed to whatever comes next. it affects only the FPU because all other writes done by the kernel prior to core shutdown are scattered; this one is different.

how to test: enlarge the save structure and write the register bank twice; check consistency of the two copies in the restore code.

#3) the save/restore machinery fails

one scenario, bug in silicon: imagine arm arch requires that after core power up the FPU is disabled. the linux kernel rightly omits disabling the FPU after powering up a core. but this buggy soc sometimes wakes up with FPU enabled. linux dispatches a userland thread, the thread uses the FPU, and because its enabled, the core doesnt trap. linux cant restore state and the thread sees the power up state (mostly 00s or FFs i guess). alternatively: linux dispatches a userland thread and the thread doesnt use the FPU in its slice. during next context switch linux sees the FPU enabled and thus saves state, clobbering the correct saved state in ram. next time the thread uses the FPU it sees the FPU power up state that was saved.

how to test: check the FPU enable flag after powering up a core.

there might be many other scenarios like these.

what would be potential scenarios involving interrupts or timers that would corrupt FPU state?

i'll post a detector soon.