Strange PIT Problem

[Lionel]

Hi!
Here's my Problem:
On QEMU: IRQ0 is called once then stops. printk function prints a black line when it should print the tick it was on. tick is one.
On Bochs: Doesn't work at all, just sits there, no IRQ called ever. tick is 0.

This is abnormal, because I know I am sending a eoi to the PIC. (To both)

If it's worth anything, it's in C++.
Thanks for considering helping me,
Lionel

[AndrewBuckley]

-EOI only needs to go to the chips that expect it, i don't think the PIT timer trips the second chip.
-the handler cannot be in c++ alone.
-use qemus built in debugger, using a printk statement is a painfull way to debug.

[Lionel]

a.Yes, I'm sending it to the correct chips, always master, and slave if it is sent from it.
b.There is a assembly stub that sets the correct values of regs and then calls the C++ handler (Uses extern "C").
c.Qemu has one of those? I thought bochs was the only one.

[AndrewBuckley]

try commenting out the call to the c++ code to make sure your assembly code is actually working.

[Chandra]

IRQ0 is called once then stops.

Make sure the PIT is programmed to 'Periodic Interrupt Mode' not the 'One shot Mode'.

Qemu has one of those? I thought bochs was the only one.

In any case, you didn't give the debugger a try.

[Lionel]

Sorry, I'm just hopeless with working with debuggers. Could never get GDB to work, Ever.
Anyway, Im iffy about the line with the star:
This is how I setup my PIT:

Code: Select all

void pit_init(uint32_t frequency)
{
	register_interrupt_handler(IRQ0, &irq_callback);
	uint32_t divisor = 1193180 / frequency;
	koutb(0x43, 0x36); //* This is were I set the mode, right?
	koutb(0x40, divisor & 0xFF);
	koutb(0x40, divisor >> 8);
}

I tried setting it to 0x34, but that causes !emu to do the same thing as Bochs.

[brain]

Just a quick half on topic note about your os and pit interrupts. in your code in descriptor_tables.cpp line 117 you point out that once you have usermode up you need to logic-or the flags with 60h to allow users to call the gate. however you wouldn't want users calling all the gates Willy nilly, this would be very dangerous, just making sure you knew

[Lionel]

Sorry, I posted that at 1am. I know that is the command byte to the pit so I can send the MSB and LSB.
Brain: Really? Okay, I remember that when I voyage into usermode.
Also, I checked the code with a third party, James Molloy's tutorial. It is exactly the same and it still fails.
I did fix a couple issues, but they didn't help.

[VolTeK]

Sorry, I'm just hopeless with working with debuggers. Could never get GDB to work, Ever.

Id suggest you learn quick, or we will be seeing you more about different problems to the same solution. It will save you time to find small mistakes, and they grow if ignored. In fact its higher priority to learn debugging then to get to work on an operating system, let alone a Bootloader.

As a good friend told me, Anything, can happen in kernel mode. Can be for random reasons that a buffer will over run, or that you will be experiencing code executing that you have never called for and it may not even be yours, and the problem will come from places you didn't think would cause it. A Debugger will help.

I really don't know how much more i can stress this, its very important you learn debugging if you really want to get into this. Even if it means loosing an eye (unless.. you only have one) read up, spend some time on it. I promise, i don't know where id be right now without one. I sure as hell wouldn't be doing the things i never thought i could that i am right now with my projects.

If you continue to ignore this, the small questions will annoy many on here, you will get stuck and you quite possibly will never move on

[Lionel]

VolTek: Alright, I guess I should attempt to learn again.

[Lionel]

Update:
Still couldn't get it to work after trying for days to fix it. I used GDB and nothing looked out of the ordinary. Tried printf debugging, still didn't find anything. I'm still thinking it's either a problem with the code, C++ and C intermixing, or the way gcc(++) compiles it. Honestly, this is the most annoying bug I have ever found! Not giving up though...

P.S: Sorry for the double post... Wait, does that apply?

[bubach]

I had a quick look at your source, but when you init the PIT I couldn't find any code where you actually enable the IRQ? Here's how.
Btw, I use 0x34 for the PIT setup, not 0x36 - but can't even remember what that value stands for since it's been like > 5 years since i wrote it - just wondering why you changed to 0x36?

[JamesM]

I had a quick look at your source, but when you init the PIT I couldn't find any code where you actually enable the IRQ? Here's how.
Btw, I use 0x34 for the PIT setup, not 0x36 - but can't even remember what that value stands for since it's been like > 5 years since i wrote it - just wondering why you changed to 0x36?

8259 defaults to all IRQs unmasked.

[bubach]

Ops, didn't notice he had a general IRQ handler that was always taking care of them. I mask everything and only unmask for when there's actually some code to run.