[coreboot] locking...

[Carl-Daniel Hailfinger]

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

-- 
http://www.hailfinger.org/