Date: Sun, 9 Sep 2012 19:50:13 GMT From: Alexander Motin <mav@FreeBSD.org> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Message-ID: <201209091950.q89JoDro082203@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin <mav@FreeBSD.org> To: Stefano Marinelli <stefano@dragas.it> Cc: attilio@freebsd.org, bug-followup@FreeBSD.org, John Baldwin <jhb@freebsd.org>, re@FreeBSD.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 22:49:10 +0300 On 09.09.2012 22:27, Stefano Marinelli wrote: >> It looks like the problem is in HPET timer operation. There are number of known and handled problems with AMD HPETs, but seems like you've found new one. Unluckily, the part of the log about HPET timer didn't fit into the message buffer. The buffer can be tuned with tunable kern.msgbufsize. Default value is 98304. You may try to double it. The specified value must be multiple of 4096. > > Ok, I rised it and I think the whole dmesg is now on the file. > The link is: http://www.dragas.org/~draga/dmesg.txt Thanks, that explains a lot. AMD started to use their proper vendor ID for HPET, but seems haven't fixed level-triggered interrupts and haven't implemented (removed?) message interrupts. All together it broke workaround in HPET driver that supposed to block HPET by default in such cases. Such patch should restore it: --- acpi_hpet.c (revision 240235) +++ acpi_hpet.c (working copy) @@ -57,6 +57,7 @@ #endif #define HPET_VENDID_AMD 0x4353 +#define HPET_VENDID_AMD2 0x1022 #define HPET_VENDID_INTEL 0x8086 #define HPET_VENDID_NVIDIA 0x10de #define HPET_VENDID_SW 0x1166 @@ -505,7 +506,7 @@ * properly, that makes it very unreliable - it freezes after any * interrupt loss. Avoid legacy IRQs for AMD. */ - if (vendor == HPET_VENDID_AMD) + if (vendor == HPET_VENDID_AMD || vendor == HPET_VENDID_AMD2) sc->allowed_irqs = 0x00000000; /* * NVidia MCP5x chipsets have number of unexplained interrupt > Also, please note there's another problem on this machine: CPU never goes to low power, keeping fans always on and keeping power consumption high. On Linux, I can see the cpu lowering its frequencies. On FreeBSD, it seems it can't detect lower than c1 statuses and other frequencies: > > [root@pcbsd-8515] ~# sysctl -a | grep cpu > cpu HAMMER > device cpufreq > kern.ccpu: 0 > kern.sched.cpusetsize: 8 > <cpu count="2" mask="3">0, 1</cpu> > <cpu count="2" mask="3">0, 1</cpu> > kern.smp.cpus: 2 > kern.smp.maxcpus: 64 > net.inet.tcp.per_cpu_timers: 0 > debug.acpi.cpu_unordered: 0 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > hw.ncpu: 2 > hw.acpi.cpu.cx_lowest: C1 > security.jail.param.cpuset.id: 0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 305us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.C001 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/0 C2/100 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 8264us > dev.acpi_perf.0.%parent: cpu0 > dev.acpi_perf.1.%parent: cpu1 I can't say about frequency control, never looked inside AMD's PowerNow; but C-states are detected as I can see. You should just enable them by adding to /etc/rc.conf lines: performance_cx_lowest="C2" economy_cx_lowest="C2" -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209091950.q89JoDro082203>