[00:13] <bryceh> Sarvatt, ok thanks... how did that happen?  Never seen my name in an Xorg.0.log before :-)
[00:15] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=5461b39585e739ed2df0d2200dc657123cfe71ff
[00:16] <bryceh> humm
[00:16] <bryceh> wow, I totally do not favor having my email address in everyone's Xorg.0.log
[00:17] <bryceh> although, if they're putting Maintainer in there, wouldn't that be ubuntu-devel@ or ubuntu-x@ instead?
[00:21] <jcristau> dpkg-parsechangelog reads it from debian/changelog
[00:24] <bryceh> jcristau, for what reason is this done?
[00:31] <RAOF> Where are we at on the gem objects leak?  Sarvatt - you seem to have that in hand.  Do you need any help?
[00:32] <Sarvatt> RAOF: yes, I threw my hands in the air at the idea of backporting the fix from master to 1.7 branch
[00:33] <bryceh> so what's our plan?
[00:33] <bryceh> sounded like we could drop some patches to get it back to working order?
[00:33] <RAOF> Why do we have GLX 1.4 backported from master, anyway?  I haven't found a justification for that, yet.
[00:33] <Sarvatt> disabling the glx 1.4 enablement patches if noone can backport it
[00:34] <bryceh> bbiab
[00:35] <Sarvatt> bryceh: it's mostly been tjaalton and asac in there for the past month :D
[00:35] <jcristau> bryceh: the idea was to try to identify our builds vs local custom builds.  probably not that useful.
[00:39] <RAOF> What do we lose by dropping glx 1.4 support?
[00:43] <Sarvatt> glx 1.3 and 1.4 support? :D
[00:43] <RAOF> Right.  Looking at the changelog, GLX 1.4 wasn't in Karmic, so dropping support won't be a regression in a release.
[00:44] <RAOF> We lose both 1.3 and 1.4 support?
[00:44] <Sarvatt> yeah 1.3 was the biggie
[00:45] <RAOF> Again, we clearly didn't have that in Karmic.
[00:45] <jcristau> RAOF: correct, that went in for server 1.8.
[00:45] <RAOF> But clutter obviously uses 1.3 if it's available, and we've been testing that codepath for most of lucid.
[00:45] <Sarvatt> it's kind of broken though, for instance xephyr doesn't work with glx 1.4 even though it claims it does because of the patches so it cant be used for gnome-shell and stuff
[00:46] <Sarvatt> RAOF: no we haven't, 1.3 support only got added to clutter in 1.2 branch
[00:46] <Sarvatt> we didn't update that until mid march?
[00:46] <Sarvatt> and it was broken causing crashes ever since :)
[00:47] <RAOF> Ok.
[00:48] <Sarvatt> http://bugzilla.openedhand.com/show_bug.cgi?id=2028
[00:48] <RAOF> Still, dropping GLX 1.3 support will possibly expose different clutter bugs.
[00:49] <Sarvatt> http://sarvatt.com/downloads/patches/xserver-1.8.0-glxdri2-resource-conversion.patch
[00:49] <Sarvatt> thats the fix for it for 1.8 branch squashed into 1 commit
[00:50] <RAOF> Yeah.  Not exactly the trivial fix :/
[00:51] <jcristau> i think i'll revert the glx 1.4 stuff for debian..
[00:51] <Sarvatt> ^ best bet by far..
[00:52]  * Sarvatt is hoping fedora backports it for F-12 since its a problem there too :)
[00:52] <jcristau> hehe
[00:55] <RAOF> It sounds like dropping glx 1.4 is the right solution.
[01:06] <bryceh> I think we need to escalate the issue.  Since it affects clutter we probably shouldn't make a decision here unilaterally
[01:06]  * bryceh ->> #ubuntu-desktop
[01:41] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/566324
[01:41] <Sarvatt> yay 845 fun
[01:42] <bryceh> *sigh* why is it people keep calling these crashes when they're actually freezes?
[01:45] <Sarvatt> whats the master bug for 8xx being trash?
[01:47] <bryceh> we don't have one on the X side.  There's one I filed about shutting off KMS but it's probably closed now
[01:47] <bryceh> er, filed against linux
[01:48] <bryceh> Sarvatt, there's also a wiki page under X/Bugs/ for the 8xx issues which could probably benefit from your review and polish
[01:48] <Sarvatt> X/Bugs/Lucidi8xxFreezes
[01:48] <Sarvatt> This page does not exist yet. You can create a new empty page, or use one of the page templates.
[01:48] <bryceh> hmm
[01:49] <Sarvatt> got it
[01:49] <bryceh> oh, no /Bugs/ in there
[01:49] <bryceh> let me insert that, one sec
[01:50]  * bryceh renames to X/Bugs/Lucidi8xxFreezes
[03:56] <Sarvatt> RAOF: I dont think nomodeset will affect it since intel has DRI2 on UMS
[03:58] <Sarvatt> jcristau: we're finding lots of problems with clutter 1.2 + glx 1.2 :(
[03:58] <RAOF> Yeah; it doesn't affect t it.  It doesn make intel unusably slow, though.
[03:58] <RAOF> As in, multi-second delays between me typing and it appearing on screen
[03:59] <Sarvatt> but i could be testing wrong, i'm using LIBGL_ALWAYS_INDIRECT=1 to launch things using the server 1.2 glx instead of the client's 1.4
[04:07] <Sarvatt> RAOF: got any ati's? you can disable KMS and go back to direct glx 1.2 there
[04:09] <RAOF> I do have an ati.  Sadly, it's in my server box, which is currently in a shipping container somewhere between Sydney and Hobart.
[04:09] <Sarvatt> mines in my server box missing a HDD sadly as well, go figure :)
[04:10] <RAOF> rickspencer3: So, there's some good news and some bad news.
[04:10] <rickspencer3> ok
[04:10] <rickspencer3> RAOF, go ahead
[04:10]  * rickspencer3 bracecs
[04:11] <RAOF> rickspencer3: The good news is that removing the GLX 1.4 backport doesn't affect most of our drivers; intel & ati with kms both support at least GLX 1.3 without that patch.
[04:11] <rickspencer3> but I thought we were rolling back to 1.2
[04:12] <RAOF> We are, but to do that we remove the GLX 1.4 backport patch; it skips 1.3
[04:12] <rickspencer3> anyway, so the bad news?
[04:12] <Sarvatt> its GLX 1.2 in the server, the client side drivers can do 1.4 with KMS (intel can do 1.4 without KMS too)
[04:12] <RAOF> The bad news is that this made my initial testing wrong; it looks like disabling GLX 1.4 breaks clutter.
[04:12] <rickspencer3> fuuuuuuuuu
[04:12] <RAOF> And by “Breaks clutter” I mean “Some apps don't render anything, and netbook-launcher doesn't render text”
[04:13] <rickspencer3> well ... that's a bit of a deal breaker
[04:13] <rickspencer3> RAOF, has anyone done any root cause analysis of the memory leak?
[04:13] <rickspencer3> like tried to figure out and fix *that* bug?
[04:13] <Sarvatt> so is a 1.5GB a day memory leak and crashing the server when you close a clutter app :(
[04:14] <rickspencer3> how widespread is this, though?
[04:14] <rickspencer3> I haven't had any issues like this
[04:14] <rickspencer3> on my UNE running netbook
[04:14] <rickspencer3> RAOF, Sarvatt can you guys paste me the link again?
[04:14] <RAOF> The memory leak?  All the X team seem to be happily reproducing it, and I think ogra was hitting it.
[04:14] <rickspencer3> the bug #, I mean, can you paste me that?
[04:16] <RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981
[05:10] <Sarvatt> basically it looks like the xserver patch we picked up is working as intended and just papering over the real problem
[05:10] <Sarvatt> it's not destroying things that would crash the server
[05:11] <Sarvatt> making them build up like they are
[05:12] <Sarvatt> and it has a side effect of not destroying things that wouldn't crash the server too :)
[07:08] <tjaalton> bryceh: corrected the X/Config page a bit about the xorg.conf.d directories. dunno what to do with Input
[07:49] <tjaalton> bryceh: also, I need to quit irc for a few weeks, but I'll read emails if you have something :)
[07:51] <tjaalton> so, hopefully by this time next month my masters thesis is reviewed and accepted.. bye!
[08:58] <lapion> tormod, I compiled the kernel with a hangcheck set to 300, and kms enabled for i855, it's working fine, btw 2.6.32-19 also worked for 2 days at a time without any crashes
[08:59] <lapion> but with the -19 I had the clockspeed of the processor set to half its official speed
[09:45] <Ng> fwiw I've not had any crashes from my 855 laptop, but it only sees light use for an hour or two a day
[09:46] <Ng> (in lucid I mean, it's been running it since beta1)
[11:01] <lapion> Ng have you done regular updates ?
[11:02] <Ng> lapion: I haven't updated it in a week or two because I didn't really want to get the DRI-disabling update to -intel ;)
[11:02] <lapion> your laptop contains an Intel 855 video chipset, or is your laptop a model 855 of zome brand?
[11:02] <lapion> What kernel are you using ?
[11:05] <lapion> Ng, well my laptop was running underclocked ( 1.4 GHZ in stead of 2.8 ghz) on kernel 2.6.32-19 for 3 days all the time compiling and recompiling a kernel, also continually displaying tv from a pcmcia analog tv-card
[11:05] <lapion> so not really  idle..
[11:05] <Ng> lapion: it's my spare laptop at home, it's a thinkpad X40 which has the intel 855 chipset
[11:05] <Ng> I'm not sure offhand which kernel it has
[11:06] <Ng> my gf uses it to browse the web in the evenings
[11:06] <lapion> cool.. try doing "uname -a" in a terminal
[11:08] <Ng> yeah I'm just several miles away from the laptop, it's not a problem of technical proficiency, just immediate proximity ;)
[11:09] <lapion> it has been running lucid lynx ?
[11:13] <Ng> yes
[11:14] <lapion> very cool..
[12:15] <Dr_Jakob> So I'm trying to figure when the fix for bug 545298 will land?
[13:11] <vish> Sarvatt: -xup2 is better :)  hasnt caused problems , I'm also watching out for the memory problem..
[16:43] <stefanlsd> Im doing the GEM leak test, and after installing the ppa updates, glxinfo still says 1.4
[16:44] <jcristau> stefanlsd: paste?
[16:44] <jcristau> it's supposed to say 1.4 client-side
[16:44] <stefanlsd> glxinfo | grep "GLX version"
[16:44] <stefanlsd> GLX version: 1.4
[16:45] <stefanlsd> jcristau: where should i see 1.2 then? following https://wiki.ubuntu.com/X/Testing/GEMLeak
[16:55] <jcristau> stefanlsd: yeah with the reverted server patch it should say GLX version: 1.2
[16:57] <Sarvatt> stefanlsd: you're using proprietary drivers
[16:57] <jcristau> ah, heh, that would do it
[17:34] <bjsnider> it won't do any good for us evil nvidia users to test the glx patches would it?
[17:35] <jcristau> no
[17:35] <Sarvatt> no point because you aren't even using glx from xserver anyway :)
[17:36] <bjsnider> troo enuff
[17:59] <lapion> anyone here interesed in getting information out of a running system with it's i915 server crashed ?
[18:02] <lapion> nvm the window of access has just closed..
[18:02] <bryceh> lapion, don't think anyone has the bandwidth at the moment
[18:02] <bryceh> if it's a crash, collect a full backtrace (see http://wiki.ubuntu.com/X/Backtracing)
[18:03] <bryceh> however maybe by 'crash' you really meant it's 'frozen', so see the freeze page at X/Troubleshooting for what to collect
[18:08] <lapion> hmm the x-server restarted 6 times. I have 5 xorg logs with a different display number, followed by one Xorg failsafe with the same timestamp. too bad in the meantime the whole system ( even ssh ) froze up..
[18:08] <lapion> it started out as a crash and ended up being a freeze
[18:11] <bryceh> if ssh froze you may have a kernel bug instead
[18:12] <lapion> it is a kernel bug related to the i915 kms.. because it only happens when the kms driver crashes..
[18:13] <bryceh> ok yeah, then probably you want to pop over and chat with the kernel guys
[18:13] <bryceh> however, things are down to the wire so people are not focusing so much on new bugs but finishing up ones already reported, so ymmv
[18:16] <lapion> this a the big i915 bug due to which i855 is blacklisted
[18:26] <stefanlsd> Sarvatt: aah ok. so this mem leak wouldnt of affected nvidia driver users?
[18:31] <bryceh> lapion, uhh do you have i855 or i915?
[18:31] <lapion> i855
[18:33] <bryceh> oh, yeah we already know about the issues on i855
[18:33] <bryceh> thought you had an i915 from your original comment
[18:33] <bryceh> yeah don't bother sending another bug report, this is well known territory
[18:34] <lapion> that's the driver.
[18:36] <lapion> btw, while using the lucid lynx beta2 disc, activating dual screen mode gives black screens with mouse cursor, 5 out of 6 times
[18:38] <lapion> both screens blacked out.. this is on a different laptop with an Intel  945GM/GMS, 943/940GML
[19:42] <vish> Sarvatt: no problems of memory leak , but is this ok?: $ cat /sys/kernel/debug/dri/0/gem_objects
[19:42] <vish> 2519 objects
[19:42] <vish> 127299584 object bytes
[19:42] <vish> thats with -xup2
[19:42] <hyperair> 2519 sounds fine.
[19:43] <hyperair> speaking as one of the victims of the i965 leak in jaunty.
[19:43] <hyperair> and karmic, come to think of it. that's why i'm still running xorg-edgers and custom kernels.
[19:45] <Sarvatt> vish: 127MB is perfectly reasonable
[19:47] <vish> \o/ ..
[19:50] <Sarvatt> vish: can you try running netbook-launcher, and any clutter app you can think of to see if there are any problems?
[19:50] <vish> Sarvatt: i dont use the netbook launcher.. will quadrapassel do?
[19:50] <Sarvatt> and also try when booting with nomodeset since it'll use DRI1 on your radeon and have a lower client glx version
[19:51] <vish> Sarvatt: i'm already using new_poll=0
[19:51] <Sarvatt> i'm working on setting up a radeon machine for testing
[19:52] <vish> Sarvatt: hmm , will opening quadrapassel crash X now ? [checking first ;)]
[19:52] <Sarvatt> yeah that just changes the way it picks timings and stuff, with KMS you wouldn't really see a difference dropping the glx version unless you were going through indirect rendering because clients could still be 1.4
[19:53] <Sarvatt> except on intel where you get DRI2 with UMS too
[19:53] <Sarvatt> no it wont
[20:07] <vish> oops , got caught up playing .. :D
[20:07] <vish> Sarvatt: no problems with quadrapassel
[20:35] <genii> Is GEMLeak testing under nv driver in 64 bit needed? https://wiki.ubuntu.com/X/Testing/GEMLeak so far has none listed
[21:34] <paul__> lo
[21:35] <Sarvatt> tormod: dh_strip does have -s --remaining-packages options if you didn't see it, generic debhelper ones
[21:35] <paul__> are there still some 'regression' bugs in lucid that you are aware of causing x server to segafult on start?
[21:36] <tormod> Sarvatt, oh thanks I forgot the generic dh ones
[21:36] <tormod> so why doesn't it work there then? :)
[21:36] <paul__> nvidia card, InitOutput in the bt, and non-match symbols (which I gather was just being discussed on -devel)
[21:45] <tormod> so the dh_strip wrapper in pkg_create_dbgsym does not use --remaining-packages ...
[21:50] <Sarvatt> maybe pkg-create-dbgsym should use the real dh_strip in the case that packages actually have -dbg packages?
[21:53] <bryceh> heya Sarvatt
[21:53] <Sarvatt> heyo!
[21:57] <paul__> if anyone looks at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568079, and needs any more information to diagnose the issue, let me know.
[21:57] <Sarvatt> dropping the glx patches has fixed 2 bugs I've seen so far with swrast as well as the memory leaks :D
[21:59] <Sarvatt> oh I missed the discussion on the gem object leak bug because I've been testing all day, better reply to those
[22:09] <tormod> bryceh,  I updated the savage mesa SRU description a bit
[22:09] <bryceh> tormod, great thanks
[22:10] <jg> bryceh: I sorta gather that the chance of having a working RS600 driver soon is between epsilon and zero, given what I see going on...
[22:10] <tormod> in our wiki we have https://wiki.ubuntu.com/X/Config/Input and https://wiki.ubuntu.com/X/InputConfiguration
[22:10] <tormod> esp the first is wrong about 10.04
[22:11] <bryceh> jg, due to the stage we're in for the release things are pretty tightly frozen; what we're prioritizing attention to are bugs where we have patches already identified, that need shepherding to get incorporated post-release as SRUs
[22:12] <tormod> the second says (correctly AFAIK): Note: The x11_options properties are not supported in Ubuntu 10.04. Use xorg.conf.d snippets instead.
[22:12] <Sarvatt> where does nvidia-settings save its settings again?
[22:12] <bryceh> I recall seeing a kernel patch go across the board for RS600 earlier that I passed along to the kernel team, but I don't have track of where things are there
[22:13] <bryceh> jg, I do know the kernel team is already working on the post-release kernel update so maybe it'll be included there
[22:13] <bryceh> Sarvatt, does it save anything anywhere other than xorg.conf?
[22:14] <Sarvatt> yeah all the settings like hue adjustments and stuff
[22:15] <bryceh> Sarvatt, that I don't know; perhaps there is a dotfile in the home dir, like dri uses?
[22:16] <Sarvatt> jg: do you have a bug? i pointed out the fix on someone elses bug to get KMS to work at all but there are still problems not fixed upstream yet since thats basically the rarest ATI GPU out there, AMD pulled them all from the market after the ATI/AMD merger 
[22:16] <paul__> Sarvatt/bryceh: do you know if what I've just reported in 568079 is known/on the rader or a new issue?
[22:16] <paul__> before I head out and leave you guys to it :)
[22:17] <jg> Sarvatt: I can enter another bug if you like; but it sounded like it was already in the system...
[22:17] <jg> Sarvatt: I have a nice, new, Intel graphics based laptop on order, so it is about to become moot for me personally, though it would be sort of nice if someday that tablet machine might be usable again.
[22:17] <Sarvatt> jg: found it https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
[22:18] <Sarvatt> i've been poking people about the problem for the past few weeks, trying to get it in as a SRU though for sure
[22:19] <Sarvatt> if you had a bug it would help because they'll need testing the justify it and its a super rare GPU
[22:19] <Sarvatt> or just clicking this affects me too even
[22:19] <jg> Sarvatt: do you want me to just chime in on that bug?
[22:19] <Sarvatt> please, yeah
[22:19] <jg> ok.
[22:19] <bryceh> paul__, I don't think it's on anyone's radar.  Not really enough info in that bug report to look into it
[22:20] <bryceh> paul__, would need a full backtrace as a minimum.  You'll probably get an automated response to collect that at some point.
[22:20] <paul__> the debug symbols don't match ;/
[22:20] <paul__> (There's a bug on that ;/
[22:20] <Sarvatt> sorry paul__, i've got 10 important things going on at once and haven't had a chance to look at it yet :(
[22:20] <paul__> np
[22:21] <jg> Sarvatt: done.
[22:21] <bjsnider> Sarvatt, there's a file i think called ~/.nvidia-settings.rc
[22:22] <bjsnider> something like that
[22:22] <bjsnider> nvidia-settings-rc
[22:22] <Sarvatt> jg: thanks, if you need an immediate fix adding radeon.modeset=0 (or just nomodeset) will make it work
[22:23] <bryceh> yeah I think we're all pretty swamped at the moment manhandling existing bugs towards solutions, we're quite short on bandwidth to look at new bug reports, and probably are only going to be able to look into ones where someone's done the legwork to identify a patch already
[22:23] <bryceh> wish we had more bug triagers right now
[22:23]  * paul__ nods
[22:23] <paul__> kinda why I spent some time trying to find the right place to idle
[22:23] <jg> Sarvatt: I tried that; no luck.  in beta 1 I could do an install, and work around; in beta 2, I couldn't even do the work around.
[22:23] <Sarvatt> bjsnider: THANKS thats exactly what I was looking for, I thought it was in a .nvidia-something directory
[22:23] <paul__> otoh, it's fairly old hardware
[22:23] <Sarvatt> jg: yeah it wouldn't work in beta 2 but it will with a current livecd
[22:23] <bryceh> paul__, there's a plentitude of docs at http://wiki.ubuntu.com/X/ for debugging/troubleshooting/etc. problems
[22:24] <paul__> warning: the debug information found in "/usr/lib/debug/usr/lib/xorg/modules/libshadowfb.so" does not match "/usr/lib/xorg/modules/libshadowfb.so" (CRC mismatch)
[22:24] <Sarvatt> because in beta 2 it was installing a modprobe conf to force modeset=1 
[22:24] <paul__> whilst the debug symbols don't match
[22:24] <paul__> i'm kinda assuming those docs are gonna be pointless :)
[22:24] <Sarvatt> paul__: can you try installing the xserver in x-updates? the -dbg packages in there will work properly
[22:24] <jg> Sarvatt: ah, ok.  as I've come down with a cold, I think I will just hope the new laptop shows up and duck for now, at least until I'm feeling better.
[22:25] <paul__> will do (i'll go google for how to do that)
[22:25] <Sarvatt> paul__: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[22:26] <Sarvatt> paul__: the rest of the info on this page does not apply but the installation and removal sections on here will tell you how to set it up - https://wiki.ubuntu.com/X/Testing/GEMLeak
[22:32] <bjsnider> Sarvatt, is there or was there a bug with installing the 32-bit libvdpau driver in nvidia-current on 32-bit systems?
[22:33] <paul__> thanks - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568079
[22:33] <Sarvatt> afraid I have no idea on that one, I saw a ton of bugs with nvidia-whatever-libvdpau upgrade problems from people using ppa versions though
[22:33] <paul__> hopefully that's slightly more useful for osmeone at some point
[22:37] <Sarvatt> oh wow, a TNT2 vanta
[22:39] <paul__> it's an old box
[22:39] <paul__> that just acts as router
[22:39] <paul__> and dev box
[22:40] <paul__> if it's too old to care about, say and i'll just buy a new dev box
[22:41] <paul__> More reporting it in case there's a more serious issue somewhere ;p
[22:42] <Sarvatt> paul__: try booting with nouveau.sodoff=1 to see if it works?
[22:43] <bryceh> Sarvatt, huh, your memory leak bug is on slashdot and phoronix
[22:44] <Sarvatt> oh fun
[22:44]  * Sarvatt turns off VPS so it doesn't explode
[22:44] <bryceh> so expect tons of people to show up and help
[22:44] <bryceh> oh wait
[22:44] <bryceh> expect an avalanche of peanuts ;-)
[22:44] <paul__> that's a kernel boot option I assume?
[22:44]  * paul__ wonders if he wants to reboot his router ATM
[22:50] <Sarvatt> paul__: you just want to start X to use it remotely? have you tried just using vesa?
[22:50] <paul__> nope
[22:51] <paul__> yes, just remotely, vesa no
[22:52] <paul__> I can reboot the box after adding nouveau.sodoff=1, but i'd need to add that to grub's config
[22:52] <Sarvatt> i wouldn't put it past it being caused by there being no connectors so nouveau doesn't set up an output then vga16fb gladly loads and is screwing things up
[22:52] <paul__> I could probably plug in a monitor later to test that theory
[22:53] <paul__> in terms of  nouveau.sodoff=1
[22:53] <paul__> would that just need to go at the end of a kernel line in grub's config?
[22:53] <Sarvatt> it would go right after quiet splash
[22:53] <Sarvatt> that will just make nouveau not load at all
[22:54] <paul__> brb
[23:03] <paul__> yea nouveau.sodoff=1 works
[23:06] <bjsnider> Sarvatt, i think the 32-bit nvidia-current tries to create symlinks to the /usr/lib32 vdpau driver, which isn't installed unless you're on amd64
[23:12] <Sarvatt> paul__: knowing if it works with a monitor plugged in or only happens with no monitor would be useful if you ever get around to testing that (without that nouveau.sodoff)
[23:12] <paul__> yea, will test tomorrow
[23:12] <paul__> i'll idle here over night to remind me
[23:12] <paul__> :)
[23:12] <Sarvatt> wouldn't be surprised if that GPU was messed up with nouveau in the first place and needs blacklisting but you're the first to report a bug about it :)
[23:13] <paul__> hah
[23:13] <paul__> a p3 box works for giving me gcc+gdb and a command line :)
[23:14] <paul__> kinda forget how old it is;p
[23:14] <Sarvatt> I remember paying $149 for my TNT vanta for a 486 machine ages ago, thats why it surprised me because I had one at some point :)
[23:17] <paul__> http://dnmouse.org/forum/viewtopic.php?f=3&t=65
[23:18] <paul__> reading that (unsupported list) and a 2006 post listing vanta as supported
[23:18] <paul__> I wonder if they dropped support
[23:18] <paul__> for old cards
[23:20] <Sarvatt> it says unsupported?
[23:20] <paul__> on that forum yes
[23:21] <paul__> http://forums.fedoraforum.org/showthread.php?t=204752
[23:23] <Sarvatt> unfortunately there are no binary drivers you can use on your card, they stopped updating the 71.xx series that worked with your card
[23:24] <Sarvatt> if it's headless and just used remotely though it shouldn't matter what you use?
[23:25] <paul__> what I have atm with nouveau.sodoff=1 I think works for what I do
[23:25] <paul__> so yea
[23:46] <paul__> gn thanks 
[23:47] <Sarvatt> no worries, will update the bug if i find anything
[23:48] <RAOF> Sarvatt: Good morning.
[23:58] <Sarvatt> heyo RAOF!
[23:59] <RAOF> Sarvatt: What's up? :)