IRC channel logs
2025-07-18.log
back to list of logs
<damo22>kernel: General protection (13), code=9e60 <damo22>cngetc: handle_ackcngetc: handle_ackall_intrs(0,3fa0034,0,c1025df6,c10b9ec0)+0xd6 <damo22>this is happening at boot when the keyboard is booting up <damo22>Pellescours: sorry for noise, i fixed everything except one thing <damo22>youpi: do we care if an irq handler causes a device to raise another interrupt inside the handler code? currently we have disabled interrupts during the handler on the cpu handling the first interrupt <damo22>i dont know if other cpus are involved with pci interrupts or just BSP <youpi>what we care is that it doesn't infinitely pile up <youpi>I don't know how the pci interrupts are wired by default <damo22>maybe it depends on focus lapic setting? <damo22>ah its in the redirection entry of the ioapic <damo22>if interrupts are disabled on bsp during an interrupt, we could miss further interrupts <youpi>that's fine, provided that we make sure to catch new interrupts *before* calling the actual driver handler <damo22>as soon as all_intrs is entered, it starts with IF disabled afaik, and nowhere do we "sti" in the handling code <damo22>i was thinking we could add sti just before the driver handler is called <damo22>but then i get a page fault with cngetc <damo22>"cngetc: handle_ack" is printed twice and then page fault somewhere <youpi>damo22: not having the IF set is not a problem for interrupts <youpi>when hardware raises an interrupt whie IF is cleared, the cpu will receive it when it will set IF again <youpi>usually that's done simply on iret of the interrupt handler, so that we are sure that the interrupts don't stack <youpi>otherwise you cannot be sure that it won't stack indefinitely <youpi>most often things just work because devices don't interrupt that much, but in some odd cases stacking can pose problem <youpi>and the key thing is making sure to ack the interrupt (by that, I mean making the hardware ready to raise another instance of the interrupt) before the hardware driver processes the interrupt <youpi>so that even if the driver handler itself makes the hardware raise another interrupt (e.g. almost at its end of processing), it's not missed, and we will call the handler again to check the hardware again <damo22>but if there is a level triggered interrupt line, and the line is high for some reason on the device, it makes more sense to handle the interrupt before you ack the interrupt so that it cant raise again until after it has been handled and so it cannot infinitely stack <damo22>otherwise, if you ack it first, the interrupt triggers thousands of times before it gets a chance to handle even once <youpi>but you have a tiny window between handling the interrupt and acking the interrupt, in which another interrupt could happen, and that you then lose <youpi>that's why there is both the masking handling *and* the eoi <youpi>to both make sure that you don't miss interrupts and that they don't stack <damo22>something is missing though with our current state <damo22>somehow nested_irqs[].ndisabled is growing to many thousands <youpi>damo22: please also test the build without apic ;) <damo22>youpi: my last mailing list patch seems to fix most issues but it has the problem with the tiny window as you mentioned <azert>This magma stuff looks like the nth iteration of the “rust rewrite” mantra. “The library is similar to libdrm, but with a more modern and unified interface” <azert>and I was the dumb one thinking that libdrm was the modern interface, while I thought that the previous one was already working perfectly fine for the end user <azert>current state: “very very rough”. Number of contributing authors: 1 <p4r4D0xum>hey, has any already tried hurd-amd64 on real hardware recently?