kexec --real-mode

kexec --real-mode

[Bernhard Walle]

Hi,

did anybody try the --real-mode option with current release? I tried it
on two machines, and on one machine it just reboots, on the other
machine it hangs.

I use

    kexec --serial=0x03f8 --serial-baud=57600 --console-serial \
    -l /boot/vmlinuz --initrd=/boot/initrd
    --append="root=/dev/sda7 console=ttyS0,57600" \
    -d

on serial console, it gives me

    Starting new kernel
    I'm in purgatory
    a
    b
    c
    d
    e
    f
    g
    h

So it gets until

    linux-entry16.S:

    191         movw    %cs, %ax
    192         movw    %ax, %ds
    193
    194 DEBUG_CHAR('h')
    195         /* Load the registers */
    196         movl    eax - entry16, %eax
    197         movl    ebx - entry16, %ebx
    198         movl    ecx - entry16, %ecx
    199         movl    edx - entry16, %edx

Any advise so far? :)


        Bernhard



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Jamey Sharp]

On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle <bwalle@suse.de> wrote:
> did anybody try the --real-mode option with current release? I tried
> it on two machines, and on one machine it just reboots, on the other
> machine it hangs.

I think you're experiencing a bug that I just proposed a patch for. :-)
You can confirm that: try adding the "--debug" option to your kexec
call. If that works correctly, then I think you'll find that the patch
in "[PATCH 2/9] Fix copy-paste bug: entry16 does not start at
entry16_debug" will solve your problem. That's archived here:

http://lists.infradead.org/pipermail/kexec/2008-April/001581.html

Jamey

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Bernhard Walle]

* Jamey Sharp [2008-04-22 16:44]:
>
> On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle <bwalle@suse.de> wrote:
> > did anybody try the --real-mode option with current release? I tried
> > it on two machines, and on one machine it just reboots, on the other
> > machine it hangs.
> 
> I think you're experiencing a bug that I just proposed a patch for. :-)
> You can confirm that: try adding the "--debug" option to your kexec
> call. If that works correctly, then I think you'll find that the patch
> in "[PATCH 2/9] Fix copy-paste bug: entry16 does not start at
> entry16_debug" will solve your problem. That's archived here:
> 
> http://lists.infradead.org/pipermail/kexec/2008-April/001581.html

No, I used --debug already.


	Bernhard



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Eric W. Biederman]

Bernhard Walle <bwalle@suse.de> writes:

> * Jamey Sharp [2008-04-22 16:44]:
>>
>> On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle <bwalle@suse.de> wrote:
>> > did anybody try the --real-mode option with current release? I tried
>> > it on two machines, and on one machine it just reboots, on the other
>> > machine it hangs.
>> 
>> I think you're experiencing a bug that I just proposed a patch for. :-)
>> You can confirm that: try adding the "--debug" option to your kexec
>> call. If that works correctly, then I think you'll find that the patch
>> in "[PATCH 2/9] Fix copy-paste bug: entry16 does not start at
>> entry16_debug" will solve your problem. That's archived here:
>> 
>> http://lists.infradead.org/pipermail/kexec/2008-April/001581.html
>
> No, I used --debug already.

If this used to work when booting older kernels on your hardware.
Jamey's patch 3/9 might help.

Otherwise if this is the first time you are trying it you may
simply have encountered the reason that --real-mode is not the default.
BIOS can get really strange after the kernel has been running.

When I had that the default I only had around a 50% success rate or
something like that.

You might try booting kexec_test and see where that puts you.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Bernhard Walle]

Hi,

* Eric W. Biederman [2008-04-23 07:00]:
> Bernhard Walle <bwalle@suse.de> writes:
> > * Jamey Sharp [2008-04-22 16:44]:
> >>
> >> On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle <bwalle@suse.de> wrote:
> >> > did anybody try the --real-mode option with current release? I tried
> >> > it on two machines, and on one machine it just reboots, on the other
> >> > machine it hangs.
> >> 
> >> I think you're experiencing a bug that I just proposed a patch for. :-)
> >> You can confirm that: try adding the "--debug" option to your kexec
> >> call. If that works correctly, then I think you'll find that the patch
> >> in "[PATCH 2/9] Fix copy-paste bug: entry16 does not start at
> >> entry16_debug" will solve your problem. That's archived here:
> >> 
> >> http://lists.infradead.org/pipermail/kexec/2008-April/001581.html
> >
> > No, I used --debug already.
> 
> If this used to work when booting older kernels on your hardware.
> Jamey's patch 3/9 might help.

Well, now it goes until DEBUG_CHAR('j'). But the kernel doesn't boot.

> Otherwise if this is the first time you are trying it you may
> simply have encountered the reason that --real-mode is not the default.
> BIOS can get really strange after the kernel has been running.

That might be the case. Thanks for the information.

> You might try booting kexec_test and see where that puts you.

But that's ELF and not bzImage.


	Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Eric W. Biederman]

Bernhard Walle <bwalle@suse.de> writes:

> Hi,
>
> * Eric W. Biederman [2008-04-23 07:00]:
>> Bernhard Walle <bwalle@suse.de> writes:
>> > * Jamey Sharp [2008-04-22 16:44]:
>> >>
>> >> On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle <bwalle@suse.de> wrote:
>> >> > did anybody try the --real-mode option with current release? I tried
>> >> > it on two machines, and on one machine it just reboots, on the other
>> >> > machine it hangs.
>> >> 
>> >> I think you're experiencing a bug that I just proposed a patch for. :-)
>> >> You can confirm that: try adding the "--debug" option to your kexec
>> >> call. If that works correctly, then I think you'll find that the patch
>> >> in "[PATCH 2/9] Fix copy-paste bug: entry16 does not start at
>> >> entry16_debug" will solve your problem. That's archived here:
>> >> 
>> >> http://lists.infradead.org/pipermail/kexec/2008-April/001581.html
>> >
>> > No, I used --debug already.
>> 
>> If this used to work when booting older kernels on your hardware.
>> Jamey's patch 3/9 might help.
>
> Well, now it goes until DEBUG_CHAR('j'). But the kernel doesn't boot.
>
>> Otherwise if this is the first time you are trying it you may
>> simply have encountered the reason that --real-mode is not the default.
>> BIOS can get really strange after the kernel has been running.

> That might be the case. Thanks for the information.
>
>> You might try booting kexec_test and see where that puts you.
>
> But that's ELF and not bzImage.

It is a different code path.  It is designed to exercise the 16bit BIOS
calls that the kernel uses with a lot of serial port debugging
so we can see if that is the problem.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Bernhard Walle]

* Eric W. Biederman [2008-04-28 10:55]:
> 
> It is a different code path.  It is designed to exercise the 16bit BIOS
> calls that the kernel uses with a lot of serial port debugging
> so we can see if that is the problem.

Well, that gives me 
------------------------------------------------------------
I'm in purgatory
kexec_test 20080324 starting...
eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000
esi: 00000000 edi: 00000000 esp: 00008FF8 ebp: 00000000
idt: 00000000 00000000
gdt: 0000006F 00005BA0
Switching descriptors.
Descriptors changed.
Legacy pic setup.
In real mode.
Interrupts enabled.
Base memory size: 0276
A20 disabled.
E820 Memory Map.
000000000009D800 @ 0000000000000000 type: 00000001
0000000000002800 @ 000
------------------------------------------------------------

Yes, the output stops here. Don't know why ...



        Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Eric W. Biederman]

Bernhard Walle <bwalle@suse.de> writes:

> * Eric W. Biederman [2008-04-28 10:55]:
>> 
>> It is a different code path.  It is designed to exercise the 16bit BIOS
>> calls that the kernel uses with a lot of serial port debugging
>> so we can see if that is the problem.
>
> Well, that gives me 
> ------------------------------------------------------------
> I'm in purgatory
> kexec_test 20080324 starting...
> eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000
> esi: 00000000 edi: 00000000 esp: 00008FF8 ebp: 00000000
> idt: 00000000 00000000
> gdt: 0000006F 00005BA0
> Switching descriptors.
> Descriptors changed.
> Legacy pic setup.
> In real mode.
> Interrupts enabled.
> Base memory size: 0276
> A20 disabled.
> E820 Memory Map.
> 000000000009D800 @ 0000000000000000 type: 00000001
> 0000000000002800 @ 000
> ------------------------------------------------------------
>
> Yes, the output stops here. Don't know why ...

Ok.  I'm guessing that whatever it is immediately after
the e820 map dump causes the box to go south.

But this is a very good clue that your BIOS just can't
handle being run after the linux kernel has run at
this point.  Unfortunately this is common and why
the --real-mode switch has not been the default for several years.

What is your interest in getting the --real-mode option working at this
point?

After this point the debugging starts to get very laborious.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Bernhard Walle]

* Eric W. Biederman [2008-04-29 10:15]:
> 
> Ok.  I'm guessing that whatever it is immediately after
> the e820 map dump causes the box to go south.
> 
> But this is a very good clue that your BIOS just can't
> handle being run after the linux kernel has run at
> this point.  Unfortunately this is common and why
> the --real-mode switch has not been the default for several years.

Ok, thanks.

> What is your interest in getting the --real-mode option working at this
> point?

Well, the first reason was just interest.

The second reason that pointed me in that direction is that I saw that
kdump-booted kernels ignore the VGA parameter [e.g. 791] (which is
quite clear since the video mode is not set in the boot block, but that
can be easily patched) and also ignore the compiled-in VGA value (set
with rdev). Then I saw that this is not done in the real kernel but in
the 16 bit boot code which is of course only executed in real mode
booting (arch/x86/boot/video.c).

I know the 32-bit booted kernel takes the video mode from the running
kernel, but currently it's not possible to change the mode. Well, it's
not really important, it just would be nice.

The overall reason behind this is that we (SUSE) use kexec now for the
first reboot in our distribution setup which works quite well, and
that's the reason I looked into that.



	Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Eric W. Biederman]

Bernhard Walle <bwalle@suse.de> writes:

> * Eric W. Biederman [2008-04-29 10:15]:

>> What is your interest in getting the --real-mode option working at this
>> point?
>
> Well, the first reason was just interest.
>
> The second reason that pointed me in that direction is that I saw that
> kdump-booted kernels ignore the VGA parameter [e.g. 791] (which is
> quite clear since the video mode is not set in the boot block, but that
> can be easily patched) and also ignore the compiled-in VGA value (set
> with rdev). Then I saw that this is not done in the real kernel but in
> the 16 bit boot code which is of course only executed in real mode
> booting (arch/x86/boot/video.c).
>
> I know the 32-bit booted kernel takes the video mode from the running
> kernel, but currently it's not possible to change the mode. Well, it's
> not really important, it just would be nice.
>
> The overall reason behind this is that we (SUSE) use kexec now for the
> first reboot in our distribution setup which works quite well, and
> that's the reason I looked into that.

Ok.  So not critical but very useful to understand and it would be
cool to use if you could.  I wish I knew of a way to not confuse the
BIOS so we could do this more often.  I know I surprised a lot of
people with how often it worked on when I was actively pursuing it.

I have often suspected that the only way we could reliably run 16bit
code after running the linux kernel would be to load in an alternative
16bit BIOS like bochs that we could safely initialize from the state
the linux kernel left the hardware.  Although if we could ever figure
out what we are doing that confuses the hardware the other path could
be used.

For video mode changing it might be possible to just run the vga
BIOS calls and make them work.

All of which is to say there are paths forward if anyone wants to
pursue them.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec --real-mode

[Jamey Sharp]

On Wed, Apr 30, 2008 at 12:35:05PM -0700, Eric W. Biederman wrote:
> ... if we could ever figure out what we are doing that confuses the
> hardware the other path could be used.

In principle, purgatory could load GDB stubs and keep them around at
least long enough to debug code running in 16-bit mode, right? It would
be nice if somebody would do that. :-)

For a lot of my recent kexec work, I found it very helpful to use the
gdbserver in qemu, though I had to abandon it eventually due to
emulation bugs.

> For video mode changing it might be possible to just run the vga
> BIOS calls and make them work.

I was relying on vesafb in the kernel I wanted to boot. It turns out
that --real-mode works great on every machine I have handy, but doesn't
work for one of my co-workers. So I'm going to see if uvesafb works
better, in the next day or two hopefully.

http://dev.gentoo.org/~spock/projects/uvesafb/

I'm hoping that running the video BIOS in an x86 emulator works
reliably, and that that's the only boot failure I encounter. :-)

Jamey

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec