On 20.06.2009 02:17, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
do_printk is defined in src/arch/i386/lib/printk_init.c as almost identical function, but without console_tx_flush and without locking. If only one CPU uses the lockless variant, we lose.
This is the version that was intended to be used when CONFIG_USE_INIT is set.
Ah.
Does the _flush actually do much? I had the impression that we flush after each character anyways, but I'm no terminal expert.
_flush calls tx_flush for each driver, but all console drivers in the tree lack such a tx_flush function, so it's essentially an expensive no-op because all console driver structs are walked each time. Kill?
Other than that, we could unify those versions by just defining an empty (for now) version of the spinlock functions in raminit stage. Then think about where we can place our locking for those platforms that need it this early...?
Sounds like a plan.
A quick test abuild with #error inserted in the lockless function shows we indeed use it for every freaking x86 target. That explains the supermicro/h8dme intertwined printk messages Ward is seeing.
They're from ram init stage afaict ...
If we need them instead of the generic variants, we should know a reason for such usage.
Besides that, do we know where static spinlock_t console_lock is placed?
In RAM
So we'd get uninitialied data for any pre-RAM spinlock access? The v3 global variable mechanism should solve this nicely. At least it was designed for that.
grep console_lock *.map coreboot_ram.map:00122058 d console_lock smm.map:000a13fc t console_lock
(raminit stage symbols are in coreboot.map)
Thanks for the hint, now I know where to look.
Regards, Carl-Daniel