On 2008-08-02, Robert Rappaport wrote:
> I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
> kernel. It has acpi, acpid and acpitool installed and operating in their
> default state. The problem is that when I close the lid to take a break
> it puts the computer into some kind of sleep/hibernation state that
> blanks the screen and I am unable to recover an operating screen on
> reopening the lid without rebooting.
>
> Can anyone suggest some course of action so that I can close and reopen
> the lid without this problem.

Bob,

you don't say exactly what you want to happen... do you want the
machine to suspend so that it will wake up properly when you open the
lid, or do you want the machine to keep running?

While I don't have a 10.2 lying around any more, in either case, take
a peek at /etc/acpi/acpi_handler.sh if you have it on your system. If
it is there, it is a shell script which handles such events, and you
may be able to figure out what parts you want to comment out (if you
don't want the machine to do anything) or fix (if you want the machine
to suspend).

A number of machines won't properly initialize the video after a
suspend to RAM if X is running, so a work-around that has worked for
me is to put a
chvt 1
before the code which suspends to RAM and a
chvt 7
after that code.

Anyway, if you give some more details, you can probably get more
specific answers.

Cheers.
Jim

On Sat, 02 Aug 2008 18:04:20 -0500, Robert Rappaport wrote:

> I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
> kernel. It has acpi, acpid and acpitool installed and operating in their
> default state. The problem is that when I close the lid to take a break
> it puts the computer into some kind of sleep/hibernation state that
> blanks the screen and I am unable to recover an operating screen on
> reopening the lid without rebooting.

I would respectfully suggest that you consider moving to Slack 12.1
and/or updating the kernel to something much nearer the current one.
ACPI support has improved hugely in recent kernels.

On 3 Aug 2008 18:27:39 +0200, Mark Madsen wrote:

>On Sat, 02 Aug 2008 18:04:20 -0500, Robert Rappaport wrote:
>
>> I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
>> kernel. It has acpi, acpid and acpitool installed and operating in their
>> default state. The problem is that when I close the lid to take a break
>> it puts the computer into some kind of sleep/hibernation state that
>> blanks the screen and I am unable to recover an operating screen on
>> reopening the lid without rebooting.
>
>I would respectfully suggest that you consider moving to Slack 12.1
>and/or updating the kernel to something much nearer the current one.
>ACPI support has improved hugely in recent kernels.

Seconded, not only need a more recent kernel, you need more recent userspace
support for the latest kernels for acpi, udev and friends. Building a
custom kernel you can disable the unreliable suspend to ram, suspend to disk
(S2R, S2D; sleep, hibernate) options.

Grant.
--
http://bugsplatter.id.au/

Jim Diamond wrote:
> On 2008-08-02, Robert Rappaport wrote:
>
>>I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
>>kernel. It has acpi, acpid and acpitool installed and operating in their
>>default state. The problem is that when I close the lid to take a break
>>it puts the computer into some kind of sleep/hibernation state that
>>blanks the screen and I am unable to recover an operating screen on
>>reopening the lid without rebooting.
>>
>>Can anyone suggest some course of action so that I can close and reopen
>>the lid without this problem.
>
>
> Bob,
>
> you don't say exactly what you want to happen... do you want the
> machine to suspend so that it will wake up properly when you open the
> lid, or do you want the machine to keep running?
>
> While I don't have a 10.2 lying around any more, in either case, take
> a peek at /etc/acpi/acpi_handler.sh if you have it on your system. If
> it is there, it is a shell script which handles such events, and you
> may be able to figure out what parts you want to comment out (if you
> don't want the machine to do anything) or fix (if you want the machine
> to suspend).
>
> A number of machines won't properly initialize the video after a
> suspend to RAM if X is running, so a work-around that has worked for
> me is to put a
> chvt 1
> before the code which suspends to RAM and a
> chvt 7
> after that code.
>
> Anyway, if you give some more details, you can probably get more
> specific answers.
>
> Cheers.
> Jim

This laptop is permanently set up on a docking station and running
without a battery. I would like it to keep running with the lid closed.
I am set up to blank the command line screen after 3 minutes of
inactivity and an X screensaver the same. I would like to maintain this
when the lid is closed.

I am attaching a copy of my acpi_handler.sh which obviously has been
rewritten for later Slackware distributions.

I could probably copy a few lines of code into that file to do what I
want if I knew what to copy. Then would my old system understand it?

With this exception I am happy with my present set up and would really
like to solve this without having to upgrade.

Thanks for all responses.

Bob



#!/bin/sh
# Default acpi script that takes an entry for all actions

IFS=${IFS}/
set $@

case "$1" in
button)
case "$2" in
power) /sbin/init 0
;;
*) logger "ACPI action $2 is not defined"
;;
esac
;;
*)
logger "ACPI group $1 / action $2 is not defined"
;;
esac

On 2008-08-03, Robert Rappaport wrote:
> This is a multi-part message in MIME format.
> --------------010403030602050307090209
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Jim Diamond wrote:
>> On 2008-08-02, Robert Rappaport wrote:
>>
>>>I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
>>>kernel. It has acpi, acpid and acpitool installed and operating in their
>>>default state. The problem is that when I close the lid to take a break
>>>it puts the computer into some kind of sleep/hibernation state that
>>>blanks the screen and I am unable to recover an operating screen on
>>>reopening the lid without rebooting.

>>>Can anyone suggest some course of action so that I can close and reopen
>>>the lid without this problem.

>> you don't say exactly what you want to happen... do you want the
>> machine to suspend so that it will wake up properly when you open the
>> lid, or do you want the machine to keep running?
>>
>> While I don't have a 10.2 lying around any more, in either case, take
>> a peek at /etc/acpi/acpi_handler.sh if you have it on your system. If
>> it is there, it is a shell script which handles such events, and you
>> may be able to figure out what parts you want to comment out (if you
>> don't want the machine to do anything) or fix (if you want the machine
>> to suspend).

> This laptop is permanently set up on a docking station and running
> without a battery. I would like it to keep running with the lid closed.
> I am set up to blank the command line screen after 3 minutes of
> inactivity and an X screensaver the same. I would like to maintain this
> when the lid is closed.

> I am attaching a copy of my acpi_handler.sh which obviously has been
> rewritten for later Slackware distributions.

> I could probably copy a few lines of code into that file to do what I
> want if I knew what to copy. Then would my old system understand it?

> With this exception I am happy with my present set up and would really
> like to solve this without having to upgrade.

> Thanks for all responses.

Bob,

you have nothing of interest in your acpi_handler.sh.

Are you running apmd, acpid, both, or neither?

What does

ps uaxw | egrep 'apm|acpi'

output?

Jim

Jim Diamond wrote:
> On 2008-08-03, Robert Rappaport wrote:
>> This is a multi-part message in MIME format.
>> --------------010403030602050307090209
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> Jim Diamond wrote:
>>> On 2008-08-02, Robert Rappaport wrote:
>>>
>>>>I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
>>>>kernel. It has acpi, acpid and acpitool installed and operating in their
>>>>default state. The problem is that when I close the lid to take a break
>>>>it puts the computer into some kind of sleep/hibernation state that
>>>>blanks the screen and I am unable to recover an operating screen on
>>>>reopening the lid without rebooting.
>
>>>>Can anyone suggest some course of action so that I can close and reopen
>>>>the lid without this problem.
>
>>> you don't say exactly what you want to happen... do you want the
>>> machine to suspend so that it will wake up properly when you open the
>>> lid, or do you want the machine to keep running?
>>>
>>> While I don't have a 10.2 lying around any more, in either case, take
>>> a peek at /etc/acpi/acpi_handler.sh if you have it on your system. If
>>> it is there, it is a shell script which handles such events, and you
>>> may be able to figure out what parts you want to comment out (if you
>>> don't want the machine to do anything) or fix (if you want the machine
>>> to suspend).
>
>> This laptop is permanently set up on a docking station and running
>> without a battery. I would like it to keep running with the lid closed.
>> I am set up to blank the command line screen after 3 minutes of
>> inactivity and an X screensaver the same. I would like to maintain this
>> when the lid is closed.
>
>> I am attaching a copy of my acpi_handler.sh which obviously has been
>> rewritten for later Slackware distributions.
>
>> I could probably copy a few lines of code into that file to do what I
>> want if I knew what to copy. Then would my old system understand it?
>
>> With this exception I am happy with my present set up and would really
>> like to solve this without having to upgrade.
>
>> Thanks for all responses.
>
> Bob,
>
> you have nothing of interest in your acpi_handler.sh.
>
> Are you running apmd, acpid, both, or neither?
>
> What does
>
> ps uaxw | egrep 'apm|acpi'
>
> output?
>
> Jim
Additionally, what's in /etc/acpi/events?

You're specifically looking for something like: event=button

Jerry

On 2008-08-04, Jerry Peters wrote:

> Additionally, what's in /etc/acpi/events?
>
> You're specifically looking for something like: event=button

Not necessarily...

Slack 12.0 and 12.1 just have
/etc/acpi/events/default
which calls
/etc/acpi/acpi_handler.sh
(with the event as an argument) for every event. As I recall, 10.2
and 11.0 were the same.

Cheers.
Jim

Jerry Peters wrote:
> Jim Diamond wrote:
>
>>On 2008-08-03, Robert Rappaport wrote:
>>
>>>This is a multi-part message in MIME format.
>>>--------------010403030602050307090209
>>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>>Content-Transfer-Encoding: 7bit
>>>
>>>Jim Diamond wrote:
>>>
>>>>On 2008-08-02, Robert Rappaport wrote:
>>>>
>>>>
>>>>>I have a Dell Latitude D520 laptop with Slackware 10.2 and a 2.6.19
>>>>>kernel. It has acpi, acpid and acpitool installed and operating in their
>>>>>default state. The problem is that when I close the lid to take a break
>>>>>it puts the computer into some kind of sleep/hibernation state that
>>>>>blanks the screen and I am unable to recover an operating screen on
>>>>>reopening the lid without rebooting.
>>
>>>>>Can anyone suggest some course of action so that I can close and reopen
>>>>>the lid without this problem.
>>
>>>>you don't say exactly what you want to happen... do you want the
>>>>machine to suspend so that it will wake up properly when you open the
>>>>lid, or do you want the machine to keep running?
>>>>
>>>>While I don't have a 10.2 lying around any more, in either case, take
>>>>a peek at /etc/acpi/acpi_handler.sh if you have it on your system. If
>>>>it is there, it is a shell script which handles such events, and you
>>>>may be able to figure out what parts you want to comment out (if you
>>>>don't want the machine to do anything) or fix (if you want the machine
>>>>to suspend).
>>
>>>This laptop is permanently set up on a docking station and running
>>>without a battery. I would like it to keep running with the lid closed.
>>> I am set up to blank the command line screen after 3 minutes of
>>>inactivity and an X screensaver the same. I would like to maintain this
>>>when the lid is closed.
>>
>>>I am attaching a copy of my acpi_handler.sh which obviously has been
>>>rewritten for later Slackware distributions.
>>
>>>I could probably copy a few lines of code into that file to do what I
>>>want if I knew what to copy. Then would my old system understand it?
>>
>>>With this exception I am happy with my present set up and would really
>>>like to solve this without having to upgrade.
>>
>>>Thanks for all responses.
>>
>>Bob,
>>
>>you have nothing of interest in your acpi_handler.sh.
>>
>>Are you running apmd, acpid, both, or neither?
>>
>>What does
>>
>> ps uaxw | egrep 'apm|acpi'
>>
>>output?
>>
>> Jim
>
> Additionally, what's in /etc/acpi/events?
>
> You're specifically looking for something like: event=button
>
> Jerry

Jim, Jerry

I have gathered the info you requested in the attached " files.txt ". I
realize that upgrading the kernel is probably the cleanest way to
straighten this out but it took me 3 months on this machine to upgrade
from 2.4.31 to 2.6.19 which is working to my satisfaction now. I will
probably upgrade after the first of the year but I am entering my busy
season and cant afford the time to try it now. If necessary I can leave
the lid up when I take my breaks until then.

Thanks all, for your response.

Bob




The command
ps uaxw | egrep 'apm|acpi'

yields

root 45 0.0 0.0 0 0 ? S< 18:27 0:00 [kacpid]
root 4745 0.0 0.0 1484 464 ? Ss 18:28 0:00 /usr/sbin/acpid

************************************************** ****

The contents of the file

/etc/acpi/events/default

are copied below

# This is the ACPID default configuration, it takes all
# events and passes them to /etc/acpi/default.sh for further
# processing.

# event keeps a regular expression matching the event. To get
# power events only, just use something like "event=button power.*"
# to catch it.
# action keeps the command to be executed after an event occurs
# In case of the power event above, your entry may look this way:
#event=button power.*
#action=/sbin/init 0

# Optionally you can specify the placeholder %e. It will pass
# through the whole kernel event message to the program you've
# specified.

event=.*
action=/etc/acpi/acpi_handler.sh %e

On 2008-08-05, Robert Rappaport wrote:

> Jim, Jerry

> I have gathered the info you requested in the attached " files.txt ". I
> realize that upgrading the kernel is probably the cleanest way to
> straighten this out but it took me 3 months on this machine to upgrade
> from 2.4.31 to 2.6.19 which is working to my satisfaction now. I will
> probably upgrade after the first of the year but I am entering my busy
> season and cant afford the time to try it now. If necessary I can leave
> the lid up when I take my breaks until then.
>
> Thanks all, for your response.

Bob,

I replaced my acpi_handler.sh with the one you sent, and when I do so
my system does not suspend when I close the lid.

I see you are running acpid and not apmd, so I'm at a loss as to what
could be making your system suspend in this case, unless it has
something to do with being in a docking station.

If I think of anything I'll let you know. Also, you could poke around
in /var/log/messages, /var/log/syslog and /var/log/debug and see if
you see anything enlightening.

Cheers.
Jim

Jim Diamond wrote:
> On 2008-08-04, Jerry Peters wrote:
>
>> Additionally, what's in /etc/acpi/events?
>>
>> You're specifically looking for something like: event=button
>
> Not necessarily...
>
> Slack 12.0 and 12.1 just have
> /etc/acpi/events/default
> which calls
> /etc/acpi/acpi_handler.sh
> (with the event as an argument) for every event. As I recall, 10.2
> and 11.0 were the same.
>
> Cheers.
> Jim
Yep, those are the defaults, but since default.sh doesn't handle lid
events, it's definitely worth looking at, just in case he's installed
something that's overiding the defaults.

Jerry