OSDev.wiki

I Can't Get Interrupts Working: Difference between revisions

Page Discussion

I Can't Get Interrupts Working (view source)

Revision as of 04:32, 9 June 2024

2,358 bytes added ,  26 days ago
m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
VisualWikitext
(Typos)
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(21 intermediate revisions by 13 users not shown)
Line 5:
== ISR problems ==
 
=== My handler doesn't get called!?! (ASMAssembly) ===
 
For this test, you need to call the interrupt yourself, by software. Don't try to get [[IRQ]] handled right from the start before you're sure your IDT setup is correct. You need to have:
 
* yourYour IDT loaded and filled properly.
* yourYour IDT's ''linear'' address loaded in a structure together with the table's size (in bytes, iircIIRC). Be especially cautious if you have a [[Higher Half Kernel]] design or did not set up [[Identity Paging|identity paging]].
* aA valid Code selector and offset in the [[Descriptors|descriptor]], proper type, etc.
* aA handling code at the defined offset.
 
'' see [[#Assembly_ExampleAssembly_Examples|test code]] below ''
 
=== My Handler doesn't get called (C) !?! ===▼
 
If you're are programming the IDT setup in C, make sure the IDTR structure has been correctly understood by your compiler. As Intel's 6 bytes structures infringe most compiler's packing rules, you'll need to use either ''bitfields'' or ''packing pragmas''. Use <tt>sizeof()</tt> and <tt>OFFSETOF()</tt> macros to make sure the expected definition is used (a runtime test would be fine)▼
▲=== My Handler doesn't get called (C) !? ===
 
▲If you're programming the IDT setup in C, make sure the IDTR structure has been correctly understood by your compiler. As Intel's 6 bytes structures infringe most compiler's packing rules, you'll need to use either ''bitfields'' or ''packing pragmas''. Use <tt>sizeof()</tt> and <tt>OFFSETOF()</tt> macros to make sure the expected definition is used (a runtime test would be fine)
 
 
=== My handler is called but it doesn't return !? ===
 
Try to run it in the BOCHSBochs and see if you get any exception report. Program all your exception to have the same kind of behavior as [[#Assembly_ExampleAssembly_Examples|the example]], but displaying a character indicating the fault. Exceptions occurring at the end of an interrupt handler are usually due to a wrong stack operation within the handler.
 
* don't try to return from an exception (unless you solved its cause). Returning from a division by zero, for instance, makes no sense at all
Line 31 ⟶ 29:
* make sure your handler doesn't trash unexpected registers. For exceptions and hardware IRQ handlers, no registers *at all* should be modified.
 
Another common source of error at this point comes from misimplementationmis implementation of ISR in C. Check the InterruptServiceRoutines page for enlightenment ...
 
== IRQ problems ==
Line 38 ⟶ 36:
Use the mask feature of the PIC to enable/disable some handlers.
 
<sourcesyntaxhighlight lang="c">
outb(0x21,0xfd);
outb(0xa1,0xff);
enable(); // asm("sti");
</syntaxhighlight>
</source>
 
=== I'm receiving EXC9a insteadGeneral ofProtection IRQ1Fault wheninterrupt strikingimmediately aafter returning from my keyfirst ?!interrupt ===
 
After initializing the gdt with the lgdt command, make sure that you are performing a long jump. For example:
 
<sourcesyntaxhighlight lang="asm">▼
init_gdt:
lgdt [gdt_table]
jmp 0x08:longjmp_after_gdt
longjmp_after_gdt:
; Do something like repoint segment registers next
</syntaxhighlight>
 
=== I'm receiving EXC9 instead of IRQ1 when striking a key?! ===
 
You missed the PIC vector reprogramming step. Check [[PIC|Can I remap the PIC?]] page. Note that if you remap the PIC vectors out of the IDT you'll get a GPF exception instead of any interrupt.
Line 50 ⟶ 60:
=== I'm receiving a double fault after enabling interrupts ===
 
DifferentMay be a different symptom for the same error as above., Thisthis time caused by ana timer interrupt calling vector 8. May also be caused if you've enabled interrupts in protected mode but haven't got an interrupt handler defined for whatever vector you've remapped the timer to, as the timer interrupt will come soon after enabling interrupts and cause a fault unless you've got a handler for it or you've masked it.
 
=== I'm not receiving any IRQ ===
Line 58 ⟶ 68:
=== I can only receive one IRQ ===
 
Each IRQ needs to be acknowledged to the PIC manually by sending an EOI. You need to have <sourcesyntaxhighlight lang="c"> outb(0x20,0x20) </sourcesyntaxhighlight> within any master handler and any <sourcesyntaxhighlight lang="c"> outb(0x20,0x20); outb(0xa0,0x20); </sourcesyntaxhighlight> within any slave handler.<br><br>
 
When handling the keyboard IRQ, make sure that you read the byte the keyboard sends you. The interrupt might not trigger again until it has been read: <syntaxhighlight lang="c"> unsigned char scan_code = inb(0x60); </syntaxhighlight>
 
Also, if you are following the barebones tutorial, be sure that your main function doesn't exit too soon (because when it does, it disables interrupts). A common solution to make sure it doesn't exit prematurely is to add <syntaxhighlight lang="c"> for(;;) {
asm("hlt");
} </syntaxhighlight>
to the end of your main kernel function. The ''for'' loop is necessary because execution continues after the CPU receives an interrupt.
 
=== When I try to enable the PIT, the keyboard doesn't work anymore ===
Line 66 ⟶ 83:
=== I keep getting an IRQ7 for no apparent reason ===
 
This is a known problem that cannot be prevented from happening, although there is a workaround. When any IRQ7 is received, simply read the In-Service Register <sourcesyntaxhighlight lang="c"> outb(0x20, 0x0B); unsigned char irr = inb(0x20);</sourcesyntaxhighlight> and check if bit 7 <sourcesyntaxhighlight lang="c">irr & 0x80</sourcesyntaxhighlight> is set. If it isn't, then return from the interrupt without sending an EOI.
 
For more information, including a more detailed explanation, see Brendan's post in [[Topic:11379|this thread]].
 
 
=== what does "shift operator may only be applied to scalar values" mean ? ===
 
You're trying to load a 16-bits field (a part of the IDT descriptor) with a reference to a 32-bit label that is subject to relocation. Try to replace
<sourcesyntaxhighlight lang="asm">
isr_label:
iret
Line 81 ⟶ 98:
dw 0xbeef
dw isr_label >> 16
</syntaxhighlight>
</source>
 
by something that extracts a 'pure value' from the address (e.g. the difference of two addresses are a pure value and <tt>$$</tt> means to NASM the start of the section)
<sourcesyntaxhighlight lang="asm">
%define BASE_OF_SECTION SOME_CONSTANT_YOU_SHOULD_KNOW
isr_label:
Line 92 ⟶ 109:
dw 0xbabe
dw (BASE_OF_SECTION + isr_label - $$) >> 16
</syntaxhighlight>
</source>
 
The role of <pre>BASE_OF_SECTION</pre> is to adjust the pure offset to the real situation (usually as defined in your linker script), e.g. if your kernel get loaded at 1MB, you'll set it to 0x100000 to keep the CPU happy.
 
==Assembly ExampleExamples==
===NASM===
▲<source lang="asm">
 
This example is made for x86 CPUs running in IA32 mode (32-bit).
<syntaxhighlight lang="asm">
int_handler:
mov ax, LINEAR_DATA_SELECTOR
Line 120 ⟶ 140:
mov [idt+49*8+6],ax
int 49
</syntaxhighlight>
</source>
 
should display a smiley on the top-left corner ... then the CPU is halted indefinitely.
 
===GNU Assembler===
 
This example sets up an interrupt handler in long mode.
<syntaxhighlight lang="asm">
.text
int_handler:
movq $0x123abc, 0x0 // this places magic value "0x123abc" at the beginning of memory
hlt
 
.p2align 4
idt:
.skip 50*16
 
idtr:
.short (50*16)-1
.quad idt
 
.globl do_test
do_test:
lidt idtr
movq $int_handler, %rax
mov %ax, idt+49*16
movw $0x20, idt+49*16+2 // replace 0x20 with your code section selector
movw $0x8e00, idt+49*16+4
shr $16, %rax
mov %ax, idt+49*16+6
shr $16, %rax
mov %rax, idt+49*16+8
int $49
</syntaxhighlight>
 
This example differs from the previous one: it will not touch the screen, but will write the value "0x123abc" to 0x0 memory address and halt. It may be useful when there's no screen or BIOS available.
 
== Problems with IDTs ==
Line 133 ⟶ 186:
Please post '''''Completed''''' problems here.
 
First of all, check your GDT. Keep in mind padding issues. In C this goes like:
<source lang="c">
// GCC
struct IDT_reg {
//struct here
} __attribute__((packed));
 
Keyboard handlers need to actually read the scancode from port 0x60—it's not enough to just have the handler print something to indicate success and then send EOI. The symptoms are identical to forgetting to send EOI.
struct GDT_reg {
//struct here
} __attribute__((packed));
 
// Visual C++
#pragma pack(push, 1)
struct IDT_reg {
//struct here
};
 
struct GDT_reg {
//struct here
};
#pragma pack(pop)
</source>
 
== IDT problems in Assembly ==
Make sure the structrestructure is correct and you are using linear addresses.
 
=== FASM notice ===
 
Since fasmFASM doesn't accept the normal way as described above, I will describe it.
FasmFASM does, however, support shl and shr, so to describe the higher part of an ISR address, we just use ''label shl 0x10'' where label is the name of the ISR.
To define the higher part, we need to write a little more, since fasm use 64 bit, before compiling.
This means that IF we just shl and shr, it will be that same as before.
This is how we are supposed to do: (label shl 0x30) shr 0x30
Here is a little example, so you can see how it works:
<sourcesyntaxhighlight lang="asm">
idt:
dw ((isr1 shl 0x30) shr 0x30) ; the low part of the address
Line 177 ⟶ 211:
isr1:
mov ax,0xdead
</syntaxhighlight>
</source>
 
== See Also ==
 
=== See alsoArticles ===
*[[IDT]]
*[[IDT_problems|IDT problemsProblems]]▼
 
▲*[[IDT_problems|IDT problems]]
 
 
[[Category:Troubleshooting]]
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/18194...26293"