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