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/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
