From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 23 07:43:32 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EB33106564A; Sat, 23 Oct 2010 07:43:32 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 068E58FC16; Sat, 23 Oct 2010 07:43:32 +0000 (UTC) Received: from home.bluelife.at (91.205.172.21) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 29E533; Sat, 23 Oct 2010 09:28:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Sat, 23 Oct 2010 07:28:25 +0000 From: Bernhard Froehlich To: Jung-uk Kim In-Reply-To: <201010191131.16732.jkim@FreeBSD.org> References: <201010181333.29143.jkim@FreeBSD.org> <08905cd48f28787b5b3d36a4e75fb793@bluelife.at> <201010191131.16732.jkim@FreeBSD.org> Message-ID: <23edca762eb8c4fb6306a607d5935564@bluelife.at> X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.4.2 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0204.4CC28E99.000F,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-acpi@FreeBSD.org, vbox@freebsd.org Subject: Re: VirtualBox: Compile problems with ACPICA 20101013 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: Sat, 23 Oct 2010 07:43:32 -0000 On Tue, 19 Oct 2010 11:31:00 -0400, Jung-uk Kim wrote: > On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: >> On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim >> >> wrote: >> > On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: >> >> Hi guys! >> >> >> >> VirtualBox has a compile problem with latest acpica. I've talked >> >> to the VirtualBox developers and they think it's an acpica >> >> problem which should be fixed upstream. Can we somehow file a >> >> bugreport or create a patch to fix that in acpica? >> > >> > Excerpt rom ACPI 4.0a: >> > >> > --------------------------------------------------- >> > Each Compatible Device ID must be either: >> > >> > o A valid HID value (a 32-bit compressed EISA type ID or a string >> > such as "ACPI0004"). >> > o A string that uses a bus-specific nomenclature. For example, >> > _CID can be used to specify the PCI ID. >> > --------------------------------------------------- >> > >> > Since it is not a valid HID value, you can only say it may be a >> > bus-specific nomenclature at best. However, it looks like an ISA >> > device to me and probably it is just a bogus ID. In fact, I >> > googled a bit and it only exists on some Intel Mac models, it >> > seems. You can just remove the entire _CID unless it is >> > absolutely necessary, which is very unlikely. :-) >> >> It very much looks like a regression. Right beyond that sentences >> they have a few examples in the ACPI 4.0a spec on page 201 that >> won't pass that check. I haven't looked at all the code so probably >> it's done somewhere completely different but if it is checked with >> that code then it will complain. >> >> ACPI 4.0a spec on page 201: >> --------------------------------------------------- >> o A valid HID value (a 32-bit compressed EISA type ID or a string >> such as "ACPI0004"). >> o A string that uses a bus-specific nomenclature. For example, >> _CID can be used to specify the PCI ID. >> >> "PCI\CC_ccss" >> "PCI\CC_ccsspp" >> "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr" >> .... >> --------------------------------------------------- >> >> Now with a deeper look at the commit from acpica [1] especially the >> second half. Before there was only an alphanumeric check for _HID >> but with that change it was put into a new function AnCheckId() >> that is called for both _HID and _CID and now wants both to be >> alphanumeric. That looks correct for _HID but it's too strict for >> _CID which is a string. Somewhere i've seen string is defined as a >> null-terminated ASCII string and no word about alphanumeric. >> >> [1] >> http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b5389e > > Yes, I am aware of the issue. My point was _CID may be pointless for > *VirtualBox* and it can be removed. I am just trying to figure out who is wrong and try to fix it there if possible. So do you agree that this is a acpica regression? Vbox guys say that removing it is not a good idea because it will "break things" but I don't know what it is used for so I cannot test it. -- Bernhard Froehlich http://www.bluelife.at/