| Sarvatt | nevermind, was a kernel fix, thought we might have another bug symptom potentially fixed by that | 00:05 |
|---|---|---|
| raevol | hey guys | 08:34 |
| raevol | nevermind | 08:34 |
| === yofel_ is now known as yofel | ||
| LLStarks | are there any important uds meetings for the x team? i might want to audit a couple. | 10:23 |
| RAOF | There are a bunch. | 10:24 |
| RAOF | You can find them on launchpad; they use the “desktop-o-xorg-*” naming scheme. | 10:25 |
| jcastro | the general team rah rah one is on thursday iirc | 13:53 |
| Sarvatt | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/774978 is looking like a common one going through intel bugs, apparently started around april 20th | 16:31 |
| ubot4` | Launchpad bug 774978 in xserver-xorg-video-intel (Ubuntu) "xserver seg'd [945GM] (affects: 4) (dups: 2) (heat: 26)" [High,Confirmed] | 16:31 |
| Sarvatt | RAOF: didn't get this worked around on the compiz side? | 16:32 |
| Sarvatt | RAOF: also your fix is in rc6, can ya forward it to stable? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=498548ec69c6897fe4376b2ca90758762fa0b817 | 16:36 |
| bryceh | Sarvatt, looks similar to 525066 which was closed 3/18 with xserver 1.10 | 17:35 |
| bryceh | Sarvatt, presumably 0801afbd was believed to be the fix, although looking at the patch it's not really a fix just stops it looping on errors | 17:36 |
| Sarvatt | added some test kernels on https://bugs.launchpad.net/ubuntu/natty/+source/unity/+bug/740126 -- thats probably the most urgent bug on the intel side at the moment and doesn't get automatically reported since it's not an actual gpu hang. I can reproduce it on all my intel machines by closing the lid or xset dpms force off | 17:50 |
| ubot4` | Launchpad bug 740126 in unity (Ubuntu Natty) (and 6 other projects) "Something blocks compiz randomly several times per day (affects: 29) (dups: 6) (heat: 162)" [High,Triaged] | 17:50 |
| Sarvatt | bryceh: that libdrm regression we thought we had did turn out to be that bug too | 17:52 |
| bryceh | Sarvatt, oh? tell me more | 17:53 |
| bryceh | btw on 774978 any idea on what he's doing that exercises the record extension? afaik that is not a typical code path most people use | 17:54 |
| bryceh | so I'm wondering if there's a way we could repro the crash | 17:54 |
| Sarvatt | bryceh: apparently importing a bunch of books into calibre and scrolling through the list will reproduce it, but I can't reproduce it that way here | 17:55 |
| Sarvatt | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/776749 | 17:56 |
| ubot4` | Launchpad bug 776749 in xserver-xorg-video-intel (Ubuntu) "xserver crashed with segfault in RecordAReply (dup-of: 774978)" [Undecided,New] | 17:56 |
| ubot4` | Launchpad bug 774978 in xserver-xorg-video-intel (Ubuntu) "xserver seg'd [945GM] (affects: 4) (dups: 2) (heat: 26)" [High,Confirmed] | 17:56 |
| bryceh | yeah I tried installing x11vnc and doing vncvlient operations (which another bug specified as the way to repro) but no luck | 17:57 |
| bryceh | I've a hunch why it crashes but I'd really like to reproduce it to be sure | 17:58 |
| Sarvatt | hopefully albert23 comes on soon and can tell us what kind of magic needs to be done in calibre to reproduce it :) I was assuming it was the book cover popups but might be having more than a page of books and scrolling through that, hmm | 18:02 |
| Sarvatt | only added 3 books and was scrolling through those fast for about 10 minutes last night | 18:02 |
| jcastro | bryceh: you guys are probably getting this question a bunch I bet: http://askubuntu.com/questions/40055/when-will-the-catalyst-11-4-driver-be-available | 18:16 |
| soreau | Hi guys, I'm trying to figure out how to convince X to not put the monitor to sleep. I've disabled power manager from startup programs and set Never in both available fields of power settings, also have this in xorg.conf http://pastebin.ca/2053899 | 18:20 |
| soreau | This works in maverick but not natty | 18:21 |
| Sarvatt | soreau: disable the "activate when idle" option in gnome-screensaver and tell g-p-m to never put the display to sleep when idle in the options? works for me | 18:22 |
| soreau | Sarvatt: oh duh | 18:23 |
| soreau | I had screensaver set to the default blank screen | 18:23 |
| Sarvatt | yeah first thing I always fix on a new install here, hate that :( | 18:24 |
| Sarvatt | jcastro: I'm not really clear on it (tseliot is the one to ask) but from what I've understood major blob updates aren't really something that can be SRUed. luckily the ati drivers from amd.com can be installed easily unlike nvidia | 18:26 |
| Sarvatt | cool! chromium has a download progress indicator in the unity icon now | 18:32 |
| Sarvatt | i'll upload fglrx 11.4 to ppa:ubuntu-x-swat/x-updates at any rate | 18:33 |
| bryceh | Sarvatt, well I think that what the calibre bug is, is that 'stuff' is never defined afaict | 18:56 |
| bryceh | 613 majorop = stuff->reqType; | 18:56 |
| bryceh | so it faults there trying to deref it | 18:56 |
| bryceh | Sarvatt, but this code hasn't changed in years; if this is why it's broken it's been broken a loooong time | 18:57 |
| bryceh | also I'm unsure how to fix it | 18:57 |
| bryceh | and curious why it'd only start happening a couple weeks ago | 18:58 |
| bryceh | anyway, bumped it back to the reporter, I think we need more info | 19:11 |
| Sarvatt | jcastro: looks like the main issue AMD has on the fglrx side is having sync to vblank enabled in the compiz opengl plugin introducing massive stuttering on their driver, so if you are getting crappy performance I suggest disabling that as a workaround until it gets fixed :) | 19:23 |
| jcastro | yeah I did that | 19:23 |
| jcastro | but even then their new driver is much faster, and is absent the once a day crash I was having with the one that came with 11.04 | 19:24 |
| Sarvatt | jcastro: that's a good justification for a SRU update, do you happen to have (or know of) a bug filed for the crashes? updating because its faster might not fly | 19:27 |
| jcastro | no but I can easily reproduce it on my x120e | 19:27 |
| jcastro | are you coming to UDS? | 19:27 |
| bryceh | Sarvatt, jcastro, no, the archive admins will reject an -fglrx update as an SRU | 19:29 |
| bryceh | we can (and should) put it in x-updates but that's pretty much as far as we're allowed to go with it | 19:30 |
| Sarvatt | (I uploaded it there about an hour ago, still waiting to build) | 19:30 |
| Sarvatt | was hoping there would be some leeway since we're shipping a beta of 11.4 and would be updating to the released 11.4 | 19:30 |
| jcastro | Sarvatt: I'll just point people to x-updates | 19:32 |
| jcastro | bryceh: is there anyone we need to convince? I can just show them the hard lockups | 19:33 |
| bryceh | jcastro, pitti | 19:33 |
| albert23 | Sarvatt: I have 11 ebooks in calibre. | 19:42 |
| bryceh | jcastro, however I also don't think trying to solicit an SRU exception in this case is the best solution | 19:42 |
| albert23 | I was thinking about http://lists.freedesktop.org/archives/xorg-devel/2011-February/018941.html as a possible cause of the crash | 19:42 |
| jcastro | bryceh: I'm easy, I'll do whatever you think is best. :) | 19:43 |
| bryceh | jcastro, what I think we really need is a better mechanism to roll out full-cloth driver updates ala x-updates | 19:43 |
| bryceh | jcastro, so like one idea would be to mod jockey to display both the stock fglrx and any available update fglrx's, for the user to selectively install if they wish | 19:43 |
| jcastro | bryceh: right, like fresh backports kinda thing. | 19:44 |
| bryceh | I *think* that would satisfy the concerns pitti raises about -fglrx sru's | 19:44 |
| bryceh | jcastro, right, but integrated nicely into jockey | 19:44 |
| jcastro | we need something like that for wireless too, I bet we could do the same thing for a group of things like these kinds of drivers | 19:44 |
| bryceh | admittedly not something doable for natty now that it's out, but iirc we discussed it before and it was not shot down as an idea. would be nice to get it in place longer term | 19:45 |
| bryceh | jcastro, exactly | 19:45 |
| bryceh | then we're solving a more general problem, rather than (ahem 'wasting') time on fighting to get stuff in via the sru process | 19:45 |
| albert23 | does cid in this line translate to a client in X? 000:<:5cc6: 16: Request(55): CreateGC cid=0x03c00ba8 drawable=0x03c00066 values={} | 19:46 |
| bryceh | jcastro, potentially could be usable for open source drivers as well, if there are updates we feel are suitable for deploying on the stable release | 19:46 |
| bryceh | (i.e., X driver updates that don't require new libdrm or mesa or whatnot) | 19:46 |
| jcastro | bryceh: right, I expect the open driver for this fusion laptop to improve rather quickly now that they're shipping | 19:46 |
| jcastro | tbh right out of the box it wasn't bad per se | 19:47 |
| bryceh | jcastro, this concept would be nice to get in place for the LTS, in that it would give another avenue for doing maintenance longer term | 19:47 |
| bryceh | albert23, I would think it is referencing an internal structure, but it's possible it maps to the X client id | 19:47 |
| bryceh | albert23, maybe check wmctrl -l | 19:50 |
| bryceh | albert23, one thing I'm wondering which you might check, is how that 'stuff' pointer gets defined? | 19:53 |
| bryceh | albert23, it looks like it's an uninitialized pointer that gets deref'd at the point your crash occurs, however this section of code hasn't changed in as far back as the git logs go | 19:53 |
| albert23 | bryceh: wmctrl looks interesting but the numbers don't match xtrace exactly | 19:54 |
| albert23 | bryceh: stuff becomes defined by REQUEST(xReq); | 19:54 |
| bryceh | albert23, yep, then like I said those are probably just internal pointer values | 19:54 |
| bryceh | albert23, aha, ok | 19:54 |
| bryceh | macros *sigh* | 19:55 |
| bryceh | albert23, still, the backtrace indicates something is fishy with that stuff pointer ('invalid memory') | 19:56 |
| bryceh | perhaps it is getting freed and then re-referenced | 19:56 |
| albert23 | bryceh: indeed | 19:56 |
| bryceh | ran across another similar bug (long since closed) where something like that was happening | 19:56 |
| albert23 | so I thought the "thing" that asked for the WaitMSC has gone when the WaitMSC evenet is triggered | 19:56 |
| albert23 | bryceh: btw, bug 775724 looks very similar with radeon | 19:59 |
| ubot4` | Launchpad bug 775724 in xorg-server (Ubuntu) "xorg crash (affects: 3) (heat: 14)" [Undecided,Incomplete] https://launchpad.net/bugs/775724 | 19:59 |
| bryceh | albert23, yeah although doesn't appear to pass through record.c | 20:00 |
| bryceh | (unless that's what step #1 is) | 20:01 |
| bryceh | (no, it wouldn't be) | 20:01 |
| bryceh | but the WriteToClient() but looks similar, yeah | 20:02 |
| bryceh | hmm, actually I could see #1 as being a record.c call | 20:03 |
| albert23 | ah, bug 771169 goes through librecord on radeon | 20:03 |
| ubot4` | Launchpad bug 771169 in xorg-server (Ubuntu) "X crashed while browsing with Chromium (librecord.so related?) (affects: 2) (dups: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/771169 | 20:03 |
| bryceh | albert23, yep you're right | 20:03 |
| albert23 | there were some patches on xorg-devel in February that look like they may be related. | 20:04 |
| albert23 | Raof reviewed them, so maybe he knows more | 20:04 |
| Sarvatt | earliest I can find is 04-18, compiz update screwing with vsync on 0415 looks possible for when it started triggering more often | 20:12 |
| albert23 | Sarvatt: did they switch on sync to vblank? Without sync to vblank I don't get the crash | 20:14 |
| albert23 | btw, I only started using calibre last week, so I have no idea if the bug may be older | 20:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!