Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Dec 2017 17:42:03 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-bugs@freebsd.org
Subject:   Re: [Bug 224069] (Fix included) Use of uninitalized register value in vesa.ko, causing X, text console and suspend/resume to fail
Message-ID:  <20171204171239.W2345@besplex.bde.org>
In-Reply-To: <20171204124654.G1571@besplex.bde.org>
References:  <bug-224069-8@https.bugs.freebsd.org/bugzilla/> <bug-224069-8-FPMQu9Aofi@https.bugs.freebsd.org/bugzilla/> <20171204124654.G1571@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Dec 2017, Bruce Evans wrote:

> On Mon, 4 Dec 2017 a bug that doesn't want replies@freebsd.org wrote:
>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224069
> ...
> I spent days looking for bugs near here.  Unfortunately, removing the
> commenting out doesn't fix them, since it has no effect except to undo the
> silly optimization.
> ...
> With at least Haswell video, vm86 crashes with invalid memory references.
> Tracing showed what looked like bad BIOS bugs (the BIOS sometimes uses
> 64-bit pointers with garbage in the top 32-bits).  I suspected buffer
> overruns from bad sizes near the bug in this PR, but everything seemed
> to be OK.  I must have checked that DL was correctly initialized for this.
> My changes somehow avoid these crashes.  Resume just never worked with
> Haswell video.  On amd64, there are no crashes by the BIOS calls are too
> hard to debug using tracing they take too many instructions.  Resume
> works for everything except video on my Haswell desktop system.

I made a little progress:
- I checked that DL is initialized to 0.
- the crash in vm86 is only in debugging code that optionally tries to
   do the same save/load as suspend/resume.  This crashes in save.  However,
   when the state to save is changed from 0xf to 0x7, save/load seems to
   work (the saved state seems to be correct and reloading it has no effect.
   I should try a mode change in between to verify its effect).  The 0x08
   bit is most important for resume.  It saves to sve the SVGA state, which
   is much larger (state 07 has size 0x3c0, mainly for the palette, and
   state 0xf has size 0x1a00).
- the same saves at suspend time fails without saving anything or crashing.
   Load at suspend time is then not attempted.
- if state 0x7 is saved early and returned later instead of failing in
   suspend, then loading it in resume doesn't fail, but has no effect.

That was on i386.  On amd64:
- save/load of state 0xf now works correctly early
- everything else behaves as on i386, except the early save of state 0xf
   can now be used for resume.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171204171239.W2345>