Request for help with QEMU log

[eryjus]

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!

[eryjus]

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.

[JamesM]

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

[bluemoon]

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?

[eryjus]

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.

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.

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!

[Kevin]

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.

[eryjus]

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