Bochs PIT not firing?

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
Ready4Dis
Member
Member
Posts: 571
Joined: Sat Nov 18, 2006 9:11 am

Bochs PIT not firing?

Post by Ready4Dis »

Ok, I am working on some multitasking code and am having problems with the PIT not firing properly. If I put a single task in my queue, the PIT fires perfectly fine.... when i add a second task, it stops firing. I know my task switching code works fine, because if I issue interrupt 0x20 manually from each task they switch back and forth and play happy. Now, the thing is, I am definetly issuing EOI at the end of each interrupt, and as I stated, if I only have one in the list (so it keeps jumping back to the same one), it works perfectly. It seems that every time I change ESP, the PIT stops functioning. Are there any known issues with the newer releases of Bochs? Why after issuing the EOI, would the interrupt stop triggering? I have printing a lot of debug info from my kernel, like making sure the IDT wasn't getting whacked, i tried re-enabling interrupts, re-setting the PIC, tried masking all PIC Int's and numasking, nothing would turn the PIT back on. But, like I mentioned, if I don't modify ESP (even though i push it, and reload it with the same value), it works fine. I even stripped it down so all process' are in the same thread, just using different esp & eip, everything else is the same. If I issue the 0x20 manually, it multi-tasks properly, so my stacks and such are all functioning properly, my IDT entries are not getting hosed, I am not changing page tables anymore (was originally, but removed it for testing), and I am issuing an EOI after each interrupt. At this point, it looks like a bug in Bochs, but my old multitasking code used to work fine, under an older version, and it was asm code, not C, so it's not 100% identical.
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

I'm using 2.3.5 (fairly recent) and it works just fine.
You might want to increment a counter in your IRQ0 handler -- and watch if it really is getting triggered. Maybe there is an IRET or STI that you are avoiding doing, in the second case -- and interrupts are not being re-enabled?
Somehow, I'll bet that the problem is in your interface between the IRQ0 handler, and your scheduler.
User avatar
inx
Member
Member
Posts: 142
Joined: Wed Mar 05, 2008 12:52 am

Post by inx »

I don't have the manual at hand, so take this with a grain of salt, but I recall it being mentioned in the i386 manual that interrupts are masked either after ESP is loaded via a mov until SS is loaded or vice versa.
Hangin10
Member
Member
Posts: 162
Joined: Wed Feb 27, 2008 12:40 am

Post by Hangin10 »

inx wrote:I don't have the manual at hand, so take this with a grain of salt, but I recall it being mentioned in the i386 manual that interrupts are masked either after ESP is loaded via a mov until SS is loaded or vice versa.
I think it's just that interrupts are disabled for a single instruction after a load to SS.
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

Actually, let me make a wildass guess.
Please post the code for how you set EFLAGS on its kernel stack, for the second task, before it gets run the very first time. I'll bet that you have the Interrupt flag off.
User avatar
inx
Member
Member
Posts: 142
Joined: Wed Mar 05, 2008 12:52 am

Post by inx »

Hangin10: Yep, you're right. Brainstorming = toaster in the bathtub of my mind.
Ready4Dis
Member
Member
Posts: 571
Joined: Sat Nov 18, 2006 9:11 am

Post by Ready4Dis »

bewing wrote:Actually, let me make a wildass guess.
Please post the code for how you set EFLAGS on its kernel stack, for the second task, before it gets run the very first time. I'll bet that you have the Interrupt flag off.
Well, I set eflags = 0x0202, just like my old multitasking code that operates correctly, and I even tried an sti call to re-enable interrupts just incase they were not on, neither of which solved the problem. I will try reloading ss, just incase that is a problem as suggested above. Right now I am going from ring0->ring0, so nothing out of the ordinary. I tried remaskin the PIC and re-enabling ints, and still nothing fires. When I call my change task function from the timre interrupt, and it stays on the original task, it will fire all day long, but as soon as a new task is added, and it switches to a knew one instead of re-calling the original, it runs the new task and never fires the interrupt again. Now, if I issue the interrupt manually, it will fire and change back to the original task, which tells me that my code for pusing/popping tasks is operating as it should be, and my task switching code is ok. My eflags should be fine, 0x202 sets bit 9 and 2, 9 being external int enable. Maybe I can try printing out the value of eflags before restoring it to make sure it's not getting hosed, but when I originally put it on the stack I put 0x0202, so I don't see how it'd get messed up if everything else stays correct (EIP, ESP, etc).


--- Edit/Update --
Ok, a little more playing around today, and I figured it out. I needed to push an extra value on the stack before eflags. I'm still not 100% sure why that made a difference, but it did, my PIT now fires happily along. It's weird, because I thought IRET only pushed/poped ESP/SS if it was a priveladge change (at least that's what the manuals say), but if it appears like it was trying top pop an invalid SS (weird, because bochs never crashes or complains), but it definetly was the problem because it is now working, thanks for all the brainstorms guys.
Post Reply