1572 replies to this topic

[bcc9]

DutchHockeyPro, on May 13 2011, 10:11 PM, said:

Anyway. Looking at the mach_kernel of Lion I see this:
Where WESTMERE, NEHALEM, and SANDYBRIDGE all jump to the same spot reading the MSR that caused you problems.

That's exactly what I noted in my first FLEX_RATIO post.  Patching that code was how I found that this MSR mishandling was the root cause of my mach_kernel failing to boot.

DutchHockeyPro, on May 13 2011, 10:11 PM, said:

And since Apple is Intels biggest client, and since Apple has Intel engineers working for them... I'd say that it is safe to assume that MSR 0x194 is part of what should work. Not to mention that more MSR's are missing from the docs/white papers, and that Asus engineers cite NDA restrictions when people do ask for info about them.

I'd say no, it's definitely *not* safe to assume undocumented fields are guaranteed to be set the way apple's code happens to be testing them, when using non-apple hardware.  Relying upon undocumented hardware behavior is not good practice.  If intel has registers whose semantics are only shared under NDA with a few vendors (and not the linux folks for example), then there isn't really anything concrete to complain to the bios vendors about.

I do however think that having the osx bootloader clear bit 16 of that MSR when bits 8 thru 15 come up 0 is a very reasonable fix.  Works for me ™.  If anyone else needs a chameleon boot file with this fix let me know.

I have found a few FLEX_RATIO references in intel's documents but nothing that details the semantics.

[me@home]

regae, on May 14 2011, 11:04 AM, said:

latest update 11A459e

thanks 4 your link on netkas.

Installed and only had to replace the kext 4 my audio to get it working again.

 Bildschirmfoto_2011_05_14_um_22.18.04.png   296.11K   113 downloads

[Time2Retire]

bcc9, on May 14 2011, 08:21 PM, said:

I'd say no, it's definitely *not* safe to assume undocumented fields are guaranteed to be set the way apple's code happens to be testing them, when using non-apple hardware.  Relying upon undocumented hardware behavior is not good practice.  If intel has registers whose semantics are only shared under NDA with a few vendors (and not the linux folks for example), then there isn't really anything concrete to complain to the bios vendors about.

Nothing is absolutely safe, but it isn't limited to Apple alone since Asus UEFI initializes this MSR with the correct values. And you can't do anything wrong when you port the values from one to the other MSR. At least that's what I've read in the datasheet.

Anyway. Most of the interesting MSR's are only slowly being added in non-NDA covered Intel documentation. I mean not much was given away in the beginning of the Sandy Bridge CPU launch. Same for JakeTown CPU's This sucks for us, but that is how things seem to work at Intel..

bcc9, on May 14 2011, 08:21 PM, said:

I do however think that having the osx bootloader clear bit 16 of that MSR when bits 8 thru 15 come up 0 is a very reasonable fix.  Works for me ™.  If anyone else needs a chameleon boot file with this fix let me know.

Oh sure. It is great that you located the problem and found a work around for your boot problem, but have you ruled out all other possible readouts from this specific MSR? I don't think so.

bcc9, on May 14 2011, 08:21 PM, said:

I have found a few FLEX_RATIO references in intel's documents but nothing that details the semantics.

Search for: "CLOCK_FLEX_MAX" instead and find this (for example):

Quote

"The processor’s maximum non-turbo core frequency is configured during power-on reset by using values stored internally during manufacturing. The stored value sets the highest core multiplier at which the particular processor can operate. If lower max non- turbo speeds are desired, the appropriate ratio can be configured using the CLOCK_FLEX_MAX MSR."

Not much of a give away, but that is what I can do for now

[oSxFr33k]

mitch_de, on Mar 13 2011, 09:51 PM, said:

The final will in general have the same requirements for chameleon. Offical (RC5 based) will not work - but until the release i think there will be at least some beta chamelon (one step further the very early chameleon lion bird now)
Also for NVIDIA: working will work, non working not - i dont think they will add officeal fermi support for example.

Thanks for the reply and sorry for the late response.  If the Nvidia cards I have are all working in Snow Leopard mostly because of Chameleon will they also work in Lion thats the question.

[bcc9]

DutchHockeyPro, on May 14 2011, 01:51 PM, said:

Oh sure. It is great that you located the problem and found a work around for your boot problem, but have you ruled out all other possible readouts from this specific MSR? I don't think so.

I identified a thorny interop problem between OSX and certain gigabyte h67 motherboard(s).  
I found two different fixes, and detailed them here.  They are the only working solutions for the h67ma-ud2h at this point.
I don't know why you keep posting inflammatory responses, but you are not helping here in any way, in fact you're just costing me extra time clarifying things to you.

I see you have a history of bad attitude posts earlier in this thread so I'm not taking it personally.  But I wish you'd at least show some respect or maybe get your posts moderated by a mature adult.

[Time2Retire]

bcc9, on May 14 2011, 11:54 PM, said:

I identified a thorny interop problem between OSX and certain gigabyte h67 motherboard(s).  
I found two different fixes, and detailed them here.  They are the only working solutions for the h67ma-ud2h at this point.
I don't know why you keep posting inflammatory responses, but you are not helping here in any way, in fact you're just costing me extra time clarifying things to you.

I see you have a history of bad attitude posts earlier in this thread so I'm not taking it personally.  But I wish you'd at least show some respect or maybe get your posts moderated by a mature adult.

What inflammatory responses? What bad attitude or lack of respect are you talking about? That's nonsense man. You simply cannot accept that a 15 year old girl is smarter than you, because hell yes did you forgot something. And now I should be moderated, because you can't handle it? Pfffft.

[digital_dreamer]

Anyone know what's up with the Memory display for System Information on the latest release (11A459e), or is this some silly goof on my part?
I've used smbios.plist injected info and, then, Cham RC5 r800 with the info removed from smbios.plist.



Bootloader messages show that it's being recognized (semi-accurately) as the following:

Slot: 0 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000
   Slot: 2 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000
   Slot: 4 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000

and:

MemoryDevice:
	   deviceLocator: A0
	   bankLocator: Bank0/1
	   memoryType: DDR3
	   memorySpeed: 1600MHz
	   manufacturer: Corsair
	   serialNumber: 00000000
	   assetTag: 
	   partNumber: 
   
   Type: 17, Length: 27, Handle: 0x19

etc.

Is Apple expecting us to populate the other fields, now, before showing anything?

MAJ

[rayap]

About this Mac memory misinformation is Chameleon related. If you boot with PCEFI with the same smbios plist it will appear. Similarly for the PCI/Ethernet cards info.

[atlee]

@DutchHockeyPro i would not think so high of yourself, this forum is for helping and dicussion not debating who has bigger underwear

[miliuco]

digital_dreamer, on May 15 2011, 12:19 AM, said:

Anyone know what's up with the Memory display for System Information on the latest release (11A459e), or is this some silly goof on my part?

Same issue here in a system installed following your hackinstaller guide, with Chameleon r796.

[Xeon3D]

Any ALC888 kexts for DP2 or DP3?

[orwell]

Xeon3D, on May 15 2011, 07:13 AM, said:

Any ALC888 kexts for DP2 or DP3?

For DP2

Attached Files

•  AppleHDA.kext.zip   1.56MB   12 downloads

[Rene204]

Xeon3D, on May 15 2011, 07:13 AM, said:

Any ALC888 kexts for DP2 or DP3?

Using here the GA-P55-USB3 (rev.1), seems that is an ALC888,
solution for me is using the Multibeast HDA Rollback (HDA-kext from 10..6.2) this works here without any Problems...
(in combination with ALC8xxHDA.kext, HDAEnabler888.kext, both from Multibeast-Installer too.)

Try out..

[Goron]

Rene204, on May 15 2011, 07:24 AM, said:

Using here the GA-P55-USB3 (rev.1), seems that is an ALC888,
solution for me is using the Multibeast HDA Rollback (HDA-kext from 10..6.2) this works here without any Problems...
(in combination with ALC8xxHDA.kext, HDAEnabler888.kext, both from Multibeast-Installer too.)

Try out..

Has anyone managed to get sound output on AD1988B? It shows up systemprofiler, but no device is found within  system preferences ... using SL dsdt and AD2000B.kext ...

Currently i´m running DP3 (11A459e), but it didn´t work in any predecessor either

[iLeopod]

The structure of AppleHDA.kext changed with lion. So if u use a legacyHDA for snow you also need a snow AppleHDA.

[Aivarz]

For AD1988B.
With this in DSDT:

			Device (HDEF)
			{
				Name (_ADR, 0x001B0000)
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x08)
						{
							"subsystem-id", 
							Buffer (0x04)
							{
								0xA0, 0x00, 0x00, 0x00
							}, 
							"subsystem-vendor-id", 
							Buffer (0x04)
							{
								0x6B, 0x10, 0x00, 0x00
							}, 
							"layout-id", 
							Buffer (0x04)
							{
								0x0C, 0x00, 0x00, 0x00
							}, 
							"PinConfigurations", 
							Buffer (Zero) {}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}
			}

[DarwinX]

DutchHockeyPro, on May 14 2011, 05:10 PM, said:

What inflammatory responses? What bad attitude or lack of respect are you talking about? That's nonsense man. You simply cannot accept that a 15 year old girl is smarter than you, because hell yes did you forgot something. And now I should be moderated, because you can't handle it? Pfffft.

You are indeed quite ingenious when it comes to coding, perhaps better than most on this forum, which is very impressive especially considering your very young age. Certainly, your contribution is significant and appreciated; what's questionable is the manner in which it's delivered. While your demeanor is quite expected of a 15 year old, it is unprofessional and dismissive of other corroborators. Having said that, I disagree with the remark that you are to be moderated as this is not a dictatorship or a blog. Such extremes are better reserved for profanity, spam or personal verbal attacks on other members of the board.

Please remember that we are all here in the pursuit of the mutual cause.

[Time2Retire]

DarwinX, on May 15 2011, 01:40 PM, said:

...what's questionable is the manner in which it's delivered. While your demeanor is quite expected of a 15 year old, it is unprofessional and dismissive of other corroborators...

You know what. I am starting to feel sorry for Blackosx for mentioning the link to my work. Seriously. Why are we having this kind of discussions here? Not to mention that I strongly disagree with this remark. Please read what he wrote and feel free to PM me so that I can show you, with clear evidence that what he did was wrong.

DarwinX, on May 15 2011, 01:40 PM, said:

Please remember that we are all here in the pursuit of the mutual cause. [/b]

This is why we advertise and push people to share their source code and ideas. That is why I have a public github repository. Because I believe that this 'sharing' is the way forward. But hey. Don't expect me to give it all away without 'you' doing anything in return for it

The problem for some people here is that I speak out when I disagree. And I do this in public. Not in some IRQ channel so that nobody reads it. And no. There's no back stabbing on my account. But I won't be quiet when someone makes false accusations, like I was fishing for something for RevoBoot. Like there's some bug that I wanted to fix in RevoBoot.

Ah yes the mutual case. Well. Let's start by giving feedback, which he clearly didn't do (and some say for obvious reasons) and answering my questions, shall we?

Oh wait. Someone else already did that for him. Not that I will change RevoBoot for it, because that much should have been clear right from the start. This is not about RevoBoot. This isn't about me. This all is about me trying to help someone, who then pulled up his fences... simply because he felt that he was under attack, and you know what they say when you corner a rat? They jump right in your face! So true.

[asapreta]

digital_dreamer, on May 14 2011, 07:19 PM, said:

Anyone know what's up with the Memory display for System Information on the latest release (11A459e), or is this some silly goof on my part?
I've used smbios.plist injected info and, then, Cham RC5 r800 with the info removed from smbios.plist.



Bootloader messages show that it's being recognized (semi-accurately) as the following:

Slot: 0 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000
   Slot: 2 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000
   Slot: 4 Type 24 2048MB (DDR3 SDRAM) 1333MHz Vendor=Corsair
		 PartNo=CM3X2G1600C9 SerialNo=00000000

and:

MemoryDevice:
	   deviceLocator: A0
	   bankLocator: Bank0/1
	   memoryType: DDR3
	   memorySpeed: 1600MHz
	   manufacturer: Corsair
	   serialNumber: 00000000
	   assetTag: 
	   partNumber: 
   
   Type: 17, Length: 27, Handle: 0x19

etc.

Is Apple expecting us to populate the other fields, now, before showing anything?

MAJ

Depending on the version of Chamaleon I run, I have this too.
The one I'm running now (I need to re-check which is) all banks are correctly populated.

[blackosx]

DutchHockeyPro, on May 15 2011, 02:09 PM, said:

You know what. I am starting to feel sorry for Blackosx for mentioning the link to my work.

After seeing the words MSR and Sandy Bridge here I drew a similarity to some of the posts in your topic and thought linking to your work would be helpful and positive. The ensuing storm was unforeseen and never part of my intention.