| RAOF | I'm trying the reporter's cpuburn trick; still no flicker here. | 00:04 |
|---|---|---|
| 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:14 | |
| RAOF | The pcert tag is for... hardware that we want to platform-certify? | 00:16 |
| bryceh | kewl: http://homepage.mac.com/arekkusu/bugs/GLInfo.html | 01:29 |
| RAOF | That's moderately fun :) | 01:33 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| bryceh | link? | 03:06 |
| 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:07 |
| 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:08 |
| bryceh | ah, ick | 03:09 |
| bryceh | yeah in that case you'll have to go through the nouveau git tree or something | 03:10 |
| RAOF | And hope that it's not one of the changes that is in fedora but not the nouveau git tree :/ | 03:11 |
| 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:28 |
| bjsnider | i830. never heard of that one | 03:44 |
| RAOF | Yeah. It's rare, and that doesnt' help. | 03:45 |
| bjsnider | the number suggests it's pretty old i guess | 03:45 |
| 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:46 |
| bjsnider | don't tablets come with their own operating systems? | 03:50 |
| RAOF | Tablet laptops, like the lenovo x300 | 03:50 |
| RAOF | Man, rev 02 Intel hardware is a rich source of hardware bugs. | 03:51 |
| 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:00 |
| 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:32 |
| 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:33 |
| Sarvatt | @@ -1373,6 +1382,8 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scr -- that hunk is missing in ours | 04:34 |
| 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:35 |
| 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:36 |
| Sarvatt | they always had that hunk and fedora doesn't have any changes in the time frame of that diff | 04:37 |
| bryceh | wait, are you sure we're missing that? | 04:38 |
| bryceh | the chunk is | 04:38 |
| 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:39 |
| bryceh | I assume it's fine | 04:40 |
| 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:41 |
| bryceh | I've gotten -ati and xserver under control | 04:42 |
| bryceh | -intel's going in the right direction but needs more attention | 04:42 |
| RAOF | It looks like we'll want to kms-blacklist 845 & 855, which should resolve quite a number. | 04:46 |
| bryceh | yeah I didn't get to i855 but noticed there's a bunch of bug reports there | 04:47 |
| 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:49 |
| * ScottK tries | 04:50 | |
| bryceh | or sometimes just DISPLAY=:0 xrandr --auto | 04:50 |
| * ScottK tries that first | 04:50 | |
| RAOF | That'll be a good one to squirrel away. | 04:51 |
| bryceh | that and 'stty sane' :-) | 04:53 |
| RAOF | Hm. Taking out that cheese has made it clear how hungry I am. Luncheon! | 04:55 |
| bryceh | and Dinner for me! | 04:55 |
| ScottK | DISPLAY=:0 xrandr --output VGA1 --mode 2048x1536 FTW! Thanks bryceh. | 04:57 |
| RAOF | Again these people with huge displays driven over VGA /:? | 04:58 |
| ScottK | RAOF: That was the default after I upgraded. | 04:59 |
| ScottK | I'm not going to leave it that way. | 05:00 |
| ScottK | bryceh: Kwin desktop effects at 1400x1050 on 865G! | 05:28 |
| ScottK | Definitely better than Karmic. | 05:29 |
| 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) | 05:59 |
| RAOF | Sarvatt: Hm. Could this perhaps *also* be related to the “plymouth, nouveau, and more than one screen” hang we've got? | 06:16 |
| * RAOF will be back shortly, after checking this kernel build | 06:17 | |
| RAOF | Good. That patch works as expected. | 06:23 |
| tjaalton | bryceh: ok thanks, updated my setup here | 06:33 |
| 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:51 |
| 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:55 |
| Sarvatt | (with multiple monitors) | 06:56 |
| RAOF | So, what happens if we don't put plymouth on any secondary monitors? | 06:57 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| Sarvatt | yeah thats what i'm thinking, ask them to test with it dropped at worst case (even though that sucks) | 07:05 |
| 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:06 |
| bryceh | we need a Ubuntu Bug Triage drinking game | 07:15 |
| 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:16 |
| bryceh | or "total show stopper" | 07:17 |
| RAOF | No! “I see this behaviour too, on $TOTALLY_DIFFERENT_HARDWARE” | 07:17 |
| RAOF | s/behaviour/bug/ | 07:18 |
| 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:21 |
| 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:23 |
| Sarvatt | that happening on NV50+ too? | 07:24 |
| RAOF | Yes. | 07:25 |
| 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:28 |
| 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:30 |
| 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:32 |
| 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:33 |
| bryceh | I feel like a dunce for not mentioning it already since it's >exactly< what I've been fiddling with all afternoon | 07:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| bryceh | well, see #556631 as another example, where it's >2048 | 07:42 |
| 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:45 |
| 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:46 |
| 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:47 |
| RAOF | Yeah. I just thought of that. | 07:48 |
| 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:49 |
| Sarvatt | sheesh, how did i not notice that, i've known about this problem since december :D | 07:54 |
| Sarvatt | ah nevermind thats just the fix for == which *should* work, i need sleep | 07:55 |
| bryceh | heh, you saying I'm not alone in being a dunce? | 07:56 |
| 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:57 |
| bryceh | heya mvo | 07:59 |
| 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:02 |
| mvo | hey bryceh | 08:03 |
| 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:07 |
| mvo | bryceh: so compiz is not correctly detecting that it can not work in this environment? | 08:10 |
| bryceh | mvo, right | 08:11 |
| mvo | bryceh: that is very possible, the code that detects this has changed in lucid | 08:12 |
| mvo | bryceh: aha, I see put that in comment #15 already | 08:13 |
| 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:14 |
| bryceh | mvo, great | 08:15 |
| 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:18 |
| 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:27 |
| mvo | bryceh: it looks like a webkit issue to me | 08:28 |
| mvo | bryceh: or do you have a recipe to reproduce? | 08:29 |
| * bryceh ponders | 08:29 | |
| 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:30 |
| mvo | ok, so just clicking on the "enlarge" screenshot picture? | 08:31 |
| 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:33 |
| 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:35 |
| * mvo nods | 08:44 | |
| 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 | 09:19 |
| bryceh | Mirv, no | 10:34 |
| Mirv | bryceh: amd64 or not? | 11:34 |
| 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 | 11:35 |
| === BUGabundo is now known as BUGabundo_lunch | ||
| === BUGabundo_lunch is now known as BUGa_vacations | ||
| bryceh | haha http://article.gmane.org/gmane.linux.kernel/969355 | 18:06 |
| * BUGa_vacations reads | 18:24 | |
| BUGa_vacations | thanks bryceh | 18:25 |
| BUGa_vacations | I needed that | 18:25 |
| BUGa_vacations | MAUAUUAU | 18:28 |
| BUGa_vacations | bryceh: look at the date | 18:28 |
| bryceh | BUGa_vacations, sure or read the rest of the thread http://thread.gmane.org/gmane.linux.kernel/969355 | 18:30 |
| tjaalton | bloody hell, waltop/wacom merge works | 20:16 |
| 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:45 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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. | 20:59 |
| bryceh | my guess/assumption is they'd all be fixable after this patch is in place | 21:00 |
| 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 | 21:01 |
| 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:46 |
| RAOF | merriam: Which bug is this? The == 2048 width bug, or a > 2048 dimension bug? | 23:51 |
| merriam | == | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
