Ubuntu

Unusable graphics with ATI RS690M

Reported by Stefan Bader on 2012-07-26
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
linux (Ubuntu)
High
Stefan Bader

Bug Description

Release: Quantal (20120726/alpha3)
Architecture: i386 (but also seen on amd64)

Using the alternate CD installation works ok, but rebooting into the install I am lucky if I get anything on the screen that resembles the lightdm screen (screenshot of that case will be attached). There were also cases of just white or just black. Login is impossible and occasionally everything goes downhill. Ssh login is possible or booting into textual mode.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xorg 1:7.7+1ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic i686
ApportVersion: 2.4-0ubuntu5
Architecture: i386
CurrentDmesg:
 [ 23.804204] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
 [ 23.804504] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Date: Thu Jul 26 19:24:26 2012
DistUpgraded: Fresh install
DistroCodename: quantal
DistroVariant: ubuntu
GraphicsCard:
 Advanced Micro Devices [AMD] nee ATI RS690M [Radeon X1200 Series] [1002:791f] (prog-if 00 [VGA controller])
   Subsystem: Dell Device [1028:01fc]
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha i386 (20120724.3)
MachineType: Dell Inc. Inspiron 1521
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-6-generic root=UUID=4ec19e6c-f6cc-4b34-9605-fef3559ebfdd ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/16/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0GU163
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA00:bd05/16/2007:svnDellInc.:pnInspiron1521:pvr:rvnDellInc.:rn0GU163:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Inspiron 1521
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.8+bzr3249-0ubuntu2
version.libdrm2: libdrm2 2.4.37-0ubuntu2
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.3-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.3-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.12.1.902-1ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~really6.14.4-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.19.0-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.1-1build1

Created attachment 63356
Xorg.0.log

This happened early May on drm-next somewhere between 4f256e8..d3029b4, and is still there in 3.5rc3 (and in current drm-next).

Things are smeared out vertically. Looks like desktop background is not corrupted. By turning off "EXABitmaps" there is less corruption.

I haven't done git bisecting, only download bisecting from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/ and v3.4-rc6-295-g4f256e8 from May 8th was good and v3.4-rc6-315-gd3029b4 from May 10th was bad. Unfortunately the build from May 9th has been deleted in the meantime so I can not narrow it down further this way. So the commits in question should be:

d3029b4 drm/radeon/kms: fix warning on 32-bit in atomic fence printing
f2e3922 drm/radeon: make the ib an inline object
f237750 drm/radeon: remove r600 blit mutex v2
68470ae drm/radeon: move the semaphore from the fence into the ib
7c0d409 drm/radeon: immediately free ttm-move semaphore
c507f7e drm/radeon: rip out the ib pool
a8c0594 drm/radeon: simplify semaphore handling v2
c3b7fe8 drm/radeon: multiple ring allocator v3
0085c950 drm/radeon: use one wait queue for all rings add fence_wait_any v2
557017a drm/radeon: define new SA interface v3
2e0d991 drm/radeon: make sa bo a stand alone object
e6661a9 drm/radeon: keep start and end offset in the SA
711a972 drm/radeon: add sub allocator debugfs file
a651c55 drm/radeon: add proper locking to the SA v3
dd8bea2 drm/radeon: use inline functions to calc sa_bo addr
8a47cc9 drm/radeon: rework locking ring emission mutex in fence deadlock detection v2
3b7a2b2 drm/radeon: rework fence handling, drop fence list v7
bb63556 drm/radeon: convert fence to uint64_t v4
d6999bc drm/radeon: replace the per ring mutex with a global one
133f4cb drm/radeon: fix possible lack of synchronization btw ttm and other ring

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Radeon Mobility X700 (PCIE) [1002:5653]

Created attachment 63357
dmesg output

Created attachment 63359
screenshot (no xorg.conf options)

Can you try to bisect this using git bisect and find the first bad commit?

Sorry, I don't know when I can have time to do that. I'll try harder if the bug can be confirmed by other people too. Maybe the right developer can make an educated guess if it's limited to this card.

Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :

The last 4 files may be some that apport would have collected if it would not crash upon trying different names.

Stefan Bader (smb) on 2012-07-26
Changed in xorg (Ubuntu):
importance: Undecided → High
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :

Though same happens when only the LVTS is used.

Stefan Bader (smb) wrote :

Adding a dummy screen section which sets "NoAccel" allows to start the GUI at least in Unity2D mode.

Bryce Harrington (bryce) on 2012-08-01
affects: xorg (Ubuntu) → xserver-xorg-video-ati (Ubuntu)
Stefan Bader (smb) wrote :

Tested today after enabling quantal-proposed and pulling the new X drivers. Result is the same (corruption/hangs) with acceleration enabled.

Hi guys,

can this be related to

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

?

I ended up in the same area of the git log.

Also can you test if booting with radeon.no_wb=1 fix the issue ?

Thanks, will test this later. BTW I already tried http://people.freedesktop.org/~glisse/0001-drm-radeon-extra-type-safe-for-fence-emission.patch which came up on the dri-devel list, but that did not fix it.

No, booting with radeon.no_wb=1 didn't help.

Created attachment 66942
backport of Christian's patch

I tried backporting Christian's patch from https://bugs.freedesktop.org/show_bug.cgi?id=54129#c11 but it did not help either. I suppose the following /sys/kernel/debug/dri/0/radeon_fence_info output indicates that the patch took effect, since the emitted numbers are above 0x100000000LL?

--- ring 0 ---
Last signaled fence 0x000000020000149f
Last emitted 0x0000000100001a9a

--- ring 0 ---
Last signaled fence 0x000000020000149f
Last emitted 0x0000000100002041

--- ring 0 ---
Last signaled fence 0x000000020000149f
Last emitted 0x000000010000294a

Created attachment 66986
backport of Christian's v2 patch

I tried backporting the v2 patch from http://lists.freedesktop.org/archives/dri-devel/2012-September/027608.html to kernel 3.5.2, see attached, but it did not help either. Maybe my card has another issue?

Output from /sys/kernel/debug/dri/0/radeon_fence_info

--- ring 0 ---
Last signaled fence 0x00000000deadbeef
Last emitted 0x0000000000000670

--- ring 0 ---
Last signaled fence 0x00000000deadbeef
Last emitted 0x0000000000000c44

(In reply to comment #10)
> Output from /sys/kernel/debug/dri/0/radeon_fence_info
>
> --- ring 0 ---
> Last signaled fence 0x00000000deadbeef
> Last emitted 0x0000000000000670
>
> --- ring 0 ---
> Last signaled fence 0x00000000deadbeef
> Last emitted 0x0000000000000c44

WTF? Well that's a very interesting information you've got us here, thanks allot.

"deadbeef" is a pattern we usually use for ring and IB tests, and I have no idea how that ended up as last signaled fence value.

Could you try Jeromes debugging patch (http://people.freedesktop.org/~glisse/0001-debug-fence-emission-reception.patch) and attach the resulting output.

Thx,
Christian.

Created attachment 67047
Possible fix

Please give the attached V3 version of the patch a try, it adds the last emitted fence as an upper limit and so should be able to even handle "deadbeef" values.

Cheers,
Christian.

Yes, v3 works! I applied it to 3.5.2 by replacing rdev->fence_drv[ring].sync_seq[ring] with rdev->fence_drv[ring].seq and there is no more corruption. The /sys/kernel/debug/dri/0/radeon_fence_info is now in sync, or off by one:

--- ring 0 ---
Last signaled fence 0x0000000000002651
Last emitted 0x0000000000002652
--- ring 0 ---
Last signaled fence 0x0000000000002703
Last emitted 0x0000000000002704

Do you still want me to run the debug patch? It seems you are not sure about the 0xdeadbeef and there could be other bugs?

Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-video-ati (Ubuntu):
status: New → Confirmed
Stefan Bader (smb) wrote :

Ok, seems that the problem is somewhere in the radeon driver in the kernel as installing a 3.2 kernel would boot with usable graphics. Though frankly that is still X guys kinda domain to me.

affects: xserver-xorg-video-ati (Ubuntu) → linux (Ubuntu)
Stefan Bader (smb) wrote :
Stefan Bader (smb) wrote :

This bug seems to be fixed between 3.6-rc5 snf 3.6-rc6. The most likely suspect would be:

commit f492c171a38d77fc13a8998a0721f2da50835224
Author: Christian König <email address hidden>
Date: Thu Sep 13 10:33:47 2012 +0200

    drm/radeon: make 64bit fences more robust v3

    Only increase the higher 32bits if we really detect a wrap around.

The patch mentions that this requires a different fix for 3.5 which is supposed to be submitted separately.

Stefan Bader (smb) wrote :

The backport was submitted to the stable mailing list (but right now not yet picked up). I applied it to our latest Quantal kernel and it did fix the graphics issues I was seeing.

Changed in linux (Ubuntu):
assignee: nobody → Stefan Bader (stefan-bader-canonical)
status: Confirmed → In Progress
tags: added: patch
Stefan Bader (smb) on 2012-09-25
Changed in linux (Ubuntu):
status: In Progress → Fix Committed
irv (irv-hbci) wrote :

Does this mean I can download it and it will be fixed? I just tried it again this morning and it was the same.

Stefan Bader (smb) wrote :

Not if you do not compile your own kernel. Fix committed, here means it was added to the git repo. When the next official kernel is build this should go into "fix released" and then it can be downloaded. The current kernel version is 3.5.0-15.23. The next one will be either -15.24 or -16.24.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.5.0-16.24

---------------
linux (3.5.0-16.24) quantal-proposed; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: ata_piix: add a disable_driver option
    - LP: #994870

  [ Christian König ]

  * (pre-stable) drm/radeon: make 64bit fences more robust v3 (3.5 stable)
    - LP: #1029582

  [ David Henningsson ]

  * SAUCE: ALSA: hda - use both input paths on Conexant auto parser
    - LP: #1037642
  * SAUCE: ALSA: hda - fix control names for multiple speaker out on
    IDT/STAC
    - LP: #1046734

  [ Herton Ronaldo Krzesinski ]

  * SAUCE: ALSA: hda/via - don't report presence on HPs with no presence
    support
    - LP: #1052499
  * SAUCE: ext4: fix crash when accessing /proc/mounts concurrently
    - LP: #1053019
  * SAUCE: ALSA: hda/realtek - Fix detection of ALC271X codec
    - LP: #1006690

  [ Kyle Fazzari ]

  * SAUCE: input: Cypress PS/2 Trackpad fix disabling tap-to-click
    - LP: #1048816

  [ Leann Ogasawara ]

  * [Config] Disable CONFIG_DRM_AST
    - LP: #1053290

  [ Stefan Bader ]

  * [Config] Disable the Cirrus QEMU drm driver
    - LP: #1038055

  [ Upstream Kernel Changes ]

  * Revert "KVM: VMX: Fix KVM_SET_SREGS with big real mode segments"
    - LP: #1045027
  * x86, efi: Handover Protocol
  * drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
    - LP: #1056729
  * UBUNTU SAUCE: apparmor: fix IRQ stack overflow
    - LP: #1056078
  * drm/nouveau: fix booting with plymouth + dumb support
    - LP: #1043518
  * ALSA: hda - Add DeviceID for Haswell HDA
    - LP: #1057698
  * ALSA: hda - add Haswell HDMI codec id
    - LP: #1057698
  * ALSA: hda - Fix driver type of Haswell controller to AZX_DRIVER_SCH
    - LP: #1057698
  * ALSA: hda_intel: Add Device IDs for Intel Lynx Point-LP PCH
    - LP: #1011438, #1057698

  [ Wang Xingchao ]

  * SAUCE: ALSA: hda - Add another pci id for Haswell board
    - LP: #1057698

  [ Wen-chien Jesse Sung ]

  * SAUCE: drm/i915: Explicitly disable RC6 for certain models
    - LP: #1002170, #1008867
 -- Leann Ogasawara <email address hidden> Thu, 27 Sep 2012 13:55:52 -0700

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released

Applied in 3.5.5.

Great, sounds like we can close the bug now.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Fix Released

A patch referencing this bug report has been merged in Linux v3.6-rc6:

commit f492c171a38d77fc13a8998a0721f2da50835224
Author: Christian König <email address hidden>
Date: Thu Sep 13 10:33:47 2012 +0200

    drm/radeon: make 64bit fences more robust v3

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

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.