Solved Can FreeBSD 13.0-RELEASE work with an older nvidia card?

malavon said:
This probably doesn't matter much considering - as far as I understand from your other thread - that you're no longer running/trying to run FreeBSD.
Click to expand...

Update: so I installed 13.1 clean on a laptop hard drive inside my desktop. Installed everything from pkg, no ports. (pkg install nvidia-driver-390). My card is a GT 430. I'm running e16 window manager right now under a regular user account, which I didn't add to the video group. (no 3d acceleration). I didn't add him to wheel either, not sure if that matters. One interesting thing is that when i installed the 390 nvidia driver, it automatically loaded linux.ko and linux64.ko, even though I didn't enable linux binary compatibility in /etc/rc.conf. I'll have to let it run for some hours, but no crashes yet.
 
I'd like to refer to a post, but it has disappeared :-(

chessguy64 said:
… I tried tapping the power button to shutdown (which did work in a text only console without X running), and I don't think the system shut down. Can't be 100% positive though, maybe I just wasn't waiting long enough. …
Click to expand...

NVIDIA aside: I very recently had a blackout in response to shutdown now. Without a desktop environment, IIRC.

Whilst the OS ceased responding to HID, it did respond to a simple press on the power button. In these situations, the waiting period is not particularly long. If swap is in use, and if it's on slow storage: be prepared to wait at least as long as the OS must take to (invisibly) handle what's swapped.
 
chessguy64 said:
… a regular user account, which I didn't add to the video group. (no 3d acceleration).
Click to expand...

Noted.

chessguy64 said:
… wheel …
Click to expand...

If you're happy without acceleration, then wheel should be negligible in the context of graphics.

Very few ports have a package message that mentions wheel. According to FreshPorts:
  • audio/playumidi
  • devel/buildkite-agent
  • emulators/vice
  • emulators/virtualbox-ose-additions
  • emulators/virtualbox-ose-additions-legacy
  • emulators/virtualbox-ose-additions-nox11
  • emulators/virtualbox-ose-additions-nox11-legacy
  • games/linux-steam-utils
  • mail/opensmtpd
  • net/bird2
  • security/lxqt-sudo
  • sysutils/dsbbatmon
  • textproc/elasticsearch6
  • textproc/elasticsearch7
  • www/domoticz
  • www/otrs
  • x11-servers/xephyr
  • x11-servers/xorg-dmx
  • x11-servers/xorg-nestserver
  • x11-servers/xorg-server
  • x11-servers/xorg-vfbserver
  • x11-servers/xwayland
 
Update: 13.5 hours uptime in X (e16 wm). No crashes with nvidia-driver-390, but the system was left on overnight, and monitor was in power save mode most of the time. It was difficult to pinpoint why it was crashing before, because I had installed a ton of stuff at once at the time I first installed xorg and was setting it up for the first time, instead of installing a minimal environment. I'm thinking it had something to do with the compatibility of the nvidia driver with some elements of the new gnome. I noticed some failed calls to dbus as well, that could have been a factor as well. Not sure how well dbus works with FreeBSD.
 
Well, proceed slow from this point. From your other post I gather you're using UFS, ZFS would have given you the benefit of snapshotting and going back to a previous snapshot in case something happens :)
Of course, FreeBSD 13.0 vs 13.1 and maybe some other packages that were updated may have fixed your issue whatever it was, so in that case going slow won't make a difference. Keep us posted if something breaks it.
 
Yeah I decided on UFS because there's less overhead / resource usage. Also because I'm not storing any data that's 100% critical to keep on this drive. I really didn't want to run gnome in the end anyway. Having a good time now, thanks. Isn't there a way to update all your packages to new versions on your current release? or do you have to wait until the next release?
 
I had the display hang right after I logged out of openbox on a non-root account. (grey squares on screen like before). This is the Xorg.0.log right after the crash below. Maybe I'm using a module / setting that isn't well supported or has to be disabled?
 

Attachments

chessguy64 said:
… Isn't there a way to update all your packages to new versions on your current release? or do you have to wait until the next release?
Click to expand...

You can update your packages at any time.

pkg -vv | grep -e url -e enabled will show whether you're using latest i.e. main or quarterly, which is currently 2022Q2.

A filtered view of the menu of branches at <https://github.com/freebsd/freebsd-ports/>:

1653761580130.png
 
chessguy64 said:
I had the display hang right after I logged out of openbox …
Click to expand...

Logged out, to a display manager? Or did you start Openbox from a console e.g. ttyv1?

At a glance (I'm not an expert) I see nothing in your Xorg.0.log to suggest a crash.

Does /var/log/messages show anything relevant from around the time of the issue?

Maybe not in this case, but it sometimes helps to enable /var/log/console.log – <https://www.freebsd.org/cgi/man.cgi?query=syslog.conf&sektion=5&manpath=FreeBSD#FILES>.
 
chessguy64 said:
Isn't there a way to update all your packages to new versions on your current release? or do you have to wait until the next release?
Click to expand...
Well, like mentioned above here I'd say it depends; you've used ports to build packages, but was that the latest version or was it the one installed (and never updated) from the FreeBSD 13.0 installation? In case of packages, there is indeed the difference between quarterly or latest. But for now let's assume that wasn't the case and somehow the hangs just coincidentally didn't occur.
chessguy64 said:
I had the display hang right after I logged out of openbox on a non-root account. (grey squares on screen like before). This is the Xorg.0.log right after the crash below. Maybe I'm using a module / setting that isn't well supported or has to be disabled?
Click to expand...
Were they always after log out? Because at least from that logfile I'd say Xorg closed just like it was supposed to. Also, do you have a corefile in /var/crash?

Also, grahamperrin 's questions seconded :)
 
grahamperrin said:
Logged out, to a display manager? Or did you start Openbox from a console
Click to expand...

I logged into a virtual tty from text console, and did "startx". "exec /usr/local/bin/openbox" was in my .xinitrc. Then I clicked "Log Out" from an openbox menu. That's when the display hung. I think X had shut down successfully before the crash, thus technically no crash according to X. This is from /var/log/messages. At the time I did have a few firefox browsers launched when I logged out. It seems to perform better on composited wms, like e16. I haven't had it crash on that. I didn't configure openbox at all, was running it on default settings.
 

Attachments

Did you end up with coredumps? (see /var/crash/). It would be logical assuming that the system crashed.
If so, don't post them here entirely, they may contain passwords etc. Just the stacktrace would suffice.
 
No core dumps in /var/crash. But I didn't wait a long time before powering off. In 13.1 adding hw.vga.textmode=1 to /boot/loader.conf seems to be a permanent fix now. It hasn't crashed/hung/displayed garbled graphics on screen since then.
 
I saw the other post after I replied to this one, I'm happy to hear that it did get fixed. It's good to know and now it's been saved for all of eternity in case someone stumbled upon the same issue.
 
You must log in or register to reply here.
Back
Top