09.07.2011 14:36, Gleb Natapov wrote: > On Sat, Jul 09, 2011 at 02:09:46PM +0400, Michael Tokarev wrote: >>> Heh. Is this S4 or S3 suspend resume? Looks like recent breakage. >>> The only knows problem to me is in win7/2008 S3 resume + net. >> >> How can I know if it's S3 or S4? And I can't say it's recent: > S3 is suspend to memory, S4 is suspend to disk. Don't remember how > different version of Windows call them. Actually win7 disables S3 > when running on qemu with cirrus adapter, so you are probably doing > S4. Ahh, yes, I remember now. Yes I used suspend-to-disk aka hybernation on windows. And actually there's no error in there - it works. I thought it is stuck in an endless loop, but it actually did suspending and it completes eventially. The only problem is that it does not show anything at all, no progress, no messages, no nothing - the screen is completely blank. That's with -vga std which I usually use. I just retried with cirrus and the effect is the same -- blank guest screen and 100% cpu usage, but it takes much much longer to complete for some reason - several minutes instead of ~30s. It also takes lots of time when resuming, and the thing is less reliable too -- I've seen ~50/50 failure ratio at resuming with -vga cirrus. >> 0.14.1 works (or actually does not work) exactly the same in >> this respect as current git: suspend/resume is equally broken. > Suspend to disk worked flawlessly for me with Windows. There is nothing > special qemu should do for it to work. I haven't checked it on upstream > for a long time though. Can you check 0.12? It looks like 0.12 works the same way - at least the behavour is very similar. I also tried current qemu-kvm git and there, things are the same. >>>> What's wrong/broken in linux? Can it be fixed? >>>> >>> Complete lack of regression testing. >> >> Hm. You wrote: >> >>> Yes, but Linux and suspend/resume are not best friends. Sometimes it >>> works by mistake, but next merged patch fixes it and suspend/resume >>> returns to its normal broken state. >> >> So regression testing should detect and raise an alarm >> when it works by mistake. But can it be fixed to work >> by design instead, after which regression testing gets >> entrirely new meaning ? :) >> > Well S4/S3 is pet peeve of mine, so I little bit exaggerated :) Design > is not enough. Testing is needed. On Windows a driver that can't properly > handle S3/S4 will not pass WHQL, will not be signed by MS and will never > be loaded by the OS. So I'm completely confused. Is virtio designed to work or to fail on suspend/resume cycle? If the former, regression testing will help. If the latter, the design should be fixed first... ;) According to your words above it's designed to fail, so to say. Also, as far as I can see, it should be fixed on the guest side, ie, in linux virtio drivers, not in qemu/kvm (which appears to work with windows guests), right? Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
