bochs: where does exception 0xff come from?

[mduft]

Hey

Now that my kernel runs stable on qemu, i thought it's time to fix it for the others (bochs/vbox). sad thing: it crashes in both, but wahtever, thats live of a kernel developer ;D

in bochs, i'm reliably getting an exception after like the 25th thread wants to run. all bochs debug info enabled, it tells me this:

Code: Select all

04261029740d[CPU0 ] page walk for address 0xffffffff81000020
04261029740d[APIC0] LAPIC read from register 0x0020
04261029740d[APIC0] read from APIC address 0x00000000fee00020 = 00000000
04261029804d[APIC0] LAPIC read from register 0x0020
04261029804d[APIC0] read from APIC address 0x00000000fee00020 = 00000000
04261029847d[CPU0 ] interrupt(): vector = ff, TYPE = 0, EXT = 1
04261029847e[CPU0 ] interrupt(long mode): vector must be within IDT table limits, IDT.limit = 0x3bf
04261029847d[CPU0 ] exception(0x0d): error_code=07fa
04261029847d[CPU0 ] interrupt(): vector = 0d, TYPE = 3, EXT = 1
04261029847d[CPU0 ] interrupt(long mode): INTERRUPT TO SAME PRIVILEGE

now my kernel logs tell me that

Code: Select all

fatal: unhandled interrupt 13 @ 0xffffffff8011d345

and the disassembly of that address tells me that the double fault occoured here:

Code: Select all

        ...
        if(doIt)
ffffffff8011d339:       80 7d ec 00             cmpb   $0x0,-0x14(%rbp)
ffffffff8011d33d:       74 01                   je     ffffffff8011d340 <intr_enable+0x48>
            asm volatile("sti");
ffffffff8011d33f:       fb                      sti    

        return true;
ffffffff8011d340:       b8 01 00 00 00          mov    $0x1,%eax
ffffffff8011d345:       eb 05                   jmp    ffffffff8011d34c <intr_enable+0x54>
    }

    return false;
ffffffff8011d347:       b8 00 00 00 00          mov    $0x0,%eax
}
ffffffff8011d34c:       48 83 c4 18             add    $0x18,%rsp
ffffffff8011d350:       5b                      pop    %rbx
ffffffff8011d351:       5d                      pop    %rbp
ffffffff8011d352:       c3                      retq   
        ...

any ideas where the hell interrupt 0xff could come from? is it hardware? is it a bug in the kernel? is it a bug in bochs (i don't assume so)? in virtualbox the kernel crashes too, but with different symptoms. however i still think the crashes could be related somehow.

any hints would be great!

thanks!

[stlw]

Hey

any ideas where the hell interrupt 0xff could come from? is it hardware? is it a bug in the kernel? is it a bug in bochs (i don't assume so)? in virtualbox the kernel crashes too, but with different symptoms. however i still think the crashes could be related somehow.

any hints would be great!

thanks!

LAPIC has spurious interrupt vector register (SVR) at address 0xFEE000F0H. Its default value is 0xFF.
From the Intel SDM book:

Code: Select all

A special situation may occur when a processor raises its task priority to be greater
than or equal to the level of the interrupt for which the processor INTR signal is
currently being asserted. If at the time the INTA cycle is issued, the interrupt that
was to be dispensed has become masked (programmed by software), the local APIC
will deliver a spurious-interrupt vector. Dispensing the spurious-interrupt vector does
not affect the ISR, so the handler for this vector should return without an EOI.

Bochs code bx_local_apic_c::acknowledge_int:

Code: Select all

  int vector = highest_priority_int(irr);
  if (vector < 0) goto spurious;
  if((vector & 0xf0) <= get_ppr()) goto spurious;

Stanislav

[mduft]

thanks for the hint! haha. while wrinting a post stating that i _do_ assign a different vector, i saw that i did a '|=' instead of a '='. that won't help when the value is already 0xff

now on to the next problems