[Top] [All Lists]

MIPS - 2.4.20 kernel - wait_on_irq issue

Subject: MIPS - 2.4.20 kernel - wait_on_irq issue
From: Krishnamurthy Daulatabad <>
Date: Tue, 7 Dec 2004 01:03:50 -0800 (PST)
Comment: DomainKeys? See
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; b=BaxPSgxidVcwzAvZZJhmG6Ax8/Sxk80K10fUT5/jHeqlywHomlD7ke0dInfDEJadtux2m1ccNnUYTckhIgKkc3JjAZp4ewgKELxS36i8EG2xk11XIsbvniY1CA0k46OPCieRFgImYAzdt/5/F2/ACiwgL4fJkhKMkYwY9aFinls= ;
Original-recipient: rfc822;
  Request some clarification on the 2.4.20 MIPS kernel

Specifically refer to function wait_on_irq() in
arch/mips/kernel/irq.c. This function is called from 
get_irqlock() which in turn is called from
__global_cli eventually by cli().     
wait_on_irq() function does not return until "all the
CPUS" have run the ISRs.  To reach this state
interrupts have to be disabled on all the CPUs and
then wait for the ISRs to complete.  So __cli()
function called from this function is supposed to
disable the interrupts. The __cli() in MIPS will
disable the Interrupts by resetting the coprocessor
register's "Interrupt Enable"  bit which is per CPU. 
So this is going to just disable the interrupts on the
current CPU and not others.                           

So in  a SMP system with N CPUs, can there be a
situation where wait_on_irq() may never return as an
ISR could be running in one CPU or the other as the
interrupts are not being disabled on all the CPUs? The
irq_running() function may always return TRUE for a
large number of CPUs in this case.

So, is there a problem here or am I missing something?

2.6 kernel seems to be handling the cli() call


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

<Prev in Thread] Current Thread [Next in Thread>