Yeah... i traced this "SMbustype" thing
here,
here,
here,
here,
here,
here (some already mentioned) and gave up
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
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
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
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?
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.
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?