| * RAOF fires up his radeon system. | 00:00 | |
| RAOF | That patch fixed it for me, and is broadly correct. | 00:00 |
|---|---|---|
| Daekdroom | Well, what was that fix for anyway? | 00:00 |
| Daekdroom | Because I'm getting a very similar traceback call. | 00:01 |
| RAOF | Reference-count DRI2 buffers and take a ref when scheduling a swap so that the buffers are still valid when the vblank event occurs. | 00:01 |
| RAOF | The problem was when a client sent a SwapBuffers request and then quit before the swap was complete. That would result in it's buffers being freed, but the swap-complete callback would still try to use them. | 00:02 |
| RAOF | There was also a similar -intel problem that got fixed in a similar way. | 00:03 |
| Daekdroom | RAOF, http://pastebin.com/RT9sizAq | 00:03 |
| Daekdroom | That's from earlier today. | 00:03 |
| RAOF | That looks like a different trace to me; you don't happen to have a second system so you could attach gdb and get a proper backtrace? | 00:05 |
| Daekdroom | No second system, unfortunately. | 00:05 |
| Daekdroom | But yeah, it looks slightly different to me, but didn't happen untill today | 00:05 |
| RAOF | Booo. How easy is it for you to reproduce this? | 00:05 |
| Daekdroom | Just open this specific Wine program, why? | 00:06 |
| RAOF | Well, because you could give me ssh access and I could gather a proper backtrace :) | 00:06 |
| Daekdroom | I don't like handling ssh :S | 00:06 |
| RAOF | Well, you can find my public keys on launchpad. | 00:08 |
| RAOF | Alternatively, you can _kinda_ get a proper backtrace on one system, but it's a bit faffy. | 00:08 |
| RAOF | Oh! | 00:08 |
| RAOF | What wine program? | 00:08 |
| Daekdroom | Huh, a game plataform called BYOND. | 00:09 |
| RAOF | Linky? | 00:09 |
| Daekdroom | Tried to reproduce it somehow in a native app and still didn't find a single one | 00:09 |
| RAOF | I mean, I could try running it :) | 00:09 |
| Daekdroom | RAOF http://www.byond.com/ trying to run a game with hardware 2D acceleration, regardless if OpenGL or DirectX will cause a instant Xcrash | 00:10 |
| Daekdroom | I still have quite a few other native apps here I can try | 00:10 |
| RAOF | I'll give byond a whirl. If you find another app which exhibits the crash, pipe up :) | 00:12 |
| Daekdroom | Ok, I'll dig it. | 00:12 |
| RAOF | Daekdroom: Bah. Any tips for running byond in wine? | 00:39 |
| Daekdroom | RAOF, oh, msvcrt | 00:40 |
| Daekdroom | Forgot to mention that override | 00:40 |
| RAOF | Which version? | 00:40 |
| Daekdroom | I use the vc6run one from winetricks | 00:40 |
| Daekdroom | *vb6run | 00:41 |
| Daekdroom | Ah, nvm, vcrun6 | 00:41 |
| Daekdroom | Hm, yeah, that last one | 00:41 |
| RAOF | And what game kills it for you? | 00:43 |
| RAOF | Well, that's promising ): | 00:45 |
| RAOF | :) | 00:45 |
| RAOF | Find a winning crasher? :) | 00:46 |
| Daekdroom | RAOF, apparently, any game as long as I try to activate 2d hardware accel | 00:46 |
| Daekdroom | (that, of course, requires the game to have graphics) | 00:46 |
| RAOF | Sweet. That just killed it. | 00:47 |
| Sarvatt | RAOF: http://sarvatt.com/git/cgit.cgi/mesa.debian/ in case it helps any, going to try to do the rest tomorrow | 00:58 |
| RAOF | Sarvatt: Thanks muchly. | 00:59 |
| Sarvatt | still have the problem with demos though, the majority of that crap doesn't have any license :( i've got a really crappy package started here http://sarvatt.com/downloads/mesa-demos/ | 01:01 |
| Sarvatt | seems like its a bit too late for a r300g | 01:02 |
| RAOF | Indeed it does. | 01:03 |
| RAOF | Particularly since it breaks ums support. | 01:03 |
| RAOF | Re mesa-demos: I'd like to ship all the demos, but that can wait for Natty. | 01:05 |
| Sarvatt | maybe we should just just rip the ones we want out and put them in a subdirectory in the mesa tarball since we're repacking it, and have a seperate build step? | 01:06 |
| RAOF | Are we repacking the mesa tarball still? | 01:06 |
| Sarvatt | yeah its still split into 2 | 01:07 |
| Sarvatt | or will be that is | 01:07 |
| RAOF | MesaLib and… ? | 01:07 |
| Sarvatt | did MesaGLUT move too? | 01:08 |
| * Sarvatt looks | 01:08 | |
| RAOF | From what I can see we don't build glut from the mesa source package at the moment anyway. | 01:11 |
| RAOF | Oh, poot. How are we getting an invalid buffer there? | 01:27 |
| RAOF | Oh, whoops! | 03:57 |
| RAOF | Mea culpa. | 03:57 |
| hyperair | Sarvatt: what? dkms packages for phc? where?! | 04:35 |
| hyperair | Sarvatt: and i thought the cpufreq governer was builtin rather than built as a module so phc couldn't be built as a module? | 04:35 |
| === freeflyi1g is now known as freeflying | ||
| NCommander | Does anyone know if this symbol still exists in our version of Xorg? | 09:57 |
| NCommander | XF86VidModeSetViewPort | 09:57 |
| tjaalton | libxxf86vm1 | 09:59 |
| jcristau | that's not in Xorg... what tjaalton said | 09:59 |
| === yofel_ is now known as yofel | ||
| kklimonda | hmm.. any known problems with nouveau locking up? I get one when using firefox from time to time. Only thing in /var/log/messages I can see is [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2. After that I can't even kill X with sysrq+k - console flashes for a second, I can see [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon and then I'm back to frozen X. | 10:59 |
| kklimonda | up to date maverick, no ppas enabled | 10:59 |
| RAOF | kklimonda: That kernel message is the GPU locking up; what GPU do you have? | 11:06 |
| kklimonda | RAOF: nVidia Corporation G84M [Quadro NVS 140M] (rev a1) | 11:09 |
| RAOF | Gah. | 11:15 |
| RAOF | That's not particularly known, but there's not a huge set of debugging options for nouveau. | 11:17 |
| kklimonda | RAOF: anything I can do to help? :) | 12:58 |
| RAOF | If you can find a dependable trigger it'd be useful and poke it upstream. | 13:05 |
| RAOF | Sarvatt: I've pushed my work on those mesa packages to ubuntu-maverick on pkg-xorg; feel free to pick it up and run with it if you've got time today :) | 13:09 |
| ion | sarvatt: Is the new fglrx release in x-updates compatible with the current xserver-xorg? (It would be really nice if it had a Breaks relation to incompatible ABIs.) | 14:04 |
| Sarvatt | ion: I don't know, they dont mention it in the release notes when they make it work with newer ones and I dont have anything to test it on :) | 14:05 |
| ion | Hehe | 14:05 |
| dandel | ion, if your talking about fglrx 8.76.7, it works just fine on ubuntu 10.04 | 14:05 |
| ion | maverick | 14:05 |
| Sarvatt | RAOF: SWEET, I'm on it now | 14:05 |
| === simar__mohaar is now known as simar | ||
| tseliot | ion: no, there's no fgrlx for maverick yet | 15:02 |
| Sarvatt | RAOF: any opinions regarding dri-experimental shipping gallium drivers with the same name as dri? should I just set up diversions for now? | 15:02 |
| Sarvatt | radeong got renamed to r300 screwing up my ddx patch to allow both installed side by side, could rename it as part of the build and go that route but it seems a dead end and other gallium drivers like the intel ones and swrast still wont work that way | 15:03 |
| Sarvatt | r300 is the only extra one i'd like to throw in -experimental really though so maybe we should do that still. I can't decide whats more evil, patching a ddx to allow loading a different dri driver name or adding a diversion | 15:05 |
| Sarvatt | anyone have any opinions on that? :) | 15:07 |
| Sarvatt | http://www.mail-archive.com/xorg-devel@lists.x.org/msg09741.html -- said ddx patch | 15:08 |
| tjaalton | I'm for the simplest approach; ship the gallium version as r300_dri | 15:16 |
| tseliot | Sarvatt: I like your patch better, even though it can add maintenance burden. Oh and did I mention the fact that I hate diversions ;) ? | 15:16 |
| tjaalton | it's experimental anyway | 15:16 |
| tjaalton | package, driver less so I hear ;) | 15:17 |
| jcristau | just decide whether you want to ship r300c or r300g | 15:18 |
| tjaalton | i think it should be decided for nutty anyway | 15:19 |
| tjaalton | hmm, or what was it called again | 15:19 |
| tjaalton | ah, well nutty feels about right here ;) | 15:19 |
| Sarvatt | its too late to do r300g as the main one and many people will complain about losing accelerated 3D in UMS but r300g is the better of the two, ugh | 15:23 |
| Sarvatt | yeah I like nutty too :) | 15:23 |
| Dr_Jakob | Sarvatt: you could ship both and have the X driver return different names depending if you have UMS or KMS. | 15:37 |
| jcristau | Dr_Jakob: i suspect ums is getting uninteresting quite fast | 15:37 |
| Sarvatt | Dr_Jakob: my patch does that | 15:38 |
| Sarvatt | it only allows gallium in the dri2 path | 15:38 |
| Sarvatt | i just didn't make gallium the default in that one | 15:38 |
| Dr_Jakob | ah ok | 15:39 |
| Dr_Jakob | never mind then... | 15:39 |
| dandel | I'm proposing a few package changes, however, i need some help from an nvidia guy who has OpenCL support working on their system. | 15:41 |
| jg | Sarvatt, my bug exists in jbarnes' latest git. Oh well... | 16:18 |
| Sarvatt | ok everything seems to be working (egl/gles/vg/etc), time to go over http://sarvatt.com/downloads/filelist_mesa_7.9.txt to make sure everything is right | 16:18 |
| Sarvatt | jg: dang, sorry man :( jbarnes mentioned even the windows drivers are having all kinds of eDP bugs yesterday | 16:19 |
| jg | Sarvatt: yeah, well I can finally build at test for jbarnes, when he has a spare moment. And it was known to work at one point, so we can see the register state in working vs. non-working. | 16:20 |
| jg | unfortunately, that kernel won't resume properly, but at least the machine is no longer an expensive paperweight. | 16:22 |
| Sarvatt | I guess r300c is the way to go in maverick, i'll just fork the packaging for xorg-edgers again and make r300g the only option :) | 16:33 |
| Sarvatt | anyone know if there is something special that needs to be done to use the egl _screen versions of the mesa demos? | 16:33 |
| Sarvatt | the _x11 ones work fine | 16:33 |
| Sarvatt | osmesa demos don't build, a bunch of talloc undefined references | 16:34 |
| Sarvatt | uploaded a preliminary mesa 7.9 here - https://edge.launchpad.net/~sarvatt/+archive/mesa | 17:13 |
| Sarvatt | and holy crap mesa builds fast with DEB_BUILD_OPTIONS='parallel=24', 4 minutes! :D | 17:14 |
| Sarvatt | this needs some serious review by the arm people to see if there are any problems | 17:15 |
| Sarvatt | hopefully there's a mesa RC soon to rebase this onto | 17:43 |
| tseliot | Sarvatt: do you have 23 cores??? | 17:46 |
| Sarvatt | the machine i'm building on has 24 yeah | 17:46 |
| tseliot | then I think you could have done DEB_BUILD_OPTIONS="parallel=25"? (I think it's nr. of cores +1) | 17:47 |
| jcristau | depends. | 17:47 |
| tseliot | on what? | 17:47 |
| tseliot | (I'm curious) | 17:48 |
| Sarvatt | 12 of those are hyperthreaded, 24 is probably overkill :) | 17:48 |
| jcristau | tseliot: at some point you're io bound anyway | 17:48 |
| Sarvatt | its got a real slow disk too | 17:48 |
| tseliot | yes, I see what you mean | 17:48 |
| bilalakhtar | I would like to report a problem. Whenever I boot maverick with all updates, the GDM login comes. If I press any key from now on, X shuts down instantly and starts again in a second or two. This happens only once. After the second start, it behaves properly. Is this fine? | 17:57 |
| jcristau | no | 17:57 |
| bilalakhtar | s/Is this fine?/Is anyone else facing this problem/g | 17:58 |
| bilalakhtar | jcristau: ^^ | 17:58 |
| jcristau | no idea about that one. | 17:59 |
| Sarvatt | jg: looks like someone else has to use 2.6.35-rc6 on your same laptop too - http://blog.mydream.com.hk/howto/ubuntu-10-10-maverick-with-hp-elitebook-2540p | 18:04 |
| jg | Sarvatt: I just filed a proper bug report at: https://bugs.freedesktop.org/show_bug.cgi?id=29821 | 18:05 |
| ubot4 | Freedesktop bug 29821 in DRM/Intel "eDP screen "flashes" on and off after boot." [Critical,New] | 18:05 |
| tjaalton | i've got a hp blade with 12 cores hyperthreaded to 24 "cores" _and_ fast disks. I'll test some insane builds on it before it's put into production :) | 18:06 |
| tjaalton | oh and 96GB memory | 18:06 |
| tjaalton | could just build it in a ramdisk | 18:07 |
| Sarvatt | hmm libdrm-nouveau1 seems to be holding back a lucid -> maverick release upgrade - http://pastebin.com/6hQKa08c | 18:10 |
| Sarvatt | tjaalton: sweet! this just has 512mb memory and 10gb of virtualized disk space :) | 18:15 |
| * Sarvatt loathes OpenVZ | 18:16 | |
| === apachelogger is now known as apache2logger | ||
| tjaalton | http://pastebin.com/CHCufLTN | 18:17 |
| tjaalton | the packaging phase is single-threaded, so it took 5m46s in total | 18:17 |
| ion | What’s that top-like software? | 18:19 |
| tjaalton | htop | 18:19 |
| ion | thanks | 18:19 |
| ion | D’oh. I already have installed it in the past, but completely forgotten about it. | 18:20 |
| Sarvatt | htop ftw! | 18:20 |
| Sarvatt | tjaalton: whats the speed on those xeons? | 18:21 |
| tjaalton | Sarvatt: 2.67GHz | 18:21 |
| tjaalton | time debian/rules build took 2m3s | 18:21 |
| Sarvatt | yeah thats like twice as fast, the 4 minutes wasn't packaging | 18:23 |
| tjaalton | heh, ok | 18:23 |
| Sarvatt | ok I dropped the Breaks: xserver-xorg-video-nouveau (<< 1:0.0.16) from libdrm-nouveau1 in maverick's package, versioned it higher than what's in maverick's archive and now I can dist upgrade from lucid to maverick, can anyone think of any other way to fix that? :) | 18:54 |
| cnd | jcristau, are you about? | 18:59 |
| jcristau | cnd: sort of | 18:59 |
| cnd | I see that you're the author of config/udev.c in xserver | 19:00 |
| cnd | I wanted to know your thoughts on how best to resolve an issue I'm having | 19:00 |
| cnd | do you have the time to chat about it? | 19:00 |
| jcristau | yep? | 19:01 |
| cnd | so I want to be able to use an InputClass to match just the Apple Magic Trackpad | 19:03 |
| cnd | unfortunately, the apple bluetooth input products rename themselves after being configured by a user in os x | 19:04 |
| cnd | so my trackpad now says it's product name is "cndougla's trackpad" | 19:04 |
| jcristau | ugh | 19:04 |
| tjaalton | :D | 19:04 |
| Sarvatt | fun! | 19:04 |
| jcristau | does apple ever do anything right? | 19:04 |
| cnd | unfortunately, I don't see any great way to fix this | 19:04 |
| cnd | but I also see bugs in the udev code | 19:04 |
| jcristau | can we match on product id instead of name? | 19:05 |
| cnd | for example, even on usb devices, the wrong udev node is checked for the usb id | 19:05 |
| cnd | the parent node should be checked it seems, but the event* node is checked | 19:05 |
| cnd | so usb devices don't even get usb_id set properly anymore | 19:05 |
| cnd | on top of that, the usb device ids listed for bluetooth devices is the device ids of the bluetooth receiver | 19:05 |
| cnd | not the actual device | 19:06 |
| cnd | the only way to get the actual device id is to parse the modalias | 19:06 |
| cnd | jcristau, so, I'm wondering if you have any good ideas of how we should deal with this :) | 19:06 |
| Sarvatt | can you tag it in udev and MatchTag? | 19:06 |
| cnd | Sarvatt, you could, but tags are limited | 19:07 |
| cnd | tags are meant to say what class of device it is | 19:07 |
| cnd | and if we start using bits for individual devices, we'll run out quickly :) | 19:07 |
| cnd | apple already does this renaming for at least three devices I have | 19:07 |
| jcristau | we don't have the device id in the udev db except in the modalias? | 19:07 |
| cnd | jcristau, correct, for bluetooth devices | 19:08 |
| jcristau | fun.. | 19:08 |
| cnd | I think for all bluetooth devices, but I only have my apple gear | 19:08 |
| cnd | I'm willing to write a patch for the udev parsing | 19:08 |
| cnd | I just want to make sure you can't think of any better way | 19:08 |
| jcristau | not really, this sounds ugly | 19:09 |
| cnd | for example, maybe it's better to define a udev rule for bluetooth devices to parse the modalias for the device id instea | 19:09 |
| cnd | d | 19:09 |
| jcristau | might want to talk to #udev or linux-hotplug@vger | 19:09 |
| cnd | yeah, I'll ask | 19:09 |
| cnd | jcristau, my current thinking is to have a bluetooth udev rule parse the modalias and then set the product and vendor ids from the data | 19:12 |
| cnd | but xserver will still need a patch to look for the usb ids on the parent node instead of the device node | 19:12 |
| cnd | so just fyi that I'll be looking into this | 19:12 |
| jcristau | ok | 19:13 |
| cnd | jcristau, I think it may be possible to get the id a different way | 19:23 |
| cnd | I'm not terribly familiar with udev | 19:23 |
| cnd | it's not obvious how to get all the data out of udevadm :) | 19:23 |
| jcristau | udevadm info --export-db should have most of it | 19:23 |
| cnd | jcristau, I don't see any attrs though | 19:24 |
| cnd | that's where I get confused | 19:24 |
| cnd | there's attrs, and then there's properties | 19:24 |
| cnd | what's the difference? | 19:24 |
| Sarvatt | oh hmm, got a reply saying something might be able to be done to work around the libdrm Breaks: screwing up dist-upgrade in update-manager. that'd certainly be better than dropping the breaks | 20:27 |
| mvo | Sarvatt: bug #614993 you mean? | 20:29 |
| ubot4 | Launchpad bug 614993 in update-manager (Ubuntu) (and 1 other project) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: Holding Back xserver-xorg-video-nouveau rather than change xorg-video-abi-8.0 (affects: 7) (dups: 5) (heat: 58)" [High,Confirmed] https://launchpad.net/bugs/614993 | 20:29 |
| Sarvatt | yeah | 20:29 |
| mvo | Sarvatt: IIRC a conflict helped (instead of the break) when I looked with that problem, the resolver is sometimes a bit dumb | 20:30 |
| Sarvatt | i couldn't work out an easy way to test that, i did try it but couldn't get update-manager to let me do a release upgrade without patching/rebuilding x-x-v-nouveau 0.0.16 too | 20:31 |
| Sarvatt | since the conflicts left things in a broken state | 20:31 |
| mvo | Sarvatt: I played with it by patching /var/lib/apt/lists/archive.ubuntu.com*maverick*main*Packages and let apt go wild on it, but of course that is rather hackish | 20:32 |
| mvo | Sarvatt: I can have a look again tomorrow, today I'm a bit too tired for anything complicated | 20:33 |
| Sarvatt | removing the breaks: was a bad idea, it ended up deciding to hold x-x-v-nouveau back to 0.0.15 which held back all of x from upgrading until i did a sudo apt-get install xserver-xorg-video-nouveau/maverick :) | 20:58 |
| Daekdroom | RAOF, just noticed from MaverickChanges that you fixed it. Thank you :) | 23:20 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!