Re: Regression in thinkpad-acpi events

Re: Regression in thinkpad-acpi events

[Maciej Rutecki]

(add more CCs)

On poniedziałek, 14 listopada 2011 o 20:44:14 Natanji wrote:
> With 3.0 it was still fine, that much is for sure. The problem came
> with the upgrade to 3.1. I've never even compiled my own kernel so I
> cannot bisect. Sorry...
> 
> Regards,
> Natanji
> 
> On Mon 14 Nov 2011 08:31:06 PM CET, Maciej Rutecki wrote:
> > On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
> >> Hello everyone,
> >> first time posting on this last, and I'm not subscribed, so please CC
> >> any replies to me. ;)
> >> 
> >> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
> >> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
> >> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely
> >> gone.
> >> 
> >> This can be observed by using the acpi_listen command. For instance, no
> >> ACPI events happen when swiveling the display, and the sleep button
> >> returns
> >> 
> >> 	button/sleep SBTN 00000080 00000000
> >> 
> >> instead of the previous
> >> 
> >> 	ibm/hotkey HKEY 00000080 00001004
> >> 
> >> The bug was reported in the Arch Linux bugtracker [1] and it was
> >> suggested to report this upstream, so this is what I did now. Sadly I
> >> have no idea how I could find out if this is indeed a kernel bug or not;
> >> I have never compiled my own kernel so what I can give you is probably
> >> limited. But I suppose quite a few members of this list use a Thinkpad.
> >> If there is anything else I can help out with, just tell me.
> >> 
> >> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658
> > 
> > Can you check that 3.1 works or not? Or try bisection that it is
> > regression after 3.0 or 3.1 kernel.
> > 
> > Regards

-- 
Maciej Rutecki
http://www.mrutecki.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in thinkpad-acpi events

[Tom Gundersen]

On Tue, Nov 15, 2011 at 7:18 AM, Maciej Rutecki
<maciej.rutecki@gmail.com> wrote:
> (add more CCs)
>
> On poniedziałek, 14 listopada 2011 o 20:44:14 Natanji wrote:
>> With 3.0 it was still fine, that much is for sure. The problem came
>> with the upgrade to 3.1. I've never even compiled my own kernel so I
>> cannot bisect. Sorry...
>>
>> Regards,
>> Natanji
>>
>> On Mon 14 Nov 2011 08:31:06 PM CET, Maciej Rutecki wrote:
>> > On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
>> >> Hello everyone,
>> >> first time posting on this last, and I'm not subscribed, so please CC
>> >> any replies to me. ;)
>> >>
>> >> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
>> >> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
>> >> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely
>> >> gone.
>> >>
>> >> This can be observed by using the acpi_listen command. For instance, no
>> >> ACPI events happen when swiveling the display, and the sleep button
>> >> returns
>> >>
>> >>    button/sleep SBTN 00000080 00000000
>> >>
>> >> instead of the previous
>> >>
>> >>    ibm/hotkey HKEY 00000080 00001004
>> >>
>> >> The bug was reported in the Arch Linux bugtracker [1] and it was
>> >> suggested to report this upstream, so this is what I did now. Sadly I
>> >> have no idea how I could find out if this is indeed a kernel bug or not;
>> >> I have never compiled my own kernel so what I can give you is probably
>> >> limited. But I suppose quite a few members of this list use a Thinkpad.
>> >> If there is anything else I can help out with, just tell me.
>> >>
>> >> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658
>> >
>> > Can you check that 3.1 works or not? Or try bisection that it is
>> > regression after 3.0 or 3.1 kernel.

I'm observing the same, also with Arch Linux, and a ThinkPad x60:
# uname -a
Linux x60 3.1.1-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

The kernel config can be found here:
<http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux>.

As requested:
# grep . /sys/bus/platform/devices/thinkpad*/*
/sys/bus/platform/devices/thinkpad_acpi/bluetooth_enable:1
grep: /sys/bus/platform/devices/thinkpad_acpi/cmos_command: Permission denied
/sys/bus/platform/devices/thinkpad_acpi/hotkey_all_mask:0x00ffffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_enabled:0
/sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_mask:0x0000080c
/sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
/sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000
/sys/bus/platform/devices/thinkpad_acpi/modalias:platform:thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/uevent:DRIVER=thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/uevent:MODALIAS=platform:thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/wakeup_hotunplug_complete:0
/sys/bus/platform/devices/thinkpad_acpi/wakeup_reason:0
/sys/bus/platform/devices/thinkpad_hwmon/fan1_input:2780
/sys/bus/platform/devices/thinkpad_hwmon/modalias:platform:thinkpad_hwmon
/sys/bus/platform/devices/thinkpad_hwmon/name:thinkpad
/sys/bus/platform/devices/thinkpad_hwmon/pwm1:255
/sys/bus/platform/devices/thinkpad_hwmon/pwm1_enable:2
/sys/bus/platform/devices/thinkpad_hwmon/temp10_input:49000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp11_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp12_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp13_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp14_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp15_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp16_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp1_input:62000
/sys/bus/platform/devices/thinkpad_hwmon/temp2_input:56000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp3_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp4_input:58000
/sys/bus/platform/devices/thinkpad_hwmon/temp5_input:37000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp6_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp7_input:37000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp8_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp9_input:46000
/sys/bus/platform/devices/thinkpad_hwmon/uevent:DRIVER=thinkpad_hwmon
/sys/bus/platform/devices/thinkpad_hwmon/uevent:MODALIAS=platform:thinkpad_hwmon
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

> >> >> This can be observed by using the acpi_listen command. For instance, no
> >> >> ACPI events happen when swiveling the display, and the sleep button
> >> >> returns
> >> >>
> >> >>    button/sleep SBTN 00000080 00000000
> >> >>
> >> >> instead of the previous
> >> >>
> >> >>    ibm/hotkey HKEY 00000080 00001004
> >> >>
> 
> I'm observing the same, also with Arch Linux, and a ThinkPad x60:
> # uname -a
> Linux x60 3.1.1-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
> x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
> 
> The kernel config can be found here:
> <http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux>.
> 
> As requested:
> # grep . /sys/bus/platform/devices/thinkpad*/*
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000

Well, the driver has connected to the firmware, and should be working.  And
there were no changes to the code from v3.0 to v3.1.1.  So, it is either a
bug in something else, a problematic interaction of the driver with
something else, or a latent thinkpad-acpi bug that some change elsewhere has
exposed.

Are the events reported by acpi_listen from arch-linux exactly the same in
v3.0.9 and v3.1.1 ?  I know some events are missing in your v3.1.1, but I am
interested in the ones that do get reported.

Although you really should be using the input device for the hotkeys, and
not any of the 0x10xx events.  Those are driver-specific and deprecated, it
is all explained in Documentation/laptops/thinkpad-acpi.txt.  So, it really
might mean that you have something in userspace reading that input device
and synthesizing the ACPI HKEY events thinkpad-acpi deprecated for a long
time now.  I know some distros did that instead of switching to an
input-device-based hotkey daemon.  Please check for that possibility,
that daemon could be the one having problems with 3.1.1...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in thinkpad-acpi events

[Tom Gundersen]

Hi Henrique,

On Wed, Nov 16, 2011 at 12:03 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
>> As requested:
>> # grep . /sys/bus/platform/devices/thinkpad*/*
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000
>
> Well, the driver has connected to the firmware, and should be working.  And
> there were no changes to the code from v3.0 to v3.1.1.  So, it is either a
> bug in something else, a problematic interaction of the driver with
> something else, or a latent thinkpad-acpi bug that some change elsewhere has
> exposed.
>
> Are the events reported by acpi_listen from arch-linux exactly the same in
> v3.0.9 and v3.1.1 ?  I know some events are missing in your v3.1.1, but I am
> interested in the ones that do get reported.
>
> Although you really should be using the input device for the hotkeys, and
> not any of the 0x10xx events.  Those are driver-specific and deprecated, it
> is all explained in Documentation/laptops/thinkpad-acpi.txt.  So, it really
> might mean that you have something in userspace reading that input device
> and synthesizing the ACPI HKEY events thinkpad-acpi deprecated for a long
> time now.  I know some distros did that instead of switching to an
> input-device-based hotkey daemon.  Please check for that possibility,
> that daemon could be the one having problems with 3.1.1...

It looks like my problem was something else. We don't do anything to
synthesize the ACPI HKEY events (AFAIK), so I believe that KDE (which
I am using) should be using the input events and that the HKEY stuff
does not matter.

I am still trying to figure out why my laptop does not always go to
sleep when I close my lid, but it turns out that I cannot reproduce it
reliably so it is taking me some time.

As to the original report about the change in HKEY events, this is
(probably) due to PROCFS_ACPI being disabled in the Arch kernel as of
3.1.

Cheers,

Tom

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2011, Tom Gundersen wrote:
> It looks like my problem was something else. We don't do anything to
> synthesize the ACPI HKEY events (AFAIK), so I believe that KDE (which
> I am using) should be using the input events and that the HKEY stuff
> does not matter.

I have no idea if KDE can do it or not.

> As to the original report about the change in HKEY events, this is
> (probably) due to PROCFS_ACPI being disabled in the Arch kernel as of
> 3.1.

Well, maybe Arch needs to update its userspace to cope with its kernel...
but still, we will only really know whether this is the problem or not if
someone checks the input devices and the acpi events over netlink in that
Arch kernel.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Henning Schild]

I came across this problem after updating the kernel on my laptop. The
hotkeys actually work until after the first wakeup from hibernation. I
tried 3.0.9 3.1.1 3.1.2 and for hibernation i used tuxonice. It is not
only the acpi events that stop working, also the events that should be
delivered as input events. Reloading the module does not help. Having
the module not loaded for the hibernation also does not help. After
waking up the events will be gone.

Do the Arch kernels use tuxonice? Do you receive events before the
first hibernation?

Henning

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Natanji]

The standard Arch kernel does not use tuxonice, you need to build your
kernel manually if you want it. I also don't receive these events before
the first hibernation, so you might be having a different problem.

Concerning PROCFS_ACPI, a user posted over at the bug report in the Arch
bugtracker [1] that re-enabling this did not solve this problem. So the
problem probably lies somewhere else still...

[1] https://bugs.archlinux.org/task/26658#comment85971

On Sun 27 Nov 2011 02:23:46 AM CET, Henning Schild wrote:
> I came across this problem after updating the kernel on my laptop. The
> hotkeys actually work until after the first wakeup from hibernation. I
> tried 3.0.9 3.1.1 3.1.2 and for hibernation i used tuxonice. It is not
> only the acpi events that stop working, also the events that should be
> delivered as input events. Reloading the module does not help. Having
> the module not loaded for the hibernation also does not help. After
> waking up the events will be gone.
>
> Do the Arch kernels use tuxonice? Do you receive events before the
> first hibernation?
>
> Henning

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Wed, 30 Nov 2011, Natanji wrote:
> The standard Arch kernel does not use tuxonice, you need to build your
> kernel manually if you want it. I also don't receive these events before
> the first hibernation, so you might be having a different problem.

Just a hunch: check /proc/interrupts.  One of them must be assigned to acpi,
and it *must* increase when you press hotkeys, etc.

Does it?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Natanji]

Yes, there are dozens of acpi interrupts every second.

$ cat /proc/interrupts | grep acpi ; sleep 1; cat /proc/interrupts | 
grep acpi
  9:    1776309          0   IO-APIC-fasteoi   acpi
  9:    1776332          0   IO-APIC-fasteoi   acpi

On Wed 30 Nov 2011 12:15:07 PM CET, Henrique de Moraes Holschuh wrote:
> On Wed, 30 Nov 2011, Natanji wrote:
>> The standard Arch kernel does not use tuxonice, you need to build your
>> kernel manually if you want it. I also don't receive these events before
>> the first hibernation, so you might be having a different problem.
>
> Just a hunch: check /proc/interrupts.  One of them must be assigned to acpi,
> and it *must* increase when you press hotkeys, etc.
>
> Does it?
>