Re: acpicpu(4) strangeness

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Fri, Jan 28, 2011 at 09:18:14AM -0800, Dustin Marquess wrote:
> So I managed to pull the ACPI data off of that one.  I'm hoping that
> being a dom0, that the Xen hypervisor hopefully didn't fiddle with
> things?  If so, I'll see if I can manage to get it booted clean.
> Attached is the output.

Thanks, those were just fine.

The tables confirm that this is indeed a BIOS bug:

        Name (_PSS, Package (0x02)
        {
            Package (0x06)
            {
                0x00000384,                     <- 900 MHz
                0x00007918,
                0x0000000A,
                0x0000000A,  
                0x00000920,
                0x00000920
            }, 

            Package (0x06)
            {
                0x00000258,                     <- 600 MHz
                0x000032C8,
                0x0000000A,
                0x0000000A, 
                0x00000616,
                0x00000616  
            }
        })

So I doubt whether this board works reliably in Linux -- or even Windows.

> Wouldn't be surprised.  While I'm on the latest BIOS release,
> Supermicro basically stopped issuing updates for the board.

This is unfortunate. And unfortunate also for a vendor like Super Micro,
given that in all likelihood this does not work for Red Hat etc. customers
either.

Generally, there are couple of general options here:

  1. Add a quirk for this board and prevent acpicpu(4) from loading.

        For this, can you install sysutils/dmidecode and send the output?

  2. Try to do the same guessing as the old EST. This would be a hack.

As for (1), some restructuring is required, but we can resort to the old
CPU PM facilities if a broken BIOS is detected. Nota bene: these BIOS bugs
are very rare; by default for instance Linux relies currently only on ACPI
for CPU frequency scaling.

- Jukka.