Ever since the introduction of the CONFIG_HZ_1000 option, my hyperthreaded P4
laptop has been unable to run the kernels because they're excruciatingly slow!
I tracked down this bug on kernel.org:
which offers two patches to fix the problem.
apparently its not related to all HT systems, only some.
be careful, as it stuffed suspend and resume for me, which used to work flawlessly.
I've tried 2.6.13 gentoo r2, r3, & r5 - same results with all.
I applied the patches mentioned on bugzilla.kernel.org to 2.6.13-gentoo-r3.
Steps to Reproduce:
1. compile any 2.6.13 kernel
2. boot to said kernel
From boot, kernel entire system runst about 10x slower.
$ emerge info
Portage 2.0.53_rc6 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2,
System uname: 2.6.13-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.12.0_pre9
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python: 2.3.5, 2.4.2
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
CFLAGS="-march=pentium4 -O2 -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c
CXXFLAGS="-march=pentium4 -O2 -pipe"
FEATURES="autoconfig distlocks fixpackages sandbox sfperms strict"
USE="x86 X acpi alsa apache2 arts avi bash-completion berkdb bitmap-fonts
bluetooth cdr crypt cups curl directfb dvd dvdr eds emboss encode esd evo fam
flac foomaticdb fortran ftp gdbm gif gnome gpm gstreamer gtk gtk2 guile
imagemagick imlib ipv6 irmc java jpeg libg++ libwww mad mikmod mmx motif mozilla
mozsvg mp3 mpeg mysql ncurses nfs nls ogg oggvorbis opengl pam pdflib perl php
png postgres python quicktime readline samba sdl spell sse ssl svg svga tcltk
tcpd tetex tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs xml
xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
The patches on that bug are not upstream yet the bug is marked as CODE_FIX.
Could you please test 2.6.14 and see if the bug has been fixed another way?
> The patches on that bug are not upstream yet the bug is marked as CODE_FIX.
oh, I was only guessing what upstream means exactly.
> Could you please test 2.6.14 and see if the bug has been fixed another way?
OK, I tried vanilla 2.6.14_rc5, and it has the same behaviour (takes very long
to boot, gdm takes 30s or more to display login screen, etc). Should I follow
this up here, or at http://bugzilla.kernel.org/show_bug.cgi?id=5165 or both?
Funny thing, it _seems_ to be 10x slower, but sound still plays ok, and typing
on keyboard is still ok, but I don't know much about these things...
will track upstream bug
It can also be much slower. Doing this: dd if=/dev/urandom of=/dev/null bs=1M
count=4 takes less than a second on my healthy system and about 43 seconds on
the slowed-down one.
I can also confirm the bug is still there with gentoo-sources-2.6.14-r2. Please
change the resolution to something different than RESOLVED UPSTREAM (as it is
I just installed vanilla-sources 2.6.15_rc1, and the "slowness" is still there.
Aforementioned patches still work however.
> Please change the resolution to something different than RESOLVED UPSTREAM (as
it is *not*).
I think it's marked RESOLVED UPSTREAM because
> will track upstream bug
ie. there's no point in having two bugs for it, so lets track the upstream one.
However, I don't use bugzilla all that much, so this interpretation may be wrong :)
> I think it's marked RESOLVED UPSTREAM because
> > will track upstream bug
> ie. there's no point in having two bugs for it, so lets track the upstream one.
Well, if we were just watching vanilla kernel sources, than yes, you'd probably
be right. But since we're looking into gentoo-sources, which have their own
patchset, than I guess the patches fixing this error could go into
gentoo-sources as well. If they break swsuspend2 than it should be perhaps be
done via exclusive USE flags (fix my hyperthreading || have swsuspend working).
Still -- baffles the blimpers out of me, how such a *serious* bug could persist
in at least two releases of the kernel. Anybody listening out there?
I don't have a good knowledge of ACPI, and I don't have much clue about the
implications of those patches.
There may well be a reason that they are in the test tree and *not* yet in
Without being able to fully understand the patches, I won't add them to
gentoo-sources until they are pushed to Linus' tree (which generally means they
are fully expected to work). This is standard policy for gentoo-sources. Sorry
for the inconvenience this bug is causing you, I expect it will be fixed soon...
*** Bug 112604 has been marked as a duplicate of this bug. ***
The bug I entered, 112604, was marked a duplicate of this bug. However in that
bug, I state that using "top" or cat /proc/cpuinfo shows that the second
processor IS NOT THERE. Has 2.6.13 changed so that an HT processor now only
shows up as one processor? If you guy still see two processor in /proc/cpuinfo,
please unmark that bug as a duplicate and reopen it.
Fixed in genpatches-2.6.14-5 / gentoo-sources-2.6.14-r4