On 14/06/2019 12:37, Jan Beulich wrote: > In order for "acpi_sleep=s3_mode" to have any effect, we should record > the video mode we switched to during boot. Since right now there's mode > setting code for VESA modes only in the resume case, record the mode > just in that one case. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > RFC: On the box that I've been trying to test this on this didn't really > make a difference (in the random cases where resume works in the > first place there): The graphics card looks to remain powered off > even after the Dom0 kernel has resumed. Additionally using > "acpi_sleep=s3_bios" didn't make a difference either. Furthermore > it looks like the serial console (connected via PCI card) doesn't > work (yet) immediately after resume (I suppose it too is powered > down), and resume hangs altogether with it in use. Hence it's sort > of difficult to actually debug anything here.
While you were away, I had an awful time debugging c/s 7aae9c1c91, even with COM1. I think we should take some proactive steps to try and make the serial settings more robust, so printk() does continue to function before the console irq gets restored. In the case of legacy COM1/COM2, this should be falling back to polled mode which at least lets the characters get out, and for PCI serial cards, we should probably make an attempt to bring it out of D3 ahead of relying on dom0 to do this. > --- > I'm wondering actually whether the user having to explicitly request the > mode restoration is a good model: Why would we _not_ want to restore the > mode we've set during boot? In the worst case Dom0 kernel or X will > change the mode another time. I think I agree. I can't see anything good which can come from offering a choice here, and I am all for reducing the quantity of 16bit VGA code we have. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
