From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 28 20:18:13 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA63A16A41F; Fri, 28 Oct 2005 20:18:13 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A7943D4C; Fri, 28 Oct 2005 20:18:13 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j9SKIBxq003697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2005 13:18:12 -0700 Message-ID: <4362877B.8020004@root.org> Date: Fri, 28 Oct 2005 13:18:03 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Moore, Robert" References: <971FCB6690CD0E4898387DBF7552B90E033A99FE@orsmsx403.amr.corp.intel.com> In-Reply-To: <971FCB6690CD0E4898387DBF7552B90E033A99FE@orsmsx403.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Jung-uk Kim , Mathieu Prevot Subject: Re: ACPI errors on amd64 (sempron) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 20:18:14 -0000 Moore, Robert wrote: >>>>This looks to me >>>>like the pci_link code is pointing the interrupt source at the >>>>wrong part of the resource descriptor. Perhaps it is not >>>>incrementing the pointer correctly for 64-bit arches. > > > I would be interested in knowing if FreeBSD is using the ACPI CA > resource manager code, or is parsing the raw AML resource template > buffers on its own. > > One advantage to using the resource manager is that the resources are > converted to a format that is easier for upper code to analyze (and > therefore less prone to error.) We use our own (acpi_resource.c): while (curr < last) { res = (ACPI_RESOURCE *)curr; curr += res->Length; /* Handle the individual resource types */ switch(res->Id) { case ACPI_RSTYPE_END_TAG: ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "EndTag\n")); curr = last; break; case ACPI_RSTYPE_FIXED_IO: if (res->Data.FixedIo.RangeLength <= 0) break; ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "FixedIo 0x%x/%d\n", res->Data.FixedIo.BaseAddress, res->Data.FixedIo.RangeLength)); set->set_ioport(dev, context, res->Data.FixedIo.BaseAddress, res->Data.FixedIo.RangeLength); break; I haven't looked at the acpi ca resource manager but it will have to match the rest of our rman system to be a viable replacement. -- Nate