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