On Wed 2006-07-05 16:03:29, David Brownell wrote: > On Wednesday 05 July 2006 1:12 pm, Linus Torvalds wrote: > > > > On Wed, 5 Jul 2006, David Brownell wrote: > > > > > > I expect this is what you meant, but one issue I've observed > ^ "NOT" ... omitted by editing error, sorry > > > on at least one platform is that after swsusp resume the preempt > > > count is goofed ... it's one too big. Which in a recent test, meant > > > that resume failed because pci_set_power_state() got called in a > > > context that couldn't msleep(). And in previous tests has led to > > > similar failures, since resume() calls all expect sleeping is OK > > > (since that's part of that API contract). > > > > Yes. > > > > I had a patch that did > > > > system_state = SYSTEM_BOOTING; > > .. > > system_state = SYSTEM_RUNNING; > > > > around the final stages of suspend/resume, because the resume stage really > > _does_ end up looking like the boot: single CPU, various special code etc. > > > > And that gets rid of some of the warnings, and is arguably a valid thing > > to do (exactly because it's "true" to some degree that we're in the bootup > > state). > > Didn't try that. In this case, debug diagnostics confirmed that what > was happening was pretty strange (to me): the preempt count was goofed. > It was correct as the snapshot was being taken, but wrong after that > snapshot got resumed. I have seen that before: Atomic snapshot used fpu copy in some wrong variants. Symptom was exactly that -- elevated preempt count -- because fpu copy routine elevated it, then copied the task struct. But I thought we solved that problem...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
