https://bugzilla.novell.com/show_bug.cgi?id=436717 Michal Seben changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mseben@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |kernel-maintainers@forge.provo.novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c1 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Priority|P5 - None |P1 - Urgent --- Comment #1 from Thomas Renninger 2008-11-25 05:16:59 MST --- Can you provide dmesg output and full hwinfo output, please. Does this always and immediately happen after boot or only after a while (ten minutes or so)? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c2 Robert Davies changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rob.opensuse.linux@googlemail.com --- Comment #2 from Robert Davies 2008-12-22 17:26:36 MST --- This occurs generally with AMD 64 X2 CPUs ( see forum thread http://forums.opensuse.org/applications/402695-kde-sysinfo-incorrect-output.... ), but I have a viable workround giving full SMP operation at full operating speed. alter your boot command line, by altering the GRUB info for the 11.1 kernel. When the kernel update to fix comes out, you'll be able to turn CPUFREQ back on for power-saving and cooler running mode. rob@fir:~> cat /proc/cmdline root=/dev/System/Root resume=/dev/sdb5 splash=silent showopts vga=0x346 CPUFREQ=no rob@fir:~> egrep 'model|cpu|bogo' /proc/cpuinfo cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ cpu MHz : 2812.692 cpu cores : 2 cpuid level : 1 bogomips : 5625.38 cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ cpu MHz : 2812.692 cpu cores : 2 cpuid level : 1 bogomips : 5625.45 fir:/mnt/home/rob # So add CPUFREQ=no to turn off, the slowness, it really made things noticeably faster for me. My GRUB entry for the 11.1 kernel now reads : title openSUSE 11.1 root (hd1,7) kernel /vmlinuz-2.6.27.7-9-default root=/dev/System/Root resume=/dev/sdb5 splash=silent showopts vga=0x346 CPUFREQ=no initrd /initrd-2.6.27.7-9-default Edit/Delete Message Reply With Quote Quick reply to this message -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c4 --- Comment #4 from Robert Davies 2008-12-22 17:30:49 MST --- Created an attachment (id=262047) --> (https://bugzilla.novell.com/attachment.cgi?id=262047) boot.msg log file This is without CPUFREQ=no -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c6 --- Comment #6 from Robert Davies 2008-12-22 17:37:23 MST --- Boot up, opening windows and starting firefox seemed much quicker, so I think Matjaz Drolc report is right, it is limiting system speed, no matter what,rather than just showing 1,000 Mhz when looking. I would expect Bogomips, not to be happening in power saving mode to, which backs up the claim. This bug has made it into 11.1 GM :( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c7 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joachim.deguara@amd.com Status|ASSIGNED |NEEDINFO Info Provider| |mdrolc@gmail.com --- Comment #7 from Thomas Renninger 2008-12-23 09:20:45 MST --- You can watch/monitor cpufreq easily on command-line: watch -n1 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_{cur_freq,max_freq} Then you have the current and maximum allowed frequency shown every second. This is a BIOS issue or say a OS communication problem with the BIOS. Best: attach acpidump output. Then search and eventually update to the latest BIOS. Then again attach acpidump output. If this still happens then, there are generally 2 possibilities why/how BIOS is setting this: - passive cooling (passive trip-point exceeded), do: watch -n1 cat /proc/acpi/thermal_zone/THRM/{temperature,trip_points} You there see the current temperature and eventually a passive trip point. If the passive trip point is exceeded, the OS starts to lower the max_freq value. Please attach/paste output of: cat /proc/acpi/thermal_zone/THRM/{temperature,trip_points} - _PPC tell the OS which frequencies are allowed to be used. Try boot param: processor.ignore_ppc=1 Double check whether the parameter really got set: cat /sys/module/processor/parameters/ignore_ppc Does it work now? Is: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq set to the real max now?

This bug has made it into 11.1 GM Hey guys, I set the prio to 1, this is the maximum I can set it to. There was no answer for a month. I really like to find the root cause, if you also do and you are willing to invest a bit of time, let's track this one down in the next year. An update kernel for 11.1 should pop up pretty soon. Thanks.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c8 --- Comment #8 from Robert Davies 2008-12-23 10:46:46 MST --- My testing of 11.1-RC1 on x86_64 was pretty much it installed, few nits but system fixable. I noticed the 1Ghz frequence, and poor bogomips, but presumed (rightly) that it'd been noticed, and was probably just false reporting. I can understand frustration on not receiving info requested back. On older systems, hpt366 and pdc202xx_old with pata_ ATA drivers, the boxes couldn't be installed without workround, kernel fixes to pata_ or alteration of the kernel configuration, so I kept the 64bit box stable on 10.3. Now if the governor is changing frequency, why is the kernel bogomips, calculated early in the boot process so pathetic? Clean boot, and with CPUFREQ=no I noticed terminal window much snappier, then Firefox started about twice as fast. So it's very plausible to me that he CPUs were running 2.8x as fast as before. Of course I should do CPU intensive benchmarks to check. I have AMD Live, the Cool N' Quiet stuff, might be why I see same thing as laptop. Thanks for the tip, I'll try and confirm it's locked, later this evening. If this bug is there as it appeared, then it's another kernel biggie as far as I'm concerned, and could explain some ppl's performance complaints I've seen on forum. So if SuSE Novell really don't have any AMD 64 X2 boxen despite my Dell Inspiron 531 being certified for SLED/SLES, then I guess I'll have to make time to sort this. I installed the latest Dell BIOS, as it has urgent fix status, and I sometimes run windows, I notice it's been compiled to the bytecode with the M$ compiler. I complained last year, as a 1.0.3 BIOS update to 1.0.8 caused trouble, and Dell ended up having to give me a new Mobo. Will report soon. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c10 Robert Davies changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|mdrolc@gmail.com | Priority|P1 - Urgent |P3 - Medium --- Comment #10 from Robert Davies 2008-12-23 12:26:05 MST --- fir:~ # cat /proc/acpi/thermal_zone/THRM/{temperature,trip_points} temperature: 15 C critical (S5): 95 C passive: 75 C: tc1=4 tc2=3 tsp=60 devices=CPU0 active[0]: 75 C: devices= FAN The good news is, I've seen it bump up from 1000 sometimes. This is what I'm running, 2 long running md5sum's simultaneously, so almost all the time, there's no output because it's stuck on 1,000 Mhz but some of the time it does get up to max speed, but rarely. while (true); do cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | grep -v 1000000; done It's not locked to the lowest speed. What's happening is that it's on the lowest speed, even if there's only 30% idle time on both CPUs (1 doing i/o wait, the other blocking on i/o idle which makes sense). What I would expect is for the CPU to be on max frequency, and go idle, rather than go slow, and idle less for max power saving. There's obviously sampling problems here, because if it's at lowest frequency when idle, and then you get a chance to sample the speed it's going to mostly sample when it's going slow. 2 simultaneous, "cat /dev/urandom | md5sum" put the frequency up to the max reliably. top shows less than < 0.1% idle time on both CPUs. So I would say the bug I'm seing is the reported frequency from /proc/cpuinfo and the bogomips value, also the way the current frequency works. So now frankly I'd want better evidence, that this is a real performance issue, due to CPUFREQ and not just the kernel reporting information in a way that "disturbs" the user. I would suggest to lower the priority, and panic over. Personally if this becomes my bug, I'd change title to CPU speed reporting locked. It'd be better if the recent_max_freq was reported, something like the highest freq used, in the last 2 seconds. Because it does give the impression that it runs slow almost all the time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

despite my Dell Inspiron 531 being certified for SLED/SLES This one is certified? Then we should have one somewhere around, I try to find

From your initial bug description: But the following command shoud output 1800000: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 800000 It looks like we have more than a sampling or say cpufreq algorithm problem. If scaling_max_freq is lowered to the lowest the dynamic freq algorithm can't do anything and cur_freq will always stay at lowest. It looks like you only run into this sometimes (maybe this got fixed with the latest BIOS?)? If not set through a BIOS option (you might want to check your BIOS configs),

https://bugzilla.novell.com/show_bug.cgi?id=436717 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c12 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |behlert@novell.com, daniel.rahn@novell.com --- Comment #12 from Thomas Renninger 2008-12-26 04:23:20 MST --- that out. Daniel/Stefan, can you help? this looks like a bug. Instead of:

while (true); do cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | grep -v 1000000; done you might want to use: watch -n1 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_{cur_freq,max_freq} to monitor current and maximum frequency. watch -n1 refreshes the output every second.

For the algorithm: I want to look closer at this, but did not have the time yet. The load threshold when to switch up the frequency and a patch series for improved sampling on no_hz kernels I'd still like to test for SLE11 (which would get integrated/backported into 11.1 then also). Benchmarking power vs performance is time consuming, but we have some nice tools now and I hope to be able to work on that soon. For this bug report I'd only like to examine the situation when max_freq gets lowered. Do you use libsensors? This might falsify ACPI temperature readings and could cause the kernel to lower max_freq, due to wrong, high temperature values. If you could reproduce when/why max_freq gets lowered (or if at all with the new BIOS), this would be great. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717

User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=436717#c18


Thomas Renninger  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID




--- Comment #18 from Thomas Renninger   2009-01-13 16:18:35 MST ---
We have a system, but cannot reproduce the problem.
This is all about the initial description:
> But the following command shoud output 1800000:
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> 800000
I expect that this is due to:
  - A bad BIOS config (unlikely, would be fixed high freq, if e.g. PowerNow is
    switched off, maybe you even have a fixed low BIOS option accidently
enabled)
  - An old broken BIOS
If you should still run into this with latest BIOS, try to find a way to
reproduce it and reopen the bug.

Robert: About general cpufreq performance is currently looked at, but the bug
is about frequency being stuck totally at lowest freq ->

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c23 --- Comment #23 from Thomas Renninger 2009-01-20 08:48:08 MST --- About bad cpufreq performance..., I have an idea what it could be. Can you please post: cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=436717 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=436717#c25 --- Comment #25 from Thomas Renninger 2009-01-20 12:46:41 MST --- This is the bug. You have a sampling rate of 1240000 us, means 1.2 seconds. That means the ondemand kernel cpufreq governor/thread, looks only every 1.2 seconds whether the cpu frequency should be switched up. The ondemand governor tries to calculate the value from the HW switching latency it gets from the cpu low level driver (powernow-k8 in your case). We used to override the value to 333ms (instead of your 1.2 seconds), thus older OpenSUSE distributions did not run into that. Thanks a lot for the values. This will be handled/fixed by a kernel update soon. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.