LLStarks | if i'm having vsync issues, do i file against ddx? | 00:10 |
---|---|---|
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:11 |
LLStarks | rather, almost a week | 00:12 |
LLStarks | no edgers drivers or anything | 00:12 |
RAOF | And you're running... nouveau? | 00:13 |
LLStarks | 915 | 00:13 |
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:14 |
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:15 |
LLStarks | 115_quell_vblank_counter_failed.patch | 00:17 |
LLStarks | probably doesn't apply here | 00:17 |
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:18 |
LLStarks | ugh. time to bisect. | 00:19 |
RAOF | Want to throw up an Xorg.0.log just to check? | 00:20 |
LLStarks | i didn't see anything suspicious | 00:20 |
LLStarks | http://pastebin.com/XB1tLDfG | 00:21 |
RAOF | Is it only with the spanned monitors? | 00:23 |
LLStarks | raof, eh? single lvds. | 00:50 |
RAOF | LLStarks: That xorg log shows i915 allocating a 2880x900 framebuffer at one point. | 00:50 |
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:51 |
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:52 |
LLStarks | and using tv as single-monitor | 00:53 |
LLStarks | the tearing is quite visible on screenshots. | 00:56 |
RAOF | Visible on *screenshots*? That's odd. | 00:57 |
LLStarks | yeah | 01:00 |
LLStarks | flash, xv, gl, it doesn't matter | 01:00 |
LLStarks | http://i.imgur.com/J2YWn.jpg | 01:01 |
LLStarks | i'll file a bug | 01:03 |
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:09 |
LLStarks | let's see if that compiz trick still works | 01:10 |
RAOF | vsync is already enabled by default. Try glxgears for example; it should be limited to (almost) exactly 60FPS | 01:12 |
LLStarks | yeah, compiz fixes it. | 01:13 |
LLStarks | can't use metacity anymore i guess | 01:13 |
LLStarks | and i'm on classic | 01:18 |
LLStarks | hmmm. i see now. | 01:20 |
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:21 |
LLStarks | ugh, maybe idon't get it | 01:22 |
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:07 |
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:12 |
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:16 |
RAOF | LLStarks: Yeah, pretty much. | 02:17 |
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. | 02:18 |
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:43 |
RAOF | .35? From memory? | 05:44 |
LLStarks | i'm thinking of grabbing a few optimus notebooks lying around and bruteforcing them acpi calls | 05:44 |
RAOF | From my understanding of optimus, that's not going to be terribly useful, except to possibly turn off the nvidia card. | 05:45 |
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:46 |
LLStarks | https://bbs.archlinux.org/viewtopic.php?pid=882737#p882737 | 05:47 |
LLStarks | assuming that acpi_call generates calls that "work", i see little reason why it wouldn't be sufficient. | 05:48 |
LLStarks | yet devs are convinced that acpi is not the solution | 05:50 |
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:51 |
RAOF | Feel free to try; it's not like we've got specs saying it's impossible :) | 05:52 |
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:53 |
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:54 |
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:55 |
LLStarks | i'd rather lose shared rendering if a simple SB.PCI0.PEG1.GFX0._OFF call can enable the discrete gpu | 05:59 |
RAOF | Well, I meant that systems which use a mux instead of a more funky approach *can't* support shared rendering. | 06:00 |
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:01 |
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:02 |
LLStarks | howso? | 06:03 |
LLStarks | btw, if not acpi, what approaches are left? nvidia coding an intel driver? | 06:06 |
RAOF | LLStarks: The intel and nvidia drivers cooperating, yes. | 08:42 |
RAOF | LLStarks: That's how it'll (eventually!) work in Linux-land :) | 08:42 |
tjaalton | sigh, this nvidia blob is slow | 09:22 |
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 | 09:24 |
tjaalton | huh, classic desktop opens unity now? | 10:24 |
tjaalton | had to disable the compiz plugin manually | 10:26 |
seb128 | seems a bug, you are the second to mention it | 10:38 |
tjaalton | ok, good | 10:40 |
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 | 10:41 |
knittl | "Due to hardware capability constraints, disabling display" | 11:12 |
knittl | oO | 11:12 |
knittl | i think this is related to my "blank screen when using nvidia-current and both screens run at full resolution" | 11:13 |
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:14 |
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:15 |
tseliot | knittl: what's up? | 11:28 |
knittl | i was told to talk to you regarding jockey not recognizing the installad driver | 11:28 |
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:29 |
knittl | do you have a secret wire to nvidia? :] | 11:30 |
tseliot | knittl: I do but you'll have to file a bug report about it and attach your nvidia-bug-report.log | 11:31 |
knittl | bugreport on launchpad? | 11:32 |
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:34 |
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:35 |
knittl | $ jockey-text -l | 11:36 |
knittl | xorg:nvidia_current - NVIDIA accelerated graphics driver (Proprietary, Disabled, In use) | 11:36 |
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:37 |
tseliot | can I see 1) your xorg.conf 2) the output of sudo update-alternatives --display gl_conf , please? | 11:38 |
knittl | http://thehappy.de/~neo/xorg.conf | 11:39 |
knittl | and u-a: http://paste2.org/p/1275564 | 11:39 |
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:43 |
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:44 |
knittl | hm, there's a 'correctly' missing … | 11:45 |
tseliot | if you can't add it, I will | 11:46 |
knittl | no, i've added it | 11:46 |
tseliot | ok | 11:48 |
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:53 |
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:54 |
tseliot | the log shows that it shouldn't | 11:55 |
knittl | tseliot: currently i only see nvidia-current (not even nouveau) | 11:55 |
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:56 |
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:57 |
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 | 11:58 |
knittl | added | 12:01 |
tseliot | thanks | 12:07 |
knittl | np | 12:08 |
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:03 |
tseliot | bjsnider: I'd rather not have the same command twice (one without the 32bit stuff) in the postinst just for that warning | 14:05 |
bjsnider | tseliot, that was the only error or indication of failure in the jockey log from knittl | 14:06 |
bjsnider | his jockey log actually said "error", not "warning" | 14:07 |
tseliot | right, I don't think that's what's causing the problem though | 14:08 |
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:09 |
knittl | yeah, jockey aborts before creating xorg.conf | 14:10 |
knittl | and the error message is confusing | 14:10 |
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:11 |
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:13 |
tseliot | the autoloading stuff is supposed to make things work when you install the package manually | 14:14 |
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:15 |
bjsnider | knittl, right, but if you use jockey, it errors out, says "check the jockey log" which doesn't include anything helpful | 14:16 |
knittl | bjsnider: yup, exactly | 14:17 |
tseliot | ah, so you got an error too | 14:17 |
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:18 |
tseliot | ok | 14:19 |
knittl | xorg.conf had to be generated with nvidia-xconfig (or manually) | 14:19 |
bjsnider | knittl, why are you on i386? | 14:20 |
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:21 |
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:22 |
knittl | i cleared the file before starting jockey and copied right after the error popped up and i had closed jockey | 14:23 |
bjsnider | the line 4 from the bottom doesn't contain an explanation | 14:24 |
tseliot | I guess KernelModuleHandler.enabled() failed somehow | 14:27 |
bjsnider | is 2.6.38-5-generic-pae the kernel in natty right now? | 14:28 |
knittl | yes | 14:29 |
tseliot | knittl: please attach that log to the bug report | 14:32 |
knittl | hm. i thought i had | 14:32 |
knittl | will do | 14:32 |
bjsnider | maybe the pae kernel is somehow the problem | 14:33 |
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:35 |
knittl | jockey.log attached | 14:36 |
tseliot | thanks | 14:39 |
bjsnider | tseliot, is this exclusively a jockey problem? | 14:41 |
tseliot | I think so | 14:42 |
bjsnider | in that case, his external monitor issue is exclusively an nvidia problem | 14:42 |
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:46 |
bjsnider | actually, it could be a hardware problem, but not something we can fix anyway | 14:47 |
knittl | hardware problem would not explain, why it works with nvidia-173 | 14:48 |
knittl | minus the comma | 14:48 |
tseliot | it definitely is s different problem | 14:49 |
bjsnider | in that case it's a regression in the driver | 14:49 |
cnd | bryce_, is it still possible to get a fix in for evdev? | 15:17 |
cnd | due to the alpha 3 release freeze | 15:18 |
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:35 |
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:37 |
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:39 |
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:40 |
cnd | tseliot, it's updated now | 15:41 |
tseliot | I can reach that address without problems here | 15:42 |
cnd | tseliot, it happens intermittently | 15:43 |
tseliot | ok | 15:44 |
tseliot | let me review your changes | 15:44 |
cnd | tseliot, thanks | 15:44 |
tseliot | cnd: any reason why you changed the source instead of adding a patch? | 15:45 |
cnd | tseliot, I didn't change the source | 15:46 |
cnd | I changed one of the patches | 15:46 |
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 :( | 15:47 |
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:00 |
tseliot | cnd: private message | 16:01 |
cnd | ok | 16:01 |
tseliot | we're good to go | 16:03 |
tseliot | cnd: uploaded and pushed | 16:05 |
cnd | tseliot, great! | 16:05 |
cnd | thanks! | 16:05 |
tseliot | np | 16:05 |
LLStarks | does xvmc still need to be manually configured in xvmconfig or should it work out of the box? | 16:54 |
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 | 17:56 |
alexmayorga | bryce_: ping | 18:17 |
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:32 |
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:34 |
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:35 |
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:36 |
bjsnider | Sarvatt, how's ath9k doing in natty? is it unusable still? | 18:58 |
Sarvatt | bjsnider: I ditched my ath9k for intel a looong time ago, had all kinds of problems on .37 with it | 18:59 |
Sarvatt | had to rmmod/modprobe it every 10gb transferred or so (very rough estimate) | 19:00 |
Sarvatt | mainly ditched it because it didn't work on the 5ghz band | 19:01 |
knittl | namnö,bauern sind die sicher nicht | 19:12 |
knittl | mcnö, sind eher unbekannt | 19:12 |
knittl | woops. sorry | 19:13 |
bjsnider | Sarvatt, the hardware didn't work on 5gz or the driver? | 19:24 |
Sarvatt | hardware | 19:24 |
bjsnider | what was it? | 19:24 |
bjsnider | i think that means it was only draft n | 19:26 |
Sarvatt | almost all non intel mini pcie cards are only 2.4ghz band :( | 19:41 |
Sarvatt | card says ar5b95 | 19:42 |
Amaranth | so, it seems fullscreen flash locks the GPU (or kernel panics in the i915 module) with a macbook pro with intel HD3000 :/ | 20:37 |
Amaranth | I don't even know how to get debug info about that since the system seems to entirely die | 20:38 |
Sarvatt | Amaranth: try the drm-intel-next mainline kernel | 20:40 |
Sarvatt | all kinds of sandybridge problems with fixes still not merged in .38 at the moment | 20:41 |
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 | 20:56 |
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:00 |
bryce_ | Sarvatt, if you have time, that'd be great | 21:02 |
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:03 |
Azelphur | looks like it'e the nvidia driver anyway, I managed to attach gdb to it | 21:04 |
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:05 |
Azelphur | fun, lots of people with problems :p | 21:06 |
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:09 |
bryce_ | ugh kwin | 21:10 |
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:12 |
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:17 |
Sarvatt | go figure, new batch of commits to 7.10 branch right as I was going to upload :) | 21:28 |
bryce_ | what? | 21:29 |
bryce_ | oh oops was thinking 1.10 | 21:29 |
bryce_ | and went, "Didn't they *just* release it?" | 21:30 |
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:32 |
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:45 |
RAOF | Yeah. I was expecting that soon and was planning to update to 7.10.1 when it was releaesed. | 21:47 |
* Sarvatt has been REALLY out of the loop | 21:48 | |
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:01 |
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:02 |
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:03 |
cnd | bryce_, lsinput works again! | 22:14 |
cnd | and should forever more! | 22:14 |
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:15 |
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:16 |
bryce_ | RAOF, ok thanks for checking | 22:17 |
RAOF | Sarvatt: I did not know that :). How does one load symbols manually? :) | 22:17 |
Sarvatt | symbol <path to debug lib> for each lib | 22:18 |
Sarvatt | I think.. | 22:19 |
Sarvatt | been awhile, let me check | 22:19 |
RAOF | Oh, and it'll probably work better if I don't have a locally built, patched Xserver, too. | 22:20 |
Sarvatt | sharedlibrary <path to debug lib>? | 22:21 |
Sarvatt | could have sworn it was symbol | 22:21 |
RAOF | I think symbol works. | 22:22 |
RAOF | But, again, symbol resolution will likely work better if I actually have the same symbols :) | 22:23 |
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:30 |
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:34 |
RAOF | Yeah, that's the core file I was looking at. | 22:36 |
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:40 |
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:41 |
bryce_ | I'm 90% sure that's just the OOM bug already fixed now | 22:43 |
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:44 |
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:45 |
bryce_ | the original cosmetic bug is re-opened, colin agreed it was better to have the OOM solved | 22:46 |
RAOF | 723319 goes up ot ProcXGetDeviceFocus, will an null client. | 22:48 |
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 | 22:52 |
bryce_ | RAOF, thanks that's perfect | 23:07 |
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 | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!