Bug 98171

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

Comment 2 Mark Linimon 2006-06-03 20:03:13 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-acpi

Over to maintainer(s).

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

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

Comment 5 dfilter service 2007-02-27 00:14:30 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"

Comment 6 Mark Linimon 2008-02-29 00:58:39 UTC

State Changed
From-To: open->closed

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.