From nobody@FreeBSD.org  Tue Nov 15 09:41:55 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B7340106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 09:41:55 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id A71DA8FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 09:41:55 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pAF9ftMr085162
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 09:41:55 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pAF9ftWT085161;
	Tue, 15 Nov 2011 09:41:55 GMT
	(envelope-from nobody)
Message-Id: <201111150941.pAF9ftWT085161@red.freebsd.org>
Date: Tue, 15 Nov 2011 09:41:55 GMT
From: Oli Kron <kron24@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: 9.0-RC2's regression in power management on VIA Samuel 2
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         162578
>Category:       kern
>Synopsis:       9.0-RC2's regression in power management on VIA Samuel 2
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 15 09:50:08 UTC 2011
>Closed-Date:    Wed Dec 14 13:11:20 UTC 2011
>Last-Modified:  Wed Jan 04 16:41:28 UTC 2012
>Originator:     Oli Kron
>Release:        9.0-RC2
>Organization:
>Environment:
FreeBSD ephraim.local 9.0-RC2 FreeBSD 9.0-RC2 #1: Sun Nov 13 19:21:14 CET 2011     toor@ephraim.local:/usr/obj/usr/src/sys/LEXVIA  i386
>Description:
I have a few machines (mostly routers) with VIA Samuel 2.
FreeBSD 9.0-RC2 breaks power management on them.

8.2-RELEASE detects:

  CPU: VIA Samuel 2 (532.64-MHz 686-class CPU)
    Origin = "CentaurHauls"  Id = 0x673  Family = 6  Model = 7
    Stepping = 3
    Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX>

and sysctl dev.cpu.0 says:

  dev.cpu.0.%desc: ACPI CPU
  dev.cpu.0.%driver: cpu
  dev.cpu.0.%location: handle=\_PR_.CPU0
  dev.cpu.0.%pnpinfo: _HID=none _UID=0
  dev.cpu.0.%parent: acpi0
  dev.cpu.0.freq: 532
  dev.cpu.0.freq_levels: 532/-1 266/-1
  dev.cpu.0.cx_supported: C1/0 C2/90 C3/900
  dev.cpu.0.cx_lowest: C2
  dev.cpu.0.cx_usage: 0.45% 99.54% 0.00% last 783us

In 8.2 I can use dev.cpu.0.cx_lowest=C2 in /etc/sysctl.conf
and powerd runs fine switching between 532 and 266 MHz.

FreeBSD 9.0-RC2 detects:

  CPU: VIA Samuel 2 (532.65-MHz 686-class CPU)
    Origin = "CentaurHauls"  Id = 0x673  Family = 6  Model = 7
    Stepping = 3
    Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX>
    AMD Features=0x80000000<3DNow!>
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the only difference

and sysctl dev.cpu.0 is:

  dev.cpu.0.%desc: ACPI CPU
  dev.cpu.0.%driver: cpu
  dev.cpu.0.%location: handle=\_PR_.CPU0
  dev.cpu.0.%pnpinfo: _HID=none _UID=0
  dev.cpu.0.%parent: acpi0
  dev.cpu.0.cx_supported: C1/0
  dev.cpu.0.cx_lowest: C1
  dev.cpu.0.cx_usage: 100.00% last 208us

Of course, dev.cpu.0.cx_lowest=C2 is not available and powerd
cannot start - "powerd -v" fails:

  powerd: lookup freq: No such file or directory

>How-To-Repeat:
install 9.0-RC2 on VIA Samuel 2 and:
1. sysctl dev.cpu.0 to see available frequencies and Cx states
2. try start powerd
>Fix:


>Release-Note:
>Audit-Trail:

From: kron <kron24@gmail.com>
To: bug-followup@FreeBSD.org, kron24@gmail.com
Cc:  
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Thu, 17 Nov 2011 13:12:25 +0100

 I've noticed yet another difference between 8.2 and 9:
 
 dmesg on 8.2:
    acpi_throttle0: <ACPI CPU Throttling> on cpu0
 
 dmesg on 9:
    acpi_throttle0: <ACPI CPU Throttling> on cpu0
    acpi_throttle0: failed to attach P_CNT
    device_attach: acpi_throttle0 attach returned 6
 
 Guessing it may relate to the power management issue.
 
 Oli

From: kron <kron24@gmail.com>
To: bug-followup@FreeBSD.org, kron24@gmail.com
Cc:  
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Tue, 22 Nov 2011 09:43:41 +0100

 I bisected this down to r216674. Moreover, "AMD
 Features=0x80000000<3DNow!>", which I highlighted in the
 original bugreport, was just a red herring.
 
 I'll try to attract some attention at users@
 

From: kron <kron24@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Tue, 22 Nov 2011 09:48:08 +0100

  > I'll try to attract some attention at users@
 
 Sorry, I meant -questions@
 

From: kron <kron24@gmail.com>
To: bug-followup@FreeBSD.org, jhb@freebsd.org, jkim@freebsd.org, 
 freebsd-acpi@freebsd.org
Cc:  
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Wed, 23 Nov 2011 07:57:57 +0100

 Hello,
 
 I'm bringing this to -acpi@ as suggested by jhb@.
 
 Some time ago while testing 9.0-RC2 I noticed that power management
 got broken (powerd doesn't start, Cx states disappeared) on a specific
 class of our minirouters. I created kern/162578, bisected the issue
 down to r216674 and I contacted the author - jhb@. John was kind to do
 a further analysis. Verbose boots before and after r216674 differ this
 way:
 
 -Calibrating TSC clock ... TSC clock: 532647138 Hz
 +Calibrating TSC clock ... TSC clock: 532648183 Hz
 
 -ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 -> 0
 -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
 -acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
 +acpi_timer0: couldn't allocate resource (port 0x4008)
 
 -acpi_throttle0: P_CNT from P_BLK 0x4010
 +acpi_throttle0: failed to attach P_CNT
 +device_attach: acpi_throttle0 attach returned 6
 
 John's comment:
  > So this is the issue, and it seems what happens is that your
  > BIOS assigns the resources for this range to the pcib0 device
  > when we expect them to be assigned as a system resource (if
  > at all):
 
  > pcib0: <ACPI Host-PCI bridge> port
  > 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f
  > on acpi0
 
  > You could try hacking your ASL to not list the 0x4000-0x407f range
  > for now, but the real fix is probably to make resources attached
  > to Host-PCI bridge devices be treated as if they were system
  > resources and put into the ACPI system resource rman instead.
  > That requires a fair bit of work however.
 
 John also suggested to involve jkim@ and -acpi@.
 
 I'm going to experiment with ASL because it would be an acceptable
 solution to me and the real fix is way above my skills ATM.
 
 If anybody is interested in this I have a spare machine affected by
 this issue and I can do any test.
 
 Best regards
 Oli Kron

From: kron <kron24@gmail.com>
To: Cc: bug-followup@FreeBSD.org, jhb@freebsd.org, jkim@freebsd.org, 
 freebsd-acpi@freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Wed, 23 Nov 2011 22:09:25 +0100

 > I'm going to experiment with ASL because it would be an acceptable
 > solution to me and the real fix is way above my skills ATM.
 
 As promised, I fiddled with ASL. I did found something which
 resembled 0x4000-0x407f:
 ...
 DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "VIA601", "AWRDACPI", 
 0x00001000)
 {
      ....
      Scope (\_SB)
      {
          ...
          Device (PCI0)
          {
              ...
              Method (_CRS, 0, NotSerialized)
              {
                  ...
                  Name (BUF0, ResourceTemplate ()
                  {
                      ...
                      IO (Decode16,
                          0x4000,             // Range Minimum
                          0x4000,             // Range Maximum
                          0x01,               // Alignment
                          0x80,               // Length
                          )
                      ...
 I removed the IO block, compiled, installed the AML, rebooted
 and voila - I have my power management back even with r216674.
 
 Big thanks to jhb@ for guiding me.
 
 As always, big thanks to all the good souls who write the
 Handbook, too. It helped me with ASL and AML.
 
 As
 1. this hack is good enough for me, and
 2. the real fix John suggested is above my skills
 I think the PR can be closed.
 
 Best regards
 Oli
 
 PS: My offer to do any tests on the affected HW still holds.
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Wed Dec 14 13:10:22 UTC 2011 
State-Changed-Why:  
apparently a workaround has been committed, and submitter 
reports that PR may be closed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162578 

From: John Baldwin <jhb@freebsd.org>
To: kron <kron24@gmail.com>
Cc: bug-followup@freebsd.org,
 jkim@freebsd.org,
 freebsd-acpi@freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
Date: Tue, 3 Jan 2012 17:12:36 -0500

 Can you try an updated HEAD and see if a stock ASL works?
 
 -- 
 John Baldwin

From: kron <kron24@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Cc: freebsd-acpi@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Wed, 04 Jan 2012 16:44:51 +0100

 On 2012/01/03 23:12, John Baldwin wrote:
 > Can you try an updated HEAD and see if a stock ASL works?
 
 Just tested - the stock ASL fails as before:
 ...
 acpi0: reservation of 0, a0000 (3) failed
 acpi0: reservation of 100000, 1f6f0000 (3) failed
 acpi_timer0: couldn't allocate resource (port 0x4008)
 ...
 acpi_throttle0: <ACPI CPU Throttling> on cpu0
 acpi_throttle0: failed to attach P_CNT
 device_attach: acpi_throttle0 attach returned 6
 ...
 
 Oli
>Unformatted:
