OSDev.org

Posted: **Tue Sep 11, 2012 6:44 pm**

Hi,

I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log:

Code: Select all

qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G

Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line):

Servicing hardware INT=0xffffffff
1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000
EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780
ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768
EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl
GDT= 00127760 00000027
IDT= 00122f40 000007ff
CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=0012b75c CCO=ADDL
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000
EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780
ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768
EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl
GDT= 00127760 00000027
IDT= 00122f40 000007ff
CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=0012b75c CCO=ADDL
EFER=0000000000000000

To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from.

By the way, it does not happen with every execution, which is maddening.

Thanks for your help!

Posted: **Tue Sep 11, 2012 9:34 pm**

Found this link: http://lists.gnu.org/archive/html/qemu- ... 01940.html... The thread is 2 years old and the patch has not been committed to the current code release.

Posted: **Wed Sep 12, 2012 1:55 am**

Have you tried recompiling qEmu with all its debugging enabled? That should tell you what is raising the interrupt. I agree it looks weird.

Posted: **Wed Sep 12, 2012 9:48 am**

You are running qemu-system-i386, I think this has little to do with the bug you posted which related to do_interrupt64.
Are you sure the #GP is not caused by a programming bug in your OS?

The patch does this:

Code: Select all

if (!apic_accept_pic_intr(env)) {
    //return -1;
}

So, does your OS properly initialized APIC? And do this happen without SMP?

Posted: **Wed Sep 12, 2012 11:18 pm**

bluemoon wrote:Are you sure the #GP is not caused by a programming bug in your OS?

When I work in Bochs, the GPF does not happen. I cannot say that my OS is working perfectly, but I can say that the INT 0xffffffff is generated on QEMU followed immediately by an INT0x0d with no code execution between. I do not get that same behavior in Bochs or Rebochs.

bluemoon wrote:So, does your OS properly initialized APIC?

I presume so. It worked as expected on real hardware, generating interrupts at the frequency I requested. However, that is not necessarily a guarantee. It worked well before I started coding for processes and the scheduler.

bluemoon wrote:And do this happen without SMP?

OK, so here is where it gets interesting...

This command works:

Code: Select all

qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G

This command works:

Code: Select all

qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G

And, as in my original post, this does not:

Code: Select all

qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G

And finally, I found in linux-user/main.c:

Code: Select all

#if defined(TARGET_I386)
int cpu_get_pic_interrupt(CPUX86State *env)
{
    return -1;
}
#endif

Now, I didn't dig enough to determine if the QEMU implementation blends the PIC and APIC code. But at this point, I most likely have a bug in QEMU and need to change my audience.

Thanks for the help!

Posted: **Thu Sep 13, 2012 1:31 am**

eryjus wrote:And finally, I found in linux-user/main.c

You're using the system emulator, not the Linux userspace emulator, so this code is not even built into qemu-system-i386.

Posted: **Thu Sep 13, 2012 8:59 am**

Kevin wrote:
eryjus wrote:And finally, I found in linux-user/main.c
You're using the system emulator, not the Linux userspace emulator, so this code is not even built into qemu-system-i386.

Thanks for the clarification.

Edit: in case anyone wants to track the bug report: https://bugs.launchpad.net/qemu/+bug/1050694

OSDev.org

Request for help with QEMU log

Request for help with QEMU log

Re: Request for help with QEMU log

Re: Request for help with QEMU log

Re: Request for help with QEMU log

Re: Request for help with QEMU log

Re: Request for help with QEMU log

Re: Request for help with QEMU log