Description of problem: When playing with cpufreq init script, I have noticed that its 'status' method returns '1' (error) even if cpufreq subsystem was successfully initialized: $ ls -l /var/lock/subsys/cpufreq -rw-r--r-- 1 root root 0 Feb 20 19:54 /var/lock/subsys/cpufreq $ /etc/rc.d/init.d/cpufreq status ; echo $? 1 $ Looking at cpufreq init script, the problem is that 'status' method (as well as 'condrestart' one) checks for existence of /var/log/subsys/cpufreq file while /var/lock/subsys/cpufreq should be checked instead. After I manually modified cpufreq script in following way, it started to work as expected: $ diff -u /tmp/cpufreq.orig /tmp/cpufreq.fixed --- /tmp/cpufreq.orig 2012-02-20 21:34:58.558134198 +0100 +++ /tmp/cpufreq.fixed 2012-02-20 21:33:37.981979412 +0100 @@ -48,12 +48,12 @@ start ;; condrestart) - if [ -f /var/log/subsys/cpufreq ]; then + if [ -f /var/lock/subsys/cpufreq ]; then restart fi ;; status) - [ -f /var/log/subsys/cpufreq ] + [ -f /var/lock/subsys/cpufreq ] RETVAL=$? ;; *) $ How reproducible: Always Steps to Reproduce: See Description above
CC: (none) => dambi
CC: (none) => eandry, n54
I'm on it.
Fixed. It's in 1 core/updates_testing
Assignee: bugsquad => qa-bugs
(In reply to comment #1) > I'm on it. Would the cpufreq rpm be the one to fix bug 4196 ?
CC: (none) => junk_no_spam
(In reply to comment #2) > Fixed. > It's in 1 core/updates_testing One more change needed # service cpufreq condrestart /etc/init.d/cpufreq: line 52: restart: command not found The restart command should be changed to real_stop.
CC: (none) => davidwhodgins
Re-assigning back to developer. Please re-assign to qa after taking care of comment 4.
Assignee: qa-bugs => n54CC: (none) => qa-bugs
I will try to fix it again,
Fixed in Cauldron, please test.
CC: junk_no_spam => (none)
Assignee: n54 => qa-bugs
(In reply to comment #7) > Fixed in Cauldron, please test. This is a MGA1 bug, not CAuldron!
CC: (none) => lists.jjorge
(In reply to comment #8) > (In reply to comment #7) > > Fixed in Cauldron, please test. > > This is a MGA1 bug, not CAuldron! It is valid for Cauldron too.
(In reply to comment #9) > It is valid for Cauldron too. Ok, but saying please test in this bug report, without anything in updates_testing won't help.
(In reply to comment #7) > Fixed in Cauldron, please test. I've tested the version in cauldron, and all options work. The status doesn't provide any output, but now terminates with a return code of zero. Now we just need the Mageia 1 version updated.
(In reply to comment #11) > (In reply to comment #7) > > Fixed in Cauldron, please test. > > I've tested the version in cauldron, and all options work. > The status doesn't provide any output, but now terminates > with a return code of zero. > > Now we just need the Mageia 1 version updated. Thank you, I will push it into 1.
(In reply to comment #11) > Now we just need the Mageia 1 version updated. OK, the package is pushed into 1/updates_testing. Please validate it.
it's a recent patch for fixing this bug that make a critical one ? https://bugs.mageia.org/show_bug.cgi?id=4772
(In reply to comment #14) > it's a recent patch for fixing this bug that make a critical one ? > https://bugs.mageia.org/show_bug.cgi?id=4772 I really doubt it. It could be related to kernel or hardware.
(In reply to comment #14) > it's a recent patch for fixing this bug that make a critical one ? > https://bugs.mageia.org/show_bug.cgi?id=4772 The patch isn't changing anything just condrestart and status.
The latest update also changed the default from performance to on-demand. That should be mentioned in an advisory. Testing complete on i586 for the srpm cpufreq-1.0-35.2.mga1.src.rpm Checked "service cpufreq start|stop|restart|condrestart|status" Although the status doesn't return any output, running echo $? right after the service cpufreq status is returning zero.
(In reply to comment #17) > The latest update also changed the default from performance > to on-demand. That should be mentioned in an advisory. > What? cpufreq point is to activate on_demand on processors to support it. It has never defaulted to performace, as this is simply default without cpufreq...
(In reply to comment #18) > (In reply to comment #17) > > The latest update also changed the default from performance > > to on-demand. That should be mentioned in an advisory. > > > What? cpufreq point is to activate on_demand on processors to support it. It > has never defaulted to performace, as this is simply default without cpufreq... Sorry, my mistake. I must have modified it previously and forgotten.
Testing x86_64 # service cpufreq start Setting CPU frequency settings: [ OK ] # service cpufreq stop # service cpufreq status # service cpufreq condrestart Resetting CPU frequency settings: [ OK ] Setting CPU frequency settings: [ OK ] # service cpufreq condrestart Resetting CPU frequency settings: [ OK ] Setting CPU frequency settings: [ OK ] # service cpufreq status # service cpufreq restart Resetting CPU frequency settings: [ OK ] Setting CPU frequency settings: [ OK ] # service cpufreq status # I don't know if this means it is working properly. Condrestart now does something, as does start and restart. Status and Stop appear to do nothing. # ll /var/lock/subsys/cpufreq -rw-r--r-- 1 root root 0 Mar 22 14:12 /var/lock/subsys/cpufreq # service cpufreq stop # ll /var/lock/subsys/cpufreq -rw-r--r-- 1 root root 0 Mar 22 14:12 /var/lock/subsys/cpufreq The stop case is empty in the init script, I think it should probably also be real_stop
After changing it to real_stop.. # service cpufreq stop Resetting CPU frequency settings: [ OK ] # ll /var/lock/subsys/cpufreq ls: cannot access /var/lock/subsys/cpufreq: No such file or directory
Please reassign when you've had a chance to look at this Kamil. Thanks.
Assignee: qa-bugs => n54
OK, I will have a look.
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
As far as I've followed, this was fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED