# insight please on why display is crashing (framebuffer/xorg?)



## chessguy64 (May 30, 2022)

Hello. I've been using FreeBSD for 2 weeks. 13.0 to 13-1-RELEASE now. I've been able to minimize random crashes from pretty often to once in a while, but for some reason no matter what I do my display will hang with a black screen and grey rectangles at least some of the time, forcing me to tap the power button to restart. My nvidia-driver-390 is pkg installed and properly set up in /usr/local/etc/X11/xorg.conf.d. Lately it's only when I log out of icewm or e16 and return to text console that I get this bug. 80-90% of the time I just return to text console fine, but a few times the display is messed up and I have to use the power button to restart. Nothing in /var/crash (though I didn't wait a long time if a core dump was being written before powering off) and no evidence in Xorg.0.log indicating X did not exit cleanly. Other than this: ->
[   537.043] (EE) event4  - IntelliMouse: client bug: event processing lagging behind by 17ms, your system is too slow
[   545.213] (EE) event4  - IntelliMouse: client bug: event processing lagging behind by 14ms, your system is too slow
.
Someone has posted that they used the same driver with a card almost as old as mine, and it works well. And most of the time it works well for me, so I'm not 100% sure it's just an issue with the 390 nvidia driver and it's compatibility with other parts of FreeBSD. I've tried different versions of the 340/390 driver, same thing happens. (just less frequently now in 13.1). Is this related at all to framebuffer on my video card (I have a GT 430) Or how xorg shuts down, and returns to text console? If so, or if not, what's the best way to troubleshoot this? (including changing BIOS settings). Thanks


----------



## rpowell47 (May 30, 2022)

I have the same issue.
Screen Flicker/Going Dark when Logging Out of Mate Issue
window > window-manager>


----------



## chessguy64 (May 30, 2022)

rpowell47 said:


> window > window-manager>



Oh. I couldn't folllow your link. I saw it in your activity now. I use icewm and e16. They don't use dbus, and I don't have dbus enabled in /etc/rc.conf. But it still happens once in a while.


----------



## rpowell47 (May 30, 2022)

In short, I've not been able to solve the issue. I'm using the GeForce 1030 graphics card, but I'm not at all thinking it is the issue. I use a single HDD 1 Tb for Ubuntu and disconnect all of my other HDDs that I use FreeBsd 13.1 on. When I use Ubuntu the logging out or shutdown command works without any issues that we have encountered. Thus, It must be an issue with Xorg, but I don't have the experience or knowledge as to research or find any Xorg current bug data. Any way - Good Luck!


----------



## mer (May 30, 2022)

I don't know if it's strictly necessary, but for Nvidia cards I've had the following line in my /boot/loader.conf for as long as I can recall:

hw.vga.textmode="1"

Why?  Because at one point in time when you switch from X to another virtual console (Ctrl-Alt-FN where FN is a "function key across the top of the keyboard") the console would not render correctly if at all.  That line in the loader "fixes" it.  You do lose any kind of "high resolution console" but my eyes are old enough that I don't care to look at tiny text.

I periodically get the "system too slow" because of events on the mouse on systems that use nvidia and Intel;  it's obviously a "system taking too long getting around to processing an event from libevent" but I've only seen it related to an USB mouse so hard to say exactly where it is.


----------



## Jose (May 30, 2022)

I had a similar problem with an Nvidia 1080Ti. I would get a black screen with a white square on the upper left side when I quit Openbox. Only way out of it was reboot (power switch still worked). It went away when I upgraded to 12.3.


----------



## rpowell47 (May 30, 2022)

Jose said:


> I had a similar problem with an Nvidia 1080Ti. I would get a black screen with a white square on the upper left side when I quit Openbox. Only way out of it was reboot (power switch still worked). It went away when I upgraded to 12.3.



Thanks Jose, you're correct. When I was using 12.3 - No Problem! When I upgraded to both 13.0 and now 13.1 - current issue. Then only change that has made a difference as to a black screen of death, is I change my BIOS to read the PCIe slot that my GeForece 1030 is using. But, the blinking on and off is still there. I'm simply running out of options. Mer, shared - hw.vga.textmode="1", which was nice, but that code did not change my issue. Thanks to all!!  - I'll keep reading. researching, and trying and if or when I find a solution, I'll post ASAP!


----------



## mer (May 30, 2022)

rpowell47 said:


> is I change my BIOS to read the PCIe slot that my GeForece 1030 is using


I'm assuming Intel CPU?  On my system I disable the Intel GPU and tell the BIOS to use the PCIe slot.  Is that what you are doing?


----------



## grahamperrin@ (May 30, 2022)

chessguy64 said:


> … Lately it's only when I log out of icewm or e16 and return to text console …



If you habitually flush swap devices before doing so, then are symptoms reproducible? 









						GitHub - Freaky/swapflush: Flush swap devices on FreeBSD
					

Flush swap devices on FreeBSD. Contribute to Freaky/swapflush development by creating an account on GitHub.




					github.com


----------



## rpowell47 (May 30, 2022)

mer said:


> I'm assuming Intel CPU?  On my system I disable the Intel GPU and tell the BIOS to use the PCIe slot.  Is that what you are doing?


Yes


----------



## chessguy64 (May 30, 2022)

Jose said:


> Only way out of it was reboot (power switch still worked). It went away when I upgraded to 12.3.



Vital.Thanks. I'll reinstall and use 12.3 instead of 13.1 idc. For better stability.


----------



## chessguy64 (May 30, 2022)

mer said:


> I don't know if it's strictly necessary, but for Nvidia cards I've had the following line in my /boot/loader.conf for as long as I can recall:
> 
> hw.vga.textmode="1"



This actually might be the root cause of why the display is crashing for so many. I didn't have that in my /boot/loader.conf, and did Ctrl+Alt+F1 in icewm, and my screen went garbled with distorted colors. Then I did Ctrl+Alt+F2 and noticed the exact same black screen I was getting before with grey rectangles when it was hanging. Once I added that line to /boot/loader.conf it doesn't do that anymore and returns normally when I do Ctrl+Alt+Fn. Also, I'm getting those "your system is too slow" errors using a PS/2 mouse, not USB.


----------



## chessguy64 (May 30, 2022)

grahamperrin said:


> If you habitually flush swap devices before doing so, then are symptoms reproducible?



I'd have to test it a lot. It's not something you can easily reproduce, because it happens so infrequently. But now I have that hw.vga setting in /boot/loader.conf, and if that is fixing things, I don't want to remove that line and test if things are working correctly now without any crashes in the future.


----------



## rpowell47 (May 30, 2022)

Well, I just spent two hours installing and then configuring BSD 12.3 that I had used 13 months ago on the exact same box! Guess WHAT, it did not resolve the issue of the Black Screen of Death.  However, that issue was not a problem until I installed 13.0 and now it is an issue with 12.3!  Thus, I'm going to shutdown and reinstall 13.1 and keep trying to resolve the issue. The only thing that I saw go by while installing the gnome and mate pkg was a message that the D-BUS was not recognized. At least the D-BUS was highlighted in yellow, or I wouldn't even notice that quick message as it was installing the pkg. So, maybe when I have 13.1 up and configured for my taste, I'll research that in issue. Thanks, I'll talk with you later.


----------



## chessguy64 (May 30, 2022)

rpowell47 said:


> Well, I just spent two hours installing and then configuring BSD 12.3 that I had used 13 months ago on the exact same box! Guess WHAT, it did not resolve the issue of the Black Screen of Death. However, that issue was not a problem until I installed 13.0 and now it is an issue with 12.3!



I don't know why if it was working without any problems in 12.3 before, then installing 13.0, using it for a while, and wiping the drive and reinstalling 12.3, why the issue would come back. I don't think it's related to your problem that you installed 13.0 on the hard drive before going back to 12.3 Also, did you add

dbus_enable="YES" to /etc/rc.conf before you installed gnome or mate? Keep in mind I don't have dbus enabled and i've had this crash happen before on logout of a wm. But I didn't have that hw.vga setting in /boot/loader.conf while the crash happened.


----------



## rpowell47 (May 30, 2022)

Yes, I always enter dbus_enable=“YES” in my rc.conf file. Now back to configuring 13.1. Talk with you tomorrow. Thanks for your thoughts.


----------



## Jose (May 31, 2022)

I'm sorry you went through all that trouble for naught. I have Dbus disabled on my system, FWIW. I doubt that's the problem, though.


----------



## chessguy64 (May 31, 2022)

Jose said:


> I'm sorry you went through all that trouble for naught. I have Dbus disabled on my system, FWIW. I doubt that's the problem, though.



What wm do you use? I'm thinking of migrating to 12.3. You haven't had the crash happen even a single time? Also do you have hw.vga.textmode="1" in /boot/loader.conf right now?


----------



## Jose (May 31, 2022)

chessguy64 said:


> What wm do you use?


I use x11-wm/openbox.



chessguy64 said:


> I'm thinking of migrating to 12.3. You haven't had the crash happen even a single time?


Keep in mind my video card is much newer than yours, and is supported by the latest driver, which is what I use. It's unlikely 12.3 is the answer to your problems.



chessguy64 said:


> Also do you have hw.vga.textmode="1" in /boot/loader.conf right now?




```
$ cat /boot/loader.conf                                                                                   
nvidia-modeset_load="YES"
hw.vga.textmode=1
fuse_load="YES"
```


----------



## chessguy64 (May 31, 2022)

Jose said:


> Keep in mind my video card is much newer than yours, and is supported by the latest driver



Well according to nvidia and FreeBSD, my video card is supported by nvidia-driver-390. Given that I saw the same graphic on screen when I didn't have hw.vga.textmode=1 in /boot/loader.conf, and did Ctrl+Alt+F1, Ctrl+Alt+F2 in X, (crash) matching the graphic on screen when I logged out of wm and it crashed.. I'd say there's a high probability it's just because I didn't have that line in /boot/loader.conf, and it has little to do with nvidia driver compatibility. I'd have an uptime of 13.5 hours before in a wm without a crash. It was only crashing recently on 13.1 when I logged out of a wm (sometimes) But yeah, I can probably use 13.1 successfully without reinstalling to 12.3. I have to reinstall anyway, because I didn't set a single / partition and did /var /usr /tmp / partitions. Might want to go with 12.3 because it is older and more stable.


----------



## grahamperrin@ (May 31, 2022)

chessguy64 said:


> … I'd say there's a high probability it's just because I didn't have that line in /boot/loader.conf, …



If attention to loader.conf(5) improves things, then (yes) you can ignore my suggestion to flush swap devices. 

(The suggestion was loosely based on situations that precede _very_ rare freezes with my AMD graphics hardware. So rare that I haven't bothered to properly diagnose things.)

Remind me, please: 



chessguy64 said:


> … tap the power button to restart. …



Those were short taps, yes? To gracefully stop. 

(Not pressing and holding to force a stop.)



chessguy64 said:


> … 12.3 because it is older and more stable.



Not necessarily. 

Some things that are (or will be) fixed for releng/13 will never be fixed for releng/12.


----------



## chessguy64 (May 31, 2022)

grahamperrin said:


> Those were short taps, yes? To gracefully stop.



No I don't think I could. It wouldn't shut down like that. Had to hold down the power button. It hasn't crashed on wm logout in a while.


----------



## mer (May 31, 2022)

Jose 
I would remove nvidia module lines from loader.conf and add them to the kld_list line in /etc/rc.conf.  I know at one point in time loader.conf was the recommended way, but I've had boot issues in the past and I think others have reported issues too when it's in loader.conf.
Just my opinions.


----------



## grahamperrin@ (Jun 1, 2022)

Well spotted by mer.

Also, `fuse_load="YES"` is (technically) useless. because `fuse` is not the name of the module. Maybe the result of following outdated guidance.

If FUSE is needed:

`sysrc kld_list+=fusefs && kldload fusefs`

Here, as a result of the rc.conf(5) entry:


```
% kldstat | grep fusefs
13    1 0xffffffff84493000    12db0 fusefs.ko
%
```


----------



## grahamperrin@ (Jun 1, 2022)

chessguy64 if you haven't already seen it: 



			Newcons - FreeBSD Wiki


----------



## chessguy64 (Jun 4, 2022)

Update: it seemed to just be an issue of that one line not being in /boot/loader.conf. Something to do with graphical consoles switching modes. I don't want to tag this thread as "Solved" just yet without some more testing, but my display doesn't even crash on wm logout anymore, even once in a while. Crazy that I've been at this for a while and got such a range of advice to what the issue was like improper nvidia-driver config, to problems with my video card clocking down (not being in "Performance Max" mode in Powermizer), my hardware is incompatible, my motherboard has a poor chipset, the PCI bus on my mobo is broken etc. And it could be fixed with a single line in one file. I see looking back that you mentioned doing this a lot earlier mer  but I wasn't switching tty terminals inside of X, so I overlooked it. Thank you.


----------



## skunk (Jun 4, 2022)

chessguy64 said:


> Update: it seemed to just be an issue of that one line not being in /boot/loader.conf.


Correct.
I can confirm this.
Although it is commonly, even in many guides, recommended to load nvidia-modeset via /etc/rc.conf (against the recommendations of Nvidia themselves, btw), this causes a bunch of (sometimes only sporadic and sometimes hard-to-reproduce) issues.
For this reason, the Skunk Installer always places nvidia-modeset loading into /boot/loader.conf.

Edit: Another side note: If you want to have suspend/resume work, use the sc console instead of the vt console.


----------



## Jose (Jun 4, 2022)

It would be sooper-cool to have a definitive answer on this. Does `nvidia-modeset_load="YES"` belong in /boot/loader.conf or  in /etc/rc.conf?


----------



## chessguy64 (Jun 4, 2022)

skunk said:


> Although it is commonly, even in many guides, recommended to load nvidia-modeset via /etc/rc.conf



I was actually talking about the hw.vga.textmode=1 setting in /boot/loader.conf, not nvidia-modeset. I have kld_list="nvidia-modeset" in /etc/rc.conf, with nothing nvidia in /boot/loader.conf, and I haven't had any issues. Also, I just logged out of X and tested s3 suspend in a tty sc console. It's still broken. On resume my monitor light blinks indefinitely and I have to hard reset.

>>> put nvidia-modeset_load="YES" into /boot/loader.conf and removed kld_list="nvidia-modeset" from /etc/rc.conf, rebooted and tried # acpiconf -s 3 again in an sc console... same thing. Only this time I could Ctrl-Alt-Del to reboot and didn't have to hard reset. Weird.


----------



## skunk (Jun 4, 2022)

chessguy64 said:


> ...tried # acpiconf -s 3 again in an sc console... same thing.


You need to do this from xorg. You also can use "`zzz`" as shortcut for the lengthy "`acpiconf -s 3`".
I also forgot to mention that the kernel must be built _without_ `options VESA` (see my bug report), which should be the default in newer kernels somewhere from post 13.0.



Jose said:


> It would be sooper-cool to have a definitive answer on this. Does `nvidia-modeset_load="YES"` belong in /boot/loader.conf or  in /etc/rc.conf?


People who advise to load nvidia-modeset via /etc/rc.conf give as reason that the memory available at the loader stage is limited, and this could make boot fail due to the large size of the nvidia driver.
But usually memory is sufficient, and thus many people suffer (unnecessary) issues with the nvidia driver, caused by nvidia driver being improperly initialized, in a too-late stage.


----------



## chessguy64 (Jun 4, 2022)

skunk said:


> You need to do this from xorg.



I'm running FreeBSD 13.1. So I tried that, and the display actually comes up now when i resume, but returns to a text console where I see # startx and the Xorg version and some other info. I hit Alt-F9 and it does return to my wm for a few seconds, but my launch menu icons are small and scaled down. Then it exits back to the text console. I see some signal 11 messages on getty, xterm, and some other stuff. I can switch ttys with Alt+F2 Alt+F3 here but I can't type anything in. Like my keyboard is locked. Then I have to hold down the power button to hard reset. Do I have to build the nvidia-driver-390 with ports and enable the ACPI_PM feature for suspend/resume to work here? I just installed the nvidia-driver-390 driver from pkg because someone reccomended doing that instead of through ports. (I have a GT 430 btw)


----------



## skunk (Jun 4, 2022)

chessguy64 said:


> I'm running FreeBSD 13.1. So I tried that, and the display actually comes up now when i resume, but returns to a text console where I see # startx and the Xorg version and some other info. I hit Alt-F9 and it does return to my wm for a few seconds, but my launch menu icons are small and scaled down. Then it exits back to the text console. I see some signal 11 messages on getty, xterm, and some other stuff. I can switch ttys with Alt+F2 Alt+F3 here but I can't type anything in. Like my keyboard is locked. Then I have to hold down the power button to hard reset.


There could be a number of reasons:
1. `kern.vty="sc"` isn't set.
2. Sometimes some hardware takes a longer time to resume (apparently in particular HDD, USB, sound stuff). During this time the display will stay in text mode. Usually this takes less than one minute, but sometimes (rarely) this can take a long time. Very rarely I have experienced times to about 10 minutes or so. After the resume is finished, the display will go to graphics mode where it was when you initiated suspend.
3. USB thumb drives being plugged can occasionally break resume (afaiu due to random daX reshuffling) if you use SCSI/SAS drives or SATA connected via the SCU; it is advisable to unmount these and remove them before suspending.
4. Some conflicting driver/software is running, or maybe incompatible configuration settings. For example, with Virtualbox running, resume fails are common.



chessguy64 said:


> Do I have to build the nvidia-driver-390 with ports and enable the ACPI_PM feature for suspend/resume to work here? I just installed the nvidia-driver-390 driver from pkg because someone reccomended doing that instead of through ports. (I have a GT 430 btw)


I (and the Skunk Installer) use the packaged driver, although my subjective feeling says that resume failures with the driver built directly from the nvidia tarball were slightly rarer (less than 1 in 100). But officially it is discouraged to build from the nvidia tarball, because it ignores the pkg system, potentially leading to libraries being overwritten and the like when doing updates. I never had problems, though.


----------



## chessguy64 (Jun 4, 2022)

skunk said:


> 1. `kern.vty="sc"` isn't set.



You've been reading my posts on this thread you know I have that set. I don't have any USB flash drives plugged in, virtualbox is not running. Nothing is really running. I literally just logged in, started X, went into wm and brought up an xterm and suspended. You still didn't answer my original question if building with ACPI_PM support would help suspend/resume in succeeding. And what about all the processes being SIGSEGV'd ? What driver/software could possibly be conflicting? all I have loaded is nvidia kernel modules, (and linux.ko, linux_common.ko). Running icewm. A PS/2 keyboard and mouse. Pretty light setup. Suspend does work in other OSes.


----------



## mer (Jun 4, 2022)

skunk said:


> People who advise to load nvidia-modeset via /etc/rc.conf give as reason that the memory available at the loader stage is limited, and this could make boot fail due to the large size of the nvidia driver.
> But usually memory is sufficient, and thus many people suffer (unnecessary) issues with the nvidia driver, caused by nvidia driver being improperly initialized, in a too-late stage.


I think there may be differences in how much memory is available based on BIOS/CSM or UEFI booting.  Also "how much memory is available" is often defined/set in loader so if you upgrade the module with an older loader you may wind up actually creating an issue.

My primary reason for not putting it in loader.conf is the same reason that I don't use graphical logins and use startx:
Control.  I've been bitten in the past where graphics related items caused a boot loop that was difficult to stop and correct.  Putting the modeset modules in rc.conf simply mean the high resolution console is available later in the boot sequence which is something I don't care about.  I'd rather have a console I can read instead of trying to squint and guess at what a character is.

Why would it be recommended to put the nvidia driver in loader.conf but not the Intel or AMD drivers?

Bottom line for me:
Put it where your system consistently boots correctly, the drivers load correctly and you can have the least amount of pain to recover is something goes wrong.

EDIT:
Versions.  If you look in /usr/ports/x11, there are 5 different "nvidia-driver" directories (excluding hybrid/secondary drivers).  nvidia-driver is typically "almost the latest" so one can pkg install that instead of nvidia-driver-470|390|340|304

YAEDIT:
skunk The latest x11/nvidia-driver in ports is at 510.60.02, but there  is a 515.48.07 (at least when I searched by my GT750 card specs).  What's interesting is the comments in the port shows how to easily build for a different version:
make DISTVERSION=xxx.yy.zz -DNO_CHECKSUM

as long as it compiles.  I think nvidia-driver may be built for "latest" pkgs, but not for quarterly, but this shows how trivial it is to "compile the driver but within the ports/pkg system".


----------



## grahamperrin@ (Jun 4, 2022)

mer said:


> I think there may be differences in how much memory is available based on BIOS/CSM or UEFI booting. Also "how much memory is available" is often defined/set in loader …



*UEFI*

<https://www.freebsd.org/status/report-2021-07-2021-09/#_improved_amd64_uefi_boot>


----------



## skunk (Jun 4, 2022)

Yes it looks like that Nvidia made the 470 driver a new long service branch for soon-legacy cards, like the no-longer-supported 304, 340 and the 390 of which support will be dropped in autumn.
Will have to update the skunk installer for that, probably I get time somewhere end of June.



mer said:


> skunk The latest x11/nvidia-driver in ports is at 510.60.02, but there  is a 515.48.07 (at least when I searched by my GT750 card specs).  What's interesting is the comments in the port shows how to easily build for a different version:
> make DISTVERSION=xxx.yy.zz -DNO_CHECKSUM
> 
> as long as it compiles.  I think nvidia-driver may be built for "latest" pkgs, but not for quarterly, but this shows how trivial it is to "compile the driver but within the ports/pkg system".


Truly interesting find!  
This could make work-around driver bugs easy, as they recently became visible in another thread, where the brand-new driver failed, but another one some slightly older .yy or .zz version worked fine.



chessguy64 said:


> You've been reading my posts on this thread you know I have that set. I don't have any USB flash drives plugged in, virtualbox is not running. Nothing is really running. I literally just logged in, started X, went into wm and brought up an xterm and suspended. You still didn't answer my original question if building with ACPI_PM support would help suspend/resume in succeeding. And what about all the processes being SIGSEGV'd ? What driver/software could possibly be conflicting? all I have loaded is nvidia kernel modules, (and linux.ko, linux_common.ko). Running icewm. A PS/2 keyboard and mouse. Pretty light setup. Suspend does work in other OSes.


I didn't make any experiments with ACPI PM support, just used the GENERIC defaults (except for `nooptions VESA`).
Regarding the PS/2 mouse, this has some bad implications. Any mouse event from the PS/2 mouse wakes up the computer. There seem to be some problems regarding shutting down PS/2 mouse events, as these can abort an ongoing suspend/resume sequence. Annoying also is that mice sometimes flip forth and back between coordinates, waking up the computer out of the blue.
Currently I am using a vintage serial/PS/2 Microsoft cordless wheel mouse, still with a ball. The only way to suspend reliably with this mouse is to use its switch on the bottom, to have it switch to the other radio channel to practically disconnect it. Other PS/2 (optical) mice can be used well only by putting it somewhere on something so that they are not lying on plain surface, and not giving events when they should not do.
This said, I strongly suggest using an USB mouse to avoid these problems.


----------



## meaw229a (Jun 5, 2022)

I have had a similar problem. Computer has Intel CPU and integrated Graphics UHD-630. Only later on a GT-1030 came into the
setup. I put the GT 1030 card in and the Bios saw it and made it the default graphics card. So far so good. Installed the NVIDIA 470
driver on FreeBSD 13.1-Release and run  nvidia-xconfig. All was working very well until I tried suspend/resume. No way to get the
computer back to resume. Only the reset button became my friend. 
I tried all the additional settings and tricks mentioned here and on other sources but nothing helped.
As a last resort I went back into the Bios to have a look. The Bios pretty much make a second additional card the default on. Nice and
easy but the Intel integrated graphics was somehow still lurking in the background. There was a button to completely disable it and
that was my match winner. After turning the integrated graphics completely off suspend/resume works 100% fine for me.
No further settings needed.

I load the nvidia driver from rc.conf. Tried from loader.conf but can not see a difference.


----------



## mer (Jun 5, 2022)

I think the key is "if you add a video card, disable the integrated graphics".  That's what I did, but honestly so long ago I forgot I did that.


----------

