<Tero.Kristo@xxxxxxxxx> writes: [...] >>Here's my hunch as to what's happening: >> >>I think the problem is a deadlock in getrawmonotonic(). Nested calls >>here will deadlock due to the xtime_lock being held. > > Looking at the seqlock code, I think a seqlock reader can "hang" only in a case where someone is constantly writing the seqlock. And, as we are inside interrupt, this should not be possible. > >>When updading the timeout, sleep_timeout_store() does a >>getrawmonotonic() to update the expiry time. While this happening, >>the UART interrupt could fire, causing an omap_uart_block_sleep() >>which would also getrawmonotonic() and deadlock in interrupt mode. > > It does not really explain why it hangs after the 5 second period though, as the device has called getrawmonotonic several times by this already. I have not seen this kind of behavior in my testing, even while fiddling with the sleep_timeout_store(). minor clarification... For me the hang is not after the 5 second timeout. For me it happens as soon as I write a non-zero value to /sys/devices/.../serial8250.2/sleep_timeout. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
