[SOLVED] Stuck in the IOAPIC / LAPIC trap... :p

[nop]

Hi all!
After reading a lot on this forum (and of course, all the Intel guides) I'm stuck with APIC interrupts. I have a mess in my mind and I don't see any light in the end of the tunnel.

Goal: invoke my service routine when I hit a key.

What I have:
- long mode
- APIC detected (LAPIC in extended mode, tested with the timer interupt) and IOAPIC detected as well
- ISR routine (the same that gets called by the LAPIC timer interrupt)

Note:
- I have only the BSP cpu enabled.
- I rely on ACPI specifications only to detect hardware even if I have MP support
- I have masked all the PIC entries (vectors start from 0x20).
- I didn't change the TPR and PPR registers (default values of 0 should be fine for me)
- I have programmed the #1 entry of the IOAPIC's IOREDTBL with edge trigger, active high

Test environment:
- Bochs 2.5
- Qemu

Can you tell me what's the _minimum_ setup of both LAPIC and IOAPIC, please? I'm thinking about the simplest thing (phys destination, BSP only etc etc) that comes in mind!

I always get a "Int 0x20 stuck?" but the ISR never gets called.

I don't have clear what delivery type to use and when! It's clear that the LAPIC is getting something from the IOAPIC but I cannot fix the problem. I made a lot of tests to no avail... so I decided to start from scratch and asking for help here.

Thank you in advance,

Matteo

P.S.: sorry for my English...

[Nable]

> I have masked all the PIC entries (vectors start from 0x20).
Don't mess together vectors and interrupt sources.
I hope that you've masked PIC pins via write 0xFF to mask registers.

Then, did you unmask your IOAPIC's IOREDTBL ? It has mask bit. Are you sure that keyboard controller uses pin #1?

And one more thing:
http://wiki.osdev.org/IDT
This article is rather buggy but it contains needed keywords: IDT and IDTR.

Also, it'll very interesting if you share your current code somehow.

[nop]

First of all, thank you!

> I have masked all the PIC entries (vectors start from 0x20).
Don't mess together vectors and interrupt sources.
I hope that you've masked PIC pins via write 0xFF to mask registers.

Yes, I know the difference, sorry! Of course I've masked all the PIC's vectors.

>
Then, did you unmask your IOAPIC's IOREDTBL ?

Yes, I've masked them all except the pin #1

>
It has mask bit. Are you sure that keyboard controller uses pin #1?

When I press a key (and only if I press any key) BOCHS signals "Interrupt 0x20 Stuck?" so I'm positive that the keyboard is pin #1; furthermore, if I don't unmask the IOREDTBL #1 nothing happens.

>
And one more thing:
http://wiki.osdev.org/IDT
This article is rather buggy but it contains needed keywords: IDT and IDTR.

I'm fine with IDT and friends As I wrote I've the LAPIC timer working as expected, so the problem is how to program LAPIC's LINT line (ExtINT? Direct, etc etc) and the IOAPIC IMHO. I'm new to APIC stuff, I'm just supporting this hardware instead of the well known 8259.

>
Also, it'll very interesting if you share your current code somehow.

I'd be glad to, but it's not possible now!

Thank you!!!

Matteo

[jnc100]

The bochs 'vector ... stuck' message is normally caused by the emulated IOAPIC receiving the interrupt but being unable to deliver it, this is normally caused by an incorrect combination of the destination field, destination mode and delivery mode. I suggest if you are just testing to get things working, you set destination mode as 0 (physical mode), delivery mode as 0 (fixed) and destination as the LAPIC id of your BSP (normally 0 unless you have remapped it). Triggering is normally edge triggered for ISA interrupts (unless there is an interrupt-source override in the ACPI tables which say otherwise).

Regards,
John.

[nop]

The bochs 'vector ... stuck' message is normally caused by the emulated IOAPIC receiving the interrupt but being unable to deliver it, this is normally caused by an incorrect combination of the destination field, destination mode and delivery mode. I suggest if you are just testing to get things working, you set destination mode as 0 (physical mode), delivery mode as 0 (fixed) and destination as the LAPIC id of your BSP (normally 0 unless you have remapped it). Triggering is normally edge triggered for ISA interrupts (unless there is an interrupt-source override in the ACPI tables which say otherwise).

Regards,
John.

Thank you!!! My settings were perfectly fine and you confirmed me that! So the error was elsewere and I was lucky enough to catch it quickly:

Code: Select all

typedef union ioapic_redirection_entry_u
{
	u64_t value;
	struct
	{
		u32_t vector : 8; 		/* 0 - 7 */
		u32_t del_mod : 3;		/* 8 - 10 */
		u32_t dest_mod :  1;	/* 11 */
		u32_t del_stat : 1;		/* 12, RO */
		u32_t polarity : 1;		/* 13 */
		u32_t irr : 1;			/* 14, RO, for level triggered interrups only */
		u32_t trig_mod : 1;		/* 15 */
		u32_t mask : 1;			/* 16 */
		u32_t _resv1 : 32;		/* 17 - 47 */
		u32_t _resv2 : 8;		/* 48 - 55 */
		u32_t destination: 8;	/* 56 - 64 */
	} field;
} ioapic_redirection_entry_t;

This is the structure that describes the IOREDTBL entry. The line

Code: Select all

u32_t _resv1 : 32;		/* 17 - 47 */

is wrong! The size is 31 bits not 32. After that everything worked like a charm!!

Regards
Matteo