Bug 1412877

Let's have the intel graphics folks look at this

Hey, I'm seeing this as well from Ubuntu, but with the same hardware (Late 2016 Razer Blade Stealth).  See also: https://www.reddit.com/r/razer/comments/5orvy5/late_2016_rbs_qhd_linux_damage_report/

I have the same issue on a Blade Stealth 2016 when I shutdown/restart and connect/disconnect power. I am running kernel 4.9.9-200.

Seeing the same thing on my Blade Stealth 2016.
It only crashes when I turn off the caps lock though not when turning it on.

(In reply to Guillaume Gauthier from comment #4)
> Seeing the same thing on my Blade Stealth 2016.
> It only crashes when I turn off the caps lock though not when turning it on.

Oh and the Tweak Tool -> Typing -> Caps Lock Key Behaviour -> change to Caps Lock is disabled did not seem to work in my case not sure why.

Same issue, same laptop
Happens with both Ubuntu 17.04 and Fedora 25, 26

Same issue, same laptop
Happens with both Ubuntu 17.04 and Fedora 25, 26

Friendly ping; this is still happening on F26 kernel 4.12.4-300.

Same issue confirmed on Fedora 25/26 with the previous and current gen Razer Blade Stealth. Workaround that got us moving below.

setxkbmap -layout us -option caps:ctrl_modifier 
gsettings set org.gnome.desktop.input-sources xkb-options "['caps:ctrl_modifier']

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I can confirm that this is an issue on Fedora 27.

Created attachment 1379358 [details]
Test program to toggle the capslock LED

Please compile this one and run it against the keyboard's device node. Note that there may be multiple event nodes that the keyboard exports, run it against all of them. See the top of the file for compilation instructions.

Short of some really strange memory corruption in the server I can only think of the caps lock LED being the culprit. I can't think of any other reason why the workaround does the job.

I ran the test against all device nodes in /dev/input/by-id and /dev/input/by-path, with no trouble. Each one output:

Toggling capslock LED on
Toggling capslock LED off
^@^@^@^@^@^@^@^@^@^@^@^@^@Q^@A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

Is that the right set of nodes to run it against, or am I missing some?

By Jove, you've cracked the case!

$ sudo ./caps-led /dev/input/event4

reliably crashes my machine!

➜  ~ ls /dev/input/by-id/                                            
usb-11121119-000JA7BFS_USB_Camera_200901010001-event-if00
usb-ELAN_Touchscreen-event-if00
usb-Razer_Razer_Blade_Stealth-event-kbd
usb-Razer_Razer_Blade_Stealth-if01-event-kbd
usb-Razer_Razer_Blade_Stealth-if02-event-mouse
usb-Razer_Razer_Blade_Stealth-if02-mouse

I can also reliably crash my machine by pointing caps-led at:

$ sudo ./caps-led /dev/input/platform-i8042-serio-0-event-kbd

that dev node is not there every boot...

➜  linux git:(patches) xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Razer Razer Blade Stealth               	id=12	[slave  pointer  (2)]
⎜   ↳ Razer Razer Blade Stealth               	id=13	[slave  pointer  (2)]
⎜   ↳ ELAN Touchscreen                        	id=14	[slave  pointer  (2)]
⎜   ↳ Synaptics TM2438-005                    	id=16	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ USB Camera: USB Camera                  	id=10	[slave  keyboard (3)]
    ↳ Razer Razer Blade Stealth               	id=11	[slave  keyboard (3)]
    ↳ AT Raw Set 2 keyboard                   	id=15	[slave  keyboard (3)]

fwiw, the X device list is not useful in this case, the X device ids are independent of the event nodes. What I'll need is the output of sudo evemu-record without any arguments, that lists the device names and their event node numbers. This means we can at least associate the devices.

And if we can rash the machine by writing the caps LED on the evdev event node, we're looking at a kernel bug.

> And if we can rash the machine by writing the caps LED on the evdev event node, we're looking at a kernel bug.

Well then we're off to the races!

➜  ~ sudo evemu-record           
Available devices:
/dev/input/event0:	Lid Switch
/dev/input/event1:	Sleep Button
/dev/input/event2:	Power Button
/dev/input/event3:	Power Button
/dev/input/event4:	AT Raw Set 2 keyboard
/dev/input/event5:	Razer Razer Blade Stealth
/dev/input/event6:	HDA Intel PCH Mic
/dev/input/event7:	HDA Intel PCH Headphone
/dev/input/event8:	Video Bus
/dev/input/event9:	ELAN Touchscreen
/dev/input/event10:	USB Camera: USB Camera
/dev/input/event11:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event12:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event13:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event14:	HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event15:	HDA Intel PCH HDMI/DP,pcm=10
/dev/input/event16:	Razer Razer Blade Stealth
/dev/input/event17:	Razer Razer Blade Stealth
/dev/input/event18:	Synaptics TM2438-005

Does anyone have any tips on how I should begin to try to debug this further? I've been trying crashdump as per [0] but it doesn't seem to work. After my screen glitches there's no recovery other than hard reboot.

[0] https://wiki.ubuntu.com/Kernel/CrashdumpRecipe?action=show&redirect=KernelTeam%2FCrashdumpRecipe

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.15.3-300.f27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

I spoke with Dmitry Torokhov (the INPUT maintainer) and he recommended trying without booting X (I think you can boot to just a command line).  I need to test that out (this is still an issue, please don't close this bug yet).

Nick: on the gdm screen, ctrl+alt+f3 to switch to a vt, log in. systemctl stop gdm.service brings down gnome. Now it's the equivalent to booting straight to the commandline.

or in grub, append: systemd.unit=multi-user.target

Thanks for the tip Peter.  In the VT, I still experience the crash using the program in comment #15.

Same exact problem with the same setup.

Kernel 4.15.7-300.fc27.x86_64

Hi,
This is still an issue on Fedora 28 release 4.16.13-300.fc28.x86_64, on the late-2017 version of the machine. 

Running the capslock-led.c script actually fixed the issue 2 of 3 tries.

Is there a proper fix released for this?

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.18.10-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 28 or Fedora 29, and are still experiencing this issue, please change the version to Fedora 28 or 29.
 
If you experience different issues, please open a new bug report for those.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.