Waiting for root device when kernel cache used; only with some disks +FIX

[bcc9]

Update: Fix here, for 10.8.x: patch-ahci-mlion.pl.0.3.zip Description

So I've found that I need to turn off the kernelcache (UseKernelCache=no) to boot Mountain Lion DP4. Otherwise, the system hangs trying to mount the root filesystem, periodically printing "Still waiting for root device" over&over.

Now, I only have this problem with GPT partitioned disk drives. When I image the filesystem over to an MBR partitioned disk (using ditto), I can boot just fine with or without the kernelcache. All the partitions I tested were via SATA disks on the same intel SATA disk controller.

 

These same GPT partitioned disks can boot OSX 10.7 just fine, with or without the kernel cache, just not OSX 10.8. This is with chameleon version 1996, so I do have the current 10.8 support in the boot loader.

 

Most of the suggestions concerning this problem appear to be invalid.

Some are focused on general root device mounting problems (AHCI mode missing from bios, usb devices not set up right). These would seem to have nothing to do with the problem at hand, otherwise the problem should apply when the kernel cache is not used.

 

Others suggest 32bit vs 64bit issues, but that question goes away with DP4, as there is no 32 bit kernel/kext.

 

I've looked a bit deeper and I can see from the logging that the correct HFS+ UUID is picked regardless of whether or not I'm booting with the kernel cache on. (Correct "Rooting via boot-uuid from /chosen: xxx" message is displayed).

 

I'm thinking that AppleFileSystemDriver.kext is failing to parse the GPT partition table when the kernel cache is used. Perhaps the kext dependencies are not being processed right, and the kernel cache is built without this kext? Anyone able to unpack /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache under mountain lion?

 

I've rebuilt the kernel cache (and applied the software update to dp4), but these did not fix the problem either.

 

I assume some hackintosh users are able to boot 10.8 via GPT partitioned disks with the kernel cache on, perhaps there are some new GPT partition layout requirements for 10.8?

[bcc9]

Update: I am able to boot from 10.8 GPT partitions with the kernelcache - sometimes.

 

First I converted the MBR partitioned disk to GPT (automatically using the handy gdisk). At this point I *was* able to boot 10.8 from the GPT disk with the kernel cache enabled, with or without an EFI system partition.

 

However, my BIOS had trouble with the EFI system partition, so I upgraded it.

 

On the next boot all my 10.8 GPT partitions booted fine - but just once. On subsequent boots, my first 2 10.8 GPT partitions went back to hanging trying to mount the root device (unless I boot with -f or UseKerenlCache=no) .

 

Perhaps 10.8 introduces new EFI dependencies that we don't know about? I don't think I can truly get to the bottom of this until the 10.8 kernel code is made available.

[bcc9]

After checking with the kernel source regarding how the root filesystem is mounted, I noticed the iokit debugging that is available after the system prints "Still waiting for root device". So I enabled that useful debugging via the boot argument: io=0x1000.

 

Upon booting, the debug info showed me that the system is only attaching 1 of the 3 SATA disk drives on my system; the one that is attaching is the one that boots correctly with or without the kernel cache.

 

So it seems that the kernel is sometimes booting without enough delay for the AHCI HDD detection to happen properly.

 

Does this ring a bell for anyone or am I just talking to myself here?

[fallen101]

To the Three sata devices are they one the same controller?

[bcc9]

To the Three sata devices are they one the same controller?

Yes, they are all via the PCH intel z68 sata controller

ioreg output (from when the system is booted via the 3rd disk), is as follows.

| |   +-o SATA@1F,2  <class IOPCIDevice, id 0x100000184, registered, matched, active, busy 0 (30711 ms), retain 18>
| |   | +-o AppleIntelPchSeriesAHCI  <class AppleIntelPchSeriesAHCI, id 0x1000001c9, registered, matched, active, busy 0 (30597 ms), retain 18>
| |   |   +-o PRT0@0  <class AppleIntelPchSeriesAHCIPort, id 0x100000185, registered, matched, active, busy 0 (30014 ms), retain 13>
| |   |   | +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x1000001ff, registered, matched, active, busy 0 (30014 ms), retain 15>
| |   |   |   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x1000002ad, registered, matched, active, busy 0 (3 ms), retain 7>
| |   |   |	 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x1000002ae, registered, matched, active, busy 0 (3 ms), retain 7>
| |   |   |	   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x1000002b1, registered, matched, active, busy 0 (2 ms), retain 8>
| |   |   |		 +-o SAMSUNG SSD 830 Series Media  <class IOMedia, id 0x1000002b2, registered, matched, active, busy 0 (2 ms), retain 11>
| |   |   |		   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002b3, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |		   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x1000002b5, !registered, !matched, active, busy 0 (1 ms), retain 10>
| |   |   |			 +-o EFI System@1  <class IOMedia, id 0x1000002b8, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002be, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o Linux filesystem@2  <class IOMedia, id 0x1000002b9, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002bd, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o Apple_HFS_Untitled_2@3  <class IOMedia, id 0x1000002ba, registered, matched, active, busy 0 (1 ms), retain 10>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c0, registered, matched, active, busy 0 (0 ms), retain 7>
| |   |   |			 +-o BIOS boot partition@4  <class IOMedia, id 0x1000002bb, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c1, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o Linux filesystem@5  <class IOMedia, id 0x1000002bc, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002bf, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   +-o PRT1@1  <class AppleIntelPchSeriesAHCIPort, id 0x100000188, registered, matched, active, busy 0 (0 ms), retain 10>
| |   |   +-o PRT2@2  <class AppleIntelPchSeriesAHCIPort, id 0x100000221, registered, matched, active, busy 0 (30029 ms), retain 11>
| |   |   | +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x100000223, registered, matched, active, busy 0 (30029 ms), retain 20>
| |   |   |   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x1000002c2, registered, matched, active, busy 0 (15 ms), retain 7>
| |   |   |	 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x1000002c3, registered, matched, active, busy 0 (15 ms), retain 7>
| |   |   |	   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x1000002c6, registered, matched, active, busy 0 (14 ms), retain 8>
| |   |   |		 +-o SAMSUNG HD103SJ Media  <class IOMedia, id 0x1000002c7, registered, matched, active, busy 0 (14 ms), retain 11>
| |   |   |		   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c8, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |		   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x1000002ca, !registered, !matched, active, busy 0 (2 ms), retain 15>
| |   |   |			 +-o EFI System Partition@1  <class IOMedia, id 0x1000002cd, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d8, registered, matched, active, busy 0 (1 ms), retain 6>
| |   |   |			 +-o nlion@2  <class IOMedia, id 0x1000002ce, registered, matched, active, busy 0 (2 ms), retain 10>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d9, registered, matched, active, busy 0 (0 ms), retain 7>
| |   |   |			 +-o nsnow@3  <class IOMedia, id 0x1000002cf, registered, matched, active, busy 0 (2 ms), retain 10>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d6, registered, matched, active, busy 0 (1 ms), retain 7>
| |   |   |			 +-o x1@4  <class IOMedia, id 0x1000002d0, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002da, registered, matched, active, busy 0 (1 ms), retain 6>
| |   |   |			 +-o x2@5  <class IOMedia, id 0x1000002d1, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002dc, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o nsnow 2 2 2@6  <class IOMedia, id 0x1000002d2, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002dd, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o nsnow 2 2 2 2 1@7  <class IOMedia, id 0x1000002d3, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002db, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o nsnow 2 2 2 2 2 1@8  <class IOMedia, id 0x1000002d4, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002de, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o nsnow 2 2 2 2 2 2@9  <class IOMedia, id 0x1000002d5, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002df, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   |			 +-o BIOS boot partition@10  <class IOMedia, id 0x1000002d7, registered, matched, active, busy 0 (1 ms), retain 9>
| |   |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002e0, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |   +-o PRT3@3  <class AppleIntelPchSeriesAHCIPort, id 0x100000225, registered, matched, active, busy 0 (0 ms), retain 8>
| |   |   +-o PRT4@4  <class AppleIntelPchSeriesAHCIPort, id 0x100000227, registered, matched, active, busy 0 (0 ms), retain 8>
| |   |   +-o PRT5@5  <class AppleIntelPchSeriesAHCIPort, id 0x100000229, registered, matched, active, busy 0 (38 ms), retain 11>
| |   |	 +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x10000022b, registered, matched, active, busy 0 (38 ms), retain 14>
| |   |	   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x10000022c, registered, matched, active, busy 0 (35 ms), retain 7>
| |   |		 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x10000022d, registered, matched, active, busy 0 (35 ms), retain 7>
| |   |		   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x100000230, registered, matched, active, busy 0 (35 ms), retain 8>
| |   |			 +-o ST3750330AS Media  <class IOMedia, id 0x100000231, registered, matched, active, busy 0 (35 ms), retain 11>
| |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x100000232, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |			   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x100000234, !registered, !matched, active, busy 0 (19 ms), retain 9>
| |   |				 +-o EFI System@1  <class IOMedia, id 0x100000237, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023b, registered, matched, active, busy 0 (0 ms), retain 6>
| |   |				 +-o Apple HFS/HFS+@2  <class IOMedia, id 0x100000238, registered, matched, active, busy 0 (19 ms), retain 10>
| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023d, registered, matched, active, busy 0 (0 ms), retain 7>
| |   |				 +-o Apple HFS/HFS+@7  <class IOMedia, id 0x100000239, registered, matched, active, busy 0 (18 ms), retain 11>
| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023c, registered, matched, active, busy 0 (0 ms), retain 7>
| |   |				 +-o Linux filesystem@8  <class IOMedia, id 0x10000023a, registered, matched, active, busy 0 (0 ms), retain 9>
| |   |				   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023e, registered, matched, active, busy 0 (0 ms), retain 6>

Interestingly, the 3rd disk, the one that always probes correctly, is the slowest.

[eep357]

jeez, how many bootable ML installs do you have? No errors building the cache when booted from any of these disks and are you rebooting using the kernel cache only after it was successfully rebuilt? I don't know that's it's related per se, but I did have a problem only under mountain lion where my GPT time machine drive would cause chameleon to freeze. Had to either unplug it to boot or reformat, but the issue would return after a few backups. The solution was to format the drive using older Apple Partition scheme which is non-bootable. Since a time machine only drive should not cause this behavior, it is a bug, but could be a chameleon with ML problem vs just a ML problem

[bcc9]

jeez, how many bootable ML installs do you have? No errors building the cache when booted from any of these disks and are you rebooting using the kernel cache only after it was successfully rebuilt? I don't know that's it's related per se, but I did have a problem only under mountain lion where my GPT time machine drive would cause chameleon to freeze. Had to either unplug it to boot or reformat, but the issue would return after a few backups. The solution was to format the drive using older Apple Partition scheme which is non-bootable. Since a time machine only drive should not cause this behavior, it is a bug, but could be a chameleon with ML problem vs just a ML problem

I only installed mountain lion once, but I copied it to two other disks to troubleshoot the "waiting for root device" issue. I multiboot, so I have a bunch of other partitions.

 

I had noticed that booting would hang for a few minutes if I used a GPT partition table and the EFI System partition was not well formed, this is why updating my BIOS was one of my first attempted fixes. I suspect this is what you were seeing when you thought chameleon was freezing.

 

Yes, I've tried rebuilding the kernel cache manually and also automatically. I don't believe you have to manually rebuild the kernel cache, as touching /S/L/E is supposed to be sufficient according to OSX documentation. In any case, rebuilding the cache has made no difference.

 

BTW, the following is the IOServicePlane tree dump produced from the io=0x1000 debugging. This shows that only the 3rd disk was probed correctly by the OS.

[eep357]

So what happens when you only have one of the disks plugged in (the one you want to boot into obviously, which I'm guessing is the Samsung F3 and not the SSD or the Barracuda)?

[bcc9]

So what happens when you only have one of the disks plugged in (the one you want to boot into obviously, which I'm guessing is the Samsung F3 and not the SSD or the Barracuda)?

Doesn't help, I tried several combinations, and- only the older seagate boots 10.8 with caching enabled.

 

HOWEVER, I did stumble upon a workaround!

 

If I boot with debug=8 ahcidisk=1, then I can boot from any of my disks/partitions with caching enabled. Looks like the extra debug logging slows down the AHCI driver just enough that it is able to finally properly attach all 3 disks at boot time.

Seems like a pretty nasty time dependent bug in 10.8.

[eep357]

Here, this may help as well. https://ata.wiki.kernel.org/index.php/Known_issues

[bcc9]

Here, this may help as well. https://ata.wiki.ker...hp/Known_issues

I don't see how. My BIOS probes all my AHCI disks just fine always, as does linux, and OSX 10.7. The problem is unique to OSX 10.8.

[TimeWalker75a]

The problem is new AHCI kexts that are partially compatible /w series 6 chipset. If you install the lateat update (security test update) from the appstore the problem will be gone for good. Had the same issue with DP4 even after the first update. Or you could swap AppleAHCI and IOAHCIFamily out /w the kexts from Lion

[bcc9]

The problem is new AHCI kexts that are partially compatible /w series 6 chipset. If you install the lateat update (security test update) from the appstore the problem will be gone for good. Had the same issue with DP4 even after the first update. Or you could swap AppleAHCI and IOAHCIFamily out /w the kexts from Lion

That doesn't sound right, Apple added sandy bridge AHCI support as of 10.6.x, about a year ago, when they introduced sandy bridge macs like the imac12. 10.7 had proper sandy bridge support as well, and I've been using OSX on a sandy bridge hackintosh (with this same hardware) since 10.6 timeframe.

 

So it doesn't make sense that 10.8 DP4 would be missing some sandy bridge AHCI support when those older releases had it. Yes there's evidently a bug in their driver, but that's a bit different.

 

Do you have any references for this problem (was this reported somewhere?) I wouldn't have bothered with 10.8 on this machine if I had known of such an outstanding issue.

 

Also, I updated with the latest DP4 security test update and it made no difference. The AHCI kexts and kernel cache were updated, but I still have to boot with ahcidisk=1 debug=8 or without caching.

 

Perhaps a better workaround than ahcidisk=1 debug=8 would be to fix chameleon to not output reams of kext read messages when booting with -v. Then booting without the cache would still be quick and it wouldn't matter much that it had been disabled.

[TimeWalker75a]

It is a bug in thei driver since it is just a preview it is not yet perfect. Until DP3 people with series 5 chipsets had same issues. Should I point out how long these chipsets have been around ?

Look at JMicron kexts for that matter - it doesnt even have a binray in it and official updater is failing to assemble proper kernel cache because of that.

The problem has been reported numerous times on various forums (I'm mostly active on AppleLife which is a Russian community). The latest update has solved the problem for me for good. I'm not sure about Chameleon though because I'm not using it, but XPC and Clover are able to boot /w caches now .

[bcc9]

Ok, well what you are describing seems to have nothing to do with the problem I've been reporting, and I still don't see any references to your claim that DP4 only has partial AHCI support for sandy bridge. That would be pretty incredible since all of the current gen macs are sandy bridge.

 

In any case your proposed fix doesn't work, and upon close inspection of the DP4 security test update, the IOAHCIFamily changes are just a renumber (the code in the binary remains the same). So your info seems generally incorrect.

[eep357]

I don't have your system or hardware, so of course would be far less familiar with it than you would be. So rather than try to provide you with a possible solution to fix your's, I will instead tell you of I problem I experienced with my own, different hardware that may have nothing to do with what your dealing with. At the time I was using DP2 as it had just been released along with whatever was ErmaC's newest Chameleon branch was at that time as well. My issues came when creating a bootable clone of my working installation and the problem occurred regardless of where I made the copy, be it on the same drive or a different one. All of my internal and external HDs (10 total) except for one, were GPT at the time. Without going into the symptoms, it turned out that my DSDT would not load properly if it was included in the chameleon partition as well as the partition I was choosing to boot into, even though the logs showed no issues and indicated it was loaded successfully. Removing the extra folder from my other partitions except for my primary ML/Chameleon partition and the 2 boot OSX helper partitions on my 2 Lion RAID-0 drives, returned all to normal. Chameleon should not have had any issues dumping the first loaded one and reloading from the partition I was booting into, but it did. Just thought I'd share one of my ML experiences and I hope you are able to find the solution to yours.

[bcc9]

Yes, chameleon is capable of doing surprising things with respect to its choices for the partitions to load config state from. I assure you I'm not having such a problem.

 

My temporary fix of slowing the driver down with ahcidisk=1 debug=8 has been working great so far.

 

Also, I did try clover instead of chameleon - same result (ahcdisk=1 debug=8 required to mount root filesystem when kernel cache is enabled).

[bcc9]

Unfortunately this apparent timing bug remains in 10.8 GM. My current workaround of <key>Kernel Flags</key><string>-v ahcidisk=1 debug=8</string> is still working fine, but not really what I want to be stuck with.

 

So I did a bit more troubleshooting on IOAHCIBlockStorage.kext, even though it was a real pain to bisect this timing bug with a binary only driver. Through some binary patch magic, I managed to find that any one of the kprintf()s in IOAHCIBlockStorageDriver::start() that are run before the first call to IOAHCIBlockStorageDriver::IdentifyDevice() are sufficient to make all my hard disks identify properly (and thus no root device mounting problem). Without the kprintf()s outputting to the console, the IdentifyDevice() is run more quickly and my faster disks don't get identified.

 

Seems like there should be a config option to make the driver delay during the IdentifyDevice phase. Anyone know of such an option?

[DoiX]

Hey, i have the same problem on my laptop (only one HDD), but in my case it occurred only after DP, anyway, congrats on finding a workaround!

[bcc9]

Hey, i have the same problem on my laptop (only one HDD), but in my case it occurred only after DP, anyway, congrats on finding a workaround!

What does only after DP mean?

So does the workaround work for you?

[DoiX]

Oh damn, numpad was off. I meant after DP2 and Yes, it works. On clover however it does a funny thing, it fills my screen with artifacts/glitches.

 

*further clarification: on the first and second ML DP i could boot normally, starting with DP3 this bug got introduced, at first i thought it's because i was using old kexts to get some things working (it happened on 10.7.4) but it turned out that wasn't the case.

[bcc9]

Oh damn, numpad was off. I meant after DP2 and Yes, it works. On clover however it does a funny thing, it fills my screen with artifacts/glitches.

I think I saw that with clover, and it was due to clover defaulting the board-id poorly for intel HD graphics. Try <key>Board-ID</key><string>Mac-94245B3640C91C81</string> in your config.plist.

ver*further clarification: on the first and second ML DP i could boot normally, starting with DP3 this bug got introduced, at first i thought it's because i was using old kexts to get some things working (it happened on 10.7.4) but it turned out that wasn't the case.

I suspect the issue is that the newer DPs have the 32 bit kexts stripped, and so the system loads faster, and so the timing bug is then uncovered.

From digging a bit deeper, the bug seems to be that IOAHCIBlockStorage only sends out its Identify command once, presumably the disk is not ready at that point, and so the identify fails (and the driver doesn't retry sending this command. Adding a kprintf() before the identify operation slows things down enough for things to work. Still investigating...

 

PS: What kind of disk are you having trouble with, samsung? (My two problem disks are samsungs)

[DoiX]

Mine is Toshiba, 7200RPM.

 

I already have that board ID set. With chameleon my system was more forgiving when it came to bugs, but on clover it's another story, if a kext or setting in the conf file isn't okay for my laptop the whole screen gets filled with artifacts. Anyway, debug=8 is causing the artifacts ( i tried to check the source code of clover but i HATE source forge, so i didn't find anything) i believe it's still reporting every debug on a subsystem level but yet again, i have no idea how clover works.

 

Wouldn't using a non 32bit stripped AHCIBlockStorage kext fix this or ML made it impossible to use even it? Also, i have no idea how you managed to add kprintf() in binary, could you enlighten me on this subject? I consider it valuable knowledge to know how to binpatch kexts.

[bcc9]

I already have that board ID set. With chameleon my system was forgiving related to bugs, but on clover it's another story, if a kext or setting in the conf file isn't okay for my laptop the whole screen gets filled with artifacts.

I also had to set <key>ProductName</key><string>MacBookPro8,1</string>, maybe that was it (sorry I did very limited clover testing)

Anyway, debug=8 is causing the artifacts ( i tried to check the source code of clover but i HATE source forge, so i didn't find anything) i believe it's still reporting every debug on a subsystem level but yet again, i have no idea how clover works.

 

Wouldn't using a non 32bit stripped AHCIBlockStorage kext fix this or ML made it impossible to use even it? Also, i have no idea how you managed to add kprintf() in binary, could you enlighten me on this subject? I consider it valuable knowledge to know how to binpatch kexts.

You can just do a simple 'svn co https://cloverefiboo...t/cloverefiboot cloverefiboot', and then you don't need to use the web page for anything.

It's more like the opposite - I suspect if you go back to DP2 and lipo -thin x86_64 your FAT kexts that the timing bug would occur there too.

 

As for the kprintf, the kprintf is in the production code, so turning on those two debug options cause it to actually execute (and output slowly via the serial port, thus the time delay).

I suspect I could patch the first kprintf in the kext with an unconditional IOSleep(100) or IODelay(100*1000) to fix the timing without any debug switches required.

[DoiX]

Also set, i even injected the proper snbplatform id and several other settings to reduce artifacts (been doing this since lion). Duh, snv co. Totally forgot about it, i guess i got turned down by the folder structure. I'm used to the simple and clean chameleon one.

 

It's really a stupid bug... being to fast breaks stuff. Really apple? I'm curious tho if this happens on MBPs/SSDs as well. Guess we have to wait for ML to go live to see.

 

Well, i assume you can do the same thing with a patched IOPCIFamily kext, having the sources would make it a lot easier.