Pavel Machek wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/