SeaBIOS March 2015

seabios@seabios.org

29 participants
51 discussions

Re: [SeaBIOS] [ipxe-devel] [Qemu-devel] Emulation failure on booting/rebooting VMs

by Robin Smidsrød

On 19.03.2015 19:31, Mohammed Gamal wrote: > > On Wed, Mar 18, 2015 at 7:09 PM, Kevin O'Connor <kevin(a)koconnor.net > <mailto:kevin@koconnor.net>> wrote: > > On Wed, Mar 18, 2015 at 06:36:48PM +0100, Mohammed Gamal wrote: > > Hi, > > I've been sporadically getting my KVM virtual machines crashing > with this > > message while they're booting > > > > KVM internal error. Suberror: 1 > > emulation failure > > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00600f12 > > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa > > EIP=0000ff53 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 > > ES =0000 00000000 0000ffff 00009300 > > CS =f000 000f0000 0000ffff 00009b00 > > SS =0000 00000000 0000ffff 00009200 > > DS =0000 00000000 0000ffff 00009300 > > FS =0000 00000000 0000ffff 00009300 > > GS =0000 00000000 0000ffff 00009300 > > LDT=0000 00000000 0000ffff 00008200 > > TR =0000 00000000 0000ffff 00008300 > > GDT= 00000000 0000ffff > > IDT= 00000000 0000ffff > > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 > > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > > DR3=0000000000000000 > > DR6=00000000ffff0ff0 DR7=0000000000000400 > > EFER=0000000000000000 > > Code=74 65 61 6d 2e 00 66 68 5f 55 00 00 e9 c3 f8 fb f4 cb 66 c3 > <cf> 66 68 > > ff e6 00 00 e9 8b b1 66 55 66 57 66 56 66 53 66 89 c1 66 89 d6 a8 > 07 75 23 > > 66 0f > > > > I am running qemu 1.2, seabios 1.7.3 and ipxe (1.0.0-f6840ba) and > the host > > CPU is AMD Opteron 6386 SE running kernel 3.4.71. > > To debug seabios issues, we need the full log - see: > http://www.seabios.org/Debugging > > But, your software versions are a bit old which makes diagnosing any > issues hard. I suggest updating to the latest software and seeing if > the problem is still present. > > -Kevin > > > Unfortunately I can't change that setup. The problem is also rather > sporadic so I have no other means to reproduce it and debug it. > I tried looking into the seabios code but it looks like the instruction > pointer is pointing at the default interrupt vector table entry > 'entry_iret_official'. I presume this means that was triggered with an > interrupt of some sort? The other register values don't seem to provide > any clues nevertheless. I thought maybe this commit was relevant, https://git.ipxe.org/wimboot.git/commitdiff/1f11d05addc7aab9097b59e07680a0d…, but noticed you're not using wimboot at all... -- Robin

5 years, 11 months

Re: [SeaBIOS] [Qemu-devel] Emulation failure on booting/rebooting VMs

by Kevin O'Connor

On Wed, Mar 18, 2015 at 06:36:48PM +0100, Mohammed Gamal wrote: > Hi, > I've been sporadically getting my KVM virtual machines crashing with this > message while they're booting > > KVM internal error. Suberror: 1 > emulation failure > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00600f12 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa > EIP=0000ff53 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 00009300 > CS =f000 000f0000 0000ffff 00009b00 > SS =0000 00000000 0000ffff 00009200 > DS =0000 00000000 0000ffff 00009300 > FS =0000 00000000 0000ffff 00009300 > GS =0000 00000000 0000ffff 00009300 > LDT=0000 00000000 0000ffff 00008200 > TR =0000 00000000 0000ffff 00008300 > GDT= 00000000 0000ffff > IDT= 00000000 0000ffff > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000000 > Code=74 65 61 6d 2e 00 66 68 5f 55 00 00 e9 c3 f8 fb f4 cb 66 c3 <cf> 66 68 > ff e6 00 00 e9 8b b1 66 55 66 57 66 56 66 53 66 89 c1 66 89 d6 a8 07 75 23 > 66 0f > > I am running qemu 1.2, seabios 1.7.3 and ipxe (1.0.0-f6840ba) and the host > CPU is AMD Opteron 6386 SE running kernel 3.4.71. To debug seabios issues, we need the full log - see: http://www.seabios.org/Debugging But, your software versions are a bit old which makes diagnosing any issues hard. I suggest updating to the latest software and seeing if the problem is still present. -Kevin

5 years, 11 months

Re: [SeaBIOS] IDT issue

by Kevin O'Connor

On Thu, Mar 19, 2015 at 06:59:19PM +0530, Naresh G. Solanki wrote: > Hi, > > With respect to the auto reset issue, > > I did detailed memory test on my board and found the following > 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF region is not writable and every byte > reads as 0xFF. 0xA0000-0xC0000 is the legacy vga range, it's not normally mapped to memory, and can not (in normal cicrcumstances) be used as memory. The 0xC0000-0x100000 region is the historic BIOS and option rom location. It almost certainly can be used as memory on your board, but it's common for chipsets to have some magic bit that makes the region read-only. So, I think you need to find that magic bit and set it properly. -Kevin

5 years, 11 months

Re: [SeaBIOS] IDT issue

by Kevin O'Connor

On Tue, Mar 17, 2015 at 06:42:06PM +0530, Naresh G. Solanki wrote: > Dear All, > > I'm trying to port coreboot with seabios payload on Intel Atom E6xx based > board, > > The problem I'm facing is during malloc init, the board reboot & keeps on > rebooting after displaying malloc init debug message. > > I tried to track it & found that it might probably be due to dummy IDT > loaded @seabios entry point (entry_elf) > > Once it reboot I'm finding that breakpoints set are not working. > Breakpoints are set through JTAG-XDP. > > Can anyone give an idea to how to go about this issue. SeaBIOS loads a dummy IDT when in 32bit mode, because the code is never supposed to raise an interrupt (interrupts and NMIs are always disabled when in 32bit mode). So, if you're seeing a fault with the IDT, it likely indicates something is causing a software fault. If a fault is ocurring in malloc_init(), then I'd check that the memory between 0xc0000-0x100000 is fully read/writable. You could also try disabling CONFIG_MALLOC_UPPERMEMORY to see if that changes behavior. malloc_init() is also called right after self-relocation, so check that the memory map that coreboot provides is accurate. You could also try disabling CONFIG_RELOCATE_INIT to see if that changes the fault. -Kevin

5 years, 11 months

Re: [SeaBIOS] [Qemu-devel] Emulation failure on booting/rebooting VMs

by Andrey Korolyov

On Wed, Mar 18, 2015 at 8:36 PM, Mohammed Gamal <mohammed.gamal(a)profitbricks.com> wrote: > Hi, > I've been sporadically getting my KVM virtual machines crashing with this > message while they're booting > > KVM internal error. Suberror: 1 > emulation failure > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00600f12 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa > EIP=0000ff53 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 00009300 > CS =f000 000f0000 0000ffff 00009b00 > SS =0000 00000000 0000ffff 00009200 > DS =0000 00000000 0000ffff 00009300 > FS =0000 00000000 0000ffff 00009300 > GS =0000 00000000 0000ffff 00009300 > LDT=0000 00000000 0000ffff 00008200 > TR =0000 00000000 0000ffff 00008300 > GDT= 00000000 0000ffff > IDT= 00000000 0000ffff > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000000 > Code=74 65 61 6d 2e 00 66 68 5f 55 00 00 e9 c3 f8 fb f4 cb 66 c3 <cf> 66 68 > ff e6 00 00 e9 8b b1 66 55 66 57 66 56 66 53 66 89 c1 66 89 d6 a8 07 75 23 > 66 0f > > I am running qemu 1.2, seabios 1.7.3 and ipxe (1.0.0-f6840ba) and the host > CPU is AMD Opteron 6386 SE running kernel 3.4.71. > > I digged a little into the kvm kernel module code and I can trace these > emulation failures only to either a call to pf_interception() - which is > highly unlikely since the machine doesn't appear to have setup paging yet - > and task_switch_interception(). I am suspecting that ipxe or seabios might > be executing some invalid code or something, since this failure only appears > sporadically and is not 100% reproducible. Any ideas why this might be > happening? > > Regards, > Mohammed Hello, would you mind to try seabios 1.8.1?

5 years, 11 months

Emulation failure on booting/rebooting VMs

by Mohammed Gamal

Hi, I've been sporadically getting my KVM virtual machines crashing with this message while they're booting KVM internal error. Suberror: 1 emulation failure EAX=00000000 EBX=00000000 ECX=00000000 EDX=00600f12 ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa EIP=0000ff53 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 000f0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009200 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008300 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=74 65 61 6d 2e 00 66 68 5f 55 00 00 e9 c3 f8 fb f4 cb 66 c3 <cf> 66 68 ff e6 00 00 e9 8b b1 66 55 66 57 66 56 66 53 66 89 c1 66 89 d6 a8 07 75 23 66 0f I am running qemu 1.2, seabios 1.7.3 and ipxe (1.0.0-f6840ba) and the host CPU is AMD Opteron 6386 SE running kernel 3.4.71. I digged a little into the kvm kernel module code and I can trace these emulation failures only to either a call to pf_interception() - which is highly unlikely since the machine doesn't appear to have setup paging yet - and task_switch_interception(). I am suspecting that ipxe or seabios might be executing some invalid code or something, since this failure only appears sporadically and is not 100% reproducible. Any ideas why this might be happening? Regards, Mohammed

5 years, 11 months

IDT issue

by Naresh G. Solanki

Dear All, I'm trying to port coreboot with seabios payload on Intel Atom E6xx based board, The problem I'm facing is during malloc init, the board reboot & keeps on rebooting after displaying malloc init debug message. I tried to track it & found that it might probably be due to dummy IDT loaded @seabios entry point (entry_elf) Once it reboot I'm finding that breakpoints set are not working. Breakpoints are set through JTAG-XDP. Can anyone give an idea to how to go about this issue. -- -------- * ---------------* ----------------* ----------- *-------------------------------------- ------- --------- -------------- ------- ------ -------------- ------- - ---- -------------- ------- ---- - -------------- ------- ------ --------------- ------- -------- --------------- --------------------------------------*

5 years, 11 months

IDT issue

by Naresh G. Solanki

5 years, 11 months

Re: [SeaBIOS] error in write and read from usb hid device

by Kevin O'Connor

On Mon, Mar 16, 2015 at 11:13:16AM +0330, Navid Movahedi wrote: > > See http://seabios.org/Debugging > > > > I couldn't add the physical EHCI controller to qemu using pass through. how > to do that? > > So, you are using coreboot+seabios on vmware and coreboot+seabios on > > real hardware as well? > > > > no, i have developed a boot loader and for usb detection and enumeration i > have used the seabios source base and i test this bootloader with vmware > and real hardware Okay, if the code has been modified that much I wont be able to help. I suggest you start by downloading the ehci specification and read through it. -Kevin

5 years, 11 months

[PATCH] vgabios: Avoid extra stack if it appears a modern OS is in use

by Kevin O'Connor

If a VBE mode set call is made, stop using the vgabios extra stack. This works under the premise that only a modern OS would invoke the VBE mode changing facilities and a modern OS would always call the vgabios with sufficient stack space. This is an ugly hack to work around a problem Windows Vista (and possibly later Windows releases) has with the VGA BIOS using a stack in the e-segment. Reported-by: Richard Laager <rlaager(a)wiktel.com> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- I ran some further tests with the Windows emulator crashing problem. I eventually came up with the targeted solution above. Basically, I tried to find a signature that indicates Windows is running and disable the extra stack in that case. It's a hack for sure, but it seems to work. For the curious, some other tests that I ran that didn't yield a solution: * The "concurrent dos" image I have actually uses vm86 mode and it still expects the vgabios to only use a tiny amount of stack space. So, just disabling the extra stack in vm86 mode breaks this "concurrent dos" image. * Windows faults on the first write access to the e-segment, so testing if the extra stack is read/writable doesn't work (as the test itself causes a fault which halts the emulation). * Windows actually copies the first 1 Meg before starting the emulation, so putting some kind of signature in the extra stack doesn't help detect if it's read-only. * When these troublesome vgabios calls are made, Windows is using a copy of the first 1 Meg instead of accessing it in place. If a log is written to the writable part of the first 1 Meg, then when the log is inspected later it doesn't show any of the troublesome calls. --- vgasrc/vbe.c | 1 + vgasrc/vgabios.h | 1 + vgasrc/vgainit.c | 15 +++++++++++++++ 3 files changed, 17 insertions(+) diff --git a/vgasrc/vbe.c b/vgasrc/vbe.c index af3d0cc..834d7b3 100644 --- a/vgasrc/vbe.c +++ b/vgasrc/vbe.c @@ -205,6 +205,7 @@ static void vbe_104f02(struct bregs *regs) { dprintf(1, "VBE mode set: %x\n", regs->bx); + check_extra_stack(); int mode = regs->bx & ~MF_VBEFLAGS; int flags = regs->bx & MF_VBEFLAGS; diff --git a/vgasrc/vgabios.h b/vgasrc/vgabios.h index fd796f2..985bbbb 100644 --- a/vgasrc/vgabios.h +++ b/vgasrc/vgabios.h @@ -100,6 +100,7 @@ extern u8 vgafont16alt[]; // vgainit.c extern struct video_save_pointer_s video_save_pointer_table; extern struct video_param_s video_param_table[29]; +void check_extra_stack(void); // vgabios.c extern int VgaBDF; diff --git a/vgasrc/vgainit.c b/vgasrc/vgainit.c index 8d12261..4616883 100644 --- a/vgasrc/vgainit.c +++ b/vgasrc/vgainit.c @@ -86,6 +86,21 @@ allocate_extra_stack(void) } } +void +check_extra_stack(void) +{ + if (!CONFIG_VGA_ALLOCATE_EXTRA_STACK) + return; + extern void entry_10(void); + if (GET_IVT(0x10).offset == (u32)entry_10) + return; + // Disable the extra stack if a VBE mode set call is made. This + // works around a bug in Windows Vista when the stack is in the + // e-segment. + dprintf(1, "Disabling SeaVGABIOS extra stack.\n"); + SET_IVT(0x10, SEGOFF(get_global_seg(), (u32)entry_10)); +} + /**************************************************************** * Timer hook -- 1.9.3

5 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS March 2015