Re: [HQ-A] GA-G41M-ES2L vs Lion

[Jeff]

I'm sorry to revive a dead thread but I'm just now getting around to
upgrading to Lion. Thanks again for the DSDT Peter. I only made the
change to add dual displays and all is well in Snow Leopard.

Currently, in my /Extras/Extensions I have:

AHCIPortInjector.kext
AppleVIAATA.kext
fakesmc.kext
IOAHCIBlockStorageInjector.kext
JMicronATA.kext
Legacy888bHDA.kext
NullCPUPowerManagement.kext
OpenHaltRestart.kext
PlatformUUID.kext
SleepEnabler.kext

All of these I have for Snow Leopard 10.6.8. Does anyone know which I
should or must remove for Lion?

Also, I'm having a hard time downloading Lion after I purchased it. I
purchased it on my wife's MacBook 2.5 Ghz Core 2 Duo. Every time I
try to download it from the App store it never will start. Also,
trying to download it through the App store on the g41M-ES2L says the
Mac is not compatible. Any suggestions on how to proceed?

Thank you.

-- Jeff


On Nov 15, 2011, at 9:41 PM, pete...@cruzio.com wrote:

Thanks Peter. I'm including two dsdts. One (labeled ubuntu) is the
virgin dsdt. The other is the dsdt that I've been using (quite well)
with
my current setup.

Now, I'm off to update to 10.6.8 before moving to Lion. Hopefully I
won't
have any issues.

The enclosed DSDT includes ALL the AMAC stuff (carefully retrofitted,
as
Gigabyte never updated its pre-P35 DSDTs properly for MacOS X
compatibility).

You WILL have to change the HDEF device to refer to whatever codec you
actually have ... Gigabyte changed its codecs so often, and there are
FOUR
revisions of this motherboard.

[pete...@cruzio.com]

> Currently, in my /Extras/Extensions I have:
>
> AHCIPortInjector.kext
> AppleVIAATA.kext
> fakesmc.kext
> IOAHCIBlockStorageInjector.kext
> JMicronATA.kext
> Legacy888bHDA.kext
> NullCPUPowerManagement.kext
> OpenHaltRestart.kext
> PlatformUUID.kext
> SleepEnabler.kext

The G41 (G)MCH + ICH7 ICH is pretty compatible as-is.

There is an updated sound kext which covers the ALC888b.

Typically, I do not use the last three named kexts.

MultiBeast For Lion should have everything you need for post-installation.

[Jeff Hester]

Hi all,

I went through the process of using Unibeast to prepare my USB drive,
following the instructions on TonyMac's siste. I can't get it to boot
from the USB drive though. When I hit F-12 to be able to select
USB-HDD it appears to search the USB drive and then it boots from my
existing drive (that contains Chimera 1.5.4). Any suggestions?

What exactly is supposed to be on the USB drive when Unibeast finishes?

Thank you.

-- Jeff

> --
> To unsubscribe: hq-a+uns...@googlegroups.com
> List options: http://groups.google.com/group/hq-a/subscribe
>
> HQ-A homepage: http://hq-a.blogspot.com/
> Group Files Page: http://bit.ly/ia8E2l

[pete...@cruzio.com]

> What exactly is supposed to be on the USB drive when Unibeast finishes?

Most will be hidden, although boot won't be hidden.

Hidden files/folders include at least these:

Extra (with a DSDT, smbios, com.apple.Boot.plist, exensions folder)

Library (with receipts)

mach_kernel

[Jeff Hester]

Ok, I finally got it to boot from the USB drive and I have
successfully install Lion (upgraded by Snow Leopard). I followed the
instructions on how to do the post install with Multibeast and I did
that.

Rebooting and starting up from the Lion drive (no USB thumb drive
attached) just gives the large grey apple and the hard drive keeps
getting accessed. I've let it go for almost 30 minutes. It's not
totally frozen because the drive is still being accessed.

Any suggestions? Could it be a dsdt problem? I'm using the one that
I got from Peter a few days ago.

I feel like I'm so close..but yet so far. :)

Thanks.

-- Jeff

[pete...@cruzio.com]

> Any suggestions? Could it be a dsdt problem? I'm using the one that
> I got from Peter a few days ago.

You need to have more information at hand.

Use -v and arch=i386, to begin with.

When the Apple menu hangs like that, it is often because it cannot find
the root device.

[Jeff Hester]

Good idea. Booting hangs at

"[PCI configuration begin]"

Does that sound like a dsdt issue?

Thanks.

[On the move with iOS.]

[pete...@cruzio.com]

> Good idea. Booting hangs at
>
> "[PCI configuration begin]"
>
> Does that sound like a dsdt issue?

This is more of a boot flags issue than it is a DSDT issue.

What is ACTUALLY occurring is: the first ...

"[PCI configuration begin]"

... indicates that the boot loader is being forced to change the boot
console address to something else.

What you WANT to see is ...

"[PCI configuration begin]"

"Console changed to 0x----"

and finally

"[PCI configuration ends]"

... and then the boot process continues with the new console address,
which will enumerate whatever problems have been encountered.

Anyway, that is my take on it.

[Kris Tilford]

On Jun 11, 2012, at 8:43 PM, Jeff Hester wrote:

> Good idea. Booting hangs at
>
> "[PCI configuration begin]"

Try the boot flag: npci=0x2000

[Jeff Hester]

Yes I had tried that. No luck.

Thanks.

[On the move with iOS.]

[Jeff Hester]

Well, I finally found a DSDT that worked. It let me boot up in Lion. (See "this works dsdt")

The one that I had been using hangs at the PCI Configuration Begin. (See "this does not work") This had worked great with Snow.

Now I have to figure out what I need to fix so I can get back to having my dual monitors back to working.

Thanks.

-- Jeff

P.S. This is the dsl version and not the aml version (required in /Extras)

[pete...@cruzio.com]

> Well, I finally found a DSDT that worked. It let me boot up in Lion.
> (See "this works dsdt")
>
> The one that I had been using hangs at the PCI Configuration Begin. (See
> "this does not work") This had worked great with Snow.

The one entitled "this does not work" is the one I built some time ago for
Snow Leopard. If a DSDT works on Snow Leopard, it is supposed to work on
Lion.

An advantage of that DSDT is it includes the AMAC stuff for maximum MacOS
X compatibility.

The one entitled "this works" is the one someone else built.

The AMAC stuff for maximum MacOS X compatibility may still be retrofitted
to that one.

I'll leave that as an exercise for someone else.

[Jeff Hester]

I've been retrofitting the one that works with the one that Peter did.
It's about 50% complete and I've not identified yet what area causes
the PCI hang.

However, I've gotten a little closer (I think) to getting the 8400gs
to work. I modified NVDANV50Hal.kext with the string that I used to
get the card working in Snow Leopard. Now, after Lion finishes
loading during the transition to the login screen the monitor actually
sleeps (and can't be woken). Does anyone know what I could try to get
it to work?

Thanks.

-- Jeff

[pete...@cruzio.com]

> I've been retrofitting the one that works with the one that Peter did.
> It's about 50% complete and I've not identified yet what area causes
> the PCI hang.

I have not.

SOME of my systems give the [ ... ], then a message that the console was
relocated, then give the [ ... ] again.

I like that!

But, most give the first [ ... ] and then nothing until the dsmos message,
or something like that.

> However, I've gotten a little closer (I think) to getting the 8400gs
> to work. I modified NVDANV50Hal.kext with the string that I used to
> get the card working in Snow Leopard. Now, after Lion finishes
> loading during the transition to the login screen the monitor actually
> sleeps (and can't be woken). Does anyone know what I could try to get
> it to work?

I have had nothing but trouble with 8400GS cards which are very late build
(these are DDR3) or are non-eVGA.

It has driven me almost to tears at some points.

Which may be why I am still running 7200GS cards with arch=i386, in some
cases, even on Lion.

[Jeff Hester]

Sounds like it's time to move from the 7200GS / 8400GS. It's taking
too much time.

What are very compatible graphics cards that other use with Lion?

-- Jeff

[Jeff Hester]

Would someone please see if I dorked up something with my dsdt? The "Ubuntu" version is from grabbing it using Ubuntu live. The "this is in the works" is what I'm trying to get to work. I added things that aren't reflected in the Ubuntu version and I'm not sure if it's required. I really appreciate someone else putting eyes on it.

[pete...@cruzio.com]

The Ubuntu version is always just a place to start with.

The AMAC modifications are applicable only to Award DSDTs, never to AMI
DSDTs.

The one which does not work is the one I modified.

It has the retrofitted AMAC stuff and all the other stuff I have come to
expect in a DSDT for SL and L.

Basically, the changes required TO ANY DSDT are:

1) in device PWRB, change the HID to CID,

2) add the AAPL stuff to the one (ICH7 or lower) or two (ICH8 or higher)
EHC devices; the changes which tonymacx86 recommends to UHC devices are
not really necessary,

3) change whatever is the "low pin count" device to LPCB,

4) change whatever is the SMBus device to include SBUS device itself.

It is NOT necessary to add a GFX0 device unless you are expecting to use
the on-board video, and in this case it is only possible for the two which
Apple specifically supports: GMA950 and GMAX3100.

If using several graphics cards, for, say, four or six independent
screens, then considerable experimentation WILL be required.

[Kris Tilford]

On Jun 13, 2012, at 11:05 PM, Jeff Hester wrote:

> Would someone please see if I dorked up something with my dsdt?

Why not use an already patched, working in Lion, dsdt from the internet?

Here's what you do, you type "GA-G41M-ES2L dsdt" into Google, and then
download the patched dsdt file from any of the many sites that have
the patched dsdt file for the GA-G41M-ES2L.

Here's one:
<http://www.osx86.net/downloads.php?do=file&id=1063>

[Jeff Hester]

I have downloaded several dsdt from the 'net.

The bottom line is that I put my dsdt, rather the one the Peter did
for me, against anyone's. (He comes close to walking on water.)
Peter's dsdt has simply worked great in Snow Leopard all the way to
the latest. Initially, when I tried to get it to work in Lion it
would hang at the "PCI configuration begin". At that point I tried
several downloaded from the internet and they would work (at least not
hang at PCI ...) But I lost dual displays. One display would work in
an either/or configuration, never when both displays were connected.

I think I have been going at this the wrong way. I was pulling from
Peter's dsdt and making changes to a dsdt that worked fine (minus dual
displays). I think the correct approach would be to make changes to
Peter's dsdt and try to resolve why it hangs at startup in Lion. I
would hope that it's a simple issue that hasn't jumped out yet. This
will hopefully give me a great Lion startup too.

Am I wrong in thinking that the lack of dual displays in Lion could be
related to the dsdt?

Some messages I noticed when booting in Lion with verbose on is:

com.apple.GeForce failed to load
com.apple.NVDAResman not found

When I boot into Snow Leopard with verbose on those messages aren't
displayed. Can I use com.apple.NVDAResman from my Snow Leopard and
install it in Lion? I don't see NVDAResman in my retail Lion
(/System/Library/Extension) install of 10.7.4. Does anyone else see
that file in their Lion install?

Thanks.

-- Jeff

P.S. At first I didn't care for Lion but I'm starting to really like
it, even with all of the rebooting. :)

[pete...@cruzio.com]

> The bottom line is that I put my dsdt, rather the one the Peter did
> for me, against anyone's. (He comes close to walking on water.)
> Peter's dsdt has simply worked great in Snow Leopard all the way to
> the latest. Initially, when I tried to get it to work in Lion it
> would hang at the "PCI configuration begin". At that point I tried
> several downloaded from the internet and they would work (at least not
> hang at PCI ...) But I lost dual displays. One display would work in
> an either/or configuration, never when both displays were connected.

Most of the problems are being caused by the boot loader.

The DSDT just defines which devices are present.

In the usual cases, these are the 0x001F000x series with special emphasis
on 0x001F0000 (LPCB) and 0x001F0003 (SBUS), the 0x001D000x series (first
USB controller), the 0x001A000x series (second USB controller, if
present), and 0x001B0000 (HDEF).

Beyond those, the boot loader should take care of the rest, namely the
graphics devices and the E-net device(s).

One reason why it is important to have LPCB, SBUS and HDEF correctly
defined is where the address is different from the above, in which case
the DSDT translates the addresses as required.

It is important to distinguish between a [PCI configuration begin] which
is a true hang and a [PCI configuration begin] which is the result of the
console address being redefined.

In the first option of the second case, if all messages were to be
displayed, you would see [PCI configuration begin], then [Console changed
to 0xXXXXXXXX], then [PCI configuration end] and, finally, ALL of the
remaining messages.

In the second option of the second case, you would see [PCI configuration
begin], then nothing for a while, and, finally, SOME of the remaining
messages, those which are not dependent upon the console address.

In the first case, you get [PCI configuration begin], and then the boot
process simply stops there. This is a true hang.

The boot flags option of MultiBeast is your friend here, as some
situations require additional boot flags, such as the PCI fix and others,
and some situations don't.

I suppose that Wizard application could be helpful here, as you can change
almost every boot flag with a single GUI. All except arch=i386, it seems.

[Jeff Hester]

Woohoo! It works in dual screen mode.

I added:

<key>PCIRootUID</key>
<string>1</string>

to the org.chameleon.Boot.plist

and it's working great. I haven't tested sleep but I can deal with everything else.

Woohoo again! :)

Thanks for everyone's help.

-- Jeff