On 03/10/2025 09:17, Michael Kelly wrote:
I have had no success yet with 64 bit on this hardware. Nor on 32 bit > with only
--disable-linux-groups which by default configures APIC. It > seems likely therefore that
something in the APIC code is not > configuring interrupt delivery on my machine. I added
various > diagnostics to the asm interrupt handlers and there is no evidence > that the
interrupt 11 is ever received when APIC is enabled.
I'll now start to investigate the APIC configuration to see if I can > narrow
it down further.
Just a quick update to say that I now also have this hardware working with APIC
on 32 and 64 bit. My interrupt IRQ11 is not being detected as an override by
acpi_apic_parse_table() in gnumach/i386/i386at/acpi_parse_apic.c and
consequently remains as an 'Edge Triggered' interrupt. I have 'hacked' my local
ioapic.c for the moment to write the ioapic entry for pin 11 as 'Level
triggered' until I can work out (or be told of) the underlying cause which
seems to be commonly attributed to ACPI.
I think that I can now explain why the interrupt mechanism does not work
on my hardware with '--enable-apic'. The hack that I described above was
actually only partially successful in that interrupts were received but
they seemingly couldn't be masked or acknowledged. The gnumach code
appeared to be working properly but there was an interrupt flood burning
75% of CPU doing nothing. I tried all other combinations of polarity and
trigger for GSI 11 but none of these worked at all.
I have Linux and NetBSD installed on the same machine and by disabling
MSI interrupts on each of these, so that the IOAPIC was used
exclusively, I could see that the GSI was 19 on those platforms. I then
hacked the IRQ handler registration to swap 11 for 19 and the system
operated properly. The disk driver worked normally and no interrupt storm.
I couldn't understand how the 19 was being identified as certainly on
NetBSD the code uses the same interface as libacpica to extract the ACPI
information. It was almost like the ACPI interface was operating
differently under NetBSD and Hurd. Researching further it turns out that
is exactly what is happening.
ACPI defines the '\_PIC' System Configuration Object Method
(https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#system-configuration-objects)
that is used by an OSPM to indicate the interrupt model that is in use
on the system. I cannot find anywhere in Hurd/GNUmach that uses this
interface meaning that the default of PIC mode is assumed.
I was able to alter \_PIC to APIC mode within the acpi_init.c code and
then the existing code that reads the MADT tables reported the IOAPIC
GSI 19 (rather than 11). With that one change (plus the patch from
earlier in this thread) I am able to boot successfully in 64 bit on my
hardware.
Is there a way of detecting the interrupt model in use within the Hurd
ACPI server? That would need to be known in order to set the appropriate
model for \_PIC. Possibly the more appropriate place might be within
gnumach/i386/i386at/acpi_parse_apic.c where it is known whether the
IOAPIC is being used or not. That code however uses a memory mapped
interface to ACPI and I don't know whether it's possible or advisable to
perform an ACPI write operation to the \_PIC mode.
Cheers,
Mike.
