Andrei Borzenkov wrote:
As far as I can tell
- early boot (platform dependent) kernel code fills in screen_info structure describing current video mode at the time kernel is booted
This *seems* to partly contradict the code in lilo. It allows "vga="ask|ext|extended|normal|NNN|0xHHH" and claims that this vga setting is done in lilo. To try to ensure it is only done in lilo it disallows the "vga=xxx" parameter in the "append" section of a kernel-boot specification.
- later video drivers use screen_info during initialization
--- Don't have any of those -- and to try to move this problem "forward", I turned off the "kbd" setup which loads a font (and keymap) for the console to try to support multiple locales and/or unicode. I hoped that by not changing the video mode, the screen would be "left" in the its original mode so a kexec wouldn't need to "restore it first". It didn't work -- and I wasn't really accurate by saying "garbage" was spewed on the screen -- more specifically, it looks like the normal boot progress (after it unpacks) as it initially comes up -- BUT, there are no "CR/LF's" each line of output is appended to the previous until it got about 2/3rd's the way down where it scrolled previous text up. That continued for maybe 10 seconds, then something reset it. Now I notice one point of potential problem: lilo sets the vga mode to 43 lines x 133 columns, but I don't think the kernel is getting the "news", since about 146 lines into the boot log, I see a message: Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled ---- I.e. the kernel maybe thinks the VGA screen is in 80x25...which isn't how 'lilo' left it. FWIW, when the screen came up, it came up (according to stty) in a 50x80 mode, but the bottom 6.5 lines were cut off (yes, no matter how I adjusted the screen tuning, the 44th line only shows the top half. That got "solved" by saying "stty rows 43". Now all 43 rows display, but I'm not sure what the width is set to (says 80). So I think I need to try to pass a vga param w/kexec -- not sure if that will help or not, but likely my next step. Good thing it is "kexec". After the HW boots (~11 seconds), I see the disks being mounted (~1.2 secs), and another ~7 seconds to bring up all the services (it's a server not a desktop).
- kexec passes original screen_info onto loaded kernel, thus making it start using whatever video mode was in effect when original kernel was booted. It also contains interesting comment
/* Copying screen_info will do? */ memcpy(¶ms->screen_info, &boot_params.screen_info, sizeof(struct screen_info));
So it appears there is no way to do what you want.
--- Hmm... great.
There are suggestions that using
kexec --real-mode
may work, as it makes loaded kernel to go through real-mode entry point that queries video BIOS for current modes.
Hmmm... will put that on my list of things to try as well... (sigh)... Thanks.. Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org