[coreboot] locking...

[Carl-Daniel Hailfinger]

On 20.06.2009 00:47, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>>> v2 has / used to have working locking code since it was first ported to
>>> opteron. It may be that it broke while adding 5 more printks but it is
>>> there somewhere.
>>>   
>>>     
>>>       
>> Any hints on where to look are appreciated. I'd like to use locking
>> inside printk ASAP.
>>   
>>     
>
> Where does the locking algorithm fail? My guess is, it's in romcc or CAR
> code. Where we are out of luck with all approaches of synchronization so
> far.
>   

Well, if the stack for the BSP and each AP are at different locations
and there are no cache overlaps, using the BSP stack for lock variables
should work even in the partial-CAR case. At least that's what I hope.


> do_printk is defined in src/console/printk.c as:
>
> int do_printk(int msg_level, const char *fmt, ...)
> {
> [...]
>         spin_lock(&console_lock);
>
>         va_start(args, fmt);
>         i = vtxprintf(console_tx_byte, fmt, args);
>         va_end(args);
>         console_tx_flush();
>
>         spin_unlock(&console_lock);
> [...]
> }
>   

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

Besides that, do we know where static spinlock_t console_lock is placed?
I can't figure out from the linker where it is.


> (we should just rename this to printk and use it the v3 way instead of
> the printk_<loglevel> layers on top, but that's orthogonal, too)
>   

Yes please!

Regards,
Carl-Daniel

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