qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot
Date: Thu, 19 Mar 2015 12:00:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

On 13/03/15 15:10, Programmingkid wrote:

> On Mar 13, 2015, at 7:00 AM, Mark Cave-Ayland wrote:
> 
>> On 13/03/15 04:13, Programmingkid wrote:
>>
>>> I have been looking into why Mac OS 10.0 fails to boot. The kernel
>>> extension that causes Mac OS 10.0 to panic is called AppleHeathrow.kext.
>>> The exact line of code that causes it to crash is in a method called
>>> Heathrow::getInterruptControllerName(). When this function tries to
>>> access the gIODTDefaultInterruptController variable, a panic takes
>>> place. The address of this variable is around 3313684 or 0x329014. I am
>>> thinking this is a region where global variables are kept. Using the
>>> 'info mtree' command in the Monitor didn't reveal anything helpful. But
>>> there are also several items listed in the output that doesn't have a
>>> memory address region displayed. I'm thinking the kernel is placing
>>> global variables in a region of memory that QEMU or something else is
>>> already using. Would anyone know a way to verify this. The address in
>>> question is 0x329014. Any help would be great.
>>
>> Can you explain more about your debugging process? If you're able to use
>> a debugger then you should have a lot more information at your disposal.
>>
>>
>> ATB,
>>
>> Mark.
>>
> 
> Yeah sure. I compile my own AppleHeathrow kernel extension with all the 
> symbols kept in it. I use IOLog() to print where execution is taking place in 
> the extension. At the line where the gIODTDefaultInterruptController variable 
> is accessed, the panic takes place. It is this code:
> IOLog("gIODTDefaultInterruptController's value = %s\n", 
> gIODTDefaultInterruptController->getCStringNoCopy()); 
> 
> I did a test where I actually set the gIODTDefaultInterruptController 
> variable before it was accessed. It fixed the panic problem and allowed the 
> kernel to boot all the way to the recognition of the boot device. It doesn't 
> go any further because the kernel just keeps printing "still waiting for root 
> device".
> 
> The variable is defined in the kernel, here: 
> http://www.opensource.apple.com/source/xnu/xnu-123.5/iokit/Kernel/IODeviceTreeSupport.cpp
> 
> The kernel extension source code I use is here:
> http://www.opensource.apple.com/source/AppleHeathrow/AppleHeathrow-1.0.0d7/Heathrow.cpp

Interesting work indeed. Perhaps the issue is that
gIODTDefaultInterruptController isn't being set because of a missing
property in the device tree which is why detection fails? What exactly
is the fault too? Is it a NULL pointer exception?


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]