Just chiming in to let you know that I've just compiled and installed
2.6.36-rc3 from upstream and the leak is definitely still here.
I also added/disabled/toggled several driver settings (AccelMethod,
ColorTiling, etc.) in my xorg.conf file without noticeable effects on
either the visual artifact
OK, not sure this is quite relevant for this bug report, but at least
on a related note using unstable's libdrm-radeon1 2.4.18-6 after a
while I get this is logged to dmesg and the system becomes unreachable
remotely (ssh can't complete the login process, but I can execute
individual commands):
[2
Just tried again with kernel 2.6.32-5 and the following packages:
ii xserver-xorg-v 1:6.13.1-2
ii libdrm-radeon1 2.4.18-6
And the behaviour when scrolling the previously mentioned webpage was different.
1) When scrolling continously RAM usage (as measured in real time by
gkrellm2, for example)
reassign 591061 src:xserver-xorg-video-ati 1:6.13.1-2
thanks
Eduardo I. (06/08/2010):
> Hi Cyril, thanks for your answer.
No problem,
> Do you want me to try any other combination of packages?
not yet, reassigning to the driver. Could be it, could be the kernel,
but I'm told upstream is subscr
Hi Cyril, thanks for your answer.
Just confirmed the memory leak is present using 2.4.18-6 with kernel 2.6.35.
ii libdrm-radeon1 2.4.18-6
Userspace interface to radeon-specific kernel
DRM services -- runtime
Will try again with 2.6.32 in a co
Hi Eduardo,
Eduardo Ivanec (31/07/2010):
> Package: libdrm-radeon1
> Version: 2.4.21-1
> Severity: important
is there any chance you could try with 2.4.18 (from unstable)? The
leak might be in libdrm or in the kernel, I guess. Since you already
checked with 2.6.32 and 2.6.35, I guess trying olde
6 matches
Mail list logo