It is still the same in latest version of kernel (2.6.8.1). Check the code of latest kernel at following link: http://lxr.linux.no/source/arch/i386/kernel/irq.c?v=2.6.8.1#L219 The above link is for handle_IRQ_event() function, see the lines from 225 to 232 in this function, its still the same ...... Regards, Gaurav. -----Original Message----- From: manish regmi [mailto:manish_regmi@xxxxxxxxxxx] Sent: Thursday, September 16, 2004 1:07 PM To: Dhiman, Gaurav Cc: kernelnewbies@xxxxxxxxxxxx Subject: Re: Interrupt Handling Doubts .... > >I agree with you that, do_IRQ() is called for each hardware interrupt >generated, but in case of shared interrupts one interrupt line can be >shared between different driver (devices), so in shared interrupt case >each entry in irq_desc[] array will point to queue of handlers which >will be called one by one when the interrupt occurs. > >From do_IRQ() function, handle_IRQ_event() function is called to invoke >all the handlers in queue for that IRQ (see the code of do_IRQ() >http://lxr.linux.no/source/arch/i386/kernel/irq.c?v=2.4.21#L563). >handle_IRQ_event() function is responsible for invoking all the handlers >registered for that IRQ by different drivers. > >What I am saying is that, in handle_IRQ_event() function >(http://lxr.linux.no/source/arch/i386/kernel/irq.c?v=2.4.21#L437) code >is only checking the flag of first handler in this queue of handlers, >that means it is only checking the flag of handler pointed by >'irq_desc[irq]" and does not check the flag of each handler in queue >before invoking the handler. > >This can lead to some problems, like if the first handler for that IRQ >number wants itself to be invoked as a slow interrupt handler (handler >flag not set to SA_INTERRUPT), the kernel will call __sti() function to >enable the interrupts on local CPU before invoking the interrupt >handler. Now for the second, third or any other handler in queue want >itself to be invoked as fast interrupt handler (flag set to >SA_INTERRUPT), kernel should call __cli() before invoking that >particular handler, which it is not doing right now. > > >In 2.4 kernel, the code in handle_IRQ_event is like this" > > if (!(action->flags & SA_INTERRUPT)) > __sti(); > > do { > status |= action->flags; > action->handler(irq, action->dev_id, regs); > action = action->next; > } while (action); > > >Where as what I think the code should be as follows to check the flag of >each handler before actually invoking it: > > do { > if (!(action->flags & SA_INTERRUPT)) > __sti(); > else > __cli(); > status |= action->flags; > action->handler(irq, action->dev_id, regs); > action = action->next; > } while (action); > > > >I clarified the same thing with Rubini also, he also agrees to it that >it might be a bug. >I hope I made my things clear. > >Cheers !! >Gaurav > > > >-----Original Message----- >From: manish regmi [mailto:manish_regmi@xxxxxxxxxxx] >Sent: Wednesday, September 15, 2004 2:36 PM >To: Dhiman, Gaurav >Cc: kernelnewbies@xxxxxxxxxxxx; drizzd@xxxxxx >Subject: RE: Interrupt Handling Doubts .... > > > > > >I think the bug is that we are checking the flag of only first handler > >and not checking the flags of other handlers in queue. But I don't >agree > >to your point that if there are arbitrary number f handlers of an IRQ, > >we can not handle them fast. We can do that enabling or disabling the > >interrupts according to the flag of each handler in queue. > > > >Gaurav > > > > > >-----Original Message----- > >From: Clemens Buchacher [mailto:drizzd@xxxxxx] > >Sent: Wednesday, September 15, 2004 9:50 PM > >To: Dhiman, Gaurav; kernelnewbies@xxxxxxxxxxxx > >Subject: Re: Interrupt Handling Doubts .... > > > >On Fri, Sep 10, 2004 at 01:47:44PM +0200, Clemens Buchacher wrote: > > > > - In handle_IRQ_event() function > > > > (http://lxr.linux.no/source/arch/i386/kernel/irq.c?v=2.4.21#L437), > > > > before calling the actual interrupt handler why are we checking >the > >flag > > > > of only first handler in list. > > > > > > Good point. I guess that's a bug then. > > > >OTOH, using both SA_INTERRUPT _and_ SA_SHIRQ is a bug anyhow, because > >the interrupt handler cannot guarantee to be fast any more if an > >arbitrary number of interrupt handlers can be run. The kernel could > >issue a warning though... > > Oh yes, But the same thing is done in latest 2.6.8. There might be some reason. May be LKML people can give clear view. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
