Bug 251779
Summary: | CPU frequency scaling appears unsupported in FC7 but is enabled in the BIOS. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | c.h. <fc6_req> | ||||
Component: | cpuspeed | Assignee: | Jarod Wilson <jarod> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 7 | ||||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-08-15 23:52:39 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
c.h.
2007-08-11 04:16:13 UTC
Try booting with some modified grub.conf kernel params. Substitute 'cpufreq.debug=7' for 'quiet' on the kernel line. Grab dmesg output after booting up and attach it to the bug. Should give some good info on why we're not getting any freq scaling. Note that freq scaling works perfectly on my own core 2 quad system, so I'd have to be inclined to say its a BIOS problem at first glance. Thanks for the kernel parameter information for debugging. I've just rebooted using the 'cpufreq.debug=7' parameter instead of 'quiet' and I see that there is new potentially relevant information in the new dmesg output. It looks like there may be some issues in the BIOS though I'm not sure how relevant those are or if they're such that the F7 PM code is intended to be able to work-around them or not. I can submit the information wrt. the memory address reservation and checksum related problems to the Motherboard/BIOS vendor and hope that they'll have enough information to resolve those before too long. Beyond that I'm just wondering if besides experimenting with other BIOS settings that "shouldn't" make PM work better (but might if there's a BIOS bug), if there's anything I could do in Fedora to get it working and to determine if F7's working "as intended" in the situation. Here I'll list a few of the items I've noticed that concern me as being potentially related problems (though I'm only speculating at the possible relevance), and thereafter I'll send the whole recent dmesg output. Concerning (relevant?) items: ... PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ... pnp: 00:0a: iomem range 0xfee00000-0xfee00fff could not be reserved ... pnp: 00:0d: iomem range 0x0-0x9ffff could not be reserved ... pnp: 00:0d: iomem range 0xe0000-0xfffff could not be reserved pnp: 00:0d: iomem range 0x100000-0xcfffffff could not be reserved ... ACPI Warning (tbutils-0158): Incorrect checksum in table [OEMB] - 7C, should be 7B [20070126] ACPI: SSDT CFF8E0D0, 0190 (r1 AMI CPU1PM 1 INTL 20060113) ACPI: SSDT CFF8E260, 0143 (r1 AMI CPU2PM 1 INTL 20060113) ACPI: SSDT CFF8E3B0, 0143 (r1 AMI CPU3PM 1 INTL 20060113) ACPI: SSDT CFF8E500, 0143 (r1 AMI CPU4PM 1 INTL 20060113) hpet_resources: 0xfed00000 is busy ... acpi-cpufreq: acpi_cpufreq_init acpi-cpufreq: acpi_cpufreq_early_init cpufreq-core: trying to register driver acpi-cpufreq cpufreq-core: adding CPU 0 acpi-cpufreq: acpi_cpufreq_cpu_init acpi-cpufreq: No P-States cpufreq-core: initialization failed cpufreq-core: adding CPU 1 acpi-cpufreq: acpi_cpufreq_cpu_init acpi-cpufreq: No P-States cpufreq-core: initialization failed cpufreq-core: adding CPU 2 acpi-cpufreq: acpi_cpufreq_cpu_init acpi-cpufreq: No P-States cpufreq-core: initialization failed cpufreq-core: adding CPU 3 acpi-cpufreq: acpi_cpufreq_cpu_init acpi-cpufreq: No P-States cpufreq-core: initialization failed cpufreq-core: no CPU initialized for driver acpi-cpufreq cpufreq-core: unregistering CPU 0 cpufreq-core: unregistering CPU 1 cpufreq-core: unregistering CPU 2 cpufreq-core: unregistering CPU 3 ... Full dmesg: see subsequently attached file and/or forthcoming comment if the attachment process gives me trouble. Created attachment 161259 [details]
dmesg with +cpufreq=7 -quiet options present.
This bit is the most relevant out of dmesg: cpufreq-core: trying to register driver acpi-cpufreq cpufreq-core: adding CPU 0 acpi-cpufreq: acpi_cpufreq_cpu_init acpi-cpufreq: No P-States This indicates that the BIOS ACPI tables aren't providing us with any P-State data, which is fatal to the acpi-cpufreq driver. Pretty sure this is a BIOS bug, and not one we can work around in any sane manner. Thank you very much for your help in assessing this and for the information on how to get the full debug data. You were correct, it was the BIOS doing something contradictory to the apparent status of the ACPI / C1E settings when other settings were made. I experimented with various configurations and found that I was able to get a functional cpuspeed configuration supporting: P0 = Full speed CPUx9 P1 = Minimum speed CPUx6 acpi-cpufreq: CPU0 - ACPI performance management activated. 1.15V @ acpi-cpufreq: *P0: 2394 MHz, 88000 mW, 10 uS 1.06V @ acpi-cpufreq: P1: 1596 MHz, 59048 mW, 10 uS Those seem to switch appropriately and the Vcores change commensurately. Thanks agaom for all the good work on the cpuspeed / power management code! I'll change this to "NOTABUG". |