>-----Original Message----- >From: linux-omap-owner@xxxxxxxxxxxxxxx >[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of ext Kevin Hilman >Sent: 25 February, 2010 17:21 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@xxxxxxxxxxxxxxx >Subject: Re: [PATCHv5] OMAP3: Serial: Improved sleep logic > ><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. It looks somewhat weird... I did some debugging on this today and I am seeing the same hang here, and it actually seems to be caused by the getrawmonotonic() somehow, as the system did not hang anymore after I removed the calls. Anyway, I figured another way to solve the issues I am seeing. I reverted back to using jiffy timers, but added a workqueue for wakeups; now wakeup timers are kicked into action after the timebase is restored. I'll post the new patch right away. There is still one issue with the UART though; some TX is still lost because PM code does not currently prevent CORE off while PER is active, basically resetting the PER domain when CORE goes off. This would be fixed by the cpuidle set I posted a bit back. Another note, I am seeing really strange behavior for my n900 with current linux-omap tree. PM branch boots up nicely, but it does not go into dynamic idle until I force it to suspend once.... Also, master branch crashes mid-boot to an ubifs caused DMA failure. -Tero -- 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
