[00:10] <LLStarks> if i'm having vsync issues, do i file against ddx?
[00:11] <RAOF> Filing against the DDX isn't a terrible idea, but more information might help.
[00:11] <LLStarks> i've been having x session-wide tearing for about a week
[00:12] <LLStarks> rather, almost a week
[00:12] <LLStarks> no edgers drivers or anything
[00:13] <RAOF> And you're running... nouveau?
[00:13] <LLStarks> 915
[00:14] <RAOF> Odd.  The DDX will do; they all collect roughly the same logs, anyway.
[00:14] <LLStarks> there was a recent vblank patch, wasn't there?
[00:15] <LLStarks> that was i830...
[00:15] <RAOF> Heh.
[00:15] <RAOF> I don't recall a recent vblank patch that we've picked up.  Possibly in the kernel, though.
[00:17] <LLStarks> 115_quell_vblank_counter_failed.patch
[00:17] <LLStarks> probably doesn't apply here
[00:18] <RAOF> Yeah.  That's just not printing out error messages.
[00:18] <RAOF> Or, rather, printing only the first 5 and discarding the rest.
[00:19] <LLStarks> ugh. time to bisect.
[00:20] <RAOF> Want to throw up an Xorg.0.log just to check?
[00:20] <LLStarks> i didn't see anything suspicious
[00:21] <LLStarks> http://pastebin.com/XB1tLDfG
[00:23] <RAOF> Is it only with the spanned monitors?
[00:50] <LLStarks> raof, eh? single lvds.
[00:50] <RAOF> LLStarks: That xorg log shows i915 allocating a 2880x900 framebuffer at one point.
[00:51] <LLStarks> i had my laptop vga'd to my tv
[00:51] <LLStarks> but that was yesterday.
[00:51] <LLStarks> did i not power cycle <__<
[00:52] <RAOF> And vsync woes aren't only when that's happening, I take it :)
[00:52] <LLStarks> lemme double check
[00:52] <LLStarks> yeah, spanned too.
[00:53] <LLStarks> and using tv as single-monitor
[00:56] <LLStarks> the tearing is quite visible on screenshots.
[00:57] <RAOF> Visible on *screenshots*?  That's odd.
[01:00] <LLStarks> yeah
[01:00] <LLStarks> flash, xv, gl, it doesn't matter
[01:01] <LLStarks> http://i.imgur.com/J2YWn.jpg
[01:03] <LLStarks> i'll file a bug
[01:09] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/726902
[01:09] <ubot4> Launchpad bug 726902 in xserver-xorg-video-intel (Ubuntu) "Tearing on i945. Loss of vsync? (affects: 1) (heat: 6)" [Undecided,New]
[01:09] <LLStarks> raof, can i force vsync on intel?
[01:10] <LLStarks> let's see if that compiz trick still works
[01:12] <RAOF> vsync is already enabled by default.  Try glxgears for example; it should be limited to (almost) exactly 60FPS
[01:13] <LLStarks> yeah, compiz fixes it.
[01:13] <LLStarks> can't use metacity anymore i guess
[01:18] <LLStarks> and i'm on classic
[01:20] <LLStarks> hmmm. i see now.
[01:21] <LLStarks> whenever metacity/compiz crashes when hooking vga or just in general, i usually reactivate metacity with just plain "metacity"
[01:21] <LLStarks> instead of --replace
[01:22] <LLStarks> ugh, maybe idon't get it
[02:07] <bryce_> cnd, heya sorry the dmb didn't give you more concrete advice, although I do remember when I mentored kirkland it was exactly the same sort of situation; he wanted to know more specifics and just got told "it's obvious when it's obvious" or similar
[02:12] <bryce_> cnd, and yeah stgraber's advice regarding doing merges is good; when I went for MOTU I devoted half a day a week to doing merges via MOM, until I felt ready (I wanted to make sure I had touched each of the different patching systems, and had done a variety of different types of packaging work)
[02:16] <RAOF> LLStarks: Oh!  You're using Metacity?  With compositing?  Don't do that :)
[02:16] <LLStarks> not with compositing
[02:16] <LLStarks> you can't turn that on unless you explicitly set gconf, right?
[02:17] <RAOF> LLStarks: Yeah, pretty much.
[02:18] <RAOF> gconftool-2 --get /apps/metacity/general/compositing_manager will tell you.
[02:18] <LLStarks> it was only relevant for like a month after beryl fell apart
[02:18] <RAOF> No, it's still useful; I use it :)
[02:18] <RAOF> When I'm not using a GL compositor.
[05:43] <LLStarks> raof, is vga_switcheroo needed at a kernel level?
[05:43] <RAOF> LLStarks: What do you mean?  It's implemented at the kernel level.
[05:43] <LLStarks> as of which kernel?
[05:44] <RAOF> .35?  From memory?
[05:44] <LLStarks> i'm thinking of grabbing a few optimus notebooks lying around and bruteforcing them acpi calls
[05:45] <RAOF> From my understanding of optimus, that's not going to be terribly useful, except to possibly turn off the nvidia card.
[05:46] <LLStarks> dell vostros with optimus don't have a physical connection and bruteforcing worked.
[05:46] <RAOF> Because, IIUC, optimus is basically the nvidia card rendering to specific piece of vram, and then copying that vram somewhere special, and then having that scanned out.
[05:47] <LLStarks> https://bbs.archlinux.org/viewtopic.php?pid=882737#p882737
[05:48] <LLStarks> assuming that acpi_call generates calls that "work", i see little reason why it wouldn't be sufficient.
[05:50] <LLStarks> yet devs are convinced that acpi is not the solution
[05:51] <LLStarks> they're looking elsewhere now
[05:51] <RAOF> It looks like that dell has an ACPI mux, which suggests that the nvidia card *is* connected to the outputs, so it's not quite optimus.
[05:52] <RAOF> Feel free to try; it's not like we've got specs saying it's impossible :)
[05:53] <LLStarks> well, the whole point of acpi_call is discover acpi mux methods. most optimus notebooks that i've examined have at least one working method.
[05:54] <LLStarks> some don't
[05:54] <LLStarks> most do
[05:54] <RAOF> My understanding of Optimus is that it didn't use ACPI muxs.  It's entirely possibly my understanding is wrong :)
[05:55] <RAOF> Although you won't be able to do shared rendering stuff with an acpi mux; you'll have to either use the nvidia card for everything or the intel gpu for everything, which isn't optimal.
[05:59] <LLStarks> i'd rather lose shared rendering if a simple SB.PCI0.PEG1.GFX0._OFF call can enable the discrete gpu
[06:00] <RAOF> Well, I meant that systems which use a mux instead of a more funky approach *can't* support shared rendering.
[06:01] <RAOF> Or, at least, if you've got shared rendering support then there's no reason for you to include a mux as well.
[06:01] <RAOF> So they're less likely to actually have one :)
[06:01] <LLStarks> well, a couple of asus notebooks can do cuda and intel simultaneously
[06:02] <LLStarks> which is confusing to say the least
[06:02] <LLStarks> *simultaneously on linux
[06:02] <RAOF> Not tremendously confusing.  The nvidia card doesn't have to be hooked up to any outputs to make that work :)
[06:03] <LLStarks> howso?
[06:06] <LLStarks> btw, if not acpi, what approaches are left? nvidia coding an intel driver?
[08:42] <RAOF> LLStarks: The intel and nvidia drivers cooperating, yes.
[08:42] <RAOF> LLStarks: That's how it'll (eventually!) work in Linux-land :)
[09:22] <tjaalton> sigh, this nvidia blob is slow
[09:24] <RAOF> At 2D?
[09:24] <tjaalton> yes
[09:24] <RAOF> Silly blob
[09:24] <tjaalton> like scrolling in chromium or nautilus
[09:24] <tjaalton> nouveau was really fast
[10:24] <tjaalton> huh, classic desktop opens unity now?
[10:26] <tjaalton> had to disable the compiz plugin manually
[10:38] <seb128> seems a bug, you are the second to mention it
[10:40] <tjaalton> ok, good
[10:41] <seb128> tjaalton, bug #726862
[10:41] <ubot4> Launchpad bug 726862 in unity (Ubuntu) (and 1 other project) "unity launchs itself on the classic desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726862
[10:41] <tjaalton> seb128: thanks
[11:12] <knittl> "Due to hardware capability constraints, disabling display"
[11:12] <knittl> oO
[11:13] <knittl> i think this is related to my "blank screen when using nvidia-current and both screens run at full resolution"
[11:14] <knittl> [ 89311.337] (WW) NVIDIA(0): Due to hardware capability constraints, disabling display
[11:14] <knittl> [ 89311.346] (WW) NVIDIA(0):     device Seiko/Epson (DFP-0) in MetaMode
[11:14] <knittl> [ 89311.346] (WW) NVIDIA(0):     "CRT-0:1920x1080@1920x1080+1920+0,DFP-0:1920x1200@1920x1200+0+0".
[11:14] <knittl> in my xorg.0.log
[11:15] <knittl> i think nvidia-current might be detecting hardware limits not correctly
[11:15] <knittl> nvidia-173 has no problems with 2 screens
[11:15] <knittl> tseliot: friendly ping :)
[11:28] <tseliot> knittl: what's up?
[11:28] <knittl> i was told to talk to you regarding jockey not recognizing the installad driver
[11:29] <tseliot> that's correct
[11:29] <knittl> and i wanted to ask if you have a clue about my issue above
[11:29] <knittl> one monitor blank when using nvidia-current and both on full resolution
[11:29] <knittl> it works with -173 though
[11:29] <knittl> so i think -current is somewhat borked in that regard
[11:30] <knittl> do you have a secret wire to nvidia? :]
[11:31] <tseliot> knittl: I do but you'll have to file a bug report about it and attach your nvidia-bug-report.log
[11:32] <knittl> bugreport on launchpad?
[11:34] <tseliot> yep
[11:34] <knittl> ok, on it
[11:34] <tseliot> also what's up with jockey?
[11:34] <knittl> nvidia bug report is generated already
[11:34] <tseliot> good
[11:34] <knittl> tseliot: i install nvidia-current, and jockey tells me 'another version of this driver is in use'
[11:34] <knittl> after reboot that is
[11:34] <tseliot> what version of ubuntu/jockey is that?
[11:34] <knittl> i'm on 32 bit
[11:34] <knittl> natty
[11:35] <knittl> but also happened in maverick
[11:35] <tseliot> what's the output of jockey-text -l ?
[11:35] <knittl> tseliot: http://www.thehappy.de/neo/jockey-nvidia-current.png
[11:35] <knittl> a screenshot, coz a picture says more than thousand words ;)
[11:36] <knittl> $ jockey-text -l
[11:36] <knittl> xorg:nvidia_current - NVIDIA accelerated graphics driver (Proprietary, Disabled, In use)
[11:37] <tseliot> I don't see how it can be disabled and in use at the same time. Did you install nvidia-current from Jockey?
[11:37] <knittl> disabled & in use … funny :D
[11:37] <knittl> tseliot: yes, i did
[11:38] <tseliot> can I see 1) your xorg.conf 2) the output of sudo update-alternatives --display gl_conf , please?
[11:39] <knittl> http://thehappy.de/~neo/xorg.conf
[11:39] <knittl> and u-a: http://paste2.org/p/1275564
[11:43] <tseliot> they look good to me. Can you file a bug report about it, please? (with "ubuntu-bug jockey-gtk")
[11:43] <knittl> yup, currently filing one on nvidia-current
[11:44] <tseliot> and include the information that you've just shown me in the bug report
[11:44] <tseliot> thanks
[11:44] <knittl> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/727112
[11:44] <ubot4> Launchpad bug 727112 in nvidia-graphics-drivers (Ubuntu) "nvdia-current does not detect hardware capabilities (affects: 1) (heat: 6)" [Undecided,New]
[11:45] <knittl> hm, there's a 'correctly' missing …
[11:46] <tseliot> if you can't add it, I will
[11:46] <knittl> no, i've added it
[11:48] <tseliot> ok
[11:53] <knittl> tseliot: https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/727117
[11:53] <ubot4> Launchpad bug 727117 in jockey (Ubuntu) "jockey-gtk shows nvidia-current as disabled although it's installed and active (affects: 1) (heat: 6)" [Undecided,New]
[11:54] <knittl> thanks in advance, i really appreciate your support
[11:54] <tseliot> knittl: does nvidia-173 still show up in Jockey? Even after an apt-get update?
[11:55] <tseliot> the log shows that it shouldn't
[11:55] <knittl> tseliot: currently i only see nvidia-current (not even nouveau)
[11:56] <tseliot> ok, that makes sense (I don't know about nouveau though)
[11:56] <knittl> before installing nvidia-current i could see all three: nvidia-173, nvidia-current and "experimental 3d support for nvidia cards"
[11:57] <knittl> that was libgl-dri-mesa-experimental or something like that
[11:57] <tseliot> yes, a few things changed in jockey and in the drivers
[11:57] <knittl> ok
[11:58] <tseliot> can you also put the output of jockey-text -l in the bug report, please?
[11:58] <knittl> oh yeah. of course
[11:58] <knittl> just a sec
[12:01] <knittl> added
[12:07] <tseliot> thanks
[12:08] <knittl> np
[14:03] <bjsnider> tseliot, to avoid the error message that happens on i386 systems when installing nvidia-current, couldn't the script test for build-arch and then only install the 32-bit vdpau links on amd64?
[14:05] <tseliot> bjsnider: I'd rather not have the same command twice (one without the 32bit stuff) in the postinst just for that warning
[14:06] <bjsnider> tseliot, that was the only error or indication of failure in the jockey log from knittl
[14:07] <bjsnider> his jockey log actually said "error", not "warning"
[14:08] <tseliot> right, I don't think that's what's causing the problem though
[14:09] <bjsnider> well, jockey installs the module, sets up the alternatives and then errors out before xorg.conf is created, right at the end
[14:09] <tseliot> it says error only because it was printed to stderr, not because it was an error
[14:10] <knittl> yeah, jockey aborts before creating xorg.conf
[14:10] <knittl> and the error message is confusing
[14:11] <tseliot> furthermore the error is printed only when installing the driver. The driver is not shown as enabled after a reboot
[14:11] <tjaalton> does jockey still create the xorg.conf even though xserver autoloads nvidia?
[14:11] <bjsnider> i guess jockey isn't logging the problem
[14:13] <tseliot> tjaalton: yep
[14:13] <tseliot> I don't think we want the Nvidia logo to show up every time, do we?
[14:13] <bjsnider> yeah, "ubuntu, by nvidia"
[14:14] <tseliot> the autoloading stuff is supposed to make things work when you install the package manually
[14:15] <bjsnider> if he tries that, everything works. there's no error
[14:15] <tjaalton> right, forgot about the logo
[14:15] <knittl> driver installs fine with apt-get
[14:16] <bjsnider> knittl, right, but if you use jockey, it errors out, says "check the jockey log" which doesn't include anything helpful
[14:17] <knittl> bjsnider: yup, exactly
[14:17] <tseliot> ah, so you got an error too
[14:18] <knittl> yeah, but bjsnider (i think) told me, it was a false positive
[14:18] <tseliot> knittl: right but was your xorg.conf written when that happened?
[14:18] <knittl> no
[14:18] <bjsnider> the jockey log contains an error that everyone on i386 gets
[14:19] <tseliot> ok
[14:19] <knittl> xorg.conf had to be generated with nvidia-xconfig (or manually)
[14:20] <bjsnider> knittl, why are you on i386?
[14:21] <knittl> i installed ubuntu back in the time when rumor had it, that not all apps would work with 64 bit OS
[14:21] <knittl> and since there is no easy way to upgrade 32->64 bit, i'm still with i368
[14:22] <tseliot> knittl: can I see the original log, please?
[14:22] <knittl> tseliot: jockey.log?
[14:22] <tseliot> yep
[14:22] <tseliot> the one with the error
[14:22] <knittl> http://thehappy.de/~neo/jockey.log
[14:23] <knittl> i cleared the file before starting jockey and copied right after the error popped up and i had closed jockey
[14:24] <bjsnider> the line 4 from the bottom doesn't contain an explanation
[14:27] <tseliot> I guess KernelModuleHandler.enabled() failed somehow
[14:28] <bjsnider> is 2.6.38-5-generic-pae the kernel in natty right now?
[14:29] <knittl> yes
[14:32] <tseliot> knittl: please attach that log to the bug report
[14:32] <knittl> hm. i thought i had
[14:32] <knittl> will do
[14:33] <bjsnider> maybe the pae kernel is somehow the problem
[14:35] <tseliot> I think I've found the problem. I need confirmation from pitti though
[14:35] <tseliot> even though I find it a bit weird
[14:36] <knittl> jockey.log attached
[14:39] <tseliot> thanks
[14:41] <bjsnider> tseliot, is this exclusively a jockey problem?
[14:42] <tseliot> I think so
[14:42] <bjsnider> in that case, his external monitor issue is exclusively an nvidia problem
[14:46] <knittl> bjsnider: yeah, monitor being blank is a driver issue
[14:46] <knittl> i guess
[14:46] <knittl> most of the time, my internal monitor is blank though ;)
[14:47] <bjsnider> actually, it could be a hardware problem, but not something we can fix anyway
[14:48] <knittl> hardware problem would not explain, why it works with nvidia-173
[14:48] <knittl> minus the comma
[14:49] <tseliot> it definitely is s different problem
[14:49] <bjsnider> in that case it's a regression in the driver
[15:17] <cnd> bryce_, is it still possible to get a fix in for evdev?
[15:18] <cnd> due to the alpha 3 release freeze
[15:35] <tseliot> cnd: maybe we should ask an archive admin? What fix are you referring to?
[15:35] <cnd> tseliot: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/725202
[15:35] <ubot4> Launchpad bug 725202 in xserver-xorg-input-evdev (Ubuntu) "X crashes on startup in evdev_drv (affects: 5) (dups: 1) (heat: 32)" [Medium,In progress]
[15:35] <cnd> some MS dongles are wreaking havoc in the kernal
[15:35] <cnd> kernel
[15:35] <cnd> and that's havoc is propagating up to evdev :)
[15:37] <tseliot> nasty bug, I think we should include it
[15:37] <tseliot> tjaalton: ^^
[15:37] <tseliot> cnd: where's the source?
[15:37] <cnd> tseliot, I just pushed it to git.debian.org
[15:37] <tseliot> or the patch
[15:39] <tseliot> cnd: here? http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=shortlog;h=refs/heads/ubuntu
[15:39] <cnd> tseliot, yep
[15:39] <cnd> wait, it's not there...
[15:39] <tseliot> which is why I asked ;)
[15:40] <cnd> ahh, pushed to the wrong tree
[15:40] <cnd> sorry bout that
[15:40] <cnd> one sec
[15:40] <cnd> is git.debian.org hard to reach for anyone else?
[15:40] <cnd> it doesn't resolve to an ip address half the time for me
[15:40] <cnd> and then it's slow to connect
[15:41] <cnd> tseliot, it's updated now
[15:42] <tseliot> I can reach that address without problems here
[15:43] <cnd> tseliot, it happens intermittently
[15:44] <tseliot> ok
[15:44] <tseliot> let me review your changes
[15:44] <cnd> tseliot, thanks
[15:45] <tseliot> cnd: any reason why you changed the source instead of adding a patch?
[15:46] <cnd> tseliot, I didn't change the source
[15:46] <cnd> I changed one of the patches
[15:47] <cnd> the patch is my xi 2.1 work
[15:47] <tseliot> cnd: ok, I guess my eyes are a little tired then ;)
[15:47] <cnd> tseliot, np :)
[15:47] <cnd> it's really hard to read
[15:47] <cnd> I know :(
[16:00] <tseliot> cnd: I'm asking an admin. If he says it's ok, I'll upload the package
[16:00] <cnd> tseliot, sounds good to me
[16:00] <cnd> tseliot, where are you asking?
[16:01] <tseliot> cnd: private message
[16:01] <cnd> ok
[16:03] <tseliot> we're good to go
[16:05] <tseliot> cnd: uploaded and pushed
[16:05] <cnd> tseliot, great!
[16:05] <cnd> thanks!
[16:05] <tseliot> np
[16:54] <LLStarks> does xvmc still need to be manually configured in xvmconfig or should it work out of the box?
[17:56] <alexmayorga> got a hung laptop with bug 553789 Anything to gather or do I just restart?
[17:56] <ubot4> Launchpad bug 553789 in xserver-xorg-video-nouveau (Ubuntu) (and 2 other projects) "X freeze/crash with nouveau driver (affects: 26) (dups: 5) (heat: 132)" [High,Confirmed] https://launchpad.net/bugs/553789
[17:56] <alexmayorga> RAOF: ping
[18:17] <alexmayorga> bryce_: ping
[18:32] <mdeslaur> Does anyone here have a Lenovo T510 with nvidia optimus in it? is it possible to force usage of the Intel graphics in it?
[18:34] <Sarvatt> mdeslaur: yep it is luckily
[18:34] <Sarvatt> you can pick between the 2 GPU's or optimus mode in bios on that
[18:35] <mdeslaur> Sarvatt: oh sweet...and the Intel card supports the 1920x1080 screens?
[18:35] <Sarvatt> one of the few optimus laptops that actually work
[18:35] <Sarvatt> yep
[18:36] <mdeslaur> Sarvatt: that's good news...I was thinking of replacing my T61, but didn't want an nvidia card this time, but that,s all that is listed on the Lenovo site for the high-res screens
[18:36] <mdeslaur> Sarvatt: so, thanks!
[18:36] <Sarvatt> mdeslaur: how long can ya wait? :)
[18:36] <mdeslaur> Sarvatt: why?
[18:58] <bjsnider> Sarvatt, how's ath9k doing in natty? is it unusable still?
[18:59] <Sarvatt> bjsnider: I ditched my ath9k for intel a looong time ago, had all kinds of problems on .37 with it
[19:00] <Sarvatt> had to rmmod/modprobe it every 10gb transferred or so (very rough estimate)
[19:01] <Sarvatt> mainly ditched it because it didn't work on the 5ghz band
[19:12] <knittl> namnö,bauern sind die sicher nicht
[19:12] <knittl> mc	nö, sind eher unbekannt
[19:13] <knittl> woops. sorry
[19:24] <bjsnider> Sarvatt, the hardware didn't work on 5gz or the driver?
[19:24] <Sarvatt> hardware
[19:24] <bjsnider> what was it?
[19:26] <bjsnider> i think that means it was only draft n
[19:41] <Sarvatt> almost all non intel mini pcie cards are only 2.4ghz band :(
[19:42] <Sarvatt> card says ar5b95
[20:37] <Amaranth> so, it seems fullscreen flash locks the GPU (or kernel panics in the i915 module) with a macbook pro with intel HD3000 :/
[20:38] <Amaranth> I don't even know how to get debug info about that since the system seems to entirely die
[20:40] <Sarvatt> Amaranth: try the drm-intel-next mainline kernel
[20:41] <Sarvatt> all kinds of sandybridge problems with fixes still not merged in .38 at the moment
[20:56] <Azelphur> Hi, my X keeps freezing and using 100% CPU, I'd like to take a crack at debugging it, anyone care to help?
[20:56] <Azelphur> It's frozen and 100%ing now and I'm ssh'd in from my netbook
[21:00] <Sarvatt> bryce_, RAOF: think I should put a newer mesa 7.10 branch checkout in x-updates/natty? so many juicy sandybridge fixes in the past few days and we're in bad shape in that regard in the archive mesa
[21:02] <bryce_> Sarvatt, if you have time, that'd be great
[21:03] <Sarvatt> wont even take 5 minutes to do that, okie
[21:03] <Azelphur> guess I'll just keep killing and restarting X like I usually do until it works \o/
[21:04] <Azelphur> looks like it'e the nvidia driver anyway, I managed to attach gdb to it
[21:05] <Sarvatt> Azelphur: ya read my mind, was just going to ask that.. might want to check http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
[21:06] <Azelphur> fun, lots of people with problems :p
[21:09] <Sarvatt> what driver version/desktop environment are you using? watching videos using vdpau and using kwin seem to be common themes with that problem there with the current releases
[21:10] <bryce_> ugh kwin
[21:12] <Sarvatt> if you've got flash 10.2 on 32 bit it's using vdpau so might be triggering that just having ads open on web sites
[21:17] <cnd> RAOF, the libavg guys have a minimal test case for that mesa glx tls issue
[21:17] <cnd> bug 259219
[21:17] <ubot4> Launchpad bug 259219 in mesa (Ubuntu) "Broken TLS support in libGL.so (affects: 1) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/259219
[21:28] <Sarvatt> go figure, new batch of commits to 7.10 branch right as I was going to upload :)
[21:29] <bryce_> what?
[21:29] <bryce_> oh oops was thinking 1.10
[21:30] <bryce_> and went, "Didn't they *just* release it?"
[21:32] <bryce_> hmm, bug #720468 seems our most popular gpu lockup today
[21:32] <ubot4> Launchpad bug 720468 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x7f9c002d) (affects: 16) (dups: 13) (heat: 124)" [High,Triaged] https://launchpad.net/bugs/720468
[21:45] <RAOF> cnd: Ah, sweet.  Test case!
[21:45] <jcristau> Sarvatt: idr says he wants to do 7.10.1 tomorrow
[21:45] <Sarvatt> cool!
[21:45] <Sarvatt> no wonder all the intel fixes are getting cherry picked all the sudden :)
[21:47] <RAOF> Yeah.  I was expecting that soon and was planning to update to 7.10.1 when it was releaesed.
[21:48]  * Sarvatt has been REALLY out of the loop
[22:01] <bryce_> RAOF, are you on x86_65?
[22:01] <RAOF> Yes.
[22:01] <RAOF> (Well, this box is; I've got an i386 965 box too)
[22:02] <bryce_> would you mind grabbing the CoreDump.gz files off bugs 724187 and 723319 and doing gdb /usr/bin/Xorg ; core /tmp/CoreFile ; bt full ?
[22:02] <ubot4> bryce_: Bug 724187 on http://launchpad.net/bugs/724187 is private
[22:03] <bryce_> I suspect one of the bugs is just a dupe of the livecd OOM bug, and the other maybe is something to do with vbox
[22:03] <bryce_> but the retracers couldn't grok them
[22:14] <cnd> bryce_, lsinput works again!
[22:14] <cnd> and should forever more!
[22:15] <RAOF> bryce_: The coredump contained a single resolvable symbol; OsLookupColor at #38 in the stack.  Sorry, no joy.
[22:15] <Sarvatt> wonderful, it looks like fglrx requires the horizontal resolution to be a multiple of 64 (or else it reports screwed up info to xrandr) to work around a driver bug that was causing corruption in 3D apps when it wasn't
[22:16] <RAOF> That's totally awesome!
[22:16] <Sarvatt> RAOF: did ya load the symbols manually? gotta do that for core dumps
[22:16] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/659205
[22:16] <ubot4> Launchpad bug 659205 in fglrx-installer (Ubuntu) "[fglrx] fails to detect correct resolution with non-multiple of 64 virtual desktop area (affects: 3) (heat: 29)" [Undecided,New]
[22:16] <jcristau> hahaha.
[22:16] <bryce_> cnd, awesome!
[22:17] <bryce_> RAOF, ok thanks for checking
[22:17] <RAOF> Sarvatt: I did not know that :).  How does one load symbols manually? :)
[22:18] <Sarvatt> symbol <path to debug lib> for each lib
[22:19] <Sarvatt> I think..
[22:19] <Sarvatt> been awhile, let me check
[22:20] <RAOF> Oh, and it'll probably work better if I don't have a locally built, patched Xserver, too.
[22:21] <Sarvatt> sharedlibrary <path to debug lib>?
[22:21] <Sarvatt> could have sworn it was symbol
[22:22] <RAOF> I think symbol works.
[22:23] <RAOF> But, again, symbol resolution will likely work better if I actually have the same symbols :)
[22:30] <RAOF> Hm.  Now with symbols it seems to be dying in dl-fini, which may be fallout of the gallium fallback patch which I already fixed.
[22:34] <bryce_> is that bug 724187?  yeah it smells a lot like that other vbox/gallium/x64 bug
[22:34] <ubot4> bryce_: Bug 724187 on http://launchpad.net/bugs/724187 is private
[22:36] <RAOF> Yeah, that's the core file I was looking at.
[22:40] <Sarvatt> btw, nvidia-current works with the 1.10 release as long as IgnoreABI is set, we could just add that via jockey the way we have many times in the past
[22:41] <bryce_> RAOF, does bug 723319's core give anything beyond ShouldSkipDevice()?
[22:41] <ubot4> bryce_: Bug 723319 on http://launchpad.net/bugs/723319 is private
[22:43] <bryce_> I'm 90% sure that's just the OOM bug already fixed now
[22:44] <Sarvatt> bryce_: fixed? ahh I was sick all weekend and didn't check up on it, was it just reverted or actually fixed?
[22:44] <Sarvatt> the ubiquity one?
[22:44]  * Sarvatt digs
[22:44] <bryce_> Sarvatt, oh sorry you were sick!
[22:45] <bryce_> Sarvatt, yep, it happened I caught colin just in time as he was prepping a new ubiquity update, and he accepted the patch to revert
[22:45] <bryce_> mario gave another similar patch which purportedly also helped, and he took that as well
[22:46] <bryce_> the original cosmetic bug is re-opened, colin agreed it was better to have the OOM solved
[22:48] <RAOF> 723319 goes up ot ProcXGetDeviceFocus, will an null client.
[22:52] <bryce_> RAOF, mind pasting the bt onto the bug?  I'll follow up on it from there.
[22:52] <bryce_> looking at the XorgLogOld.txt I can see it definitely is the same bug
[23:07] <bryce_> RAOF, thanks that's perfect
[23:37] <bryce_> bug 718620 appears to be a hybrid-graphics specific issue 
[23:37] <ubot4> Launchpad bug 718620 in xserver-xorg-video-intel (Ubuntu) "With HybridGraphics Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 19) (dups: 25) (heat: 200)" [High,Triaged] https://launchpad.net/bugs/718620