On 08.01.2009 17:52, Marc Jones wrote:
On Wed, Jan 7, 2009 at 7:34 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.01.2009 17:47, Marc Jones wrote:
On Mon, Jan 5, 2009 at 6:36 PM, Bao, Zheng Zheng.Bao@amd.com wrote:
If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
Acked-by: zheng bao zheng.bao@amd.com
I also fixed this in acpi_tables.c Pistachio.
r 3847
Thanks! The Linux kernel powernow-k8 driver doesn't complain anymore, but now the machine will lock up or reboot once I put some load on it. Blacklisting the powernow-k8 driver avoids the issue, but that makes frequency scaling impossible.
AFAICS the standard cpu frequency governor is ondemand and it scales the frequency down from 1800 MHz to 1000 Mhz. That seems to work fine, but scaling up again will cause the lockups/reboots. By the way, coreboot reports a BIST failure after such reboots. Not nice.
Rudolf's PowerNow tables had entries for 1000/1600/1800 MHz. The proprietary BIOS and coreboot only have entries for 1000/1800 MHz. According to the docs, scaling from 1000 MHz to 1800 MHz can't be done in a single step. Is that maybe the reason for the problems I'm seeing?
Can you dump the current tables or can you not get that far before a crash? The entries are end points and the driver takes care of the stepping that needs to be done to get to those points. We need to check that the table generated the correct vid setting for the fid. It is well described in the bkdg section 10.6.
I managed to boot fine with the proprietary BIOS, blacklisted the k8-powernow driver and rebooted with coreboot.
Attached are the following files: _PSS with coreboot (crash) _PSS with proprietary BIOS (ok)
If I combine the _PSS from the proprietary BIOS with the other tables from coreboot, the machine does not crash. I'll try to narrow it down further.
Regards, Carl-Daniel