Dell XPS 1340 mostly working with OSX 10.5.6,10.5.7

[Gambit642]

Is there a way to determine the exact kext that a piece of hardware is using?

 

I want to know exactly which kext file the SATA controller is using. Its not AppleNForceATA.kext cause the system works even when you don't install this, unload it or just remove it. One thing is for sure though, the XxX 10.5.6 distro is using a driver that iDeneb 10.5.6 isn't. I wan't to get iDeneb installing to rule it the battery issue as a distro specific bug.

 

On windows you can go to the device manager and find a piece of hardware and the *.dll's and *.ini's which the OS is using to talk to that device. Is there a way to do this on OS X?

[pmcnano]

Open system profiler and check loaded kexts?

[Gambit642]

Open system profiler and check loaded kexts?

Well, Extensions gives you a complete list of every loaded driver, and Serial-ATA tells you what the device is called, but not what Driver is being used.

 

I found the driver through other means:

Our MCP79 AHCI SATA controller is being resolved with:

AppleAHCIPort.kext v1.5.2

 

I have confirmed that the iDeneb v1.4 distro is using the same version (Minor difference in file Size but has entries for the MCP79 Chipset). So the panic isn't being caused by a lack of SATA Controller support. Most likely, an unnecessary kext is being loaded which our hardware doesn't like.

[pmcnano]

Panic? what panic? lol....Im using retail 10.5.6 disc, few other kexts......i mean, all the hardware is almost like a MBP, why would you need something moded else for audio?.....

 

Cheers

[Gambit642]

Panic? what panic? lol....Im using retail 10.5.6 disc, few other kexts......i mean, all the hardware is almost like a MBP, why would you need something moded else for audio?.....

 

Cheers

You aren't using XxX 10.5.6 distro that bcc9 recommended? What method did you use to boot the retail DVD on a non-mac?

[pmcnano]

Well, for starting you could make a Boot 132 disk, but well lol i have the advantage of having OSX installed in my desktop, so I just plug the hdd in my desktop open the instalation via terminal (open /Volumes/Theinstalationdisk/System/Installation/Packages/OSInstall.mpkg).......finish install, install chameleon...put extra kexts you want..and you are done!..... =)

 

The method would be similar using a Boot 132 disk, just insert boot 132 disk, insert retail boot, install boot with 132 disk, install chameleon and needed kexts..and you are done!....Anyway:

 

bcc9, still a mistery why some people have trackpad working after sleep..not fair..meh..

 

edit:

 

btw i have been working a little bit in the video card thing.......I got the name and everything injected..but the problem is injecting the displays..thats when it fails......There should be some strings that i need to make them work...

[Cheesy]

Hi guys,

 

I was able to boot iDeneb 10.5.6 on the Studio 13 and I have the same problem with the AppleACPIEC.kext driver, it just quits after a minute or so. We have the same behavior as with XxX, no battery info.

 

It seems the AppleACPIEC.kext problem is common to a few distros. One thing I noticed (and i would like to know if you get the same behavior) is when I close the lid, AppleACPIEC.kext is unloaded right away. Without closing the lid, it stays loaded for about a minute.

 

 

Regards !

[jake123]

So... I get my 1340 tomorrow.... Does anyone have an update on the built-in microphone, sleep, battery meter, sleep, and Truemobile 1515 wifi card?

 

Thanks!

[pmcnano]

Sleep works fine..battery metter nothing, mic nothing, 1515 wifi nothing QQ haha

[bcc9]

You can boot OS X with the boot flag

debug=0x02

And during verbose boot you can quickly see a reference that the ACPI Service has failed which didn't show in just verbose

What message are you referring to; anything that sheds any light on the problem? I suspect you're just referring to the AppleIntelCPUPowerManagement timeout message, which I don't think alludes to anything about the ACPI controller kext.

You can also run kextload with a "-v [0-6]" (i think -v) to see all the linking and dialogs which occur when ACPIEC.kext is loaded, but it doesn't echo out anything out when it finally unloads.

So like:

kextload -v 3 AppleACPIEC.kext

Yes you can get a bunch of verbose output with -v but, again, anything that sheds any light on the problem? One could step thru the kext with a remote debugger and also disassemble it, but any such reverse engineering would be a lot easier with a laptop that has working ACPI events to compare against.

 

Is there a way to determine the exact kext that a piece of hardware is using?

 

I want to know exactly which kext file the SATA controller is using. Its not AppleNForceATA.kext cause the system works even when you don't install this, unload it or just remove it. One thing is for sure though, the XxX 10.5.6 distro is using a driver that iDeneb 10.5.6 isn't. I wan't to get iDeneb installing to rule it the battery issue as a distro specific bug.

I don't have an exact recipe for that. kextstat will show you what modules are loaded so you can start narrowing things down from that. After that, the ioregistry tells the story; the drivers leave breadcrumbs there, often reporting the PCI match that was used to cause the driver to load . You can see reference to AppleMCP79AHCIPort for the SATA devices in the ioregisty, and the only kext which defines that is AppleAHCIPort.kext. So that's a big hint that AppleAHCIPort.kext is necessary for this chipset's sata to work.

 

You can often just search the kext's Info.plist to find the PCI match string for the device you're looking for.

That matching is documented in apple's developer docs, go read those for more details.

[bcc9]

Another thing, isn't thepress of the Power Button an ACPI event? When you tap the power button, OS X prompts if you want to shut down, restart or sleep.

Good point. Notice that the power button method defined in the dsdt doesn't depend upon the ACPI controller state, unlike the LID and battery methods:

		 Device (PWRB)
	 {
		 Name (_HID, EisaId ("PNP0C0C"))
		 Method (_STA, 0, NotSerialized)
		 {
			 Return (0x0B)
		 }
	 }

[Gambit642]

Good point. Notice that the power button method defined in the dsdt doesn't depend upon the ACPI controller state, unlike the LID and battery methods:

		 Device (PWRB)
				 {
					 Name (_HID, EisaId ("PNP0C0C"))
					 Method (_STA, 0, NotSerialized)
					 {
						 Return (0x0B)
					 }
				 }

Well, I am going to dig way back to a reference that pmcnano made about the purpose of AppleACPIEC.kext on a non-genuine mac. I believe he said (as a proxy; of hopefully someone credible) that it handled ACPI events for genuine hardware. Now, with the exception of Voodoo battery...I believe that many of the general battery related fixes were actually work arounds to the failing of Apple's vanilla ACPI controller on different hardware.

 

Im not certain on this but I believe the resolution for most was to provide a non-vanilla ACPI controller for battery events.

 

Such as:

AppleACPIPowerSource.kext (as a plugin to the vanilla AppleACPIPlatform.kext)

Or:

AppleSmartBattery.kext (stand-alone driver) for which the source is available here:

http://www.insanelymac.com/forum/index.php?showtopic=80425

In his distro notes he mentions that the pmconfigd source is what is responsible for detecting batteries and setting related values which will be used by others apps. My C++ skill is minimal...so I am not making any promises.

 

I don't think the service failure of the vanilla AppleACPIPlatform.kext is uncommon or specific to our model. However, even these generic fixes seem to have trouble identifying ACPI directly on our hardware. There are other hardware configurations in that forum which, like us, still don't have a working solution.

 

My thoughts for a penny? (Although they are not worth that much)

 

Any arguments (...bcc9 )?

[bcc9]

Well, I am going to dig way back to a reference that pmcnano made about the purpose of AppleACPIEC.kext on a non-genuine mac. I believe he said (as a proxy; of hopefully someone credible) that it handled ACPI events for genuine hardware. Now, with the exception of Voodoo battery...I believe that many of the general battery related fixes were actually work arounds to the failing of Apple's vanilla ACPI controller on different hardware.

Congrats you caught him in a misstatement.

So the controller handles access to ACPI memory. Those ACPI devices whose state is determined via I/O thru that memory aren't working.

 

Im not certain on this but I believe the resolution for most was to provide a non-vanilla ACPI controller for battery events.

 

The xps1340 is special in that it's ACPI controller *should* be able to work with the stock apple drivers as the hardware is the same as the unibody macbook.

 

AppleSmartBattery doesn't sound too promising as the hardware for this system is a control method battery not a smart battery. Unless someone wrote code to make a control method battery look like a smart battery. Worth taking a look.

[Gambit642]

The xps1340 is special in that it's ACPI controller *should* be able to work with the stock apple drivers as the hardware is the same as the unibody macbook.

Isn't I/O ultimately up to firmware, not the controller?

I would suspect that it is the same reason that our mobo's BIOS won't accept quad-core processors, even though the i670 (or whatever it is) chipset can.

 

I assumed it was those differences which was causing the ACPIEventController not to register itself.

[pmcnano]

I never said (well i dont recall it?).....that AppleACPIEC.kext was only used on genuine macs, I said i read somewhere that deleting that file made its laptop battery recognized, though not sure why.

 

In the other hand, chatting with the author of the mini9's dsdt battery modifications......Deleting the file from his laptop will result on the battery not being detected, also....the dsdt modification for the mini has nothing to do with our laptop.

[jake123]

So... I got my 1340 today, and I have to say... I thought the m1330 was a rip off of the macbook pro... this one is even more of a copy (minus the aluminum). The glass over the screen I think is 1000x better than the plastic.

 

Anyways onto 1340 with osx.

 

I've gotten everything to work in OS X that you guys have, except for my ethernet and wifi.

 

Because we can't use the 1515 yet, I put in a 1395 in the WWAN slot. I made sure it was enabled in the bios... yet its still not being found by os x (windows found it though). Also, when i first installed os x the builtin ethernet worked perfect. Now, everytime I reboot it detects a new ethernet, with the same Mac ID... thus making Ethernet 1-Ethernet 20. Since it started making new ethernets, I haven't been able to get online. It just says "self obtained ip address" for the latest ethernet (ie 20)... and the rest remain not connected.

 

 

Truemobile 1395 support can be found here: http://www.insanelymac.com/forum/index.php?showtopic=51725

p.s. did anyone else's touchpads come "sticky", is yours still sticky?

 

 

 

Any help would be great. Thanks!

[bcc9]

Isn't I/O ultimately up to firmware, not the controller?

I wouldn't say that. The DSDT table in bios defines the method for I/O to the control method battery. The CPU accesses the hardware register(s), thru the AML interpreter. The hardware registers, in the case of this laptop's battery, is in the ACPI controller's address space. Thus failure to initialize the ACPI controller means failure to access the battery status. Period. I'm not guessing here - this is per the ACPI spec.

[jake123]

Can anyone help me with my sleep? I've done everything listed in the first post of this thread. Currently, when I shut my lid, the keyboard LED's and screen turn off... when i open the lid, the screen and keyboard lights INSTANTLY turn on (the computer meanwhile remains on the whole time).

When I hit "sleep", the computer will completely go to sleep. When its time to resume, it will reach a black screen. I can shut the screen and it will go back to sleep. Opening the lid will have it "power on" to a black screen (not hitting POST..)

 

Thanks!

[bcc9]

Can anyone help me with my sleep? I've done everything listed in the first post of this thread. Currently, when I shut my lid, the keyboard LED's and screen turn off... when i open the lid, the screen and keyboard lights INSTANTLY turn on (the computer meanwhile remains on the whole time).

When I hit "sleep", the computer will completely go to sleep. When its time to resume, it will reach a black screen. I can shut the screen and it will go back to sleep. Opening the lid will have it "power on" to a black screen (not hitting POST..)

 

Thanks!

 

The OS is deaf to lid events because of the problems we're having with the ACPI controller.

To resume from sleep you need to hit the power button.

 

p.s. did anyone else's touchpads come "sticky", is yours still sticky?

As if the factory diags were done while the tech was eating his lunch? Ew, no.

[jake123]

The OS is deaf to lid events because of the problems we're having with the ACPI controller.

To resume from sleep you need to hit the power button.

 

As if the factory diags were done while the tech was eating his lunch? Ew, no.

 

When I hit the power button all the lights go on, but it goes to a black screen....

[bcc9]

When I hit the power button all the lights go on, but it goes to a black screen....

I don't have that problem. You could roll back your changes 1 by 1 to figure out what is causing the resume issue.

[Visthetic]

In response to your sticky keys, I think you gotta modify the VoodooPS2 settings on your system preferences pane.

 

I had that problem and messed around with that configuration and the Trackpad preferences to finally get a decent configuration that worked normally.

 

On another note, replaced my 1515 wireless with the 1510 and it works beautifully!

[JC13]

does anyone have any problems with powering off? After installing VoodooPower, my 1340 doesn't seem to power off properly. The screen shuts off, but the keys are still lit. I have to hold down the power button to force it to shut down. Anyone?

[jake123]

So now it sleeps but then instantly wakes up with a dead mouse Can you refer me to which kext to use? ApplePS2Controller?

 

does anyone have any problems with powering off? After installing VoodooPower, my 1340 doesn't seem to power off properly. The screen shuts off, but the keys are still lit. I have to hold down the power button to force it to shut down. Anyone?

 

Ugh, now this is happening to me... After doing what was mentioned on the first post and nothing else.

[Gambit642]

wtf?....mh im using the same......same goes for bcc9 afaik, and it doesnt work correctly after sleep =(

Okay, I have been able to duplicate my scenario. I can't explain why this works but I think it has to do with the order the kext are being loaded.

 

-After a fresh install (havn't been able to fix PS2 after sleep after it breaks without reinstalling)

-Install VoodooPS2 using their package and also selecting the trackpad install

-Delete AppleACPIPS2nub.txt only, NOT ApplePS2Controller.kext (removing both will break working PS2 after sleep)

-Yes keeping ApplePS2Controller.kext will cause a warning in verbose startup

-Wipe out the extensions cache, and restart

 

I have done this several times with success. PS2 keyboard and trackpad will work after sleep.

In this configuration, the Vanilla and Voodoo kexts are conflicting, but In a way that offer Voodoo functionality and working post sleep.

 

-Once you remove the Vanilla ApplePS2Controller.kext, it breaks the working sleep return. Unfortunately, even replacing the original ApplePS2controller and removing the Voodoo will not resolve the issue. It stays broke...I am assuming that the installer is doing something else besides just dropping VoodooPS2Controller.kext.

 

Edit: I had it working and then went through with OS X updates and the rest of the driver updates and it stopped again. So, its easily broken.