The DreamerThe Beastie Blog

updating x11/nvidia-driver-304 to 304.123 with poudriere testport

Thursday, November 6 2014

This work in progress first started on September 18th, 2014, suffered a setback when a portsnap clobbered my work in progress under /usr/ports around September 29th, 2014 (Mondays… :gimacing:) And, then got set aside as felt the need for a proper rework of master port before submitting a PR.

On my workstation at work, I was not able to (completely) get X to work consistently on the graphics card that came with the system (a Radeon HD5450). At the time, FreeBSD 9.0 was the newest and don’t recall when I became aware of WITH_NEW_XORG, though I thought I had tried it but turned out that I had only done it to my home system and didn’t make the switch at work until later when I found that I hadn’t (after switch to NVIDIA Quadro FX1x00’s.) Which may have been unfortunate…

At that time I was building two new FreeBSD 9.0 workstations. At home, I was turning ‘zen’ into such a system, which had come with an NVIDIA GT420. This NVIDIA card worked when the system was Windows 7, but I was unable to get it to work when I tried Ubuntu 12.04LTS (reportedly an issue existed at the time with graphics cards with 2G or more of memory, not sure if it had been resolved. Also hadn’t considered that the issue was with NVIDIA driver.) Between giving up on resurrecting it as Windows 7 (after having purchased a real Windows 7 package, in hopes it could ‘repair’ my installation….) I played around with a bit with Xen, but decided that it didn’t suit the current constraints of my environment (no system capable of VT-d, there was mixed on whether ‘zen’ had the capability or not, but it was likely that the CPU did but the BIOS did not.)

But, after many iterations, I eventually got something on the Radeon HD5450 at work. It wasn’t consistent, and I didn’t know at the time that it was considered known/expected behavior for it to kill syscons and to often panic on logout (which restarts X.) But, before these issues became significant, I had run out and purchased an HD5450 for ‘zen’ to try. I was not able to achieve the same level of success here, unfortunately. Like due to differences in hardware (generation or purpose – work was a 2nd generation Core i7 Dell Optiplex, while home was a 1st generation Core i7 HP home computer.) While things were thought to be working at work, I tried a number of additional cards on the ‘zen’, such as a Radeon HD4670 and an ATI FirePro V4900. Work on getting X running on these cards were hampered by the known issues of it killing syscons and/or causing the system to panic. As a failed X would often return to nothing or panic. While the workaround of having a serial console might be possible at work, where I’m using the port to connect to a UPS, no such port exists on the HP system at home. Been meaning to get to trying more USB devices to see what I can get to work or not, on FreeBSD. I have things like a TrippLite SMART1500 UPS and a Fujitsu ScanSnap S300 working (though I use my HP OfficeJet 8600xi for scanning now.) I believe its currently the first (and, so far, only) desktop system that doesn’t have a physical serial port (there have been many laptops without serial ports, and on systems where I’ve needed serial ports its been in the many range…like 8+.) It might be considered the newest/most advanced system I own. Defintely the latter, since I have newer systems that have serial ports…. namely a pair of headless, fanless boxes that use for FreeBSD servers (for various services, such as DNS, NTP, DHCP, Radius, and I’m working on carp/hast for some yet to be determined purpose. Though the latter might result in me getting another pair of like boxes…something not based on JMicron NICs….possibly in the multi-NIC kind and replace DD-WRT hacked routers.)

Later things reached significant frustration at work, that I went on the hunt for a different graphics card to try instead of the Radeon HD5450. I had offer to purchase whatever card to get things working, except that I didn’t know what such a card was as it had been many years since me or co-workers done recent FreeBSD with graphics. I was worse, in that I hadn’t really done much since shortly after FreeBSD was available from CheapBytes. Since I was heavily into my Amigas at home (or Desqview/X), and professionally I had systems initially running Xenix, then Interactive Unix from the other ISC (Interactive Systems Corp.), to finally Solaris 2/x86 where briefly ISC had come out with an AT&T SVr4 offering, but was then acquired by Sun Microsystems to roll their expertise into Solaris 2/x86. That company had started by delivering its software on 486’s running Interactive Unix (important as they were the first to have Motif, and it had been decided that our application must have a Motif interface…) When I started my first system was a 386/40MHz (Cyrix)….ended with a Pentium Pro 200MHz running Solaris 2.5.1/x86 (and a fulltime 64K ISDN connection to the world…we had originally gotten our e-mail presence through the use of AmigaUUCP :wink:, initially had an on-demand ISDN, which we could go to 128K with, but eventually the hourly rate exceeded that of a dedicated 64K.) Sure seems funny talking about the good ole’ days :smirk:

Between Interactive Unix and Solaris, the company had moved to HP-UX and PA-RISC, but the cost of such hardware led to users wanting us to go back to x86 based systems, which were catching up on speed (especially when over cost.) But, they were pushing that it be a Linux version, which wedged the President between a free OS (especially one involving GPL) and the evil company called Sun (Microsystems.) He relented by going with Solaris/x86. I have no idea what the state of graphical desktops on FreeBSD was like at the time, as I had really gotten to having a graphical desktop (except as a means to have lots of xterm windows.) So, wasn’t a consideration for why I wanted to run FreeBSD at the time.

Though at current job, co-workers had mentioned past experience with video cards from Matrox or S3. Matrox was a brand I knew from my first job, and I vaguely recall S3 which had started appearing then. Matrox having somewhat of an edge, being that we were a Canadian company and our president having come from Quebec…. Matrox was probably also easier to get under DND contract.

But, seems these days there’s only two choices. And, I tend towards NVIDIA because I do a lot of BOINC, though BOINC on FreeBSD doesn’t do CUDA (yet…not that I have FreeBSD systems where I’d want to do that.)

Anyways…digging around the office, I realize that there’s are NVIDIA Quadro FX1400 available, which had come with our Sun Ultra 20’s. Which were the workstations that the wave of new hires, where I’m the only one that remains, got. These old machines have pretty much all failed now, but at the time I was in the process of ‘upgrading’ from mine. Which was already borrowing parts from another Ultra 20 which sits on my desk and serves as a plant stand. So switching to the Quadro FX1400, and voila! Everything works! :triumph:

So, I then go on the search online to find a Quadro FX card for my system at home,, before they cease operation, happens to have FX1700s for a good price. So, that’s what I’m using at home. And, all was good….

But, in early 2013, the x11/nvidia-driver was updated to a version that didn’t support the X1400, seems the 304.xx driver is the legacy series that will be last to support the GPU. Apparently it will continue to get support until the end of 2017.

The X1700 continues to work with x11/nvidia-driver (currently 331.67.) Though I worry about the day it reaches its end-of-life, or perhaps its end-of-support. Unix Legacy support is said to be to support newer Linux kernels and X servers, as well as fixes for critical bugs. Some how FreeBSD and Solaris are lumped in…. seems backwards.

So, switching my work system to use x11/nvidia-driver-304 wasn’t an issue and things continued to work fine until a few months before I started this work. www/chromium is running into problems with its more and more intense of GPU, and sometimes its problems affect my entire desktop. No problems like this at home. I’m tweaking settings/disabling features with little help to get things stable again. Then I happen to be poking around on the NVIDIA website and see that the latest 304.xx driver is 304.123.

Some quick hacking to the master port x11/nvidia-driver, I’m able to get it to build and install and all is good again until /usr/ports is refreshed wiping out my hacks and I accidentally revert back to 304.88.

 Setting up 'poudriere' here, since its been a while since I've had a working `www/chromium` on here, having made it to a
 37.xx but not being able to get back after moving forward.  Home system I'm staying with 35.xx until I know there's a newer
 working version for me.  There was discussion that building in 'poudriere' works where outside of it doesn't.... Trying for
 a simplier setup, without portshaker and less fiddling to `/usr/ports` and only this one port.  Though I have since moved to
 trying to build everything, and running into the same problems that I'm working on fixing at home.


Re-hack the files and save them aside for the future work of making them proper for submission.

The issue is that the master makefile converts version numbers into a big ‘integer’ of the form MMMmmuu, where ‘88’ fits into ‘mm’, but ‘123’ doesn’t. So the various conditions don’t apply correctly. For the hack, I override NVVERSION to be ‘3049900’. The more proper solution is to rewrite everything to use MMMmmmuu (or MMM.mmmuu - since while debugging find that the values are doubles).

Which after ignoring for a month, I decide to dive in on November 1st, causing me to lose track of the weekend :grin:

But, then came the question of testing my changes. I have ports-mgmt/poudriere more or less working on my home system, so I set up a testport jail (without my heavily customized make.conf and a ‘portshaker’ combination of a clean FreeBSD ports tree plus my changes) to use poudriere testport on it. First, I start by doing a ‘testport’ on the x11/nvidia-driver baseline. Which ended horribly in failure. (pkg-plist issues)

So, I’ve been spending lots of time cleanup up the baseline port, before I can get to testing my patches.

But, then this morning, I discover that x11/nvidia-driver has been upgraded to 340.46. And, x11/nvidia-driver-304 has been upgraded to 304.123. I take a peek, and see the maintainer had gone with MMM.mmm(uu) I had done the other on first pass, and the second later, but hadn’t gotten to deciding which way to stay with.

So, the question is do I abandon this work, or see if the new x11/nvidia-driver and x11/nvidia-driver-304 ports are fully fixed or just quickly upgraded? The issue being that poudriere testport does much more intensive pkg-plist validation than other methods. And, its the reason I haven’t switched to installing from my custom package repo, because I use numerous ports that had built/installed fine on the outside which fail inside of poudriere. Some of the failures inside of poudriere are due to pkg-plist and/or pkg-install/pkg-deinstall. Often involving the use non-default options.

IE: there’s a port’s pkg-install that creates symlinks for and, but not because it belongs to a port dependency. But, the pkg-deinstall just does an rm -f*, which poudriere fails because its considered bad to remove files belonging to a different port.


Also, it has come to my attention that 340.xx is the legacy driver series that will be the last support the X1700 (and the X1800, so will need to plan on a bigger step upgrade if I want to stay with x11/nvidia-driver after this version.) Though it will continue to be supported until the end of 2019.