On 25.08.12 19:37, Mark Cave-Ayland wrote:
On 25/08/12 18:01, Andreas Tobler wrote:
SRR0 is the fault IP. So if the fault at hand is an instruction fetch fault, yes, that would be the address at fault. If it's a data fault you would have to check DAR for the address it faults in.
It might also help to boot the guest with -d in_asm,cpu,int and check out /tmp/qemu.log afterwards. Search for the IP that faulted and see why exactly it did.
Whoa!!! The first try I ended after the log grew over 5GB :)
The next step was enabling the logging at a position where I knew it is going to happen soon.
Below the excerpt from the qemu.log.
Now the big question for me, what does this exactly say?
Thanks for your hints, really appreciated!
Hi Mark!
Do you get any output with just OpenBIOS built with DEBUG_CIF enabled in libopenbios/client.c? According to my email here, one of the things I found a while back was that the dma-alloc method wasn't defined in OpenBIOS for PPC when trying to boot (see the OpenBIOS archives for more information).
Yeah, with this DEBUG option enabled I see something. The last entry is about mmu and translations. Then it hangs. Well, it is in an endless loop inside the FreeBSD kernel.
I my repeat myself, but the kernel starts booting from the loader. And then, maybe after the mmu is on in the kernel? the exception occurs.
The dma-alloc issues I found in the archives appear much earlier in the boot process, right? And do I get it right, that if needed, the dma-alloc, I'd get an exception?
(Me new in this business ;)
Thanks, Andreas
....
finddevice("/chosen") = 0xfff45644 getprop(0xfff45644, "mmu", 0x00c21efc, 4) = 4 0x00c21efc 0f b5 a8 70 __ __ __ __ __ __ __ __ __ __ __ __ .??p instance-to-package(0x0fb5a870) = 0xfff521c8 getproplen(0xfff521c8, "translations") = 0x00000250 getprop(0xfff521c8, "translations", 0x00024000, 592) = 592 0x00024000 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00
......@......... ..... ..... .....