I upgraded a system with a Permedia 2 video card, which uses the glint drivers. The installer couldn’t launch the GUI, but I’ve run into that fairly often, so I just used the text-based installer without thinking much of it. The upgrade process itself went fine, but on booting into the new system, it was unable to launch X. I kept getting the following error:

X: symbol lookup error: /usr/lib/xorg/modules/drivers//glint_drv.so: undefined
symbol: RamDacCreateInfoRec

I found a reference to the problem occurring in Debian, as Debian bug #423129, then followed that to Freedesktop.org bug 10906, which has been fixed. It turns out that the xorg X server moved some features from a pluggable module into the server itself, but didn’t keep them available for drivers that use them. I tested the patch with the X server SRPM from Fedora, and was able to run the system in graphics mode again.

Then I checked Fedora’s bug database, and found Red Hat bug 242800, filed just yesterday. I confirmed that I had the same problem, pointed them at the upstream bug, and reported that the fix worked for me.

For those who are comfortable with modifying and building SRPMs, you can grab xorg-x11-server-1.3.0.0-5.fc7.src.rpm from any Fedora mirror, then add the patch from that Freedesktop.org bug report to the SPEC file. That will give you a set of RPMs that will work with the card. (If you don’t know what I’m talking about, you’re probably better off waiting until Fedora has a chance to test the fix and issue an update, but if you want to learn, check out the RPM Guide, particularly chapters 8 and 9.)

Update (June 7): A fixed version, xorg-x11-server-Xorg-1.3.0.0-8.fc7 has hit the testing repository.

Update (June 11): The fix has been released, so all you have to do is install/upgrade in text mode and run yum update after you’re done.

The card used to work under Linux using the standard I2O drivers (i2o_block, etc.), but sometime last year Promise changed the firmware so that it no longer uses I2O. Now you’re stuck with Promise’s own driver, so if you want to use an old enough distribution* (say, Red Hat 7.3) that you can find a driver disk, or make your own driver disk, go ahead…but don’t expect to be able to upgrade it unless you can create a driver disk for the newer distro. This assumes the source code for the driver will work with recent 2.4 kernels—it won’t compile with 2.6. There has been talk of merging the pti_st driver into the kernel (fortunately it’s GPLed), but I can’t find anything more recent than August. Someday it might work again, but not today.

Now, FreeBSD is another matter. It has built-in drivers (pst), the installer will detect it automatically, and even let you install your entire system to it—without warning you that FreeBSD can’t boot from the SX6000. You can boot from another drive and interact with it once the system’s running, but you can’t put your entire system on the RAID array. (This information is not in the installer, not in the hardware notes, not in the driver man page. I only found the one 1½-year-old mailing list post by the driver’s author, and a bunch of “I don’t think it works” comments in other lists and forums.)

I hope this post will save someone a lot of frustration.

*Of the distributions for which Promise has provided driver disks, only one—SuSE 9.0—hasn’t already been retired.

I finally started looking, and that’s not the case. It seems that the Airport Extreme chipset manufacturer, Broadcom, refuses to release Linux drivers or to release specs to allow anyone else to write Linux drivers.

I don’t expect it to do any good, but I signed my first online petition.

Ah, well, I can do almost everything under Mac OS, and for those occasions that I actually need Linux, I can always go solo or plug in a cable, though it does limit where I can hook it up.