Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


Retired Developers
  • Content count

  • Joined

  • Last visited

About Kabyl

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender
  1. Chameleon v2.1 (Main Trunk)

    Thanks for the patch! applied with a few changes (r1004).
  2. Chameleon v2.1 (Main Trunk)

    I got that, I will clarify the what the code does a bit more though: - first we check for smbios.plist key/value pairs, if the specific key isn't found (false), - call the getters functions, if that returns false (value not set), - use the default value, if that's not set (false), - use the original data from the BIOS whatever that data is, it could be buggy, which is the case for your SMBMemoryDeviceSerialNumber. Now, since our SMBMemoryDevice* getters for the string fields always return a value, the original data from the BIOS is never used, and this is an option some users might want to use. What I did in the last commit is remove this option for Intel-chipset users (always return a value (true)) because in most cases we can read the SPD and RAM controller info. That's very possible, probably the reason why it worked in my tests is the order in which the fields are set. I shouldn't have trusted that. I'll have to do more tests and fix this later.
  3. Chameleon v2.1 (Main Trunk)

    The case where a user has a good SMBIOS, and wants to keep the original data. And if you check the change log you'll see that I was going back and forth between the two, and finally decided on the previous change. But now, I think we have a better way (check the last commit). That's exactly what the return false does, but sometimes SMBIOS is buggy.
  4. Chameleon v2.1 (Main Trunk)

    OK, I think there is a better solution, I'll add a quick hack to check if UseMemDetect is true and return a default value, otherwise leave whatever is found in the original SMBMemoryDevice records, and hope non-Intel-based chipset users wouldn't complain about having no memory info.
  5. Chameleon v2.1 (Main Trunk)

    If I revert it, it will break it for others, so I left the code commented. Could you upload an ioreg from each case?
  6. Chameleon v2.1 (Main Trunk)

    I think your issue is related to this: http://forge.voodooprojects.org/p/chameleo...o/smbios.c#L378 The syntax has changed, there is no underscore.
  7. Chameleon v2.1 (Main Trunk)

    Slice, I think you need to re-checkout the repo, there is no mem.h in platform.c http://forge.voodooprojects.org/p/chameleo...saio/platform.c
  8. That's with the working booter, I need another with the current booter.
  9. Well, that means something is broken, can you upload your .ioreg?
  10. I don't have a Radeon card to test, if you can try the attached booter. boot.gz
  11. Sure. It was done that way on purpose, I wanted people to report the error so that we can add support properly.
  12. Chameleon v2.1 (Main Trunk)

    Try this: http://www.mediafire.com/?bs7nmnnc1eyi8r2 Thank you MaLd0n.
  13. Chameleon v2.1 (Main Trunk)

    I'm going to need your .ioreg. Your inbox if full Anyone has a SandyBridge-based Mac's .ioreg?
  14. Chameleon v2.1 (Main Trunk)

    If you could upload a .ioreg dump, I'll try to fix it.
  15. Good! That happens when you don't make clean and re make.