Re: Potential source of interrupt aliasing

From: Scott Long (scottl_at_samsco.org)
Date: 04/11/05

  • Next message: Matthew Dillon: "Re: Potential source of interrupt aliasing" 
    Date: Mon, 11 Apr 2005 01:08:51 -0600
To: Matthew Dillon <dillon@apollo.backplane.com>

    Matthew Dillon wrote:
    > Hmm. I can think of two solutions that avoid masking:
    >
    > * Change the trigger mode from level to edge as a means of masking the
    > interrupt, then change it back to level triggered to unmask. This
    > would be done in the IO APIC.
    >
    > * Change the delivery mode to low-priority for the interrupt that occured
    > and use the priority field to mask the interrupt to the cpu. This
    > would be done in the IO APIC with the LAPIC's TPR set appropriately.
    >
    > These are off-the-cuff ideas. I don't know how easy or hard it would be
    > to implement (yet). But, certainly, changing the trigger mode can't be
    > any more complicated then messing around with the mask.
    >
    > -Matt

    This is a place where two-level interrupt handling like in Mac OSX
    starts looking attractive. You have the driver quench the source right
    away in what is basically a fast interrupt handler, then you have an
    ithread come along later and process the data. I somewhat approximate
    this with the AAC driver, though I use a taskqueue instead of an
    ithread. There are definite trade-offs here; sometimes the only way to
    quench the hardware is to dequeue a status byte that is needed for later
    data processing. Queueing up this data byte to an ithread, and
    accounting that there might be more interrupts before the ithread runs,
    is ugly. Btw, AAC doesn't exhibit aliasing problems in the chipsets
    that I mentioned precisely because we don't mask the IOAPIC for fast
    handlers. Unfortunetaly, moving the entire OS to this scheme is
    quite labor-intensive. It would make just as much sense to implement
    MSI infrastructre and convert a number of drivers to that. And again,
    Linux seems immune to this problem, so it's very intriguing to find out
    why.

    Scott
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Matthew Dillon: "Re: Potential source of interrupt aliasing"

    Relevant Pages

    • Re: Potential source of interrupt aliasing
      ... : Hmm. ... I can think of two solutions that avoid masking: ... * Change the trigger mode from level to edge as a means of masking the ... interrupt, then change it back to level triggered to unmask. ...
      (freebsd-current)
    • Re: kernel: return from interrupt
      ... >> happening with PREEMPTION compiled in? ... > AFAIK this is the only return path from an interrupt. ... > another return path for the interrupts, the scheduler is not invoked on ... or call ithread_schedule() to schedule the ithread. ...
      (freebsd-current)
    • RE: serious networking (em) performance (ggate and NFS) problem
      ... > in the network layer that debug.mpsafenet=0 might correct. ... > noticed that our setup here has that setup, ... own ithread. ... generating a higher interrupt load. ...
      (freebsd-current)
    • RE: serious networking (em) performance (ggate and NFS) problem
      ... > in the network layer that debug.mpsafenet=0 might correct. ... > noticed that our setup here has that setup, ... own ithread. ... generating a higher interrupt load. ...
      (freebsd-stable)
    • Re: Potential source of interrupt aliasing
      ... > not one interrupt aliasing issue. ... > What I/O APIC chipset and stepping does Doug have on that motherboard? ... work at all on 4.x is that the interrupts on the second and third APICs ... - uhci ithread scheduled ...
      (freebsd-current)