DSDT fixes for Gigabyte boards

Master Chief · November 3, 2009

Hello Friends and Wizards,
I recall with 10.5.7 I never used to see the "verifying DMI pool data" screen nor the PCI device listing. These started cropping up after SL. So my question is, is this somehow related to the CMOS reset bug, doing something there which was not done in Leopard, causing these screens to appear on every boot? Is this not supposed to happen only when some new hardware changes are made not on every boot? At least that's how it works with a Windoze only install.

Thoughts & ideas?

Interesting. Here are a few things to look into:

Have you flashed your BIOS recently?

Did you change the Apple model identifier? If yes change it back as a test.

Did you run into the CMOS reset bug with Snow Leopard? If yes, have you checked all settings in the BIOS afterwards?

And do you get the screens with all (the original) or a specific DSDT?

William Parker · November 4, 2009

Interesting. Here are a few things to look into:
Have you flashed your BIOS recently?

Did you change the Apple model identifier? If yes change it back as a test.

Did you run into the CMOS reset bug with Snow Leopard? If yes, have you checked all settings in the BIOS afterwards?

And do you get the screens with all (the original) or a specific DSDT?

Hi,

I have not changed the BIOS recently, It is the same one I used in 10.5.7 without "verifying dmi pool data" showing up.

As for the model identifier I did change it in the SMBIOS.plist in Extra folder, which I changed back to what it was but this did not change anything.

Yes I did encounter the CMOS reset bug which I took care of by changing values in device RTC in DSDT. After that I needed to re-enter everything in CMOS setup as per my preferences.

This "verifying dmi pool data" thing is same with every iteration of DSDT I have used. Now I am beginning to think it might even be Chameleon bootloader with PC-EFI v10.5. Because I used the much older one on Leopard previously.

xjasx · November 4, 2009

Having some trouble with my PR scope, i've been using iSoprano's PR scope from original post, but decided I'd switch it up to how Master Chief does it...

	Scope (_PR)
{
	Processor (CPU0, 0x00, 0x00000410, 0x06) {}
	Processor (CPU1, 0x01, 0x00000410, 0x06) {}
	Processor (CPU2, 0x02, 0x00000410, 0x06) {}
	Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}

Scope (_PR.CPU0)
{
	Method (_PSS, 0, NotSerialized)
	{
		Return (Package(0x06)
		{
			Package (0x06) { 0, 0, 10, 10, 0x4820, 0 },
			Package (0x06) { 0, 0, 10, 10, 0x081E, 1 },
			Package (0x06) { 0, 0, 10, 10, 0x471C, 2 },
			Package (0x06) { 0, 0, 10, 10, 0x071A, 3 },
			Package (0x06) { 0, 0, 10, 10, 0x4618, 4 },
			Package (0x06) { 0, 0, 10, 10, 0x0616, 5 }
		})
	}
	Method (_CST, 0, NotSerialized)
	{
		Return (Package (0x02)
		{
			One, 
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x1, 0x2, 0x0, 0x1,)},0x01,0x9D,0x3E8}
		})
	}
}
Scope (_PR.CPU1)
{
	Method (_CST, 0, NotSerialized)
	{
		Return (Package (0x04)
		{
			0x03, 
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x000, ,)},0x01,0x01,0x3E8}, 
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x414, ,)},0x02,0x01,0x1F4}, 
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x415, ,)},0x03,0x55,0x0FA} 
		})
	}
}

Scope (_PR.CPU2)
{
	Method (_CST, 0, NotSerialized)
	{
			Return (^^CPU1._CST ())
	}
}
Scope (_PR.CPU3)
{
	Method (_CST, 0, NotSerialized)
	{
			Return (^^CPU1._CST ())
	}
}

Originally i did not include the _PSS, and even with it, the speedstep isnt there, BUT cpu2 and 3 will jump between x6 and x9 multipliers (C1E state)

doesn't make sense to me because aren't CPU2 and 3 just referring to code in CPU1?

Master Chief · November 4, 2009

Having some trouble with my PR scope, i've been using iSoprano's PR scope from original post, but decided I'd switch it up to how Master Chief does it...

<snip />

Originally i did not include the _PSS, and even with it, the speedstep isnt there, BUT cpu2 and 3 will jump between x6 and x9 multipliers (C1E state)

doesn't make sense to me because aren't CPU2 and 3 just referring to code in CPU1?

You forgot to add (removed?) _PSS objects! Here's an example:

		Processor (CPU3, 0x03, 0x00000410, 0x06)
	{
		Alias (\_PR.CPU1._PSS, _PSS)
		Alias (\_PR.CPU2._CST, _CST)
	}

as the above code (example) is what you need for P state support (first Alias) and C state support (second Alias). And thus only two instead of the usual eight lines

Tip: Get rid of unnecessary Scope statements (to improve the readability).

Hi,
I have not changed the BIOS recently, It is the same one I used in 10.5.7 without "verifying dmi pool data" showing up.

As for the model identifier I did change it in the SMBIOS.plist in Extra folder, which I changed back to what it was but this did not change anything.

Yes I did encounter the CMOS reset bug which I took care of by changing values in device RTC in DSDT. After that I needed to re-enter everything in CMOS setup as per my preferences.

This "verifying dmi pool data" thing is same with every iteration of DSDT I have used. Now I am beginning to think it might even be Chameleon bootloader with PC-EFI v10.5. Because I used the much older one on Leopard previously.

If this would have been caused by the boot loader, then others people here would have complained long before you. Don't you agree?

I would say re-check your BIOS settings one more time (using the default settings as a starter).

William Parker · November 4, 2009

@ Master Chief

I suspect that most people using ICH10R in AHCI mode and Chameleon with SL on GIGABYTE boards will see this "verifying dmi....". I have at least 2 more machines here (my friends') with same results. With Leopard the scene is different.

Besides if everything works okay, I don't think any one's gonna complain about few scrolling lines of text at boot. It bugs me because I had an Abit ip35Pro which used to boot as elegantly as Apple. White screen at power on, followed by Apple logo, followed by whirly under it & finally the desktop. Not a single line in between. Could never get a DSDT out of that board though, & sleep didn't work.

You love challenges, & this is more on the lines of "making it more mac-like". Moreover I see your tempo on this thread a bit dampened.

What say?

My Best Wishes To You.

Cathul · November 4, 2009

I always have the "verifying dmi.." lines when i start up my computer. Doesn't matter if i use Windows, Leopard, Linux oder Snow Leopard.

keeza · November 4, 2009

I always have the "verifying dmi.." lines when i start up my computer. Doesn't matter if i use Windows, Leopard, Linux oder Snow Leopard.

same here

xjasx · November 4, 2009

same... that has nothing to do with the OS itself at all

William Parker · November 4, 2009

Hi, and Thank you Friends.

To verify this "verifying dmi…." phenomenon, I fished out a XFX 7600GT & a 7300GT to replace my 9800GT here. Formatted a fresh HDD, installled 10.5.4 with dsmos.kext & PC-EFI V9. Results. with 7600GT the message in concern flashes for much less than a second & definitely much lower duration than on 9800GT. And surprise surprise.. with 7300GT the message is gone. With 9800GT it is same as in SL.

So guys definitely not an OS issue but a Display card issue.

With 9800GT on SL now I also see the EPA logo flash for a brief second and a lazy leisurely "verifying dmi….". The screen is getting dirtier with every display card upgrade. Is this a case for display card BIOS Mod?

Man even the AHCI screen bugs me. Who on God's earth would want to see it detecting the same drives every day? What could be more crass? Damned thing does not even have an option to hide it like "Quiet Boot" or something. Feels perplexing running such a refined OS on such a shabbily designed BIOS.

Magicians?

Master Chief · November 4, 2009

@ Master Chief
... Moreover I see your tempo on this thread a bit dampened.

What say?

My Best Wishes To You.

I ran into the Mexican flu and need a lot more sleep, and since people here seem to do fine without me :rolleyes:

But I'm not a pussy – not even taking Tamiflu – so let's get cracking!!! Enter a much shorter, cleaner and much better readable copy of my SATA Device:

            Device (SATA)
           {
               Name (_ADR, 0x001F0002)

               Device (PRT0)
               {
                   Name (_ADR, Zero)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "1"))
                   }
               }

               Device (PRT1)
               {
                   Name (_ADR, One)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "2"))
                   }
               }

               Device (PRT2) // New Device.
               {
                   Name (_ADR, 0x02)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "3"))
                   }
               }

               Device (PRT3) // New Device.
               {
                   Name (_ADR, 0x03)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "4"))
                   }
               }

               Device (PRT4) // New Device.
               {
                   Name (_ADR, 0x04)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "5"))
                   }
               }

               Device (PRT5) // New Device.
               {
                   Name (_ADR, 0x05)

                   Method (_DSM, 4, NotSerialized)
                   {
                       Return (MCBN (Arg2, "6"))
                   }
               }
           }

In fact, when you don't want/need the "Bay n" bits then you could instead use something like this:

			Device (SATA)
		{
			Name (_ADR, 0x001F0002)
		}

And here's the new helper Method for people who do want the "Bay n" info to show up in System Profiler:

    // New Method V1.0 – By Master Chief
   Method (MCBN, 2, NotSerialized)
   {
       Name (BUF0, Buffer (0x06) { "Bay n" } )
       Store (Arg1, Index (BUF0, 0x04))

       Store (Package (0x02)
       {
           "io-device-location",
            BUF0
       }, Local0)

       MCDP (Arg0, RefOf (Local0))
       Return (Local0)
   }

I have this new Method right below my Methods MCDP and MCID. And make sure you have/add the following Method in your DSDT or it won't even compile:

    // New Method V1.1 By Master Chief.
   Method (MCDP, 2, NotSerialized)
   {
       If (LEqual (Arg0, Zero)) // Function index: 0
       {
           Store (Buffer (One)
           {
               0x03
           }, Arg1)
       }
   }

Now you say: "But I don't have a Device called SATA". And looking at a few GB DSDT's I received over the past couple of weeks.... That seems pretty accurate. Now do a search for Device (IDE1) or Name (_ADR, 0x001F0002) because that is the one you are looking for.

Another recommendation is to remove Device (IDE2) at address 0x001F0005 simply because this one is not used for the six & six SATA configuration. Only in the four and two configuration, which we are not using in our hacks and thus it is safe to remove it.

Note: Some people don't have six but four SATA ports on their motherboard, and in that case simple don't add the last two devices. Thanks to Cathul (post #361) for the reminder!

Now. Both _STM and _GTM are IDE specific Methods (see ACPI specifications) and thus it is safe to remove them. That is if you don't use any old fashioned IDE hardware of course. As a note: On a real Mac Pro (3,1) you'll find SATA and PATA devices only in ioreg/IORegistry Explorer. And PATA is where the Apple SuperDrive (double-layer DVD/CD burner) is connected. And most of the stuff you have removed, or are going to remove, can only be found in Device (PATA ).

Same for the DRVn Devices. And after the removal of all this... well... there isn't really much useful code left in your Device (PRIM) and Device (SECD). The result is a smaller and much cleaner DSDT.

Note: You might run into compiler errors, so please do this in steps – like I keep telling people to do.

Good Luck and Happy Hacking!

Cathul · November 4, 2009

What if your board has only 4 ICH9-SATA ports?

Afaik the Gigabyte GA-P35-DS3 (without L, S, P whatever) only had 4 SATA-ports, not 6 like the ICH9-R.

Can i just leave out the PRT4 and PRT5 device without any issues?

FKA · November 4, 2009

What if your board has only 4 ICH9-SATA ports?
Afaik the Gigabyte GA-P35-DS3 (without L, S, P whatever) only had 4 SATA-ports, not 6 like the ICH9-R.

Can i just leave out the PRT4 and PRT5 device without any issues?

Hi Cathul

I'd try replacing IDE2 with this:

            Device (SATA)
           {
               Name (_ADR, [color="#ff0000"][b]0x001F0005[/b][/color])
               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x81, 0x26, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

Please note the device ID I've used sets SATA devices as EBS2 rather than ICH9 but as this is a MacPro native southbridge you dont need IOAHCIBlockStorageInjector.kext or IOAHCIFamily kext.

D.

Master Chief · November 4, 2009

What if your board has only 4 ICH9-SATA ports?
Afaik the Gigabyte GA-P35-DS3 (without L, S, P whatever) only had 4 SATA-ports, not 6 like the ICH9-R.

Can i just leave out the PRT4 and PRT5 device without any issues?

The addition of the PRTn devices is a pure cosmetic only one, to add info for System Profiler. Well, that and ioreg/IORegistryExplorer showing more Mac like device names.

Innerz · November 5, 2009

I'm trying to apply this PATA fix found by THe KiNG

OperationRegion (IDET, PCI_Config, 0x40, 0x04) // IDE Timing Register
Field (IDET, WordAcc, NoLock, Preserve)
{
Offset (0x00),
M1, 8,
Offset (0x01),
M2, 8,
Offset (0x02),
M3, 8,
Offset (0x03),
M4, 8
}

Method (_DSM, 4, NotSerialized)
{
Store (0x07, M1)
Store (0xE3, M2)
Store (Zero, M3)
Store (0xC0, M4)
Return (Zero)
}

But i'm a little bit confuse because i don't have the "0x001F0001" offset. Perhaps you could help me. Thank you

Here my DSDT.dsl.zip

ganxiao · November 5, 2009

Hi all, i found something very interesting!!!

On some gigabyte mainboard, SSDT table depends on feartures you enabled in bios.

I have cst errors in post screen when boot 10.6.1 on my ex58-ud4 platform previously.

Turbo boost feature didn't work on my i7 920 in SL either.

I realized that's due to lack of c-state info in ssdt,

and noticed someone claimed he got rid of those annoiying messages by enable c states in bios.

After hack the AppleLPC.kext and enable C3/C6/C7 state support in bios,

those messages are gone, and it seems c-states gonna work.

I got CSTInfo in ioreg, and have to remove irq under PIC/RTC/TMR to solve issue of sound distort and interrupt conficts.

Geekbench 64bit score increased from 9000 to 9500, and msr tool show turbo boost active.

After compared ssdt table before and after c state enabled in bios,

i noticed ssdt table was different,

Name (CSEN, 0x00000000) change to Name (CSEN, 0x00000001),

Method (_CST, 0, NotSerialized) appears after c stats enabled in bios.

Still need to hack SMC_Platform_Plugin to enable speedstep course i use macpro4,1 in smbios.plist.

CST_Disable_in_BIOS.zip

CST_Enable_in_BIOS.zip

In conclude,

gigabyte user may not need to mod ssdt and add it to dsdt to get c-state and p-state work.

Vanilla C-state and speedstep should work w/o dsdt smc_plugin and lpc hacks on some giga MB.

gigabyte has implemented ssdt table well enough for osx, what we need to do is:

1. enable C1E, EIST, C3/C6/C7 support in bios to produce proper ssdt table, enable turbo boost if using i7 cpu

2. use macpro3,1 in smbios.plist, then you may not need smc_plugin hack

3. hack LPC if needed (my EP43-UD3L do not need hack, device id 3a18 is the same as apple's, but EX58-UD4 need)

@masterchief

your dsdt mod is really excellent, good job!!

I'm merging those mods to my i7 platform.

FKA · November 5, 2009

In conclude,
gigabyte user may not need to mod ssdt and add it to dsdt to get c-state and p-state work.

Vanilla C-state and speedstep should work w/o dsdt smc_plugin and lpc hacks on some giga MB.

gigabyte has implemented ssdt table well enough for osx, what we need to do is:

1. enable C1E, EIST, C3/C6/C7 support in bios to produce proper ssdt table, enable turbo boost if using i7 cpu

2. use macpro3,1 in smbios.plist, then you may not need smc_plugin hack

3. hack LPC if needed (my EP43-UD3L do not need hack, device id 3a18 is the same as apple's, but EX58-UD4 need)

@masterchief

your dsdt mod is really excellent, good job!!

I'm merging those mods to my i7 platform.

Hi ganxiao

Firstly this thread is about DSDT mod's ... i.e. not hacking the AppleLPC.kext but adding LPC device id to DSDT.

Secondly - good for you if you don't need to make any additions to DSDT to get C-and P-states working

Thirdly - how have you proved that your P and c states are actually working ?

Last but not least - do you think p-states are related to enabling the C.I.A.2 function in BIOS? I have to admitt I hadn't thought about this before!

D.

ganxiao · November 5, 2009

Hi ganxiao

Firstly this thread is about DSDT mod's ... i.e. not hacking the AppleLPC.kext but adding LPC device id to DSDT.

Secondly - good for you if you don't need to make any additions to DSDT to get C-and P-states working

Thirdly - how have you proved that your P and c states are actually working ?

Last but not least - do you think p-states are related to enabling the C.I.A.2 function in BIOS? I have to admitt I hadn't thought about this before!

D.

Hi FormerlyKnownAs,

Thanks for your quick reply,

Fisrt

My bad!

when i say hacking the AppleLPC.kext, i mean adding LPC device id to DSDT actually,

but adding LPC device id to AppleLPC.kext's plist also works.

Second

Yes, I didn't need to make any additions to DSDT to get P-states working,

I'm not sure if C-states did work, maybe you can tell how to verify that,

but i indeed get rid of those cst errors.

here is dsdt i am using now

dsdt.aml.zip

Third

Here is a snapshot of ioregistryexplorer

Here is i7 920 @ 1.6GHz, lowest frequency in SL and windows

Here is when turbo boost activated, i7 920 @ 2.8GHz, 1x mutiplier more than stock 2.66GHz

here is i7 920 @ 1.83GHz, one of several middle states, which mean p-states really works

Temperature is around 36 - 39 Celsius in idle, almost the same in windows

Here is my ioreg dump for more details,

ioreg_macpro4_1_smc_pp.zip

Fourth

When i use MacPro4,1 in smbios.plist, i don't have to use legacy AGPM kext to enable GPU throttle,

It's enabled by default in MacPro4,1

What i did in my own made LegacyACPI_SMC_PlatformPlugin.kext is just add MacPro4,1 to PLimitDict=0 and StepDataDict=SP1 to enable speedstep,

I dont know if the new macpro4,1 is using variable speeds on power demand or if it can be enable/disable in someway, i dont see the StepData in the macpro4.1 ioreg.

Last but not least

I don't think C.I.A.2 function has relationship with p-states,

C1E and EIST enable p-states,

C3/C6/C7 SUPPORT enable c-states,

I noticed Gigabyte P35/P45 had a different SSDT table, it might not work in my way,

and dgsga with ASUS X58 MB has same experience like me .

Maybe it's only available in i7 platform,

But i hope this could help you!

Cathul · November 5, 2009

This is how my SATA device looks in my dsdt.dsl at the moment:

			Device (SATA)
		{
			Name (_ADR, 0x001F0002)
			Method (_DSM, 4, NotSerialized)
			{
				Return (MCID (Arg2, 0x2681))
			}
		}

Guess i'll screw the bay information. It works great as it is at the moment. I don't have to use any injector for device ids and stuff like that.

And tbh, i'll get my 24" iMac early 2009 generation with a radeon 4850 tomorrow evening. Guess i wont mess with a hack anymore when i have this iMac. :whistle:

FKA · November 5, 2009

Last but not least
I don't think C.I.A.2 function has relationship with p-states,

C1E and EIST enable p-states,

C3/C6/C7 SUPPORT enable c-states,

I noticed Gigabyte P35/P45 had a different SSDT table, it might not work in my way,

and dgsga with ASUS X58 MB has same experience like me .

Maybe it's only available in i7 platform,

But i hope this could help you!

I think you correct - there is a lot in your SSDT that isn't in the P35/45 ...

I'm still interested in the Turbo boost feature your talking about - excuse my ignorance but are you talking about CIA2 in BIOS or something else?

Cheers

D.

ganxiao · November 5, 2009

I think you correct - there is a lot in your SSDT that isn't in the P35/45 ...

I'm still interested in the Turbo boost feature your talking about - excuse my ignorance but are you talking about CIA2 in BIOS or something else?

Cheers

D.

Turbo boost is a new feature introduced in Nehalem, check 1 2 for details.

There is a "Intel® Turbo Boost Tech" option in my bios to enable this feature,

CIA2 is auto-overclock function, it only increase fsb speed.

But Turbo boost change mutipliers.

BRs,

Ganxiao

Master Chief · November 5, 2009

I'm trying to apply this PATA fix found by THe KiNG
OperationRegion (IDET, PCI_Config, 0x40, 0x04) // IDE Timing Register
Field (IDET, WordAcc, NoLock, Preserve)
{
Offset (0x00),
M1, 8,
Offset (0x01),
M2, 8,
Offset (0x02),
M3, 8,
Offset (0x03),
M4, 8
}

Method (_DSM, 4, NotSerialized)
{
Store (0x07, M1)
Store (0xE3, M2)
Store (Zero, M3)
Store (0xC0, M4)
Return (Zero)
}
But i'm a little bit confuse because i don't have the "0x001F0001" offset. Perhaps you could help me. Thank you

Here my DSDT.dsl.zip

I only have this "confidential" document so be real nice to fae@jmicron.com and ask for the JMB362 Data Sheet

This is how my SATA device looks in my dsdt.dsl at the moment:
			Device (SATA)
		{
			Name (_ADR, 0x001F0002)
			Method (_DSM, 4, NotSerialized)
			{
				Return (MCID (Arg2, 0x2681))
			}
		}
Guess i'll screw the bay information. It works great as it is at the moment. I don't have to use any injector for device ids and stuff like that.

And tbh, i'll get my 24" iMac early 2009 generation with a radeon 4850 tomorrow evening. Guess i wont mess with a hack anymore when i have this iMac.

My congratulations! Happy to see you on the other side (in the Apple forums).

Hi all, i found something very interesting!!!
On some gigabyte mainboard, SSDT table depends on feartures you enabled in bios....

@masterchief

your dsdt mod is really excellent, good job!!

I'm merging those mods to my i7 platform.

Pssst CSTInfo Number 0x1140105 is C1 only! You are missing the CStateOverride Boolean True

asapreta · November 5, 2009

I´ve been away for some days, but will read everything you guys posted since I´ve been out.

But a question I was to ask before my trip. Is there any way to make this "programmable" or a very generic one for some motherboard families than we "mere mortals" can do some editing activating what we find most relevant for our needs?

Of course I wanna a real hackintosh, but truth said, it´s kinda difficult to follow you guys sometimes.

Keep the good work.

FKA · November 5, 2009

I´ve been away for some days, but will read everything you guys posted since I´ve been out.

But a question I was to ask before my trip. Is there any way to make this "programmable" or a very generic one for some motherboard families than we "mere mortals" can do some editing activating what we find most relevant for our needs?

Of course I wanna a real hackintosh, but truth said, it´s kinda difficult to follow you guys sometimes.

Keep the good work.

Hi asapreta

I think this would be something to come in the future.

I'd love to see these methods applied to koalala's ACPI patcher, it was/still is a great application.

It's such a dam shame that guys not around anymore.

D.

Cathul · November 6, 2009

My congratulations! Happy to see you on the other side (in the Apple forums).

Thank you, but i'll surely miss the hacking of my current rig.

On the other side, i need my computer for work so it needs to be a solid system without the probability of breaking functionality with an official Apple update on OSX.

I have attached my modified dsdt.dsl with all my modifications so far.

It's for the GA-P35-DS3 with an Intel Core2Quad Q9550 only. Probably it's of some use to others with the same setup.

dsdt.dsl.zip

mitch_de · November 6, 2009

can someone explain in short the reason / goal of that code below :

OperationRegion ([b]IDET, PCI_Config, 0x40, 0x04[/b]) // IDE Timing Register
Field (IDET, WordAcc, NoLock, Preserve)
{
Offset (0x00),
M1, 8,
Offset (0x01),
M2, 8,
Offset (0x02),
M3, 8,
Offset (0x03),
M4, 8
}
Method (_DSM, 4, NotSerialized)
{
Store (0x07, M1)
Store (0xE3, M2)
Store (Zero, M3)
Store (0xC0, M4)
Return (Zero)
}

Cosmetic/Apple_like mod or does this avoid things like 4GB+ IDE KPs without modding IOATA & Co and similar really needful things ?

I am a bit slower / dont like to add all possible cosmetic only things in my dsdt, but thats my own thinking;)

Thanks ( i have an EP-35-DS3, ICH9-SATA (non Raid).

DSDT fixes for Gigabyte boards

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites