[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: |
Programmingkid |
Subject: |
Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot |
Date: |
Fri, 13 Mar 2015 11:10:17 -0400 |
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
- [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 <=
- Re: [Qemu-ppc] Possible reason why Mac OS 10.0 fails to boot, Mark Cave-Ayland, 2015/03/19
- 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