Alienware m17x r3 DSDT suddenly causing kernel panics in OS and Install USB

[TittyKitty]

Right after finally getting everything up and running correctly, suddenly and seemingly inexplicably my Alienware m17x r3 gets kernel panics at boot. It doesn't matter if I use the USB stick or boot from the bootloader on the HDD, or even if I boot into my installation of OS X or the installer. Right after I start booting and it loads all those files at the start of the process, I get a kernel panic. I think it happens right after it does something with the CPU Power Management kext, but it moves too fast for me to be able to tell 100%.

The reason I think it's the DSDT is because when I boot with DSDT=Null it works (although I get a black screen because I'm pretty sure my DSDT has a patch for my graphics). What would cause a DSDT to suddenly cause the system to crash, regardless of whether it's on the HDD itself or the USB?

The last thing I was doing before this happened was installing Xcode and PyAlienFX. I installed libusb and then attempted to install PyAlienFX, which didn't work, so I read this and attempted to install PyGTK. The installation for PyGTK never started because Xcode was in the middle of installing. When I went to launchpad to check on the progress of Xcode, the system froze (everything except the mouse), and when I rebooted these kernel panics began.

I'm going to attempt to re-extract the DSDT using linux and edit it again with only what is absolutely necessary. Interestingly enough, when I extracted my DSDT via Windows, it got compile errors without me even changing anything. I commented out something to fix one of the errors and then found a fix for the other one elsewhere, and then made the patches suggested in this thread. Even if I get it working after doing it over, I still would like to know what would cause sudden kernel panics like this.

Also, one more thing, I briefly got it to work after booting into Windows once and restarting. It booted normally, except I got a kernel panic with VoodooHDA (even though it was working before). This only fixed it once however, after trying the same thing again it didn't work.

Specs:
Intel i7-2670QM
4GB Ram
Intel HD 3000 or ATI 6870M (disabled)

Also, the flags -x and -s don't do anything, the same thing happens in the same place. Attached are my DSDT, bootloader settings, and a screenshot of the kernel panic. Thanks in advance for any help!


View attachment DSDT.zip
View attachment org.chameleon.Boot.plist

 

[RehabMan]

...
The reason I think it's the DSDT is because when I boot with DSDT=Null it works (although I get a black screen because I'm pretty sure my DSDT has a patch for my graphics). What would cause a DSDT to suddenly cause the system to crash, regardless of whether it's on the HDD itself or the USB?
...

Post the DSDT you have at /Extra/dsdt.aml.

Also,

Please provide complete details in your profile/signature
(Profile/Settings link in upper right corner of this site)

System: manufacturer/model
CPU: detailed CPU model + motherboard chipset
Graphics: all graphics devices + laptop internal screen resolution

For example, typical Ivy laptop:
System: HP ProBook 4540s
CPU: i5-3320m/HM76
Graphics: HD4000, 1366x768

Use CPU-Z on Windows to find CPU (Core iX-xxx) and motherboard chipset (HMxx), and graphics capabilities. For a laptop, these details are important and affect critical installation procedures.

Note: DSDT and PCIRootUID are not kernel flags and have no effect when passed to the kernel.

 

[TittyKitty]

Post the DSDT you have at /Extra/dsdt.aml.

Also,

Please provide complete details in your profile/signature
(Profile/Settings link in upper right corner of this site)

System: manufacturer/model
CPU: detailed CPU model + motherboard chipset
Graphics: all graphics devices + laptop internal screen resolution

For example, typical Ivy laptop:
System: HP ProBook 4540s
CPU: i5-3320m/HM76
Graphics: HD4000, 1366x768

Use CPU-Z on Windows to find CPU (Core iX-xxx) and motherboard chipset (HMxx), and graphics capabilities. For a laptop, these details are important and affect critical installation procedures.

Note: DSDT and PCIRootUID are not kernel flags and have no effect when passed to the kernel.

Alright, attached are two DSDT files, OldDSDT is the one I was using at the time I made this thread, and DSDT is the new one I just extracted and edited from linux. Both produce the same results. I also updated my signature and profile.

Also, sorry, I didn't know the difference between kernel flags and everything else. That guide I linked to had PCIRootUID and DSDT there for some reason. Does it automatically load the DSDT in /Extras/?

Thanks for the help.

View attachment DSDT.zip

 

[RehabMan]

Alright, attached are two DSDT files, OldDSDT is the one I was using at the time I made this thread, and DSDT is the new one I just extracted and edited from linux. Both produce the same results. I also updated my signature and profile.

Also, sorry, I didn't know the difference between kernel flags and everything else. That guide I linked to had PCIRootUID and DSDT there for some reason. Does it automatically load the DSDT in /Extras/?

Thanks for the help.

View attachment 105823

First of all, your OldDSDT.aml and DSDT.aml have differing OperationRegion addresses, which usually indicate that they were extracted with under different hardware configuration (eg. different amount of RAM) or different BIOS version, or it indicates you have floating regions (only solution is to use Clover).

Second, if a freshly extracted and patched DSDT causes problems but the native DSDT doesn't, it is either the edits, or randomly floating regions. Post your native DSDT so I can compare.

 

[TittyKitty]

First of all, your OldDSDT.aml and DSDT.aml have differing OperationRegion addresses, which usually indicate that they were extracted with under different hardware configuration (eg. different amount of RAM) or different BIOS version, or it indicates you have floating regions (only solution is to use Clover).

Second, if a freshly extracted and patched DSDT causes problems but the native DSDT doesn't, it is either the edits, or randomly floating regions. Post your native DSDT so I can compare.

Alright, here's the one I extracted via linux:
View attachment NativeDSDT.zip

I'm pretty sure I still had switchable graphics enabled the first time I extracted it, but the second time they were disabled and it was only using the HD3000. Also, the first time I extracted it was under Windows, but the second time was with an Ubuntu USB. The bios was the same version both times I extracted it.

 

[TittyKitty]

You're gonna kill me, but I was under the impression that when you booted from the USB it loaded the DSDT from there as well. I never replaced the DSDT on the OS X partition with the one I just extracted from linux. I just did and it's working fine again.

I'm curious though, did the old DSDT stop working because I changed my switchable graphics setting or what? I'm kind of concerned that I might have floating regions like you said, and the only reason it's working now is by chance.

Anyway, thanks for the help, and sorry for bumping this. I didn't know if you'd see it if I just edited it.

 

[RehabMan]

Alright, here's the one I extracted via linux:
View attachment 105824

I'm pretty sure I still had switchable graphics enabled the first time I extracted it, but the second time they were disabled and it was only using the HD3000. Also, the first time I extracted it was under Windows, but the second time was with an Ubuntu USB. The bios was the same version both times I extracted it.

The OperationRegions are definitely different between OldDSDT and NativeDSDT/DSDT. They match against the newly patched DSDT.

I'm not sure which DSDT wins when you boot from USB with a DSDT in /Extra to a partition which also contains an /Extra/DSDT. Best not to test the ambiguity.

Most of the patches you're using are pretty normal, except the IRQ patch is a bit different. You might try my "IRQ Fix" from here: https://github.com/RehabMan/Laptop-DSDT-Patch. Other useful stuff there too...

There are also differences in methods GOPS and SOPS... maybe this is a diff in the native DSDT.

 

[RehabMan]

...
I'm curious though, did the old DSDT stop working because I changed my switchable graphics setting or what? I'm kind of concerned that I might have floating tables like you said, and the only reason it's working now is by chance.
...

It could be floating regions or it could be that you made a material change to your BIOS options which caused a change in the native DSDT. Whenever you do that, you must re-extract and re-patch...

 

[TittyKitty]

The OperationRegions are definitely different between OldDSDT and NativeDSDT/DSDT. They match against the newly patched DSDT.

I'm not sure which DSDT wins when you boot from USB with a DSDT in /Extra to a partition which also contains an /Extra/DSDT. Best not to test the ambiguity.

Most of the patches you're using are pretty normal, except the IRQ patch is a bit different. You might try my "IRQ Fix" from here: https://github.com/RehabMan/Laptop-DSDT-Patch. Other useful stuff there too...

There are also differences in methods GOPS and SOPS... maybe this is a diff in the native DSDT.

It could be floating regions or it could be that you made a material change to your BIOS options which caused a change in the native DSDT. Whenever you do that, you must re-extract and re-patch...

I just realized I accidentally said tables instead of regions, my ignorance is showing.

I'll check out your IRQ fix and the rest of the stuff in that link. Thanks again for all your help.

Also, I think GOPS and SOPS were the methods producing compile errors in the unpatched DSDT. I read somewhere (can't remember where) to change it to what's in the patched DSDT. I'm not sure what either of those methods do though...

One last question: I plan on changing my graphics to the 6870M in the bios when I want to boot into windows and back to the HD3000 when I want OS X. Will doing that cause problems again?

 

[RehabMan]

...
Also, I think GOPS and SOPS were the methods producing compile errors in the unpatched DSDT. I read somewhere (can't remember where) to change it to what's in the patched DSDT. I'm not sure what either of those methods do though...

It is unlikely the method are being called when running OS X anyway... If you found an SSDT that defined HDSE, you could better determine how the code is supposed to read (using iasl -da *.aml).

One last question: I plan on changing my graphics to the 6870M in the bios when I want to boot into windows and back to the HD3000 when I want OS X. Will doing that cause problems again?

Unless doing so causes regions to move, should not be a problem. You should test specifically for that.

Is your system dual-GPU switched (eg. both available to Windows, but sharing output ports), or is it dual-GPU with each GPU having dedicated ports, or mutually exclusive with each other?