Re: [PATCHv5] OMAP3: Serial: Improved sleep logic

[Kevin Hilman <khilman@deeprootsystems.com>]

<Tero.Kristo@nokia.com> 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