kexec and frame buffer
Luca Falavigna
each of them I gathered dmesg messages from original and relocated kernel, in
order to easily compare them later on. These tests were run on a virtual machine
in order to provide the same environment for each experiment.
Here are my tests and related results:
1) Frame buffer not enabled
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro
Everything went well, as supposed to be. I was able to read boot messages and to
see login prompts.
2) Frame buffer enabled in the relocated kernel
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro vga=791
This time I was able to read boot messages and so on, but I couldn't be able to
load vesafb in the relocated kernel. dmesg showed nothing about vesafb.
3) Frame buffer enabled in the original kernel
Original kernel command line: root=/dev/hda1 ro vga=791
Relocated kernel command line: root=/dev/hda1 ro {vga=791,}
This time I wasn't able to read boot messages in the relocated kernel, whether
vga parameter was set or not. I looked at dmesg in order to get some useful
informations:
Linux version 2.6.13-rc5 (dktrkranz@gandalf) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #3 Wed Aug 3 13:39:11 UTC 2005
[...]
-Console: colour dummy device 80x25
+Console: colour VGA+ 80x25
[...]
-vesafb: framebuffer at 0xf0000000, mapped to 0xc2880000, using 3072k, total
16384k
-vesafb: mode is 1024x768x16, linelength=2048, pages=0
-vesafb: protected mode interface info at 00ff:44f0
-vesafb: scrolling: redraw
-vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
-mtrr: your processor doesn't support write-combining
-Console: switching to colour frame buffer device 128x48
-fb0: VESA VGA frame buffer device
[...]
It seems relocated kernel doesn't (or can't) load vesafb. Is frame buffer
supported in kexec or there is some work-in-progress?
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric W. Biederman
So without doing passing --real-mode the vga= parameter currently
cannot work. The vga= parameter is processed by vga.S which
make BIOS calls and we bypass all of the BIOS calls.
So you can try with the --real-mode option and you have
a chance of the code working. Or you can figure out which
information video.S passes to the kernel figure out how
to get that same information out of a running kernel
and then /sbin/kexec can be tweaked to pass the current
video mode. Changing frame buffer modes shouldn't work
but you should at least be able to preserve the existing
ones.
Eric
Luca Falavigna
Hash: SHA1
Eric W. Biederman ha scritto:
> So without doing passing --real-mode the vga= parameter currently
> cannot work. The vga= parameter is processed by vga.S which
> make BIOS calls and we bypass all of the BIOS calls.
Actually that file is video.S
> So you can try with the --real-mode option and you have
> a chance of the code working. Or you can figure out which
> information video.S passes to the kernel figure out how
> to get that same information out of a running kernel
> and then /sbin/kexec can be tweaked to pass the current
> video mode. Changing frame buffer modes shouldn't work
> but you should at least be able to preserve the existing
> ones.
I tried to pass --real-mode flag to kexec but my virtual machine doesn't like
it. When I launch kexec -e, it tells me: "A strange behaviour occourred which
crashed virtual machine". I'll dig source code ASAP to figure out this matter.
Meanwhile I'm going to follow your advice to inspect video.S in order to track
down something useful.
Regards,
- --
Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQvTG5czkDT3RfMB6AQJY8Qf9HucRMCCAvta/pAs1CakqwJs5bZo4uJUu
3tat7+24I57mDmj+2IGe7qLO9W9ctCyVJStHTMCpjYq0qF7TA9VZSsU3ip1h9/IG
HnCzozUGpd3yrNsrs3v0fvinQ1z2UtrOY8lxCUISchI3Ho43KnPDoAV2mfT+eEcP
pN/lUz6Z/Jb0YbNS9Z352bqs+JtuxHzX1pVD4uH4X+Dkua3kAde5C0bwP9K+O15A
//qlXb4AJErv6I5+Q/RxCDAn4TtVJCcdoA9Sp84ZH8jnxiYkg2coijvwFHLLvPD/
bK49QyD5QHmsVC3x/pIefd3qPEOphbNPE7AlN86X8B4i8lI6jr2x3g==
=YhUC
-----END PGP SIGNATURE-----
Eric W. Biederman
> Eric W. Biederman ha scritto:
>> So without doing passing --real-mode the vga= parameter currently
>> cannot work. The vga= parameter is processed by vga.S which
>> make BIOS calls and we bypass all of the BIOS calls.
> Actually that file is video.S
Oops. Anyway I believe you also want to look at include/linux/tty.h
at the screen_info structure. I believe that is where
all of that information is passed.
>> So you can try with the --real-mode option and you have
>> a chance of the code working. Or you can figure out which
>> information video.S passes to the kernel figure out how
>> to get that same information out of a running kernel
>> and then /sbin/kexec can be tweaked to pass the current
>> video mode. Changing frame buffer modes shouldn't work
>> but you should at least be able to preserve the existing
>> ones.
> I tried to pass --real-mode flag to kexec but my virtual machine doesn't like
> it. When I launch kexec -e, it tells me: "A strange behaviour occourred which
> crashed virtual machine".
Cool. I haven't used that code in a long time but it is pretty
trivial code to switches to real mode so I don't really doubt it :)
> I'll dig source code ASAP to figure out this matter.
> Meanwhile I'm going to follow your advice to inspect video.S in order to track
> down something useful.
Sounds good.
Eric
Luca Falavigna
Hash: SHA1
Eric W. Biederman ha scritto:
> Anyway I believe you also want to look at include/linux/tty.h
> at the screen_info structure. I believe that is where
> all of that information is passed.
I noticed. Maybe if we fill struct x86_linux_param_header with some values
obtained from struct screen_info, we should be able to "score that mid-court
prayer" ;)
>>I tried to pass --real-mode flag to kexec but my virtual machine doesn't like
>>it. When I launch kexec -e, it tells me: "A strange behaviour occourred which
>>crashed virtual machine".
>
>
> Cool. I haven't used that code in a long time but it is pretty
> trivial code to switches to real mode so I don't really doubt it :)
Added to my list-of-things-to-do-after-holydays :)
Regards,
- --
Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQvYmaszkDT3RfMB6AQLPMQf/W3HZbJj50rxI1LOHyw0hhcQZji+gU68R
E88xmgbL1fuiQqdqD1vp3gG7uDf9jjE+TjNMQ1qgZr01xHUjV13Jq8e9Lu75S+RZ
JgiYJxFKGY/ctl9oFgEraU9Qje1b18dTmYh5G4xfZLNjUFUM1uQowV6CSPLVRadv
ucmzduDrqwRBQgN9vSrWPoLio8nbT5ZjxLjaY1z3P3EYXoBs9LLx1bjzLmR7/cVe
MP3/BM61CLqflOG9G+ck9yD2RIYnLhvNHDBKt1X+oP+U/iSkzse3XEM/YVny6/3d
zAYy8m66o2bPnj/vNcBbroxANTdiXJce8QWayk9a69c26DmjOLnYrQ==
=iPn6
-----END PGP SIGNATURE-----
Luca Falavigna
Hash: SHA1
Luca Falavigna ha scritto:
> Eric W. Biederman ha scritto:
>
>>>Anyway I believe you also want to look at include/linux/tty.h
>>>at the screen_info structure. I believe that is where
>>>all of that information is passed.
>
> I noticed. Maybe if we fill struct x86_linux_param_header with some values
> obtained from struct screen_info, we should be able to "score that mid-court
> prayer" ;)
>
I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and
store screen_info variables into struct x86_linux_param_header, but I got the
same result: no messages shown in console, as I supposed.
After that I looked at video.S, especially an interesting label called "video":
# This is the main entry point called by setup.S
# %ds *must* be pointing to the bootsector
video: pushw %ds # We use different segments
pushw %ds # FS contains original DS
popw %fs
[...]
#ifdef CONFIG_VIDEO_SELECT
movw %fs:(0x01fa), %ax # User selected video mode
cmpw $ASK_VGA, %ax # Bring up the menu
jz vid2
[...]
Video mode is stored (by bootloader, actually) at offset 0x01fa from a given
boot sector, which should be located at physical address DEF_SETUPSEG (0x9020).
Feel free to correct me if I'm wrong.
If we could store current video mode before executing reboot_code_buffer,
probably setup() function would take care of anything else. So we could
implement a function (or an assembly stub) in machine_kexec which does this job.
I think this is the best (and safest) solution.
Regards,
- --
Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQvzwDczkDT3RfMB6AQJlQAf+INkCMjhmm18RPCMHXij7WmOL/4TCKTc8
fZCf+IzhsSUxwkfYmUbTfXtJ/xCxIyRh5gBGirB9n/s9NzOiYwmcQWMrn7DbWpWu
YBVkTdz3W3Y0dA08baIYQ8u51gJvnVMuGJEFqsLxPx+gzHJOETEGkzhuyUuPk+J+
N4OkSyTGYt5zXZmyVzV7KZ8XLrfX3XvRLV3m2aey0Hz4jcf8sIozANokDRdG3MpN
7F0Z4yL1EnMI4oijHSDLeqbycAg8iYa49P45EO6+jzuRH2i2bnq8hOvBHa0+B01Q
Gr0Ljd+DJ2jNVO4ecqbWC9oFxBFXsRN+ThAxsYEbWDGIrJdAa32mfA==
=BztK
Eric W. Biederman
> Luca Falavigna ha scritto:
>> Eric W. Biederman ha scritto:
>>
>>>>Anyway I believe you also want to look at include/linux/tty.h
>>>>at the screen_info structure. I believe that is where
>>>>all of that information is passed.
>>
>> I noticed. Maybe if we fill struct x86_linux_param_header with some values
>> obtained from struct screen_info, we should be able to "score that mid-court
>> prayer" ;)
>>
> I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and
> store screen_info variables into struct x86_linux_param_header, but I got the
> same result: no messages shown in console, as I supposed.
Hmm. very odd. Sounds very much like an implementation problem.
> After that I looked at video.S, especially an interesting label called "video":
>
> # This is the main entry point called by setup.S
> # %ds *must* be pointing to the bootsector
> video: pushw %ds # We use different segments
> pushw %ds # FS contains original DS
> popw %fs
> [...]
> #ifdef CONFIG_VIDEO_SELECT
> movw %fs:(0x01fa), %ax # User selected video mode
> cmpw $ASK_VGA, %ax # Bring up the menu
> jz vid2
> [...]
>
> Video mode is stored (by bootloader, actually) at offset 0x01fa from a given
> boot sector, which should be located at physical address DEF_SETUPSEG (0x9020).
> Feel free to correct me if I'm wrong.
That is the default address, it can actually move quite a bit.
> If we could store current video mode before executing reboot_code_buffer,
> probably setup() function would take care of anything else. So we could
> implement a function (or an assembly stub) in machine_kexec which does this job.
> I think this is the best (and safest) solution.
That is why we have sys_kexec_load().
With a working ioctl (or other way to query the information) we
just need to populate screen_info from x86-linux-setup.c in /sbin/kexec.
Eric