I've been trying to get my old hardware machine working with SATA disk
controller operating in 'Native IDE compatibility mode'. This is
detected correctly by rumpkernel in the same way as when using Qemu and
i440fx machine. I've managed to get it working with 2 changes:
1) The IRQ configuration for this controller should always use the
legacy IRQ and not that provided by the ACPI tables. On my machine the
ACPI table still includes a mapping from 14 to 19 even though the legacy
controller mode is configured. Hurd therefore wrongly chooses 19 for the
IRQ.
NetBSD arch amd64 implements pciide_machdep_compat_intr_establish()
which only attempts a legacy IRQ configuration and correctly chooses 14.
This function is also implemented within rump but basically just calls
into the normal interrupt establishment code losing the 'legacy only'
context. I hacked something together for test purposes but a proper fix
might be to alter rump's pciide_machdep_compat_intr_establish() to
provide the missing context so Hurd can choose to call ACPI translation
or not.
2) Perhaps the more difficult issue relates to the IOAPIC interrupt
configuration. Looking at gnumach/i386/i386at/ioapic.c,
ioapic_configure() configures pins 14 and 15 with level triggering and
active low. I think that historically these were configured as legacy
IRQs having edge triggering and active high but were changed to allow
Qemu IDE on piix3 to work. On my hardware machine, these pins need to be
configured as legacy pins (active high/edge triggered).
I'd have expected that Qemu would emulate pins 14 and 15 as active
high/edge triggered but it seems not as booting a virtual machine
(i440fx) with my changes does not work correctly and has interrupt
loss/timeout issues. The strange thing is that booting NetBSD with the
same virtual machine works correctly and yet that seems to configure the
interrupt as active high/edge triggered. I can't explain this
inconsistency at the moment.
Can anyone can shed any light on the interrupt configuration issue?
Cheers,
Mike.
