I have a working kernel which has been working for a few years without problems. Been using djgpp and vmware to develop and debug. Used bochs sometimes but not mainly.
Now i converted all my makefiles etc to work in linux and i use gcc for compiling and bochs for simulation. Now i have a problem. First of all i have some suspicion that gcc makes some .sections that not djgpp made. I have been cleaning up in my ld.script and now that seems ok too.
But then... after everything is away.. I sometimes (when moving data in memory) and maby other times get an interrupt.. (int 239 if im not mistaking) it goes directly to an Unhandled() function and stops the kernel. Without the isr entry i get a fault that the gate is not present.
What in hell is this int 239?? I have been looking around but cant find anything.. Can it be some dma stuff or something??
-
Thomas
Unknown interrupt problems.
Re: Unknown interrupt problems.
Hi,
It might be a software interrupt, if you do an "int 239" or if you accidentally execute unknown data. I'm guessing this is extremely unlikely (you'd probably know if you used "int 239" deliberately, and you'd probably crash if it was being used accidentally).
If it's not a software interrupt then it has to be a hardware interrupt. It might be coming from the PIC chip/s, the I/O APIC, the local APIC/s, from a PCI device using MSI or from the chipset itself.
Without any way of knowing, I'd guess you've mapped the PIC chips to generate IRQs 0xE0 to 0xEF, and the IRQ is coming from the slave PIC's spurious IRQ (or perhaps IRQ 0x15).
Cheers,
Brendan
It's not an exception.thomasnilsen wrote:What in hell is this int 239?? I have been looking around but cant find anything.. Can it be some dma stuff or something??
It might be a software interrupt, if you do an "int 239" or if you accidentally execute unknown data. I'm guessing this is extremely unlikely (you'd probably know if you used "int 239" deliberately, and you'd probably crash if it was being used accidentally).
If it's not a software interrupt then it has to be a hardware interrupt. It might be coming from the PIC chip/s, the I/O APIC, the local APIC/s, from a PCI device using MSI or from the chipset itself.
Without any way of knowing, I'd guess you've mapped the PIC chips to generate IRQs 0xE0 to 0xEF, and the IRQ is coming from the slave PIC's spurious IRQ (or perhaps IRQ 0x15).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
OOppps i did it again..
Sorry.. i was a litte to quick on last post. Its not int 239 (wich is 0xEF which i use for my syscall.. 0xCDEF 
It was 39... see debug log from bochs under:
-- snip --
00015685651d[CPU ] interrupt(): vector = 39, INT = 0, EXT = 1
00015685651e[CPU ] interrupt(): gate not present
00015685651d[CPU ] exception(0x0B)
00015685651d[CPU ] interrupt(): vector = 11, INT = 0, EXT = 1
00015685651d[CPU ] int_trap_gate286(): INTERRUPT TO SAME PRIVILEGE
00015685652i[CPU ] WARNING: HLT instruction with IF=0!
-- snip --
0x0B is double fault,, but the int 39 is what causes it it seems since that is not resolved.. of course since its not added... But what is this interrupt?? Any ideas? This dont happen on vmware so must be some virtual-hardware specific??
cheers
Thomas
It was 39... see debug log from bochs under:
-- snip --
00015685651d[CPU ] interrupt(): vector = 39, INT = 0, EXT = 1
00015685651e[CPU ] interrupt(): gate not present
00015685651d[CPU ] exception(0x0B)
00015685651d[CPU ] interrupt(): vector = 11, INT = 0, EXT = 1
00015685651d[CPU ] int_trap_gate286(): INTERRUPT TO SAME PRIVILEGE
00015685652i[CPU ] WARNING: HLT instruction with IF=0!
-- snip --
0x0B is double fault,, but the int 39 is what causes it it seems since that is not resolved.. of course since its not added... But what is this interrupt?? Any ideas? This dont happen on vmware so must be some virtual-hardware specific??
cheers
Thomas
How is your PIC programmed? I mean, what is the offset for your irq's? I can imagine you programmed the master-pic to start at a certain vector/gate. I don't know bochs thoroughly, but I believe EXT=1 is giving the clue that the origin of the interrupt is external. So it could be the PIC...
Otherwise, I don't have a clue at all...
Otherwise, I don't have a clue at all...
Just a random guess:
1. You remapped the PIC to 0x20 to 0x2F.
2. You disable IRQ's very shortly and then reenable them.
3. You handle interrupts for some devices.
4. You don't know about spurious interrupts yet.
Solution: In the IRQ7 handler, check in the interrupt flags whether an interrupt was triggered. If not, ignore.
1. You remapped the PIC to 0x20 to 0x2F.
2. You disable IRQ's very shortly and then reenable them.
3. You handle interrupts for some devices.
4. You don't know about spurious interrupts yet.
Solution: In the IRQ7 handler, check in the interrupt flags whether an interrupt was triggered. If not, ignore.
Mysterius bochs interrupt
This is basically what i do:
inst are disabled upon boot
Mask off all irq lines
Map irq0-7 to pic1
Map irq8-15 to pic2
Mask off all IRQ's
Adds irq0 isr timer (32)
Unmask irq0 (pit timer)
Adds irq1 isr keyboard handler (33)
Unmask irq1 (keyboard)
while(true)
Thats roughley whats done.... I can mention that this problem makes the kernel when running in vmware go smooth without any problems anywhere. But on bochs it almost wont handle anything before crashing... I i leave the bochs kernel alone after booting it works, but when i write a command in console... it halts... after i have pressed enter to execute the command. Some commands do not crash and some do... seems to be totaly random....
I have a floppy image here if someone likes to take a look:
http://84.247.152.125:8080/kernel.img
write 'help' after boot to get a list of known commands..
-
Thomas
inst are disabled upon boot
Mask off all irq lines
Map irq0-7 to pic1
Map irq8-15 to pic2
Mask off all IRQ's
Adds irq0 isr timer (32)
Unmask irq0 (pit timer)
Adds irq1 isr keyboard handler (33)
Unmask irq1 (keyboard)
while(true)
Thats roughley whats done.... I can mention that this problem makes the kernel when running in vmware go smooth without any problems anywhere. But on bochs it almost wont handle anything before crashing... I i leave the bochs kernel alone after booting it works, but when i write a command in console... it halts... after i have pressed enter to execute the command. Some commands do not crash and some do... seems to be totaly random....
I have a floppy image here if someone likes to take a look:
http://84.247.152.125:8080/kernel.img
write 'help' after boot to get a list of known commands..
-
Thomas
Case closed.
Hmmm,,, spurious interrrupts.. Strange
I just added an Interrupt gate on the isr for irq7 and just did it make iretd and now everything works
Yeeeehaaa! Thanks alot for helping out!
cheers
Thomas
I just added an Interrupt gate on the isr for irq7 and just did it make iretd and now everything works
Yeeeehaaa!
Thanks alot for helping out!cheers
Thomas