| seb128 | see that's a good workaround ;-) | 00:04 |
|---|---|---|
| seb128 | and that let you enable 2 screens without complaining too ;-) | 00:04 |
| 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:06 |
| 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 |
| ubottu | Ubuntu bug 367442 in xserver-xorg-video-openchrome "[regression] Jaunty and Intrepid screen xserver won't start" [Undecided,Confirmed] | 00:12 |
| mnemo | check out the actual patch... basically the dev forgot to add braces | 00:12 |
| mnemo | let's see what the original bug reporter comes back with though | 00:13 |
| 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:14 |
| mnemo | have to sleep now | 00:15 |
| mnemo | night | 00:15 |
| bryce | cya | 00:15 |
| === cshadowrun is now known as CShadowRun | ||
| bryce | 20 min at 1700 | 00:22 |
| bryce | 1650 is good | 00:57 |
| NCommander | TO whoever fixed X's dependencies on video drivers on SPARC in jaunty; thanks! | 01:15 |
| bryce | NCommander: thanks, it's so unusual to have someone come here to report the _absence_ of a bug :-) | 01:50 |
| bryce | 1612 did not freeze after 30 min, 1604 did freeze in <10 min | 02:21 |
| jbarnes | bryce: differences in log? | 02:21 |
| 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:22 |
| bryce | jbarnes: http://pastebin.ubuntu.com/159748/ | 02:26 |
| bryce | https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392/comments/289 | 02:28 |
| ubottu | Ubuntu bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] | 02:28 |
| 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:29 |
| * 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ubottu | Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] https://launchpad.net/bugs/359392 | 02:33 |
| 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 | 02:34 |
| bryce | jbarnes: 1608 ran for 30 min, no freeze. 1606 froze in <1 min | 03:05 |
| jbarnes | wow interesting | 03:05 |
| 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:06 |
| 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:07 |
| bryce | 1607 is looking pretty good | 03:08 |
| bryce | what a weird number for it to be on | 03:09 |
| james_w | 10:45 | |
| bryce | jbarnes: increased testing overnight shows several people confirming the freezes go away with larger virtual | 17:08 |
| jbarnes | wow great | 17:08 |
| 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:09 |
| bryce | ok cool, I'll work on a patch to up the default for now | 17:11 |
| 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:53 |
| jbarnes | ok cool | 17:54 |
| * Ng boggles slightly | 19:08 | |
| Ng | setting a larger Virtual size makes it stop crashing? :) | 19:09 |
| 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:10 |
| unamed | hello | 19:12 |
| 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:15 |
| 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:16 |
| 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:17 |
| bryce | fwiw, the freeze we're looking at *seems* to be particular to i965 | 19:18 |
| unamed | any solutions about? | 19:22 |
| 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:27 |
| 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:33 |
| tormod | unamed: please don't spam the channel with logs, rather refer to your bug report | 19:36 |
| tormod | bryce: where did you post the versioning rules for x-updates? | 19:41 |
| 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? | 19:45 |
| 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:17 |
| bryce | yes, ~build1 would probably be better. Probably doesn't matter since it'd be basically the same stuff either way | 20:18 |
| bryce | tormod: I'll add to https://wiki.ubuntu.com/X/DriverBuilding - does that sound memorable enough? | 20:19 |
| tormod | looks good. one comment: debuild with or without -i or even -I.git (not consistent) | 20:25 |
| bryce | ok, I'll straighten that out | 20:27 |
| 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:32 |
| 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:33 |
| pwnguin | anyone know why X would UnloadModule evdev? | 20:35 |
| jcristau | pwnguin: because the device goes away, or because Init fails | 20:40 |
| 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:41 |
| jcristau | (see xf86NewInputDevice there's a number of things that can go wrong) | 20:43 |
| tormod | bryce: or even 1.2.3-1ubuntu2.0~xup~1 so there's less confusion | 20:44 |
| bryce | yeah | 20:45 |
| tormod | but why that ~1 after xup ? | 20:45 |
| 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:50 |
| tormod | oh clarity | 20:51 |
| bryce | in general I would wait for new releases only | 20:51 |
| 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:52 |
| tormod | right. it would probably be tempting to neglect SRU's and ask people to use x-updates, much less paper-work :p | 20:55 |
| tormod | we can also test SRU fixes in x-updates | 20:57 |
| 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:58 |
| 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) | 20:59 |
| tormod | and to silence those people crying for newer versions and why Ubuntu release policy sucks etc :) | 21:01 |
| tormod | maybe we should use the "backports" repo more, also for X stuff, at least those without dependency issues? | 21:02 |
| 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:03 |
| 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:04 |
| 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 |
| ubottu | Ubuntu bug 368004 in apport "apport-collect crashes for certain dates/locales" [Undecided,New] | 21:05 |
| bryce | on the other hand, it is certainly possible to pin packages... but would people want to do that? | 21:05 |
| 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:06 |
| 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:07 |
| bryce | I run into that type of bug a LOT with my arsenal (auto-bug-triage) scripts | 21:08 |
| mnemo | heh right | 21:08 |
| bryce | in this case it looks like it was a filename that had the bad character | 21:09 |
| 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:10 |
| 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 | 21:11 |
| === seb128_ is now known as seb128 | ||
| mnemo | bryce: nice comment on the intel perf bug :) | 23:36 |
| bryce | oh, thanks | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!