analogg

Hey, no problem. I'm glad you got it working. This seems like a nice little board. Tomorrow at work... Saturday? Awww. I had the same problem with multishit not moving the DSDT. I wonder if there is a new naming convention, or there's just a bug. Windows... I've got one machine that runs both OS X and Windows 7. I just installed to another HD, like you are doing, and boot from the OS X drive. I'll send you a PM. Cheers, Analogg

30 years... That puts you up there with me. Started with an 8080 at 2MHz, 256 bytes ROM, 8K RAM. Wooo! I've been able to figure some of this stuff out. Really _understanding_ ACPI? No, but the way the code is written makes a bit of sense. I can think of two ways to cause the black screen: A problem with the DSDT - It should end up in /Extra, and be the one you patched. It should be compiled, and have a .aml extension. DSDT.aml is common. The other is the HDMI / 9800GT problem I would have, if I tried to use HDMI. However, in my case, the screen is black even if I use the install stick. I don't think that the installer kexts are any different than those that do get installed. Cheers, Analogg

Artur-pt, I think that is not what is wanted here. Yes, it would eliminate the warning, but would change what the code is doing. The intent is to access the hi and lo bytes separately in a 16 bit value. Using CreateWord would change the access from 8 to 16 bits. Writing the lo byte would change the whole word, and writing the hi byte would change the high byte, plus the byte that follows it. That can't be good. This code appears in the ACPI Implementers' Guide. In the guide, they just use the byte offset, instead of the symbolic value. So, whether it seems like bad practice or not, that's what they recommend. Cheers, Analogg

Originally, I cavalierly ignored them. I did indeed get the same warnings. Three errors, two warnings. I hit the "fix errors" button, and was left with the warnings. After reading your post, I spent some time looking at the warnings. I will now respectfully ignore them. The "raw" DSDT, if re-compiled, yields 3 errors, and 12 warnings. After seeing that, I thought I'd just give it a try. And, it worked. The warnings are about byte fields being created for a buffer at a location where there is a 16-bit value. Intentionally, as far as I can tell. They are taking a 16 bit IO address, and creating byte fields "LO" and "HI". Seems reasonable. The warning occurs for the "LO" part, because the byte offset used evaluates to an entry in the symbol table, and that symbol (the buffer field name) is used. For the "HI" part, the offset+1 does not match a symbol table entry, and the offset (a number) is used instead. The symbol is tagged as a 16 bit value, and the warning is generated. This may have been compiled with warnings. Or, perhaps, a different symbol was used originally, some kind of cast operator was used, or perhaps a pragma was used to suppress warnings. If there was something like that, it was lost in the compile - decompile process. A dirty "fix" would be to change the symbol names used to offsets - (0x02, and 0x04, respectively). This works, generates the same code, with no warnings, but is bad programming practice. I may have over-thought this one. Cheers, Analogg

Hmm, I tried clicking on the patch file, and it downloaded as a .zip, as it should. Inside the zip is a .txt file. I wonder if your browser is automatically opening the file? Anyway, the .txt file is what you will apply as a patch. Regarding the black screen on boot, the PNY 9800GT that I'm using will always give a black screen if I try to use HDMI. I've tried with several systems, and it's the same. I don't know if it's unique to this particular board, or 9800x's in general. So if, after you have a DSDT, you still get black and you are using HDMI, this might be a problem. Here's yet another how-to on patching, this one is pictorial, instead of video. http://www.tonycrapx86.com/dsdt/31716-guide-creating-your-own-dsdt-most-boards.html It's really straightforward, once you get into it.

My setup has a 9800 GT, and some old Seagate rotating storage. At some point, I downloaded the Mountain Lion installer again, to get 10.8.2 on the install stick. It's made life a little easier. The install stick was created with unishit. I had three partitions: one clean 10.8.2, one with Easybeast, one DSDT-free. Neither the Easybeast or the DSDT-free would even boot (black screen). I used the install stick to boot into the clean partition, and delete the /Extra folder from the DSDT-free partition, then booted into it from the install stick. I created the DSDT from there. Oh, at some point, I booted Ubuntu to get the "raw" DSDT. Nice OS. USB 3.0 just works. For the final installation, I cloned the clean install onto the Easybeast partition (only took a few minutes, as all of the files were already there.) I created the DSDT, and left it on the desktop. I ran multishit 5.0.2 and selected... UserDSDT or DSDT-Free Installation Audio.Realtek.WithDSDT.ALC888b/887.v100302 Miscellaneous.FakeSMC Plugins.Motherboard Plugins Miscellaneous.FakeSMC Plugins.HWMonitor Application Network.maolj's AtherosL1cEthernet System.AppleRTC Patch for CMOS Reset Boot Options.Verbose Boot I rebooted, and found I hadn't deleted OemSMBIOS.kext. Grrrr. Fix, reboot, and most things worked. Audio didn't work, but fortunately, my first guess was the layout-id. (I had done lots of reading at this point.) If you are using MB 5.0.2 and OS X 10.8.2, you'll have to delete OemSMBIOS.kext, and then rebuild the kext cache. I've taken to just deleting the kext cache, and letting it get rebuilt on the next boot. (sudo rm /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) If you use MB 5.1.2 (maybe 5.1.1 or later) you don't need to delete OemSMBIOS.kext, but you will have to change the audio layout-id to 1, and the HWMonitor won't work. If you use an SSD, I believe you should also select TRIM Enabler. I don't have any experience with this myself. The easiest way I know of to check for QE/CI is to have a close look at the menu bar. If it's a solid color, no QE/CI. If you can see the background through it, (blurred - basically, any variations in color/brightness) you're good. Just use a background that has some detail at the top of the screen. Again, good luck!

You're welcome! You're welcome! You're welcome! I've been using the "multishit" post install tool. I had used MB 5.1.2, with it's updated features. I just tried a clean install, using MB 5.0.2 with the older hardware monitoring, and audio drivers. I created a DSDT with only the GA-G41M-Combo patch, and ran post-install with MB 5.0.2. The older hardware monitoring works, and with that I can tell that speed stepping works. Uh-oh, audio didn't work. To fix that, I manually changed the audio "layout-id" in the DSDT from "0x0C, 0x00, 0x00, 0x00" to "0x77, 0x03, 0x00, 0x00". You can find that in Device HDEF, which is within Device PCI0. Find them in the tree view on the left side of "DSDT Editor". Click "Device HDEF" in the tree view, and it will appear in the edit window. I'm going to keep this configuration for now, as "everything" seems to work. I just need to find who's working on the hardware monitoring stuff, and mention that there might be an issue. What the heck - I needed to create a new patch file anyway. Attached is the complete patch. Apply that to your "raw" DSDT, and you should be good to go. GA-G41MT-S2PT_DSDT_PATCH.zip

I just got my GA-G41MT-S2PT rev 2.1 working fairly well. The hardware monitoring is not working, and I haven't confirmed speed stepping. Audio and network are working, and both continue to work after sleep, which is itself working. Geekbench scores are what I would expect. I started by extracting the BIOS's DSDT using Ubuntu 12 LTS. I applied to that the patch for the GA-G41M-Combo board. After applying the patch, the system booted, and sleep worked. Audio didn't work, but I'm using the "Optimized Realtek AppleHDA", mentioned here: http://www.tonycrapx86.com/audio/67763-ml-optimized-realtek-applehda-preview-alpha.html. I further added the patches found here: http://www.tonycrapx86.com/audio/67710-ml-how-add-edit-dsdt-hdef.html in the attachment ML_hdef_audio_ids_v1.zip. Specifically, I applied add_hdef.txt, followed by hdef_audio_id_1.txt. In my efforts to determine if the hardware monitoring problem is DSDT related, I've compared 4 of the 9 patches for various Gigabyte G41 series boards. They are all the same. I was hoping to find a different patch for the IT8720 used on the -S2PT, but it looks like it is not different enough from the IT8718 used on the -Combo to warrant a different patch. If you are using the now old-style audio drivers, you can probably just apply the GA-G41M-Combo patch, and call it a day. Even though the audio is different, I don't think it will matter. The patch files I compared were for boards with differing audio, but the patches were all the same. Good luck!