Created attachment 925308 [details] # dmesg > dmesg.log Description of problem: An issue similar to bug 1012674. When I use my Fn keys to adjust brightness my netbook slows down till it becomes unusable: I have to switch a console and reboot. Brightness can be adjusted via software without problems. Doesn't work: * video.use_native_backlight=1 * Option "Backlight" "intel_backlight" Version-Release number of selected component (if applicable): # uname -r 3.15.8-200.fc20.i686 Additional info: # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 9 ago 2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
Created attachment 925309 [details] # grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log
Thanks for the bug report. You say your system becomes very slow. Have you tried running top to see if something is eating a lot of CPU when this happens ? Note I'm with vacation next week, so I won't be answering any bugzilla comments then.
Well, top command reports nothing of strange. The most active processes are X (max 18%) and systemd-udevd (max 4%), but both often are less than 5%. It seems that slowness is not due to CPU overload, the cause is the poor response of input commands (like touchpad and especially keyboard). I need to restart X (eg logout-login) to get normal responsiveness.
(In reply to Massimiliano from comment #3) > Well, top command reports nothing of strange. The most active processes are > X (max 18%) and systemd-udevd (max 4%), but both often are less than 5%. It > seems that slowness is not due to CPU overload, the cause is the poor > response of input commands (like touchpad and especially keyboard). I need > to restart X (eg logout-login) to get normal responsiveness. Hmm, this sounds like it is a userspace issue rather then a kernel issue then. Peter, any idea how to debug this input becoming lagged after a brightness key has been pressed once problem ?
Can you try to run evtest first to check that the events aren't somehow delayed in the kernel? If they show up without delay on evtest, then we've at least narrowed it down to X. For the touchpad, this could be a clock issue, one that we're currently working on. I don't know why the keyboard is affected though, the evdev driver doesn't make use of timestamps, so it's all contained within the server. Do you notice the delay gets worse or does it remain constant? if the latter, what is the approximate delay in seconds? I'm trying to rule out XKB accessibility activating, easy way to check is install xkbset, then run xkbset q | grep Slow-Keys.
(In reply to Peter Hutterer from comment #5) > Can you try to run evtest first to check that the events aren't somehow > delayed in the kernel? If they show up without delay on evtest, then we've > at least narrowed it down to X. > I've never used evtest before. I've detected input devices (see attachment). But if I try: # evtest /dev/input/event5 Input driver version is 1.0.1 Input device ID: bus 0x11 vendor 0x2 product 0x7 version 0x1b1 Input device name: "SynPS/2 Synaptics TouchPad" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 272 (BTN_LEFT) Event code 273 (BTN_RIGHT) Event code 325 (BTN_TOOL_FINGER) Event code 330 (BTN_TOUCH) Event code 333 (BTN_TOOL_DOUBLETAP) Event code 334 (BTN_TOOL_TRIPLETAP) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 5023 Min 1472 Max 5888 Resolution 121 Event code 1 (ABS_Y) Value 4212 Min 1408 Max 5218 Resolution 182 Event code 24 (ABS_PRESSURE) Value 0 Min 0 Max 255 Event code 28 (ABS_TOOL_WIDTH) Value 0 Min 0 Max 15 Event code 47 (ABS_MT_SLOT) Value 0 Min 0 Max 1 Event code 53 (ABS_MT_POSITION_X) Value 0 Min 1472 Max 5888 Resolution 121 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min 1408 Max 5218 Resolution 182 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min 0 Max 65535 Properties: Property type 0 (INPUT_PROP_POINTER) Property type 3 (INPUT_PROP_SEMI_MT) Testing ... (interrupt to exit) *********************************************** This device is grabbed by another process. No events are available to evtest while the other grab is active. In most cases, this is caused by an X driver, try VT-switching and re-run evtest again. *********************************************** So I switch to a console (ctrl+alt+f2) to test touchpad after brightness tuning. Touchpad output doesn't seem to have a delay in console, but it remains slow under X. Keybord ouptput for evtest is slower in X (after brightness tuning) than in console or in normal condition under X. > For the touchpad, this could be a clock issue, one that we're currently > working on. I don't know why the keyboard is affected though, the evdev > driver doesn't make use of timestamps, so it's all contained within the > server. > > Do you notice the delay gets worse or does it remain constant? if the > latter, what is the approximate delay in seconds? I'm trying to rule out XKB > accessibility activating, easy way to check is install xkbset, then run > xkbset q | grep Slow-Keys. The delay (slowness) after tuning brightness is constant. But I notice that after a while (especially if I switch from console to X many times), then X comes back to work again. The more I press Fn-keys, the more the system becomes slow (and for a longer time). $ xkbset q | grep Slow-Keys Slow-Keys = Off
Created attachment 933024 [details] $ cat /proc/bus/input/devices
Following this: https://bbs.archlinux.org/viewtopic.php?id=178014 I've tried "acpi_osi=" (empty string) as kernel parameter. Now OSD brightness indicator appears after a bit delay (2 secs) and during this time the netbook is still sluggish. But after this interval everything works as expected. It seems a good workaround. # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=
(In reply to Massimiliano from comment #8) > Following this: https://bbs.archlinux.org/viewtopic.php?id=178014 > I've tried "acpi_osi=" (empty string) as kernel parameter. Now OSD > brightness indicator appears after a bit delay (2 secs) and during this time > the netbook is still sluggish. But after this interval everything works as > expected. It seems a good workaround. > > # cat /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686 > root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 > rhgb quiet acpi_osi= Ok, see this seems to be a kernel problem. What does "ls /sys/class/backlight" say when you boot with "acpi_osi=" ? Can you try with "acpi_backlight=vendor" (and no other special options) on the kernel commandline ?
(In reply to Hans de Goede from comment #9) > > Ok, see this seems to be a kernel problem. > > What does "ls /sys/class/backlight" say when you boot with "acpi_osi=" ? > # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 2 set 2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 > Can you try with "acpi_backlight=vendor" (and no other special options) on > the kernel commandline ? No sluggish anymore with this option: # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 1 set 22.20 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi But OSD display often doesn't appear (delay has been increased). But shouldn't we use option video.use_native_backlight=1 instead?
Thanks for the testing. Recently there has been a lot of work done to make interaction with the acpi ec controller work more smooth, including some work specifically to work around bugs on some model acer laptops: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi?id=3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi?id=558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 These commits are part of 3.17-rc3, can you please try installing this kernel build: http://koji.fedoraproject.org/koji/buildinfo?buildID=574277 Download kernel-3.17... kernel-core-... and kernel-modules-... for your architecture (if you've done a 32 bit install use the PAE versions) and then install them like this: rpm -ivh kernel*.rpm Then reboot into the new kernel without any special commandline options and see if that changes anything (e.g. fixes the slow down). If that does not fix thinhgs 100% try the same kernel with "acpi_backlight=vendor". (In reply to Massimiliano from comment #10) > But shouldn't we use option video.use_native_backlight=1 instead? That is for new laptops with a win8 ready BIOS it does not do anything on older laptops. Regards, Hans
(In reply to Hans de Goede from comment #11) > Download kernel-3.17... kernel-core-... and kernel-modules-... for your > architecture (if you've done a 32 bit install use the PAE versions) and then > install them like this: > > rpm -ivh kernel*.rpm > > Then reboot into the new kernel without any special commandline options and > see if that changes anything (e.g. fixes the slow down). If that does not > fix thinhgs 100% try the same kernel with "acpi_backlight=vendor". > No good: # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 2 set 21.42 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 Better: # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 2 set 21.46 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi I notice no difference between the two kernel (3.15 and 3.17).
Hi Massimiliano, Thanks for testing, can you try adding: "acpi_osi=Linux" the kernel command line and see if that helps ? Can you please try this by it self, as well as combined with "acpi_backlight=vendor" ? Thanks, Hans
(In reply to Hans de Goede from comment #13) > Hi Massimiliano, > > Thanks for testing, can you try adding: "acpi_osi=Linux" the kernel command > line and see if that helps ? > > Can you please try this by it self, as well as combined with > "acpi_backlight=vendor" ? > Very slow with this option: # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=Linux # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 16 set 2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 Not slow, but again OSD display often doesn't appear (tipically only at 100%): # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=Linux acpi_backlight=vendor # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 15 set 22.24 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi
Hi, Can you try to see where the keypress events for the osd are coming from when using acpi_backlight=vendor ? Do: "sudo yum install evemu", switch to a text console (ctrl + alt + f2) and then run "sudo evemu-record", select an input device and see if that is generathing keypress events for the brightness keys. Likely suspects for this are the "video bus" input device, and something with "acer" in the name. It would be also good to know where the events are coming from when not using acpi_backlight=vendor, and last, but not least, I would also like you to check if when the osd is slow, the events are also slow. Thanks, Hans
(In reply to Hans de Goede from comment #15) > Hi, > > Can you try to see where the keypress events for the osd are coming from > when using acpi_backlight=vendor ? > > Do: "sudo yum install evemu", switch to a text console (ctrl + alt + f2) and > then run "sudo evemu-record", select an input device and see if that is > generathing keypress events for the brightness keys. Likely suspects for > this are the "video bus" input device, and something with "acer" in the name. > # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor # evemu-record Available devices: /dev/input/event0: Power Button /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: AT Translated Set 2 keyboard /dev/input/event5: Video Bus /dev/input/event6: SynPS/2 Synaptics TouchPad /dev/input/event8: Webcam /dev/input/event9: HDA Intel Mic /dev/input/event10: HDA Intel Headphone Select the device event number [0-10]: I obtain response only from 4 and 5. In case of 5: ################################ # Waiting for events # ################################ E: 0.000000 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.000000 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 0.000086 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.000086 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 0.400177 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.400177 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 0.400290 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.400290 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.125801 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 2.125801 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.125860 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 2.125860 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.485866 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 2.485866 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.485927 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 2.485927 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.876339 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 2.876339 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 2.876421 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 2.876421 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- OSD appears late (tipically at 100%), but the brightness changes and the output is printed regularly. > It would be also good to know where the events are coming from when not > using acpi_backlight=vendor, > and last, but not least, I would also like you to check if when the osd is > slow, the events are also slow. > # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet # evemu-record Available devices: /dev/input/event0: Power Button /dev/input/event1: Lid Switch /dev/input/event2: Sleep Button /dev/input/event3: Power Button /dev/input/event4: AT Translated Set 2 keyboard /dev/input/event5: SynPS/2 Synaptics TouchPad /dev/input/event6: Video Bus /dev/input/event7: Webcam /dev/input/event9: HDA Intel Mic /dev/input/event10: HDA Intel Headphone Select the device event number [0-10]: I obtain response only from 4 and 6. The output is printed, but the response is slow and the system slows down globally. It seems there is a bottleneck in event dispatching. Regards Massimiliano
Hi Massimiliano, So it seems that the best we can do for your system is to add a quirk so that the kernel will automatically behave as if "acpi_backlight=vendor" is passed to the kernel. Then there still (sometimes) is the delay after pressing the brightness keys, but atleast the slowdown of the entire system goes away, right? Please let me know if you agree that this is the best way forward, then I'll write a patch for this, and give you a kernel to test. Regards, Hans
(In reply to Hans de Goede from comment #17) > Hi Massimiliano, > > So it seems that the best we can do for your system is to add a quirk so > that the kernel will automatically behave as if "acpi_backlight=vendor" is > passed to the kernel. > Yes, this is the best behavior that I've obtained till now. > Then there still (sometimes) is the delay after pressing the brightness > keys, but atleast the slowdown of the entire system goes away, right? > Yes. > Please let me know if you agree that this is the best way forward, then I'll > write a patch for this, and give you a kernel to test. > OK Thanks, Massimiliano
Hi, I've started a scratchbuild with a kernel with a quirk for your model, you can find this scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7832541 Note this is still building atm. The added quirk tell the kernel to always behave as if acpi_backlight=vendor is specified on the kernel commandline. ace on your machine. Can you please download the kernel-3.16.5-....x86_64.rpm file, and then install it with: sudo rpm -ivh kernel-3.16.5-....x86_64.rpm And boot into it without specifying any special kernel commandline parameters. After booting this kernel please do: ls /sys/class/backlight It should now only list acer-wmi, just like when booting unpatched kernels with acpi_backlight=vendor. Please let me know if this scratch build works, then I'll send the patch upstream. Thanks, Hans
Ugh, that scratchbuild has failed because the release field was too long, here is a new build I've just started: https://koji.fedoraproject.org/koji/taskinfo?taskID=7839906 Please follow the previous testing instructions using this build (once it has finished building).
(In reply to Hans de Goede from comment #19) > > Can you please download the kernel-3.16.5-....x86_64.rpm file, and then > install it with: > sudo rpm -ivh kernel-3.16.5-....x86_64.rpm > No, I can't. This bug is for i686 platform. ;-) > And boot into it without specifying any special kernel commandline > parameters. > # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.16.5-200.rhbz1123661.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet > After booting this kernel please do: > > ls /sys/class/backlight > # ls -l /sys/class/backlight totale 0 lrwxrwxrwx 1 root root 0 13 ott 22.40 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi > It should now only list acer-wmi, just like when booting unpatched kernels > with acpi_backlight=vendor. > Yes. > Please let me know if this scratch build works, then I'll send the patch > upstream. > It works. Thank you. Massimiliano
(In reply to Massimiliano from comment #21) > > Please let me know if this scratch build works, then I'll send the patch > > upstream. > > > It works. Thank you. That is good to hear, I've send the patch upstream and it should show up in one of the 3.16.x stable patches eventually. In the mean time please keep using acpi_backlight=vendor on the kernel commandline, Regards, Hans