Re: [PATCH]: gnumach - simplify interrupt handling

[Samuel Thibault]

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