| libv | ah michaellarabel, you're awake :) | 02:46 |
|---|---|---|
| RAOF | Hm. What have I broken in nouveau? | 04:40 |
| RAOF | Oh. I may have built it against broken headres. | 04:57 |
| RAOF | Aha! It was, of course, option 3. "lbm-drm" != "drm_lbm" | 05:28 |
| RAOF | Combined with VESA hating kms with a passion. | 05:35 |
| Duke` | interresting: http://bugzilla.kernel.org/show_bug.cgi?id=15004 | 06:23 |
| ubottu | bugzilla.kernel.org bug 15004 in Video(DRI - Intel) "i915: *ERROR* Execbuf while wedged" [Normal,New] | 06:23 |
| Sarvatt | RAOF: did you see someone already released 2.4.17-0ubuntu2 without updating git? | 14:14 |
| Sarvatt | some ports people needed libdrm-intel1 to build on arm and powerpc so plymouth would build there | 14:15 |
| jcristau | libdrm-intel on arm and powerpc? srsly? | 14:17 |
| Sarvatt | yeah tell me about it.. | 14:22 |
| Sarvatt | easier to make libdrm-intel generic than fix plymouth i guess | 14:23 |
| jcristau | why don't they fix the actual bug instead? | 14:23 |
| Sarvatt | fedora builds it on all arches as well | 14:23 |
| jcristau | still doesn't make sense :) | 14:24 |
| Sarvatt | i tried to explain that but the person i was talking to was convinced intel might make an arm chipset because of xscale... :D | 14:27 |
| jcristau | *shrug* not my problem anyway. | 14:43 |
| bjsnider | why are people getting OpenGL version string: 2.1.2 NVIDIA 190.53 | 15:11 |
| bjsnider | when they do glxinfo? | 15:11 |
| bjsnider | that's the wrong opengl version | 15:11 |
| bjsnider | should say 3.2 | 15:11 |
| Sarvatt | bjsnider i just said why in #ubuntu+1 :D not all cards support all of the extensions for 3.2, they dont just show 3.2 globally because the driver supports it | 15:19 |
| Sarvatt | only G80 or newer does opengl 3+ | 15:20 |
| Sarvatt | The new features in OpenGL 3.0, OpenGL 3.1 and OpenGL 3.2 require G80, or newer hardware. Thus OpenGL 3.0/3.1/3.2 is not supported on NV3x, NV4x nor G7x hardware. - from http://developer.nvidia.com/object/opengl_3_driver.html | 15:24 |
| hyperair | what about nv1x? =p | 15:25 |
| Sarvatt | not supported by that driver at all so they didnt reference it :D i'm sure its opengl 1.4 or 1.5 though | 15:26 |
| Sarvatt | or not | 15:27 |
| Sarvatt | eww :D | 15:27 |
| Sarvatt | yeah 1.3 | 15:28 |
| vish | Sarvatt: could you have a look at Bug #515548 , it is logging the errors right now , any other info i can attach to the bug report? | 15:37 |
| ubottu | Launchpad bug 515548 in xserver-xorg-video-ati "Radeon errors overflow in gdm logs. Makes root run out of space." [Undecided,New] https://launchpad.net/bugs/515548 | 15:37 |
| * vish watches disk space running out :( | 15:44 | |
| Ng | dear xinput, please sit still! love, Ng | 16:09 |
| Sarvatt | i'd like to know why the xorg log is going to the gdm log in the first place | 16:34 |
| Sarvatt | the useful gdm log info is getting overwritten by the xorg log stuff | 16:35 |
| jcristau | Xorg stderr goes to gdm.log | 16:36 |
| Sarvatt | does your Xorg.0.log have all those CS section size missmatch start errors Ng? the ones attached to the bugs dont | 16:43 |
| Ng | Sarvatt: I'm not entirely sure what errors you're referring to, but "CS" doesn't occur in any of the Xorg logs I have on-disk right now | 16:44 |
| Sarvatt | the ones filling your gdm log, ah | 16:45 |
| Sarvatt | have you tried xorg-edgers to see if its any different with the newer mesa/ati? | 16:46 |
| bjsnider | Sarvatt, i didn't know the nvidia blob was so intelligent that it enables certain extensions depending on the hardware it's driving... | 16:50 |
| Sarvatt | it happens when watching videos with Xv right? | 16:51 |
| jcristau | "intelligent"? | 16:51 |
| jcristau | it's like 3d driver 101 | 16:51 |
| Sarvatt | ./radeon/radeon_cs_gem.c: fprintf(stderr, "CS section size missmatch start at (%s,%s,%d) %d vs %d\n", | 16:55 |
| Sarvatt | are there any upstream bugs about it that you know about Ng? it'd be easy to disable the error reporting from libdrm if you just want it fixed on your system and its working right but its obviously a bug with ati | 17:01 |
| Sarvatt | what are you doing when it writes that? watching a video with Xv or just using the system? | 17:01 |
| Sarvatt | can ya sudo tail -f /var/log/gdm/:0.log in a terminal while you use the system to see? | 17:02 |
| Ng | Sarvatt: I think you may have me confused with someone else, I'm not using an ati system or havnig problems with video, I was just whining at xinput for changing device names, breaking my scripts ;) | 17:02 |
| Sarvatt | ohh I'm really sorry Ng, indeed it was vish having the problem | 17:03 |
| Ng | np :) | 17:03 |
| Sarvatt | vish: see above please :D | 17:04 |
| * vish catches up , to | 17:04 | |
| jcristau | Ng: blame udev for putting quotes in the device names :) | 17:05 |
| vish | Sarvatt: I havent used Xorg-edgers since mesa in that crashes my X :( , But Xorg log doesnt seems to have any errors , the x log in the bug report didnt have the info? | 17:06 |
| Sarvatt | odd that the radeon stderr stuff is only going to the gdm log, intel stuff goes to the Xorg.0.log when it prints this stuff | 17:06 |
| jcristau | ErrorF vs fprintf(stderr) i guess | 17:07 |
| vish | hmm , mesa in lucid is also 7.7 > I was earlier having this Bug #436546 , hence stopped using -edgers | 17:09 |
| ubottu | Launchpad bug 436546 in mesa "X crashes when using compiz cube and cairo-dock" [Unknown,Confirmed] https://launchpad.net/bugs/436546 | 17:09 |
| Sarvatt | brb driving | 17:10 |
| * vish checks mesa in -edgers | 17:12 | |
| vish | anyone know if the mesa 7.7 in lucid is same as mesa 7.7.0~git20090921.972e995b-0ubuntu0tormod ? | 17:28 |
| Sarvatt | no, *alot* different | 17:50 |
| Sarvatt | tons of changes in the 3 months between those | 17:51 |
| Sarvatt | did you see what was said in #radeon vish? | 17:51 |
| Sarvatt | <suokko> [12:19:03] Sarvatt: Looks like change to R500 video code and not adding extra bytes to reserved space | 17:52 |
| Sarvatt | <suokko> [12:19:49] Without looking the code safe fix looks like adding 2 to reservation count in the line which error message complains about | 17:52 |
| vish | Sarvatt: just joined #radeon | 17:52 |
| Sarvatt | <suokko> [12:32:42] Sarvatt: http://sprunge.us/fBPB | 17:52 |
| vish | Sarvatt: hmm , i'm not sure how to patch and run that :s | 17:54 |
| Sarvatt | can you add that patch to the package or do you want me to make you one with that patch? | 17:54 |
| Sarvatt | okie one sec | 17:54 |
| Sarvatt | taking ages to update my sources on this tethered connection, sorry | 17:57 |
| vish | np... thanks for looking into it :) | 17:58 |
| Sarvatt | hoping bryce reenabled the patch system in the lucid package to make it easier :D | 17:58 |
| Sarvatt | uploaded it here vish https://edge.launchpad.net/~sarvatt/+archive/ppa | 18:02 |
| Sarvatt | argh wait a sec | 18:02 |
| Sarvatt | i have a ppa dependency on edgers there | 18:02 |
| Sarvatt | putting it here https://edge.launchpad.net/~sarvatt/+archive/more-bugs | 18:03 |
| * vish adds ppa and awaits upload | 18:05 | |
| bryce_ | heya | 18:31 |
| === bryce_ is now known as bryce2 | ||
| Sarvatt | heyo bryceh/bryce2/bryce_, sorry disconnected a few times there :) | 18:49 |
| bryce2 | :-) | 18:49 |
| bryce2 | Sarvatt, yeah at the developer's sprint right now. I was actually surprised wireless worked right off the bat no prob. | 18:53 |
| Sarvatt | bryce2: any chance replacing the ErrorF's in 100_rethrow_signals.patch with fprintf(stderr's might work? Does ErrorF try to write to the log? | 18:55 |
| bryce2 | yeah ErrorF does try to write to the log | 18:56 |
| Sarvatt | I'm thinking its the ErrorF's in FatalSignal() causing the problem | 18:56 |
| bryce2 | ok, yeah I can give that a shot. Getting that sorted out is on my todo for the week | 18:57 |
| bryce2 | I'm also wondering if that NoTrapSignals or whatever flag would be worth trying | 18:57 |
| Sarvatt | yeah I'm going to try it out as well when I get a chance, just looking at logging problems vish is having and put two and two together | 18:57 |
| bryce2 | seems to me we tried that at one point but I don't remember | 18:57 |
| * bryce2 nods | 18:58 | |
| bryce2 | btw did my pm reach you? | 18:58 |
| bryce2 | freenode is such a pita | 18:58 |
| vish | Sarvatt: i installed the updates , but the logging hasnt stopped... should i check after an X restart? | 18:58 |
| Sarvatt | vish: yeah have to restart X, if possible could you pastebin your ~/.xsession-errors if it happens again with that patch before you reboot again? | 19:00 |
| Sarvatt | looking now bryce2 | 19:00 |
| vish | hmm. , thats very odd...! it stopped just now... [/me wonders if it is scared of Sarvatt ] | 19:07 |
| vish | ;) | 19:07 |
| Sarvatt | the patch fixed it? | 19:09 |
| Sarvatt | keep in mind I'm almost positive it only happens when you're watching videos | 19:09 |
| vish | Sarvatt: i wasnt watching any videos now... [Was using Inkscape ] and after the update too , no videos but the logging was going on.. but just stopped now.. | 19:12 |
| * vish plays videos | 19:12 | |
| Sarvatt | nautilus thumbnailing videos would do it too | 19:12 |
| Sarvatt | or having a video without a thumbnail in the directory when you go to open a file in inkscape or something | 19:13 |
| vish | ha , might be that.. there were a few videos which wouldnt thumbnail | 19:13 |
| Sarvatt | no videos but the logging was going on.. but just stopped now.. << that mean you were getting the cs errors? | 19:33 |
| Sarvatt | with the patched driver? | 19:34 |
| vish | it seemed to occur even after the patched driver , but it has stopped logging now... I trying to check if it starts again.. [havent restarted X yet] earlier it wouldnt stop logging unless i restart X | 19:44 |
| vish | I'm* | 19:44 |
| vish | hmm , started again :/ | 19:47 |
| Sarvatt | you need to restart X to use the new driver vish | 19:47 |
| vish | Sarvatt: yeah.. i was just making sure :) | 19:47 |
| vish | brb | 19:50 |
| * vish now has a quiet gdm log , will be keeping an eye on it :) | 20:03 | |
| Duke` | ok, execbuf error still present | 20:04 |
| Sarvatt | #0 0x00007fff160baf40 in ?? () | 21:39 |
| Sarvatt | #1 0x000000000045f4a0 in FatalError (f=0x579a98 "Server is already active for display %s\n%s %s\n%s\n") at ../../os/log.c:561 | 21:39 |
| Sarvatt | #2 0x0000000000469293 in LockServer () at ../../os/utils.c:374 | 21:39 |
| Sarvatt | #3 0x00000000004629c6 in OsInit () at ../../os/osinit.c:305 | 21:39 |
| Sarvatt | #4 0x0000000000425f06 in main (argc=1, argv=0x7fff160bd2f8, envp=0x7fff160bd308) at ../../dix/main.c:170 | 21:39 |
| Sarvatt | looks like it's dying in the AbortServer(); call in FatalError, AbortServer() just doing SigAbortServer(0) and the old AbortServer() was renamed to SigAbortServer() | 21:41 |
| * Sarvatt is messing around with the rethrow signals patch | 21:41 | |
| bryce2 | cool | 21:41 |
| bryce2 | sort of. The old AbortServer() is still there and still works as it did before, it just calls SigAbortServer with a 0 argument | 21:42 |
| bryce2 | this way, the API doesn't break | 21:43 |
| Sarvatt | so its going to FatalError, prints the FatalError messages, gets down to AbortServer() which calls SigAbortServer(0), thats supposed to call SigAbortDDX(0) which is in hw/xfree86/common/xf86Init.c why doesn't that show up in the backtrace? it's getting called because ddxSigGiveUp: Closing log is in the output and thats an ErrorF string in that function | 22:09 |
| Sarvatt | http://paste.ubuntu.com/367125/ | 22:10 |
| bryce2 | yeah I suspect printing to the log after the log has been closed might be the source of the crash bug | 22:11 |
| Sarvatt | the trash after ddxSigGiveUp and before the first backtrace is gone when I disable 168_glibc_trace_to_stderr.patch | 22:11 |
| bryce2 | so if you spot anywhere that it is calling ErrorF after the point where the log has been closed, we may want to try disabling those ErrorF's | 22:11 |
| Sarvatt | xf86CloseConsole(); | 22:13 |
| Sarvatt | + ErrorF (" ddxSigGiveUp: Closing log\n"); | 22:13 |
| Sarvatt | xf86CloseLog(); | 22:13 |
| Sarvatt | maybe move the ErrorF up above the xf86CloseConsole()? | 22:13 |
| bryce2 | Sarvatt, try commenting that out | 22:14 |
| bryce2 | in the patch change the line to + /* ErrorF (" ddxSigGiveUp: Closing log\n"); */ | 22:14 |
| Sarvatt | yeah thats building now | 22:18 |
| mdeslaur | so, when is nouveau kms supposed to hit the lucid kernel? | 22:37 |
| Sarvatt | darn, didn't fix it | 22:38 |
| Sarvatt | dont think its ever going to hit the lucid kernel mdeslaur, they are working on making a linux-backports-modules-nouveau though | 22:39 |
| mdeslaur | ah, that would do...I want to try nouveau again, but it only suspends with kms support, AFAIK | 22:39 |
| bryce2 | mdeslaur, I have it installed and running with kms | 22:40 |
| bryce2 | mdeslaur, I've a desktop box here in the desktop room hooked up to the projector if you want to tinker | 22:40 |
| mdeslaur | bryce2: you have a special kernel? | 22:41 |
| bryce2 | mdeslaur, yeah the l-b-m ppa sarvatt mentioned | 22:41 |
| Sarvatt | mdeslaur: it only works with KMS period right now, did you have to disable KMS to use nouveau before? | 22:41 |
| bryce2 | it's from apw's ppa | 22:41 |
| Sarvatt | they ripped out non-kms support | 22:41 |
| mdeslaur | Sarvatt: oh! I didn't know that... | 22:41 |
| mdeslaur | bryce2: ah, cool, thanks | 22:41 |
| Sarvatt | mdeslaur: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau | 22:43 |
| mdeslaur | thanks, I'll try that next week | 22:44 |
| Sarvatt | can't say I feel comfortable with all the changes to accomidate l-b-m instead of just using nouveau-kernel-source and building it locally with dkms, i dont think either will coexist with radeon/intel either way and the xserver changes only really make sense if nouveau is there by default which it isnt with lbm | 22:46 |
| Sarvatt | people wont be able to use updated kernels that have nouveau with the libdrm changes to accomidate lbm-nouveau too | 22:49 |
| mdeslaur | ouch | 22:50 |
| Sarvatt | no luck commenting out that ddxSigGiveUp ErrorF. one thing I noticed is with the patch and X -verbose its got an extra line (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor | 22:52 |
| Sarvatt | (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor | 22:52 |
| Sarvatt | (WW) xf86OpenConsole: VT_GETSTATE failed: Bad file descriptor | 22:52 |
| Sarvatt | without the patch I just see (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor | 22:53 |
| Sarvatt | (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor | 22:53 |
| Sarvatt | its reopening the console after xf86CloseConsole and before xf86CloseLog because it said that before the ddxSigGiveUp ErrorF that was between them | 22:56 |
| bryce2 | hmm | 22:56 |
| Sarvatt | hmm 121_only_switch_vt_when_active.diff | 23:02 |
| Sarvatt | yeah that xf86OpenConsole is from 121_only_switch_vt_when_active.diff which I had dropped in the xserver i'm using on this machine and not the other, dropped that patch and it still crashes the same though. darn red herrings | 23:22 |
| bryce2 | heh | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!