Bug 200829
Summary: | Keyboard lost after exit s2idle on ASUS UX433FN | ||
---|---|---|---|
Product: | Power Management | Reporter: | Chris Chiu (chris.chiu) |
Component: | cpuidle | Assignee: | Rafael J. Wysocki (rjw) |
Status: | CLOSED INVALID | ||
Severity: | blocking | CC: | lenb, rjw |
Priority: | P1 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 4.18 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | dmidecode output of ux433fn |
Description
Chris Chiu
2018-08-16 10:03:47 UTC
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. |