[00:04] <seb128> see that's a good workaround ;-)
[00:04] <seb128> and that let you enable 2 screens without complaining too ;-)
[00:06] <bryce> trying with 1700
[00:06] <bryce> I notice that either it seems to "work really well" or "slow down and freeze in 10 min"...  it sort of feels like maybe there's a magic number
[00:12] <mnemo> bryce: i might have identified a potentially cherry pick for openchrome today --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/367442
[00:12] <mnemo> check out the actual patch... basically the dev forgot to add braces
[00:13] <mnemo> let's see what the original bug reporter comes back with though
[00:14] <bryce> mnemo: yeah that looks sane
[00:14] <bryce> mnemo: might be some other bugs that fixes
[00:14] <mnemo> yup, lets keep an eye on it
[00:15] <mnemo> have to sleep now
[00:15] <mnemo> night
[00:15] <bryce> cya
[00:22] <bryce> 20 min at 1700
[00:57] <bryce> 1650 is good
[01:15] <NCommander> TO whoever fixed X's dependencies on video drivers on SPARC in jaunty; thanks!
[01:50] <bryce> NCommander: thanks, it's so unusual to have someone come here to report the _absence_ of a bug :-)
[02:21] <bryce> 1612 did not freeze after 30 min, 1604 did freeze in <10 min
[02:21] <jbarnes> bryce: differences in log?
[02:22] <NCommander> bryce, well I was planning to chance it down
[02:22] <NCommander> bryce, something didn't get properly rebuilt on SPARC since it was trying to build in xorg-xserver-video-2
[02:22] <NCommander> But I tested it today, and to my suprised, I got a SPARC livefs vs. a failure message :-)
[02:26] <bryce> jbarnes: http://pastebin.ubuntu.com/159748/
[02:28] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392/comments/289
[02:29] <bryce> running 1608 now... judging from its fast performance it looks like it's going to be a non-freeze case, but I'll give it an hour
[02:30]  * jbarnes looks at tiling restrictions for 965
[02:30] <NCommander> bryce, trying to run down the INtel issue?
[02:30] <bryce> yes
[02:30] <bryce> seems like I do nothing else these days but this X freeze bug...
[02:31] <NCommander> bryce, handy tip; this is in a bug report somewhere, but flipping greedy mode on Intel made all freezes + slowness go away
[02:31]  * NCommander has an affected card.
[02:31] <NCommander> might help you narrow your search down.
[02:32] <bryce> actually I already know of a lot of different settings that can make the freeze go *away*... but I'm looking for the root cause
[02:32] <NCommander> bryce, is there something I can do to help track it down?
[02:32] <bryce> but thanks.  I'll put it on my todo list to play with.  We already know greedy probably wouldn't be sru-able
[02:33] <bryce> NCommander: for now, just add your info to - https://wiki.ubuntu.com/DesktopTeam/i965Users
[02:33] <bryce> NCommander: the script mentioned there is mdz's script on bug 359392, if you'd like to run that
[02:34] <NCommander> bryce, I probably should turn greedy mode off
[02:34] <NCommander> bryce, BTW, second tibet of info
[02:34] <NCommander> I got the freezes while the INtel driver was loaded, but not in use
[02:34]  * NCommander has two video cards on my laptop
[02:34] <NCommander> One which is active at any given time.
[02:34] <NCommander> Might be a red hearing though
[03:05] <bryce> jbarnes: 1608 ran for 30 min, no freeze.  1606 froze in <1 min
[03:05] <jbarnes> wow interesting
[03:06] <jbarnes> that's really good data though
[03:06] <bryce> bets on 1607?
[03:06] <jbarnes> heh
[03:06] <bryce> isn't that the year Jamestown was founded or something?
[03:07] <bryce> wow, I do know my history!  http://en.wikipedia.org/wiki/1607
[03:07] <crdlb> heh, they put that on our license plates here :)
[03:08] <bryce> 1607 is looking pretty good
[03:09] <bryce> what a weird number for it to be on
[10:45] <james_w>  
[17:08] <bryce> jbarnes: increased testing overnight shows several people confirming the freezes go away with larger virtual 
[17:08] <jbarnes> wow great
[17:09] <bryce> jbarnes: would it be crazy if we just upped the default virtual for i965?  Or does this give you other ideas we could try instead?
[17:09] <jbarnes> upping the defautl should be fine
[17:09] <jbarnes> but it does give me ideas about where to look now... I'll have to come up with some debug patches though
[17:11] <bryce> ok cool, I'll work on a patch to up the default for now
[17:53] <bryce> jbarnes: colin king emailed me with questions on the perf patches, I gave him what I knew and suggested he get in contact with you for further details
[17:54] <jbarnes> ok cool
[19:08]  * Ng boggles slightly
[19:09] <Ng> setting a larger Virtual size makes it stop crashing? :)
[19:10] <Ng> would that likely help with odd random lockups? I think about once a week I get a total system hang when I unlock my laptop (so the display will be off and it dies before that gets woken up), or is this just the crash while it's in use that the workspace-changing script reproduces?
[19:12] <unamed> hello
[19:15] <bryce> hi unamed
[19:15] <unamed> how are u?
[19:15] <bryce> Ng, s/crash/freeze/
[19:15] <unamed> me, have a problem
[19:15] <unamed> i wrote down all infos
[19:16] <Ng> bryce: hmm, well it can't hurt to try I guess. Any particular size I should set?
[19:16] <bryce> Ng: we don't yet know how extensive of freezes that are solved for having the higher virtual.  if you can reproduce your system hang easily, give it a try
[19:16] <Ng> I don't know of any particular way to reproduce it :/
[19:16] <bryce> Ng: my testing suggests something >1600 on my hardware
[19:16] <Ng> I lock/unlock and suspend/unsuspend many times each day and it happens (I would guess wildly) about once a week
[19:16] <tormod> unamed: if you have a precise problem, it is best to file a bug report
[19:16] <bryce> Ng: 2048 2048 seems like a good setting, that's what I'd recommend
[19:16] <Ng> ok
[19:16] <Ng> ta :)
[19:17] <bryce> Ng: as a plus, this will make projector use case work better for you :-)
[19:17] <Ng> heh
[19:17] <unamed> I got Asus x58-l with GM965 X3100 with Linux Kubuntu 9.04 and xserver... intel with 2,4 or 2,6.3 (problem still the same) and under this configuration the videos is flickering
[19:17] <Ng> yeah because I do a lot of presentations ;)
[19:17] <bryce> Ng: I'd also be very interested (and quite surprised) if it causes any problems
[19:18] <bryce> fwiw, the freeze we're looking at *seems* to be particular to i965
[19:22] <unamed> any solutions about?
[19:27] <tormod> unamed: for a start, try searching for "flicker" or "video" on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel
[19:27] <tormod> and see if somebody with the same card has the same problem
[19:27] <unamed> i'm doing it
[19:33] <unamed> 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 03)
[19:33] <unamed>         Subsystem: ASUSTeK Computer Inc. Device [1043:14e2]                                                                
[19:33] <unamed>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-              
[19:33] <unamed>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-               
[19:33] <unamed>         Latency: 0                                                                                                         
[19:33] <unamed>         Region 0: Memory at fe900000 (64-bit, non-prefetchable) [size=1M]                                                  
[19:33] <unamed>         Capabilities: <access denied> 
[19:36] <tormod> unamed: please don't spam the channel with logs, rather refer to your bug report
[19:41] <tormod> bryce: where did you post the versioning rules for x-updates?
[19:45] <tormod> it was not in the ML but maybe on the PPA page previously? Well the question is the Debian syncs. Why "build1", isn't ~build1 better, in case there's an official sync later?
[20:17] <bryce> tormod: I had posted the naming rules to the ppa itself, but removed them since I thought it added clutter that might confuse/scare users
[20:17] <bryce> tormod: maybe it'd be good to establish a wiki page on it though, I'll do that
[20:18] <bryce> yes, ~build1 would probably be better.  Probably doesn't matter since it'd be basically the same stuff either way
[20:19] <bryce> tormod: I'll add to https://wiki.ubuntu.com/X/DriverBuilding - does that sound memorable enough?
[20:25] <tormod> looks good. one comment: debuild with or without -i or even -I.git (not consistent)
[20:27] <bryce> ok, I'll straighten that out
[20:32] <bryce> hmm
[20:32] <bryce> you know, if a new version is put out for Jaunty, it's going to be numbered .1
[20:32] <bryce> e.g 1.2.3-1ubuntu2 -> 1.2.3-1ubuntu2.1
[20:33] <bryce> so I wonder if the correct version for an xup package would be 1.2.3-1ubuntu2.1~xup~1 rather than 1.2.3-1ubuntu3~xup~1
[20:35] <pwnguin> anyone know why X would UnloadModule evdev?
[20:40] <jcristau> pwnguin: because the device goes away, or because Init fails
[20:41] <pwnguin> 13:35 < pwnguin> anyone know why X would UnloadModule evdev?
[20:41] <pwnguin> 13:37 -!- mvo [n=egon@p54A66B3D.dip.t-dialin.net] has quit ["Ex-Chat"]
[20:41] <pwnguin> 13:40 < jcristau> pwnguin: because the device goes away, or because Init fails
[20:41] <pwnguin> doh
[20:41] <pwnguin> damn irssi
[20:43] <jcristau> (see xf86NewInputDevice there's a number of things that can go wrong)
[20:44] <tormod> bryce: or even 1.2.3-1ubuntu2.0~xup~1 so there's less confusion
[20:45] <bryce> yeah
[20:45] <tormod> but why that ~1 after xup ?
[20:50] <tormod> bryce: should we consider for instance the latest libdrm crash fix for x-updates, or only wait for new releases?
[20:50] <bryce> ah, that's because if we need to put out an update to our update, we can increment that number to supersede
[20:50] <bryce> I like ~xup~1 better than ~xup1 simply for clarity
[20:50] <tormod> then xup, xup1 xup2 etc would work as well
[20:51] <tormod> oh clarity
[20:51] <bryce> in general I would wait for new releases only
[20:52] <bryce> if a crash fix is really important and worth putting out to users, then it probably makes more sense to put it out as an SRU
[20:52] <bryce> but we can play it by ear
[20:52] <tormod> okdok
[20:52] <bryce> ultimately it's going to be driven by what we actually end up having time for
[20:55] <tormod> right. it would probably be tempting to neglect SRU's and ask people to use x-updates, much less paper-work :p
[20:57] <tormod> we can also test SRU fixes in x-updates
[20:58] <tormod> scratch that, would make SRU even more painfull
[20:58] <bryce> right
[20:58] <bryce> also in general we will be carrying newer versions of drivers, for which SRUs would not apply anyway
[20:58] <tormod> good point
[20:59] <bryce> - however - it can be useful if we think a fix went in upstream in the newer release, to have them test it, before we go through trying to cherrypick out the fix
[20:59] <bryce> (indeed, this was my main motivation in setting this up)
[21:01] <tormod> and to silence those people crying for newer versions and why Ubuntu release policy sucks etc :)
[21:02] <tormod> maybe we should use the "backports" repo more, also for X stuff, at least those without dependency issues?
[21:03] <bryce> well, I've given that some thought
[21:03] <bryce> looking at past releases of backports I notice a distinct lack of X packages
[21:04] <bryce> so there's some pros and cons
[21:04] <bryce> on the pro side, I think -backports is more widely known, so this would distribute new drivers to a wider array of people
[21:05] <bryce> on the con side, it adds an unknown amount of risk of causing breakage to people who e.g. just want newer apps, and don't want drivers changing out from under them
[21:05] <bryce> so I am kind of leaning at this point towards the idea of x-updates being sort of a parallel to -backports
[21:05] <mnemo> bryce: just fyi... i've been asking some people to run apport-collect for jaunty bugs... and it seems that this script itself actually crashes for a significant number of users... i've collected some info on these errors here: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/368004
[21:05] <bryce> on the other hand, it is certainly possible to pin packages... but would people want to do that?
[21:06] <mnemo> bryce: are you or pitti maintaining the xorg hook for apport btw?
[21:06] <bryce> mnemo: erk
[21:06] <bryce> mnemo: I am maintaining the xorg hook, but if it is crashing he might be the better one to investigate
[21:07] <mnemo> i've shown him the bug and he said he put it on this todo list, but I just wanted to mention it here as well so it's not forgotten
[21:07] <bryce> aha I recognize that error
[21:07] <bryce> that's in apport-collect code
[21:07] <bryce> it is a unicode error, and means that there was a non-ascii character in the bug report, that crashes apport
[21:08] <bryce> I run into that type of bug a LOT with my arsenal (auto-bug-triage) scripts
[21:08] <mnemo> heh right
[21:09] <bryce> in this case it looks like it was a filename that had the bad character
[21:10] <bryce> anyway, something pitti will have to fix
[21:10] <bryce> thanks for letting me know about it though
[21:10] <bryce> I wish launchpadlib handled this type of thing better
[21:10] <mnemo> yea
[21:11] <bryce> tormod: in any case, if later we decide to push stuff into -backports, I figure x-updates gives us fertile ground to pull from
[21:11] <bryce> tormod: I don't have any plans to pursue this idea, but if anyone else is interested in feeding stuff into -backports, go for it
[23:36] <mnemo> bryce: nice comment on the intel perf bug :)
[23:37] <bryce> oh, thanks