On 19.06.2009 18:13, Myles Watson wrote: >> as we move into the multicore world, messages get harder and harder to >> read when they are interspersed byte-wise. I propose to add optional >> locking to printk. >> > This should only matter for the time during RAM, right? Is it a larger > issue? >
Once we have printk in CAR for almost all CPUs, it matters even for CAR stage. >> However, this locking has to work when some CPUs are in CAR and others >> are in RAM. And that's the big problem. >> > Yuck. > At least that's what I believe can happen on K8 and later platforms. >> AFAICS we can't simply use atomic normal memory acceses since the CPUs >> in CAR won't see that. Atomic register modifications are not possible >> across processors AFAICS. >> The only idea I have is abusing some MMIO chipset/CPU space which is >> usable as scratch space. In theory, that should work. But do CPUs or >> chipsets have such MMIO areas? >> > They do. It's hard to know if someone is already (ab)using them, though. > Well, a quick (or not so quick) coreboot code search should help find out if the areas in question are already used. Do you know of an example fur such a MMIO area for the K8 with 690/SB600? That would help me implement a proof of concept. >> Of course, I'm aware that locking (if possible at all) will be highly >> CPU/chipset dependent, but even if we can make locking work on only a >> subset of platforms, it is still a lot better than nothing. >> > Are you thinking of putting it in the ops of the cpu device? I guess that > only works after CAR. > Actually, I'd use it as a function outside the device tree inside CPU and/or chipset code. The device tree is available too late to be useful here. > Another option would be to only let the BSP print messages by default. That > would clean up most people's logs most of the time. > Except for the problem Ward is seeing right now. For that, we really want the AP messages. And preferably they should be readable (not intertwined). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
