commit 9630bdd9 changes behavior of the poweroff - bug?
in [Kernel]
|
Prev: [PATCH] proc: Report file name on detected read_proc overflow
Next: [PATCH] hwmon: sht15: Fix sht15_calc_temp interpolation function
From: Rafael J. Wysocki on 24 Apr 2010 22:40 On Monday 19 April 2010, Rafael J. Wysocki wrote: > On Monday 19 April 2010, Michal Hocko wrote: > > On Fri 16-04-10 20:00:29, Rafael J. Wysocki wrote: > > > On Wednesday 14 April 2010, Michal Hocko wrote: > > > > On Tue 13-04-10 22:53:37, Rafael J. Wysocki wrote: > > > > > On Tuesday 13 April 2010, Michal Hocko wrote: > > > > > > On Tue 13-04-10 01:01:54, Rafael J. Wysocki wrote: > > > > > > > On Saturday 10 April 2010, Rafael J. Wysocki wrote: > > > > > > > > On Friday 09 April 2010, Tony Vroon wrote: > > > > > > > > > On Fri, 2010-04-09 at 22:42 +0200, Rafael J. Wysocki wrote: > > > > > > > > > > Please check if the patch below changes anything. > > > > > > > > > > drivers/acpi/wakeup.c | 4 ++-- > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > That didn't change the behaviour for me, sorry. > > > > > > > > > > > > > > > > Well, I would be sorry if it did, because the patch removed some useful code. :-) > > > > > > > > > > > > > > > > > (I made sure to go through a full power down session before trying the > > > > > > > > > patched kernel) > > > > > > > > > > > > > > > > Thanks for testing. So it looks like we don't disable the GPE during power off. > > > > > > > > > > > > > > > > I'll try to figure out what's going on, please stay tuned. > > > > > > > > > > > > > > Can you please check if the patch below changes the behavior? > > > > > > > > > > > > Unfortunately, it didn't help either (I have tried on top of the fresh > > > > > > rc4). > > > > > > > > > > That gets really weird. > > > > > > > > > > > > --- > > > > > > > drivers/acpi/wakeup.c | 6 +++--- > > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > Index: linux-2.6/drivers/acpi/wakeup.c > > > > > > > =================================================================== > > > > > > > --- linux-2.6.orig/drivers/acpi/wakeup.c > > > > > > > +++ linux-2.6/drivers/acpi/wakeup.c > > > > > > > @@ -63,17 +63,17 @@ void acpi_enable_wakeup_device(u8 sleep_ > > > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > > > struct acpi_device *dev = > > > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > > > + u8 action = ACPI_GPE_ENABLE; > > > > > > > > > > Can you try to change the above to ACPI_GPE_DISABLE and retest, please? > > > > > > > > Unfortunately didn't help as well... > > > > Just for reference: > > > > > > > > diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c > > > > index 248b473..f23c08f 100644 > > > > --- a/drivers/acpi/wakeup.c > > > > +++ b/drivers/acpi/wakeup.c > > > > @@ -63,7 +63,7 @@ void acpi_enable_wakeup_device(u8 sleep_state) > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > struct acpi_device *dev = > > > > container_of(node, struct acpi_device, wakeup_list); > > > > - u8 action = ACPI_GPE_ENABLE; > > > > + u8 action = ACPI_GPE_DISABLE; > > > > > > That probably means the chipset enables the GPEs by itself _after_ we've > > > disabled them in acpi_enable_wakeup_device(). > > > > Is this something BIOS specific? > > > > > > > > Unfortunately, I can't reproduce the issue on any of my test boxes and it's > > > hard to find the source of the problem staring at the code. > > > > Are there any debug options I can turn on to provide some information? > > We can only check what the kernel tells us before power off, but all that seems > correct. > > > Btw. what exactly does this mean? In what state is the laptop while it > > is turned off and GPE is enabled? > > If a GPE is enabled, then some part of the chipset has power provided so that > it can signal wakeup. > > I'll look into it a bit more later today. Please try the patch below. It kind of restores the previous behavior, let's see if it changes anything. Rafael --- drivers/acpi/acpica/evgpeblk.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c =================================================================== --- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c +++ linux-2.6/drivers/acpi/acpica/evgpeblk.c @@ -364,7 +364,7 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob union acpi_operand_object *pkg_desc; union acpi_operand_object *obj_desc; u32 gpe_number; - acpi_status status; + acpi_status status = AE_OK; ACPI_FUNCTION_TRACE(ev_match_prw_and_gpe); @@ -439,13 +439,15 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob if (gpe_device == target_gpe_device) { gpe_event_info = acpi_ev_gpeblk_event_info(gpe_block, gpe_number); - if (gpe_event_info) + if (gpe_event_info) { + status = acpi_ev_disable_gpe(gpe_event_info); gpe_event_info->flags |= ACPI_GPE_CAN_WAKE; + } } cleanup: acpi_ut_remove_reference(pkg_desc); - return_ACPI_STATUS(AE_OK); + return_ACPI_STATUS(status); } /******************************************************************************* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 24 Apr 2010 23:20 On Sunday 25 April 2010, Rafael J. Wysocki wrote: > On Monday 19 April 2010, Rafael J. Wysocki wrote: > > On Monday 19 April 2010, Michal Hocko wrote: > > > On Fri 16-04-10 20:00:29, Rafael J. Wysocki wrote: > > > > On Wednesday 14 April 2010, Michal Hocko wrote: > > > > > On Tue 13-04-10 22:53:37, Rafael J. Wysocki wrote: > > > > > > On Tuesday 13 April 2010, Michal Hocko wrote: > > > > > > > On Tue 13-04-10 01:01:54, Rafael J. Wysocki wrote: > > > > > > > > On Saturday 10 April 2010, Rafael J. Wysocki wrote: > > > > > > > > > On Friday 09 April 2010, Tony Vroon wrote: > > > > > > > > > > On Fri, 2010-04-09 at 22:42 +0200, Rafael J. Wysocki wrote: > > > > > > > > > > > Please check if the patch below changes anything. > > > > > > > > > > > drivers/acpi/wakeup.c | 4 ++-- > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > That didn't change the behaviour for me, sorry. > > > > > > > > > > > > > > > > > > Well, I would be sorry if it did, because the patch removed some useful code. :-) > > > > > > > > > > > > > > > > > > > (I made sure to go through a full power down session before trying the > > > > > > > > > > patched kernel) > > > > > > > > > > > > > > > > > > Thanks for testing. So it looks like we don't disable the GPE during power off. > > > > > > > > > > > > > > > > > > I'll try to figure out what's going on, please stay tuned. > > > > > > > > > > > > > > > > Can you please check if the patch below changes the behavior? > > > > > > > > > > > > > > Unfortunately, it didn't help either (I have tried on top of the fresh > > > > > > > rc4). > > > > > > > > > > > > That gets really weird. > > > > > > > > > > > > > > --- > > > > > > > > drivers/acpi/wakeup.c | 6 +++--- > > > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > > > Index: linux-2.6/drivers/acpi/wakeup.c > > > > > > > > =================================================================== > > > > > > > > --- linux-2.6.orig/drivers/acpi/wakeup.c > > > > > > > > +++ linux-2.6/drivers/acpi/wakeup.c > > > > > > > > @@ -63,17 +63,17 @@ void acpi_enable_wakeup_device(u8 sleep_ > > > > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > > > > struct acpi_device *dev = > > > > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > > > > + u8 action = ACPI_GPE_ENABLE; > > > > > > > > > > > > Can you try to change the above to ACPI_GPE_DISABLE and retest, please? > > > > > > > > > > Unfortunately didn't help as well... > > > > > Just for reference: > > > > > > > > > > diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c > > > > > index 248b473..f23c08f 100644 > > > > > --- a/drivers/acpi/wakeup.c > > > > > +++ b/drivers/acpi/wakeup.c > > > > > @@ -63,7 +63,7 @@ void acpi_enable_wakeup_device(u8 sleep_state) > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > struct acpi_device *dev = > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > - u8 action = ACPI_GPE_ENABLE; > > > > > + u8 action = ACPI_GPE_DISABLE; > > > > > > > > That probably means the chipset enables the GPEs by itself _after_ we've > > > > disabled them in acpi_enable_wakeup_device(). > > > > > > Is this something BIOS specific? > > > > > > > > > > > Unfortunately, I can't reproduce the issue on any of my test boxes and it's > > > > hard to find the source of the problem staring at the code. > > > > > > Are there any debug options I can turn on to provide some information? > > > > We can only check what the kernel tells us before power off, but all that seems > > correct. > > > > > Btw. what exactly does this mean? In what state is the laptop while it > > > is turned off and GPE is enabled? > > > > If a GPE is enabled, then some part of the chipset has power provided so that > > it can signal wakeup. > > > > I'll look into it a bit more later today. > > Please try the patch below. It kind of restores the previous behavior, > let's see if it changes anything. If it doesn't help, please try to comment out the acpi_enable_gpe() in drivers/acpi/wakeup.c:acpi_wakeup_device_init() and retest (if you haven't done that already). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Hocko on 26 Apr 2010 11:10 On Sun 25-04-10 04:35:42, Rafael J. Wysocki wrote: > On Monday 19 April 2010, Rafael J. Wysocki wrote: > > On Monday 19 April 2010, Michal Hocko wrote: > > > On Fri 16-04-10 20:00:29, Rafael J. Wysocki wrote: > > > > On Wednesday 14 April 2010, Michal Hocko wrote: > > > > > On Tue 13-04-10 22:53:37, Rafael J. Wysocki wrote: > > > > > > On Tuesday 13 April 2010, Michal Hocko wrote: > > > > > > > On Tue 13-04-10 01:01:54, Rafael J. Wysocki wrote: > > > > > > > > On Saturday 10 April 2010, Rafael J. Wysocki wrote: > > > > > > > > > On Friday 09 April 2010, Tony Vroon wrote: > > > > > > > > > > On Fri, 2010-04-09 at 22:42 +0200, Rafael J. Wysocki wrote: > > > > > > > > > > > Please check if the patch below changes anything. > > > > > > > > > > > drivers/acpi/wakeup.c | 4 ++-- > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > That didn't change the behaviour for me, sorry. > > > > > > > > > > > > > > > > > > Well, I would be sorry if it did, because the patch removed some useful code. :-) > > > > > > > > > > > > > > > > > > > (I made sure to go through a full power down session before trying the > > > > > > > > > > patched kernel) > > > > > > > > > > > > > > > > > > Thanks for testing. So it looks like we don't disable the GPE during power off. > > > > > > > > > > > > > > > > > > I'll try to figure out what's going on, please stay tuned. > > > > > > > > > > > > > > > > Can you please check if the patch below changes the behavior? > > > > > > > > > > > > > > Unfortunately, it didn't help either (I have tried on top of the fresh > > > > > > > rc4). > > > > > > > > > > > > That gets really weird. > > > > > > > > > > > > > > --- > > > > > > > > drivers/acpi/wakeup.c | 6 +++--- > > > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > > > Index: linux-2.6/drivers/acpi/wakeup.c > > > > > > > > =================================================================== > > > > > > > > --- linux-2.6.orig/drivers/acpi/wakeup.c > > > > > > > > +++ linux-2.6/drivers/acpi/wakeup.c > > > > > > > > @@ -63,17 +63,17 @@ void acpi_enable_wakeup_device(u8 sleep_ > > > > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > > > > struct acpi_device *dev = > > > > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > > > > + u8 action = ACPI_GPE_ENABLE; > > > > > > > > > > > > Can you try to change the above to ACPI_GPE_DISABLE and retest, please? > > > > > > > > > > Unfortunately didn't help as well... > > > > > Just for reference: > > > > > > > > > > diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c > > > > > index 248b473..f23c08f 100644 > > > > > --- a/drivers/acpi/wakeup.c > > > > > +++ b/drivers/acpi/wakeup.c > > > > > @@ -63,7 +63,7 @@ void acpi_enable_wakeup_device(u8 sleep_state) > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > struct acpi_device *dev = > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > - u8 action = ACPI_GPE_ENABLE; > > > > > + u8 action = ACPI_GPE_DISABLE; > > > > > > > > That probably means the chipset enables the GPEs by itself _after_ we've > > > > disabled them in acpi_enable_wakeup_device(). > > > > > > Is this something BIOS specific? > > > > > > > > > > > Unfortunately, I can't reproduce the issue on any of my test boxes and it's > > > > hard to find the source of the problem staring at the code. > > > > > > Are there any debug options I can turn on to provide some information? > > > > We can only check what the kernel tells us before power off, but all that seems > > correct. > > > > > Btw. what exactly does this mean? In what state is the laptop while it > > > is turned off and GPE is enabled? > > > > If a GPE is enabled, then some part of the chipset has power provided so that > > it can signal wakeup. > > > > I'll look into it a bit more later today. > > Please try the patch below. It kind of restores the previous behavior, > let's see if it changes anything. Again, no success. Just to make sure that I didn't screw anything. I have used just the following patch on top of the clean rc5 (your patch has failed with some rejects but I guess that the following should do the same): commit 65eafe4a504e3bb2c13b4feb8590dc52e7439baa Author: Rafael J. Wysocki <rjw(a)sisk.pl> Date: Sun Apr 25 04:35:42 2010 +0200 diff --git a/drivers/acpi/acpica/evgpeblk.c b/drivers/acpi/acpica/evgpeblk.c index fef7219..b6e1e0c 100644 --- a/drivers/acpi/acpica/evgpeblk.c +++ b/drivers/acpi/acpica/evgpeblk.c @@ -367,7 +367,7 @@ acpi_ev_match_prw_and_gpe(acpi_handle obj_handle, union acpi_operand_object *pkg_desc; union acpi_operand_object *obj_desc; u32 gpe_number; - acpi_status status; + acpi_status status = AE_OK; ACPI_FUNCTION_TRACE(ev_match_prw_and_gpe); @@ -447,12 +447,13 @@ acpi_ev_match_prw_and_gpe(acpi_handle obj_handle, gpe_block-> block_base_number]; + status = acpi_ev_disable_gpe(gpe_event_info); gpe_event_info->flags |= ACPI_GPE_CAN_WAKE; } cleanup: acpi_ut_remove_reference(pkg_desc); - return_ACPI_STATUS(AE_OK); + return_ACPI_STATUS(status); } /******************************************************************************* > > Rafael > > --- > drivers/acpi/acpica/evgpeblk.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c > =================================================================== > --- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c > +++ linux-2.6/drivers/acpi/acpica/evgpeblk.c > @@ -364,7 +364,7 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob > union acpi_operand_object *pkg_desc; > union acpi_operand_object *obj_desc; > u32 gpe_number; > - acpi_status status; > + acpi_status status = AE_OK; > > ACPI_FUNCTION_TRACE(ev_match_prw_and_gpe); > > @@ -439,13 +439,15 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob > if (gpe_device == target_gpe_device) { > gpe_event_info = acpi_ev_gpeblk_event_info(gpe_block, > gpe_number); > - if (gpe_event_info) > + if (gpe_event_info) { > + status = acpi_ev_disable_gpe(gpe_event_info); > gpe_event_info->flags |= ACPI_GPE_CAN_WAKE; > + } > } > > cleanup: > acpi_ut_remove_reference(pkg_desc); > - return_ACPI_STATUS(AE_OK); > + return_ACPI_STATUS(status); > } > > /******************************************************************************* > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 26 Apr 2010 12:30 Michal, > my laptop changed behavior during poweroff recently (after upgrading > from .33 to .34-rc1). The system seems to be powered off (status display > is off) at first glance but when I close the lid then I can hear a noise > which sounds like HDD parking and when I open lid again it starts > booting without poweroff button (same like when I suspend to RAM). Tony, > I have the exact same "lid close = powering back on" regression on a > Fujitsu-Siemens Lifebook S6420. Perhaps you can review this description and help me better understand the symptoms? Michal, Re: poweroff Before the regression you could hear the HDD park as a result of the "poweroff" command without touching the lid, and after the regression you don't hear that sound until after you close the lid -- no matter how long you wait to close the lid? During this period after poweroff and LCD goes out, but before lid close, are there any other signs of life? eg. does caps lock button light the caps LED? How about during this period if you press the power button and hold it for 5 seconds, does that cause the HDD parking sound? If yes, then the regression is that poweroff never completes, though perhaps a lid event allows it to complete. When you say 'when I open the lid again i starts booting'. Is that a cold boot from scratch, or a resume from suspend? Does the new boot start when the lid is closed, or when it is subsequently opened? Thanks for sending your /proc/acpi/wakeup, it shows that LID S4 *enabled which means that the LID is not an S5 wakeup device. So if you really do get down to S5, the LID should not be able to wake the system. So if it is, then we are never getting to S5. Tony, Please send the /proc/acpi/wakeup file before and after the regression. Does the system reach a complete poweroff before the lid is closed? If yes, what happens when you press the power button w/o closing the lid? If you reached S5, it should give you a cold boot. If you did not reach S5, it will have no effect. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 26 Apr 2010 15:00
On Monday 26 April 2010, Michal Hocko wrote: > On Sun 25-04-10 04:35:42, Rafael J. Wysocki wrote: > > On Monday 19 April 2010, Rafael J. Wysocki wrote: > > > On Monday 19 April 2010, Michal Hocko wrote: > > > > On Fri 16-04-10 20:00:29, Rafael J. Wysocki wrote: > > > > > On Wednesday 14 April 2010, Michal Hocko wrote: > > > > > > On Tue 13-04-10 22:53:37, Rafael J. Wysocki wrote: > > > > > > > On Tuesday 13 April 2010, Michal Hocko wrote: > > > > > > > > On Tue 13-04-10 01:01:54, Rafael J. Wysocki wrote: > > > > > > > > > On Saturday 10 April 2010, Rafael J. Wysocki wrote: > > > > > > > > > > On Friday 09 April 2010, Tony Vroon wrote: > > > > > > > > > > > On Fri, 2010-04-09 at 22:42 +0200, Rafael J. Wysocki wrote: > > > > > > > > > > > > Please check if the patch below changes anything. > > > > > > > > > > > > drivers/acpi/wakeup.c | 4 ++-- > > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > That didn't change the behaviour for me, sorry. > > > > > > > > > > > > > > > > > > > > Well, I would be sorry if it did, because the patch removed some useful code. :-) > > > > > > > > > > > > > > > > > > > > > (I made sure to go through a full power down session before trying the > > > > > > > > > > > patched kernel) > > > > > > > > > > > > > > > > > > > > Thanks for testing. So it looks like we don't disable the GPE during power off. > > > > > > > > > > > > > > > > > > > > I'll try to figure out what's going on, please stay tuned. > > > > > > > > > > > > > > > > > > Can you please check if the patch below changes the behavior? > > > > > > > > > > > > > > > > Unfortunately, it didn't help either (I have tried on top of the fresh > > > > > > > > rc4). > > > > > > > > > > > > > > That gets really weird. > > > > > > > > > > > > > > > > --- > > > > > > > > > drivers/acpi/wakeup.c | 6 +++--- > > > > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > > > > > Index: linux-2.6/drivers/acpi/wakeup.c > > > > > > > > > =================================================================== > > > > > > > > > --- linux-2.6.orig/drivers/acpi/wakeup.c > > > > > > > > > +++ linux-2.6/drivers/acpi/wakeup.c > > > > > > > > > @@ -63,17 +63,17 @@ void acpi_enable_wakeup_device(u8 sleep_ > > > > > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > > > > > struct acpi_device *dev = > > > > > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > > > > > + u8 action = ACPI_GPE_ENABLE; > > > > > > > > > > > > > > Can you try to change the above to ACPI_GPE_DISABLE and retest, please? > > > > > > > > > > > > Unfortunately didn't help as well... > > > > > > Just for reference: > > > > > > > > > > > > diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c > > > > > > index 248b473..f23c08f 100644 > > > > > > --- a/drivers/acpi/wakeup.c > > > > > > +++ b/drivers/acpi/wakeup.c > > > > > > @@ -63,7 +63,7 @@ void acpi_enable_wakeup_device(u8 sleep_state) > > > > > > list_for_each_safe(node, next, &acpi_wakeup_device_list) { > > > > > > struct acpi_device *dev = > > > > > > container_of(node, struct acpi_device, wakeup_list); > > > > > > - u8 action = ACPI_GPE_ENABLE; > > > > > > + u8 action = ACPI_GPE_DISABLE; > > > > > > > > > > That probably means the chipset enables the GPEs by itself _after_ we've > > > > > disabled them in acpi_enable_wakeup_device(). > > > > > > > > Is this something BIOS specific? > > > > > > > > > > > > > > Unfortunately, I can't reproduce the issue on any of my test boxes and it's > > > > > hard to find the source of the problem staring at the code. > > > > > > > > Are there any debug options I can turn on to provide some information? > > > > > > We can only check what the kernel tells us before power off, but all that seems > > > correct. > > > > > > > Btw. what exactly does this mean? In what state is the laptop while it > > > > is turned off and GPE is enabled? > > > > > > If a GPE is enabled, then some part of the chipset has power provided so that > > > it can signal wakeup. > > > > > > I'll look into it a bit more later today. > > > > Please try the patch below. It kind of restores the previous behavior, > > let's see if it changes anything. > > Again, no success. Just to make sure that I didn't screw anything. I > have used just the following patch on top of the clean rc5 (your patch > has failed with some rejects but I guess that the following should do > the same): Thanks for testing. Did you try the second thing, ie. try to comment out the acpi_enable_gpe() in drivers/acpi/wakeup.c:acpi_wakeup_device_init() and retest (if you haven't done that already)? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |