[00:36] <mdeslaur> fyi: http://blino.org/blog/mandriva/poulsbo-xserver1.7.html
[02:26] <ripps> why does it take forever for the gtk file dialog to do anything when I select a folder with a lot of images. It freezes for like a full minute before it allows me to bush a button.
[02:28] <RAOF> The simple, facetious answer would be “because GTK is doing something slow”.
[02:28] <RAOF> ripps: However, we can do better than that.  Let's narrow it down: what X driver?
[02:28] <ripps> RAOF: r300 ati KMS
[02:30] <RAOF> Good, so we're in the “should have decent acceleration” zone.
[02:31] <RAOF> It also suggests that maybe it's not an X problem, but let's see if we can pinpoint it.
[02:33] <RAOF> Is there any obvious system load when that's happening?  Disc access?
[02:33] <RAOF> Is GTK trying to do something stupid, like create thumbnails for everything?
[02:33] <ripps> It is an external ntfs harddrive, so I suppose that might have something to do with it, but this problem seems to come a go. Just a few weeks ago, it was loading at a decent pace, but the last couple days, it's been taking almost a full minute. The only program that seems to be having load is the program that called the dialog (in this case, usually google-chrome)
[02:34] <ripps> It spikes pretty high too, I've caught chrome at about 86% during one of these loads
[02:35] <RAOF> If you copy that directory to a more native filesystem, does it load quickly?
[02:36] <ripps> RAOF: I don't have enough space on a native filesystem right now (hence the reason I use a external harddrive) I could do some cleaning and see if I can.
[02:36] <RAOF> Keep that up your sleeve; it might be useful.
[02:37] <RAOF> So, does this happen all the time?  If you now try to open the same directory again, is it as slow again?
[02:37] <ripps> I don't want to convert the harddrive to a linux native filesystem because I tend to transfer files between it and a windows pc usually.
[02:38] <ripps> RAOF: loading the directory in Nautilus doesn't have this kind of slowdown, only with gtk file dialogs
[02:39] <ripps> I have a lot of images and cbz comic archives mixed together in the folder
[02:43] <ripps> Hmmm... at-spi-registry jumped up to 15-19% while it was loading the directory... think that might have something to do with it? 
[02:43] <ripps> RAOF: ^
[02:43] <RAOF> That seems odd.
[02:44] <RAOF> That's the accessability framework…
[02:46] <ripps> Hmm.. now that I think about it. I started playing around with secondary dwell clicks a few weeks ago. I turned it off because it wasn't working very well, but I might have never turned accessibility service off. 
[02:46] <RAOF> Give that a whirl, perhaps?
[02:49] <ripps> well, I killed at-spi-registryd, but I still see slow dialog, this time Xorg was the one jumping up to 15-18% instead of at-spi
[02:50] <ilmari> anything revealing in xrestop?
[02:51] <RAOF> oprofile might be a winner; it would be interesting to see what's actually taking time.
[02:52] <RAOF> Also, to eliminate the driver it might be nice to try again with the vesa driver.  If that showed the same behaviour it would strongly suggest a bug somewhere higher in the stack.
[02:52] <ripps> How do I force X to load vesa?
[02:54] <RAOF> Add an xorg.conf with Driver "vesa" in there.  https://wiki.ubuntu.com/X/KernelModeSetting has an example.
[03:00] <ripps> How do I use oprofile?
[03:03] <RAOF> http://oprofile.sourceforge.net/docs/ has a cheat-sheet
[03:04] <RAOF> I haven't used oprofile myself, though, so I'm not sure how easy that is in practice.
[03:04] <RAOF> opreport --demangle=smart --symbols `which lyx` from the examples page is probably the output we're looking for.
[03:37] <bjsnider> RAOF, what hardware does the netbook you're testing have?
[03:38] <RAOF> bjsnider: An intel something-or-other and a GeForce 9300M
[03:38] <bjsnider> cool, so it's dual gpus?
[03:43] <RAOF> Yes, but hidden behind a crazy bios switch.
[03:43] <RAOF> One of them is always hidden.
[03:44] <bjsnider> well, i set up a ppa with vaapi with mplayer and vlc. depending on which intel generation, hardware accel for hd video may work for both gpus
[03:44] <bjsnider> https://launchpad.net/~nvidia-vdpau/+archive/cutting-edge-multimedia
[03:44] <bjsnider> i'd say for it to work well the intel gpu has to be at least a gma 4500
[03:52] <Sarvatt> it needs seperate libva kernel and libdrm updates as well to even be worth bothering with on intel
[03:53] <Sarvatt> none of its upstream yet last i checked a few days ago
[03:54] <RAOF> Yeah; those patches exposing the fancy h264 hardware decode ringbuffer to libdrm don't seem to have landed yet.
[03:55] <bjsnider> strange that the intel libva driver builds. i'd have thought there'd be undefined symbol errors and so forth
[04:05] <RAOF> Ok.  Time for some lunch.
[09:04] <Ng> bryceh: aha, I'll try that tonight, thanks :)
[12:37] <mvo> hi, what is the best way to debug something like bug #570634
[12:37] <ubottu> Launchpad bug 570634 in xorg-server "immediate logout of the gnome session after hardy -> lucid upgrade (inside kvm)" [Undecided,New] https://launchpad.net/bugs/570634
[12:37] <mvo> apport seems to not pick it up, should it?
[12:43] <jcristau> you say "nothing unusual in the X log" and then attach an X log which shows a segv :)
[12:44] <mvo> jcristau: that was a bit of a mistake …
[12:44] <jcristau> compiz with cirrus, though?
[12:44] <mvo> yes
[12:44] <mvo> well, kvm
[12:44] <jcristau> that's asking for trouble :)
[12:45] <mvo> heh :)
[12:45] <mvo> I noticed!
[12:45] <jcristau> then again, (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
[12:45] <jcristau> means compiz can't work
[12:45] <mvo> yeah, it should detect it and fallback, and sometimes it does
[12:46] <mvo> but not always it seems
[12:46] <jcristau> maybe it tries, but X crashes first :)
[12:46] <mvo> yeah
[12:47] <mvo> is there a way to retrace the crash? will it pick up debug symbols automatically?
[12:50] <jcristau> starting X with -core should get a core dump in /etc/X11
[12:51] <jcristau> seems like X crashes on the first composite call, before compiz gets a chance to check glx stuff
[12:53] <mvo> thanks, I try that (I just need to figure out where gdm calls X and how to add args)
[13:39] <tseliot> mvo: maybe try gdm_server_start_on_active_vt (added by patch 28) or gdm_server_start ?
[13:40] <seb128> mvo, start without compiz and see if running glxinfo crashes it too
[13:41] <jcristau> seb128: it's not crashing in GL stuff
[13:41] <jcristau> it's crashing in composite
[13:41] <seb128> oh ok
[13:42] <tseliot> mvo: you can add arguments as shown in that patch: server->priv->command = g_strdup (X_SERVER " -nr -verbose")
[13:42] <jcristau> tseliot: should be possible to do that from the gdm config, though, hopefully
[13:42] <jcristau> it is with gdm 2.20 anyway..
[13:42] <seb128> I've looked a bit for this and it doesn't seem to be in the config with the new gdm no
[13:43] <jcristau> sigh
[13:43] <tseliot> :-/
[13:43] <jcristau> no end of brokenness in this new gdm it seems
[13:44] <jcristau> other option would be to start X without compiz, ssh in, attach gdb, and then start compiz
[13:44] <mvo> tseliot: right, that is a bit heavy weight
[13:45]  * tseliot nods
[13:45] <mvo> glxinfo works fine
[13:45] <mvo> but I'm sure its some sort of race as I sometimes can login
[13:45] <mvo> and sometimes can't
[14:15] <Cobalt> Is there any benefit to adding the Xorg Edgers repository (for Intel chipsets) in Lucid?
[14:55] <JanC> Cobalt: do you have problems with the default drivers?
[14:56] <Cobalt> I haven't upgraded yet, I was just wondering what people's experience of it has been. Will be doing so towards release time.
[15:44] <JanC> Cobalt: I think xorg edgers might be useful on lucid for people with an intel i8xx IGP
[15:44] <JanC> but I haven't followed all the latest stuff about that
[15:51] <__mikem> Sarvatt: may I ask when I can expect xorg-edgers to be available?
=== ara_ is now known as ara
=== ara is now known as Guest4805
=== Guest4805 is now known as ara
[17:13] <Sarvatt> __mikem: available? if you mean vmware support in there I already told you that i probably wont get to it for a  month or two
[17:14] <__mikem> Sarvatt: oh okay. Sorry, I forgot that you gave me a time frame
[17:16] <Sarvatt> i told you how to do it yourself too :)
=== seb128_ is now known as seb128
[18:08] <Sarvatt> mvo: hmm so kvm's cirrus device no longer has a 1234 pci id? we have a patch default cirrus to vesa but you have an actual cirrus pci id there
[18:09] <mvo> Sarvatt: oh, that is interessting
[18:09] <Sarvatt> defaulting qemu's cirrus pci id to vesa I mean because it had problems with the cirrus driver
[18:10] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/184_virtual_devices_autodetect.patch;h=a236e2210ba8c71324f178e6e344c6954befc26e;hb=refs/heads/ubuntu-lucid
[18:13] <Sarvatt> but looking at that i dont see how it ever worked since 1234 pci id would never have been matched and it would have been defaulted to vesa anyway, need to look into that some more
[18:45] <Sarvatt> darnit, don't have any systems handy with hardware virtualization support to mess with it at the moment and it looks to be significantly different in the non KVM case, asking for a full backtrace with archive versions of xserver are still screwed up since xserver dbg and dbgsym packages are still screwed up
[18:55] <Sarvatt> apport definitely isn't working with xserver segfaults though, its not just this one machine i'm on
[19:17] <bryceh> fairly sure it's turned off by default at this point
[19:17] <bryceh> Sarvatt, or had you explicitly enabled it?
[19:18] <Sarvatt> yeah I enabled it and its not blacklisted
[19:18] <bryceh> mm, then could be a bug somewhere
[19:18] <bryceh> are other apport crash hooks working?
[19:18] <Sarvatt> it hasn't worked since the fixes to have it not crash the server in other situations here, and i haven't seen an apport xserver bug since then either
[19:19] <Sarvatt> yeah other ones are working fine
[19:20] <bryceh> hrm, sounds like a bug in the x apport script maybe then
[19:23] <Cobalt> JanC: Fair enough, I'll see what the deal is after I install.
[19:30] <bryceh> Sarvatt, sounds a lot like a bug in my commit 1643fb38 but I don't see an obvious error
[19:31] <bryceh> Sarvatt, would be interesting if commenting out lines 76-83 would make it functional again
[19:38] <Sarvatt> will do, need to switch back to a broken xserver that i can crash easily too :)
[19:44] <Sarvatt> it hasn't been working for me since january though, but its possible I'm remembering wrong or didn't dig into it any deeper in that time frame
[19:44] <bryceh> well, I know it at least worked up until the last change (mar 8th) since that change was prompted by apport reports ending up in the wrong place
[19:45] <bryceh> I admit I don't recall seeing many reports subsequent to that, but that's also about when we stopped the -intel freeze capture tool, which quelled a lot of the reports
[19:47] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/510997 -- thats the last apport bug i see reported regarding a segfault using free drivers
[19:47] <ubottu> Ubuntu bug 510997 in xorg-server "Xorg crashed with SIGSEGV in _IO_default_xsputn()" [Undecided,Confirmed]
[19:48] <Sarvatt> assert reports seem to still be working
[19:49] <Sarvatt> but there are lots of bugs with server segfaults in the logs after
[19:49] <bryceh> hrm
[19:50] <bryceh> there were several changes on jan 25th
[19:51] <bryceh> and then a bunch in feb
[19:54] <Sarvatt> that bug was filed against karmic too throwing another wrench in it, bah
[19:54] <bryceh> bug #515135 is newer - from 1-31
[19:54] <ubottu> Launchpad bug 515135 in xserver-xorg-video-intel "Xorg crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/515135
[19:55] <Sarvatt> bryceh: ok thats interesting because xserver-xorg-core 2:1.7.3.902-1ubuntu9
[19:56] <Sarvatt> xorg-server (2:1.7.3.902-1ubuntu9) lucid; urgency=low
[19:56] <Sarvatt>   * Fully disable 100_rethrow_signals.patch as it seems to still cause
[19:56] <Sarvatt>     crashes.  Goodbye apport.
[19:56] <bryceh> seems the apport hook still works for proprietary drivers though - lp #566435 from 4/18
[19:56] <ubottu> Launchpad bug 566435 in nvidia-graphics-drivers "Xorg crashed with SIGSEGV in strtol()" [Medium,New] https://launchpad.net/bugs/566435
[20:01] <bryceh> this is a sad state of affairs to be troubleshooting why we're not *more* bug reports than we already are ;-)
[20:03] <Sarvatt> well its wasting a heck of a lot of time digging through peoples logs and vague descriptions to find the info and we're losing automatic duping :) 
[20:03] <bryceh> bugs that have vbox installed seem to be getting through ok - lp #559288
[20:03] <Sarvatt> downgrading to xserver 2:1.7.6-2ubuntu5 now to play with the apport script and see if i can get it going
[20:03] <ubottu> Launchpad bug 559288 in virtualbox-ose "Xorg crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/559288
[20:05] <bryceh> mm, the vbox test bails out before the nvidia bits anyway so that doesn't tell much
[20:06] <bryceh> ooh I have an idea
[20:06] <Sarvatt> shoot me any ideas you have because i have an easily testable setup going now :)
[20:06] <bryceh> wait maybe not
[20:07] <bryceh> well there is a stanza towards the end that prompts the user before attaching their gdm files
[20:07] <bryceh> since it's an interactive bit, I thought maybe it fails when handling crashes
[20:07] <bryceh> however that wouldn't explain why it's working for proprietary drivers
[20:07] <bryceh> but might try commenting that out and see if it makes any difference
[20:09] <bryceh> the one thing I see that might be squirrelly with open vs. proprietary is the stuff for attaching /var/lib/dkms/ bits around line 92
[20:10] <bryceh> Sarvatt, do you have a /var/lib/dkms directory?  If so, that bit of code could be executing but maybe the glob is breaking
[20:11] <bryceh> kind of crazy how many X crashes are really "broken vbox" bugs
[20:11] <Sarvatt> commented all of that stuff out, lets see
[20:12] <Sarvatt> no /var/lib/dkms here
[20:13] <bryceh> lp #560633 is a recent one with no proprietary drivers or vbox
[20:13] <ubottu> Launchpad bug 560633 in xserver-xorg-input-evdev "Xorg crashed with SIGSEGV in read()" [Undecided,Confirmed] https://launchpad.net/bugs/560633
[20:16] <Sarvatt> oh bah 2:1.7.6-2ubuntu5 had the fix for clutter crashing in it, it was 2:1.7.6-2ubuntu1 i needed
[20:30] <Sarvatt> nothing in /var/crash/, apport is running and i even tried using the karmic source_xorg.py
[20:35]  * Sarvatt just goes the easy route and puts a patched gdm to launch x with -core in a PPA for now
[20:38] <Sarvatt> my crashes all end at 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e937b] but the ones that are working go farther past that? #2  0x00007f6ec8cf934e in backtrace () from /lib/libc.so.6 #1  0x00007f6ec7f3966e in _Unwind_Backtrace () from /lib/libgcc_s.so.1
[20:52] <Sarvatt> it sure would be nice if mesa could remove ~/.drirc on upgrade or downgrade
[20:53] <Sarvatt> i always forget to reset all of the settings when i change mesa versions, right now it leaves texture tiling enabled on intel when i downgrade back to the lucid version where its horribly buggy
[20:54] <Sarvatt> think i'll put a note about that on xorg-edgers, only a problem if someone installed driconf anyway
[20:59] <Sarvatt> bryceh: noticed something odd in the bug you linked there - http://launchpadlibrarian.net/43774793/GdmLog2.txt
[21:00] <Sarvatt> it didn't print the backtrace info in the log and it successfully dumped a core
[21:05] <bryceh> do you think people commonly use driconf?  If so we could add it to the apport hook :-)
=== BUGabundo is now known as BUGabundo_dinner
[21:07] <bryceh> yeah I haven't looked at enough of the new gdm logs to know if that's normal or not
[21:08] <Sarvatt> nah i'm sure it's by far the minority but if you've ever installed it and changed the settings all of the settings stick around permenantly until you remove ~/.drirc
[21:11] <Sarvatt> if i install mesa 7.9 and then driconf and change a setting, it'll store all of the settings from 7.9 and those will get loaded for everything mesa in all other versions even if the default values are different
[21:12] <Sarvatt> going from 7.9 to 7.7 is bad that way because intel will use texture tiling that's really screwed up in 7.7 and disabled by default there
[21:16] <Sarvatt> bryceh: all of the reports where apport is working and catching segfaults are the same - http://launchpadlibrarian.net/43553278/GdmLog2.txt
[21:16] <Sarvatt> and here's what it looks like not working http://pastebin.com/DJtj6nhL
[21:17] <Sarvatt> (that's /var/log/gdm/:0.log.1 after a crash)
[21:18] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/168_glibc_trace_to_stderr.patch;h=ed218bb3673836c143afac8c8842255b818bd90c;hb=refs/heads/ubuntu insufficient for all cases?
[21:19] <bryceh> well, the presence of a .driconf could be a clue on bugs; I'll put on my todo list to add it to apport later on
[21:21] <bryceh> could be
[21:21] <bryceh> Sarvatt, there has always been some cases where xserver crashes don't get caught by apport, and we never did figure out why
[21:22] <bryceh> however it seems like we're getting far fewer than usual
[21:23] <bryceh> mm, we disabled 100_rethrow_signals.patch on Jan 18th
[21:24] <bryceh> so that explains why it "seemed" that crashes stopped being captured at that point
[21:24] <bryceh> it was re-enabled on Feb 3rd
[21:25] <bryceh>   * 100_rethrow_signals.patch: Fix SigAbortServer to cleanly exit(1) on a
[21:25] <bryceh>     non-signal crash, as the original upstream code does. Not exiting leads to
[21:25] <bryceh>     continuing back into the code which threw the error, which eventually
[21:25] <bryceh>     leads to writing into the already closed log file and other operations
[21:25] <bryceh>     which cause segfaults.
[21:25] <bryceh>   * Re-enable 100_rethrow_signals.patch.  Hello apport.
[21:25] <bryceh>  -- Martin Pitt <martin.pitt@ubuntu.com>  Wed, 03 Feb 2010 17:29:53 -0800
[21:25] <Sarvatt> the log stops at the backtrace on every bug i can find so far where it's working, looks like the backtrace info is supposed to go to STDERR for apport to catch it and it's being printed to the log in the cases where its not working
[21:27] <bryceh> weird
[21:27] <bryceh> well, I can imagine that is what is causing the problem
[21:28] <bryceh> but why would it be that this seems to be working for the proprietary drivers?
[21:31] <Sarvatt> trying to find an apport bug with a 32 bit core dump i can play with to look into it more
[21:31] <bryceh> we should bring pitti into this at some point too
=== BUGabundo_dinner is now known as BUGabundo
[21:39] <Sarvatt> seems to be one specific abort path that works and the others dont or something, the ones that are working are using proprietary drivers or having input related crashes
[21:45] <Sarvatt> darn only core dump i can find is x86_64 and i use 32 bit on everything but one machine that i dont have access to at the moment
=== BUGabundo is now known as BUGabundo_Chuck
[22:08] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/563759 -- floating point exception getting reported as a SIGSEGV?
[22:08] <ubottu> Error: Could not parse data returned by Ubuntu: list index out of range (https://launchpad.net/bugs/563759)
[22:22] <Sarvatt> yeah looking through the bugs it really was limited to proprietary drivers/input crashes even in karmic :(
[22:22] <jcristau> obviously that's because the free video drivers aren't buggy
=== BUGabundo_Chuck is now known as BUGabundo_DrHous
[22:59] <Sarvatt> seems like it would be cleaner and work in more situations if apport just parsed the reason it died whenever it dies with a SIGABRT, but i have no idea how you'd get a core dump that way without starting with -core
[23:04] <lapion> has anyone with that uses i915 kms with an i855 or older chipset tried the new 2.6.33.3 drm drivers?
[23:05] <lapion> what was the ppa for experimental 2.6 drm kernels again ?
[23:07] <Sarvatt> lapion: just curious, have you ever tried using KMS and forcing the X driver to fbdev to see if it had problems?
[23:08] <lapion> You mean like booting with the regular kernel into single user mode and then staring up failsafex ?
[23:09] <lapion> I mean booting to single usermode with kms, and then starting kms ? I get a black screen..
[23:09] <lapion> 2nd kms=failsafemode
[23:11] <lapion> failsafe mode/non kms mode gives me no dual screen..
[23:11] <lapion> that is failsafe mode without kms
[23:12] <lapion> Sarvatt, booting with kms and fbdev gives me black screen
[23:12] <Sarvatt> ah yeah fbdev wouldn't give you dual screen anyway
[23:13] <Sarvatt> lapion: how about intel 2.8.0? have you tried that out?
[23:13] <Sarvatt> i backported all of the stuff to make it work with xserver 1.7 in the x-retro PPA
[23:14] <Sarvatt> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-retro
[23:16] <bryceh> ah thanks for fixing that up Sarvatt
[23:17] <lapion> I just read someting in the http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33.3
[23:17] <Sarvatt> needed 8 or 9 commits backported, EXA was dropped before 2.8.0 though so I dropped that part of the changelog that you put in
[23:18] <lapion> You see I was getting hangcheck errors without the zserver freezing..
[23:19] <Sarvatt> what did you read interesting there?
=== BUGabundo_DrHous is now known as BUGabundo_Naruto
[23:26] <lapion>     Commit:     bc9025bdc4e2b591734cca17697093845007b63d
[23:27] <lapion> hmm I think I misinterpreted this one.. they are talking about locks not deadlocks
[23:28] <lapion> hmm as of latest update my pentium 4 clock cannot be set anymore
[23:29] <ilmari> speaking of locks/deadlocks... sysrq-d (show all locks that are held) isn't doing anything (just outputs the sysrq help message), even though CONFIG_LOCKDEP_SUPPORT=y
[23:29]  * ilmari would like to be able to investigate https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138 further the next time it happens
[23:29] <ubottu> Ubuntu bug 568138 in xserver-xorg-video-intel "[arrandale] deadlock in i915_gem_madvise_ioctl" [Undecided,Confirmed]
[23:29] <lapion> btw when selecting resume in the Recovery Menu, doesn't start the Xserver under lucid
[23:31] <ilmari> the gdm upstart job it's still checking /proc/cmdline and refusing to start if the machine was initally booted in single user mode
[23:31] <ilmari> s/it's/is/
[23:32] <lapion> well yeah sudo start gdm resolved in pretty quickly
[23:35] <lapion> btw btw ilmari alt-ssyrq-d does that freeze up the system ?
[23:36] <ilmari> lapion: I haven't tried actually hitting the keys, but echo d > /proc/sysrq-trigger just gives the help message
[23:37] <lapion> about the freezes, if the xserver freezes once, the xserver freezes up faster in successive reboots
[23:37] <ilmari> both the i915 kernel thread and X are stuck in __mutex_lock_slowpath+0xe7/0x170 
[23:41] <lapion> are you talking about show blockes tasks (W) ?
[23:41] <lapion> I believe it's activated with W
[23:41] <ilmari> no, that works
[23:41] <lapion> ilmari, 
[23:41] <ilmari> which is just what the softlockup watchdog already has showed
[23:41] <ilmari> 'd'     - Shows all locks that are held.
[23:41] <ilmari> (from /usr/share/doc/linux-doc/sysrq.txt.gz)
[23:43] <lapion> outdated info
[23:47] <Sarvatt> ilmari: pretty sure its because CONFIG_LOCK_STAT isn't set
[23:49] <ilmari> ah