[00:04] <RAOF> I'm trying the reporter's cpuburn trick; still no flicker here.
[00:14] <Sarvatt> got your backlight maxed? maybe if you dim it all the way?
[00:14]  * Sarvatt gets flicker at the lowest brightness setting but its a hardware problem
[00:16] <RAOF> The pcert tag is for... hardware that we want to platform-certify?
[01:29] <bryceh> kewl: http://homepage.mac.com/arekkusu/bugs/GLInfo.html
[01:33] <RAOF> That's moderately fun :)
[03:01] <RAOF> bryceh: I see we've both decided that bug #541492 is a candidate for kms blacklisting at the same time :)
[03:01] <ubottu> Launchpad bug 541492 in xserver-xorg-video-intel "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)" [Unknown,Confirmed] https://launchpad.net/bugs/541492
[03:01] <bryceh> RAOF, heh
[03:02] <bryceh> RAOF I already sent i830 off to be blacklisted
[03:02] <bryceh> RAOF, any other chipsets we should think about blacklisting?
[03:02] <bryceh> there was an ati card, but it ended up the kernel team got some patches to solve it
[03:03] <RAOF> I'm still going through the list.  I think we should quirk off acceleration for some nvidia cards, and I've got a patch for that, but we can't quirk off kms for them :)
[03:04] <RAOF> Oh, while I think of it - do you have any tips for how to decypher fedora's kernel packaging?  I wanted to see if they had any secret sauce for making macbook pros work, but I'm struggling with viewcvs.
[03:06] <bryceh> link?
[03:07] <RAOF> http://cvs.fedoraproject.org/viewvc/F-12/kernel/ ?
[03:07] <bryceh> I don't have particular tricks, usually I just thumb through the patches and cherrypick
[03:07] <bryceh> mm, slow webpage
[03:08] <RAOF> Nouveau's a bit difficult for that in Fedora, since they basically take the diff between 2.6.33 and nouveau/linux-2.6 and apply it.
[03:09] <bryceh> ah, ick
[03:10] <bryceh> yeah in that case you'll have to go through the nouveau git tree or something
[03:11] <RAOF> And hope that it's not one of the changes that is in fedora but not the nouveau git tree :/
[03:28] <bryceh> tjaalton, I've moved the versions page up a level (and discarded the historical data):  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
[03:44] <bjsnider> i830. never heard of that one
[03:45] <RAOF> Yeah.  It's rare, and that doesnt' help.
[03:45] <bjsnider> the number suggests it's pretty old i guess
[03:46] <bjsnider> i wonder how many people are still using it
[03:46] <bjsnider> and on what type of device
[03:46] <RAOF> At least some on at least one tablet, and it doesn't drive their lvds because the encoder(?) isn't supported at all.
[03:50] <bjsnider> don't tablets come with their own operating systems?
[03:50] <RAOF> Tablet laptops, like the lenovo x300
[03:51] <RAOF> Man, rev 02 Intel hardware is a rich source of hardware bugs.
[04:00] <RAOF> Why is drm not even *attempting* to load in bug #552481 ?
[04:00] <ubottu> Launchpad bug 552481 in xserver-xorg-video-intel "[i845g] Login screen doesn't appear" [High,Incomplete] https://launchpad.net/bugs/552481
[04:32] <bryceh> RAOF, excluding proprietary drivers, we are at a point where we have fewer bugs in our workqueue than when we started:
[04:32] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
[04:32] <RAOF> That's a *nice* looking curve at the end
[04:33] <Sarvatt> bryceh: did you drop the hunk in drmmode_xf86crtc_resize on purpose in the intel 101-copy-fb.patch
[04:33] <Sarvatt> ?
[04:33] <Sarvatt> http://cvs.fedoraproject.org/viewvc/F-12/xorg-x11-drv-intel/copy-fb.patch?revision=1.9&content-type=text/plain&view=co
[04:34] <Sarvatt> @@ -1373,6 +1382,8 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scr  -- that hunk is missing in ours
[04:35] <bryceh> Sarvatt, wow that's an old one
[04:35] <Sarvatt> i'm looking at the newest one relevant to 2.9.1
[04:35] <bryceh> the formatting of our patch doesn't match what I generally create
[04:35] <bryceh> nor does it look like an upstream patch
[04:36] <bryceh> iirc someone gave it to me to include, but I don't remember who.  alberto maybe
[04:36] <Sarvatt> i figured you applied it by hand and did a manual diff or something, must not have been you :)
[04:36] <bryceh> mmm, maybe it's one of the ones we got from moblin
[04:36] <bryceh> no, when I do patches they don't have the line of ======'s there at the top
[04:36] <bryceh> perhaps the fedora patch is an updated version
[04:37] <Sarvatt> they always had that hunk and fedora doesn't have any changes in the time frame of that diff
[04:38] <bryceh> wait, are you sure we're missing that?
[04:38] <bryceh> the chunk is
[04:39] <bryceh> +	scrn->canDoBGNoneRoot = TRUE;
[04:39] <bryceh> +
[04:39] <bryceh> which we do have in our patch
[04:39] <Sarvatt> we have +	pScrn->canDoBGNoneRoot = TRUE; in another area
[04:40] <bryceh> I assume it's fine
[04:41] <bryceh> RAOF, yeah been busting hump getting bug reports cleared out... a lot I'm just reassigning to the kernel, some I'm terminating with prejudice, others sending upstream
[04:42] <bryceh> I've gotten -ati and xserver under control
[04:42] <bryceh> -intel's going in the right direction but needs more attention
[04:46] <RAOF> It looks like we'll want to kms-blacklist 845 & 855, which should resolve quite a number.
[04:47] <bryceh> yeah I didn't get to i855 but noticed there's a bunch of bug reports there
[04:49] <ScottK> I'm testing my 865 machine and I got the video into a mode the won't display.  How can I reset the resolution via ssh?
[04:49] <RAOF> DISPLAY=:0 xrandr --output $WHATEVER --mode $SOMETHINGSAFE
[04:50]  * ScottK tries
[04:50] <bryceh> or sometimes just DISPLAY=:0 xrandr --auto
[04:50]  * ScottK tries that first
[04:51] <RAOF> That'll be a good one to squirrel away.
[04:53] <bryceh> that and 'stty sane' :-)
[04:55] <RAOF> Hm.  Taking out that cheese has made it clear how hungry I am.  Luncheon!
[04:55] <bryceh> and Dinner for me!
[04:57] <ScottK> DISPLAY=:0 xrandr --output VGA1 --mode 2048x1536 FTW!  Thanks bryceh.
[04:58] <RAOF> Again these people with huge displays driven over VGA /:?
[04:59] <ScottK> RAOF: That was the default after I upgraded.
[05:00] <ScottK> I'm not going to leave it that way.
[05:28] <ScottK> bryceh: Kwin desktop effects at 1400x1050 on 865G!
[05:29] <ScottK> Definitely better than Karmic.
[05:59] <Sarvatt> bryceh: *all* of the batchbuffer no space left on device bugs i can find that are happening right after startup have multiple displays and drmmode_xf86crtc_resize is called in that case, i'm not sure if its screwing up there because we are missing that hunk but it seems suspicious
[05:59] <Sarvatt> (plus I cant find any non ubuntu reports of it happening upstream)
[06:16] <RAOF> Sarvatt: Hm.  Could this perhaps *also* be related to the “plymouth, nouveau, and more than one screen” hang we've got?
[06:17]  * RAOF will be back shortly, after checking this kernel build
[06:23] <RAOF> Good.  That patch works as expected.
[06:33] <tjaalton> bryceh: ok thanks, updated my setup here
[06:51] <Sarvatt> i think theres just something wrong in general with the bgnr stuff with multiple displays, looks like its happening in fedora too and we dont see it on radeon/nouveau because it doesn't work if theres multiple displays :)
[06:51] <Sarvatt> https://bugzilla.redhat.com/attachment.cgi?id=386700
[06:55] <Sarvatt> the failed to submit batchbuffer no space error always happens right after a (II) intel(0): Allocate new frame buffer event in Xorg.0.log in both ubuntu and fedora, no reports elsewhere
[06:56] <Sarvatt> (with multiple monitors)
[06:57] <RAOF> So, what happens if we don't put plymouth on any secondary monitors?
[07:00] <Sarvatt> need to hook up another monitor and try to reproduce it so i can mess around in drmmode_xf86crtc_resize to see where its failing
[07:00] <RAOF> This is the one big failing of the x200s: it's got a stupid, useless VGA output instead of something useful.
[07:01] <bryceh> Sarvatt, ok on the batchbuffer no  space bug, keep investigating and let me know if you find something definitive; sounds like a promising lead
[07:01] <bryceh> Sarvatt, might be worth making a ppa with redhat's patch instead of ours for folks to test; I can examine it more closely next week if it proves to make a difference
[07:02] <Sarvatt> i dont think the nouveau thing is related btw, that seems to be a lockup in TTM when theres multiple monitors and it just waits forever somewhere, and its exacerbated by alot of <=nv40 cards always saying they have a tv connected which fedora forces off by default
[07:02] <Sarvatt> bryceh: it happens on fedora too
[07:02] <Sarvatt> just fedora and us
[07:03] <bryceh> well, that's like 95% of the market between the two ;-)
[07:03] <RAOF> Do we have any reports of -ati disliking plymouth + dual-head?
[07:03] <Sarvatt> no because it doesnt copy the fb in dual head
[07:03] <Sarvatt> only intel does that
[07:03] <bryceh> RAOF, not that I've seen
[07:04] <Sarvatt> first place i looked was drmmode_display.c in both radeon and nouveau, they have the copyfb stuff upstream already
[07:04] <bryceh> Sarvatt, or maybe a ppa with that patch dropped
[07:05] <Sarvatt> yeah thats what i'm thinking, ask them to test with it dropped at worst case (even though that sucks)
[07:06] <Sarvatt> its the ones with Failed to submit batchbuffer: No space left on device in the xorg log, or [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffer with a -28 return
[07:15] <bryceh> we need a Ubuntu Bug Triage drinking game
[07:16] <RAOF> Everytime vga16fb messes things up you take a shot?
[07:16] <bryceh> and every mention of bug #1
[07:16] <ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
[07:17] <bryceh> or "total show stopper"
[07:17] <RAOF> No!  “I see this behaviour too, on $TOTALLY_DIFFERENT_HARDWARE”
[07:18] <RAOF> s/behaviour/bug/
[07:21] <Sarvatt> ok going to upload an intel with no 101-copy-fb.patch and ask the 10 or so bugs I see from a quick search to test :) if anything disabling it if theres >1 monitor shouldn't be hard, drmmode_display.c is pretty much duplicated between the 3 drivers and we can just do it how nouveau does (besides the uxa specific stuff)
[07:23] <RAOF> I'm not sure that doing it how nouveau does it is a wonderful idea; copy it too well and you'll make plymouth hang with >1 monitor :)
[07:24] <Sarvatt> that happening on NV50+ too?
[07:25] <RAOF> Yes.
[07:28] <Sarvatt> i think thats a nouveau specific problem though, seems to be hung looping a gem ioctl and getting stuck in ttm_bo_wait
[07:30] <Sarvatt> first thing i looked at was http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f0fbe3eb5f65fe5948219f4ceac68f8a665b1fc6 but we have that
[07:30] <Sarvatt> thats where its getting stuck though
[07:32] <RAOF> Yeah.  I'm pretty sure that we've got the interesting bugfixes from nouveau/linux-2.6.
[07:32] <Sarvatt> something tells me its a problem fixed in the api bump :)
[07:33] <RAOF> I seem to remember having the same problem with xorg-edgers, though.
[07:33] <bryceh> oh one other thing with >1 head systems
[07:34] <bryceh> I feel like a dunce for not mentioning it already since it's >exactly< what I've been fiddling with all afternoon
[07:35] <bryceh> watch for cases that are: a) multihead with total width > 2048; and b) running compiz; and c) older hardware with max texture size = 2048
[07:35] <bryceh> symptoms include black screen, strange corruption on right side of monitor, freezes, or other random behavior
[07:35] <bryceh> regression from karmic
[07:36] <bryceh> see bug #428769
[07:36] <ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released] https://launchpad.net/bugs/428769
[07:36] <bryceh> in karmic, there was a wrapper script to compiz that checked the max texture size and refused to run
[07:36] <bryceh> in lucid, they got rid of the wrapper in favor of doing the checks in the compiz binary, but it seems something is still not quite right
[07:37] <bryceh> bug #555641 is the X.org side of things, basically that it's a hardware limit and compiz shouldn't run in this case
[07:37] <ubottu> Launchpad bug 555641 in xorg-server "MASTER: max texture size prevents compiz from running" [Wishlist,Triaged] https://launchpad.net/bugs/555641
[07:38] <bryceh> see also http://bugs.freedesktop.org/show_bug.cgi?id=27530 where alex confirms as much
[07:38] <ubottu> Freedesktop bug 27530 in Driver/Radeon "[RV370] Portion of second monitor unusable" [Normal,Resolved: notabug]
[07:40] <RAOF> bryceh: That's a slightly different bug though, isn't it?  I'm fairly sure multihead with *>* 2048 width works by falling back to metacity (I've seen this confimed in lucid bug reports).
[07:41] <RAOF> The problem in that bug is with a screen resolution exactly *equal* to the max texture size.
[07:41] <bryceh> RAOF, it's supposed to do that, but I've run through several bug reports now where it clearly did not happen
[07:41] <RAOF> Which is significantly less common, I'd hope.
[07:42] <bryceh> well, see #556631 as another example, where it's >2048
[07:45] <Sarvatt> yeah its 1 pixel off it seems bryceh, 2047 works 2048 doesn't so theres something odd going on
[07:45] <Sarvatt> 2048 = compiz starts fine but you get a black screen, 2047 works from the bugs i've read over the past few months
[07:46] <Sarvatt> 2049 would just fall back to metacity right
[07:46] <RAOF> Sarvatt: Bug #556631 does seem to be a counter example there.
[07:46] <ubottu> Launchpad bug 556631 in xserver-xorg-video-ati "Portion of second monitor unusable" [Medium,Triaged] https://launchpad.net/bugs/556631
[07:46] <RAOF> Albiet an -ati counterexample, rather than an -intel one.
[07:47] <bryceh> I mean we don't have any compiz logs, so don't know exactly whats going on
[07:47] <bryceh> the reporter could have mindlessly overridden compiz doing checking (if that's still possible to do) for all we know
[07:48] <RAOF> Yeah.  I just thought of that.
[07:49] <bryceh> could be an easy fix in the == 2048 case though:  https://bugs.edge.launchpad.net/ubuntu/lucid/+source/compiz/+bug/428769/comments/17
[07:49] <ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released]
[07:49] <RAOF> Right.  A >= rather than > on the compiz check.
[07:54] <Sarvatt> sheesh, how did i not notice that, i've known about this problem since december :D
[07:55] <Sarvatt> ah nevermind thats just the fix for == which *should* work, i need sleep
[07:56] <bryceh> heh, you saying I'm not alone in being a dunce?
[07:57] <bryceh> anyway, I've set up both bugs to get top priority from the compiz folks so hopefully they'll get it sorted
[07:57] <bryceh> meanwhile if you guys see more blank screen on boot bugs where they're running compiz on dual head with small max texture sizes, dupe 'em up
[07:59] <bryceh> heya mvo
[08:02] <Sarvatt> i was figuring it was one of these other ancient patches in here extending the texture 1 pixel in some direction (like 015_draw_dock_shadows_on_desktop.patch maybe?) but couldn't work it out
[08:03] <mvo> hey bryceh
[08:07] <bryceh> mvo, we were just discussing an issue we've seen reported a bunch, that I think may be a compiz regression - https://bugs.edge.launchpad.net/ubuntu/lucid/+source/compiz/+bug/428769
[08:07] <ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048" [Unknown,Fix released]
[08:10] <mvo> bryceh: so compiz is not correctly detecting that it can not work in this environment?
[08:11] <bryceh> mvo, right
[08:12] <mvo> bryceh: that is very possible, the code that detects this has changed in lucid
[08:13] <mvo> bryceh: aha, I see put that in comment #15 already
[08:14] <mvo> bryceh: I can do a upload with a fix as described in #17
[08:14] <mvo> bryceh: I don't have the HW to test it though
[08:14] <mvo> bryceh: this particular error
[08:14] <mvo> but it does make perfect sense
[08:14] <mvo> (the fix)
[08:15] <bryceh> mvo, great
[08:18] <mvo> if LP lets me that is
[08:18] <bryceh> heh
[08:18] <bryceh> mvo, probably will be blocked until freeze is lifted tomorrow
[08:27] <mvo> bryceh: while I have you here, you set bug #540519 to confirmed and targeted it. do you have more inside into it?
[08:27] <ubottu> Launchpad bug 540519 in software-center "software-center crashed with SIGSEGV in webkit_web_view_execute_script()" [Undecided,Confirmed] https://launchpad.net/bugs/540519
[08:28] <mvo> bryceh: it looks like a webkit issue to me
[08:29] <mvo> bryceh: or do you have a recipe to reproduce?
[08:29]  * bryceh ponders
[08:30] <bryceh> I got the crash myself, and this was suggested as the dupe of it
[08:30] <bryceh> mvo, I think I was trying to look at screenshots of games
[08:31] <mvo> ok, so just clicking on the "enlarge" screenshot picture?
[08:33] <mvo> bryceh: I upload your suggested fix now. one thing that is odd is that the reporter claims it works with the jaunty version of X/compiz on the same HW
[08:35] <bryceh> mvo, I think it might have been on a game where the screenshot didn't show.  I don't really remember the precise situation, eventually software-center locked up and I think I had to kill it, so got the crash report later
[08:44]  * mvo nods
[09:19] <Mirv> do other intel lucid users have this recent slowdown bug #555595 ?
[09:19] <ubottu> Launchpad bug 555595 in linux "Intel graphics performance regression in recent lucid kernel update (was: Firefox Slows Down Compiz)" [Undecided,Confirmed] https://launchpad.net/bugs/555595
[10:34] <bryceh> Mirv, no
[11:34] <Mirv> bryceh: amd64 or not? 
[11:35] <Mirv> it seems the problem was not there in at least -16 which I managed to get now installed. 
[11:35] <Mirv> the bug reporter and me are using amd64
=== BUGabundo is now known as BUGabundo_lunch
=== BUGabundo_lunch is now known as BUGa_vacations
[18:06] <bryceh> haha http://article.gmane.org/gmane.linux.kernel/969355
[18:24]  * BUGa_vacations reads
[18:25] <BUGa_vacations> thanks bryceh
[18:25] <BUGa_vacations> I needed that
[18:28] <BUGa_vacations> MAUAUUAU
[18:28] <BUGa_vacations> bryceh: look at the date
[18:30] <bryceh> BUGa_vacations, sure or read the rest of the thread http://thread.gmane.org/gmane.linux.kernel/969355
[20:16] <tjaalton> bloody hell, waltop/wacom merge works
[20:45] <apw> bryceh, do i take you reposonses to the radeon PLL thread to mean that you think we need it regardless of its hugeness?
[20:52] <bryceh> apw, yes-ish.  If anyone has specific concerns about possible regressions though, I'd favor further testing first.  I skimmed through the code briefly and didn't see anything that frightened me
[20:52] <bryceh> but devil's in the details of course
[20:52] <apw> bryceh, there are kernels with the patches applied in that bug, so we could get people to test that
[20:52] <bryceh> apw, my experience has been that Alex is a pretty careful coder, and is good about recommending only patches that are safe
[20:52] <apw> bryceh, yeah as alwasy, a difficult choice
[20:53] <apw> thats good to know
[20:53] <bryceh> (one of the reasons I like working on -ati so much more than -intel)
[20:53] <apw> bryceh, :) thats something ... 
[20:54] <apw> its works pretty well on my only ati box the current stuff, but i did see some flickering there ... perhaps i need to test
[20:59] <bryceh> apw, dunno if you saw them but we've bumped a bunch of pll quirk bugs over to linux the past couple weeks
[20:59] <bryceh> if you do a search for 'needs_pll_quirk' I think you'll turn them up.  At least half a dozen, maybe more.
[21:00] <bryceh> my guess/assumption is they'd all be fixable after this patch is in place
[21:01] <bryceh> apw, <shifting-topics> so with the firmware update on my MT tablet, it looks like I'm going to need to reinstall windows 7 in order to install the firmware.  Urgh.
[21:01] <bryceh> I'll give it a go next week
[23:46] <merriam> You know compiz was broken the same way (black screen) in the Karmic release?  -->  <bryceh> in karmic, there was a wrapper script to compiz that checked the max texture size and refused to run
[23:51] <RAOF> merriam: Which bug is this?  The == 2048 width bug, or a > 2048 dimension bug?
[23:58] <merriam> ==