IRC channel logs

<damo22>irq 10 and 11 are hardcoded by qemu to be treated like PCI interrupts

<damo22>maybe we need to do that in gnumach too?

<damo22>because on my thinkpad, there is no MADT overrides for 10,11

<damo22>youpi: ^ what do you think?

<damo22>qemu adds 10 and 11 as MADT overrides

<damo22>i tried that, it doesnt fix the problem with IDENTIFY timeout

<youpi>damo22: question is: how does linux manage to get it working

<youpi>we can't just hardcode things

<damo22>its not straightforward to see, i need to grok the source again

<damo22>maybe it knows about piix routing

<damo22>it looks like ExtINT mode of ioapic means there is a i8259 chip connected as well

<damo22>i only saw that in arch/x86/kernel/apic/io_apic.c

<damo22>i dont know if piix uses that

<damo22>see enable_IO_APIC()

<damo22>it falls back to MP tables

<damo22> /*

<damo22> * If the i8259 is routed through an IOAPIC Put that IOAPIC in

<damo22> * virtual wire mode so legacy interrupts can be delivered.

<damo22> */

<damo22>i want to avoid requiring mp tables

<damo22>and just rely on acpi

<damo22>because if we used mp tables, we dont even need acpi for some older machines, but they phased out mp tables

<damo22>so to support all machines we could just use acpi and provide workarounds for ones that are too old

<damo22>currently i dont know enough detail to see the full picture

<damo22>so i dont know why gnumach fails on my thinkpad for example

<damo22>s/gnumach/rump

<damo22>it definitely seems to be irq related

<damo22>i dont understand the huge comment in ioapic_ack_level()

<damo22> * It appears there is an erratum which affects at least version 0x11

<damo22> * of I/O APIC ...

<damo22>i changed the EOI code to be more like Linux, but it didnt make any noticable difference

<damo22>for example, checking the APIC_TMR register

<damo22>to see if there was a mismatching trigger mode interrupt

2025-06-23.log