Disabling the PIT 0 timer

[durand]

Is there any way to disable the PIT 0 timer and not have it generate an IRQ 0 request?

I'm trying to resolve a problem I'm having with IRQs and I think it happens on some machines (and vmware) when IRQ 0 is masked but has interrupts pending. Basically, my idle threads are not being woken up when they're in a cpu hlt'ed state and interrupts are enabled. An IRQ should wake them up but they just sleep forever. Displaying the value of the interrupt request register of the PIT shows an IRQ 0 waiting to be serviced.

I'm not using the PIT 0 timer for anything and I don't want to have to service it all the time. Masking seems to have some problems. So disabling would be perfect.

Alternatively, is there a more creative solution?

[earlz]

I'm not using the PIT 0 timer for anything and I don't want to have to service it all the time. Masking seems to have some problems. So disabling would be perfect

your not making any sense I'm a bit inexperienced but if you have problems with threads not waking up then why would you need to disable pit0

[Brendan]

Hi,

Is there any way to disable the PIT 0 timer and not have it generate an IRQ 0 request?

There's isn't a "normal" way (like an enable/disable flag in the PIT itself), but it should be possible to program it for "one-shot" mode. In this case you won't get any IRQs unless you program the timer's count.

I'm trying to resolve a problem I'm having with IRQs and I think it happens on some machines (and vmware) when IRQ 0 is masked but has interrupts pending. Basically, my idle threads are not being woken up when they're in a cpu hlt'ed state and interrupts are enabled. An IRQ should wake them up but they just sleep forever. Displaying the value of the interrupt request register of the PIT shows an IRQ 0 waiting to be serviced.

I'm not using the PIT 0 timer for anything and I don't want to have to service it all the time. Masking seems to have some problems. So disabling would be perfect.

Alternatively, is there a more creative solution?

What you've described sounds like an unmasked IRQ0 that's blocking further IRQs - most likely something left over after initialization. I'd guess that during boot you disable IRQs with the CLI instruction, then initialize everything (protected mode, etc), and then enable IRQs with STI. Any IRQ received between the CLI and the STI won't be handled, so the EOI isn't sent which blocks further IRQs after the STI. In this case it would work sometimes but not others (depending on whether you get an IRQ during initialization or not).

There would be 2 ways to solve this. The first way is to mask all IRQs before you do the CLI (before protected mode initialization, etc), so that unhandled IRQs can't happen during initialization. The second way would be to send EOI/s to the PIC just before doing the STI (after protected mode initialization, etc) to clear any unhandled IRQs that have occured.

If my guessing is correct, then disabling the PIT will only hide the problem - any IRQ that is received at the wrong time would cause the same problem, it's just that IRQ0 is the most likely IRQ and is also the highest priority IRQ (remembering that only lower priority IRQs are blocked when an EOI isn't sent).


Cheers,

Brendan

[mystran]

Are we sure this isn't spurious interrupts striking again?

[Brendan]

Hi,

Are we sure this isn't spurious interrupts striking again?

Yes - a spurious interrupt doesn't set any of the flags in the ISR/IRR and won't cause other IRQs to be blocked...

AFAIK (and I'm mostly guessing) it's more of a "CLI solves everything" problem (where in reality, the CLI instruction causes more hassles than it solves half the time).

For an example, it's possible to mask all IRQs, then switch to protected mode, setup paging, remap the PIC, initialize memory management, etc, and then unmask the IRQs without ever using a CLI instruction (and without having the "unhandled IRQs" problem).

I guess what I'm saying is that if you need to disable interrupts for more than 10 instructions (except for within the code that does task switches), then there's probably a better way you've overlooked...


Cheers,

Brendan

[Ryu]

This may or may not work on all standard x86 systems, where I only have Bochs and my system to do testing. I think you can just use mode 5 (Hardware Triggered Strobe) for counter 0 to basically disable it from interrupting. It doesn't stop the counter register but I have yet to find a method for that mode to generate a interrupt. It can be a easier way then using One Shot as Brendan pointed out.

[durand]

Thanks. I set the PIT to mode 0 and now I only receive one IRQ which I ack and carry on. Unfortunately, I still have the problem I was trying to solve... So.. I have to think of something else that could be wrong.