Messages in this thread | | | From | Andi Kleen <> | Subject | Re: 2.6.18-rc6-mm1: GPF loop on early boot | Date | Sun, 10 Sep 2006 15:55:51 +0200 |
| |
On Sunday 10 September 2006 15:26, Ingo Molnar wrote: > * Andi Kleen <ak@suse.de> wrote: > > > Basically, non-atomic setup of basic architecture state _is_ going to > > > be a nightmare, lockdep or not, especially if it uses common > > > infrastructure like 'current', spin_lock() or even something as simple > > > as C functions. (for example the stack-footprint tracer was once hit by > > > this weakness of the x86_64 code) > > > > I disagree with that. The nightmare is putting stuff that needs so > > much infrastructure into the most basic operations. > > ugh, "having a working current" is "so much infrastructure" ??
Together with stacktrace the infrastructure needed is quite considerable.
> > the i686 PDA patches introduce tons of early_current() uses. While i > like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is > too fragile in my opinion, and it will regularly hit instrumenting > patches.
Or the instrumentation patches just always need to check some global variable. Maybe system_state could be extended or something.
> > Perhaps the early setup code (if we really want to do it all in C)
Sorry but moving it into assembler would be just crazy.
> should be moved into 32-bit early boot userspace code (like > compressed/misc.c) and it will thus not depend on any kernel > infrastructure.
Ok I guess it would make sense to add a i386_start_kernel to i386 and initialize the boot PDA there. I would also move early_cpu_init into there because that also avoids quite some mess later.
-Andi - 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/
| |