| mnemo | Sarvatt: btw, you should get some sleep.. :) | 00:00 |
|---|---|---|
| maxb | Can anyone point me at any documentation which explains how X gets its xkb_layout these days? Since today's hal upload ceasing to deal with keymaps in favour of leaving it to udev-extras, my X no longer picks up the "gb" layout for my system and defaults to "us" instead | 00:08 |
| Sarvatt | i'd be interested in knowing that too, i have to customize my layout because i use a gateway bios from a clone of this aspire one and i can't just change the acer hal fdi to match Gateway anymore | 00:10 |
| maxb | Why a Gateway BIOS in an Acer, ooi? | 00:11 |
| Sarvatt | acer limits the number of backlight brightness levels in their bios | 00:11 |
| maxb | ah, ues | 00:12 |
| maxb | *yes | 00:12 |
| Sarvatt | gateway one is the exact same thing minus that part because they never used the panels with flickering problems at the lowest levels | 00:12 |
| Sarvatt | i get 30 minutes more battery life with the gateway one :d | 00:12 |
| maxb | I have a flickery one unfortunately | 00:12 |
| maxb | Though I'd still like to have the option of the lower brightnesses | 00:13 |
| Sarvatt | i do too, otherwise I would use the acer bios because it only blacklists the flickery one from the lowest levels | 00:13 |
| Sarvatt | flickering during hdd access is a small price to pay for 30 minutes more battery life :d | 00:13 |
| Sarvatt | http://macles.blogspot.com/2009/03/brightness-table.html#comments | 00:14 |
| Sarvatt | oh good, looks like libdrm is getting updated to 2.4.10 and adding drm_intel_bo_disable_reuse that might fix that swapping/font corruption problem | 00:30 |
| bryce | mnemo: btw, there's a technique I use in launchpad when asking questions - if the bug is already set to 'Incomplete', I move it to 'New', and then 'Incomplete' after asking my question. This resets the "without reply" toggle on the bug | 01:12 |
| bryce | mnemo: it is a hassle, but by doing this it makes it easier to do a search for "Incomplete with response" bugs to see ones that the reporter (or some me-tooer) has answered | 01:12 |
| bryce | unfortunately launchpad is not smart enough to realize when us triagers comment on an Incomplete bug, it doesn't count as a "response" :-) | 01:13 |
| Sarvatt | bryce: I build -intel 2.7.1 final release here using your 2.7.0 debian instead of merging debian's like we do on edgers incase you want to copy it to x-updates https://launchpad.net/~sarvatt/+archive/sarvatt-graphics | 02:31 |
| Sarvatt | so it's got all of the patches except 119_drm_bo_unreference_needs_null.patch which is already in 2.7.1 | 02:32 |
| bryce | Sarvatt: ah, excellent thanks | 03:02 |
| bryce | probably I should do the merge using the official tarball | 03:08 |
| Sarvatt | oops, forgot to change the commit id it was based on in the changelog. ah well, wanted to rebuild it against the new 2.4.10 drm anyway | 03:14 |
| bryce | ok, 2.7.1 packaged and in process of building: https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa | 03:55 |
| bryce | once it's built and a couple people verify it's good to go, I'll move it to x-updates | 03:55 |
| tjaalton | upgraded to karmic, now reboot.. | 09:13 |
| tjaalton | hmm, wrong layout | 09:16 |
| Sarvatt | have you guys considered backporting http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=63cde0ea0e2bc85005136c353c363777488804d2 to jaunty's mesa? | 09:25 |
| Sarvatt | re: bug 359392 | 09:25 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/359392/+text) | 09:25 |
| tjaalton | haven't seen it before, but looks sane | 09:26 |
| Sarvatt | i was just looking over https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392 again and have seen they backported that patch to all the branches | 09:28 |
| ubottu | Ubuntu bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] | 09:29 |
| tjaalton | it's just a matter of workflow management | 09:30 |
| tjaalton | I'd like to put these in a git branch (ubuntu-jaunty for instance) where such fixes can be staged and uploaded to a ppa or -proposed | 09:31 |
| jpds | Sarvatt: No, this was a hardy -> intrepid -> jaunty upgrade. | 13:52 |
| apw | bryce, hey ... | 15:38 |
| apw | it seems that your test version of x does seem to have changed behaviour on mtrr for the better, but it still seems to remove the mtrr ... | 15:38 |
| apw | 2:2.6.3-0ubuntu9.3~bug314928~2 is installed | 15:39 |
| apw | by w | 15:40 |
| bryce | apw, ok, that's good... is there removed mtrr's causing further problems I take it? | 17:43 |
| apw | it seems to still badly interact with the kernel, as in it still removes the mtrr on exit | 17:44 |
| apw | i see this both for logout and for guess session exit | 17:44 |
| apw | it is better in that for a rather more invasive kernel patch which adds and removes the mtrr on vt switch the mtrr does survive with your new xserver. but the viable patch to add and remove mtrr at load/unload still gets broken by it | 17:45 |
| bryce | hrm | 17:47 |
| apw | [ 203.861744] Pid: 3553, comm: Xorg Tainted: G W 2.6.28-13-generic #44~ | 17:49 |
| apw | lp314928apw5 | 17:49 |
| apw | that is the process which is calling the ioctl ... | 17:50 |
| bryce | what is the "viable patch"? | 17:51 |
| apw | the clean backport of upstream behavour is to add and remove the mtrr at load/unload time. the patch matching the further normal semantics is the one i am looking at as viable | 17:51 |
| bryce | ahh | 17:52 |
| apw | the other was a bodge i did to see if i could get round things the xserver was doing, doing it at enter/leave vt time. but that seemed to get hurt by the xserver also fiddling at VT switch time | 17:52 |
| bryce | ok, so either there is another bit of code removing mtrr's, or the code I if'd still gets called in some circumstances | 17:52 |
| apw | your change i _think_ has removed the vt switch fiddle, but perhaps not the exit fiddle | 17:52 |
| apw | yeah something like that | 17:53 |
| bryce | would it help for me to add some debug comments on each call so you can sort out which is being called? or have you been able to sort that out via gdb? | 17:53 |
| apw | i've been tracing it with kernel debug thus far | 17:53 |
| bryce | (or maybe it'd be obvious if I skim through the code for similar mtrr stuff) | 17:53 |
| apw | but we can try it pretty easy as it exhibits on guess sessions too, so its not sooo iintrusive to test | 17:54 |
| hyperair | anyone familiar with the issue of intel's gpu driver leaking memory like a bloody sieve? | 17:55 |
| apw | which version? kernel memory? what workload? many of us are using intel successfully | 17:56 |
| bryce | apw: hmm, the driver seems to call i830_fixup_mtrrs in just the one place | 17:56 |
| bryce | apw: there's mtrr code in the xserver which I wonder about | 17:56 |
| apw | in the generic part you mean? | 17:56 |
| bryce | yeah | 17:57 |
| bryce | I grepped "mtrr" in the xserver core and it spewed a bunch of stuff, but then jbarnes pointed us at this patch so I ignored it. But now I wonder if it's worth looking at. | 17:57 |
| jbarnes | bryce: was my patch not sufficient? | 17:58 |
| jbarnes | I think with libpciaccess the server won't mess with mtrrs anymore | 17:58 |
| bryce | jbarnes: no apw says he's still getting mtrr's removed, although it's considerably better | 17:59 |
| jbarnes | hm | 17:59 |
| bryce | apw: do you get any messages "Removing bad MTRR range" or "Failed to remove bad MTRR range"? | 17:59 |
| apw | yeah its definatly happening less often. i beleive it was happening at vt switch into another x-server and is not now | 17:59 |
| apw | bryce, in Xorg.0.log ? | 17:59 |
| bryce | yes | 18:00 |
| apw | nothing about mtrr at all in there | 18:00 |
| bryce | hmm | 18:00 |
| bryce | well, from what I understand of the code, if the -intel driver is removing MTRRs it should be printing at least one of those messages | 18:00 |
| bryce | so if it's not -intel, and if the xserver isn't messing with mtrrs anymore... could it be something besides X doing it? | 18:01 |
| jbarnes | I think the mtrr code removes any ranges set by the process when it exits | 18:03 |
| jbarnes | iirc | 18:04 |
| bryce | by mtrr_remove_offending() ? | 18:04 |
| jbarnes | I was thinking the kernel | 18:04 |
| bryce | ah | 18:04 |
| jbarnes | yeah, I *think* when the mtrr file gets closed or the process exits its additions will be removed | 18:06 |
| jbarnes | unless some other process added them too | 18:06 |
| apw | jbarnes, i am seeing an explicit removals occuring via an ioctl on the mtrr control file, i added a warning to the kernel and it logged the Xorg process as culprit | 18:08 |
| jbarnes | oh ok | 18:08 |
| jbarnes | with the intel driver huh? | 18:08 |
| jbarnes | the only place in the server that should hit that path is xf86MapVidMem, which we don't use anymore afaik | 18:11 |
| apw | perhaps its time for a version with some explicit debug in that routine to tell us if it is called | 18:15 |
| apw | just in case somehow my machine is mad and still using it somehow | 18:15 |
| apw | bryce, so what do you think? perhaps a bit of debug in userspace might help here? am able to test here | 18:30 |
| jbarnes | apw: if you have debug symbols, gdb could help too | 18:30 |
| jbarnes | set a breakpoint on the setWC callback and backtrace | 18:30 |
| jbarnes | or in one of the mtrr fns | 18:30 |
| apw | jbarnes, ok i think bryce did make some dbg ones | 18:31 |
| bryce | yep, you'll want -dbg's of both -intel and xorg-server | 18:31 |
| apw | hrm i think i only have the -intel one | 18:32 |
| bryce | xserver-xorg-core-dbg specifically | 18:32 |
| mnemo | bryce: -intel only prints those two messages to xorg.log if it tried to delete the mtrr but the operation failed | 18:50 |
| mnemo | well no sry.. the first one should have been in the xorg.log | 18:51 |
| mnemo | nevermind | 18:51 |
| bryce | right | 18:51 |
| tjaalton | huh, Xorg uses 100% cpu but everything seems to work | 18:56 |
| mnemo | tjaalton: on what gfx card? and what is it doing if you sample stacks with gdb? | 18:57 |
| tjaalton | mnemo: intel, karmic | 18:58 |
| tjaalton | can't use gdb since there's no other machine to ssh from | 18:58 |
| tjaalton | but I remember hearing something similar recently | 18:58 |
| mnemo | i've a bunch of -ati bugs for jaunty with constant 50% or 100% cpu (i guess the 50% cpu reports are for dual core users etc) | 18:59 |
| mikaelhm | mnemo, hi. Remember me:-) | 19:01 |
| mnemo | mikaelhm: yea, did you find a proper stacktrace yet? | 19:01 |
| mikaelhm | nop, it just happend again (first time today) | 19:01 |
| mikaelhm | there is nothing in the log | 19:01 |
| mikaelhm | but. | 19:02 |
| mikaelhm | When i look in the dmesg | 19:02 |
| mikaelhm | I see this http://paste.ubuntu.com/171815/ | 19:03 |
| mikaelhm | and when i booted up I got this apport bug thingy-dingy | 19:04 |
| mnemo | yea thats like another bug probably | 19:05 |
| mikaelhm | Sorry the program "firefox" closed unexpe | 19:05 |
| mikaelhm | it said... | 19:05 |
| mnemo | mikaelhm: whenever something crashes, just send bug reports using apport.. doesnt matter if its pidgin or firefox or whatever.. they can often be useful for us | 19:06 |
| mnemo | mikaelhm: also, in some rare cases gfx driver bugs can also show up as application crashes | 19:06 |
| mikaelhm | should it be a new bug or related? I'm new to bugreporting. | 19:06 |
| mnemo | when it's a new program, always file a new bug | 19:07 |
| mikaelhm | oki | 19:07 |
| mikaelhm | it says, firefox chrashed in SIGSEGV in pthreaths_mutex_lock | 19:07 |
| mikaelhm | but i'll report it. | 19:08 |
| mnemo | please do | 19:08 |
| mikaelhm | Could not upload report data to crash database: | 19:09 |
| mikaelhm | <urlopen error The read operation timed out> | 19:09 |
| mnemo | that's because canonical cant run their servers properly :( | 19:10 |
| mikaelhm | I could only cancel it | 19:10 |
| mikaelhm | :-( | 19:10 |
| mnemo | it happens quite often with firefox because the debug dumps are so big that the server times out... i've filed a bug about it to the LP team but they havn't fix it yet | 19:10 |
| mnemo | this happens only for firefox crashes though | 19:10 |
| mikaelhm | ok | 19:10 |
| mnemo | so for those you might want to consider checking the checkbox "reduced report" (and not "complete") because that one works and it still gets us a stacktrace | 19:11 |
| mikaelhm | but how to report then? just manually,, or? can i get apport again? | 19:11 |
| mnemo | mikaelhm: if you want to re-submit the firefox that just happened you can look in /var/crash and then double click the .crash file that has firefox in the name (and select "reduce report" this time) | 19:11 |
| mikaelhm | cannot select reduce report | 19:13 |
| mnemo | strange.. why not? is that option grayed out? | 19:13 |
| mikaelhm | there is no option. | 19:13 |
| mikaelhm | damnit | 19:14 |
| mikaelhm | about 95% done | 19:14 |
| mikaelhm | there is only a ratio butten for complete report (106mb recommended) but its grayed out | 19:15 |
| mnemo | mikaelhm: when you click the .crash file you should see this --> http://temp.minimum.se/apport.png | 19:16 |
| mnemo | if you cant select "reduced report" then you probably can't report this bug unfortunatly.. :( | 19:17 |
| mikaelhm | i only see this http://i-dyllen.dk/apport.png | 19:20 |
| mnemo | ah, strange.. ok so then this bug cannot be submitted | 19:22 |
| mikaelhm | mnemo, cannot or might not, if i try several times will it work, i dont no the report bug, | 19:23 |
| mnemo | at least i've never managed to submit one of those, but I didn't try a lot of times.. | 19:24 |
| mnemo | the bug that prevents this bug from being submitted is this bug: https://bugs.launchpad.net/malone/+bug/357907 | 19:24 |
| ubottu | Ubuntu bug 357907 in malone "+filebug is timing out when processing large blobs" [Undecided,Confirmed] | 19:24 |
| mikaelhm | I think I managed it. | 19:25 |
| mikaelhm | no, this time the webpage gave me a timeout error | 19:27 |
| mikaelhm | https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+filebug/fuAN2CdKMInjhg7HGPiB7uPlNkV?field.title=firefox+crashed+with+SIGSEGV+in+pthread_mutex_lock() | 19:27 |
| tjaalton | ok, got a backtrace from my hung xserver | 19:31 |
| tjaalton | well, not hung but cpu-hungry | 19:31 |
| tjaalton | hmm backtrace wont do, need to use a profiler | 19:33 |
| mnemo | tjaalton: so what did the backtrace say? | 19:35 |
| tjaalton | mnemo: nothing of interest, because the server works | 19:36 |
| tjaalton | something is just eating resources | 19:36 |
| mnemo | WaitForSomething ? | 19:37 |
| tjaalton | yes | 19:37 |
| mnemo | i guess "info threads" also says just one thread? | 19:38 |
| mnemo | afaik X is always single threaded | 19:38 |
| tjaalton | sigh, profiling made easy.. not! | 19:42 |
| mnemo | which one did you use? | 19:42 |
| tjaalton | trying oprofile | 19:42 |
| mnemo | i've never tried it myself but I heard they use sysprof in #intel-gfx sometimes | 19:42 |
| tjaalton | ok, trying it | 19:44 |
| tjaalton | "in kernel" | 19:46 |
| tjaalton | right, thanks | 19:46 |
| tjaalton | not very helpful | 19:46 |
| mnemo | sysprof can split that up as well I think | 19:46 |
| mnemo | but then you need kernel debug symbols installed first | 19:46 |
| tjaalton | sigh^2 | 19:47 |
| tjaalton | don't think they're apt-gettable | 19:48 |
| tjaalton | ah, found it | 19:51 |
| === jldugger is now known as pwnguin | ||
| mnemo | tjaalton: cool, what package was it? | 19:53 |
| tjaalton | mnemo: no I mean found the ddebs | 19:53 |
| mnemo | tjaalton: where did you get them? i'd like to try it as well.. | 19:55 |
| tjaalton | ddebs.ubuntu.com | 19:55 |
| tjaalton | apt-get doesn't seem to work though | 19:59 |
| mnemo | tjaalton: was that a replacement kernel with debug info or was it added debug symbols for the existing normal package? (i.e. like how -dbgsym works) | 20:00 |
| tjaalton | just the symbols | 20:00 |
| mnemo | they dont even seem to have symbols the stock jaunty kernel in there... i just find 2.6.28-12 in http://ddebs.ubuntu.com/pool/main/l/linux/ but im still on -11 (maybe -12 is in proposed?) | 20:05 |
| tjaalton | I dont think sysprof is meant for debugging the kernel | 20:10 |
| tjaalton | it still doesn't split it up | 20:10 |
| tjaalton | great, opreport doesn't work | 20:18 |
| tjaalton | needs a rebuild | 20:19 |
| mnemo | tjaalton: did oprofile give you anything yet? | 20:30 |
| tjaalton | mnemo: not yet | 20:38 |
| tjaalton | need to learn how to use it first | 20:39 |
| tjaalton | bah, opreport doesn't work, and doesn't build | 20:42 |
| tjaalton | so that's it then | 20:42 |
| tjaalton | huh, I can't suspend.. grr | 21:06 |
| Sarvatt | i just started getting this too yesterday tjaalton, are you on karmic too? | 21:13 |
| tjaalton | Sarvatt: yes | 21:13 |
| tjaalton | the hotkeys don't work, and the applet only has logout | 21:13 |
| Sarvatt | systems too darn slow to do anything when it happens, takes about 3 minutes for the VT to come up but I'm on a slow atom cpu :D | 21:13 |
| Sarvatt | yep no suspend/hibernate on my faster-user-switch applet either, hotkeys are screwy too since the change to udev-extras | 21:21 |
| Sarvatt | been a rough last few days for karmic | 21:21 |
| Sarvatt | i get a devicekit battery fully charged notification every time i plug ac in too no matter the charge level | 21:22 |
| mnemo | bryce: ping? | 23:10 |
| mnemo | i was going to ask you if you've seen any like this before? --> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/376220 | 23:13 |
| ubottu | Ubuntu bug 376220 in mesa "package libglu1-mesa 7.4-0ubuntu3.1 failed to install/upgrade: package libglu1-mesa is already installed and configured" [Undecided,New] | 23:13 |
| bryce | mm | 23:13 |
| bryce | looking | 23:13 |
| mnemo | its my mesa SRU so im a bit paranoid | 23:13 |
| mnemo | its probably nothing | 23:13 |
| mnemo | it was copied from proposed to updates today | 23:14 |
| bryce | guess would be that it's a foss-vs-proprietary issue | 23:14 |
| mnemo | how so? | 23:14 |
| bryce | wait, no | 23:14 |
| mnemo | the log doesnt actually show any error for mesa so I was thinking it might be a bug in apport | 23:14 |
| mnemo | because those ttf fonts seem to fail | 23:15 |
| mnemo | and maybe then it gets the package wrong? | 23:15 |
| bryce | 2009-05-08 11:00:47 ERROR -1: Malformed status line. | 23:15 |
| bryce | maybe an error in sources.list? | 23:16 |
| mnemo | i think the malformed status thing could be a bad reply from sourceforge when its wgetting the proprietary fonts | 23:16 |
| bryce | ok | 23:16 |
| mnemo | my other theory was that maybe he tried the mesa upgrade from proposed and so thats why he already had it | 23:17 |
| mnemo | but if apport triggers on that then i guess i should have seen something like it before | 23:17 |
| mnemo | anyway, its probably nothing | 23:17 |
| bryce | yeah not sure | 23:17 |
| mnemo | im going to sleep now so.. | 23:18 |
| mnemo | i hope this doesnt blow up overnight :) | 23:18 |
| bryce | night mnemo :-) | 23:18 |
| mnemo | nn bye | 23:18 |
| bryce | tjaalton: do you know if we need mdetect for anything anymore? Isn't that no longer needed with dexconf, etc.? | 23:45 |
| bryce | if not, we can just sync -vmmouse from Debian I think. | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
