Different behaviours in bochs and qemu [solved]

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
dawix
Posts: 15
Joined: Thu Oct 20, 2011 10:10 pm

Different behaviours in bochs and qemu [solved]

Post by dawix »

Hi,
my kernel runs perfectly in qemu, but when i run it with bochs after few seconds of task switching it stops with an exception n 13 should be the bad tss exception. 5 o 6 times the task switch occours because each process prints a different message.
Now...if it have to comply about the tss, why after several switches?! sometimes after 50. I do not alloc nothing new the 2 tasks tey just enter in an endless loop and they write a character on the screen. STRANGE

this is the interesting part in the bochs output:

Code: Select all

00803208341e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x27)


looks like that an hardware interrupt fires?! i have masked all the irqs except the irq0 for the timer and that is mapped at 0x20.

Thanks for the help
Dave
dawix
Posts: 15
Joined: Thu Oct 20, 2011 10:10 pm

Re: Different behaviours in bochs and qemu [solved]

Post by dawix »

Ok...few minutes to remember that i do not put an entry in the idt table for the irq7 = offset 39 in my remapping of the irqs = 0x27...
Anyway qemu do not complain even without it if the irq do not fires. Looks like bochs uses that irq line for some reasons and test if it have an entry in the idt.
I repeat, the irq line is also masked and the only one not masked is for the timer, irq0. Bochs just complains for IRQ37 i can put all zeros in the other entries of the IDT.

But now it works :D
User avatar
xenos
Member
Member
Posts: 1114
Joined: Thu Aug 11, 2005 11:00 pm
Freenode IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Different behaviours in bochs and qemu [solved]

Post by xenos »

I've never seen IRQ7 randomly fire on Bochs... On real hardware IRQ7 usually is a "spurious interrupt", and I indeed observed it on some PCs.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Post Reply