Re: Kexec for v2.5.47 (test feedback)

From: Eric W. Biederman (ebiederm@xmission.com)
Date: Tue Nov 12 2002 - 23:16:42 EST


Andy Pfiffer <andyp@osdl.org> 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

-
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/



This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:28 EST