[00:04] see that's a good workaround ;-) [00:04] and that let you enable 2 screens without complaining too ;-) [00:06] trying with 1700 [00:06] 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] 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] Ubuntu bug 367442 in xserver-xorg-video-openchrome "[regression] Jaunty and Intrepid screen xserver won't start" [Undecided,Confirmed] [00:12] check out the actual patch... basically the dev forgot to add braces [00:13] let's see what the original bug reporter comes back with though [00:14] mnemo: yeah that looks sane [00:14] mnemo: might be some other bugs that fixes [00:14] yup, lets keep an eye on it [00:15] have to sleep now [00:15] night [00:15] cya === cshadowrun is now known as CShadowRun [00:22] 20 min at 1700 [00:57] 1650 is good [01:15] TO whoever fixed X's dependencies on video drivers on SPARC in jaunty; thanks! [01:50] NCommander: thanks, it's so unusual to have someone come here to report the _absence_ of a bug :-) [02:21] 1612 did not freeze after 30 min, 1604 did freeze in <10 min [02:21] bryce: differences in log? [02:22] bryce, well I was planning to chance it down [02:22] bryce, something didn't get properly rebuilt on SPARC since it was trying to build in xorg-xserver-video-2 [02:22] But I tested it today, and to my suprised, I got a SPARC livefs vs. a failure message :-) [02:26] jbarnes: http://pastebin.ubuntu.com/159748/ [02:28] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392/comments/289 [02:28] Ubuntu bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] [02:29] 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] bryce, trying to run down the INtel issue? [02:30] yes [02:30] seems like I do nothing else these days but this X freeze bug... [02:31] 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] might help you narrow your search down. [02:32] 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] bryce, is there something I can do to help track it down? [02:32] 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] NCommander: for now, just add your info to - https://wiki.ubuntu.com/DesktopTeam/i965Users [02:33] NCommander: the script mentioned there is mdz's script on bug 359392, if you'd like to run that [02:33] Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] https://launchpad.net/bugs/359392 [02:34] bryce, I probably should turn greedy mode off [02:34] bryce, BTW, second tibet of info [02:34] 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] One which is active at any given time. [02:34] Might be a red hearing though [03:05] jbarnes: 1608 ran for 30 min, no freeze. 1606 froze in <1 min [03:05] wow interesting [03:06] that's really good data though [03:06] bets on 1607? [03:06] heh [03:06] isn't that the year Jamestown was founded or something? [03:07] wow, I do know my history! http://en.wikipedia.org/wiki/1607 [03:07] heh, they put that on our license plates here :) [03:08] 1607 is looking pretty good [03:09] what a weird number for it to be on [10:45] [17:08] jbarnes: increased testing overnight shows several people confirming the freezes go away with larger virtual [17:08] wow great [17:09] 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] upping the defautl should be fine [17:09] but it does give me ideas about where to look now... I'll have to come up with some debug patches though [17:11] ok cool, I'll work on a patch to up the default for now [17:53] 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] ok cool [19:08] * Ng boggles slightly [19:09] setting a larger Virtual size makes it stop crashing? :) [19:10] 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] hello [19:15] hi unamed [19:15] how are u? [19:15] Ng, s/crash/freeze/ [19:15] me, have a problem [19:15] i wrote down all infos [19:16] bryce: hmm, well it can't hurt to try I guess. Any particular size I should set? [19:16] 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] I don't know of any particular way to reproduce it :/ [19:16] Ng: my testing suggests something >1600 on my hardware [19:16] I lock/unlock and suspend/unsuspend many times each day and it happens (I would guess wildly) about once a week [19:16] unamed: if you have a precise problem, it is best to file a bug report [19:16] Ng: 2048 2048 seems like a good setting, that's what I'd recommend [19:16] ok [19:16] ta :) [19:17] Ng: as a plus, this will make projector use case work better for you :-) [19:17] heh [19:17] 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] yeah because I do a lot of presentations ;) [19:17] Ng: I'd also be very interested (and quite surprised) if it causes any problems [19:18] fwiw, the freeze we're looking at *seems* to be particular to i965 [19:22] any solutions about? [19:27] unamed: for a start, try searching for "flicker" or "video" on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel [19:27] and see if somebody with the same card has the same problem [19:27] i'm doing it [19:33] 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 03) [19:33] Subsystem: ASUSTeK Computer Inc. Device [1043:14e2] [19:33] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- [19:33] Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 [19:33] Region 0: Memory at fe900000 (64-bit, non-prefetchable) [size=1M] [19:33] Capabilities: [19:36] unamed: please don't spam the channel with logs, rather refer to your bug report [19:41] bryce: where did you post the versioning rules for x-updates? [19:45] 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] 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] tormod: maybe it'd be good to establish a wiki page on it though, I'll do that [20:18] yes, ~build1 would probably be better. Probably doesn't matter since it'd be basically the same stuff either way [20:19] tormod: I'll add to https://wiki.ubuntu.com/X/DriverBuilding - does that sound memorable enough? [20:25] looks good. one comment: debuild with or without -i or even -I.git (not consistent) [20:27] ok, I'll straighten that out [20:32] hmm [20:32] you know, if a new version is put out for Jaunty, it's going to be numbered .1 [20:32] e.g 1.2.3-1ubuntu2 -> 1.2.3-1ubuntu2.1 [20:33] 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] anyone know why X would UnloadModule evdev? [20:40] pwnguin: because the device goes away, or because Init fails [20:41] 13:35 < pwnguin> anyone know why X would UnloadModule evdev? [20:41] 13:37 -!- mvo [n=egon@p54A66B3D.dip.t-dialin.net] has quit ["Ex-Chat"] [20:41] 13:40 < jcristau> pwnguin: because the device goes away, or because Init fails [20:41] doh [20:41] damn irssi [20:43] (see xf86NewInputDevice there's a number of things that can go wrong) [20:44] bryce: or even 1.2.3-1ubuntu2.0~xup~1 so there's less confusion [20:45] yeah [20:45] but why that ~1 after xup ? [20:50] bryce: should we consider for instance the latest libdrm crash fix for x-updates, or only wait for new releases? [20:50] ah, that's because if we need to put out an update to our update, we can increment that number to supersede [20:50] I like ~xup~1 better than ~xup1 simply for clarity [20:50] then xup, xup1 xup2 etc would work as well [20:51] oh clarity [20:51] in general I would wait for new releases only [20:52] 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] but we can play it by ear [20:52] okdok [20:52] ultimately it's going to be driven by what we actually end up having time for [20:55] right. it would probably be tempting to neglect SRU's and ask people to use x-updates, much less paper-work :p [20:57] we can also test SRU fixes in x-updates [20:58] scratch that, would make SRU even more painfull [20:58] right [20:58] also in general we will be carrying newer versions of drivers, for which SRUs would not apply anyway [20:58] good point [20:59] - 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] (indeed, this was my main motivation in setting this up) [21:01] and to silence those people crying for newer versions and why Ubuntu release policy sucks etc :) [21:02] maybe we should use the "backports" repo more, also for X stuff, at least those without dependency issues? [21:03] well, I've given that some thought [21:03] looking at past releases of backports I notice a distinct lack of X packages [21:04] so there's some pros and cons [21:04] 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] 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] so I am kind of leaning at this point towards the idea of x-updates being sort of a parallel to -backports [21:05] 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] Ubuntu bug 368004 in apport "apport-collect crashes for certain dates/locales" [Undecided,New] [21:05] on the other hand, it is certainly possible to pin packages... but would people want to do that? [21:06] bryce: are you or pitti maintaining the xorg hook for apport btw? [21:06] mnemo: erk [21:06] mnemo: I am maintaining the xorg hook, but if it is crashing he might be the better one to investigate [21:07] 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] aha I recognize that error [21:07] that's in apport-collect code [21:07] it is a unicode error, and means that there was a non-ascii character in the bug report, that crashes apport [21:08] I run into that type of bug a LOT with my arsenal (auto-bug-triage) scripts [21:08] heh right [21:09] in this case it looks like it was a filename that had the bad character [21:10] anyway, something pitti will have to fix [21:10] thanks for letting me know about it though [21:10] I wish launchpadlib handled this type of thing better [21:10] yea [21:11] 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] 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 === seb128_ is now known as seb128 [23:36] bryce: nice comment on the intel perf bug :) [23:37] oh, thanks