After discovering yesterday that this system will indeed run ML, I decided to do a fresh install to see if I could get it working that way. I first tried to remove the GeForce 210 video card and did the install using the onboard video. This worked just fine to install and update the system to 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at least there were no install problems. With no DSDT in place, the BIOS got set back to default with each boot, but only a couple of items need to be changed to make this Hackintosh friendly.
Next I decided to add the 210 video card and an /Extra folder with only the DSDT file in it. This caused the system to no longer boot, hanging at the PCI configuration begin line. So my goal today is to find out exactly what is causing that, it obviously has to be either the addition of the card or DSDT.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
On Wednesday, October 31, 2012 10:57:31 AM UTC-4, hackintosh1x wrote:
> After discovering yesterday that this system will indeed run ML, I decided > to do a fresh install to see if I could get it working that way. I first > tried to remove the GeForce 210 video card and did the install using the > onboard video. This worked just fine to install and update the system to > 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at > least there were no install problems. With no DSDT in place, the BIOS got > set back to default with each boot, but only a couple of items need to be > changed to make this Hackintosh friendly.
> Next I decided to add the 210 video card and an /Extra folder with only > the DSDT file in it. This caused the system to no longer boot, hanging at > the PCI configuration begin line. So my goal today is to find out exactly > what is causing that, it obviously has to be either the addition of the > card or DSDT.
Removing the GeForce 210 video card allows the system to boot normally, so this problem must be related to the NV bug which prevents the system from booting. The cloned system from the DS3L suffered from the same problem and the NV override had been performed on that system prior to moving it over to this system. I will give that a try next to see if that will allow the system to boot up with the video card installed.
> On Wednesday, October 31, 2012 10:57:31 AM UTC-4, hackintosh1x wrote:
> After discovering yesterday that this system will indeed run ML, I decided to do a fresh install to see if I could get it working that way. I first tried to remove the GeForce 210 video card and did the install using the onboard video. This worked just fine to install and update the system to 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at least there were no install problems. With no DSDT in place, the BIOS got set back to default with each boot, but only a couple of items need to be changed to make this Hackintosh friendly.
> Next I decided to add the 210 video card and an /Extra folder with only the DSDT file in it. This caused the system to no longer boot, hanging at the PCI configuration begin line. So my goal today is to find out exactly what is causing that, it obviously has to be either the addition of the card or DSDT.
> Removing the GeForce 210 video card allows the system to boot normally, so this problem must be related to the NV bug which prevents the system from booting. The cloned system from the DS3L suffered from the same problem and the NV override had been performed on that system prior to moving it over to this system. I will give that a try next to see if that will allow the system to boot up with the video card installed.
Interesting. After applying the NVoverride and installing the video card once more, the system still hangs at PCI configuration begin. Back to the drawing board.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
On Wednesday, October 31, 2012 11:36:31 AM UTC-4, hackintosh1x wrote:
> On Oct 31, 2012, at 11:22 AM, hackintosh1x wrote:
> On Wednesday, October 31, 2012 10:57:31 AM UTC-4, hackintosh1x wrote:
>> After discovering yesterday that this system will indeed run ML, I >> decided to do a fresh install to see if I could get it working that way. I >> first tried to remove the GeForce 210 video card and did the install using >> the onboard video. This worked just fine to install and update the system >> to 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at >> least there were no install problems. With no DSDT in place, the BIOS got >> set back to default with each boot, but only a couple of items need to be >> changed to make this Hackintosh friendly.
>> Next I decided to add the 210 video card and an /Extra folder with only >> the DSDT file in it. This caused the system to no longer boot, hanging at >> the PCI configuration begin line. So my goal today is to find out exactly >> what is causing that, it obviously has to be either the addition of the >> card or DSDT.
> Removing the GeForce 210 video card allows the system to boot normally, so > this problem must be related to the NV bug which prevents the system from > booting. The cloned system from the DS3L suffered from the same problem and > the NV override had been performed on that system prior to moving it over > to this system. I will give that a try next to see if that will allow the > system to boot up with the video card installed.
> Interesting. After applying the NVoverride and installing the video card > once more, the system still hangs at PCI configuration begin. Back to the > drawing board.
> On Wednesday, October 31, 2012 11:36:31 AM UTC-4, hackintosh1x wrote:
> On Oct 31, 2012, at 11:22 AM, hackintosh1x wrote:
>> On Wednesday, October 31, 2012 10:57:31 AM UTC-4, hackintosh1x wrote:
>> After discovering yesterday that this system will indeed run ML, I decided to do a fresh install to see if I could get it working that way. I first tried to remove the GeForce 210 video card and did the install using the onboard video. This worked just fine to install and update the system to 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at least there were no install problems. With no DSDT in place, the BIOS got set back to default with each boot, but only a couple of items need to be changed to make this Hackintosh friendly.
>> Next I decided to add the 210 video card and an /Extra folder with only the DSDT file in it. This caused the system to no longer boot, hanging at the PCI configuration begin line. So my goal today is to find out exactly what is causing that, it obviously has to be either the addition of the card or DSDT.
>> Removing the GeForce 210 video card allows the system to boot normally, so this problem must be related to the NV bug which prevents the system from booting. The cloned system from the DS3L suffered from the same problem and the NV override had been performed on that system prior to moving it over to this system. I will give that a try next to see if that will allow the system to boot up with the video card installed.
> Interesting. After applying the NVoverride and installing the video card once more, the system still hangs at PCI configuration begin. Back to the drawing board.
> After reading this thread, I'm wondering if it really can be that simple. I'll give this a try first to see if it works.
Not quite. I made the change, repaired permissions and when I booted with the card inserted, I got a white screen with black blocks at the top. Now I'm wondering if perhaps using the NVoverride might have caused this. My plan now is to clone the current Lion system and then try to update that to ML. Once done I will add the vender and device id's once more and see what happens.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
On Wednesday, October 31, 2012 12:55:48 PM UTC-4, hackintosh1x wrote:
> On Oct 31, 2012, at 11:47 AM, hackintosh1x wrote:
> On Wednesday, October 31, 2012 11:36:31 AM UTC-4, hackintosh1x wrote:
>> On Oct 31, 2012, at 11:22 AM, hackintosh1x wrote:
>> On Wednesday, October 31, 2012 10:57:31 AM UTC-4, hackintosh1x wrote:
>>> After discovering yesterday that this system will indeed run ML, I >>> decided to do a fresh install to see if I could get it working that way. I >>> first tried to remove the GeForce 210 video card and did the install using >>> the onboard video. This worked just fine to install and update the system >>> to 10.8.2. Of course the video was limited to 1024x768 and no QE/CI, but at >>> least there were no install problems. With no DSDT in place, the BIOS got >>> set back to default with each boot, but only a couple of items need to be >>> changed to make this Hackintosh friendly.
>>> Next I decided to add the 210 video card and an /Extra folder with only >>> the DSDT file in it. This caused the system to no longer boot, hanging at >>> the PCI configuration begin line. So my goal today is to find out exactly >>> what is causing that, it obviously has to be either the addition of the >>> card or DSDT.
>> Removing the GeForce 210 video card allows the system to boot normally, >> so this problem must be related to the NV bug which prevents the system >> from booting. The cloned system from the DS3L suffered from the same >> problem and the NV override had been performed on that system prior to >> moving it over to this system. I will give that a try next to see if that >> will allow the system to boot up with the video card installed.
>> Interesting. After applying the NVoverride and installing the video card >> once more, the system still hangs at PCI configuration begin. Back to the >> drawing board.
> Not quite. I made the change, repaired permissions and when I booted with > the card inserted, I got a white screen with black blocks at the top. Now > I'm wondering if perhaps using the NVoverride might have caused this. My > plan now is to clone the current Lion system and then try to update that to > ML. Once done I will add the vender and device id's once more and see what > happens.
No luck so far. I have done a full update of my Lion install, then added the device/vendor id's, but verbose boot stuck without continuing to the desktop. Then I went back and did another bare install (completely updated), added the device/vendor id's, but then on the reboot, I got that same messed up video screen and took a picture<https://docs.google.com/open?id=0B-nE6U1IUPG0X3ozUXpYUjVaZVU>of it this time. Now all I have to do figure out why this is happening.
> After discovering yesterday that this system will indeed run ML ...
A 945GC (that's the GMAC/Northbridge) are most often found paired with an
ICH7 (that's the Southbridge).
This combo is immediately compatible with Lion, and even with all
resolutions and CI/QE.
When the usual PCI-e 16x slot is stuffed with an 8400GS or better, it is
immediately compatible with Mountain Lion.
Nothing particularly wrong with a 945GC/ICH7 except its (generally) small
RAM capacity, usually 2 GB or 4GB ... definitely 4 GB at the most.
USB 2.0/1.1 performance is OK. With a PCI-e 1x card, USB 3.0 is possible.
Alas, the sound chip is seldom one of the preferred ALC8xx ones, although
I DO have two such boards which have the very nice ALC888s.
LAN is almost always R8111.
Basically, a very solid board, although with a relatively low growth
potential.
I have a Shuttle 945-based system, since discontinued, but often available
on eBay from a NYC-based seller for cheap for brand-new units.
As the ICH7 includes built-in IDE, and the Shuttle "prints" the
connections for IDE devices, one has the option of allocating IDE to the
optical and hard drives, and then to use SATA for external devices.
Alas, the Shuttle K45 (that's what Shuttle Inc calls its 945GC-equipped
model) has a Marvell 88E8056 gigabit E-net LAN (for which support is
available for ALL Intel versions of OS X) and an ALC662 codec (for which
Voodoo or the hacked AppleHDA immediately applies), also NO PCIe-16x shot,
so no Mountain Lion.
If anyone wants to play with a real econo-Shuttle, I have my DSDT
available for it.
Remember, the Supermicro server was a 945GC-based machine, and it proved
to be quite usable on Server Lion. Supported 4 GB, too.
> Basically, a very solid board, although with a relatively low growth
> potential.
> I have a Shuttle 945-based system, since discontinued, but often available
> on eBay from a NYC-based seller for cheap for brand-new units.
> As the ICH7 includes built-in IDE, and the Shuttle "prints" the
> connections for IDE devices, one has the option of allocating IDE to the
> optical and hard drives, and then to use SATA for external devices.
> Alas, the Shuttle K45 (that's what Shuttle Inc calls its 945GC-equipped
> model) has a Marvell 88E8056 gigabit E-net LAN (for which support is
> available for ALL Intel versions of OS X) and an ALC662 codec (for which
> Voodoo or the hacked AppleHDA immediately applies), also NO PCIe-16x shot,
> so no Mountain Lion.
> If anyone wants to play with a real econo-Shuttle, I have my DSDT
> available for it.
> Remember, the Supermicro server was a 945GC-based machine, and it proved
> to be quite usable on Server Lion. Supported 4 GB, too.
This is all well and good, but something is obviously stopping this one from working properly with an 8400GS as I made the swap for that card once I found it worked okay using the cloned DS3L ML partition. And this was initially using the DS3L DSDT which I left in place but later swapped for the GA-945GCMX-S2 DSDT. Obviously the problem lies somewhere in the video card being incompatible with the OS as it works fine other than no QE/CI and single resolution with the onboard GMA950 video. And the same card works fine under Lion.
I'm stepping away from it for now, as I often do, to get a better handle on what the problem might be.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
I found this post on Insanely that explains a lot about Nvidia kexts and how to make them work with any partiuclar card. I think it will help with my understanding of the subject.
On Wednesday, October 31, 2012 10:19:15 PM UTC-4, hackintosh1x wrote:
> I found this post on Insanely that explains a lot about Nvidia kexts and > how to make them work with any partiuclar card. I think it will help with > my understanding of the subject.
After reading a bit of the above, it's clear that the device/vendor id's need to be inserted into both the NVDANV50Hal.kext and NVDAResman.kext as well. Since I only put it in the former and not the latter, perhaps that may be the problem. I will give that a try next.
>>> Alas, the sound chip is seldom one of the preferred ALC8xx ones,
>>> although
>>> I DO have two such boards which have the very nice ALC888s.
>> Actually this one has an ALC888.
> Those MSI 945 systems we bought some time ago had ALC888s.
> Quite a versatile little machine:
> 2 legacy PCI slots
> 1 PCI-e 16x slot
> 1 PCI-e 1x slot
> I think I paid about $99 for them at Fry's Electronics.
> Still have them around, too, although not immediately functional.
Not sure what happened to mine, probably lost in the move. A lot of computer stuff got thrown out. They weren't as Hackintosh friendly as the Gigabyte boards IIRC.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
>> Still have them around, too, although not immediately functional.
> Not sure what happened to mine, probably lost in the move. A lot of
> computer stuff got thrown out. They weren't as Hackintosh friendly as the
> Gigabyte boards IIRC.
The BIOS support was W-E-A-K.
Mainly supported Pentium 4s, Pentium Ds, Celerons both single and dual,
and a rather limited number of Core 2 Duos (none of the very fast ones,
such as the E8400) and NO C2Qs.
There WAS a final BIOS update in 2007, and it was for added processor
microcode support.
> On Wednesday, October 31, 2012 10:19:15 PM UTC-4, hackintosh1x wrote:
> I found this post on Insanely that explains a lot about Nvidia kexts and how to make them work with any partiuclar card. I think it will help with my understanding of the subject.
> After reading a bit of the above, it's clear that the device/vendor id's need to be inserted into both the NVDANV50Hal.kext and NVDAResman.kext as well. Since I only put it in the former and not the latter, perhaps that may be the problem. I will give that a try next.
That was a bust, same results, improper video. Not sure I altered the NVDAResman.kext properly as I could not locate where to put the device/vendor info. I did find a line with the vendor info, but the device was listed as null 0x0000, so I just changed that to 0x0422, which is the device number. Guess I will go back and read some more.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
> That was a bust, same results, improper video. Not sure I altered
> the NVDAResman.kext properly as I could not locate where to put the
> device/vendor info. I did find a line with the vendor info, but the
> device was listed as null 0x0000, so I just changed that to 0x0422,
> which is the device number. Guess I will go back and read some more.
Once you properly change the VID & PID to match your card, you also
need to be sure you're not loading an old version of the kext from a
kext cache file. I don't have any Mt. Lion hacks, but I think Apple
changed around the kext caches? No more Extensions.mkext, isn't it in
System/Library/Caches/com.apple.kextcaches? I usually just Safe Boot
once to rebuild these caches.
>> That was a bust, same results, improper video. Not sure I altered the NVDAResman.kext properly as I could not locate where to put the device/vendor info. I did find a line with the vendor info, but the device was listed as null 0x0000, so I just changed that to 0x0422, which is the device number. Guess I will go back and read some more.
> Once you properly change the VID & PID to match your card, you also need to be sure you're not loading an old version of the kext from a kext cache file. I don't have any Mt. Lion hacks, but I think Apple changed around the kext caches? No more Extensions.mkext, isn't it in System/Library/Caches/com.apple.kextcaches? I usually just Safe Boot once to rebuild these caches.
I've been using the latest version of Kext Utility which was upgraded for ML. I believe the Extension.mkext is saved to /S/L/E, but not totally sure. BTW, I've done safe boots also after doing this, but still no joy. I'm going to poke around the NV kexts which work from the DS3L and see if those will provide any clues.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
>> That was a bust, same results, improper video. Not sure I altered the NVDAResman.kext properly as I could not locate where to put the device/vendor info. I did find a line with the vendor info, but the device was listed as null 0x0000, so I just changed that to 0x0422, which is the device number. Guess I will go back and read some more.
> Once you properly change the VID & PID to match your card, you also need to be sure you're not loading an old version of the kext from a kext cache file. I don't have any Mt. Lion hacks, but I think Apple changed around the kext caches? No more Extensions.mkext, isn't it in System/Library/Caches/com.apple.kextcaches? I usually just Safe Boot once to rebuild these caches.
As the Insanely post I spoke of yesterday was written in August of 2010, I'm wondering if perhaps some things changed with ML in the way the NV kexts are used. The thread speaks of NVDANV40Hal dealing with series 6 & 7 cards, with NVDANV50Hal dealing with series 8 and up cards. There is no mention of NVSMU, NVDAGF100Hal or NVDAGK100Hal. I'm assuming the two 100Hal kexts deal with later cards, but what does NVSMU do?
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
Something different. I moved over the /Extra folder of the working partition to the one I'm experimenting with. Also prior to this, I installed the rest of the NV kexts via Kext Utility from the working partition. The last line of my verbose boot looks like this:
It doesn't seem to want to go any further than this. I'm not sure if this is progress or not, but there is something which is preventing my experimental partition from booting to the desktop successfully and I aim to find out what it is.
The experiment continues.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
doug--the 210 card uses the 100F kext. that's where i placed the vendor and device ID for my msi 210; before doing so the boot would not complete (hung at the shift from the boot sequence to the desktop). i didn't put the 210 id's into the resman kext.
i have no idea why there are 2 100 kexts, F and K.
On Thursday, November 1, 2012 3:18:13 PM UTC-4, hackintosh1x wrote:
> On Nov 1, 2012, at 2:48 PM, Kris Tilford wrote:
> On Nov 1, 2012, at 1:20 PM, mosslack wrote:
> That was a bust, same results, improper video. Not sure I altered the > NVDAResman.kext properly as I could not locate where to put the > device/vendor info. I did find a line with the vendor info, but the device > was listed as null 0x0000, so I just changed that to 0x0422, which is the > device number. Guess I will go back and read some more.
> Once you properly change the VID & PID to match your card, you also need > to be sure you're not loading an old version of the kext from a kext cache > file. I don't have any Mt. Lion hacks, but I think Apple changed around the > kext caches? No more Extensions.mkext, isn't it in > System/Library/Caches/com.apple.kextcaches? I usually just Safe Boot once > to rebuild these caches.
> As the Insanely post I spoke of yesterday was written in August of 2010, > I'm wondering if perhaps some things changed with ML in the way the NV > kexts are used. The thread speaks of NVDANV40Hal dealing with series 6 & 7 > cards, with NVDANV50Hal dealing with series 8 and up cards. There is no > mention of NVSMU, NVDAGF100Hal or NVDAGK100Hal. I'm assuming the two 100Hal > kexts deal with later cards, but what does NVSMU do? > * > From the main system of mosslack...* > ______________________________ > Alt-OS <http://mosslack.weebly.com/alt-os.html> <+> GG<http://www.girlsgenerationusa.com/Default.aspx#!featured> > <+> TBIE <http://mosslack.blogspot.com/> <+> Hack List<http://mosslack.weebly.com/>
> I've been using the latest version of Kext Utility which was
> upgraded for ML.
I've noted this before, but when I've used Kext Utility it "opens up"
the permissions of my entire System to "execute" which I believe is a
huge security hole? I've always run Disk Utility after using Kext
Utility to correct the permissions back to their default state. I
think Kext Wizard might not change the default permissions, and offers
the same ease of use? And Kext Helper works easy, except it often
won't quit correctly and must be Force Quit.
> doug--the 210 card uses the 100F kext. that's where i placed the vendor and device ID for my msi 210; before doing so the boot would not complete (hung at the shift from the boot sequence to the desktop). i didn't put the 210 id's into the resman kext.
> i have no idea why there are 2 100 kexts, F and K.
> ken
As I mentioned, I switched back to the 8400 GS once I found it worked fine with ML on this system. No sense wasting a better card on something that doesn't get used that much. I kind of figured the later cards used the 100 kexts as they are not present in /S/L/E for Snow Leopard, but are in Lion and ML.
Looking at /S/L/E on the cloned DS3L drive, I find a total of 7 NV kexts. In addition to the normal ones we have mentioned, 2 extra ones are present, both no doubt from applying the NVoverride on that system. They are _OverrideNVDANV50Hal.kext and _OverrideNVDAResman.kext. I didn't copy these as I didn't notice them when I was looking at the kext which were in alphabetical order. I may have to copy those over just to see if that makes the difference.
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
