[GUIDE] Making a DSDT.aml for Dell XPS M1330, XPS M1530, and XPS M1730

[danofun]

fusion71au, you're on a roll!  keep up the great work!

 

I've successfully installed 10.10 public beta on my m1530 following fusion71au's chameleon guide a couple of pages ago.  Almost everything is working, including Slice's latest version of FakeSMC, but I am having issues with my networking.  Any help would be greatly appreciated.

 

1.)  My ethernet card is working properly but the MAC address defaults to 00:11:22:33:44:55.  In previous OS X versions I've been manually entering the correct MAC address by hex editing /System/Library/Extensions/IONetworkingFamily.kext/Contents/Plugins/AppleYukon2.kext/Contents/MacOS/AppleYukon2.  Is there a known solution for either Mavericks or Yosemite Public Beta?

 

2.)  My Dell TrueMobile 1505 (BCM4321 pci 1434:4328) wifi is not working correctly (bluetooth seems to be functional) in Yosemite Public Beta and has worked OOB for the past few iterations of OS X.  AppleAirportBrcm43224 is loading, the card is identified as a Third Party Wireless Card (en1), yet it is unable to find any wireless networks.  It is in a constant state of "Looking for Networks" and manually joining a wireless network does not work.  Any guidance would be greatly appreciated!

[fusion71au]

Hi @danofun,

 

TBH, since I've never used the ethernet cable on my machine (just my wireless USB), I've never bothered to patch my networking kexts.

 

If you intend to hex edit the IONetworkingFamily.kext in S/L/E, this will invalidate the kext's signature so you'll most likely need to use the boot flag kext-dev-mode=1 after repairing permissions (alternatively with Clover, you can inject it from EFI/Clover/Kexts/10.10).  Check that it is loading with the kextstat command

kextstat | grep IONetworking

Unfortunately I can't comment on the BCM4321 as I don't own one and haven't seen any reports about it in Yosemite.  Does it work when you disable wireless security settings on your router?

 

Maybe try rolling back kexts to 10.9.4 versions?  Also rebranding as an Airport Extreme by flashing the firmware or DSDT edit/FakeID in Clover might help?

 

Good Luck .

[danofun]

@fusion71au,

 

Thank you for your reply!  After successfully rebranding my wi-fi card as an Airport Extreme, I was still unable to find a wireless network.  However, rolling back to the 10.10 DP3 IO80211Family.kext has successfully allowed my wifi card to connect to wireless networks.  I've since upgraded to the 10.10 DP5 IO80211Family.kext which also works.  It seems the public beta of IO80211Family.kext has some issues with certain Broadcom cards.

 

EDIT:

In order to correct my network card's MAC address, I rolled back to the 10.7.4 AppleYukon2.kext (attached).  Then, hex edit /System/Library/Extensions/IONetworkingFamily.kext/Contents/Plugins/AppleYukon2.kext/Contents/MacOS/AppleYukon2 at offset 1A6F5 by changing the numbers in red to your ethernet cards MAC address.  

 

1A6F5 : C6 45 D2 00 C6 45 D3 11 C6 45 D4 22 C6 45 D5 33 C6 45 D6 44 C6 45 D7 55

 

Repair permissions, and reboot.  The boot flag kext-dev-mode=1 is not necessary for this particular modification.

AppleYukon2_10.7.4.zip

[lulighttec]

All my trackpad prefpane everything has now been solved (not that it was such a difficult problem before).  My bf bought me a Magic Trackpad for my birthday last week.  :-)

 

EDIT: I spoke too soon.  As soon as I got the magic trackpad connected, the Trackpad.prefpane stopped working.  I tried installing the native Trackpad.prefpane with pacifist, but still nothing.  An interesting prefpane has appeared in the prefpane folder called BluetoothTrackpad.prefpane.  Can't run it either.  Haven't figured this one out yet.

 

-L

[lulighttec]

@fusion71au,

 

Thank you for your reply!  After successfully rebranding my wi-fi card as an Airport Extreme, I was still unable to find a wireless network.  However, rolling back to the 10.10 DP3 IO80211Family.kext has successfully allowed my wifi card to connect to wireless networks.  I've since upgraded to the 10.10 DP5 IO80211Family.kext which also works.  It seems the public beta of IO80211Family.kext has some issues with certain Broadcom cards.

 

EDIT:

In order to correct my network card's MAC address, I rolled back to the 10.7.4 AppleYukon2.kext (attached).  Then, hex edit /System/Library/Extensions/IONetworkingFamily.kext/Contents/Plugins/AppleYukon2.kext/Contents/MacOS/AppleYukon2 at offset 1A6F5 by changing the numbers in red to your ethernet cards MAC address.  

 

1A6F5 : C6 45 D2 00 C6 45 D3 11 C6 45 D4 22 C6 45 D5 33 C6 45 D6 44 C6 45 D7 55

 

Repair permissions, and reboot.  The boot flag kext-dev-mode=1 is not necessary for this particular modification.

You know, I didn't really notice this until I upgraded to Yosemite yesterday, but I guess it must have been there since Mavericks.  I thought Clover might have been doing something to make this incorrectly report this erroneous MAC address for my Marvell Yukon ethernet, but this seemed to fix it.  Of course, after I applied this fix, I suddenly couldn't sign into the App Store, and iMessage continues to be broken.  Very curious indeed.  I also lost most of my magic trackpad gestures after upgrading to Yosemite.  I may just revert back to Mavericks.

 

Edit: I rolled back my IONetworkingFamily.kext and my AppleBluetoothMultitouch.kext & AppleMultitouchDriver.kext to Mavericks, and that took care of my trackpad gestures and fixed the problem of the App Store telling me I was on a different computer.  It naturally reset the en0 MAC address to 001122334455 again, which is frustrating to me, because I feel like that is going to be the case for all of us with XPS M1530 with the Marvell Yukon NIC, but I didn't know what else to do at the moment.  I didn't want to have to call Apple support and end up trying to explain why I was getting rejected from the same computer I've always used, but it looks like I'm going to have to call them anyway because of iMessage not letting me sign in.  However, my ROM that is injected by clover matches my actual MAC address, so I feel a little less uncomfortable calling them about that, and just pretending I'm not near my computer to give them the serial number...

 

Thoughts? Suggestions?

 

Edit 2:

 

I have been reading so much discussion on so many forums about the best way to fix the iMessage issue that my head is starting to hurt, and everything I'm reading is all starting to swim together in my brain.  I think I'm going to walk away for tonight, and try to think through it tomorrow.  

[DarwinX]

 

I have been reading so much discussion on so many forums about the best way to fix the iMessage issue that my head is starting to hurt, and everything I'm reading is all starting to swim together in my brain.  I think I'm going to walk away for tonight, and try to think through it tomorrow.  

 

 

For the last few days, I too have been having this iMessage error which prevents me from accessing the service. It is frustrating as I actively use that feature, and I'm not at all comfortable contacting the Apple support. Providing a valid Apple serial number in SMBios.plist produces the same result. Here is the actual error:

 

Your Apple ID "darwin@me.com" can't be used to set up iMessage at this time.

 

If this is a new Apple ID, you do not need to create another one. To use this Apple ID with iMessage, contact iMessage support with the code below.

 

Customer Code: 2004-0616-8723

[lulighttec]

For the last few days, I too have been having this iMessage error which prevents me from accessing the service. It is frustrating as I actively use that feature, and I'm not at all comfortable contacting the Apple support. Providing a valid Apple serial number in SMBios.plist produces the same result. Here is the actual error:

 

Your Apple ID "darwin@me.com" can't be used to set up iMessage at this time.

 

If this is a new Apple ID, you do not need to create another one. To use this Apple ID with iMessage, contact iMessage support with the code below.

 

Customer Code: 2004-0616-8723

Yes, this is the same error I'm getting.  I just didn't want to put my details up on the forum.  :-)  You might think about redacting a few of them, like the customer code.  From the reading I've been doing, it seems like this is a result of them getting ready for the Handoff feature.  Some say they have had success by spoofing a real mac, but others I've read seem to be fixing it without doing that.  If I read it correctly, that is the route I would like to go if possible.

[fusion71au]

Hi guys,

 

For those of you that are having problems with iMessage/Facetime, it is mainly because Apple have upgraded their security in preparation for Yosemite's "handoff" and "continuity" features.  They are actively checking for valid/registered serials so people using generated serials eg using chameleon wizard, clover configurator have been noticing problems esp the "contact Apple with customer code" error.

 

The only ways to solve this error are

1) To use genuine serials esp MLB & ROM from a Mac or Apple Support validated hack - see my pocedure in post #1747 using ElNono_'s imessage-debug tool

2) Actually call Apple Support and validate your current "fake" serials by providing them with the customer code displayed in the error.  Many people have found Apple Support to be very helpful and manage to talk their way into fixing the issue by providing a valid system serial - see Miztorr's guide.

 

If you don't have a real Mac handy or are reluctant to call Apple Support, then you can try @heryts serials in this post. 

The crucial values for validation are ROM & MLB (the other values like system serial, SmUUID/system-id can be kept unique for your own system).

 

MLB = 11111111111111111

ROM = 111111111111

 

or you can try

MLB = C02K7438DRVCN1S5A

ROM = 50465D3699A9 (this is UEZdNpmp if you convert to Base64)

 

He called Apple support and had the serials above "verified" - the only risk is that Apple may block them if too many people use them at the same time ....

[DarwinX]

Yes, this is the same error I'm getting.  I just didn't want to put my details up on the forum.  :-)  You might think about redacting a few of them, like the customer code.  From the reading I've been doing, it seems like this is a result of them getting ready for the Handoff feature.  Some say they have had success by spoofing a real mac, but others I've read seem to be fixing it without doing that.  If I read it correctly, that is the route I would like to go if possible.

 

It is redacted. The numeral and the e-mail address are not real. 

 

Hi guys,

 

For those of you that are having problems with iMessage/Facetime, it is mainly because Apple have upgraded their security in preparation for Yosemite's "handoff" and "continuity" features.  They are actively checking for valid/registered serials so people using generated serials eg using chameleon wizard, clover configurator have been noticing problems esp the "contact Apple with customer code" error.

 

The only ways to solve this error are

1) To use genuine serials esp MLB & ROM from a Mac or Apple Support validated hack - see my pocedure in post #1747 using ElNono_'s imessage-debug tool

2) Actually call Apple Support and validate your current "fake" serials by providing them with the customer code displayed in the error.  Many people have found Apple Support to be very helpful and manage to talk their way into fixing the issue by providing a valid system serial - see Miztorr's guide.

 

If you don't have a real Mac handy or are reluctant to call Apple Support, then you can try @heryts serials in this post. 

The crucial values for validation are ROM & MLB (the other values like system serial, SmUUID/system-id can be kept unique for your own system).

 

MLB = 11111111111111111

ROM = 111111111111

 

or you can try

MLB = C02K7438DRVCN1S5A

ROM = 50465D3699A9 (this is UEZdNpmp if you convert to Base64)

 

He called Apple support and had the serials above "verified" - the only risk is that Apple may block them if too many people use them at the same time ....

Inserting C02K7438DRVCN1S5A into the nvram fails to produce any positive result - the error persists. Perhaps, this serial number has already been blacklisted by Apple. I would call Apple support if I could gain access to a genuine Apple serial number which is still valid. Of course, if I did have a valid serial number, I probably wouldn't even need to make that call in the first place.

 

Here is the debug:

 

2014-09-01 11:34:48.537 imessage_debug[641:707] Gq3489ugfi: <98265e3c 73561569 45ca82e7 447a0468 c6>
2014-09-01 11:34:48.539 imessage_debug[641:707] Fyp98tpgj: <5a028469 a3e3f90e a7c45195 9822c324 df>
2014-09-01 11:34:48.539 imessage_debug[641:707] kbjfrfpoJU: <006360f1 6b29a2c2 e7b29271 89064aee 03>
2014-09-01 11:34:48.540 imessage_debug[641:707] IOPlatformSerialNumber: CK129U13DB67
2014-09-01 11:34:48.541 imessage_debug[641:707] IOPlatformUUID: 0B75EAD1-587B-5C43-B874-4F03BCB1B40C
2014-09-01 11:34:48.541 imessage_debug[641:707] board-id: Mac-F42D86C8
2014-09-01 11:34:48.542 imessage_debug[641:707] product-name: MacBookPro5,1
2014-09-01 11:34:48.542 imessage_debug[641:707] 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM: <50465d36 99a9>
2014-09-01 11:34:48.543 imessage_debug[641:707] 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB: C02K7438DRVCN1S5A

2014-09-01 11:34:48.543 imessage_debug[641:707] oycqAZloTNDm: <ad1b258b e95e4a25 51e38ac1 86a76e45 5e>
2014-09-01 11:34:48.544 imessage_debug[641:707] abKPld1EcMni: <39870046 0b688f8a 575f3da0 0b89da4f 0d>

It is time for me to get a real Mac….

[lulighttec]

I have access to a real mac, but my thing is, I hate having to depend on that.  I would much rather have my "own" serial number, MLB and ROM working to make my machine unique and "in the system".  I don't know.  I guess it's six of one and half a dozen of the other.  I borrowed the MLB and ROM from the other MBP in the house to get it working for now, and kept my previous serial number, Board serial, SmUUID and UUID and such, and it is working now.  I just don't know if it will cause problems in the future.  I even thought about getting an old logic board from eBay just to have, but there's no real way to get the ROM from that, because as far as I can see, it isn't printed anywhere.  

 

On another note, it's worth mentioning that from what I can see (I looked at lots and lots of pictures), before 2010, the MLB was only 13 digits long, not 17.  It seems to me that as long as the ROM matches the MLB (come from the same machine), the MLB could be either length and should work fine.

[fusion71au]

@DarwinX,

 

Try @heryts alternate set of serials

Re MLB = 11111111111111111

ROM = 111111111111

 

If you want to get hold of genuine serials, have a look at my post #105 in the AIO guides.  You can check a system serial is registered by entering it into the Apple self solve site ---> see its warranty status etc.

 

@Lulighttec,

 

As I said before, if you want to validate your "hackintosh" serials, you will need to contact Apple Support with that error code.  You are correct in that serial numbers from older machines were shorter -

• system serial used to be 11 characters long
• MLB used to be 13 characters long

The main thing is that MLB & ROM should come from the same Mac ....

[lulighttec]

Hi Guys,

 

Slice has just released the latest iteration of his FakeSMC 3.3.1 and hardware sensors compatible with OSX 10.6-10.10 and our machines.

 

All working well, choosing the below options to install FakeSMC, GeforceSensor, IntelCPUMonitor, PC8739x and HWInfo.kext....

Slice FakeSMC 3.3.1.png

S:L:E.png

The included NWMonitor now works reliably in Mavericks and Yosemite (hooray!)....

NWMonitor.png

however iStat Menus gives incorrect frequency readings (like previously with sensors from Slice's FakeSMC branch)....

iStat Menus.png

 

@fusion71au - I very carefully removed my old FakeSMC and its accoutrements, and followed your instructions to install this, and this is all I get:

 

That, and my bluetooth started actin' funny after I installed this...

[lulighttec]

I'll add to that, I can't get my ACPIBatteryManager.kext to work right either.  I've made sure AppleSmartBatteryManager.kext is disabled (renamed the extension), and I tried doing the reverse as well... neither kext works right.  It's like it only detects the initial state of the battery percentage on boot and never changes from that, and it can't detect whether the power adapter is connected or not, or if the battery is charging.  AppleSmartBatteryManager doesn't do any better, with the added issue of refusing to display in the menu bar (keeps unchecking itself).  I know between DarwinX and fusion71au this can be figured out.

[RehabMan]

I'll add to that, I can't get my ACPIBatteryManager.kext to work right either.  I've made sure AppleSmartBatteryManager.kext is disabled (renamed the extension), and I tried doing the reverse as well... neither kext works right.  It's like it only detects the initial state of the battery percentage on boot and never changes from that, and it can't detect whether the power adapter is connected or not, or if the battery is charging.  AppleSmartBatteryManager doesn't do any better, with the added issue of refusing to display in the menu bar (keeps unchecking itself).  I know between DarwinX and fusion71au this can be figured out.

Likely a DSDT issue. Use the debug version of ACPIBatteryManager.kext and analyse logs from it in system.log.

[fusion71au]

@fusion71au - I very carefully removed my old FakeSMC and its accoutrements, and followed your instructions to install this, and this is all I get:

 

That, and my bluetooth started actin' funny after I installed this...

 

Check that FakeSMC and the monitor kexts are being loaded eg kextstat | grep -v com.apple will list all third party (non Apple) kexts loaded on your system...

XXXXX-MacBook-Pro:~ XXXXX$ kextstat | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) <Linked Against>
   14    4 0xffffff7f811b8000 0xb000     0xb000     org.netkas.FakeSMC (3.3.1) <11 7 5 4 3>
   15    0 0xffffff7f81f28000 0xd000     0xd000     org.kozlek.GeforceSensor (1.0.2d1) <14 12 7 5 4 3>
   16    0 0xffffff7f811c5000 0x2000     0x2000     org.slice.PC8739x (1) <14 7 5 4 3>
   21    0 0xffffff7f81dfc000 0x6000     0x6000     org.slice.IntelCPUMonitor (1.1) <14 7 5 4 3>
   22    0 0xffffff7f81e04000 0x3000     0x3000     org.slice.HWInfo (1) <14 7 4 3>
   34    0 0xffffff7f80f04000 0xb000     0xb000     org.voodoo.driver.PS2Controller (1.1.0) <11 7 5 4 3 1>
   42    0 0xffffff7f82441000 0x2000     0x2000     net.osrom.kext.Disabler (1.0.1) <4 3>
   53    0 0xffffff7f80ef6000 0x5000     0x5000     org.voodoo.driver.PS2Keyboard (1.1.0) <37 5 4 3>
   55    0 0xffffff7f80ee7000 0xf000     0xf000     org.voodoo.driver.PS2Trackpad (1.1.0) <37 5 4 3>
   93    0 0xffffff7f80fc8000 0x21000    0x21000    org.voodoo.driver.VoodooHDA (2.8.4) <92 12 7 5 4 3>
  100    0 0xffffff7f810c1000 0xc0000    0xc0000    com.realtek.driver.RTL8192SU (1079) <48 39 5 4 3 1>

If you don't see FakeSMC, GeforceSensor, PC8739x, IntelCPUMonitor, HWInfo in the loaded kexts list, make sure they are present in S/L/E and then try repairing permissions manually or with kext wizard.  Slice's first installer from that thread did not set permissions correctly in /S/L/E - he later revised the installer in post#27.

 

Re bluetooth and battery - I can't comment because I don't use the bluetooth function and my original battery has long given up the ghost (I currently only use AC power).  I'm pretty sure if you don't roll back AppleACPIPlatform.kext that you will need to make additional adjustments to your DSDT to make ACPIBatteryManager.kext work properly (as @Rehabman said).

[DarwinX]

@fusion71au - I very carefully removed my old FakeSMC and its accoutrements, and followed your instructions to install this, and this is all I get:

 

That, and my bluetooth started actin' funny after I installed this...

 

Perhaps, you neglected to place the FakeSMC hardware monitoring plugins within the appropriate /System/Library/Extensions/FakeSMC.kext/Contents/Plugins directory.

I'll add to that, I can't get my ACPIBatteryManager.kext to work right either.  I've made sure AppleSmartBatteryManager.kext is disabled (renamed the extension), and I tried doing the reverse as well... neither kext works right.  It's like it only detects the initial state of the battery percentage on boot and never changes from that, and it can't detect whether the power adapter is connected or not, or if the battery is charging.  AppleSmartBatteryManager doesn't do any better, with the added issue of refusing to display in the menu bar (keeps unchecking itself).  I know between DarwinX and fusion71au this can be figured out.

 

Do try the following ACPIBatteryManager version 1.52. It is fully viable on my rig under both the OS 10.8.5 and 10.9.4.

 

ACPIBatteryManager.kext-v1.52.zip

[lulighttec]

Perhaps, you neglected to place the FakeSMC hardware monitoring plugins within the appropriate /System/Library/Extensions/FakeSMC.kext/Contents/Plugins directory.

According to Slice (and his installer) those kexts no longer belong in that directory. They should be installed into S/L/E. He mentions this when someone asked him the same question in the thread that fusion71au posted. I did try repairing the permissions, and I tried using his updated installer that is supposed to have fixed the permissions, but neither of those solutions worked. FakeSMC loads, but the other kexts aren't loading. I suppose it wouldn't hurt to try it and report back; it's not like I'm going to break anything that is already working. :-)

 

Do try the following ACPIBatteryManager version 1.52. It is fully viable on my rig under both the OS 10.8.5 and 10.9.4.

 

ACPIBatteryManager.kext-v1.52.zip

Thanks for this suggestion; I did try it, but it isn't working either. I think somewhere along the line the AppleACPIPlatform.kext was updated, and it never occurred to me to roll it back because I just don't remember seeing it mentioned in anyone's Yosemite installs... could be my faulty [human] memory though. In any case, I'm not sure where to get a rollback version of it; I don't think I have 10.8 anywhere readily accessible.

[lulighttec]

So I figured out what was going on with the sensors for Slice's new FakeSMC. I was trying to search for logs from the debug version of ACPIBatteryManager, and realized that it wasn't loading the kext because it wasn't signed, which of course made me realize that it wasn't loading any of the unsigned kexts.  The obvious solution was to change my clover configuration to include Kext dev mode=1.  I'm not sure how that changed; I had it set once before.  Anyway, once I did that, of course all the sensor kexts loaded right up and filled up my HWMonitor with info.  
 
That being said, once I did this, ACPIBatteryManager.kext also loaded, but is still not working right, and doesn't really seem to be logging anything as such.  I have noticed that when I try to tick the box for "Show battery status in menu bar", besides it quickly un-ticking itself, it also leaves a message in the log that looks like this:
 

2:42:47 PM systemUIServer: Menu Extra: <BatteryExtra: 0x7f9d29c80b00> is over retained.

Soon after that appears, it is followed by a whole string of logs, which look like this:
 

9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::pollingTimeOut called
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBatteryManager::getBatterySTA called
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBatteryManager::getBatteryBIF: validateObject return 0x0
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fPowerUnit       = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fDesignCapacity  = 0x1450
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fMaxCapacity     = 0xe1b
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fBatteryTech     = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fDesignVoltage   = 0x2b5c
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fCapacityWarning = 0x208
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fLowWarning      = 0x9d
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fDeviceName      = 'DELL RN8878'
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fSerialNumber    = '774'
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fType            = 'LION'
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBIF: fManufacturer    = ''
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBatteryManager::getBatteryBST called
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit       = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus    = 0x0
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x1450
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x30b3
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x1
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery: Battery is charged.
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
9/3/14 2:42:50.000 PM kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called

So, I'm not sure what all that means, but the larger second bit of log happens fairly regularly, every minute or so, so I imagine that is the system polling the battery for status.  Interesting thing to note, when I unplug the power adapter, the log doesn't change at all, but if it is in fact what I suspect it to be, I would think it would [change].

 

@Rehabman - I looked at your post about patching the DSDT for the newer ACPIPlatformManager; my DSDT doesn't contain "EmbeddedControl".  Anywhere.  I was at a loss after discovering that.  I'm using the same DSDT that DarwinX and others have posted here most recently to use with Cloverboot and Yosemite with our machines.  I included a copy just for kicks.

 

DSDT copy.zip

[RehabMan]

...

@Rehabman - I looked at your post about patching the DSDT for the newer ACPIPlatformManager; my DSDT doesn't contain "EmbeddedControl".  Anywhere.  I was at a loss after discovering that.  I'm using the same DSDT that DarwinX and others have posted here most recently to use with Cloverboot and Yosemite with our machines.  I included a copy just for kicks.

...

Without any EmbeddedControl regions, there is no need to patch any multi-byte EC fields. Although other DSDT problems can still have an effect. For example, your DSDT has Mutex objects with non-zero SyncLevel (there is a patch for this in my repo). There could be other patches you might need...

[lulighttec]

 

 

Without any EmbeddedControl regions, there is no need to patch any multi-byte EC fields. Although other DSDT problems can still have an effect. For example, your DSDT has Mutex objects with non-zero SyncLevel (there is a patch for this in my repo). There could be other patches you might need...

 

Not being a programmer, I would not have picked up on that as you did, and I wouldn't know how to begin looking for anything else that might need patching.  I'm happy to apply patches I might need, however.  I'll see if I can find the patch you're referring to...

[RehabMan]

Not being a programmer, I would not have picked up on that as you did, and I wouldn't know how to begin looking for anything else that might need patching.  I'm happy to apply patches I might need, however.  I'll see if I can find the patch you're referring to...

https://github.com/RehabMan/Laptop-DSDT-Patch

"Fix Mutex with non-zero SyncLevel"

 

Also might be interesting for you...

"Fix _WAK Arg0 v2"

"IRQ Fix"

 

Also the OSID method in your DSDT needs work (it has no case for _OSI("Darwin")).

[lulighttec]

https://github.com/RehabMan/Laptop-DSDT-Patch

"Fix Mutex with non-zero SyncLevel"

 

Also might be interesting for you...

"Fix _WAK Arg0 v2"

"IRQ Fix"

 

Also the OSID method in your DSDT needs work (it has no case for _OSI("Darwin")).

For that last bit... do you mean it needs something like:

                If (_OSI ("Darwin"))
                {
                    Store (0x30, MIS3)
                }

inserted into that larger conditional statement?  Not a coder, but recognize some things...

[lulighttec]

@RehabMan - So I tried the patches you suggested, with the exception of the OSID method edit (because I hadn't heard back from you yet), and it hasn't made any difference in the battery indicator.  It still polls on the first boot, and then whatever it reads then is what it shows until the next boot.  I am, however, excited to see if it will make a difference with the sleep problem I've been having!  I will have to test it out.

 

 

EDIT:  So, I tried putting the machine to sleep, and it went to sleep.... and then it woke up when I opened the lid!!!  I thought I'd try it again just to be sure, so I put it to sleep again... and this time, it rebooted.  :-/  Oh well.  However, no CMOS reset that I could tell.

 

 

EDIT:  I forgot to mention that the "show battery status in menu bar" no longer un-ticks itself; it now actually shows in the menu bar.  It's just that it never changes.  It never realizes that I've unplugged the power adapter, the percentage never changes, etc.  I've been watching the log messages, and every second, this is what I see:

9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::pollingTimeOut called
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::pollBatteryState: path = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBatteryManager::getBatterySTA called
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatterySTA: battery_status = 0x1f
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBatteryManager::getBatteryBIF called
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBatteryManager::getBatteryBIF: validateObject return 0x0
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: acpibat_bif size = 13
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fPowerUnit       = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fDesignCapacity  = 0x1450
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fMaxCapacity     = 0xea6
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fBatteryTech     = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fDesignVoltage   = 0x2b5c
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fCapacityWarning = 0x208
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fLowWarning      = 0x9d
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fDeviceName      = 'DELL RN8878'
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fSerialNumber    = '774'
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fType            = 'LION'
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBIF: fManufacturer    = ''
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBatteryManager::getBatteryBST called
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: acpibat_bst size = 4
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: fPowerUnit       = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus    = 0x0
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x1450
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x30a7
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::setBatteryBST: fAverageRate = 0x1
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery: Battery is charged.
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::constructAppleSerialNumber called
9/4/14 12:18:33.000 AM kernel[0]: AppleSmartBattery::rebuildLegacyIOBatteryInfo called

What do you make of that?  It keeps displaying the same values regardless of the status of the power adapter or the actual battery charge, etc.

[fusion71au]

https://github.com/RehabMan/Laptop-DSDT-Patch

"Fix Mutex with non-zero SyncLevel"

 

Also might be interesting for you...

"Fix _WAK Arg0 v2"

"IRQ Fix"

 

Also the OSID method in your DSDT needs work (it has no case for _OSI("Darwin")).

@Rehabman,

 

The Fix _WAK Arg0 v2 and IRQ Fix are very interesting .

 

Most of the XPS m1530 owners in this thread have successfully used immo/DarwinX's DSDT from the first post in this thread for multiple iterations of OSX from SL--->Yosemite. 

 

More recently for Mavericks 10.9.0-10.9.1, a regressed AppleACPIPlatform.kext was required for fully functional sleep but unfortunately the kext is incompatible with 10.9.2+ or Yosemite.

 

With the native AppleACPIPlatform.kext, the first sleep-wake cycle works perfectly but on invoking sleep a second time (through the Apple menu or by closing the lid), the machine reboots...

 

I successfully applied the above WAK and IRQ fixes to my DSDT with MaciASL but unfortunately the reboot on second sleep still occurs (like described by @lulighttec above) .  Any thoughts or experience with this weird phenomenon and what might be causing it?

 

@lulighttec,

Sorry for "hijacking" your battery discussion with Rehabman .

[lulighttec]

@fusion71au - No worries man!  Isn't that what these threads are for?  So other people can join the discussion?  Provide input and insight?  Or, not?  :-)  It's all good to me.  Now, maybe you can tell me if I was right about fixing the OSID method...