* Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> [150804 13:48]: > [ +cc Felipe, Tony ] > > On 08/03/2015 08:18 PM, Charles Manning wrote: > > On Tue, Aug 4, 2015 at 11:56 AM, Greg KH <greg@xxxxxxxxx> wrote: > >> On Tue, Aug 04, 2015 at 10:23:12AM +1200, Charles Manning wrote: > >>> I am debugging an issue on the OMAP where the serial irq processing is > >>> normally low (around 1%) but can sometimes rise to much higher (well > >>> over 10%). > >>> > >>> This lead me to sniff around the locking.... > >>> > >>> I notice that in some drivers eg. omap-serial.c the whole interrupt > >>> handling loop is locked via spin_lock(). > > That looks like a deadlock waiting-to-happen to me. For example, > > ==> IRQ > serial_omap_irq() > spin_lock(port->lock) > ... > ==> higher priority IRQ > handler in some other driver > printk() > console_unlock() > call_console_drivers() > serial_omap_console_write() > spin_lock(port->lock) > ** DEADLOCK ** > > Felipe, Tony, this is possible on OMAP, right? Well I think on SMP cores it's just very inefficient, and on the UP cores we just handle one interrupt at a time and FIQs are used by the bootrom code. But looking at that code again I'm wondering absout the use of pm_runtime calls from the interrupt handlers.. The last time I tried to remove pm_runtime_irq_safe from serial-omap and 8250 I ran into weirdness on SMP systems I believe. Have to give it another try with the generic wakeirqs at some point. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
