lkml.org 
[lkml]   [1999]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Lockups - lost interrupt
    On Mon, Sep 13, 1999 at 08:42:20AM +0200, mingo@chiara.csoma.elte.hu wrote:
    >
    > On Sun, 12 Sep 1999 yodaiken@chelm.cs.nmt.edu wrote:
    >
    > > There are parts of the new irq.c that are not obviously there to support
    > > RTLinux. Please don't chop em. Especially important is: the functions
    > > in the low level handler structure do not invoke any spinlocks and
    > > there are labels on the low level irq catch code that allow the RTL
    > > module to patch to take control.
    >
    > i'm not touching the architecture part, thats i think pretty clean right
    > now. I ment minor stuff like moving the no_irq controller definition out
    > of i8259.c and the like. (no_irq_type is not really Intel-dependent. The
    > #if SMP thing in ack_none is just an expression of 'what should we do if
    > the vector is illegal', which is architecture dependent. But this doesnt

    Yes. But it was not obvious to me what to do when it was illegal so
    I left it there.

    > make the no_irq_type controller truly architecture-dependent.) Another
    > more generic thing i'm thinking about (not done yet), to move the vector
    > building defines near to every controller's source code section. This
    > makes the thing a little bit more modular. Not all controllers are truly
    > independent (there are obvious interactions between 8259A and the first
    > IOAPIC in the system), but this is not a problem. The APIC/IOAPIC code
    > OTOH has major modifications/fixes.
    >
    > what labels do you mean?

    If you look at the build irq macros, you will see that common irq
    has a label on the line of code that does "call do_IRQ" (unless linus
    removed that later) and the other low level routines are similarly
    labled. RTLinux is going to be nearly totally moduler and the init
    code in the rtl module will patch that code to call rtl_intercept
    instead of do_IRQ. What's missing for me now is an ifdefed code
    section that will fill in a data structure with the pointers
    #ifdef RTL_CONFIG
    struct rtl_code {
    void * call_common,do_irq,call_smpx,do_smpx ...
    irq_desc, ... }
    = initialize
    #endif

    Then there is a similar size ifdefed parts in system.h
    #ifdef RTL_CONFIG
    struct irq_control { do_cli,do_sti .... }

    #define __cli() irq_control.do_cli()
    ...

    and the export in ksysms

    On insert the rtl module will patch the code, make a copy
    of irq_desc handler list, replace irq_desc.handler in eah irq
    with a soft handler pointer and change the irq_control structure
    to point to soft cli and soft sti etc.

    Anyway, that's the theory.


    On module cleanup, the rtl module will unpatch and restore everything
    to original. Interstingly enough, lmbench shows no performance
    consequences of replacing cli/sti with indirect function calls.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.023 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site