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): kernel-4.17.2-200.fc28.x86_64. 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 info: The asus-nb-wmi module is blacklisted because it caused more trouble than it solved for using function keys. Never got in the way of actual typing.
Created attachment 1454143 [details] Dmesg of machine booting with kernel 4.17.2-200
Created attachment 1454157 [details] Correct dmesg of machine booting with kernel 4.16.16-300
*** Bug 1594571 has been marked as a duplicate of this bug. ***
To follow up on a question asked on freenode/#fedora-devel: Removing the blacklist entry for asus-nb-wmi does not change the situation, the keyboard still is not functioning at all on the released 4.17.2 kernel.
The problem is that when it's trying to allocate an IDR and there isn't one available. Nothing in that code has changed recently as far as I see. Could you see if you can narrow down where the regression got introduced? All the pre-release 4.17 kernels we've built can be found in Koji[0]. I'd first see if it's in rc1 (kernel-4.17.0-0.rc1.git0.1.fc29). If it is, see which of the rc0 kernels it happened in. Otherwise, see which rc build introduced the problem. [0] https://koji.fedoraproject.org/koji/search?match=glob&type=build&terms=kernel-4.17*
Created attachment 1454423 [details] ACPI dump Asus K501UB
Okay, I've done a poor-mans bisect using koji kernels, and found the bug was introduced between kernel-4.17.0-0.rc0.git1.1.fc29 and kernel-4.17.0-0.rc0.git4.1.fc29. I have attached an ACPI dump as well, as I'm 99% certain that the vast increase in ACPI errors are related to my problems. We had a little back-and-forth on IRC where I dare to conclude the following: - Allocating an IDR fails if it's 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.
This all really needs to be discussed upstream with the maintainers of the code since Fedora closely tracks that. I'd start with the maintainers of the intel-lpss framework, Jarkko Nikula <jarkko.nikula.com>, Andy Shevchenko <andriy.shevchenko.com> plus the ACPI maintainer Rafael J. Wysocki <rafael.j.wysocki> along with the usual mailing lists. If you have the ability, doing a kernel bisect to identify the specific commit that broke would be very helpful as well.
Symptoms are gone with the just-released-upstream 4.17.3 kernel.