Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: acpicpu(4) strangeness

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

            Package (0x06)
                0x00000258,                     <- 600 MHz

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

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.

Home | Main Index | Thread Index | Old Index