[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.
- [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Programmingkid, 2015/03/13
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Mark Cave-Ayland, 2015/03/13
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Programmingkid, 2015/03/13
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot,
Mark Cave-Ayland <=
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Programmingkid, 2015/03/19
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Mark Cave-Ayland, 2015/03/28
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Programmingkid, 2015/03/28
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Mark Cave-Ayland, 2015/03/28
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Programmingkid, 2015/03/28