Date: Thu, 26 Apr 2018 12:54:14 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: suspend/resume does not work in qemu (qemu-devel) Message-ID: <39728d5a-0a40-b888-f91b-a9cef66c40c2@FreeBSD.org> In-Reply-To: <09a48756-2dda-e830-5943-c7f1b9fa053a@FreeBSD.org> References: <09a48756-2dda-e830-5943-c7f1b9fa053a@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/04/2018 11:54, Andriy Gapon wrote: > > Not sure if this really matters and on what end the problem might be, but > resuming from S3 in qemu is stuck forever here: It seems that the same issue _might_ affect real hardware if sc (syscons) console is used. What I see is that a system suspends and resumes fine with vt. If I switch to sc then I see the following message during suspend (never seen with vt): vga0: saving 1024 bytes of video state And the system fails to resume. Of course, it is much harder to tell with the real hardware where the resume fails. So, I am not sure. > #3 x86emu_exec_one_byte (emu=0xffffffff81eac618 <x86bios_emu>) at > /usr/devel/git/cpu-pause/sys/contrib/x86emu/x86emu.c:4655 > #4 0xffffffff8106c398 in x86emu_exec (emu=0xffffffff81eac618 <x86bios_emu>) at > /usr/devel/git/cpu-pause/sys/contrib/x86emu/x86emu.c:246 > #5 0xffffffff8106b8d4 in x86bios_intr (regs=0xfffffe002e1933f0, intno=16) at > /usr/devel/git/cpu-pause/sys/compat/x86bios/x86bios.c:634 > #6 0xffffffff80fb7cd2 in vesa_bios_save_restore (code=2, p=0xfffff8000365e004) > at /usr/devel/git/cpu-pause/sys/dev/fb/vesa.c:551 > #7 vesa_load_state (adp=<optimized out>, p=<optimized out>) at > /usr/devel/git/cpu-pause/sys/dev/fb/vesa.c:1535 > #8 0xffffffff810632e0 in vga_resume (dev=0xfffff800039eb100) at > /usr/devel/git/cpu-pause/sys/isa/vga_isa.c:112 > #9 0xffffffff8106311e in isavga_resume (dev=0xfffff800039eb100) at > /usr/devel/git/cpu-pause/sys/isa/vga_isa.c:243 > #10 0xffffffff80ac2de4 in DEVICE_RESUME (dev=<optimized out>) at ./device_if.h:305 > ... > > Using -vga none works around the problem, of course. > Maybe it's buggy video BIOS in the emulation. > -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39728d5a-0a40-b888-f91b-a9cef66c40c2>