Dell XPS 1340 under OSX 10.6, including boot-132 install cd

[bcc9]

Well I dont know whats up inmy system, but If I sleep the first time on AC wake up and unplug I can sleep over and over again!

So after you switch to battery the "FireWire GUID 0000000000000000 is invalid!" log messages stop appearing?

[pmcnano]

Nah, the message is still there, but just to make a note, I can sleep also with your dsdt (while on AC). I mean, my firewirefix has nothing to do.

[bcc9]

Nah, the message is still there, but just to make a note, I can sleep also with your dsdt (while on AC). I mean, my firewirefix has nothing to do.

I thought the point was *auto* sleep. OSX won't auto sleep when /var/log/kernel is logging new errors every 30 seconds. Doesn't matter the state of the power cable.

[bcc9]

Ok, I've figured out a way to get the GUID errors to clear after resume, without just getting rid of AppleFWOHCI.

As I noted in post #1, the old workaround in 10.5.x of unloading/reloading AppleFWOHCI.kext was problematic as the kext doesn't unload fully.

However I've found that it still does uninitialize things sufficiently so that the next kextload picks up the GUID as per normal, thus clearing the error situation.

 

Time to reinstall sleepwatcher

[bcc9]

However I've found that it still does uninitialize things sufficiently so that the next kextload picks up the GUID as per normal, thus clearing the error situation.

 

Time to reinstall sleepwatcher

Hold that thought - each incomplete kextunload leaks a driver instance, thus leaking memory as can be seen with ioalloccount.

[mikeraffone]

Hi,

 

I've been running an SL vanilla on my XPS 1340 for quite some time now, thanks largely to the efforts of those people on this forum (bcc9 and pmcnano and others) - so cheers!

 

I have a question:

 

I'm migrating my system over to another XPS 1340, the only difference is instead of the nvidia geforce 9400m, i have the NVIDIA GeForce 210M 512MB

 

do you know if your DSDT will get QE/CI working on this graphics card, and if not, how do I go about modifying it, so it will?

 

_Mike

[olegpronin]

Hi,

 

I've been running an SL vanilla on my XPS 1340 for quite some time now, thanks largely to the efforts of those people on this forum (bcc9 and pmcnano and others) - so cheers!

 

I have a question:

 

I'm migrating my system over to another XPS 1340, the only difference is instead of the nvidia geforce 9400m, i have the NVIDIA GeForce 210M 512MB

 

do you know if your DSDT will get QE/CI working on this graphics card, and if not, how do I go about modifying it, so it will?

 

_Mike

 

I think you'll only need to change 256 to 512 and write other name for nvidia card (in dsdt)

[mikeraffone]

I think you'll only need to change 256 to 512 and write other name for nvidia card (in dsdt)

 

That's what I hoped, but bcc9's dsdt doesn't have an obvious place for that change, there is no "VRAM,totalsize" string to modify.

 

I have found this DSDT modification for the 210m, which I believe may work, I'm trying to bring them together, but having difficulty (i'm not awesome at this):

 

Device (PEGP)
[indent]			{
			Name (_ADR,  0x00010000)
			Device (GFX0)
			{
				Name  (_ADR, Zero)
				Name (_SUN, One)
				Method  (_DSM, 4, NotSerialized)
				{
					Store  (Package (0x18)
						{
							"@0,compatible",  
							Buffer (0x0B)
							{
								"NVDA,NVMac"
							},  

							"@0,device_type", 
							Buffer  (0x08)
							{
								"display"
							},  

							"@0,name", 
							Buffer  (0x0F)
							{
								"NVDA,Display-A"
							},  

							"@0,AAPL,boot-display", 
							Buffer  (0x04)
							{
								0x01,  0x00, 0x00, 0x00
							}, 

							"@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, 0x09, 0x00, 
								/*  0008 */	0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 
								/*  0010 */	0x00, 0x00, 0x00, 0x00
							},  

							"VRAM,totalsize", 
							Buffer  (0x04)
							{
								0x00,  0x00, 0x00, 0x20
							}, 

							"device_type",  
							Buffer (0x0D)
							{
								"NVDA,GeForce"
							},  

							"model", 
							Buffer  (0x13)
							{
								"NVIDIA  GeForce 210"
							}, 

							"rom-revision",  
							Buffer (0x0F)
							{
								"70.18.2D.00.A3"
							}
						},  Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf  (Local0))
					Return (Local0)
				}
			}

[/indent]

[bcc9]

For QE/CI with the 9400/9500, the EFI string didn't need to include the vram size; it gets automatically picked up by the driver.

I suspect the answer is the same for the 210m but I don't have one to test with and haven't seen any reports here.

The video card model name should be cosmetic, so you can change it if you want or not.

[mikeraffone]

For QE/CI with the 9400/9500, the EFI string didn't need to include the vram size; it gets automatically picked up by the driver.

I suspect the answer is the same for the 210m but I don't have one to test with and haven't seen any reports here.

The video card model name should be cosmetic, so you can change it if you want or not.

 

Thanks, starting to get my head around this now.

 

The computer has both the onboard 9400m and the added g210m.

 

Apparently the g210m is supported via chameleon flagging graphicsenabler=yes (I'll confirm this later today, doing a clean reboot to test).

 

If it does work with graphicsenabler, running off the native support in osx for the device - do you think I'd be able to install the 9400m via the dsdt injector, and the g210m via the chameleon injector, at the same time - or would they clash?

[pmcnano]

It is most likely that you will have the same problem as us, so, forget about the 210m. You will only have 9400m! If I boot with the 9500gs I get kernel panic

[mikeraffone]

It is most likely that you will have the same problem as us, so, forget about the 210m. You will only have 9400m! If I boot with the 9500gs I get kernel panic

 

Do you think the kernel panic is because our standard installs of os x do not include the needed kexts to deal with switching between the onboard and the extra GPU?

 

Perhaps if we could work out a way to implement the parts of the Macbook Pro Software Update 1.3 - released 13 April 2010 (http://support.apple.com/kb/DL1026) that deal with the "automatic graphic switching" between the onboard 9400m and the GT330m on the late model macbook pros, then it wouldn't kernel panic?

 

Surely if it supports both devices natively, the problem is that they're clashing, even though perhaps they don't have to?

[mikeraffone]

For QE/CI with the 9400/9500, the EFI string didn't need to include the vram size; it gets automatically picked up by the driver.

I suspect the answer is the same for the 210m but I don't have one to test with and haven't seen any reports here.

The video card model name should be cosmetic, so you can change it if you want or not.

 

bcc9, you're probably going to hate this question, but where in your fixed.dsl file can i put a wireless injection?

 

I have an injection script for dell wireless 1520, which runs on broadcom 4353, but its too new to be picked up by os x automatically (device unknown).

 

Everywhere I try to put the inject code, a get a syntax compiler error...

 

This is the code I'm looking to insert:

Device (ARPT)
		{
			Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x12)
					{
						"AAPL,slot-name",
						Buffer (0x08)
						{
							"AirPort"
						},

						"device-id",
						Buffer (0x04)
						{
							0x53, 0x43, 0x00, 0x00
						},

						"vendor-id",
						Buffer (0x04)
						{
							0xE4, 0x14, 0x00, 0x00
						},

						"subsystem-id",
						Buffer (0x04)
						{
							0x87, 0x00, 0x00, 0x00
						},

						"subsytem-vendor-id",
						Buffer (0x04)
						{
							0x6B, 0x10, 0x00, 0x00
						},

						"name",
						Buffer (0x0D)
						{
							"pci14e4,4353"
						},

						"model",
						Buffer (0x13)
						{
							"Dell Wireless 1520"
						},

						"device_type",
						Buffer (0x08)
						{
							"Airport"
						},

						"built-in",
						Buffer (One)
						{
							0x00
						}
					}, Local0)
				DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				Return (Local0)
			}
		}

[bcc9]

bcc9, you're probably going to hate this question, but where in your fixed.dsl file can i put a wireless injection?

 

I have an injection script for dell wireless 1520, which runs on broadcom 4353, but its too new to be picked up by os x automatically (device unknown).

 

Everywhere I try to put the inject code, a get a syntax compiler error...

You would add the Device() entry as a child node of whatever PCI device the 1520 is attached to. Check your lspci info (-nnvt) to find out for sure where it attaches.

If it's like the 1515, I think that'd make it a child of the PCI bridge that the dsdt is calling the XVR2 device.

 

I doubt you need to add an EFI string to the DSDT just to match the 1520, you could probably just add the PCI id to the driver's info.plist.

 

Perhaps if we could work out a way to implement the parts of the Macbook Pro Software Update 1.3 - released 13 April 2010 (http://support.apple.com/kb/DL1026) that deal with the "automatic graphic switching" between the onboard 9400m and the GT330m on the late model macbook pros, then it wouldn't kernel panic?

 

Surely if it supports both devices natively, the problem is that they're clashing, even though perhaps they don't have to?

Regarding switching, see the earlier posts in this thread about gfxcardstatus. It does not look like anyone has put much effort into getting it to work on this system.

[pmcnano]

Tell me the vendor and device id of the broadcom card and I will upload you a dummy kext for you ^^!!

 

and about the dual graphics, I do think they are clashing, not sure what to do, I have done everything I can think!

[kelobb]

My 1520 doesn't work in my hackintosh - is there a conflict between bcc9 dsdt and 1520 and added id to info.plist kext (which one - Airport or Airport 43224)?

 

What do you think?

 

Regards

[bcc9]

My 1520 doesn't work in my hackintosh - is there a conflict between bcc9 dsdt and 1520 and added id to info.plist kext (which one - Airport or Airport 43224)?

 

What do you think?

 

Regards

I'd suspect there is probably a problem with your pci id matching. What does your matching xml look like? If the matching is working, then what error are you getting from the broadcom driver when it loads?

[mikeraffone]

I'd suspect there is probably a problem with your pci id matching. What does your matching xml look like? If the matching is working, then what error are you getting from the broadcom driver when it loads?

 

lspci finds the device as Broadcom unknown device (14a4:4353)

 

PCI\VEN_14E4&DEV_4353&SUBSYS_000E1028&REV_01

 

And 4353 should be recognised in the AppleAirportBrcm43224 kext - it exists in the plist without needing to be added.

 

There is some sort of problem where the computer does not recognise the device - even a dummy kext does not work.

 

What do you think we dell wiresless 1520 people can do about this, short of buying another card?

[bcc9]

lspci finds the device as Broadcom unknown device (14a4:4353)

 

PCI\VEN_14E4&DEV_4353&SUBSYS_000E1028&REV_01

 

And 4353 should be recognised in the AppleAirportBrcm43224 kext - it exists in the plist without needing to be added.

 

There is some sort of problem where the computer does not recognise the device - even a dummy kext does not work.

 

What do you think we dell wiresless 1520 people can do about this, short of buying another card?

So then is pci14e4,4353 showing up in your ioregistry?

(Still not enough info posted to know whether the iokit matching is working or not). If it isn't matching, proceed with troubleshooting that.

Assuming it is matching, what error does the driver report when you try to load it, when you have verbose debugging turned on?

If it really just auto-unloads silently even with all the driver debugging knobs turned on, then you could set up a remote gdb to see at what point it decides to unload.

 

These are some of the troubleshooting techniques I had to go through to get AppleACPIEC loaded&working properly for this laptop way back when.

[mikeraffone]

So then is pci14e4,4353 showing up in your ioregistry?

 

Here is the oireg entry for XVR4

 

	| |   |   +-o Z01N@0  <class IOPCIDevice, id 0x1000001be, registered, matched, active, busy 0 (16632 ms), retain 9>
| |   |	   {
| |   |		 "assigned-addresses" = <1000068200000000000040f00000000000400000>
| |   |		 "IOInterruptSpecifiers" = (<1700000007000000>,<0000000000000100>)
| |   |		 "class-code" = <00800200>
| |   |		 "IODeviceMemory" = (({"address"=0xfffffffff0400000,"length"=0x4000}))
| |   |		 "IOPowerManagement" = {"CurrentPowerState"=0x2}
| |   |		 "subsystem-vendor-id" = <28100000>
| |   |		 "built-in" = <00>
| |   |		 "acpi-device" = "IOACPIPlatformDevice is not serializable"
| |   |		 "IOInterruptControllers" = ("io-apic-0","IOPCIMessagedInterruptController")
| |   |		 "name" = "pci14e4,4353"
| |   |		 "IOChildIndex" = 0x1
| |   |		 "device-id" = <53430000>
| |   |		 "vendor-id" = <e4140000>
| |   |		 "IOPCIExpressASPMDefault" = 0x3
| |   |		 "acpi-pmcap-offset" = 0x40
| |   |		 "compatible" = <706369313032382c6500706369313465342c3433353300706369636c6173732c30323830303000>
| |   |		 "IOPCIResourced" = Yes
| |   |		 "IOPCIExpressLinkCapabilities" = 0x176c11
| |   |		 "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/XVR4@160000/Z01N@0"
| |   |		 "subsystem-id" = <0e000000>
| |   |		 "revision-id" = <01000000>
| |   |		 "IOPCIExpressLinkStatus" = 0x3011
| |   |		 "IOName" = "pci14e4,4353"
| |   |		 "acpi-wake-type" = 0x2
| |   |		 "reg" = <00000600000000000000000000000000000000001000060200000000000000000000000000400000>
| |   |	   }

 

The driver lists as being loaded ... or at least, the kextload command works successfully, and the driver reports itself in kextstat.

 

What do you think?

 

There isn't a child entry for the card itself, below that. Even though the kext has loaded. Strange.

[kelobb]

bcc9 - could you post some links for some informations about your debugging method? I'll try to find out why this hardware (1520) has its strange behaviour with Apple kext (where its pci id match).

 

Maybe some dsdt hacks could fix and emulate this board which is a kind new piece of hardware.

Thx

Regards

[bcc9]

bcc9 - could you post some links for some informations about your debugging method? I'll try to find out why this hardware (1520) has its strange behaviour with Apple kext (where its pci id match).

 

Maybe some dsdt hacks could fix and emulate this board which is a kind new piece of hardware.

Thx

Regards

Some background reading (these are in the MacOSX docs online at developer.apple.com):

I/O Kit Fundamentals (especially the section about debugging a driver with gdb, even though the documentation pre-dates the 10.6 kextutil command)

http://developer.apple.com/mac/library/doc...undamentals.pdf

Kernel Extension Programming Topics

http://developer.apple.com/mac/library/doc...KEXTConcept.pdf

Writing PCI Drivers

http://developer.apple.com/mac/library/doc...gPCIDrivers.pdf

 

The driver lists as being loaded ... or at least, the kextload command works successfully, and the driver reports itself in kextstat.

If the broadcom driver is not *AUTO* loading, then there is a problem. I still haven't heard whether it is auto loading or only loading when you do so manually.

Looks to me like the driver should match the ioregistry entry you quoted. But if it was loading successfully I'd expect to see a child entry. Since you say you don't see such an entry, I assume it's not loading successfully and there is an error to be seen if you would just turn on enough debugging. Perhaps some IOkit debugging would be in order (io=xxx) in your com.apple.Boot.plist.

[rs710i]

Thanks bcc9, your guides have truly been a lifesaver for me with installing Mac. I've worked from your 10.5 guide and it worked like a charm. I'm currently trying to upgrade to 10.6 and I'm having a little trouble..I have put the SL image on a USB thumb drive formatted in hsf+, and I boot from a cd first with you .iso build on it, but when i get to chameleon graphical menu i don't see an option to boot with the thumb drive though it's plugged in..any suggestions on what's wrong? Or should I attempt by using a DVD install?

Thanks again

[bcc9]

Thanks bcc9, your guides have truly been a lifesaver for me with installing Mac. I've worked from your 10.5 guide and it worked like a charm. I'm currently trying to upgrade to 10.6 and I'm having a little trouble..I have put the SL image on a USB thumb drive formatted in hsf+, and I boot from a cd first with you .iso build on it, but when i get to chameleon graphical menu i don't see an option to boot with the thumb drive though it's plugged in..any suggestions on what's wrong? Or should I attempt by using a DVD install?

Thanks again

Thanks.

Assuming you still have 10.5 running, test the thumb drive by plugging it in, and if the install screen doesn't pop up as in:

http://www.insanelymac.com/forum/index.php...t&p=1474307

then there is something wrong with the way you copied osx onto that drive. I suspect that's the most likely problem.

[itwong]

works smoothly updating from 10.6.1 to 10.6.4. install myHack installer 1.1 to upgrade bootloader and run comboupdate 10.6.4. use pfix to repair permission. use bcc9's acpi patcher to fix acpi detection issue and use 10.6.3 AppleHDA patch to patch the stock AppleHDA to work with bcc9's HDAidt v4. Everything now works like it should. Thank you for everyone contributing in this thread