[coreboot] locking...

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 20 02:46:55 CEST 2009

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.


> 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.

> 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.



More information about the coreboot mailing list