Dell Optiplex 755 DSDT, Vanilla SpeedStep+Sleep working.

[LatinMcG]

it management = TPI stuff

 

the "aiting for root device is something he did in the kexts or used a distro with modified ahci kexts.

 

sleepenabler wont be needed if EHCI patch is done right.

[gygabyte666]

@Doug & Catalyst,

 

I already provided a direct link to the dell support page for the 755. There are several BIOS revs on that page. Not sure if this is helpful or not but I just checked my ioreg for my e1000e and I have this for ethernet:

 

Built-In=<01>

 

I assume that 01 means yes where 00 would mean no but I could be wrong. I can log into the App Store, iCloud and the iTunes Store just fine. If you're having problems trying to figure out your dsdt then please feel free to download my dsdt on the first post from my 760 thread and examine it for clues to help you out. I can't guarantee it'll fix everything but it should be better than going in completely blind. Going off what Latin suggests, you could probably just copy/paste my EHCI fixes right into your own dsdt without much fuss. Just be sure to check for errors while compiling.

 

http://www.insanelymac.com/forum/index.php?showtopic=275921&hl=&fromsearch=1

 

Hope it helps. Good luck.

[catalystTGJ]

gygabyte,

 

Thanks for the info on your 760 thread. I read through it, and lived your pain (vicariously... and that was enough!)

 

My current circumstance with sleep on the 755 sounds terribly similar to yours on the 760. Its sort of working, BUT... if the machine sleeps for more than around a minute of time (if less, then it works fine, but a minute or more and the problem happens), upon waking it, it will function for about 30 seconds (might even be exactly 30 seconds), and then bounce! And it's a seriously hard bounce, no warnings or error screens of any sort, just BLAM! black, and then reboot of course. Same as what you're seeing. I was reading on another thread where folks were thinking it had something to do with VMware 4, but my opinion now is its strictly Lion and the Optiplex (Probably others have this problem as well). I can reproduce this failure on a clean copy of Lion with no Vmware installed, so its not that at all. At any rate.. My biggest frustration with the system isn't sleep though. I could just as well turn that {censored} off and not even worry about it, but the random KP's on startup or even on reboots is what's most annoying, and i really wanna cure that with this DSDT patching, if at all possible. So far, i've not had much luck with any of the DSDT's posted on this thread, though I think/feel like they do help somewhat. They definitely get rid of the USB sleep warning deal that i was seeing in verbose when not using a DSDT, but i still get random KP's. Funny thing is, its like there's some sort of limit on how many KP's can happen in a row. Almost as if there's something in the code that is saying... "Alright, now that's enough panicking... just work already!" It seems that around 3 KP's in a row, and then it'll boot up . That's silly, I know... but maybe someone else has a thought about that. At any rate, i've exported the DSDT.aml from my system two ways. One from the Hack itself, and another from the Windows iasl.exe. The outputs look identical to me, but i haven't done a byte compare between the two yet.

[gygabyte666]

That sounds all too familiar. My original sleep problem was my own ignorance. I haven't owned a tower in years so I assumed on knowledge i've had of previous towers from say, oh about 5-6 years ago on how they would define as sleeping. Back then, they didn't have such aggressive power management as they do now. Long story short, my tower originally wasn't sleeping at all. It would merely go into what I call "coma-mode" in which the system remained on but the display would turn off. Fixing the dsdt properly is the only way this was solved so it would actually sleep/wake.

 

That said, my system is still far from perfect. Even though I have working sleep/wake I have BIOS resetting issues that i've never been able to really fix. If I wake my system from sleep on Lion or SL some of my BIOS options will reset or change. For example, it will change my networking preferences from enabled to enabled with PXE, which breaks my ethernet upon wake. It will also set my system to enable auto on time, which really sucks since my computer could turn on randomly. These are issues I face even today with no real solution in sight with the exception of just not allowing my system to sleep, but for me and what I do, it doesn't really need to sleep. I also have a reboot bug that couldn't be fixed either. If I reboot from Lion or SL my BIOS will hang at the Dell splash screen. The only fix is to hard shutdown the system from the power button and then turn it back on. Not really a dangerous problem to have but annoying just the same.

 

Anyway, what you're experiencing sounds unfortunately like it could be from a million different things. Unneeded Chameleon plist flags and/or kernel extensions, incorrect BIOS settings, or just conflicting and incorrect dsdt fixes. I would start screwing with dsdt LAST from everything else. using improper dsdts from other systems or inaccurate fixes on your own can cause more problems than they fix. It's best to make certain your setup is accurate with the basics like BIOS settings, boot flags, and kexts before you start seriously messing with dsdt fixes.

 

It's very likely that your extracted dsdts from both Windows and OS X are identical but to be safe I suggest you extract one from using a Linux distro. It's the only way to be 100% certain that no other factors are screwing with the extraction results. Any live disc version of Linux should work fine and not take more than a few minutes with a USB drive handy. VMWare I can't say much about because my current processor doesn't support VT-x so I can't use it on my current setup. I feel much the same way as you though, I doubt it would be causing any issues. The BIOS & processor handles how VT-x is used, not the OS afaik. USB sleep warning can easily be fixed with the EHCI dsdt fix mentioned several times above but it only really prevents full system sleep for now so I would be more concerned with the other issues ATM.

 

Lastly, the random KPs could also be from unneeded boot flags and/or kexts, poor BIOS settings or by using other system dsdts. I can't stress enough how important it is to really test out your setup and purge unneeded files. It will likely take time and patience to do but I really should get done. You should also make sure that if you are using kernel caches, they are being rebuilt properly. If you're unsure of how to make them in Terminal, then just delete them and allow the OS or diskutil to rebuild them on their own on next reboot.

[LatinMcG]

the dsdt would be same if extracted in win or linux.

[gygabyte666]

As I mentioned that would probably be the case however, I've always felt more comfortable relying on Linux for dsdt extraction. Just personal preference tips really.

[LatinMcG]

As I mentioned that would probably be the case however, I've always felt more comfortable relying on Linux for dsdt extraction. Just personal preference tips really.

i used to think it would affect it but its hard coded

[catalystTGJ]

Gig, i understand the warm and fuzzy that one can get from doin something a tried and true way, but i'm leaning towards Latin's opinion. DSDT should be coming from hardware and not something that should change, unless somehow using a DSDT in a hack bootloader could change what gets read.. then i can see a reason to reach out to some alternate OS that isn't also already "soft" adulterating it like perhaps a linux distro. My understanding of DSDT's is that fooling with them at all started in the 'nX world, but that's the extent of my knowledge on the subject anyway. I do agree on hackin on DSDT as the last resort. My problem is that the process i went through to build this 755 hack was pretty darn plain vanilla as it comes. I used ###### with Lion (10.7.3), and followed that up with ###### with the [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] choice, adding the voodoo audio driver and the AppleIntel1000e nic driver. That all worked great. So before even playing with any DSDT's i've been experiencing these random KP's at start up, BUT i do also have an nVidia GT 240 card in there and using an EFI string to get that working which it does, but there's not much more to it beyond that. So far Sleep works great if i just use it as S1 mode instead of S3. Only when S3 is on do i start having all these problems specific to sleep. I think the DSDT route is the only route to get the KP's under control, but the one big thing that i've noticed about the hack community is there seems to be a lack of documentation with particular tools. Maybe someone can point me to some more fundamental information on what's out there, but when i look at all these patches for DSDT's there's very little explanation for what they are all for. That makes the entire process much more difficult, I feel. To a point most of it is pretty self explanatory, but there's a great deal of room to improve me thinks. I've begun the arduous process of patching, which isn't terribly difficult in and of itself, but the constant rebooting to test is frustrating as all get out. Can burn up a lot of time messing with these steps. I think i need some more raw knowledge on DSDT's in general to get a better understand of it all. I too ran into the same problem of the "still waiting for root device".. that others have seen, so i feel if i could get past this things might be golden! I appreciate everyone's comments and feedbacks so far on here. Good stuff. :-)

[gygabyte666]

i used to think it would affect it but its hard coded

 

Makes sense. I assumed as much. I guess I'm just a complete and total unix whore, lol. I try to avoid using Windows for as much as possible. Again, personal preference.

 

@Catalyst,I can't exactly say I agree with your install being totally vanilla anymore since you relied on MBeast to assist with the process. I'm sure it helps new users by being user-friendly but aside from that I still considerate it in the same grey-area as a modified distro and I would never advise it to be used in place of a manual installation. Just my 2 cents.

 

You might want to consider making a thread in their support forum.

[catalystTGJ]

Yeah, that's a possible route as well. I'm more interested in the DSDT discovery process at this point. Hence the reason i ended up on this thread. The other site is sparse on this sort of detail. The machine works pretty well anyway, just gotta smooth out the rough edges. At the end of the process one thing is certain to me now. Other than the wealth of knowledge one might gain from studying how it all works, (pulling back the proverbial curtain so to speak), seriously the cost of buying a real Mac is definitely worth the money to just avoid all the extra work it takes to try to build a hack instead. Obviously, there's many reasons to construct a hack other than cost, but most of the time its simply folks trying to avoid a premium cost of apple hardware, or perhaps trying to get a more powerful system at a lower price, again still just a cost thing. My opinion is the mac equipment is good enough, and more enjoyable to use than to tinker too long with problems such as these. Not saying i would have chose not to do this, if i'd known how much trouble it would be before. I knew it would be, but its expensive to spend so much time on it. Its not monetarily logical really. Mac's are not that high. :-)

 

I'll tinker some more tonight with the DSDT edits and try and get something working satisfactory. If i make progress i'll post here.

[gygabyte666]

I own many, many authentic Apple machines. That said, I tinker around with osx86 because I like it. I do it because I enjoy problem solving and coming up with solutions to problems that can occur from testing with it on different hardware. I also do it for knowledge on how to fix problems affecting my real Macs that Apple doesn't supply fixes for on their own.

 

Everyone is entitled to their own opinion but to me, those who are involved in the osx86 community for no other reason than to pirate Apple's software, their hard work or to provide themselves with a cheap/free alternative to actually supporting Apple are in it for completely the wrong reasons. To me, if you're not willing to put in a fair amount of work and spend a potientially long time trying to figure things out for yourself then you are clearly in the wrong place. It's the main reason I will never support or recommend people to use modified distros or the so called "noob installers". I've always seen this community as not a community of thieves and pirates but as a community of problem solvers who are love the hardware and software they use and personally, i'm proud to be a part of it.

 

Anyway, this is getting off-topic so I wish you luck in solving your problems. I only hope you are doing this for the right reasons. I'll leave it at that.

[DougJoseph]

gygabyte666:

 

I purchased a copy of Lion for this from the App Store, but I was unable to get it to install using a 16GB thumb drive and ######'s ###### method. That's why I used a distro. Based on what LatinMcG has mentioned, use of a distro may be why I cannot get a DSDT file to successfully get past the "waiting for root device" issue. Do you have any advice for me on actually using this copy of Lion "vanilla" style? Some way other than ######?

[gygabyte666]

Sure. Check post #5 at this thread for instructions on repartitioning your thumb drive so you can use it to install your purchased copy of Lion for a fresh install. It isn't exact but hopefully it's close enough to help you out, just ignore the stuff that doesn't pertain to your setup. If it's not clear enough let me know and i'll provide more details. Just be sure to backup your current kexts, etc in the Extra folder before formatting. You'll need them later. http://www.insanelym...l=&fromsearch=1

[catalystTGJ]

DougJoseph,

 

I know why you're getting the "root device" problem. I too had this issue, and it has to do with fixing the errors that show up with the original DSDT. If you fix them, it actually breaks it. If you leave them, it should work fine. There should be 4 errors, if you start with a clean DSDT, no patches, and you attempt to compile it. Do not FIX these errors, and then take the AML file gen'd and test it with your machine. It should boot without any issues. Keep in mind the initial 2-3 KP's is normal before it will boot up properly. After you see this working, go ahead and do some patching, but always take note of the error count when you compile. If it goes up past the initial 4, you've got problems creeping in. If it stays at the 4, then you know its just the original flaws that the DSDT had to begin with. This is working well for me so far. I have not attempted to fix these 4 errors, and i've made about 6-7 DSDT's with various patches so far, and they have all worked.

 

I've also noticed that not all of the patches will actually go into the DSDT with the patching apps, so I'm wondering about this, and what all it means. I've been able to successfully add:

 

DTGP (Needed by the other things that use it.)

SHUTDOWN (This fixed SHUTDOWN, which would just reboot the machine if attempted without this patch.)

REMOVE (This got rid of a couple of things, but I think SPK survived, which may need to be removed manually)

ICH9 USB Sleep (I think this cured the need for the use of a Sleepenabler KEXT, however sleep is still broken if using S3 mode in BIOS)

_T_x rename (unsure what this gained)

New HPET (unsure of any improvement here, and have yet to try the other HPET)

 

I tried but abandoned the following:

LPC ICH9 (This CAUSED LPC initialization failure)

LPC ICH10 (This also CAUSED LPC initialization failure)

 

Now, maybe there's something else needed to get the above to work right, but from what i can tell attempting to add the EHCI stuff doesn't work as it doesn't actually get added in by a patching app. Maybe that means that it must be done manually, in which case i haven't reached that level. Some advise on this would be much appreciated by anyone on here.

 

Hope some of this information is found useful. So far, My system works with Sleep (S1 mode), Shutdown, Graphics is all working with the EFI string method. I want to move this into the DSDT so that i can get the HDMI and audio working right with this. I also do still have the problem with the App Store not recognizing the nic, so I need to get that worked out, and have some information on that already, so hopefully won't be too tough to get going. I think the random KP problems are gone as well, but that remains to be seen/experienced.

 

Cheers.

[DougJoseph]

catalystTGJ:

 

Wow! Thanks. Will try this.

[catalystTGJ]

I took baby steps when i was adding the patches. The first two i started with was "DTGP" and "SHUTDOWN". I tested those alone and that fixed shutdown for me. I suppose i could post the DSDT's that i've made so far, but i am running A21 BIOS also, just in case you weren't aware of this possibly important detail.

[LatinMcG]

the EHCI i modified someones addition to work with most optiplex missign EHCI

ill past later. {im in windows}

 

can u show part of the errors that dotn need fixing. i dont know if i got an original dsdt to check that out.

[catalystTGJ]

Below is what came out of the log generated by Chameleon Wizard compiling the dsl. I'm only posting the 4 errors here, as there are also a number of warnings and remarks as well. i can post the whole log if you'd like to see the whole thing. I need to figure out how to attach files in here, then i can post the original .aml file as also:

 

 

 

/Users/catalysttgj/Desktop/DSDTEditor-Linux-Mac-Win (Parser)/755-A21-DSDT-00.dsl 2953: 0x0EC00000, // Length

Error 4050 - Length is not equal to fixed Min/Max window ^

 

/Users/catalysttgj/Desktop/DSDTEditor-Linux-Mac-Win (Parser)/755-A21-DSDT-00.dsl 2964: 0xF0000000, // Range Minimum

Error 4051 - Address Min is greater than Address Max ^

 

/Users/catalysttgj/Desktop/DSDTEditor-Linux-Mac-Win (Parser)/755-A21-DSDT-00.dsl 2981: 0x00004000, // Length

Error 4043 - Invalid combination of Length and Min/Max fixed flags ^

 

.

.

.

 

 

/Users/catalysttgj/Desktop/DSDTEditor-Linux-Mac-Win (Parser)/755-A21-DSDT-00.dsl 4831: Return (Zero)

Error 4104 - Invalid object type for reserved name ^ (found ZERO, requires Buffer)

 

Damn, I'm slow! Finally figured out how to post a file on here. I'm enclosing a clean 755 DSDT with A21 Bios.

755-A21-DSDT-00.aml.zip

[LatinMcG]

as i suspected. i been fixing that on them.

even in my inspiron 1520. hmm

[catalystTGJ]

One thing i just discovered, and perhaps you'll want to confirm this... I tried out DSDTSE from the Evo folks, and it seems that it doesn't produce the same errors during a compile. I get 0 errors from it, so perhaps the Evo app is a little bit more updated in this area, than the chameleon wizard, and other apps that do compilation?

 

Oh, and you mentioned you had a modified EHCI code for machines that don't have it, if i understood that correctly... Would you happen to able to post that up? I'd like to check this out, or if you could point me in a direction, if its already posted in someone else's stuff. If its just a block of code i need to paste in, I think i'll be able to figure that out. I've made a total of ten DSDT's so far gradually adding specific patches, but some of the patches that i see people claiming they're adding do not actually change anything when i "preview" them in the patch tools. Perhaps I have to add them in manually when they don't go in on their own, but this seems contrary to the patching scheme, so i'm not sure that they are really supposed to belong in there.

 

I've been able to put into the DSDT the following to date:

DTGP

SHUTDOWN

PATCH REMOVE

LPC ICH10 (Though I have left this out of further DSDT's as it caused LPC init failures.)

LPC ICH9 (Also, left this out of further DSDT's as it caused LPC init failures.)

ICH9 USB Sleep

_T_x Rename

New HPET (I'm a bit concerned that this might have influenced a change in USB messaging that i see in verbose boot)

Manually I removed the COMA and COMB blocks. (Changed nothing as far as i can tell, but works without them)

LPC (This also caused LPC init failures, so also left out.)

SBUS

 

All of these i was able to see that changes were happening in the preview.

 

But certain patches that are recommended by folks didn't show any changes at all, such as:

 

from the Desktop Folder:

EHCI

IRQs

RTC

SMBUS

 

from the Patch folder:

EHCI Ownership

EHCI Sleep

 

I haven't fooled with the speedstep stuff yet. I'm also curious about the WAK patch, but it says its for Gigabyte boards in the comments of the code. It sure would be nice if there was better documentation for all these patches. Either I just haven't found it, or it really doesn't exist in one nice organized place. Seems its just a scattered mess.

 

I'm also wanting to add the GT240+HDMI+Audio code block mentioned on the TM site, but i'm a bit uncertain as to how i do this properly. I believe I need to just replace the entire code block that is already in the DSDT starting at "Device (PCI0)" and ending at just before "Device (IDE1)".

 

Without spending too much time on this, is my thinking correct? Below, I've listed the two code blocks in question.

 

This is the code block I need to add:

 

 

Device (PCI0)

{

Name (_HID, EisaId ("PNP0A03"))

Name (_ADR, Zero)

Name (_UID, One)

Name (_BBN, Zero)

Method (_S3D, 0, NotSerialized)

{

If (LEqual (OSFL, 0x02))

{

Return (0x02)

}

Else

{

Return (0x03)

}

}

 

Device (PEGP)

{

Name (_ADR, 0x00030000)

Name (_PRW, Package (0x02)

{

0x09,

0x05

})

Device (GFX0)

{

Name (_ADR, Zero)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x1A)

{

"AAPL,slot-name",

"PCI x16",

"@0,compatible",

Buffer (0x0B)

{

"NVDA,NVMac"

},

 

"@0,device_type",

Buffer (0x08)

{

"display"

},

 

"@0,name",

Buffer (0x0F)

{

"NVDA,Display-A"

},

 

"@1,compatible",

Buffer (0x0B)

{

"NVDA,NVMac"

},

 

"@1,device_type",

Buffer (0x08)

{

"display"

},

 

"@1,name",

Buffer (0x0F)

{

"NVDA,Display-B"

},

 

"NVCAP",

Buffer (0x18)

{

/* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00,

/* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07,

/* 0010 */ 0x00, 0x00, 0x00, 0x00

},

 

"VRAM,totalsize",

Buffer (0x04)

{

0x00, 0x00, 0x00, 0x40

},

 

"device_type",

Buffer (0x0C)

{

"NVDA,Parent"

},

 

"model",

Buffer (0x16)

{

"nVidia GeForce GT 240"

},

 

"rom-revision",

Buffer (0x25)

{

"3172a"

},

 

"hda-gfx",

Buffer (0x0A)

{

"onboard-1"

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

}

 

Device (HDAU)

{

Name (_ADR, One)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"hda-gfx",

Buffer (0x0A)

{

"onboard-1"

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

}

}

 

Method (_STA, 0, NotSerialized)

{

Return (0x0F)

}

 

 

This is the code block I think i need to replace: (I believe this to be related to the onboard video which i'm not using at all.)

 

 

Device (PCI0)

{

Name (_HID, EisaId ("PNP0A03"))

Name (_UID, 0x04)

Name (_ADR, Zero)

Name (_PRW, Package (0x02)

{

0x0D,

0x05

})

Method (_S1D, 0, NotSerialized)

{

Return (One)

}

Method (_S3D, 0, NotSerialized)

{

If (HACK ())

{

Return (0x03)

}

Else

{

Return (0x02)

}

}

Device (GRFX)

{

Name (_ADR, 0x00020000)

Method (_S1D, 0, NotSerialized)

{

Return (0x03)

}

Scope (^^PCI0)

{

OperationRegion (MCHP, PCI_Config, 0x40, 0xC0)

Field (MCHP, AnyAcc, NoLock, Preserve)

{

Offset (0x60),

TASM, 10,

Offset (0x62)

}

}

OperationRegion (IGDP, PCI_Config, 0x40, 0xC0)

Field (IGDP, AnyAcc, NoLock, Preserve)

{

Offset (0x12),

, 1,

GIVD, 1,

, 2,

GUMA, 3,

Offset (0x14),

, 4,

GMFN, 1,

Offset (0x18),

Offset (0xA8),

GSSE, 1,

GSSB, 14,

GSES, 1,

Offset (0xB0),

, 4,

GCDC, 3,

Offset (0xBC),

ASLS, 32

}

Method (GSCI, 0, NotSerialized)

{

OperationRegion (IGDM, SystemMemory, ASLS, 0x2000)

Field (IGDM, AnyAcc, NoLock, Preserve)

{

SIGN, 128,

SIZE, 32,

OVER, 32,

SVER, 256,

VVER, 128,

GVER, 128,

MBOX, 32,

Offset (0x200),

SCIE, 1,

GEFC, 4,

GXFC, 3,

GESF, 8,

Offset (0x204),

PARM, 32

}

Method (GBDA, 0, NotSerialized)

{

If (LEqual (GESF, Zero))

{

Store (0x41, PARM)

Store (One, GXFC)

Return (Zero)

}

If (LEqual (GESF, One))

{

Store (Zero, PARM)

Store (One, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x04))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x05))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x06))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x07))

{

Or (PARM, GIVD, PARM)

XOr (PARM, One, PARM)

Or (PARM, ShiftLeft (GMFN, One), PARM)

Or (PARM, 0x1000, PARM)

If (LLess (TASM, 0x08))

{

Or (PARM, 0x00020000, PARM)

}

Else

{

If (LLess (TASM, 0x10))

{

Or (PARM, 0x00040000, PARM)

}

Else

{

Or (PARM, 0x00060000, PARM)

}

}

Or (PARM, 0x3E800000, PARM)

Store (One, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x0A))

{

Store (0x04, GXFC)

Return (Zero)

}

Store (0x04, GXFC)

Return (Zero)

}

Method (SBCB, 0, NotSerialized)

{

If (LEqual (GESF, Zero))

{

Store (Zero, PARM)

Store (One, GXFC)

Return (Zero)

}

If (LEqual (GESF, One))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x03))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x04))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x05))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x06))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x07))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x08))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x09))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x0A))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x0B))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x10))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x11))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x12))

{

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GESF, 0x13))

{

Store (0x04, GXFC)

Return (Zero)

}

Store (0x04, GXFC)

Return (Zero)

}

If (LEqual (GEFC, 0x04))

{

GBDA ()

}

If (LEqual (GEFC, 0x06))

{

SBCB ()

}

Store (One, SCIS)

Store (Zero, GESF)

Store (Zero, GSSE)

Store (Zero, SCIE)

Return (Zero)

}

OperationRegion (TCOI, SystemIO, 0x0860, 0x08)

Field (TCOI, WordAcc, NoLock, Preserve)

{

Offset (0x04),

, 9,

SCIS, 1,

Offset (0x06)

}

}

[LatinMcG]

backwards .. its outdated.. iasl newer checks for more "errors"

 

the EHCI missing that happens to 755.

http://www.insanelym...dpost&p=1800329

compare his original to the one i patched for ideas.

 

(i seem to have lost that file but wil retrace it eventualy)

 

 

u can rip out Device (GRFX)

[catalystTGJ]

Ah, I see. hmm... The rabbit hole gets deeper then! Seems they might be false positives, possibly?

[LatinMcG]

seems errors about min max flag seem to cause issue for these optiplex's

idea would be to check it in dsdt editor and save as .dsl then compile in dsdtse.

[stenopo]

Hi guys,

 

I'm another proud owner of a 755MT (Q6600 / A21 / 8600GT512Mb) that is beginning the funny game of dsdt tweaking. How my BIOS version is A21 I started with the DSDT posted by catalystTGJ. Trying to continue with his work, I started with the speedstep hack, but I don't know how to check if it is working right. So, I post the file here and together maybe in collaboration We'll get system as optimized as possible.

 

Download DSDT.aml

 

Thanks

[LatinMcG]

speedstep in dsdt = pre chameleon 2.0 RC5 GeneratePStates GenerateCStates