On Fri, 24 Sep 2004, Oliver Neukum wrote: > > In PCI every state above 0 is "idle" -- but there's no reason that should > > be true for every device in the system. > > So remote wakeup needs to be disabled, doesn't it?
PCI remote wakeup is a peculiar thing. It's not a regular interrupt; it's a special signal on the PCI bus. I think when the system is running it has no effect (that might be wrong) and when the system is powered down it causes the power to be turned on. > > However when the restored image begins executing, drivers may expect the > > devices to be in the same state as before the image was created. This > > argues that idle devices must be in a known state, which is presumably one > > of minimum power usage. That would be okay, except: > > Presumably the state would be the state at power up. What if, as you suggest, there are other hosts on the bus using the device? Aren't they liable to alter the device from its power-up state? > > I don't know how late in the boot process the memory image is restored. > > At the very end. Before or after the init process begins running in userspace? > > But it's safe to guess that all the drivers may not have been loaded yet > > AFAICT the image includes all modules. No -- I'm not talking about the memory image; I'm talking about the bootup kernel. There may be modules stored in the memory image that aren't yet loaded into the bootup kernel when the resume-from-disk operation begins. > > Mass storage devices with removable media or that use a hot-pluggable > > transport will cause difficulty. When the memory image starts running it > > Why? Any device can be gone. And resumption is a bus operation. > It can fail. That must be handled. Certainly. Devices that are gone aren't a problem; the problem is devices that are still there but contain different data (because of a media change, for example). > A problem for higher layers. Higher layers should checksum media. I agree, but they don't always do it and it's not always practical. > > To be safe, the kernel must assume that all such devices have gone away > > when the image starts executing. Mounted filesystems would be in trouble. > > Ideally _all_ non-virtual filesystems should be unmounted during the > > suspend-to-disk, before the image is prepared. Restoring the device > > That negates the purpose of suspension. If you unmount everything > you are doing a conventional power cycle. Not true. User programs would remain running across a suspend. > At least that root fs must > remain mounted. But if something must stay mounted, everything can > remained mounted. Why must the root fs remain mounted? Why can't the kernel remount it before unfreezing the processes? Anyway, I didn't say everything _had_ to be unmounted, just that it would be good to do so. The only dangerous devices are ones with hot-pluggable transports or removable media. > > Assuming all devices are suspended, it is really necessary to resume > > everything in order to write the memory image to a partition? Or would it > > Depends on permissible swap partitions. If i-scsi is allowed all network > interfaces must be up. Or rather, there's no way to calculate which > would have to be up. At least, no easy way. What device does the i-scsi driver use as the parent for its SCSI host? > > suffice to resume just the swap device and its ancestors in the power > > tree? Come to think of it, is a tree really the right sort of data > > structure to express the power dependencies in the system? Isn't it > > possible to have devices that won't work right unless _several_ other > > devices (not all of them its ancestors) are powered on? > > Nevertheless the ordering constraints must be met requiring a tree. It seems to me you've just indicated a case (i-scsi) where a tree is insufficient, because the network adapters that must be turned on before using an i-scsi host aren't among the ancestors of that host. The ordering constraints are _more_ strict than can be expressed using a tree. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
