Re: CVS commit: src/sys/dev/acpi

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jul 19,  9:32am, jruohonen%iki.fi@localhost (Jukka Ruohonen) wrote:
-- Subject: Re: CVS commit: src/sys/dev/acpi

| On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote:
| > 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
| 
| ACPI is silent about the CPU IDs in the processor object. In all three
| systems where I tested this the range started from 0. So now these systems
| hit the included assertion:
| 
|       static cpuid_t
|       acpicpu_id(uint32_t id)
|       {
|               CPU_INFO_ITERATOR cii;
|               struct cpu_info *ci;
| 
|               KASSERT(id != 0);
| 
| This is a known issue. No clean solution exist in any implementation I am
| aware of.  The IDs may also vary between the processor object and MADT.

That's why I added the assertion :-) so that it would be obvious when
that fails.

| In essence, however, this is not so much of an issue because the essential
| information should be uniform across CPUs.
| 
| > 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
| >    attaching the unmatched ones, make the match fail. Do we want to
| >    attach and do nothing instead?
| 
| Can I see the DSDT of this laptop (see acpidump(8))? Due to the reasons with
| the identification, I think we might want to attach them all nevertheless.

I will send it to you tonight when I get home. I am leaning towards attaching
all of them too.

christos