We recently hit a weird problem on the ASUS laptop UX433FN with latest Intel Core i7-8565U CPU on kernel 4.18. The keyboard stops functioning after exit s2idle. It stops firing interrupts after resume on any keypress. We thought it should be something wrong with i8042 driver or even atkbd driver, so we tried to skip the suspend/resume path of i8042 and input devices but no luck. Then we tried to hack the s2idle code to fail right before it goes into the idle state to find out which code really cause the keyboard broken. It comes with an interesting finding that if it aborts s2idle before cpuidle_resume() in s2idle_enter(), the keyboard is fine. If it aborts after cpuidle_resume, then the keyboard down. At least it proves that even with dpm_noirq_begin() and dpm_noirq_suspend_devices() executed, the keyboard is still alive. There should be something wrong with the cpuidle. Going deeper into intel_idle_s2idle() which is invoked by cpuidle_enter_s2idle(), we found that the keyboard interrupt will no longer function after mwait_idle_with_hints() which just simply executing intel monitor and mwait instructions. With Rafael's suggestion, we found the following can keep keyboard alive. echo 1 > /sys/devices/system/cpu/cpuX/cpuidle/state8/disable X and be any number 0 ~ 7 However, the other ASUS laptop UX533FD with the same CPU Intel Core i7-8565U only have 4(state0 ~ 3) entries under the same sysfs path. /sys/devices/system/cpu/cpuX/cpuidle/ That may explain why the same problem does not happen on this laptop? /sys/devices/system/cpu/cpuidle/current_driver of UX433FN, UX533FD both 'acpi_idle' /sys/devices/system/cpu/cpuX/cpuidle/state8/name on UX433FN is 'C10' /sys/devices/system/cpu/cpuX/cpuidle/state8/desc on UX433FN is ':MWAIT 0x60' Please let me know if there's more information required. Thanks
The intel_idle driver doesn't seem to be enabled in your kernel. Can you please enable it and see if you can reproduce the results then?
Since the acpi_idle is used on both systems, the list of available C-states depends on the information provided by the platform firmware in the ACPI tables and that generally depends on the firmware and not on the CPU model.
Thanks for the precious information. I think I get it clear. Sorry that there was a confusion I made on the comment. Let me summarize my results based on the cpuidle information. 1. When I tried on 4.17 stable kernel, it was using the intel_idle driver. So I have the keyboard lost problem because of the deepest state (8) not working correctly. 2. When I switch to kernel 4.18.0-rc8+, the cpuidle driver shows acpi_idle, and the keyboard works OK after resuming from s2idle. So there must be a commit between these 2 versions that fixed this problem though I didn't find it in intel_idle driver. Since intel_driver.c is identical on both kernel I built myself. I'll try to do bisect to find out. Thanks
Sorry for the confusion. I re-verified with the latest linux kernel with all required modules loaded on my UX433FN and UX533FD. The '/sys/devices/system/cpu/cpuidle/current_driver' of both is 'intel_idle'. '/sys/devices/system/cpu/cpuX/cpuidle/state8/name' of both is 'C10' '/sys/devices/system/cpu/cpuX/cpuidle/state8/desc' of both is ':MWAIT 0x60' The UX533FD have the keyboard still functioning after S3. The default suspend method on this machine is S3. The UX433FN have the keyboard broken after s2idle. However, as I experiment before, the keyboard stops functioning even after I do 'echo mem > /sys/power/state'. So I still don't know whey UX533FD differs with UX433FN. They're the same i7-8565U.
What's there in /sys/power/mem_sleep on the UX433FN? If that's "[s2idle] deep", please try to echo "deep" into that file to change the value to "s2idle [deep]" and then try to suspend.
It's "[s2idle] deep" in /sys/power/mem_sleep on UX433FN. If I echo deep in to the file, it does change to "s2idle [deep]". Then the keyboard works as a charm after suspend. In UX533FD, the /sys/power/mem_sleep shows "s2idle [deep]" at the first place. Maybe we need to do something for s2idle on this particular CPU?
It looks like we need a blacklist entry for the UX433FN to make it use suspend-to-RAM (ACPI S3) by default. Please attach the output of dmidecode from that machine.
Created attachment 277997 [details] dmidecode output of ux433fn
Just request another production sample of UX433FN from ASUS. It's still s2idle but keyboard works fine after resume. So it's not OS problem.