Bug 98904

Summary: kernel: Race condition when mouse and/or keyboard randomly doesn't work upon fresh boot - Thinkpad Yoga S1
Product: Wayland Reporter: Máirín Duffy <duffy>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: benjamin.tissoires, bugzilla, peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Log from when the keyboard was non functional in runlevel 3
dmesg output from when keyboard and trackpoint are working

Description Máirín Duffy 2016-11-29 18:20:19 UTC
libinput version: 1.5.1
libinput 1.5.1-1.fc25.x86_64

My Thinkpad Yoga S1 has a weird race condition on bootup affecting input drivers - maybe 3 out of every 5 boots, the system boots with no working mouse and/or keyboard. I just reboot again and it works fine, although sometimes it takes several boots to get both working. 

This happened since I got the laptop and loaded it with F23... I upgraded to F25 + Wayland today and was able to reproduce the issue.

The following are input settings for all devices on the system when it is in the state where upon boot the keyboard worked but the pointer did not:


⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                    id=4    [slave  pointer  (2)]
⎜   ↳ xwayland-touch:13                             id=7    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
  ↳ Virtual core XTEST keyboard                     id=5    [slave  keyboard (3)]
  ↳ xwayland-keyboard:13                            id=6    [slave  keyboard (3)]
     

Device 'Virtual core pointer':
        Device Enabled (119):   1
        Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000

    Device 'Virtual core XTEST pointer':
            Device Enabled (119):   1
            Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
            XTEST Device (238):     1
     
Device 'xwayland-touch:13':
        Device Enabled (119):   1
        Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (242):     0
        Device Accel Constant Deceleration (243):       1.000000
        Device Accel Adaptive Deceleration (244):       1.000000
        Device Accel Velocity Scaling (245):    10.000000

Device 'Virtual core keyboard':
            Device Enabled (119):   1
            Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
     

Device 'Virtual core XTEST keyboard':
        Device Enabled (119):   1
        Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        XTEST Device (238):     1

    Device 'xwayland-keyboard:13':
            Device Enabled (119):   1
            Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
     


I couldn't run evemu on the pointer because there wasn't a deviec for it if I understand correctly, just for the touchscreen. If I reboot the system so the mouse works again, and run xinput list, i get a pointer and relative-pointer device that wasn't there before:

RL: http://paste.fedoraproject.org/493306/14804435/

⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                    id=4    [slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                           id=6    [slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13                  id=7    [slave  pointer  (2)]
⎜   ↳ xwayland-touch:13                             id=9    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
   ↳ Virtual core XTEST keyboard                     id=5    [slave  keyboard (3)]
   ↳ xwayland-keyboard:13                            id=8    [slave  keyboard (3)]
Comment 1 Peter Hutterer 2016-12-02 03:32:14 UTC
fwiw, xinput list from within wayland doesn't provide us with much info, all you get is the xwayland emulated devices. something is going wrong here, can you attach the journalctl -b -k output here please.

I guess this means you can't get past the login screen? What happens if you boot into a tty, does it work then?
Comment 2 Peter Hutterer 2017-02-15 06:03:06 UTC
ping? is this still an issue?
Comment 3 Máirín Duffy 2017-02-15 12:34:21 UTC
Hi Peter, it is still an issue (updated f25, kernel-4.9.7-201.fc25.x86_64 <= altho this is super crash-happy, it happens on that one but I'm mostly using kernel-4.8.8-300.fc25.x86_64)

Sorry for not following up. I got stuck because when I was reproducing it the keyboard wasn't working either so I couldn't run journalctl and didn't have a second computer.

Sometimes the keyboard does work and if that's the case I can type my password into the login screen and then can't do anything.

Let me trying booting into tty and see if I can reproduce.
Comment 4 Máirín Duffy 2017-02-16 13:46:50 UTC
Booted into tty using kernel-4.8.8-300.fc25.x86_64 (put '3' on the grub kernel line) and got to the tty and keyboard did not work. So I can reproduce the issue booting into tty.
Comment 5 Peter Hutterer 2017-02-17 01:26:25 UTC
ok, I'm gonna punt you to benjamin because this looks like it's a kernel bug. A dmesg would be good from such a bootup  where it doesn't work (journalctl -k -b <negative boot number>, where the number is -1 for the last boot, etc)
Comment 6 Máirín Duffy 2017-02-21 17:27:58 UTC
Okay cool. I'm attaching the log, I found it from when this originally happened. I tried to reproduce just now by rebooting about 10 times and could not but I did find the log where it happened.
Comment 7 Máirín Duffy 2017-02-21 17:28:25 UTC
Created attachment 129801 [details]
Log from when the keyboard was non functional in runlevel 3
Comment 8 Benjamin Tissoires 2017-02-27 09:27:34 UTC
Sorry for the delay, I was on PTO enjoying time off :)

It looks from the logs that the PS/2 nodes are simply ignored, so I guess the controller just bails out.

Just to be sure, could you also attach a dmesg when both keyboard and touchpad are working?

If they are still handled by PS/2, then there will be some trial and error to do with some kernel module parameters (i8042.noloop, i8042.nomux, i8042.noselftest, i8042.reset, i8042.notimeout and maybe i8042.kbdreset) - Just dumping them here so that I don't need to refetch them later.
Comment 9 Máirín Duffy 2017-03-01 16:01:38 UTC
Created attachment 130003 [details]
dmesg output from when keyboard and trackpoint are working

Here you go Benjamin! This is the dmesg output from when the keyboard and trackpoint are working.
Comment 10 Benjamin Tissoires 2017-03-01 16:34:07 UTC
Thanks for the logs. So you are using a PS/2  keyboard, and a PS/2 mouse, so we will need to check the flags I was mentioning in my previous comment.

I think those that have the best chance of being useful are i8042.notimeout and i8042.nomux. So please append those 2 flags to the kernel boot line in grub ("i8042.notimeout=1 i8042.nomux=1"), and try to boot, and reboot, and reboot :)
If these 2 flags reliably make both the touchpad and keyboard work, we will need to check which one is the right one (so please do the same tests with only one flag).

Note: there might be an other slightly less tedious option which would consist in providing a dmesg of a failed keyboard/touchpad boot with i8042.debug=1.
  -> In that case make sure to test the keyboard before typing a password (cause the length can be detected from the number of key events, but the keys are masked). So please beware in such situation to not type the LUKS password or your password with the embedded keyboard.
Comment 11 Peter Hutterer 2017-05-23 05:42:54 UTC
Máirín, we're still waiting on data from you, see comment 10. Ttry with a newer kernel too, that's always useful ;)
Comment 12 Peter Hutterer 2017-09-06 06:01:59 UTC
ping?
Comment 13 Sebastian Birke 2017-09-06 12:05:08 UTC
Hi,

I found this thread by searching the ACPI Exception/Error message,
that i get as the first output during boot up and i actually found in the attached log by Máirín Duffy.

I am using Debian 9.1 (stretch) on a ThinkPad Yoga (Type 20C0) with the following kernel version:
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64

If i remember correctly, with the former Debian Jessie, it did not show up.

So far I did not discovered any problems.
If i can help with further details to solve that issue, please let me know.
Comment 14 Máirín Duffy 2017-09-06 12:14:54 UTC
Hi Peter,

Sorry to go AWOL; I tried newer kernels in F25 and no luck, but once I upgraded to F26 I haven't been able to reproduce the issue.

However, I have new input issues with F26 :( trackpoint / synaptics loses sync by 2 bytes it seems every 10-15 minutes, and I lose control of the buttons; discovered switching VTs fixes it, but it seems one problem traded for another. Is it useful to file a bug on that? I brought the hardware in for Lyude to look at today.
Comment 15 Peter Hutterer 2017-12-18 05:00:58 UTC
After a debugging session with Máirín last week: adding psmouse.synaptics_intertouch=0 to the kernel command line seems to help with the issue.

So I'm closing this bug for now, we know a workaround/the issue and can fix this in the kernel now.

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.