| Sarvatt | superm1: hmm your nvidia 190 drivers dont pull in libvdpau for me | 00:08 |
|---|---|---|
| Sarvatt | ah maybe because Depends: nvidia-190-kernel-source (>= 190.42), libvdpau, x11-common (>= 1:7.0.0), ${shlibs:Depends} when the package is libvdpau1 | 00:09 |
| superm1 | Sarvatt, it's possible i didn't add that depends (because mythtv has it inheritently when it build-depends against something with vdpau support) | 00:09 |
| Sarvatt | might have been libvdpau in your 0.2 version and changed to libvdpau1 in this 0.3 i'm guessing | 00:10 |
| Sarvatt | its libvdpau1 in the 0.2 in all your PPAs too incase you want to change that in the nvidia-glx-190 depends next time you upload to one without mythtv | 00:16 |
| Sarvatt | ....not that there is one without mythtv now that i look :D | 00:17 |
| Sarvatt | thanks for all of the help, it's working great now | 00:20 |
| Sarvatt | hmm, updating the nvidia-glx-190 package to Depend on libvdpau1 didn't pull in libvdpau on the update either | 00:29 |
| Sarvatt | debian/control.in was missing the libvdpau depends completely was the problem | 00:45 |
| Sarvatt | The following NEW packages will be installed: libvdpau1 The following packages will be upgraded: nvidia-190-kernel-source nvidia-glx-190 | 00:48 |
| Sarvatt | phew thats more like it | 00:48 |
| Sarvatt | now i notice no modalias getting installed :D | 00:52 |
| superm1 | nvidia-common dependencies need to be adjusted for that | 01:56 |
| Sarvatt | i just made it provide nvidia-185-modaliases for now | 03:04 |
| === freeflyi1g is now known as freeflying | ||
| Sarvatt | nvidia-settings 190.42 needed a patch to compile against the x11proto-xf86vidmode-dev headers instead of the libxxf86vm-dev ones, errors trying to build against the lib's after the xorg 7.5 split. http://bugs.gentoo.org/attachment.cgi?id=208926 | 06:46 |
| Duke` | Sarvatt, is there a fix specific to our problem in this new libdrm? ([drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged) | 08:57 |
| Sarvatt | Duke`: nope, pretty sure its a kernel problem. check out the "enable memory self refresh" patch threads on the intel-gfx mailing list. the new libdrm is just overwriting the headers in linux-libc-dev and its the same as the one before it otherwise | 16:27 |
| Sarvatt | Duke`: what kernel are you using? I haven't had it happen on the ubuntu 2.6.32 kernel yet | 16:28 |
| Sarvatt | of course suspend/resume is broken on this and not on the drm-next kernels, flickering and eventually freezing on a solid color after resume | 16:28 |
| hyperair | memory self refresh? | 16:42 |
| hyperair | what's that do? | 16:42 |
| Duke`_ | Sarvatt, i use the 2.6.32 | 16:47 |
| tjaalton | my intel seems to make X eat the cpu (stock lucid) | 16:48 |
| Sarvatt | anything special about it or is it just a stock install? | 16:55 |
| Sarvatt | gonna check if mine does too | 16:55 |
| Sarvatt | haven't tried the stock environment in a few weeks | 16:56 |
| Sarvatt | KMS doesn't work unless I blacklist vga16fb though on 2.6.32-7 | 16:56 |
| tjaalton | nothing special, 965GM. booting fails ~every second time, evdev crashes for some reason and falls back to vesa (which doesn't work at all due to KMS) | 17:00 |
| tjaalton | I'll merge new evdev & xserver tomorrow | 17:00 |
| tjaalton | and mesa (includes r600_dri.so) | 17:00 |
| Sarvatt | does it happen with compiz disabled too? | 17:02 |
| tjaalton | haven't tried | 17:03 |
| Sarvatt | sounds like a problem hyperair (i think?) had with 965 back when edgers had mesa 7.6/libdrm 2.4.14 is why i was asking | 17:06 |
| tjaalton | I've had this before iirc | 17:07 |
| tjaalton | happens after the first resume I guess | 17:07 |
| Sarvatt | /proc/dri/0/gem_objects was growing huge and and x was using 100% cpu i think | 17:08 |
| tjaalton | size is 0 | 17:10 |
| Sarvatt | now thats odd.. | 17:11 |
| Sarvatt | reverting back to stock lucid now but i doubt it'll be the same on my 945 | 17:13 |
| Sarvatt | hmm The following packages are BROKEN: xserver-xorg-core | 17:14 |
| Sarvatt | oh because i have a newer wacom in edgers and theres no installable wacom in the archive | 17:15 |
| Sarvatt | sounds like yer using vesa though if theres nothing in gem_objects? | 17:16 |
| Sarvatt | ah joystick is broken in lucid too | 17:17 |
| Sarvatt | oops i have some newer bits in a local package archive, no wonder ppa-purge didnt work right | 17:18 |
| tjaalton | compiz works, so doubt it's vesa :) | 17:19 |
| Sarvatt | do you have a /proc/dri/1 ? | 17:20 |
| hyperair | Sarvatt: which issue? | 17:21 |
| Sarvatt | X using alot of CPU like 6 months ago | 17:21 |
| hyperair | Sarvatt: i had two issues: one was the crazy memory leak that drove me nuts, and the other was the weird re-drawing issue. | 17:21 |
| hyperair | X using a lot of CPU... | 17:21 |
| hyperair | no i don't think i had that | 17:21 |
| hyperair | i just had increased swapping activity | 17:22 |
| hyperair | until it took up all my resources | 17:22 |
| hyperair | if X got oom killed in the fray, then well and good, otherwise i restart | 17:22 |
| Sarvatt | rebooting to stock lucid to see how things are here | 17:22 |
| hyperair | or i preemtively log out and kill X before it can kill the rest of my computer | 17:22 |
| hyperair | anyway the issue was a kernel thing | 17:23 |
| hyperair | if lucid uses .32, it shouldn't see such an issue | 17:23 |
| hyperair | no wait, there was a patch involved in mesa i think.. | 17:23 |
| tjaalton | I won't worry too much about it, yet | 17:23 |
| hyperair | no wait, it was definitely the kernel. i remember sarvatt giving me a custom compiled kernel and that solved all my issues | 17:24 |
| Sarvatt | thats strange, 4 reboots, X only started twice | 17:30 |
| Sarvatt | the other 2 I got failsafe with vesa all garbled | 17:30 |
| hyperair | ouch | 17:30 |
| * hyperair makes note not to upgrade to lucid until all's clear | 17:31 | |
| tjaalton | Sarvatt: sounds like my problem. check the gdm log | 17:31 |
| Sarvatt | cant find any gdm logs from the failed boots hmm | 17:33 |
| Sarvatt | its only got the 2 successful ones then edgers ones, failsafe doesnt have anything in it | 17:34 |
| Sarvatt | when it failed x tried to start on vt2, dont know if thats normal for failsafe | 17:35 |
| Sarvatt | wonder why it fails like that with the lucid packages and not edgers though | 17:39 |
| Sarvatt | do you have plymouth installed tjaalton? | 17:42 |
| tjaalton | yep | 17:42 |
| Sarvatt | me too | 17:42 |
| Sarvatt | theres some video trickery in there, gonna try removing it | 17:43 |
| Sarvatt | what the heck, 4 boots again, 2 failures again | 17:52 |
| Sarvatt | got an orphaned /etc/init/usplash.conf for some reason | 17:56 |
| Sarvatt | 164_trap-aspect-ratios.patch is the only patch we're dropping in edgers vs lucids xserver | 18:13 |
| * Sarvatt wonders how this edid caching works in the ubuntu kernel | 18:15 | |
| Sarvatt | its happening every other boot reliably though for some reason | 18:17 |
| Sarvatt | going to try a stock 2.6.32 just to rule out any kind of patches | 18:18 |
| * hyperair uses 2.6.32-zen0 | 18:19 | |
| Sarvatt | 10 reboots on a stock 2.6.32 kernel from the mainline thing and no errors, pretty darn safe to say its a ubuntu kernel patch messing it up | 18:42 |
| Sarvatt | only thing ubuntu specific that stands sticks out is http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=c5155725948be57010c4a558a1b9c5ddefb864c3 | 18:49 |
| Ng | hrm, my trackpad isn't showing up in "xinput list" in lucid | 18:55 |
| Sarvatt | that commit isnt even in 2.6.32-7 thats having problems so definitely not that then | 18:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!