[00:26] <Sarvatt> RAOF: bored? want to try testing out a plymouth change to see if fixes it? wish i could still reproduce it :( it'll show up here - https://edge.launchpad.net/~sarvatt/+archive/bugfixes
[00:27] <RAOF> I'll give it a whirl next time I reboot.
[00:30] <Sarvatt> i just changed it to stop resetting the ISIG flag on plymouth's VT. i think our gdm/plymouth integration stuff is screwing up with that because its using the same VT
[00:42] <superm1> Sarvatt, and here i thought i was crazy that I was crashing X by hitting enter on my terminals the other day :)
[02:12] <johanbr> hi... what could be the problem if nouveau says "(EE) [drm] failed to open device" ?
[02:12] <johanbr> this is on lucid + xorg-edgers, completely updated
[02:14] <Sarvatt> did you boot the 2.6.32-14 kernel?
[02:15] <johanbr> yep
[02:15] <johanbr> http://paste.ubuntu.com/382674/ for X log
[02:16] <johanbr> uname -a
[02:16] <johanbr> oops :)
[02:17] <Sarvatt> were you the person that didn't update things and just updated individual packages instead?
[02:17] <johanbr> yes, definitely 32-14 :)
[02:17] <johanbr> I've done that sometimes yes
[02:17] <johanbr> but I remembered our conversation, so did a full dist-upgrade this time :)
[02:17] <Sarvatt> is it a laptop with the lid closed by any chance?
[02:18] <johanbr> laptop yes, lid closed no
[02:18] <Sarvatt> actually, i think acpi=noirq might be messing with it, can you try booting with lbm-nouveau.ignorelid=1 added to grub?
[02:19] <johanbr> absolutely
[02:19] <johanbr> I'll try removing the acpi= option too
[02:19] <johanbr> back in a minute... 
[02:19] <Sarvatt> that'll ignore the acpi lid status, log looks like mine does when i boot with the lid closed
[02:22] <Sarvatt> hmm he said he was using edgers but.. 	compiled for 1.7.5, module version = 0.0.15
[02:22] <Sarvatt> oh nevermind mine says that too, the drm message later is where it says its 0.0.16
[02:26] <Sarvatt> any luck?
[02:26] <johanbr> afraid not... still didn't work, but log now slightly different
[02:27] <johanbr> http://paste.ubuntu.com/382680/
[02:28] <johanbr> "drmGetBusid returned ''" doesn't look good
[02:28] <johanbr> it was "lbm-nouveau.ignorelid=1", right?
[02:29] <Sarvatt> can you paste your dmesg?
[02:29] <johanbr> sure, just a sec
[02:30] <johanbr> http://paste.ubuntu.com/382683/
[02:33] <johanbr> I do have the experimental 3d stuff installed... could that be interfering?
[02:34] <Sarvatt> do you have nouveau-firmware installed?
[02:34] <Sarvatt> no i dont think so, some pretty nasty errors in dmesg there
[02:35] <johanbr> yep, nouveau-firmware is installed... 20091212-0ubuntu1
[02:36] <RAOF> All these people with shiny new nv5x+ cards!  They'll get to test out the ctxprog generator soon, I think; it sounds like mwk's gearing up for a test-request on it.
[02:36] <Sarvatt> johanbr: hmm I think i'd start by purging plymouth and seeing if that helps any
[02:37] <johanbr> I actually just installed plymouth to see if that would help :)
[02:37] <johanbr> but I'll try purging it and removing the boot options, I haven't tried that combination
[02:38] <johanbr> back in a bit...
[02:40] <RAOF> Why is that drm rather than lbm-drm?
[02:41] <Sarvatt> where?
[02:41] <RAOF> In johanbr's dmesg logs.
[02:42] <Sarvatt> hmm
[02:42] <Sarvatt> good point
[02:42] <RAOF> Someone's got a stale version of 0.0.15 from upstream; it's 2.6.32-847-nicelogshasum
[02:43] <RAOF> Actually, it might be nouveau-kernel-source.
[02:44] <Sarvatt> ugh yeah gotta be, [   12.306932] [drm] Initialized nouveau 0.0.15 v2.6.32-847-g50ebb93924038778b for 0000:01:00.0 on minor 0
[02:44] <Sarvatt> completely missed that
[02:44] <RAOF> It might be nice to get that info into the lbm-builds, too.
[02:45] <Sarvatt> [   13.428170] [lbm-drm] Initialized nouveau 0.0.16 20090420 for 0000:05:00.0 on minor 0 here
[02:46] <RAOF> Actually... what would be nice in there is “initialized nouveau 0.0.16 lbm-drm $PACKAGE_VERSION ...”
[02:52] <Sarvatt> deleting nouveau-kernel-source from edgers
[02:52] <Sarvatt> i'm sure thats what he did
[02:54] <Sarvatt> think i should upload lbm-nouveau with http://0x04.net/~mwk/0001-drm-nv50-Implement-ctxprog-state-generation.patch ?
[02:57] <Sarvatt> eh might as well, its crack anyway :)
[02:58] <Sarvatt> http://lists.freedesktop.org/archives/nouveau/2010-February/005137.html
[03:06] <Sarvatt> uploaded
[03:11] <johanbr> finally!
[03:11] <johanbr> downgrading the X server made nouveau work again
[03:17] <johanbr> Sarvatt, I *think* it was this upgrade that broke it:
[03:17] <johanbr> [UPGRADE] xserver-common 2:1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubu
[03:17] <johanbr> ntu0sarvatt3 -> 2:1.7.5~git20100216+server-1.7-branch.f0ec2e0d-0ubuntu0sarvatt
[03:17] <Sarvatt> johanbr: you installed nouveau-kernel-source
[03:17] <Sarvatt> thats an obsolete package and screwed things up
[03:18] <johanbr> oh!
[03:18] <Sarvatt> i deleted it off edgers so noone else would do that
[03:19] <johanbr> ahhh...
[03:19] <Sarvatt> we probably need to get nouveau-kernel-source deleted from the archive too?
[03:20] <Sarvatt> xserver should be 1.7.5-1ubuntusomething btw, theres newer in the archive than whats in lucid
[03:20] <Sarvatt> err than whats in edgers
[03:22] <Sarvatt> johanbr: sudo apt-get purge nouveau-kernel-source should fix you up
[03:22] <johanbr> yep, just that did that :)
[03:22] <johanbr> I'll just reboot and make sure everything's okay
[03:22] <johanbr> many thanks for your help
[03:23] <Sarvatt> no worries, you'll see lbm-drm in your dmesg instead of drm all over the place
[03:23] <Sarvatt> if its working right
[03:29] <Sarvatt> any luck?
[03:31] <johanbr> yep, back to working order now
[03:31] <johanbr> thank you
[03:31] <Sarvatt> no worries, sorry about that, should have removed that package a long time ago
[03:32] <Sarvatt> bryceh: nouveau-kernel-source should probably be removed from the archive for lucid :)
[03:32] <bryceh> Sarvatt, heh
[03:33] <Sarvatt> i put a firmwareless nouveau package up on edgers also to get more testing
[03:33] <Sarvatt> http://lists.freedesktop.org/archives/nouveau/2010-February/005137.html
[03:34] <Sarvatt> i'm guessing it'd work fine for whats going in lucid, its the 3D stuff thats iffy with it
[03:48] <Sarvatt> maybe we should patch out this error message from evdev - (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
[03:49] <Sarvatt> alot of people posting  bug reports thinking its actually a problem
[03:50] <Sarvatt> its just because of how we load evdev always then another driver if it fits later from how the udev rules are set up
[03:54] <Sarvatt> http://sarvatt.com/downloads/patches/0001-Silence-EVIOCGNAME-error.patch  ?
[04:00] <bryceh> AGREED
[04:00] <bryceh> I just triaged a bug about that
[04:01] <RAOF> Sarvatt: Wow, you're quick.  I was going to apply that voodoo generator later this afternoon :)
[04:01] <bryceh> Sarvatt, works for me
[04:02] <bryceh> Sarvatt, do you have git access to the -evdev tree?  If so, go ahead and commit that.  If not, I'll take care of it tomorrow
[04:31] <Sarvatt> sure thing bryceh, i'll merge everything into the ubuntu branch and set it all up. should I set the changelog to UNRELEASED or leave it lucid?
[04:31] <Sarvatt> xserver-xorg-input-evdev (1:2.3.2-3ubuntu1) lucid; urgency=low
[04:32] <Sarvatt> i merged the xserver-xorg-input-evdev-1_2.3.2-3 tag into ubuntu since thats what we're on in lucid, origin/ubuntu was really old since we've been syncing from debian for lucid
[04:33] <Sarvatt> building it now to see if its working right before i push it
[04:36] <Sarvatt> yay works fine, http://paste.ubuntu.com/382729/
[04:39] <Sarvatt> well I just left the changelog as lucid, hope I dont screw anything up doing that :)
[04:40] <Sarvatt> pushed it all here http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=shortlog;h=refs/heads/ubuntu
[05:05] <Sarvatt> bryceh: do you want a debdiff? should I include the changelog with the ubuntu history in it if so since the synced one just has the debian history? here's one if thats right - http://sarvatt.com/downloads/patches/xserver-xorg-input-evdev_2.3.2-3ubuntu1.debdiff
[06:30] <bryceh> Sarvatt, looks great
[06:31] <bryceh> Sarvatt, only other thing is if you can associate the debdiff to a launchpad bug report, it's good to do so
[06:37] <bryceh> Sarvatt, upload sponsored
[06:45] <Sarvatt> thanks bryceh 
[06:45] <Sarvatt> go figure I found one after - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/517316
[06:45] <ubottu> Launchpad bug 517316 in xserver-xorg-input-evdev "ioctl EVIOCGNAME failed on lucid" [Undecided,Fix released]
[06:45] <Sarvatt> was on virtualbox-ose :)
[06:47] <bryceh> heh, yeah that always happens to me
[06:47] <bryceh> sometimes doing a google against site:bugs.launchpad.net for the error message turns up some bug matches
[06:47] <bryceh> probably would get too many hits in this case though
[06:50] <Sarvatt> label:ubuntu-x-swat eviocgname in gmail here :)
[06:50] <Sarvatt> almost 11k bug emails in there
[06:51] <bryceh> closing out all the -nv bugs make a good dent in our peak - http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
[06:52] <bryceh> also with james_w's help I sorted out a bug that's been preventing my triaging scripts from running for the last few months, so I'm hoping they'll kick in and start catching up on triaging work
[06:52] <Sarvatt> nice!
[06:52] <bryceh> I think outside the scripted triaging, I'm personally just going to be focusing  on bugs marked 'lucid' (maybe I mentioned that already)
[06:52] <Sarvatt> nvidia stuff is going to be *hard*, so many bugs that are just people screwing things up for themselves and needing help fixing it instead of actual bugs
[06:53] <bryceh> er, s/marked/tagged/
[06:53] <bryceh> yeah, totally
[06:53] <bryceh> I've complained about that at the last few ubuntu gatherings
[06:53] <bryceh> they're more like support requests than bug reports
[06:54] <bryceh> i.e., "Please fix this issue that is making my system broken" vs. "This is a flaw in the Ubuntu product that should be fixed"
[06:57] <Sarvatt> yeah the kind of thing you can spend 8 hours helping 8 people fix it when you have 1000+ bugs worth of it to go through..
[06:59] <bryceh> yep
[07:00] <bryceh> what chaps my hide is when the bug reporters get dickish about it... e.g. #121574
[07:01] <bryceh> although I've noticed it's rarely actually people who actually report bugs, but more likely drive by commenters who've never filed bug reports before who have the worst manners
=== yofel_ is now known as yofel
[11:59] <DawnLight> compiz is leaking memory i'm gonna run out i wanna report what do i do quick
[11:59] <DawnLight> ?
[13:29] <bjsnider> Sarvatt, i don't doubt that you're correct about nvidia users having screwed up their own systems and now they need help, but can you give a few examples of that?
[16:50] <apw> under KMS if your edid information is wrong or hidden by a KVM switch is there any way to tell KMS drivers a sensible resolution override line one used to do in /etc/xorg.conf ??
[16:51] <jcristau> i think you can pass something like video=VGA1:1024x768 to the kernel
[16:52] <tseliot> can it be video=LVDS1 too (when using a laptop)?
[16:53] <jcristau> …
[18:37] <smb> tseliot, Hm, if I would now any name. On laptops I would look into acpi info but on a desktop...
[18:38] <tseliot> ???
[18:39] <smb> tseliot, Sorry, trying the thing apw has askd before
[18:39] <tseliot> ah, ok
[18:39] <smb> Getting a different video mode on a kms
[18:39] <smb> But its a desktop to acpi knows nothing about gfx hw
[18:40] <smb> And its nouveau and behind a switch that hides the EDID 
[18:41] <tseliot> ouch
[18:43] <smb> Atm, it feels to me we got 3 kernel/grub arguments which all do *not* work. Or I just have not found out how they are supposed to work
[18:43] <tseliot> what arguments?
[18:45] <smb> vga= is deprecated, video= and gfxpayload=
[18:48] <apw> tseliot, have you ever tried video= on kms?
[18:50] <tseliot> nope
=== yofel_ is now known as yofel
[21:28] <tormod> please cherrypick for mesa, bug 515846
[21:28] <ubottu> Launchpad bug 515846 in mesa "mesa 7.7 DRI crash, assertion in driNewRenderbuffer()" [Undecided,Confirmed] https://launchpad.net/bugs/515846
[21:29] <tjaalton> is it not in 7.7-branch?
[21:30] <tjaalton> seems to be
[21:30] <tjaalton> so we'll get it anyway
[21:36] <RAOF> Sarvatt: I don't think your -11 plymouth fixed the enter crash for me.
[21:46] <BUGabundo> bRoas
[21:48]  * jcristau sighs at subscriber-only ubuntu lists...
[21:49] <bryceh> ahem, "spam-free" subscribe-only ubuntu lists...
[21:52] <BUGabundo> eheh
[21:52] <BUGabundo> humm
[21:52] <BUGabundo> don't member be able to email to every list?
[21:52] <BUGabundo> *Members/Motu
[21:53] <bryceh> dunno
[21:57] <jcristau> well at least kernel-team@ seems to be moderated, rather than outright rejecting non-subscriber posts
[21:57] <BUGabundo> AFAIK all lists are moderated
[21:58] <jcristau> that's not what mailman tells me
[21:59] <tormod> tjaalton, hi, "we'll get it" like soon? I think it is a blocker for all non-intel/ati
[22:04] <tjaalton> tormod: like after alpha3
[22:04] <tjaalton> bgoglin is about to upload 7.7-4
[22:05] <tormod> goodygood
[22:56] <kklimonda> so the latest nouveau broke it for me :/
[22:59] <kklimonda> update*
[23:07] <kklimonda> the one from xorg-edgers ppa 2.6.32-14.999~xorgedgers4
[23:13] <RAOF> Broke in what way?