RE: [PM][ACPI] No ACPI interrupts after resume from S1

RE: [PM][ACPI] No ACPI interrupts after resume from S1

[Yu, Luming]

I made a mistake in using base_number. Would you please have updated patch a try?
Thanks a lot. --Luming


-----Original Message-----
From: Karol Kozimor [mailto:sziwan@hell.org.pl]
Sent: 2003?10?27? 5:41
To: Yu, Luming
Cc: Pavel Machek; M?ns Rullg?rd; acpi-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: Re: [PM][ACPI] No ACPI interrupts after resume from S1


Thus wrote Yu, Luming:
> Would you please try patch at http://bugme.osdl.org/show_bug.cgi?id=1409

Hi,
The patch makes my kernel oops on resume:
hdc: completing PM  request, resume
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 90
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: A0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 24
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: C8
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: E0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: F0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space:  4
Unable to handle kernel paging request at virtual address 70677679
 printing eip:
c020c44c
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c020c44c>]   Not tainted
EFLAGS: 00010206
EIP is at acpi_hw_lowlevel_read+0x30/0x122
eax: c02e6344   ebx: cffd6408   ecx: cfc51e88   edx: 00000010
esi: 70677671   edi: cfc51e90   ebp: 00000008   esp: cfc51e58
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 304, threadinfo=cfc50000 task=c1368a0)
Stack: 00000130 c021c9b8 00000002 c02e6499 c02e6344 c02f6720 cffd6408 cfe3b228
       000001e0 00000001 c020b6b2 00000008 cfc51e90 70677671 c0311650 00000018
       c020b9c2 cffd6408 00000010 00000000 00000000 cfc51ebc c02da521 00000001
Call Trace:
 acpi_ut_acquire_mutex+0xc0/0x16b
 acpi_hw_enable_gpe+0x1e/0x44
 acpi_hw_enable_ec_gpes+0x7f0x85
 acpi_leave_sleep_state+0x119/0x13e
 dpm_resume+0x34/0x5a
 acpi_pm_finish+0xb/0x38
 [...]

Code: 8b 56 08 8b 46 04 89 d1 09 c1 75 0a 31 c0 83 c4 18 5b 5c 5f
[hand typed, but at least the traces should be OK]

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Karol Kozimor]

Thus wrote Yu, Luming:
> I made a mistake in using base_number. Would you please have updated patch a try?
> Thanks a lot. --Luming

The updated patch fixes the issue, the interrupts now still occur after S1
resume.
Thanks,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

RE: [PM][ACPI] No ACPI interrupts after resume from S1

[Yu, Luming]

I have made an updated version. Would you please retry?
-Luming

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Yu, Luming
Sent: 2003?10?27? 16:56
To: Karol Kozimor
Cc: Pavel Machek; M?ns Rullg?rd; acpi-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: RE: [PM][ACPI] No ACPI interrupts after resume from S1


I made a mistake in using base_number. Would you please have updated patch a try?
Thanks a lot. --Luming


-----Original Message-----
From: Karol Kozimor [mailto:sziwan@hell.org.pl]
Sent: 2003?10?27? 5:41
To: Yu, Luming
Cc: Pavel Machek; M?ns Rullg?rd; acpi-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: Re: [PM][ACPI] No ACPI interrupts after resume from S1


Thus wrote Yu, Luming:
> Would you please try patch at http://bugme.osdl.org/show_bug.cgi?id=1409

Hi,
The patch makes my kernel oops on resume:
hdc: completing PM  request, resume
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 90
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: A0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 24
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: C8
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: E0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: F0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space:  4
Unable to handle kernel paging request at virtual address 70677679
 printing eip:
c020c44c
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c020c44c>]   Not tainted
EFLAGS: 00010206
EIP is at acpi_hw_lowlevel_read+0x30/0x122
eax: c02e6344   ebx: cffd6408   ecx: cfc51e88   edx: 00000010
esi: 70677671   edi: cfc51e90   ebp: 00000008   esp: cfc51e58
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 304, threadinfo=cfc50000 task=c1368a0)
Stack: 00000130 c021c9b8 00000002 c02e6499 c02e6344 c02f6720 cffd6408 cfe3b228
       000001e0 00000001 c020b6b2 00000008 cfc51e90 70677671 c0311650 00000018
       c020b9c2 cffd6408 00000010 00000000 00000000 cfc51ebc c02da521 00000001
Call Trace:
 acpi_ut_acquire_mutex+0xc0/0x16b
 acpi_hw_enable_gpe+0x1e/0x44
 acpi_hw_enable_ec_gpes+0x7f0x85
 acpi_leave_sleep_state+0x119/0x13e
 dpm_resume+0x34/0x5a
 acpi_pm_finish+0xb/0x38
 [...]

Code: 8b 56 08 8b 46 04 89 d1 09 c1 75 0a 31 c0 83 c4 18 5b 5c 5f
[hand typed, but at least the traces should be OK]

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PM][ACPI] No ACPI interrupts after resume from S1

[Yu, Luming]

Would you please try patch at http://bugme.osdl.org/show_bug.cgi?id=1409
Thanks,
Luming

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Pavel Machek
Sent: 2003?10?23? 16:24
To: M?ns Rullg?rd; acpi-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: Re: [PM][ACPI] No ACPI interrupts after resume from S1


Hi!


> > working.  Normally, they will generate an ACPI event, that is
> > processed by acpid etc.  After a suspend, each button will work once.
> > If I then close and open the lid, they will work one more time, and so
> > on.  Any way I can help?
> 
> Please specify the type of suspend. The situation I described only occurs
> for S1 (or, echo -n standby, more specifically), and only in certain kernel
> versions.

Find out which versions break it, pay special atetion to
hwsleep.c.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Karol Kozimor]

Thus wrote Yu, Luming:
> Would you please try patch at http://bugme.osdl.org/show_bug.cgi?id=1409

Hi,
The patch makes my kernel oops on resume:
hdc: completing PM  request, resume
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 90
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: A0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: 24
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: C8
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: E0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space: F0
  hwregs-0760 [56] hw_low_level_read     : Unsupported address space:  4
Unable to handle kernel paging request at virtual address 70677679
 printing eip:
c020c44c
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c020c44c>]   Not tainted
EFLAGS: 00010206
EIP is at acpi_hw_lowlevel_read+0x30/0x122
eax: c02e6344   ebx: cffd6408   ecx: cfc51e88   edx: 00000010
esi: 70677671   edi: cfc51e90   ebp: 00000008   esp: cfc51e58
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 304, threadinfo=cfc50000 task=c1368a0)
Stack: 00000130 c021c9b8 00000002 c02e6499 c02e6344 c02f6720 cffd6408 cfe3b228
       000001e0 00000001 c020b6b2 00000008 cfc51e90 70677671 c0311650 00000018
       c020b9c2 cffd6408 00000010 00000000 00000000 cfc51ebc c02da521 00000001
Call Trace:
 acpi_ut_acquire_mutex+0xc0/0x16b
 acpi_hw_enable_gpe+0x1e/0x44
 acpi_hw_enable_ec_gpes+0x7f0x85
 acpi_leave_sleep_state+0x119/0x13e
 dpm_resume+0x34/0x5a
 acpi_pm_finish+0xb/0x38
 [...]

Code: 8b 56 08 8b 46 04 89 d1 09 c1 75 0a 31 c0 83 c4 18 5b 5c 5f
[hand typed, but at least the traces should be OK]

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

[PM][ACPI] No ACPI interrupts after resume from S1

[Karol Kozimor]

Hi,

Suspending and resuming from S1 disables ACPI interrupts for my machine
(ASUS L3800C laptop). No further interrupts and events are generated,
/proc/interrupts shows no change w.r. to ACPI. This happens regardless of
whether the specific IRQ is shared or not.

Versions affected: 2.6.0-test[5-8], 2.6.0-test5-mm4, 2.6.0-test6-mm4.
Versions unaffected: 2.6.0-test3, 2.4.22 with 20030918 ACPI.

Note: it seems that running a pmdisk cycle after resume from S1 reenables
the interrupts somehow (though treat it as a not-thoroughly-tested
observation for now).

http://bugme.osdl.org/show_bug.cgi?id=1185 may contain information relevant
to the matter (DSDT, dmesg, etc.).

I'll be happy to provide any further info.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Karol Kozimor <sziwan@hell.org.pl> writes:

> Suspending and resuming from S1 disables ACPI interrupts for my machine
> (ASUS L3800C laptop). No further interrupts and events are generated,
> /proc/interrupts shows no change w.r. to ACPI. This happens regardless of
> whether the specific IRQ is shared or not.

I've got an Asus M2400E laptop, and have seen similar things.  After a
suspend, the extra buttons (I use them to fire up programs) stop
working.  Normally, they will generate an ACPI event, that is
processed by acpid etc.  After a suspend, each button will work once.
If I then close and open the lid, they will work one more time, and so
on.  Any way I can help?

-- 
Måns Rullgård
mru@users.sf.net

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Karol Kozimor]

Thus wrote M?ns Rullg?rd:
> > Suspending and resuming from S1 disables ACPI interrupts for my machine
> > (ASUS L3800C laptop). No further interrupts and events are generated,
> > /proc/interrupts shows no change w.r. to ACPI. This happens regardless of
> > whether the specific IRQ is shared or not.
> suspend, the extra buttons (I use them to fire up programs) stop
> working.  Normally, they will generate an ACPI event, that is
> processed by acpid etc.  After a suspend, each button will work once.
> If I then close and open the lid, they will work one more time, and so
> on.  Any way I can help?

Please specify the type of suspend. The situation I described only occurs
for S1 (or, echo -n standby, more specifically), and only in certain kernel
versions.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Karol Kozimor <sziwan@hell.org.pl> writes:

>> suspend, the extra buttons (I use them to fire up programs) stop
>> working.  Normally, they will generate an ACPI event, that is
>> processed by acpid etc.  After a suspend, each button will work once.
>> If I then close and open the lid, they will work one more time, and so
>> on.  Any way I can help?
>
> Please specify the type of suspend. The situation I described only occurs
> for S1 (or, echo -n standby, more specifically), and only in certain kernel
> versions.

standby, at least.

After echo -n mem > /sys/power/state, the display light won't turn on,
so I don't know what's going on.  I've never managed to resume from a
suspend to disk.  It just boots normally and makes a fuss about the
filesystems.

-- 
Måns Rullgård
mru@kth.se

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Pavel Machek]

Hi!

> >> suspend, the extra buttons (I use them to fire up programs) stop
> >> working.  Normally, they will generate an ACPI event, that is
> >> processed by acpid etc.  After a suspend, each button will work once.
> >> If I then close and open the lid, they will work one more time, and so
> >> on.  Any way I can help?
> >
> > Please specify the type of suspend. The situation I described only occurs
> > for S1 (or, echo -n standby, more specifically), and only in certain kernel
> > versions.
> 
> standby, at least.
> 
> After echo -n mem > /sys/power/state, the display light won't turn on,
> so I don't know what's going on.  I've never managed to resume from a
> suspend to disk.  It just boots normally and makes a fuss about the
> filesystems.

Are you passing resume= option?
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

>> >> suspend, the extra buttons (I use them to fire up programs) stop
>> >> working.  Normally, they will generate an ACPI event, that is
>> >> processed by acpid etc.  After a suspend, each button will work once.
>> >> If I then close and open the lid, they will work one more time, and so
>> >> on.  Any way I can help?
>> >
>> > Please specify the type of suspend. The situation I described
>> > only occurs for S1 (or, echo -n standby, more specifically), and
>> > only in certain kernel versions.
>> 
>> standby, at least.
>> 
>> After echo -n mem > /sys/power/state, the display light won't turn on,
>> so I don't know what's going on.  I've never managed to resume from a
>> suspend to disk.  It just boots normally and makes a fuss about the
>> filesystems.
>
> Are you passing resume= option?

I've been trying the new suspend to disk implementation (pmdisk, I
think) lately.  I get these lines in the kernel log when starting
after a suspend:

PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S3 S4 S5)

Last time I tried swsusp, I did pass the resume= option, but it didn't
work.

Could it be that some disk cache is never flushed properly?
Occasionally, some random filesystem is reported as not being cleanly
unmounted when booting normally, which seems to point in the same
direction.

-- 
Måns Rullgård
mru@kth.se

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Nick Piggin]

Måns Rullgård wrote:

>Pavel Machek <pavel@ucw.cz> writes:
>
>
>>>>>suspend, the extra buttons (I use them to fire up programs) stop
>>>>>working.  Normally, they will generate an ACPI event, that is
>>>>>processed by acpid etc.  After a suspend, each button will work once.
>>>>>If I then close and open the lid, they will work one more time, and so
>>>>>on.  Any way I can help?
>>>>>
>>>>Please specify the type of suspend. The situation I described
>>>>only occurs for S1 (or, echo -n standby, more specifically), and
>>>>only in certain kernel versions.
>>>>
>>>standby, at least.
>>>
>>>After echo -n mem > /sys/power/state, the display light won't turn on,
>>>so I don't know what's going on.  I've never managed to resume from a
>>>suspend to disk.  It just boots normally and makes a fuss about the
>>>filesystems.
>>>
>>Are you passing resume= option?
>>
>
>I've been trying the new suspend to disk implementation (pmdisk, I
>think) lately.  I get these lines in the kernel log when starting
>after a suspend:
>
>PM: Reading pmdisk image.
>PM: Resume from disk failed.
>ACPI: (supports S0 S1 S3 S4 S5)
>
>Last time I tried swsusp, I did pass the resume= option, but it didn't
>work.
>
>Could it be that some disk cache is never flushed properly?
>Occasionally, some random filesystem is reported as not being cleanly
>unmounted when booting normally, which seems to point in the same
>direction.
>

Try turning your disk cache off, or set it to write through caching
(even so I heard some IDE drives don't turn it off anyway!). See if
it helps.

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Nick Piggin <piggin@cyberone.com.au> writes:

>>I've been trying the new suspend to disk implementation (pmdisk, I
>>think) lately.  I get these lines in the kernel log when starting
>>after a suspend:
>>
>>PM: Reading pmdisk image.
>>PM: Resume from disk failed.
>>ACPI: (supports S0 S1 S3 S4 S5)
>>
>>Last time I tried swsusp, I did pass the resume= option, but it didn't
>>work.
>>
>>Could it be that some disk cache is never flushed properly?
>>Occasionally, some random filesystem is reported as not being cleanly
>>unmounted when booting normally, which seems to point in the same
>>direction.
>>
>
> Try turning your disk cache off, or set it to write through caching
> (even so I heard some IDE drives don't turn it off anyway!). See if
> it helps.

That took me one step further.  Now it loaded the image swap, but them
immediately rebooted.  I didn't have time to see if there were any
error messages.  I don't have a serial port, so I can't put a console
there.  This was with lots of modules loaded, so maybe unloading some
would help.  Are there any known broken drivers in this list:

Module                  Size  Used by
ide_cd                 36612  0 
cdrom                  32160  1 ide_cd
evdev                   7808  1 
ipv6                  226496  12 
iptable_filter          2304  1 
ip_tables              15616  1 iptable_filter
sis_agp                 4224  1 
agpgart                25896  1 sis_agp
ohci_hcd               16128  0 
usbcore                94940  3 ohci_hcd
snd_intel8x0           28164  0 
snd_ac97_codec         50948  1 snd_intel8x0
snd_pcm                84004  1 snd_intel8x0
snd_timer              20996  1 snd_pcm
snd_page_alloc          9092  2 snd_intel8x0,snd_pcm
snd_mpu401_uart         6144  1 snd_intel8x0
snd_rawmidi            19616  1 snd_mpu401_uart
snd                    43364  6 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi
soundcore               7104  1 snd
ohci1394               31112  0 
ieee1394               68396  1 ohci1394
sis900                 16516  0 
crc32                   4096  1 sis900
ds                     10884  4 
yenta_socket           14336  0 
pcmcia_core            60768  2 ds,yenta_socket
rtc                    10552  0 

In case it matters, sisfb is compiled into the kernel.

-- 
Måns Rullgård
mru@kth.se

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Pavel Machek]

Hi!

> >>I've been trying the new suspend to disk implementation (pmdisk, I
> >>think) lately.  I get these lines in the kernel log when starting
> >>after a suspend:
> >>
> >>PM: Reading pmdisk image.
> >>PM: Resume from disk failed.
> >>ACPI: (supports S0 S1 S3 S4 S5)
> >>
> >>Last time I tried swsusp, I did pass the resume= option, but it didn't
> >>work.
> >>
> >>Could it be that some disk cache is never flushed properly?
> >>Occasionally, some random filesystem is reported as not being cleanly
> >>unmounted when booting normally, which seems to point in the same
> >>direction.
> >>
> >
> > Try turning your disk cache off, or set it to write through caching
> > (even so I heard some IDE drives don't turn it off anyway!). See if
> > it helps.
> 
> That took me one step further.  Now it loaded the image swap, but them
> immediately rebooted.  I didn't have time to see if there were any
> error messages.  I don't have a serial port, so I can't put a console
> there.  This was with lots of modules loaded, so maybe unloading some
> would help.  Are there any known broken drivers in this list:

Try it completely without modules. I'm not sure how it should work
with modules which means it probably does not work at all.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> Try it completely without modules. I'm not sure how it should work
> with modules which means it probably does not work at all.

Are you saying it doesn't work with any modules?  What about all the
people who have reported success with suspend-to-disk?  I thought
everyone used at least some modules.

-- 
Måns Rullgård
mru@kth.se

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Nigel Cunningham]

Some modules cause problems. If I suspend with the intel-agp driver
loaded, for example, the computer reboots when copying the original
kernel back, because the hardware state doesn't match. I can suspend and
resume my i830 based laptop just fine without it. Once the right changes
are made to the driver, the module will work, but not yet.

Pavel, excuse me for jumping in here.

Regards,

Nigel

On Sat, 2003-10-25 at 11:45, Måns Rullgård wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> 
> > Try it completely without modules. I'm not sure how it should work
> > with modules which means it probably does not work at all.
> 
> Are you saying it doesn't work with any modules?  What about all the
> people who have reported success with suspend-to-disk?  I thought
> everyone used at least some modules.
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Pavel Machek]

Hi!

> Some modules cause problems. If I suspend with the intel-agp driver
> loaded, for example, the computer reboots when copying the original
> kernel back, because the hardware state doesn't match. I can suspend and
> resume my i830 based laptop just fine without it. Once the right changes
> are made to the driver, the module will work, but not yet.
> 
> Pavel, excuse me for jumping in here.

No problem, I'm actually tired of replying to all those mails myself
;-).

									Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

>> That took me one step further.  Now it loaded the image swap, but them
>> immediately rebooted.  I didn't have time to see if there were any
>> error messages.  I don't have a serial port, so I can't put a console
>> there.  This was with lots of modules loaded, so maybe unloading some
>> would help.  Are there any known broken drivers in this list:
>
> Try it completely without modules. I'm not sure how it should work
> with modules which means it probably does not work at all.

OK, so I tried it with just the a few modules loaded (those I couldn't
unload, for some reason), and it worked.  Now I guess I'll have to
track down which modules are being evil.

-- 
Måns Rullgård
mru@kth.se

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Pavel Machek]

Hi!


> > working.  Normally, they will generate an ACPI event, that is
> > processed by acpid etc.  After a suspend, each button will work once.
> > If I then close and open the lid, they will work one more time, and so
> > on.  Any way I can help?
> 
> Please specify the type of suspend. The situation I described only occurs
> for S1 (or, echo -n standby, more specifically), and only in certain kernel
> versions.

Find out which versions break it, pay special atetion to
hwsleep.c.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: [PM][ACPI] No ACPI interrupts after resume from S1

[Karol Kozimor]

Thus wrote Pavel Machek:
> Find out which versions break it, pay special atetion to
> hwsleep.c.

I stated in my original mail that the last working version was 2.6.0-test3.
test4 is broken w.r. to S1, and test5 resumes with ACPI interrupts gone.
I'll try to be more specific, though.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl