Damien Zammit, le lun. 11 nov. 2019 21:23:15 +1100, a ecrit: > On 11/11/19 3:08 am, Samuel Thibault wrote: > > Samuel Thibault, le dim. 10 nov. 2019 16:25:22 +0100, a ecrit: > >> Samuel Thibault, le dim. 10 nov. 2019 16:22:04 +0100, a ecrit: > >>> Ok, I have restored some of the mask/unmask_irq, so that curr_pic_mask > >>> will still exist, but without the notion of spl: it will just store > >>> which IRQs have been effectively disabled. That'll already be good for a > >>> first step :) > >> > >> And we'll have to rethink this all against edge/level-triggered > >> interrupts etc. for the interface for userlevel interrupts. > > > > (what was happening with netdde is that the interrupt kept raising again > > and again, thus never returning from interrupt handling. That's why I > > had to restore the code that can mask an interrupt) > > See attached patch that fixes the hang with current master when applying > netdde patches and trying to bring up /dev/eth0.
You meant on top of your patch that adds masking to interrupt.S. I had a look at documentations and the Linux driver. They seem to be saying that one should mask the interrupt before EOI it indeed. I have now done so in interrupt.S. Note that the values for commands were completely bogus except NON_SPEC_EOI... That being said, now netdde with e1000 works only because linux_intr calls disable_irq before queue_intr. If that is not done, we keep getting interrupts. This really looks like an edge-vs-level trigger issue which we need to clear out. Possibly it's indeed the hardware which keeps the interrupt getting triggered until the driver manages it, and there is nothing around that. That'd be unfortunate because it'd mean that we wouldn't be able to just notify the userland driver of the interrupt, we'd have to wait for it to acknowledge it before re-enabling the interrupt. That's poor isolation if we have several devices on the same interrupt. Samuel
