| hyperair | maco: i don't think that the wireless driver is related to the gpu driver. | 00:09 |
|---|---|---|
| hyperair | 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:10 |
| maco | 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:12 |
| hyperair | O_o? | 00:15 |
| maco | well they both wanted to use 100% of CPU and kmail wanted 40% | 00:15 |
| maco | with a dual core, they can only get 200% | 00:15 |
| hyperair | kmail is an x client. | 00:15 |
| hyperair | but seriously, this isn't within ubuntu-x's field | 00:15 |
| hyperair | you should be complaining to the kde people | 00:16 |
| hyperair | ubuntu-x only handles X itself, and its drivers. | 00:16 |
| maco | *sigh* but the Xorg process was using 100% and then 58% later | 00:16 |
| maco | 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 |
| hyperair | O_o sounds like you seriously got your system screwed up | 00:16 |
| maco | i just installed it like 3 weeks ago | 00:16 |
| hyperair | but there are X clients that can cause Xorg's CPU usage to rise dramatically | 00:17 |
| maco | but kmail and Xorg are listed separately in top | 00:17 |
| hyperair | yes they are | 00:17 |
| hyperair | they are different processes | 00:17 |
| maco | and Xorg was using quite a lot more than kmail was | 00:17 |
| hyperair | but kmail is an X client | 00:17 |
| * hyperair facepalm | 00:17 | |
| hyperair | will you listen? | 00:17 |
| hyperair | quit kmail and see | 00:17 |
| maco | but kmail doesnt count into it! | 00:17 |
| hyperair | for all you know, kmail's causing X's CPU usage to rise | 00:18 |
| maco | it is not | 00:18 |
| hyperair | X clients *communicate* with the X server. | 00:18 |
| maco | xorg's usage has gone down since then | 00:18 |
| maco | Xorg process is down to 4% now (yay) and kmail is still 31% | 00:18 |
| hyperair | well next time identify the faulty X client | 00:18 |
| maco | so Xorg's CPU usage in top isnt just adding up all the X clients' usage %s | 00:18 |
| maco | im running all the same things i was runnign before | 00:18 |
| hyperair | ...you seriously aren't listening. | 00:19 |
| hyperair | Xorg is a *server*. Kmail and other applications are X *clients* | 00:19 |
| hyperair | when a client bombards a server with requests, what happens? | 00:19 |
| hyperair | the server takes more CPU. | 00:19 |
| hyperair | it's as simple as that. | 00:19 |
| hyperair | they are separate processes! | 00:19 |
| hyperair | hell they could even be on different computers! | 00:20 |
| maco | so how do i find out which client is sending all those requests? | 00:20 |
| maco | the same apps have been running the entire time. | 00:20 |
| hyperair | dunno. quit the highest cpu using client and see | 00:20 |
| hyperair | could be a buggy client that suddenly screwed up | 00:20 |
| maco | if an application is on a different workspace, does it still talk to X? it doesnt need to be drawn... | 00:21 |
| hyperair | yes, it does. | 00:22 |
| maco | 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 |
| maco | oh and the terminal is on a different workspace | 00:25 |
| maco | a not-visible one | 00:25 |
| hyperair | it would probably be telling X that there are updates | 00:27 |
| hyperair | but i don't think it would be rendered until it's unobscured | 00:27 |
| maco | hmm so could that be why my cpu usage goes up when im remote compiling? | 00:27 |
| hyperair | well it might rise a little, but very little. | 00:28 |
| hyperair | you should probably just test quitting the clients one by one the next time it happens | 00:29 |
| maco | ok | 00:30 |
| bryce_ | hyperair is right | 00:38 |
| maco | 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 |
| bryce_ | 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 |
| maco | how many *top apps are there? | 00:39 |
| maco | [h]top, powertop, and iotop were the ones i knew | 00:40 |
| bryce_ | there's like a dozen | 00:40 |
| bryce_ | htop, vtop, ptop, itop, atop, mtop, ntop, top, xrestop... probably lots more. 'stop' ;-) | 00:40 |
| bryce_ | maco, anyway, it's a common point of confusion, and I've documented it at http://wiki.ubuntu.com/X/Troubleshooting/ | 00:41 |
| maco | ok | 00:42 |
| maco | thanksguys | 00:42 |
| bryce_ | 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 | 01:57 |
| ScottK | bryce_: Give away the hard ones.... | 03:40 |
| bryce_ | ScottK, I don't want to scare him off! ;-) | 04:35 |
| Starks | bryce, what do you think of this? http://ubuntuforums.org/showpost.php?p=7773647&postcount=13 | 14:10 |
| Starks | would the license allow this? | 14:10 |
| tseliot | Starks: the patch acts upon the open part of the driver therefore I don't that patch is a problem | 14:14 |
| Starks | can karmic ship with it? | 14:14 |
| tseliot | poulsbo was only made available in a PPA | 14:16 |
| tseliot | Ubuntu doesn't have poulsbo in its repositories | 14:17 |
| tseliot | as poulsbo uses an old version of libdrm | 14:17 |
| tseliot | a PPA would be the right place for that | 14:18 |
| ScottK | tseliot: PPA is only allowed for free software. | 14:22 |
| Starks | ppa doesn't allow binary blobs? | 14:23 |
| Starks | since when? | 14:23 |
| tseliot | 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 |
| ScottK | tseliot: Read the PPA terms of service. | 14:24 |
| jcristau | maybe canonical gets an exception | 14:24 |
| ScottK | It probably does as there are commercial exceptions to the TOS. | 14:25 |
| tseliot | it could be | 14:25 |
| Starks | does a driver have to be sanctioned in order to be included? | 14:26 |
| Starks | also, even if intel and powervr had up to date psb drivers, would they be included by default? | 14:26 |
| Starks | or would it be restricted? | 14:27 |
| tseliot | restricted | 14:29 |
| tseliot | not that it's so simple | 14:30 |
| Starks | poulsbo's successor is likely to be another powervr-created monster. | 14:42 |
| jcristau | sigh. they didn't learn anything from the psb fiasco? | 14:43 |
| Starks | dunno. | 14:51 |
| Starks | it was a decent chip spec-wise | 14:52 |
| Starks | drivers were shit though. | 14:52 |
| Starks | windows was no exception. | 14:52 |
| === ripps_ is now known as ripps | ||
| === michael_ is now known as michaellarabel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!