Dotan Cohen posted on Sun, 13 Feb 2011 21:36:49 +0200 as excerpted:
> So is there any way to leave it at wide open throttle, i.e. 2.7 GHz?
> Because locking it at 1000 MHz is ridiculous, I can barely use this
> machine.
Makes sense. See below.
> Great, but until they actually work and don't leave me crippled at 1000
> MHz at least let me manually override it. On which KDE component should
> I file a bug? Or should I file at my distro (Kubuntu)?
Kubuntu... let's just say doesn't exactly have the reputation of having
the smoothest or best working distro-packaged kde out there. I understand
there's resource and political issues that make it so, so don't hold it
against the folks putting out the product, but pretty much everyone I've
read seems to agree that kubuntu isn't the best choice for those wanting a
good kde4 experience. One alternative allowing you to keep kubuntu
untouched but testing something else would be to try a LiveCD/DVD version
from a different distro. If it has the same problem, it's probably an
upstream bug. If not, it's possibly a distro bug.
Filing a bug: At least with Gentoo, the general policy is file with the
distro first, just in case it's a distro patch or policy that's the
problem. The gentoo package maintainer will generally recommend filing it
upstream if it's appropriate. However, gentoo's a rolling release on
which several versions of a particular package (or metapackage, desktop
environment in this case) are available, from bleeding edge, either in
~arch/testing or in an overlay, to at least one and often several older
stable versions.
With a semi-annual bin-based distro like kubuntu, which tends to sync and
test everything shipped with a release and mainly support the release-
shipped version, I'd expect it to be more likely for bugs to remain
unaddressed until they basically expire -- newer versions potentially
fixing the problem are available in the newer release. Particularly for
kubuntu, given the factors above.
But that's simply my general opinion. You're the one with kubuntu
experience. Anyway, see below...
>> What may have happened, however, is that kde 4.6 is actually out in
>> front of the other changes, particularly if you're not running equally
>> new kernels and lower-level user-space, so the choice is removed, but
>> the capacity hasn't yet been, so some upgrade installs are getting
>> locked at the last set cpu frequencies, until either the rest of the
>> system catches up, or until the last set config is removed.
>>
>>
> It's a fairly recent kernel:
> uâganymede:~$ uname -a
> Linux ganymede 2.6.35-25-generic-pae #44-Ubuntu SMP Fri Jan 21 19:01:46
> UTC 2011 i686 GNU/Linux
> âganymede:~$
<smile> You must understand that you're talking to someone who isn't yet
running 2.6.38 git-kernels mainly due to lack of time this cycle. I'm
still on 2.6.37, and feel rather behind at that.
2.6.35 is indeed reasonably upto date for a distro kernel, I'll agree.
However, my point was that kde4 does seem to work best when the entire
system is kept reasonably synced, and 2.6.35 was released... google says
early Aug, 2010. That would put it more in line with kde 4.5 than 4.6.
2.6.37 was released shortly before kde 4.6, and kde does seem to be
forward looking, so I'd suggest an equally new kernel 2.6.37 to go with
the new kde 4.6.
The 4.6 switch to udev/udisks/upower/etc probably means they should be
reasonably upto date as well. For reference, here's the versions I'm
running: upower-0.9.8 udisks-1.0.2 udev-164-r1 (the -r1 being the gentoo
revision, it's 164 upstream).
Not saying that the newest will fix everything, and of course they may
bring their own problems if updated while the rest of the install remains
at the release, just sayin' that waiting for a 4.6 that presumably ships
as part of a kubuntu release (I'm presuming 4.6 was an upgrade of an
existing install on the same distro release) may well get you a better
tested-to-work-together platform.
> And I've removed all the config files, still the problem exists.
This is what all those "see below" comments were about...
You tried with a clean user (clean $HOME, so new user or backed up and
deleted $HOME)? Or just the obvious config files?
If the former, than it looks to be a problem at the system level. That's
a whole different beast. Next thing I'd try in that case is whether
booting to a CLI, without starting X (no xdm/kdm/etc) at all, still CPU-
freq limits you. If so, it can hardly be KDE or X. If not, I'd strongly
suspect an issue with the system-wide kde config. That's normally found
in $KDEPREFIX/share, so probably either /usr/share, /usr/local/share, or
/opt/share, depending on where your distro or your own build put it. (A
kde session gets its config from built-in, system-level, and user-level,
with each level normally superseding the former, if both exist. If you've
tried with a clean user, that means the system-level config is the next
suspect.)
If you haven't, recently, you might also think about taking apart your
hardware and checking to see if it needs cleaned. Perhaps the CPU heatsink
is clogged with dust, the CPU is throttling to prevent overheating, and
the timing just happened to line up with your kde 4.6 install. That's
certainly not unheard of. (Tech sites occasionally run features where
they post horror story photos of systems readers, generally admins or tech
support brought the system to fix because it was running slow or wouldn't
boot, have had to clean out... Let's just say you don't want to be eating
while you're reading such articles...)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
