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

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.
 
  • Like
Reactions: mer
chessguy64 said:
Update: it seemed to just be an issue of that one line not being in /boot/loader.conf.
Click to expand...
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.
 
  • Like
Reactions: mer
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?
 
skunk said:
Although it is commonly, even in many guides, recommended to load nvidia-modeset via /etc/rc.conf
Click to expand...

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.
 
chessguy64 said:
...tried # acpiconf -s 3 again in an sc console... same thing.
Click to expand...
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?
Click to expand...
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.
 
skunk said:
You need to do this from xorg.
Click to expand...

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)
 
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.
Click to expand...
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)
Click to expand...
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.
 
skunk said:
1. kern.vty="sc" isn't set.
Click to expand...

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.
 
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.
Click to expand...
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".
 
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".
Click to expand...
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.
Click to expand...
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.
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top