Bug 512958 - Open/close laptop lid doesn't generate acpi signal on HP mini 2140
Summary: Open/close laptop lid doesn't generate acpi signal on HP mini 2140
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i586
OS: Linux
low
medium
Target Milestone: ---
Assignee: John Feeney
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-21 13:48 UTC by Jan Klícha
Modified: 2013-01-10 08:00 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 19:29:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
lspci -vvnn > lspci-vvnn.log (21.73 KB, text/plain)
2009-07-21 13:48 UTC, Jan Klícha
no flags Details
lspci -vvnn of PB DotS 015 (21.55 KB, text/plain)
2010-01-31 21:48 UTC, Massimiliano
no flags Details
decompiled DSDT from a HP mini 2140 (451.06 KB, text/plain)
2010-04-19 16:39 UTC, Michal Schmidt
no flags Details

Description Jan Klícha 2009-07-21 13:48:29 UTC
Created attachment 354484 [details]
lspci -vvnn > lspci-vvnn.log

Description of problem:
Closing laptop lid doesn't generate any acpi signal and gnome-power-manager doesn't suspend or hibernate the computer - HP mini 2140. Gnome-power-manager doesn't offer section in settings about actions by opening/closing laptop lid.
/proc/acpi/button/lid/C1C4/state is changing correctly from open to close and vice versa.

The laptop begins working correctly (acpi is sending signals about opening/closing lid switch) only if I set following two commands:
echo 1 > /proc/acpi/video/C083/DOS
echo 0 > /proc/acpi/video/C083/DOS
Initial value of /proc/acpi/video/C083/DOS is 4.
Gnome-power-manager still doesn't offer settings for behavior by opening/closing laptop lid.


Version-Release number of selected component (if applicable):
uname -a:
Linux Morpheus 2.6.29.5-191.fc11.i586 #1 SMP Tue Jun 16 23:11:39 EDT 2009 i686 i686 i386 GNU/Linux

cat /proc/version:
Linux version 2.6.29.5-191.fc11.i586 (mockbuild.redhat.com) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 SMP Tue Jun 16 23:11:39 EDT 2009

acpid-1.0.8-4.fc11.i586
gnome-power-manager-2.26.3-1.fc11.i586

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Zdenek Prikryl 2009-07-23 13:52:47 UTC
acpid is a simple application watching for acpi events. It doesn't generate any acpi event. It seems that the problem is in kernel (kernel module). So I'm reassigning it to kernel.

Comment 2 chg 2009-07-31 11:31:17 UTC
I have the same behavior om my HP Compaq nx7300 laptop.

Comment 3 Tommi Kyntola 2009-12-07 19:48:42 UTC
On my HP mini 5101 I have a similar issue, but it's
/proc/acpi/button/lid/C1D0/state and it, too, is changing correctly when I open or close the lid, but acpi_listen shows nothing.

Comment 4 Tommi Kyntola 2009-12-07 20:31:50 UTC
On an HP nw8530 where it works I get:
Dec  7 20:19:25 localhost kernel: input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2
Dec  7 20:19:25 localhost kernel: ACPI: Lid Switch [LID]

and the state file is in /proc/acpi/button/lid/LID/state

And on a said HP mini 5101 I get:
Dec  7 18:04:14 localhost kernel: input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2
Dec  7 18:04:14 localhost kernel: ACPI: Lid Switch [C1D0]

and the state file is in /proc/acpi/button/lid/C1D0/state

Comment 5 Tommi Kyntola 2009-12-08 09:12:25 UTC
This originates to kernel acpi drivers.

The button.c uses what it gets from acpi_device_bid for the
directory name aswell as for the Lid Switch [%s] printk.

The acpi_device_bid is, if I understood correcrly, filled with
what it gets from drivers/acpi/scan.c:
static void acpi_device_get_busid(struct acpi_device *device)

which in turn defaults to calling acpi_get_name from acpica/nsxfname.c.
Now, why that returns C1D0 rather than LID is beyond me.

And about missing events, I think it has to do with 
acpi_lid_send_state 
 -> acpi_evaluate_integer 
     -> acpi_evaluate_object
         and all the "magic" it does there with names

Someone with more knowledge of kernel acpi internals might want to take a look at this. I'm willing try any patches or produce debugs etc.

I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access to said laptop again (it's my wife's, you see) and check if that shows anything relevant.

Comment 6 Tommi Kyntola 2009-12-09 22:09:55 UTC
I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and the problem persist, _but_ I compiled the stock 2.6.32 with the config from said fedora kernel and low and behold, the lid acpi signaling works.

acpi_listen shows the lid events and system suspended when I configured it to from power management.

This was about the HP mini 5101 and I have no idea what the situation is with hp mini 2140 what this bug is about.

Hopefully those acpi changes make it to the fedora kernel soon. I glanced briefly but didn't spot them in 2.6.31.y yet either.

Comment 7 Alexei Panov 2010-01-10 14:04:23 UTC
I have same problem on HP Mini 5101. I have tried to rebuild kernel from src rpm with parameter with_vanilla 1, i.e. without additional patches. And so, lid switch has started to work and, by the way, the sound in skype has ceased to "break" at start. But restoring of system after hibernation does not work (probably there are no patches for i945..).
P.S. kernel 2.6.32 from koji http://koji.fedoraproject.org/koji/buildinfo?buildID=149813

Comment 8 Massimiliano 2010-01-31 21:48:24 UTC
Created attachment 387888 [details]
lspci -vvnn of PB DotS 015

I have the same problem with my PackardBell Dot S 015 netbook. The following command:

while :; do echo -n "$(date) -- "; cat /proc/acpi/button/lid/LID0/state ; sleep 1 ; done

reports that the lid status is always "closed", even if it is open.
My kernel is kernel-2.6.31.12-174.2.3.fc12.i686. I have attached my "lspci -vvnn".

Comment 9 Alexei Panov 2010-03-04 22:42:54 UTC
I have found a patch which breaks operation of Lid Switch on HP Mini 5101, and possible on others HPs. 
This patch is linux-2.6-acpi-video-dos.patch. If you build a kernel without this patch lid switch perfectly works.
I suggest to test for those who have such problem, I have made a variant of a kernel without the offending patch ftp://ftp.atisserv.ru/kernel-hp-lid/

Comment 10 Michal Schmidt 2010-04-19 16:39:35 UTC
Created attachment 407630 [details]
decompiled DSDT from a HP mini 2140

Comment 11 Michal Schmidt 2010-04-19 16:44:42 UTC
+CC Matthew Garrett

Matthew, do you have any ideas why linux-2.6-acpi-video-dos.patch breaks signals from the lid on HP mini 2140?

Comment 12 Matthew Garrett 2010-04-19 16:54:23 UTC
You can change this at runtime by writing to /proc/acpi/video/*/DOS - valid values are from 0 to 7 inclusive. Can you work out which values work and which don't?

Comment 13 Matthew Garrett 2010-04-19 16:56:15 UTC
Sorry, epiphany seems to do bad things to the component field.

Comment 14 Matthew Garrett 2010-04-19 17:09:21 UTC
Also, could you please confirm which events you see from the lid switch?

Comment 15 Michal Schmidt 2010-04-20 20:41:37 UTC
I don't have a HP mini 2140, but an acquaintance of mine does, so I had him test all 8 DOS settings. He uses Ubuntu with kernel 2.6.31-20-generic.

Only with DOS=0 there were ACPI events emitted (observed in /proc/acpi/events) when closing and reopening the lid:

video C083 00000080 00000000 
button/lid C1C4 00000080 00000038 
video C083 00000080 00000000 
button/lid C1C4 00000080 00000039 
video C083 00000080 00000000 

With any other DOS setting (1..7) /proc/acpi/events remained silent all the time.

Comment 16 Jan Klícha 2010-04-20 20:51:36 UTC
Initial value of /proc/acpi/video/C083/DOS after start is 4. If I change value
from 1 to 7 no acpi signal is generated. Acpi signal is generated only if I set
value to 0. There exist one exception. If previous value was 4 and I change it
to 0 no acpi signal is generated. It means after start or restart of laptop I
have to set some other value then 0 or 4. After that I can set value to 0
immediately and lid switch begins send acpi siglals well.

acpi_listen: (only if I set /proc/acpi/video/C083/DOS to 0)
button/lid C1C4 00000080 00000009
video C083 00000080 00000000
thermal_zone TZ2 00000081 00000000
thermal_zone TZ0 00000081 00000000
thermal_zone TZ3 00000081 00000000

The last value in the row beginning with button/lid changes incrementally.

Comment 17 Michal Schmidt 2010-04-20 21:01:55 UTC
(In reply to comment #16)
> There exist one exception. If previous value was 4 and I change it
> to 0 no acpi signal is generated.

I think this is because an oddity in the DSDT. Specifically the way the C140 method called from the _DOS method compares the current requested value with the previous value masked by 0x83.

4 & 0x83 is 0 which equals the current requested value 0 and therefore the body of C140 is not executed.

Comment 18 Matthew Garrett 2010-04-20 21:03:58 UTC
Do you get events if you set it from 4 to 1 and then to 4?

Comment 19 Jan Klícha 2010-04-20 21:09:07 UTC
No events for changes from 4 to 1 and again to 4.

Comment 20 Matthew Garrett 2010-04-20 21:45:23 UTC
Ugh. Ok, I see the issue now. The firmware is comparing _DOS to 0, while it should actually be ANDing it with 0x3 and comparing it with 0. This is somewhat infuriating, since we really want to set bit 3 of _DOS in order to disable automatic AC/DC transitions. I've checked various other HPs and found that they don't suffer from this problem, and the code in fact later does the correct thing in the lid event function.

I'd prefer not to revert this patch just because of two broken machines. I'll see if I can think of a workaround.

Comment 21 Massimiliano 2010-04-25 07:50:58 UTC
> I've checked various other HPs and found that they don't suffer...

Is this an HP issue only? I have a similar problem on a PackardBell Dot S IT/015 netbook. I try to read the state of the lid manually through HAL:

# hal-find-by-property --key button.type --string 'lid'
/org/freedesktop/Hal/devices/computer_logicaldev_input_4

#hal-get-property --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_4 --key button.state.value
true

The command returns that the lid is closed (value is "true"): but this is false, because the lid is open! So I try to set the value manually:

#hal-set-property --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_4 --key button.state.value --bool false

# cat /proc/acpi/button/lid/LID0/state
state:      closed

Nothing happens! If I do the same thing in my AcerTravelmate laptop it is immediatly suspended (because the state of the lid has changed). Neverthless the state of the lid has changed for HAL:

#hal-get-property --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_4 --key button.state.value
false

Is this the same bug or should I open a new one?

Comment 22 Michal Schmidt 2010-04-25 12:39:59 UTC
Massimiliano,
it looks like a different issue because on the HP mini 2140
the /proc/acpi/button/lid/*/state file always shows the correct
lid state and the bug is only that it does not generate events
when the state changes.
Your problem might be related to this one only if changing
the /proc/acpi/video/*/DOS setting would have an influence on it.

Comment 23 bielcardona 2010-05-01 11:13:35 UTC
Hi all,
this bug also applies to HP mini 5101.
On startup, the state of lid in /proc/acpi/button/lid/C1D0/state is always correct, but it generates no signals (checked with acpi_listen).
If i manually set:
echo 1 > /proc/acpi/video/C088/DOS
echo 0 > /proc/acpi/video/C088/DOS
then everything works ok.
Is there a way that I can execute those two commands on startup by default? or maybe this could be dangerous?

Thanks

Comment 24 Michal Schmidt 2010-05-02 17:57:53 UTC
(In reply to comment #23)
> If i manually set:
> echo 1 > /proc/acpi/video/C088/DOS
> echo 0 > /proc/acpi/video/C088/DOS
> then everything works ok.
> Is there a way that I can execute those two commands on startup by default? or
> maybe this could be dangerous?

It should be safe. You can use /etc/rc.local.

Comment 25 Alexander Saprykin 2010-06-20 14:05:25 UTC
(In reply to comment #23)
> If i manually set:
> echo 1 > /proc/acpi/video/C088/DOS
> echo 0 > /proc/acpi/video/C088/DOS
> then everything works ok.

The same issue for me on HP 530 laptop. After these two commands all is work fine.

Comment 26 Vic Ricker 2010-07-04 04:56:11 UTC
I have a System 76 Pangolin Performance panp4n.  It came with Ubuntu, but I replaced with Fedora, currently F13.

It appears to have the same problem.  /proc/acpi/button/lid/LID0/state shows the proper lid state when the lid opens and closes, but the laptop will not suspend.

I also have a problem when going on battery power.  The LCD dims, but the gnome battery applet continues to show that the laptop is running on AC.

/proc/acpi/battery/BAT0/state also shows the correct state.

acpi_listen shows nothing.

Comment 27 João Gomes 2010-10-19 23:30:08 UTC
Could this be related with the following?

https://bugzilla.gnome.org/show_bug.cgi?id=565661

Comment 28 João Gomes 2010-10-20 11:22:58 UTC
I cannot apply the workaround.
It says "permission denied", even if I use sudo.

$ sudo echo 1 > /proc/acpi/video/GFX0/DOS
bash: /proc/acpi/video/GFX0/DOS: Permission denied
$ sudo echo 0 > /proc/acpi/video/GFX0/DOS
bash: /proc/acpi/video/GFX0/DOS: Permission denied

I also noticed another thing.
If I do the following it recognizes correctly if the lid is closed or open.

(with the lid closed)
$ cat /proc/acpi/button/lid/LID/state
state: closed

(with the lid open)
$ cat /proc/acpi/button/lid/LID/state
state: open

But the output of the gnome-power-manager in verbose mode, with the lid open, says that the lid is closed:

TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_set_mode,108
 - Doing a state transition: normal
TI:12:09:52 TH:0x8a7e8b8 FI:gpm-manager.c FN:gpm_manager_idle_changed_cb,804
 - lid is closed, so we are ignoring ->NORMAL state changes
TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_evaluate,192
 - X not idle

Comment 29 Michal Schmidt 2010-10-20 18:55:52 UTC
(In reply to comment #28)
> I cannot apply the workaround.
> It says "permission denied", even if I use sudo.
> 
> $ sudo echo 1 > /proc/acpi/video/GFX0/DOS
> bash: /proc/acpi/video/GFX0/DOS: Permission denied

This is a common mistake. The output redirection is of course done by your shell before the command "sudo echo 1" is even started. Your shell runs unprivileged, so it fails to open the file for writing. Use a real root shell, or something like this:
sudo sh -c 'echo 1 > /proc/acpi/video/GFX0/DOS'

Comment 30 João Gomes 2010-10-20 19:11:47 UTC
aaaah you're right! And that explains why it didn't even ask for the password...

Thank you!

Comment 31 João Gomes 2010-10-20 22:04:18 UTC
From what I could see from the comments there are a different problem:

/proc/acpi/button/lid/LID0/state shows the correct state, but the gnome-power-manager does not recognizes the state changes.
In this case, the workaround doesn't solve the problem.
And, in the verbose mode, the gnome-power-manager shows:
"lid is closed, so we are ignoring ->NORMAL state changes"

Do you think this is a completely distinct problem?
Is there any possible solution?

My laptop is also an HP.

Comment 32 Bug Zapper 2010-11-04 10:43:43 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 33 Alexei Panov 2010-11-04 14:43:59 UTC
This bug has present also in Fedora 13, RHEL 6 and, maybe, in Fedora 14

Comment 34 Vic Ricker 2010-11-06 23:39:51 UTC
I can confirm that it is still a problem in F14 on System 76 Pangolin Performance.

Comment 35 Jan Klícha 2010-11-07 10:51:27 UTC
I upgraded my HP 2140 mini to Fedora 14 and I can confirm the same behavior as I described at the origin of this bug.

Comment 36 Martin Belohorka 2011-02-28 07:32:42 UTC
I have a Clevo M767TU with F14 and it also displays the same behavior. Clevo, Sager, system 76 and alienware are basically the same re-branded laptops.

In short. The state shows the correct value for the lid switch.

hal-get-property --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_3 --key button.state.value 
always evaluates to "false".

Vic, At one time, i actually had the AC plug detection working, but it needed several seconds inorder to switch state  in gnome-power-manager. Unfortunately, I cant remember exactly what settings I had then since it was not the problem i was trying to fix back then.

Comment 37 Martin Belohorka 2011-03-10 21:54:46 UTC
I have tried a couple of more things.
Some of them were fruitless.

I updated to acpid-2.0.8 from rawhide. No change
I updated to a kernel from rawhide. 2.6.38-something. No change

One that did work was to see what happens when I used a ubuntu liveCd. The ac_adapter detection worked and so did the lid and powerbutton.

Im not sure if it gives any new info as they apparently uses the old /proc/acpi/event system, or they did when 10.10 was released since acpid --version was from the old 1.x series.

Is there any other helpful information I can supply?

Comment 38 Vic Ricker 2011-03-11 04:00:54 UTC
I don't know a whole lot about how this stuff works so I grabbed the source of acpid and messed around with it a little.

It watches netlink socket and /dev/input/event*.  It doesn't appear that the lid switch is reported by any of these.

I was hoping that something was just messed up in there, and I could just add an event to call pm-suspend, but I think that's not the case.

Comment 39 Martin Belohorka 2011-03-11 07:42:50 UTC
I guess that you will see the same thing I saw. If you got the source of a 2.0.x version of acpid ( http://www.tedfelix.com/linux/acpid-netlink.html ) then you can find a debugging program called kacpimon with it. 

Kill off your current acpid and run this program. It should show all your netlink and input events as they occur. I got no output from it no matter what I did.

I guess my next step is to take the current kernel source rpm and include the /proc/acpi/events support again and see if this fixes the problem.

Comment 40 Martin Belohorka 2011-03-12 17:52:36 UTC
Just adding /proc/acpi/event support to the current fedora kernel did not solve the issue.

Comment 41 Martin Belohorka 2011-03-13 09:55:42 UTC
Ok I have a solution.

* update acpid to the 2.0.8 in rawhide
* recompile the current ( 2.6.35.11-83) fedora supplied kernel from fedora WITH the ACPI_PROC_EVENT support and WITHOUT all fedora supplied patches containing the name "acpi"

When I after booting, i run
 acpid -d -f -l

I can see, for instance:

acpid: procfs completed event "processor CPU0 00000081 00000000"
acpid: procfs received event "processor CPU1 00000081 00000000"
acpid: 0 total rules matched
acpid: procfs completed event "processor CPU1 00000081 00000000"
acpid: procfs received event "button/lid LID0 00000080 00000001"
acpid: 0 total rules matched
acpid: procfs completed event "button/lid LID0 00000080 00000001"
acpid: procfs received event "processor CPU0 00000081 00000000"


Next step: I will start with reverting to the current f14 acpid (2.0.6 I belive). If it still works, i will either go for the ACPI_PROC_EVENT support or for some of the least probable patches.

Comment 42 Martin Belohorka 2011-03-13 10:04:55 UTC
acpid 2.0.7 (current fedora f14) still works. It still triggers on the procfs interface.

Comment 43 Martin Belohorka 2011-03-13 10:36:46 UTC
(I guess I am reporting too small increments of progress, but as i only have one computer I have to test and report errors on the same one, this is the way it has to be)

Anyway. acpid apparently had an option for forcing
 netlink interface and dont care about /proc/acpi/event

acpid -d -f -l -n

i can see, for instance:

acpid: completed netlink event "processor LNXCPU:01 00000080 00000000"
acpid: received netlink event "processor LNXCPU:01 00000081 00000000"
acpid: 0 total rules matched
acpid: completed netlink event "processor LNXCPU:01 00000081 00000000"
acpid: received netlink event "battery PNP0C0A:00 00000081 00000001"
acpid: 0 total rules matched
acpid: completed netlink event "battery PNP0C0A:00 00000081 00000001"

This makes the acpi patches to the kernel the only remaining modification. after the test if the kernel without proc/acpi/event support, i will start applying the patches one by one again.

These are the patches i currently have removed.

[martin@Delamain SPECS]$ grep -i acpi kernel.spec 
%define buildid .acpitest
#Patch384: pci-acpi-disable-aspm-if-no-osc.patch
#Patch390: linux-2.6-defaults-acpi-video.patch
#Patch391: linux-2.6-acpi-video-dos.patch
#Patch393: acpi-ec-add-delay-before-write.patch
#Patch394: linux-2.6-acpi-debug-infinite-loop.patch
#Patch395: acpi-update-battery-information-on-notification-0x81.patch
#Patch454: thinkpad-acpi-fix-backlight.patch
# silence the ACPI blacklist code
# Patch2802: linux-2.6-silence-acpi-blacklist.patch
# ACPI
# ApplyPatch linux-2.6-defaults-acpi-video.patch
# ApplyPatch linux-2.6-acpi-video-dos.patch
# ApplyPatch acpi-ec-add-delay-before-write.patch
# ApplyPatch linux-2.6-acpi-debug-infinite-loop.patch
# ApplyPatch acpi-update-battery-information-on-notification-0x81.patch
# disable aspm if acpi doesn't provide an _OSC method
# ApplyPatch pci-acpi-disable-aspm-if-no-osc.patch
# ACPI
# ApplyPatch thinkpad-acpi-fix-backlight.patch
# silence the ACPI blacklist code
# ApplyPatch linux-2.6-silence-acpi-blacklist.patch
- Backport the ACPI battery notification patch (#656738)
   pnpacpi-cope-with-invalid-device-ids.patch
- pnpacpi: cope with invalid device IDs. (rhbz#641468)
- drm-nouveau-acpi-edid-fix.patch: drop, merged into updates
- nouveau: fix oops in acpi edid support
- Replace pci-acpi-disable-aspm-if-no-osc.patch with
- pci-acpi-disable-aspm-if-no-osc.patch, pci-aspm-dont-enable-too-early.patch
- Add a patch to debug an infinite loop warning from acpi.
- linux-2.6-acpi-video-export-edid.patch: rebase & copy from F-13
- acpi-ec-add-delay-before-write.patch: copy from F-13
- thinkpad-acpi-fix-backlight.patch: Fix backlight support on some recent

Comment 44 Martin Belohorka 2011-03-13 17:32:39 UTC
My issue is a copy of https://bugzilla.redhat.com/show_bug.cgi?id=599679

Comment 45 Tommi Kyntola 2012-06-21 07:49:24 UTC
I have to bump this up again because I upgraded this hp mini to fedora 16 and current fedora kernel (3.4.2-1) no longer has /proc/acpi/video at all making the workaround unasble.

What ever happened to that file?
(I upgraded from 13 to 14,15 and finally 16 overnight and didn't notice this until now, so I can't say for sure when the /proc/acpi/video/C088/DOS disappeared)

And as before, the lid changes state correctly in /proc/acpi/button/lid/C1D0/state but no action is taken by the system and suspend works just fine from the power button.

Comment 46 Chris Wilson 2012-07-31 12:29:10 UTC
I have seen this problem with an Intel Classmate running Ubuntu 10.04 LTS (2.6.32-36 kernel) and also when using a stock kernel (2.6.32.59) which enabled me to do ACPI debugging.

It turns out that the ACPI DSDT table contains a control method _Q2A, which is repeatedly triggered by the embedded controller when automatic brightness control of the backlight is enabled (Fn+F10). This method sends repeated notifications to the kernel to adjust the brightness level, with a delay. These notifications queue up inside the kernel and cause long delays in dispatch of other notifications, such as LID events.

You can see this happening if you build a kernel with the following options:

CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y

and then run the following commands:

/etc/init.d/rsyslog stop
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_layer
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_level
echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo egrep '(push query execution|ev_queue_notify_reques)' /proc/kmsg

This will show you 0x2a (_Q2A) events being constantly triggered by the embedded controller:

<7>[  380.985859] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[  380.996304]   evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[  380.996331]   evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[  381.008269]   evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[  381.008295]   evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8
<7>[  381.084229] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[  381.120283]   evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[  381.120310]   evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[  381.132316]   evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[  381.132342]   evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8

Once you press Fn+F7 to stop the automatic brightness control, the Notify queue slowly empties. LID events go to the back of the queue and so they can be executed much later when the queue is full.

It's made worse because the kernel doesn't have a driver for the Notify events (FNBT, 83 and 93) sent by the _Q2A control method, so it doesn't adjust the brightness at all, so next time the EC triggers the _Q2A control method it runs for just as long. If the kernel did adjust the brightness, the next _Q2A would do nothing.

Something similar may be happening in your case and delaying the reception of the LID events that you actually want. You might want to trace all of ACPI instead of just ec.c, since any _E or _L control method could be causing the delay, not just the embedded controller. If you see a long delay between:

<7>[  380.985859] acpi:ACPI: EC: push query execution (0x??) on queue

when you close the lid, and:

<4>[ 1064.570281]   evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [LID_] Node f7018060 Value 0x80 (**Device Specific**)

that means that the ACPI interpreter is busy doing something else (which maybe you can't see yet) instead of executing the Notify for the LID event.

Comment 47 Fedora End Of Life 2012-08-16 19:29:51 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.