RevoGirl / RevoBoot

The RevoBoot-loader project
http://revogirl.wordpress.com/
Other
50 stars 138 forks source link

Reboot during dynamic CPU detection #23

Open alvindarkness opened 13 years ago

alvindarkness commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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

alvindarkness commented 13 years ago

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.