11 Replies Latest reply: Aug 27, 2010 6:37 PM by R C-R
dfgfgre Level 1 Level 1 (0 points)
One morning I found my MacBook frozen and with fans spinning noisy. It refused to boot anymore, even off the install DVD. I started in target disk mode and checked the disk, which was fine. The Apple Hardware Test also ran without complaints, although I've already been supposing a grilled CPU.

However a Knoppix Live DVD surprisingly started with the noacpi flag enabled. Linux loaded and ran perfectly. Since then I've been trying to achieve the same result with XNU boot flags but without success.

The current situation is:
- I moved all but the essential kexts out of the Extensions folder, keeping only these:
AppleAPIC.kext
AppleFileSystemDriver.kext
AppleRTC.kext
AppleSMBIOS.kext
IOACPIFamily.kext
IOATAFamily.kext
IOHIDFamily.kext
IOPCIFamily.kext
IOSCSIArchitectureModelFamily.kext
IOStorageFamily.kext
IOUSBFamily.kext
IOUSBMassStorageClass.kext
System.kext

- com.apple.Boot.plist contains these flags: -v cpus=1 acpi=off

and the kernel hangs early on load with the last couple of messages being:

ACPI: System State [ ...
mbinit: done ...
rooting via boot-uuid from /chosen: ...
Waiting on <dict ID="0"><key>IOProviderClass ...
-------------------

- when I omit either the cpus or the acpi flag, the kernel stops loading after the ACPI line and sometimes I get a kernel panic stating (among many lines of text): processor registers corrupt

So, my questions are:
1. Which parameters and/or kexts should I pass to the XNU kernel in order to achieve the same behaviour like Linux - loading with ACPI disabled (or loading at all)?
2. How could I track down the problem?
3. If the thermal sensor or something else on the CPU (Intel Core 2 Duo) is being burned out, is there a tool to test this, i.e. can I tell that there will be no data corruption when I install and use Linux on the MacBook?

Thanks in advance!
Erik

MacBook, Mac OS X (10.6.4)
  • 1. Re: How can I _really_ disable ACPI?
    William Lloyd Level 6 Level 6 (19,355 points)
    No, dude. Just... no.
  • 2. Re: How can I _really_ disable ACPI?
    R C-R Level 6 Level 6 (14,175 points)
    The first thing you need to consider is that XNU is an acronym for "X is not UNIX." This is a reminder that the OS X kernel is substantially different from other UNIX variants, being a unique hybrid of Mach and BSD kernel components. If you try to use features provided by some other kernel, you will most likely be disappointed in the results.

    Moreover, as described in System Startup Programming Topics: The Boot Process, the boot process is unique to the Mac, & depending on the circumstances, the boot loader may need to load some drivers and other kernel extensions early in the boot process, before the kernel can be linked & initialized. Much of this depends on the *I/O Kit*, a part of XNU that is radically different from traditional systems. For more about this, see for example XNU: The Kernel.

    The bottom line is that just removing what you consider to be non-essential extensions & modifying com.apple.Boot.plist has about zero chances of doing anything besides breaking the boot or kernel initialization process.

    If your MacBook won't boot into OS X, it is likely because some system files were corrupt, or possibly because of other modifications you have performed on system level components. What you are doing is basically like trying to put a bandaid on a terminally ill patient. Trying to hack the OS isn't going to get you anywhere, at least if your goal is running OS X stably.

    Message was edited by: R C-R
  • 3. Re: How can I _really_ disable ACPI?
    dfgfgre Level 1 Level 1 (0 points)
    Well, I see ... The weird thing is, that this has to be a hardware problem as I boot and run flawlessly the same installation on my Mac Mini off the MacBook's hard disk via FireWire and Target Disk Mode. So, no - no files or system level components are corrupt ...

    On the other hand, the hardware bug seems not to be that serious, if Linux loads despite some missing functionality (I am suspecting a temperature sensor of the CPU). Is there a Intel CPU testing tool to track this down?

    And what if I compile my own kernel? Apple releases the XNU sources. I would like to know all options before going Linux ...

    Greets,
    Erik
  • 4. Re: How can I _really_ disable ACPI?
    R C-R Level 6 Level 6 (14,175 points)
    I'm not quite sure how you hope to solve a hardware problem by using a different kernel -- no matter what, it is a workaround, not a solution.

    Compiling your own kernel is a formidable task, at least if you want to run OS X frameworks on it. That will take a lot of study of the developer docs, & remember: Darwin is only a part of OS X. Much of OS X is closed source & not well documented.
  • 5. Re: How can I _really_ disable ACPI?
    The hatter Level 9 Level 9 (58,880 points)
    < One morning I found my MacBook frozen and with fans spinning noisy. It refused to boot anymore, even off the install DVD.

    Boot from external drive is okay?
    Then the directory isn't totally corrupt, something that can prevent booting from CD/DVDs.

    Use Disk Warrior, don't assume that no error report in Apple First Aid means 100% clean bill of health.

    AHT does not look for file system errors.

    Maybe there is a bad block hidden in the partition tables, maybe not, but until you rule out such things, I'd just reinitialize and restore and check how many spare blocks used now.
  • 6. Re: How can I _really_ disable ACPI?
    Martin Pace Level 5 Level 5 (5,090 points)
    Well, I see ... The weird thing is, that this has to be a hardware problem as I boot and run flawlessly the same installation on my Mac Mini off the MacBook's hard disk via FireWire and Target Disk Mode. So, no - no files or system level components are corrupt ...


    A Mac Mini and a MacBook are not identical and may use different drivers for some of their components. A driver used by the MacBook may be corrupt while the driver used by the Mac Mini is not. Try an archive and install.

    Other things to try are a PRAM reset and SMC reset.

    Message was edited by: Martin Pace
  • 7. Re: How can I _really_ disable ACPI?
    R C-R Level 6 Level 6 (14,175 points)
    Then the directory isn't totally corrupt, something that can prevent booting from CD/DVDs.


    How can a corrupted file system on a HD prevent booting from an entirely different device? If you invoke the Startup Manager (option key start), nothing is loaded from any storage device until you choose one to boot from, & then it loads everything from that device.
  • 8. Re: How can I _really_ disable ACPI?
    dfgfgre Level 1 Level 1 (0 points)
    The point with the different drivers for MacBook and Mac Mini is an interesting one. But all the low level drivers are actually kexts and, as I mentioned, I stripped the system down to the bones leaving only 15 crucial kexts. And, yes, I made of course a PRAM and SMC reset.

    I will mark the question as answered, as there is obviously no solution (well, a workaround). If someone has an idea how to gain more control over the kernel extensions, at least how NOT to load certain kexts, please share with us

    Message was edited by: dfgfgre
  • 9. Re: How can I _really_ disable ACPI?
    The hatter Level 9 Level 9 (58,880 points)
    It does, it has, it has been confirmed (not in your universe but showed up years ago and pulling the hdd solved the no boot situation) apparently even during boot there is a scan of volumes, and a really really bad directory will do it.

    Even EFI boot manager can't handle those drives.
  • 10. Re: How can I _really_ disable ACPI?
    dfgfgre Level 1 Level 1 (0 points)
    Well, ok, we are talking here about kernel loading, and as soon as the kernel and its modules are read off the disk into memory, even a corruption of some file or some area of the HDD won't prevent the kernel from loading any more. All disk corruptions have no impact after this point until the kernel is loaded and a runlevel is entered. Then, yes, disk corruptions come into play again.

    What happens in my case is that one of the kexts tries to talk to a buggy hardware, which is not responding or gives a bogus response and this interrupts the loading process. It is funny that the XNU kernel loads it extensions based on a mysterious logic that nobody knows of or can control ... it has a touch of black magic
  • 11. Re: How can I _really_ disable ACPI?
    R C-R Level 6 Level 6 (14,175 points)
    dfgfgre wrote:
    It is funny that the XNU kernel loads it extensions based on a mysterious logic that nobody knows of or can control ... it has a touch of black magic


    There is no mysterious logic about it. The process is well explained in the previously mentioned System Startup Programming Topic & related links, expecially I/O Kit Fundamentals: Introduction to I/O Kit Fundamentals.

    What is mysterious is your explanation about what will or won't prevent the kernel & extensions to it from loading, which makes no sense in light of the material in these references. And while instances of needing to disconnect the HD to get a system to boot from another source are quite possible, there is no reason to think that "a really really bad directory" is the cause, whatever that mysterious phrase is supposed to mean.

    Think about it: a directory is a feature of a file system. At boot time, no method of accessing any file system exists in the computer. The bootROM (which is in firmware) starts the process by first doing POST, which initializes some of the hardware, & then selects the operating system to run. If there is a partition on some device previously set for that in PRAM (for instance, by using the Startup Disk System Preference), it will choose that one unless one of two exceptions occur: 1) the user overrides that by invoking the Startup Manager (also in firmware) or 2) the chosen device isn't available for some reason, in which case the firmware starts looking for the first available device with a boot loader. In either of these two exceptions, it is certainly possible that a bad boot loader from the device would halt the boot process, but if the user takes control of the choice by evoking the Startup Manager, unless there is a hardware problem in the computer itself, this is a non-issue, assuming a viable boot loader is chosen.

    Only after the boot loader loads the kernel environment from the device (which for OS X among other things means building the I/O device tree) can that kernel provide the low level services necessary to access the file systems it supports.

    If you want to take control of the boot process, you can -- but you must be familiar with all of the requirements involved, including those mentioned in the previously mentioned references, the EFI boot process, & so on. But in no case will this exempt you from the problems "buggy" hardware will cause. There is nothing whatsoever mysterious about that.