| RAOF | Hm. It's not *too* hard to do the ForceGallium patch in a potentially-upstreamable way. | 02:10 |
|---|---|---|
| bryceh | heya RAOF | 02:18 |
| RAOF | bryceh: Howdie. | 02:29 |
| RAOF | bryceh: I commented on fdo bug 34017 by the way, although I haven't really read the code to know whether that's it or not. | 02:32 |
| ubot4 | Launchpad bug 34017 in linux-restricted-modules-2.6.24 (Ubuntu) "Include nvidia-settings and nvidia-xconfig (heat: 1)" [Wishlist,Fix released] https://launchpad.net/bugs/34017 | 02:32 |
| bryceh | wow that's an old one | 02:32 |
| bryceh | oh fdo | 02:32 |
| RAOF | fdo 34017 | 02:32 |
| RAOF | Understand that, ubot4? :) | 02:32 |
| RAOF | The 965 lockup on boot thingy. | 02:34 |
| bryceh | hm interesting | 02:35 |
| RAOF | I guess I could have ppa'd up some packages for users to test, but Chris is responsive and actually knows what he's talking about :) | 02:36 |
| bryceh | what's the typo he's referring to in comment #8? | 02:36 |
| RAOF | I presumed it was somethnig to do with the output, but I couldn't spot the typo. | 02:36 |
| bryceh | I dunno, he may be responsive but his terse replies are sometimes cryptic and less than helpful | 02:40 |
| RAOF | Any comments on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/715939 ? If it's what I'm guessing, it's an unavoidable side-effect of our ForceGallium patch, which I could fairly easily re-do in such a way as to not break what their doing. | 02:40 |
| ubot4 | Launchpad bug 715939 in xserver-xorg-video-ati (Ubuntu) "6.14.0 and 101_select_between_classic_and_gallium_dri.patch doesn't work properly (affects: 1) (heat: 6)" [High,Incomplete] | 02:40 |
| RAOF | At the cost of not having an xorg.conf option to switch between gallium/not gallium. | 02:40 |
| bryceh | I'm curious if they did a manual install of something | 02:44 |
| bryceh | too bad they didn't report the issue via ubuntu-bug | 02:44 |
| RAOF | I think they did do a manual install of mesa, or at least are using LIBGL_DRIVERS_PATH. We *could* say not our problem, don't use ForceGallium + home made stuff. | 02:45 |
| bryceh | sounds like they might be playing with builds of upstream code, so yeah could be they got into a weird situation where they're using our mesa with upstream's drivers | 02:45 |
| bryceh | or vice versa | 02:45 |
| RAOF | Yeah. | 02:46 |
| bryceh | I think I'd be sort of tempted to do that. If he's using xorg-edgers that's one thing but if they start running hand rolled stuff, then I think the pottery barn rule kicks in | 02:46 |
| bryceh | otoh working properly in such a situation might encourage more testing or something... your call I guess, if you think it's worth the effort | 02:47 |
| bryceh | ickle's on crack | 02:48 |
| bryceh | although, I do notice the user is on xserver 1.9.902 | 02:50 |
| jaytaoko | bryceh: ping | 02:54 |
| bryceh | hi jaytaoko, I'm EODing in 2 minutes so need to be quick | 02:58 |
| bryceh | ok wife is calling me away. ttyl | 03:03 |
| * RAOF needs a new router. | 03:05 | |
| RAOF | jaytaoko: Can I tag-team for bryce? | 03:05 |
| jaytaoko | RAOF: hello | 03:14 |
| RAOF | Were you talking about the radeon unity graphical corruption bug? | 03:15 |
| RAOF | Oh, also. Hi! :) | 03:15 |
| jaytaoko | RAOF: thank you for responding. Would it be possible to revert to the previous X (before 1.10) on a system? | 03:15 |
| jaytaoko | RAOF: oh, we talked about the radeon corruption bug yesterday | 03:16 |
| RAOF | Yes, it should be possible to revert to a previous X. It'll be easiest if you've still got the old packages around in /var/cache/apt/archives, but possible even if not. | 03:17 |
| jaytaoko | RAOF: does that also mean a revert of the kernel? | 03:17 |
| RAOF | jaytaoko: Hm. I presume your question is in aid of installing one of the propritary drivers; I'm unsure if they build against the 2.6.38 kernel or not. If you weren't going for a proprietary driver, then you wouldn't need to care. | 03:19 |
| jaytaoko | RAOF: the think is I am facing another bug with the radeon driver... and I wonder if by reverting I can use my NVidia card instead | 03:19 |
| RAOF | The kernels are parallel installable, however; unless you've deliberately cleaned them up, you can probably select an older one with the grub menu. | 03:19 |
| RAOF | I _think_ that nvidia works on 2.6.38; that got uploaded before Xserver 1.10, so users would have complained about kernel breakage which I haven't noticed. | 03:20 |
| jaytaoko | RAOF: do you know if NVidia has released a new driver for the latest kernel... | 03:21 |
| RAOF | I don't know, sorry. | 03:21 |
| jaytaoko | RAOF: ok, because if they have, maybe I can try and put back my NVidia GPU | 03:21 |
| jaytaoko | RAOF: ok, what are the steps to revert? | 03:22 |
| jaytaoko | RAOF: also I can tell you more about that radeon bug... maybe you have an idea... | 03:23 |
| jaytaoko | RAOF: I have noticed since using my radeon with the open source driver, that some of my opengl programs don't respond visually as they should | 03:23 |
| jaytaoko | RAOF: for instead, I have a text editor entry based on OpenGL | 03:24 |
| RAOF | When using particular GL features, or just generally? | 03:24 |
| jaytaoko | RAOF: generally | 03:24 |
| jaytaoko | RAOF: my text editor entry does not show a cursor and when I type characters, they don't show up on the screen | 03:25 |
| jaytaoko | RAOF: The screen updates only after I move the entire window | 03:25 |
| RAOF | Hm, interesting. | 03:26 |
| jaytaoko | RAOF: this correspond to an X ConfigureNotify event | 03:26 |
| jaytaoko | RAOF: It works fine on Intel and NVidia. | 03:26 |
| jaytaoko | RAOF: I have it working on my dell mini 9 | 03:26 |
| RAOF | Or possibly just _any_ X event? It could be that something's not getting flushed, and so the X connection is waiting to fill a buffer...? | 03:27 |
| jaytaoko | RAOF: Do you think I should flush a buffer after calling the buffer swap for opengl? | 03:27 |
| jaytaoko | RAOF: XFlush for instance? | 03:28 |
| RAOF | You could try that, but I'm not sure that it should be needed. | 03:28 |
| RAOF | That's just my first-order wild guess after hearing the symptoms. | 03:28 |
| jaytaoko | RAOF: let me try... | 03:28 |
| bjsnider | jaytaoko, the problem is the x server not the kernel. but they haven't released a new one today | 03:29 |
| jaytaoko | bjsnider: yes, I understand NVidia and ATI have to release new drivers that works with the latest release of X | 03:31 |
| jaytaoko | bjsnider: proprietary drivers that is | 03:31 |
| bjsnider | do you further understand that you should be using the x-updates ppa for those updates and not installing them from nvidia's website? | 03:32 |
| RAOF | As for downgrading, I think ‘sudo aptitude install xserver-xorg-core=2:1.9.0.902-1ubuntu4 xserver-xorg-input-evdev=1:2.6.0-1ubuntu5 nvidia-current” should give you a downgrade path, if the packages are still in your apt cache. | 03:37 |
| jaytaoko | bjsnider: I always get them from the ubuntu updates | 03:38 |
| bjsnider | ok | 03:38 |
| RAOF | If they're not, you can download them from launchpad: https://launchpad.net/ubuntu/+source/xorg-server/2:1.9.0.902-1ubuntu4/+buildjob/2146215 and https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.6.0-1ubuntu4/+buildjob/2235322 | 03:38 |
| jaytaoko | RAOF: thanks! | 03:39 |
| jaytaoko | RAOF: unfortunately, XFlush has no effect on issue... | 03:40 |
| jaytaoko | RAOF: but has you said, it should not be necessary to call XFlush | 03:40 |
| RAOF | Are you mixing X rendering (ie: fonts) with GL calls? Although IIUC that shouldn't be fixed by a ConfigureNotify... | 03:42 |
| jaytaoko | RAOF: no pure GL... | 03:43 |
| jaytaoko | RAOF: I only do OpenGL calls | 03:43 |
| RAOF | Hm. Font rendering in GL? Cool :). I'm... not sure, then. | 03:44 |
| jaytaoko | RAOF: The text entry I am working on use pango+cairo for font rendering in software | 03:44 |
| RAOF | Ah, right. | 03:44 |
| jaytaoko | RAOF: then from the software rendering of the text, transform that into an opengl texture | 03:45 |
| jaytaoko | RAOF: and use that texture | 03:45 |
| RAOF | Hm, yeah. | 03:45 |
| jaytaoko | RAOF: but I have other simpler program that don't use pago+cairo and they exhibit the same issue | 03:45 |
| RAOF | I guess the only other thing to check would be whether the problem is in the rendering, or in the displaying; you could possibly distinguish between those by dumping the front/back buffers as an image file and looking at them? | 03:46 |
| RAOF | It certainly just *sounds* like a driver bug :) | 03:46 |
| jaytaoko | RAOF: ther program does some optimization to avoid rendering when it does not have to... | 03:47 |
| jaytaoko | RAOF: if I disable these optimizations, they the program renders as expected... But it becomes much slower, because some operations are done much more frequently | 03:47 |
| RAOF | Ah, ok. | 03:48 |
| RAOF | This sounds like it could relatively easily be made into a small automated test, which could be incorporated into piglit? | 03:48 |
| jaytaoko | RAOF: in this particular case there is some allocation of texture and framebuffer surface that are done at every frames if I disable the optimizations | 03:48 |
| jaytaoko | RAOF: it is part of Nux test case | 03:49 |
| jaytaoko | RAOF: The program uses the rendering architecture of Nux | 03:49 |
| jaytaoko | RAOF: so I don't know how to reproduce that in a smaller test case | 03:50 |
| RAOF | Ah. That's probably not small enough to go into piglit :). Hm. Is there a bug filed for this? | 03:50 |
| jaytaoko | RAOF: no, I haven't filled a bug yet. because I don't have a case to make it a bug in the driver just yet | 03:52 |
| RAOF | Ah. You're not totally convinced that nux is doing something that's not guaranteed to work, but that intel and nvidia happen to make work as a happy accident? | 03:53 |
| jaytaoko | RAOF: I suspect a driver issue, but filling it in that way with reference to a big program such as Nux won't be helpful | 03:53 |
| jaytaoko | RAOF: yes, I am not convinced... | 03:53 |
| RAOF | Ah. Ok. | 03:54 |
| jaytaoko | RAOF: unless I can pin-point the issue precisely, I can't say with 100% certainty that this is a driver bug | 03:54 |
| jaytaoko | RAOF: still I suspect a driver bug :-D | 03:54 |
| RAOF | Right. :) | 03:55 |
| RAOF | If you *could* narrow it down to a smallish test-case, I'd be happy to do the manouevering required to get it into piglit, where it'll become a part of the test-suite. | 03:55 |
| jaytaoko | RAOF: thanks, I am going to try and find where the issue is... I hope I can tell you that soon | 03:56 |
| RAOF | Sweet. | 03:57 |
| thesheff17 | once in a great while about once a day my x server crashes. Any in site into this problem? http://pastebin.com/F2mQm5Qn | 04:00 |
| RAOF | thesheff17: Urgh, fglrx. It might be an Xserver problem, in which case we could potentially do something about it, or it might be an fglrx problem, in which case there's little to do but hope amd fix it. | 04:20 |
| RAOF | thesheff17: Have you filed a bug? A better backtrace would be useful, too. | 04:20 |
| thesheff17 | RAOF: I have not filed a bug yet...how can I get a better backtrace of it? | 04:21 |
| RAOF | thesheff17: https://wiki.ubuntu.com/X/Backtracing is a good reference. | 04:22 |
| thesheff17 | RAOF: ok I enabled the apport service. | 04:24 |
| thesheff17 | RAOF: unfortunately the crash is completely random...about once every 24 hours. | 04:25 |
| RAOF | Well, hopefully apport will catch it next time. | 04:26 |
| RAOF | You should also install the debugging packages; at least xserver-xorg-core-dbg, but possibly others mentioned on the debugging page. | 04:26 |
| thesheff17 | RAOF: sure will do. | 04:27 |
| thesheff17 | I installed xserver-xorg-video-ati-dbg, xserver-xorg-core-dbg, libgl1-mesa-dri-dbg and will let you know when it happens again....what should I do when it does happen again? | 04:33 |
| jaytaoko | RAOF: I have another Natty system that I haven't updates in 2 months. Can I update it to a point in time before alpha 2? | 04:42 |
| RAOF | thesheff17: Apport will *hopefully* pop up and offer to help you report the bug. Do so :) | 04:43 |
| RAOF | jaytaoko: If you update it from the command line you can upgrade it without upgrading the X server - aptitude is good at offering choices (some of which will be wrong ☺). | 04:43 |
| thesheff17 | well the screen goes black...and I actually see like 10.10 loading screen. I have ssh access though | 04:44 |
| thesheff17 | also all the ctrl-alt F keys don't work as well :-/ | 04:44 |
| jaytaoko | RAOF: will try that! | 04:44 |
| RAOF | jaytaoko: Failing that, “apt-get upgrade” will guarantee an upgrade without removing nvidia. | 04:44 |
| RAOF | thesheff17: apport should record the crash, and offer to file it when you start up next time. | 04:45 |
| thesheff17 | RAOF: ah excellent | 04:45 |
| thesheff17 | RAOF: thanks for the help. | 04:45 |
| tjaalton | ..and now the laptop froze.. duh | 10:48 |
| tjaalton | fun with nouveau _and_ intel | 10:48 |
| === yofel_ is now known as yofel | ||
| tjaalton | interesting, now all the menus open behind the windows.. | 14:01 |
| tjaalton | don't get it.. thunderbird on one machine opens links fine, on the other firefox tries to open "www.%u.com" | 15:16 |
| tjaalton | both running natty | 15:16 |
| thesheff17 | RAOF: ping | 19:17 |
| === Amaranth_ is now known as Amaranth | ||
| bryceh | Internal error: Could not resolve keysym XF86TouchpadOn | 21:33 |
| bryceh | Internal error: Could not resolve keysym XF86TouchpadOff | 21:33 |
| bryceh | anyone else have ^^ in their .xsession-errors ? | 21:33 |
| bryceh | (this is on a desktop with no touchpad) | 21:33 |
| RAOF | thesheff17: Pong | 22:01 |
| thesheff17 | RAOF: I had the xserver crash but it didn't let me report anything once it crashed. | 22:04 |
| RAOF | :( | 22:04 |
| RAOF | Hm. The apport hook doesn't always catch crashes. | 22:05 |
| RAOF | But with those debug symbols installed the backtrace in /var/log/Xorg.0.log might be better. | 22:05 |
| thesheff17 | RAOF: hmm.strange I don't see it crashing in Xorg.0.log. I SSH into the machine from my laptop and did an /etc/init.d/gdm restart did that over write the log? | 22:09 |
| RAOF | Yes, it would, but it would move it to Xorg.0.log.old. | 22:09 |
| RAOF | Hah! But if you can SSH in then you can attach gdb and grab a really good backtrace! | 22:10 |
| RAOF | As long as you don't mind having gdb attached for a day or so, until the crash happens :) | 22:10 |
| thesheff17 | RAOF: yea that is no problem. | 22:10 |
| RAOF | Then that's a good way to get a good backtrace, but if Xorg.0.log.old has a backtrace in it, that would be useful to see first, too. | 22:13 |
| thesheff17 | here is my Xorg.0.log.old http://pastebin.com/sd7LkHFF I just went through the steps to attach it. I think it is already running. | 22:14 |
| RAOF | There are a couple of non-obvious pitfals to having gdb attached to X; they're listed on the X/Debugging page I linked you to yesterday. Basically, you want to “handle SIGUSR1 nostop” so VT switching works, and “handle SIGPIPE nostop” so closing apps doesn't cause X to stop in gdb. | 22:18 |
| RAOF | Urgh, no. That backtrace is just as useless as the last one. Oh, well. gdb should grab a better one! | 22:19 |
| thesheff17 | RAOF: yea it didn't look much different then the last one I was looking at. So basically I attached the pid to gdb and then did cont. Should I stop this so I can address those SIG stuff? and then re attach? | 22:20 |
| RAOF | If you hit ctrl-c in the gdb window that should stop X and return control to gdb, where you can do the SIG handling stuff. | 22:21 |
| thesheff17 | k | 22:21 |
| RAOF | Then cont will start X back up again. | 22:22 |
| thesheff17 | should X be stopped prior to attaching gdb? | 22:23 |
| LLStarks | ooh: http://www.nvnews.net/vbulletin/showthread.php?t=61644 | 22:23 |
| thesheff17 | nm...that last thing I said didn't make sense. Just knew to all this. | 22:23 |
| thesheff17 | *new | 22:23 |
| RAOF | Whenever gdb catches a signal - SIGSEGV (generated by the crash), SIGINT (generated by ctrl-c), SIGUSR1 (generated by VT switching) - it stops the process that it's attached to. | 22:26 |
| RAOF | And throws up a gdb prompt. Since one of those things is something that you're not interested in debugging - namely VT switching - you want gdb to not stop there. | 22:27 |
| thesheff17 | RAOF: ah ok | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!