| === wgrant_ is now known as wgrant | ||
| bryceh | RAOF, tjaalton: any concerns if I upload the mesa 8.0.3 merge to quantal now? | 02:01 |
|---|---|---|
| RAOF | I'm good with that. | 02:01 |
| bryceh | alrighty | 02:02 |
| bryceh | up it goes | 02:03 |
| tjaalton | bryceh: yeah, thanks | 05:31 |
| mlankhorst | hm, does xorg 1.12 have the signal safe stuff? | 08:58 |
| jcristau | no | 08:59 |
| jcristau | iirc | 08:59 |
| tjaalton | not even a point-release? | 09:06 |
| tjaalton | hmm was it the security fix or something else? | 09:06 |
| tjaalton | got it now, apparently still under testing | 09:08 |
| mlankhorst | but yeah updating my laptop now, might as well do a thorough sru of https://bugs.launchpad.net/ubuntu/precise/+source/xserver-xorg-input-synaptics/+bug/941953 and confirm it in quantal first :) | 09:18 |
| ubottu | Launchpad bug 941953 in xserver-xorg-input-synaptics (Ubuntu Precise) "Xorg crashed with SIGSEGV in WriteToClient() with buf = 0x100000000 from ProcXIGetProperty()" [High,Triaged] | 09:18 |
| mlankhorst | looks like my desk is getting too small already :) | 09:20 |
| seb128 | mlankhorst, hey | 09:45 |
| mlankhorst | hey | 09:52 |
| seb128 | mlankhorst, how are you? | 09:54 |
| mlankhorst | im good, you? | 09:54 |
| seb128 | mlankhorst, I'm good thanks | 09:54 |
| seb128 | mlankhorst, is there any reason you are not on #ubuntu-desktop? ;-) | 09:54 |
| mlankhorst | woops must have left at one point and never rejoined | 09:54 |
| seb128 | mlankhorst, ok, Laney is having login issues and we were looking for xorg expertise ;-) | 09:55 |
| seb128 | is Xephyr segfaulting on precise for others as well? | 10:16 |
| tjaalton | how do you use it? | 10:18 |
| seb128 | tjaalton, Xephyr :1 | 10:18 |
| seb128 | DISPLAY=:1 somecommand | 10:18 |
| seb128 | rather | 10:20 |
| seb128 | - Xephyr :1 as my user | 10:20 |
| seb128 | su testuser | 10:20 |
| seb128 | DISPLAY=:1 gnome-settings-daemon | 10:20 |
| seb128 | which leads to a | 10:20 |
| seb128 | Backtrace: | 10:20 |
| seb128 | 0: Xephyr (xorg_backtrace+0x37) [0xea1107] | 10:20 |
| seb128 | 1: Xephyr (0xd02000+0x1a2e8a) [0xea4e8a] | 10:20 |
| seb128 | 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x25640c] | 10:20 |
| seb128 | every time | 10:21 |
| jcristau | get a debug build and use gdb? | 10:21 |
| seb128 | no xserver-xephyr-dbgsym and xserver-xorg-core-dbg doesn't include it :-( | 10:25 |
| seb128 | I guess I will need to rebuild xorg | 10:25 |
| seb128 | http://pastebin.ubuntu.com/1048865/ is the non debug bt | 10:25 |
| tjaalton | I ran xterm inside xephyr, and exiting it caused a similar segfault | 10:27 |
| tjaalton | I think we have several of these reported against xserver | 10:29 |
| seb128 | tjaalton, do you have a number I can track and maybe milestone for 12.04.1? ;-) | 10:30 |
| tjaalton | bug 1009629 | 10:31 |
| ubottu | Launchpad bug 1009629 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in DeliverRawEvent()" [High,Confirmed] https://launchpad.net/bugs/1009629 | 10:31 |
| seb128 | tjaalton, thanks | 10:32 |
| jcristau | possibly https://lists.debian.org/debian-x/2012/05/msg00240.html? | 10:35 |
| jcristau | sadly no bt in that bug though | 10:36 |
| tjaalton | in the lp one? right | 10:36 |
| tjaalton | but does look similar | 10:36 |
| jcristau | yeah looks the same | 10:37 |
| jcristau | there's a revert in 1.12-branch that fixes it | 10:37 |
| tjaalton | oh | 10:37 |
| jcristau | 58dfb13953af71021317b9d85230b1163198f031 | 10:37 |
| tjaalton | I'll check it out | 10:37 |
| tjaalton | uh, there was an sru to _add_ that code | 10:39 |
| tjaalton | seb128: can you reproduce it with -0ubuntu10.1? | 10:39 |
| tjaalton | if you can find it.. | 10:39 |
| seb128 | tjaalton, let me try, do I need to downgrade only xserver-xephyr? | 10:40 |
| tjaalton | seb128: maybe so, I think the code is builtin | 10:40 |
| seb128 | tjaalton, https://launchpad.net/ubuntu/+source/xorg-server/2:1.11.4-0ubuntu10.1 has the binaries if you want btw | 10:40 |
| tjaalton | yeah I'll try it as well | 10:41 |
| seb128 | tjaalton, yeah, no segfault with that version | 10:41 |
| tjaalton | confirmed | 10:42 |
| tjaalton | bad cnd :) | 10:43 |
| tjaalton | wonder if there was another fix upstream for the original bug | 10:43 |
| seb128 | cnd, no cookie for you! | 10:43 |
| tjaalton | thanks jcristau for the pointer | 10:43 |
| tjaalton | seb128: I added a note to the bug | 10:45 |
| seb128 | tjaalton, thanks | 10:45 |
| seb128 | tjaalton, who should be assigned to this bug? we want to make sure that regression is fixed before 12.04.1 | 10:46 |
| mlankhorst | seb128: pick me? | 10:47 |
| seb128 | mlankhorst, done, thanks ;-) | 10:47 |
| mlankhorst | we'll probably move to 1.13 though | 10:48 |
| tjaalton | not for precise | 10:48 |
| RAOF | That's *totally* SRUable. No new features at all! | 10:49 |
| tjaalton | :) | 10:49 |
| mlankhorst | hehehe :P | 10:49 |
| tjaalton | maybe the original bug would need to be reopened as well | 10:49 |
| tjaalton | bug 968845 | 10:49 |
| ubottu | Launchpad bug 968845 in xserver-xorg-input-synaptics (Ubuntu Quantal) "bcm5974 touchpad doesn't work after S3 on MacBookAir" [Medium,Fix released] https://launchpad.net/bugs/968845 | 10:49 |
| seb128 | while you guys are around | 10:52 |
| seb128 | could somebody look at https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/962892 | 10:52 |
| ubottu | Launchpad bug 962892 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __assert_fail_base() unless clear compiz/unity settings" [High,Triaged] | 10:52 |
| seb128 | it's getting quite some dups on launchpads and on errors.ubuntu.com | 10:52 |
| tjaalton | what a messy bug | 10:57 |
| tjaalton | looks like the duplicate bot isn't that helpful there | 10:58 |
| tjaalton | some have fglrx loaded, mostly intel though | 10:58 |
| mlankhorst | tjaalton: the original report is a assert(0) in intel ddx | 10:58 |
| mlankhorst | so ignore the fglrx ones.. | 10:58 |
| tjaalton | right | 10:58 |
| mlankhorst | seb128: I'm going to take a look :) | 10:59 |
| seb128 | mlankhorst, thanks | 10:59 |
| tjaalton | yeah, i'll reboot instead | 10:59 |
| seb128 | tjaalton, mlankhorst: you can check the reports on errors.ubuntu.com as well they might have useful infos | 11:01 |
| seb128 | open http://errors.ubuntu.com, entry xserver-xorg-core in the entry and select "month" in the combo | 11:01 |
| seb128 | it's the first bug listed, if you click on the function you have the list of individual reports | 11:02 |
| mlankhorst | 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) | 11:02 |
| mlankhorst | specific error seems to be assert(0) when it can't identify the generation of bufmgr_gem->pci_device | 11:02 |
| mlankhorst | but it should be recognising it as gen6 if I'm reading it right.. | 11:10 |
| tjaalton | it's also a hybrid system, like many on the bug | 11:29 |
| tjaalton | of the dupes | 11:29 |
| mlankhorst | i noticed, but running updates now to test | 11:30 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/984189 is not hybrid though | 11:40 |
| ubottu | Launchpad bug 962892 in xorg-server (Ubuntu) "duplicate for #984189 Xorg crashed with SIGABRT in __assert_fail_base() unless clear compiz/unity settings" [High,Triaged] | 11:40 |
| mlankhorst | hm getting a different bug instead | 11:43 |
| tjaalton | yeah not all dupes had hybrid | 11:45 |
| mlankhorst | some early corruption in xserver-xorg | 11:46 |
| mlankhorst | awesome :) | 11:46 |
| tjaalton | i've unduped 984189 | 11:50 |
| tjaalton | looks like another snb crasher, probably fixed already | 11:50 |
| mlankhorst | damageRegionProcessPending | 11:57 |
| tjaalton | you can repro it? | 11:59 |
| mlankhorst | I'm hitting another bug | 12:01 |
| mlankhorst | damageRegionProcessPending for some reason | 12:01 |
| mlankhorst | I'll see if I can attach valgrind again | 12:02 |
| * mlankhorst looks for the signal patches again | 12:04 | |
| mlankhorst | yay, worth it | 14:04 |
| mlankhorst | ==1651== Address 0xdfdfdfdfdfdfdff7 is not stack'd, malloc'd or (recently) free'd | 14:04 |
| tjaalton | i sent three drm/i915 commits to stable@, makes at least my ivb stable :) | 14:05 |
| mlankhorst | so it seems my crash is caused by freed memory | 14:05 |
| mlankhorst | my X server is called 'exec /usr/bin/valgrind --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" &> /home/mlankhorst/nfs/vg' :) | 14:07 |
| mlankhorst | http://pastebin.com/xg2yfXKs | 14:08 |
| cnd | tjaalton, seb128, mlankhorst: only Jeremy Huddleston saw the crash on OS X, so I didn't bother with reverting the added patch | 14:11 |
| cnd | we will need to cherry-pick a couple of patches that fix it cleanly, IIRC | 14:11 |
| seb128 | cnd, it happens every time you use Xephyr and close a client | 14:11 |
| cnd | fun | 14:12 |
| mlankhorst | weird.. I'll try upstart xf86-video-intel | 14:12 |
| cnd | mlankhorst, did you chat with RAOF about synaptics? | 14:13 |
| tjaalton | cnd: btw, is the precise xserver missing some input fixes from 1.12.x? can't recall what it maps to | 14:13 |
| tjaalton | i mean _other_ fixes ;) | 14:13 |
| cnd | tjaalton, it maps to 1.12.1 + the patches in debian/patches | 14:13 |
| mlankhorst | cnd: ugh some other issues popped up in between, I wanted to reproduce it on this laptop first with valgrind but it dies in a new way I haven't seen before | 14:14 |
| cnd | for input | 14:14 |
| tjaalton | oh right | 14:14 |
| tjaalton | yeah | 14:14 |
| mlankhorst | I'll try the other one | 14:14 |
| cnd | mlankhorst, do you have a macbook? | 14:14 |
| mlankhorst | nope | 14:14 |
| cnd | mlankhorst, then there's a low chance you'll be able to reproduce it easily | 14:15 |
| cnd | I can only reproduce it on a macbook air | 14:15 |
| mlankhorst | cnd: k | 14:15 |
| mlankhorst | which issue specifically? | 14:16 |
| cnd | mlankhorst, when you close the lid, the screen interacts with the touchpad and causes many dancing touches | 14:17 |
| cnd | and then the device is disabled for suspend | 14:18 |
| cnd | the touches aren't disposed of properly | 14:18 |
| cnd | so on resume, some touches may be "stuck" as active | 14:18 |
| mlankhorst | ah k | 14:21 |
| seb128 | I guess you can probably fake that playing with the lid contact on a normal laptop :p | 14:23 |
| mlankhorst | was thinking the same | 14:24 |
| mlankhorst | just echo mem > /sys/power/state | 14:24 |
| mlankhorst | wait.. why does irssi have tab completion for that? | 14:24 |
| Prf_Jakob | So yeah, you guys need to blacklist the AMD SI driver from Unity. | 15:33 |
| Prf_Jakob | No cayman | 15:33 |
| mlankhorst | hm, just running X with valgrind is providing plenty of amusement.. | 16:05 |
| mlankhorst | bryceh/RAOF: If we decide to push x 1.12, can we upstream the signal safe patches too and force some testing with valgrind? | 16:51 |
| bryceh | mlankhorst, some patches can be upstreamed (and are on my todo list), but a few are not going to be acceptable upstream | 16:52 |
| mlankhorst | I mean, I was tracking why i915 was refusing to log in only to notice that upstream added another regression on top :s | 16:53 |
| mlankhorst | and seeing how many different bugs in x org are memory based it would be nice to have as feature.. | 16:57 |
| tjaalton | how do you force testing with valgrind?-) | 16:59 |
| mlankhorst | create a shell script X2 with contents: | 17:00 |
| mlankhorst | exec /usr/bin/valgrind --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" &>> /home/mlankhorst/nfs/vg.$(hostname) | 17:00 |
| mlankhorst | look for any suspicious read/write errors or crashes | 17:00 |
| mlankhorst | bryceh: hm any thoughts on this ? http://pastebin.com/qFpTpMzx | 17:21 |
| bryceh | drawableDamage(pDrawable); | 17:25 |
| bryceh | hmm | 17:25 |
| mlankhorst | df is my valgrind free-fill | 17:26 |
| mlankhorst | but from whatI can tell it should only nuke that drawable if refcount drops to zero, which it did. | 17:30 |
| bryceh | I wonder if it's caused by this cast: | 17:31 |
| bryceh | return (char *) (*privates) + key->offset; | 17:31 |
| mlankhorst | don't think so, it just looks like that's how it registers private data into it | 17:32 |
| bryceh | or something. the "Invalid read of size 8" errors are complaining about differences in variable sizes | 17:33 |
| mlankhorst | I think it's simply reffing the damage after the pixmap was freed, but I don't see how.. | 17:33 |
| seb128 | mlankhorst, I'm not a valgrind expert but --leak-check=full might help to stop where it was freed | 17:35 |
| seb128 | mlankhorst, not sure if --leak-resolution=high does the same | 17:35 |
| seb128 | mlankhorst, I just know that the one we listed is on our standard set of flags for desktop debugging | 17:35 |
| mlankhorst | seb128: no that's on exit | 17:35 |
| seb128 | ok | 17:35 |
| mlankhorst | --leak-check=<no|summary|yes|full> [default: summary] | 17:36 |
| mlankhorst | When enabled, search for memory leaks when the client program finishes. If set to summary, it says how many leaks occurred. If set | 17:36 |
| mlankhorst | to full or yes, it also gives details of each individual leak. | 17:36 |
| mlankhorst | I need to set --track-origins=yes though | 17:36 |
| mlankhorst | more slowdown :) | 17:36 |
| bryceh | mlankhorst, yeah not sure what's going on there. If you got a reproducible case, might chat with ickle | 17:38 |
| mlankhorst | bryceh: yeah seems to happen on upstream intel too | 17:39 |
| mlankhorst | it's annoying since it blocks login | 17:41 |
| mlankhorst | hm just to be sure I'll try without valgrind patch | 17:58 |
| mlankhorst | bryceh: hm, at this point I'm not even 100% sure it's intel specific, I'll cut down on other options | 18:18 |
| mlankhorst | https://bugs.freedesktop.org/show_bug.cgi?id=51240 added :) | 18:34 |
| ubottu | Freedesktop bug 51240 in Driver/intel "[i915] crash in damageRegionProcessPending on login" [Normal,New: ] | 18:34 |
| mlankhorst | hm was afraid of that, some changes between x 1.11 and x 1.12 | 20:28 |
| Sarvatt | mlankhorst: i dont even see that commit in xserver at all | 20:32 |
| mlankhorst | Sarvatt: well with the x 1.12 I uploaded to x-staging ppa things work, so I guess there's probably some truth to it | 20:33 |
| bryceh | Sarvatt, hey I'm looking at the gpu lockup udev rule. | 20:35 |
| bryceh | currently we trigger on ERROR=1 from the kernel. there is also a RESET=1 which apparently happens later but still prior to the reset | 20:35 |
| bryceh | one of the Intel guys suggested moving to RESET=1 might eliminate the false gpu lockups | 20:36 |
| Sarvatt | sounds right to me, we did it on ERROR=1 before to grab an intel_gpu_dump of the actual crash before but its automatically captured in debugfs now | 20:53 |
| bryceh | right | 20:53 |
| bryceh | Sarvatt, ok... I'll test it on a couple systems but expect to have it in within the week; ping me if you spot anything wonky... I think you tend to notice gpu weirdness before anyone else here :-) | 20:54 |
| mlankhorst | night all :) | 20:59 |
| * bryceh waves | 21:12 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!