In the meantime I found out that the opensource driver from mesa/dri works pretty well with the r280, and I can get my HD Rips encoded with h263 & with DTS of Battlestar Galactica to play just fine so I was happy with the card and the driver, no recompile every time I switch kernels, no patch digging around the forums of rage3d and gentoo. I was a happy man...
... At least I thought I was, till the DAY finally came! I was on a hunt for a Linksys WRT-54GL. Not that I've got the money but I decided I'll get it on my CC and stay away from pubs, bars, clubs, or whatever places I spend most of my money for the next couple of months and I'll pay for the router. Well, the router just didn't came alone. I found probably one of the last N6600TDs currently sold in Sofia (the lack of AGP video cards on the market is already present by the way) so I was a happy man, with a brand new router that I can run linux on and a video card that I thought will be a piece of cake to setup on my old and heavy modified CRUX linux v.2.1 x86_64 release...
...Think again, you moron!!!
Back at home...
... I took the ATI card out of the Athlon64 and decided its place is again back in my old desktop machine running with a Celeron PIII 1GHz version from where I took it out about a year ago. "Nice", I thought, I'll just put the ATI card back in the PIII machine, as I did a fresh install of CRUX 2.2 on it just a day ago, it will be a pleasure for me to setup the r280 with the opensource driver and I'll have a sweet machine, rather old, but sweet, running fresh & cool CRUX 2.2 that can handle movies and stuff and has a DVI connector and pretty good AGP card. Unfortunately nothing is what it seems. Compile of Mesa3D/DRI from cvs on xOrg 6.9 and I'm ready to go. And what I get is the dreadfull message from the server:
drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [drm] DRM interface version 1.0 (II) RADEON(0): [drm] drmSetBusid failed (9, pci:0000:01:00.0), Device or resourc e busy (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. |
OK, it could be the cvs build, its too new for the xOrg 6.9 , lets do it. Upgrade to 7.1, after all the damn driver was working on 7.1 on my Athlon64 box. Well, "was" is the keyword. It doesn't work even after an upgrade to 7.1. I'm still investigating the problem, however I don't have enough time. Why? It's simple. The nightmare just began with the ATI card, it scaled to full time freakshow with the NVIDIA.
Another smart idea from me was that just taking out the ATI, putting the NVIDIA and compiling the kernel driver for my brand new kernel the NVIDIA will work. What I ended up doing was digging around for a proper patch to the latest NVIDIA kernel so I can put it to work with my 2.6.17-mm7. It's all back again, new kernel, new recompile of the proprietary driver, and constant digging around in gentoo forums, debian and FC repos for patches. At least NVIDIA driver works well under Linux, or that is what I've heard about it. After all the nvidia.ko was finally in my kernel, but what the hell happened with the rest of the stuff, I copied it by hand, and I ended up missing some nvidia libs, thank God I know my way around my system, but even the ldd didn't help much, after doint all the symlinking and renaming by hand, after there weren't anymore messages about libGLcore.so.1 and libnvidia-tls.so.1 not found I still ended up with non-working GLX. Why you will ask. Well, unresolved symbols in the statically compiled NVIDIA drivers. It seems like my distro was too old, gcc-3, glibc heavily modded with various x86_64 patches, and a custom hell of libs in /lib32, /lib64, /usr/lib64, /usr/lib32 and you get a machine that works like a charm, unless you want to modify it a little bit with stuff you don't compile yourself. Binary world is not my world, as it seems. Before I took the giant step for me, and a small step for the mankind, to just bust the sucker and clean the mess up, I took the liberty of testing xOrg 7.1 with NVIDIA driver. It doesn't work in general. Missing fonts and stuff. Practically not usable. Probably there was a solution around the net for that, but googling 3 or 4 hours more would just leave me with no time for anything else, and I have to go to work also, or do I? I hate it anyway, after all pH (read as a dyslexic would) is a shitty place to work at, at least in Bulgaria.
Time for an upgrade. Or more like a fresh install, because an upgrade will just mess things up even more. That wasn't hard to do. Download the latest CRUX-2.2 64bit from danm( unfortunately the now late project doesn't get too much of an updates in the ports tree, but anyway I do them usually myself, so this will not be a big problem). On top of that I really messed up my GNOME 2.14.2 install by trying to move to 2.15.91 then 2.15.92 and various parts were not working because they were compiled against really old versions of libs of my CRUX 1.3, or 2.0, or 2.1, or whatever it is after the various abuses I repeatedly did on it. The A64 box is already booting from CD, a quick 10 min install and back to a fresh, clean and empty root partition with the basic gcc, glibc, perl, X toolchain. Sysup the system, without sysing up the gtk, cairo, glitz, pango, atk and x11 though, and I would be more than happy to proceed with the NVIDIA driver install. Kernel version? The PIII is running 2.6.18-rc4-mm2, I'll run that on the A64 box also, unless...
... unless the sucker has a bug! The freaky kernel image still has 3xTime problem, but only on the Athlon64, on the PIII it works just fine. Unfortunatelly it took me some time to find that out (about a couple of days ;) ) in the mean time, after manual copy and symlink of the NVIDIA glx part of the driver I finally got the good news, glxinfo says you are in the game! Or more like using NVIDIA glx implementation. What will glxgears say then? 150 fps??? Or what about 2.4 fps when you have CPU load and hdd activity. This couldn't be right. Well the 3xTime problem could have been the reason. I just switched last night to 2.6.18-rc4-no2. A little over 4000 fps, good, this is more like it. By the way, I think I'll fill in this blog article with exact instruction how to install the GLX part of the driver and what to symlink on a CRUX system, but this would be applicable to any Linux anyway. I could even write a shell script?! Or maybe not. I'll think about it.
So now what? I would definately think of a way to test my Asus N6600TD under Linux. I know that there are different 3D shooters around and I'll give them a try, just to see what this baby can do. I hope it could do a lot. In the mean time, well it playbacks movies, and does it well. I'm still compiling the GNOME 2.15.92 but the glitz seems working alright so far. I'll check it in an hour or so. If everything is alright with that, I can proceed with hunting down the DRI problem on the ATI/PIII machine.
1 comment:
I feel your pain.
The emasculated monkeys at ATI and Nvidia should just open up the specs for the products we pay for so open-source drivers can be written. Of course, the buggers won't do that. Well, they won't get my money anymore then either.
Post a Comment