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

[Mark Cave-Ayland]

On 19/03/15 15:03, Programmingkid wrote:

> 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. 

Well we know that the xnu kernel equivalent of OS X 10.2/Darwin 6.02
already runs fine under QEMU, so are you able to compile the newer
kernel module for the older kernel, and if so does it work? If this is
the case, a diff between the old and new modules should help isolate
exactly what the issue is.


ATB,

Mark.