> STR does not need to "ensure that you have a consistent snapshot".
Linus I think someone's been spiking your guinness again... > Why? Becuase there is no _room_ for inconsistency. There's nothing to be > "inconsistent with", since any changes to memory (by things like DMA or > other setup that happens while the suspend process is going on) is by > _definition_ consistent with the resume image (becasue there is no > separate image). You bet there is. We need to know if data arrived or not, because there is no guarantee that the data retrieved if we inadvertently re-execute a command will be the same. The hardware state itself isn't the problem, its the combination of hardware state and internal state which need to match in some cases. > off DMA and try to make the hardware be wevy wevy quiet while it's hunting > wabbits, it's a lot easier to just do nothing at all on "freeze", and just > make sure that "thaw" will re-initialze the DMA tables entirely! All Who cares about DMA mapping tables, those are easy to deal with, not even that bad with an IOMMU to restore. More problematic is the users data because if we have a device where re-executing a command is not repeatable (eg O_DIRECT SCSI on a shared bus) then we risk being inconsistent in our S2RAM. If we re-run the command on resume having allowed it to prattle on while doing S2anything then we'll get the wrong answer. Now there are lots of devices we don't care about as they don't have state in the form that causes problems - network cards, TV capture etc, but there are cases where it matters that every operation is either finished or not started and there is no doubt about them getting done during the S2RAM/S2DISK S2DISK/S2RAM both need to synchronize the state of a device so it can build a valid snapshot. That bit is a shared requirement just like you said didn't exist. Doesn't even need to involve turning DMA off, just getting a consistent state. The rest can be quite different. Mind you some laptops think S2RAM is just a transition state on the way to disk, leave them in ACPI S2RAM and the firmware will magically turn it into a save to disk and back to ram if the battery runs low or you leave it idle too long. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
