[00:01] <Sarvatt> Ng: can ya attach your Xorg.0.log too? since i'm using your info for the report and it doesn't match the other guys
[00:01] <Ng> sure
[00:02] <Ng> I'll attach .old since that should match up with the drm_debug=0x01 boot
[00:18] <Sarvatt> okie Ng, https://bugs.freedesktop.org/show_bug.cgi?id=27589 if you wouldn't mind subscribing incase they ask for more info :)
[00:24] <Ng> Sarvatt: cool thanks, subscribing now
[00:24] <Sarvatt> well its linked now so it'll show up in the launchpad bug, forgot about that :D
[01:29] <DanaG> hmm, has the version of nouveau planned for Lucid been locked down?  I'm having this issue, which I'd call a release-blocker for some hardware:
[01:29] <DanaG> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/547124
[01:30] <DanaG> I've added a backtrace with debug symbols.
[01:30] <DanaG> ah, looks like it's already being commented on. cool.
[01:33] <RAOF> DanaG: Yeah.  Can you try edgers?  There's a libdrm commit that looks jucily like a fix for that.
[01:34] <DanaG> Yup, already tested it, in fact -- works fine in Edgers (as long as you keep the userspace and kernel components matching).
[01:34] <RAOF> Right.
[01:34] <RAOF> That, of course, being the big (Linus-fire-breathing) trick.
[01:35] <DanaG> hmm, I can try fetching source with that package, depending on how long it'll take to build that myself.
[01:36] <DanaG> ah, just libdrm... cool.
[01:36] <RAOF> If it works fine in edgers that's all I really need to know.
[01:42] <DanaG> heh, nv17 is a card that never should have existed.
[01:42] <DanaG> It's absolute bollocks that they replaced the geforce3 with a "4 mx" that's really not even a geforce3.
[01:42] <RAOF> That's your GeForce “4” MX, right?
[01:42] <DanaG> Yeah.
[01:42]  * RAOF had one of those, too.
[01:43] <DanaG> I mean, even cutting down a geforce 3, I can understand.... but to skip back two generations? Fail.
[01:44] <DanaG> If ATI did the same, the 9200 would be a souped-up Radeon 7500, not a tweaked Radeon 8500. =þ
[01:44] <DanaG> no, it would be a 7000.
[01:45] <DanaG> Cool, rebuilt libdrm... works great with that patch.
[01:45] <DanaG> er
[01:45] <DanaG> lemme double-check.
[01:45] <DanaG> gdm seems to be doing something funky.
[01:46] <DanaG> yup, it works.  Had to reboot to un-failsafe it.
[01:47] <RAOF> Sweet.
[01:48] <DanaG> And now that I'm not on edgers, it's not offering 3D -- which is a good thing, since nv17 3D is just a "bag of hurt".
[02:25] <DanaG> hmm, is there a slightly-less-"edgy" xorg-edgers that has the nouveau that would go with 2.6.34 kernel?
[02:26] <DanaG> great... the display-switch hotkey on this laptop forcibly goes behind the OS's back and does god-only-knows what, and royally breaks the video output.
[02:27] <DanaG> on the old Toshiba, ubuntu netbook would be far nicer than winxp... if not for toshiba's stupidity (that needs a driver that's only in 34 kernel).
[02:30] <RAOF> DanaG: edgers, with /usr/lib/xorg/extensions/nouveau_vieuex.so deleted?
[02:30] <DanaG> Or rather, dpkg-diverted.
[02:30] <RAOF> Yah,
[02:30] <DanaG> My brother was wanting me to set the thing up (it's his old laptop) for my grandmother (who lives way across the country).
[02:32] <DanaG> Or maybe just build the new toshiba-acpi out-of-tree.
[03:20]  * DanaG gives up and sticks XP on the thing... and will be glad to be rid of it.
[03:20] <DanaG> Too much stuff broken by the combination of nvidia + toshiba.
[03:21] <RAOF> :/
[03:22] <DanaG> I can't, in good conscience, set up Ubuntu on this old Toshiba, for somebody who lives way across the country. Especially with things as bad as the "I hit two keys and the screen died" sort of stuff.
[03:22] <DanaG> And as a bonus, I can stop griping about the nvidia thing... since it won't be in my hands anymore. =þ
[03:23] <RAOF> That laptop's can't be your gforce2mx, though.
[03:23] <DanaG> no, I mean, the toshiba IS the one with the MX.
[03:24] <RAOF> At what point did some madman want to stick a gforce 2 mx into a laptop.
[03:24] <RAOF> That ain't no laptop card!
[03:25] <DanaG> And some madman also used not only a P4, or a Celeron, but both -- P4-based Celeron!
[03:25] <DanaG> Ew.
[03:25] <DanaG> If P4 == crap and Celeron == crap, then that thing == crap².
[03:26] <bjsnider> DanaG, are you now absolving nvidia of any blame for your crappy laptop?
[03:27] <DanaG> Actually, it's my brother's.
[03:27] <DanaG> I would never have chosen something that sucky. =þ
[03:28] <DanaG> In this case, Toshiba is the one to blame.  They even managed to screw up the EDID, so it claims to be 969x768.
[03:28] <bjsnider> it is not nvidia's fault that they spend 30 seconds a year working on the 96 driver?
[03:29] <DanaG> That's not what I meant.  Toshiba were just the ones to choose the stuff to go into the laptop... and they chose badly.
[03:31] <DanaG> Anyway, that's all way off-topic, anyway.  Oops, I just said "Anyway" twice -- or now it's 3 times.
[04:10] <ripps> Hmm... just booted into new -20 lucid kernel. Xorg seems to be higher than usual, but I'm not experiencing any performance loss with my browser and pulse. Guess jus wait and see if the usual lag shows up.
[04:20] <ripps> There it goes
[04:20] <ripps> uptime 25 min
[04:22] <ripps> this makes no sense, what happens at ~25 minutes that could be causing this lag
[04:24] <ripps> Everytime I move something, either changing window in screen or moving something with my mouse, I get a serious amount of lagging and stutter. Everything visual and audio become choppy...
[04:33] <Sarvatt> it go away if you switch to a vt and back?
[04:34] <ripps> Sarvatt: nope
[04:35] <ripps> killing gnome-session or otherwise restarting Xorg fixes things; for another half hour
[04:36] <ripps> Xorg ~20% normally, around ~10% in VT. Not much audio lagging there.
[04:36] <RAOF> A mem-leak which takes about 25 minutes to make you hit swap?
[04:37] <RAOF> Something triggers gnome-settings-daemon to probe the xrandr properties crazily?
[04:38] <ripps> whoa, killing gnome-settings-daemon made Xorg jump to ~75%. Massive slowdown, than back down to normally laggy ~20%
[04:39] <ripps> According to top, Xorg is only using 3.8% memory, is that enough to hit swap?
[04:40] <ripps> Of course, this might have nothing to do with Xorg, it's just a victim here.
[04:42] <RAOF> What's actually happening when everything goes pear-shaped?  Is there a high memory load, or high CPU usage, or…?
[04:44] <ripps> RAOF: I've been trying to figure it out, but I can't find any sortof trigger besides ~25 minutes, and either nautilus or a browser open. If I'm not using the computer and just have Transmission and evolution open, it doesn't seem to hit lag zone.
[04:46] <ripps> But I can just be scrolling down a page in chrome and at around ~25 minutes, lag zone hits. I get this in 2.6.33 mainline as well, but it only happens for a minute before it seems to recover and behave normally.
[04:46] <RAOF> And what are the symptoms other than “it seems to get laggy”?  Is there an unusual memory load?  Unusual CPU load?
[04:47] <ripps> RAOF: the only thing I can notice is that Xorg's cpu usage tends to be a bit higher. There doesn't seem to be an abnormal amount of swap being used according to free -m (in fact, it says only 39mb is being used by swap now)
[04:48] <RAOF> So the CPU usage isn't 100%?  Load average is reasonable?
[04:48] <RAOF> Let's get some logs!  Xorg.0.log and dmesg.
[04:49] <RAOF> One of those might provide something to bite into.
[04:49] <ripps> RAOF: I've been checking all the logs in /var/log. I'm not finding anything useful.
[04:49] <ripps> I'll pastebin them if you want
[04:50] <RAOF> They'll be better than nothing.
[04:52] <ripps> Xorg.0.log: http://pastebin.com/3sDYpmZ5
[04:53] <ripps> dmesg: http://pastebin.com/3sDYpmZ5
[04:53] <ripps> correction, dmesg: http://pastebin.com/gCfekW1m
[04:55] <ripps> messages: http://pastebin.com/WqKAFCvC
[04:56] <Sarvatt> darnit, guess I can't use chromium anymore at all, my system starts going swap crazy after a few hours no matter what versions of everything i'm using.. my gem_objects are rediculious using chromium, 3k objects using 1.2GB after 2 hours uptime..
[04:57] <Sarvatt> [21157.585651] Out of memory: kill process 19759 (chromium-browse) score 2358912 or a child
[04:57] <Sarvatt> [21157.585663] Killed process 19759 (chromium-browse)
[04:57] <Sarvatt> [21209.492436] pulseaudio invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
[04:57] <ripps> debug: http://pastebin.com/s3e3dvTH
[04:58] <ripps> Sarvatt: do you see that with google-chrome-unstable?
[04:58] <Sarvatt> huzzah it actually killed itself on its own in under 5 minutes for once, usually I spend almost 20 barely able to move the mouse pointer before giving up
[04:58] <RAOF> You're right.  Apart from your tuner drivers being broken I don't see anything particularly informative in those logs.
[04:59] <ripps> I kind of forgot about that tuner, I haven't used it in years... I should just remove it.
[04:59] <Sarvatt> ripps: yeah no different with google-chrome-beta even
[05:02] <ripps> I don't think compiz is responsible for the problem. First of all, the problem persists, even when I revert to metacity; Second, the compiz effects aren't actually slowed down, I can use scale and expo with decent speed. But scrolling or opening a window grinds video/audio to a momentary halt. It like theres something up with gtk or X11 rendering.
[05:04] <ripps> I'm about ready to reinstall my entire ubuntu to see if it fixes the problem, I'm an upgrade from Karmic to Lucid Alpha 1 and I figure it can't hurt to clean up the system.
[05:05] <ripps> I have my /home on a seperate partition, so It should be pretty clean and straight forward reinstall
[05:08] <Sarvatt> valgrinding X sure is a fun adventure
[05:10] <ripps> I've read a few comments on Identi.ca where some people think that lucid beta2 is much more unstable than the alphas. I think a recent upgrade has been giving alot of problems
[05:19] <Sarvatt> oh ripps your problem might just be a pulse problem
[05:23] <RAOF> Sarvatt: What do you think about bug #541492?  The only thing reported to work reasonably there is disabling DRI, which seems a serious feature regression.  It doesn't look like we've got the “big hammer” kernel patch, which also isn't a fix but makes things crash less.
[05:24] <RAOF> In a surprising turn of events, it looks like i845 is more stable *with* kms than without.
[05:25] <ripps> Sarvatt: nope, I already tried killing pulse, no such luck.
[05:26] <RAOF> Upstream seems to have a good idea of what's going wrong, just not a good idea of how to fix it.
[05:26] <RAOF> I guess we could disable DRI for release, and then fix it in an SRU when there's a fix available.  Maybe.
[05:29] <ripps> I'm going back to 2.6.33 mainline so I can d/l the lucid-beta2 iso and reinstall ubuntu.
[05:33] <Sarvatt> RAOF: 8xx is a mess, I think 865 is the only one thats even remotely stable and theres pretty much no way the fixes are going to be in lucid.. he keeps pushing out huge patch series on the lists that refactor whole subsystems in preparation of trying to fix things on 8xx
[05:35] <Sarvatt> blacklisting KMS on 8xx was working for a lot of people from what I saw because we disabled UMS support in intel 2.9.1 for awhile (meaning people got vesa automatically with nomodeset) and I see just as many problems now that we have UMS again except people have to manually pick vesa now too
[05:35] <RAOF> Right.  There seems to be at least as many and as serious problems with UMS as KMS.
[05:37] <RAOF> The question is what to do about it.
[05:37] <Sarvatt> oh nice, thats a  differen't fdo bug that i was looking at earlier
[05:37] <Sarvatt> which big hammer patch did you mean?
[05:37] <RAOF> Fedora has a patch which doesn't fix things, but which introduces a sufficient delay that it doesn't hit the problem so often.
[05:38] <Sarvatt> i was just digging through agp commits that are different between our 2.6.32 and upstream
[05:38] <RAOF> Bugger.  ctrl-w shouldn't be so close to ctrl-v
[05:38] <Sarvatt> RAOF: do you mean drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing.?
[05:38] <RAOF> https://bugzilla.kernel.org/attachment.cgi?id=25084 is the patch that I'm talking about.
[05:39] <Sarvatt> because we've had that for a long time
[05:40] <Sarvatt> ah yeah we just have the equivalent to that for 865 only
[05:40] <Sarvatt> (which is probably why 865 actually kind of works)
[05:40] <RAOF> Hm.  Not according to my grep of ubuntu-lucid
[05:41] <RAOF> wbinvd is called from exactly 2 places in lucid's kernel - drm_cache.c and ati_pcigart.c
[05:42] <RAOF> If we had the big hammer patch, it's been lost along the way somewhere.
[05:42] <Sarvatt> huh, you're right
[05:42] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/gpu/drm/i915/i915_gem.c;h=e2421869a40cf809f509c57e58a770a7c0e4043a;hp=e4408daf8cef099d388611268be5cbd5605c1dc4;hb=cfa16a0de5392c54db553ec2233a7110e4b4da7a;hpb=e76a16deb8785317a23cca7204331af053e0fb4e
[05:45] <Sarvatt> ah removed here http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e517a5e97080bbe52857bd0d7df9b66602d53c4d
[05:48] <RAOF> So, the big hammer patch doesn't fix the problem, but makes it happen (much) less often.
[05:59] <Sarvatt> have you seen any reports that its crashing with vesa?
[06:01] <RAOF> No.
[06:07] <Sarvatt> call me crazy but i think its more than a little crazy to expect things like compiz to work on a 10 year old GPU that was worse than a 4 year old GPU when it was released in a modern distro, they haven't had any acceleration on windows since vista in 2006 and vesa should just work™
[06:08] <RAOF> vesa won't necessarily get the resolution correct, though, right?
[06:08] <RAOF> If we don't care about compiz we could just disable DRI on those cards.
[06:12] <Sarvatt> i'm interested in knowing if anyone has problems with fbdev ontop of KMS on those GPU's
[06:45] <Sarvatt> hmm http://bugs.freedesktop.org/show_bug.cgi?id=27187
[06:46] <RAOF> That'd be a duplicate, surely?
[06:46] <RAOF> Or, rather, should be.
[06:46] <Sarvatt> nope thats 855 specific, patches dont work on 845 going by the other bug..
[06:48] <RAOF> “The new chipset flush is a magic dance involving a flock of canaries”
[06:58] <Sarvatt> RAOF: what netbook did you get?
[06:59] <RAOF> An… Asus N10J
[06:59] <RAOF> It's slightly heavier than my x200s :)
[07:00] <RAOF> But it's got a crazy gpu switch on the side, an nv98, and an hdmi port.
[07:02] <RAOF> It's kinda fun.
[07:03] <Sarvatt> ah darn AMI bios
[07:03] <RAOF> It has, however, reinforced my opinion that netbooks aren't really useful for actual work :)
[07:04] <Sarvatt> i just discovered the wonders of modifying EFI setup variables in insyde bioses, opened up a crazy amount of options I didn't have before and I'm sure switchable graphics ones have a lot more options :D
[07:05] <RAOF> Oooh, cool.
[07:05] <Sarvatt> pfft I've used a netbook as my primary machine for 1.5 years now and haven't looked back, 8.9" too
[07:05]  * RAOF is firmly of the opinion that they're a poor-man's x200s
[07:05] <RAOF> 12" is where it's at.
[07:06] <RAOF> You get a full size keyboard, and a CPU that's faster than mental computation.
[07:06] <Sarvatt> yup I'm poor! :) I have 4 other laptops but the 10 hour battery is what makes it for me, spend most of my time using it on the road
[07:06] <Sarvatt> 11-12" is what i'm going to get next for sure though, already eyeballing some new ones
[07:11] <Sarvatt> oh sheesh, lenovo has NIC/ac adapter whitelists in the bios too? I thought only HP was that crappy..
[07:14] <RAOF> AMI bios, so I can't play with funky options?
[07:19] <Sarvatt> RAOF: btw looks like theres more than just the backported fix for nouveau in the old nouveau api situation - http://cvs.fedoraproject.org/viewvc/F-12/libdrm/nouveau-fix-bo-failure.patch?view=markup
[07:20] <RAOF> Bah.  Why isn't the second fix in libdrm git?
[07:21] <RAOF> Also, why explicitly cast to void *?  That's throwing away the compiler warning that would have told you that you're doing something obviously wrong and stupid.
[07:21] <RAOF> :(
[07:22] <Sarvatt> yeah with my insyde bios i can just dump the full list of options and patch the ones i want, never had any luck doing this with other brands before. here's a listing off one of mine (summary at the bottom) http://pastebin.com/fqAxCqmi
[07:22] <RAOF> Silly me.  Need to read more context.
[07:23] <Sarvatt> theres no NOUVEAU_BO_PIN in the 0.0.16 api
[07:23] <RAOF> Yeah.  I should think before talking.
[07:25] <Sarvatt> xserver: Branch 'server-1.7-branch' - 20 commits -- whoa
[13:45] <asac> bryceh: tjaalton: http://pastebin.com/SfEsJXN7 ... can i just upload ?
[13:46] <asac> or can you stage and upload?
[13:46] <asac> (thats the last one ;))
[13:46] <asac> for lucid
[13:54] <tseliot> asac: it looks good to me. Do you have access to the git branch too?
[13:54] <asac> tseliot: i dont think i have access
[13:54] <asac> can you apply and i push
[13:54] <asac> ?
[13:55] <asac> or just replay?
[13:55] <tseliot> asac: yes, I can apply your changes for you
[13:55] <asac> thanks
[13:55] <tseliot> asac: let me check if there's something else pending first
[13:55] <asac> kk
[13:56]  * asac stands in line
[13:57] <tseliot> asac: yep there seem to be pending changes: git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=ubuntu
[13:58] <tseliot> Sarvatt: is your patch ^^ ready to be uploaded?
[14:01] <ScottK> tseliot: We got that KDE issue sorted over the weekend.
[14:01] <tseliot> ScottK: that's great news :-)
[14:01] <ScottK> Yeah, I was worried about that one.
[14:04] <bjsnider> tseliot, is there a big nvidia-current breakage right now?
[14:04] <tseliot> bjsnider: no, why?
[14:04] <bjsnider> the lucid channel has been choked with complaints all weekend
[14:06] <bjsnider> also several people are saying they managed to use the nvidia-installer
[14:06] <tseliot> bjsnider: complains about what? About not being able to complete the installation in Jockey?
[14:07] <tseliot> yes, you can use the installer, and screw your system in the process ;)
[14:07] <bjsnider> i thought it was disabled
[14:07] <tseliot> you can override that block
 NET||abuse: current is 195 and with nvidia-current 3D doesn't work for me :( but when I install binary distribudion from nvidia over it it works
[14:09] <bjsnider> there were some complaints about jockey reporting that "a different version" is in use
[14:12] <tseliot> I have fixed that today
[14:12] <tseliot> (the 2nd issue)
[14:13] <tseliot> and "3D doesn't work for me" without any logs doesn't mean much to me
[14:13] <tseliot> (and without knowing how the driver was installed)
[14:16] <bjsnider> tseliot, i'll get more info about what the deal was on the weekend and report it to you, but i think it was the jockey thing.
[14:16] <bjsnider> a lot of people put too much faith in what jockey tells them unfortunately
[14:16] <asac> tseliot: i can also upload this as 2.1
[14:16] <asac> but lets wait a bit longer for Sarvatt 
[14:16] <tseliot> bjsnider: ok, if so, revision ubuntu7 should fix it
[14:17] <tseliot> asac: yes, let's wait a little bit
[14:20] <bjsnider> tseliot, is it realistically possible to recover from using the nvidia-installer or should that person do a wipe & reload?
[14:21] <tseliot> bjsnider: maybe by passing --uninstall to the installer and reinstalling mesa
[15:49] <seb128> is there a known ati issue after user switching?
[15:49] <seb128> we get quite some bugs on the desktop side saying that screen stays blank after switching
[16:06] <tseliot> seb128: yes, it's a known issue, nothing we can do about it
[16:07] <seb128> tseliot, why not? I didn't check but is that a fglrx bug?
[16:07] <seb128> I'm pretty sure I saw an issue on a box using the opensource one
[16:08] <tseliot> seb128: yes, I was referring to fglrx. If it affects -ati then it must be a different issue
[16:08] <seb128> ok, is there a known issue on ati open source? ;-)
[16:11] <tseliot> I wouldn't know. Anyone ^^ ?
[16:27] <tseliot> asac, Sarvatt: my bad, there doesn't seem to be any pending commit. Feel free to upload. I'll commit your changes to git
[16:27] <asac> kk
[16:28] <asac> tseliot: if something explodes let me know ;)
[16:28] <tseliot> asac: sure :-P
[16:29] <asac> uploaded
[16:29] <tseliot> asac: ok, let me upload the git branch
[16:32] <tseliot> asac: ok, done
[16:32] <asac> cool
[17:25] <Sarvatt> sorry about that asac and tseliot
[18:26] <Sarvatt> darn I was packaging up the new geode with the missing icon fix commit but Q-FUNK already pushed it to debian even :)
[19:11] <Sarvatt> the compiz change to not start at >= max texture size instead of > max texture size sure is ruffling alot of feathers
[19:12] <Sarvatt> > max texture size was working for radeon people with dual screen setups, but people on intel with 1 monitor thats 2048xwhatever can't use it
[19:13] <Sarvatt> hmm looks like dual monitor 2048 virtual on intel worked too, just not single monitor
[20:30] <Sarvatt> well that doesn't look good..
[20:30] <Sarvatt> 221 objects
[20:30] <Sarvatt> 26755072 object bytes
[20:30] <Sarvatt> memory usage is fine with edgers, totally busted with lucid
[20:31] <Sarvatt> ahhh wait I disabled BO reuse in driconf this boot
[20:32] <ripps> Okay, it time to potentially break my desktop. Let's reinstall Ubuntu
[20:55] <ripps> Okay... livecd is broken, just drops me to a commandline, no X
[21:50] <ripps> okay, how about trying xorg-edgers, and than if that fails, I'll try d/ling the daily livecd
[21:58] <ripps> Well, xorg-edgers seems to load just fine, we'll see if I still get the massive slow down in ~25 minutes
[22:45] <ripps> Hmm... well, it's been about 50 minutes, and I haven't seen any massive slowdowns/lag/stuttering so I guess xorg-edgers fixed it. (I've probably just jinxed it)
[22:56] <ripps> dang, I jinxed it. After lagging has showed up.
[22:57] <ripps> It happened after loading a large image in chrome while running aptitude update in terminal... might be related, probably not.
[23:00] <ripps> hmm... I gonna play with some ati driver options in xorg.conf, see if maybe limiting the agpsize will help