interrupt handler

interrupt handler

Post by sanket rath » Sat, 24 Aug 2002 21:10:03



hi,
Can i use spin lock in the interrupt handler for a singlre processor machine. because books says u can not use locks but spin lock is some thing diffrent

thanks in advance

--Sanket
---------
--
Get your free email from www.linuxmail.org

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by Kerenyi Gabo » Sat, 24 Aug 2002 21:10:05



Quote:>hi,
>Can i use spin lock in the interrupt handler for a singlre processor machine. because books says u can not use locks
>but spin lock is some thing diffrent

Yes you can. Spinlocks will be compiled in if you choose SMP even on single processor machine.
But look at the documentation in the kernel source.
I think "lock" in your message is a semaphore in real life.

Spinlocks never sleep - they don't perform task switch and you can use them anywhere, while semaphores
can sleep and you can use them only in user context (not in interrupt or bottom half)

Gabor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by Richard B. Johnso » Sat, 24 Aug 2002 21:20:07



> hi,
> Can i use spin lock in the interrupt handler for a singlre processor
> machine. because books says u can not use locks but spin lock is some
> thing diffrent

> thanks in advance

> --Sanket
> ---------

Interrupts default to OFF within an interrupt handler. Given this,
why would you use a spin-lock within the ISR on a single-processor
machine?

To directly answer your question, YES, you can use a spin-lock
within an ISR even though it won't do anything except add code
on a single processor machine.

On multiple CPU machines, you can use the form of spin-lock that
does not save/restore interrupts within the ISR, and use the
save/restore versions, with the same lock variable, outside the
ISR.

Cheers,
* Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

interrupt handler

Post by Kerenyi Gabo » Sat, 24 Aug 2002 22:00:10




>> hi,
>> Can i use spin lock in the interrupt handler for a singlre processor
>> machine. because books says u can not use locks but spin lock is some
>> thing diffrent

>> thanks in advance

>> --Sanket
>> ---------

>Interrupts default to OFF within an interrupt handler. Given this,
>why would you use a spin-lock within the ISR on a single-processor
>machine?

Because he would like to write a code that can be run on a computer
with more than one CPU.

Anyway, do anybody know what kind of advantages/disadvantages I can get
if I don't disable interrupts at all in my driver? Even if I have to use a circular
buffer or anything else? Is it worth trying to find such a solution or is it
a wasted time?

Gabor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by Richard B. Johnso » Sat, 24 Aug 2002 22:10:08





> >> hi,
> >> Can i use spin lock in the interrupt handler for a singlre processor
> >> machine. because books says u can not use locks but spin lock is some
> >> thing diffrent

> >> thanks in advance

> >> --Sanket
> >> ---------

> >Interrupts default to OFF within an interrupt handler. Given this,
> >why would you use a spin-lock within the ISR on a single-processor
> >machine?

> Because he would like to write a code that can be run on a computer
> with more than one CPU.

> Anyway, do anybody know what kind of advantages/disadvantages I can get
> if I don't disable interrupts at all in my driver? Even if I have to
> use a circular
> buffer or anything else? Is it worth trying to find such a solution or is it
> a wasted time?

> Gabor

If your ISR manipulates any data, which is quite likely, then
your driver code, that is outside the ISR, must be written
with the knowledge that an interrupt can happen at any time.

There are probably certain critical regions of code that must
be protected against modification from the ISR code. You need
to protect those critical regions with spin-locks.

Spin-locks have very little code. If there is no contention,
they do not affect performance in any measurable way. If there
is contention, they simply delay execution of the ISR to a time
where code is executing in a non-critical section. This delay
is necessary so, even though it does affect performance, the
system would not work without it.

Cheers,
* Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

interrupt handler

Post by Kerenyi Gabo » Sat, 24 Aug 2002 22:40:07




>> Anyway, do anybody know what kind of advantages/disadvantages I can get
>> if I don't disable interrupts at all in my driver? Even if I have to
>> use a circular
>> buffer or anything else? Is it worth trying to find such a solution or is it
>> a wasted time?

>> Gabor

>If your ISR manipulates any data, which is quite likely, then
>your driver code, that is outside the ISR, must be written
>with the knowledge that an interrupt can happen at any time.

Well I wrote it in this way of course.

Quote:>There are probably certain critical regions of code that must
>be protected against modification from the ISR code. You need
>to protect those critical regions with spin-locks.

I know. But there are some technics that can be used to workaorund
the irq disabling thing.

Quote:>Spin-locks have very little code. If there is no contention,
>they do not affect performance in any measurable way. If there
>is contention, they simply delay execution of the ISR to a time
>where code is executing in a non-critical section. This delay
>is necessary so, even though it does affect performance, the
>system would not work without it.

I talked about irq disabling, not spinlocks. With or without spinlocks.
When you need synch between a bottom half(or user context) and irq
handler on single processor machine you can't use just spinlocks. you have to
disable the irq. so the question is about irq disabling to modify data
in a mutual way.
I solved it without disabling irq using a circular buffer (very simple one)
I think with this solution there is a better response time for the hardware
items. (they can get immediate response from the OS)

Gabor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by Robert Lov » Sun, 25 Aug 2002 01:20:08



> Interrupts default to OFF within an interrupt handler. Given this,
> why would you use a spin-lock within the ISR on a single-processor
> machine?

Only the current interrupt handler is disabled... interrupts are
normally ON.

        Robert Love

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by Richard B. Johnso » Sun, 25 Aug 2002 01:50:07




> > Interrupts default to OFF within an interrupt handler. Given this,
> > why would you use a spin-lock within the ISR on a single-processor
> > machine?

> Only the current interrupt handler is disabled... interrupts are
> normally ON.

>    Robert Love

No. Check out irq.c, line 446. The interrupts are turned back on
only if the flag did not have SA_INTERRUPT set. Certainly most
requests for interrupt services within drivers have SA_INTERRUPT
set.

This is linux-2.4.18 or 2.4.19. If the current code, 2.5+ enables
by default, it's broken and should be fixed.

Cheers,
* Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

interrupt handler

Post by Robert Lov » Sun, 25 Aug 2002 02:00:08




> > Only the current interrupt handler is disabled... interrupts are
> > normally ON.

> No. Check out irq.c, line 446. The interrupts are turned back on
> only if the flag did not have SA_INTERRUPT set. Certainly most
> requests for interrupt services within drivers have SA_INTERRUPT
> set.

Sigh... SA_INTERRUPT is used only for fast interrupts.  Certainly most
drivers do not have it (and most that do are probably from the way old
days when we went through great pains to distinguish between fast and
slow interrupt handlers).

Today, very few things should run with all interrupts disabled.  That is
just dumb.  In fact, on this system, it seems only the timer interrupt
sets SA_INTERRUPT...

        Robert Love

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

interrupt handler

Post by george anzinge » Sun, 25 Aug 2002 05:50:06





> > > Only the current interrupt handler is disabled... interrupts are
> > > normally ON.

> > No. Check out irq.c, line 446. The interrupts are turned back on
> > only if the flag did not have SA_INTERRUPT set. Certainly most
> > requests for interrupt services within drivers have SA_INTERRUPT
> > set.

> Sigh... SA_INTERRUPT is used only for fast interrupts.  Certainly most
> drivers do not have it (and most that do are probably from the way old
> days when we went through great pains to distinguish between fast and
> slow interrupt handlers).

> Today, very few things should run with all interrupts disabled.  That is
> just dumb.  In fact, on this system, it seems only the timer interrupt
> sets SA_INTERRUPT...

And THAT makes sense as most of the timer interrupt is
processed holding the write_lock() on xtime which would need
to be an irq lock otherwise.  If they were turned on the
system would have an additional interrupts on/off overhead.

>         Robert Love

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--

High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

1. Problems with interrupt handler

Hello,

i have a problem with an interrupt handler. When the interrupt occurs,
I got the following message:

Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In interrupt handler - not syncing

I am using the redhat 6.0 distributen with Kernel 2.2.5. The interrupt
handler does nothing else, than sending a sigusr2 to an application.

TIA
S. Heursch

2. two-headed RS/6000?

3. aiee, killing interrupt handler

4. more SGI bashing

5. aiee, killed interrupt handler - kernel panic

6. Netscape Plugins on AIX

7. driver: interrupt handler not getting called

8. telnet <file>output

9. Serializing data & device access across file ops and interrupt handler

10. SMP aic7xxx 2.4.3 boot panic: Aiee, killing interrupt handler

11. kernel panic, killing interrupt handler

12. interrupt handler not being called .

13. Kernel panic: Aiee, killing interrupt handler!