Hi Mike, Did you end up sending mail to NetBSD to ask about rump? I can't find the thread. It might be worth asking them about this particular issue as well.
I read somewhere on netbsd's mailing list archives that they have to use -M q35 as well for qemu to work correctly (which basically bypasses the piix3 ide controller). Damien On 8/9/26 10:11 pm, Michael Kelly wrote: > 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. > >
