Hello, everyone!
I recently finished with ACPI parsing and successfully got LAPIC, IO APIC addresses and now trying to get HPET or PIT working (if HPET is not available). However, despite spending several days debugging and re-reading the wiki articles several times, I still can't get either timer to work. When running from HPET, the interrupt is called once and then fails. When using PIT, the handler is not called at all.
My guess is that the problem is probably either in how the IRQ is routed through the APIC IO, or in acknowledgement
Here is my code for this part of operating system:
ACPI: header, source
Timer: source
PS in the given links not all the content is indicated, as the files are quite large and I have given the necessary parts for easier reading
HPET is enabled, but the interrupt handler is called once
-
- Member
- Posts: 186
- Joined: Tue Aug 26, 2008 11:24 am
- GitHub: https://github.com/sebihepp
Re: HPET is enabled, but the interrupt handler is called once
Declare the variable ticks as volatile - maybe the compiler optimizes it away.
Re: HPET is enabled, but the interrupt handler is called once
Been using HPET for a couple of years but all in assembly, why do you have to declare your own Frequency?, did you re-map all IRQs in accordance to Maximum Redirection Entry?
-
- Member
- Posts: 5577
- Joined: Mon Mar 25, 2013 7:01 pm
Re: HPET is enabled, but the interrupt handler is called once
Why does hpet_eoi write to the APIC EOI register twice?
Why do you route PIT interrupts through the PICs and HPET interrupts through the APICs?
Are you trying to use PICs and APICs at the same time?
Which virtual machine are you using? QEMU has monitor commands ("info pic" and "info lapic") you can use to check the interrupt controllers.
What is the CPU doing when the second interrupt is supposed to arrive? Are interrupts enabled?
Why do you route PIT interrupts through the PICs and HPET interrupts through the APICs?
Are you trying to use PICs and APICs at the same time?
Which virtual machine are you using? QEMU has monitor commands ("info pic" and "info lapic") you can use to check the interrupt controllers.
What is the CPU doing when the second interrupt is supposed to arrive? Are interrupts enabled?