qemu-ppc
[Top][All Lists]
Advanced

[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: Sat, 28 Mar 2015 20:53:20 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

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?


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]