IRC channel logs
2025-06-22.log
back to list of logs
<damo22>youpi: isa_dma_bridge_buggy = 1 in linux for this bridge <damo22>i think we need to disable dma for piixide <damo22>drivers/pci/quirks.c:DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0, quirk_isa_dma_hangs); <damo22>i tried building rump without piixide dma option, but it still loses interrupts, i am guessing the pci to isa bridge needs pci routing set up <damo22>ok i think acpi_get_irq_number() needs to fail if the b/d/f is for an ISA irq <damo22>tried that, it still loses interrupts <damo22>netbsd special cases the IDE pci interrupt establisher <damo22>but i still cant work out why its losing interrupts <damo22> [ 1.036887] piixide0 at pci0 dev 1 function 1: Intel 82371SB IDE Interface (PIIX3) (rev. 0x00) <damo22> [ 1.036887] piixide0: primary channel interrupting at ioapic0 pin 14 <damo22> [ 1.036887] piixide0: primary channel wired to compatibility mode <damo22>not quite, it works in qemu but now breaks on hw <damo22>youpi: two patches i mailed in now allows qemu to function without -M q35 <damo22>according to the ACPI spec, MADT IRQ overrides are only for ISA bus legacy interrupts, so i assume they only apply to 0-15, but PIIX3 uses 14 and 15 as active-low level i think without providing any ACPI overrides <youpi>damo22: that being said, can the gnumach workaround pose problem? <youpi>ah, it hardcodes things, not a good thing <youpi>are we confident that 14&15 would in practice always be pci irqs? <damo22>ive patched it to only affect pc_piix <youpi>how does linux avoid the issue? by knowing the piix chipset configuration? <youpi>damo22: I'm talking about the gnumach patch <youpi>the qemu patch does makes sense to me <damo22>im not sure if they are always pci irqs but definitely for the PIIX chipset <damo22>if we were confident they are, then gnumach patch could be viable <damo22>did you see my acpi patch? that one is probably ok, although could be better if we could check for presence of PIIX3 ISA bridge <damo22>i think irq 9 is always SCI interrupt on x86 <damo22>so it should never be returned by the acpi lookup <diegonc>so I patched GNU Mach to provide some virtial memory limitations, I also patched glibc to use the new Mach RPC in setrlimit and init_relimit and finally patched Hurd's libpager. I need to run the ext2fs translator but I don't know how to run it through the GLIBC testrun.sh script <diegonc>Is somthing like `settrans -a mnt $GLIBC_BUILD/testrun.sh /hurd/ext2fs test.image` ok? or it won't even work? <diegonc>I suspect it wont work but I'll try anyway in the meantime <diegonc>CaptRon: I'm not sure what you refer to by my Hurd VM has 12GB (amd64) <diegonc>we can move on to USB now I guess haha <diegonc> demo@debian:~/dev/hurd/upstream/test$ settrans -a mnt ../glibc-build/testrun.sh ../hurd/build-tree/ext2fs/ext2fs ./fs.img <diegonc> ../hurd/build-tree/ext2fs/ext2fs: error while loading shared libraries: libdiskfs.so.0.3: cannot open shared object file: No such file or directory <diegonc> settrans: ../glibc-build/testrun.sh: Translator died <youpi>diegonc: testrun.sh excludes other library paths, so you'd have to fix it to include /lib/i386-gnu last in the library path <diegonc>thanks youpi. I was doing just that as I saw your message. I could finally mount an fs image yay <diegonc>now I need to make ext2fs allocate a huge amount of memory :P <diegonc>dd if=/dev/zero of=./dummy.bin bs=1M count=7168 <diegonc>now I can't exit haha. It all started with the vm limit softdebugger call and somehow mutated into an invalid opcode (6) a t_debug+0xb :P <diegonc>trace/u didn't show usermode frames unfortunately