[00:09] maco: i don't think that the wireless driver is related to the gpu driver. [00:10] maco: rather, i've noticed your issue on the .31 kernels, specifically whenever the system begins running out of memory, or during periods of very high I/O activity [00:12] oh i dont think the drivers are touching each other, just that X was going nuts until the wireless wanted so much CPU that they couldnt both have what they wanted [00:15] O_o? [00:15] well they both wanted to use 100% of CPU and kmail wanted 40% [00:15] with a dual core, they can only get 200% [00:15] kmail is an x client. [00:15] but seriously, this isn't within ubuntu-x's field [00:16] you should be complaining to the kde people [00:16] ubuntu-x only handles X itself, and its drivers. [00:16] *sigh* but the Xorg process was using 100% and then 58% later [00:16] i already talked to rtg about the wireless thing, im just concerned about why Xorg is using my entire CPU when there's not even compositing happening [00:16] O_o sounds like you seriously got your system screwed up [00:16] i just installed it like 3 weeks ago [00:17] but there are X clients that can cause Xorg's CPU usage to rise dramatically [00:17] but kmail and Xorg are listed separately in top [00:17] yes they are [00:17] they are different processes [00:17] and Xorg was using quite a lot more than kmail was [00:17] but kmail is an X client [00:17] * hyperair facepalm [00:17] will you listen? [00:17] quit kmail and see [00:17] but kmail doesnt count into it! [00:18] for all you know, kmail's causing X's CPU usage to rise [00:18] it is not [00:18] X clients *communicate* with the X server. [00:18] xorg's usage has gone down since then [00:18] Xorg process is down to 4% now (yay) and kmail is still 31% [00:18] well next time identify the faulty X client [00:18] so Xorg's CPU usage in top isnt just adding up all the X clients' usage %s [00:18] im running all the same things i was runnign before [00:19] ...you seriously aren't listening. [00:19] Xorg is a *server*. Kmail and other applications are X *clients* [00:19] when a client bombards a server with requests, what happens? [00:19] the server takes more CPU. [00:19] it's as simple as that. [00:19] they are separate processes! [00:20] hell they could even be on different computers! [00:20] so how do i find out which client is sending all those requests? [00:20] the same apps have been running the entire time. [00:20] dunno. quit the highest cpu using client and see [00:20] could be a buggy client that suddenly screwed up [00:21] if an application is on a different workspace, does it still talk to X? it doesnt need to be drawn... [00:22] yes, it does. [00:25] so if a terminal has an ssh session and that session is compiling stuff, X still would be requested to render all that compiler-spew? [00:25] oh and the terminal is on a different workspace [00:25] a not-visible one [00:27] it would probably be telling X that there are updates [00:27] but i don't think it would be rendered until it's unobscured [00:27] hmm so could that be why my cpu usage goes up when im remote compiling? [00:28] well it might rise a little, but very little. [00:29] you should probably just test quitting the clients one by one the next time it happens [00:30] ok [00:38] hyperair is right [00:39] im sorry i got confused before. the server & client separation didnt occur to me. i thought it was a parent/child process thing he was talking aout [00:39] maco, xrestop can also give some clues about what apps might be using X, but it looks only at resource memory usage so isn't a perfect indicator [00:39] how many *top apps are there? [00:40] [h]top, powertop, and iotop were the ones i knew [00:40] there's like a dozen [00:40] htop, vtop, ptop, itop, atop, mtop, ntop, top, xrestop... probably lots more. 'stop' ;-) [00:41] maco, anyway, it's a common point of confusion, and I've documented it at http://wiki.ubuntu.com/X/Troubleshooting/ [00:42] ok [00:42] thanksguys [01:57] Sarvatt, if you're interested in scoring some merges for your motu app, I've marked some packages currently needing merged: http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html [03:40] bryce_: Give away the hard ones.... [04:35] ScottK, I don't want to scare him off! ;-) [14:10] bryce, what do you think of this? http://ubuntuforums.org/showpost.php?p=7773647&postcount=13 [14:10] would the license allow this? [14:14] Starks: the patch acts upon the open part of the driver therefore I don't that patch is a problem [14:14] can karmic ship with it? [14:16] poulsbo was only made available in a PPA [14:17] Ubuntu doesn't have poulsbo in its repositories [14:17] as poulsbo uses an old version of libdrm [14:18] a PPA would be the right place for that [14:22] tseliot: PPA is only allowed for free software. [14:23] ppa doesn't allow binary blobs? [14:23] since when? [14:24] ScottK: I know that nvidia is also made available in PPAs and there's this PPA with psb too: https://launchpad.net/~ubuntu-mobile/+archive/ppa [14:24] tseliot: Read the PPA terms of service. [14:24] maybe canonical gets an exception [14:25] It probably does as there are commercial exceptions to the TOS. [14:25] it could be [14:26] does a driver have to be sanctioned in order to be included? [14:26] also, even if intel and powervr had up to date psb drivers, would they be included by default? [14:27] or would it be restricted? [14:29] restricted [14:30] not that it's so simple [14:42] poulsbo's successor is likely to be another powervr-created monster. [14:43] sigh. they didn't learn anything from the psb fiasco? [14:51] dunno. [14:52] it was a decent chip spec-wise [14:52] drivers were shit though. [14:52] windows was no exception. === ripps_ is now known as ripps === michael_ is now known as michaellarabel