From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 1 19:53:05 2008 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 C978A1065673; Mon, 1 Dec 2008 19:53:05 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi025.prodigy.net (nlpi025.sbcis.sbc.com [207.115.36.54]) by mx1.freebsd.org (Postfix) with ESMTP id 96F788FC1B; Mon, 1 Dec 2008 19:53:05 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-9-199.dsl.snfc21.pacbell.net [71.139.9.199]) (authenticated bits=0) by nlpi025.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id mB1Jr337002311; Mon, 1 Dec 2008 13:53:04 -0600 Message-ID: <493440A2.7070108@root.org> Date: Mon, 01 Dec 2008 11:53:06 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: John Baldwin References: <200811251835.mAPIZFIC002676@sana.init-main.com> <200812011212.45582.jhb@freebsd.org> In-Reply-To: <200812011212.45582.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: binding processor object to pcpu struct. 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: Mon, 01 Dec 2008 19:53:05 -0000 John Baldwin wrote: > On Tuesday 25 November 2008 01:35:15 pm Takanori Watanabe wrote: >> In my box, processor does not binded properly to ACPI object, >> so I wrote the code as follows. >> comment? >> >> I'm afraid system pcpu unit number and cpu device instance number >> may inconsistent, but without this change, ACPI namespace and >> pcpu struct does not match. > > Hmm, so is the issue that the acpi_cpu driver expects processor objects to be > listed in the same order in _PR_ as in the MADT? If so, then that is > probably a false assumption. The MADT should always have ACPI IDs for non-UP > systems. OTOH, the comment in the code in acpi_cpu_attach() indicates that > some boxes do not use the same ProcID value in processor objects and MADT > entries and your patch breaks that case. I will look at the spec to see how > this is supposed to work. It's good that you are concerned about not breaking the existing code. I had to rework it a lot to handle various different implementations when I first wrote it. There was always one BIOS that was slightly different, and I think some were even mutually incompatible with each other. My memory is fuzzy, but you are right that the MADT id does not always match the Processor object id. I believe some of them had duplicate IDs. I think I tried to do a fallback, where we would use the Processor id if they all matched, otherwise just do strict ordering. The cvs logs should have the details. I ended up thinking that Windows probably just used the order of Processor objects (or mptable enumeration) and ignored the id field completely. That would be the only way so many differently broken implementations would work. -- Nate