![]() | |||||||||||||
Messages in this thread |
On Wed, 25 Jun 2003, Pavel Machek wrote: > > Admittedly I didn't care about swsusp so far. Given the big fat warning on > > top of Documentation/swsusp.txt I would not even try and i personally > > don't see what I would miss without swsusp. > > That's okay... Just support your DMA-ing devices are supported. No matter whether it would be ISA-DMA or PCI busmastering I guess? Not sure whether we can claim most irda drivers ready for swsusp then. vlsi_ir should be fine and for irda-usb I assume it would be up to the hcd - but don't know about the others... > > For the meantime, I think we should apply this if somebody would explain > > what's going on here. > > We need kernel thread to sleep at defined place. Process running > userspace can be stopped any time, but processes running in kernel can > be only stopped at defined places, to avoid unexpected surprises. Ok, thanks for explaining! > If it is possible to sleep at place "a", and no locks needed for > suspend are held at "a", inserting > > if (current->flags & PF_FREEZE) > refrigerator(PF_IOTHREAD); > > is the right thing to do. Ok, so the proposed patch is doing the right thing and should be applied. Pavel, two more questions: * For a kernel compiled with CONFIG_SWSUSP=n, may I assume PF_FREEZE would never be set or at least refrigerator would be noop? * Isn't there a race on SMP (and probably UP with CONFIG_PREEMPT) when PF_FREEZE gets modified by another cpu right after the test? Thanks Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:36 [from the cache] ©2003-2008 | |||||||||||||