[00:00] ah ok [00:00] I've got new versions I should upload... maybe I'll request bug reporters test them and then upload monday [00:01] vbox nvidia bcmwl so far, found a fix for vbox in svn that i put up a bug about, still trying to load the darn page with the nvidia patch that people say is working to try that out [00:01] oh wow, today's DebianImportFreeze. bummer [00:01] wow [00:03] http://www.nvnews.net/vbulletin/attachment.php?attachmentid=37305&d=1245688007 [00:04] works, woohoo [00:06] looks quite simple too [00:07] http://www.nvnews.net/vbulletin/showthread.php?t=134779 [00:07] will have to see if theres any problems with it later though, compiled it remotely [00:12] weird, nvnews.net isn't loading for me [00:12] yeah it took almost an hour for that page to load [00:12] ah must be popular ;-) [01:48] 1028 objects [01:48] 145694720 object bytes after 4 hours of compiz running, memory leak is for sure gone here [01:54] cool [01:54] I'm finalizing a script to request retesting on most of the -intel bugs [02:45] * hyperair grumbles about modprobe hanging and an oops on the .31 kernel [02:45] =( [02:45] i can't even boot it [02:45] Sarvatt: I'm up to ~1G of objects [02:45] well over 3000 [02:46] jbarnes: on which kernel/mesa? [02:46] wow [02:47] mesa 7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt ? [02:47] kernel from today [02:47] * jbarnes gets versions [02:47] 2.6.30-10-generic [02:48] how do I get full version info? [02:48] dpkg -l truncates things [02:48] dpkg -S doesn't show full version info [02:49] 7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt [02:49] apt-cache policy I gues [02:49] oh you're on x64 arent you [02:49] it took 24 hours for the darn x64 0624 to build [02:50] in 0623 i was just cherry picking 2 of the memory leak fixes from 7.5 branch, but 0624 has the merge of 7.5 into 7.6 so maybe there was something else in there [02:50] http://launchpadlibrarian.net/28299189/mesa_7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt_7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt.diff.gz [02:52] actually, i wonder if me using Option "SwapbuffersWait" "false" has something to do with it too, i've never ever seen gem_objects staying so low [02:53] no that doesn't affect object creation [02:58] interesting that Always free image offsets memory when re-initializing texture image fields. and Also release direct rendering resources in glXDestroyGLXPixmap. werent enough to fix the leak then if it ends up being fixed for you in the 0624 one like it is for me [02:59] just upgraded, I'll check tomorrow [03:00] 945? [03:00] gm45 [03:00] err g45 [03:09] jbarnes: you need a .31 kernel to fully avoid the gem object leak thing, from my experience =\ [03:10] jbarnes: well i'm actually using a kernel labelled as 2.6.30-sarvatt5 [03:11] that was june 21st linus git [03:13] guess i could reboot to the ubuntu kernel to see if thats true, i dont think it is though.. [03:18] 144 objects [03:18] 50532352 object bytes [03:18] i used to get over 300mb just starting compiz [03:21] * RAOF should make nouveau-kernel-source's get-orig-source do something more smart than cloning a kernel repository and throwing almost all of it away. [03:42] not much more of an option right now is there? seems to be in a transition stage [03:49] * hyperair has it at ~300M most of the time [04:04] now that is an amazing amount of new email from ubuntu-x-swat :) [04:07] 453 objects [04:07] 78503936 object bytes --- 50 minutes later opening and closing stuff with compiz on under 2.6.30-10 [04:11] switched to gnome-shell to see how leaky this is these days, clutter had some problems not long ago [04:13] Sarvatt, scary thing is I haven't run the script I mentioned yet... [04:15] 852 new mails now, lets see how many after the intel bug script of doom :D [04:21] hehe [04:21] actually it'll be even worse [04:21] now I have -fglrx and -nvidia scripts too [04:21] just doing the final dry runs now, and will be unleashing them soon [04:22] we're probably going to get a lot of feedback over the next week or so; hopefully it's mostly "looks like it's fixed now". [04:23] well at least its not right after a big change breaking things like the mesa update, would have lost that crash trend in the noise :D [04:23] yeah [04:23] also I figure it's good to get -nvidia and -fglrx tested before the new kernel hits [04:24] after that we're gonna have to wait a good bit of time before we can have folks retest [04:28] bug 363467 is the first one notified so far [04:28] Launchpad bug 363467 in xserver-xorg-video-intel "[gm965] kubuntu final live cd doesn't start xorg for HP 2710p laptop" [High,Incomplete] https://launchpad.net/bugs/363467 [04:47] anyone used gnome-shell? would like to figure out a way for it to use external gconf schemas so i can change the settings around, menus just a bit too big on a netbook [04:49] oh sheesh, first link on google has a hack around for it [04:58] heh [04:58] 99 bugs changed for fglrx-installer [04:59] 100 more new emails :D [04:59] beat me to it [05:00] just wait... the -intel and -nvidia scripts are still running [05:03] I'm probably seriously choking up launchpad's email server [05:14] would it help any to come up with a symptoms list of changes for -intel in new kernel revisions to match in the scripts? like .31-rc2 has suspend/resume fixes, hdmi detection, tv problems, an agpgart module order fix, 31-rc1 has gem pae support, a cursor corruption on resume fix, displayport, tv/vga detection fixes [05:16] 160 bugs changed for nvidia-graphics-drivers-180 [05:17] yeah that'd totally help [05:24] 126 bugs changed for xserver-xorg-video-intel [05:56] there's an rc2 already? [06:49] nah just new stuff since rc1 === ripps_ is now known as ripps [09:52] OK. These intel freezes are becoming increasingly frequent and annoying. [10:55] RAOF: with what? karmic+KMS with dpms disabled is proving to be extremely reliable atm :) [10:55] (although I am a kernel behind and had to disable dpms ;) [10:55] Ng: Karmic+KMS. There was a week or so where this combination was silky smooth. Now, not so much. [10:57] RAOF: where are you seeing the freezes? [10:57] Resume now almost always fails, and now random lockups during regular useage are getting more frequent. [10:57] huh [10:58] I'll play with -10 over the weekend, but I can't risk my stability today ;) [10:58] (I'm doing a very careful karmic dance on my work laptop) === albert231 is now known as albert23 [18:46] hey guys... how can i best report a problem with the nouveau drivers (not working on my machine( [19:11] hooo boy 2.6.31-rc1 in karmic now :D the bugs are going to go nuts with all of the things that cant build against it, no nvidia and i imagine ati blobs, bcmwl, vbox [19:50] hmm, linux-libc-dev now replaces libdrm-dev even though libdrm-dev ships more things than linux-libc-dev does [19:50] (on the drm side) [19:52] guess it shouldnt be a problem because it pulls libdrm-dev later than linux-libc-dev on the PPAs? or am I going to have to add a Replaces: linux-libc-dev again to libdrm-dev to compile things [19:56] looks like thats an old change i just noticed so it shouldnt matter because things are working :D [20:16] bryce: i updated intel-gpu-tools on edgers, saw someone asking you about a newer version earlier but i closed whatever channel it was so i dont remember the name [20:20] Depends: libpciaccess0 (>= 0.10), libdrm-intel1 (>= 2.4.9), libc6 (>= 2.4), libdrm2 (>= 2.3.1) [20:20] hmm it doesnt need that libdrm2 depend [20:21] guess it doesnt matter, everyone with libdrm-intel1 is going to have it [20:31] Sarvatt: cool [20:32] Sarvatt: if you'd like to prepare a debdiff of that I'll sponsor it straight away for you [20:32] oh i just packaged it quickly and didnt even make an orig.tar.gz, how would you want it to be named? the version is still 1.0.1 but theres git updates past it [20:33] ah interesting [20:34] version would be 1.0.1+gitBLAH-0ubuntu1, but let's check first if debian has packaged it [20:34] 1.0.1+git20090626-0ubuntu1 and add all the changes to the changelog? [20:35] i looked there first and couldnt find it, where did you merge it from debian at? [20:35] anholts intel-gpu-tools-debian? [20:36] yeah [20:36] oh right, hasn't been accepted into debian yet [20:36] yes that looks like a good version number [20:36] yeah he hasnt updated intel-gpu-tools-debian yet, i used debian/ from your package [20:37] ok [20:37] i also added a git log > ChangeLog and installed it in debian/rules dh_installchangelogs, should i skip that step? [20:37] no that's good [20:38] in fact if you include the ChangeLog you probably don't need to mention much in debian/changelog... just keep to important highlights [20:39] jcristau: any reason you guys aren't including intel-gpu-tools? should we be sending our debian/ changes upstream for it? [20:40] tar --exclude=debian --exclude=debian/* --exclude=.git --exclude=.git/* -cf - intel-gpu-tools | gzip -9 >intel_gpu_tools_1.0.1+git20090626.orig.tar.gz [20:40] would that be the correct name for the orig.tar.gz? [20:41] oh sorry intel-gpu-tools [20:41] intel-gpu-tools_1.0.1+git20090626.orig.tar.gz [20:47] that may be fine; I usually split it up into several steps [20:47] mv $dir intel_gpu_tools_1.0.1+git20090626 ; rm -rf .git debian/ ; gzip -9 ... [20:47] that way the directory is named correctly. However I suspect it may not matter [20:48] * bryce_ is happily closing many bugs from replies to yesterday's bug spam [20:52] hm things seem a little better so far [20:52] ~2700 objects weighing in at around 400M [20:54] 971 objects 271MB here on the 2.6.30-10 kernel so it wasnt -31 specific at least in my case [20:55] bryce: http://sarvatt.com/downloads/intel-gpu-tools_1.0.1+git20090626-0ubuntu1.debdiff https://edge.launchpad.net/%7Esarvatt/+archive/ppa/+sourcepub/660025/+listing-archive-extra [20:58] jbarnes: here is the diff between 0623 and 0624 incase you want to track down where the fix was, anything that doesnt say cherry-pick in the changelog was new https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/mesa_7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt_7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt.diff.gz [20:59] i pulled Always free image offsets memory when re-initializing texture image fields. and Also release direct rendering resources in glXDestroyGLXPixmap. into 7.6 by hand in the 0623 one so it wasnt those unless they needed other changes to go with it as well [21:00] all the ones that say (cherry picked from commit x) in the changelog were already in 7.6 i mean [21:04] i need to turn part messages back on, you probably werent even here when i said all that jbarnes :D [21:04] heh yeah I crashed right after looking at my mem usage [21:04] I think virtualbox grabbed my input and didn't give it back [21:05] I'm on 624 now [21:05] the changelog was big so I didn't bother looking through it [21:05] yeah sounds like things are better now but still crap on 0623, thats a heck of alot of objects though [21:06] 911 objects [21:06] 278081536 object bytes after 17 hours uptime with compiz [21:07] 965 render probably generates lots of objects [21:07] you're on 945 right? [21:07] yeah 945GME, aspire one netbook [21:08] woohoo 7.5-rc4 mesa, that was sorely needed [21:09] they pulled in like 50 intel fixes and updates after rc3 [21:12] would texture tiling increase object size? it was disabled on 965+ in the 0624 one but not 0623 [21:12] only slightly on 965 [21:12] 945 is the one that really bloats with texturing [21:15] 7.5-rc4 - sweetness [21:17] surprised it wasnt the 7.5 release [21:17] kees has uploaded a fixed read-edid package that works on amd64 :-) [21:20] bryce_: i noticed you did the dri.pc install differently, the way we've been doing it on the hook was taken from debian-experimental mesa 7.5 by adding usr/lib/glx/pkgconfig/dri.pc usr/lib/pkgconfig/ to libgl1-mesa-dev.install, just aheads up whenever you guys merge 7.5 into the ubuntu branch [21:20] reworking the hooks in auto-xorg-git now to cope with all these changes :) [21:21] ok [21:28] http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=537f3e7a1ef969b191f3d751f17563ab620d3676 [21:33] ah they probably want to update the 7.5 release note docs before final :D [21:34] Sarvatt: cool, we can drop our change in favor of those when we update [21:48] i should have learned my lesson about not updating things until PST work hours are over :D [21:50] can only upload new full source packages if the commit id is numerically higher or i fudge the version with a .r1 between +gitxxxx and the 8 digit commit id :D [21:51] * Sarvatt jumps to japan real quick where its the 27th. [22:26] bryce_: did you see 2.6.31-11.13 up on karmic-changes? incoming bugs from anything building modules using the old net_device api, block layer, i2c or agpgart not working anymore (nvidia and fglrx especially) [22:30] yeah I've adopted the practice with ppas to always append a ~1 or something [22:30] the times when I've failed to do it always end up being the times when I end up needing to do a ~2 ;-) [22:31] Sarvatt: yeah jj mentioned .31 was in flight [22:37] i'm going to be surprised if xserver 1.6.2 gets released before karmic at the rate things are going, much less a 1.7 branch starting.. [22:38] with XI2 1.9.99.12 every input driver needs updating to work with it and they've only updated evdev mouse synaptics acecad and joystick so far a week or so after that came out [22:39] ThJaeger fixed up wacom to work with it and sent me a package for the PPA that works good [23:08] superm1: are you around? [23:09] regarding your bug here https://bugs.edge.launchpad.net/bugs/385658 [23:09] Ubuntu bug 385658 in xorg-server "karmic alpha2 candidate doesn't boot up on Studio XPS 1340" [Undecided,New] [23:09] the problem is xserver-xorg-video-nv has the pci id installed for your GeForce 9200M GS device, but the PC wants to use the IGP instead [23:09] which isnt supported [23:11] I can make a patch for xserver so it falls back to vesa for all 084x and 086x nvidia devices which would fix it in the case of not having an xorg.conf and -nv not installing pci ids, but its kind of tricky while we are installing pci ids with the driver [23:13] nv works fine for the 9200M GS device though, i dont know what the preferred solution would be because its a really tricky situation [23:14] * hyperair groans [23:14] ccache rocks, right up til the point where you end up with truncated files in .ccache because your comp overheated and died, and ext4 likes leaving truncated files around [23:15] bryce_: do you have any ideas on how we should handle the situation there in that bug? [23:16] superm1: if you have a machine to test it on, can you try using xorg-edgers to see how it handles it? the -nv driver in there does not install pci ids [23:16] hmm [23:16] all 084x and 086x nvidia devices dont work in -nv, but its binding -nv to it because the 9200M GS does work fine but the PC is a hybrid and wants to use the IGP to save power by default [23:17] Sarvatt: regarding xserver 1.7, well good to have the head's up on it, sounds like we want to wait a bit longer. Maybe we could formalize your ppa a bit more for enterprising souls to test with, but I don't know of much in 1.7 that's a must-have for karmic [23:19] they pulled the dri2 updates into server_1_6_branch so there isnt much more in 1.7 on the graphics side IMO [23:19] there is a list of proposed pulls from master into 1.6 branch that we could look into adding to 1.6.2 in karmic http://www.x.org/wiki/Server16Branch [23:20] the front buffer rendering fixes and dri2proto 2.1 were what i was worried about that lead to me making the PPA for master in the first place [23:22] yeah my PPA needs some work to get testing done, alot more components build now and i havent reviewed the patches to see why things dont apply, if they were upstream or just need refreshing or didnt apply at all anymore due to changes [23:23] its just centered around a works for me scenario and doesnt take into account that people might actually use xephyr or kdrive and such :D [23:24] yeah at some point during the release cycle I'll shift focus to xserver crash bugs, and agreed we should look into pulling patches from that proposed branch [23:26] hopefully if there's no 1.7 in time we at least see a 1.6.2 out. [23:26] i dont think xserver 1.6.2 is far off from release, kpackard was saying he wanted to get it out the door that day in #xorg-devel last week but didnt happen, they pulled the dri2 stuff into 1.6 branch post 1.6.1.901 that we have though [23:26] sorry keithp :) [23:28] superm1's bug is tricky, does anyone know if there is no pci id file but an xorg.conf exists if the internal xserver detection mechanisms will work similar to not having an xorg.conf in that situation? [23:28] because if so adding a switch and case check for 0840 and 0860 id's to make them default to vesa in xserver will work [23:28] Sarvatt: no new mesa 7.5 build for jaunty? (last one is from june 22nd) [23:29] i just uploaded a new one! [23:29] did it not take? [23:29] Sarvatt: ah yes I got it! [23:29] mesa - 7.5.0~git20090626+mesa-7-5-branch.2d865034-0ubuntu0sarvatt [23:29] I checked 10 minutes ago and there was nothing :p [23:29] :) [23:29] lol yeah it was building [23:30] thx! [23:30] no worries! [23:30] sorry i'm a little negligent about updating jaunty [23:30] Sarvatt: I'm looking at superm1's bug currently... [23:31] if i could get him to confirm it works right when nv.ids isnt installed it'd be a _really_ simple fix [23:31] the 170_primary_pci_video_device.patch patch jerone said fixed it in jaunty is still present in karmic... [23:31] the patch that actually fixed it in jaunty was default_to_vesa [23:31] Sarvatt: think he's in texas so maybe he's off work at happy hour or something ;-) [23:31] ahh [23:31] ahh [23:32] jinx [23:32] :D [23:32] 0840 and 0860 ids need to be explicitly defaulted to vesa instead of nv really bad [23:32] ok [23:33] they already are by the nv.ids not matching but it screws up when its a hybrid and the unused device actually is supported by nv [23:33] (since its the first device out of the two) [23:33] *&$^ hybrids [23:36] ;-) [23:37] how fedora does it -- they dont install ids, and they add a check for 084x and 086x devices in hw/xfree86/common/xf86AutoConfig.c in xserver and tell it to use vesa if those match [23:37] instead of "case 0x10de: case 0x12d2: driverList[0] = "nv"; break;" which matches nvidia unconditionally, they have it doing [23:38] http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/F-11/xserver-1.6.1-nouveau.patch?view=markup [23:38] easier that way [23:38] too much to paste :D [23:38] looking [23:38] the bottom part [23:39] top part is just to shut up a nouveau AIGLX error in xorg.0.log because there is no dri for nouveau [23:39] right [23:40] doesnt help he works for dell and they have a thing for these silly hybrids that the x people refuse to work with :D [23:40] yeah sure we could do something like that [23:40] thats only going to fix it if the nv.ids isnt installed though [23:40] as far as i can see [23:41] because it'll still try to use nv because the not in use device is matched as supporting in nv.ids [23:41] it might _just work_ magically if the nv.ids isnt installed and the driver can do its detection methods instead of getting matched in the id's and forced though [23:41] which is what i'm unsure of [23:42] yeah, might be worth experimenting with [23:42] I'm really not certain how we should handle *.ids for karmic [23:42] guess we need to come to a decision on that [23:42] i'll copy -nv from edgers without the nv.ids install and ask him to try that [23:43] if we're going to drop *.ids processing, then we may as well move ahead with that now, so we can get stuff straightened out by alpha-3 [23:43] ok [23:43] ids are really bad if you ask me in some instances because every driver seems to handle it differently in the post pciaccess world, dropping nv.ids from -nv is going to open up ALOT more chips working right with -nv [23:43] if we're going to keep .ids's for karmic, then maybe we need to look into improving the heuristics to account for the hybrid hardware better [23:44] but it looks like ati handles ids being installed fine because they add everything to a table that can extract it right [23:44] can we drop .ids support on a per-driver basis? [23:44] maybe we should do it for -nv first to test the waters? [23:44] -nv has a ton of case checks for supported cards and doesnt add them to the table that 01_gen_pci_ids.diff pulls the ids from [23:46] plus debian has dropped pci id installs globally in every driver that i've seen and is working to fix the server detection methods instead of using that hack [23:46] mm [23:46] tjaalton and jcristau are the ones to ask really, i'm not knowledgeable enough about it to give an opinion on it, just seeing the problem in -nv with it gone and it looks like dropping it in -nv helps alot [23:51] i _really_ think this bug is bogus and the patch should be dropped from -nv by the way https://bugs.edge.launchpad.net/bugs/321613 [23:51] Ubuntu bug 321613 in xserver-xorg-video-nv "9100m G card (for acer aspire 4350)" [Undecided,Fix released] [23:52] (9100m G falls under 0840 and 0860 that dont work in -nv that fedora explicitly makes use vesa in that patch i linked above) [23:54] i'll copy nv without the nv.ids installed to an empty ppa and ask people to try it to get some feedback on dropping nv.ids in karmic for that driver [23:55] its just mainly a problem on the livecd's IMO, who uses -nv outside of that situation? :D [23:57] Sarvatt: processing your intel-gpu-utils package now... all looks good, only (picky) detail is to indent the second bullet point (about the changelog) one level since it's a ubuntu change since the last version [23:58] anyway, other than that all looks good... upload sponsored :-) [23:59] oh, I cut and pasted that from your changelog!