=== cjwatson_ is now known as cjwatson
[12:51] <tzanger> I'm trying to debug an X crash on resume with 2.6.31 on 9.04 (intel 2.7.1 driver on a GM or GL960) -- VBE is not posting on resume (checked pm-suspend.log) but not sure where to go from here. suspend is fine, as sometimes when I resume it takes a few seconds for X to die and I can see y screen as it was when I suspended
[13:08]  * Ng wishes X would refuse to let me move my mouse pointer into areas of the virtual display which aren't part of a physical display
[13:09] <Ng> but I suspect that all falls down for weird setups where there is a gap between physical displays :(
[13:25] <virtuald> will radeon get default modesetting? i haven't seen any problems with it but you might know more. 
[13:37] <tseliot> virtuald: not in karmic
[13:38] <Kano> hi, did anybody run top on a live image?
[13:39] <Kano> i have got 100% load with nvidia gfx card and 32 bit intel
[13:39] <Kano> for one core with Xorg
[13:39] <Kano> that kills vt switching too
[13:40] <Kano> anybody else with that problem?
[13:52] <tseliot> Kano: with nvidia or nv?
[14:02] <tzanger> I'm trying to debug an X crash on resume with 2.6.31 on 9.04 (intel 2.7.1 driver on a GM or GL960) -- VBE is not posting on resume (checked pm-suspend.log) but not sure where to go from here. suspend is fine, as sometimes when I resume it takes a few seconds for X to die and I can see y screen as it was when I suspended
[14:04] <tseliot> tzanger: is this with KMS enabled?
[14:04] <tzanger> what's KMS?
[14:04] <tzanger> kernel mode selection?
[14:04] <tseliot> kernel mode settings
[14:04] <tzanger> I don't think so
[14:04] <Kano> tseliot: nv, nvidia binary is fine
[14:04] <tzanger> how may I check it?
[14:04] <tseliot> tzanger: can you reproduce the problem in Karmic?
[14:05] <tzanger> tseliot: haven't tried, I would prefer not to do a dist-upgrade and end up with the same issue
[14:05] <tseliot> Kano: can I see your /var/log/Xorg.0.log?
[14:05] <tjaalton> tzanger: that's why we have livecd's
[14:06] <tseliot> tzanger: suspend/resume is extremely fast with KMS
[14:06] <tzanger> tjaalton: good point; I never woul dhave thought to try suspend with a live cd
[14:06] <tzanger> tseliot: hmm, it's not extremely fast... several (5-6) seconds
[14:07] <tseliot> tzanger: it's very fast on my netbook with KMS on Karmic
[14:07] <tjaalton> jaunty didn't have intel kms
[14:07]  * tseliot nods
[14:08] <Kano> tjaalton: why has your paste.u.c no upload feature?
[14:08] <jcristau> why do you think #ubuntu-x has anything to do with it?
[14:09] <Kano> tjaalton: the intel onboard system: http://paste.debian.net/47753
[14:09] <Kano> you get the failed entries when you try vt switch
[14:12] <Kano> tseliot: thats nvidia: http://paste.ubuntu.com/281287/
[14:13] <Kano> nfsboot
[14:13] <tjaalton> haven't seen that
[14:13] <tseliot> Kano: maybe it's worth seeing dmesg too
[14:14] <Kano> nothing special in dmesg
[14:14] <Kano> no permanent errors or so
[14:19] <Kano> ps aux |grep bin/X is more interesting
[14:20] <Kano> http://paste.debian.net/47755
[14:20] <Kano> do you see the line with 99.5
[14:20] <Kano> thats the same on both
[14:21]  * tseliot has a look
[14:21] <Kano> root      1943 99.5  0.8  68608 21972 ?        Rs   12:38  41:43 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-v2qsYS/database -nolisten tcp vt7
[14:21] <Kano> thats a bit extreme
[14:22] <jcristau> attach gdb, see where it's spinning?
[14:22] <Kano> how to do so?
[14:22] <tseliot> https://wiki.ubuntu.com/X/Backtracing
[14:24] <Kano> well x is still running, it is not crashed
[14:27] <jcristau> Kano: ssh, gdb -p $(pidof X), bt
[14:31] <Kano> http://paste.debian.net/47756/
[14:32] <Kano> anything else?
[14:34] <jcristau> do that a few times
[14:34] <Kano> always the same
[14:34] <jcristau> ok.
[14:34] <Kano> well not when i quit gdb
[14:34] <Kano> then i get something else some times
[14:35] <jcristau> ah.
[14:35] <Kano> http://paste.debian.net/47757/
[14:37] <Kano> http://paste.debian.net/47758/
[14:38] <Kano> is that wait for something busy wait?
[14:38] <jcristau> no, it's the loop around select()
[14:39] <Kano> well a loop without wait will result in 100% load
[14:42] <jcristau> you know what select() is, right?
[14:42] <Kano> no ;)
[14:42] <Kano> but i see the load, not on your system?
[14:43] <Kano> interestingly with intel onboard 64 bit it does not happen
[14:43] <Kano> with nv there is no diff
[17:25] <tseliot> freedesktop-bugs #22893
[17:25] <ubottu> Launchpad bug 22893 in screem "Screem hangs when editing php file." [Medium,Invalid] https://launchpad.net/bugs/22893
[23:22] <tormod> for those not on the ML: https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000630.html
[23:34] <bryce> tormod, thanks
[23:34] <bryce> tormod, yeah alberto mentioned 2.9.0 to me too
[23:35] <bryce> once I'm back from leave I'll add them in.  I figure since we're close to beta release, we ought to wait until post-beta-freeze anyway
[23:35] <bryce> we may need a FFe for -intel
[23:36] <tormod> seems like upstream makes releases now in the hope of getting them into the coming distro releases, so it would be a pity not to...
[23:36] <tormod> yes karmic is really frozen for beta now
[23:36] <bryce> there's also new libdrm and xorg-server 1.6.4 that could be worth pulling
[23:36] <tormod> hold on a bit for 1.6.4 , there are dga issues
[23:36] <jcristau> 1.6.4 is broken
[23:36] <bryce> ah, shame
[23:36] <albert23> Didn't the desktop meeting decide not to update?
[23:36] <jcristau> but, should be fixed soon
[23:36] <albert23> rickspencer3so we are agreed, the karmic X stack today is the Karmic X stack we will ship with, modulo any blockers found by users in the beta?
[23:37] <bryce> oh heh
[23:37] <tormod> bryce, are you in the desktop meetings?
[23:37] <bryce> yeah I've been on leave so am not up to speed on decisions made at recent meetings
[23:37] <albert23> this was today
[23:38] <bryce> s/I've been on leave/I am on leave until the 1st/
[23:38] <tormod> are there any X people in this desktop meetings?
[23:38] <albert23> Today was tseliot
[23:39] <bryce> right
[23:39] <jcristau> well i think it'd make sense to update at least the server from the stable branch, and mesa from a random snapshot to the release :)
[23:40] <tormod> +1
[23:43] <bryce> is libdrm 2.4.14 safe/worthwhile?
[23:43] <tormod> seems safe
[23:45] <tormod> some chipsets added for intel, some 64-bit fix for radeon, and a memory leak
[23:47] <tormod> bryce, in any case, the 2.4.14 in xorg-edgers should be a pretty clean package
[23:49] <bryce> ok
[23:50] <bryce> I talked to jbarnes last week and he advocates -intel 2.9.0... says it's mostly bug fixes.  There's been some 8xx fixes upstream that I'd really like to see included in Karmic
[23:51] <bryce> but I'll have to check with Rick as per today's meeting
[23:52] <albert23> For 865 you would also need a kernel fix from 2.6.32 (agp/intel: Fix the pre-9xx chipset flush.)
[23:53] <bryce> albert23, ah good to know - can you file a bug about that and subscribe me to it?  I'll follow up and make sure it gets in.
[23:54] <albert23> it's bug 407793
[23:54] <ubottu> Launchpad bug 407793 in xserver-xorg-video-intel "[i865g][Karmic Alpha 3] X corruption and freeze when clicking "Other" on GDM login screen" [High,Triaged] https://launchpad.net/bugs/407793
[23:55] <bryce> ok thanks
[23:55] <albert23> Did you register your son on LP?
[23:55] <bryce> yep
[23:56] <tormod> bryce, congratulations with your "release" by the way :)
[23:56] <bryce> :-) thanks
[23:57] <RAOF> Congratulations!
[23:57] <bryce> albert23, ok I stuck it on the kernel team's todo list.  Likely should be pulled now, but let me know if it looks stuck or something
[23:58] <albert23> thanks