Hello,
I am contacting the stable branch maintainers with a bug report concerning the asus-wmi kernel driver in the 4.4 kernel branch. I had initially contacted maintainers for the specific driver and received a response stating that I should contact the stable branch maintainers about the issue instead. Their opinion was that the patch in question should be reverted rather than debugged. I will append my initial report here and let you decide what to do with the bug.
Original Bug Report:
The 2019-01-26 commit to the asus-wmi.c driver code in the 4.4 kernel branch has introduced a bug with several known models of EeePC netbooks.
Description of Problem: The bug occurs during boot, where the screen (possibly backlight?) will shut off and display hotkeys are unable to bring it back on. The problem is present on all kernels since the 2019-01-26 commit. There have been several reports of the issue in the slackware forum at linuxquestions.org
Corrective actions taken so far: Appending acpi_osi=Linux will circumvent the issue and keep the screen on, but this causes several error messages in the boot log about eeepc_wmi "failing to load both WMI and and legacy ATKD devices", and warns not to use acpi_osi=Linux.
Appending acpi_backlight=vendor also prevents the screen from shutting off during boot. However, pressing the brightness hotkeys causes the system to hang.
Reversing the asus-wmi.c patch that was committed on 2019-01-26 and rebuilding the 4.4 series module also fixes the problem, and brightness hotkeys work normally. The commit in question is 0c4a25cc6f2934f3aa99a0bbfd20b71949bcad25
Model I have tested this on: ASUS EeePC 1000H (Slackware 14.2, kernels 4.4.201, 4.4.202) Additional models reporting this issue: ASUS Eee PC 1005HAB, ASUS Eee PC 1225b, ASUS Eee PC 1025c (Slackware 14.2, various kernels from 4.4.172 and higher)
Additional Notes: This problem seems to have been corrected in the 4.19 kernel branch, as reported by several users in the slackware forum. I attempted to test some of the fixes from the 4.19 code as patches to the 4.4 code but had no success. There have been multiple changes in that branch and I am unsure what exactly has corrected the bug in that version.
If there is any additional information that I can provide, please let me know.
Regards,
Bob Funk
Hi,
On Fri, Nov 22, 2019 at 08:33:46PM -0600, Bob Funk wrote:
Hello,
I am contacting the stable branch maintainers with a bug report concerning the asus-wmi kernel driver in the 4.4 kernel branch. I had initially contacted maintainers for the specific driver and received a response stating that I should contact the stable branch maintainers about the issue instead. Their opinion was that the patch in question should be reverted rather than debugged. I will append my initial report here and let you decide what to do with the bug.
Original Bug Report:
The 2019-01-26 commit to the asus-wmi.c driver code in the 4.4 kernel branch has introduced a bug with several known models of EeePC netbooks.
Description of Problem: The bug occurs during boot, where the screen (possibly backlight?) will shut off and display hotkeys are unable to bring it back on. The problem is present on all kernels since the 2019-01-26 commit. There have been several reports of the issue in the slackware forum at linuxquestions.org
Corrective actions taken so far: Appending acpi_osi=Linux will circumvent the issue and keep the screen on, but this causes several error messages in the boot log about eeepc_wmi "failing to load both WMI and and legacy ATKD devices", and warns not to use acpi_osi=Linux.
Appending acpi_backlight=vendor also prevents the screen from shutting off during boot. However, pressing the brightness hotkeys causes the system to hang.
Reversing the asus-wmi.c patch that was committed on 2019-01-26 and rebuilding the 4.4 series module also fixes the problem, and brightness hotkeys work normally. The commit in question is 0c4a25cc6f2934f3aa99a0bbfd20b71949bcad25
Model I have tested this on: ASUS EeePC 1000H (Slackware 14.2, kernels 4.4.201, 4.4.202) Additional models reporting this issue: ASUS Eee PC 1005HAB, ASUS Eee PC 1225b, ASUS Eee PC 1025c (Slackware 14.2, various kernels from 4.4.172 and higher)
Additional Notes: This problem seems to have been corrected in the 4.19 kernel branch, as reported by several users in the slackware forum. I attempted to test some of the fixes from the 4.19 code as patches to the 4.4 code but had no success. There have been multiple changes in that branch and I am unsure what exactly has corrected the bug in that version.
If there is any additional information that I can provide, please let me know.
I suspect that this is caused by missing commit 401fee81, which fixes 78f3ac76d9e5, was backported to 4.19 but not to 4.4. However you will have to backport it by hand as it doesn't apply due to context differences, but it trivial to do.
I am also running updated kernels on a 1025C and do not experience such issues (5.4-rc8 now, but I used to run 4.4 till 4.4.79, which didn't contain the backport of 78f3ac76d9e5).
Regards, Willy
On Sat, Nov 23, 2019 at 07:14:46AM +0100, Willy Tarreau wrote:
I suspect that this is caused by missing commit 401fee81, which fixes 78f3ac76d9e5, was backported to 4.19 but not to 4.4. However you will have to backport it by hand as it doesn't apply due to context differences, but it trivial to do.
Please try the attached patch. I haven't even tried to compile it but I think it's OK.
Willy
I compiled kernel with the patch you attached and it does indeed correct the problem as well. Perhaps backporting this patch to the 4.4 kernel would be a better alternative than reverting as I had originally suggested.
Regards, Bob Funk
On 11/23/19 12:20 AM, Willy Tarreau wrote:
On Sat, Nov 23, 2019 at 07:14:46AM +0100, Willy Tarreau wrote:
I suspect that this is caused by missing commit 401fee81, which fixes 78f3ac76d9e5, was backported to 4.19 but not to 4.4. However you will have to backport it by hand as it doesn't apply due to context differences, but it trivial to do.
Please try the attached patch. I haven't even tried to compile it but I think it's OK.
Willy
On Fri, Nov 22, 2019 at 08:33:46PM -0600, Bob Funk wrote:
Hello,
I am contacting the stable branch maintainers with a bug report concerning the asus-wmi kernel driver in the 4.4 kernel branch. I had initially contacted maintainers for the specific driver and received a response stating that I should contact the stable branch maintainers about the issue instead. Their opinion was that the patch in question should be reverted rather than debugged. I will append my initial report here and let you decide what to do with the bug.
Any reason you can not just use 5.3 or newer for this hardware? Why are you stuck on 4.4?
thanks,
greg k-h
Hi Greg, I have no personal issues against upgrading to a newer kernel myself. The reason I am working with the 4.4 kernel is that it is the supported kernel from my distro's stable release (slackware). Unfortunately slackware's stable release is several years old and consequently based on the older 4.4 LTS kernel branch.
The result of the distro packaging this older kernel is multiple users reporting this bug to the slackware community so I came to the kernel maintainers to see if this can be fixed upstream. I could also advocate for the slackware maintainer to apply the patch to his releases if you think that's a better route to take.
For the record, the patch that Willy offered does fix the issue on my affected system. That might be a better choice than my request to revert as per the original email.
Please let me know what you decide.
Thanks,
Bob Funk
On 11/23/19 3:27 AM, Greg KH wrote:
On Fri, Nov 22, 2019 at 08:33:46PM -0600, Bob Funk wrote:
Hello,
I am contacting the stable branch maintainers with a bug report concerning the asus-wmi kernel driver in the 4.4 kernel branch. I had initially contacted maintainers for the specific driver and received a response stating that I should contact the stable branch maintainers about the issue instead. Their opinion was that the patch in question should be reverted rather than debugged. I will append my initial report here and let you decide what to do with the bug.
Any reason you can not just use 5.3 or newer for this hardware? Why are you stuck on 4.4?
thanks,
greg k-h
On Sat, Nov 23, 2019 at 01:08:03PM -0600, Bob Funk wrote:
For the record, the patch that Willy offered does fix the issue on my affected system. That might be a better choice than my request to revert as per the original email.
Greg, FWIW I did nothing more than a regular backport so that you can take it as-is. I think you dropped it from 4.4 because it did not apply well and was not worth the hassle, but given that it fixes a regression caused by another backport I think it makes sense to take it, at least so that some users do not stop updating. The fix was only merged into 4.19, not 4.4/4.9/4.14.
The backports for 4.9 and 4.14 are easy to do, if you're willing to take the patches I can do them as well, just let me know.
Cheers, Willy
On Sat, Nov 23, 2019 at 08:22:44PM +0100, Willy Tarreau wrote:
On Sat, Nov 23, 2019 at 01:08:03PM -0600, Bob Funk wrote:
For the record, the patch that Willy offered does fix the issue on my affected system. That might be a better choice than my request to revert as per the original email.
Greg, FWIW I did nothing more than a regular backport so that you can take it as-is. I think you dropped it from 4.4 because it did not apply well and was not worth the hassle, but given that it fixes a regression caused by another backport I think it makes sense to take it, at least so that some users do not stop updating. The fix was only merged into 4.19, not 4.4/4.9/4.14.
The backports for 4.9 and 4.14 are easy to do, if you're willing to take the patches I can do them as well, just let me know.
Let's try something like this:
For 4.14 and 4.9 I'll also grab db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") which makes 401fee819 apply cleanly.
For 4.4, I'll grab this long list:
92a505e8055f ("platform/x86: asus-wmi: add SERIO_I8042 dependency") db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") 71f38c11cdb8 ("platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB") 999d4376c628 ("platform/x86: asus-wmi: fix asus ux303ub brightness issue") a961a285b479 ("asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF") a977e59c0c67 ("asus-wmi: Create quirk for airplane_mode LED") 6b7ff2af5286 ("asus-wmi: Add quirk_no_rfkill for the Asus Z550MA") 02db9ff7af18 ("asus-wmi: Add quirk_no_rfkill for the Asus U303LB") 2d735244b798 ("asus-wmi: Add quirk_no_rfkill for the Asus N552VW") b5643539b825 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A") 7c1c184bb571 ("platform/x86: asus-wmi: try to set als by default") aca234f63788 ("asus-wmi: provide access to ALS control")
Which looks scary, but it's all quirks for laptops folks are actually using with this kernel. Then 401fee819 also applies cleanly on 4.4.
On Mon, Nov 25, 2019 at 08:30:48AM -0500, Sasha Levin wrote:
On Sat, Nov 23, 2019 at 08:22:44PM +0100, Willy Tarreau wrote:
On Sat, Nov 23, 2019 at 01:08:03PM -0600, Bob Funk wrote:
For the record, the patch that Willy offered does fix the issue on my affected system. That might be a better choice than my request to revert as per the original email.
Greg, FWIW I did nothing more than a regular backport so that you can take it as-is. I think you dropped it from 4.4 because it did not apply well and was not worth the hassle, but given that it fixes a regression caused by another backport I think it makes sense to take it, at least so that some users do not stop updating. The fix was only merged into 4.19, not 4.4/4.9/4.14.
The backports for 4.9 and 4.14 are easy to do, if you're willing to take the patches I can do them as well, just let me know.
Let's try something like this:
For 4.14 and 4.9 I'll also grab db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") which makes 401fee819 apply cleanly.
For 4.4, I'll grab this long list:
92a505e8055f ("platform/x86: asus-wmi: add SERIO_I8042 dependency") db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") 71f38c11cdb8 ("platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB") 999d4376c628 ("platform/x86: asus-wmi: fix asus ux303ub brightness issue") a961a285b479 ("asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF") a977e59c0c67 ("asus-wmi: Create quirk for airplane_mode LED") 6b7ff2af5286 ("asus-wmi: Add quirk_no_rfkill for the Asus Z550MA") 02db9ff7af18 ("asus-wmi: Add quirk_no_rfkill for the Asus U303LB") 2d735244b798 ("asus-wmi: Add quirk_no_rfkill for the Asus N552VW") b5643539b825 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A") 7c1c184bb571 ("platform/x86: asus-wmi: try to set als by default") aca234f63788 ("asus-wmi: provide access to ALS control")
Which looks scary, but it's all quirks for laptops folks are actually using with this kernel. Then 401fee819 also applies cleanly on 4.4.
Ah the joy of dealing with stable branches :-) I agree that all of them are sufficiently small and isolated to be easy to deal with, and if they can avoid bug reports that's always a bonus.
Willy
I tested out the patch that was announced today for the 4.4.204-stable review and all is working well here. Thanks for addressing this.
Regards,
Bob Funk
On 11/25/19 7:30 AM, Sasha Levin wrote:
On Sat, Nov 23, 2019 at 08:22:44PM +0100, Willy Tarreau wrote:
On Sat, Nov 23, 2019 at 01:08:03PM -0600, Bob Funk wrote:
For the record, the patch that Willy offered does fix the issue on my affected system. That might be a better choice than my request to revert as per the original email.
Greg, FWIW I did nothing more than a regular backport so that you can take it as-is. I think you dropped it from 4.4 because it did not apply well and was not worth the hassle, but given that it fixes a regression caused by another backport I think it makes sense to take it, at least so that some users do not stop updating. The fix was only merged into 4.19, not 4.4/4.9/4.14.
The backports for 4.9 and 4.14 are easy to do, if you're willing to take the patches I can do them as well, just let me know.
Let's try something like this:
For 4.14 and 4.9 I'll also grab db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") which makes 401fee819 apply cleanly.
For 4.4, I'll grab this long list:
92a505e8055f ("platform/x86: asus-wmi: add SERIO_I8042 dependency") db2582afa744 ("platform/x86: asus-nb-wmi: Support ALS on the Zenbook UX430UQ") 71f38c11cdb8 ("platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB") 999d4376c628 ("platform/x86: asus-wmi: fix asus ux303ub brightness issue") a961a285b479 ("asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF") a977e59c0c67 ("asus-wmi: Create quirk for airplane_mode LED") 6b7ff2af5286 ("asus-wmi: Add quirk_no_rfkill for the Asus Z550MA") 02db9ff7af18 ("asus-wmi: Add quirk_no_rfkill for the Asus U303LB") 2d735244b798 ("asus-wmi: Add quirk_no_rfkill for the Asus N552VW") b5643539b825 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A") 7c1c184bb571 ("platform/x86: asus-wmi: try to set als by default") aca234f63788 ("asus-wmi: provide access to ALS control")
Which looks scary, but it's all quirks for laptops folks are actually using with this kernel. Then 401fee819 also applies cleanly on 4.4.
linux-stable-mirror@lists.linaro.org
-
Bob Funk -
Greg KH -
Sasha Levin -
Willy Tarreau