From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 27 21:39:46 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 0B55016A41F; Thu, 27 Oct 2005 21:39:46 +0000 (GMT) (envelope-from mathieu_prevot@yahoo.fr) Received: from relay-am.club-internet.fr (relay-am.club-internet.fr [194.158.104.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B52343D45; Thu, 27 Oct 2005 21:39:45 +0000 (GMT) (envelope-from mathieu_prevot@yahoo.fr) Received: from [192.168.0.3] (d02v-213-44-152-175.d4.club-internet.fr [213.44.152.175]) by relay-am.club-internet.fr (Postfix) with ESMTP id 44F8F25612; Thu, 27 Oct 2005 23:39:44 +0200 (CEST) In-Reply-To: <435928CA.1010305@root.org> References: <971FCB6690CD0E4898387DBF7552B90E0323D7B6@orsmsx403.amr.corp.intel.com> <7B5FE857-16A8-4369-B577-3F3190B56840@yahoo.fr> <200510210954.58860.jhb@freebsd.org> <435928CA.1010305@root.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <55E0CA58-AC1E-48E4-A4D0-DDC5829D3690@yahoo.fr> Content-Transfer-Encoding: quoted-printable From: Mathieu Prevot Date: Thu, 27 Oct 2005 23:39:33 +0200 To: Nate Lawson X-Mailer: Apple Mail (2.734) Cc: freebsd-acpi@freebsd.org 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: Thu, 27 Oct 2005 21:39:46 -0000 Le 21 oct. 05 =E0 19:43, Nate Lawson a =E9crit : > John Baldwin wrote: > >> On Friday 21 October 2005 02:38 am, Mathieu Prevot wrote: >> >>>> I think that the generation of the OS for Amd64 needs to set this >>>> define: >>>> >>>> #define ACPI_MISALIGNED_TRANSFERS >>>> >>>> I will look into doing this automatically in the actypes.h header >>>> >>> >>> To confirm, the same output on the same system but with >>> 6.0RC1i386GENERIC: >>> >> I think Robert's point is a patch like the following hack would =20 >> shut up the warnings: >> Index: actypes.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /usr/cvs/src/sys/contrib/dev/acpica/actypes.h,v >> retrieving revision 1.1.1.29 >> diff -u -r1.1.1.29 actypes.h >> --- actypes.h 1 Dec 2004 23:13:39 -0000 1.1.1.29 >> +++ actypes.h 21 Oct 2005 13:52:22 -0000 >> @@ -194,6 +194,9 @@ >> typedef UINT64 ACPI_SIZE; >> #define ALIGNED_ADDRESS_BOUNDARY 0x00000008 /* No =20 >> hardware alignment support in IA64 */ >> +#ifdef __amd64__ >> +#define ACPI_MISALIGNED_TRANSFERS >> +#endif >> #define ACPI_USE_NATIVE_DIVIDE /* Native =20= >> 64-bit integer support */ >> #define ACPI_MAX_PTR ACPI_UINT64_MAX >> #define ACPI_SIZE_MAX ACPI_UINT64_MAX >> The problem is that currently the actypes.h header assumes that =20 >> the only 64-bit platform it runs on is IA-64, but it also runs on =20 >> amd64 and amd64 allows for unaligned accesses just like i386. >> I'm not sure if ALIGNED_ADDRESS_BOUNDARY should be 0x4 for amd64 =20 >> either, probably not though. >> > > If that works, can you commit it to something off the vendor =20 > branch? (Perhaps acfreebsd.h or something?) > > --=20 > Nate I simply added #define ACPI_MISALIGNED_TRANSFERS in /usr/src/sys/amd64/include/acpica_machdep.h so the intel actypes.h =20= is preserved. Maybe it is simpler than touching the Robert's / Intel's code. Is it =20 right ? If so, someone have to commit it on the CVS sources. Can you do it =20 before the release ? --MP