Messages in this thread | | | Date | Thu, 27 Mar 2008 10:23:56 +0100 | From | Helge Hafting <> | Subject | Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot |
| |
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
| |