OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 10:38 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Getting hard interrupts working (soft interrupts work)
PostPosted: Tue Jul 04, 2017 1:00 am 
Offline

Joined: Tue Jul 04, 2017 12:45 am
Posts: 15
I am using QEMU/GRUB2 to boot my kernel, so system is already in protected mode once I get execution. I have managed to get software interrupts working, but hardware interrupts still fail when triggered (I have been testing with #1, the keyboard). I am able to successfully:

    - Execute and return from the interrupt handler (ASM and C) installed in the IDT via software interrupts (e.g. int 1)
    - Mask/unmask the keyboard interrupts and observe that interrupts are not received when masked (and keys are struck on the keyboard)

I've written the ISR to write to the video buffer so I can be informed when something happens. This works as expected with software interrupts. However, when triggered via hardware (e.g. hitting a button on the keyboard), QEMU will just triple fault and restart. As such, the ISR does not appear to be being executed when triggered in this way.

As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?


Top
 Profile  
 
 Post subject: Re: Getting hard interrupts working (soft interrupts work)
PostPosted: Tue Jul 04, 2017 1:55 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
pragmatic wrote:
As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?

Like what? Which specific Wiki page are you referring to?

You have re-mapped the PIC? Have you enabled paging (could a page fault occur)?

Add a #DF handler to see what the original fault is.. Also debug with gdb to see what exactly happens. There's an article about gdb in the Wiki I think.

PS. I'd recommend adding all the ISR's that are possible (based on what you set as limit in the IDTR), such that those ISR's simply print an error and halt (ie. kpanic). Then replace those ISR's one by one with real ones. The benefit is that if any unexpected interrupt occurs you'll know about it immediately..


Top
 Profile  
 
 Post subject: Re: Getting hard interrupts working (soft interrupts work)
PostPosted: Tue Jul 04, 2017 3:18 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
pragmatic wrote:
I am using QEMU/GRUB2 to boot my kernel, so system is already in protected mode once I get execution. I have managed to get software interrupts working, but hardware interrupts still fail when triggered (I have been testing with #1, the keyboard). I am able to successfully:

    - Execute and return from the interrupt handler (ASM and C) installed in the IDT via software interrupts (e.g. int 1)
    - Mask/unmask the keyboard interrupts and observe that interrupts are not received when masked (and keys are struck on the keyboard)

I've written the ISR to write to the video buffer so I can be informed when something happens. This works as expected with software interrupts. However, when triggered via hardware (e.g. hitting a button on the keyboard), QEMU will just triple fault and restart. As such, the ISR does not appear to be being executed when triggered in this way.

As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?


I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Getting hard interrupts working (soft interrupts work)
PostPosted: Tue Jul 04, 2017 10:13 pm 
Offline

Joined: Tue Jul 04, 2017 12:45 am
Posts: 15
LtG wrote:
Like what? Which specific Wiki page are you referring to?


Mostly http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working.

LtG wrote:
You have re-mapped the PIC? Have you enabled paging (could a page fault occur)?


I did intentionally skip the remapping step. I saw it more as a required step after I was sure my GDT/IDT were working properly. Of course, this turned out to be exactly my problem.

LtG wrote:
Add a #DF handler to see what the original fault is.. Also debug with gdb to see what exactly happens. There's an article about gdb in the Wiki I think.


I have been using GDB, but it turns out that improper configuration was causing the triple fault. It's hard to debug the GDT/IDT configuration when the behavior is a hardware-driven triple fault. Now that I understand the problem I can do this more effectively.

Brendan wrote:
I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").


This is exactly what the problem was. As mentioned above, I was planning to remap the PIC once I was sure my interrupt configuration was sound. Your wording is a bit confusing, though. My IDT had only a single entry at index 1 (for what I was interpreting to be IRQ1). I was able to successfully execute/return from this interrupt by issuing:

Code:
int 1


After this comment, I added the same entry to index 9 of my IDT and was able to properly handle interrupts from the keyboard.

I suppose I was thinking of the entries in the IDT as "IRQ" handlers, rather than "INT" handlers. It seems they just share the same handler space but with different mappings.
It's mentioned here: http://wiki.osdev.org/PIC#The_IBM_PC.2FAT_8259_PIC_Architecture


Top
 Profile  
 
 Post subject: Re: Getting hard interrupts working (soft interrupts work)
PostPosted: Wed Jul 05, 2017 11:00 pm 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
pragmatic wrote:
Brendan wrote:
I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").


This is exactly what the problem was. As mentioned above, I was planning to remap the PIC once I was sure my interrupt configuration was sound. Your wording is a bit confusing, though. My IDT had only a single entry at index 1 (for what I was interpreting to be IRQ1).


You had set your IDTR limit to 0-1, which means any INT higher than 1 would cause an exception (#GPF), but because you don't have a handler for #GPF (13/0xD, but your limit says only 0 and 1 are valid handlers) it can't be started -> causes double fault (#DF, 8/0x8), which of course you don't have either and thus can't be started -> triple fault -> reboot.


Top
 Profile  
 
 Post subject: Re: Getting hard interrupts working (soft interrupts work)
PostPosted: Thu Jul 06, 2017 7:41 am 
Offline

Joined: Tue Jul 04, 2017 12:45 am
Posts: 15
LtG wrote:
You had set your IDTR limit to 0-1, which means any INT higher than 1 would cause an exception (#GPF), but because you don't have a handler for #GPF (13/0xD, but your limit says only 0 and 1 are valid handlers) it can't be started -> causes double fault (#DF, 8/0x8), which of course you don't have either and thus can't be started -> triple fault -> reboot.


Indeed this is true, though I was managing it this way intentionally. I realized the system was triple-faulting but could not figure out why. It turned out to be the mapping of the PIC. However, your point contends with what I thought was happening. Rather than a GPF I was thinking it went straight through to DF -> TF, not GPF -> DT -> TF. Thanks for that bit of info!

I plan to install a default handler for each entry now that I have a working configuration.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot] and 49 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group