[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)
0x00000384, <- 900 MHz
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.
Main Index |
Thread Index |