| Summary: | Resume from sleep fails to restore keyboard and touchpad controls | ||
|---|---|---|---|
| Product: | libevdev | Reporter: | Adrian Gabor <adrianovidiugabor> |
| Component: | Core | Assignee: | Peter Hutterer <peter.hutterer> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, jwrdegoede, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
journalctl output
dmesg output lspci output xorg.log |
||
Created attachment 113135 [details]
dmesg output
Created attachment 113136 [details]
lspci output
Created attachment 113137 [details]
xorg.log
The radeon driver doesn't have anything to do with the keyboard or touchpad so I doubt it's related. I guess this is probably related to the kernel input drivers or maybe some special platform handling for your system. Ok Alex, thanks for reassigning it. please run evemu-record against the device after you lost input. do you still see events from the kernel? Is it ok if I run evemu after rebooting or not? Because when I loose input I lose it for good, it doesn't come back until I reboot my laptop. (I can't log in, can't do commands) When this happens I usually plug my external usb mouse and do a reboot from GDM. But if this is not ok, I guess I can lookup an external usb keyboard and do the test with that. Ok, so I have some updates. I managed to obtain the info by using only the external mouse. First difference: When executing evemu-describe under normal circumstances I get: [code] /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: 2.4G Wireless Keyboard&Mouse /dev/input/event2: 2.4G Wireless Keyboard&Mouse /dev/input/event3: Video Bus /dev/input/event4: Video Bus /dev/input/event5: Lid Switch /dev/input/event6: Power Button /dev/input/event7: Sleep Button /dev/input/event8: Power Button /dev/input/event9: PC Speaker /dev/input/event10: Asus WMI hotkeys /dev/input/event11: HDA ATI HDMI HDMI/DP,pcm=3 /dev/input/event12: USB Camera /dev/input/event13: HD-Audio Generic Mic /dev/input/event14: HD-Audio Generic Headphone /dev/input/event15: ETPS/2 Elantech Touchpad [/code] After I lose input evemu-describe will not show the touchpad at all only the other devices. (will still display the integrated keyboard) I then went on and executed evemu-record on the integrated keyboard, and indeed, no event is recorded and displayed when pressing keys. If the device disappears that'd be a kernel bug then. CC-ing Hans and Benjamin, let's see if there's something obvious here. I'm afraid I don't have anything useful to add there, there are no known elantech issues where an elantech touchpad disappears after a suspend/resume, so this seems to be something new. Adrian, can you please collect the output of dmesg after a suspend / resume where the touchpad is gone ? @Hans de Goede. Thank you for helping me! I'll attach a dmesg output but it might take a few days; resume freezes happen less these days (but still happen nonetheless). Anyway, isn't the journalctl output file above of any help? It records a failed resume. The computer went to sleep at 20:59:26 and woke up in a failed state (no input) at 21:51:14. For example these two lines : --feb 03 21:51:15 adrianPC gdm-Xorg-:0[297]: (II) config/udev: removing device ETPS/2 Elantech Touchpad --feb 03 21:51:15 adrianPC gdm-Xorg-:0[297]: (II) UnloadModule: "synaptics" Everything from 22:15:55 onward is recorded after a system reboot. (shouldn't be of much interest/importance). (In reply to Adrian Gabor from comment #11) > @Hans de Goede. > > Thank you for helping me! > > I'll attach a dmesg output but it might take a few days; resume freezes > happen less these days (but still happen nonetheless). > > Anyway, isn't the journalctl output file above of any help? > It records a failed resume. The computer went to sleep at 20:59:26 and woke > up in a failed state (no input) at 21:51:14. > > For example these two lines : > --feb 03 21:51:15 adrianPC gdm-Xorg-:0[297]: (II) config/udev: removing > device ETPS/2 Elantech Touchpad > --feb 03 21:51:15 adrianPC gdm-Xorg-:0[297]: (II) UnloadModule: "synaptics" > > Everything from 22:15:55 onward is recorded after a system reboot. > (shouldn't be of much interest/importance). Ah yes, the journalctl output includes the dmesg bits from after the resume, no clue there really wrt what is wrong though. Can you please do "lsmod" and provide the output here ? Output of a 'good' (with input) lsmod. Module Size Used by fuse 87410 7 kvm_amd 59168 0 kvm 426425 1 kvm_amd uvcvideo 83143 0 videobuf2_vmalloc 12816 1 uvcvideo videobuf2_memops 12519 1 videobuf2_vmalloc videobuf2_core 39635 1 uvcvideo v4l2_common 12995 1 videobuf2_core videodev 135040 3 uvcvideo,v4l2_common,videobuf2_core joydev 17063 0 mousedev 17272 0 media 18365 2 uvcvideo,videodev crct10dif_pclmul 13394 0 crc32_pclmul 12915 0 crc32c_intel 21809 0 arc4 12536 2 snd_hda_codec_realtek 63196 1 snd_hda_codec_generic 63087 1 snd_hda_codec_realtek ath9k 137724 0 ghash_clmulni_intel 12978 0 aesni_intel 167997 0 snd_hda_codec_hdmi 49263 1 ath9k_common 21746 1 ath9k asus_nb_wmi 20664 0 asus_wmi 22781 1 asus_nb_wmi ath9k_hw 428656 2 ath9k_common,ath9k ath 26067 3 ath9k_common,ath9k,ath9k_hw sparse_keymap 12818 1 asus_wmi radeon 1546803 5 mac80211 608652 1 ath9k aes_x86_64 16719 1 aesni_intel snd_hda_intel 26387 5 snd_hda_controller 26938 1 snd_hda_intel lrw 12757 1 aesni_intel gf128mul 12970 1 lrw glue_helper 12649 1 aesni_intel mac_hid 12633 0 cfg80211 453926 4 ath,ath9k_common,ath9k,mac80211 rfkill 18867 4 cfg80211,asus_wmi snd_hda_codec 112621 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller evdev 21544 18 ablk_helper 12572 1 aesni_intel cryptd 18553 3 ghash_clmulni_intel,aesni_intel,ablk_helper r8169 80917 0 psmouse 107442 0 pcspkr 12595 0 mii 12675 1 r8169 serio_raw 12849 0 ttm 81779 1 radeon k10temp 12588 0 snd_hwdep 17244 1 snd_hda_codec snd_pcm 88785 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 26614 1 snd_pcm snd 73436 18 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel wmi 17339 1 asus_wmi shpchp 35210 0 drm_kms_helper 80985 1 radeon soundcore 13031 2 snd,snd_hda_codec drm 263481 8 ttm,drm_kms_helper,radeon hwmon 12930 3 k10temp,radeon,asus_wmi i2c_piix4 20857 0 i2c_algo_bit 12744 1 radeon i2c_core 50152 7 drm,i2c_piix4,drm_kms_helper,i2c_algo_bit,v4l2_common,radeon,videodev thermal 17559 0 video 18043 1 asus_wmi battery 17452 0 ac 12715 0 button 12953 0 acpi_cpufreq 17218 0 processor 27777 5 acpi_cpufreq sch_fq_codel 17343 6 ext4 510292 2 crc16 12343 1 ext4 mbcache 17171 1 ext4 jbd2 86379 1 ext4 hid_generic 12393 0 usbhid 48595 0 hid 106316 2 hid_generic,usbhid sr_mod 21903 0 sd_mod 43575 6 cdrom 47479 1 sr_mod atkbd 22254 0 libps2 12739 2 atkbd,psmouse ahci 33248 5 sdhci_pci 22137 0 libahci 27215 1 ahci sdhci 39051 1 sdhci_pci led_class 12855 3 ath9k,sdhci,asus_wmi mmc_core 110515 2 sdhci,sdhci_pci ohci_pci 12808 0 ohci_hcd 43006 1 ohci_pci libata 181518 2 ahci,libahci ehci_pci 12512 0 xhci_pci 12675 0 ehci_hcd 69939 1 ehci_pci scsi_mod 147580 3 libata,sd_mod,sr_mod xhci_hcd 152471 1 xhci_pci usbcore 199382 8 uvcvideo,ohci_hcd,ohci_pci,ehci_hcd,ehci_pci,usbhid,xhci_hcd,xhci_pci usb_common 12561 1 usbcore i8042 18002 1 libps2 serio 18282 9 serio_raw,atkbd,i8042,psmouse Hi again, Ok, so asus_wmi may be causing issues here, and having serio_raw listed is weird too, try creating a /etc/modprobe.d/blacklist.conf with the following in there: blacklist asus_nb_wmi blacklist asus_wmi blacklist serio_raw Then reboot and check lsmod for those modules not being listed, and after that just use the laptop and see if the suspend/resume issue is gone. If it is gone try re-enabling either the asus modules or the serio_raw one to pinpoint the issue. Regards, Hans Hi. Well..that solution didn't work after all. Lost input twice already with those 3 modules blacklisted. I'm afraid I'm all out of ideas then. This sounds like an ACPI embedded controller bug. Have you tried updating your BIOS to the latest version ? No I didn't...but I doubt that's the case. I constantly dual-boot with windows. And in windows the problem never appears. Hmm, So one last thing which you can try is adding: "i8042.nomux=1" to your kernelcommandline and see if that helps. Regards. Hans Haven't tried your last suggestion yet Hans but I would like to ask you a question. When looking over the kernel's output messages upon resume I found these: [ 4472.923364] atkbd serio0: Unknown key released (translated set 2, code 0x7c on isa0060/serio0). [ 4472.923366] atkbd serio0: Use 'setkeycodes 7c <keycode>' to make it known. [ 4473.121833] atkbd serio0: Unknown key released (translated set 2, code 0x7c on isa0060/serio0). [ 4473.121836] atkbd serio0: Use 'setkeycodes 7c <keycode>' to make it known. [ 4473.322394] atkbd serio0: Unknown key released (translated set 2, code 0x7c on isa0060/serio0). [ 4473.322397] atkbd serio0: Use 'setkeycodes 7c <keycode>' to make it known. Can't they somehow link to the problem and what exactly might they mean. Regards, Adrian Unfortunately the problem still occurs if booting with i8042.nomux=1 :( fwiw, this isn't a libevdev bug, it looks like something in the kernel so I'm closing this bug for now. Feel free to continue the discussion here though |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 113134 [details] journalctl output When I wake up my machine from sleep it sometimes happens to lose keyboard and touchpad controls(no input). It happens frequently with lightdm (about 1 in 3 wake-ups) and not that often with gdm (1 in 10+ wake-ups). This only happens to the integrated input components, external usb mouse works fine. The bug is distro agnostic (successfully reproduced it in Ubuntu 10.04 and latest Arch) while using various versions of kernel (3.13 up to 3.18.5), mesa (10.3 - mesa-git) and xserver (3.15-3.16). I attached here the relevant output produced by journalctl (crash.log) I posted this in the radeon section but I'm not sure at all if it's a radeon issue. I'm apologise if this turns out to be unrelated to radeon.