On Tue, 1 Jun 2010, Neil Brown wrote: > > As I said before, we generally can't prevent such things from happening, > > because even if we handle the particular race described above, it still is > > possible that the event will be "lost" if it arrives just a bit later (eg. > > during a suspend-toggle switch). So the PRE_SUSPEND thing won't really > > solve the entire problem while increasing complexity. > > > > > My freerunner has a single core so without CONFIG_PREEMPT it may be that > > > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a > > > soft_irq thread has a chance to finish handling of the interrupt (my > > > knowledge of these details is limits). But on a muilti-core device I think > > > there would definitely be a race-window. > > > > Yes, there always will be a race window. The only thing we can do is to > > narrow it, but we cannot really close it (at least not on a PC, but I'm not > > really sure it can be closed at all). > > Well you are the expert so I assume you are right, but I would really like to > understand why this is. > > I guess that if the event was delivered as an edge-triggered interrupt which > the interrupt controller couldn't latch, then it might get lost. Is that > what happens? You're barking up the wrong tree. If I understand correctly, Rafael is saying that there's a race involving events which are not _wakeup_ events. If a non-wakeup event arrives shortly before a suspend, it can have its normal effect. If it arrives while a suspend is in progress, its delivery may be delayed until the system resumes. And if it arrives after the system is fully suspended, it may never be noticed at all. With wakeup events the problem isn't so bad. Wakeup events are always noticed, and if the system is designed properly they will either abort a suspend-in-progress or else cause the system to resume as soon as the suspend is complete. (Linux is not yet properly designed in this sense.) Or maybe I'm misunderstanding also, and Rafael is saying that there's a race involving events whose meaning changes depending on whether or not the system is asleep. This is obviously true and clearly unavoidable. > And if you are right that the race window cannot be closed, then the whole > suspend-blocker infrastructure is pointless as the purpose of it is simply to > close that window. If it really does not and cannot work, then it would be > best to reject it for that reason rather than for less concrete aesthetic > arguments. > But presumably it does work in practice on Android hardware so ..... confused. The point you're missing is that Android works with regard to wakeup events. It doesn't necessarily always receive non-wakeup events (although I don't know how Android classifies events -- maybe everything is a wakeup event for them). Alan Stern -- 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
