On Thu, 17 Mar 2005, Nigel Cunningham wrote: > > Given that on some platforms it's necessary to leave some IRQs enabled for > > remote wakeup to work, the definitions of FREEZE and SUSPEND need to be > > changed. A quiesced device does not perform DMA and does not generate > > interrupt requests _except_ that it may issue wakeup requests (which may > > be IRQs) if it is enabled for remote wakeup. > > I don't think the definition of FREEZE needs to be changed because - > unless I misunderstand - it is only used when swsusp and Suspend2 are > doing their atomic copies. Pavel, is this right? Nevertheless the definition still needs to be changed. As it stands now, moving from FREEZE to SUSPEND might involve an _increase_ in device activity -- namely, enabling resume IRQs. That's not what we want. > > I don't think this will cause any problems for Suspend To Disk. If a > > wakeup IRQ arrives before the system is asleep and is fielded by an > > interrupt handler, the handler will try to start a resume. But resume > > needs a process context to operate, and all processes will be frozen -- so > > nothing will happen. > > Does the handler try to start a usermode helper program? Depends on the details of the driver. But it's impossible to _fork_ a new process from an interrupt handler. You can try to _wakeup_ an existing process, but when the process is frozen it can't wake up. Alan Stern
