amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl

[Alexander Motin]

The following reply was made to PR amd64/171355; it has been noted by GNATS.

From: Alexander Motin <mav at FreeBSD.org>
To: Stefano Marinelli <stefano at dragas.it>
Cc: attilio at freebsd.org, bug-followup at FreeBSD.org, 
 John Baldwin <jhb at freebsd.org>,
 re at 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 at 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