| === yofel_ is now known as yofel | ||
| tjaalton | mesa 7.10.2, go/no-go ? | 08:26 |
|---|---|---|
| RAOF | tjaalton: The diffstat is (somewhat surprisingly) not too scary. Everything seems to work, too. | 10:28 |
| tjaalton | RAOF: oh, you've tested it already? | 10:28 |
| RAOF | A bit today. | 10:28 |
| tjaalton | ok, nice | 10:28 |
| tjaalton | next week the kernel will be frozen, so if we want to disable nouveau acceleration by default we should make it now | 10:30 |
| tjaalton | OTOH fedora doesn't do it anymore | 10:30 |
| tjaalton | so maybe it would be too invasive a change at this point | 10:30 |
| RAOF | And we don't seem to have users screaming about it, either. | 10:31 |
| tjaalton | right | 10:31 |
| tjaalton | let's keep status quo then | 10:31 |
| RAOF | I've got a nouveau upload that supposedly fixes an EXA crash, but, again, people don't seem to be hitting it. | 10:32 |
| tjaalton | got a link to a bug? | 10:32 |
| RAOF | No; it was just talking with darktama.\ | 10:32 |
| tjaalton | ok | 10:32 |
| tjaalton | great, can't install maverick on a spare machine because of ati kms fail | 12:01 |
| tjaalton | have to use a dvi-dsub dongle, and it doesn't seem to recognize it | 12:02 |
| tjaalton | radeon.modeset=0 to the rescue, of course.. | 12:08 |
| tjaalton | except X still doesn't work | 12:20 |
| tseliot | is it a new card? | 12:22 |
| tjaalton | no, an ancient X800 | 12:24 |
| tjaalton | hum no, some firegl device actually, but from the same era | 12:24 |
| tjaalton | I'll try natty next | 12:24 |
| tseliot | hmm.. | 12:26 |
| tjaalton | x starts, just no picture to prove it | 12:26 |
| tjaalton | logfile looks innocent as well | 12:26 |
| tjaalton | same with natty | 12:57 |
| tjaalton | works with the dvi cable | 13:03 |
| tseliot | tjaalton: what cable was the one that didn't work? | 13:41 |
| tjaalton | tseliot: d-sub, with a dvi dongle | 13:52 |
| tseliot | ah, ok | 13:52 |
| === seb128_ is now known as seb128 | ||
| kklimonda | hey, any chance that one of you, X people have seen something like that on nouveau: http://people.ubuntu.com/~kklimonda/wtf.png ? | 16:55 |
| bryceh_ | heya sarvatt | 21:35 |
| Sarvatt_ | heyo! sorry, swapping between 4 different machines and missed IRC | 21:44 |
| Sarvatt_ | btw | 21:45 |
| Sarvatt_ | Error: Failure creating backup file for /etc/default/grub. Changes not applied. | 21:45 |
| Sarvatt_ | [Errno 13] Permission denied: '/etc/default/grub.bak' | 21:45 |
| Sarvatt_ | bryceh_: doesn't look like this runs update-grub after? | 21:46 |
| Sarvatt_ | bryceh_: hrm, second run thinks "disable bootloader graphics" isn't applied 100% of the time | 21:48 |
| Sarvatt_ | but its there | 21:48 |
| bryceh_ | Sarvatt, yeah I just added update-grub yesterday | 21:56 |
| bryceh_ | Sarvatt, those errors are because it has to run as sudo | 21:56 |
| bryceh_ | need to figure out gksudo or some such to request privs | 21:56 |
| bryceh_ | Sarvatt, yeah sorted the disable bootloader graphics issue out yesterday too; that was kind of a hard one | 21:57 |
| bryceh_ | Sarvatt, fixes pushed to bzr | 21:59 |
| Sarvatt_ | bryceh_: cool, everything working now | 22:00 |
| bryceh_ | I also got the packaging squared away. Just need to test it on a virgin machine then I think I can upload. | 22:01 |
| bryceh_ | ok, X blueprints filed | 22:53 |
| bryceh_ | I made 3, one for stakeholders, one for discussing tools/processes/debugging/etc., one team huddle one | 22:53 |
| bryceh_ | RAOF, ^ please review and see if I missed anything | 22:55 |
| tjaalton | subscribed to them | 22:57 |
| bryceh_ | tjaalton, I'm looking forward to having so many X folks at one UDS :-) | 22:59 |
| tjaalton | bryceh_: yeah, there might even be <gasp> discussions :) | 23:02 |
| tjaalton | the previous planning session I attended took maybe 15min :) | 23:02 |
| bryceh_ | yeah | 23:03 |
| Sarvatt_ | hopefully they dont overlap private sessions I have to go to this time around :) | 23:03 |
| tjaalton | uds-j | 23:03 |
| bryceh_ | tjaalton, Sarvatt_, yeah make sure you're subbed as essential to these so you don't get too cross-scheduled | 23:03 |
| bryceh_ | tjaalton, Sarvatt, also if you guys think we need additional topics just shout. | 23:04 |
| bryceh_ | although it seems from past uds's that 3 X sessions was about right | 23:04 |
| bryceh_ | but now that there's more of us we could probably handle more if we see the need | 23:06 |
| tjaalton | sure | 23:09 |
| bryceh_ | tjaalton, sarvatt: I'm kind of disappointed -intel is still proving quite buggy - http://tinyurl.com/3jrqgat | 23:10 |
| tjaalton | yeah.. | 23:11 |
| bryceh_ | I have been pumping bug reports upstream but the patches we've been getting have been more miss than hit lately | 23:11 |
| tjaalton | btw, was the apport-collect script broken for a while? | 23:12 |
| bryceh_ | I'm kinda stuck on what else to do... any ideas? | 23:12 |
| bryceh_ | tjaalton, yeah, a couple typos | 23:12 |
| tjaalton | ok, that's why ubuntu-bug reported ~empty bugs | 23:12 |
| bryceh_ | sorry about that; have them run apport-collect <bug-nr> and that should fix them up | 23:13 |
| tjaalton | so are these intel bugs without the trigger-happy apport script? | 23:15 |
| tjaalton | ie. nothing we can turn off?-) | 23:15 |
| tjaalton | left | 23:15 |
| bryceh_ | the GPU lockup ones are from the gpu lockup hook, and are mostly legit bugs | 23:15 |
| tjaalton | right | 23:15 |
| bryceh_ | I think I got the script a lot less trigger-happy now, although the vesafb conflict or whatever that causes the false positives is still there | 23:16 |
| bryceh_ | bugs with ESR 0x00000010 are often that issue | 23:16 |
| tjaalton | ok, so unless we educate ourselves as gpu programmers there's not much to do than report them upstream and be nice to ickle :) | 23:17 |
| bryceh_ | bug #2 is whatever causes freezes on 915/945, we get tons of those, and upstream tends to dupe them all together, point to a patch, and close as fixed. Then we have to pull that fix in, and wait for another series of 915/945 bugs to get reported. Rinse, lather, repeat. | 23:18 |
| ubot4` | bryceh_: Bug 2 on http://launchpad.net/bugs/2 is private | 23:18 |
| bryceh_ | there's a third class which is arrandale specific | 23:18 |
| bryceh_ | I had thought the new ia32-libs would resolve that since it seems to only affect x86_64, but we're still getting bugs reported | 23:19 |
| bryceh_ | so like "[arrandale] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000024)" is typical error codes on that | 23:19 |
| tjaalton | ah | 23:20 |
| bryceh_ | fourth class is 965-specific, bug #686388 | 23:20 |
| ubot4` | Launchpad bug 686388 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "[i965gm] GPU lockup - Invalid GTT entry during Display B Fetch (affects: 11) (dups: 8) (heat: 80)" [High,Incomplete] https://launchpad.net/bugs/686388 | 23:20 |
| bryceh_ | I think that covers the common classes for the gpu lockups | 23:20 |
| bryceh_ | then there's a whole bunch of other random assorted bugs | 23:20 |
| bryceh_ | oh, and various 865 lockups, but we just wontfix those | 23:21 |
| bryceh_ | tjaalton, yeah I think you're right regarding needing gpu programming education ;-) | 23:22 |
| tjaalton | i'll probably buy a second hand fujitsu laptop (v5535) with sis 671 on it, and see how the damn driver works first :) | 23:23 |
| tjaalton | or, rather, doesn't | 23:23 |
| bryceh_ | heh | 23:24 |
| bryceh_ | well, like one thing I'm wondering is it'd be nice if when Intel posts a patch that "fixes" it, that we have some easy way to roll a kernel with that patch so reporter can easily verify that no, it doesn't | 23:24 |
| tjaalton | don't the kernel team do that, provide a ppa with a kernel that has a proposed patch | 23:25 |
| bryceh_ | we have daily builds of intel-drm-next, but I think they're being stricter about putting untested patches into that | 23:25 |
| bryceh_ | tjaalton, yeah they do, but I wonder if bugging them each time there is a patch needing packaged is the right solution? | 23:25 |
| bryceh_ | and maybe it is; technically they are kernel bugs after all... | 23:26 |
| tjaalton | bryceh_: no, but can't we make use of the infrastructure directly? | 23:26 |
| Sarvatt_ | tjaalton: do you have an account on tangerine? its so friggin fast for building kernels, I can walk ya through it tomorrow if you want | 23:26 |
| bryceh_ | right, that's what I'm wondering | 23:26 |
| tjaalton | Sarvatt_: t.c.c? | 23:27 |
| Sarvatt_ | tangerine.buildd | 23:27 |
| tjaalton | doesn't seem like I do | 23:27 |
| tjaalton | "Permission denied (publickey)." | 23:28 |
| Sarvatt_ | gotta pivot in from chinstrap | 23:28 |
| tjaalton | that's where i tried from | 23:29 |
| Sarvatt_ | you'd know if you had an account, lets see | 23:29 |
| Sarvatt_ | its a 64 core 64gb ram machine in one of the datacenters for kernel building, takes <10 minutes for a kernel build | 23:30 |
| tjaalton | hah | 23:30 |
| tjaalton | hmm, at my previous job I built mesa in 8min on a shell server, which had 12cores + hyperthreading, and 96GB RAM | 23:32 |
| tjaalton | can't remember the time it took, but it was fast | 23:32 |
| tjaalton | could've been less than 8min | 23:32 |
| bryceh_ | it would be totally awesome if we could go from a) patch posted in upstream bug tracker, to b) built kernel (or mesa) .debs for reporter to test, in under 10 min | 23:36 |
| bryceh_ | heck, even 30 min would be nice | 23:37 |
| bryceh_ | currently it seems the turnaround is >5 hrs for such a case | 23:37 |
| JanC | tjaalton: I once talked with somebody who builds a kernel in < 1 min at his job ;) | 23:38 |
| tjaalton | yep, it should be doable. like create a branch, pull the fix, push the package to the builder (with some script, lp# as an argument) and then the bug would get the link | 23:39 |
| tjaalton | JanC: ok, that's quick :) | 23:39 |
| JanC | he works/worked at http://sara.nl/ though :P | 23:39 |
| Sarvatt_ | thats a really freaking good idea | 23:40 |
| tjaalton | i got a couple of friends at http://csc.fi | 23:40 |
| tjaalton | they have all the toys :,I | 23:40 |
| Sarvatt_ | bryceh_: https://wiki.canonical.com/KernelTeam/BuildResources | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
