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

[Programmingkid]

On Mar 19, 2015, at 8:00 AM, Mark Cave-Ayland wrote:

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?

What I found out is that XNU's variables are reference counted. An integer variable keeps count of the number of references a variable has. The reference count of the gIODTDefaultInterruptController does go to zero. So the value it has is released. The variable is set correctly from the start, so I know that isn't an issue. This does appear to be a simple NULL pointer exception.

Using a watchpoint in gdb, the exact code that sets the retainCount to zero was found. 

Here is the stack trace of where the gIODTDefaultInterruptController variable is set to zero:

#0  0x002faed0 in .L_AAretry ()

#1  0x002ea3c0 in OSObject::release (this=0x1fae8c8, when=1) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSObject.cpp:117

#2  0x002ea42c in OSObject::release (this=0x1) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSObject.cpp:123

#3  0x002eb1fc in OSArray::flushCollection (this=0x1fc57e8) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSArray.cpp:209

#4  0x002eafc4 in OSArray::free (this=0x1fc57e8) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSArray.cpp:153

#5  0x002ea3e0 in OSObject::release (this=0x1fc57e8, when=1) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSObject.cpp:118

#6  0x002ea42c in OSObject::release (this=0x1) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSObject.cpp:123

#7  0x002ef3cc in OSDictionary::setObject (this=0x1fc1950, aKey=0x1fc57e8, anObject=0x2012a28) at /Users/misbah/Desktop/xnu-123.5/libkern/c++/OSDictionary.cpp:312

#8  0x0021e37c in IORegistryEntry::setProperty (this=0x1ffa5e0, aKey=0x1fa9e40, anObject=0x2012a28) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IORegistryEntry.cpp:631

#9  0x0024ac70 in IOCPUInterruptController::setCPUInterruptProperties (this=0x1f9f4d0, service=0x1ffa5e0) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOCPU.cpp:339

#10 0x00246cf4 in IOPlatformExpert::setCPUInterruptProperties (this=0x1, service=0x1ffa5e0) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOPlatformExpert.cpp:281

#11 0x0d4c23cc in ?? ()

#12 0x00227ba4 in IOService::startCandidate (this=0x1faab60, service=0x1fa1620) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOService.cpp:2098

#13 0x00227998 in IOService::probeCandidates (this=0x1ffa5e0, matches=0x1fa1620) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOService.cpp:2065

#14 0x002284a4 in IOService::doServiceMatch (this=0x1ffa5e0, options=33220812) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOService.cpp:2294

#15 0x00228b8c in _IOConfigThread::main (self=0x1fbb788) at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOService.cpp:2483

#16 0x00217acc in ioThreadStart () at /Users/misbah/Desktop/xnu-123.5/iokit/Kernel/IOLib.c:119

#17 0x000551cc in thread_continue (old_thread=0x0) at /Users/misbah/Desktop/xnu-123.5/osfmk/kern/sched_prim.c:1340

The place where the fault takes place is in the AppleHeathrow kernel - at code that tries accessing the gIODTDefaultInterruptController variable. 

I originally thought this might be an issue with OpenBIOS also. Still trying to determine the problem.