[00:47] <mornau> hi, i'm having trouble starting X with the radeon driver on oneiric with Sarvatt's x updates: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/972024
[00:47] <ubottu> Launchpad bug 972024 in xorg (Ubuntu) "RADEONDRIGetVersion failed because of version mismatch (1.17.0 -> 2.10.0)" [Undecided,New]
[00:48] <mornau> I would appreciate any help you can provide, or hints on how to improve my report 
[02:09] <lesshaste> hi
[02:09] <lesshaste> I have had to turn off 3d as the system freezes regularly 
[02:09] <lesshaste> I get
[02:09] <lesshaste> [ 1934.458109] [drm] nouveau 0000:01:00.0: fail pre-validate sync
[02:09] <lesshaste> [ 1934.458114] [drm] nouveau 0000:01:00.0: validate vram_list
[02:09] <lesshaste> [ 1934.458238] [drm] nouveau 0000:01:00.0: validate: -16
[02:09] <lesshaste> is this a known problem?
[02:11] <lesshaste> also seems to be this bug
[02:11] <lesshaste> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663763
[02:11] <ubottu> Debian bug 663763 in xserver-xorg-video-nouveau "xserver-xorg-video-nouveau: X server freeze" [Important,Open]
[02:13] <RAOF> lesshaste: On what chip?
[02:13] <lesshaste> 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1)
[02:14] <lesshaste> RAOF, does that answer the question?I am not sure how to find out the exact chip
[02:15] <RAOF> That's enough, yeah.  The other way would be “dmesg | grep nouveau | grep Detected”
[02:15] <RAOF> So, when you asked in #nouveau mumpf suggested that might be fixed by a new libdrm.
[02:16] <lesshaste> RAOF, well yes but one in the future
[02:16] <lesshaste> it's a pretty fatal bug
[02:16] <lesshaste> and 11.10 doesn't have the latest kernel/X
[02:16] <lesshaste> so I was hoping there might be interim fixes
[02:19] <RAOF> You can try a newer kernel, but that doesn't look particularly promising.
[02:19] <lesshaste> RAOF, ok thanks.. so just a newer kernel, not a new X ?
[02:19] <RAOF> (You can try, for example, the 3.3.1 kernel here http://kernel.ubuntu.com/~kernel-ppa/mainline/ )
[02:19] <lesshaste> I am not sure where all the parts of nouveau live
[02:19] <RAOF> Newer X is unlikely to be interesting.
[02:19] <lesshaste> so the driver is entirely in the kernel?
[02:20] <RAOF> Much of it is.
[02:20] <lesshaste> ok
[02:20] <lesshaste> I vaguely remember this debate :)
[02:20] <RAOF> 3D lives in mesa, which would be another candidate for update.
[02:20] <lesshaste> oh well it's definitely  a 3d problem
[02:20] <lesshaste> it all works fine in 2d
[02:21] <scientes> epiphany flickers for me
[02:21] <scientes> im using nvidia
[02:21] <RAOF> lesshaste: But a lockup is always a kernel bug :)
[02:21] <scientes> RAOF, :P
[02:22] <scientes> also, xorg-edgers
[02:24] <RAOF> scientes: You're using the binary nvidia driver, and edgers?
[02:24] <scientes> no i am not
[02:24] <scientes> im using stock precise all over
[02:25] <scientes> and epiphany is flickering with h264 video
[02:25] <scientes> i was just participating in the conf on mainline kernel
[02:26] <bryceh> RAOF, you in?
[02:27] <scientes> bryceh, he is
[02:27] <RAOF> Indeed.
[02:28] <bryceh> RAOF, been poking at those memory corruption bugs this afternoon, think I got a feel for what's going on
[02:28] <bryceh> RAOF, https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.tag=precise&field.tags_combinator=ALL
[02:28] <bryceh> that should get the main ones
[02:28] <bryceh> now, the bugs all have different back traces and seem to occur under a random variety of situations
[02:28] <bryceh> however they have a few things in common
[02:29] <bryceh> a ton are going through __libc_message
[02:29] <bryceh> so, like it could be they're trying to print out an error message, or generate a stacktrace in Xorg.0.log, or even just print out the usual input device spew
[02:30] <bryceh> they hit malloc_printerr(), then __libc_message, and poomph
[02:31] <bryceh> so this is characteristic of Ye Olde buffer overflow or other out-of-place memory write
[02:31] <bryceh> and I'm betting ALL of these bugs are going to be traceable to the same flaw
[02:31] <RAOF> https://launchpadlibrarian.net/93074590/Stacktrace.txt looks like the initial error is in malloc, and the reason why it's going through __libc_message is that libc is abort()ing.  That would be entirely consistent with memory corruption due to out-of-place writes.
[02:32] <bryceh> afaict this is not afflicting upstream, so that would suggest it's either the fault of frankenserver, or one of our patches added in precise
[02:32] <bryceh> (or maybe somehting underneath X, but slangasek didn't think that was likely)
[02:33] <bryceh> it is *possible* we could narrow things down by finding the earliest one of these reports
[02:33] <bryceh> if we were able to reliably reproduce it, then we could try iterating through the patches or some such
[02:34] <bryceh> however while some people are able to get it reliably, there aren't steps identified to reliably reproduce it independently
[02:34] <Sarvatt> it's going to be the first frankenserver that did it so not much narrowing down, guaranteed :(
[02:34] <RAOF> Other option is in my barrier patch (again!)
[02:34] <bryceh> Sarvatt, yeah I'm afraid of that too.  Offhand I think I recall seeing these reports right after we put it in
[02:35] <bryceh> anyway, I'm EOD so wanted to hand that off to you.  also hoping maybe you're more clever than me and can figure it out from here
[02:36] <bryceh> now, one bit of good news, it seems that while we have a lot of reports, a large chunk of these occur on shutdown only, so won't be noticeable once we shut off apport
[02:37] <bryceh> but enough are occurring otherwise, that I think this might be our #1 bug in X for the release
[02:38] <bryceh> I'm wondering if it might be something as simple as a some struct or memory chunk that changed size between 1.11 and 1.12, but some code is using the wrong size when writing it or freeing it
[02:40] <bryceh> RAOF, one thing you might try is running valgrind with and without your patch, to see if anything turns up in just a static analysis?
[02:41] <Sarvatt> from what i saw from every bug i've filed its mostly, sigsegv in X for the actual bug, signal handler called, trying to print a backtrace for that crash, some input closedown "stuff" is going on past that and trying to write to the log at the same time, memory corruption bug duped to doko's even if its unrelated because its looking at the __libc_message abort higher up
[02:42] <Sarvatt> aka 100_rethrow_signals.patch causing it most likely
[02:43] <bryceh> yes, some portion of the bugs are double crashes.  Crash, then in the segfault handler it's crashing again when trying to print the crash out
[02:44] <bryceh> and yes the signal throw in that patch might be partly to blame; it's always been a bit of a  klunker
[02:44] <RAOF> bryceh: Yeah.
[02:45] <bryceh> or I should say, we've had to debug it a few times in the past...  we might want to consider disabling that patch for the release, just to mitigate any chance of it contributing to the problem
[02:45] <bryceh> that'd mean we'd need to have people gather crash dumps manually, but that's nothing new
[02:51] <lesshaste> RAOF, sorry.. back
[02:51] <lesshaste> RAOF, it isn't a lock up exactly.. I mean you can ssh in
[02:51] <lesshaste> RAOF, and the mouse pointer moves :)
[02:56] <RAOF> lesshaste: Eh, so it's a GPU lockup then.  Still, try a newer kernel.
[02:56] <lesshaste> RAOF, k
[02:56] <RAOF> You could also try a Precise livecd; there's a newer mesa on it, but I don't think there's been much work on 3d for the nv4x family.
[02:57] <lesshaste> RAOF, ok thanks. I still don't understand if mesa can cause a gpu lockup
[02:57] <RAOF> It can, by submitting an invalid command stream.
[02:58] <RAOF> The kernel would ideally disallow that, but there's all sorts of fun ways to kill the GPU.
[02:58] <lesshaste> ah ok
[02:58] <lesshaste> thanks
[04:47] <tjaalton> meh, desktop hung during the night, ssh works
[04:52]  * RAOF suddenly remembers he has a bunch of *tests* that can easily be run under valgrind.
[06:11] <tjaalton> hmm, turns out that turning the kvm box on really helps in getting to the session.. :P
[07:23] <RAOF> Heh.
[07:24] <RAOF> Bah.  That valgrind session has not been very helpful.
[07:24] <RAOF> Although at least I know that the barrier event overflow code works.
[08:17] <tjaalton> hmm, should some part of the system save the brightness setting or not?
[08:17] <mlankhorst> already happens afaict, at least on kde
[08:17] <tjaalton> oh
[08:18] <tjaalton> gnome-settings-daemon then :)
[08:23] <seb128> tjaalton, known feature request, no need to file it
[08:24] <tjaalton> seb128: ok, it was filed already so I moved it there..
[08:24] <seb128> tjaalton, well you can guess that such requests got filed several times ;-)
[08:24] <seb128> like that's one of those coming back regularly
[08:28] <tjaalton> seb128: ok found the master bug
[08:28] <seb128> tjaalton, I'm not sure what was the current trend upstream, I think some of the upstream people think it shouldn't be an user thing
[08:28] <seb128> but rather a system one
[08:29] <tjaalton> yeah, we probably needs systemd for that ;)
[08:29] <tjaalton> -s
[08:30]  * seb128 slaps tjaalton
[08:30] <seb128> tjaalton, you also need systemd to make you coffee right? ;-)
[08:30] <tjaalton> seb128: good thing I don't drink that stuff :)
[09:43] <tjaalton> ah, downgrading freetype to the oneiric version fixed monospace font size issues..
[09:53] <tjaalton> seb128: ooh, your commit fixed that too :) bug 966654 should be duped to the one you just fixed
[09:53] <ubottu> Launchpad bug 966654 in freetype (Ubuntu) "Monospace fonts have too much space between glyphs" [Undecided,New] https://launchpad.net/bugs/966654
[09:53] <seb128> tjaalton, oh, feel free to close it then ;-)
[09:54] <tjaalton> seb128: sure thing, upgrading now and comparing the terminal size to the one with 2.4.4
[09:54] <tjaalton> i mailed ubuntu-desktop@ early in the cycle about the regression, but didn't look deeper into what caused the bump in the font size
[09:57] <seb128> tjaalton, upstream reply seems the old style is wrong
[09:58] <seb128> tjaalton, upstream just replied to my email
[09:58] <seb128> "For years, FreeType had this metrics
[09:58] <seb128> bug, and unfortunately the users got used to the appearance of far too
[09:58] <seb128> widely spaced lines.  What FreeType now returns is what the font
[09:58] <seb128> designer has had in mind while designing the font, and what can be
[09:58] <seb128> found in the font."
[09:59] <tjaalton> meh
[10:01] <seb128> tjaalton, well I've no strong opinion on rendering but I want _ to display in gtk when underline markup is set ;-)
[10:02] <tjaalton> seb128: yeah, my vote is to keep it this way for lts and fight the issues with upstream for q->?
[10:03] <seb128> tjaalton, that's sort of what my upload and email to upstream just set up for ;-)
[10:03] <seb128> i.e revert to avoid regression and let them time to deal with it
[10:03] <tjaalton> yup
[10:04] <tjaalton> and confirmed that I get the same font as on 11.10, whee
[10:24] <tjaalton> yup, total horizontal size of the terminals 344 -> 416 characters :):)
[10:24] <tjaalton> of course now i've used this for months, takes some time to get used to the old again
[11:38] <RAOF> bryceh: I've got a valgrind log of one of those X crashes in abort().  From which I can determine three things: (1) the Intel driver *still* does a huge bunch of stuff valgrind considers suspicious on initialisation, (2) in this case the crash is triggered by the [mi] EQ overflow message being written, and (3) there seems to be some valgrind-suspicious ioctls in synaptics initialisation, but I didn't have debugging symbols for that.
[11:50] <RAOF> Given that trigger, and that X under valgrind is hella slow, I should be able to trigger it again with more debugging symbols.  Tomorrow, though ☺.
=== yofel_ is now known as yofel
[15:03] <mornau> ricotz, Sarvatt: could one of you help me with this one by chance? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/972024
[15:03] <ubottu> Launchpad bug 972024 in xserver-xorg-video-ati (Ubuntu) "RADEONDRIGetVersion failed because of version mismatch (1.17.0 -> 2.10.0)" [Undecided,New]
[15:12] <Sarvatt> mornau: I just looked into it and apparently ati just needs a rebuild, but the machine i do my uploads from got hosed from the grub update and i'm fixing that so it'll be about an hour until i can upload it
[15:13] <Sarvatt> ati built against libdrm 2.4.32 when it requires 2.4.33 for KMS support
[15:15] <tjaalton> that's an edgers bug?
=== lool- is now known as lool
[15:15] <Sarvatt> so it silently dropped kms support when it built - checking for LIBDRM_RADEON... no
[15:19] <Sarvatt> tjaalton: yeah edgers bug and argh this iso needs to download faster so i can fix it :)
[15:23] <Sarvatt> stupid macs using rEFIt that can't boot a liveusb unless they are created a certain way. you have to make the vfat file system on the usb stick directly, it wont boot off a partition
[15:35] <ricotz> Sarvatt, hmm, which grub update caused this trouble?
[15:35] <Sarvatt> 20ubuntu1
[15:35] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/972250
[15:35] <ubottu> Launchpad bug 972250 in grub2 (Ubuntu) "regression from 4k_sectors.patch: "non-sector-aligned data is found in the core file"" [Critical,In progress]
[15:36] <ricotz> ah, just wanted to ask if this is gpt related
[15:37] <Sarvatt> yup it was, silly me left the laptop unplugged last night and got stuck with the screwed up grub install that was full of errors after the upgrade :)
[15:38] <ricotz> that is bad indeed :\
[15:48] <ricotz> mornau, the fix is on its way
[15:50] <mornau> thanks guys, you're great
[15:54] <mornau> btw. should i have added some tag to the bug report to ensure you get notified? (It's a pity that common tags aren't documented on launchpad)
[15:57] <ricotz> mornau, i think you could use something like "[xorg-edgers ppa] ..." as bug title
[15:58] <mornau> alright, i'll try to think of it next time if it turns out it's likely PPA related.
[16:01] <ricotz> mornau, you probably want to use a newer kernel too to get the kernel-space drm-updates while using edgers
[16:02] <mornau> I remember there's a PPA for newer kernel builds but i tend to forget its name, and have trouble finding it on a search engine then.
[16:03] <ricotz> the edgers ppa contains a rebuild of the precise kernel
[16:03] <ricotz> currently 3.2.0-20.32 (and 3.2.0-21.34 building)
[16:04] <mornau> "apt-cache search linux-image" doesn't seem to list it on this oneiric amd64 system
[16:06] <ricotz> https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/2321458/+listing-archive-extra
[16:09] <mornau> okay, this is not yet built for amd64
[16:10] <mornau> hmm actually it is, sorry
[16:59] <mornau> the availability of this updated kernel image might also be a good hint to add to the edgers page on launchpad
[17:10] <bryceh> RAOF, ah interesting findings. If you happen to still be around and can post one of the valgrind logs somewhere, I wouldn't mind perusing it a bit myself.
[17:14] <Sarvatt> RAOF: building libdrm with valgrind installed should fix most of that
[18:45] <mornau> so just to report back: linux-image-3.2.0-20.32-generic with libdrm-radeon1 2.4.33+git20120403.43704256-0ubuntu0ricotz~oneiric fixes radeon X output via DRM/DRI.
[18:48] <mornau> this kernel image looks a little buggy (gives me trouble with apparmor -> libvirtd keeps respawning, and dhcp fails somehow (haven't looked closer into it, yet)) but i guess that's why a newer image is just building now.
[19:39] <Sarvatt> phew, good thing cairo 1.12 didn't get shoved in at the last second https://lists.debian.org/debian-x/2012/04/msg00076.html
[19:40] <Sarvatt> exa's all kinds of busted with it
[19:54] <bryceh> heh
=== ajmitch_ is now known as ajmitch
[23:14] <RAOF> bryceh: http://paste2.org/p/1965772 is the valgrind log.
[23:14] <RAOF> Sarvatt: Oooh, if I build libdrm with valgrind installed it fixes a bunch of those ioctl warnings?  How?
[23:15] <RAOF> Also, could we build-depend on valgrind for libdrm ☺
[23:18] <bryceh> RAOF, thanks
[23:26] <RAOF> This *is* easy to trigger; firing up a unity session under valgrind and thrashing around on the touchpad will overflow the EQ and trigger.  I'll rebuild libdrm to clear *that* noise out and go again.
[23:26] <Sarvatt> RAOF: http://cgit.freedesktop.org/mesa/drm/log/?qt=grep&q=valgrind
[23:27] <RAOF> Yeah, found it by updating my libdrm git and grepping.
[23:56] <bryceh> RAOF, you might also try comparing a valgrind run with patch 100 commented out
[23:58] <RAOF> I'll give that a whirl.  I *think* what will happen is that it'll die in exactly the same place; the rethrow-signals codepath is only being hit once ErrorF has thrown a SIGSEGV anyway.