Re: Kexec for v2.5.47 (test feedback)

[Eric W. Biederman]

Andy Pfiffer <[e-mail]> writes:

> On Mon, 2002-11-11 at 23:22, Eric W. Biederman wrote:
> > > On Mon, 2002-11-11 at 10:15, Eric W. Biederman wrote:
> > > > kexec is a set of system calls that allows you to load another kernel
> > > > from the currently executing Linux kernel.
> > > 
> 
> > > Results on my usual problem machine:
> > > 
> > > # ./kexec-1.5 ./kexec_test-1.5
> > > Shutting down devices
> > > Debug: sleeping function called from illegal context at
> include/asm/semaphore.h9
> 
> > > 
> > > Call Trace: [<c011a698>] [<c0216193>] [<c012b165>] [<c0132dec>] [<c0140357>
> > 
> > Hmm. I wonder what is doing that.  Do you have the semaphore problem on a
> normal reboot?
> 
> 
> No clue as of yet.  I do not see this information during a normal
> reboot.

Doh.   I must compile that debugging in when I am testing.  I introduced a spin lock,
and then I called a function that might sleep...  Though I am puzzled by what
in the device_shutdown and reboot notifier path is actually sleeping
but that is academic.

Next version will use a semaphore to be polite.
I should have asked where those addresses mapped to in your
system.map.

Anyway one of the reasons I grumble about splitting it, more global
variables that have to be protected, and more chances to fumble
something.  Oh, well.

> > > Starting new kernel
> > > 
> > > kexec_test 1.5 starting...
> > > eax: 0E1FB007 ebx: 00001078 ecx: 00000000 edx: 00000000
> > > esi: 00000000 edi: 00000000 esp: 00000000 ebp: 00000000
> > > idt: 00000000 C0000000
> > > gdt: 00000000 C0000000
> > > Switching descriptors.
> > > Descriptors changed.
> > > Legacy pic setup.
> > > In real mode.
> > > <hang>
> > 
> > Yep it works until it runs into your apics that are not shutdown.
> > That looks like one of the next things to tackle.
> 
> I used the linux-2.5.44.x86kexec-hwfixes.diff (it applied cleanly to
> pure 2.5.47 + kexec); I'll try your updated version soon if there are
> any major differences.

I don't think there is anything significant.

> > The challenge is with the apic shutdown is that currently the apics are not
> > in the device tree so that needs to happen before I can submit a good version
> > for 2.5.x
> >  
> > 
> > > Confirming some earlier suspicions:
> > > CONFIG_SMP=y
> > > CONFIG_X86_GOOD_APIC=y
> > > CONFIG_X86_LOCAL_APIC=y
> > > CONFIG_X86_IO_APIC=y
> > > 
> > > Last time I tried to run a UP kernel (and no APIC support) on this system
> > > it wasn't pretty.  I'll add that to my list of combinations to try.
> 
> On this same system, I reconfigured and tried this:
>     # CONFIG_SMP is not set
>     CONFIG_X86_GOOD_APIC=y
>     # CONFIG_X86_UP_APIC is not set
>     # CONFIG_X86_LOCAL_APIC is not set
>     # CONFIG_X86_IO_APIC is not set
>     
> None of the "ordinary" APIC initialization messages were output during
> the regular BIOS->LILO boot of this kernel.
> 
> So, does this information suggest looking somewhere other than APIC
> shutdown?

I am not certain.  All that is certain is there is an unhandled
interrupt.  

Anyway the next step will be to enter the Linux kernel in 32bit mode
so I can avoid the whole mess of getting the BIOS working again.  That
should avoid most of these complications as I will be able to skip
the whole step of enabling interrupts.

Eric