Hi! > A problem with the PM_FREEZE state has surfaced recently. > > It has to do with the device state recorded in the memory image. When the > image is made, devices are in the FREEZE state, and that's what gets > recorded. But then the image is written to disk and devices are put into > SUSPEND. > > Later on, when the system wakes up and the image is restored, drivers are > asked to resume the devices. The problem is that now the drivers think > the devices are in FREEZE when in fact they are really in SUSPEND. The > difference is significant and it can cause errors in the resume procedure. No; devices are in FREEZE if their driver was in kernel, and in some kind of power up state when not. Drivers should just handle both. > Here's another, slightly more far-fetched problem. I don't know if this > can come up in actual practice. > > When a disk device is put in FREEZE, there may be pending write requests > in its I/O queue. After the image has been Can they? If so, we need to solve that somehow. ...it might happen with network devices, too. We would send packet twice. We should limit queueing in drivers across FREEZE... -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
