[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

Bug #1085751 reported by Dave Gilbert
96
This bug affects 17 people
Affects Status Importance Assigned to Milestone
xorg (Fedora)
Invalid
Undecided
Unassigned
xserver-xorg-video-ati (Ubuntu)
Fix Released
Undecided
Unassigned
Quantal
Won't Fix
Undecided
Unassigned

Bug Description

This is on a machine upgraded from Quantal to Raring.

I switched between two users, and then switched back under KDE and managed to trigger that Failed to parse relocation. It happened (and the screen went blank) at the moment I clicked the 'activate' button on the screen saver to switch back to my original user. Both users running KDE.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.7.0-4-generic 3.7.0-4.12
ProcVersionSignature: Ubuntu 3.7.0-4.12-generic 3.7.0-rc7
Uname: Linux 3.7.0-4-generic x86_64
ApportVersion: 2.6.3-0ubuntu2
Architecture: amd64
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Sun Dec 2 23:49:46 2012
HibernationDevice: RESUME=UUID=985b0eb1-c149-486d-a66d-3113788778b1
InstallationDate: Installed on 2012-07-17 (138 days ago)
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120717)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.7.0-4-generic root=UUID=711860b7-f028-46b1-83bb-c2be5dc8044d ro nointremap crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.7.0-4-generic N/A
 linux-backports-modules-3.7.0-4-generic N/A
 linux-firmware 1.97
RfKill:

SourcePackage: linux
UpgradeStatus: Upgraded to raring on 2012-12-02 (0 days ago)
dmi.bios.date: 09/10/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.50
dmi.board.name: P55M Pro
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.50:bd09/10/2009:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnP55MPro:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

Revision history for this message
In , Loic-yhuel (loic-yhuel) wrote :

Since 3.5.0 kernel (currently 3.5.2-3.fc17.x86_64), resuming from suspend or hibernation randomly fails. There is no display, and the screen flashes every few seconds (probably due to the backlight).

Hardware:
Toshiba Satellite Pro A300 laptop
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series

Here are the relevant kernel messages :
[drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
radeon 0000:01:00.0: WB enabled
radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0xffff880134cc6c00
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
radeon 0000:01:00.0: GPU reset succeed
[drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
...

Revision history for this message
In , agd5f (agd5f) wrote :

Can you bisect?

Revision history for this message
In , Loic-yhuel (loic-yhuel) wrote :

I will try, but it can be long as the problem is not systematic.

Revision history for this message
In , Aaannz (aaannz) wrote :

I am experiencing same problem. My log repeats this messages almost 4times/second:

[drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
radeon 0000:01:00.0: WB enabled
radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880220418c00
[drm] ring test on 0 succeeded in 1 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
radeon 0000:01:00.0: GPU reset succeeded, trying to resume
[drm] probing gen 2 caps for device 8086:29e1 = 2/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0

HW is desktop pc with GPU
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV770 [Radeon HD 4850]

using openSUSE 12.2 with kernel 3.6.3

But I think I didn't encounter this issue back in august when this report was created and I always try to use the latest kernel released. I start to hitting this after upgrading to xorg server 1.13 (default openSUSE has 1.12) and Mesa 9.0 (default openSUSE is Mesa 8.x)

Revision history for this message
In , Aaannz (aaannz) wrote :

Noticed that this can be easily triggered by switching between text and X console few times.

My current versions:
# uname -a
Linux Cerberos 3.6.5-10-desktop #1 SMP PREEMPT Wed Oct 31 20:15:15 UTC 2012 (cefb3b0) x86_64 x86_64 x86_64 GNU/Linux
# rpm -q libdrm_radeon1
libdrm_radeon1-2.4.39-94.1.x86_64

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Does this issue go away if you boot back into the Precise kernel, but stay on a Raring install?

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

(You said Precise, but I assume you mean Quantal since that's what I was previously on - if you really meant precise just ask and I'll try)

I don't seem to be able to trigger it on the Quantal 3.5.0-19, but managed to repeat the failure on the Raring 3.7.0 (same Raring userspace)

My test procedure is to login as myself (in kde); then select switch users from the K menu, and login as my other user,
open a terminal for my other user, and then switch back and forth.
Add firefox with youtube and/or glxgears to taste.

When I first reported this bug I'd just done once to my other user and then it failed when I switched back.

I repeated the failure and it took 2 or 3 round trips.

I'm currently on 3.5.0-19 and have flipped at least 7 or 8 times with no problems.

Dave

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I'd like to perform a bisect to figure out what commit caused this regression. It would be very helpful to know the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

v3.5.7: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.7-quantal/
v3.6 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/
v3.7-rc3: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc3-raring/

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: performing-bisect
Revision history for this message
Id2ndR (id2ndr) wrote :

I encountered this trouble on a laptop upgraded from precise to quantal (linux 3.5.0-19). Using previous linux version (3.2 from precise) or 3.6 from PPA didn't helped. After backuping and removing ~/.{compiz,config,gconf{,d},gnome2} directories, it now works normally. I haven't find the main trouble yet.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Are you now unable to reproduce this bug?

Revision history for this message
Id2ndR (id2ndr) wrote :

I can reproduce the bug when putting back the files I reviously backed up.
However I tried to do the same on a second computer with a new test account and the same file without being able to reproduce the trouble (the first computer wasn't mine but the one of an user that I take care of in my LUG).

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :
Download full text (4.1 KiB)

Hi Joseph,
  this still occurs for me with the 3.5.7 from that link (and with current raring), but as stated not with the 3.5.0-19 from quantal.
My test procedure on my box is:
  * Fresh boot
  * Log in via kdm as my default user
  * Wait for my standard KDE desktop to settle
  * K menu->Leave->Switch user
     * select new session
     * Login as my other user
As my other user:
  * K menu->Leave->Switchuser
  * select the existing session for my main user

And that blew up this time for both 3.7.0-7-generic #15-Ubuntu and 3.5.7-030507-generic #201210130556

and I've checked again, 3.5.0-7 is still good for me - bounced back and forward 5 or 6 times.

I also had a blow up on 3.7.0 when running an SDL game, also triggered the -35

dmesg on the blowups from the user switching test:
3.7.0-7-generic #15-Ubuntu booted, logged in, did switch user, did switch back
   - bang
[ 72.399456] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[ 72.415838] radeon 0000:07:00.0: GPU reset succeeded, trying to resume
[ 72.421887] [drm] probing gen 2 caps for device 8086:d138 = 2/0
[ 72.421890] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[ 72.424721] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 72.424812] radeon 0000:07:00.0: WB enabled
[ 72.424820] radeon 0000:07:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880225f0ac00
[ 72.471175] [drm] ring test on 0 succeeded in 1 usecs
[ 72.671008] [drm] ib test on ring 0 succeeded in 0 usecs
[ 72.671029] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[ 72.687120] radeon 0000:07:00.0: Saved 25 dwords of commands on ring 0.
[ 72.687126] radeon 0000:07:00.0: GPU softreset
[ 72.687131] radeon 0000:07:00.0: R_008010_GRBM_STATUS=0xA0003028
[ 72.687134] radeon 0000:07:00.0: R_008014_GRBM_STATUS2=0x00000002
[ 72.687138] radeon 0000:07:00.0: R_000E50_SRBM_STATUS=0x200000C0
[ 72.687142] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
[ 72.687146] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00010000
[ 72.687149] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00000000
[ 72.687153] radeon 0000:07:00.0: R_008680_CP_STAT = 0x80010042
[ 72.687160] radeon 0000:07:00.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
[ 72.702019] radeon 0000:07:00.0: R_008020_GRBM_SOFT_RESET=0x00000001
[ 72.717870] radeon 0000:07:00.0: R_008010_GRBM_STATUS=0x00003028
[ 72.717874] radeon 0000:07:00.0: R_008014_GRBM_STATUS2=0x00000002
[ 72.717878] radeon 0000:07:00.0: R_000E50_SRBM_STATUS=0x200000C0
[ 72.717882] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
[ 72.717885] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000
[ 72.717889] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00000000
[ 72.717892] radeon 0000:07:00.0: R_008680_CP_STAT = 0x00000000
[ 72.718887] radeon 0000:07:00.0: GPU reset succeeded, trying to resume
[ 72.720137] [drm] probing gen 2 caps for device 8086:d138 = 2/0
[ 72.720139] [drm] enabling PCIE gen 2 link speeds, disable with rad...

Read more...

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Hi,
  Chopped it down a bit further, 3.5.1-030501-generic #201208091310 also triggers,
but I still can't get 3.5.0-19-generic #30-ubuntu to fail.

Haven't tried a mainline 3.5.0 yet.

Dave

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

I can get it to fail with 3.5.0-030500-generic #201207211835

so I guess that's a fairly small gap relative to 3.5.0-19-generic #30.
Is it something we added/unconfigured?

Dave

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

ok, sorry - seems like I was going in the wrong direction there.

So I've had it fail on the 3.5.7-030507 generic but 3.5.0-19-generic #30 works fine
and nothing newer works either.

The number of diffs looks tiny, and I don't see anything obvious.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Rebuilding 3.5.0-19-generic in my raring user space produces a kernel which also doesn't seem to exhibit the bug.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

..and a rebuilt 3.5.7 mainline fails.

Revision history for this message
In , Aaannz (aaannz) wrote :

Since upgrade to kernel 3.7.1 (from openSUSE Tumbleweed) I can no longer replicate this. For me this problem appears to be fixed.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can you test the following kernel:

v3.5.6: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.6-quantal/

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
nyuszika7h (lyokon42) wrote :

I can reproduce this bug on both an Ubuntu 13.04 Raring Ringtail Live USB and an installed system upgraded from Ubuntu 12.10 Quantal Quetzal.

Steps to reproduce:
1. Log in from the graphical interface.
2. Switch to tty1 (Ctrl-Alt-F1)
3. Switch to tty2 (Ctrl-Alt-F2)
4. Switch to X11 [tty7] (Ctrl-Alt-F7)

If you can't reproduce the bug following these steps, you might need to repeat steps 2 to 4 a few times. I wasn't able to reproduce this without first logging in from the graphical interface.

I've installed the 3.5.6 kernel, and I can still reproduce this bug. Although I just grabbed the linux-image and linux-image-extra debs and installed them. I'm not sure if they contain the patches, or if not, how to apply them.

Revision history for this message
nyuszika7h (lyokon42) wrote :

Syslog attached.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

3.5.6-030506-generic #201210130527 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.6-quantal/ failed
(One cycle of switching user and back)

[ 73.068583] [drm] ring test on 0 succeeded in 1 usecs
[ 73.068607] [drm] ib test on ring 0 succeeded in 0 usecs
[ 73.666523] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[ 73.682420] radeon 0000:07:00.0: >GPU reset succeed
[ 73.685254] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 73.685297] radeon 0000:07:00.0: >WB enabled
[ 73.685300] radeon 0000:07:00.0: >fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880225827c00
[ 73.731443] [drm] ring test on 0 succeeded in 1 usecs
[ 73.731467] [drm] ib test on ring 0 succeeded in 0 usecs
[ 74.329648] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
dg@major:~$ uname -a
Linux major 3.5.6-030506-generic #201210130527 SMP Sat Oct 13 09:39:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Those are some interesting results since 3.5.0-19 has the upstream 3.5.7 updates. Can you also test the following two kernels:

v3.5.0-18: https://launchpad.net/ubuntu/+source/linux/3.5.0-18.29
v3.5.0-22: https://launchpad.net/ubuntu/+source/linux/3.5.0-22.34

Look at the links under "Builds" for your specific arch.

This test will see if an Ubuntu Sauce package fixes this bug. The Ubuntu 3.5.0-18.29 kernel has the upstream 3.5.6 updates, so it will confirm what you see in 3.5.0-19.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
In , Ash Hughes (ashes-iontach) wrote :

I am using kernel 3.7.2-201.fc18.x86_64 (Fedora 18) and no libdrm_radeon and am also experiencing this problem. Problem not present in Fedora 17.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Ash: While it's possible the bug watch you added is the same one as this, it's certainly not a slamdunk; it gives the same symptom but I don't know enough about the driver to know if it's actually the same.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Joseph:
  3.5.0-22.34 works nicely; it's done 20 full cycles and still going fine.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

3.5.0-18.29 also works fine.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

and just to confirm 3.8.0-1.5 still exhibits the bug.

[ 329.150568] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[ 329.166480] radeon 0000:07:00.0: GPU softreset: 0x00000007
[ 329.193800] radeon 0000:07:00.0: GPU reset succeeded, trying to resume
[ 329.210521] [drm] probing gen 2 caps for device 8086:d138 = 2/0
[ 329.210524] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_g
en2=0
[ 329.212664] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 329.212725] radeon 0000:07:00.0: WB enabled
[ 329.212729] radeon 0000:07:00.0: fence driver on ring 0 use gpu addr 0x000000
0020000c00 and cpu addr 0xffff880226ce7c00
[ 329.212731] radeon 0000:07:00.0: fence driver on ring 3 use gpu addr 0x000000
0020000c0c and cpu addr 0xffff880226ce7c0c
[ 329.259169] [drm] ring test on 0 succeeded in 1 usecs
[ 329.259229] [drm] ring test on 3 succeeded in 1 usecs
[ 329.259251] [drm] ib test on ring 0 succeeded in 0 usecs
[ 329.259270] [drm] ib test on ring 3 succeeded in 1 usecs

Changed in fedora:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
In , Jeff Fortin Tam (kiddo) wrote :

Downstream reports:
https://bugzilla.redhat.com/show_bug.cgi?id=883536
https://bugzilla.redhat.com/show_bug.cgi?id=849347

I'm kinda wondering if this has something to do with 64-bits (probably not, as comment 6 hints that this was not present in Fedora 17 64-bits).

Revision history for this message
In , agd5f (agd5f) wrote :

Can anyone bisect and track down what broke it?

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

It would be really helpful to be able to identify the last good and first bad upstream kernels. Then we can bisect to find the commit that caused this regression. It appears an Ubuntu SAUCE patch fixes this issue, but I've been unable to identify which one.

Can you test the following kernel:
v3.5-rc4: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc4-quantal/

If it also exhibits the bug, please test:
v3.5-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc1-quantal/

Revision history for this message
In , Jeff Fortin Tam (kiddo) wrote :

I don't think I have the knowledge to build (and git bisect!) my own driver, however there is some additional clue I can give from https://bugzilla.redhat.com/show_bug.cgi?id=883536 :

the issue does not seem to be strictly related to suspend & resume. It is very easy to trigger the problem in Fedora 18 by booting up to the GDM login screen, switching to another virtual terminal by pressing ctrl+alt+F3, then trying to switch back to GDM by doing ctrl+alt+F1.

Chris Van Hoof (vanhoof)
tags: added: blocks-hwcert-enablement
Changed in linux (Ubuntu Quantal):
importance: Undecided → Medium
status: New → Incomplete
assignee: nobody → Timo Aaltonen (tjaalton)
Changed in hwe-next:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Chris Van Hoof (vanhoof)
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
no longer affects: hwe-next/quantal
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
no longer affects: hwe-next
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
no longer affects: hwe-next
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
Chris Van Hoof (vanhoof)
no longer affects: hwe-next
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

3.5-rc4 3.5.0-030500rc4-generic #201206241635 exhibits the bug

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

3.5.0-030500rc1-generic #201206022335 also fails.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Chris Van Hoof: Can you explain why you've got Precise and Quantal tasks on here?
If you look through the bug you'll see that Quantal kernels work fine for me, this only failed for me after an upgrade to Raring,
and usign the Quantal kernels of the time was fine.

Revision history for this message
Alberto Milone (albertomilone) wrote :

well, we have Quantal's backported kernels in Precise, hence the Precise task.

Changed in linux (Ubuntu Precise):
importance: Undecided → Medium
status: New → Incomplete
tags: removed: performing-bisect
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Upstream pointed out that this commit should fix it for evergreen gpu's:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=bb588820ef421c6098dca1fec29c3b347f1c8c19

there is a similar commit for earlier gpu's, both sent to the stable list so they should end up in 3.5 before too long.

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Timo: Can you explain why you believe that patch is relevant to this bug?
To me that patch looks like something on the display hardware side, and I thought the -35's were some sort of memory allocation screw up (but I may be wrong)?

Revision history for this message
Claude Durocher (claude-d) wrote :

I can confirm this bug on a Precise installation with the new Quantal backported kernel and xorg :

laptop:~$ uname -a
Linux laptop 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux

laptop:~$ lspci | grep VGA
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Mobility Radeon HD 5000 Series]

The problem occurs after resume and can be easily triggered with ctrl-alt-f1 ctrl-alt-f3 combinaison.

Seems like the guys at Fedora fixed it already : https://bugzilla.redhat.com/show_bug.cgi?id=849347#c63

Revision history for this message
Matthew Mott (orbweaver) wrote :

Confirmed on Quantal with kernel 3.5.0-25-generic and a Radeon HD4850 [RV770].

Changed in linux (Ubuntu Quantal):
status: Incomplete → Confirmed
Revision history for this message
coolman (coolman7) wrote :

I have the same problem with 3.5.0-25 kernel on ubuntu 12.04.2 LTS and I had same problem with ubuntu 12.10. By the it seems that fedora team solved the problem with xorg-x11-drv-ati-7.0.0-0.9 driver. Is it possible to use the same driver with ubuntu?

Thanks

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Hi ClaudeD, Matthew, Coolman,
  Hmph - that's really interesting; for me on my Raring box it fails reliably, but I've never got a Quantal kernel to fail (see above).

Revision history for this message
Claude Durocher (claude-d) wrote :

Problem still exist with 3.5.0-27-generic #46~precise1-Ubuntu SMP.

Is someone at Cannonical working seriously on this?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Dave: that's not the same bug then, the upstream/fedora patch is in the -ati driver version 7.1.0, which raring has had for some time.

Changed in xserver-xorg-video-ati (Ubuntu):
status: New → Fix Released
Revision history for this message
Jose Carlos Garcia Sogo (jsogo) wrote :

I have just updated to Raring and I am hit by this bug. It happens with a ATI Radeon HD4330, and it is triggered each time I suspend or hibernate the laptop, which is quite nasty. As this is a lenghty bug, I would like to provide any useful information you may request.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-ati (Ubuntu Precise):
status: New → Confirmed
Changed in xserver-xorg-video-ati (Ubuntu Quantal):
status: New → Confirmed
Revision history for this message
Claude Durocher (claude-d) wrote :

Tested with raring : cannot reproduce the problem. I only had it with the 3.5 kernel on my machine.

Revision history for this message
penalvch (penalvch) wrote :

Dave Gilbert, as per http://www.asrock.com/mb/Intel/P55M%20Pro/?cat=Download&os=BIOS an update is available for your BIOS (2.30). If you update to this, does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Thank you for your understanding.

tags: added: bios-outdated-2.30 needs-upstream-testing regression-potential
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Timo Aaltonen (tjaalton)
Changed in linux (Ubuntu Quantal):
assignee: Timo Aaltonen (tjaalton) → nobody
Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Closing unsupported series nomination.

This bug was nominated against a series that is no longer supported, ie quantal. The bug task representing the quantal nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Quantal):
status: Confirmed → Won't Fix
Revision history for this message
Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in xserver-xorg-video-ati (Ubuntu Quantal):
status: Confirmed → Won't Fix
no longer affects: hwe-next
Revision history for this message
In , jecks (slayerproof32) wrote :

Created attachment 141375
Screen when resuming on RV610 gpu

Revision history for this message
In , jecks (slayerproof32) wrote :

Hello all, my RV610 gpu has issues when resuming. I usually get the screen i posted. When that screen appears, the only solution ive found is to Ctrl+alt+f3 and reboot the system. That screen will sometimes flicker, or even briefly show the login screen before going back to it. One day I noticed some messages maybe describing the bug shown in attachment 2

Relevant Dmesg|grep radeon

[ 12.079128] [drm] radeon kernel modesetting enabled.
[ 12.079207] fb: switching to radeondrmfb from VESA VGA
[ 12.079781] radeon 0000:01:00.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
[ 12.079783] radeon 0000:01:00.0: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF
[ 12.084832] [drm] radeon: 256M of VRAM memory ready
[ 12.084834] [drm] radeon: 512M of GTT memory ready.
[ 13.837201] [drm] radeon: power management initialized
[ 13.868698] radeon 0000:01:00.0: WB enabled
[ 13.868702] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0x00000000196569de
[ 13.869146] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x00000000000521d0 and cpu addr 0x000000000d3aa4f8
[ 13.869151] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 13.869201] radeon 0000:01:00.0: radeon: using MSI.
[ 13.869226] [drm] radeon: irq initialized.
[ 14.843499] fbcon: radeondrmfb (fb0) is primary device
[ 14.869372] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 14.888793] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor

Revision history for this message
In , jecks (slayerproof32) wrote :

I dont understand why "attachment 2" was highlighted. sorry

Revision history for this message
In , jecks (slayerproof32) wrote :

Created attachment 141376
Possible error messages relating to the bug

penalvch (penalvch)
affects: fedora → xorg (Fedora)
Changed in xorg (Fedora):
importance: High → Undecided
status: Confirmed → New
no longer affects: linux (Ubuntu Quantal)
no longer affects: linux (Ubuntu Precise)
no longer affects: linux (Ubuntu)
penalvch (penalvch)
Changed in xorg (Fedora):
status: New → Invalid
penalvch (penalvch)
no longer affects: xserver-xorg-video-ati (Ubuntu Precise)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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