| Message ID | 5D03870E0200007800238473@prv1-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: S3 resume adjustments | expand |
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 <jbeulich@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
On 29.08.2019 16:45, Andrew Cooper wrote: > On 14/06/2019 12:37, Jan Beulich wrote: >> --- >> 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. Well, mode restoration may of course hang due to BIOS issues. But in such a case the question is how sensible it is to use S3 on such a system. Also note that adjusting this isn't going to reduce the quantity of 16-bit code; it would only be a change to what video_flags defaults to. Right now, without the command line option provided, mode restoration would happen only if reset_videomode_after_s3() gets invoked, i.e. just on a single Toshiba laptop model which I guess didn't even have 64-bit capable CPUs. Jan
--- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -455,14 +455,17 @@ check_vesa: cmpb $0x99, %al jnz _setbad # Doh! No linear frame buffer. + pushw %bx subb $VIDEO_FIRST_VESA>>8, %bh orw $0x4000, %bx # Use linear frame buffer movw $0x4f02, %ax # VESA BIOS mode set call int $0x10 + popw %bx cmpw $0x004f, %ax # AL=4f if implemented jnz _setbad # AH=0 if OK movb $1, bootsym(graphic_mode) # flag graphic mode + movw %bx, bootsym(video_mode) stc ret
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 <jbeulich@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. --- 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.