Date: Mon, 04 Dec 2017 21:28:43 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 224069] (Fix included) Use of uninitalized register value in vesa.ko, causing X, text console and suspend/resume to fail Message-ID: <bug-224069-8-xfzyKnXaH5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-224069-8@https.bugs.freebsd.org/bugzilla/> References: <bug-224069-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224069 --- Comment #8 from Stefan B. <sblachmann@gmail.com> --- (In reply to Jung-uk Kim from comment #4, #5 and #6) #4: Didn't know about register zeroing. Such was not common back then when I did VGA programming via hardware and INT10 decades ago using mixed C and assembly back in the 16-bit DOS times. The sysctl tip is great for debugging! #5 No, you don't deserve that at all. When I saw the commit Mark pointed me at, I instantly recognized that it wa= s a lot of work involved. And you know, the bigger the work, the easier it is to overlook a detail. See please my comment #3, too. And I did not know you were the one who implemented FreeBSD suspend/resume. That was great work, good to know. Thank you! However, I think the suspend/resume thing has been neglected, and it does n= ot=20 work for many people. Below I discuss part of possible reasons. Btw, are you still interested in improving suspend/resume from STR to STD? #6 That is very interesting, because: In the FreeBSD forums, there are constant complaints regarding Nvidia cards= .=20 Garbled display when switching between console and X, and after resume. I h= ave made the discovery that this apparently *only* happens when vesa.ko is pres= ent. And that is in the GENERIC kernel or as loaded module. In the forums I have talked much of that problem. Apparently all people that followed my advice to build a custom kernel *without* option VESA and switch from vt to sc console (because the default vt console pulls in vesa.ko, if = not present in kernel), got rid of these problems. And, in my naive opinion I think suspend/resume should *not* be broken by j= ust doing kldload vesa.ko. (this is factually the way to reproduce the problem) So I have the strong feeling that there is a serious problem with the vesa module. But that is just my (possibly misleading) intuition. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224069-8-xfzyKnXaH5>