Dealing with faulty BIOS table
Hey folks,
I have an HP pavilion (ze4502us) with broken PST tables. I'll mail the dmidecode results directly to Dave per the instructions in kernel messages. If anyone wants me to post them to the list, let me know and I'll do it.
Is there a blueprint for how to deal with broken PST tables given their prevalence? I know that the ideal solution is for vendors to ship machines with the correct data in the BIOS. I was thinking of something similar to the blacklist method in ACPI. I am not really sure how you'd fingerprint a broken laptop. To identify mine as a broken machine, I'd use logic like...
// PST tables are known broken tables of a ze4502us... if (cpu has powernow capabilities) AND
(no PST tables match the cpuid) AND
(cpuid is cpuid of a ze4502us) AND
(the # of PST tables matches the # in a ze4502us) AND (signature of ea. PST table matches a ze4502us)
The code could suggest (via printk) what the problem is (you have a known broken BIOS) and could propose a fix (it probably could be fixed by selecting one of the PSTs using a fake cpuid) during regular bootup. Similar to ACPI, there could be a kernel parameter (like ACPI=force) passed during the boot process to try fix broken PST tables instead of merely suggesting the solution. Obviously "use at your own risk" documentation would accompany the solution.
Is this worth doing? Is this the right way to do it? I don't know if the prevalence of broken PST files justifies adding a separate file to fix them. However, I think many users would like rather pass a kernel parameter to overcome their broken BIOS rather than recompile their kernel with a one line hack. I think you'd probably want to break it out the logic into a separate file to avoid kludge.
- Drew
Hi,
Quoted 3 lines
Is there a blueprint for how to deal with broken PST tables given their prevalence? I know that the ideal solution is for vendors to ship machines with the correct data in the BIOS.
There's some discussion of the next-to-ideal solution to use the information in the ACPI tables instead of the PST tables when these are broken. Window$ uses the info in the ACPI tables, so we should be able to solve many issues this way.
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 10 lines · Dominik Brodowski
Hi,
Quoted 3 lines
Is there a blueprint for how to deal with broken PST tables given their prevalence? I know that the ideal solution is for vendors to ship machines with the correct data in the BIOS.
There's some discussion of the next-to-ideal solution to use the information in the ACPI tables instead of the PST tables when these are broken. Window$ uses the info in the ACPI tables, so we should be able to solve many issues this way.
FYI: I'm planing to introduce a kind of 'merge' of the two infos, also there may be soon a way to override the table via sysfs if really needed.
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.