Bug 200277 - Kernel 4.17.2 does not recognise Asus K501UB laptop keyboard/trackpad
Summary: Kernel 4.17.2 does not recognise Asus K501UB laptop keyboard/trackpad
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: All Linux
: P1 low
Assignee: acpi_other
URL: https://bugzilla.redhat.com/show_bug....
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-25 18:44 UTC by Roy
Modified: 2018-07-23 03:28 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.17.2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
ACPI dump Asus K501UB (974.04 KB, text/plain)
2018-06-25 18:44 UTC, Roy
Details
GOOD dmesg for kernel 4.16.16 (66.32 KB, text/plain)
2018-06-25 18:46 UTC, Roy
Details
BAD dmesg for kernel 4.17.2 (73.97 KB, text/plain)
2018-06-25 18:47 UTC, Roy
Details
GOOD dmesg for kernel 4.17.3 (65.61 KB, text/plain)
2018-06-27 15:35 UTC, Roy
Details

Description Roy 2018-06-25 18:44:51 UTC
Created attachment 276835 [details]
ACPI dump Asus K501UB

(This bug is reported as Red Hat Bugzilla #1594572)

Description of problem:
The current kernel 4.17.2 does not recognise the internal keyboard and trackpad of the Asus K501UB laptop, rendering the machine useless on the go. Input works from an external keyboard and mouse. Machine works fine with kernel 4.16.

Version-Release number of selected component (if applicable):
Any Fedora kernel newer than (including) kernel-4.17.0-0.rc0.git4.1.fc29, - Linux v4.16-9576-g38c23685b273. This commit identifier is the result of installing various pre-release kernel RPMs, not of a proper git bisect.

How reproducible:
Type.

Steps to Reproduce:
1. Start machine
2. Type (In my case: hard drive decryption key)

Actual results:
None

Expected results:
Many

Additional information:
- Allocating an IDR fails with
[    8.886249] couldn't get idr

A likely condition for this to happen is to be called with a "start" integer smaller than 0. For I2C devices this is set to adap->nr, unless adap->nr is -1, in which case it's assigned to __i2c_first_dynamic_bus_num.
- __i2c_first_dynamic_bus_num does not have a default value and is only initialised in i2c_register_board_info(). If due to ACPI problems this function is never called, it could default to anything including a negative number, causing the allocation to fail. Does it make sense to assign a default value to __i2c_first_dynamic_bus_num regardless of whether ACPI needs fixing?
- Semi-related: I've also lost a lot of suspend modes. 4.16 reports "ACPI: (supports S0 S3 S4 S5)", 4.17 reports ACPI: (supports S0). There many warnings in the logs leading up to that.
Comment 1 Roy 2018-06-25 18:46:52 UTC
Created attachment 276837 [details]
GOOD dmesg for kernel 4.16.16
Comment 2 Roy 2018-06-25 18:47:30 UTC
Created attachment 276839 [details]
BAD dmesg for kernel 4.17.2
Comment 3 Roy 2018-06-27 15:35:16 UTC
Created attachment 276927 [details]
GOOD dmesg for kernel 4.17.3

Symptoms have vanished with kernel 4.17.3, thanks! There's still a few warnings left in the dmesg logs (attached), but those are of much lower urgency now that the system works correctly again.
Comment 4 Zhang Rui 2018-07-23 03:28:25 UTC
so I guess the bug can be closed?

Note You need to log in before you can comment on or make changes to this bug.