Jump to content

10.8.5 out

edebca0c

By edebca0c,
in New Releases and Updates

 Share
231 posts in this topic

Recommended Posts

RobertX
RobertX
Posted
Posted

..just waiting for updated nvidia web drivers...all else is well...

...got the web drivers loaded again(after supplemental update:12F45) by updating the plist of NVDAStartup.kext to reflect the new system version...(just a fix...) :smoke:

 

post-11772-0-79348700-1380892700_thumb.png  post-11772-0-32191700-1380893005_thumb.png

  • Like 1
Link to comment
Share on other sites
pkdesign
pkdesign
Posted
Posted

Guys, would appreciate any sort of help.

 

I'm having the high temps issue after the 10.8.5 upgrade. Idle gone from 40 to 48 on cpu and GPU from 37 to close to 50 :(

 

I'm on an EP45-UD3R with E8400

 

I've seen comments on editing the DSDT but my issue is that I'm on the Cartri Bios so no DSDT.

 

Is there any option whatsoever for the likes of me? Please help :(

I am having the same issue. I just verified it by booting into 10.8.4 from a backup. Temps rise from 42 to 48 when I boot into 10.8.5. I use a properly edited DSDT for my Gigabyte GA-EX58-UD4P mobo from MacMan that has worked flawlessly. I also have pretty good P States from 12-21. What could have caused this rise in temps from just a point ugrade?

Link to comment
Share on other sites
RobertX
RobertX
Posted
Posted

I am having the same issue. I just verified it by booting into 10.8.4 from a backup. Temps rise from 42 to 48 when I boot into 10.8.5. I use a properly edited DSDT for my Gigabyte GA-EX58-UD4P mobo from MacMan that has worked flawlessly. I also have pretty good P States from 12-21. What could have caused this rise in temps from just a point ugrade?

...perhaps applelpc.kext is not loading for you(i had to manually add my id to the plist to get temps down) :smoke:...a dirty little hack, as you have to do this every time you update(my dsdt edit for LPC no longer works with 10.8.5 either)...and i haven't gotten around to fixing it properly

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

:D   First of all, I want to express my thankfulness for your great kext. I've some usb dongles with CSR chipset which work out of the box. But one annoying fact is that it will always prompt me some verification window unlike the Dell BT which just connects. Any ideas to improve usb dongle experience? :D

Missed this post before. Probably should take this to the bluetooth thread. As I mentioned there, CSR support is not in my kext, but it should be EZ to add. I'm not sure which CSR dongles require a manual usb command to switch them to HCI mode. If yours does, you could try adding the CSR support from bluez that I left out from the kext and testing the mode switching with that. The stock osx driver is handling this partially for CSR chipsets right now?
Link to comment
Share on other sites
p.H
p.H
Posted
Posted

Yeah. I think OS X treats those usb BT dongles differently compared with Apple's own internal BT parts. I am sorry for not knowing the bluetooth thread you've mentioned. Would you mind directing me to the thread? Plus, I just did the Mavs upgrade and I was messing with the AppleHDA.kext. I would know if your patch-hda works with 10.9? I tried it beforehand, but I could not make it work. If things aboult AppleHDA did not change much between 10.9 and 10.8, I think I was able to make it. But I failed at the moment. So just eager to know if it has something to do with your patch script :D

 

Edit: Just come to know that your patch has a new version 2.0. I tried it out and it worked. :D

Link to comment
Share on other sites
p.H
p.H
Posted
Posted

Hi, TimeWalker. Since the 10.9 GM is out, would you mind sharing the patched version of IOBluetoothFamily for 10.9?

Or is it possible that you could make the patch to be easily used with Clover who has the ability to patch kext on the go?

Link to comment
Share on other sites
TimeWalker75a
TimeWalker75a
Posted
Posted

Hi, TimeWalker. Since the 10.9 GM is out, would you mind sharing the patched version of IOBluetoothFamily for 10.9?

Or is it possible that you could make the patch to be easily used with Clover who has the ability to patch kext on the go?

		<key>KextsToPatch</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>configurePM BT</string>
				<key>Find</key>
				<data>
				AAAAD4UHAQAA
				</data>
				<key>Name</key>
				<string>IOBluetoothHostControllerUSBTransport</string>
				<key>Replace</key>
				<data>
				AAAAD4QHAQAA
				</data>
			</dict>
Link to comment
Share on other sites
p.H
p.H
Posted
Posted

Thanks bro. But I have some personal thoughts and correct me if I am wrong. :D

Since this patch can be applied with Clover like the ATI connector, is it universal? Is the patch usable throughout different OS?

And if you are willing, please tell me something more(in depth) about the patch. :D Thanks again. :D

Link to comment
Share on other sites
p.H
p.H
Posted
Posted

Oops. I was not capable of that but I am interested in the process. Would you mind sharing a more detailed process? I would like to learn how to find it myself so that I won't bother others every time the Kext gets updated. :D   If someone is hungry, you can offer them fish. But the better thing is to teach them how to fish themselves if you can. :D

Hope you will share the detailed procedure as a tutorial for people like me. Thanks in advance. :D

Link to comment
Share on other sites
TimeWalker75a
TimeWalker75a
Posted
Posted

otool -t -V /System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/IOBluetoothHostControllerUSBTransport.kext/Contents/MacOS/IOBluetoothHostControllerUSBTransport > ~/Desktop/out.txt

 

Have to have command line tools installed for otool to work.

Then find this string in the output:

IOBluetoothHostControllerUSBTransport::configurePM() -- commandSleep is not called in the workloop

Then look for procedure around it:

000000000000381e	callq	*0x7a8(%rax)
0000000000003824	movb	$0x1, %al
0000000000003826	testb	$0x1, 0xb6(%r14) <<-- test if PowerState is 0x01 .. 
000000000000382e	jne	0x3912  << -- if it's 0x00 then jump to resume controller
s0000000000003834	movb	$0x1, %al
0000000000003836	cmpq	$0x0, 0x98(%r14)
000000000000383e	je	0x3912
0000000000003844	leaq	0xb6(%r14), %r13
000000000000384b	xorl	%ebx, %ebx
000000000000384d	leaq	0xfffffffffffffe48(%rbp), %r15
0000000000003854	leaq	0x9020(%rip), %r12 ## literal pool for: "IOBluetoothHostControllerUSBTransport::configurePM() -- commandSleep is not called in the workloop\n"@/SourceCache/IOBluetoothFamily_kexts/IOBluetoothFamily-4170.4.2/Core/Family/HCI/Transports/USB/IOBluetoothHostControllerUSBTransport/IOBluetoothHostControllerUSBTransport.cpp:1159
000000000000385b	movl	$0x12c, %edi
0000000000003860	movl	$0xf4240, %esi
0000000000003865	movq	%r15, %rdx
0000000000003868	callq	_clock_interval_to_deadline
000000000000386d	movq	0x98(%r14), %rdi
0000000000003874	movq	(%rdi), %rax
0000000000003877	movq	0xfffffffffffffe48(%rbp), %rdx
000000000000387e	movq	%r13, %rsi
0000000000003881	xorl	%ecx, %ecx
0000000000003883	callq	*0x1f0(%rax)
0000000000003889	movl	%eax, %ecx
000000000000388b	incl	%ebx
000000000000388d	movb	$0x1, %al
000000000000388f	cmpl	$0x1, %ecx
0000000000003892	je	0x38ac
0000000000003894	testl	%ecx, %ecx
0000000000003896	je	0x3912
0000000000003898	cmpl	$0xe00002e2, %ecx
000000000000389e	jne	0x38b3
00000000000038a0	movq	%r12, %rdi
00000000000038a3	xorb	%al, %al
00000000000038a5	callq	_panic
00000000000038aa	jmp	0x38b3
00000000000038ac	testb	$0x1, (%r13)
00000000000038b1	jne	0x3912
00000000000038b3	cmpl	$0x64, %ebx
00000000000038b6	jb	0x385b
00000000000038b8	movl	$0x1ff, %edi
00000000000038bd	callq	_IOMalloc
00000000000038c2	movq	%rax, %rbx
00000000000038c5	movb	$0x1, %al
00000000000038c7	testq	%rbx, %rbx
00000000000038ca	je	0x3912
00000000000038cc	movq	%rbx, %rdi
00000000000038cf	movl	$0x1ff, %esi
00000000000038d4	callq	_bzero
00000000000038d9	leaq	0x90b6(%rip), %rdx ## literal pool for: **** [IOBluetoothHostControllerUSBTransport][configurePM] -- ERROR -- waited 30 seconds and still did not get the commandWakeup() notification -- this = %p ****

00000000000038e0	movq	%rbx, %rdi
00000000000038e3	movl	$0x1ff, %esi
00000000000038e8	movq	%r14, %rcx
00000000000038eb	xorb	%al, %al
00000000000038ed	callq	_snprintf
00000000000038f2	leaq	0x88a6(%rip), %rdi ## literal pool for: %s
00000000000038f9	movq	%rbx, %rsi
00000000000038fc	xorb	%al, %al
00000000000038fe	callq	_IOLog
0000000000003903	movq	%rbx, %rdi
0000000000003906	movl	$0x1ff, %esi
000000000000390b	callq	_IOFree
0000000000003910	movb	$0x1, %al
0000000000003912	movq	0xd70f(%rip), %rcx

You are looking at offset 0x382e which has opcode jne (0x85) and you want to reverse it to je (0x84) so that if state is 0x01 it would just carry on resuming the controller from sleep. 

Then you open up any hex editor (Hex Fiend for example), Edit - Jump to offset (might require hex to dec conversion, use Calculator.. 14382 in this case)

4J5av.png

.. and you look for a pattern around your 85 value that would be unique.  00 01 0F 85 DE 00 00 00 for example .. if it's the only pattern found in the finary (use CMD+F) then you can take it as Find pattern and as replace you just revert the jne to je. Or other way around if the check was checking against 0x00 and expecting it to be equal (je).

  • Like 4
Link to comment
Share on other sites
p.H
p.H
Posted
Posted (edited)

First of all, thanks for the tutorial. Then comes my question :D
I've taken the essential part(untouched) of the output for the file of 10.9 GM and found that the logic is the different here.

All the annotation below is my person thought about the what it is doing based on my knowledge and the info you provided.

 

0000000000002da8 callq *0x7a8(%rax)
0000000000002dae movb $0x1, %bl
0000000000002db0 cmpb $0x0, 0xb6(%r14)   <-- test if PowerState is 0, 0xb6(%r14) stores the value of PowerState
0000000000002db8 jne 0x2ec5                        <-- jump to 0x2ec5 if PowerState is not equal to 0
0000000000002dbe movb $0x1, %bl
0000000000002dc0 cmpq $0x0, 0x98(%r14)
0000000000002dc8 je 0x2ec5
0000000000002dce leaq 0xb6(%r14), %r15
0000000000002dd5 movl $0x1, %eax
0000000000002dda leaq 0xacdf(%rip), %r13 ## literal pool for: "IOBluetoothHostControllerUSBTransport::configurePM() -- commandSleep is not called in the workloop\n"@/SourceCache/IOBluetoothFamily_kexts/IOBluetoothFamily-4200.4.6/Core/Family/HCI/Transports/USB/IOBluetoothHostControllerUSBTransport/IOBluetoothHostControllerUSBTransport.cpp:1172

 

Now I think you can see the logical difference with the code output. As your patch suggests(from jne to je), my situation is jump if PowerState equals 0. Whereas yours is to jump if PowerState equals 1. This is driving me nuts. The patch you provided did work in 10.9 GM though. 

Edited by Gringo Vermelho
Fullquotes removed here and elsewhere. Please don't quote entire posts when replying directly below them.
Link to comment
Share on other sites
mbhang
mbhang
Posted
Posted

pkdesign,

 

Can you please advise on what the edits were  - which plist file  - and what did you change ?

 

Thanks,

I am having the same issue. I just verified it by booting into 10.8.4 from a backup. Temps rise from 42 to 48 when I boot into 10.8.5. I use a properly edited DSDT for my Gigabyte GA-EX58-UD4P mobo from MacMan that has worked flawlessly. I also have pretty good P States from 12-21. What could have caused this rise in temps from just a point ugrade?

Link to comment
Share on other sites
p.H
p.H
Posted
Posted

As I've said in my post it could be the other way around if the check is checking against 0, depends on how the binary was compiled. And the code from my example comes from supplemental 10.8.5 to stay on topic.

Oops. After all, all I need is to change that specific JNE to JE in future kext updates?

Link to comment
Share on other sites
pkdesign
pkdesign
Posted
Posted

I am having the same issue. I just verified it by booting into 10.8.4 from a backup. Temps rise from 42 to 48 when I boot into 10.8.5. I use a properly edited DSDT for my Gigabyte GA-EX58-UD4P mobo from MacMan that has worked flawlessly. I also have pretty good P States from 12-21. What could have caused this rise in temps from just a point ugrade?

This is absolutely a DSDT issue. I found the answer here: http://www.tonymacx86.com/mountain-lion-desktop-support/109371-higher-temps-after-upgrade-10-8-5-a.html

 

My temps went from 48/50 down to 38/40 immediately.

Link to comment
Share on other sites
  • 2 weeks later...
 Share
Go to topic listing
×
×
  • Create New...