Spurious interrupt 0x2C on bochs with SMP only

[mduft]

Hey!

I'm starting out implementing/researching SMP for my kernel, now that i have threading and userspace in place without it Now, without any modification my fine-running kernel crashes as soon as i compile bochs with --enable-smp (it works with QEMU). The problem i'm facing is a spurious interrupt 0x2C. from what i see when debugging this code from bochs' apic.cc:

Code: Select all

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

Code: Select all

(gdb) p /x irr
$19 = {0x0 <repeats 44 times>, 0x1, 0x0 <repeats 211 times>}
(gdb) p /x isr
$20 = {0x0 <repeats 35 times>, 0x1, 0x0 <repeats 220 times>}
(gdb) p /x get_ppr()
$21 = 0x20
(gdb) p /x vector
$22 = 0x2c

Thus it seems that the ISR bit for 0x20 (35) is still set while 0x2C (44) arrives, and PPR is 0x20 (reasonable because ISR 0x20 is set). This causes a spurious interrupt All seems somewhat reasonable (although i don't like it ). however, why does this only occur as soon as i compile bochs with SMP support (also with only one cpu configured in bochsrc!). Also i have 0x2C = RTC (IRQ8) and 0x20 = LAPIC Timer. is this a bad setup? is there a problem with priorities in this case?

the actual problem why i found this issue is that my spurious interrupt vector makes the kernel crash because it is (seems so) not reentrant

oh - and my spurious interrupt vector is currently 33 (0x21), thus a higher priority than all others... bad?

Thanks, Markus

[mduft]

interesting. it seems that the problem is not (only) related to my kernel. it's a combination of problems it seems. the kernel now runs find on SMP bochs, after i reverted a commit on the kernel (which changed only comments and the bochs config (to increase no of CPUs), manually increased the CPU count again, rebuilt bochs, and now it runs (nearly always). Very rarerly i get a pagefault at boot, but i don't doubt that my kernel is the bad guy here