subject:"\[Bug 89860\] Re\: \/proc\/acpi\/button\/lid\/\*\/state always says open"

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2014-02-18 Thread juanmanuel

For those of you with a Samsung laptop showing this problem, please see
this issue:

   https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061

in particular my last two posts.

I think a kernel patch can be made to flush the events from the embedded
controller, at resume, in the same way that I do it with my C program
that I attached to that issue for Samsung laptops (and maybe others with
the problem). TL;DR: If the events don't get flushed (queried), the GPE
of the EC is never triggered again (chicken and egg situation), my
little program queries the events and "unstucks" the EC immediatly.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
  /proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-10-18 Thread adrian

** Attachment added: "fwts --interactive test after hibernate"
   
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860/+attachment/3402397/+files/results-after-hibernate.log

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
  /proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-10-18 Thread adrian

I've been running the 'fwts --interactive' test before and after hibernate.
The most significant parts:

Before:
Test 2 of 3: Test LID buttons on a single open/close.
Got 25 interrupt(s) on GPE gpe10.
Got 13 interrupt(s) on GPE gpe1D.
Got 38 interrupt(s) on GPE gpe_all.
Got 25 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
FAILED [HIGH] NoLidState: Test 2, Could not detect lid closed state.
FAILED [HIGH] NoSCIInterrupts: Test 2, Did not detect any SCI interrupts.
FAILED [HIGH] NoGPEInterrupts: Test 2, Did not detect any GPE interrupts.
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

After:
Test 2 of 3: Test LID buttons on a single open/close.
Got 1 interrupt(s) on GPE gpe1D.
Got 1 interrupt(s) on GPE gpe_all.
Got 1 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
PASSED: Test 2, Detected lid closed state.
Got 1 interrupt(s) on GPE gpe11.
Got 1 interrupt(s) on GPE gpe1D.
Got 2 interrupt(s) on GPE gpe_all.
Got 2 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

Complete results are attached.

** Attachment added: "fwts --interactive test before hibernate"

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860/+attachment/3402396/+files/results-before-hibernate.log

--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
/proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-10-17 Thread adrian

I'm having the same problem using Linux Mint 13 (based on Ubuntu 12.04)
with a Compaq nc6000.

Lid state /proc/acpi/button/lid/C139/status is always set to "open", but
if I hibernate (pm-hibernate) and wake-up, lid button works correctly.

acpi_listen shows in both cases (with and without hibernating) the lid events:
button/lid C139 0080 0048

The last number is increased in each event.
In each event, /etc/acpi/lid.sh is called. This script checks 
/proc/acpi/button/lid/*/state and acts in consecuence.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
  /proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-08-24 Thread taj

It seems a typical HP problem
For me (NC6320) I check /proc/acpi/video/C083/DOS

I fixed this in 10.04 Lucid, by putting the following lines (both
needed, in this order!) into /etc/rc.local

echo 1 > /proc/acpi/video/C083/DOS
echo 0 > /proc/acpi/video/C083/DOS

However, after dist-upgrade to 12.04 this trick does not work anymore...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
  /proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-07-31 Thread gcc

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 '0x0004' | sudo tee /sys/module/acpi/parameters/debug_layer
echo '0x0004' | 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.

These web pages are useful references:

* https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
* http://www.mjmwired.net/kernel/Documentation/acpi/method-customizing.txt
* http://www.kernel.org/doc/Documentation/acpi/debug.txt (beware the verbose 
spew of useless messages)
* 
http://kernel.ubuntu.com/~cking/presentations/gpes-and-embedded-controller/EmbeddedControllerAndACPI.odp

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/89860

Title:
  /proc/acpi/button/lid/*/state always says "open"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 89860] Re: /proc/acpi/button/lid/*/state always says "open"

2012-07-12 Thread knarf

There is a workaround for this bug which has plagued the HP Compaq
nc6120 I'm using ever since, well, forever. I was put on the track of
this workaround by reading an old Advogato blog entry
(http://www.advogato.org/person/mjg59/diary/62.html) where someone by
the handle of 'mjg59' tells about his adventures in ACPI-land and the
possible use of setpci to get around ACPI table bugs (which I consider
this to be). He does not state which register he changed but I found
more information elsewhere which implicated register 0xbb. As to which
value to poke there I have experimented a bit as this seems to differ
between systems. On the nc6120 the following command, when executed
after *each* ACPI-event, restores functionality to the lid switch:

sudo setpci -s 00:1f.0 bb.b=04

I attached a tarball containing two ACPI scripts which make that this
command is executed after every ACPI event. Using these scripts, my
machine works as expected: the display goes black when the lid switch is
pressed/the lid is closed. Opening the lid brings the display back to
life. Monitoring the state of the lid switch (cat
/proc/acpi/button/lid/C1E9/state on this system) shows the reported
state to reflect the actual condition, where before it would stay stuck
on 'closed'.

So, if you are also bitten by this bug - which has been around for
*years* - you might want to try the setpci command I mentioned. If this
works (directly or after changing the poked value) you might want to
give these ACPI scripts a try. If you had to change the poked value to
make it work, you should also change the value in the
/etc/acpi/handler.sh script.

1 2 >

1 - 100 of 125 matches

Mail list logo