| Sarvatt | ok, fglrx + preempt kernel = recipe for disaster | 01:16 |
|---|---|---|
| bryceh | Sarvatt, erf | 01:23 |
| bryceh | Sarvatt, is it supposed to work? | 01:23 |
| Sarvatt | kas_spin_lock is totally not preempt safe - http://launchpadlibrarian.net/43764353/OopsText.txt | 01:23 |
| Sarvatt | sheesh, pains me when I see people using -preempt on a laptop, I hope they never leave the ac adapter :) | 01:32 |
| Sarvatt | -preempt uses just under 10 watts more idling for one of my machines, constant 1000+ wakeups/second in powertop | 01:36 |
| Sarvatt | bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/542925 -- attached a debdiff if its not too late to get the fix in | 01:57 |
| ubottu | Launchpad bug 542925 in xserver-xorg-video-ati "[RN50] mpg files no video or audio on ATI ES1000" [Medium,Triaged] | 01:57 |
| bryceh | Sarvatt, thanks, I'll take a look at it tomorrow | 02:02 |
| bryceh | (I'm about to run out for the evening) | 02:03 |
| bryceh | actually, maybe I can beg a few minutes from the wife | 02:03 |
| RAOF | Have fun! | 02:03 |
| bryceh | (date night; gonna go see that hot tub time machine movie) | 02:04 |
| bryceh | Sarvatt, uploaded | 02:09 |
| Sarvatt | woohoo thanks, enjoy the worst named movie ever :) | 02:09 |
| bryceh | Sarvatt, RAOF, yeah we can take fixes through to Thursday, and then after release we can do SRU's | 02:09 |
| bryceh | so keep the debdiff's flowin' :-) | 02:10 |
| RAOF | :) | 02:11 |
| bjsnider | what is a debdiff? | 02:20 |
| bjsnider | i know what a diff is | 02:20 |
| virtuald | a diff to a debian source tree | 02:20 |
| virtuald | i think | 02:20 |
| bjsnider | how would one go about making such a diff? | 02:22 |
| RAOF | With the “debdiff” tool; basically, you make a new candidate package, and debdiff produces the diff between the current package and the new package. | 02:23 |
| bjsnider | coolio | 02:24 |
| bjsnider | then what do you do with it? | 02:24 |
| RAOF | Attach it to the bug it's meant to fix, generally. | 02:25 |
| Sarvatt | sheesh, that was painful.. took almost 2 hours to update a days worth of packages in fedora from a raawhide livecd snapshot from april 11th. all of this new DRI2 stuff in xserver 1.8 sure does kill performance, I want my tearing back :) | 04:49 |
| RAOF_ | Do we have anyone here capable of sponsoring an -intel package to break 3D on lots of user's hardware? :/ | 08:06 |
| bryceh | RAOF_, yes | 08:10 |
| bryceh | RAOF_, well if it's ready soonish; I'm about to hit the sack | 08:11 |
| hyperair | RAOF_: to break 3D on lots of users' hardware? why? | 08:13 |
| bryceh | hyperair, 8xx I assume | 08:14 |
| hyperair | eh? | 08:14 |
| bryceh | well, it's sack-hitting time. night | 08:19 |
| RAOF | Bah. Sorry bryceh. | 08:47 |
| Mirv | bryceh: woohaa. I just found out the intel slowdown thing I mentioned might be a bug in the ondemand CPU throttler instead. I happened to suspect something fishy once again and added CPU applet to GNOME panel... | 09:14 |
| Mirv | with ondemand I get 2-3 times slower performance in gtkperf than with forced clock speed. the 2-3 depends on whether straight after boot or later. | 09:16 |
| Sarvatt | RAOF: what intel patch? the cliprects one? | 16:25 |
| apw | Sarvatt, bryceh ... what is your feeling on the patches from RAOF to disable acceleration for various nouveau chipsets? if we want them in the release i need to commit them now, but it isn't 100% clear that they have been tested by those afffected; they have indicated nouveau.noaccel=1 works for them but not used a patched kernel | 16:33 |
| apw | i believe the symptoms are not booting without them | 16:33 |
| Sarvatt | apw: it's very much needed, I haven't looked over the patches though. they haven't been tested? | 16:35 |
| apw | its not clear they _have_ been tested is a better position | 16:35 |
| apw | the users appear to have said that they used noaccel on the kernel command line | 16:35 |
| apw | and the patches look like they do that at least | 16:35 |
| apw | Sarvatt, do you have any of the affected h/w as i do have test kernels | 16:36 |
| Sarvatt | have they been booted on machines that dont have quirks to see if it works right otherwise at least? | 16:36 |
| apw | or indeed any nouveau h/w that isn't on the list | 16:36 |
| apw | i don't have any nvidia h/w so i can't say i know it has been booted either way | 16:36 |
| apw | hense my concern :) | 16:36 |
| Sarvatt | apw: I wont be able to test it for probably 6 more hours or so until I get off of work | 16:37 |
| apw | http://people.canonical.com/~apw/raof-nv-accel-lucid/ | 16:37 |
| Sarvatt | can ya link a kernel? | 16:37 |
| Sarvatt | thanks, will try it ASAP | 16:37 |
| apw | pretty much need to made a decision 'now' to hit the deadlines for freeze | 16:37 |
| apw | the patches are in the same directory | 16:38 |
| Sarvatt | anyone here using nouveau that can test a kernel really fast? :) | 16:38 |
| apw | Sarvatt, my feeling is that if it boots and doesn't explode on any nvidia h/w its better to have it than now | 16:39 |
| Sarvatt | yeah agreed | 16:39 |
| apw | not ... as it makes people boot (assuming it matches correctly) and if it does not ... then they still boot and they can get an update | 16:39 |
| apw | but having stopped all thinkpad booting once this week, i am nurvous about any not known tested code | 16:40 |
| Sarvatt | i couldn't figure out why that works on 2.6.34 and not our kernel, I think its our battery patch actually | 16:41 |
| Sarvatt | the async one | 16:41 |
| Sarvatt | hmm yeah the nouveau patches *look* fine to me | 16:42 |
| apw | Sarvatt, i thought that too, the first thing i did was back out the battery async patch | 16:42 |
| apw | no effect. it was related to a couple of bugs in the replacement code in part | 16:42 |
| apw | at least for thinkpads, however even with that fixed it still kills mac pros and i don't yet know why | 16:43 |
| Sarvatt | trying to switch to nouveau and reboot into that kernel remotely, i'm so glad jockey-text exists now :) | 16:50 |
| Sarvatt | darn one of my other laptops has a 10de:0244 but 10de:0242 is quirked | 16:53 |
| Sarvatt | apw: working fine here | 16:59 |
| Sarvatt | on a machine not quirked | 16:59 |
| apw | Sarvatt, well thats something at least | 16:59 |
| Sarvatt | sudo cat /sys/module/nouveau/parameters/noaccel | 16:59 |
| Sarvatt | 0 | 16:59 |
| Sarvatt | worst case is it breaks the 3 quirked chipsets that were already broken I'd guess :D | 17:01 |
| apw | Sarvatt, i have two other non-quirked confirmations for the patches | 17:21 |
| * apw pokes bryceh | 17:21 | |
| bryceh | apw, yep | 17:21 |
| apw | oh ... | 17:21 |
| apw | wondering what you thought about the patches from RAOF diabliing accel for three nvidia cards | 17:22 |
| apw | you don't happen to have one of them do you? | 17:22 |
| apw | people.canonical.com/~apw/raof-nv-accel-lucid/ | 17:22 |
| apw | we now have a trio of tests on 'other' nvidia h/w suggesting they don't break things for non-quirked h/w | 17:23 |
| apw | and i am feeling they might be worth the risk, as they make unbootable h/w bootable ... what is your take | 17:23 |
| bryceh | apw, just looked through the patches, and they look fine | 17:24 |
| bryceh | they're limited to only have effect against the specific hardware so should be really low risk | 17:25 |
| apw | thats waht i feel, if you have any nvidia h/w you could boot test them too | 17:25 |
| apw | expecting them to not trigger | 17:25 |
| apw | if you are happy, then i think i am ready to take the risk | 17:26 |
| bryceh | if you've already had a couple other people boot check them, that satisfies me. | 17:28 |
| apw | sarvatt, bjf and jfo all have booted with them | 17:31 |
| bryceh | perfect | 17:31 |
| apw | ok ... fingers crossed then | 17:31 |
| === |thade| is now known as Alexia_Death_ | ||
| tormod | https://wiki.ubuntu.com/X/InputConfiguration talks about ENV{x11_options.name}="value", is this valid? | 19:30 |
| jcristau | no | 19:30 |
| tormod | so there is no way to set arbitrary options from udev? was there? | 19:39 |
| ripps | geez, what's with all the lucid live cd's they're all broken. The desktop cd has a kernel oops early on and can't load X, and the alternate CD has no network modules installed | 19:40 |
| ripps | All I want to do is reinstall Ubuntu.... | 19:42 |
| tormod | Sarvatt, I think the gallium hook is finished now... | 20:12 |
| jcristau | tormod: there was. there isn't now. | 20:12 |
| tormod | jcristau, thanks, do you know when it was in Ubuntu? | 20:13 |
| jcristau | tormod: it went away with server 2:1.7.6-2 | 20:14 |
| jcristau | replaced by inputclass | 20:14 |
| tormod | jcristau, your reply on "release thoughts" was really good :) | 20:15 |
| Sarvatt | AGREED! I was just going to mention that :) | 20:17 |
| Sarvatt | protos never were an issue here, it takes all of 10 minutes to completely update and package them all.. and I wouldn't exactly call the 3 month intel release process a good model since theres almost no stable release support there | 20:22 |
| tormod | if they want more people to test latest git, they should make it easier for us packagers to package it, rather than the odd guy wanting to compile the whole pile :) | 20:24 |
| jcristau | also they should make it not broken half the time. granted it's not much more broken than the "releases", but still. | 20:25 |
| ripps | hmm... with xorg-edgers, it seem like there's some errors rendering ass subtitles. | 20:32 |
| ripps | in mplayer | 20:32 |
| === rickspencer3_ is now known as rickspencer3 | ||
| jcristau | tormod, Sarvatt: note that you're allowed to comment as well if you have an opinion on that stuff :) | 20:36 |
| tormod | we'll be dismissed as ubuntu fanboys :) and canonical has so much money and all that | 20:38 |
| bryceh | heh | 20:38 |
| Sarvatt | hard to write a meaningful comment on my phone but I was planning on it :) | 20:39 |
| bryceh | yeah I got hate mail last time I posted to xorg-devel with ubuntu perspective feedback about release stuff | 20:39 |
| BUGabundo | eheh | 20:40 |
| BUGabundo | so we are eaten by wolfs if we say something | 20:40 |
| BUGabundo | and eaten by wolfs if we shut up | 20:41 |
| bryceh | BUGabundo, that seems about the gist of it | 20:41 |
| BUGabundo | many upstreams seem to dislike ubuntu | 20:41 |
| BUGabundo | go figure | 20:41 |
| BUGabundo | but then again, 'I'm a fanboy' | 20:42 |
| BUGabundo | so my POV doesn't count | 20:42 |
| Sarvatt | my only real complaint about ubuntu is the amount of patches carried around for most packages that deviate significantly from upstream. enabling features or providing a better out of the box experience is a goal I agree with but just about every major package I grab I find patches from years ago that I question the relevance of but I'm not able to follow the code well enough to say for sure its not | 21:11 |
| bryceh | Sarvatt, is that an issue you've seen with the X packages? | 21:20 |
| bryceh | Sarvatt, admittedly we've got an assload of ubuntu patches in xserver, many of which are not cherrypicks | 21:20 |
| Sarvatt | xserver compiz and gnome-screensaver are the most recent ones i've looked at off the top of my head, its just when I see bugs with errors happening in the code path the patch from 4 years ago with no description and not upstream touches my I spend hours trying to research the patch (which happens a *lot*) | 21:24 |
| bryceh | yeah we could probably do better with xserver. OTOH I think we did a pretty good housecleaning when 1.7 got merged | 21:27 |
| bryceh | maybe for meerkat you, raof, and timo can do a more thorough scrub | 21:27 |
| bryceh | e.g. there's a bunch of xserver patches which really are just null pointer asserts which might not be needed anymore, but I kept them in lucid just to be extra conservative | 21:28 |
| seb128 | bryceh, bug #553401 is that something on your list for lucid? | 21:28 |
| ubottu | Launchpad bug 553401 in xkeyboard-config "typo in some symbol files in xkb-data" [Undecided,Confirmed] https://launchpad.net/bugs/553401 | 21:28 |
| seb128 | bryceh, I'm not sure if it's right or not, just ran across it while searching for a duplicate and it has a change which seems easy to review | 21:29 |
| bryceh | seb128, it's not on my todo list, but yeah I noticed it as well but also was not sure if it's right or not | 21:29 |
| bryceh | seb128, is it a serious issue, or just code cleanup? | 21:30 |
| seb128 | ok, I just wanted to point it | 21:30 |
| seb128 | well users comment suggest it makes layout work instead of returning errors | 21:30 |
| seb128 | see comment #1 | 21:30 |
| seb128 | I'm not sure if that's true though | 21:31 |
| seb128 | I just mentioned it in case somebody there was familiar with xkb | 21:31 |
| seb128 | let me ping svu ;-) | 21:31 |
| bryceh | ok well as there's a debdiff included I can just slap it in; it doesn't sound like it holds much risk | 21:31 |
| bryceh | thanks for contacting svu | 21:31 |
| bryceh | seb128, ahh nevermind, don't bug svu | 21:33 |
| seb128 | bryceh, <svu> seb128: well, the patch makes sense indeed. | 21:33 |
| seb128 | bryceh, too late | 21:33 |
| bryceh | the fix is to remove semicolons from a ubuntu patch | 21:33 |
| seb128 | right... | 21:33 |
| jcristau | yeah the patch seems correct. | 21:33 |
| bryceh | oh not a ubuntu patch but a cherrypick from upstream, so worth notifying svu | 21:35 |
| bryceh | seb128, uploaded | 21:39 |
| seb128 | bryceh, thanks! | 21:40 |
| bryceh | seb128, ok _now_ I have no further todo's planned for xkeyboard-config | 21:41 |
| bryceh | all the high priority xkeyboard-config bugs tagged lucid are resolved | 21:41 |
| seb128 | good ;-) | 21:43 |
| seb128 | and nice to see we got that fix in too | 21:43 |
| RAOF | apw: I've booted that kernel and it didn't affect my non-quirked hardware, and the reporter of the GeForce 3 boot-hang found that it successfully booted the otherwise unbootable hardware. | 22:48 |
| jcristau | Sarvatt: you've got quite some experience building X from git with edgers and all, i think that's valuable to that discussion, since making that easier is what keithp uses to justify his changes afaict | 22:54 |
| bryceh | morning RAOF | 23:13 |
| RAOF | bryceh: Good morning. | 23:14 |
| RAOF | bryceh: Sorry about missing you last night. There's a debdiff on bug #541492, and a commit in pkg-xorg/libdrm for another bug. | 23:20 |
| ubottu | Launchpad bug 541492 in xserver-xorg-video-intel "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)" [Unknown,Confirmed] https://launchpad.net/bugs/541492 | 23:20 |
| bryceh | ok | 23:21 |
| bryceh | RAOF, had to redo the debdiff a bit since I already did a -3ubuntu2 just a bit ago | 23:26 |
| bryceh | libdrm uploaded | 23:27 |
| bryceh | intel -3u3 uploaded | 23:28 |
| RAOF | Thanks muchly. | 23:29 |
| bryceh | man, this is just depressing: http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg | 23:30 |
| RAOF | :( | 23:31 |
| RAOF | In some ways that's partially to be expected, though. There's certainly upward pressure on that graph towards the end of a cycle, where there are more people testing. | 23:32 |
| bryceh | yep | 23:32 |
| RAOF | Man, the intel bugs are volatile though! | 23:32 |
| bryceh | yeah here on out we're not going to be able to wrestle the bug stats down | 23:33 |
| bryceh | RAOF, volatile as in tempers? | 23:33 |
| RAOF | That too:) | 23:33 |
| RAOF | I mean volatile as in “contribute most of the jaggedness to the totals curve” | 23:33 |
| bryceh | with -ati I'm amazed at a) how many are really just looking for free tech support, not really reporting an actual "defect" for us to fix, and b) how often people pinpoint the issue to the *kernel* modesetting (UMS is fine) yet still file the bug against xorg. Heh | 23:34 |
| bryceh | RAOF, ah yeah | 23:35 |
| bryceh | RAOF, well in truth with this style of stacked graph, whatever significant package were on the bottom would cause spikiness | 23:35 |
| bryceh | here -intel is towards the top - http://www2.bryceharrington.org:8080/X/Graphs/totals.svg | 23:36 |
| bryceh | well, this one shows we made a pretty solid dent prior to -beta2: http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg | 23:36 |
| RAOF | Well, yeah. | 23:36 |
| bryceh | wish we'd gotten more sent upstream though | 23:37 |
| RAOF | Actually, that's something that we should probably discuss at UDS - with a significant part of X now in the kernel, how do we want to do the triage? | 23:37 |
| bryceh | yeah that'd be a good topic | 23:37 |
| bryceh | mainly it boils down to the question, if we just sent all the output and modesetting bug reports to linux, is someone still going to be about to forward those bug reports upstream? | 23:38 |
| RAOF | Right. | 23:38 |
| RAOF | But it's also that those are quite a specific type of kernel bug report, and it's a type that us X guys generally have significant insight into. | 23:39 |
| bryceh | so far, if it's clear it's a kernel drm or modesetting issue I've just been shoving it on over and not worrying about it. If it's not clear I send it upstream and once I see a kernel patch proposed upstream, then I move it to linux. | 23:40 |
| bryceh | in the latter we've done half the work so I don't feel bad about it. The former case though I feel a bit guilty in that I don't know if JFo or other kernel folk are going to forward bug reports upstream | 23:40 |
| bryceh | but sending bugs upstream isn't hard, just drudge work | 23:40 |
| RAOF | Yeah. | 23:41 |
| bryceh | yeah regarding the insight... that was my motivation for writing up everything I know about modesetting issues and posting to the kernel mailing list | 23:41 |
| bryceh | these kinds of bugs are quite common and have a fairly well defined set of steps to troubleshoot and I don't think it's good if only a few of us have the necessary insights to troubleshoot them | 23:42 |
| bryceh | anyway, like you said it's a good topic to discuss | 23:43 |
| bryceh | honestly I just don't think we really have the manpower on just the X side | 23:43 |
| jcristau | hire more people :) | 23:44 |
| bryceh | jcristau, but who to hire? | 23:44 |
| jcristau | yeah good question.. | 23:44 |
| bryceh | jcristau, fact is we have graphics slots open on the jobs page. Finding people interested + skillful with X is tough | 23:45 |
| jcristau | right :/ | 23:46 |
| bryceh | at least on the kernel side, even if they don't have X skills, they have ability to fiddle kernel code, and so could learn X as they go | 23:46 |
| bryceh | a lot of resolution issues are just quirks or minor algorithm fixups that don't require much X depth, just knowing where to slap the appropriate C code in | 23:47 |
| RAOF | Yeah. | 23:48 |
| bryceh | problem is that with quirks we used to be able to have users easily test them via setting an option in xorg.conf, but there's no equivalent mechanism in the kernel yet | 23:48 |
| bryceh | once there is though, the process of handling those bugs could probably be handled by the bug triagers pretty well | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
