Hi, I'm running on amd64 and openrc with cpufreq. Each time I want to shutdown Gentoo, the process hangs at ============== *snip* ============== Running cpufreq-set --governor performance... ============== *snap* ============== and the only thing I can do is hard-power off the machine. No idea how to track down the problem. Hints, anyone? Cheers, Nico Reproducible: Always
Does it hang when you try to restart the cpufreq init script manually?
Yes. The output is =================== *snip =================== * Stopping CPU Frequency Daemon... * start-stop-daemon: 1 process refused to stop [ !! ] * ERROR: cpufreqd failed to stop =================== *snap =================== and the syslog says =================== *snip =================== Jul 25 16:15:35 N5 cpufreqd: term_handler : Caught TERM signal (Terminated), forcing exit. Jul 25 16:15:42 N5 /etc/init.d/cpufreqd[6603]: start-stop-daemon: 1 process refused to stop Jul 25 16:15:42 N5 /etc/init.d/cpufreqd[6593]: ERROR: cpufreqd failed to stop =================== *snap ===================
Alright, I just tried sys-power/cpufreqd-2.2.1 and that fixes the error for me. Marking as WORKSFORME. Cheers, Nico
Oh dear, this is puzzling. Upgrading solved the issue for exactly *one* reboot, now it appears back again. I have not the slightest idea where issue may be rooted.
How about using 'ps ax' to show what state cpufreqd process is in? Have you checked for any kernel complaints with 'dmesg' after attempting to stop cpufreqd? Also, please post your 'emerge --info' output.
Hi, thanks for the feedback. `dmesg` doesn't say anything, but I guess the syslog (see commen #0) is more verbose anyway. `ps ax` tell me that ================= *snip* ================= 5265 ? Dsl 0:00 /usr/sbin/cpufreqd -f /etc/cpufreqd.conf ================= *snap* ================= -- from `man ps` I gather the capital D means "Uninterruptible sleep (usually IO)" which I guess is another work for crash (?). My `emerge --info`: Portage 2.2_rc33 (default/linux/amd64/2008.0/desktop, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.30.1 x86_64) ================================================================= System uname: Linux-2.6.30.1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T7300_@_2.00GHz-with-glibc2.2.5 Timestamp of tree: Sun, 26 Jul 2009 07:45:02 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.5.4-r3 dev-python/pycrypto: 2.0.1-r8 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.3-r2 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="en_US.utf-8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/misc /usr/local/portage/kde-testing /usr/local/portage/sectools /var/paludis/repositories/java-overlay /var/paludis/repositories/science /usr/local/portage/java-experimental" SYNC="rsync://rsync.samerica.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi aiglx alsa amd64 apache2 audiofile berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus divx dri dvd dvdread eds emboss encode evo fam ffmpeg fftw firefox fortran ftp gdbm gif gpm gstreamer hal iconv ifc imagemagick isdnlog isight jack java javascript jikes jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kdexdeltas ldap libnotify live mad midi mikmod minimal mmx mmxext mp3 mpeg mudflap multilib musepack nas ncurses nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl plotutils png ppds pppd python qt3 qt3support qt4 quicktime readline reflection samba sdl session speex spell spl sse sse2 ssl ssse3 startup-notification svg sysfs tcpd theora tiff truetype unicode usb vcd videos vorbis wifi wmp xine xml xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="all" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
'D' state is not the same as "crash"; if you run 'ps' while a normal process is doing lots of I/O (e.g. a big 'find' command) you will sometimes see it in 'D' state while waiting for data from the hard drive. Having a process stay in 'D' mode is bad news though, for two reasons. One reason is that you've got a process that you can't get rid of; the other reason is that the problem must involve the kernel (or possibly hardware). A properly behaving kernel will finish the I/O request and bring the process back to interruptible state, so that it is able to be killed if necessary. Is this a fairly new system where this hang problem has been there the whole time? Or did it used to work, perhaps when you used an older version of the kernel (if so which one)?
Ah, the kernel.. Well, the laptop is about two years old, so I guess you can't really call this bleeding edge anymore. It's a custom configured kernel, though, and I might not have taken extra care of which options I pulled in and which I didn't. Let's say I look into the kernel and play around with what's there, and report back when I found a trigger that resolves the problem. Cheers, Nico
Okay, I was now able to restart twice consecutively, which I hope means that the problem is solved. cpufreqd needs either (or both?) of the kernel options Deprecated /proc/acpi files Deprecated power /proc/acpi directories activated to work. Can you confirm this? Cheers, Nico
Looking at http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg197695.html and http://cpufreqd.sourceforge.net/need/ and http://linux.die.net/man/5/cpufreqd.conf it seems actually quite likely hat /proc/acpi is the killer.
Yes! Sounds like you've got it. Ok to close this as Fixed?
Hm, yeah, why not prevent other users from bumping into this by adding CONFIG_CHECK="ACPI_PROCFS" to the pkg_setup() of the ebuild?
Ok, assigning suggestion to cpufreqd maintainers. Maybe it would be even better to do a post-install einfo unconditionally. A new kernel might be installed with a different config later on, and then cpufreqd starts acting wonky, and then the user could look back for messages from cpufreqd (or just notice it in the ebuild).
Hi, quite surprisingly, I was able to reproduce the bug *again*. :/ In kernel, I have <M> 'powersave' governor as a module. When then trying to (manually) cpufreq-set -g powersave the cpufreq process would just go into 'D' state and not come back. I guess this is also what happened all the time before: cpufreqd tried to set the CPUs to powersave b/c the power cable was unplugged or something, thus sending cpufreq to Nirvana. When I go <*> 'powersave' governor and set cpufreq-set -g powersave all I get is ================ *snip* ================ Error setting new values. Common errors: - Do you have proper administration rights? (super-user?) - Is the governor you requested available and modprobed? - Trying to set an invalid policy? - Trying to set a specific frequency, but userspace governor is not available, for example because of hardware which cannot be set to a specific frequency or because the userspace governor isn't loaded? ================ *snap* ================ Anybody who can make sense of this? Cheers, Nico
Not sure if this is the same bug: I compiled a 2.6.30 kernel, and any of the following command hangs as you described: cpufreq-set -g ondemand cpufreq-set -g performance cpufreq-info cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor I also can't kill them. Well, I'm playing with some config settings atm, maybe I can resolve it. cpufrequtils 005.
Ok, my problem went away when I didn't compile the kernel with -O3 -march=native :-)
this looks like its mostly a kernel issue. could somebody report it to bugs.kernel.org (check for duplicates first)... thanks.
