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