Bug 1546464
Summary: | Update to Kernel 4.15 breaks support for backlit keyboard Dell Precision 5520/Dell XPS 9560 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kevin Cianfarini <kevincianfarini> | ||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 27 | CC: | airlied, bskeggs, darrellpf, dennyvatwork, ewk, hdegoede, ichavero, itamar, jamesmcminn, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, kevincianfarini, labbott, linville, mchehab, mjg59, rh, steved | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-11-30 23:03:33 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Kevin Cianfarini
2018-02-17 20:05:44 UTC
I guess I have a related issue on my Dell Latitude E5450 (A18 BIOS). Backlit keyboard was working properly with 4.14, after the upgrade to 4.15 at boot I get: Feb 20 21:47:46 gemlatitude5450 kernel: dell_laptop: Setting old previous keyboard state failed Feb 20 21:47:46 gemlatitude5450 kernel: leds dell::kbd_backlight: Setting an LED's brightness failed (-6) And it boots with backlit always off (was on just before the error). Trying to activate via the key combination works, but light fades out just after stopping typing, instead of respecting the 10s timeout. Running sudo smbios-keyboard-ctl -v --set-mode fixes all the issues. Where I should report the issue upstream? https://github.com/dell/libsmbios? My specific issue is caused by this patch https://src.fedoraproject.org/rpms/kernel/blob/f27/f/0001-platform-x86-dell-laptop-Filter-out-spurious-keyboar.patch which is part of 4.15.3-300.fc27.x86_64. Recompiling the kernel without it makes the backlit happy. Thanks for finding that. Hans, can you take a look at this? (In reply to Daniele Viganò from comment #2) > My specific issue is caused by this patch > https://src.fedoraproject.org/rpms/kernel/blob/f27/f/0001-platform-x86-dell- > laptop-Filter-out-spurious-keyboar.patch which is part of > 4.15.3-300.fc27.x86_64. > > Recompiling the kernel without it makes the backlit happy. I can confirm that this resolves the issue for me too. Created attachment 1399307 [details]
Backported Dell platform commits from v4.16rc2
I've tested kernel-4.16.0-0.rc2.git0.1.fc28.x86_64 and it works fine,
so what I've done is to backport the patches included into v4.16rc2 to v4.15 and recompiled kernel-core-4.15.3-300.fc27.x86_64. It works fine and no issues anymore. Attached you can find the patch.
I had to revert
From b04eb8aaab8d0eef224247075528c7545fd2a50c Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko.com>
Date: Mon, 22 Jan 2018 18:05:44 +0200
Subject: [PATCH 10/13] platform/x86: dell-laptop: Re-use
DEFINE_SHOW_ATTRIBUTE() macro
because DEFINE_SHOW_ATTRIBUTE() isn't available in v4.15
Ah, forgot to say that my patch already includes https://src.fedoraproject.org/rpms/kernel/blob/f27/f/0001-platform-x86-dell-laptop-Filter-out-spurious-keyboar.patch Hi All, Thank you for the bugreport. I'm somewhat surprised that the patch in question breaks things, because it only changes when we send a notification of the brightness changing to userspace and contains 0 other changes, it certainly does not explain these errors: Feb 20 21:47:46 gemlatitude5450 kernel: dell_laptop: Setting old previous keyboard state failed Feb 20 21:47:46 gemlatitude5450 kernel: leds dell::kbd_backlight: Setting an LED's brightness failed (-6) Likewise the backported patches don't really seem to fix anything. I've a feeling the real bug may be completely different and this is a hotboot vs coldboot thing... Can someone with a "fixed" kernel build try to cold boot the machine and/or maybe reboot from Windows if you're a multiboot user. I guess we can always move to using the backported patch-set (thank you for that), but I wonder if it will actually fix things? Regards, Hans Hi Hans, thanks for your reply. I did many reboots in the last 30 minutes doing both cold and hot boot, with and without AC. You are probably right that there's no strict correlation, at least not a direct one, with the patch (see also last point) These are the (strange) results: - kernel-4.15.3-300.fc27.x86_64 produced the "dell_laptop: Setting old previous keyboard state failed" 1/3 of the times (and the backlit was switched off) and sometime produced the error kernel: dell_smbios: No dell-smbios drivers are loaded but functionality was ok - same kernel with patches from v4.16: never got the "dell_laptop: Setting old previous keyboard state failed", but sometime I get the same error above kernel: dell_smbios: No dell-smbios drivers are loaded I also see in the journal errors like this kernel: dell-smbios A80593CE-A997-11DA-B012-B622A1EF5492: Invalid call 0/0: 7fff - kernel-4.15.3-300.fc27.x86_64 without your patch didn't tried yet because I accidentally removed it and I need to recompile it - kernel-4.14.18-300.fc27.x86_64 no issues, even if I discovered that it also include your patch https://src.fedoraproject.org/rpms/kernel/blob/27927bcc86906fdee8df7092c3391536b4f770bc/f/0001-platform-x86-dell-laptop-Filter-out-spurious-keyboar.patch ---- Could be a kind of race condition issue? Like the kernel trying to play with SMI when not ready yet? There's any specific test that I can run? I'll keep the situation monitored in the next days and report you the feedback. Hi Daniele, Thank you for testing, one thing which could cause race conditions I guess is userspace smbios access, you said before that you did smbios-keyboard-ctl, so you've the (mostly obsolete) userspace tools installed, maybe these come with some boot-time service which accesses the smbios? Otherwise this sounds like a regression introduced in 4.15. The dell-laptop code in 4.15 has the following commits which are not in 4.14: 2017-12-11 platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410 Pali Rohár 1 -0/+17 2017-11-21 platform/x86: dell-laptop: fix error return code in dell_init() weiyongjun (A) 1 -1/+3 2017-11-16 platform/x86: dell-laptop: Allocate buffer before rfkill use Mario Limonciello 1 -4/+5 2017-11-03 platform/x86: dell-smbios: Introduce dispatcher for SMM calls Mario Limonciello 1 -178/+105 This info comes from: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/platform/x86/dell-laptop.c?h=v4.15 I guess the dispatcher stuff may have introduced some bugs :| It might be best to report this upstream to: [hans@shalem linux]$ scripts/get_maintainer.pl -f drivers/platform/x86/dell-laptop.c "Pali Rohár" <pali.rohar> (maintainer:DELL LAPTOP DRIVER) Darren Hart <dvhart> (maintainer:X86 PLATFORM DRIVERS) Andy Shevchenko <andy> (maintainer:X86 PLATFORM DRIVERS) platform-driver-x86.org (open list:DELL LAPTOP DRIVER) Hi Hans, thanks for your support. I'm also in contact with Mario Limonciello from Dell and he gave me some feedback: he also explained me that with 4.15 a new way to do BIOS calls has been introduced and this can lead to a race condition when a consumer tries to use smbios before it's available. Anyway, I removed smbios-keyboard-ctl to reduce entropy/noise and I tried to find a pattern for what concern reboots: - kernel-4.15.3-300.fc27.x86_64 COLD boot: OK reboot: NOT OK - kernel-4.15.3-300.fc27.x86_64 + backport from v4.16 COLD boot: OK reboot: OK I didn't get the "dell_laptop: Setting old previous keyboard state failed" message anymore, probably due the smbios-keyboard-ctl removal. I will make more testing in the weekend. Ok, I made more than hundred reboots/cold boots in the last 24 hrs with the following kernels: 1) kernel-4.15.3-300.fc27.x86_64 (official from fedora-updates) 2) kernel-4.15.4-300.fc27.x86_64 (official from fedora-updates) 3) kernel-4.15.4-398.fc27.x86_64 (with Hans' patch removed) 4) kernel-4.15.4-399.fc27.x86_64 (with patches backported from v4.16rc2) 5) kernel-4.16.0-0.rc2.git0.1.fc28.x86_64 (from fedora 28) These are the results: - 1) 2) and 3) frequent backlit errors, I would say at every reboot and often during cold boots - 4) and 5) never had an issues so far So, conclusions: as Hans said I confirm that his patch is not the cause of backlit issues, but also that I was unable to reproduce any issue with the current v4.16 tree (as Mario Limonciello from Dell suggested in the mail exchange). If someone else wants to try the patched kernel it can be downloaded from here http://cdn.ftp.openquake.org/fedora/kernel/f27-bz1546464/ (F27, x86_64) To whom is still affected by these issues, kernel 4.16 stable is out and it solves all of my issues. I'm using 4.16 from F28 on F27 (since rc2 and now the stable one) and I never been able to reproduce any issue (I was with the latest release of 4.15 and 4.16 looks rock solid). So, I don't know if 4.16 will be available for F27 too, but in such case the issue could be closed as resolved, for me. Thanks everyone The problem still persists for me. Kernel 4.16.0-2.fc29.x86_64 (Rawhide) and an XPS 13 9360 I too am still experiencing the issue on kernel 4.16.2-300.fc28.x86_64 (Dell XPS 9560). *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are 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.17.7-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, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those. The problem has never been resolved for me. It still persists on 4.18.0-0.rc4.git0.1.fc29.x86_64 with a Dell XPS 9360 During grub the backlight is on bright on the keyboard. Immediately after the kernel boot it goes off and never reappears. At times the F10 keyboard button under gnome has toggled through three states (with the screen icon showing as for display bright/dim) but the keyboard has never lit up in any of the states. (I don't see a way to get bugzilla to change the version) echo 1 > /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/brightness echo 20s > /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/stop_timeout This causes the backlight to come on, but it turns off after the 20 second timeout. Hitting another key doesn't result in the backlight coming on again. I was eventually able to fix this after installing Windows 10 on my XPS 9560, which also exhibited the same behaviour. It seems that a firmware setting had been changed that set the keyboard backlight timeout (possibly 0 seconds?). The fix for me was using Dell's Feature Enhancement Pack (https://www.dell.com/support/home/uk/en/ukdhs1/Drivers/DriversDetails?driverId=MHVWP) to change the keyboard backlight timeout to any other value. It's possible that I am the exception here and that the bug still exists, however I would suggest others who are still experiencing the issue verify that this is not also the case for them. In my case, cat /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/start_triggers showed -keyboard -touchpad Fix was to change it... echo +keyboard > /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/start_triggers and if you wish echo +touchpad > /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/start_triggers 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. |