<snip>
Actually, the TinyBIOS "workaround" is the same thing.
Like I may have said before, there is a reason why this MSR is undocumented.
It works, but the behavior is unvalidated, and obviously erratic. When we
first developed this code, we were using the Geode GX on the OLPC with VSA,
so using the MSR was nessesary if we wanted to get our hands on any
timers at all. Mitch Bradley (author of OpenFirmware) determined through
testing that the MSR was erratic, especially when you ran it when all the
timers were already clear. I suspect thats the problem that we see here -
writing the MSR in TinyBIOS unstablizied the registers, and writing the
MSR again kicked it back. Of course, the unfortunate corollary is that
when the workaround isn't in v0.99, if you run the MSR in the kernel, then
you will end up destabilizing everything.
Furthermore, using the MSR is okay with TinyBIOS, but not okay with the
other Geode BIOSen (Insyde, General Software, and for the moment LinuxBIOS)
because VSA (the SMM handler) _does_ use some of the timers. So needless
to say, I'm concerned.
We control the timer and the status bits for the timer in the setup
register, which is what you are showing above. Thats fine.
Hmm - are you running with nohz? I ran the same thing on the OLPC
and I'm getting 81 IRQ/s which is okay, considering that sugar was running
in the background.
Hmm - yeah, my math is off there - it is a 32768 Hz clock. That
shouldn't affect things too negatively - if it does we can adjust the
divisor we use - currently we use 16.
I'm not sure if we can - all we can tell is if the registers are zero or
not. Like I said, running the MSR is probably dangerous in 9 out of 10
situations, the one good use being the one you determined. I would
support adding the mfgptfix bit though - just as long as it isn't
automagic.
Thank you very much for your help!
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
--
