This fix is breaking v2 when running it with emulation mainboard qemu-x86:
Output Log:
CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa
And here it keeps holding. With older revisions v2 works fine.
Regards,
René
2009/5/29 svn@coreboot.org
Author: linux_junkie Date: 2009-05-29 20:42:23 +0200 (Fri, 29 May 2009) New Revision: 1170
Modified: coreboot-v3/util/x86emu/Config.lb coreboot-v3/util/x86emu/Makefile Log: rename the option CONFIG_PCI_OPTION_ROM_RUN_VM86 to CONFIG_PCI_OPTION_ROM_RUN_REALMODE. Signed-off-by: Joseph Smith joe@settoplinux.org Acked-by: Stefan Reinauer stepan@coresystems.de
Modified: coreboot-v3/util/x86emu/Config.lb
--- coreboot-v3/util/x86emu/Config.lb 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Config.lb 2009-05-29 18:42:23 UTC (rev 1170) @@ -1,11 +1,11 @@ uses CONFIG_PCI_OPTION_ROM_RUN_YABEL -uses CONFIG_PCI_OPTION_ROM_RUN_VM86 +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE
if CONFIG_PCI_OPTION_ROM_RUN_YABEL dir yabel dir x86emu else
- if CONFIG_PCI_OPTION_ROM_RUN_VM86
- if CONFIG_PCI_OPTION_ROM_RUN_REALMODE object x86.o object x86_interrupts.o object x86_asm.S
Modified: coreboot-v3/util/x86emu/Makefile
--- coreboot-v3/util/x86emu/Makefile 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Makefile 2009-05-29 18:42:23 UTC (rev 1170) @@ -37,7 +37,7 @@ #TODO: remove these, these are .h files from slof, to make the merge easier... X86EMU_INCLUDE += -I $(src)/util/x86emu/yabel/compat endif -VM86_SRC = x86.c x86_asm.S +REALMODE_SRC = x86.c x86_asm.S
ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y) LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(BIOSEMU_SRC) @@ -47,8 +47,8 @@ LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(patsubst %,yabel/%,$(BIOSEMU_SRC)) endif
-ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_VM86),y) -LIBX86EMU_SRC=$(VM86_SRC) +ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y) +LIBX86EMU_SRC=$(REALMODE_SRC) endif
LIBX86EMU_OBJS = $(patsubst %.c,$(obj)/util/x86emu/%.o,$(LIBX86EMU_SRC))
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Dear René,
can you try the latest version? I checked in a possible fix for v3.
Best regards,
Stefan
On 07.06.2009 17:49 Uhr, René Reuter wrote:
This fix is breaking v2 when running it with emulation mainboard qemu-x86:
Output Log:
CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa
And here it keeps holding. With older revisions v2 works fine.
Regards,
René
2009/5/29 <svn@coreboot.org mailto:svn@coreboot.org>
Author: linux_junkie Date: 2009-05-29 20:42:23 +0200 (Fri, 29 May 2009) New Revision: 1170 Modified: coreboot-v3/util/x86emu/Config.lb coreboot-v3/util/x86emu/Makefile Log: rename the option CONFIG_PCI_OPTION_ROM_RUN_VM86 to CONFIG_PCI_OPTION_ROM_RUN_REALMODE. Signed-off-by: Joseph Smith <joe@settoplinux.org <mailto:joe@settoplinux.org>> Acked-by: Stefan Reinauer <stepan@coresystems.de <mailto:stepan@coresystems.de>> Modified: coreboot-v3/util/x86emu/Config.lb =================================================================== --- coreboot-v3/util/x86emu/Config.lb 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Config.lb 2009-05-29 18:42:23 UTC (rev 1170) @@ -1,11 +1,11 @@ uses CONFIG_PCI_OPTION_ROM_RUN_YABEL -uses CONFIG_PCI_OPTION_ROM_RUN_VM86 +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE if CONFIG_PCI_OPTION_ROM_RUN_YABEL dir yabel dir x86emu else - if CONFIG_PCI_OPTION_ROM_RUN_VM86 + if CONFIG_PCI_OPTION_ROM_RUN_REALMODE object x86.o object x86_interrupts.o object x86_asm.S Modified: coreboot-v3/util/x86emu/Makefile =================================================================== --- coreboot-v3/util/x86emu/Makefile 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Makefile 2009-05-29 18:42:23 UTC (rev 1170) @@ -37,7 +37,7 @@ #TODO: remove these, these are .h files from slof, to make the merge easier... X86EMU_INCLUDE += -I $(src)/util/x86emu/yabel/compat endif -VM86_SRC = x86.c x86_asm.S +REALMODE_SRC = x86.c x86_asm.S ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y) LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(BIOSEMU_SRC) @@ -47,8 +47,8 @@ LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(patsubst %,yabel/%,$(BIOSEMU_SRC)) endif -ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_VM86),y) -LIBX86EMU_SRC=$(VM86_SRC) +ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y) +LIBX86EMU_SRC=$(REALMODE_SRC) endif LIBX86EMU_OBJS = $(patsubst %.c,$(obj)/util/x86emu/%.o,$(LIBX86EMU_SRC)) -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot
Nope I'm getting the same error with 1171 in v2:
CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa
René
2009/6/7 Stefan Reinauer stepan@coresystems.de
Dear René,
can you try the latest version? I checked in a possible fix for v3.
Best regards,
Stefan
On 07.06.2009 17:49 Uhr, René Reuter wrote:
This fix is breaking v2 when running it with emulation mainboard qemu-x86:
Output Log:
CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa
And here it keeps holding. With older revisions v2 works fine.
Regards,
René
2009/5/29 svn@coreboot.org
Author: linux_junkie Date: 2009-05-29 20:42:23 +0200 (Fri, 29 May 2009) New Revision: 1170
Modified: coreboot-v3/util/x86emu/Config.lb coreboot-v3/util/x86emu/Makefile Log: rename the option CONFIG_PCI_OPTION_ROM_RUN_VM86 to CONFIG_PCI_OPTION_ROM_RUN_REALMODE. Signed-off-by: Joseph Smith joe@settoplinux.org Acked-by: Stefan Reinauer stepan@coresystems.de
Modified: coreboot-v3/util/x86emu/Config.lb
--- coreboot-v3/util/x86emu/Config.lb 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Config.lb 2009-05-29 18:42:23 UTC (rev 1170) @@ -1,11 +1,11 @@ uses CONFIG_PCI_OPTION_ROM_RUN_YABEL -uses CONFIG_PCI_OPTION_ROM_RUN_VM86 +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE
if CONFIG_PCI_OPTION_ROM_RUN_YABEL dir yabel dir x86emu else
- if CONFIG_PCI_OPTION_ROM_RUN_VM86
- if CONFIG_PCI_OPTION_ROM_RUN_REALMODE object x86.o object x86_interrupts.o object x86_asm.S
Modified: coreboot-v3/util/x86emu/Makefile
--- coreboot-v3/util/x86emu/Makefile 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Makefile 2009-05-29 18:42:23 UTC (rev 1170) @@ -37,7 +37,7 @@ #TODO: remove these, these are .h files from slof, to make the merge easier... X86EMU_INCLUDE += -I $(src)/util/x86emu/yabel/compat endif -VM86_SRC = x86.c x86_asm.S +REALMODE_SRC = x86.c x86_asm.S
ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y) LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(BIOSEMU_SRC) @@ -47,8 +47,8 @@ LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(patsubst %,yabel/%,$(BIOSEMU_SRC)) endif
-ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_VM86),y) -LIBX86EMU_SRC=$(VM86_SRC) +ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y) +LIBX86EMU_SRC=$(REALMODE_SRC) endif
LIBX86EMU_OBJS = $(patsubst %.c,$(obj)/util/x86emu/%.o,$(LIBX86EMU_SRC))
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Sorry, I didn't read your report thorough enough, I thought you were using v3 due to the v3 revision numbers.
The fix is only renaming a variable, nothing more. It's highly unlikely that it's the cause of the breakage. What coreboot v2 revision are you using?
Stefan
On 07.06.2009 17:49 Uhr, René Reuter wrote:
This fix is breaking v2 when running it with emulation mainboard qemu-x86:
Output Log:
CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes Calling Option Rom... oprom: INT# 0x0 oprom: eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c oprom: ebp: 00013f50 esp: 00000ffa edi: 0000ea44 esi: 0001444c oprom: ip: 0556 cs: 0000 flags: 00000246 Oops, exception 0 while executing option rom Unexpected Exception: 0 @ 00:00000556 - Halting Code: 0 eflags: 00000246 eax: 00000000 ebx: 0001444c ecx: 00013ff4 edx: 0001444c edi: 0000ea44 esi: 0001444c ebp: 00013f50 esp: 00000ffa
And here it keeps holding. With older revisions v2 works fine.
Regards,
René
2009/5/29 <svn@coreboot.org mailto:svn@coreboot.org>
Author: linux_junkie Date: 2009-05-29 20:42:23 +0200 (Fri, 29 May 2009) New Revision: 1170 Modified: coreboot-v3/util/x86emu/Config.lb coreboot-v3/util/x86emu/Makefile Log: rename the option CONFIG_PCI_OPTION_ROM_RUN_VM86 to CONFIG_PCI_OPTION_ROM_RUN_REALMODE. Signed-off-by: Joseph Smith <joe@settoplinux.org <mailto:joe@settoplinux.org>> Acked-by: Stefan Reinauer <stepan@coresystems.de <mailto:stepan@coresystems.de>> Modified: coreboot-v3/util/x86emu/Config.lb =================================================================== --- coreboot-v3/util/x86emu/Config.lb 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Config.lb 2009-05-29 18:42:23 UTC (rev 1170) @@ -1,11 +1,11 @@ uses CONFIG_PCI_OPTION_ROM_RUN_YABEL -uses CONFIG_PCI_OPTION_ROM_RUN_VM86 +uses CONFIG_PCI_OPTION_ROM_RUN_REALMODE if CONFIG_PCI_OPTION_ROM_RUN_YABEL dir yabel dir x86emu else - if CONFIG_PCI_OPTION_ROM_RUN_VM86 + if CONFIG_PCI_OPTION_ROM_RUN_REALMODE object x86.o object x86_interrupts.o object x86_asm.S Modified: coreboot-v3/util/x86emu/Makefile =================================================================== --- coreboot-v3/util/x86emu/Makefile 2009-05-29 17:38:46 UTC (rev 1169) +++ coreboot-v3/util/x86emu/Makefile 2009-05-29 18:42:23 UTC (rev 1170) @@ -37,7 +37,7 @@ #TODO: remove these, these are .h files from slof, to make the merge easier... X86EMU_INCLUDE += -I $(src)/util/x86emu/yabel/compat endif -VM86_SRC = x86.c x86_asm.S +REALMODE_SRC = x86.c x86_asm.S ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y) LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(BIOSEMU_SRC) @@ -47,8 +47,8 @@ LIBX86EMU_SRC=$(patsubst %,x86emu/%,$(X86EMU_SRC)) $(patsubst %,yabel/%,$(BIOSEMU_SRC)) endif -ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_VM86),y) -LIBX86EMU_SRC=$(VM86_SRC) +ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y) +LIBX86EMU_SRC=$(REALMODE_SRC) endif LIBX86EMU_OBJS = $(patsubst %.c,$(obj)/util/x86emu/%.o,$(LIBX86EMU_SRC))
I just did a build on v2 for qemu and it is failing badly, same error. Now I have something to do on the plane tomorrow.
ron
On Sun, Jun 7, 2009 at 8:32 PM, ron minnichrminnich@gmail.com wrote:
I just did a build on v2 for qemu and it is failing badly, same error. Now I have something to do on the plane tomorrow.
ron
btw, this looks really broken: In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes
It's already there. Why copy it?
ron
On Sun, 7 Jun 2009 20:33:32 -0700, ron minnich rminnich@gmail.com wrote:
On Sun, Jun 7, 2009 at 8:32 PM, ron minnichrminnich@gmail.com wrote:
I just did a build on v2 for qemu and it is failing badly, same error. Now I have something to do on the plane tomorrow.
ron
btw, this looks really broken: In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes
It's already there. Why copy it?
Hmm, REALMODE (was VM86) works fine for me on real hardware...
On 08.06.2009, at 05:33, ron minnich rminnich@gmail.com wrote:
On Sun, Jun 7, 2009 at 8:32 PM, ron minnichrminnich@gmail.com wrote:
I just did a build on v2 for qemu and it is failing badly, same error. Now I have something to do on the plane tomorrow.
ron
btw, this looks really broken: In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 copying VGA ROM Image from 000c0000 to 0xc0000, 0x8c00 bytes
It's already there. Why copy it?
Ah yes! On qemu a "real VGA card" is emulated, not "onboard graphics". Thus you must not pack the VGA rom into coreboot.rom
Also I believe you need a patched vgabios-cirrus.rom for qemu.
Stefan
On Sun, Jun 7, 2009 at 10:16 PM, Stefan Reinauerstepan@coresystems.de wrote:
Ah yes! On qemu a "real VGA card" is emulated, not "onboard graphics". Thus you must not pack the VGA rom into coreboot.rom
neither of us are packing it into coreboot.rom. The ROM is being found as an expansion ROM attached to the PCI device.
Then the code copies the ROM over itself (memcpy c0000 to c0000). This is probably not harmful, but definitely not needed, and quite wrong for real hardware.
Also I believe you need a patched vgabios-cirrus.rom for qemu.
I have the patched vgavios. This was all working for me a few weeks ago. This problem is something new, and I'm not sure what.
Interesting that it works on real hardware!
ron
On Mon, 8 Jun 2009 05:20:14 -0700, ron minnich rminnich@gmail.com wrote:
On Sun, Jun 7, 2009 at 10:16 PM, Stefan Reinauerstepan@coresystems.de wrote:
Ah yes! On qemu a "real VGA card" is emulated, not "onboard graphics".
Thus
you must not pack the VGA rom into coreboot.rom
neither of us are packing it into coreboot.rom. The ROM is being found as an expansion ROM attached to the PCI device.
Then the code copies the ROM over itself (memcpy c0000 to c0000). This is probably not harmful, but definitely not needed, and quite wrong for real hardware.
Also I believe you need a patched vgabios-cirrus.rom for qemu.
I have the patched vgavios. This was all working for me a few weeks ago. This problem is something new, and I'm not sure what.
Interesting that it works on real hardware!
Here is the output on real hardware:
On mainboard, rom address for PCI: 00:02.0 = fff00000 PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040 PCI ROM Image, Vendor 8086, Device 3577, PCI ROM Image, Class Code 030000, Code Type 00 copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes Real mode stub @00000500: 434 bytes Calling Option Rom...
what's interesting is that the qemu case is mostly like that. I am going to make sure I have the fixed qemu option rom. I wish we could get the qemu guys to actually fix the real thing.
ron
Fix attached for qemu.
It would be nice to know if this causes trouble for real hardware, but it should not.
ron
On 09.06.2009 0:52 Uhr, ron minnich wrote:
Fix attached for qemu.
Awesome! Thanks for spotting this!
It would be nice to know if this causes trouble for real hardware, but it should not.
ron
There are some problems with the way these interrrupts were managed. First, the CLI erases any knowledge of whether interrupts were enabled or disabled. Second, the STI works badly on qemu; we get an immediate INT #0 as soon as the STI happens.
Is this a Qemu bug?
This doesn't happen on real hardware but, that said, I don't think this code should be doing cli and sti.
Peter Stuge brought this up, and I think I remembered seeing somewhere that loading the IDT and some other stuff should be guarded by cli+sti because otherwise an interrupt could happen during the switch?!? Not sure. It looks highly unlikely that this would happen for us.
Peter? Alex? Do you guys have more insight?
This change fixes the observed qemu failures.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
I hope we find out why this is a problem, because a combination of cli+sti should never cause an interrupt that would not exist without cli+sti. If we can't I suggest we commit this in a few days (Acked-by: Stefan Reinauer stepan@coresystems.de) since it fixes the problem.
On Mon, Jun 8, 2009 at 11:29 PM, Stefan Reinauerstepan@coresystems.de wrote:
I hope we find out why this is a problem, because a combination of cli+sti should never cause an interrupt that would not exist without cli+sti. If we can't I suggest we commit this in a few days (Acked-by: Stefan Reinauer stepan@coresystems.de) since it fixes the problem.
I'm going to commit it. The reason is that we should never do an sti unless we are prepared to take a device interrupt, and we are not. I think it is an error to do an sti at this point. Also, just doing a cli/sti without determining that interrupts were enabled in the first place is also a mistake.
Thanks. Rene, this will fix your problem on qemu.
ron
Committed revision 1172.
On 09.06.2009 13:11 Uhr, ron minnich wrote:
On Mon, Jun 8, 2009 at 11:29 PM, Stefan Reinauerstepan@coresystems.de wrote:
I hope we find out why this is a problem, because a combination of cli+sti should never cause an interrupt that would not exist without cli+sti. If we can't I suggest we commit this in a few days (Acked-by: Stefan Reinauer stepan@coresystems.de) since it fixes the problem.
I'm going to commit it. The reason is that we should never do an sti unless we are prepared to take a device interrupt, and we are not. I think it is an error to do an sti at this point. Also, just doing a cli/sti without determining that interrupts were enabled in the first place is also a mistake.
I agree. Sorry for the premature action of me adding cli/sti to my original code submission. I only tested on real hardware (three boards, all with the same chipset)... This is a good example how complex interactions between components for seemingly trivial code can be.
Stefan
Yep now it's working. Thanks for the fix Ron!
Regards,
René
2009/6/9 Stefan Reinauer stepan@coresystems.de
On 09.06.2009 13:11 Uhr, ron minnich wrote:
On Mon, Jun 8, 2009 at 11:29 PM, Stefan Reinauerstepan@coresystems.de stepan@coresystems.de wrote:
I hope we find out why this is a problem, because a combination of cli+sti should never cause an interrupt that would not exist without cli+sti. If we can't I suggest we commit this in a few days (Acked-by: Stefan Reinauerstepan@coresystems.de stepan@coresystems.de) since it fixes the problem.
I'm going to commit it. The reason is that we should never do an sti unless we are prepared to take a device interrupt, and we are not. I think it is an error to do an sti at this point. Also, just doing a cli/sti without determining that interrupts were enabled in the first place is also a mistake.
I agree. Sorry for the premature action of me adding cli/sti to my original code submission. I only tested on real hardware (three boards, all with the same chipset)... This is a good example how complex interactions between components for seemingly trivial code can be.
Stefan
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
BTW, the way I fixed this.
one I realized the problem was bounded by x86_asm.S, I just did the usual 'bisect via hlt'.
in other words, put hlt instructions in this code at various places until you isolate the failing instruction. If you don't have a debugger it works very well. Infinite loop if the hlt worked, INT #0 if it did not. Then you can center on where the problem is.
ron
Stefan Reinauer wrote:
This doesn't happen on real hardware but, that said, I don't think this code should be doing cli and sti.
Peter Stuge brought this up, and I think I remembered seeing somewhere that loading the IDT and some other stuff should be guarded by cli+sti because otherwise an interrupt could happen during the switch?!? Not sure.
Indeed I assumed that interrupts were enabled before. If they are not, then no problem. But if they will be enabled at some point there can be issues. The IDT is one thing, but also the mode switching can cause trouble for the interrupts, or make interrupts cause trouble.
It looks highly unlikely that this would happen for us.
There is plenty of switching back and forth between PM and RM, but as long as interrupts are never enabled (also by option ROMs) then I don't think this matters.
//Peter
-
Joseph Smith -
Peter Stuge -
René Reuter -
ron minnich -
Stefan Reinauer