From martin@email.aon.at  Thu May 18 19:01:14 2006
Return-Path: <martin@email.aon.at>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0D3D816A414
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 May 2006 19:01:14 +0000 (UTC)
	(envelope-from martin@email.aon.at)
Received: from email.aon.at (warsl404pip8.highway.telekom.at [195.3.96.102])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CAA0743D46
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 May 2006 19:01:11 +0000 (GMT)
	(envelope-from martin@email.aon.at)
Received: (qmail 8690 invoked from network); 18 May 2006 19:01:08 -0000
Received: from m1473p020.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([80.121.56.20])
          (envelope-sender <martin@email.aon.at>)
          by smarthub71.highway.telekom.at (qmail-ldap-1.03) with SMTP
          for <FreeBSD-gnats-submit@freebsd.org>; 18 May 2006 19:01:08 -0000
Received: from gandalf.xyzzy (localhost.xyzzy [127.0.0.1])
	by gandalf.xyzzy (8.13.6/8.13.6) with ESMTP id k4IJ17JG017871
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 May 2006 21:01:07 +0200 (CEST)
	(envelope-from martin@gandalf.xyzzy)
Received: (from martin@localhost)
	by gandalf.xyzzy (8.13.6/8.13.6/Submit) id k4IJ16Sl017869;
	Thu, 18 May 2006 21:01:06 +0200 (CEST)
	(envelope-from martin)
Message-Id: <200605181901.k4IJ16Sl017869@gandalf.xyzzy>
Date: Thu, 18 May 2006 21:01:06 +0200 (CEST)
From: Martin Birgmeier <martin@email.aon.at>
Reply-To: Martin Birgmeier <martin@email.aon.at>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         97468
>Category:       i386
>Synopsis:       [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-acpi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 18 19:10:15 GMT 2006
>Closed-Date:    Sun Jun 24 23:47:00 GMT 2007
>Last-Modified:  Sun Jun 24 23:47:00 GMT 2007
>Originator:     Martin Birgmeier
>Release:        FreeBSD 6.1-RELEASE i386
>Organization:
MBi at home
>Environment:
System: FreeBSD gandalf.xyzzy 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Tue May 16 21:10:15 CEST 2006 root@gandalf.xyzzy:/d/6s4e/OBJ/FreeBSD/RELENG_6_1_0_RELEASE/src/sys/GANDALF i386

>Description:
	Using 'shutdown -p' or 'reboot -p' on an ASUS A7V results in a hang
	after the disks have been synced.

	Using a kernel compiled with ACPI_DEBUG and the following
	/boot/loader.conf settings:

	    debug.acpi.layer="ACPI_BUTTON ACPI_POWER"
	    debug.acpi.level="ACPI_LV_FUNCTIONS"

	will give the following additional messages during startup
	(not really interesting):

	    BUTTON-0132 [18] acpi_button_attach    : ----Entry
	    BUTTON-0168 [18] acpi_button_attach    : ----Exit-        0       0

	and after reboot -p (this seems interesting):

	    POWERRES-0510 [35] acpi_pwr_wake_enable  : ----Entry
	    POWERRES-0748 [36] acpi_pwr_find_consumer: ----Entry
	    POWERRES-0756 [36] acpi_pwr_find_consumer: ----Exit- 0
	    POWERRES-0246 [36] acpi_pwr_register_cons: ----Entry
	    POWERRES-0748 [37] acpi_pwr_find_consumer: ----Entry
	    POWERRES-0756 [37] acpi_pwr_find_consumer: ----Exit- 0
	    POWERRES-0266 [36] acpi_pwr_register_cons: ----Exit- AE_OK
	    POWERRES-0748 [36] acpi_pwr_find_consumer: ----Entry
	    POWERRES-0756 [36] acpi_pwr_find_consumer: ----Exit- 0xc566cda0

	Obviously, acpi_pwr_wake_enable never returns, but I am not enough of
	an ACPI expert to gauge this output.

>How-To-Repeat:
	See description.

>Fix:
	I found the following web page:

	    http://www.ussg.iu.edu/hypermail/linux/kernel/0201.3/0138.html

	But I have no idea what I could possibly do with this information.

>Release-Note:
>Audit-Trail:

From: Cy Schubert <Cy.Schubert@komquats.com>
To: bug-followup <bug-followup@freebsd.org>
Cc:  
Subject: Re: i386/97468: [acpi] ACPI on ASUS A7V hangs on shutdown -p 
 (power off)
Date: Tue, 25 Jul 2006 08:44:18 -0700

 I have one of these. It powers off just nicely using halt -p and reboot -p. 
 It will hang or just reboot on power off when the BIOS alarm setting is set 
 in the power settings. This is not specific to just this board, I have 
 three other machines with ASUS motherboards (CUSL2, CUSL2-C, and P3B-F), 
 which behave the same way. (Please note that the CUSL2, CUSL2-C, and P3B-F 
 are Pentium III's while the A7V is an AMD Athalon). An IBM P4 system at 
 work does not exhibit this problem when the alarm setting is set in the 
 BIOS. I have another PII machine, which I cannot recall what it is as I 
 need to disassemble it to see which motherboard it has (it's not an ASUS 
 but has an Award BIOS), that exhibits the same problem when the alarm 
 setting is set in the BIOS. Turning off that setting allows FreeBSD to 
 power down the system. Unfortunately I need to power down the systems at a 
 certain time of day through cron and power them back up at another time of 
 day, but that should be in another PR. Check your BIOS settings. I bet that 
 the alarm setting is set in your BIOS.
 
 
 -- 
 Cheers,
 Cy Schubert <Cy.Schubert@komquats.com>
 FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
 
 			e**(i*pi)+1=0
 
 

From: Martin Birgmeier <martin@email.aon.at>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/97468: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off)
Date: Sun, 5 Nov 2006 17:49:28 +0100 (CET)

 O.k., this makes me unhappy enough to post a follow-up after much
 fiddling with ACPI debugging flags, and not finding a clue...
 
 Notes:
 
 - The proposal by Cy Schubert does not work, as I've never set an alarm
   in the bios. I checked it multiple times, though, just to make sure.
 
 - Setting debug.acpi.max_threads=1 at the loader prompt does not help.
 
 - I fiddled with lots of debug.acpi.layer and debug.acpi.level settings,
   output for interesting combinations follows below. The method used
   was to boot with empty flags, and then set/reset them for one second
   via sysctl. I had to do this because some ACPI stuff is continuously
   running, totally clobbering my screen.
 
 Please respond by following up to this defect entry
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=97468), the email address
 given is invalid.
 
 Regards,
 
 Martin
 
 
 ACPI_HARDWARE/ACPI_LV_VERBOSITY3:
 -- same as --
 ACPI_ALL_COMPONENTS ACPI_ALL_DRVERS/ACPI_LV_VERBOSITY3:
 =======================================================
 
 This is the continuously running stuff. Debugging output was turned on/off
 via sysctl. I located the loop and manually copied one sequence.
 
   hwregs-0359 [000c] [41] AcpiGetRegister       : ----Entry
   hwregs-0590 [000c] [42] HwRegisterRead        : ----Entry
   hwregs-0885 [000c] [42] HwLowLevelRead        : Read:       411 width 16 from        0    e400 (SystemIO)
   hwregs-0680 [000c] [42] HwRegisterRead        : ----Exit- AE_OK
   hwregs-0399 [000c] [41] AcpiGetRegister       : Read value        1 regiser 1   
   hwregs-0402 [000c] [41] AcpiGetRegister       : ----Exit- AE_OK
   hwregs-0432 [000c] [41] AcpiSetRegister       : ----Entry 00000001
   hwregs-0590 [000c] [42] HwRegisterRead        : ----Entry
   hwregs-0885 [000c] [42] HwLowLevelRead        : Read:       411 width 16 from        0    e400 (SystemIO)
   hwregs-0680 [000c] [42] HwRegisterRead        : ----Exit- AE_OK
   hwregs-0708 [000c] [42] HwRegisterWrite       : ----Entry
   hwregs-0966 [000c] [42] HwLowLevelWrite       : Wrote:       10 width 16   to        0    e400 (SystemIO)
   hwregs-0805 [000c] [42] HwRegisterWrite       : ----Exit- AE_OK
   hwregs-0559 [000c] [41] AcpiSetRegister       : Set bits:       10 actual        0 register 1
   hwregs-0560 [000c] [41] AcpiSetRegister       : ----Exit- AE_OK
 
 I'd be happy if someone could tell me why this stuff is continuously
 running, and where it comes from. Interestingly, it's all just reads
 and writes, with no higher level acpi functions in between.
 
 
 ACPI_BUTTON ACPI_HARDWARE ACPI_POWER/ACPI_LV_FUNCTIONS:
 =======================================================
 
 Here I just enabled the above setting (without the sleep 1 and disabling),
 then pressed the power button, waited until the screen stabilized, and
 copied the last 24 lines. The first few lines match the previous case,
 repeating forever until the "done", except for the missing ACPI_LV_IO
 (LowLevel) functions.
 
   hwregs-0590 [42] HwRegisterRead        : ----Entry
   hwregs-0680 [42] HwRegisterRead        : ----Exit- AE_OK
   hwregs-0402 [41] AcpiGetRegister       : ----Exit- AE_OK
   hwregs-0432 [41] AcpiSetRegister       : ----Entry 00000001
   hwregs-0590 [42] HwRegisterRead        : ----Entry
   hwregs-0680 [42] HwRegisterRead        : ----Exit- AE_OK
   hwregs-0708 [42] HwRegisterWrite       : ----Entry
   hwregs-0805 [42] HwRegisterWrite       : ----Exit- AE_OK
   hwregs-0650 [41] AcpiSetRegister       : ----Exit- AE_OK
 done
 All buffers synced.
 Uptime: 1m46s
 POWERRES-0510 [43] acpi_pwr_wake_enable  : ----Entry
 POWERRES-0748 [44] acpi_pwr_find_consumer: ----Entry
 POWERRES-0756 [44] acpi_pwr_find_consumer: ----Exit- 0
 POWERRES-0246 [44] acpi_pwr_register_cons: ----Entry
 POWERRES-0748 [45] acpi_pwr_find_consumer: ----Entry
 POWERRES-0756 [45] acpi_pwr_find_consumer: ----Exit- 0
 POWERRES-0266 [44] acpi_pwr_register_cons: ----Exit- AE_OK
 POWERRES-0748 [44] acpi_pwr_find_consumer: ----Entry
 POWERRES-0756 [44] acpi_pwr_find_consumer: ----Exit- 0xc56bd8e0
  hwsleep-0243 [42] AcpiEnterSleepStatePre: ----Entry
   hwregs-0222 [43] AcpiGetSleepTypeData  : ----Entry
   hwregs-0300 [43] AcpiGetSleepTypeData  : ----Exit- AE_OK
 
 
 ACPI_BUTTON ACPI_HARDWARE ACPI_POWER ACPI_NAMESPACE ACPI_PARSER/
 ACPI_LV_FUNCTIONS:
 ================================================================
 
 Again, I just enabled, and then pressed the power button. Now, as
 described in the intro above, something continues to rush by
 continuously, and I can barely make out a lot of namespace and
 parser functions (and I believe no others - but cannot be sure).
 So it seems that for whatever reason, the system enters some loop
 after the AcpiEnterSleepStatePrep.

From: Martin Birgmeier <martin@email.aon.at>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/97468: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off)
Date: Sun, 5 Nov 2006 20:02:23 +0100 (CET)

 One more thing: The machine can successfully be powered down via ACPI
 under both Win98 and Suse Linux 10.0.
 
 Regards,
 
 Martin
Responsible-Changed-From-To: freebsd-i386->freebsd-acpi 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sun Jan 7 11:13:35 UTC 2007 
Responsible-Changed-Why:  
ACPI issue (spotted by Astrodoy on IRC) 

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

From: Remko Lodder <remko@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/97468: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power
 off)
Date: Sun, 07 Jan 2007 12:15:49 +0100

 Remko Lodder wrote:
 > Synopsis: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off)
 > 
 > Responsible-Changed-From-To: freebsd-i386->freebsd-acpi
 > Responsible-Changed-By: remko
 > Responsible-Changed-When: Sun Jan 7 11:13:35 UTC 2007
 > Responsible-Changed-Why: 
 > ACPI issue (spotted by Astrodoy on IRC)
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=97468
 
 I ment Astrodog ofcourse :)
 
 -- 
 Kind regards,
 
       Remko Lodder               ** remko@elvandar.org
       FreeBSD                    ** remko@FreeBSD.org
 
       /* Quis custodiet ipsos custodes */

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/97468: commit references a PR
Date: Sun, 24 Jun 2007 20:36:05 +0000 (UTC)

 njl         2007-06-24 20:35:59 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/modules/i2c/controllers/alpm Makefile 
     sys/modules/i2c/controllers/viapm Makefile 
   Log:
   The viapm module build had what appear to be some debugging CFLAGS left
   around to force the IO port to a fixed address.  They were only turned
   on in the module build and were present since the original import.  This
   breaks soft power-off on the Asus A7V since it reprograms the SMBus base
   address to a different one than the BIOS expects.  A similar issue was
   found in the alpm(4) module build.
   
   PR:             kern/113986, i386/97468
   MFC after:      3 days
   Approved by:    re
   
   Revision  Changes    Path
   1.2       +0 -1      src/sys/modules/i2c/controllers/alpm/Makefile
   1.3       +0 -1      src/sys/modules/i2c/controllers/viapm/Makefile
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: njl 
State-Changed-When: Sun Jun 24 23:46:23 UTC 2007 
State-Changed-Why:  
Fix committed, thank you very much for your debugging effort. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=97468 
>Unformatted:
