https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316
--- Comment #3 from Jan Kokemüller <jan.kokemuel...@gmail.com> --- Created attachment 147407 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147407&action=edit acpidump of a Lenovo SL510 Thanks for the detailed analysis. I've had another look at how my laptop (Lenovo SL510) handles C-states. By default the OS queries the _CST method of the firmware and this results in the following C-states: dev.cpu.0.cx_supported: C1/1/1 C2/2/57 dev.cpu.1.cx_supported: C1/1/1 C2/2/57 So this means that cpu_can_deep_sleep does not get set. When I insert a "return (ENXIO);" at the start of the acpi_cpu_cx_cst function in sys/dev/acpica/acpi_cpu.c the OS falls back to FADT/P_BLK parsing and I get the following: dev.cpu.0.cx_supported: C1/1/0 C2/2/1 C3/3/57 dev.cpu.1.cx_supported: C1/1/0 C2/2/1 C3/3/57 ... which looks closer to the actual hardware to me. I've attached the acpidumps. The _CST method is in ssdt5.dsl. My laptop seems to fall into one of the cases at lines 115, 318, or 531. I wonder why they do this weird remapping of C-states? -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
