Date: Mon, 20 Feb 2017 10:25:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 217247] [acpi] r265474 makes 11.0R unusable with Atom 330 Message-ID: <bug-217247-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217247 Bug ID: 217247 Summary: [acpi] r265474 makes 11.0R unusable with Atom 330 Product: Base System Version: 11.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: stephane_freebsd@lesimple.fr After upgrading my FreeBSD-based firewall from 10.3R to 11.0R, the boot time (from power-on to the login prompt) rocketed from ~1 minute to more than 45 minutes, and even when up, the system was extremely slow. The loadavg was >= 2, with no process really taking that much CPU time, and the number of IRQ was= not too high (200-300 per sec) even if 20% of the time was spent in IRQ. To rule out any oddity with my system config, I reproduced the problem with= the bare official FreeBSD-10.3-RELEASE-amd64-memstick.img where the kernel takes 20s to boot, and FreeBSD-11.0-RELEASE-amd64-memstick.img takes more than 8 minutes, from "Booting..." to the login prompt. So, it took me several days of manual bisecting-compiling-memstick-booting,= and I finally found the culprit: base r265474 The diff is pretty straightforward, in /etc/defaults/rc.conf: -performance_cx_lowest=3D"HIGH" # Online CPU idle state +performance_cx_lowest=3D"Cmax" # Online CPU idle state -economy_cx_lowest=3D"HIGH" # Offline CPU idle state +economy_cx_lowest=3D"Cmax" # Offline CPU idle state If I override these values by putting HIGH back in /etc/rc.conf.local, the problem disappears. I was able to manually confirm that if I set dev.cpu.N.cx_lowest to C2 (or = C3), the system is horribly slow and sluggish, and back to C1 ("HIGH"), it's usa= ble again. The commit message indicates that "This may not stay through 11.0-RELEASE, = but at least having it on by default in -HEAD will expose (more) issues with br= oken hardware", so I guess my hardware is broken, even if I didn't observe such behavior previously under other OSes (namely Linux). I can imagine that any= body else booting FreeBSD 11.0 under such hardware would just give up, so it mig= ht be a good idea to detect this CPU on install and keep cx_lowest at C1? root@fw:~ # sysctl hw.machine hw.model dev.cpu.0 hw.machine: amd64 hw.model: Intel(R) Atom(TM) CPU 330 @ 1.60GHz dev.cpu.0.cx_method: C1/hlt C2/io C3/io dev.cpu.0.cx_usage_counters: 10731 0 0 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 4432us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 C2/2/1 C3/3/85 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%location: handle=3D\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU --=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-217247-8>