137 replies to this topic

[LatinMcG]

LPC ICH9 or 10
RTC (so u dont need the RTC fix)
New Hpet
HID to CID (power button hack)

Remove HCI ownership from list.
HCI Sleep (i need to check your D7and A7 EHCI entries if not missing.)
post dsdt in zip
and ioregistry explorer dump

ill post the EHCI Optiplex patch.txt i got for these.

[DougJoseph]

Well, I'm back now. That caused the root device to be unavailable. So, now I am trying again with smaller steps.

This time:

PATCHES I applied:
1. DTGP
2. AHCI SATA orange icon

Rebooting again now. Report back soon.

PS: I wrote the above before I saw your reply. I will try the steps you outlined. Thanks again!

Here is my second try "REDUX"

PATCHES I applied:
1. DTGP
2. AHCI SATA orange icon
3. EHCI sleep
4. ICH9 USB sleep
5. LPC (I don't know if the patch was for 9 or 10. I am on ICH9. I got no errors on compiling.)
6. RTC (Note to self: remove the "RTC fix" kext)
7. New HPET

I removed "EHCI ownership" from the list, as you instructed.

I cannot find a patch for "HID to CID (power button hack)" -- Can you give me any guidance on that?

I will attach the and ioregistry explorer dump and the DSDT in zip format. (You mentioned checking my D7and A7 EHCI entries if not missing. Thanks!)

What is the EHCI Optiplex patch you mentioned about posting? Do I need to wait for it before rebooting?

Re: the zip of the files:

I tried twice to upload. I keep getting server error. Will find another way.

[LatinMcG]

think its in patches/desktops CID

the ehci patch for optiplex..  when its missing the EHCI devices on some optiplex . it needs it in dsdt to patch the sleep of it.

dont forget SBUS also

[DougJoseph]

Thanks again, LatinMcG!

I downloaded from here:

Quote

Download: (last updated on 29/Sep/2011)

Mac OS:   DSDTEditor_Mac.zip   1.04MB   10438 downloads

Third try. Until now, I was apparently using either an old or incomplete set of patches. I am now using the set that has a folder called "Desktop"

PATCHES I applied:
1. DTGP - from "Desktop" folder
2. AHCI SATA orange icon - from main folder
3. EHCI sleep - from main folder
4. EHCI - from "Desktop" folder -- ## this is perhaps something you have a better version of?
5. ICH9 USB sleep - from "Desktop" folder
6. LPC ICH9 - from "Desktop" folder
7. RTC - from "Desktop" folder
8. New HPET - from main folder
9. SBUS - from "Desktop" folder -- ## Note: when I did this, I got two errors: name already exists in scope BUS0, and in _ADR.
10. HID to CID - from "Desktop" folder.

Question: Is ElliotLegacyRTC the right kext to delete?

Note: re: the SBUS error: I found two copies of the same code right next to each other, and removed the second one. No errors now.

I am trying here to attach the files. Looks like it worked this time.

When you glance at them, would you see if the attached o.c.b.plist needs any changes? I am fuzzy on what overlap there can be on stuff like sleep states, etc.

Attached contains IOReg dump, AML, DSL, and o.c.b.plist.

Attached Files

•  Dell-755-ICH9.zip   322.75K   52 downloads

[DougJoseph]

Thanks again, LatinMcG for your help!

Currently this DSDT causes the "Still waiting for root device" issue. This may be something easy for a guru like you to fix, but I am lost on it...

[LatinMcG]

k il look at it. and post later tonight.(i have to go out onsite)

the new hpet use from main patches folder.. the stil waiting for root might be the Device (PCI0) has _UID, 0x04 change to 0x00

or u need to set raid on bios for ahci to work. ( if u dump dsdt with raid off it might be an issue.. not sure %100)

SBUS not sure why. maybe u allready had it patched


EDIT: i see in ioreg its loaded sata as 2922 not 2681 or 27c0 that are compatible

and the PCI0 _UID is 0x04 .. yep ioreg is with no dsdt

[LatinMcG]

EHCI is not missing.
i have to revise dsdt for extra junk.. disable lpt and com ports..

also if u booting with no dsdt.. u might need to leave raid off so it lets ide mode boot sata. then when u have dsdt with sata device id 2681 or 27c0 it needs raid

[DougJoseph]

OK, I am trying to follow.

Yes, the IOReg dump was made while booting without DSDT. At that time the BIOS was set to "Raid, if not available use AHCI"...

Do you need me to do anything else to provide more info?

You mentioned that "EHCI is not missing."

I left a patch called "EHCI ownership" per your instruction. I added a patch called simply EHCI. Should I have left that one out?

[LatinMcG]

nah all fine. set hibernatemode to 0 in terminal

sudo pmset hibernatemode 0

uncheck use secure virtual mem in security section of preferences.
remove hdadisabler as u have no HDEF in dsdt
dont use intelcpumpmdisabler if u are.  rm0ve and use GeneratePStates GenerateCStates in chameleon wizard.

[DougJoseph]

Thanks again.

I made the above changes, except:

I searched in the "Security & Privacy" section of preferences, but I could not find any option for Secure Virtual Memory.

Added later: I found an article here that says in OS X Lion, Secure Virtual Memory is always on.

I also found this page, which tells how to disable it via terminal. So, I will do that!


Re: the issue of 'waiting for root device'

On line #645 I found Device (PCI0)

On line #1016 I found Name (_UID, 0x07)

I changed it to Name (_UID, 0x00)

Not sure if that is right, but worth a try.

After the try:

Well, that one also caused the "waiting for root device" issue. So I changed it back.


Additional note:

I noticed today that the main folder has a patch named "SBUS" while the Desktop folder has one named "SMBUS"...

I had not noticed the difference until today. I then applied the SBUS from the main folder. No errors.

[LatinMcG]

_UID would be about 10 lines or so bellow device (PCI0)
if missing copy  the _ADR and rename to _UID (but its not missing .. yours says 0x00 aka Zero..as i fixed it i believe.

[DougJoseph]

Thanks!

I must have misunderstood earlier. I was looking for a UID of 0x04 to switch to a 0x00. Below are the 25 or so lines starting at PCI0. I guess it is already at the right setting.

I am still get the "waiting for root device" error.

		Device (PCI0)
		{
			Name (_HID, EisaId ("PNP0A08"))
			Name (_CID, EisaId ("PNP0A03"))
			Name (_UID, Zero)
			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)
				}
			}

[LatinMcG]

waiting for root device could be also the port u have sata on..
or the sata is at not raid with the deviceid of 2681 or 27c0
it needs raid for ahci

[DougJoseph]

Thanks,

I have two choice for drive access, and I have tried both.

1. RAID, unless not present, then use AHCI
2. RAID, unless not present, then use ATA

In both cases I am getting the "still waiting for root device" error, when I use the DSDT that I have so far... The one I have is based on your change, with other patches added.

[LatinMcG]

try this -v -x -f Wait=Yes
tell me if its loading /Extra/dsdt.aml


irqs have to be removed manualy ?
let me look at it more

[DougJoseph]

Also, I have just had a strange thing start happening. This just started in that last day or two. I can no longer get the BIOS settings to stay saved. Every time I boot, regardless of whether using a DSDT or having it deleted, the BIOS settings revert away from what I have saved there. Any idea what could cause that or how to fix it?

Edited to add: I earlier thought it was happening even with the DSDT deleted, but over time it seems that deleting the DSDT did allow the BIOS to get back to normal.

Also, I tried -v -x -f Wait=Yes
It was definitely loading /Extra/dsdt.aml

[LatinMcG]

dsdt is not loading then.
also i found this in sata

Device (SATA)
			{
				Name (_ADR, 0x001F0002)
				OperationRegion (RIDE, SystemIO, 0xFE32, One)
				Field (RIDE, ByteAcc, NoLock, Preserve)
				{
					IRST,   8
				}
				Method (_STA, 0, NotSerialized)
				{
					Alias (WEN3, MBEN)
					Alias (WST3, MBST)
					Store (GI32, Local0)
					And (GI32, 0x70, Local0)
					If (LEqual (Local0, 0x30))
					{
						Store (0x0F, Local1)
					}
					Else
					{
						Store (Zero, Local1)
					}
					Return (Local1)
				}

Alias might not work

[DougJoseph]

I gather that the DSDT is loading because without it I can boot, with it I cannot boot.

I first wondered if the DSDT could be over stepping and changing my settings in the PC's BIOS. Then I noticed the reverting was happening even when the DSDT file has been deleted. ??

When you say "Alias might not work" ... that is Greek to me! :-)

Just to check, I am now booting using a BartPE disc (boots into a Windows pre-installation environment). I am going to look into perhaps re-flashing the BIOS.

The Dell BIOS utility seems to be allowing me to re-flash the BIOS.

I have re-flashed the BIOS. I am now testing to see if BIOS changes stay saved. :-)

[LatinMcG]

yah no problem with alias i believe.

the rtc reset might be cause .. or sleep resets cmos is it lion or snow ?

im gone till tonight .. lowryparkszoo with kid

[DougJoseph]

As of now (booting without any DSDT file in place) the BIOS settings in the blue screen BIOS area, are staying saved.

It is Lion.

Have a great time at the zoo with family! That is excellent.
Also, thank you for all your help!