Bug 428895
| Summary: | System freezes with p4-clockmod and ondemand governor | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Janakiev <malwkgad> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | CC: | chris, christoph, ronny.fischer |
| 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: | 2008-03-10 21:45:30 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: | |||
|
Description
Peter Janakiev
2008-01-15 21:43:03 UTC
p4-clockmod doesn't actually save any power, and has a number of unexplained problems on some systems. I'm leaning towards just disabling it. (In reply to comment #1) > p4-clockmod doesn't actually save any power, and has a number of unexplained > problems on some systems. I'm leaning towards just disabling it. > I don't think we have a choice given the problems with it. Driver disabled in rawhide to see if anyone complains. Objection! First noticed the problem since updating F8 to 2.6.24.3-12.fc8 a few days ago. Therefore this late complaint. Asus EEE either has a fixed frequency setting of 630 MHz or (by loading p4-clockmod) you get the full frequency range from 112 to 900 MHz and cpuspeed support. I was using cpuspeed + p4-clockmod over a month now, and get not a single hang or crash. Best fix would be to reenable p4-clockmod but blacklisting it if possible. This is my vote for reenabling p4-clockmod. Please! having knobs to turn is pointless if they are either causing crashes on some systems or having no effect on others. The fact that the eee is appearing to be scaling speed is a misnomer. All it's doing is making work take longer to complete, which isn't saving you any power at all. Perhaps my comment was not accurate enough. I have no problem if the cpu cannot scale down below 630 MHz, as it is like Dave stated - it does not save power - everything just appears sluggish. With cpuspeed running it seemed to scale up to the full 900 Mhz. This was the reason I objected. Digging in deeper showed I was wrong. Wrote a simple calculating benchmark and ran it multiple times. Using 'time' showed: With p4-clockmod not loaded: * /proc/cpuinfo says cpu MHz = 630 * benchmark run time on average = 1m1s With p4-clockmod loaded and cpuspeed off: * /proc/cpuinfo says cpu MHz = 900 * benchmark run time on average = 1m1s With p4-clockmod loaded and cpuspeed on with MIN_SPEED/MAX_SPEED = 900000: * /proc/cpuinfo says cpu MHz = 900 * benchmark run time on average = 1m1s With p4-clockmod loaded and cpuspeed on with MIN_SPEED/MAX_SPEED = 675000: * /proc/cpuinfo says cpu MHz = 675 * benchmark run time on average = 1m23s So enabling p4-clockmod just raises the displayed MHz, but the cpu is not running any faster when displaying 900 instead of 630 MHz. The difference equals the underclocked/normal FSB ratio: 70 MHz underclocked/100 MHz normal. There is the possibility to overclock the fsb to 100 MHz instead of 70 MHz, where having cpuspeed would be nice, but as it is not guaranteed not to harm the EEE when running with 100 MHz FSB, not having p4-clockmod is not a big issue. Therefore, I am sorry and remove my objection. *** Bug 438326 has been marked as a duplicate of this bug. *** I'd like to add a minor complaint after I've exhausted my other easy paths with my desktop PC. I've got an HP with somewhat broken ACPI DSDT. When it reaches some heat threshold, I get an ACPI error message logged. Example: Feb 3 05:28:59 hostname kernel: ACPI Error (psargs-0355): [\_TZ_.THRM] Namespace lookup failure, AE_NOT_FOUND Feb 3 05:28:59 hostname kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_GPE._L1C] (Node f7d02450), AE_NOT_FOUND Feb 3 05:28:59 hostname kernel: ACPI Exception (evgpe-0576): AE_NOT_FOUND, while evaluating GPE method [_L1C] [20070126] Basically, the errors map to a bug (undeclared variable basically) in the DSDT that only occurs when the CPU crosses a temp. threshold. Since I'm not up to ACPI debugging (I tried), I've been experimenting with the onboard fan controller and running it at annoyingly high volume levels to reduce the amount of times this message is printed. Even with these step I get around 900 reports a day. Thats an improvement from 10,000's. In the past (up until Fedora 9 rawhide), I simply enabled p4-clockmod and regardless of comments in the source code (saying it doesn't save energy) it seemed to keep the CPU cool enough that the messages were in the <100 range per day. At least for me, the p4-clockmod seems to help reduce CPU heat during idle systems (not busy systems of course) and has resulted in 0% system lockups. I could use it back in standard distribution but will look in to compiling it as a load module without recompiling the whole kernel package. From my point of view the p4-clockmod is reducing power consumption. Maybe not much because of the high clock rates of the Pentium 4 structure itself but enough to let the CPU produce less heat at all. For sure the work takes longer if the speed is scaled down, but that is just normal. I'd like to remind that the cpu frequency scaling is just about that to reduce speed when the PC is idle or has less work to do. Furthermore it is pretty unusual to use the p4-clockmod with Eee PC when this is equipped with a Celeron CPU based upon the Intel Pentium M arch. Therefor the usage of the integrated acpi_cpufreq should be used. |