acpi_cpu: binding processor object to pcpu struct.
nate at root.org
Mon Dec 1 11:53:05 PST 2008
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.
>> 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.
More information about the freebsd-acpi