mlankhorst | morning | 03:57 |
---|---|---|
RAOF | Yo yo! | 03:58 |
tjaalton | plymouthd seems to crash here on boot | 04:49 |
mlankhorst | because of the race? | 04:58 |
mlankhorst | bbbbaaacktrace! | 05:00 |
tjaalton | no, it doesn't race anymore after changing lightdm.conf locally | 05:01 |
tjaalton | I guess the crash was the reason it was racing so reliably :) | 05:01 |
mlankhorst | haha | 05:01 |
=== Prf_Jako1 is now known as Prf_Jakob | ||
tjaalton | the plymouth crasher is bug 733453 | 08:18 |
ubottu | bug 733453 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in script_obj_deref_direct()" [High,Confirmed] https://launchpad.net/bugs/733453 | 08:18 |
mlankhorst | valgrindddd | 08:19 |
tjaalton | how to run it during boot? | 08:20 |
tjaalton | just edit init/plymouth.conf? | 08:21 |
mlankhorst | I guess so, don't see why that wouldn't work | 08:21 |
mlankhorst | though you'd want to pipe the output to somewhere | 08:21 |
mlankhorst | &>> /run/something | 08:22 |
tjaalton | right | 08:22 |
seb128 | tjaalton, mlankhorst: you also have the good old trip of "mv bin bin.real" and make "bin" a wrapper script calling valgrind bin.real --log-file=/tmp/... | 08:23 |
seb128 | trip->trick | 08:23 |
mlankhorst | seb128: well in case of X I just change the symlink in /etc/X11/X to point to my wrapper script | 08:25 |
seb128 | well, if you have a symlink, sure you can just change the target | 08:25 |
seb128 | but most binaries don't have a smylink | 08:25 |
mlankhorst | true | 08:26 |
tjaalton | hmm, either it's not working or logging is somehow off | 09:08 |
tjaalton | --log-file=foo that is | 09:08 |
tjaalton | tried /tmp and /run | 09:08 |
mlankhorst | tjaalton: root is ro at that point, maybe point to /dev ? | 09:19 |
mlankhorst | oh and plymouth might fork | 09:20 |
mlankhorst | so you'd need --trace-children=yes | 09:20 |
tjaalton | ok | 09:20 |
tjaalton | still nothing | 09:25 |
mlankhorst | hmz.. | 09:28 |
tjaalton | hrm, alt-tabbing is slow on ivb | 09:28 |
tjaalton | with mesa 9.1 | 09:28 |
seb128 | tjaalton, is plymouth working? your wrapper is correctly +x and call the full path to the binary? | 09:29 |
mlankhorst | he's modifying the init script | 09:29 |
tjaalton | seb128: yep | 09:29 |
tjaalton | tried both | 09:29 |
mlankhorst | my guess is root still rootonly since it gets called before mountall | 09:29 |
tjaalton | now I have a wrapper | 09:29 |
seb128 | try doing an echo"test" > /tmp/debug | 09:29 |
tjaalton | right | 09:29 |
tjaalton | root is ro, nothing | 09:33 |
tjaalton | tried /dev, /run, /tmp | 09:33 |
mlankhorst | heh | 09:34 |
mlankhorst | mkdir /dummy | 09:34 |
mlankhorst | and in the init script /sbin/mount -n -t tmpfs /dummy /dummy | 09:34 |
tjaalton | didn't get that to work either, maybe need to add an initramfs hook or something | 09:56 |
tjaalton | but did check how mesa performance has dropped on gen4 i915.. | 09:57 |
tjaalton | that or the dash has changed dramatically since precise | 09:57 |
tjaalton | lunch -> | 09:59 |
mlankhorst | oh cool, git-bzr works well enough to clone a repository | 10:05 |
tjaalton | hum, what's bug 1134492 about then | 11:37 |
ubottu | bug 1134492 in xorg-lts-quantal (Ubuntu) "xserver-xorg-lts-quantal breaks Kubuntu" [Undecided,New] https://launchpad.net/bugs/1134492 | 11:37 |
mlankhorst | presumably libegl stuff | 11:38 |
mlankhorst | iirc kwin depends on libegl, which we don't install by default | 11:38 |
tjaalton | ah | 11:39 |
tjaalton | but doesn't kubuntu 12.04.2 use the backport stack? | 11:40 |
tjaalton | iirc it does | 11:40 |
mlankhorst | the bug is about installing kubuntu-desktop separately, I believe | 11:40 |
mlankhorst | oh wait kubuntu-desktop is kept, lts-quantal is installed after | 11:41 |
tjaalton | kubuntu-desktop installs just fine here | 11:42 |
mlankhorst | it will install fine, the bug is about installing kubuntu-desktop first, then installing xserver | 11:42 |
mlankhorst | and having a resolution that will remove kubuntu-desktop i believe | 11:42 |
tjaalton | good thing I've booted 12.04.1 off a usb stick | 11:43 |
tjaalton | so I can try :) | 11:43 |
mlankhorst | I forgot which one it was though | 11:44 |
mlankhorst | tjaalton: hah I have a ssd and a chroot, race you to it! | 11:45 |
tjaalton | :) | 11:46 |
tjaalton | i have a local mirror | 11:46 |
mlankhorst | wait libglu gets removed, why ._. | 11:47 |
mlankhorst | oh nm | 11:50 |
mlankhorst | that user just misconfigured his stuff | 11:50 |
mlankhorst | no alarm | 11:50 |
mlankhorst | Empfohlene Pakete: | 11:50 |
mlankhorst | libgl1-mesa-glx-lts-quantal | 11:50 |
tjaalton | recommends not enabled? | 11:52 |
mlankhorst | indeed.. | 11:53 |
tjaalton | heh | 11:53 |
ogra_ | note that flavours like lubuntu do that by default | 11:53 |
mlankhorst | not my problem | 11:53 |
ogra_ | (no idea about kubuntu, but they might too) | 11:53 |
mlankhorst | though I guess I could explicitly enable it | 11:54 |
tjaalton | meh, blur/fade regressed on haswell too | 12:26 |
tjaalton | with mesa 9.1 | 12:26 |
tjaalton | what a fail | 12:26 |
tjaalton | the recent work in master made it better but it's still worse than it was with 9.0 | 12:27 |
mlankhorst | the question we should be asking is whether it can be resolved in time or not :/ | 12:28 |
tjaalton | right | 12:36 |
tjaalton | wonder if git master builds | 12:37 |
mlankhorst | not with radeon afaik | 12:41 |
tjaalton | bah | 12:54 |
=== schmidtm__ is now known as schmidtm_ | ||
tjaalton | hm, I could just try reverting the bad commit that caused the perf regression | 14:47 |
tjaalton | no change on hsw, although it seems it didn't regress after all.. | 15:38 |
tjaalton | snb is just as happy with the revert as with the 19 patches | 15:46 |
tjaalton | so looks like it worked there | 15:46 |
tjaalton | who cares about serious sam 3 performance anyway? :) | 15:46 |
bryce | tjaalton, did you chat with slangasek about 9.1 in raring? | 16:10 |
seb128 | bryce, tjaalton: what's the status on the performances issues of the new version on gen5 cards? that should probably be resolved before talking about landing the update... | 16:29 |
Sarvatt | https://devtalk.nvidia.com/default/topic/539249 | 16:30 |
bryce | seb128, 6 lines up tjaalton says he has been trying to revert the problematic patch; no luck so far | 16:32 |
seb128 | bryce, ok, I restarted my IRC and didn't have that backlog, thanks | 16:33 |
bryce | seb128, I suggested talking with slangasek or another release admin before landing it with any regressions | 16:33 |
bryce | seb128, ah I may have misread his comments; sounds like he successfully reverted the change but hasn't yet confirmed the fix on gen5 hardware, I guess | 16:35 |
tjaalton | bryce: not yet | 17:16 |
tjaalton | bryce, seb128: pitti tested the reverted version, it's better than the ppa version but slightly worse than 9.0.3 on raring | 17:18 |
tjaalton | does anyone have IVB to test on? | 17:18 |
tjaalton | I do, but it means killing my session :) | 17:19 |
tjaalton | so, this latest one with just the one revert on top of 9.1.1 looks like the best solution for now | 17:19 |
tjaalton | uploaded -intel 2.21.6 | 18:13 |
mlankhorst | \o/ | 18:14 |
tjaalton | fixes at least one bug | 18:14 |
mlankhorst | push to git? | 18:14 |
tjaalton | done | 18:14 |
mdeslaur | so...in quantal, what exactly is supposed to install the proper kernel headers so the nvidia dkms module gets built? | 18:14 |
mlankhorst | tjaalton: oh can you add --enable-valgrind to rules? | 18:14 |
tjaalton | it's on the queue | 18:14 |
mdeslaur | I can't believe this doesn't even work out of the box | 18:15 |
tjaalton | mdeslaur: the image should have it, but there was a bug in the builder that removed them.. | 18:15 |
mlankhorst | ah nm it should have VG enabled afaict | 18:15 |
tjaalton | quantal is so passé anyway :) | 18:15 |
tjaalton | mlankhorst: well this one should first get past the queue :) | 18:16 |
mdeslaur | tjaalton: so if you install nvidia once your quantal is up-to-date, it doesn't actually work without you manually installing the kernel headers? | 18:16 |
tjaalton | mdeslaur: correct | 18:16 |
tjaalton | I think | 18:16 |
tjaalton | haven't tried | 18:16 |
mdeslaur | awesome. guess 2013 isn't the year of the linux desktop. | 18:16 |
tjaalton | hehe | 18:16 |
tjaalton | well technically that was in 2012 | 18:16 |
mlankhorst | tjaalton: I just want valgrind so I can get rid of most false positives on a default boot, and only get the USEFUL backtraces :P | 18:16 |
tjaalton | surely 13.04 will kick butt, and include other bugs | 18:17 |
mdeslaur | tjaalton: I included a 6 month SRU grace period :P | 18:17 |
tjaalton | mdeslaur: nobody cares about quantal, other than maybe because of the lts backport stack | 18:17 |
mlankhorst | that^ | 18:18 |
mlankhorst | if people cared about quantal my xxv-nouveau would have been accepted a lot sooner in quantal-proposed | 18:18 |
mlankhorst | been a month now? | 18:18 |
mdeslaur | the people who opposed turning non-lts releases into a rolling release should be _forced_ to do sru maintenance and testing :P | 18:19 |
mlankhorst | I'm not against rolling releases, but I think waiting for raring to be released first wouldn't have been a bad idea | 18:19 |
mdeslaur | well, that's a separate issue | 18:20 |
tjaalton | mdeslaur: yeah rolling ftw, interim releases are a big pita | 18:21 |
mlankhorst | nobody cares about the interim :/ | 18:21 |
mlankhorst | people care more about the quantal lts stack in precise than about quantal | 18:22 |
tjaalton | flavors do, but for how long | 18:24 |
tjaalton | I hope this can be revisited after T | 18:24 |
llstarks | i'd like a rolling repo | 18:28 |
llstarks | i'm only on "stable" ubuntu for maybe a day or two each year anyway. release and toolchain upload are now simultaneous though | 18:29 |
=== f4bs0 is now known as f4bs | ||
=== erapp_000_ is now known as llstark | ||
=== llstark is now known as llstarks | ||
llstarks | i'm going to test nvidia 319.12, i want to see what xrandr outputs with the new randr 1.4 support for optimus | 23:04 |
llstarks | http://us.download.nvidia.com/XFree86/Linux-x86/319.12/README/randr14.html | 23:05 |
llstarks | they're basically telling us how to implement it | 23:05 |
bjsnider | llstarks, it is good news for optimi users, no? | 23:10 |
llstarks | i don't know yet. it's an always-on driver situation. nvidia+modesettng | 23:11 |
bjsnider | if you use the nvidia-installer be careful it doesn't overwrite anything | 23:12 |
llstarks | i'm still trying to figure out the xorg.conf | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!