Quick note - per my testing, Beta RC3 desktop spin passes the validation testing for Beta, with a clean slate except for https://bugzilla.redhat.com/show_bug.cgi?id=636229 which I noted in passing. Great job!
testing from others to confirm is still welcome! I'm not always right =)
People,
On 2010-09-22 09:13, Adam Williamson wrote:
Quick note - per my testing, Beta RC3 desktop spin passes the validation testing for Beta, with a clean slate except for https://bugzilla.redhat.com/show_bug.cgi?id=636229 which I noted in passing. Great job!
testing from others to confirm is still welcome! I'm not always right =)
I find it boots OK with qemu and from a USB stick and, in fact, seems to install OK to a HD but when running the resulting install, I find it is deadly slow and unusable (I am using F13 on the same machine - a Gateway LT30 netbook - with no problems).
Regards,
Phil.
On Tue, Sep 21, 2010 at 11:29 PM, Philip Rhoades phil@pricom.com.au wrote: <SNIP>
I find it boots OK with qemu and from a USB stick and, in fact, seems to install OK to a HD but when running the resulting install, I find it is deadly slow and unusable (I am using F13 on the same machine - a Gateway LT30 netbook - with no problems).
<SNIP>
Are you noticing any outlier processes eating into system resources when running top? or maybe something in dmesg or /var/log/messages that might elude to the cause of the slow down ... I've got the XFCE spin running here without any issues. I imagine this is a bug of some sort, just need to track it down :)
-AdamM
On Wed, 2010-09-22 at 14:29 +1000, Philip Rhoades wrote:
People,
On 2010-09-22 09:13, Adam Williamson wrote:
Quick note - per my testing, Beta RC3 desktop spin passes the validation testing for Beta, with a clean slate except for https://bugzilla.redhat.com/show_bug.cgi?id=636229 which I noted in passing. Great job!
testing from others to confirm is still welcome! I'm not always right =)
I find it boots OK with qemu and from a USB stick and, in fact, seems to install OK to a HD but when running the resulting install, I find it is deadly slow and unusable (I am using F13 on the same machine - a Gateway LT30 netbook - with no problems).
Like OtherAdam, I can't reproduce; I did all that validation testing from an installed copy of the live image (I installed it to a USB stick, in fact, on a Dell Inspiron 6400, so it's not exactly a fast environment, but it ran fine).
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Guys,
On 2010-09-22 17:58, Adam Williamson wrote:
On Wed, 2010-09-22 at 14:29 +1000, Philip Rhoades wrote:
People,
On 2010-09-22 09:13, Adam Williamson wrote:
Quick note - per my testing, Beta RC3 desktop spin passes the validation testing for Beta, with a clean slate except for https://bugzilla.redhat.com/show_bug.cgi?id=636229 which I noted in passing. Great job!
testing from others to confirm is still welcome! I'm not always right =)
I find it boots OK with qemu and from a USB stick and, in fact, seems to install OK to a HD but when running the resulting install, I find it is deadly slow and unusable (I am using F13 on the same machine - a Gateway LT30 netbook - with no problems).
Like OtherAdam, I can't reproduce; I did all that validation testing from an installed copy of the live image (I installed it to a USB stick, in fact, on a Dell Inspiron 6400, so it's not exactly a fast environment, but it ran fine).
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Thanks,
Phil.
On Wed, 2010-09-22 at 20:29 +1000, Philip Rhoades wrote:
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Check /var/log/Xorg.0.log for incriminating messages.
Adam,
On 2010-09-22 21:03, Adam Williamson wrote:
On Wed, 2010-09-22 at 20:29 +1000, Philip Rhoades wrote:
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Check /var/log/Xorg.0.log for incriminating messages.
I can't see anything obvious - should I send this log to anyone now that this version as been OK'd already?
Thanks,
Phil.
On Thu, 2010-09-23 at 20:25 +1000, Philip Rhoades wrote:
Adam,
On 2010-09-22 21:03, Adam Williamson wrote:
On Wed, 2010-09-22 at 20:29 +1000, Philip Rhoades wrote:
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Check /var/log/Xorg.0.log for incriminating messages.
I can't see anything obvious - should I send this log to anyone now that this version as been OK'd already?
You should still file a bug, as we can fix it for the final release, perhaps. Thanks!
Adam,
On 2010-09-24 22:48, Adam Williamson wrote:
On Thu, 2010-09-23 at 20:25 +1000, Philip Rhoades wrote:
Adam,
On 2010-09-22 21:03, Adam Williamson wrote:
On Wed, 2010-09-22 at 20:29 +1000, Philip Rhoades wrote:
I agree with Adam - look for processes eating resources. I recommend using htop (a much better top replacement) and iotop (which will let you look for processes that are using the disk heavily).
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Check /var/log/Xorg.0.log for incriminating messages.
I can't see anything obvious - should I send this log to anyone now that this version as been OK'd already?
You should still file a bug, as we can fix it for the final release, perhaps. Thanks!
Done!
Regards,
Phil.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2010 05:29 AM, Philip Rhoades wrote:
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Thanks,
Phil.
By any chance are you using the radeon graphics driver? When you issue 'su -c init 3' from a xterm, does X get killed?
I had a similar experience. I blamed the radeon driver, but found that booting with the kernel param 'nohz=off' greatly reduced the CPU time eaten by X. (I don't have a 'root cause' for this one, sorry)
- -Jeff
Jeff,
On 2010-10-03 01:54, Jeff Raber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2010 05:29 AM, Philip Rhoades wrote:
Using top I found it is Xorg - taking up nearly 100% of CPU time . .
Is there some way to find out what it is about Xorg in particular?
Thanks,
Phil.
By any chance are you using the radeon graphics driver? When you issue 'su -c init 3' from a xterm, does X get killed?
No . .
I had a similar experience. I blamed the radeon driver, but found that booting with the kernel param 'nohz=off' greatly reduced the CPU time eaten by X. (I don't have a 'root cause' for this one, sorry)
That param didn't make any difference either . .
Thanks,
Phil.
-
Adam Miller -
Adam Williamson -
Jeff Raber -
Philip Rhoades