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: http://bugzilla.kernel.org/show_bug.cgi?id=5165 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. Reproducible: Always Steps to Reproduce: 1. compile any 2.6.13 kernel 2. boot to said kernel Actual Results: 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, 2.6.13-gentoo-r3 i686) ================================================================= 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-apps/sandbox: 1.2.13 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 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" 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 /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="ftp://arion/pub/gentoo-portage/ ssh://gauntlet.pcorp.com.au/usr/portage/ ftp://mirror.isp.net.au/pub/gentoo/ ftp://gg3.net/pub/linux/gentoo/ ftp://gentoo.ccccom.com ftp://ftp.ussg.iu.edu/pub/linux/gentoo" LANG="en_AU" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" 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 *not*). Thanks, [a]
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.
> 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? [a]
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 Linus' tree. 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 upstream
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c0335526c95d90a1d958e0059f40a5745fc7c5d http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6d93c64803a5fea84839789aae13290419c62d92
Fixed in genpatches-2.6.14-5 / gentoo-sources-2.6.14-r4