From nobody@FreeBSD.org  Tue May 30 22:21:27 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B346916A7C1
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 30 May 2006 22:21:27 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7B0F343D53
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 30 May 2006 22:21:27 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k4UMLRn1020421
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 30 May 2006 22:21:27 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k4UMLRAD020420;
	Tue, 30 May 2006 22:21:27 GMT
	(envelope-from nobody)
Message-Id: <200605302221.k4UMLRAD020420@www.freebsd.org>
Date: Tue, 30 May 2006 22:21:27 GMT
From: William Anderle <William.Anderle@Alice.it>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop (probably on all 3020 / 5020 series)
X-Send-Pr-Version: www-2.3

>Number:         98171
>Category:       kern
>Synopsis:       [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop (probably on all 3020 / 5020 series)
>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:   Tue May 30 22:30:19 GMT 2006
>Closed-Date:    Fri Feb 29 01:03:30 UTC 2008
>Last-Modified:  Fri Feb 29 01:03:30 UTC 2008
>Originator:     William Anderle
>Release:        6.1-RELEASE
>Organization:
>Environment:
FreeBSD Scarface.willytp.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Mon May 22 08:46:45 PDT 2006     root@PCBSD.localhost:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
On my Acer 5024WLMi laptop, I get tons of the following ACPI errors:

kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.TZSV._TMP] (Node 0xc4e84820), AE_NO_HARDWARE_RESPONSE
ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE

These two errors happens in the same minute and every few minutes:
May 31 00:07:52 Scarface kernel: ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
May 31 00:07:52 Scarface kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.TZSV._TMP] (Node 0xc4e84820), AE_NO_HARDWARE_RESPONSE
May 31 00:08:12 Scarface kernel: ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
May 31 00:08:12 Scarface kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS0._TMP] (Node 0xc4e84a40), AE_NO_HARDWARE_RESPONSE
May 31 00:08:22 Scarface kernel: ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
May 31 00:08:22 Scarface kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS1._TMP] (Node 0xc4e84940), AE_NO_HARDWARE_RESPONSE
>How-To-Repeat:
Just install FreeBSD 6.1 i386 on a Acer 5024WLMi laptop (or more probably, on any Acer 3020 / 5020 series laptop)
>Fix:

>Release-Note:
>Audit-Trail:

From: William Anderle <William.Anderle@Alice.iT>
To: bug-followup@FreeBSD.org,  William.Anderle@Alice.it
Cc:  
Subject: Re: kern/98171: ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop (probably
 on all 3020 / 5020 series)
Date: Wed, 31 May 2006 01:57:37 +0200

 I forgot to add ACPI error 0239.
 I copy here all the boot ACPI initialization sequence with its own errors.
 
 May 30 00:37:11 Scarface kernel: acpi0: <PTLTD   RSDT> on motherboard
 May 30 00:37:11 Scarface kernel: acpi0: Overriding SCI Interrupt from 
 IRQ 9 to IRQ 21
 May 30 00:37:11 Scarface kernel: acpi0: Power Button (fixed)
 May 30 00:37:11 Scarface kernel: acpi_ec0: <Embedded Controller: GPE 
 0x3> port 0x62,0x66 on acpi0
 May 30 00:37:11 Scarface kernel: ACPI-0501: *** Error: Handler for 
 [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
 May 30 00:37:11 Scarface kernel: ACPI-1304: *** Error: Method execution 
 failed [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc4edbb80), 
 AE_NO_HARDWARE_RESPONSE
 May 30 00:37:11 Scarface kernel: ACPI-0239: *** Error: Method execution 
 failed [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc4edbb80), 
 AE_NO_HARDWARE_RESPONSE
 May 30 00:37:11 Scarface kernel: Timecounter "ACPI-fast" frequency 
 3579545 Hz quality 1000
 May 30 00:37:11 Scarface kernel: acpi_timer0: <32-bit timer at 
 3.579545MHz> port 0x8008-0x800b on acpi0
 May 30 00:37:11 Scarface kernel: cpu0: <ACPI CPU> on acpi0
 May 30 00:37:11 Scarface kernel: acpi_lid0: <Control Method Lid Switch> 
 on acpi0
 May 30 00:37:11 Scarface kernel: acpi_button0: <Sleep Button> on acpi0
 May 30 00:37:11 Scarface kernel: pcib0: <ACPI Host-PCI bridge> port 
 0xcf8-0xcff on acpi0
 May 30 00:37:11 Scarface kernel: pci0: <ACPI PCI bus> on pcib0
 May 30 00:37:11 Scarface kernel: pcib1: <ACPI PCI-PCI bridge> at device 
 2.0 on pci0
 May 30 00:37:11 Scarface kernel: pci1: <ACPI PCI bus> on pcib1
 May 30 00:37:11 Scarface kernel: pci1: <display, VGA> at device 0.0 (no 
 driver attached)
 May 30 00:37:11 Scarface kernel: pcib2: <ACPI PCI-PCI bridge> at device 
 6.0 on pci0
 May 30 00:37:11 Scarface kernel: pci9: <ACPI PCI bus> on pcib2
 May 30 00:37:11 Scarface kernel: pcib3: <ACPI PCI-PCI bridge> at device 
 7.0 on pci0
 May 30 00:37:11 Scarface kernel: pci4: <ACPI PCI bus> on pcib3
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Jun 3 19:03:13 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer(s). 

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

From: Cy Schubert <Cy.Schubert@komquats.com>
To: bug-followup <bug-followup@freebsd.org>, William.Anderle@Alice.it
Cc:  
Subject: Re: kern/98171: [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi 
 Laptop (probably on all 3020 / 5020 series)
Date: Tue, 11 Jul 2006 12:38:48 -0700

 I recently purchased one of these puppies. The bug exists and it often 
 affects battery monitoring. I suspect that since the machine came with a 
 special chipset driver for XP, that "reverse engineering" or contacting the 
 vendor might be a good place to start. I will see what I can do to help out.
 
 
 -- 
 Cheers,
 Cy Schubert <Cy.Schubert@komquats.com>
 FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
 
 			e**(i*pi)+1=0
 
 

From: Cy Schubert <Cy.Schubert@komquats.com>
To: bug-followup <bug-followup@freebsd.org>, William.Anderle@Alice.it
Cc: njl@freebsd.org
Subject: Re: kern/98171: [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi
 Laptop (probably on all 3020 / 5020 series)
Date: Sat, 15 Jul 2006 10:32:11 -0700

 I tried a couple of things. First, I enabled the EC burst mode code in 
 acpi_ec.c, via a kernel tunable, hw.acpi.ec.burst=1 in the patch below. 
 That solved the messages problem however it caused the battery status to 
 stop working completely -- prior to the patch it worked about half the 
 time. Thinking that a 10 ms polling loop may inundate the embedded 
 controller that monitors battery status and temperature in the ACER Aspire 
 notebooks, I turned the poll delay also into a kernel tunable, 
 hw.apci.ec.poll_delay. Normally the poll delay is 10 ms, however IMHO 
 polling for battery and temperature status, along with anything else the 
 embedded controller monitors, every second is probably good enough. That 
 seems to have fixed the problem. The messages are now gone and battery 
 status is reported 100% of the time.
 
 You will need to apply the following patch:
 
 --- sys/dev/acpica/acpi_ec.c.orig	Thu May 11 10:41:00 2006
 +++ sys/dev/acpica/acpi_ec.c	Sat Jul 15 09:47:27 2006
 @@ -291,6 +291,12 @@
  static int	ec_poll_timeout = EC_POLL_TIMEOUT;
  TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout);
  
 +static int	ec_poll_delay = EC_POLL_DELAY;
 +TUNABLE_INT("hw.acpi.ec.poll_delay", &ec_poll_delay);
 +
 +static int ec_burst = 0;
 +TUNABLE_INT("hw.acpi.ec.burst", &ec_burst);
 +
  ACPI_SERIAL_DECL(ec, "ACPI embedded controller");
  
  static __inline ACPI_STATUS
 @@ -875,15 +881,15 @@
       * Poll the EC status register for up to 1 ms in chunks of 10 us 
       * to detect completion of the last command.
       */
 -    for (i = 0; i < 1000 / EC_POLL_DELAY; i++) {
 +    for (i = 0; i < 1000 / ec_poll_delay; i++) {
  	EcStatus = EC_GET_CSR(sc);
  	if (EVENT_READY(Event, EcStatus)) {
  	    Status = AE_OK;
  	    break;
  	}
 -	AcpiOsStall(EC_POLL_DELAY);
 +	AcpiOsStall(ec_poll_delay);
      }
 -    period = i * EC_POLL_DELAY;
 +    period = i * ec_poll_delay;
  
      /*
       * If we still don't have a response and we're up and running, wait up
 @@ -966,10 +972,10 @@
      ACPI_SERIAL_ASSERT(ec);
      CTR1(KTR_ACPI, "ec read from %#x", Address);
  
 -#ifdef notyet
 -    /* If we can't start burst mode, continue anyway. */
 -    EcCommand(sc, EC_COMMAND_BURST_ENABLE);
 -#endif
 +    if (ec_burst != 0) {
 +	/* If we can't start burst mode, continue anyway. */
 +	EcCommand(sc, EC_COMMAND_BURST_ENABLE);
 +    }
  
      Status = EcCommand(sc, EC_COMMAND_READ);
      if (ACPI_FAILURE(Status))
 @@ -985,13 +991,11 @@
  
      *Data = EC_GET_DATA(sc);
  
 -#ifdef notyet
 -    if (sc->ec_burstactive) {
 +    if (ec_burst != 0) {
  	Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE);
  	if (ACPI_FAILURE(Status))
  	    return (Status);
      }
 -#endif
  
      return (AE_OK);
  }    
 @@ -1004,10 +1008,10 @@
      ACPI_SERIAL_ASSERT(ec);
      CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data);
  
 -#ifdef notyet
 -    /* If we can't start burst mode, continue anyway. */
 -    EcCommand(sc, EC_COMMAND_BURST_ENABLE);
 -#endif
 +    if (ec_burst != 0) {
 +	/* If we can't start burst mode, continue anyway. */
 +	EcCommand(sc, EC_COMMAND_BURST_ENABLE);
 +    }
  
      Status = EcCommand(sc, EC_COMMAND_WRITE);
      if (ACPI_FAILURE(Status))
 @@ -1029,13 +1033,11 @@
  	return (Status);
      }
  
 -#ifdef notyet
 -    if (sc->ec_burstactive) {
 +    if (ec_burst != 0) {
  	Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE);
  	if (ACPI_FAILURE(Status))
  	    return (Status);
      }
 -#endif
  
      return (AE_OK);
  }
 
 After you apply the patch, rebuild and install the new kernel. Then add the 
 following to your loader.conf file:
 
 #hw.acpi.ec.poll_timeout=100
 #hw.acpi.ec.poll_delay=10
 hw.acpi.ec.poll_delay=1000
 # hw.acpi.ec.burst=1
 
 You may have to play with these a bit to get them just right. I'm thinking 
 of making these sysctl variables too so you can adjust them on the fly, 
 however given that each time the kernel polls for a sysctl variable, CPU 
 time is used, slowing down the system ever so slightly, I'm kind of leaning 
 toward just keeping them as kernel tunables to be set at boot time only. 
 (Maybe the sysctl variables could be set when a debug kernel tunable is set 
 at boot time, allowing the user to adjust the settings more quickly without 
 rebooting, then set them in loader.conf but that should really be a matter 
 of discussion on freebsd-arch or hackers.) Anyhow, this solved the problem 
 I had on my ACER Aspire 3623NWXMi. You may want to try different 
 combinations of the above kernel tunables.
 
 As I'm a ports commmitter I need to find a src committer to commit this for 
 me.
 
 
 -- 
 Cheers,
 Cy Schubert <Cy.Schubert@komquats.com>
 FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
 
 			e**(i*pi)+1=0
 
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/98171: commit references a PR
Date: Tue, 27 Feb 2007 00:14:30 +0000 (UTC)

 njl         2007-02-27 00:14:20 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/dev/acpica       acpi_ec.c 
   Log:
   Rework EC I/O approach.  Implement burst mode, including proper handling of
   case where it asynchronously exits burst mode on its own.  Handle different
   values of hz in sleep loop.  Provide more debugging options to tune EC
   behavior.  These tunables/sysctls may be temporary and are not for user
   access if the EC is working properly.  Burst mode is now on by default for
   testing and the poll interval has been increased from 100 to 500 us and
   total timeout from 100 to 500 ms.
   
   Hopefully this should be the first step of addressing reports of timeout
   errors during battery or thermal access, especially on HP/Compaq laptops.
   It is reasonably stable and should not cause a loss of functionality or
   performance on systems that were previously working.  Testing shows an
   increase of responsiveness by ~75% on one system.
   
   PR:             kern/98171
   
   Revision  Changes    Path
   1.69      +206 -109  src/sys/dev/acpica/acpi_ec.c
 _______________________________________________
 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: linimon 
State-Changed-When: Fri Feb 29 00:58:39 UTC 2008 
State-Changed-Why:  
This was committed by njl on Tue Feb 27 2007 but never MFCed to RELENG_6. 
However, with bugmeister hat on, I'm going to go ahead and close it 
because 1) it would be a fairly large MFC, 2) there are other changes 
in RELENG_7 that happened later, which have also not been MFCed; and 
3) njl has unfortunately turned in his commit bit in the meantime. 

If anyone is having this problem, the fix is to upgrade to RELENG_7. 

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