Re: [Fastboot] [CFT] kexec syscall for 2.5.43 (linux booting linux)

[ebiederm@xmission.com (Eric W. Biederman)]

ebiederm@xmission.com (Eric W. Biederman) writes:

> Rob Landley <landley@trommello.org> writes:
> 
> > On Tuesday 22 October 2002 03:33, Eric W. Biederman wrote:
> > 
> > > j < Printed from the second callback in setup.S, just before the
> > > kernel decompresser is run >
> > >
> > >
> > > I have a very strange node that makes it all of the way to 'j' before
> > > rebooting. The concept that something is dying in protected mode will all
> > > of the interrupts disabled is so novel that I really don't know what to
> > > make of it, yet.
> > 
> > It would almost have to be the MMU.  Any way to dump the page tables?
> 
> I don't know yet.  I need to find a way to install some additional hooks
> at run time so I can narrow down where the failure is occuring.  I
> will have to look, but I should be able to set up an interrupt
> descriptor table and single step through the code.  

In the process of setting up hooks, I have run across a very interesting
data point.  If I load %ds, %es, %ss in my hook the problem goes away.
But I must load all 3.

Given that the code sequence that is executed if my hook is not run is:

	cld
	cli
	movl $(__KERNEL_DS),%eax
	movl %eax,%ds
	movl %eax,%es
	movl %eax,%fs
	movl %eax,%gs

	lss stack_start,%esp

I am rather confused.  I am not changing the gdt or anything like that so it
appears I may have found a way to tickle a processor errata.

Anyway Andy if you have a second please try kexec-tools 1.3 and see what
happens when you pass it the debug option.  I am really curious if your lockup
is anywhere near mine.  I doubt it as I am running on a P4.  But it appears
you never know what the problems will look like until you test them.

Eric