Dave Hansen wrote:
On Fri, 2008-03-21 at 14:17 +0100, Pavel Machek wrote:
So what's the reason for pushing for this insanely-early workaround in the
first place, instead of letting user-space do something like
cat my-dsdt-image > /proc/sys/acpi/DSDT
or whatever at runtime?
You have interpretted code runing (AML), and you want to replace it
with different code?
Akin to changing from one kernel to different during runtime?
Heh. That gave me an idea.
Can we use kexec for this? Let's say you get as far in boot as the
initrd and realize that you're running on one of these screwed up
systems. Can you stick the new DSDT somewhere known (and safe) in
memory, and kexec yourself back to the beginning of the kernel boot?
When you boot up the second time, you have the new, shiny DSDT there
which is, of course, used instead of the bogus BIOS one.
I see a problem here.
This could work. And if it is successful, the "kexec reboot around
busted hw"-trick
is used for other stuff as well.
So your broken machine reboots with some fix, then it reboots with the
custom DSDT. Is the previous fix preserved? Then a third problem is hit,
another kexec reboot. Is the first fix _and_ the custom DSDT
preserved on this reboot? Or do we get an infinite sequence of reboots,
alternating between a couple of completely unrelated fixes for bad
hw/bios...
Once there is more than one fix utilizing this trick, some "protocol" for
managing a string of kexec fixes might become necessary.
Helge Hafting
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
