Why ATI drivers did not eat my pony after all (this time)
03 Jan 2012Last year (hah! last year!), by which I mean Xmas 2011, just two weeks ago, I did all my updates and disruptive work in the week BEFORE Xmas, rather than after. It's one of the perks of working for a university that I get a week off between Xmas and the new year, and I decided to actually take advantage of it this year.
(I could make that paragraph better, but it's beyond me right now.)
(The other advantage, of course, is free honey from honeybee researchers.)
I allowed myself three days, but was actually done in two. That's considerably better than last year, and in large part that's because I learned a (not the) right way to uninstall/reinstall proprietary ATI drivers. Unlike last year, in fact, it was practically painless.
This might explain why it was not terribly surprising to come back to a problem related to the upgrade: a user telling me that PyMOL no longer worked. And sure enough, when I tried running it over SSH, it crashed:
$ pymol
/usr/bin/pymol: line 2: 17723 Segmentation fault /usr/bin/python //usr/lib64/python2.6/site-packages/pymol/__init__.py "$@"
...which wasn't exactly what she was seeing, but I was pretty sure that it was only the tip of the iceberg.
A backtrace (caught by the wonderful catchsegv, which I only just
found out about) showed that it was failing at XF86DRIQueryVersion
,
which turns up in approximately 38% of all web pages. They're all
related to problems w/the proprietary ATI driver, how it eats ponies,
and how everything was sunshine and lollipops once they rolled back to
the Mesa-provided copy of libGL.
We are running the proprietary ATI driver -- we need the 3D performance -- so this made sense. And after last year's fiasco I was quite prepared to believe that ATI has a nasty appetite for BBQ. But much searching showed that before the Xmas upgrade, everyone'd been using the ATI-supplied libGL w/, presumably, no problems. I decided to prove it by reinstalling Mesa on a test machine. Yep, now it works fine. ATI hates the world!
...but I'd forgotten that I was running this over SSH. With X forwarding. And this made a difference. The Truth Hammer smacked me when I tried PyMOL on another workstation, from an actual sit-at-the-keyboard-and-use-the-coffee-holder X session, and it worked fine. I SSH'd to the original user's machine, and that worked fine.
I checked the version of libGL on my machine, and sure enough it was
different: 7.7.1 versus 7.8.2. My suspicion is that either the
XF86DRIQueryVersion
routine has changed enough that this causes
problems, or there was some other difference (32-bit vs 64bit? could
be...) between my machine and theirs (mine runs a different distro, so
there's lots of chances for interesting differences).
I simply did not expect there to be any problem debugging X programs over SSH; probably naive, but what the hell. Now I know.
Oh, and the user's problems? Wack PYTHONHOME
. Unset that and all
is well.
Happy new year, everyone!
Add a comment:
Name and email required; email is not displayed.
Related Posts
QRP weekend 08 Oct 2018
Open Source Cubesat Workshop 2018 03 Oct 2018
mpd crash? try removing files in /var/lib/mpd/ 11 Aug 2018