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
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
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
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?
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
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.
--
-------- * ---------------* ----------------* -----------
*-------------------------------------- ------- ---------
-------------- ------- ------ -------------- ------- -
---- -------------- ------- ---- - -------------- -------
------ --------------- ------- -------- ---------------
--------------------------------------*
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.
--
-------- * ---------------* ----------------* -----------
*-------------------------------------- ------- ---------
-------------- ------- ------ -------------- ------- -
---- -------------- ------- ---- - -------------- -------
------ --------------- ------- -------- ---------------
--------------------------------------*
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
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
