Chameleon > Bug Reports
SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Gringo Vermelho:
--- Quote from: konsti on December 09, 2010, 01:15:02 PM ---1. SMbustype: yes, it was referenced around the web; our dear Gringo Vermelho even makes a mention in his thread! How about that ;)
But according to your posted link on the actual used smbios.plist keys, indeed, SMbustype doesn't exist. Wonder who invented it...
--- End quote ---
It did exist in Chameleon 2.0 RC4 (I used it!) and was invented by DigitalDJ:
http://forum.voodooprojects.org/index.php?topic=839.0
I don't know how it became "SMbustype" when the code made it in, zef probably knows.
Azimutz:
Yeah... i traced this "SMbustype" thing here, here, here, here, here, here (some already mentioned) and gave up :P
Still i don't know were it came from and there's also no sign of it on RC4's code.
SMcputype and SMbusspeed are indeed from DigitalDJ's patch, which i believe is inspired by his kext work (even here, no SMbustype).
Let's just leave that one alone before it comes to life again ;D
About SMbusspeed, afaik it's cpu specific, Core i7 i believe; it's of no use for you Konsti (or me), but i did checked that stuff you mention and it does the same here. The important part is that also doesn't seem to work with SMBIOSdefaults=n.
Anyone can confirm? :)
Ok... this SMBIOS stuff can get messy to explain, simply because it interacts with several stuff, cpu detection, memory detection, Mac model setting, etc... As i mentioned, the explanation i gave is mainly based on my experience as a user and the tests i been doing the past days, to refresh my mind; i also been taking a look at the code, but getting knowledge from there is going to take time, for me.
The main problem That Konsti brought up is that, some stuff, namely SMcputype, doesn't get injected from smbios.plist when SMBIOSdefaults=n is used, which i already confirmed. It seems now that SMbusspeed can be added to the bunch!? I can also confirm that the mentioned smbios.plist keys work with SMBIOSdefaults=n on RC4.
Also, i already knew that UseMemDetect is being affected by the same problem.
These are the facts!
According to that, i changed the topic again to something more appropriate and that doesn't make us being "out of topic" so easily :P
Note: Gringo, about this topic change, can you check i did it properly? I only changed first post and i don't see the other posts updated :o which i assumed it would. Wanted to spare you guys some work, but instead...
With this said, one thing we need to keep in mind, is the possibility that this code isn't ready yet!?
Also, we are assuming these keys should work with SMBIOSdefaults=n, but there's the possibility this was done on purpose? I don't believe so on the UseMemDetect case, since it has it's own mechanism to disable it.
To many doubts i can't answer atm.
So Konsti, i already explained you don't need to use SMBIOSdefaults=n to use a smbios.plist's values...
What more can i say or help you with? :)
--- Quote from: Gringo Vermelho on December 08, 2010, 04:39:30 PM ---Yes it's a late model 651 with EM64T. There's a message about 64-bit being enabled at the beginning of the boot process. IIRC you could use chess.app to see if 64-bit addressing was working? I'll check later, the P4 is occupied running Windows 7 during the day.
I think I know why you're asking, the Core Solo didn't have EM64T right? I wonder if that could cause problems.
Memory detection didn't fully work with Asere's booter either. Speed and type was correctly detected but the rest was missing, like with RC5. It would be cool if it was working but I can understand if nobody wants to put in the work to support something as old as i865/ICH5.
--- End quote ---
Gringo, about the memory detection i'll take a look; maybe we can at least figure if it's a problem with the detection code or some incompatibility with the machine/Bios. There's code for ICH5 on spd.c; can you check the dev id of the smbus controller against yours?
Just a silly question... do you have the missing info on Windows? :)
We're out of topic here so, feel free to pm me if you need.
About the cpu-type you're right, i did asked because of the em64t thing; Intel Core Solo/Duo don't have it.
I don't think it makes any diff; i mean, i can use Core Duo on my Pentium D and i never saw any diff. But maybe Core 2 Solo it's a better fit on these cases?! Specially on the 64 bit capable Atom's, since they belong to the same family as Core 2 cpus (6).
Our old stuff is family 15.
Anyway, i consider this stuff mostly cosmetic, since the real cpu is always detected on my system.
The "64 mode" message means you can run 64 bit apps, yes. Did you gave a try to Snow on that machine?
Gringo Vermelho:
The SMBus controller on the P5P800SE:
00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] (rev 02)
On Windows (it's running 64-bit Windows 7 Ultimate) I can see all the SPD data for all four sticks of RAM with CPU-Z.
I agree Core 2 Solo would be a better fit for my P4 and the Atoms too, but then what about older model P4s with no 64-bit support? They would still need to be set as Core Solo. Chameleon would then have to check for EM64T capability in addition to whatever it's doing now when setting the CPU type. If that's even possible.
But I guess it would be a lot of work to support old, obsolete hardware like that and I don't know how much it matters. Maybe it would be giving me trouble if I was using a MacMini model identifier, the Mac Mini had the Core Solo right? From what I've seen so far it seems that most apps look at the model identifier instead of the CPU type.
I haven't attempted to install Snow Leopard on it, maybe I'll give it a go just to say I did it.
About the topic - let me check that, I never tried changing a topic title. I hope there's a tickbox that says 'change title for all posts'. If not, blame Rocksteady. :P
/Edit
...nope, you have to change each post title individually. Booooorring!
Azimutz:
--- Quote ---The SMBus controller on the P5P800SE:
00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] (rev 02)
On Windows (it's running 64-bit Windows 7 Ultimate) I can see all the SPD data for all four sticks of RAM with CPU-Z.
--- End quote ---
The controller id matches
--- Code: ---{0x8086, 0x24D3, "ICH5", read_smb_intel },
--- End code ---
I'd say the booter is not being able to retrieve the info, but... will try to take a look.
--- Quote ---I agree Core 2 Solo would be a better fit for my P4 and the Atoms too, but then what about older model P4s with no 64-bit support? They would still need to be set as Core Solo. Chameleon would then have to check for EM64T capability in addition to whatever it's doing now when setting the CPU type. If that's even possible.
But I guess it would be a lot of work to support old, obsolete hardware like that and I don't know how much it matters. Maybe it would be giving me trouble if I was using a MacMini model identifier, the Mac Mini had the Core Solo right? From what I've seen so far it seems that most apps look at the model identifier instead of the CPU type.
--- End quote ---
yep.. as i said, i believe most of this stuff is cosmetics, unless one can take advantage of it in cases like native power management.
Chameleon does detect if the cpu has em64t or not; it's how it chooses the arch to pass to the kernel. And it also detects the number of cpus/cores. It's not that hard to make changes in that direction; in fact, it seems pretty easy.
Will try to take a look too :)
--- Quote ---I haven't attempted to install Snow Leopard on it, maybe I'll give it a go just to say I did it.
--- End quote ---
It will work Gringo! I know a mate who has it running on a machine very similar to yours; he just doesn't run it on x86_64 arch because of the graphics drivers not having support for 64 bit (nVidia 7xxx).
--- Quote ---About the topic - let me check that, I never tried changing a topic title. I hope there's a tickbox that says 'change title for all posts'. If not, blame Rocksteady. :P
/Edit
...nope, you have to change each post title individually. Booooorring!
--- End quote ---
hum.. it seems like so :P looks like Blackosx did the same on the other change.
Will do so, while the posts aren't that many.
konsti:
Dear friends, my turn to reply 8)
1. Thanks for confirming the SMcputype bug of this thread, Azimutz. I am happy I am not getting crazy! So what can the next step be? I mean, how can we have Chameleon developers also poke into the code and see where this injection gets lost?
2. The above question also expands to SMbusspeed, hoping that you can also confirm my contradicting reports in System Profiler with SMBIOSdefaults=Yes or No :) Anyway, what kind of unit is 1.33 GT/s ?
3. And I believe you all refer to CoreSolo as processor, since there has apparently never been a Core2Solo, right? You are indeed referring to value:
<key>SMcputype</key>
<string>257</string>
...correct?
4. I also have a hackintosh based on Core i7-860 (2.83GHz) and will test the SMbusspeed in relation to SMBIOSdefaults, if you want (more feedback, I mean).
Cheers!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version