Date: Mon, 4 Dec 2017 13:25:12 +1100 (EST) From: 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: <20171204124654.G1571@besplex.bde.org> In-Reply-To: <bug-224069-8-FPMQu9Aofi@https.bugs.freebsd.org/bugzilla/> References: <bug-224069-8@https.bugs.freebsd.org/bugzilla/> <bug-224069-8-FPMQu9Aofi@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > Mark Linimon <linimon@FreeBSD.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |linimon@FreeBSD.org > > --- Comment #1 from Mark Linimon <linimon@FreeBSD.org> --- > (In reply to Stefan B. from comment #0) >> Thus I wish I knew who has commented out that line for what reason. > > (Note: jkim is already on the Cc: here, so I don't need to take any action.) > > fwiw, there's a way to look that up. > > Look up the src file on FreeBSD's svnweb: > > https://svnweb.freebsd.org/base/head/sys/dev/fb/vesa.c > > Do an "annotate" based on the latest commit, here rev 326255: > > https://svnweb.freebsd.org/base/head/sys/dev/fb/vesa.c?annotate=326255 > > Search for the commented out line (shows as 517 there rather than 515): > > https://svnweb.freebsd.org/base/head/sys/dev/fb/vesa.c?annotate=326255#l517 > > Clicking the line number in that block takes you to: > > https://svnweb.freebsd.org/base/head/sys/dev/fb/vesa.c?r1=198250&r2=198251&; > > Clicking the 'latest revision' link on the right takes you to: > > > https://svnweb.freebsd.org/base/head/sys/dev/fb/vesa.c?revision=198251&view=markup > > which is a very large commit from jkim Mon Oct 19 20:58:10 2009 UTC (8 years, 1 > month ago). I have no knowledge of what's all involved there. This was a very competent commit. The commenting out is just a silly optimization. The bzero() a couple of lines earlier clears DL. The commenting out just avoids clearing DL again. This is obscure since the commented out setting is to STATE_SIZE which happens to be 0. Deleting the line would be a larger obfuscation, so the initialization is left as a comment as a hint. But this is a silly optimization. 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. Most of my newer systems (with integrated Intel video) apparently just don't support resuming video using vesa, but either thay or the device driver are more broken than that. Some of they days were spent implementing and fixing disassembly and tracing in vm86 mode, to debug nearby vesa calls. i386 mostly uses vm86 bios calls to call vesa functions, but vm86 is unavailable on amd64 so the x86bios emulator is used. This works well for some things. 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. With Sandy Bridge video on a laptop system, I get more and different crashes and resume doesn't come back. This might be from more complicated other peripherals. Resume only works on 1 of my systems (a laptop from 2006 with Nvidea graphics; resume started working on FreeBSD a couple of years ago). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171204124654.G1571>