OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:55 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 80 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject: Issues with interrupts
PostPosted: Thu Aug 04, 2022 1:01 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Before I even start, I want to say that: Yes, I have read the GDT and IDT and "Why are my interrupts not working?" page on the Wiki. My code is hosted on https://github.com/techflashYT/Techflash-OS
It does not crash. It makes it to the inf loop at the end of the kernel, but nothing happens at all, neither the PIT interrupt, nor the keyboard works at all.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 1:04 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Where do you enable interrupts?


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 1:32 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
Where do you enable interrupts?

I found the `sti` instruction in both ISRASM.S and IDTASM.S


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 1:33 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
In ISRASM the STI instruction occurs immediately before IRETQ, so it does nothing. Delete it.

In IDTASM the STI instruction occurs in the function IDTFlush. Where do you call IDTFlush?


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 3:31 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
In ISRASM the STI instruction occurs immediately before IRETQ, so it does nothing. Delete it.

In IDTASM the STI instruction occurs in the function IDTFlush. Where do you call IDTFlush?


Crap, the file must not have saved right last time, hang on.

UPDATE: Fixed the broken IDT code, still doesn't work.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 3:45 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Where do you initialize the interrupt controller?


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 3:49 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
Where do you initialize the interrupt controller?

I've heard that it doesn't need to be; GRUB already initializes it. If that's incorrect I can do that.

Also, wouldn't it triple fault if I tried to send commands to it before initialization?


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 3:55 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Where on earth did you hear that? Neither Multiboot nor Multiboot2 mention anything about it.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 4:07 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
Where on earth did you hear that? Neither Multiboot nor Multiboot2 mention anything about it.

I don't remember anymore, it was a while ago.
UPDATE: Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 5:10 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Techflash wrote:
Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.

If you're talking about the code on this page, it writes those values to the PICs during initialization. You can refer to the 8259A datasheet to see exactly how each 8259A will interpret those values.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 6:03 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
Techflash wrote:
Found a function on the Wiki for initializing the PIC, but I can't seem to find anywhere what parameters to call it with.

If you're talking about the code on this page, it writes those values to the PICs during initialization. You can refer to the 8259A datasheet to see exactly how each 8259A will interpret those values.

Alright, I'll do that then, I need to take a break for a few hours though.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 9:03 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
UPDATE: It really seems like it's already being initialized somewhere... somehow. Not sure where in the code it is, but since I'm definitely already receiving interrupts, I think that the PIC is fine. But now after some tweaking to my IDT code, I'm getting this error in Bochs:
Code:
06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
06958696000e[CPU0  ] interrupt(long mode): must be 64 bit segment
(0).[6958696000] [0x000000113f30] 0008:ffffffffffe03f30 (unk. ctxt): test ecx, edx             ; 85d1
06958696000p[CPU0  ] >>PANIC<< exception(): 3rd (13) exception with no resolution

My code segment (0x08) according to Bochs is 64-bit:
Code:
cs:0x0008, dh=0x00209900, dl=0x0000ffff, valid=1
        Code segment, base=0x00000000, limit=0x0000ffff, Execute-Only, Non-Conforming, Accessed, 64-bit


The only thing that I can think of is the IDT is messed up and it's reading some garbage data when it's trying to find where the CS to switch to is


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 9:35 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Techflash wrote:
UPDATE: It really seems like it's already being initialized somewhere... somehow.

It isn't. Your OS will fail to receive interrupts on some PCs because the interrupt controllers are not initialized.

Techflash wrote:
But now after some tweaking to my IDT code,

It's hard to spot bugs in your code when I can't see the current version of your code.

Techflash wrote:
The only thing that I can think of is the IDT is messed up and it's reading some garbage data when it's trying to find where the CS to switch to is

Perhaps. Try using "info idt" in the Bochs debugger.


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Thu Aug 04, 2022 11:55 pm 
Offline
Member
Member

Joined: Sun May 08, 2022 2:10 am
Posts: 70
Octocontrabass wrote:
It isn't. Your OS will fail to receive interrupts on some PCs because the interrupt controllers are not initialized.

Hmm... I wouldn't have though that Bochs would init them by default but maybe.

Octocontrabass wrote:
It's hard to spot bugs in your code when I can't see the current version of your code.

The latest version of my code has been available at https://github.com/techflashYT/Techflash-OS since the beginning.

Octocontrabass wrote:
Perhaps. Try using "info idt" in the Bochs debugger.

Will try in a second.
Log of this is at: https://gist.github.com/techflashYT/3c506580d7740e859f4d017f08cfffe7
Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?


Top
 Profile  
 
 Post subject: Re: Issues with interrupts
PostPosted: Fri Aug 05, 2022 9:40 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
Techflash wrote:
Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?
That is generally a good idea. Between IOAPIC, local APIC, and MSI, you can generally not know how many interrupts you will have ahead of time these days. Filling the entire IDT can be done as simply as:
Code:
.align 8
.global external_interrupt
external_interrupt:
.set interrupt,32
.rept 256-32
  pushq interrupt-128
  jmpq interrupt_common
.align 8
.set interrupt, interrupt+1
.endr


This defines a new symbol, "external interrupt", that handles interrupt 32. You need to define your own function "interrupt_common". It is entered with an IRET frame and the interrupt number less 128 on the stack. The encoding is chosen such that for all possible values of "interrupt", the encoding of the push instruction is the short encoding. This means that all interrupt handlers are exactly 8 bytes apart from one another (you have 2 bytes for the push and at most 5 for the jump, makes 7 in total, aligned to 8). So now you can define in C:
Code:
extern const char external_interrupt[];
for (int i = 0; i < 256-32; i++)
  set_idt_entry(i + 32, external_interrupt + 8 * i);

Your "interrupt_common" function will then need to save all registers, probably fix up the interrupt number on stack, then call whatever interrupt handler you need to. Then restore registers and do whatever work is required when returning from interrupt.

_________________
Carpe diem!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 80 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: FrankRay78, Google [Bot], SemrushBot [Bot] and 57 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