serial 8250 driver causing "irq nobody cared" messages

[Ian Campbell]

Hi all,

I am seeing lots of instances of "irq27: nobody cared". This appears to
be because a second UART interrupt occurs while the serial8250_interrupt
is running, this interrupt is then delayed by the logic in do_edge_IRQ.
The first invocation of the interrupt handler deals with this second
interrupt before returning, at which point the delayed interrupt is
dispatched. However there is now no work to be done so
serial8250_interrupt returns IRQ_NONE.

My board has a PXA255 and an additional UART (an XR16C2852) on GPIO4
(IRQ27). The interrupt is configured as a rising edge interrupt although
the hardware pin is active high. This interrupt is not shared although I
do have CONFIG_SERIAL_8250_SHARE_IRQ enabled.

I am using the attached patch to add some debugging and this is what I
see:

unmask gpio 4
GEDR0 triggers interrrupt
ack gpio 4
serial8250_interrupt(27)...iir = c2...status = 60...THRE...GEDR0 triggers interrrupt
irq is already running. delay it
mask gpio 4
ack gpio 4
iir = c1...end: handled=1.
unmask gpio 4
serial8250_interrupt(27)...iir = c1...end: handled=0.
irq27: nobody cared
(snip stack trace etc)
handlers:
[<c010219c>] (serial8250_interrupt+0x0/0x184)

I happened to notice this when I was updating my board code to use a
platform device rather than arch-pxa/serial.h but I think that is a
coincidence. At the same time I also upgraded from 2.6.10-rc1-bk14 to
the latest -bk17 snapshot which I believe included a patch to make
serial8250_interrupt() properly return IRQ_NONE if it didn't do
anything. I think it is this change which has unmasked an existing
problem. However I'm not sure if the problem is with the board interrupt
configuration, the pxa interrupt handling or the serial code. Any ideas?

Thanks,
Ian.

[Russell King - ARM Linux]

Post by Ian Campbell
I happened to notice this when I was updating my board code to use a
platform device rather than arch-pxa/serial.h but I think that is a
coincidence.

It is coincidence. Around that time, I put in a change to return the
correct IRQ handler state, since another architecture ports IRQ subsystem
requires handlers to return IRQ_NONE when no IRQ work has been done.

Unfortunately, this is fundamentally incompatible with the serial ports
connected to edge triggered outputs.

I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Nicolas Pitre]

Post by Russell King - ARM Linux

Post by Ian Campbell
I happened to notice this when I was updating my board code to use a
platform device rather than arch-pxa/serial.h but I think that is a
coincidence.

It is coincidence. Around that time, I put in a change to return the
correct IRQ handler state, since another architecture ports IRQ subsystem
requires handlers to return IRQ_NONE when no IRQ work has been done.
Unfortunately, this is fundamentally incompatible with the serial ports
connected to edge triggered outputs.
I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

Why not adding a flag like UPF_POSSIBLE_SPURIOUS_IRQS that returns
IRQ_HANDLED unconditionally when set?


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Thomas Gleixner]

Post by Nicolas Pitre

Post by Russell King - ARM Linux

Post by Ian Campbell
I happened to notice this when I was updating my board code to use a
platform device rather than arch-pxa/serial.h but I think that is a
coincidence.

It is coincidence. Around that time, I put in a change to return the
correct IRQ handler state, since another architecture ports IRQ subsystem
requires handlers to return IRQ_NONE when no IRQ work has been done.
Unfortunately, this is fundamentally incompatible with the serial ports
connected to edge triggered outputs.
I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

Why not adding a flag like UPF_POSSIBLE_SPURIOUS_IRQS that returns
IRQ_HANDLED unconditionally when set?

Is this not a good reason to think about the integration into the
generic irq framework ? So those problems can be handled at one central
point.

I know that ARM IRQ handling has a lot of oddities, which are not shared
by other archs.

But I have already started to integrate ARM irqs into the generic
framework and it seems not to be totaly out of the world. A lot of
functions which are in the ARM infrastructure are either already almost
functionally equvillent available or if not, they could be useful for
other archs too. I have it up on two 720T machs, a 920T and a PXA. Give
me a day or two to clean up the #ifdef mess and I will provide a patch
for discussion.

Any thoughts ?

tglx



-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Russell King - ARM Linux]

Post by Nicolas Pitre

Post by Russell King - ARM Linux
It is coincidence. Around that time, I put in a change to return the
correct IRQ handler state, since another architecture ports IRQ subsystem
requires handlers to return IRQ_NONE when no IRQ work has been done.
Unfortunately, this is fundamentally incompatible with the serial ports
connected to edge triggered outputs.
I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

Why not adding a flag like UPF_POSSIBLE_SPURIOUS_IRQS that returns
IRQ_HANDLED unconditionally when set?

It isn't a property of the port. It's unfortunately a property of how
edge triggered interrupts work - it's impossible for a driver to clear
down an already triggered and therefore pending interrupt.

It's absolutely nothing to do with the device being a serial port or
even a SMC91x device. It's the edge triggered interrupt input itself.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Ian Campbell]

Post by Russell King - ARM Linux

Post by Nicolas Pitre

Post by Russell King - ARM Linux
I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

Why not adding a flag like UPF_POSSIBLE_SPURIOUS_IRQS that returns
IRQ_HANDLED unconditionally when set?

It isn't a property of the port. It's unfortunately a property of how
edge triggered interrupts work - it's impossible for a driver to clear
down an already triggered and therefore pending interrupt.

How about an IRQF_IGNORE_SPURIOUS flag then?

I bet there is a subtle/brutally obvious reason why some trick to
simulate a level triggered interrupt can't work but I think I'll ask
anyway :-). For example cancelling the pending interrupt on a falling
(or opposite) edge or checking GPLR before dispatching? The default mode
should clearly be as it is now, but an option the platform can enable on
a per interrupt basis?

Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: [phone]
Cambridge CB1 7EA, United Kingdom Phone: [phone]


-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Russell King - ARM Linux]

Post by Ian Campbell

Post by Russell King - ARM Linux

Post by Nicolas Pitre

Post by Russell King - ARM Linux
I suspect ARM people who have this particular weird IRQ setup will
have to get used to passing noirqdebug on the kernel command line to
turn off the "nobody cared" warnings.

Why not adding a flag like UPF_POSSIBLE_SPURIOUS_IRQS that returns
IRQ_HANDLED unconditionally when set?

It isn't a property of the port. It's unfortunately a property of how
edge triggered interrupts work - it's impossible for a driver to clear
down an already triggered and therefore pending interrupt.

How about an IRQF_IGNORE_SPURIOUS flag then?

I'm not sure. I think that there's a fundamental thing in that you
should ignore the IRQ_NONE return status if you're using an edge
triggered input. With such an input, you can never be sure whether
you really have any work to do or not.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Russell King - ARM Linux]

Post by Russell King - ARM Linux

Post by Ian Campbell
How about an IRQF_IGNORE_SPURIOUS flag then?

I'm not sure. I think that there's a fundamental thing in that you
should ignore the IRQ_NONE return status if you're using an edge
triggered input. With such an input, you can never be sure whether
you really have any work to do or not.

OK, I've just dropped #2219 into your patch system that adds the flag
which you can feel free to ignore :-). Perhaps all that is required is
to remove the
if (ret != IRQ_HANDLED)
report_bad_irq(irq, regs, desc, ret);
from arch/arm/kernel/irq.c:do_edge_IRQ? Would you like me to submit
another patch?

Yes please - that's probably the best way to get shot of this problem.

Thanks.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php