https://bugzilla.novell.com/show_bug.cgi?id=361341 Summary: dbus "assumes" CPUFREQ module should be tried; even if not on CPUFREQ enabled kernel Product: openSUSE 10.3 Version: Final Platform: i686 OS/Version: openSUSE 10.3 Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: qa@suse.de Found By: Other In the rc.d/dbus script, there is a check for "CPUFREQ" -- if set to "no" or "off", it skips the attempt to load CPUFREQ. However, there is no place CPUFREQ could be set (there is no inclusion of a /etc/sysconfig/<file>). So CPUFREQ can NEVER have a value of "no" or "off". So on my non-CPUFREQ-capable P-III processor, I constantly get the "annoying" bootup message: "Loading CPUFreq modules (CPUFreq not supported)" um, like ya, duh, why does it even try? Aren't the only processors supporting cpufreq, "mobile" processors, at this time? Rub salt in the 'wound'....since I doubt Intel will go back and create a microcode patch to enable CPUFreq for non-mobile processors. Maybe the logic should be "positive"...like: if [ "$CPUFREQ" = "yes" -o "$CPUFREQ" = "on" ]; then .. Or *at least*, if you want to keep the negative logic, then this: if [ -n "$CPUFREQ" -a "$CPUFREQ" != "no" -a "$CPUFREQ" != "off" ]; then ... *and*, above in script "pre-log", include a /etc/sysconfig/dbus file. Then during setup, users with CPUFreq-capable processors can have CPUFREQ set to "true" (or on, or yes...)... while the (I'm guessing, here) majority of processors that are not "mobile w/ dynamic CPUFreq-ability" wouldn't need to set CPUFREQ to get "default=off" behavior. L. Walsh -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.