dose ISR could be PREEMPTIVED in linux-2.6 ? - Linux

This is a discussion on dose ISR could be PREEMPTIVED in linux-2.6 ? - Linux ; we know, a kernel task could be preemptived in 2.6, but i'm not sure that does a ISR routine could be preemptived in 2.6. any one have practice with this problem? thanks for hare the description on it....

+ Reply to Thread
Results 1 to 11 of 11

Thread: dose ISR could be PREEMPTIVED in linux-2.6 ?

  1. dose ISR could be PREEMPTIVED in linux-2.6 ?

    we know, a kernel task could be preemptived in 2.6, but i'm not sure
    that does a ISR routine could be preemptived in 2.6.

    any one have practice with this problem? thanks for hare the
    description on it.

  2. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    lion3875 wrote:
    > we know, a kernel task could be preemptived in 2.6, but i'm not sure
    > that does a ISR routine could be preemptived in 2.6.
    >
    > any one have practice with this problem? thanks for hare the
    > description on it.


    I'm no expert on kernel internals, but my guess (without checking) would be
    the ISR would need to be atomic.

    Otherwise, if an interrupt could interrupt the interrupt service routine
    causing the interrupt service routine to run again...
    Well, everything would get very messy very quickly.
    It might end up spending all its time attempting to service interrupts but
    not actually get a chance to complete any of them.
    --
    | |What to do if you find yourself stuck in a crack|
    | spike1@freenet.co.uk |in the ground beneath a giant boulder, which you|
    | |can't move, with no hope of rescue. |
    | Andrew Halliwell BSc |Consider how lucky you are that life has been |
    | in |good to you so far... |
    | Computer Science | -The BOOK, Hitch-hiker's guide to the galaxy.|

  3. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    After takin' a swig o' grog, Andrew Halliwell belched out
    this bit o' wisdom:

    > lion3875 wrote:
    >> we know, a kernel task could be preemptived in 2.6, but i'm not sure
    >> that does a ISR routine could be preemptived in 2.6.
    >>
    >> any one have practice with this problem? thanks for hare the
    >> description on it.

    >
    > I'm no expert on kernel internals, but my guess (without checking) would be
    > the ISR would need to be atomic.
    >
    > Otherwise, if an interrupt could interrupt the interrupt service routine
    > causing the interrupt service routine to run again...
    > Well, everything would get very messy very quickly.
    > It might end up spending all its time attempting to service interrupts but
    > not actually get a chance to complete any of them.


    I'm looking at Robert Love's book on Linux Kernel Development, and it
    says that interrupt handlers in Linux don't need to be reentrant,
    because the corresponding interrupt line is masked out on all
    processors on the system, so that the interrupt handler call is
    never nested.

    It also indicates that interrupt handlers are interruptable. They also
    cannot block. They're divided into two halves, each half meant for
    different work.

    There's a lot to 'em, and I'd recommending finding that book (or its
    equivalent on the web) and studying it. There's no pat answer.

    --
    No one can make you feel inferior without your consent.
    -- Eleanor Roosevelt

  4. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    On 2008-10-03, Chris Ahlstrom wrote:
    > After takin' a swig o' grog, Andrew Halliwell belched out
    > this bit o' wisdom:
    >
    >> lion3875 wrote:
    >>> we know, a kernel task could be preemptived in 2.6, but i'm not sure
    >>> that does a ISR routine could be preemptived in 2.6.
    >>>
    >>> any one have practice with this problem? thanks for hare the
    >>> description on it.

    >>
    >> I'm no expert on kernel internals, but my guess (without checking) would be
    >> the ISR would need to be atomic.
    >>
    >> Otherwise, if an interrupt could interrupt the interrupt service routine
    >> causing the interrupt service routine to run again...
    >> Well, everything would get very messy very quickly.
    >> It might end up spending all its time attempting to service interrupts but
    >> not actually get a chance to complete any of them.

    >
    > I'm looking at Robert Love's book on Linux Kernel Development, and it
    > says that interrupt handlers in Linux don't need to be reentrant,
    > because the corresponding interrupt line is masked out on all
    > processors on the system, so that the interrupt handler call is
    > never nested.
    >
    > It also indicates that interrupt handlers are interruptable. They also
    > cannot block. They're divided into two halves, each half meant for
    > different work.
    >
    > There's a lot to 'em, and I'd recommending finding that book (or its
    > equivalent on the web) and studying it. There's no pat answer.


    I thought you had to use the "CLI" instruction (x86) to disable
    interrupts at the start of your interrupt handler then enable interrupts
    with the "STI" instruction when your handler is finished. Data storage
    has to be set using "sig_atomic_t" so that the data is read/written in
    one instruction..

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  5. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    After takin' a swig o' grog, Gregory Shearman belched out
    this bit o' wisdom:

    > On 2008-10-03, Chris Ahlstrom wrote:
    >
    >> There's a lot to 'em, and I'd recommending finding that book (or its
    >> equivalent on the web) and studying it. There's no pat answer.

    >
    > I thought you had to use the "CLI" instruction (x86) to disable
    > interrupts at the start of your interrupt handler then enable interrupts
    > with the "STI" instruction when your handler is finished. Data storage
    > has to be set using "sig_atomic_t" so that the data is read/written in
    > one instruction..


    Could be, but the Love's book didn't mention it. Maybe you don't have
    to do that any more with the 2.6 kernel. Plus the top half requires a
    different strategy from the bottom half, from what I've read.

    --
    Providence, New Jersey, is one of the few cities where Velveeta cheese
    appears on the gourmet shelf.

  6. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    On 2008-10-04, Chris Ahlstrom wrote:
    > After takin' a swig o' grog, Gregory Shearman belched out
    > this bit o' wisdom:
    >
    >> On 2008-10-03, Chris Ahlstrom wrote:
    >>
    >>> There's a lot to 'em, and I'd recommending finding that book (or its
    >>> equivalent on the web) and studying it. There's no pat answer.

    >>
    >> I thought you had to use the "CLI" instruction (x86) to disable
    >> interrupts at the start of your interrupt handler then enable interrupts
    >> with the "STI" instruction when your handler is finished. Data storage
    >> has to be set using "sig_atomic_t" so that the data is read/written in
    >> one instruction..

    >
    > Could be, but the Love's book didn't mention it. Maybe you don't have
    > to do that any more with the 2.6 kernel. Plus the top half requires a
    > different strategy from the bottom half, from what I've read.


    Hmmm... perhaps C either implicitly sets these instructions or doesn't
    worry about reentrancy and leaves it up to the programmer to handle
    these probs, ie setting up a signal queue...

    Can't really remember that much. I used to do a lot of signal handling
    once upon a time, but not much these days.

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  7. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    On Oct 3, 7:39*am, Andrew Halliwell wrote:
    > lion3875 wrote:
    > > we know, a kernel task could be preemptived in 2.6, but i'm not sure
    > > that does a ISR routine could be preemptived in 2.6.

    >
    > > any one have practice with this problem? thanks for hare the
    > > description on it.

    >
    > I'm no expert on kernel internals, but my guess (without checking) would be
    > the ISR would need to be atomic.
    >
    > Otherwise, if an interrupt could interrupt the interrupt service routine
    > causing the interrupt service routine to run again...
    > Well, everything would get very messy very quickly.
    > It might end up spending all its time attempting to service interrupts but
    > not actually get a chance to complete any of them.



    You mask the interrupt(s) you want to ignore.

    As for the original question, certain ISRs are already preempted by
    other ISRs. What problem are trying to fix?

  8. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    After takin' a swig o' grog, Gregory Shearman belched out
    this bit o' wisdom:

    > On 2008-10-04, Chris Ahlstrom wrote:
    >>
    >> Could be, but the Love's book didn't mention it. Maybe you don't have
    >> to do that any more with the 2.6 kernel. Plus the top half requires a
    >> different strategy from the bottom half, from what I've read.

    >
    > Hmmm... perhaps C either implicitly sets these instructions or doesn't
    > worry about reentrancy and leaves it up to the programmer to handle
    > these probs, ie setting up a signal queue...
    >
    > Can't really remember that much. I used to do a lot of signal handling
    > once upon a time, but not much these days.


    And I've never done it at all, just some light reading on it.

    --
    Monitor not included.

  9. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    Chris Ahlstrom writes:

    > After takin' a swig o' grog, Gregory Shearman belched out
    > this bit o' wisdom:
    >
    >> On 2008-10-04, Chris Ahlstrom wrote:
    >>>
    >>> Could be, but the Love's book didn't mention it. Maybe you don't have
    >>> to do that any more with the 2.6 kernel. Plus the top half requires a
    >>> different strategy from the bottom half, from what I've read.

    >>
    >> Hmmm... perhaps C either implicitly sets these instructions or doesn't
    >> worry about reentrancy and leaves it up to the programmer to handle
    >> these probs, ie setting up a signal queue...
    >>
    >> Can't really remember that much. I used to do a lot of signal handling
    >> once upon a time, but not much these days.

    >
    > And I've never done it at all, just some light reading on it.


    Thanks for that contribution.

    C doesn't "implicitly" do anything. Its not defined in the standard.

    All handling must be done at the programmer level. In some cases kernel
    type code drops into ASM for platform specific non divisible operators
    to achieve this level of lock.




  10. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    On 3 Oct 2008 23:58:11 GMT, Gregory Shearman wrote:

    > I thought you had to use the "CLI" instruction (x86) to disable
    > interrupts at the start of your interrupt handler then enable
    > interrupts with the "STI" instruction when your handler is finished.


    That was never the right procedure, even in DOS. For one thing, it
    disables all interrupts on the current CPU, which is almost never
    necessary (see below).

    For another, the sti will always hard enable interrupts even if they
    were already disabled by the OS before your handler was called. That
    may not be a good idea. For that reason you should at least use the
    save/restore flags macros instead of cli/sti.

    In addition, the traditional x86 interrupt controller hardware masks the
    particular irq for your handler before the handler is called. So you
    can only be interrupted by higher-priority irq's, not another one of the
    same kind or lower.

    Linux carries this behavior across architectures.


    --
    -| Comrade Bob Hauck
    -| Proud part owner of the People's Insurance Company (formerly AIG)
    -| http://www.haucks.org/

  11. Re: dose ISR could be PREEMPTIVED in linux-2.6 ?

    On Fri, 3 Oct 2008 12:39:28 +0100, Andrew Halliwell
    wrote:

    > I'm no expert on kernel internals, but my guess (without checking)
    > would be the ISR would need to be atomic.


    Most interrupt controllers disable further interrupts at the same or
    lower priority levels until the current one is cleared. The ISR or the
    OS is responsible for this, depending on the system design.


    > Otherwise, if an interrupt could interrupt the interrupt service
    > routine causing the interrupt service routine to run again...


    ISR's typically allow higher-priority interrupts to happen while they
    run. This is usually not a problem. If it is, then the ISR must
    disable interrupts globally until it is safe to enable them again.


    > It might end up spending all its time attempting to service interrupts
    > but not actually get a chance to complete any of them.


    That can happen anyway if interrupts arrive at a high enough rate. Or
    if they are level-triggered and the ISR fails to clear them in the
    hardware that's requesting service 8->


    --
    -| Comrade Bob Hauck
    -| Proud part owner of the People's Insurance Company (formerly AIG)
    -| http://www.haucks.org/

+ Reply to Thread