Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reboot during dynamic CPU detection #23

Open
alvindarkness opened this issue Aug 24, 2011 · 6 comments
Open

Reboot during dynamic CPU detection #23

alvindarkness opened this issue Aug 24, 2011 · 6 comments

Comments

@alvindarkness
Copy link

On a lenovo y560p laptop with an i7 2630QM CPU. Using the latest source, which seems to have the gigabyte fix that was included yesterday. I've got most debug options set within settings.h.

If I set USE_STATIC_CPU_DATA to true, the boot loader seems to get past the cpu detection portion onto smbios/drivers etc. But if I set USE_STATIC_CPU_DATA to false, a reboot occurs very early on (after displaying the architecture as x86_64 then c-states etc, through to the cpu tdp = 45 as the last thing displayed).

Not sure if its related (or more likely something stupid I'm doing) - but when I try to use static cpu data, using the following

define STATIC_CPU_Type 0x701 // also tried 702 and 703

define STATIC_CPU_NumCores 4

define STATIC_CPU_NumThreads 8

define STATIC_CPU_FSBFrequency 100000000ULL

define STATIC_CPU_QPISpeed 0

I noticed the cpu debug info spits out that the cpu frequency is 0Hz. (but continues through the following sections then causes a kernel panic)

@RevoGirl
Copy link
Owner

Hi,

Sorry about that. So the last line you see is: "CPU IA (Core) TDP: 45" and then it reboots. That helps me to track it down, and I moved code into cpu.c minutes ago so now you can check if it makes it into function checkFlexRatioMSR() in cpu.c If not, then it is likely one of these two calls:

wrmsr64(MSR_MISC_PWR_MGMT, 0x400001);
wrmsr64(MSR_PKG_CST_CONFIG_CONTROL, 0x18008407);

That's just above the new call to checkFlexRatioMSR in dynamic_data.h Or when it fails because of the new code, then you could block that call (as well). Can you test this?

About the CPU frequency being 0. Do you see something like "CPU: TSCFreq: 0"?

@alvindarkness
Copy link
Author

Sorry about the delay. Ive tried to narrow down which line is causing it using the information you provided. Its definitely the second wrmsr64 line causing it.. I'm no programmer, but added a few lines to the code (below). It displays "done.. about to call 2nd wrmsr64 line\n" then reboots..

                                    printf("about to call the first wrmsr64 line\n");
                                    sleep(5);

                                    // Disable EIST Hardware coordination.
                                    wrmsr64(MSR_MISC_PWR_MGMT, 0x400001);

                                    printf("done.. about to call 2nd wrmsr64 line\n");
                                    sleep(5);

                                    // Disable C1/C3 state auto demotion i.e. it won't change C3/C6/C7 requests to C1/C3.
                                    wrmsr64(MSR_PKG_CST_CONFIG_CONTROL, 0x18008407);

                                    printf("called the new lines okay about to call checkflexratioMSR\n");
                                    sleep(5);

                                    checkFlexRatioMSR();
                                    printf("checkflexratioMSR called and we are continuing\n");
                                    sleep(5);

Also I added a printf at the end of getTSCFrequency to show the value the function is returning, and its not zero.

This is all with USE_STATIC_CPU_DATA set to 0. Im yet to try the static cpu stuff further. Id love to get the boot loader working, so anything else you want me to try please let me know.

@alvindarkness
Copy link
Author

Sorry I just re-read and saw you told me to try comment out the line and try again. It boots with the second wrmsr64 line commented. Thanks!

Just a side question.. "sysctl -a | grep -i frequency" gives me -:
hw.busfrequency = 396000000
hw.cpufrequency = 1995000000

A friends macbookpro8,2 has a bus frequency of hw.busfrequency = 100000000.

Any way to get that reported correctly? I was reading on another forum that occasional audio glitches could be caused by it, and I do get an audio glitch almost every time p-state changes.

@RevoGirl
Copy link
Owner

Right. Now we know what the problem is. Too bad that I can't recall why I added the lines (probably for testing). What values do you get when you use:

printf("MSR 1: 0x%0x\n", rdmsr64(MSR_MISC_PWR_MGMT));
printf("MSR 2: 0x%0x\n", rdmsr64(MSR_PKG_CST_CONFIG_CONTROL));

And when we need the lines, then we should at least call msr = rdmsr(...) and use the values we get from it.

Thanks for testing.

p.s. I use a modified AppleSMBIOS.kext to work around the bus frequency error. Still haven't looked at the latest XNU sources, but I hope to have some time this weekend.

@alvindarkness
Copy link
Author

Thanks! I'll try the printf statements later today and let you know the results.

@alvindarkness
Copy link
Author

Okay the values I get are -

MSR 1: 0x400001
MSR 2: 0x1e008404

side note: I compiled an applesmbios and got rid of the assume quad pumping line, that worked a treat. Thanks for the suggestion. Audio still seems to glitch slightly when going into any turbo p-state (above multiplier 20). Im yet to try but I presume if I get revoboot to generate p-states and choose zero turbo-states that the cpu should never turbo?

side note 2: ignore the above, audio glitch fixed. ended up it was the applesmbios/applebattery combo i was using.. fixed it per chance. if theres anything else you want me to test or code to run let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants