| Sarvatt | eww, 7 boots in a row getting failsafe, thanks for the hint that fbdev works at least :D | 00:50 |
|---|---|---|
| Sarvatt | xorg metapackage, brltty, ntp, ifupdown, dhcp3-client, mountall, console-setup. something in that round of updates broke startup for me, hmm | 00:57 |
| Sarvatt | or xorg-server actually.. http://paste.ubuntu.com/342254/ | 01:00 |
| Sarvatt | anyone else come in here this afternoon saying x wouldnt start? :) | 01:01 |
| JanC | Sarvatt: I think I saw bryce & others talking about something like that | 01:04 |
| JanC | where "like that" == people getting failsafe X | 01:05 |
| JanC | it was something related to dkms IIRC | 01:06 |
| geser | Hello, I've installed lucid alpha on my new Dell mini 10v and the touchpad is driving me crazy. Drag&Drop is nearly impossible to do as the cursor jumps into the upper right corner as soon as I try to do it. | 09:58 |
| geser | is this a known problem? and are any workarounds known? | 09:59 |
| hyperair | only drag&drop? | 09:59 |
| seb128 | I've no such issue there | 10:01 |
| tseliot | I can't reproduce the problem here | 10:02 |
| geser | if I only use one finger it's ok but when I try to do a quick click and use an other finger it jumps too | 10:02 |
| tseliot | with the Mini 10v | 10:02 |
| tseliot | maybe you're missing the udev rules for synaptics? | 10:03 |
| tseliot | tjaalton: I assume that my patch for synaptics is already in Lucid | 10:03 |
| tseliot | the one about the jumpy cursor | 10:03 |
| tjaalton | tseliot: actually no, it's in git though | 10:04 |
| geser | which package are they in? (I used http://cdimages.ubuntu.com/ubuntu-netbook-remix/daily-live/current/ for installation) | 10:04 |
| tseliot | geser: then it's because my patch is not in Lucid yet, as tjaalton said | 10:04 |
| tseliot | tjaalton: can you upload it, please? | 10:04 |
| seb128 | I'm getting the issue too using 2 fingers there... | 10:05 |
| tjaalton | tseliot: sure | 10:05 |
| * tseliot will become core-dev soon (hopefully) and won't have to bug other core-devs (too much) for uploads ;) | 10:05 | |
| tseliot | thanks | 10:05 |
| tseliot | seb128: yes, that's expected, without my patch | 10:06 |
| seb128 | ok | 10:07 |
| tjaalton | tseliot: uploaded | 10:08 |
| tseliot | thanks | 10:08 |
| virtuald | mew | 10:43 |
| geser | tseliot: I've tested the new package and the touchpad works fine now. Big thanks. | 11:17 |
| tseliot | geser: good, thank tjaalton for the upload ;) | 11:18 |
| geser | tjaalton: thanks for the upload :) | 11:19 |
| tjaalton | np :) | 11:20 |
| === ripps is now known as ripps|sleep | ||
| bjsnider | tseliot, for some reason as yet undetermined, the nvidia 195 blob is almost twice the size (70MB) of the 185/190 drivers | 14:41 |
| bjsnider | i thought you might find that interesting/puzzling, but maybe i'm wrong | 14:41 |
| tseliot | bjsnider: are you referring to the whole package? | 14:42 |
| bjsnider | pkg1/pkg2 combined | 14:42 |
| tseliot | bjsnider: you should use pkg0/pkg2 instead | 14:43 |
| bjsnider | the 64 nvidia package is 39.1 MB. the previous one was 22 | 14:43 |
| tseliot | bjsnider: maybe they're shipping bigger and/or more libraries? | 14:44 |
| tseliot | I'm working on the new packaging scripts for Lucid and I'll start with 190 | 14:44 |
| bjsnider | i think i'm using the right packages. i've been doing this for awhile. i just can't figure out what the hell they've put into this driver to make it so much bigger | 14:45 |
| tseliot | bjsnider: pkg1 has some prebuilt modules which pkg0 doesn't have (for 32 bit) | 14:45 |
| tseliot | prebuilt for suse, redhat, etc. | 14:46 |
| bjsnider | yeah, pkg1 is also almost twice as big as before | 14:46 |
| bjsnider | i mean i know they've been gradually growing, but this is a huge leap in size | 14:46 |
| tseliot | ok, thanks for reporting | 14:47 |
| bjsnider | tseliot, in the new scripts, is it possible to have most of the version numbers as variables? it is such a pain in the butt when a new driver comes out to change all of the numbers | 14:47 |
| bjsnider | like it is in the .in files | 14:48 |
| tseliot | bjsnider: yes, the new scripts will be much saner to maintain | 14:48 |
| bjsnider | awesome | 14:48 |
| tseliot | and to use | 14:48 |
| tseliot | :-) | 14:48 |
| bjsnider | and you're putting everything into one package, or so i hear | 14:49 |
| bjsnider | but debian is going in the opposite direction | 14:49 |
| tseliot | right | 14:50 |
| tseliot | but I'll talk to the debian maintainers when I'm done. I think we can share at least part of the code with them | 14:51 |
| bjsnider | i'd like to backport the changes you're implementing. any idea whent hey might be done? | 14:52 |
| bjsnider | or can i help? | 14:52 |
| tseliot | backport to what? Karmic? | 14:52 |
| bjsnider | indeed | 14:53 |
| tseliot | it can turn into an utter mess | 14:53 |
| bjsnider | i already implemented the minor changes in mario's ppa | 14:54 |
| bjsnider | i'd say the current one is an utter mess | 14:54 |
| tseliot | I'll use alternatives instead of diversions in mesa, fglrx and nvidia | 14:54 |
| tseliot | yes, the current one is an utter mess (which is part of the problem for a backport) | 14:54 |
| bjsnider | well, blob users face those types of issues when switching from packaged versions to nvidia's installer as well. they know what they're getting into. | 15:03 |
| tseliot | bjsnider: usually they don't. Furthermore I'm going to prevent problems with the nvidia installer from happening | 15:09 |
| tseliot | but if you warn them, then it's ok | 15:12 |
| federico1 | hmm, no tseliot | 19:24 |
| bjsnider | he was here earlier | 19:30 |
| bjsnider | the ddos attacks have kicked everybody off from time to time | 19:31 |
| federico1 | bryce: ping? | 19:39 |
| bryce | hi federico1, what's up? | 19:44 |
| federico1 | bryce: my man | 19:46 |
| federico1 | bryce: tseliot mentioned that he's interested in the moblin patches to do transformations in the GnomeRR API | 19:46 |
| federico1 | bryce: but we didn't have a chance to discuss what that would actually be used for | 19:46 |
| bryce | mm ok | 19:46 |
| federico1 | bryce: do you know anything about that? | 19:46 |
| bryce | no, hadn't discussed it with him. | 19:47 |
| federico1 | in moblin I think we just use transforms to implement cloning by scaling the display, if one of them doesn't support the same resolution | 19:47 |
| bryce | my guess is that it's for an OEM project for some hardware | 19:47 |
| bryce | there was one question that I heard of where they needed a zoom functionality but couldn't use compiz | 19:48 |
| bryce | another question involved supporting multi-head on an i945 chip that was limited to 4k x 4k so they wanted a workaround to allow external monitors to work with large resolutions | 19:49 |
| federico1 | haven't heard about the zooming one | 19:49 |
| federico1 | the other one is a *constant* source of pain for us | 19:49 |
| federico1 | some stupid OEMs can't make up their minds on whether they want 3D or external monitors | 19:50 |
| federico1 | (not even Windows supports both) | 19:50 |
| bryce | I don't know if his question to you was in relation to either of those or something completely different | 19:50 |
| federico1 | bryce: ok, I'll ping him later | 19:50 |
| bryce | yeah we need xinerama back on intel... | 19:50 |
| bryce | federico1, hey btw a side question to you | 19:51 |
| federico1 | bryce: sure | 19:51 |
| bryce | one thing we've been doing in ubuntu is modify xserver to re-throw signals, so if X crashes we have a tool (apport) which collects the backtrace and auto-files the bug report | 19:51 |
| bryce | I maintain the patch to rejigger the signal handling myself, but have wondered if it would be of any interest outside ubuntu. do you guys do anything like that for crash handling? | 19:52 |
| bryce | the patch is kind of invasive and ugly so I've been afraid to propose it upstream ;-) | 19:52 |
| bryce | federico1, an example of the kinds of bug reports we are able to generate with this type of thing - https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/459402 | 19:55 |
| ubottu | Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/459402) | 19:56 |
| federico1 | bryce: one sec | 20:03 |
| federico1 | bryce: interesting but scary :) | 20:04 |
| federico1 | bryce: do you need any kind of user input? if the X server is toast, you can't get much input... :) | 20:04 |
| bryce | federico1, right, apport stores a .crash file on /var when this happens, then on a later reboot it prompts them, displays the bug filing page, etc. | 20:07 |
| bryce | federico1, heh, ok, I think you answered my question :-) | 20:08 |
| federico1 | ah, okay | 20:11 |
| federico1 | makes sense | 20:11 |
| federico1 | hmmmmmmmmm | 20:11 |
| federico1 | I'm not very sure what we do these days in opensuse about automatic crash reports | 20:12 |
| federico1 | since bug-buddy got broken beyond all recognition a few years ago, it has been kind of spotty | 20:12 |
| federico1 | bryce: anyway, I'm documenting all of this here: http://en.opensuse.org/Moblin/RANDR | 20:30 |
| bryce | federico1, thanks I'll pass it along to tseliot | 20:47 |
| tormod | what's this (vdso) (__kernel_rt_sigreturn+0x0) that I get in Xorg backtraces? | 20:53 |
| tormod | http://paste.ubuntu.com/342983/ | 20:55 |
| === ubott2 is now known as ubottu | ||
| bryce | tormod, realtime kernel? | 20:59 |
| bryce | tormod, probably a sconklin question (#ubuntu-kernel?) | 20:59 |
| tormod | bryce, don't think so: 2.6.32-8.12-generic | 20:59 |
| tormod | I noticed that Sarvatt's pastebin earlier had (vdso) (__kernel_sigreturn+0x0) | 21:00 |
| bryce | does the v in vdso stand for virtual? | 21:00 |
| bryce | rt == run-time | 21:02 |
| bryce | tormod, how's your memory situation? | 21:03 |
| tormod | probably, but I have no idea why I have "rt". memory is 1GB | 21:03 |
| tormod | if you talk about my laptop and not me :) | 21:04 |
| bryce | heh | 21:04 |
| tormod | but how it was at the time of the crash I don | 21:05 |
| bryce | tormod, hmm well looks like kernel was unhappy about something (low memory, bad system call or some such) and raised a signal | 21:05 |
| bryce | the call appears to be a fairly standard signal raising routines if google is to be trusted | 21:05 |
| bryce | can you repro the problem? I've got a rewrite of the xserver signal handling patch if you'd like to give that a try? | 21:06 |
| tormod | this things happen if I switch from console to X (with radeon, stock lucid) | 21:06 |
| tormod | I think I heard about a similar issue on intel before | 21:06 |
| bryce | mm, so could be failing to map some memory during the switch | 21:07 |
| bryce | if you can repro it easily enough, maybe try gdb'ing it | 21:07 |
| bryce | maybe we can get more info that way? | 21:07 |
| tormod | ok will try | 21:08 |
| tormod | this is on my USB stick install (poor man's SSD), but I don't see it on my HD install which has xorg-edgers | 21:10 |
| tormod | ok will try now, guess that means brb | 21:11 |
| bryce | tormod, ok xserver with refreshed apport signal handling hook patch is at https://edge.launchpad.net/~bryceharrington/+archive/blue | 21:14 |
| bryce | tormod, ok xserver with refreshed apport signal handling hook patch is at https://edge.launchpad.net/~bryceharrington/+archive/blue | 21:27 |
| tormod | bryce, thanks, I guess gdb is fine: http://paste.ubuntu.com/343010/ | 21:29 |
| bryce | interesting, no kernel_rt_sigreturn call this time? | 21:33 |
| tormod | nope | 21:34 |
| bryce | according to my source, it's crashing on this line? radeon_cs_space_add_persistent_bo(info->cs, driver_priv->bo, RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM, 0); | 21:35 |
| bryce | mm, could crash if driver_priv == NULL; that looks unchecked | 21:36 |
| bryce | or something inside radeon_cs_space_add_persistent_bo(), however I think that symbol would have been in your stack trace if it descended into it | 21:36 |
| bryce | hmm this is weird | 21:39 |
| bryce | exaGetPixmapDriverPrivate() gets called twice in that routine | 21:39 |
| tormod | one with src one with dst | 21:39 |
| bryce | mm | 21:40 |
| bryce | FUNC_NAME(RADEONPrepareSolid) also has a pair of calls | 21:40 |
| bryce | and in the second of those, it does a NULL ptr check | 21:40 |
| bryce | driver_priv = exaGetPixmapDriverPrivate(pPix); | 21:40 |
| bryce | if (driver_priv) | 21:40 |
| bryce | info->state_2d.dst_bo = driver_priv->bo; | 21:40 |
| bryce | makes me wonder if ALL of these calls need such a check | 21:41 |
| bryce | tormod, if you have this up in gdb, next thing I'd do is check if indeed driver_priv is NULL before dereferencing driver_priv->bo | 21:42 |
| bryce | or alternatively, insert a print statement | 21:42 |
| bryce | like: if (driver_priv == NULL) | 21:42 |
| bryce | RADEON_FALLBACK(("driver_priv is NULL\n")); | 21:42 |
| tormod | no, I have rebooted, and it got totally stuck after I tried to stop X | 21:43 |
| * bryce speculates | 21:43 | |
| bryce | maybe during the console->X switch there is a brief period where the driver privates aren't available for some reason? | 21:44 |
| tormod | I think I should first see if I can reproduce on my main install by uninstalling edgers | 21:44 |
| tormod | thing is I have no journal on the USB stick, so these crashes can mess up my fs there | 21:44 |
| bryce | ouch | 21:44 |
| tormod | yeah I can reproduce here on my HD install | 21:56 |
| tormod | are we getting a newer libdrm soon? could be that one | 21:58 |
| bryce | maybe; lookos like 2.4.15-1 is available in debian, looks like it's waiting on merge? | 21:59 |
| tormod | maybe the merge is waiting for 2.4.16 ? | 22:04 |
| tjaalton | it's merged, but .16 was rejected from debian | 22:05 |
| tjaalton | I'll upload it as -0ubuntu1 | 22:06 |
| tormod | why was it rejected? | 22:06 |
| tjaalton | debian/copyright was missing stuff | 22:06 |
| tjaalton | it was stuck in NEW because it added libdrm-radeon1 | 22:07 |
| tormod | ok, meanwhile I will see if just upgrading libdrm from edgers will help | 22:08 |
| bryce | tjaalton, btw the rethrow_signals patch is rewritten to apply now. I'll upload it once it's tested sufficiently. | 22:08 |
| tjaalton | bryce: yeah, sounds good | 22:08 |
| bryce | tjaalton, I'm going on vacation after friday through to the end of the year, any things that I should get squared away before I go? | 22:09 |
| tjaalton | bryce: close all the bugs?-) | 22:10 |
| tjaalton | I don't know if there's anything special right now. maybe we should prepare a new ati snapshot? | 22:11 |
| bryce | does -intel need an update too? | 22:13 |
| tjaalton | not really. the beta needs kernel changes.. | 22:14 |
| bryce | ah ok | 22:14 |
| tjaalton | or so I'm told | 22:14 |
| tjaalton | because of the pageflip stuff | 22:14 |
| bryce | ok then I'll do an -ati update | 22:15 |
| bryce | and hammer on bugs with what time remains | 22:15 |
| tjaalton | note that I didn't say "fix the bugs", closing is sufficient :) | 22:15 |
| * bryce lols | 22:15 | |
| bryce | ok I have a script for that ;-) | 22:16 |
| tjaalton | hehehe | 22:16 |
| bryce | actually speaking of which I promised to set up some of my automatic bug scripts for others on the desktop team, including the close bugs one | 22:16 |
| tjaalton | yeah, they will benefit from them | 22:17 |
| tjaalton | jbarnes: hey, do you know if kernel support for the intel Q4 release will be backported to .32.x or will it require .33? | 22:19 |
| tormod | no, libdrm update did not help, guess next to try is DDX | 22:26 |
| tjaalton | bryce: heh, the "current" nvidia source package name on debian is just "nvidia-graphics-drivers" | 22:31 |
| tjaalton | so at least they don't seem to care if the upgrade goes boom | 22:31 |
| bryce | heh | 22:32 |
| tjaalton | (the nvidia maintainers) | 22:32 |
| tjaalton | and the legacy packages are "nvidia-graphics-legacy-173" etc (binary nvidia-glx-legacy-173 etc) | 22:33 |
| bryce | any relation between debian's packages and ours? | 22:34 |
| bryce | i.e. should we be considering changing in ubuntu to better match what debian does? | 22:34 |
| tjaalton | some, I haven't checked how much they have diverged since | 22:34 |
| tjaalton | well, it's something to consider, even if we won't actively merge from them | 22:35 |
| jbarnes | tjaalton: q4 should be ok with 2.6.32 | 22:35 |
| tjaalton | jbarnes: cool, thanks | 22:35 |
| bryce | tjaalton, ok if you see tseliot, you might mention the idea to him | 22:35 |
| tjaalton | bryce: I will | 22:35 |
| tormod | building radeon DDX from git solved the issue. no time for bisecting now. I don't think anything has changed in the radeon_exa_funcs.c stuff we looked at | 22:38 |
| bryce | tormod, ok, well I'll up us to a newer snapshot later this week. got a favorite snapshot id I should use? | 22:40 |
| tjaalton | libdrm uploaded | 22:40 |
| tjaalton | oh wait | 22:40 |
| tjaalton | Connection failed, aborting. Check your network [Errno 111] Connection refused | 22:41 |
| tormod | bryce, HEAD is my favorite :) | 22:41 |
| tjaalton | whattaheck | 22:41 |
| tormod | lp is down for service | 22:41 |
| tjaalton | gah | 22:41 |
| Sarvatt | pheeew, might get another day of stability then because that libdrm update is going to ruin it :D | 22:42 |
| tjaalton | oh right, source v3 rollout and that | 22:42 |
| tjaalton | Sarvatt: why? | 22:42 |
| Sarvatt | i'm lucky to last an hour without crashing with 2.4.16 | 22:43 |
| Sarvatt | just crashed there with only 2.4.16 libdrm different than lucid, same problems i'm getting with edgers | 22:44 |
| tjaalton | which driver? | 22:44 |
| Sarvatt | intel 2.9.1 through git master | 22:45 |
| Sarvatt | [ 3389.832500] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. | 22:45 |
| Sarvatt | [ 3389.836934] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.Fatal server error: | 22:45 |
| Sarvatt | Failed to map batchbuffer: Input/output error | 22:45 |
| tjaalton | ok then.. jbarnes ^^ | 22:46 |
| tjaalton | if the new intel builds, maybe time to update that as well | 22:47 |
| jbarnes | sounds like a gpu rese4t | 22:47 |
| jbarnes | reset | 22:47 |
| tjaalton | that's with just a new libdrm | 22:47 |
| Sarvatt | if i downgrade libdrm to 11-25 like Duke` also has to do it doesn't happen | 22:48 |
| tjaalton | I'll try it myself before uploading | 22:51 |
| Sarvatt | try like, loading a folder in icon view with alot of video thumbnails, that almost always seems to trigger it | 22:52 |
| Sarvatt | message is a little different when it crashes after suspend/resume | 23:01 |
| Sarvatt | [264301.566382] (WW) intel(0): i830_uxa_pixmap_swap_bo_with_image: bo map failed | 23:01 |
| Sarvatt | [264301.566535] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error | 23:01 |
| Sarvatt | [264301.566658] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error | 23:01 |
| Sarvatt | [264301.566777] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error | 23:01 |
| Sarvatt | then hundreds of those failed to submit batch buffer messages | 23:01 |
| bryce | hrm | 23:01 |
| Sarvatt | freezes to a solid color when those happen | 23:01 |
| bryce | what do you guys think of holding off on doing the update until this is sorted? | 23:02 |
| tjaalton | well, if 2.9.99.902 builds, we could update that as well | 23:02 |
| bryce | if -intel is looking like it might be getting unstable again, I'd prefer holding off on updating. | 23:02 |
| Sarvatt | that needs the headers from libdrm installed because our linux-libc-dev doesnt have the pageflip ioctls | 23:02 |
| tjaalton | that would likely mean the same for nouveau and ati | 23:02 |
| tjaalton | Sarvatt: jbarnes said it wouldn't | 23:03 |
| tjaalton | well | 23:03 |
| tjaalton | not exactly true, I didn't say we use the kernel headers, not libdrm | 23:03 |
| Sarvatt | http://lists.freedesktop.org/archives/intel-gfx/2009-December/005166.html | 23:04 |
| Sarvatt | get those errors unless you have the headers from libdrm or 2.6.33 | 23:04 |
| Sarvatt | ah i'll check the irclogs | 23:05 |
| tjaalton | then the kernel needs those commits. simple as that | 23:06 |
| tjaalton | bryce: I meant that nouveau/ati probably depend on .16 as well | 23:06 |
| bryce | I'm just fearful of if we put in known-bad stuff expecting the fixes will arrive in time for release... they might not | 23:07 |
| Sarvatt | there was a thread about it on dri-devel last month where they talked about how people should be using libdrm's headers instead of the installed kernel ones because they use getparam things to enable runtime detection of features and they dont want all the ifdef trickery on top of that | 23:07 |
| bryce | (as has burned us before...) | 23:07 |
| Sarvatt | could just revert this commit from 2.9.99.902 to get it to work though http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906 | 23:09 |
| tjaalton | I'm just saying.. no need to upload broken stuff | 23:10 |
| bryce | Sarvatt, you can verify this resolves the issue for you? | 23:10 |
| Sarvatt | doesnt resolve any issue outside of letting it compile :D | 23:11 |
| bryce | tjaalton, also I can raise the issues as blockers to Intel if we have bug reports on them | 23:11 |
| Sarvatt | intel has been more broken than it ever was for me in jaunty since 11-06 | 23:11 |
| bryce | Sarvatt, :-/ | 23:11 |
| bryce | ok | 23:12 |
| bryce | well, first I've been told (by jbarnes and others) that libdrm policy is "regression-free" | 23:12 |
| bryce | so if we've found regressions in libdrm with -intel, flag those for me and I'll get them raised with Intel ASAP | 23:13 |
| bryce | we can focus on at least getting libdrm in and stable, so the nouveau and ati work can continue unimpeded | 23:13 |
| bryce | we can hold off on updating -intel until we have confidence that it's rock solid | 23:14 |
| bryce | if Sarvatt's findings are right and it's a pile of breakage at the moment, well I'd rather not update intel until we're absolutely confident about it | 23:15 |
| bryce | otherwise we'll be swimming in more bug reports :-) | 23:15 |
| tormod | Sarvatt, maybe we should add a reinstall of linux-libc-dev in ppa-purge... I got burnt now :) | 23:15 |
| tormod | bryce, he talked about libdrm not intel, right? | 23:16 |
| bryce | tormod, here's the exact quite from Yingying @ Intel: | 23:16 |
| tormod | bryce, if libdrm is held back, the latest ati commit that builds is 0061c4db | 23:17 |
| bryce | > For libdrm, we'd suggest Lucid pick up the latest libdrm. We've got | 23:17 |
| bryce | > some performance fixes in there, and some useful correctness fixes. | 23:17 |
| bryce | > Libdrm has a no-regressions policy which we've been good at, so this | 23:17 |
| bryce | > shouldn't be a problem. For -intel driver, the right version is going | 23:17 |
| bryce | > to be 2.10 (Intel Q4 version) which will provide KMS-based overlay | 23:17 |
| bryce | > support. If Ubuntu wants to support pre-915 chips and KMS, that seems | 23:17 |
| bryce | > like a requirement. | 23:17 |
| tormod | bryce, I am sure we will get there eventually :) | 23:17 |
| bryce | tormod, think I should update to that commit or just hold off until the libdrm stuff is in place? is there testing value in moving to that snapshot? | 23:18 |
| tormod | bryce, it will fix the console switching breakage | 23:18 |
| bryce | ok | 23:18 |
| bryce | then I'll work on getting that snapshot in | 23:19 |
| tormod | well let me test it once more :) | 23:19 |
| bryce | meanwhile, if anyone has specific bugs narrowed to the libdrm update, make sure they're in LP and subscribe me to them and I'll ensure they get upstream priority on them | 23:19 |
| tormod | bryce, yes that works: I reverted to old libdrm, built the above ati commit, and it fixed the issue | 23:21 |
| Sarvatt | was going to say that commit went into the stable branch too so it should work | 23:22 |
| Sarvatt | tormod: thats nasty, guess ppa-purge should check for all provides: and install those too huh.. | 23:23 |
| Sarvatt | err Replaces: | 23:24 |
| tjaalton | looks like having a stable radeon kms needs a lot from .33 | 23:25 |
| tormod | Sarvatt, ideally, but can get a bit ugly to detect all that, maybe we should just track our Replaces | 23:25 |
| tjaalton | by reading a thread from last month | 23:25 |
| Sarvatt | will do bryce, i havent filed any bugs on lp because its been edgers packages and i've seen all my issues on fdo bugzilla already | 23:29 |
| Sarvatt | note to self: dont use jordan.freenode.net :D | 23:31 |
| tormod | Sarvatt, it's netsplit all over I think | 23:33 |
| Sarvatt | tjaalton: this was the thread I was talking about, sorry http://marc.info/?l=dri-devel&m=125770698907397&w=2 | 23:35 |
| tjaalton | Sarvatt: yes I read most of it | 23:36 |
| tjaalton | so could be that we'll be shipping them from libdrm, again | 23:36 |
| tjaalton | Granted this means the F12 kernel has now got | 23:37 |
| tjaalton | a bunch of patches that should be in 2.6.32 but will have to wait for | 23:37 |
| tjaalton | 2.6.33, distros thinking of packaging radeon kms do take note. | 23:37 |
| tjaalton | that's what I said about earlier (if you got that) | 23:38 |
| tjaalton | so I think the kernel team will have to pull a lot of drm updates from .33 | 23:38 |
| bjsnider | then why not just use the .33 kernel at large? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!