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

[Programmingkid]

On Mar 28, 2015, at 4:53 PM, Mark Cave-Ayland wrote:

> On 28/03/15 20:47, Programmingkid wrote:
> 
>> On Mar 28, 2015, at 4:29 PM, Mark Cave-Ayland wrote:
>> 
>>> 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?
>> I have compiled Mac OS 10.2's kernel before. It sounds like you want me
>> to take Mac OS 10.2's kernel and try to use it in my Mac OS 10.0 boot CD.
>> The test probably wouldn't yield any useful information.  
>> ... goes and tries it....
>> It causes a kernel panic. 
>> 
>>> If this is
>>> the case, a diff between the old and new modules should help isolate
>>> exactly what the issue is.
>> 
>> The thing is there are thousands of changes that took place between those two
>> operating system versions. Your idea might work, but it would probably take
>> years to figure out.
> 
> I was actually thinking of just the AppleHeathrow kext module, but if it
> doesn't compile in a 10.0 tree then at least a visual diff between the
> two versions of Heathrow.cpp both the old and new versions may provide
> some insight?

From what I understand, it is a problem with the kernel. A global variable that 
the
AppleHeathrow kernel extension uses is null when it should contain a value. A 
quick
look at the AppleHeathrow source code does reveal that the 
gIODTDefaultInterruptController
variable is still used in Mac OS 10.2.