[00:09] <Sarvatt> tormod: the -dbgsym package works -dbg has the wrong CRC
[00:09] <Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of B4300B09
[00:09] <Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be B4300B09
[00:09] <Sarvatt> (after purging dbg and installing dbgsym)
[00:35] <Sarvatt> bryceh: has this been the craziest week for bugs or what? :D
[00:38] <Sarvatt> wowsa, my VPS moved to a new datacenter and they put me on a 8 core xeon instead of the slow dual core opteron I had before, time to build some kernels!
[00:38] <bryceh> Sarvatt, has it?  sadly it seems rather pedestrian compared with some releases
[00:38] <bryceh> always the last few weeks before release get kind of crazy
[00:38] <bryceh> I'm actually a bit optimistic that 8xx is our only big worry at the moment
[00:56] <Sarvatt> ati and nouveau are in nasty shape, we've got <NV50 nouveau's reporting phantom TV connectors a lot of the time coupled with the fact plymouth is broken on nouveau with >1 output, there are quite a few ati generations with issues like rn50 with a tdms hooked up that refuses to start that i just found out about this morning (nasty because thats a *very* popular server chipset), and tons of reports about screwed up multihead issues on other ati. K
[00:56] <Sarvatt> MS should have been disabled on the server kernels for sure. then there's the flickering lenovo and people with switchable GPU's using the intel side are getting, I wasn't able to work out a way to use failsafe easily because the initramfs-tools blacklists were getting ignored after a certain point in the boot and KMS was loading anyway. clutter 1.2 is HORRIBLY slow on intel without xserver 1.8 because of the GLX swap method its using
[01:00]  * bryceh holds hands over ears, shuts eyes, and 'lalalala's
[01:01] <bryceh> honestly though, all those issues seem bad but we've had releases that were much worse
[01:01] <bryceh> or at least seemed much worse
[01:02] <bryceh> I'm sure jcristau is sitting over there laughing at us for sucking so bad ;-)
[01:05] <Sarvatt> i think we're going to set a record for the number of complaints that the livecd wont even start up this release :)
[01:07] <bryceh> Sarvatt, I dunno
[01:07] <bryceh> I can see that possibly with -nouveau, but even -nv tended to suck pretty hard in that regard
[01:07] <bryceh> -ati and -intel seem to be pretty solid in my own testing
[01:20] <bjsnider> but clutter isn't going to be used as much because gnome-shell isn't the default yet, so that intel issue isn't too bad
[01:34] <RAOF> Sarvatt: I thought I was pretty on top of the nouveau bugs, and I can't recall a lot of phantom TV problems.  We could pick up Fedora's patch to quirk that off if there's a widespread problem.
[01:36] <RAOF> Sarvatt: I think the problem where the blacklist gets ignored is that the blacklist only prevents the module being autoloaded, which it does, but then X starts up and the DDX specifically requests it's kernel module, which exists, and so gets loaded.
[01:41] <Sarvatt> wish it was that easy, it was getting loaded by plymouth :(
[01:41] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/539655
[01:41] <Sarvatt> https://bugs.edge.launchpad.net/bugs/533135
[01:41] <RAOF> Oh, balls.  Because plymouth has a drm backend, which will be doing the same thing.
[01:42] <Sarvatt> yeah i tried adding a new check in plymouth for the extra command line option i added to not load but didnt have any luck
[01:44] <Sarvatt> ahhh that second bug wasnt filed against nouveau, no wonder
[01:45] <RAOF> Neither was the first bug.  I'm well aware of the plymouth bug, though, because I've been duping lots of nouveau bugs against in.
[01:45] <RAOF> s/in./it./
[01:51] <Sarvatt> oh nice - http://lists.freedesktop.org/archives/nouveau/2010-April/005576.html
[01:55] <RAOF> A little bit late, but yeah.  I've been watching that.
[02:29] <RAOF> HURRAY!  At least the macbook pro noaccel quirk seems to be working as planned.
[02:38] <bryceh> RAOF, Sarvatt, hey this is probably the last chance we have to toss in patches without doing paperwork... are there any patches on your radars that you'd like to have me upload?
[02:39] <bryceh> I'm about to head over to my mom's to help with some stuff but have a few minutes
[02:40] <RAOF> Are you taking care of vesa-on-855-845?  That's the change on my current radar.
[02:43] <bryceh> that one I think will be worth doing the paperwork on, so I'm ok waiting a couple days there
[02:43] <bryceh> should be an easy patch, but I want to see how the no-kms / no-dri changes shake out before going that route
[02:43] <RAOF> That's reasonable.
[02:45] <Sarvatt> bryceh: none that I can think of unfortunately
[02:45] <bryceh> Sarvatt, I still have on my todo list to look at that redhat patch to rejigger how lvds modesetting works, just haven't had time to dig into it
[02:46] <bryceh> might look at it when I get back tonight or tomorrow morning if there's time
[02:47] <Sarvatt> bryceh: OpenBSD backported quite alot to intel 2.9.1 since they have GEM but no KMS now but I haven't been able to dig up a link yet
[02:47] <Sarvatt> might be worth looking over
[02:48] <Sarvatt> yeah looks like its not public yet, darn
[02:50] <Sarvatt> i was asking if it'd be possible to push it straight to 2.9 branch so everyone could collaborate and send along the commits we are backporting on it but didn't get a response
[02:51] <bryceh> mm
[02:52] <Sarvatt> ahh found a tarball at least  - http://old.nabble.com/New-intel-X-driver-requires-testing.-td28210444.html
[02:56] <bryceh> alright, I have a few minor cherrypicks from xserver upstream which I'll upload later tonight
[02:56] <Sarvatt> going to take a year to compare it from the tarball :D
[02:57] <bryceh> heh, yeah
[03:33] <Sarvatt> http://sarvatt.com/downloads/patches/openbsd2.9.1.patch
[03:33] <Sarvatt> thats a huge patch
[03:35] <RAOF> You're sure that's not just an entirely new driver which happens to share some filenames? :)
[05:39] <vish> Sarvatt: nope , I'm using ATI , and another mac Lucid user also has same problem
[07:35] <RAOF> Has anyone figured out why Xorg seems to prefer vesa over any of the other fallback drivers we've got set?
[07:39] <bryceh> RAOF, don't think so
[07:39] <bryceh> RAOF, worth studying for meerkat tho
[07:44] <RAOF> Man, I wish evolution wasn't such a memory hog.
[07:49] <tjaalton> RAOF: got a logfile?
[07:51] <RAOF> tjaalton: Of Xorg picking the wrong fallback?  Yeah, many.   http://launchpadlibrarian.net/43695726/XorgLog.txt is a fine example.
[07:51] <tjaalton> right, should use fbdev
[07:51] <RAOF> nouveau loads, nv loads, vesa loads, fbdev loads... nouveau bails, vesa picks it up.
[07:51] <tjaalton> but how did that work before? that part was not changed aiui
[07:52] <tjaalton> i mean, how should it know to load fbdev instead of vesa?
[07:52] <RAOF> No, it should try nv before vesa.
[07:52] <tjaalton> oh
[07:53] <RAOF> I don't think we've ever really tested “I'd like driver A, then if driver A fails try driver B, then fallback to vesa or whatever” before.
[07:53] <RAOF> As far as I know, it's always been “try the driver that should work, or vesa if it doesn't”
[07:54] <tjaalton> does this case have xorg.conf?
[07:54] <RAOF> No.
[07:54] <tjaalton> ok
[07:54] <RAOF> If it had xorg.conf X wouldn't be trying to fallback at all, would it?
[07:54] <tjaalton> not true anymore
[07:54] <RAOF> It'd try the driver specified, then bail?  That's the behaviour I remember?
[07:55] <tjaalton> since -2u1
[07:55] <RAOF> Ah.  With xorg.conf.d?
[07:55] <tjaalton> no, the patch from suse (merged in 1.8)
[07:55] <tjaalton> which allows us to use xorg.conf.d & inputclass..
[07:56] <RAOF> Ok.  That seems a better behaviour, yes.
[07:59] <tjaalton> maybe something to ask rüdiger..
[08:05] <tjaalton> RAOF: seeing what happens with beta1 would be interesting too, to confirm if this is a regression or a bug in nv
[08:06] <RAOF> I *think* this has been consistent throughout lucid…  I wonder if I've got a beta 1 livecd handy?
[08:07] <tjaalton> hm, cdimage.u.c doesn't have it
[08:08] <tjaalton> though it should be enough to build the previous xserver version and start with that
[08:08] <tjaalton> or comment out the patches
[08:08] <RAOF> Of course.  Hurray for packaging-in-vcs.
[08:08] <tjaalton> indeed :)
[08:10] <tjaalton> speaking of which, bryceh: please push mesa to git
[08:26] <bryceh> tjaalton, done
[08:27] <tjaalton> bryceh: thanks
[08:28] <tjaalton> fyi, I'm merging a couple of patches from upstream to allow adding stuff in /etc/X11/xorg.conf.d as well
[08:28] <tjaalton> first in debian
[08:28] <tjaalton> now if you do that the system dir is bypassed, breaking things..
[08:29] <tjaalton> the downside is that the conf snippets would move to /usr/share/X11/xorg.conf.d, but that can be done with Breaks and bumping the serverminver
[08:36] <bryceh> tjaalton, getting a bit late for such changes, no?
[08:36] <tjaalton> bryceh: yes
[08:36] <tjaalton> but it's basically a bugfix
[08:36] <tjaalton> pointed out on the ffe
[08:36] <bryceh> looks like uploads are now being blocked and require archive admin approval to get in
[08:37] <tjaalton> already?
[08:37] <tjaalton> well, that doesn't mateer
[08:37] <tjaalton> *matter
[08:37] <bryceh> subject: [ubuntu/lucid] xorg-server 2:1.7.6-2ubuntu4 (Waiting for approval)
[08:38] <tjaalton> ok
[08:39] <bryceh> hi seb128
[08:39] <seb128> hey bryceh
[08:40] <bryceh> tjaalton, any thoughts on these two patches?
[08:40] <bryceh> make lvds modesetting more robust (upstreamed for 2.11, still applies to 2.9.1)
[08:40] <bryceh> http://cvs.fedoraproject.org/viewvc/F-12/xorg-x11-drv-intel/lvds-modes.patch?revision=1.2&content-type=text%2Fplain&view=co
[08:40] <bryceh> ati:
[08:40] <bryceh> Fix default mode setup for invalid edid's
[08:40] <bryceh> http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-drv-ati/radeon-6.12.2-lvds-default-modes.patch?view=markup
[08:44] <tjaalton> bryceh: 2.11.0 is released, does it have that?
[08:45] <tjaalton> looks like it
[08:45] <tjaalton> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7d0e6ff4dadcf243b1006ce6f85bd06c5f4e4908
[08:46] <tjaalton> surprised that the ati one isn't upstream
[08:46] <RAOF> That looks like sound reasoning on the ati patch.
[08:46] <tjaalton> heh
[08:46] <tjaalton> maybe it's less useful with ati kms
[08:46] <tjaalton> ?
[08:48] <RAOF> Maybe.  IIUC the DDX should be able to bend kms to its will - adding modes, etc.
[08:49] <RAOF> So while your boot -> X experience would be of an undriven display, once X started you'd get a suboptimal mode, but at least you'd get something.
[08:51] <tjaalton> ok
[08:53] <RAOF> I'm not sure if that's what the patch would *do*, but it's certainly possible.  Userspace can definitely add modes (at least for nouveau; I haven't tested radeon).  I can do so via xrandr.
[08:56] <tjaalton> right, different from setting the initial mode
[09:07] <tjaalton> bryceh: err, patch 115 is garbage
[09:07] <tjaalton> html
[09:08] <tjaalton> well, all of the new ones are
[09:08] <tjaalton> git show ftw
[09:08] <tjaalton> and having the upstream remote to make that work
[09:20] <bryceh> bleah, I fixed that in the upload
[09:21] <tjaalton> ah, good :)
[09:21] <bryceh> this whole thing of using git for maintaining the packaging is like the most irritating thing to me
[09:22] <tjaalton> bzr is no different
[09:22] <tjaalton> or any other dvcs
[09:23] <bryceh> well it's not like we actually *use* the vcs
[09:23] <bryceh> we still have each of the patches done in quilt, so it's sort of like we're using one vcs inside another
[09:23] <RAOF> I think that's silly, yes.
[09:24] <seb128> how would you want to do it otherwise?
[09:24] <tjaalton> it would quickly become a mess
[09:24] <bryceh> I mean it's like washing the dishes before putting them in the dishwasher
[09:25] <tjaalton> though upstream patches from the branch we're following should be fine to cherry-pick as is
[09:27] <seb128> the only issue is quilt, would be much nicer if dpatch or simple-patchsys was used ;-)
[09:27] <tjaalton> bah
[09:27] <tjaalton> quilt is fine
[09:27] <seb128> I hate it
[09:27] <tjaalton> i hate dpatch, so here we go :)
[09:27] <seb128> it's so annoying to use and slow and getting in your way
[09:27] <seb128> I always forget to quilt add
[09:28] <seb128> do my changes
[09:28] <RAOF> Yeah.  That part is weird.
[09:28] <seb128> and go "ups", need to scratch the whole dir and start again
[09:28] <seb128> I'm probably too stupid to use it
[09:28] <tjaalton> or just do your stuff, git diff > foo.diff and add it to series
[09:28] <seb128> that's what I tend to do
[09:28] <seb128> so you don't use quilt :-p
[09:28] <tjaalton> unless it interferes with other patches, of course
[09:28] <seb128> I can do that with simple-patchsys too
[09:29] <bryceh> seb128, that's pretty much what I do too.
[09:29] <seb128> I tend to quilt push the change before the one I want to edit
[09:29] <seb128> and then copy the dir
[09:29] <seb128> do my change
[09:29] <seb128> and diff
[09:31] <seb128> not to mention you have to export QUILT_PATCHES to be able to edit a patch
[09:31] <tjaalton> that's in .quiltrc already ;)
[09:31] <seb128> it shows how much the thing is meant to be used to do packaging, if you don't export environment variables you need to know about it doesn't work
[09:32] <seb128> way to lower the work to start contributing
[09:32] <seb128> anyway enough rant on quilt ;-)
[09:36] <tjaalton> bryceh: funny how your commits show as merges while there were no changes to be merged, it should've been a direct push
[09:36] <tjaalton> and conflicts in changelog
[09:37] <bryceh> it's because of asac's commit
[09:38] <tjaalton> no I already had that
[09:38] <bryceh> I didn't
[09:38] <tjaalton> these were after your latest push
[09:38] <tjaalton> oh
[09:38] <tjaalton> well always git pull before you start :)
[09:38] <bryceh> see, now...
[09:39] <bryceh> #insert git rant #14
[09:39] <tjaalton> s/git/$DVCS/?
[09:39] <bryceh> tools should *save* you work, not add extra steps for no real value
[09:40] <tjaalton> oh there's valuea
[09:40] <tjaalton> -a
[09:40] <Ng> rebase \o/
[09:40] <tjaalton> now I should get that release from the queue to work on it
[09:40] <tjaalton> if it wasn't behind dvcs
[09:42] <bryceh> tjaalton, you'd have to remind me what the value was
[09:43] <bryceh> for me it's mostly just making me feel like an asshole for not pulling and pushing all the time
[09:43] <tjaalton> bryceh: it's a team effort, no other way around it
[09:45] <bryceh> tjaalton, yeah and I suck it up and do the git stuff, I still see no value in it
[09:45] <tjaalton> so it would be better to just have the archive as the version storage?
[09:46] <tjaalton> and do apt-get source; <stuff>; dput?
[09:46] <bryceh> yep
[09:46] <tjaalton> hrm :)
[09:46] <tjaalton> that's probably fine for a one-man-team :)
[09:46] <bryceh> well it's not like we do a huge amount of development on the packages
[09:47] <RAOF> If we replace that with $VCS $BRANCH ; <stuff> ; $VCS $PUSH (as source-package-branches is moving to?)
[09:47] <bryceh> tjaalton, well a lot of packages are basically just that
[09:48] <bryceh> tjaalton, or maybe one person does the merge, and another person does most of the patch work until the next merge
[09:48] <tjaalton> and I'd rather not do a merge by hand
[09:48] <tjaalton> anymore
[09:48] <bryceh> and doesn't it seem like on the packages where we *do* work together that we're constantly having to either bug someone to push a commit, or doing it for them?
[09:49] <tjaalton> things just move too fast
[09:50] <tjaalton> like having several uploads of the same package on the same day...
[09:51] <tjaalton> having to merge the changes of an upload or a few per release is a price i'm willing to pay
[09:52] <tjaalton> it's only a few minutes of work
[09:56] <mvo> seb128: edit-patch!
[09:57] <seb128> mvo, ;-)
[09:57] <seb128> I need to try that one day
[09:57] <mvo> if you hate quilt, try it next time you need to do somethingwith quilt
[09:57] <mvo> it should just work
[09:57] <mvo> (unless there are bugs of course ;)
[09:57] <seb128> cool
[09:57] <seb128> I know who to bug about bugs :p
[10:00] <mvo> hehehe
[10:00] <mvo> and it inegrates with $vcs of choice, so no more "ups, forget to bzr/git add that one"
[10:51] <Dr_Jakob> Anyway I can get the Lucid installer to either not try to update itself or get it to use a proxy to do it.
[10:56] <bryceh> Dr_Jakob, sure you have the right channel?
[10:56] <Dr_Jakob> Heh, sorry.
[14:06] <mvo> tseliot: hm, I got three warnings via debconf that I should install nvidia-current on my system (lucid -> lucid upgrade)
[14:07] <tseliot> mvo: one for nvidia-common, one for the kernel and one for the headers, I guess
[14:07] <mvo> probably
[14:08] <mvo> I assume the releae upgrader will deal with that automatically via the nvidia-common import and the nvidia.old_drivers check?
[14:08] <mvo> tseliot: or is there additional code needed?
[14:09] <tseliot> mvo: yes, update-manager should deal with that, therefore we should not get those warnings in a dist-upgrade from u-m. You would still be bugged if you updated from the command line though
[14:10] <tseliot> mvo: assuming that what I remember about update-manager is correct
[14:28] <Sarvatt> Dr_Jakob: you were right btw, archive -dbg packages for mesa and xserver are screwed up, the -dbgsym packages all work though
[14:29] <Dr_Jakob> Sarvatt: ah ok
[14:29] <Sarvatt> I was using everything from a PPA and they strip them differently there so they worked
[14:30] <Dr_Jakob> Heh okay
[14:30] <Dr_Jakob> Do I need to switch to PPA or have never versions been uploaded?
[14:30] <Dr_Jakob> well for me me the dbgsym packages where empty..
[14:30] <Sarvatt> just purge the -dbg and -dbgsym packages you might have installed and reinstall just the -dbgsym
[14:31] <Sarvatt> no reboots or anything needed that I was saying before
[14:32] <Sarvatt> its just X related packages it looks like
[14:34] <Sarvatt> http://sarvatt.com/downloads/dbgsym.py -- if you run that with say ./dbgsym.py /usr/bin/Xorg it'll tell you every dbg package with wrong CRC's
[14:35] <seb128> Sarvatt, oh, handy
[14:35] <Sarvatt> well every file in /usr/lib/debug/ with wrong CRC's that is
[14:36] <Sarvatt> i need to file a bug about this, trying to find packages that have -dbg that work right to compare the build rules
[14:36] <seb128> Sarvatt, it assumes rpm though?!
[14:36] <seb128>     dpkg_output = commands.getoutput("rpm -qf "+debug_file)
[14:37] <Dr_Jakob> Reading symbols from /usr/lib/xorg/modules/libvgahw.so...Reading symbols from /usr/lib/debug/usr/lib/xorg/modules/libvgahw.so...(no debugging symbols found)...done.
[14:37] <Sarvatt> thats just for one of the command line options
[14:37] <Dr_Jakob> Need to get 7,972B of archives.
[14:37] <Dr_Jakob> After this operation, 164kB of additional disk space will be used.
[14:37] <Dr_Jakob> dbgsym is still "empty"
[14:38] <Sarvatt> you did a sudo apt-get purge xserver-xorg-core-dbg xserver-xorg-core-dbgsym first?
[14:38] <Dr_Jakob> dbgsym wasn't installed
[14:38] <Dr_Jakob> and I removed -dbg before.
[14:38] <Sarvatt> ok I'm sorry, I swear I tested that last night
[14:39] <Sarvatt>         dh_strip -pxserver-xorg-core --dbg-package=xserver-xorg-core-dbg
[14:39] <Sarvatt>         dh_strip -s --remaining-packages
[14:39] <Sarvatt> hmm
[15:19] <Dr_Jakob> Sarvatt: sorry to ask this but do you have a ETA on when the issue would be resolved?
[15:19] <Dr_Jakob> Or should I just compile X by hand or switch to PPA?
[15:28] <herman_> hi how can I adjust the contrast of my lcd notebook, my video is an intel X4500
[15:31] <herman_> is there some software that i can do that?
[16:04] <Sarvatt> bryceh: did you see xorg-server 2:1.7.6-2ubuntu4 failed to build because of 115 still?
[16:06] <Sarvatt> Dr_Jakob: no idea on an ETA unfortunately, compiling by hand will definitely work for now, just apt-get source xorg-server, cd xorg-server-foo, sudo apt-get build-dep xorg-server then debuild -uc -us -b
[16:07] <Dr_Jakob> ok thanks
[16:12] <Sarvatt> sorry about that :( i'll let you know as soon as its fixed
[16:13] <Dr_Jakob> Right thanks.
[16:13] <Dr_Jakob> I can image things are hectic right now.
[16:14] <Dr_Jakob> Errm, it doesn't build due to what I assume is patch 115?
[16:14] <Dr_Jakob> "Patch 115_xext_fix_cursor_ref_counting.patch does not apply (enforce with -f)"
[16:14] <jcristau> kill it from debian/patches/series
[16:15] <Dr_Jakob> jcristau: thanks
[16:17] <Sarvatt> something in the build changes since 1.6.x screwed up the debug symbol extraction with pkg-create-dbgsym that creates the ddeb's - http://ddebs.ubuntu.com/pool/main/x/xorg-server/
[16:18] <jcristau> Sarvatt: would that explain that the -dbg themselves get screwed up?
[16:20] <Sarvatt> yeah it has to be pkg-create-dbgsym I believe because it works fine on PPA (where pkg-create-dbgsym is skipped) and self built packages without it installed, archive packages get run through pkg-create-dbgsym to make the ddebs and i dont think its handling the dh_strip rules right
[16:21] <Sarvatt> -dbg works fine when not run through pkg-create-dbgsym I mean
[16:21] <jcristau> ah right
[16:22] <Dr_Jakob> Sarvatt: 115, 116, 117, 118 where all broken.
[16:22] <Sarvatt> plus -dbg is screwed up in mesa as well but the ddeb from pkg-create-dbgsym work in that case, just not xorg-server
[16:23] <Sarvatt> Dr_Jakob: sorry about that, you grabbed the source for a screwed up upload thats waiting for approval to be fixed I believe
[16:24] <Dr_Jakob> ah ok
[16:25] <Sarvatt> sorry for all of the pain :)
[16:26] <Dr_Jakob> Well I still have to fix bug 545298
[16:33] <Sarvatt> ok got a bug here about the -dbg problems https://bugs.edge.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/562418
[16:36] <Dr_Jakob> ok thanks
[19:37] <jcristau> bryceh: your xorg-server commit seems to have changed nothing but changelog
[19:37] <jcristau> the "Update patches in previous upload to fix FTBS issue" one
[19:42] <bryceh> jcristau, commit b1bebad6 was the one that fixed the patches
[19:44] <jcristau> heh ok
[19:44] <jcristau> was confused when seeing that commit mail :)
[19:49] <bryceh> jcristau, yeah for as simple as the patches were I totally fucked up the upload.  Dunno why, I've been cherrypicking patches all month.
[19:53] <bdmurray> bryceh: I have had my system lock up on me 2 times today and I found this in my Xorg.1.log - http://pastebin.osuosl.org/32447
[19:55] <bryceh> bdmurray, hmm, were you able to find any other bug reports reporting that error message?
[19:56] <bdmurray> bryceh: I haven't looked in the hopes you'd had them all memorized
[19:56] <bryceh> bdmurray, it's nothing I recognize offhand
[19:57] <bdmurray> bryceh: cool, cause I was looking at the wrong log.  sorry about that
[19:58] <bryceh>             if (ioctl(xf86Info.consoleFd, VT_WAITACTIVE, xf86Info.vtno) < 0)
[19:58] <bryceh>                 FatalError("xf86OpenConsole: VT_WAITACTIVE failed: %s\n",
[19:58] <bryceh>                            strerror(errno));
[19:58] <bryceh> that's the code producing the error, it's in lnx_init.c in the xserver
[19:58] <bryceh> pretty sure we've not done any changes on the X side which would affect that code path
[19:59] <bryceh> my guess is it's something lower level than X, since it's just trying to open a VT
[20:00] <bdmurray> bryceh: that was really really old
[20:00] <bdmurray> the log I was looking at
[20:00] <bryceh> oh
[20:00] <bryceh> huh, you've got me confused.  I need coffee.
[20:01] <bdmurray> My system has exploded a couple of times today but not related to that error message
[20:02] <bryceh> ok, well see the troubleshooting docs to narrow the problem down
[20:02] <bdmurray> right its a full system lock up though I have to power cycle it
[20:03] <bryceh> kernel panic?
[20:03] <bryceh> no ssh?
[20:03] <bdmurray> yeah, no ssh and not able to ping so really probably the kernel
[20:03] <bryceh> yep
[20:04] <bryceh> X failures don't take down the network
[20:20] <tormod> bdmurray, just in general, netconsole can sometimes show some messages which otherwise do not reach the filesystem before crashes
[20:21] <bdmurray> tormod: How can I set that up?
[20:22] <tormod> bdmurray, https://wiki.ubuntu.com/KernelTeam/Netconsole
[20:22] <jcristau> Documentation/networking/netconsole.txt in the kernel source has instructions
[20:25] <bdmurray> okay this is happening right now - http://pastebin.osuosl.org/32450
[20:25] <bdmurray> I was able to ssh in this time
[20:26] <jcristau> heh, gpu reset every .04s
[20:26] <bdmurray> yeah the monitors are cycling through some garbage
[20:27] <bdmurray> Is there anything I should get before rebooting?
[20:30] <jcristau> i'd take it to #radeon
[20:30] <jcristau> they might have a clue what's going on
[20:47] <stanley_> Hi guys I am in some serious trouble here...my cursor won;t work it just froze and even after a restart won't do anything once I log into my profile...at the login screen it does, but once I log into my profile it just stops working
[20:50] <kklimonda> hey, is installation of NVIDIA X drivers from their .pkg installer supported in 10.04 yet?
[20:51] <bjsnider> no, and it won't be
[20:51] <kklimonda> thanks
[20:51] <bjsnider> that would pooch the xorg/mesa system
[20:53] <tormod> stanley_, try log in with Failsafe Terminal / session / xterm or whatever they call it
[20:54] <stanley_> ok...then do what?
[21:09] <tormod> stanley_, is your  cursor fine there?
[21:09] <stanley_> yes it is
[21:09] <stanley_> works great everywhere except when i log into my profile
[21:10] <tormod> stanley_, what graphics card and driver?
[21:11] <stanley_> I am not sure what driver, but I have an NVIDIA GeForce Go 6150 (UMA)
[21:13] <stanley_> If i log into another profile the cursor works fine...
[21:13] <stanley_> it there something I could reset in my profile to fix this or something I should reinstall?
[21:17] <tormod> stanley_, did you change Desktop Effects settings in your profile?
[21:18] <stanley_> Thanks for all your help man, it literally hasn't worked all day and I guess just decided it will start working again now
[21:23] <Sarvatt> bdmurray: what GPU? what kernel version? try booting with pci=nomsi?
[21:33] <bdmurray> Sarvatt: I've trying to report the bug to Launchpad at the moment - getting OOPses though
[21:43] <bdmurray> Sarvatt: I finally got bug 564181 reported
[21:44] <Sarvatt> yep bdmurray try booting with pci=nomsi
[21:45] <bdmurray> Sarvatt: is this specific to 2.6.32-21?
[21:48] <Sarvatt> you bug is?
[21:49] <Sarvatt> ah hah you have a XFX RV730 too
[21:49] <bdmurray> I had not seen this before this kernel.  So is the boot option specific to this kernel?
[21:50] <Sarvatt> darn the XFX rv730 quirk upstream doesn't look related - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa8450f6c93c9d4c99adfea2f52f1d02d878d5b
[21:51] <Sarvatt> if it's new to 2.6.32-21 thats definitely interesting
[21:52] <Sarvatt> the pci=nomsi probably doesn't apply, I thought that was an IGP card
[21:52] <Sarvatt> quite a bunch of those getting the same exact errors without disabling MSI
[21:53] <tormod> the MSI troubles, are they limited to x86_64?
[22:10] <bdmurray> Is there some better test case than using googleearth?
[22:11] <bdmurray> I mean is there something similar to googleearth that would be better for recreating the bug
[22:11] <jcristau> there isn't a generic "make my gpu hang" test-case i don't think :)
[22:11] <jcristau> depends on the particular bug
[22:27] <bryceh> jcristau, well there is gem_hang  ;-) ;-)
[22:27] <jcristau> hehe
[22:28] <bryceh> bdmurray, mdz did a tool which we used to help trigger freezes on intel back in jaunty/karmic you could dig up
[22:29] <bryceh> bdmurray, found it - http://launchpadlibrarian.net/25683477/repro.sh
[22:29] <bryceh> bdmurray, the use cases that script exercises may not be relevant for your particular freeze but better than nothing
[22:30] <bryceh> bdmurray, back in jaunty we used that to help make some of the freeze bugs happen faster, for verification purposes.  YMMV.
[22:31] <bdmurray> bryceh: I can make it happen very quickly!  I was just thinking that googleearth was not the most accessible test case. ;-)
[22:32] <bryceh> if it happens quickly, it's probably a decent test case
[22:33] <bryceh> sometimes a 3D game or flash website will trigger bugs in a similar way as googleearth, but like jcristau says often the hangs are pretty situational
[22:36] <bdmurray> bryceh: so would getting a gdb backtrace be useful in this case?
[22:37] <bryceh> not really
[22:37] <bryceh> freezes tend to give stack traces that just show it's stuck waiting on the gpu
[22:37] <bryceh> which is like, duh ;-)
[22:37] <bryceh> bdmurray, what generally tends to be needed is a gpu dump - see the freeze page in X/Troubleshooting 
[22:38] <bryceh> basically you run the reg dumper thingee to get a register dump, and also snag the error file from sysfs
[22:39] <jcristau> radeon has that too?
[22:39]  * jcristau is less familiar with it than with intel
[22:41] <bryceh> jcristau, yep
[22:41] <jcristau> cool
[22:42] <bryceh> jcristau, there's two tools actually, one for pre-R500 and one for R500 and newer
[22:42] <jcristau> i meant the error state in sysfs
[22:42] <bryceh> oh, that I am not sure of, I think they may not have that yet
[22:42] <jcristau> ok
[22:42] <jcristau> thanks :)
[22:42] <bryceh> at least, it's not been something I've been told to collect from people
[22:44] <bdmurray> bryceh: I don't see anything about radeon freezes on that page - https://wiki.ubuntu.com/X/Troubleshooting/Freeze
[22:45] <bryceh> page needs updated...  Well the directions are also at https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen - scan for 'Register Dumps for -ati"
[22:56] <bdmurray> bryceh: hrm, I've only been able to ssh into 1 time when it was hung
[22:58] <bryceh> bdmurray, tried with ethernet?
[22:58] <bryceh> bdmurray, when a system is frozen to the point that it's not ssh-able, it starts to smell kernel-ish
[22:59] <bryceh> but you could try sshing in and running top prior to triggering the bug, and see if the issue is caused driving the cpu load
[22:59] <bryceh> or tail -f on kernel logs to see if it issues any error messages before locking up
[23:39] <bdmurray> bryceh: I've updated the bug with the output I received from netconsole
[23:39] <bryceh> bdmurray, ok
[23:42] <bdmurray> don't get too excited!
[23:47] <bryceh> heh
[23:59] <Sarvatt> bdmurray: can you try booting with radeon.dynclks=0 added to the grub kernel command line?