Ubuntu

Avoid acpi button event jitter by having a ignore-event timer

Reported by Ram Yalamanchili on 2006-07-15
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: acpi-support

The scenario:
The laptop lid is hooked to automatically put the laptop in sleep mode. (sleep.sh is called)

Now, close the lid, but you happened to close it intermittently (close-open-close quickly) or you have only half-closed the lid. Laptop goes into sleep mode and powers off nicely. But, when you open it again, you will notice it will go off into suspend again. This is because that quick open-close-open generated more than 1 lid close event and the sleep.sh script is being run multiple times.

The fix:

Keep track of when the last sleep.sh/hibernate.sh was completed, and ignore if suspend was called again within the last 10 secs or whatever.. I modified my sleep.sh in the following way, and hibernate.sh can be done in a similar fashion. Ideally this code should be somewhere in the backend where you dont repeatedly call sleep/hibernate multiple times within a given time frame.

--------------- START -------------------------
#!/bin/bash

# Check if sleep occured within the LASTOCCURED number of seconds
# If it did, then exit the script.
LASTOCCUREDSECS=10

# In-progress check
find /tmp/acpiSuspendInProgress &> /dev/null
if [ $? == 0 ]; then
    # Already started, exiting...
        echo "`date`: acpi: sleep.sh: Already in progress.. exiting" >> /tmp/acpiSuspendLog
    exit;
fi
touch /tmp/acpiSuspendInProgress
echo "`date`: acpi: sleep.sh: Starting suspend" >> /tmp/acpiSuspendLog

# Delay check
LAST_RUN=`date --reference=/tmp/acpiSuspendTracker +%s 2> /dev/null`
if [ $? == 0 ]; then
  TIME_NOW=`date +%s`
  DIFF=$(($TIME_NOW - $LAST_RUN))
  if [ $DIFF -le $LASTOCCUREDSECS ]; then
    rm -f /tmp/acpiSuspendInProgress
        echo "`date`: acpi: sleep.sh: Was called too soon ($DIFF seconds ago), exiting" >> /tmp/acpiSuspendLog
    exit;
  fi
fi

. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/device-funcs
. /usr/share/acpi-support/policy-funcs

DeviceConfig;

if [ x$ACPI_SLEEP != xtrue ] && [ x$1 != xforce ]; then
  exit;
fi

# If gnome-power-manager or klaptopdaemon are running, let them handle policy
if [ x$1 != xforce ] && [ x$1 != xsleep ] && [ `CheckPolicy` = 0 ]; then
    exit;
fi

if [ x$LOCK_SCREEN = xtrue ]; then
    if pidof xscreensaver > /dev/null; then
        for x in /tmp/.X11-unix/*; do
            displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
            getXuser;
            if [ x"$XAUTHORITY" != x"" ]; then
                export DISPLAY=":$displaynum"
                . /usr/share/acpi-support/screenblank
            fi
        done
    fi
fi

# Generic preparation code
. /etc/acpi/prepare.sh

if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
  hdparm -d 0 /dev/hda
fi

echo -n $ACPI_SLEEP_MODE >/sys/power/state

touch /tmp/acpiSuspendTracker
if [ x$RESET_DRIVE = xtrue ] && [ -b /dev/hda ]; then
    hdparm -w /dev/hda
    hdparm -C /dev/hda
    hdparm -C /dev/hda
    hdparm -C /dev/hda
    hdparm -d 1 /dev/hda
fi

if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
  hdparm -d 1 /dev/hda
fi

# Generic wakeup code
. /etc/acpi/resume.sh
touch /tmp/acpiSuspendTracker
rm -f /tmp/acpiSuspendInProgress
echo "`date`: acpi: sleep.sh: Completed resume" >> /tmp/acpiSuspendLog

Ram Yalamanchili (ramyinc) wrote :
Ram Yalamanchili (ramyinc) wrote :
Matt Zimmerman (mdz) wrote :

A couple of general issues with this patch:

- It uses hardcoded pathnames in /tmp, which would create a serious security vulnerability
- If it prevents an action, this is only logged to a new logfile which the user will never see

As to whether this is the correct way to solve the problem, I defer to the laptop team.

Matthew Garrett (mjg59) wrote :

Ought to be done in the power management frontend, rather than acpi-support

Ram Yalamanchili (ramyinc) wrote :

This is really just a POC to highlight the problem. The private log was interesting in my case:

Sat Jul 15 10:07:10 CEST 2006: acpi: sleep.sh: Starting suspend
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Completed resume
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Starting suspend
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Starting suspend
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Starting suspend
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Starting suspend
Sat Jul 15 10:07:34 CEST 2006: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting

You can see 4 consecutive acpi sleep requests immediately after resume. If they weren't ignored the laptop would possible go thru the routine 4 times at the minimum.

Can we get someone from power management to take a look at this?

Elliot Hughes (elliot-hughes) wrote :

Confirming as there is a patch written.

Changed in acpi-support:
status: Unconfirmed → Confirmed
Darryl Moore (darryl-moores) wrote :

I've had the same problem. Both with Ubuntu and previously with Fedora, on several computers too.

I applied this fix and it is way better!!!!

Here is the suspend log dump from the two times I suspended after applying this fix.

darryl@el-grande:~$ cat /tmp/acp*
Sun Jan 6 08:11:29 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Completed resume
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
darryl@el-grande:~$ cat /tmp/acp*
Sun Jan 6 08:11:29 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Completed resume
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 08:29:47 EST 2008: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sun Jan 6 08:37:22 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Completed resume
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Starting suspend
Sun Jan 6 19:53:54 EST 2008: acpi: sleep.sh: Was called too soon (0 seconds ago), exiting

Now I don't think it is just closing the lid that does this as I've had it happen as it did in the first set of log entries here when I use the logout menu button too. But even if there is a software bug somewhere causing too many calls to sleep, now I don't care.

Frankly this is a really easy fix for a really annoying problem. I'm rather disappointed that this fix has been sitting here for over a year and a half now and no one has seen fit to incorporate it into the main distro. At least raise the importance level to something better than "undecided" please.

Peping (peping110) wrote :

I'm here just to say something quite obvious. The bug also happens when several kinds of invoking the sleep event happen simultaneously, like pressing "Sleep" button and then closing the lid. When you open it, the laptop turns on, then goes to suspend again.
e
It's especially annoying if you change your open/close lid behaviour frequently and don't remember the current setting

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers