From nobody@FreeBSD.org  Wed Jun 24 17:05:42 2009
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 04EE71065672
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 24 Jun 2009 17:05:42 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id D9D268FC1F
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 24 Jun 2009 17:05:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n5OH5fb3071728
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 24 Jun 2009 17:05:41 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n5OH5fWG071727;
	Wed, 24 Jun 2009 17:05:41 GMT
	(envelope-from nobody)
Message-Id: <200906241705.n5OH5fWG071727@www.freebsd.org>
Date: Wed, 24 Jun 2009 17:05:41 GMT
From: Dan Burkland <dan@dburkland.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Dell Vostro 1310 will not shutdown (Requires user intervention)
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         136008
>Category:       i386
>Synopsis:       [acpi] Dell Vostro 1310 will not shutdown (Requires user intervention)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-acpi
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 24 17:10:02 UTC 2009
>Closed-Date:    
>Last-Modified:  Mon Jan 11 20:20:01 UTC 2010
>Originator:     Dan Burkland
>Release:        Issue occurs on 7.1, RELEASE, 7.2 RELASE & STABLE, & 8-Current (tried i386 & amd64 versions of each release)
>Organization:
>Environment:
FreeBSD bsdcurrent.localdomain 8.0-CURRENT-200906 FreeBSD 8.0-CURRENT-200906 #0: Sun Jun  7 10:31:30 UTC 2009     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
I am able to successfully install FreeBSD 7.1,7.2,& Current (both i386 & AMD64) without any problems. However when I issue a "shutdown -p now" to power off the machine it fails to power off and it requests that I press a key to reboot it. Directly proceeding the "shutdown -p now" command I receive several error messages on my console: 
"acpi_ec0: EcRead: failed waiting to get data 
ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531
ACPI Error (psparse-0633): Method parse/execution failed [\PTS] (MOde 0xffffff000253ac0), AE_NO_HARDWARE_REPONSE
acpi0: AcpiEnterSleepStatePrep failed - AE_NO_HARDWARE_RESPONSE

The operating system has halted.
Please press any key to reboot"

I have tried disabling ACPI which prevents my machine from booting. 

1) A Dmesg with boot-v can be found here: http://jperzel.net/vostro1310/current/dmesgwith-v.log

2) A Dmesg with boot-v and ACPI disabled could not be provided due to my machine not booting when ACPI was disabled.

3) Output from sysctl hw.acpi can be found here: http://jperzel.net/vostro1310/current/sysctlhwacpi.log

4) An ACPIDUMP can be found here: http://jperzel.net/vostro1310/current/dburkland-DellVostro1310.asl

I also have made both forum & and mailing (freebsd-acpi with the title "Dell Vostro 1310") posts if you would like what others have said about this problem. I will be more than happy to provide you with any other information you may need.
>How-To-Repeat:
Shutdown -p now or halt -p
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jun 24 17:43:59 UTC 2009 
Responsible-Changed-Why:  
Sounds like an ACPI problem. 

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

From: Ilya Bakulin <webmaster@kibab.com>
To: bug-followup@FreeBSD.org, dan@dburkland.com
Cc:  
Subject: Re: i386/136008: [acpi] Dell Vostro 1310 will not shutdown
 (Requires user intervention)
Date: Mon, 28 Sep 2009 20:27:18 +0400

 --Sig_/EAzJ16sc/d0hEZlOsUlyXqA
 Content-Type: multipart/mixed; boundary="MP_/CraSF8uEy=eJAif63J7.+Ca"
 
 --MP_/CraSF8uEy=eJAif63J7.+Ca
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 I have exactly the same laptop model with similar symptoms.
 It seems that EC cannot work in polled mode at all. Since FreeBSD ACPI code=
  disables GPEs on shutdown, it is not able to receive answer from EC, and r=
 eboots machine.
 
 Atached patch adds new sysctl "debug.acpi.ec.disable_polling", setting it t=
 o "1" resolves all described symptoms.
 
 --=20
 Regards,
 Ilya Bakulin
 http://kibab.com
 xmpp://kibab612@jabber.ru
 
 --MP_/CraSF8uEy=eJAif63J7.+Ca
 Content-Type: text/x-patch
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename=acpi_ec_addon.diff
 
 --- sys/dev/acpica/acpi_ec.c	2009-06-05 22:44:36.418313000 +0400
 +++ sys/dev/acpica/acpi_ec.c	2009-09-04 15:49:54.000000000 +0400
 @@ -197,6 +197,10 @@
  SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout,
      EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)");
 =20
 +static int	ec_disable_polling;
 +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, disable_polling, CTLFLAG_RW, &ec_disa=
 ble_polling, 0,
 +    "Totally disable use of polled mode (Dell EC problem workaround)");
 +
  static ACPI_STATUS
  EcLock(struct acpi_ec_softc *sc)
  {
 @@ -577,7 +581,9 @@
 =20
      /* Disable the GPE so we don't get EC events during shutdown. */
      sc =3D device_get_softc(dev);
 -    AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR);
 +    if (!ec_disable_polling) {
 +	AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR);
 +    }
      return (0);
  }
 =20
 @@ -814,7 +820,7 @@
 =20
      ACPI_SERIAL_ASSERT(ec);
      Status =3D AE_NO_HARDWARE_RESPONSE;
 -    int need_poll =3D cold || rebooting || ec_polled_mode || sc->ec_suspen=
 ding;
 +    int need_poll =3D (cold || rebooting || ec_polled_mode || sc->ec_suspe=
 nding )  &&  !ec_disable_polling;
      /*
       * The main CPU should be much faster than the EC.  So the status shou=
 ld
       * be "not ready" when we start waiting.  But if the main CPU is really
 @@ -894,7 +900,11 @@
  	    device_printf(sc->ec_dev,
  		"wait timed out (%sresponse), forcing polled mode\n",
  		Status =3D=3D AE_OK ? "" : "no ");
 -	    ec_polled_mode =3D TRUE;
 +	    if (ec_disable_polling) {
 +		device_printf(sc->ec_dev, "Polling explicitly disabled! Continue waiting=
  for generated GPEs...\n");
 +	    } else {
 +		ec_polled_mode =3D TRUE;
 +	    }
  	}
      }
      if (Status !=3D AE_OK)
 
 --MP_/CraSF8uEy=eJAif63J7.+Ca--
 
 --Sig_/EAzJ16sc/d0hEZlOsUlyXqA
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.12 (FreeBSD)
 
 iEYEARECAAYFAkrA4+sACgkQo9vlj1oadwg8YwCfT2LuqsTHf77i3ObhIpV89YJd
 k2oAniZlLrJfVQSmFVf478sMnOA98xSJ
 =kZw9
 -----END PGP SIGNATURE-----
 
 --Sig_/EAzJ16sc/d0hEZlOsUlyXqA--

From: Sevan / Venture37 <venture37@gmail.com>
To: bug-followup@FreeBSD.org, dan@dburkland.com
Cc:  
Subject: Re: i386/136008: [acpi] Dell Vostro 1310 will not shutdown (Requires
 user intervention)
Date: Mon, 11 Jan 2010 20:08:40 +0000

 This is a multi-part message in MIME format.
 --------------010201010104070900050707
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Unmangled version of the diff attached for the 8.0-RELEASE source, I've 
 been using this diff on 8.0-RELEASE AMD64 for the past few month & it 
 kind of works (issuing halt -p when running off battery works, but not 
 if I'm running from the mains, there are lots of errors when switching 
 power sources aswell)
 
 
 Sevan / Venture37
 
 --------------010201010104070900050707
 Content-Type: text/plain;
  name="acpi_ec.c.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="acpi_ec.c.txt"
 
 --- sys/dev/acpica/acpi_ec.c.orig	2009-12-16 03:21:36.283295223 +0000
 +++ sys/dev/acpica/acpi_ec.c	2009-12-16 03:38:44.410426185 +0000
 @@ -197,6 +197,10 @@
  SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout,
      EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)");
  
 +static int	ec_disable_polling;
 +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, disable_polling, CTLFLAG_RW, &ec_disable_polling, 0,
 +    "Totally disable use of polled mode (Dell EC problem workaround)");
 +
  static ACPI_STATUS
  EcLock(struct acpi_ec_softc *sc)
  {
 @@ -577,7 +581,9 @@
  
      /* Disable the GPE so we don't get EC events during shutdown. */
      sc = device_get_softc(dev);
 -    AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR);
 +    if (!ec_disable_polling){
 +    AcpiDisableGpe(sc->ec_gpehandle,sc->ec_gpebit,ACPI_NOT_ISR);
 +    }
      return (0);
  }
  
 @@ -814,7 +820,7 @@
  
      ACPI_SERIAL_ASSERT(ec);
      Status = AE_NO_HARDWARE_RESPONSE;
 -    int need_poll = cold || rebooting || ec_polled_mode || sc->ec_suspending;
 +    int need_poll = ( cold || rebooting || ec_polled_mode || sc->ec_suspending ) && !ec_disable_polling;
      /*
       * The main CPU should be much faster than the EC.  So the status should
       * be "not ready" when we start waiting.  But if the main CPU is really
 @@ -894,7 +900,11 @@
  	    device_printf(sc->ec_dev,
  		"wait timed out (%sresponse), forcing polled mode\n",
  		Status == AE_OK ? "" : "no ");
 +	if (ec_disable_polling) {
 +	    device_printf(sc->ec_dev,"Polling explicitily disabled! Continue waiting for generated GPEs...\n");
 +	} else {
  	    ec_polled_mode = TRUE;
 +		}
  	}
      }
      if (Status != AE_OK)
 
 --------------010201010104070900050707--
>Unformatted:
