From owner-svn-src-vendor@FreeBSD.ORG Wed Dec 8 19:33:19 2010 Return-Path: Delivered-To: svn-src-vendor@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E09A106564A; Wed, 8 Dec 2010 19:33:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB998FC08; Wed, 8 Dec 2010 19:33:19 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id oB8JXJdC012635; Wed, 8 Dec 2010 19:33:19 GMT (envelope-from dougb@svn.freebsd.org) Received: (from dougb@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id oB8JXJLZ012628; Wed, 8 Dec 2010 19:33:19 GMT (envelope-from dougb@svn.freebsd.org) Message-Id: <201012081933.oB8JXJLZ012628@svn.freebsd.org> From: Doug Barton Date: Wed, 8 Dec 2010 19:33:19 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-vendor@freebsd.org X-SVN-Group: vendor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r216302 - in vendor/bind9/dist-9.4: . bin/named doc/draft lib/dns lib/dns/include/dns lib/isc X-BeenThere: svn-src-vendor@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the vendor work area tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 19:33:19 -0000 Author: dougb Date: Wed Dec 8 19:33:18 2010 New Revision: 216302 URL: http://svn.freebsd.org/changeset/base/216302 Log: Vendor import of BIND 9.4-ESV-R4 Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html (contents, props changed) vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf (contents, props changed) vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt (contents, props changed) vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt (contents, props changed) vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt (contents, props changed) vendor/bind9/dist-9.4/release-notes.css (contents, props changed) Deleted: vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-10.txt vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt Modified: vendor/bind9/dist-9.4/CHANGES vendor/bind9/dist-9.4/bin/named/query.c vendor/bind9/dist-9.4/lib/dns/api vendor/bind9/dist-9.4/lib/dns/include/dns/db.h vendor/bind9/dist-9.4/lib/dns/rbtdb.c vendor/bind9/dist-9.4/lib/dns/validator.c vendor/bind9/dist-9.4/lib/isc/api vendor/bind9/dist-9.4/lib/isc/print.c vendor/bind9/dist-9.4/version Modified: vendor/bind9/dist-9.4/CHANGES ============================================================================== --- vendor/bind9/dist-9.4/CHANGES Wed Dec 8 17:34:07 2010 (r216301) +++ vendor/bind9/dist-9.4/CHANGES Wed Dec 8 19:33:18 2010 (r216302) @@ -1,3 +1,30 @@ + --- 9.4-ESV-R4 released --- + +2970. [security] Adding a NO DATA negative cache entry failed to clear + any matching RRSIG records. A subsequent lookup of + of NO DATA cache entry could trigger a INSIST when the + unexpected RRSIG was also returned with the NO DATA + cache entry. + + CVE-2010-3613, VU#706148. [RT #22288] + +2968. [security] Named could fail to prove a data set was insecure + before marking it as insecure. One set of conditions + that can trigger this occurs naturally when rolling + DNSKEY algorithms. + + CVE-2010-3614, VU#837744. [RT #22309] + +2966. [bug] isc_print_vsnprintf() failed to check if there was + space available in the buffer when adding a left + justified character with a non zero width, + (e.g. "%-1c"). [RT #22270] + +2962. [port] win32: add more dependancies to BINDBuild.dsw. + [RT #22062] + +2786. [bug] Additional could be promoted to answer. [RT #20663] + --- 9.4-ESV-R3 released --- 2925. [bug] Named failed to accept uncachable negative responses Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html Wed Dec 8 19:33:18 2010 (r216302) @@ -0,0 +1,123 @@ + + + + + + +
+ +

Introduction

+ +

+ BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV. +

+

+ This document summarizes changes from BIND 9.4-ESV-R3 to BIND 9.4-ESV-R4. + Please see the CHANGES file in the source code release for a + complete list of all changes. +

+
+ +

Download

+ +

+ The latest release of BIND 9 software can always be found + on our web site at + http://www.isc.org/software/bind. + There you will find additional information about each release, + source code, and some pre-compiled versions for certain operating + systems. +

+
+ +

Support

+ +

Product support information is available on + http://www.isc.org/services/support + for paid support options. Free support is provided by our user + community via a mailing list. Information on all public email + lists is available at + https://lists.isc.org/mailman/listinfo. +

+
+ +

New Features

+ +

9.4-ESV-R4

+ +

None.

+
+
+ +

Feature Changes

+ +

9.4-ESV-R4

+ +

None.

+
+
+ +

Security Fixes

+ +

9.4-ESV-R4

+ +
  • + Adding a NO DATA signed negative response to cache failed to clear + any matching RRSIG records already in cache. A subsequent lookup + of the cached NO DATA entry could crash named (INSIST) when the + unexpected RRSIG was also returned with the NO DATA cache entry. + [RT #22288] [CVE-2010-3613] [VU#706148] +
  • + BIND, acting as a DNSSEC validator, was determining if the NS RRset + is insecure based on a value that could mean either that the RRset + is actually insecure or that there wasn't a matching key for the RRSIG + in the DNSKEY RRset when resuming from validating the DNSKEY RRset. + This can happen when in the middle of a DNSKEY algorithm rollover, + when two different algorithms were used to sign a zone but only the + new set of keys are in the zone DNSKEY RRset. + [RT #22309] [CVE-2010-3614] [VU#837744] +
+
+
+ +

Bug Fixes

+ +

9.4-ESV-R4

+ +
  • + isc_print_vsnprintf() failed to check if there was + space available in the buffer when adding a left + justified character with a non zero width, + (e.g. "%-1c"). + [RT #22270] +
  • + win32: add more dependencies to BINDBuild.dsw. + [RT #22062] +
+
+
+ +

Thank You

+ +

+ Thank you to everyone who assisted us in making this release possible. + If you would like to contribute to ISC to assist us in continuing to make + quality open source software, please visit our donations page at + http://www.isc.org/supportisc. +

+
+
Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf ============================================================================== Binary file. No diff available. Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt Wed Dec 8 19:33:18 2010 (r216302) @@ -0,0 +1,70 @@ + __________________________________________________________________ + +Introduction + + BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV. + + This document summarizes changes from BIND 9.4-ESV-R3 to BIND + 9.4-ESV-R4. Please see the CHANGES file in the source code release for + a complete list of all changes. + +Download + + The latest release of BIND 9 software can always be found on our web + site at http://www.isc.org/software/bind. There you will find + additional information about each release, source code, and some + pre-compiled versions for certain operating systems. + +Support + + Product support information is available on + http://www.isc.org/services/support for paid support options. Free + support is provided by our user community via a mailing list. + Information on all public email lists is available at + https://lists.isc.org/mailman/listinfo. + +New Features + +9.4-ESV-R4 + + None. + +Feature Changes + +9.4-ESV-R4 + + None. + +Security Fixes + +9.4-ESV-R4 + + * Adding a NO DATA signed negative response to cache failed to clear + any matching RRSIG records already in cache. A subsequent lookup of + the cached NO DATA entry could crash named (INSIST) when the + unexpected RRSIG was also returned with the NO DATA cache entry. + [RT #22288] [CVE-2010-3613] [VU#706148] + * BIND, acting as a DNSSEC validator, was determining if the NS RRset + is insecure based on a value that could mean either that the RRset + is actually insecure or that there wasn't a matching key for the + RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY + RRset. This can happen when in the middle of a DNSKEY algorithm + rollover, when two different algorithms were used to sign a zone + but only the new set of keys are in the zone DNSKEY RRset. [RT + #22309] [CVE-2010-3614] [VU#837744] + +Bug Fixes + +9.4-ESV-R4 + + * isc_print_vsnprintf() failed to check if there was space available + in the buffer when adding a left justified character with a non + zero width, (e.g. "%-1c"). [RT #22270] + * win32: add more dependencies to BINDBuild.dsw. [RT #22062] + +Thank You + + Thank you to everyone who assisted us in making this release possible. + If you would like to contribute to ISC to assist us in continuing to + make quality open source software, please visit our donations page at + http://www.isc.org/supportisc. Modified: vendor/bind9/dist-9.4/bin/named/query.c ============================================================================== --- vendor/bind9/dist-9.4/bin/named/query.c Wed Dec 8 17:34:07 2010 (r216301) +++ vendor/bind9/dist-9.4/bin/named/query.c Wed Dec 8 19:33:18 2010 (r216302) @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.257.18.55 2010/07/03 23:45:26 tbox Exp $ */ +/* $Id: query.c,v 1.257.18.56 2010/11/17 10:21:01 marka Exp $ */ /*! \file */ @@ -1129,7 +1129,8 @@ query_addadditional(void *arg, dns_name_ goto cleanup; } result = dns_db_find(db, name, version, type, - client->query.dboptions | DNS_DBFIND_GLUEOK, + client->query.dboptions | + DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK, client->now, &node, fname, rdataset, sigrdataset); if (result == DNS_R_GLUE && @@ -1614,7 +1615,8 @@ query_addadditional2(void *arg, dns_name goto try_glue; result = dns_db_find(db, name, version, type, - client->query.dboptions | DNS_DBFIND_GLUEOK, + client->query.dboptions | + DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK, client->now, &node, fname, NULL, NULL); if (result == ISC_R_SUCCESS) goto found; Added: vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt Wed Dec 8 19:33:18 2010 (r216302) @@ -0,0 +1,1792 @@ + + + +BEHAVE WG M. Bagnulo +Internet-Draft UC3M +Intended status: Standards Track A. Sullivan +Expires: April 4, 2011 Shinkuro + P. Matthews + Alcatel-Lucent + I. van Beijnum + IMDEA Networks + October 1, 2010 + + +DNS64: DNS extensions for Network Address Translation from IPv6 Clients + to IPv4 Servers + draft-ietf-behave-dns64-11 + +Abstract + + DNS64 is a mechanism for synthesizing AAAA records from A records. + DNS64 is used with an IPv6/IPv4 translator to enable client-server + communication between an IPv6-only client and an IPv4-only server, + without requiring any changes to either the IPv6 or the IPv4 node, + for the class of applications that work through NATs. This document + specifies DNS64, and provides suggestions on how it should be + deployed in conjunction with IPv6/IPv4 translators. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on April 4, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + + + +Bagnulo, et al. Expires April 4, 2011 [Page 1] + +Internet-Draft DNS64 October 2010 + + + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 2] + +Internet-Draft DNS64 October 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 11 + 5.1. Resolving AAAA queries and the answer section . . . . . . 11 + 5.1.1. The answer when there is AAAA data available . . . . . 12 + 5.1.2. The answer when there is an error . . . . . . . . . . 12 + 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 + 5.1.4. Special exclusion set for AAAA records . . . . . . . . 13 + 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 13 + 5.1.6. Data for the answer when performing synthesis . . . . 13 + 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 14 + 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 + 5.2. Generation of the IPv6 representations of IPv4 + addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Handling other Resource Records and the Additional + Section . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 16 + 5.3.2. Handling the additional section . . . . . . . . . . . 17 + 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17 + 5.4. Assembling a synthesized response to a AAAA query . . . . 18 + 5.5. DNSSEC processing: DNS64 in validating resolver mode . . . 18 + 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19 + 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 20 + 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 20 + 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 20 + 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 21 + 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 21 + 7. Deployment scenarios and examples . . . . . . . . . . . . . . 22 + 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 + 7.2. An example of an-IPv6-network-to-IPv4-Internet setup + with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24 + 7.3. Example of IPv6-Internet-to-an-IPv4-network setup + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 + Appendix A. Motivations and Implications of synthesizing AAAA + Resource Records when real AAAA Resource Records + + + +Bagnulo, et al. Expires April 4, 2011 [Page 3] + +Internet-Draft DNS64 October 2010 + + + exist . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 4] + +Internet-Draft DNS64 October 2010 + + +1. Introduction + + This document specifies DNS64, a mechanism that is part of the + toolbox for IPv6-IPv4 transition and co-existence. DNS64, used + together with an IPv6/IPv4 translator such as stateful NAT64 + [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to + initiate communications by name to an IPv4-only server. + + DNS64 is a mechanism for synthesizing AAAA resource records (RRs) + from A RRs. A synthetic AAAA RR created by the DNS64 from an + original A RR contains the same owner name of the original A RR but + it contains an IPv6 address instead of an IPv4 address. The IPv6 + address is an IPv6 representation of the IPv4 address contained in + the original A RR. The IPv6 representation of the IPv4 address is + algorithmically generated from the IPv4 address returned in the A RR + and a set of parameters configured in the DNS64 (typically, an IPv6 + prefix used by IPv6 representations of IPv4 addresses and optionally + other parameters). + + Together with an IPv6/IPv4 translator, these two mechanisms allow an + IPv6-only client to initiate communications to an IPv4-only server + using the FQDN of the server. + + These mechanisms are expected to play a critical role in the IPv4- + IPv6 transition and co-existence. Due to IPv4 address depletion, it + is likely that in the future, many IPv6-only clients will want to + connect to IPv4-only servers. In the typical case, the approach only + requires the deployment of IPv6/IPv4 translators that connect an + IPv6-only network to an IPv4-only network, along with the deployment + of one or more DNS64-enabled name servers. However, some features + require performing the DNS64 function directly in the end-hosts + themselves. + + This document is structured as follows: section 2 provides a non- + normative overview of the behaviour of DNS64. Section 3 provides a + non-normative background required to understand the interaction + between DNS64 and DNSSEC. The normative specification of DNS64 is + provided in sections 4, 5 and 6. Section 4 defines the terminology, + section 5 is the actual DNS64 specification and section 6 covers + deployments issues. Section 7 is non-normative and provides a set of + examples and typical deployment scenarios. + + +2. Overview + + This section provides an introduction to the DNS64 mechanism. + + We assume that we have one or more IPv6/IPv4 translator boxes + + + +Bagnulo, et al. Expires April 4, 2011 [Page 5] + +Internet-Draft DNS64 October 2010 + + + connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 + translator device provides translation services between the two + networks enabling communication between IPv4-only hosts and IPv6-only + hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only + applications, hosts that can only use IPv6, as well as cases where + only IPv6 connectivity is available to the client. By IPv4-only + servers we mean servers running IPv4-only applications, servers that + can only use IPv4, as well as cases where only IPv4 connectivity is + available to the server). Each IPv6/IPv4 translator used in + conjunction with DNS64 must allow communications initiated from the + IPv6-only host to the IPv4-only host. + + To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to + learn the address of the responder, DNS64 is used to synthesize a + AAAA record from an A record containing a real IPv4 address of the + responder, whenever the DNS64 cannot retrieve a AAAA record for the + queried name. The DNS64 service appears as a regular DNS server or + resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query + generated by the IPv6 initiator. It first attempts a resolution for + the requested AAAA records. If there are no AAAA records available + for the target node (which is the normal case when the target node is + an IPv4-only node), DNS64 performs a query for A records. For each A + record discovered, DNS64 creates a synthetic AAAA RR from the + information retrieved in the A RR. + + The owner name of a synthetic AAAA RR is the same as that of the + original A RR, but an IPv6 representation of the IPv4 address + contained in the original A RR is included in the AAAA RR. The IPv6 + representation of the IPv4 address is algorithmically generated from + the IPv4 address and additional parameters configured in the DNS64. + Among those parameters configured in the DNS64, there is at least one + IPv6 prefix. If not explicitly mentioned, all prefixes are treated + equally and the operations described in this document are performed + using the prefixes available. So as to be general, we will call any + of these prefixes Pref64::/n, and describe the operations made with + the generic prefix Pref64::/n. The IPv6 address representing IPv4 + addresses included in the AAAA RR synthesized by the DNS64 contain + Pref64::/n and they also embed the original IPv4 address. + + The same algorithm and the same Pref64::/n prefix(es) must be + configured both in the DNS64 device and the IPv6/IPv4 translator(s), + so that both can algorithmically generate the same IPv6 + representation for a given IPv4 address. In addition, it is required + that IPv6 packets addressed to an IPv6 destination address that + contains the Pref64::/n be delivered to an IPv6/IPv4 translator that + has that particular Pref64::/n configured, so they can be translated + into IPv4 packets. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 6] + +Internet-Draft DNS64 October 2010 + + + Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs + are passed back to the IPv6 initiator, which will initiate an IPv6 + communication with the IPv6 address associated with the IPv4 + receiver. The packet will be routed to an IPv6/IPv4 translator which + will forward it to the IPv4 network. + + In general, the only shared state between the DNS64 and the IPv6/IPv4 + translator is the Pref64::/n and an optional set of static + parameters. The Pref64::/n and the set of static parameters must be + configured to be the same on both; there is no communication between + the DNS64 device and IPv6/IPv4 translator functions. The mechanism + to be used for configuring the parameters of the DNS64 is beyond the + scope of this memo. + + The prefixes to be used as Pref64::/n and their applicability are + discussed in [I-D.ietf-behave-address-format]. There are two types + of prefixes that can be used as Pref64::/n. + + The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved + by [I-D.ietf-behave-address-format] for the purpose of + representing IPv4 addresses in IPv6 address space. + + The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is + an IPv6 prefix assigned by an organization to create IPv6 + representations of IPv4 addresses. + + The main difference in the nature of the two types of prefixes is + that the NSP is a locally assigned prefix that is under control of + the organization that is providing the translation services, while + the Well-Known Prefix is a prefix that has a global meaning since it + has been assigned for the specific purpose of representing IPv4 + addresses in IPv6 address space. + + The DNS64 function can be performed in any of three places. The + terms below are more formally defined in Section 4. + + The first option is to locate the DNS64 function in authoritative + servers for a zone. In this case, the authoritative server provides + synthetic AAAA RRs for an IPv4-only host in its zone. This is one + type of DNS64 server. + + Another option is to locate the DNS64 function in recursive name + servers serving end hosts. In this case, when an IPv6-only host + queries the name server for AAAA RRs for an IPv4-only host, the name + server can perform the synthesis of AAAA RRs and pass them back to + the IPv6-only initiator. The main advantage of this mode is that + current IPv6 nodes can use this mechanism without requiring any + modification. This mode is called "DNS64 in DNS recursive resolver + + + +Bagnulo, et al. Expires April 4, 2011 [Page 7] + +Internet-Draft DNS64 October 2010 + + + mode". This is a second type of DNS64 server, and it is also one + type of DNS64 resolver. + + The last option is to place the DNS64 function in the end hosts, + coupled to the local (stub) resolver. In this case, the stub + resolver will try to obtain (real) AAAA RRs and in case they are not + available, the DNS64 function will synthesize AAAA RRs for internal + usage. This mode is compatible with some functions like DNSSEC + validation in the end host. The main drawback of this mode is its + deployability, since it requires changes in the end hosts. This mode + is called "DNS64 in stub-resolver mode". This is the second type of + DNS64 resolver. + + +3. Background to DNS64-DNSSEC interaction + + DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge + for DNS64, because DNSSEC is designed to detect changes to DNS + answers, and DNS64 may alter answers coming from an authoritative + server. + + A recursive resolver can be security-aware or security-oblivious. + Moreover, a security-aware recursive resolver can be validating or + non-validating, according to operator policy. In the cases below, + the recursive resolver is also performing DNS64, and has a local + policy to validate. We call this general case vDNS64, but in all the + cases below the DNS64 functionality should be assumed needed. + + DNSSEC includes some signaling bits that offer some indicators of + what the query originator understands. + + If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit + set, the query originator is signaling that it understands DNSSEC. + The DO bit does not indicate that the query originator will validate + the response. It only means that the query originator can understand + responses containing DNSSEC data. Conversely, if the DO bit is + clear, that is evidence that the querying agent is not aware of + DNSSEC. + + If a query arrives at a vDNS64 device with the "Checking Disabled" + (CD) bit set, it is an indication that the querying agent wants all + the validation data so it can do checking itself. By local policy, + vDNS64 could still validate, but it must return all data to the + querying agent anyway. + + Here are the possible cases: + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 8] + +Internet-Draft DNS64 October 2010 + + + 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with + the DO bit clear. In this case, DNSSEC is not a concern, because + the querying agent does not understand DNSSEC responses. The + DNS64 can do validation of the response, if dictated by its local + policy. + + 2. A security-oblivious DNS64 receives a query with the DO bit set, + and the CD bit clear or set. This is just like the case of a + non-DNS64 case: the server doesn't support it, so the querying + agent is out of luck. + + 3. A security-aware and non-validating DNS64 receives a query with + the DO bit set and the CD bit clear. Such a resolver is not + validating responses, likely due to local policy (see [RFC4035], + section 4.2). For that reason, this case amounts to the same as + the previous case, and no validation happens. + + 4. A security-aware and non-validating DNS64 receives a query with + the DO bit set and the CD bit set. In this case, the DNS64 is + supposed to pass on all the data it gets to the query initiator + (see section 3.2.2 of [RFC4035]). This case will not work with + DNS64, unless the validating resolver is prepared to do DNS64 + itself. If the DNS64 modifies the record, the client will get + the data back and try to validate it, and the data will be + invalid as far as the client is concerned. + + 5. A security-aware and validating DNS64 resolver receives a query + with the DO bit clear and CD clear. In this case, the resolver + validates the data. If it fails, it returns RCODE 2 (Server + failure); otherwise, it returns the answer. This is the ideal + case for vDNS64. The resolver validates the data, and then + synthesizes the new record and passes that to the client. The + client, which is presumably not validating (else it should have + set DO and CD), cannot tell that DNS64 is involved. + + 6. A security-aware and validating DNS64 resolver receives a query + with the DO bit set and CD clear. This works like the previous + case, except that the resolver should also set the "Authentic + Data" (AD) bit on the response. + + 7. A security-aware and validating DNS64 resolver receives a query + with the DO bit set and CD set. This is effectively the same as + the case where a security-aware and non-validating recursive + resolver receives a similar query, and the same thing will + happen: the downstream validator will mark the data as invalid if + DNS64 has performed synthesis. The node needs to do DNS64 + itself, or else communication will fail. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 9] + +Internet-Draft DNS64 October 2010 + + +4. Terminology + + This section provides definitions for the special terms used in the + document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + Authoritative server: A DNS server that can answer authoritatively a + given DNS request. + + DNS64: A logical function that synthesizes DNS resource records (e.g + AAAA records containing IPv6 addresses) from DNS resource records + actually contained in the DNS (e.g., A records containing IPv4 + addresses). + + DNS64 recursive resolver: A recursive resolver that provides the + DNS64 functionality as part of its operation. This is the same + thing as "DNS64 in recursive resolver mode". + + DNS64 resolver: Any resolver (stub resolver or recursive resolver) + that provides the DNS64 function. + + DNS64 server: Any server providing the DNS64 function. This + includes the server portion of a recursive resolver when it is + providing the DNS64 function. + + IPv4-only server: Servers running IPv4-only applications, servers + that can only use IPv4, as well as cases where only IPv4 + connectivity is available to the server. + + IPv6-only hosts: Hosts running IPv6-only applications, hosts that + can only use IPv6, as well as cases where only IPv6 connectivity + is available to the client. + + Recursive resolver: A DNS server that accepts requests from one + resolver, and asks another server (of some description) for the + answer on behalf of the first resolver. Full discussion of DNS + recursion is beyond the scope of this document; see [RFC1034] and + [RFC1035] for full details. + + Synthetic RR: A DNS resource record (RR) that is not contained in + the authoritative servers' zone data, but which is instead + synthesized from other RRs in the same zone. An example is a + synthetic AAAA record created from an A record. + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 10] + +Internet-Draft DNS64 October 2010 + + + IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 + packets and vice-versa. It is only required that the + communication initiated from the IPv6 side be supported. + + For a detailed understanding of this document, the reader should also + be familiar with DNS terminology from [RFC1034], [RFC1035] and + current NAT terminology from [RFC4787]. Some parts of this document + assume familiarity with the terminology of the DNS security + extensions outlined in [RFC4035]. It is worth emphasizing that while + DNS64 is a logical function separate from the DNS, it is nevertheless + closely associated with that protocol. It depends on the DNS + protocol, and some behavior of DNS64 will interact with regular DNS + responses. + + +5. DNS64 Normative Specification + + DNS64 is a logical function that synthesizes AAAA records from A + records. The DNS64 function may be implemented in a stub resolver, + in a recursive resolver, or in an authoritative name server. It + works within those DNS functions, and appears on the network as + though it were a "plain" DNS resolver or name server conforming to + [RFC1034], and [RFC1035]. + + The implementation SHOULD support mapping of separate IPv4 address + ranges to separate IPv6 prefixes for AAAA record synthesis. This + allows handling of special use IPv4 addresses [RFC5735]. + + DNS messages contain several sections. The portion of a DNS message + that is altered by DNS64 is the Answer section, which is discussed + below in section Section 5.1. The resulting synthetic answer is put + together with other sections, and that creates the message that is + actually returned as the response to the DNS query. Assembling that + response is covered below in section Section 5.4. + + DNS64 also responds to PTR queries involving addresses containing any + of the IPv6 prefixes it uses for synthesis of AAAA RRs. + +5.1. Resolving AAAA queries and the answer section + + When the DNS64 receives a query for RRs of type AAAA and class IN, it + first attempts to retrieve non-synthetic RRs of this type and class, + either by performing a query or, in the case of an authoritative + server, by examining its own results. The query may be answered from + a local cache, if one is available. DNS64 operation for classes + other than IN is undefined, and a DNS64 MUST behave as though no + DNS64 function is configured. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 11] + +Internet-Draft DNS64 October 2010 + + +5.1.1. The answer when there is AAAA data available + + If the query results in one or more AAAA records in the answer + section, the result is returned to the requesting client as per + normal DNS semantics, except in the case where any of the AAAA + records match a special exclusion set of prefixes, considered in + Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 + SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A + for an analysis of the motivations for and the implications of not + complying with this recommendation). By default DNS64 + implementations MUST NOT synthesize AAAA RRs when real AAAA RRs + exist. + +5.1.2. The answer when there is an error + + If the query results in a response with RCODE other than 0 (No error + condition), then there are two possibilities. A result with RCODE=3 + (Name Error) is handled according to normal DNS operation (which is + normally to return the error to the client). This stage is still + prior to any synthesis having happened, so a response to be returned + to the client does not need any special assembly than would usually + happen in DNS operation. + + Any other RCODE is treated as though the RCODE were 0 (see sections + Section 5.1.6 and Section 5.1.7) and the answer section were empty. + This is because of the large number of different responses from + deployed name servers when they receive AAAA queries without a AAAA + record being available (see [RFC4074]). Note that this means, for + practical purposes, that several different classes of error in the + DNS are all treated as though a AAAA record is not available for that + owner name. + + It is important to note that, as of this writing, some servers + respond with RCODE=3 to a AAAA query even if there is an A record + available for that owner name. Those servers are in clear violation + of the meaning of RCODE 3, and it is expected that they will decline + in use as IPv6 deployment increases. + +5.1.3. Dealing with timeouts + + If the query receives no answer before the timeout (which might be + the timeout from every authoritative server, depending on whether the + DNS64 is in recursive resolver mode), it is treated as RCODE=2 + (Server failure). + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 12] + +Internet-Draft DNS64 October 2010 + + +5.1.4. Special exclusion set for AAAA records + + Some IPv6 addresses are not actually usable by IPv6-only hosts. If + they are returned to IPv6-only querying agents as AAAA records, + therefore, the goal of decreasing the number of failure modes will + not be attained. Examples include AAAA records with addresses in the + ::ffff:0:0/96 network, and possibly (depending on the context) AAAA + records with the site's Pref::64/n or the Well-Known Prefix (see + below for more about the Well-Known Prefix). A DNS64 implementation + SHOULD provide a mechanism to specify IPv6 prefix ranges to be + treated as though the AAAA containing them were an empty answer. An + implementation SHOULD include the ::ffff/96 network in that range by + default. Failure to provide this facility will mean that clients + querying the DNS64 function may not be able to communicate with hosts + that would be reachable from a dual-stack host. + + When the DNS64 performs its initial AAAA query, if it receives an + answer with only AAAA records containing addresses in the excluded + range(s), then it MUST treat the answer as though it were an empty + answer, and proceed accordingly. If it receives an answer with at + least one AAAA record containing an address outside any of the + excluded range(s), then it MAY build an answer section for a response + including only the AAAA record(s) that do not contain any of the + addresses inside the excluded ranges. That answer section is used in + the assembly of a response as detailed in Section 5.4. + Alternatively, it MAY treat the answer as though it were an empty + answer, and proceed accordingly. It MUST NOT return the offending + AAAA records as part of a response. + +5.1.5. Dealing with CNAME and DNAME + + If the response contains a CNAME or a DNAME, then the CNAME or DNAME + chain is followed until the first terminating A or AAAA record is + reached. This may require the DNS64 to ask for an A record, in case + the response to the original AAAA query is a CNAME or DNAME without a + AAAA record to follow. The resulting AAAA or A record is treated + like any other AAAA or A case, as appropriate. + + When assembling the answer section, any chains of CNAME or DNAME RRs + are included as part of the answer along with the synthetic AAAA (if + appropriate). + +5.1.6. Data for the answer when performing synthesis + + If the query results in no error but an empty answer section in the + response, the DNS64 attempts to retrieve A records for the name in + question, either by performing another query or, in the case of an + authoritative server, by examining its own results. If this new A RR + + + +Bagnulo, et al. Expires April 4, 2011 [Page 13] + +Internet-Draft DNS64 October 2010 + + + query results in an empty answer or in an error, then the empty + result or error is used as the basis for the answer returned to the + querying client. If instead the query results in one or more A RRs, *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-src-vendor@FreeBSD.ORG Wed Dec 8 19:33:45 2010 Return-Path: Delivered-To: svn-src-vendor@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD751065679; Wed, 8 Dec 2010 19:33:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 0091D8FC20; Wed, 8 Dec 2010 19:33:45 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id oB8JXiYp012681; Wed, 8 Dec 2010 19:33:44 GMT (envelope-from dougb@svn.freebsd.org) Received: (from dougb@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id oB8JXilG012680; Wed, 8 Dec 2010 19:33:44 GMT (envelope-from dougb@svn.freebsd.org) Message-Id: <201012081933.oB8JXilG012680@svn.freebsd.org> From: Doug Barton Date: Wed, 8 Dec 2010 19:33:44 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-vendor@freebsd.org X-SVN-Group: vendor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r216303 - vendor/bind9/9.4-ESV-R4 X-BeenThere: svn-src-vendor@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the vendor work area tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 19:33:45 -0000 Author: dougb Date: Wed Dec 8 19:33:44 2010 New Revision: 216303 URL: http://svn.freebsd.org/changeset/base/216303 Log: Tag the 9.4-ESV-R4 release Added: vendor/bind9/9.4-ESV-R4/ - copied from r216302, vendor/bind9/dist-9.4/ From owner-svn-src-vendor@FreeBSD.ORG Thu Dec 9 20:04:15 2010 Return-Path: Delivered-To: svn-src-vendor@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317F41065695; Thu, 9 Dec 2010 20:04:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE448FC1D; Thu, 9 Dec 2010 20:04:15 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id oB9K4Fvv049262; Thu, 9 Dec 2010 20:04:15 GMT (envelope-from jkim@svn.freebsd.org) Received: (from jkim@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id oB9K4EV9049247; Thu, 9 Dec 2010 20:04:14 GMT (envelope-from jkim@svn.freebsd.org) Message-Id: <201012092004.oB9K4EV9049247@svn.freebsd.org> From: Jung-uk Kim Date: Thu, 9 Dec 2010 20:04:14 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-vendor@freebsd.org X-SVN-Group: vendor-sys MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r216331 - in vendor-sys/acpica/dist: . common compiler debugger dispatcher events executer include tests/misc tools/acpiexec tools/acpisrc utilities X-BeenThere: svn-src-vendor@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the vendor work area tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:04:15 -0000 Author: jkim Date: Thu Dec 9 20:04:14 2010 New Revision: 216331 URL: http://svn.freebsd.org/changeset/base/216331 Log: Import ACPICA 20101209. Added: vendor-sys/acpica/dist/events/evxfgpe.c (contents, props changed) Modified: vendor-sys/acpica/dist/changes.txt vendor-sys/acpica/dist/common/dmtable.c vendor-sys/acpica/dist/common/dmtbinfo.c vendor-sys/acpica/dist/compiler/aslanalyze.c vendor-sys/acpica/dist/compiler/aslerror.c vendor-sys/acpica/dist/compiler/aslmessages.h vendor-sys/acpica/dist/compiler/dtutils.c vendor-sys/acpica/dist/debugger/dbcmds.c vendor-sys/acpica/dist/debugger/dbdisply.c vendor-sys/acpica/dist/debugger/dbexec.c vendor-sys/acpica/dist/dispatcher/dswexec.c vendor-sys/acpica/dist/events/evevent.c vendor-sys/acpica/dist/events/evgpe.c vendor-sys/acpica/dist/events/evgpeblk.c vendor-sys/acpica/dist/events/evgpeinit.c vendor-sys/acpica/dist/events/evgpeutil.c vendor-sys/acpica/dist/events/evxface.c vendor-sys/acpica/dist/events/evxfevnt.c vendor-sys/acpica/dist/executer/exconfig.c vendor-sys/acpica/dist/include/acdebug.h vendor-sys/acpica/dist/include/acdisasm.h vendor-sys/acpica/dist/include/acevents.h vendor-sys/acpica/dist/include/acglobal.h vendor-sys/acpica/dist/include/aclocal.h vendor-sys/acpica/dist/include/acpixf.h vendor-sys/acpica/dist/include/actypes.h vendor-sys/acpica/dist/tests/misc/badcode.asl vendor-sys/acpica/dist/tools/acpiexec/Makefile vendor-sys/acpica/dist/tools/acpiexec/aecommon.h vendor-sys/acpica/dist/tools/acpiexec/aeexec.c vendor-sys/acpica/dist/tools/acpiexec/aehandlers.c vendor-sys/acpica/dist/tools/acpisrc/astable.c vendor-sys/acpica/dist/utilities/utglobal.c vendor-sys/acpica/dist/utilities/utxface.c Modified: vendor-sys/acpica/dist/changes.txt ============================================================================== --- vendor-sys/acpica/dist/changes.txt Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/changes.txt Thu Dec 9 20:04:14 2010 (r216331) @@ -1,4 +1,76 @@ ---------------------------------------- +09 December 2010. Summary of changes for version 20101209: + +This release is available at www.acpica.org/downloads + +1) ACPI CA Core Subsystem: + +Completed the major overhaul of the GPE support code that was begun in July +2010. Major features include: removal of _PRW execution in ACPICA (host +executes _PRWs anyway), cleanup of "wake" GPE interfaces and processing, +changes to existing interfaces, simplification of GPE handler operation, and +a handful of new interfaces: + + AcpiUpdateAllGpes + AcpiFinishGpe + AcpiSetupGpeForWake + AcpiSetGpeWakeMask + One new file, evxfgpe.c to consolidate all external GPE interfaces. + +See the ACPICA Programmer Reference for full details and programming +information. See the new section 4.4 "General Purpose Event (GPE) Support" +for a full overview, and section 8.7 "ACPI General Purpose Event Management" +for programming details. ACPICA BZ 858,870,877. Matthew Garrett, Lin Ming, +Bob Moore, Rafael Wysocki. + +Implemented a new GPE feature for Windows compatibility, the "Implicit Wake +GPE Notify". This feature will automatically issue a Notify(2) on a device +when a Wake GPE is received if there is no corresponding GPE method or +handler. ACPICA BZ 870. + +Fixed a problem with the Scope() operator during table parse and load phase. +During load phase (table load or method execution), the scope operator should +not enter the target into the namespace. Instead, it should open a new scope +at the target location. Linux BZ 19462, ACPICA BZ 882. + +Example Code and Data Size: These are the sizes for the OS-independent +acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The +debug version of the code includes the debug output trace mechanism and has a +much larger code and data size. + + Previous Release: + Non-Debug Version: 89.8K Code, 18.9K Data, 108.7K Total + Debug Version: 166.6K Code, 52.1K Data, 218.7K Total + Current Release: + Non-Debug Version: 89.9K Code, 19.0K Data, 108.9K Total + Debug Version: 166.3K Code, 52.1K Data, 218.4K Total + +2) iASL Compiler/Disassembler and Tools: + +iASL: Relax the alphanumeric restriction on _CID strings. These strings are +"bus-specific" per the ACPI specification, and therefore any characters are +acceptable. The only checks that can be performed are for a null string and +perhaps for a leading asterisk. ACPICA BZ 886. + +iASL: Fixed a problem where a syntax error that caused a premature EOF +condition on the source file emitted a very confusing error message. The +premature EOF is now detected correctly. ACPICA BZ 891. + +Disassembler: Decode the AccessSize within a Generic Address Structure (byte +access, word access, etc.) Note, this field does not allow arbitrary bit +access, the size is encoded as 1=byte, 2=word, 3=dword, and 4=qword. + +New: AcpiNames utility - Example namespace dump utility. Shows an example of +ACPICA configuration for a minimal namespace dump utility. Uses table and +namespace managers, but no AML interpreter. Does not add any functionality +over AcpiExec, it is a subset of AcpiExec. The purpose is to show how to +partition and configure ACPICA. ACPICA BZ 883. + +AML Debugger: Increased the debugger buffer size for method return objects. +Was 4K, increased to 16K. Also enhanced error messages for debugger method +execution, including the buffer overflow case. + +---------------------------------------- 13 October 2010. Summary of changes for version 20101013: This release is available at www.acpica.org/downloads Modified: vendor-sys/acpica/dist/common/dmtable.c ============================================================================== --- vendor-sys/acpica/dist/common/dmtable.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/common/dmtable.c Thu Dec 9 20:04:14 2010 (r216331) @@ -295,6 +295,19 @@ static const char *AcpiDmFadtP "Unknown Profile Type" }; +#define ACPI_GAS_WIDTH_RESERVED 5 + +static const char *AcpiDmGasAccessWidth[] = +{ + "Undefined/Legacy", + "Byte Access:8", + "Word Access:16", + "DWord Access:32", + "QWord Access:64", + "Unknown Width Encoding" +}; + + /******************************************************************************* * * ACPI Table Data, indexed by signature. @@ -669,6 +682,7 @@ AcpiDmDumpTable ( case ACPI_DMT_UINT8: case ACPI_DMT_CHKSUM: case ACPI_DMT_SPACEID: + case ACPI_DMT_ACCWIDTH: case ACPI_DMT_IVRS: case ACPI_DMT_MADT: case ACPI_DMT_SRAT: @@ -884,6 +898,19 @@ AcpiDmDumpTable ( AcpiOsPrintf ("%2.2X (%s)\n", *Target, AcpiUtGetRegionName (*Target)); break; + case ACPI_DMT_ACCWIDTH: + + /* Encoded Access Width */ + + Temp8 = *Target; + if (Temp8 > ACPI_GAS_WIDTH_RESERVED) + { + Temp8 = ACPI_GAS_WIDTH_RESERVED; + } + + AcpiOsPrintf ("%2.2X (%s)\n", Temp8, AcpiDmGasAccessWidth[Temp8]); + break; + case ACPI_DMT_GAS: /* Generic Address Structure */ Modified: vendor-sys/acpica/dist/common/dmtbinfo.c ============================================================================== --- vendor-sys/acpica/dist/common/dmtbinfo.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/common/dmtbinfo.c Thu Dec 9 20:04:14 2010 (r216331) @@ -282,7 +282,7 @@ ACPI_DMTABLE_INFO AcpiDmTableI {ACPI_DMT_SPACEID, ACPI_GAS_OFFSET (SpaceId), "Space ID", 0}, {ACPI_DMT_UINT8, ACPI_GAS_OFFSET (BitWidth), "Bit Width", 0}, {ACPI_DMT_UINT8, ACPI_GAS_OFFSET (BitOffset), "Bit Offset", 0}, - {ACPI_DMT_UINT8, ACPI_GAS_OFFSET (AccessWidth), "Access Width", 0}, + {ACPI_DMT_ACCWIDTH, ACPI_GAS_OFFSET (AccessWidth), "Encoded Access Width", 0}, {ACPI_DMT_UINT64, ACPI_GAS_OFFSET (Address), "Address", 0}, ACPI_DMT_TERMINATOR }; Modified: vendor-sys/acpica/dist/compiler/aslanalyze.c ============================================================================== --- vendor-sys/acpica/dist/compiler/aslanalyze.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/compiler/aslanalyze.c Thu Dec 9 20:04:14 2010 (r216331) @@ -684,19 +684,45 @@ AnCheckId ( UINT32 AlphaPrefixLength; + /* Only care about string versions of _HID/_CID (integers are legal) */ + if (Op->Asl.ParseOpcode != PARSEOP_STRING_LITERAL) { return; } + /* For both _HID and _CID, the string must be non-null */ + Length = strlen (Op->Asl.Value.String); + if (!Length) + { + AslError (ASL_ERROR, ASL_MSG_NULL_STRING, + Op, NULL); + return; + } /* - * If _HID/_CID is a string, all characters must be alphanumeric. - * One of the things we want to catch here is the use of - * a leading asterisk in the string -- an odd construct - * that certain platform manufacturers are fond of. + * One of the things we want to catch here is the use of a leading + * asterisk in the string -- an odd construct that certain platform + * manufacturers are fond of. Technically, a leading asterisk is OK + * for _CID, but a valid use of this has not been seen. */ + if (*Op->Asl.Value.String == '*') + { + AslError (ASL_ERROR, ASL_MSG_LEADING_ASTERISK, + Op, Op->Asl.Value.String); + return; + } + + /* _CID strings are bus-specific, no more checks can be performed */ + + if (Type == ASL_TYPE_CID) + { + return; + } + + /* For _HID, all characters must be alphanumeric */ + for (i = 0; Op->Asl.Value.String[i]; i++) { if (!isalnum ((int) Op->Asl.Value.String[i])) @@ -707,13 +733,6 @@ AnCheckId ( } } - if (Type == ASL_TYPE_CID) - { - /* _CID strings are bus-specific, no more checks can be performed */ - - return; - } - /* _HID String must be of the form "XXX####" or "ACPI####" */ if ((Length < 7) || (Length > 8)) Modified: vendor-sys/acpica/dist/compiler/aslerror.c ============================================================================== --- vendor-sys/acpica/dist/compiler/aslerror.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/compiler/aslerror.c Thu Dec 9 20:04:14 2010 (r216331) @@ -241,6 +241,8 @@ AePrintException ( UINT32 ErrorColumn; FILE *OutputFile; FILE *SourceFile; + long FileSize; + BOOLEAN PrematureEOF = FALSE; if (Gbl_NoErrors) @@ -289,6 +291,19 @@ AePrintException ( SourceFile = Gbl_Files[ASL_FILE_INPUT].Handle; } + if (SourceFile) + { + /* Determine if the error occurred at source file EOF */ + + fseek (SourceFile, 0, SEEK_END); + FileSize = ftell (SourceFile); + + if ((long) Enode->LogicalByteOffset >= FileSize) + { + PrematureEOF = TRUE; + } + } + if (Header) { fprintf (OutputFile, "%s", Header); @@ -307,33 +322,42 @@ AePrintException ( fprintf (OutputFile, " %6u: ", Enode->LineNumber); /* - * Seek to the offset in the combined source file, read the source - * line, and write it to the output. + * If not at EOF, get the corresponding source code line and + * display it. Don't attempt this if we have a premature EOF + * condition. */ - Actual = fseek (SourceFile, (long) Enode->LogicalByteOffset, - (int) SEEK_SET); - if (Actual) - { - fprintf (OutputFile, - "[*** iASL: Seek error on source code temp file %s ***]", - Gbl_Files[ASL_FILE_SOURCE_OUTPUT].Filename); - } - else + if (!PrematureEOF) { - RActual = fread (&SourceByte, 1, 1, SourceFile); - if (!RActual) + /* + * Seek to the offset in the combined source file, read + * the source line, and write it to the output. + */ + Actual = fseek (SourceFile, (long) Enode->LogicalByteOffset, + (int) SEEK_SET); + if (Actual) { fprintf (OutputFile, - "[*** iASL: Read error on source code temp file %s ***]", + "[*** iASL: Seek error on source code temp file %s ***]", Gbl_Files[ASL_FILE_SOURCE_OUTPUT].Filename); } - - else while (RActual && SourceByte && (SourceByte != '\n')) + else { - fwrite (&SourceByte, 1, 1, OutputFile); RActual = fread (&SourceByte, 1, 1, SourceFile); + if (!RActual) + { + fprintf (OutputFile, + "[*** iASL: Read error on source code temp file %s ***]", + Gbl_Files[ASL_FILE_SOURCE_OUTPUT].Filename); + } + + else while (RActual && SourceByte && (SourceByte != '\n')) + { + fwrite (&SourceByte, 1, 1, OutputFile); + RActual = fread (&SourceByte, 1, 1, SourceFile); + } } } + fprintf (OutputFile, "\n"); } } @@ -376,7 +400,7 @@ AePrintException ( ExtraMessage = NULL; } - if (Gbl_VerboseErrors) + if (Gbl_VerboseErrors && !PrematureEOF) { SourceColumn = Enode->Column + Enode->FilenameLength + 6 + 2; ErrorColumn = ASL_ERROR_LEVEL_LENGTH + 5 + 2 + 1; @@ -406,6 +430,11 @@ AePrintException ( fprintf (OutputFile, " (%s)", ExtraMessage); } + if (PrematureEOF) + { + fprintf (OutputFile, " and premature End-Of-File"); + } + fprintf (OutputFile, "\n"); if (Gbl_VerboseErrors) { Modified: vendor-sys/acpica/dist/compiler/aslmessages.h ============================================================================== --- vendor-sys/acpica/dist/compiler/aslmessages.h Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/compiler/aslmessages.h Thu Dec 9 20:04:14 2010 (r216331) @@ -258,6 +258,9 @@ typedef enum ASL_MSG_NULL_DESCRIPTOR, ASL_MSG_UPPER_CASE, ASL_MSG_HID_LENGTH, + ASL_MSG_NULL_STRING, + ASL_MSG_LEADING_ASTERISK, + ASL_MSG_INVALID_FIELD_NAME, ASL_MSG_INTEGER_SIZE, ASL_MSG_INVALID_HEX_INTEGER, @@ -382,7 +385,7 @@ char *AslMessages /* ASL_MSG_VENDOR_LIST */ "Too many vendor data bytes (7 max)", /* ASL_MSG_WRITE */ "Could not write file", /* ASL_MSG_MULTIPLE_DEFAULT */ "More than one Default statement within Switch construct", -/* ASL_MSG_TIMEOUT */ "Possible operator timeout is ignored", +/* ASL_MSG_TIMEOUT */ "Result is not used, possible operator timeout will be missed", /* ASL_MSG_RESULT_NOT_USED */ "Result is not used, operator has no effect", /* ASL_MSG_NOT_REFERENCED */ "Namespace object is not referenced", /* ASL_MSG_NON_ZERO */ "Operand evaluates to zero", @@ -403,6 +406,8 @@ char *AslMessages /* ASL_MSG_NULL_DESCRIPTOR */ "Min/Max/Length/Gran are all zero, but no resource tag", /* ASL_MSG_UPPER_CASE */ "Non-hex letters must be upper case", /* ASL_MSG_HID_LENGTH */ "_HID string must be exactly 7 or 8 characters", +/* ASL_MSG_NULL_STRING */ "Invalid zero-length (null) string", +/* ASL_MSG_LEADING_ASTERISK */ "Invalid leading asterisk", /* These messages are used by the data table compiler only */ Modified: vendor-sys/acpica/dist/compiler/dtutils.c ============================================================================== --- vendor-sys/acpica/dist/compiler/dtutils.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/compiler/dtutils.c Thu Dec 9 20:04:14 2010 (r216331) @@ -573,6 +573,7 @@ DtGetFieldLength ( case ACPI_DMT_UINT8: case ACPI_DMT_CHKSUM: case ACPI_DMT_SPACEID: + case ACPI_DMT_ACCWIDTH: case ACPI_DMT_IVRS: case ACPI_DMT_MADT: case ACPI_DMT_SRAT: Modified: vendor-sys/acpica/dist/debugger/dbcmds.c ============================================================================== --- vendor-sys/acpica/dist/debugger/dbcmds.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/debugger/dbcmds.c Thu Dec 9 20:04:14 2010 (r216331) @@ -2071,7 +2071,7 @@ AcpiDbGenerateGpe ( return; } - (void) AcpiEvGpeDispatch (GpeEventInfo, GpeNumber); + (void) AcpiEvGpeDispatch (NULL, GpeEventInfo, GpeNumber); } Modified: vendor-sys/acpica/dist/debugger/dbdisply.c ============================================================================== --- vendor-sys/acpica/dist/debugger/dbdisply.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/debugger/dbdisply.c Thu Dec 9 20:04:14 2010 (r216331) @@ -896,7 +896,8 @@ AcpiDbDisplayGpes ( GpeIndex = (i * ACPI_GPE_REGISTER_WIDTH) + j; GpeEventInfo = &GpeBlock->EventInfo[GpeIndex]; - if (!(GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK)) + if ((GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) == + ACPI_GPE_DISPATCH_NONE) { /* This GPE is not used (no method or handler), ignore it */ @@ -906,8 +907,7 @@ AcpiDbDisplayGpes ( AcpiOsPrintf ( " GPE %.2X: %p RunRefs %2.2X Flags %2.2X (", GpeBlock->BlockBaseNumber + GpeIndex, GpeEventInfo, - GpeEventInfo->RuntimeCount, - GpeEventInfo->Flags); + GpeEventInfo->RuntimeCount, GpeEventInfo->Flags); /* Decode the flags byte */ @@ -931,14 +931,17 @@ AcpiDbDisplayGpes ( switch (GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) { - case ACPI_GPE_DISPATCH_NOT_USED: + case ACPI_GPE_DISPATCH_NONE: AcpiOsPrintf ("NotUsed"); break; + case ACPI_GPE_DISPATCH_METHOD: + AcpiOsPrintf ("Method"); + break; case ACPI_GPE_DISPATCH_HANDLER: AcpiOsPrintf ("Handler"); break; - case ACPI_GPE_DISPATCH_METHOD: - AcpiOsPrintf ("Method"); + case ACPI_GPE_DISPATCH_NOTIFY: + AcpiOsPrintf ("Notify"); break; default: AcpiOsPrintf ("UNKNOWN: %X", Modified: vendor-sys/acpica/dist/debugger/dbexec.c ============================================================================== --- vendor-sys/acpica/dist/debugger/dbexec.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/debugger/dbexec.c Thu Dec 9 20:04:14 2010 (r216331) @@ -180,6 +180,9 @@ AcpiDbExecuteMethod ( ACPI_DEVICE_INFO *ObjInfo; + ACPI_FUNCTION_TRACE (DbExecuteMethod); + + if (AcpiGbl_DbOutputToFile && !AcpiDbgLevel) { AcpiOsPrintf ("Warning: debug output is not enabled!\n"); @@ -190,7 +193,7 @@ AcpiDbExecuteMethod ( Status = AcpiGetHandle (NULL, Info->Pathname, &Handle); if (ACPI_FAILURE (Status)) { - return (Status); + return_ACPI_STATUS (Status); } /* Get the object info for number of method parameters */ @@ -198,7 +201,7 @@ AcpiDbExecuteMethod ( Status = AcpiGetObjectInfo (Handle, &ObjInfo); if (ACPI_FAILURE (Status)) { - return (Status); + return_ACPI_STATUS (Status); } ParamObjects.Pointer = NULL; @@ -269,7 +272,20 @@ AcpiDbExecuteMethod ( AcpiGbl_CmSingleStep = FALSE; AcpiGbl_MethodExecuting = FALSE; - return (Status); + if (ACPI_FAILURE (Status)) + { + ACPI_EXCEPTION ((AE_INFO, Status, + "while executing %s from debugger", Info->Pathname)); + + if (Status == AE_BUFFER_OVERFLOW) + { + ACPI_ERROR ((AE_INFO, + "Possible overflow of internal debugger buffer (size 0x%X needed 0x%X)", + ACPI_DEBUG_BUFFER_SIZE, (UINT32) ReturnObj->Length)); + } + } + + return_ACPI_STATUS (Status); } Modified: vendor-sys/acpica/dist/dispatcher/dswexec.c ============================================================================== --- vendor-sys/acpica/dist/dispatcher/dswexec.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/dispatcher/dswexec.c Thu Dec 9 20:04:14 2010 (r216331) @@ -400,10 +400,26 @@ AcpiDsExecBeginOp ( * we must enter this object into the namespace. The created * object is temporary and will be deleted upon completion of * the execution of this method. + * + * Note 10/2010: Except for the Scope() op. This opcode does + * not actually create a new object, it refers to an existing + * object. However, for Scope(), we want to indeed open a + * new scope. */ - Status = AcpiDsLoad2BeginOp (WalkState, NULL); + if (Op->Common.AmlOpcode != AML_SCOPE_OP) + { + Status = AcpiDsLoad2BeginOp (WalkState, NULL); + } + else + { + Status = AcpiDsScopeStackPush (Op->Named.Node, + Op->Named.Node->Type, WalkState); + if (ACPI_FAILURE (Status)) + { + return_ACPI_STATUS (Status); + } + } } - break; Modified: vendor-sys/acpica/dist/events/evevent.c ============================================================================== --- vendor-sys/acpica/dist/events/evevent.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/events/evevent.c Thu Dec 9 20:04:14 2010 (r216331) @@ -180,54 +180,6 @@ AcpiEvInitializeEvents ( /******************************************************************************* * - * FUNCTION: AcpiEvInstallFadtGpes - * - * PARAMETERS: None - * - * RETURN: Status - * - * DESCRIPTION: Completes initialization of the FADT-defined GPE blocks - * (0 and 1). This causes the _PRW methods to be run, so the HW - * must be fully initialized at this point, including global lock - * support. - * - ******************************************************************************/ - -ACPI_STATUS -AcpiEvInstallFadtGpes ( - void) -{ - ACPI_STATUS Status; - - - ACPI_FUNCTION_TRACE (EvInstallFadtGpes); - - - /* Namespace must be locked */ - - Status = AcpiUtAcquireMutex (ACPI_MTX_NAMESPACE); - if (ACPI_FAILURE (Status)) - { - return (Status); - } - - /* FADT GPE Block 0 */ - - (void) AcpiEvInitializeGpeBlock ( - AcpiGbl_FadtGpeDevice, AcpiGbl_GpeFadtBlocks[0]); - - /* FADT GPE Block 1 */ - - (void) AcpiEvInitializeGpeBlock ( - AcpiGbl_FadtGpeDevice, AcpiGbl_GpeFadtBlocks[1]); - - (void) AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE); - return_ACPI_STATUS (AE_OK); -} - - -/******************************************************************************* - * * FUNCTION: AcpiEvInstallXruptHandlers * * PARAMETERS: None @@ -366,9 +318,17 @@ AcpiEvFixedEventDetect ( if ((FixedStatus & AcpiGbl_FixedEventInfo[i].StatusBitMask) && (FixedEnable & AcpiGbl_FixedEventInfo[i].EnableBitMask)) { - /* Found an active (signalled) event */ - + /* + * Found an active (signalled) event. Invoke global event + * handler if present. + */ AcpiFixedEventCount[i]++; + if (AcpiGbl_GlobalEventHandler) + { + AcpiGbl_GlobalEventHandler (ACPI_EVENT_TYPE_FIXED, NULL, + i, AcpiGbl_GlobalEventHandlerContext); + } + IntStatus |= AcpiEvFixedEventDispatch (i); } } Modified: vendor-sys/acpica/dist/events/evgpe.c ============================================================================== --- vendor-sys/acpica/dist/events/evgpe.c Thu Dec 9 19:02:23 2010 (r216330) +++ vendor-sys/acpica/dist/events/evgpe.c Thu Dec 9 20:04:14 2010 (r216331) @@ -202,12 +202,13 @@ AcpiEvEnableGpe ( /* - * We will only allow a GPE to be enabled if it has either an - * associated method (_Lxx/_Exx) or a handler. Otherwise, the - * GPE will be immediately disabled by AcpiEvGpeDispatch the - * first time it fires. + * We will only allow a GPE to be enabled if it has either an associated + * method (_Lxx/_Exx) or a handler, or is using the implicit notify + * feature. Otherwise, the GPE will be immediately disabled by + * AcpiEvGpeDispatch the first time it fires. */ - if (!(GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK)) + if ((GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) == + ACPI_GPE_DISPATCH_NONE) { return_ACPI_STATUS (AE_NO_HANDLER); } @@ -229,6 +230,104 @@ AcpiEvEnableGpe ( /******************************************************************************* * + * FUNCTION: AcpiEvAddGpeReference + * + * PARAMETERS: GpeEventInfo - Add a reference to this GPE + * + * RETURN: Status + * + * DESCRIPTION: Add a reference to a GPE. On the first reference, the GPE is + * hardware-enabled. + * + ******************************************************************************/ + +ACPI_STATUS +AcpiEvAddGpeReference ( + ACPI_GPE_EVENT_INFO *GpeEventInfo) +{ + ACPI_STATUS Status = AE_OK; + + + ACPI_FUNCTION_TRACE (EvAddGpeReference); + + + if (GpeEventInfo->RuntimeCount == ACPI_UINT8_MAX) + { + return_ACPI_STATUS (AE_LIMIT); + } + + GpeEventInfo->RuntimeCount++; + if (GpeEventInfo->RuntimeCount == 1) + { + /* Enable on first reference */ + + Status = AcpiEvUpdateGpeEnableMask (GpeEventInfo); + if (ACPI_SUCCESS (Status)) + { + Status = AcpiEvEnableGpe (GpeEventInfo); + } + + if (ACPI_FAILURE (Status)) + { + GpeEventInfo->RuntimeCount--; + } + } + + return_ACPI_STATUS (Status); +} + + +/******************************************************************************* + * + * FUNCTION: AcpiEvRemoveGpeReference + * + * PARAMETERS: GpeEventInfo - Remove a reference to this GPE + * + * RETURN: Status + * + * DESCRIPTION: Remove a reference to a GPE. When the last reference is + * removed, the GPE is hardware-disabled. + * + ******************************************************************************/ + +ACPI_STATUS +AcpiEvRemoveGpeReference ( + ACPI_GPE_EVENT_INFO *GpeEventInfo) +{ + ACPI_STATUS Status = AE_OK; + + + ACPI_FUNCTION_TRACE (EvRemoveGpeReference); + + + if (!GpeEventInfo->RuntimeCount) + { + return_ACPI_STATUS (AE_LIMIT); + } + + GpeEventInfo->RuntimeCount--; + if (!GpeEventInfo->RuntimeCount) + { + /* Disable on last reference */ + + Status = AcpiEvUpdateGpeEnableMask (GpeEventInfo); + if (ACPI_SUCCESS (Status)) + { + Status = AcpiHwLowSetGpe (GpeEventInfo, ACPI_GPE_DISABLE); + } + + if (ACPI_FAILURE (Status)) + { + GpeEventInfo->RuntimeCount++; + } + } + + return_ACPI_STATUS (Status); +} + + +/******************************************************************************* + * * FUNCTION: AcpiEvLowGetGpeInfo * * PARAMETERS: GpeNumber - Raw GPE number @@ -412,7 +511,7 @@ AcpiEvGpeDetect ( } ACPI_DEBUG_PRINT ((ACPI_DB_INTERRUPTS, - "Read GPE Register at GPE%X: Status=%02X, Enable=%02X\n", + "Read GPE Register at GPE%02X: Status=%02X, Enable=%02X\n", GpeRegisterInfo->BaseGpeNumber, StatusReg, EnableReg)); /* Check if there is anything active at all in this register */ @@ -437,7 +536,7 @@ AcpiEvGpeDetect ( * Found an active GPE. Dispatch the event to a handler * or method. */ - IntStatus |= AcpiEvGpeDispatch ( + IntStatus |= AcpiEvGpeDispatch (GpeBlock->Node, &GpeBlock->EventInfo[((ACPI_SIZE) i * ACPI_GPE_REGISTER_WIDTH) + j], j + GpeRegisterInfo->BaseGpeNumber); @@ -521,13 +620,27 @@ AcpiEvAsynchExecuteGpeMethod ( return_VOID; } - /* - * Must check for control method type dispatch one more time to avoid a - * race with EvGpeInstallHandler - */ - if ((LocalGpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) == - ACPI_GPE_DISPATCH_METHOD) + /* Do the correct dispatch - normal method or implicit notify */ + + switch (LocalGpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) { + case ACPI_GPE_DISPATCH_NOTIFY: + + /* + * Implicit notify. + * Dispatch a DEVICE_WAKE notify to the appropriate handler. + * NOTE: the request is queued for execution after this method + * completes. The notify handlers are NOT invoked synchronously + * from this thread -- because handlers may in turn run other + * control methods. + */ + Status = AcpiEvQueueNotifyRequest ( + LocalGpeEventInfo->Dispatch.DeviceNode, + ACPI_NOTIFY_DEVICE_WAKE); + break; + + case ACPI_GPE_DISPATCH_METHOD: + /* Allocate the evaluation information block */ Info = ACPI_ALLOCATE_ZEROED (sizeof (ACPI_EVALUATE_INFO)); @@ -538,8 +651,8 @@ AcpiEvAsynchExecuteGpeMethod ( else { /* - * Invoke the GPE Method (_Lxx, _Exx) i.e., evaluate the _Lxx/_Exx - * control method that corresponds to this GPE + * Invoke the GPE Method (_Lxx, _Exx) i.e., evaluate the + * _Lxx/_Exx control method that corresponds to this GPE */ Info->PrefixNode = LocalGpeEventInfo->Dispatch.MethodNode; Info->Flags = ACPI_IGNORE_RETURN_VALUE; @@ -554,6 +667,11 @@ AcpiEvAsynchExecuteGpeMethod ( "while evaluating GPE method [%4.4s]", AcpiUtGetNodeName (LocalGpeEventInfo->Dispatch.MethodNode))); } + + break; + + default: + return_VOID; /* Should never happen */ } /* Defer enabling of GPE until all notify handlers are done */ @@ -573,6 +691,7 @@ AcpiEvAsynchExecuteGpeMethod ( * FUNCTION: AcpiEvAsynchEnableGpe * * PARAMETERS: Context (GpeEventInfo) - Info for this GPE + * Callback from AcpiOsExecute * * RETURN: None * @@ -586,6 +705,32 @@ AcpiEvAsynchEnableGpe ( void *Context) { ACPI_GPE_EVENT_INFO *GpeEventInfo = Context; + + + (void) AcpiEvFinishGpe (GpeEventInfo); + + ACPI_FREE (GpeEventInfo); + return; +} + + +/******************************************************************************* + * + * FUNCTION: AcpiEvFinishGpe + * + * PARAMETERS: GpeEventInfo - Info for this GPE + * + * RETURN: Status + * + * DESCRIPTION: Clear/Enable a GPE. Common code that is used after execution + * of a GPE method or a synchronous or asynchronous GPE handler. + * + ******************************************************************************/ + +ACPI_STATUS +AcpiEvFinishGpe ( + ACPI_GPE_EVENT_INFO *GpeEventInfo) +{ ACPI_STATUS Status; @@ -593,25 +738,23 @@ AcpiEvAsynchEnableGpe ( ACPI_GPE_LEVEL_TRIGGERED) { /* - * GPE is level-triggered, we clear the GPE status bit after handling - * the event. + * GPE is level-triggered, we clear the GPE status bit after + * handling the event. */ Status = AcpiHwClearGpe (GpeEventInfo); if (ACPI_FAILURE (Status)) { - goto Exit; + return (Status); } } /* - * Enable this GPE, conditionally. This means that the GPE will only be - * physically enabled if the EnableForRun bit is set in the EventInfo + * Enable this GPE, conditionally. This means that the GPE will + * only be physically enabled if the EnableForRun bit is set + * in the EventInfo. */ (void) AcpiHwLowSetGpe (GpeEventInfo, ACPI_GPE_CONDITIONAL_ENABLE); - -Exit: - ACPI_FREE (GpeEventInfo); - return; + return (AE_OK); } @@ -619,8 +762,9 @@ Exit: * * FUNCTION: AcpiEvGpeDispatch * - * PARAMETERS: GpeEventInfo - Info for this GPE - * GpeNumber - Number relative to the parent GPE block + * PARAMETERS: GpeDevice - Device node. NULL for GPE0/GPE1 + * GpeEventInfo - Info for this GPE + * GpeNumber - Number relative to the parent GPE block * * RETURN: INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED * @@ -633,16 +777,25 @@ Exit: UINT32 AcpiEvGpeDispatch ( + ACPI_NAMESPACE_NODE *GpeDevice, ACPI_GPE_EVENT_INFO *GpeEventInfo, UINT32 GpeNumber) { ACPI_STATUS Status; + UINT32 ReturnValue; ACPI_FUNCTION_TRACE (EvGpeDispatch); + /* Invoke global event handler if present */ + AcpiGpeCount++; + if (AcpiGbl_GlobalEventHandler) + { + AcpiGbl_GlobalEventHandler (ACPI_EVENT_TYPE_GPE, GpeDevice, + GpeNumber, AcpiGbl_GlobalEventHandlerContext); + } /* * If edge-triggered, clear the GPE status bit now. Note that @@ -655,58 +808,55 @@ AcpiEvGpeDispatch ( if (ACPI_FAILURE (Status)) { ACPI_EXCEPTION ((AE_INFO, Status, - "Unable to clear GPE[0x%2X]", GpeNumber)); + "Unable to clear GPE%02X", GpeNumber)); return_UINT32 (ACPI_INTERRUPT_NOT_HANDLED); } } /* - * Dispatch the GPE to either an installed handler, or the control method - * associated with this GPE (_Lxx or _Exx). If a handler exists, we invoke - * it and do not attempt to run the method. If there is neither a handler - * nor a method, we disable this GPE to prevent further such pointless - * events from firing. + * Always disable the GPE so that it does not keep firing before + * any asynchronous activity completes (either from the execution + * of a GPE method or an asynchronous GPE handler.) + * + * If there is no handler or method to run, just disable the + * GPE and leave it disabled permanently to prevent further such + * pointless events from firing. + */ + Status = AcpiHwLowSetGpe (GpeEventInfo, ACPI_GPE_DISABLE); + if (ACPI_FAILURE (Status)) + { + ACPI_EXCEPTION ((AE_INFO, Status, + "Unable to disable GPE%02X", GpeNumber)); + return_UINT32 (ACPI_INTERRUPT_NOT_HANDLED); + } + + /* + * Dispatch the GPE to either an installed handler or the control + * method associated with this GPE (_Lxx or _Exx). If a handler + * exists, we invoke it and do not attempt to run the method. + * If there is neither a handler nor a method, leave the GPE + * disabled. */ switch (GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) { case ACPI_GPE_DISPATCH_HANDLER: - /* - * Invoke the installed handler (at interrupt level) - * Ignore return status for now. - * TBD: leave GPE disabled on error? - */ - (void) GpeEventInfo->Dispatch.Handler->Address ( - GpeEventInfo->Dispatch.Handler->Context); + /* Invoke the installed handler (at interrupt level) */ + + ReturnValue = GpeEventInfo->Dispatch.Handler->Address ( + GpeDevice, GpeNumber, + GpeEventInfo->Dispatch.Handler->Context); - /* It is now safe to clear level-triggered events. */ + /* If requested, clear (if level-triggered) and reenable the GPE */ - if ((GpeEventInfo->Flags & ACPI_GPE_XRUPT_TYPE_MASK) == - ACPI_GPE_LEVEL_TRIGGERED) + if (ReturnValue & ACPI_REENABLE_GPE) { - Status = AcpiHwClearGpe (GpeEventInfo); - if (ACPI_FAILURE (Status)) - { - ACPI_EXCEPTION ((AE_INFO, Status, - "Unable to clear GPE[0x%2X]", GpeNumber)); - return_UINT32 (ACPI_INTERRUPT_NOT_HANDLED); - } + (void) AcpiEvFinishGpe (GpeEventInfo); } break; case ACPI_GPE_DISPATCH_METHOD: - - /* - * Disable the GPE, so it doesn't keep firing before the method has a - * chance to run (it runs asynchronously with interrupts enabled). - */ - Status = AcpiHwLowSetGpe (GpeEventInfo, ACPI_GPE_DISABLE); - if (ACPI_FAILURE (Status)) - { - ACPI_EXCEPTION ((AE_INFO, Status, - "Unable to disable GPE[0x%2X]", GpeNumber)); - return_UINT32 (ACPI_INTERRUPT_NOT_HANDLED); - } + case ACPI_GPE_DISPATCH_NOTIFY: /* * Execute the method associated with the GPE @@ -717,7 +867,7 @@ AcpiEvGpeDispatch ( if (ACPI_FAILURE (Status)) { ACPI_EXCEPTION ((AE_INFO, Status, - "Unable to queue handler for GPE[0x%2X] - event disabled", + "Unable to queue handler for GPE%02X - event disabled", GpeNumber)); } break; @@ -730,20 +880,8 @@ AcpiEvGpeDispatch ( * a GPE to be enabled if it has no handler or method. */ ACPI_ERROR ((AE_INFO, - "No handler or method for GPE[0x%2X], disabling event", + "No handler or method for GPE%02X, disabling event", GpeNumber)); - - /* - * Disable the GPE. The GPE will remain disabled until a handler - * is installed or ACPICA is restarted. - */ - Status = AcpiHwLowSetGpe (GpeEventInfo, ACPI_GPE_DISABLE); - if (ACPI_FAILURE (Status)) - { *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-src-vendor@FreeBSD.ORG Thu Dec 9 20:05:30 2010 Return-Path: Delivered-To: svn-src-vendor@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F32E106566C; Thu, 9 Dec 2010 20:05:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id E877E8FC23; Thu, 9 Dec 2010 20:05:29 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id oB9K5Ttt049325; Thu, 9 Dec 2010 20:05:29 GMT (envelope-from jkim@svn.freebsd.org) Received: (from jkim@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id oB9K5TfY049324; Thu, 9 Dec 2010 20:05:29 GMT (envelope-from jkim@svn.freebsd.org) Message-Id: <201012092005.oB9K5TfY049324@svn.freebsd.org> From: Jung-uk Kim Date: Thu, 9 Dec 2010 20:05:29 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-vendor@freebsd.org X-SVN-Group: vendor-sys MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r216332 - vendor-sys/acpica/20101209 X-BeenThere: svn-src-vendor@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the vendor work area tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:05:30 -0000 Author: jkim Date: Thu Dec 9 20:05:29 2010 New Revision: 216332 URL: http://svn.freebsd.org/changeset/base/216332 Log: Tag ACPICA 20101209. Added: vendor-sys/acpica/20101209/ - copied from r216331, vendor-sys/acpica/dist/