Date: Wed, 17 Sep 2014 16:15:39 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 192316] Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior Message-ID: <bug-192316-8-UjZu5KsoZ7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192316-8@https.bugs.freebsd.org/bugzilla/> References: <bug-192316-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192316 --- Comment #3 from Jan Kokem=C3=BCller <jan.kokemueller@gmail.com> --- Created attachment 147407 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147407&action= =3Dedit 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 "re= turn (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 on= e of the cases at lines 115, 318, or 531. I wonder why they do this weird remapp= ing of C-states? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192316-8-UjZu5KsoZ7>