Regression in thinkpad-acpi events

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

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

(add more CCs)

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

Well, please keep me in the CC. I'm the thinkpad-acpi maintainer.

That usually happens when you don't have thinkpad-acpi loaded at all.

Does lsmod report that thinkpad-acpi is loaded? Are there any messages from thinkpad-acpi in the kernel log?

  "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

thinkpad-acpi is definitely loaded:

$ lsmod | grep think
thinkpad_acpi          54704  0
snd                    43817  11
snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,thinkpad_acpi,snd_timer
rfkill                 12470  3 bluetooth,thinkpad_acpi,cfg80211
nvram                   4765  1 thinkpad_acpi

I also noticed that removing or replacing the tablet pen in its slot still yields an ibm/hotkey acpi event. This is the output of $ acpi_listen when I do this:
ibm/hotkey IBM0068:00 00000080 0000500c
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000
ibm/hotkey IBM0068:00 00000080 0000500b
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000

thinkpad-acpi also shows up in kernel log:

# cat /var/log/kernel.log | grep thinkpad_acpi
Nov 14 10:00:13 localhost kernel: [   14.207399] thinkpad_acpi: ThinkPad
ACPI Extras v0.24
Nov 14 10:00:13 localhost kernel: [   14.207403] thinkpad_acpi:
http://ibm-acpi.sf.net/
Nov 14 10:00:13 localhost kernel: [   14.207406] thinkpad_acpi: ThinkPad
BIOS 7JET30WW (1.15 ), EC 7JHT13WW-1.04
Nov 14 10:00:13 localhost kernel: [   14.207409] thinkpad_acpi: Lenovo
ThinkPad X60 Tablet, model 6363WDK
Nov 14 10:00:13 localhost kernel: [   14.224471] thinkpad_acpi: detected
a 8-level brightness capable ThinkPad
Nov 14 10:00:13 localhost kernel: [   14.231577] thinkpad_acpi: ACPI
backlight control delay disabled
Nov 14 10:00:13 localhost kernel: [   14.232156] thinkpad_acpi: radio
switch found; radios are enabled
Nov 14 10:00:13 localhost kernel: [   14.232897] thinkpad_acpi: possible
tablet mode switch found; ThinkPad in laptop mode
Nov 14 10:00:13 localhost kernel: [   14.257007] thinkpad_acpi: rfkill
switch tpacpi_bluetooth_sw: radio is blocked
Nov 14 10:00:13 localhost kernel: [   14.263972] thinkpad_acpi: Standard
ACPI backlight interface available, not loading native one
Nov 14 10:00:13 localhost kernel: [   14.264099] thinkpad_acpi: Console
audio control enabled, mode: monitor (read only)
Nov 14 10:00:13 localhost kernel: [   14.265628] input: ThinkPad Extra
Buttons as /devices/platform/thinkpad_acpi/input/input5
Nov 14 10:00:16 localhost kernel: [   19.996929] thinkpad_acpi:
deprecated sysfs attribute: access by process with PID 1076
Nov 14 10:00:16 localhost kernel: [   19.996934] thinkpad_acpi: WARNING:
sysfs attribute bluetooth_enable is deprecated and will be removed.
Please switch to generic rfkill before year 2010
Nov 14 12:58:34 localhost kernel: [ 5453.928107] thinkpad_acpi: ACPI
backlight control delay disabled
Nov 14 19:30:16 localhost kernel: [23290.557775] Modules linked in: fuse
hidp hid cpufreq_ondemand ext3 jbd ecb btusb bluetooth pcmcia arc4
snd_hda_codec_analog iwlagn sdhci_pci firewire_ohci sdhci mmc_core
firewire_core yenta_socket pcmcia_rsrc pcmcia_core uhci_hcd mac80211
crc_itu_t snd_hda_intel ehci_hcd snd_hda_codec psmouse thinkpad_acpi
snd_hwdep cfg80211 e1000e serio_raw iTCO_wdt snd_pcm iTCO_vendor_support
snd_timer i2c_i801 snd usbcore snd_page_alloc soundcore rfkill ac nvram
battery evdev thermal ipv6 acpi_cpufreq freq_table processor mperf ext4
mbcache jbd2 crc16 cryptd aes_i586 aes_generic xts gf128mul dm_crypt
dm_mod ata_piix sd_mod ahci libahci libata scsi_mod i915 drm_kms_helper
drm i2c_algo_bit button i2c_core video intel_agp intel_gtt agpgart
Nov 14 19:30:16 localhost kernel: [23292.952019] thinkpad_acpi: ACPI
backlight control delay disabled

So I suppose it is loaded alright, but just some of the events don't work anymore at all (like for my physical rfkill switch) and/or get overridden by other "standard" events (like with the sleep button).

Are those events above *exactly* the same on the kernel that is not causing problems?

Please give me the output of:
grep . /sys/bus/platform/devices/thinkpad*/*

(adjust that path if required, it may be slightly incorrect). I really want to know the contents of the hotkey_* sysfs nodes.

  "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

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Henrique,

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

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

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

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

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

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

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