Logic for interrupts:
- interrupt.S raises spl (thus IF cleared)
- interrupt.S EOI
- interrupt.S calls the handler
- for pure in-kernel handlers, they do whatever they want with IF
cleared.
- when a userland handler is registers, queue_intr masks the irq.
- interrupt.S lowers spl with s
On 2/10/23 10:56, Samuel Thibault wrote:
> So in the end, I'd tend to think that it's up to queue_intr to do the
> unmasking, like it does now, while spl is still high and thus we don't
> risk nesting. That way it's the in-kernel intr handler that knows
> whether to mask/unmask or not. I.e. it'd be
Samuel Thibault, le lun. 02 oct. 2023 01:43:48 +0200, a ecrit:
> Also, "don't EOI in the user handlers anymore.", isn't that already the
> case?
Ah, that's the irqtab.irqdev_ack call in irq_acknowledge.
Then I'd say we should try to move it to queue_intr? So that it's done
before the driver manag
Samuel Thibault, le lun. 02 oct. 2023 01:56:51 +0200, a ecrit:
> Samuel Thibault, le lun. 02 oct. 2023 01:50:14 +0200, a ecrit:
> > Samuel Thibault, le lun. 02 oct. 2023 01:43:48 +0200, a ecrit:
> > > Damien Zammit, le dim. 01 oct. 2023 23:26:02 +, a ecrit:
> > > > I think the logic for this sh
Samuel Thibault, le lun. 02 oct. 2023 01:50:14 +0200, a ecrit:
> Samuel Thibault, le lun. 02 oct. 2023 01:43:48 +0200, a ecrit:
> > Damien Zammit, le dim. 01 oct. 2023 23:26:02 +, a ecrit:
> > > I think the logic for this should be:
> > >
> > > When we get irq N, first we mask irq N, then EOI
Samuel Thibault, le lun. 02 oct. 2023 01:43:48 +0200, a ecrit:
> Damien Zammit, le dim. 01 oct. 2023 23:26:02 +, a ecrit:
> > I think the logic for this should be:
> >
> > When we get irq N, first we mask irq N, then EOI irq N.
> > Then call the handler. If there is a user handler for irq N, l
Damien Zammit, le dim. 01 oct. 2023 23:26:02 +, a ecrit:
> I think the logic for this should be:
>
> When we get irq N, first we mask irq N, then EOI irq N.
> Then call the handler. If there is a user handler for irq N, let the irq_ack
> unmask irq N, otherwise we need to unmask irq N now.
> B
Hi,
On 1/10/23 20:13, Samuel Thibault wrote:
> Sometimes the "why" of a commit is obvious, so it doesn't need to be
> explained, but here it's really not and thus it definitely needs to
> be. We have had various pings-pongs in the past about whether to EOI
> before/after the interrupt, masking or
BTW, I added to kdb a whatis command that is convenient to determine
what an address points to (a stack? a port? some kalloc? ...)
Samuel
Hello,
Good news! It seems I fixed the bug that was making my 64bit VM
crashing quite often. The problem was that when receiving a message from
userland, ipc_kmsg_get would allocate a kernel buffer with the same size
as the userland message. But since we may expand the 32bit port names
into 64bit
Hello,
Sometimes the "why" of a commit is obvious, so it doesn't need to be
explained, but here it's really not and thus it definitely needs to
be. We have had various pings-pongs in the past about whether to EOI
before/after the interrupt, masking or not, etc. So we really need
a firm explanatio
applied, thanks!
Damien Zammit, le dim. 01 oct. 2023 04:58:04 +, a ecrit:
> ---
> i386/i386at/autoconf.c | 6 ++
> i386/i386at/model_dep.c | 8
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/i386/i386at/autoconf.c b/i386/i386at/autoconf.c
> index ef813d92..
Applied, thanks!
Damien Zammit, le dim. 01 oct. 2023 04:57:40 +, a ecrit:
> ---
> i386/i386at/kd.h| 1 +
> i386/i386at/kd_event.c | 7 +++
> i386/i386at/model_dep.c | 2 --
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/i386/i386at/kd.h b/i386/i386at/kd.h
>
13 matches
Mail list logo