wmfire is supposed to allow independent monitoring of each CPU or core in an SMP system. In reality, it will never display information for the highest-numbered CPU or core. This is not a new bug; it appears to have existed for about 8 years. I have submitted a code fix to the project maintainer; I am filing this bug to notify the ebuild maintainer so he or she can keep an eye out for a new wmfire release. Reproducible: Always Steps to Reproduce: 1. Install wmfire on an SMP system. Start it up. 2. Hover your mouse cursor over wmfire. You should see a flaming indicator icon that tells you which stats wmfire is monitoring. CPU's or cores are represented by side-by-side dots: one dot for the first CPU, two for the second, etc. 3. Left-clicking will change the monitored stat. Left click until you see your second-highest CPU (3 dots on a quad core system). 4. Left click again. Actual Results: In the current release, the last CPU or core is skipped, and we are now monitoring memory usage (represented by a grid of many dots). Expected Results: The intended behaviour is that you should see your next CPU or core (4 dots on a quad-core system). As noted in description, I already have a fix coded and submitted to the project maintainer. case@rlyeh ~/DEV/dockapps/wmfire $ emerge --info /usr/lib64/portage/pym/portage/package/ebuild/config.py:353: UserWarning: 'cache.metadata_overlay.database' is deprecated: /etc/portage/modules (user_auxdbmodule, modules_file)) Portage 2.1.10.44 (default/linux/amd64/10.0, gcc-4.5.3, glibc-2.13-r4, 3.0.17-tuxonice-r1-rlyeh-v10-tuxonice x86_64) ================================================================= System uname: Linux-3.0.17-tuxonice-r1-rlyeh-v10-tuxonice-x86_64-AMD_A8-3510MX_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.0.3 Timestamp of tree: Sat, 04 Feb 2012 23:45:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.1.4-r3 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.1 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="rsync://rsync.gtlib.gatech.edu/gentoo ftp://ftp.gtlib.gatech.edu/pub/gentoo ftp://lug.mtu.edu/gentoo/ rsync://mirrors.rit.edu/gentoo/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" 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="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3dnow X a52 a53 aac aalib acl acpi alsa amd64 apng bash-completion berkdb bluetooth bzip2 cdparanoia cdr cli cracklib crypt cups cxx dbus dri ffmpeg fglrx firefox flac fortran gdbm gnome gpm gstreamer gtk gzip iconv ipv6 jpeg mmx modules mp3 mp4 mpeg mplayer mudflap multilib nautilus ncurses nls nptl nptlonly offensive ogg opengl openmp pam pcre png posix pppd python readline sdl session sse sse2 ssl svgalib sysfs tcpd threads tiff udev unicode v4l vorbis x264 xcomposite xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" 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 cgi cgid 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" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fglrx" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Thanks for the report! You can attach the patch here and I will add it to a revision bump, until a new upstream release (if any) happens.
(In reply to comment #1) > Thanks for the report! You can attach the patch here and I will add it to a > revision bump, until a new upstream release (if any) happens. I'd be happy to. I've also found another closely-related bug (it didn't show up with the command-line options I normally use, but I caught it during further testing). If you don't specify a CPU or core on the command-line, and browse through cores by clicking on wmfire, the first core doesn't show up. I have a fix for this bug, too. I just need to grab an older version from my RCS repository; my local source has some color palette enhancements I am working on that shouldn't be included with the bugfix. I should be able to get this to you tonight. Please forgive my ignorance, but I am new to Gentoo and I still need to RTFM on the proper Gentoo ways of doing things. What's the proper format for posting a patch? Can I just post my patched source file here as an attachment, or would a diff be more appropriate? Thanks!
Created attachment 303449 [details] patched wmfire.c The cleanest way to fix both SMP bugs seemed to be to split the "test" logic and return code in change_cpu()into a separate function, more_cpus(). This way, we can test for more CPU's to monitor before incrementing our current CPU. Return type of change_cpu() was changed to void to prevent confusion, since it no longer has meaningful information to return. Trying to simultaneously check and increment the current CPU was the root cause of the SMP issues. I also got rid of the cpu_av flag and replaced it with a special value for cpu_id, CPU_AV = -1. I then had to create another special value (CPU_NEXT) for the "which" arg to change_cpu(), so that the pre-existing special value of -1 wouldn't conflict with CPU_NEXT. This simplifies the logic in change_cpu()/more_cpus(), since it's now only maintaining one variable instead of two. A minor change to the main loop logic was required so that we call change_cpu() later in the process, after we've decided what we're going to monitor. This prevents skipping CPU's. All of this has the felicitous side effect that the "average cpu" monitor can now be specified on the command line with a flag of "-c -1", which was not possible previously.
Unified diffs are generally preferred, but after your work on this I made the patch myself :) wmfire-1.4-r2 is in tree, thanks for the report and fix!
(In reply to comment #4) > Unified diffs are generally preferred, but after your work on this I made the > patch myself :) > > wmfire-1.4-r2 is in tree, thanks for the report and fix! Thank you! I intend to contribute more in the future, so I will read up to on the proper gentoo procedures for patches.
