Pavel Machek wrote:
Hi!
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.
It costs you some bootup time, but we're talking about working around
really busted hardware here.
Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
with new dsdt.
Turning off acpi is not exactly easy, but specs describe how to do
it...
Why do you think it's necessary to turn off acpi mode? What will not
work if we keep it on all the time?
BTW, let me summarize my understanding of the kexec approach:
* the userspace write the new DSDT (cat my-dsdt-image >
/sys/firmware/acpi/tables/DSDT)
* the kernel don't use this DSDT directly but keeps it somewhere warm
and fuzzy in the RAM
* userspace does a kexec
* the new kernel boots and at some (early) point, dsdt_override() is
called. It detects that the special place in the RAM for a new DSDT is
used. It provides this pointer to ACPI as the new place to read the DSDT.
Dave, am I correctly understanding the scenario you had in mind?
I have pratically no knowledge of kexec. Is there a documented way to
pass big chunk of data from one kernel to another one? How can I do that?
Eric
--
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
