IRC channel logs

<diegonc>some malloc tests in glibc spam "no more room in" on the mach console

<diegonc>or there's something to fix?

<youpi>it can be expected, depending on the test

<youpi>some of them exercise getting an error on too many allocations

<diegonc>it had too-large in the name, so I guess its one of them

<damo22>what should i work on now?

<damo22>youpi: is it possible that rumpdisk interrupt handler causes another interrupt on the device but the IF is cleared on BSP so cannot trigger immediately, and the queue_intr has already masked it, so the interrupt does not raise at all. Then the user handler on the AP gets stuck because its waiting for that interrupt to occur?

<youpi>no, because the interrupt handler is not supposed to expect the interrupt to happen while it's running

<youpi>it's supposed to leave, and thus let irq be acked

<youpi>and thus unmasked

<youpi>and thus triggered again

<youpi>and the next handler call will proceed on

<damo22>ok

<damo22>but afaik ahci has a set of interrupts of its own?

<youpi>what do you mean by "a set" ?

<damo22>one per channel?

<youpi>probably

<damo22>if the pci interrupt triggers AHCI interrupts, that could be a problem?

<youpi>why?

<damo22>because we dont allow any nesting

<youpi>that's not a problem

<youpi>we eventually get to run the handler

<youpi>which can process whatever is there to finish

<youpi>think of it as a producer/consumer situation

<youpi>the irq is just there to signal that the producer (the card) put some stuff to process

<youpi>it's fine to be signaled several times or just once, as long as the consumer is signaled eventually if there is still stuff to process

<youpi>one thing that we are missing on hurd-amd64 is crash-core that fails

<youpi>gotta go to bed, see you

<damo22>nn

IRC channel logs

2025-07-20.log