From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 23 21:44:42 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11DBF16A41F; Fri, 23 Dec 2005 21:44:42 +0000 (GMT) (envelope-from groot@kde.org) Received: from multi.science.ru.nl (multi.science.ru.nl [131.174.16.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E37A43D68; Fri, 23 Dec 2005 21:44:40 +0000 (GMT) (envelope-from groot@kde.org) Received: from [83.116.148.63] (helo=[10.0.0.155]) (authen=adridg) by multi.science.ru.nl (8.13.5/5.7) with ESMTP id jBNLiVLe013846; Fri, 23 Dec 2005 22:44:31 +0100 (MET) From: Adriaan de Groot To: freebsd-acpi@freebsd.org Date: Fri, 23 Dec 2005 22:44:36 +0100 User-Agent: KMail/1.8.2 References: <200512221155.04352.groot@kde.org> In-Reply-To: <200512221155.04352.groot@kde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512232244.37363.groot@kde.org> X-Spam-Score: -0.276 () BAYES_40 X-Scanned-By: MIMEDefang 2.48 on 131.174.16.159 Cc: freebsd-amd64@freebsd.org Subject: Re: Bad characters in Asus A8N-VM CSM X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 21:44:42 -0000 On Thursday 22 December 2005 11:55, Adriaan de Groot wrote: > I just picked up an Asus A8N-VM CSM motherboard. It's a nForce 430 + GFor= ge > 6150 integrated mini-ATX job, amd64, very 1337 and new. That means trouble > :) I knew that when buying it, and know now that it really needs work to > get it working at all. > > ACPI-0397: *** Error: NSSearchAndEnter: Bad character in ACPI Name: > 43035350 ACPI-0381: *** Error: Looking up [0x43035350] (NON-ASCII) > in namespace, AE_BAD_CHARACTER [Following up on myself, for documentation purposes, and CCing -amd64 to wa= rn=20 off potential users there as well.] Well, an instructive but unproductive evening yields the following: 1) Default BIOS (rev. 0403) and FBSD 5.1 amd64 boots, produces ACPI warning= =20 messages above and works normally (no NIC, no SATA tried). 2) Newest BIOS (rev. 0506) and FBSD 5.1 amd64 boots and then page faults in= =20 kernel mode in vm_pageq_enqueue right after GEOM adds ad0. ACPI warning is= =20 still there. 3) I didn't try 6-STABLE with the newest BIOS, since having busted ACPI the= re=20 means you can't get _anything_ done. =46rom the booted 5.1 environment I got an ACPI dump and after hacking utmi= sc.c=20 in contrib/dev/acpica to accept a broken character 0x03, I got a disassembl= y.=20 The bad character is in 0x43035350, which from the looks of the IASL should= =20 have been PSSC (0x43535350) but somehow isn't. It's in one of the processor= =20 sections (the other has a Name(PSSC, 0x0A) ). Elsewhere in the IASL there's some undefined symbols ending in _HFZF (sorry= , I=20 don't have the machine under scrutiny on or functional at this very moment)= ,=20 which I suppose is semi-normal, and then a totally weird-ass Return( While(Local1) { ... }) This chokes the compiler, of course. I suspect that it should read Return(0x00) While (Local1) ... or so, but this suggests yet more broken ACPI tables. Over in Linux land, http://www.nvnews.net/vbulletin/showthread.php?t=3D6059= 6=20 shows that with some effort and the latest of the latest everything, it is= =20 possible to get a functioning machine. If I can create a barely legal ASL=20 file that compiles, I'll have to try out what's described in "11.16.5.3=20 Overriding the Default AML " of the handbook. Until then (or someone more competent than myself deals with the issues), I= 'd=20 suggest avoiding this board entirely. [ade]