[haiku] Re: The refrigerator & light problem and an solution

  • From: "Cyan" <cyanh256@xxxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Tue, 06 Jan 2009 02:07:36 GMT

Mizsei Zoltán (miqlas) <miqlas@xxxxxxxxx> wrote:

> We need change the code, and if the is_computer_on() give 1 the
> ACPI need start the computer.
> (If the computer runs, nothing will happend.)
> If the is_computer_on() gives always 1 the computer always will
> starting automatically.
> But if not, the machine never start automatically. 
> This is the solvation of this problem.


This sounds like an interesting solution to the problem, but will it
pass the "paper test"?
The function listing (in assembler), along with any subroutines it
calls, must be printed out on paper, and the computer must be
powered-down. The listing should then be walked-through by hand,
keeping track of register and memory values on paper.

If the underlying function for is_computer_on() returns a value other
than 1, the startup routine is initiated. After powering-up the
computer though, the status must be monitored before deciding whether
to return 1 or an "undefined" value. If the power-up process was
found to have failed, the latter is chosen.

How the power status should be checked is another matter entirely,
and is the real underlying issue here. Perhaps one could check the
relevant register of the Super I/O chip to ensure that the PS_ON line
is asserted?

But even that poses a problem due to the very poor documentation
that Be provided -- if the power supply has been turned off via
PS_ON line but the system is still running due to power stored in
the capacitors, should it still always return 1? Even if some add-in
cards have entered reset due to insufficient voltage?

Perhaps instead one could check the power supply voltage monitoring
registers in the Super I/O to ensure a near-zero voltage on the
relevant rails? (which would be the case if the paper simulation
of the function is performed correctly...)

This wouldn't be completely fail-safe: in the event of a buggy
Super I/O, or a motherboard design which doesn't bother to route the
rails to the monitoring pins, the function may return false even
on a powered-up computer -- which could be extremely dangerous.


Also, there appears to be a problem with the is_computer_on_fire()
function in R5. When the computer is on fire, the function must
return the temperature of the motherboard (again due to poor
documentation, it isn't stated what units are used).

However, after expensive testing, it was found that the function
clearly does not behave anything like the documentation suggests.
The returned temperature did not correspond to the measured value
anywhere on the motherboard in any known unit, and the returned
value did not track temperature changes as the fire progressed.

The definition of "computer" is also unclear. Does it correspond to
any fire taking place within the chassis, including one started for
the purpose of cooking or warmth? Or specifically a fire caused by
burning wiring or connectors? (the most common type of computer fire)
Or perhaps a fire on the motherboard itself, with the components
acting as the fuel source?

Here's a practical code snippet which demonstrates just how lethal
this implementation of the function can be:


double mtemp, prev_mtemp = 0;
uint16 trend = 0;

/* To avoid false alarms due to cooking fumes. */
turn_smoke_alarms_off();

/* To avoid water damage due to malfunction of the sprinklers. */
disable_sprinkler_system();

for(;;) {

    snooze(1000);

    if( alarm_is_sounding() || sprinklers_discharging() ) {
        /* Once smoke is detected or the sprinklers trigger,
           there is almost certainly a fire and they must not
           be turned off. */
        continue;
    }

    mtemp = is_computer_on_fire();

    if( mtemp > prev_mtemp ) {
        /* Temperature might be rising. */
        trend++;
    } else {
        /* Temperature might be constant or falling. */
        if( trend ) trend--;
    }

    if( trend < 10 ) {
        /* Temperature seems to be constant or falling.
           Disable to the smoke alarms to avoid false-triggering
           and turn off the sprinklers for safety against water
           damage. */
        turn_smoke_alarms_off();
        disable_sprinkler_system();
    } else if( trend >= 30000 ) {
        /* Temperature seems to be mostly rising over the last
           ~30 seconds. This is potentially a cause for concern,
           so enable the safety measures. This does not trigger
           the alarms or sprinklers immediately: they will only
           trigger upon detecting smoke. */
        turn_smoke_alarms_on();
        enable_sprinkler_system();
        trend = 30000;
    }

    prev_mtemp = mtemp;
}


Other related posts: