Hi,
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
(2) The Xorg Server has trouble, the VESA driver doesn't work.
There are also some good news: linux kernel with vesafb active works fine, likewise winxp guests.
cheers, Gerd
[ 90.904] (II) Loading sub module "vbe" [ 90.904] (II) LoadModule: "vbe" [ 90.904] (II) Loading /usr/lib/xorg/modules/libvbe.so [ 90.905] (II) Module vbe: vendor="X.Org Foundation" [ 90.905] compiled for 1.10.4, module version = 1.1.0 [ 90.905] ABI class: X.Org Video Driver, version 10.0 [ 90.905] (II) Loading sub module "int10" [ 90.905] (II) LoadModule: "int10" [ 90.906] (II) Loading /usr/lib/xorg/modules/libint10.so [ 90.909] (II) Module int10: vendor="X.Org Foundation" [ 90.909] compiled for 1.10.4, module version = 1.0.0 [ 90.909] ABI class: X.Org Video Driver, version 10.0 [ 90.909] (II) VESA(0): initializing int10 [ 90.912] (II) VESA(0): Bad V_BIOS checksum [ 90.912] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 97.832] Backtrace: [ 97.833] 0: Xorg (xorg_backtrace+0x3c) [0x80a408c] [ 97.833] 1: Xorg (0x8048000+0x60496) [0x80a8496] [ 97.833] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x2c040c] [ 97.837] 3: /usr/lib/xorg/modules/libint10.so (0x2ed000+0x47e2) [0x2f17e2] [ 97.837] 4: /usr/lib/xorg/modules/libint10.so (0x2ed000+0x343a) [0x2f043a] [ 97.837] 5: /usr/lib/xorg/modules/libint10.so (0x2ed000+0xe02e) [0x2fb02e] [ 97.837] 6: /usr/lib/xorg/modules/libint10.so (0x2ed000+0x13134) [0x300134] [ 97.837] 7: /usr/lib/xorg/modules/libint10.so (0x2ed000+0xdd56) [0x2fad56] [ 97.837] 8: /usr/lib/xorg/modules/libint10.so (xf86ExecX86int10+0x5d) [0x2f135d] [ 97.837] 9: /usr/lib/xorg/modules/libvbe.so (VBEExtendedInit+0x92) [0x2cc102] [ 97.837] 10: /usr/lib/xorg/modules/drivers/vesa_drv.so (0x2b5000+0x29db) [0x2b79db] [ 97.837] 11: Xorg (InitOutput+0x84b) [0x80b93cb] [ 97.837] 12: Xorg (0x8048000+0x1c1e5) [0x80641e5] [ 97.837] 13: /lib/libc.so.6 (__libc_start_main+0xf3) [0x72a3f3] [ 97.847] 14: Xorg (0x8048000+0x1c6a1) [0x80646a1] [ 97.848] Segmentation fault at address 0xb7e55000 [ 97.848] Fatal server error: [ 97.848] Caught signal 11 (Segmentation fault). Server aborting [ 97.850] [ 97.850]
On 03/02/12 09:09, Gerd Hoffmann wrote:
Hi,
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
(2) The Xorg Server has trouble, the VESA driver doesn't work.
There are also some good news: linux kernel with vesafb active works fine, likewise winxp guests.
Hi Gerd.
I took a look at the issue with Xorg. According to my diagnostic, x86emu (the real-mode emulator that the X server uses) seems to have problems emulating mov instructions that uses segment selectors other than DS and SS.
In lots of places in the vga bios code, we use instructions like mov %cs:(%eax), %ebp to access global variables (mostly when we use the GET_GLOBAL macro). We also might have a problem we use the SET_FARVAR macro because it uses ES.
This issue with segment selector seems to be confirmed by some comments I found in x86emu's code while doing my research: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/x86emu/decode.c The comment describing the decode_rm00_address function (line 838) seems to imply that only DS or SS can be used.
Kevin, would you see a problem modifying the READx_SEG macros in src/farptr.h to only dereference memory using the DS selector, in the vgabios case ?
For example:
#define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "push %%ds\n" \ "movw %%" #SEG " , %%ax\n" \ "movw %%ax, %%ds\n" \ "movb %1, %b0\n" \ "pop %%ds" : "=Qi"(value) \ : "m"(var), "m"(__segment_ ## SEG))
instead of:
#define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "movb %%" #SEG ":%1, %b0" : "=Qi"(value) \
On 03/04/12 00:21, Julian Pidancet wrote:
On 03/02/12 09:09, Gerd Hoffmann wrote:
Hi,
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
(2) The Xorg Server has trouble, the VESA driver doesn't work.
There are also some good news: linux kernel with vesafb active works fine, likewise winxp guests.
Hi Gerd.
I took a look at the issue with Xorg. According to my diagnostic, x86emu (the real-mode emulator that the X server uses) seems to have problems emulating mov instructions that uses segment selectors other than DS and SS.
In lots of places in the vga bios code, we use instructions like mov %cs:(%eax), %ebp to access global variables (mostly when we use the GET_GLOBAL macro). We also might have a problem we use the SET_FARVAR macro because it uses ES.
This issue with segment selector seems to be confirmed by some comments I found in x86emu's code while doing my research: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/x86emu/decode.c The comment describing the decode_rm00_address function (line 838) seems to imply that only DS or SS can be used.
Kevin, would you see a problem modifying the READx_SEG macros in src/farptr.h to only dereference memory using the DS selector, in the vgabios case ?
For example:
#define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "push %%ds\n" \ "movw %%" #SEG " , %%ax\n" \ "movw %%ax, %%ds\n" \ "movb %1, %b0\n" \ "pop %%ds" : "=Qi"(value) \ : "m"(var), "m"(__segment_ ## SEG))
instead of:
#define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "movb %%" #SEG ":%1, %b0" : "=Qi"(value) \
Hi again,
I've done further debugging, and you can ignore all of the crap above. x86emu badly handles the retl instruction and only pops a 16bit wide value from the stack, whereas the corresponding calll pushes a 32bit return address. leavel suffers from the same problem.
I've applied the following patch to x86emu and it seems to work better:
diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c index 5d3cac1..dd15387 100644 --- a/hw/xfree86/x86emu/ops.c +++ b/hw/xfree86/x86emu/ops.c @@ -8503,7 +8503,11 @@ static void x86emuOp_ret_near(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF("RET\n"); RETURN_TRACE("RET",M.x86.saved_cs,M.x86.saved_ip); TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + } else { + M.x86.R_IP = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } @@ -8807,8 +8811,13 @@ static void x86emuOp_leave(u8 X86EMU_UNUSED(op1)) START_OF_INSTR(); DECODE_PRINTF("LEAVE\n"); TRACE_AND_STEP(); - M.x86.R_SP = M.x86.R_BP; - M.x86.R_BP = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_ESP = M.x86.R_EBP; + M.x86.R_EBP = pop_long(); + } else { + M.x86.R_SP = M.x86.R_BP; + M.x86.R_BP = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); }
I am now wondering why Xorg calls VBE function 4f01 on the ROM so many times. It might be another bug. Also, in my test environment, Xorg still reports a bad checksum.
On Sun, Mar 04, 2012 at 03:03:49AM +0000, Julian Pidancet wrote:
I've done further debugging, and you can ignore all of the crap above. x86emu badly handles the retl instruction and only pops a 16bit wide value from the stack, whereas the corresponding calll pushes a 32bit return address. leavel suffers from the same problem.
Well, that's unfortunate. The system SeaBIOS uses to get gcc compiled code working in 16bit mode is going to generate "retl" instructions.
It may be possible to post-process the resulting assembler code, but (assuming we could) it would be quite ugly.
I've applied the following patch to x86emu and it seems to work better:
So, I guess the question is, how important is support for current/legacy x86emu versions?
-Kevin
On Sun, Mar 4, 2012 at 7:04 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Sun, Mar 04, 2012 at 03:03:49AM +0000, Julian Pidancet wrote:
I've done further debugging, and you can ignore all of the crap above. x86emu badly handles the retl instruction and only pops a 16bit wide value from the stack, whereas the corresponding calll pushes a 32bit return address. leavel suffers from the same problem.
Well, that's unfortunate. The system SeaBIOS uses to get gcc compiled code working in 16bit mode is going to generate "retl" instructions.
It may be possible to post-process the resulting assembler code, but (assuming we could) it would be quite ugly.
I've applied the following patch to x86emu and it seems to work better:
So, I guess the question is, how important is support for current/legacy x86emu versions?
I've tried to replace .code16gcc with .code16 in src/code16gcc.s to see if gcc would be able to generate code which doesn't use 32bit version of the call/ret instructions. The result was quite disappointing, it generates functions like this:
push %ebp mov %esp,%ebp [...] call 123 <func> [...] leave ret
Which seems correct, except that the prologue pushes 32bit on the stack, whereas the epilogue pops 16bit. (Could it be a GCC bug ?)
I am going to propose a patch to xorg-devel in the next few days, but in the meantime, it would be nice to find a solution in SeaBIOS so the code can work with older versions of Xorg.
I've done my testing with a 64bit machine though, I am wondering if there is a way to force Xorg to use vm86 at least on 32bit machines. Anybody knows anything about that ?
Hi,
It may be possible to post-process the resulting assembler code, but (assuming we could) it would be quite ugly.
Too bad, but there is no way around that :(
I've applied the following patch to x86emu and it seems to work better:
So, I guess the question is, how important is support for current/legacy x86emu versions?
Very. Almost every linux distro in the wild is affected by this, so this is a showstopper for qemu switching from lgpl vgabios to seabios vgabios.
cheers, Gerd
On Fri, Mar 02, 2012 at 10:09:10AM +0100, Gerd Hoffmann wrote:
Hi,
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
Thanks. Can you point me to an image and/or the steps to reproduce? I've tracked down a few of these before, and I'm sure I can fix it if I can reproduce it.
There are also some good news: linux kernel with vesafb active works fine, likewise winxp guests.
Great!
-Kevin
On 03/04/12 20:06, Kevin O'Connor wrote:
On Fri, Mar 02, 2012 at 10:09:10AM +0100, Gerd Hoffmann wrote:
Hi,
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
Thanks. Can you point me to an image and/or the steps to reproduce? I've tracked down a few of these before, and I'm sure I can fix it if I can reproduce it.
Install fedora 15 (or older) in qemu (mimimal is enougth). Edit /boot/grub/menu.lst and comment out the splashimage and hiddenmenu lines. On next reboot grub will come up in text mode and you'll see the behavior described above.
cheers, Gerd
On Mon, Mar 05, 2012 at 08:10:41AM +0100, Gerd Hoffmann wrote:
On 03/04/12 20:06, Kevin O'Connor wrote:
On Fri, Mar 02, 2012 at 10:09:10AM +0100, Gerd Hoffmann wrote:
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
Thanks. Can you point me to an image and/or the steps to reproduce? I've tracked down a few of these before, and I'm sure I can fix it if I can reproduce it.
Install fedora 15 (or older) in qemu (mimimal is enougth). Edit /boot/grub/menu.lst and comment out the splashimage and hiddenmenu lines. On next reboot grub will come up in text mode and you'll see the behavior described above.
I couldn't reproduce the issue on the initial screen, but I can reproduce when hitting the 'c' key. Turns out to be an integer overflow issue - patch below.
-Kevin
From c823759f201db6cea5a5f13fb7b5bec1cc47c114 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor kevin@koconnor.net Date: Mon, 5 Mar 2012 17:11:50 -0500 Subject: [PATCH] vgabios: int1009 handler bug limits count to 256 characters. To: seabios@seabios.org
Fix bug (u8 overflow) causing large screen fills to fail.
Signed-off-by: Kevin O'Connor kevin@koconnor.net --- vgasrc/vgabios.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c index 58e467d..faf57b1 100644 --- a/vgasrc/vgabios.c +++ b/vgasrc/vgabios.c @@ -510,10 +510,15 @@ handle_1008(struct bregs *regs) static void noinline write_chars(u8 page, struct carattr ca, u16 count) { + u16 nbcols = GET_BDA(video_cols); struct cursorpos cp = get_cursor_pos(page); while (count--) { vgafb_write_char(cp, ca); cp.x++; + if (cp.x >= nbcols) { + cp.x -= nbcols; + cp.y++; + } } }
On 03/05/12 23:20, Kevin O'Connor wrote:
On Mon, Mar 05, 2012 at 08:10:41AM +0100, Gerd Hoffmann wrote:
On 03/04/12 20:06, Kevin O'Connor wrote:
On Fri, Mar 02, 2012 at 10:09:10AM +0100, Gerd Hoffmann wrote:
Did some more testing of the vgabios today, two issues popped up:
(1) screen isn't cleared in some cases. Visible with grub1 in text mode. When it displays the menu a few stray chars are visible. Even more obvious it becomes when hitting 'c' then to get a prompt, then alot of the menu is still visible.
Thanks. Can you point me to an image and/or the steps to reproduce? I've tracked down a few of these before, and I'm sure I can fix it if I can reproduce it.
Install fedora 15 (or older) in qemu (mimimal is enougth). Edit /boot/grub/menu.lst and comment out the splashimage and hiddenmenu lines. On next reboot grub will come up in text mode and you'll see the behavior described above.
I couldn't reproduce the issue on the initial screen, but I can reproduce when hitting the 'c' key. Turns out to be an integer overflow issue - patch below.
Fixes it.
thanks, Gerd
-
Gerd Hoffmann -
Julian Pidancet -
Kevin O'Connor