Linux-kernel mailing list archive 1999-34,: Re: Trying to free free IRQ

# Re: Trying to free free IRQ

mullein (mullein@aa.net)
Sun, 22 Aug 1999 17:50:43 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David Ford: "2.3.15p2, /proc related oops/crash/reboot"
- Previous message: Alan Cox: "Re: [PATCH] [RFC] x86 SMP lazy FPU context switching"

I've mentioned this before, though possible a little unclearly. And I'd
like to disclaim that I only think I know what I'm talking about and could
be wrong.
2.3.11 did not issue the "Trying to free free irq 4" message, 2.3.14 did.
Only my mouse is on irq 4. It appears that the code at the end of
free_irq() in arch/i386(in my case)/kernel/irq.c has changed.
free_irq() scans a linked list of actions on the irq passed to it for ones
that match dev_id and removes them from the list of entries. In both
versions of the code, the following is done when dev_id matches the
current one:
*p=action->next;
if(!irq_desc[irq].action) {
irq_desc[irq].status |= IRQ_DISABLED;
irq_desc[irq].handler->shutdown(irq);
}
}

now, 2.3.11 would call spin_unlock_irqrestore(); and then barrier() as
long as status & IRQ_IN_PROGRESS "to make sure its not being used by
another CPU". as soon as status was not maskable with IRQ_IN_PROGRESS,
kfree() and return are called. Outside of the for loop, at the end,
printk("Trying to free free IRQ %D") was called along with
spin_unlock_irqrestore() AGAIN - which means that kfree and
spin_unlock_irqrestore were never reached in the function except in the
case that dev_id wasn't in the list of irq actions.

2.3.14, on the other hand, simply ends the loop with the common code, and
then calls kfree and spin_unlock_irqrestore(). There is no return() inside
the loop any longer, so when the for loop is finished it should always
reach kfree() and spin_unlock_irqrestore().

questions
1. It seems to me like the 2.3.11 behavior was incorrect. Why, if i only
have one device, is it trying to free the irq?

2. Since the logic for checking on other cpus for irq actions is gone, how
does this affect smp machines?

mullein

On Sun, 22 Aug 1999, Trever Adams wrote:

> I disagree Sam. If that is what it is meant to do, then something is
> broken. My modem is on IRQ3 (ppp tests as well). There is NO other
> device on that irq unless the new PnP routines have assigned some other
> device that irq on boot, but from boot messages and /proc/interrupts, it
> hasn't. Also, now in 2.3.14 (first 2.3 I have tried), my serial ports
> do NOT show up in /proc/interrupts!
>
> Trever
>
> EPOX MPV3-C Motherboard with 128 meg of SDRAM, Permedia 2 video, NetGear
> FA310TX card, Symbios scsi card (Diamond Dual FirePort 40), USRobotics
> 56k modem (non PnP mode), and I believe that is it.
>
> From: Smc659@aol.com
> Date: Fri, 20 Aug 1999 21:00:02 EDT
> Subject: Re: Trying to free free IRQ
>
> Its trying to free an IRQ thats in conflict with another. If IRQ3 only
> shows
> up on PPP then it must be your modem. Have you added any new devices
> lately?
>
> Sam
>
> -
> 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/
>

-
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/

- Next message: David Ford: "2.3.15p2, /proc related oops/crash/reboot"
- Previous message: Alan Cox: "Re: [PATCH] [RFC] x86 SMP lazy FPU context switching"