Hello:

I recently installed Etch on my new system and found X performance to be
sluggish, particularly when using Iceape. It appears as if there is little or
no hardware acceleration, remeniscent of a K7 with a slow graphics card. While
scrolling a web page down (but never up), or moving windows the display
sometimes freezes for about one second or more, with up to 100% CPU utilization.

My hardware is a K8M800 chipset motherboard with an Athlon64 X2 5000+ and Radeon
7500. I have tested all recent kernels up to and including linux 2.6.23-rc3.
All kernel and enabled X performance options are enabled, e.g. DRI, GLX, AGP,
on-CPU GART, color tiling. The same graphics card had much better performance
with Sarge even without acceleration.

Some system-specific details follow:

lspci
00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416)
MPEG-2 Encoder (rev 01)
00:0a.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416)
MPEG-2 Encoder (rev 01)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller
(rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237
AC97 Audio Controller (rev 60)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon
7500]


grep enabled /var/log/Xorg.0.log
(==) AIGLX enabled
(II) RADEON(0): Color tiling enabled by default
(**) RADEON(0): Backing store enabled
(II) RADEON(0): Direct rendering enabled
(II) RADEON(0): Render acceleration enabled
(II) RADEON(0): Acceleration enabled
(**) RADEON(0): DPMS enabled
(==) RADEON(0): Silken mouse enabled
(==) RandR enabled







--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Aug 18, 2007 at 06:01:10PM -0400, Marty wrote:
> Hello:
>
> I recently installed Etch on my new system and found X performance to be
> sluggish, particularly when using Iceape. It appears as if there is little
> or
> no hardware acceleration, remeniscent of a K7 with a slow graphics card.
> While
> scrolling a web page down (but never up), or moving windows the display
> sometimes freezes for about one second or more, with up to 100% CPU
> utilization.

Did you check with top what is using the CPU?

> My hardware is a K8M800 chipset motherboard with an Athlon64 X2 5000+ and
> Radeon
> 7500. I have tested all recent kernels up to and including linux

You call that a slow card?

> grep enabled /var/log/Xorg.0.log
> (==) AIGLX enabled
> (II) RADEON(0): Color tiling enabled by default
> (**) RADEON(0): Backing store enabled
> (II) RADEON(0): Direct rendering enabled
> (II) RADEON(0): Render acceleration enabled
> (II) RADEON(0): Acceleration enabled
> (**) RADEON(0): DPMS enabled
> (==) RADEON(0): Silken mouse enabled
> (==) RandR enabled

Any errors in the log?

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGx3+fqJyztHCFm9kRAjtgAJ90LGGQqJPGNaF7oeM8hy yYrOzlOgCeMHVd
IxLgfHn8BG3UUd8QbdUXCX8=
=0iKz
-----END PGP SIGNATURE-----

On Sat, Aug 18, 2007 at 06:01:10PM -0400, Marty wrote:
> Hello:
>
> I recently installed Etch on my new system and found X performance to be
> sluggish, particularly when using Iceape. It appears as if there is little
> or
> no hardware acceleration, remeniscent of a K7 with a slow graphics card.
> While
> scrolling a web page down (but never up), or moving windows the display
> sometimes freezes for about one second or more, with up to 100% CPU
> utilization.

Did you check with top what is using the CPU?

> My hardware is a K8M800 chipset motherboard with an Athlon64 X2 5000+ and
> Radeon
> 7500. I have tested all recent kernels up to and including linux

You call that a slow card?

> grep enabled /var/log/Xorg.0.log
> (==) AIGLX enabled
> (II) RADEON(0): Color tiling enabled by default
> (**) RADEON(0): Backing store enabled
> (II) RADEON(0): Direct rendering enabled
> (II) RADEON(0): Render acceleration enabled
> (II) RADEON(0): Acceleration enabled
> (**) RADEON(0): DPMS enabled
> (==) RADEON(0): Silken mouse enabled
> (==) RandR enabled

Any errors in the log?

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGx3+fqJyztHCFm9kRAjtgAJ90LGGQqJPGNaF7oeM8hy yYrOzlOgCeMHVd
IxLgfHn8BG3UUd8QbdUXCX8=
=0iKz
-----END PGP SIGNATURE-----

Andrei Popescu wrote:
> On Sat, Aug 18, 2007 at 06:01:10PM -0400, Marty wrote:
>> Hello:
>>
>> I recently installed Etch on my new system and found X performance to be
>> sluggish, particularly when using Iceape. It appears as if there is little
>> or
>> no hardware acceleration, remeniscent of a K7 with a slow graphics card.
>> While
>> scrolling a web page down (but never up), or moving windows the display
>> sometimes freezes for about one second or more, with up to 100% CPU
>> utilization.
>
> Did you check with top what is using the CPU?

Xorg. To see the instantaneous usage I have to increase top's update frequency.

Incidently, I noticed that I was running a lot of plugins, so I removed flash
and disabled javascript, which ed a little but did not solve the problem.

>
>> My hardware is a K8M800 chipset motherboard with an Athlon64 X2 5000+ and
>> Radeon
>> 7500. I have tested all recent kernels up to and including linux
>
> You call that a slow card?

For 2D apps it should be very fast. Its responsiveness seems normal under
moderate graphics load, only a few percent of the CPU, but jumps to 100% under
heavy load, such as scolling up a large web page (i.e. a blog), opening a web
page, starting or stopping an X app. When I enabled on the onboard VIA graphics
I saw the same effect, but more pronounced. On a much older, slower system
which I recently upgraded to Etch, I see a similar but less pronounced effect.

>
>> grep enabled /var/log/Xorg.0.log
>> (==) AIGLX enabled
>> (II) RADEON(0): Color tiling enabled by default
>> (**) RADEON(0): Backing store enabled
>> (II) RADEON(0): Direct rendering enabled
>> (II) RADEON(0): Render acceleration enabled
>> (II) RADEON(0): Acceleration enabled
>> (**) RADEON(0): DPMS enabled
>> (==) RADEON(0): Silken mouse enabled
>> (==) RandR enabled
>
> Any errors in the log?

If I enable the frame buffer (which I did since my last post):

(EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode is
disabled

I also get the following warnings:

(WW) RADEON(0): DRI init changed memory map, adjusting ...
(WW) RADEON(0): MC_FB_LOCATION was: 0x1fff0000 is: 0x1fff0000
(WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xe07fe000
(WW) AIGLX: 3D driver claims to not support visual 0x23

The last one is followed by several similar lines. The framebuffer does not
seem to affect the freeze issue.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrei Popescu wrote:
> On Sat, Aug 18, 2007 at 06:01:10PM -0400, Marty wrote:
>> Hello:
>>
>> I recently installed Etch on my new system and found X performance to be
>> sluggish, particularly when using Iceape. It appears as if there is little
>> or
>> no hardware acceleration, remeniscent of a K7 with a slow graphics card.
>> While
>> scrolling a web page down (but never up), or moving windows the display
>> sometimes freezes for about one second or more, with up to 100% CPU
>> utilization.
>
> Did you check with top what is using the CPU?

Xorg. To see the instantaneous usage I have to increase top's update frequency.

Incidently, I noticed that I was running a lot of plugins, so I removed flash
and disabled javascript, which ed a little but did not solve the problem.

>
>> My hardware is a K8M800 chipset motherboard with an Athlon64 X2 5000+ and
>> Radeon
>> 7500. I have tested all recent kernels up to and including linux
>
> You call that a slow card?

For 2D apps it should be very fast. Its responsiveness seems normal under
moderate graphics load, only a few percent of the CPU, but jumps to 100% under
heavy load, such as scolling up a large web page (i.e. a blog), opening a web
page, starting or stopping an X app. When I enabled on the onboard VIA graphics
I saw the same effect, but more pronounced. On a much older, slower system
which I recently upgraded to Etch, I see a similar but less pronounced effect.

>
>> grep enabled /var/log/Xorg.0.log
>> (==) AIGLX enabled
>> (II) RADEON(0): Color tiling enabled by default
>> (**) RADEON(0): Backing store enabled
>> (II) RADEON(0): Direct rendering enabled
>> (II) RADEON(0): Render acceleration enabled
>> (II) RADEON(0): Acceleration enabled
>> (**) RADEON(0): DPMS enabled
>> (==) RADEON(0): Silken mouse enabled
>> (==) RandR enabled
>
> Any errors in the log?

If I enable the frame buffer (which I did since my last post):

(EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode is
disabled

I also get the following warnings:

(WW) RADEON(0): DRI init changed memory map, adjusting ...
(WW) RADEON(0): MC_FB_LOCATION was: 0x1fff0000 is: 0x1fff0000
(WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xe07fe000
(WW) AIGLX: 3D driver claims to not support visual 0x23

The last one is followed by several similar lines. The framebuffer does not
seem to affect the freeze issue.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Aug 18, 2007 at 09:10:32PM -0400, Marty wrote:
> Andrei Popescu wrote:

> For 2D apps it should be very fast. Its responsiveness seems normal under
> moderate graphics load, only a few percent of the CPU, but jumps to 100%
> under heavy load, such as scolling up a large web page (i.e. a blog),

Can you give an example?

> opening a web page, starting or stopping an X app. When I enabled on

It's normal to use 100% CPU, you do want the app started as soon as
possible, don't you? The question is for how long. Iceweasel takes
about 4 seconds (counted) to start on my P4 1.6, Intel on-board, 512 MB
RAM.

> If I enable the frame buffer (which I did since my last post):
>
> (EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode
> is disabled
>
> I also get the following warnings:
>
> (WW) RADEON(0): DRI init changed memory map, adjusting ...
> (WW) RADEON(0): MC_FB_LOCATION was: 0x1fff0000 is: 0x1fff0000
> (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xe07fe000
> (WW) AIGLX: 3D driver claims to not support visual 0x23
>
> The last one is followed by several similar lines. The framebuffer does
> not seem to affect the freeze issue.

I'm not familiar with radeon cards, but if you suspect a driver issue
you could try the generic vesa driver.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGyAiJqJyztHCFm9kRAqrUAKCP3DD9Vfwh2tD2Le+Wnw W1aovftACfVvr5
iTpCLJ5L23VzyXOLFo00k9U=
=WGG1
-----END PGP SIGNATURE-----

Andrei Popescu wrote:
> On Sat, Aug 18, 2007 at 09:10:32PM -0400, Marty wrote:
>> Andrei Popescu wrote:
>
>> For 2D apps it should be very fast. Its responsiveness seems normal under
>> moderate graphics load, only a few percent of the CPU, but jumps to 100%
>> under heavy load, such as scolling up a large web page (i.e. a blog),
>
> Can you give an example?

http://www.dailytech.com/PC+Manufact...rticle8326.htm

My crude test is to resize the browser to fit one half screen, open a bash
terminal window on the other half and run top -d .5 (.5s refresh interval).

Watching top, I scroll through the page with the scroll slider. At low or
medium scroll rates I see about 20% CPU utilization or less. While increasing
the scroll rate I seem to cross a threshhold causing the CPU to peg, likewise by
dragging the top window quickly over the browser window. Finally, I see it when
I open several such pages in different windows and cycle through them. The
problem does not appear during similar tests on a Sarge system.

>> opening a web page, starting or stopping an X app. When I enabled on
>
> It's normal to use 100% CPU, you do want the app started as soon as
> possible, don't you? The question is for how long. Iceweasel takes
> about 4 seconds (counted) to start on my P4 1.6, Intel on-board, 512 MB
> RAM.

I'm not sure about it. Now I think it's limited to opening and closing certain
web pages. not applications.

>> If I enable the frame buffer (which I did since my last post):
>>
>> (EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode
>> is disabled
>>
>> I also get the following warnings:
>>
>> (WW) RADEON(0): DRI init changed memory map, adjusting ...
>> (WW) RADEON(0): MC_FB_LOCATION was: 0x1fff0000 is: 0x1fff0000
>> (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xe07fe000
>> (WW) AIGLX: 3D driver claims to not support visual 0x23
>>
>> The last one is followed by several similar lines. The framebuffer does
>> not seem to affect the freeze issue.
>
> I'm not familiar with radeon cards, but if you suspect a driver issue
> you could try the generic vesa driver.

I think the evidence of this problem while using the onboard graphics and one
other Etch system tends to point away from the Radeon card.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 07:04:32AM -0400, Marty wrote:

> I'm not sure about it. Now I think it's limited to opening and closing
> certain
> web pages. not applications.

Try disabling javascript, flash, ... things like that.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFGyCzuqJyztHCFm9kRAq15AJYwpXKn/t8z7HxhdBrJP5Wr2BHAAJ4lqk62
rVF/cEV6TH88yzm+PMzH9Q==
=Lx6s
-----END PGP SIGNATURE-----

Andrei Popescu wrote:
> On Sun, Aug 19, 2007 at 07:04:32AM -0400, Marty wrote:
>
>> I'm not sure about it. Now I think it's limited to opening and closing
>> certain
>> web pages. not applications.
>
> Try disabling javascript, flash, ... things like that.
>
> Regards,
> Andrei

I have removed all plugins, and disabled java, javascript and .
I have also disabled images and link prefetching. None of these changes fix the
problem.

On the same site I found a page that scrolls even more slowly:
http://www.dailytech.com/German+Scie...rticle8487.htm

New observations after further testing: First, I think I was mistaken, and this
problem does not occur in my other Etch system. Secondly, top shows only one
CPU pegged at 100%, while the overall CPU utilization is 50%, suggesting that
the other CPU is idle. Taken together these seem to suggest a possible SMP or
motherboard issue (MSI K9MM-V).


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marty wrote:

> I have removed all plugins, and disabled java, javascript and .
> I have also disabled images and link prefetching. None of these changes fix the
> problem.
>
> On the same site I found a page that scrolls even more slowly:
> http://www.dailytech.com/German+Scie...rticle8487.htm
>
> New observations after further testing: First, I think I was mistaken, and this
> problem does not occur in my other Etch system. Secondly, top shows only one
> CPU pegged at 100%, while the overall CPU utilization is 50%, suggesting that
> the other CPU is idle. Taken together these seem to suggest a possible SMP or
> motherboard issue (MSI K9MM-V).

I posted too soon. Apparently the image setting had not taken hold, and when I
did disable it the problem went away, both in Iceape and Konqueror. This seems
odd because the page is mostly text, with only a few small images. Now I am
guessing there is some kind of image library issue.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marty wrote:

> I have removed all plugins, and disabled java, javascript and .
> I have also disabled images and link prefetching. None of these changes fix the
> problem.
>
> On the same site I found a page that scrolls even more slowly:
> http://www.dailytech.com/German+Scie...rticle8487.htm
>
> New observations after further testing: First, I think I was mistaken, and this
> problem does not occur in my other Etch system. Secondly, top shows only one
> CPU pegged at 100%, while the overall CPU utilization is 50%, suggesting that
> the other CPU is idle. Taken together these seem to suggest a possible SMP or
> motherboard issue (MSI K9MM-V).

I posted too soon. Apparently the image setting had not taken hold, and when I
did disable it the problem went away, both in Iceape and Konqueror. This seems
odd because the page is mostly text, with only a few small images. Now I am
guessing there is some kind of image library issue.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
>
> >New observations after further testing: First, I think I was mistaken, and
> >this problem does not occur in my other Etch system. Secondly, top shows
> >only one CPU pegged at 100%, while the overall CPU utilization is 50%,
> >suggesting that the other CPU is idle. Taken together these seem to
> >suggest a possible SMP or motherboard issue (MSI K9MM-V).
>
> I posted too soon. Apparently the image setting had not taken hold, and
> when I did disable it the problem went away, both in Iceape and Konqueror.
> This seems odd because the page is mostly text, with only a few small
> images. Now I am guessing there is some kind of image library issue.

Just to clarify what you're seeing in top: 0.0%wa ?

I've found that the browsers pre-render and store stuff in memory which
slows down the system when it starts to swap, or it saves stuff to the
disk cache with the same result. Since I often access my browser via
ssh from my slow box, I've found that Konq stores rendered pages in the
Xorg server whereas iceweasel stores it locally. My X terminal box only
has 64 MB ram so if I need to view a complex/graphical page or multiple
tabs I'll use iceweasel, otherwise I like Konq.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
>
> >New observations after further testing: First, I think I was mistaken, and
> >this problem does not occur in my other Etch system. Secondly, top shows
> >only one CPU pegged at 100%, while the overall CPU utilization is 50%,
> >suggesting that the other CPU is idle. Taken together these seem to
> >suggest a possible SMP or motherboard issue (MSI K9MM-V).
>
> I posted too soon. Apparently the image setting had not taken hold, and
> when I did disable it the problem went away, both in Iceape and Konqueror.
> This seems odd because the page is mostly text, with only a few small
> images. Now I am guessing there is some kind of image library issue.

Just to clarify what you're seeing in top: 0.0%wa ?

I've found that the browsers pre-render and store stuff in memory which
slows down the system when it starts to swap, or it saves stuff to the
disk cache with the same result. Since I often access my browser via
ssh from my slow box, I've found that Konq stores rendered pages in the
Xorg server whereas iceweasel stores it locally. My X terminal box only
has 64 MB ram so if I need to view a complex/graphical page or multiple
tabs I'll use iceweasel, otherwise I like Konq.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Douglas A. Tutty wrote:
> On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
> >
>> >New observations after further testing: First, I think I was mistaken, and
>> >this problem does not occur in my other Etch system. Secondly, top shows
>> >only one CPU pegged at 100%, while the overall CPU utilization is 50%,
>> >suggesting that the other CPU is idle. Taken together these seem to
>> >suggest a possible SMP or motherboard issue (MSI K9MM-V).
>>
>> I posted too soon. Apparently the image setting had not taken hold, and
>> when I did disable it the problem went away, both in Iceape and Konqueror.
>> This seems odd because the page is mostly text, with only a few small
>> images. Now I am guessing there is some kind of image library issue.
>
> Just to clarify what you're seeing in top: 0.0%wa ?

I'm not sure I understand myself. I stopped it while scrolling and copied the
first few lines below:

Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.9%us, 4.8%sy, 0.0%ni, 45.1%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2073092k total, 1917620k used, 155472k free, 18832k buffers
Swap: 6434024k total, 0k used, 6434024k free, 1631596k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3353 root 15 -10 98128 24m 6460 R 100 1.2 10:36.02 Xorg

>
> I've found that the browsers pre-render and store stuff in memory which
> slows down the system when it starts to swap, or it saves stuff to the
> disk cache with the same result. Since I often access my browser via
> ssh from my slow box, I've found that Konq stores rendered pages in the
> Xorg server whereas iceweasel stores it locally. My X terminal box only
> has 64 MB ram so if I need to view a complex/graphical page or multiple
> tabs I'll use iceweasel, otherwise I like Konq.

I don't know if those issues apply here. I have some large applications running
(e.g. mythbackend) but I also seem to have plenty of memory, and top indicates
there is no swap memory used.

>
> Doug.
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 10:42:22AM -0400, Marty wrote:
> Douglas A. Tutty wrote:
> >On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
> > >
> >>>New observations after further testing: First, I think I was mistaken,
> >>and >this problem does not occur in my other Etch system. Secondly, top
> >>shows >only one CPU pegged at 100%, while the overall CPU utilization is
> >>50%, >suggesting that the other CPU is idle. Taken together these seem
> >>to >suggest a possible SMP or motherboard issue (MSI K9MM-V).
> >>
> >>I posted too soon. Apparently the image setting had not taken hold, and
> >>when I did disable it the problem went away, both in Iceape and
> >>Konqueror. This seems odd because the page is mostly text, with only a
> >>few small images. Now I am guessing there is some kind of image library
> >>issue.
> >
> >Just to clarify what you're seeing in top: 0.0%wa ?
>
> I'm not sure I understand myself. I stopped it while scrolling and copied
> the first few lines below:
>
> Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie
> Cpu(s): 49.9%us, 4.8%sy, 0.0%ni, 45.1%id, 0.2%wa, 0.0%hi, 0.0%si,
> 0.0%st

You have the (1) toggle on so that all CPUs are aggregated into Cpu(s).
Turn off the toggle to get a separate line for each CPU. According to
this your system is idle about half the time. I suspect that one
processor (the one running Xorg) is going flat out and the other is
idle. I don't know if Xorg is multi-threaded and able to run on
multiple CPUs or single threaded where SMP doesn't . Hopefully, the
application can use the other CPU to spread the load.


> Mem: 2073092k total, 1917620k used, 155472k free, 18832k buffers
> Swap: 6434024k total, 0k used, 6434024k free, 1631596k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3353 root 15 -10 98128 24m 6460 R 100 1.2 10:36.02 Xorg
>

If you have Irix mode set, then Xorg is using 100% of the CPU on which
it is running. If you have Solaris mode set, then Xorg is using 100% of
all CPUs, for the time period since the last refresh.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Douglas A. Tutty wrote:
> On Sun, Aug 19, 2007 at 10:42:22AM -0400, Marty wrote:
>> Douglas A. Tutty wrote:
>> >On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
>> > >
>> >>>New observations after further testing: First, I think I was mistaken,
>> >>and >this problem does not occur in my other Etch system. Secondly, top
>> >>shows >only one CPU pegged at 100%, while the overall CPU utilization is
>> >>50%, >suggesting that the other CPU is idle. Taken together these seem
>> >>to >suggest a possible SMP or motherboard issue (MSI K9MM-V).
>> >>
>> >>I posted too soon. Apparently the image setting had not taken hold, and
>> >>when I did disable it the problem went away, both in Iceape and
>> >>Konqueror. This seems odd because the page is mostly text, with only a
>> >>few small images. Now I am guessing there is some kind of image library
>> >>issue.
>> >
>> >Just to clarify what you're seeing in top: 0.0%wa ?
>>
>> I'm not sure I understand myself. I stopped it while scrolling and copied
>> the first few lines below:
>>
>> Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 49.9%us, 4.8%sy, 0.0%ni, 45.1%id, 0.2%wa, 0.0%hi, 0.0%si,
>> 0.0%st
>
> You have the (1) toggle on so that all CPUs are aggregated into Cpu(s).
> Turn off the toggle to get a separate line for each CPU. According to
> this your system is idle about half the time. I suspect that one
> processor (the one running Xorg) is going flat out and the other is
> idle. I don't know if Xorg is multi-threaded and able to run on
> multiple CPUs or single threaded where SMP doesn't . Hopefully, the
> application can use the other CPU to spread the load.
>
>
>> Mem: 2073092k total, 1917620k used, 155472k free, 18832k buffers
>> Swap: 6434024k total, 0k used, 6434024k free, 1631596k cached
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 3353 root 15 -10 98128 24m 6460 R 100 1.2 10:36.02 Xorg
>>
>
> If you have Irix mode set, then Xorg is using 100% of the CPU on which
> it is running. If you have Solaris mode set, then Xorg is using 100% of
> all CPUs, for the time period since the last refresh.
>
> Doug.
>
>

Thanks. I also found the threads option (H) in the man page. Below is a more
complete top listing, with (1) and Irix mode off, and threads on. It shows only
about one third of the total number of tasks.

Tasks: 173 total, 4 running, 169 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2073092k total, 2020192k used, 52900k free, 3976k buffers
Swap: 6434024k total, 56k used, 6433968k free, 1536972k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3353 root 14 -10 103m 33m 6608 R 49.9 1.6 15:35.94 Xorg
32185 marty 16 0 307m 249m 22m S 0.3 12.3 1:16.70 iceape-bin
32483 marty 16 0 2228 1172 856 S 0.2 0.1 0:04.79 top
1 root 16 0 1948 644 552 S 0.0 0.0 0:24.81 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.02 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.38 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.10 events/0
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.40 events/1
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ker
9 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
12 root 10 -5 0 0 0 S 0.0 0.0 0:00.21 kblockd/0
13 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 kblockd/1
14 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
105 root 10 -5 0 0 0 S 0.0 0.0 0:00.02 khubd
107 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
234 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
235 root 15 0 0 0 0 S 0.0 0.0 0:00.03 pdflush
236 root 15 0 0 0 0 S 0.0 0.0 0:00.54 kswapd0
237 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
238 root 13 -5 0 0 0 S 0.0 0.0 0:00.00 aio/1
360 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
361 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/1
363 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
364 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
404 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_2
405 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 usb-storage
420 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
483 root 15 0 0 0 0 S 0.0 0.0 0:00.00 kirqd
603 root 16 -4 2708 1152 348 S 0.0 0.1 0:00.03 udevd
950 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 ivtv_vbi/0
951 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 ivtv_vbi/1
998 root 5 -10 0 0 0 S 0.0 0.0 1:11.84 ivtv-enc
999 root 5 -10 0 0 0 S 0.0 0.0 5:43.70 ivtv-enc-vbi
1000 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 ivtv_vbi/0
1001 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ivtv_vbi/1
1034 root 10 -10 0 0 0 S 0.0 0.0 0:00.00 ivtv-enc
1035 root 10 -10 0 0 0 S 0.0 0.0 0:00.00 ivtv-enc-vbi
2080 daemon 16 0 1684 364 272 S 0.0 0.0 0:00.00 portmap
2083 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/0
2084 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 rpciod/1
2085 root 18 0 0 0 0 S 0.0 0.0 0:00.00 lockd


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 12:01:03PM -0400, Marty wrote:
> Douglas A. Tutty wrote:
> >On Sun, Aug 19, 2007 at 10:42:22AM -0400, Marty wrote:
> >>Douglas A. Tutty wrote:
> >>>On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
> >>> >
> >>>>>New observations after further testing: First, I think I was mistaken,
> >>>>and >this problem does not occur in my other Etch system. Secondly,
> >>top >>shows >only one CPU pegged at 100%, while the overall CPU
> >>utilization is >>50%, >suggesting that the other CPU is idle. Taken
> >>together these seem >>to >suggest a possible SMP or motherboard issue
> >>(MSI K9MM-V).
> >>>>
> >>>>I posted too soon. Apparently the image setting had not taken hold, and
> >>>>when I did disable it the problem went away, both in Iceape and
> >>>>Konqueror. This seems odd because the page is mostly text, with only a
> >>>>few small images. Now I am guessing there is some kind of image
> >>library >>issue.

> Thanks. I also found the threads option (H) in the man page. Below is a
> more complete top listing, with (1) and Irix mode off, and threads on. It
> shows only about one third of the total number of tasks.
>
> Tasks: 173 total, 4 running, 169 sleeping, 0 stopped, 0 zombie
> Cpu0 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si,
> 0.0%st
> Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,
> 0.0%st
> Mem: 2073092k total, 2020192k used, 52900k free, 3976k buffers
> Swap: 6434024k total, 56k used, 6433968k free, 1536972k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3353 root 14 -10 103m 33m 6608 R 49.9 1.6 15:35.94 Xorg
> 32185 marty 16 0 307m 249m 22m S 0.3 12.3 1:16.70 iceape-bin
> 32483 marty 16 0 2228 1172 856 S 0.2 0.1 0:04.79 top

Two things: it appears that Xorg isn't multi-threaded, and that there
is a problem. I don't know how to fix it.

Does the problem happen with Konqureror or iceweasel as well or only
with iceape? Do you need the all-in-one-mega-app approach of iceape or
would Konq or iceweasel work for you?

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 19, 2007 at 12:01:03PM -0400, Marty wrote:
> Douglas A. Tutty wrote:
> >On Sun, Aug 19, 2007 at 10:42:22AM -0400, Marty wrote:
> >>Douglas A. Tutty wrote:
> >>>On Sun, Aug 19, 2007 at 09:04:13AM -0400, Marty wrote:
> >>> >
> >>>>>New observations after further testing: First, I think I was mistaken,
> >>>>and >this problem does not occur in my other Etch system. Secondly,
> >>top >>shows >only one CPU pegged at 100%, while the overall CPU
> >>utilization is >>50%, >suggesting that the other CPU is idle. Taken
> >>together these seem >>to >suggest a possible SMP or motherboard issue
> >>(MSI K9MM-V).
> >>>>
> >>>>I posted too soon. Apparently the image setting had not taken hold, and
> >>>>when I did disable it the problem went away, both in Iceape and
> >>>>Konqueror. This seems odd because the page is mostly text, with only a
> >>>>few small images. Now I am guessing there is some kind of image
> >>library >>issue.

> Thanks. I also found the threads option (H) in the man page. Below is a
> more complete top listing, with (1) and Irix mode off, and threads on. It
> shows only about one third of the total number of tasks.
>
> Tasks: 173 total, 4 running, 169 sleeping, 0 stopped, 0 zombie
> Cpu0 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si,
> 0.0%st
> Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,
> 0.0%st
> Mem: 2073092k total, 2020192k used, 52900k free, 3976k buffers
> Swap: 6434024k total, 56k used, 6433968k free, 1536972k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3353 root 14 -10 103m 33m 6608 R 49.9 1.6 15:35.94 Xorg
> 32185 marty 16 0 307m 249m 22m S 0.3 12.3 1:16.70 iceape-bin
> 32483 marty 16 0 2228 1172 856 S 0.2 0.1 0:04.79 top

Two things: it appears that Xorg isn't multi-threaded, and that there
is a problem. I don't know how to fix it.

Does the problem happen with Konqureror or iceweasel as well or only
with iceape? Do you need the all-in-one-mega-app approach of iceape or
would Konq or iceweasel work for you?

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Douglas A. Tutty wrote:

> Two things: it appears that Xorg isn't multi-threaded, and that there
> is a problem. I don't know how to fix it.
>
> Does the problem happen with Konqureror or iceweasel as well or only
> with iceape?

Konqueror has almost identical symptoms, though slightly less severe.

Do you need the all-in-one-mega-app approach of iceape or
> would Konq or iceweasel work for you?

I wish it were that easy to resolve. At this point it seems independent of the
graphics hardware but related to web browsing and images (and not plugins, java
or javascript). I can't rule out other X apps at this point. I've tried
various browser configuration settings. Nothing unusual appears in the system
logs or boot up messages. I will try a stripped down kernel and/or run a mirror
of the system on another motherboard to eliminate most hardware related issues.
My guess is that I will find the problem this way and it will not turn out to
be a user-space software issue.

If that doesn't isolate the problem, however, then I probably take a look at the
libraries. Except for debian-multimedia and custom kernels, all binaries pass a
debsums check against the latest debian archive. The following command lists the
libs that are common to both Iceape and Konqueror:

$ echo "`apt-cache depends iceape-browser|grep ' lib'`"+"`apt-cache depends
konqueror|grep ' lib'`"|sort|uniq -d
Depends: libc6
Depends: libfontconfig1
Depends: libgcc1
Depends: libjpeg62
Depends: libpng12-0
Depends: libstdc++6
Depends: libx11-6
Depends: libxcursor1
Depends: libxext6
Depends: libxft2
Depends: libxi6
Depends: libxinerama1
Depends: libxrandr2
Depends: libxrender1
Depends: libxt6

Of these, the ones that look like they could be related to browser images are
libjpeg62, libpng12-0, libxinerama1, libxrandr2 and libxrender1. None are
debian-multimedia replacements. There was a big library upgrade a couple days
ago but I've already overwritten my daily backup so I can't easily revert.

If and when I locate the problem I'll post the resolution here.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Douglas A. Tutty wrote:

> Two things: it appears that Xorg isn't multi-threaded, and that there
> is a problem. I don't know how to fix it.
>
> Does the problem happen with Konqureror or iceweasel as well or only
> with iceape?

Konqueror has almost identical symptoms, though slightly less severe.

Do you need the all-in-one-mega-app approach of iceape or
> would Konq or iceweasel work for you?

I wish it were that easy to resolve. At this point it seems independent of the
graphics hardware but related to web browsing and images (and not plugins, java
or javascript). I can't rule out other X apps at this point. I've tried
various browser configuration settings. Nothing unusual appears in the system
logs or boot up messages. I will try a stripped down kernel and/or run a mirror
of the system on another motherboard to eliminate most hardware related issues.
My guess is that I will find the problem this way and it will not turn out to
be a user-space software issue.

If that doesn't isolate the problem, however, then I probably take a look at the
libraries. Except for debian-multimedia and custom kernels, all binaries pass a
debsums check against the latest debian archive. The following command lists the
libs that are common to both Iceape and Konqueror:

$ echo "`apt-cache depends iceape-browser|grep ' lib'`"+"`apt-cache depends
konqueror|grep ' lib'`"|sort|uniq -d
Depends: libc6
Depends: libfontconfig1
Depends: libgcc1
Depends: libjpeg62
Depends: libpng12-0
Depends: libstdc++6
Depends: libx11-6
Depends: libxcursor1
Depends: libxext6
Depends: libxft2
Depends: libxi6
Depends: libxinerama1
Depends: libxrandr2
Depends: libxrender1
Depends: libxt6

Of these, the ones that look like they could be related to browser images are
libjpeg62, libpng12-0, libxinerama1, libxrandr2 and libxrender1. None are
debian-multimedia replacements. There was a big library upgrade a couple days
ago but I've already overwritten my daily backup so I can't easily revert.

If and when I locate the problem I'll post the resolution here.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 8/18/07, Marty <martyb@ix.netcom.com> wrote:
> Hello:
>