Comment 717 for bug 59695

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

There's further problems that need fixing.
/etc/acpi/start.d/90-hdparm.sh uses getState() from
/usr/share/acpi-support/power-funcs to set STATE. 90-hdparm.sh says if
$STATE is BATTERY then -B 128 else -B 254. That's fine. But
power-funcs has

    getState() {
            /usr/bin/on_ac_power;
            if [ "$?" -eq 0 ]; then
                    STATE="AC";
            elif [ "$?" -eq 1 ]; then
                    STATE="BATTERY";
            fi
    }

(Ignore the trailing semi-colons.)

/usr/bin/on_ac_power(1) defines its exit value as 0, 1, or 255. 0 =
mains. 1 = not mains. 255 = could not be determined. The above code
doesn't save $? after running on_ac_power so the first test, whether it
is 0, tramples $? by the time the elif test is run. Here's the `sh -x'
output.

    + /usr/bin/on_ac_power
    + '[' 255 -eq 0 ']'
    + '[' 1 -eq 1 ']'
    + STATE=BATTERY

See how the 255 from on_ac_power has been trampled to 1. So when
on_ac_power exits non-0 we have STATE=BATTERY. Here's one possible fix.

    getState() {
        /usr/bin/on_ac_power
        case $? in
        0) STATE=AC;;
        1) STATE=BATTERY;; # Strictly, not mains.
        *) STATE=UNKNOWN;; # 255 and future ones.
        esac
    }

It's because STATE is erroneously being set to BATTERY that 90-hdparm.sh
is using -B 128:

      if hdparm -i $dev 2> /dev/null | grep -q 'AdvancedPM=yes' ; then
        if [ $STATE = "BATTERY" ] ; then
          hdparm -B 128 $dev
        else
          hdparm -B 254 $dev
        fi
      fi

Fix that, and I return to 254, avoiding the `excessive head load/unload
cycles' 90-hdparm.sh warns against.

As it stands getState() is badly broken causing BATTERY behaviour on
desktop machines.