[06:41] bryce_: there's a(nother) patch which might fix the wacom crashes, I'll prepare a new server on my PPA [06:41] ok [06:45] hmm, if I get a freeze today, have to check ssh:ing and killing compiz. earlier I just did alt-sysrq-k (to get garbled screen ie. change to terminal) and ctrl-alt-delete to reboot cleanly [06:51] I >just now< had a freeze [06:51] 2nd one since downgrading to 7.3 [06:51] I was tabbing back and forth quickly and it locked [06:51] went to another machine and killed compiz, but still was locked [06:52] ok, so mesa is off the hook?-) [06:54] well, compiz is off the hook at least [06:54] s/mesa/mesa upgrade/ [06:56] tjaalton: well, take a look at https://wiki.ubuntu.com/X/Bugs/IntelDriver [06:57] tjaalton: notice the number of freezes first reported around 4/7-4/10 [06:57] allow for a day or two of suffering before reporting, puts you at 4/5 or earlier [06:58] now look at this list of stuff that was changed around that timeframe: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392 [06:58] Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] [06:58] but if downgrading mesa didn't help.. [06:59] before I downgraded, I got a freeze within 2 hrs. After downgrading, my first freeze came 24 hrs later, the second freeze came another 48 hours later [07:00] debugging is easier if it happens more often ;) [07:00] * tjaalton runs [07:00] seriously though, I just threw a dart at that list and mesa looked like the ripest candidate [07:01] open to other ideas [07:01] nothing else on that list really strikes me as likely [07:02] it's possible it's been freezing up all along, since I usually turn compiz off after testing it for a while [07:02] looking from the other side, there is that patch on mesa 7.4.x git that is supposed to address intel deadlocks. perhaps helpful to go in the right direction? [07:02] forwards is a nice direction too... [07:03] i dont know the circumstances of the deadlock that patch is supposed to address though, might be completely unrelated deadlock [07:04] superm1: which one [07:04] ? [07:05] I see only a generic non-intel one [07:05] yeah that's right my bad. it is generic [07:05] and I see only DRI2-related intel fixes [07:05] http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=d805c82068feffda03266855a843de261a45865c [07:05] well it's generic, but of course might have been done because of an intel problem [07:05] ah, innocent-looking commit header [07:06] what about 174_set_bg_pixmap_of_cow_to_none.patch to xserver [07:06] or bumping the max texture size [07:07] fits the timeframe, and it futzs with how compiz works [07:07] upstream declined it for 7.4 and idr pointed out that it would need other changes too.. [07:07] which then broke radeon [07:07] which patch is that one? [07:08] it's in mesa [07:09] ahhhhh [07:09] now _that_ could explain why we have only gotten reports on i965 [07:09] 103 in mesa [07:09] bump_965_texture_limit [07:09] since only i965 supports the 4kx4k textures anyway [07:09] right [07:10] I'll try a build with that disabled, that is a very good hypothesis [07:10] switching machines... [07:10] I'm also running mesa without 102/103/104 patches now. [07:10] Mirv: and still froze? [07:11] tjaalton: not yet [07:11] good :) [07:12] okay i've got a fix for bug 355242 [07:12] Launchpad bug 355242 in mesa "mythfrontend.real crashed with SIGSEGV in QGLWidget::resizeEvent()" [High,Fix committed] https://launchpad.net/bugs/355242 [07:12] that involves adding a very small patch [07:12] nice! [07:13] http://pastebin.com/f426f1a5e [07:14] weird, lost my network-manager key [07:18] is git.debian.org not working right now? this is my first time pushing to it, so i might just be messing up something with it.. [07:18] seems to be out of reach atm [07:19] okay i'll try to push again before i go to bed, otherwise i'll try again in the mornin [07:20] hrm, firefox won't start now [07:20] superm1: attach it to the upstream bug too [07:20] oh, done already [07:22] tjaalton: seen siretart's post about reverting to the intrepid -intel? [07:25] bryce_: will he maintain it then?-) [07:25] s/will/would/ [07:25] yeah [07:25] I'll feel pretty sheepish if the solution to all our problems is just to go back to 2.4.1 ;-) [07:26] heh [07:26] oh hell, git.debian.org is down eh? [07:26] if only the greedy patch would work [07:26] yes [07:27] well, even if the patch worked, slangasek says on his system greedy turns firefox black [07:27] ah [07:28] would -intel then have to replace/conflict the -intel-2.4 package? [07:28] dunno [07:32] seems to be the other way around [07:33] bryce, were you planning on pulling in 775ca8e3fa5ddf090115907c78889ed8311cd3ae to fix freedesktop bug 20479 too? I have a sneaking suspicion it's going to solve the other mythtv mesa bug [07:33] Freedesktop bug 20479 in Driver/Radeon "[R100 Mobility M7 7500] Problems with 16bit mode using radeon driver" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=20479 [07:33] i'm doing another build with it to verify tho [07:33] good god, froze again [07:33] in the middle of an upgrade to boot [07:34] heh, after upgrading mesa to 7.4 [07:34] ah, maybe I know why it hasn't frozen on me yet.. [07:35] but shouldn't I have had to reboot before that takes affect? [07:35] I've got libgl1-mesa-dri without our own patches [07:35] installed [07:35] 7.4-0ubuntu1 UNRELEASED :P [07:35] ahhhhhghgh [07:35] so, the texture size bump is a very good candidate.. [07:36] dude, that's not the sound of pieces falling into place is it? [07:36] hehe [07:36] normally these are upgraded with the proper versions from the archive, dunno why it didn't happen this time.. [07:37] dunno, but same here, not showing as being upgradeable [07:37] I was in the middle of rebuilding mesa without that patch when my system froze :-P so let's try that again... [07:37] I'll upgrade now to make sure it hangs here too [07:38] I'm pretty happy if I don't get hangs anymore, so not upgrading :) [07:39] bryce_: so the hang you're seeing with 7.3 is probably fixed in 7.4 ;) [07:39] hahaha [07:40] yeah, I probably traded a once a day hang for a once an hour hang ;-) [07:40] and now we are all laughing at it :P [07:41] (if it really _is_ fixed by dropping patch 103..) [07:50] *build build* [07:51] *crash crash* [07:52] tjaalton: not funny ;) [07:52] hey, I'll take *crash crash* over *Freez... any day [07:53] I'm doing my "compile very important work-related stuff" thing, it has usually been good at reproducing any freezing problem [07:54] Mirv: I'm trying to make mine crash/freeze :) [07:55] so far no one's found good steps to reproduce [07:56] however having firefox loaded, and alt-tabbing seems like a good approach maybe [07:58] yeah, big windows [09:55] I've got the mesa builds, but am waiting for one more freeze before applying [10:14] bug #361568 [10:14] Launchpad bug 361568 in nvidia-graphics-drivers-180 "Black areas appear on the screen randomly" [Undecided,New] https://launchpad.net/bugs/361568 [11:34] mesa 7.4 without patches 102/103/104 is still solid here. I think I used to encounter crash this far to a work day previously. [11:34] (if using compiz, like now) [11:36] Mirv: still having trouble reproducing crash one last time.. [11:37] X is surprisingly stable when you don't want it to be === albert231 is now known as albert24 === albert24 is now known as albert23 [12:21] https://bugs.launchpad.net/ubuntu/+bug/361291 [12:21] Launchpad bug 361291 in ubuntu "regressions in kde4.2.2" [Undecided,New] [12:22] say ubuntu dictators thake a look at the other site, there are bugs that need to be fixed, like freezing and the regressions [12:26] hit'n'run [12:34] tjaalton: I was just debugging #351394 and it seems that the "nv" driver is not supporting some cards (9600gt in the bugreport). I assume I can use /usr/share/xserver-xorg/pci/nv.ids to detect what can be used with nv? [12:34] hey there [12:35] mvo: nv.ids has a (strict) subset of the supported hardware [12:35] martin olsson suggested that I should talk to you on ubuntu-devel@l.u.c [12:37] jcristau: thanks. out of curiosity, why is it a subset? is there a better way to get the full set? [12:40] http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n797 [12:40] see NVIsG80 and NVIsSupported [12:40] * mvo looks [12:40] hahaha, bug 361639 [12:40] Launchpad bug 361639 in xorg "unneccessary dependency from xserver-xorg to hal" [Undecided,New] https://launchpad.net/bugs/361639 [12:40] it's spreading [12:41] mvo: and then there's the fun with NVGetPCIXpressChip which i'm not sure i understand [12:41] tjaalton: have fun :) [12:41] yeah, the -nv is a mess [12:42] jcristau: I should probably wishlist/in-progress it :) [12:44] siretart`: you are planning to put -intel-2.4 in universe? [12:44] tjaalton: I've suggested that on the mailing list, since it happens to work for me. [12:44] tjaalton: scottk then told me that I'd need another ACKs from motu-release from that. [12:45] siretart`: what happens when it's removed from the archive? [12:46] tjaalton: if what gets removed? [12:46] siretart`: -intel-2.4, it's not going to be there forever :) [12:46] tjaalton: yes. so what? [12:46] besides, I'm sure there would be bugreports against the maintained packages.. [12:47] siretart`: -intel would have to Replace it right? [12:47] why? [12:47] to support upgrades? [12:48] oh, I'm not suggesting to include it in main, nor install it by default [12:48] I understand, but people won' [12:48] therefore IMO there is no point in considering upgrade paths [12:48] duh [12:48] you'd probably need conflicts and replaces, since they'd presumably share some files [12:48] still, it's going to haunt the team [12:48] jcristau: -intel-2.4 has them [12:48] yes, the intel-2.4 conflicts, replaces and provides the -intel package [12:49] it is a hack for people with hardware that happens to work better with the 2.4 branch until the 2.7 branch matures for older intel chips like mine [12:49] I'd prefer to keep it in a PPA.. [12:50] k [12:50] would you please mention that on the mailing list so that others can comment on that? [12:50] yes === seb128_ is now known as seb128 [16:27] finally managed to freeze compiz [16:27] ssh works [16:37] what's the backtrace look like? [16:38] checking [16:38] note that this is with the "bump the texture size on 965" patch [16:38] I haven't been able to crash it with plain mesa 7.4 [16:39] yeah iirc there were some other places that needed fixing with that [16:43] anyway, here's the backtrace: http://pastebin.ubuntu.com/151506 [16:44] looks like it hung the chip somehow [16:45] mouse works, but that's it [16:57] killing X hung it for good [17:16] I've had quite a heavy day without any crashes using 102/103/104 patches, so this is starting to look relatively clear [17:16] I mean freezes [17:17] and without using, ghr. [17:18] now that I have this working so well, I won't try putting the texture size patch back since I enjoy this :) [18:27] jbarnes: check https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/358574 which I think is the same bug, and has some kernel error messages to it [18:27] Launchpad bug 358574 in linux "[drm:i915_gem_idle] *ERROR* hardware wedged" [Medium,Triaged] [18:36] bryce: it's possible, I'm not too familiar with the texture size stuff [18:58] jbarnes: btw, one option I'm considering for solving the performance issue is to just switch greedy migration back on [18:58] this is patch http://launchpadlibrarian.net/25354124/05_intel_exa_force_greedy.patch we carried back in hardy [18:58] however, unfortunately it causes a segfault: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/360798 [18:58] Error: This bug is private [18:59] Michel recently suggested disabling Migration optimization altogether [18:59] Option "EXAOptimizeMigration" "off" [18:59] in fdo bug 20739 [18:59] Launchpad bug 20739 in nobootloader "Install mkvmlinuz and create vmlinuz on pegasos." [Medium,Fix released] https://launchpad.net/bugs/20739 [18:59] ahh interesting; I'd missed that [19:00] I've never tried it... sounds promising though [19:01] cool, will give it a go, thanks! [19:04] jbarnes: oh btw on the i965 freeze, dunno if you saw the scrollback but current working theory is that it is caused by 103_bump_965_texture_limit.patch [19:04] yeah saw that... good to isolate it [19:05] upstream mesa may already have a fix [19:05] fits with the evidence that it is i965-specific [19:05] since I remember hearing about something similar shortly after the texture size bump went in [19:05] idr explained that the other commit would break radeon [19:05] ah interesting, on which list? [19:06] mesa3d-dev [19:06] 7.4 rel candidate 1 thread [19:06] ok [19:07] so I'd just drop it and reopen the bug it fixed.. [19:08] tjaalton: are we fairly convinced this is the case? I'm going to go test my laptop with it dropped... however since reproducing the freeze takes so long, would be nice to have the external verification that others have pinpointed to this patch [19:11] bryce: the other patch fixes tfp for dri2, so patch 103 should be the only one that matters with exa [19:11] Interesting: "Each time we bump up the max texture size it means we also increase the max drawing surface size (render to texture and all that). One consequence of this is the fixed point arithmetic in the swrast triangle code may start failing." [19:12] ok, bbiab. testing time [20:09] in complete irony, I finally gave up trying to reproduce the freeze on my laptop, and the exact moment I went to install the mesa debs, guess what [20:12] plunk [20:13] heh [20:20] ok, booted with the "fixed" mesa, now to wait and see if it freezes... [20:22] bryce: so I have 102/103/104 patches disabled and definite improvement, so if it's not tfp/dri2 patch (on exa!) or one-line vblank patch (theoretically could be), it's pretty surely the bump texture patch [20:22] I couldn't work for a full day with compiz enabled earlier [20:23] sweet [20:24] Mirv, did you need 102 or 104 disabled? It'd be interesting to know if you get the same benefit with only 103 disabled [20:40] Mirv: actually, you should need 102 [20:41] I mean, you want it, since vblank still has issues and it was disabled again a while back.. [21:38] heya tormod [22:08] tjaalton: I think I've got a dup of 358643, but it crashes in a different place. [22:09] tjaalton: 361972 [22:12] kees: ok, there are a couple of candidates to try [22:13] kees: http://cgit.freedesktop.org/xorg/xserver/commit/?id=efa31092d6703397121a0ada4f7205a8ecad3d3d [22:14] and 1df6716281579e2937743d840ab1079343c503ac [22:14] for the server [22:15] tjaalton: okay, cool. I have other stuff I have to do first, but if there are packages built to test those fixes, I can do that. [22:15] there aren't yet [22:15] maybe I could push those to my ppa [22:18] and test it myself :P [22:32] actually, no time for testing, but it's uploaded [22:33] kees: it'll show up in https://edge.launchpad.net/~tjaalton/+archive/ppa [22:33] includes the first commit, which should fix crashes when the configfile has devices that aren't present [22:34] not necessarily the same as the other bug [22:37] tjaalton: okay, thanks. [22:44] tjaalton: let me start my VMs again, one sec [22:45] hi bryce :) [22:46] kees: so, if lshal doesn't show input.x11_driver = 'vmmouse', the fdi file is busted [22:46] Xorg.0.log should also show that it's using vmmouse [22:55] bryce, on my 945, neither disabling migration nor enabling greedy migration improves things. The 2.6.30rc works perfectly with EXA though, subjectively the same performance as 2.6.28 under UXA, and as I had in 8.10 and previous using greedy migration [22:58] that's good news [22:58] cwillu: nice [23:00] less nice is that disabling migration or enabling greedy would be easy things to roll out... [23:01] guess we can hope the kernel team knows something to try cherrypicking... [23:01] we've got jbarnes here ;) [23:02] obi wan jbarnes, you're our only hope [23:04] bryce: it's the bit 17 swizzle patch, that is in 2.6.30-rc2 [23:05] albert23: ahh [23:05] weird, I was just now looking at that [23:06] https://bugs.freedesktop.org/show_bug.cgi?id=16835 [23:06] Freedesktop bug 16835 in Driver/intel "[945 tiling] Low performance due to no A17 workaround" [Major,Resolved: fixed] [23:06] there's also exec buffer fencing [23:06] that went in post-2.6.28 [23:06] helps 945 chips a lot [23:11] * cwillu feels helped :) [23:12] * cwillu tries turning on vblank [23:12] nice [23:13] my big internal gear isn't tearing, and I'm getting more than 0.3fps [23:13] * cwillu knows what to ask for for christmas [23:14] heh [23:14] that's odd though, the screensaver preview doesn't get composited. Is that normal? [23:15] i.e., if I spin the cube, I have a black square showing the glmatrix screensaver in the middle of the screen [23:15] for 945 there are really 3 big perf fixes: a17 swizzle, mchbar alloc, and execbuf fencing [23:15] cwillu: you have to use uxa+dri2 to get redirected direct rendering [23:15] ah, k [23:15] guess I got used to uxa pretty quick [23:17] and vblank is still slow as hell under uxa, but that's to be expected? [23:21] dri2 doesn't support it === RAOF_ is now known as RAOF [23:21] aiui [23:21] I've reported the perf findings with the 2.6.30-rc2 to the kernel team [23:22] also check out the benchmark results michael larabel posted [23:26] ok, given the lack of really solid positive results from turning off migration, I'm going to postpone working that change into a patch for now [23:27] sounds like the kernel team has a better lead on a real fix