Ubuntu

[RV410] Color depth degradation after resume (ATI Mobility Radeon X700)

Reported by zvaral on 2010-01-20
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
xserver-xorg-driver-ati
Confirmed
Medium
xserver-xorg-video-ati (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: yelp

After resuming my Acer laptop (with Ati Radeon x700) from suspend, the color depth of X changes to 8 bit or similar. Originally it is set to 24 bit color depth which is presented after the boot process but it degrades after the first suspend/resume.

ProblemType: Bug
Architecture: amd64
Date: Wed Jan 20 09:06:51 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/yelp
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100113)
Package: yelp 2.28.0+webkit-1ubuntu1
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-10.14-generic
SourcePackage: yelp
Tags: lucid
Uname: Linux 2.6.32-10-generic x86_64
---
Architecture: amd64
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100224.1)
Lsusb:
 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: Acer, inc. Ferrari 4000
Package: xserver-xorg-video-ati 1:6.12.191-1ubuntu2
PackageArchitecture: amd64
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=ce9e0038-ae57-40d1-b512-7fb439874808 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
Tags: lucid lucid
Uname: Linux 2.6.32-16-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 03/20/06
dmi.bios.vendor: Acer
dmi.bios.version: 3A27
dmi.board.name: Ferrari IV
dmi.board.vendor: Acer, Inc.
dmi.board.version: Not Applicable
dmi.chassis.type: 1
dmi.chassis.vendor: , Inc.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAcer:bvr3A27:bd03/20/06:svnAcer,inc.:pnFerrari4000:pvrNotApplicable:rvnAcer,Inc.:rnFerrariIV:rvrNotApplicable:cvn,Inc.:ct1:cvrN/A:
dmi.product.name: Ferrari 4000
dmi.product.version: Not Applicable
dmi.sys.vendor: Acer, inc.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: x86_64
 kernel: 2.6.32-16-generic

[lspci]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X700 (PCIE) [1002:5653]
     Subsystem: Acer Incorporated [ALI] Device [1025:007e]

zvaral (z-varallyay) wrote :
Robert Wall (rww) wrote :

Which Xorg driver are you using (radeon, radeonHD, fglrx, etc.)?

Please also attach the contents of /var/log/Xorg.0.log from a session where this problem occurs, and the output of lspci -vvnn

Changed in yelp (Ubuntu):
status: New → Incomplete
zvaral (z-varallyay) wrote :

I use the Xorg driver obtained from the default install of the 10.04 alpha2 disk which is radeon.
I attached the /var/log/Xorg.0.log file as well as the output of the lspci -vvnn command (lspci_out.txt).

zvaral (z-varallyay) wrote :
Robert Wall (rww) on 2010-01-20
summary: - color depth degradation after resume (ati mobility radeon)
+ [lucid alpha-2][radeon] Color depth degradation after resume (ATI
+ Mobility Radeon X700)
affects: yelp (Ubuntu) → xserver-xorg-video-radeonhd (Ubuntu)
Changed in xserver-xorg-video-radeonhd (Ubuntu):
status: Incomplete → Confirmed
affects: xserver-xorg-video-radeonhd (Ubuntu) → xserver-xorg-video-ati (Ubuntu)
Bryce Harrington (bryce) on 2010-02-27
tags: added: resume

After reinstalling my system using the alpha 3 CD, this issue disappeared. Therefore this bug has been corrected and should not be considered as a bug anymore.

But simply using daily upgrade of my computer from an earlier installation (alpha 2) has not resolved this problem. I would be grateful if somebody could suggest how to prepare the upgrade process to take effect on such modifications along with closing this bug.

zvaral (z-varallyay) wrote :
Download full text (4.5 KiB)

I have to withdraw my previous comment.

The truth is that I have two machines theoretically with the same configuration (except the hard drives are different). Both are the same acer ferrari 4005 WLMi model. In one of them the color depth degradation still appears while the other one suffers from Bug #524860 related to gnome-keyring but color depth changes after suspend/resume does not appear.

I did the following experiment: I switched on both machines when booted up I logged in, suspended and resumed. After these I coppied the file from /var/log/Xorg.0.log to

Xorg.0.log_homepc (refers to homepc suffering from color depth changes after resume) and
Xorg.0.log_hardnut (refers to the other laptop without any issue after resume)

Please, find the difference between the two files here below. (It seems that the two radeon x700 cards are a bit different)

zvaral@hardnut:~$ diff Xorg.0.log_homepc Xorg.0.log_hardnut
6,9c6,9
< Current Operating System: Linux homepc 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64
< Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-15-generic root=UUID=ce9e0038-ae57-40d1-b512-7fb439874808 ro quiet splash
< Build Date: 02 March 2010 03:30:16PM
< xorg-server 2:1.7.5-1ubuntu2 (buildd@)
---
> Current Operating System: Linux hardnut 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64
> Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-15-generic root=UUID=4ceac70f-55c9-4a91-baae-aee960ec8114 ro quiet splash
> Build Date: 19 February 2010 11:38:32AM
> xorg-server 2:1.7.5-1ubuntu1 (buildd@)
16,17c16,17
< (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 3 08:05:23 2010
< (II) Loader magic: 0x7c82e0
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 3 09:18:02 2010
> (II) Loader magic: 0x7c8300
93c93
< (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
---
> (II) Open ACPI successful (/var/run/acpid.socket)
369c369
< drmOpenDevice: open result is 8, (OK)
---
> drmOpenDevice: open result is 9, (OK)
371c371
< drmOpenDevice: open result is 8, (OK)
---
> drmOpenDevice: open result is 9, (OK)
374,375c374,375
< drmOpenDevice: open result is 8, (OK)
< drmOpenByBusid: drmOpenMinor returns 8
---
> drmOpenDevice: open result is 9, (OK)
> drmOpenByBusid: drmOpenMinor returns 9
385,386c385,386
< (II) RADEON(0): Manufacturer: SEC Model: 3446 Serial#: 0
< (II) RADEON(0): Year: 2006 Week: 0
---
> (II) RADEON(0): Manufacturer: SEC Model: 0 Serial#: 0
> (II) RADEON(0): Year: 2003 Week: 0
403c403
< (II) RADEON(0): LTN154P4-L01
---
> (II) RADEON(0): LTN154P1-L02
405,406c405,406
< (II) RADEON(0): 00ffffffffffff004ca3463400000000
< (II) RADEON(0): 00100103802115780a87f594574f8c27
---
> (II) RADEON(0): 00ffffffffffff004ca3000000000000
> (II) RADEON(0): 000d0103802115780a87f594574f8c27
410c410
< (II) RADEON(0): 00000000003cd2026400000000fe0053
---
> (II) RADEON(0): 00000000003cd2026401000000fe0053
412c412
< (II) RADEON(0): 004c544e31353450342d4c30310a0080
---
> (II) RADEON(0): 004c544e31353450312d4c30320a00fe
497a498,500
> record: RECORD extension enabled at configure time.
> record: This extension is known to be broken, disabling extension now..
> record: h...

Read more...

Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Thanks for reporting this bug to help making the -ati graphics driver
better. We hear from upstream that a number of bugs (possibly including
this one) have been fixed in the newer DRM code from the 2.6.33 kernel.
I don't know if your bug is one of the ones fixed in this release,
though, but we've prepared a PPA with this DRM update. Would you mind
installing this, rebooting, and testing if the original issue can be
reproduced with it or not?

The DRM PPA is here:

    https://edge.launchpad.net/~apw/+archive/red

Note there could be new bugs... please file these as new reports using
the command 'ubuntu-bug linux' (for kernel or DRM or KMS bugs) or
'ubuntu-bug xorg' if you suspect them to be X.org issues.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Incomplete
zvaral (z-varallyay) wrote :

I thank you very much that you consider my bug report.

Unfortunately, the mentioned PPA did not help me.

Bryce Harrington (bryce) wrote :

Okay thanks, this bug should probably go upstream next. Would you mind please updating to the latest version of ubuntu, reproducing the problem, and then run the command:

  apport-collect 510001

This will update the bug report with the latest info so we can send the bug report upstream.

You don't need to have the ppa installed anymore. The code it provided is now in Ubuntu proper.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → New
status: New → Incomplete

apport information

tags: added: apport-collected
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Bryce Harrington (bryce) on 2010-03-19
Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → Medium
Bryce Harrington (bryce) on 2010-03-23
Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Triaged
Bryce Harrington (bryce) on 2010-03-24
description: updated
Download full text (6.8 KiB)

Forwarding this bug from Ubuntu reporter zvaral:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/510001

[Problem]
After a resume from suspend, the color depth changes from 24 bit to 8 bit.

[Original Description]
After resuming my Acer laptop (with Ati Radeon x700) from suspend, the color depth of X changes to 8 bit or similar. Originally it is set to 24 bit color depth which is presented after the boot process but it degrades after the first suspend/resume.

I have two machines theoretically with the same configuration (except the hard drives are different). Both are the same acer ferrari 4005 WLMi model. In one of them the color depth degradation still appears while the other one suffers from Bug #524860 related to gnome-keyring but color depth changes after suspend/resume does not appear.

I did the following experiment: I switched on both machines when booted up I logged in, suspended and resumed. After these I coppied the file from /var/log/Xorg.0.log to

Xorg.0.log_homepc (refers to homepc suffering from color depth changes after resume) and
Xorg.0.log_hardnut (refers to the other laptop without any issue after resume)

Please, find the difference between the two files here below. (It seems that the two radeon x700 cards are a bit different)

zvaral@hardnut:~$ diff Xorg.0.log_homepc Xorg.0.log_hardnut
6,9c6,9
< Current Operating System: Linux homepc 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64
< Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-15-generic root=UUID=ce9e0038-ae57-40d1-b512-7fb439874808 ro quiet splash
< Build Date: 02 March 2010 03:30:16PM
< xorg-server 2:1.7.5-1ubuntu2 (buildd@)
---
> Current Operating System: Linux hardnut 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64
> Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-15-generic root=UUID=4ceac70f-55c9-4a91-baae-aee960ec8114 ro quiet splash
> Build Date: 19 February 2010 11:38:32AM
> xorg-server 2:1.7.5-1ubuntu1 (buildd@)
16,17c16,17
< (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 3 08:05:23 2010
< (II) Loader magic: 0x7c82e0
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 3 09:18:02 2010
> (II) Loader magic: 0x7c8300
93c93
< (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
---
> (II) Open ACPI successful (/var/run/acpid.socket)
369c369
< drmOpenDevice: open result is 8, (OK)
---
> drmOpenDevice: open result is 9, (OK)
371c371
< drmOpenDevice: open result is 8, (OK)
---
> drmOpenDevice: open result is 9, (OK)
374,375c374,375
< drmOpenDevice: open result is 8, (OK)
< drmOpenByBusid: drmOpenMinor returns 8
---
> drmOpenDevice: open result is 9, (OK)
> drmOpenByBusid: drmOpenMinor returns 9
385,386c385,386
< (II) RADEON(0): Manufacturer: SEC Model: 3446 Serial#: 0
< (II) RADEON(0): Year: 2006 Week: 0
---
> (II) RADEON(0): Manufacturer: SEC Model: 0 Serial#: 0
> (II) RADEON(0): Year: 2003 Week: 0
403c403
< (II) RADEON(0): LTN154P4-L01
---
> (II) RADEON(0): LTN154P1-L02
405,406c405,406
< (II) RADEON(0): 00ffffffffffff004ca3463400000000
< (II) RADEON(0): 00100103802115780a87f594574f8c27
---
> (II) RADEON(0): 00ffffffffffff004ca3000000000000
> (II) RADEON(0): 000d0103...

Read more...

Created an attachment (id=34610)
BootDmesg.txt

Created an attachment (id=34611)
CurrentDmesg.txt

Created an attachment (id=34612)
XorgLog.txt

Created an attachment (id=34613)
XorgLogOld.txt

Created an attachment (id=34614)
Xrandr.txt

What looks to be different between the two systems is the monitors, which seem to be a rev number different. This sounds minor but the EDID presented by the monitors are coming through quite a bit differently. I'm not sure if that is what is causing the difference in behavior but I could certainly imagine it could. I do notice one error in the EDID parsing bits:

(II) RADEON(0): Unknown vendor-specific block f

I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=27422 - please subscribe to this bug in case upstream needs further information or wishes you to test something. Thanks ahead of time.

How was it determined that 'the color depth changes from 24 bit to 8 bit'? The X server can't change depth at runtime.

If it's that the colours become dark or otherwise broken, it could be a duplicate of bug 27382.

I'm not sure how he's determining that. His xdpyinfo looks completely normal: http://launchpadlibrarian.net/41230371/xdpyinfo.txt

Perhaps he means to say that the screen appears to lose color depth. Maybe we need a photo.

Here's the user's reply. Photos and some regdump data in the link below.

Hello Bryce,

I thank you for your questions.

I have no reliable information on the real color depth after
suspend/resume. I have just assumed that it could be something similar.
Therefore I attached two photos on the screen after such actions. (Sorry
my cam is horrible so you will be able to see rather distorted images
but the phenomena looks clear.)

I've also checked the PID of Xorg

$ ps -A |grep Xorg
  964 tty7 00:00:13 Xorg

therefore I copied some files from /proc/964 to the compressed directory
attached here. There is a subdir within named as 964.

I also performed the actions you requested with radeontool. There is a
regdump_broke_local.txt and regdump_broke_remote.txt along with the
regdump_good.txt file. regdump_broke_local.txt is the gathered info
using the broken screen. regdump_broke_remote.txt is the same but I
logged in remotely.

I hope this helps! Thanks, Zoltan

** Attachment added: "radeontool regdumps + photos"
   http://launchpadlibrarian.net/42921659/bug_rep.tgz

Please, send me your questions in connection with this bug in the future.
Regards,
Zoltan

Hi zvaral,

Upstream has a question for you regarding how you're determining it is 8-bit. If you are using data from the computer itself, please attach the relevant log or command output to the upstream bug report. If you're determining it visually please include a photo of the screen to the upstream bug report. This will help narrow in on where things are failing.

radeontool might also be useful to assist in debugging this issue. To install it from the command line, use this command:

    sudo apt-get install radeontool

After installing it, you run it like this:

    radeontool regmatch '*' > regdump_good.txt
    radeontool regmatch '*' > regdump_broke.txt

Run it two times. Once when you have a working screen (for any driver), and once in the broken case (either from the tty console or logged into the sick box remotely). Attach both of those to the upstream bug report. Thanks ahead of time!

Changed in xserver-xorg-video-ati (Ubuntu):
status: Triaged → Incomplete
Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
zvaral (z-varallyay) wrote :

Hello Bryce,

I thank you for your questions.

I have no reliable information on the real color depth after suspend/resume. I have just assumed that it could be something similar. Therefore I attached two photos on the screen after such actions. (Sorry my cam is horrible so you will be able to see rather distorted images but the phenomena looks clear.)

I've also checked the PID of Xorg

$ ps -A |grep Xorg
  964 tty7 00:00:13 Xorg

therefore I copied some files from /proc/964 to the compressed directory attached here. There is a subdir within named as 964.

I also performed the actions you requested with radeontool. There is a regdump_broke_local.txt and regdump_broke_remote.txt along with the regdump_good.txt file. regdump_broke_local.txt is the gathered info using the broken screen. regdump_broke_remote.txt is the same but I logged in remotely.

I hope this helps! Thanks, Zoltan

Bryce Harrington (bryce) wrote :

Thanks zvaral, I've forwarded this information upstream.

Could you please register and subscribe to the upstream bug report, so you can answer their questions more directly? (Being a liaison copying-and-pasting between launchpad and bugzilla is not very efficient for me.) http://bugs.freedesktop.org/show_bug.cgi?id=27422

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Triaged
summary: - [lucid alpha-2][radeon] Color depth degradation after resume (ATI
- Mobility Radeon X700)
+ Color depth degradation after resume (ATI Mobility Radeon X700)

If you want a bug tracked here, attach all the information here directly.

Does running something like

xgamma -gamma 1.0

fix the problem?

Bryce Harrington (bryce) on 2010-05-21
tags: added: hardy
Changed in xserver-xorg-driver-ati:
importance: Unknown → Medium

Any news here? I seem to suffer the same problem?!

When using reboot from main-menu, the screen darkens and the question "restart" appears. After boot, there is a shading that looks nice ... after resume the shading are real circles, which leads me to the opinion, that the color-depth is different ... which could also be seen in plymouth, where there are stripes now

zvaral (z-varallyay) wrote :

I would have some additional comments.

I downloaded some new and old Ubuntu CD images, burned them, booted the computer with the CDs, suspended it and finally resumed it. The interesting result is that this issue is also presented in Ubuntu 10.10 Maverick but not presented in Ubuntu 9.10 Karmic Koala.

In 9.10, after resume, the screen has the same nice shading than before.

The CD image I used is ubuntu-9.10-desktop-amd64.iso.
The related parameters of this ubuntu release (on the CD):

uname -a
Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

X -version

X.Org X Server 1.6.4
Release Date: 2009-9-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server x86_64 Ubuntu
Current Operating System: Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64
Kernel command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash --
Build Date: 26 October 2009 05:19:56PM
xorg-server 2:1.6.4-2ubuntu4 (buildd@)
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.

Changed in xserver-xorg-driver-ati:
importance: Medium → Unknown
Changed in xserver-xorg-driver-ati:
importance: Unknown → Medium
bugbot (bugbot) on 2011-04-28
summary: - Color depth degradation after resume (ATI Mobility Radeon X700)
+ [RV410] Color depth degradation after resume (ATI Mobility Radeon X700)
Redge (redge-online) wrote :

I'm having a problem which might be similar to this one, except the color distortions are even worse.

I have an iMac with a Mobility Radeon HD 2600 XT.

I've included a picture. This is on a fresh install of Ubuntu 12.04 without the fglrx driver installed (as it doesn't install for me and this time I haven't even tried to install it).

I can provide more details if needed. Do you think I'm in the right place here?

zvaral, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-video-ati (Ubuntu):
importance: Medium → Low
status: Triaged → Incomplete
Redge (redge-online) wrote :

I for one am still experiencing this issue on saucy. I've also reported my problem to the xf86-video-ati maintainers:

https://bugs.freedesktop.org/show_bug.cgi?id=70735

They suggested that in my case it might be caused by Apple EFI and to try re-installing with MBR, but I haven't gotten around to trying it out yet.

Redge, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.