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

C

chessguy64

Hello. I'm new to FreeBSD, and I've just installed 13.0-RELEASE. After I installed xorg, I did "# pkg install nvidia-driver" which directed me to the legacy 390.x drivers on the NVIDIA website, as it said that the new 470.x driver would ignore my GPU. (I have a NVIDIA GeForce GT 430 card) I downloaded that, did a make / make install. I installed enlightenment, xfce, and a few other window managers and everything seemed to work ok for a few days, but eventually X would just hang in the middle of me doing something, with a frozen black screen with a few grey rectangles on it. In the doc for the 390.x driver, under min. requirements I see "Note that FreeBSD 7-STABLE versions older than FreeBSD 7.3 and FreeBSD 10-CURRENT development snapshots are not supported." Other min requirements are: " XFree86/X.Org 4.2/6.7.0" and " libvdpau * 0.2". Am I running entirely the wrong version of FreeBSD to get it to work with my model nvidia card? Should I do a fresh install of FreeBSD 7.3? Or is it feasible to try to get my card to work with 13.0-RELEASE ? Any input would be appreciated. Thanks.
 
You shouldn't install FreeBSD 7.3. According to the nvidia driver page the most recent driver for your card is 390.147, released: 2021.12.16. The problem you described is not necessarily problem with your graphic card, it maybe "anything" - CPU overheating, memory error (check it with memtest) or even disk failing. But if you still suspect your GPU check /var/log/Xorg.0.log after it crashed.
 
I ended up doing a clean install of 13.0, installing the driver from the x11/nvidia-driver-390 port you mentioned, instead of from the NVIDIA site. Everything is working great now (so far), tested it with XFCE and no crashes / hangs. Thanks a lot! Great community here.
 
I'm having the same issue. I'm using GNOME 42 atm. A few hours can pass and things will be perfectly fine, but then randomly my screen will go black, with two grey/whitish rectangles spaced 6 inches apart, and i'm forced to hit the power button to shut down and reboot. This happens randomly and not specifically when I'm doing any one thing. I'm using a non-UEFI system with onboard graphics disabled, display init first set to PCI-Express, and the legacy 390.x drivers for my nvidia card built from ports. I couldn't find many clues as to the problem in the Xorg log, because I don't know if X is actually crashing, or just my display is garbled. I did add my user to the video group that I use GNOME in. I've attached my dmesg and last Xorg.0.log, and my /etc/X11/xorg.conf. I'm using a blue VGA cable for my display. (My monitor doesn't have DVI ports) Does anyone have any idea as to the root of this problem? I also have a NVIDIA settings GUI app that I can change settings in. Maybe I should change some settings in there? Please help. I really want this to be a stable system to use every day, and not have an uptime of 8 hours or less before it crashes.
 

Attachments

  • Xorg0.0.txt
    16.2 KB · Views: 124
  • dmesg.txt
    10.8 KB · Views: 109
  • xorg.conf.txt
    1.5 KB · Views: 110
It's a PNY Verto GeForce GT 430 2048MB DDR3 card. I also flashed a custom BIOS a long time ago before I installed FreeBSD (I have an HP branded motherboard Nettle2-GL8E) So it's not a stock BIOS. Not sure if that has anything to do with it.
 
IIRC some older Nvidia cards had/have problems with power saving features and/or adaptive clocking.
Try disabling the underclocking feature e.g. via the nvidia-settings menu -> PowerMizer -> "Preferred Mode = Max Performance".

Using another driver version (e.g. 340) might also help.
 
I will try that. Thank you. Also I just noticed that "nvidia_load="YES"" was not in my /boot/loader.conf. But looking at my dmesg it looks like it was loaded anyway at some point? vgapci0: child nvidia0 requested pci_enable_io
 
chessguy64 said:
It's a PNY Verto GeForce GT 430 2048MB DDR3 card.
Click to expand...
That should be supported by the 390 version of the driver.

chessguy64 said:
But looking at my dmesg it looks like it was loaded anyway at some point? vgapci0: child nvidia0 requested pci_enable_io
Click to expand...
No, you get that message regardless of the NVidia driver. It's a generic VGA device.

chessguy64 said:
my /etc/X11/xorg.conf.
Click to expand...
Start by removing that file. You don't need it.

Then create a /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf:
Code: 
Section "Device"
  Identifier "Card0"
  Driver     "nvidia"
EndSection
That's all the Xorg configuration you need.

chessguy64 said:
Also I just noticed that "nvidia_load="YES"" was not in my /boot/loader.conf.
Click to expand...
That's fine, it's loaded in another way; sysrc kld_list+="nvidia-modeset".
 
Thanks again. As a final note, should I set "always enable" for the onboard video in my BIOS ? And then try to install the drivers for GeForce 6150SE nForce onboard video as well? Right now it's set to enable only if there is no external GPU, and "pciconf -l |grep vga" will only show my nvidia card, not the integrated video. I'm not going to use onboard video ever, but I've noticed a lot of things tie in together on this motherboard, like onboard video and the onboard Ethernet. (I use a PCI card for wired Ethernet) Wasn't sure if I would get better performance / stability enabling the onboard video?
 
Ah. I was thinking enabling the onboard video and installing the nForce drivers for it would enable chipset features / compatibility that I'm not getting now.
 
Video card driver has nothing to do with the mainboard chipset drivers.
 
SirDice said:
It wasn't a very good chipset though.
Click to expand...

That must be about the nicest thing anyone has ever said about an nForce chipset 😅

But now that chessguy64 has mentioned using one of those chipsets: the described problems may very well be caused by that.
The nForce 4 had compatibility problems with a lot of other hardware (IIRC the PCI bus had extremely flaky latency and other timing issues), were horribly unreliable and IIRC even had hardware bugs in the SATA controller which frequently caused data loss (or were those the 3 series?).
I'm not sure if troubleshooting on this hardware makes much sense, given the multitude of hard- and firmware-bugs this platform inherits. The described problem may very well be caused by the borked PCI bus on that platform.
 
sko said:
I'm not sure if troubleshooting on this hardware makes much sense, given the multitude of hard- and firmware-bugs this platform inherits. The described problem may very well be caused by the borked PCI bus on that platform.
Click to expand...


Thank you for sharing this. I bought and installed a new D-Link Gigabit Desktop PCI card (DGE-530T), which is supposed to have great compatibility with FreeBSD AFAIK (one of the main reasons I bought it), yet despite my internet subscription being 1GBPS, I could not reach download or upload speeds above 500 mbps on a good day. All cables are Cat5e. The speed test to the router is 980MBps down/up. The speed to my device won't go past 500mbps, with a much slower upload (100-200MBps) speed. I had a feeling the PCI bus was saturated, and reading this just makes me think that is the case. Also only the first 2 SATA ports register in the BIOS under the SATA controller, and the remaining ports will classify the device (hdd) as an IDE device. Maybe it's time for a new motherboard :)
 
chessguy64 said:
yet despite my internet subscription being 1GBPS, I could not reach download or upload speeds above 500 mbps on a good day.
Click to expand...
My, now rather old, firewall system has the same problem. I was basically 'stuck' on 250Mbit/s throughput. Had to shift things around and modify a bunch of PCI parameters (in the BIOS) to get a higher throughput. It seems to level out somewhere between 500 and 600Mbit/s. Which suffices for my current connection (that's 600Mbit) but is going to pose a problem when I get my fibre connection. I'm probably going to need to replace my firewall system with something a bit more modern.

My firewall is currently running on an Intel Celeron board: C847MS-E33. CPU is not the issue, there's very little CPU load. It's mostly the PCI bus that's bottlenecking it.
 
SirDice said:
My firewall is currently running on an Intel Celeron board: C847MS-E33. CPU is not the issue, there's very little CPU load. It's mostly the PCI bus that's bottlenecking it.
Click to expand...

Do you know of a good AM2 socket mobo with a nice PCI bus where I can get gigabit ethernet speeds? (at any price) Or at the least with a better chipset in case the chipset might be causing the video card hangs re: what sko was talking about. I have an Athlon 64 X2 dual core 6000+ CPU.
 
chessguy64 said:
Do you know of a good AM2 socket mobo with a nice PCI bus where I can get gigabit ethernet speeds?
Click to expand...
I fear that even with today's heavily bloated prices for used hardware, this is just wasted money and effort.

E.g. you can get LGA1150 boards like a supermicro X10SLH-F for ~60EUR and I've even seen bundles with quad-core xeon E3/v3 and 16-32GB RAM for ~150EUR and less. Such hardware is orders of magnitudes faster and more energy efficient than any ancient AM2 system and easily saturates your 1GB link.
You could even slap in some X520 10G NICs on such a board and with a reasonable amount of filtering/PF rulesets you might still be able to saturate those links at least for local routing (I offloaded local 10G routing to my switches - nothing beats ASICs in that regard).
Actually, this would be what I'd currently go for as a replacement for the Edgerouter 4 /w OpenBSD that can just keep up with my 150MBit radio uplink I temporarily got from my ISP until the fiber link is ready.

As hard as it is sometimes to let some old but working hardware go, oftentimes it just isn't rational to keep it running (at least as a "workhorse").
I also still have a Sun T1000 in my rack and love to run this little machine with OpenBSD. I even keep a backup-firewall up to date in one logical domain and this thing still has amazing performance for that purpose, especially given its age. But it draws ~100-120W constantly and even after replacing the fans with some 'silent' ones, that system is far from bearable in the living space...
 
Never mind saturating 1 GB connection, I don't see any indication that machine is intended for any work. Neither as firewall, nor for the regular desktop things.
 
sko said:
I fear that even with today's heavily bloated prices for used hardware, this is just wasted money and effort.
Click to expand...

True. I guess I just got attached to it having it for so long. Oddly enough, I've used this same GT 430 card in the same system for at least 8-9 years now with Win7 and it has not crashed like this once. I'm using the older 340 driver now instead of 390 like you said, just using "nvidia" module and not "nvidia-modeset" like I had before. I set "Prefer Max Performance" in settings as well. When I installed the 390 port, I remember now that I built it with "ACPI support" enabled. I'm really wondering if that's been the cause of my problems all along. I looked around a bit and it doesn't seem to be well supported in older cards like mine. At one point they didn't even support it at all. I'm thinking this would be a good preventative measure because if the card has no power management support it can't clock down ?
 
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. But just in case you are or can have a dual boot up and running easily.
In the other thread, where things are quickly spiraling out of control, someone mentioned PR 251015. It's perfectly possible that the same issue is happening on your videocard.
Now, to be sure there are a few things I'd certainly recommend and that is to start with a clean install (FreeBSD 13.1, not 13.0, not -CURRENT as suggested in the other thread) and use packages only. Don't build ports with custom stuff, just use packages only. This creates a much simpler baseline which may or may not help (aka. pkg install ... instead of make install.
After one of those graphical freezes, does the system still respond to an ACPI shutdown? (basically, pressing the power button - assuming that's enabled in your bios). If it is, the bug I linked isn't happening. Otherwise, we don't know much more including if it is.
If it is no longer responding, there's a kernel crash dump written to /var/crash. This assumes that you didn't disable crash dumps (remember, clean FreeBSD 13.1 - by default crash dumps are enabled in the installer (DUMPDEV option).
Even though I'm not sure I'll be able to provide much help from there, at the very least it might be enough to help fix the linked bug for someone else using that driver. Even if your FreeBSD experience didn't work out, someone elses might be helped by it.
 
malavon said:
After one of those graphical freezes, does the system still respond to an ACPI shutdown?
Click to expand...

I can only say that in 13.0 when the video crash happened, 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. I'll try your suggestion. Thank you for this. This has been one of the most, if not, the most useful pieces of information I've gotten on this issue.
 
Now again, I'm not going to promise that we can somehow fix your problem. In fact, I'd be surprised if we can - just tempering expectations here. But we'll see.

chessguy64 said:
Can't be 100% positive though, maybe I just wasn't waiting long enough.
Click to expand...
I'm not sure, but I think you said something earlier about a built-in videocard disabled in the bios? If there is and you can get that enabled - without losing the ability to boot FreeBSD - you might be able to get the DMESG output on a second screen. Just make sure it's set as the primary videocard.
Catch is, with hardware this old I have no idea if it's going to work. I do the same on my Haswell, where the onboard (on-CPU) Intel "GPU" (it's not used as GPU, just terminal output) is used until the moment Xorg starts (which disables the Intel output because, well, reasons). But if a crash occurs in the NVIDIA driver it may very well mean that the terminal is shown again, which may give some indication about the possible issue. Also, test ACPI shutdown before a crash, make sure it's enabled and you have an idea how long it takes.
chessguy64 said:
Thank you for this. This has been one of the most, if not, the most useful pieces of information I've gotten on this issue.
Click to expand...
Well, without going into details and I won't speak for others but can speak for myself, I too have been on edge on this forum because of several quite persistent trolls over the past years (not a typo). It's sometimes hard to distinguish the fake accounts from the real problems and couple that with frustrations, lack of body language etc etc and things can heat up.

EDIT: adding quickly: when a coredump is being written, the system won't shutdown because it's writing gigabytes of data to disk. Give it ample time to do so.
 
You must log in or register to reply here.
Back
Top