Bug 358354

Summary:	CPU frequency scaling not working after upgrade to latest kernel (2.6.16.54-0.2.5-default)
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Forgotten User B-7XM5iatA <forgotten_B-7XM5iatA>
Component:	Kernel	Assignee:	Thomas Renninger <trenn>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Critical
Priority:	P5 - None	CC:	daniel.lescohier, gp, hmuelle, mge, trenn
Version:	Final
Target Milestone:	---
Hardware:	x86
OS:	SuSE Linux 10.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Forgotten User B-7XM5iatA 2008-02-02 21:31:16 UTC

After update to kernel 2.6.16.54-0.2.5-default CPU frequency scaling stop working.
Following errormessage in the startprotocol:
Starting powersaved: /etc/init.d/powersaved: line 223:  3224 Segmentation fault      modprobe $MODULE >&/dev/null

Line 223 in /etc/init.d/powersaved 
for MODULE in $CPUFREQ_MODULES; do

Comment 1 Greg Kroah-Hartman 2008-02-04 15:27:28 UTC


*** This bug has been marked as a duplicate of bug 357598 ***

Comment 2 Thomas Renninger 2008-02-08 13:13:58 UTC

Mixed up kernel versions...
The duplicate is 10.3 and a totally other problem.

Hmm, 10.1 is rather old. It's not worth to take the effort and risk (to break other machines).
If you'd use SLES/SLED products it would be something else... and this has a good chance to be included in SP2 (and gets some QA testing then that other machines do not break because of the fix), but for 10.1, pls use the latest 11.0 Alpha/Beta versions. If the problem should persist, pls reopen the bug, adjust the product and this will get fixed for upstream inclusion.

Can you attach dmidecode of the machine, pls.

Comment 5 Gerald Pfeifer 2008-02-08 14:50:48 UTC

10.1 is going to get out of security updates in a few months and should
be of low priority.  At this point openSUSE users really should be migrating
to 10.2 or 10.3.

That said, introducing a regression is always bad and we should address this
unless it carries high effort or risk.  If it does, the advise is to go to
10.2 or 10.3.

Comment 6 Thomas Renninger 2008-02-09 11:22:09 UTC

Ah, I think I remember this one. I thought this never got into a official kernel release, I will look at it on Mo.
So, yes. This will get fixed for 10.1 as well.

Comment 7 Thomas Renninger 2008-02-10 21:25:19 UTC

*** Bug 359828 has been marked as a duplicate of this bug. ***

Comment 8 Thomas Renninger 2008-02-10 21:41:32 UTC

This should be the offending patch:
patches.arch/x86_64_powernow_display_cpus_correctly.patch
Fortunately this problem has been discovered (shortly) before SP1 came out (and it's not included there), but I forgot to remove it for SP2. This seem to be the reason how it has been found its way to 10.1 kernel.

I still want to have a closer look why booted_cores can be zero there and will remove it on Mo.

Comment 9 Thomas Renninger 2008-02-14 08:41:34 UTC

10.1 is SLES based, please try this kernel:
ftp.suse.com/pub/projects/kernel/kotd/SLES10_SP1_BRANCH/{x86_64,i386}/kernel-default.rpm

You can check the changelog rpm -qp --changelog kernel-xy.rpm |less
This is the fix:
* Mon Feb 11 2008 - trenn@suse.de
- patches.arch/x86_64_powernow_display_cpus_correctly.patch:
  Output cleanup for CPUs in powernow-k8 driver (#334743).
  Check for possible divide through zero.

The change will be in the next update kernel.