Date: Mon, 01 Dec 2008 11:53:06 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: binding processor object to pcpu struct. Message-ID: <493440A2.7070108@root.org> In-Reply-To: <200812011212.45582.jhb@freebsd.org> References: <200811251835.mAPIZFIC002676@sana.init-main.com> <200812011212.45582.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?493440A2.7070108>