| broder | RAOF: hey - how hard is it to tell from GPU hang data whether it's a bug that's been fixed already? | 04:05 |
|---|---|---|
| RAOF | I think it depends. | 04:07 |
| RAOF | And in what way hard? Automated hard? Dude looking at it hard? | 04:07 |
| broder | Either. I have an apport report from a Natty machine, and I'm wondering whether this is a "cherry-pick one patch and move on" or "cry in a corner" grade of problem. http://web.mit.edu/broder/Public/xserver-xorg-video-intel.2012-01-21.crash if you have a second | 04:08 |
| RAOF | Certainly some bugs are easy to tell; there's an obviously-bad value in the command stream. And by ‘obviously’ I mean ‘obvious to someone who fixed the bug’ :) | 04:08 |
| broder | I seem to be able to reproduce it with some amount of consistency by going from either an extended or cloned monitor layout to just the external being enabled. Symptomatically the screen is all black | 04:09 |
| broder | Actually...I wonder if this is connected to the issue where GnomeRR screws up the CRTC config on the external display | 04:10 |
| RAOF | It looks to me like that gpu dump isn't useful; it seems to have fallen off the end. | 04:11 |
| broder | :-/ | 04:12 |
| RAOF | I suspect that might have picked up the post-reset hardware state. | 04:13 |
| broder | I forget - how much of the relevant data is gathered when I run apport-collect/ubuntu-bug as opposed to when the hang actually occurs? | 04:14 |
| RAOF | The most useful information - the gpu dump - is collected when the hang occurs. | 04:15 |
| broder | Hmm, ok. Phrased differently, given that I can reproduce the issue without too much difficulty, is there something else I can do to get better debugging output? | 04:15 |
| RAOF | drm.debug=0x4 might spew something interesting into dmesg; and a newer kernel has better gpu hang reporting. But that latter thing's not very useful for you :) | 04:16 |
| broder | I can try to drop in a newer kernel. I suppose the risk is that it fixes the bug as a side-effect :) | 04:17 |
| RAOF | Right :) | 04:18 |
| cnd | RAOF, are we pushing X today? | 04:37 |
| RAOF | cnd: I'm not sure. There's the Xorg metapackage left to go - tjaalton was on that - and an intel upload. Things got delayed by the PPA running out of room. It's now got 4GiB of space, and so that's resolved. | 04:38 |
| cnd | ok | 04:38 |
| * cnd is getting anxious :) | 04:38 | |
| RAOF | :) | 04:42 |
| RAOF | By the way, is there an obvious place to get the unclamped input history of a master device anywhere? | 04:42 |
| RAOF | (ie: not clamped to the screen) | 04:42 |
| cnd | RAOF, raw events? | 04:51 |
| RAOF | Yeah, I guess so. | 04:52 |
| RAOF | And maintain my own history. | 04:52 |
| cnd | the only way to get history that I'm aware of is the XI 1.x motion history | 04:52 |
| RAOF | Or, rather, pull stuff out of valuators[0] and [1]. | 04:52 |
| cnd | and that is only the history of the normal events | 04:52 |
| RAOF | Yeah. | 04:52 |
| cnd | though I'm not sure if master devices spit out raw events | 04:53 |
| cnd | I bet they do, but you'd want to double check | 04:53 |
| RAOF | Since I'm actually in the server I can just pull stuff out of the DeviceIntPtr | 04:54 |
| cnd | RAOF, and maintain the history yourself? | 04:56 |
| RAOF | Yup. I only need this, this-1 anyway. | 04:56 |
| cnd | ahh, ok | 04:57 |
| RAOF | tjaalton: You're doing the Xorg metapackage? | 04:58 |
| RAOF | cnd: If I want the valuator in screen coordinates I'll need to rescale it, right? | 04:59 |
| cnd | hmmm | 04:59 |
| cnd | it potentially depends :) | 04:59 |
| RAOF | :) | 05:00 |
| RAOF | I'll follow stuff through, then. | 05:00 |
| cnd | I would imagine the coordinates are stored in screen coords already | 05:00 |
| cnd | that's my best educated guess without looking at the code | 05:00 |
| RAOF | I think they are for master devices. | 05:00 |
| cnd | and it's still my sunday night, so... | 05:00 |
| cnd | :) | 05:00 |
| cnd | RAOF, that sounds familiar | 05:00 |
| RAOF | Yeah, certainly. Just picking your brains while you're here :) | 05:00 |
| cnd | like for master devices the device int ptr holds screen coords while for slaves it holds device coords | 05:01 |
| cnd | I think there's a comment to that effect | 05:01 |
| RAOF | Good, that concords with my understanding. I'll also check that I get sane values out, but that should work nicely. | 05:02 |
| RAOF | Oh, whoops. Need to cherry-pick an additional patch for the xserver. | 05:03 |
| tjaalton | RAOF: it's basically done on git, maybe just needs another pair of eyes to check it through | 05:32 |
| RAOF | Ok, cool. | 05:34 |
| tjaalton | maybe I'll just upload it to the ppa | 05:36 |
| tjaalton | now that there's room | 05:36 |
| RAOF | I can give it a look over if you like, but you could just upload. | 05:36 |
| tjaalton | i'll just do that | 05:38 |
| tjaalton | done | 05:44 |
| tjaalton | now off to feed the kids :) -> | 05:45 |
| RAOF | :) | 05:46 |
| broder | RAOF: if i drop precise's kernel on top of natty to test this GPU lockup, do you know off the top of your head if natty's detection/state dump tools still work? | 06:50 |
| RAOF | Yes, they should. | 06:50 |
| broder | Cool | 06:51 |
| tjaalton | hmm uploaded xorg to a non-existing ppa first, should be ok now | 07:16 |
| tjaalton | RAOF: wacom works | 08:14 |
| tjaalton | hum, I'll merge xkb-data | 08:37 |
| tjaalton | RAOF: would you agree that we can drop the dvorak-intl -> dvorak-alt-intl rename in xkb-data, now that oneiric is out? | 09:06 |
| tjaalton | hmm no, after precise | 09:18 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| Milos_SD | hello | 13:52 |
| Milos_SD | will xorg-edgers ppa have xserver 1.12 for oneiric? | 13:52 |
| === yofel_ is now known as yofel | ||
| cnd | tjaalton, do you know where we stand on the x upload? | 16:24 |
| tjaalton | cnd: not really, xorg metapackage is on the ppa so maybe we are good to go and waiting for RAOF to hit the big red button | 17:06 |
| cnd | ok | 17:11 |
| FernandoMiguel | evening | 19:34 |
| cnd | RAOF, let me know when you're on so we can discuss the X upload | 20:30 |
| tjaalton | speaking of which, could we sneak in the new stable release rc? | 20:36 |
| tjaalton | i'll try merging with debian | 20:36 |
| ricotz | tjaalton, yeah, having this ctrl+alt+* thing patched would be nice too | 20:40 |
| tjaalton | ricotz: hm? that's xkb-data | 20:40 |
| tjaalton | no need for xserver patches | 20:41 |
| ricotz | oh, but debian has a xserver patch for it | 20:41 |
| tjaalton | cnd: looks like merging from the upstream stable branch doesn't work without reverting some stuff | 20:41 |
| ricotz | http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=663e92e660a15548f68a764479d7d59ed5c9af64 | 20:42 |
| tjaalton | ricotz: applied before a new xkb-data was available | 20:42 |
| cnd | tjaalton, there's been a new 1.11 stable release? | 20:42 |
| tjaalton | cnd: rc's | 20:42 |
| tjaalton | debian has 1.11.3.901, .902 was released on saturday | 20:43 |
| cnd | tjaalton, it's a pain to merge because of the frankenserver | 20:43 |
| cnd | I'd suggest that if we are ready to push as is, we do so and then update | 20:43 |
| tjaalton | yeah | 20:43 |
| tjaalton | we can merge later | 20:43 |
| albert23 | Hmm, somehow I still have the screensaver bug, with xkb-data 2.3-1ubuntu3 from canonical-x/x-staging | 20:59 |
| albert23 | [ 2185.106] Ungrabbing all devices and killing their owners; grabs listed below: | 20:59 |
| ricotz | tjaalton, ^ | 21:04 |
| ricotz | by any chance, has someone tested fglrx 8.920 or 8.930 with xserver 1.12? | 21:04 |
| albert23 | arg, ubuntu-bug fails, not an official ubuntu package | 21:06 |
| tjaalton | albert23: i can't reproduce it | 21:13 |
| tjaalton | running the same repo | 21:14 |
| albert23 | Tjaalton: I am using a laptop, using numlock so the P becomes *. Could that make a difference? | 21:16 |
| tjaalton | ah me too, tried the wrong key :) | 21:18 |
| tjaalton | let's see.. | 21:18 |
| albert23 | xev says that's XF86ClearGrab, no underscore | 21:18 |
| albert23 | the package diff says XF86_ClearGrab, with underscore | 21:18 |
| tjaalton | yep, still happens | 21:18 |
| jcristau | look at xkbcomp output | 21:19 |
| albert23 | jcristau: which input file should I use for xkbcomp? | 21:25 |
| jcristau | your X server | 21:25 |
| albert23 | xkbcomp :0 gives no output | 21:26 |
| jcristau | xkbcomp :0 - | 21:26 |
| albert23 | lists XF86ClearGrab with KP_Multiply | 21:28 |
| jcristau | sure. | 21:28 |
| jcristau | that's not an issue tho | 21:28 |
| jcristau | you want to check if there's an associated action | 21:29 |
| tjaalton | action= Private(type=0x86,data[0]=0x43,data[1]=0x6c,data[2]=0x73,data[3]=0x47,data[4]=0x72,data[5]=0x62,data[6]=0x00); | 21:29 |
| albert23 | same here | 21:30 |
| jcristau | on a server started after xkb-data was upgraded? | 21:30 |
| albert23 | indeed | 21:31 |
| tjaalton | need to check | 21:31 |
| tjaalton | I did upgrade earlier today and booted the new kernel | 21:31 |
| jcristau | that doesn't make a lot of sense... | 21:31 |
| tjaalton | hm the package was updated three days ago, so yes | 21:31 |
| albert23 | could "XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm" be related? That file is dated 8 December for me | 21:32 |
| jcristau | albert23: yes | 21:32 |
| tjaalton | haha | 21:32 |
| jcristau | very much so. | 21:32 |
| tjaalton | mine is dated 5min after the package update | 21:34 |
| tjaalton | after a reboot | 21:36 |
| tjaalton | hm | 21:36 |
| tjaalton | though it could use an older one.. | 21:36 |
| tjaalton | why of course | 21:36 |
| tjaalton | from september | 21:36 |
| tjaalton | i'm winning.. ;) | 21:37 |
| jcristau | yay moblin patches | 21:37 |
| albert23 | I have multiple too, but youngest is 4 days ago | 21:37 |
| albert23 | So it doesn't seem to rebuild with an update | 21:37 |
| tjaalton | not necessarily no | 21:39 |
| tjaalton | and the server picks a seemingly random one | 21:40 |
| albert23 | it even tries multiple, according to x log | 21:40 |
| tjaalton | eh | 21:41 |
| tjaalton | quality crap | 21:41 |
| albert23 | interesting: it only tries the 3 oldest, dated 8 December, not the youngest | 21:41 |
| tjaalton | ricotz: why bother testing fglrx, it won't work | 21:43 |
| cnd | albert23, so you needed to delete the old xkmfiles to fix the security bug? | 21:45 |
| albert23 | cnd, didn't do that yet | 21:45 |
| cnd | xkm cache files can cause other issues, as I found out a few months ago :) | 21:46 |
| cnd | bryce, RAOF, you guys thought about adding a script or hook somewhere to clean those out | 21:46 |
| jcristau | but, faster boot! | 21:46 |
| cnd | any news on that? | 21:46 |
| bryce | cnd, thought about but no plans | 21:47 |
| jcristau | you could make them live in /run so they go away on their own | 21:47 |
| cnd | jcristau, that would defeat the purpose :) | 21:48 |
| jcristau | not really | 21:48 |
| cnd | they are cached to make subsequent X server starts faster | 21:48 |
| jcristau | you'd run xkbcomp once instead of 3 times per device | 21:48 |
| cnd | or so I've been told | 21:48 |
| jcristau | (ok, maybe not 3, but still) | 21:48 |
| jcristau | i suppose rm them in xkb-data.postinst would make sense too | 21:49 |
| cnd | that's what I'm thinking | 21:49 |
| jcristau | to invalidate the cache | 21:49 |
| ricotz | tjaalton, still hoping, i can't play with fglrx here though, but nvidia has a driver built against 1.12 | 21:49 |
| jcristau | nvidia != fglrx | 21:50 |
| tjaalton | ricotz: built? as in package doesn't conflict? | 21:50 |
| ricotz | jcristau, i dont have a radeon card so i never used it | 21:51 |
| ricotz | tjaalton, as in binary built against the 1.12 video abi | 21:51 |
| tjaalton | which version is that? | 21:51 |
| jcristau | ricotz: me neither. but from experience nvidia works with an xserver release as soon as that exists. fglrx waits until the next one is almost there. | 21:51 |
| ricotz | tjaalton, no public release though, 295.10 | 21:52 |
| tjaalton | ok | 21:52 |
| ricotz | jcristau, right, but as the nvidia binaries tend to work with never servers, i was hoping kind of the same with fglrx | 21:53 |
| tjaalton | not surprising though, since aaronp got upset recently when the abi was going to be broken again | 21:53 |
| ricotz | jcristau, 290.10 kind of works with 1.12 | 21:53 |
| jcristau | ricotz: as i said.. | 21:53 |
| jcristau | nvidia != fglrx | 21:53 |
| ricotz | right | 21:53 |
| albert23 | ok, moved the xkm's away and restarted X. Now I have fresh xkm's and xkbcomp does not show XF86ClearGrab with action anymore. | 21:55 |
| albert23 | screensaver works fine now | 21:56 |
| tjaalton | hm, the staging upload was not in git | 21:56 |
| tjaalton | if dpkg --compare-versions "$2" lt-nl 2.5; then | 21:58 |
| tjaalton | rm -f /var/lib/xkb/*.xkm | 21:58 |
| tjaalton | fi | 21:58 |
| tjaalton | I'll try that.. | 21:59 |
| jcristau | tjaalton: tbh i don't think that should be version-specific | 22:01 |
| tjaalton | yeah | 22:01 |
| tjaalton | true | 22:01 |
| RAOF | cnd: Yo! | 22:01 |
| cnd | RAOF, holla! | 22:01 |
| tjaalton | RAOF: hang on, I've got a xkb-data update under testing ;) | 22:01 |
| RAOF | tjaalton: Merged from Debian? Cool. | 22:02 |
| cnd | tjaalton, with the postinst change to delete the cache? | 22:02 |
| tjaalton | cnd: yes | 22:02 |
| cnd | tjaalton, cool | 22:02 |
| tjaalton | RAOF: read the recent backlog | 22:02 |
| RAOF | Yay xkb cache? | 22:03 |
| tjaalton | that | 22:03 |
| cnd | RAOF, so once tjaalton has the xkb cache issue resolved, are we ready to push? | 22:05 |
| RAOF | I believe so, yes. | 22:06 |
| cnd | cool | 22:07 |
| cnd | mdeslaur, ping | 22:11 |
| mdeslaur | cnd: yes? | 22:18 |
| cnd | so we want to push the latest X bits to precise today | 22:19 |
| mdeslaur | cnd: ok | 22:19 |
| cnd | with a fix that tjaalton is readying for xkb-data, we believe we have addressed the security hole | 22:19 |
| mdeslaur | cnd: ok, great | 22:19 |
| cnd | is there anything we need to do at this point? | 22:20 |
| cnd | or did you just need to check that we had things fixed before pushing? | 22:20 |
| mdeslaur | cnd: I just wanted to make sure the fix went in before it got pushed | 22:20 |
| cnd | ok | 22:21 |
| cnd | thanks for following the issue :) | 22:21 |
| mdeslaur | cnd: thanks for fixing it! | 22:21 |
| cnd | np (though tjaalton and RAOF deserve the credit :) | 22:22 |
| tjaalton | and albert23 for the heads up :) | 22:22 |
| mdeslaur | thanks tjaalton and RAOF too | 22:22 |
| RAOF | :) | 22:22 |
| mdeslaur | and albert23 | 22:22 |
| albert23 | np | 22:22 |
| tjaalton | pushed the commit, fixed it here | 22:26 |
| tjaalton | so it removes the cache files every time postinst is run | 22:27 |
| tjaalton | ok, pushing it to the ppa | 22:31 |
| tjaalton | or, to the archive? | 22:31 |
| tjaalton | does it matter? | 22:31 |
| cnd | tjaalton, I think this can go to the archive | 22:31 |
| tjaalton | yeah | 22:32 |
| cnd | hmm | 22:33 |
| cnd | actually, RAOF pushed it to the ppa last time | 22:33 |
| cnd | you could probably do either, unless xkb-config has an interdependency with the X server | 22:33 |
| RAOF | I did, but there's no reason for this to not go to the archive. | 22:33 |
| RAOF | I pushed it to the PPA since it only fixed a bug found in the PPA; a new upstream version is more widely usefu. | 22:36 |
| tjaalton | pushed to precise | 22:38 |
| tjaalton | RAOF: you have the keys now ;) | 22:45 |
| RAOF | tjaalton: Ok. I'll find out how to turn them :) | 22:45 |
| tjaalton | yeah, noticed :) | 22:45 |
| cnd | \o/ | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!