On 18.10.2008 01:36, Jordan Crouse wrote:
On 18/10/08 00:28 +0200, Carl-Daniel Hailfinger wrote:
On 17.10.2008 23:57, Myles Watson wrote:
Yes. I know when it was a new feature I tried it out and didn't see this garbage.
I remember it working well some time ago. It would be great if you could do a binary search and narrow it down. I can then fix the problem.
I don't ever remember it working exactly right. If you look at the output, it matches what ever is living at physical address 0x0 - at least for the first page or so. Clearly there is come contention here.
That would be indeed bad. However, I remember that Marc checked some time ago with an FS2 that the code behaved as intended. And I checked right now with svn HEAD that a v3 boot in qemu has the post-CAR printk buffer at exactly one location (0x90000) and except for remnants at the original CAR printk buffer location, the contents of the buffer don't appear anywhere else nor are they garbled.
If you want t dump the low 1M of qemu from the qemu console, try this: memsave 0x0 0x100000 lowmem.dump
Multiple possibilities: - My qemu works differently from yours - Your payload is broken - Your tree is broken
Neither of them is something I'm happy about.
Regards, Carl-Daniel