Please blacklist ATI Radeon Mobility 7500 from compiz

Hmm, this sounds awfully familiar. What was the dimensions on the png?

There was once a bug where if you loaded a png with dimensions equal to or larger than the screen resolution, it'd trigger an array bounds issue. Does this bug reproduce reliably when loading the png? (Try loading it in firefox too - iirc the bug also triggered there.)

Also, see if you can reproduce this one with EXA enabled as well. Possibly it is an XAA-specific bug, in which case again we should focus on figuring out why EXA is not enabled for this hardware, and fix *that*.

My desktop is 1400x1050. Attached is a png that causes X to reliably hang the desktop with XAA (no xorg.conf), radeon.modeset=0 and compiz (opening by double clicking the png on the Desktop, which opens eog). The png is 1400x1050. After the hang the display is totally unusable, but I can ssh in. Stopping and starting gdm has no affect.

After rebooting and enabling EXA (using radeon.modeset=0 and compiz), X does not hang, but is painfully slow, as mentioned in bug #513956.

As a side note, if I logged in with EXA but without compiz, started firefox and then tried to enable compiz, I could not ("Desktop effects could not be enabled"). I had to close firefox first to successfully enable compiz. There was nothing interesting in dmesg or Xorg.0.log to try to debug this.

This is still not fixed with 2.6.32-14.20-generic and the latest xorg-edgers drivers, but a there is a little more information:
1. the png no longer displays when using EXA (eog display black only)
2. I am unable to enable compiz if using XAA-- X froze 3 times in a row when I enabled desktop affects. I have a feeling this may have always been the case, and I just got lucky. The png no longer reliably crashes XAA (maybe eog changed?). Seems the bug is not so much the png but XAA+compiz+no KMS.

Of course, a minute after posting my last comment, X froze.

Hi Jamie,

We're not going to have this fixed for Alpha 3. However, I took the
matter of this bug up with David Airlie upstream, who told us we need to
pull the latest DRM code from the .33 kernel in order to fix this bug
and many like it. It seems a lot of kms stuff got rushed into .32 and
is pretty buggy, especially with older or unusual hardware.

I brought the kernel guys in on this discussion, and while there was
heavy skepticism that this was just upstream pushing us to bleeding edge
stuff yet again, in this case we have assurance that .33 has been a
stabilization release and thus is an appropriate solution. The question
remains whether the kernel team will backport this drm code en masse to
the .32 kernel, or if instead it would be put in
linux-restricted-modules for users to opt-in to as needed. There wasn't
time to do either one of these in time for alpha-3. I think we're
leaning towards the former, but the decision will be made after alpha-3
is out.

Even phoronix has picked up on this debate and written about it:
http://www.phoronix.com/scan.php?page=news_item&px=Nzk5Nw

So in case you think your bug is being ignored... quite the contrary.
But it's that piece of yarn which unravels the whole sweater.

One thing you could do for testing, would be to install and try Andy's
drm backport and give me feedback on it:

  http://people.canonical.com/~apw/drm-backport-lucid/

I don't know if simply installing this is enough, or if it'll require
additional configuration of bits and pieces, so be aware it could be
time consuming to set this all up properly... or it might just magically
work.

Otherwise, I'd say sit tight, it'll be a week or so before we can get
this drm available in Lucid and integrated to a point where we'll be
confident it can be easily tested.

On Wed, Feb 24, 2010 at 02:48:16PM -0000, Jamie Strandboge wrote:
> Of course, a minute after posting my last comment, X froze.
>
> --
> [lucid] xorg froze after disabled KMS and enabling compiz on ATI Radeon Mobility 7500
> https://bugs.launchpad.net/bugs/513950
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in ???xserver-xorg-video-ati??? package in Ubuntu: Triaged
> Status in ???xserver-xorg-video-ati??? source package in Lucid: Triaged
>
> Bug description:
> Binary package hint: xorg
>
> In trying workarounds for bug #507148 I disabled KMS by booting with radeon.modeset=0. I had compiz disabled, then enabled it. I had screen garbling so tried to take a screenshot. This worked but after double clicking on the Screenshot.png on my desktop, X froze. I could ssh in, so I ran 'ubuntu-bug xorg' from there. I do not have an xorg.conf file.
>
> ProblemType: Bug
> Architecture: i386
> Date: Thu Jan 28 13:40:00 2010
> DistroRelease: Ubuntu 10.04
> DkmsStatus: Error: [Errno 2] No such file or directory
> EcryptfsInUse: Yes
> Lsusb:
> ??Bus 004 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
> ??Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 001 Devi...

On Wed, 2010-02-24 at 18:08 +0000, Bryce Harrington wrote:
> Hi Jamie,
>
> We're not going to have this fixed for Alpha 3. However, I took the
> matter of this bug up with David Airlie upstream, who told us we need to
> pull the latest DRM code from the .33 kernel in order to fix this bug
> and many like it. It seems a lot of kms stuff got rushed into .32 and
> is pretty buggy, especially with older or unusual hardware.
>
Understood.

> One thing you could do for testing, would be to install and try Andy's
> drm backport and give me feedback on it:
>
> http://people.canonical.com/~apw/drm-backport-lucid/
>
I ended up using the one that he asked me to in bug LP: #507148. compiz
still crashed (see report).

Thanks for the follow up. :)

--
Jamie Strandboge | http://www.canonical.com

On up to date Lucid as of 2010-03-09, this is still a problem with no xorg.conf file (X defaults to XAA). Today it survived switching to compiz, but after rebooting and logging in, when I opened the PNG-crasher, the system locked up.

$ cat /proc/version_signature
Ubuntu 2.6.32-16.24-generic

Thanks for re-testing Jamie. Would you mind also adding your testing
comments on the upstream bug reports? When we went upstream with the
issues before they said testing with this new drm was required before
they'd look into the issue.

Also, Andy has implemented functionality for blacklisting cards from
using KMS, and I suggested you might be willing to serve as a guinea pig
for this. apw - can you give Jamie any directions on how to set up this
testing? If you need pciids, I think all the relevant data files are
attached to this bug report for reference.

On Tue, Mar 09, 2010 at 09:44:20PM -0000, Jamie Strandboge wrote:
> On up to date Lucid as of 2010-03-09, this is still a problem with no
> xorg.conf file (X defaults to XAA). Today it survived switching to
> compiz, but after rebooting and logging in, when I opened the PNG-
> crasher, the system locked up.
>
> $ cat /proc/version_signature
> Ubuntu 2.6.32-16.24-generic
>
> --
> [lucid] xorg froze after disabled KMS and enabling compiz on ATI Radeon Mobility 7500
> https://bugs.launchpad.net/bugs/513950
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in ???xserver-xorg-video-ati??? package in Ubuntu: Triaged
> Status in ???xserver-xorg-video-ati??? source package in Lucid: Triaged
>
> Bug description:
> Binary package hint: xorg
>
> In trying workarounds for bug #507148 I disabled KMS by booting with radeon.modeset=0. I had compiz disabled, then enabled it. I had screen garbling so tried to take a screenshot. This worked but after double clicking on the Screenshot.png on my desktop, X froze. I could ssh in, so I ran 'ubuntu-bug xorg' from there. I do not have an xorg.conf file.
>
> ProblemType: Bug
> Architecture: i386
> Date: Thu Jan 28 13:40:00 2010
> DistroRelease: Ubuntu 10.04
> DkmsStatus: Error: [Errno 2] No such file or directory
> EcryptfsInUse: Yes
> Lsusb:
> ??Bus 004 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
> ??Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ??Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> MachineType: IBM 2378RRU
> Package: xorg 1:7.5+1ubuntu2
> PccardctlIdent:
> ??Socket 0:
> ??????no product info available
> ??Socket 1:
> ??????no product info available
> PccardctlStatus:
> ??Socket 0:
> ??????no card
> ??Socket 1:
> ??????no card
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-11-generic root=UUID=0c1cec18-6655-4ef5-8c03-2009d66c50e2 ro splash quiet radeon.modeset=0
> ProcEnviron:
> ??PATH=(custom, user)
> ??LANG=en_US.UTF-8
> ??SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-11.15-generic
> RelatedPackageVersions:
> ??xserver-xorg 1:7.5+1ubuntu2
> ??libgl1-mesa-glx 7.7-0ubuntu8
> ??libdrm2 2.4.17-0ubuntu2
> ??xserver-xorg-video-intel 2:2.9.1-1ubuntu1
> SourcePackage: xorg
> Uname: Linux 2.6.32-11-generic i686
> dmi.bios.date: 06/18/2007
> dmi.bios.vendor: IBM
> dmi.bios.version: 1RETDRWW (3.23 )
> dmi.board.name: 2378RRU
> dmi.board.vendor: IBM
> dmi.board.version: Not Available
> dmi.chassis.as...

Yes, I did that last time. I'll do it again for this kernel.

Jamie, can you adjust the memory allocation to the IGP in your bios? If so, can you up it to at least 64MB and boot with no xorg.conf and KMS enabled?

Robert, I lent my laptop to one of our kernel developers (so he could more easily test fixes/reproduce, etc). As such, I am unable to test this atm. I will ask him to do so though.

It appears we've lost momentum on getting this bug solved, so I think we should proceed with the backup plan of blacklisting the chip from compiz and kms until we can verify a proper fix to it. For this bug report we'll focus on the compiz blacklisting.

Wait, please don't do this yet. Manoj was working on fixes for kms/dri/compiz and thinks he has them solved. I don't have my laptop back from him to confirm, but will tomorrow. Please see comments starting at number #44 in bug #507148.

Okay, in looking at the other bugs it looks like the fixes have been applied and confirmed, so if I understand correctly those fixes make this bug no longer relevant, so I am closing it as resolved now. If this is incorrect, please reopen (actually, at this point filing a new bug report would probably be better, but your call).

Thanks Bryce, there is no need to blacklist. After a lot of automated testing and many hours of real world use, it no longer crashes.