Bug 26302

Summary: [M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: emmanuel.touzery, jamie, marc.deslauriers, thomas, vish
Version: 7.4 (2008.09)   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/507148
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
XorgLog.txt
none
CurrentDmesg.txt
none
BootDmesg.txt
none
T42 dmesg after updating to latest drivers
none
T42 Xorg.log after using updated drivers
none
kern.log with backported drm from .33
none
fallback on VRAM memory placement
none
don't print pointless errors. none

Description Bryce Harrington 2010-01-28 10:50:21 UTC
Users with this card are reporting that their systems either do not boot up (systems with 16MB video ram) or lose compiz shortly after booting (systems with 32MB).  dmesg indicates TTM has run out of memory:

[ 213.812640] [TTM] Failed moving buffer. Proposed placement 0x00060004
[ 213.812650] [TTM] Out of aperture space or DRM memory quota.
[ 213.812660] [drm:radeon_object_create] *ERROR* Failed to allocate TTM object (5914624, 0x00060004, 0)
[ 213.812667] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (5914624, 4, 4096)

[Original Report]
The livecd will not boot to the desktop. Selecting "install" from the boot menu will install lucid, but after typing in password at gdm screen, desktop session will not start.
This is with the 20100113 lucid i386 livecd on a Thinkpad T30.

Architecture: i386
Date: Wed Jan 13 14:32:59 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100113)
MachineType: IBM 236684U
Package: xorg 1:7.5+1ubuntu1
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-10-generic root=UUID=6420e365-513d-4f8d-97b7-552d3b37da8c ro quiet splash
ProcEnviron:
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-10.14-generic
RelatedPackageVersions:
 xserver-xorg 1:7.5+1ubuntu1
 libgl1-mesa-glx 7.7-0ubuntu4
 libdrm2 2.4.17-0ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20091125.0061c4db-0ubuntu2
Uname: Linux 2.6.32-10-generic i686
dmi.bios.date: 08/08/2005
dmi.bios.vendor: IBM
dmi.bios.version: 1IET70WW (2.09 )
dmi.board.name: 236684U
dmi.board.vendor: IBM
dmi.chassis.type: 10
dmi.chassis.vendor: IBM
dmi.product.name: 236684U
dmi.sys.vendor: IBM
Comment 1 Bryce Harrington 2010-01-28 10:51:44 UTC
Created attachment 32876 [details]
XorgLog.txt

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] [1002:4c57]
	Subsystem: IBM Device [1014:0517]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+ DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 66 (2000ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at 2000 [size=256]
	Region 2: Memory at d0100000 (32-bit, non-prefetchable) [size=64K]
	[virtual] Expansion ROM at d0120000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: radeon
	Kernel modules: radeonfb, radeon
Comment 2 Bryce Harrington 2010-01-28 10:51:58 UTC
Created attachment 32877 [details]
CurrentDmesg.txt
Comment 3 Bryce Harrington 2010-01-28 10:52:13 UTC
Created attachment 32878 [details]
BootDmesg.txt
Comment 4 Bryce Harrington 2010-01-28 10:53:07 UTC
Fwiw, a very similar bug was reported against -nouveau too:
https://bugs.freedesktop.org/show_bug.cgi?id=24810
Comment 5 Jamie Strandboge 2010-01-28 11:33:41 UTC
I am one of the people seeing this in the Launchpad bug. I've got an IBM T42 with the radeon 7500 (but with 32MB video ram).

Disabling KMS and compiz so far seems to make things better.
Comment 6 Jerome Glisse 2010-02-09 01:06:11 UTC
Same as :
https://bugzilla.redhat.com/show_bug.cgi?id=529081
Comment 7 Jamie Strandboge 2010-02-09 07:14:54 UTC
I have tried various things to help diagnose this. To enable/disable KMS, I pass radeon.modeset=1 or 0 (respectively). To enable compiz, I turn on desktop effects from within the System/Preferences/Appearance/Visual Effects in Ubuntu. Checking Xorg.0.log, with KMS, EXA is enabled by default. Without KMS, XAA is disabled by default. To force EXA or XAA, I create a simple xorg.conf and use AccelMethod. Performance based on general responsiveness and resizing firefox windows. 

Here are my findings:

* KMS/EXA/compiz: compiz crash (out of memory) (this bug, fairly easy to reproduce with a couple of large applications (firefox and OO.o))
* KMS/EXA/no compiz: lockup, but much harder to reproduce (saw it once after several hours of use)
* no KMS/XAA/compiz: lockup and garbling (https://launchpad.net/bugs/513950, https://launchpad.net/bugs/513956)
* no KMS/XAA/no compiz (stable after several full days of use, but needs RenderAccel "off" due to https://launchpad.net/bugs/513968)
* no KMS/forced EXA/compiz: limited testing, seems stable, but performance is very poor. Had difficulty turning on compiz in all circumstances (see this comment: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/513950/comments/4)
* no KMS/forced EXA/no compiz: limited testing, seems stable, but performance is very poor

Performance with EXA and KMS is generally good. Performance with EXA and without KMS is very poor. Performance with XAA without KMS is better than EXA with KMS.

Note that I tried to force XAA when using KMS, by using AccelMethod "XAA", but EXA was used anyway. Xorg.0.log gave:
...
(**) RADEON(0): Option "AccelMethod" "XAA"
...
(II) RADEON(0): EXA: Driver will not allow EXA pixmaps in VRAM
...
(II) Loading sub module "exa"
(II) LoadModule: "exa"
(II) Loading /usr/lib/xorg/modules/libexa.so
(II) Module exa: vendor="X.Org Foundation"
        compiled for 1.7.3.902, module version = 2.5.0
        ABI class: X.Org Video Driver, version 6.0
(--) Depth 24 pixmap format is 32 bpp
(II) RADEON(0): [DRI2] Setup complete
(II) RADEON(0): Front buffer size: 5808K
(II) RADEON(0): VRAM usage limit set to 20577K
(==) RADEON(0): Backing store disabled
(II) RADEON(0): Direct rendering enabled
(II) RADEON(0): Render acceleration enabled for R100 type cards.
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen
(II) RADEON(0): Acceleration enabled
(==) RADEON(0): DPMS enabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Set up textured video

This unsurprisingly resulted in the same out of memory bugs as KMS/EXA tests above.
Comment 8 Alex Deucher 2010-02-09 07:17:25 UTC
XAA doesn't work with KMS.  Is there any chance you could try the drm from the soon to be released 2.6.33 and the latest fixes from the mesa 7.7 branch?
Comment 9 Jamie Strandboge 2010-02-09 07:20:45 UTC
I'd be happy to test anything to get this bug resolved. I'll need help from Bryce for this testing though.
Comment 10 Bryce Harrington 2010-02-09 09:39:24 UTC
Jamie, you should be able to get what you need out of xorg-edgers and the kernel team's kernel crack ppa.

[Btw, take care not to block on needing something from me, as I'm utterly swamped with non-bug work currently (and may be so for a while).]
Comment 11 Jamie Strandboge 2010-02-09 10:17:18 UTC
Bryce, all the help I needed was making sure I had the latest drivers with matched libraries. Since you say that is all in xorg-edgers, that's really I all need (thanks).

Running kernel 2.6.33-020633rc7-generic with the following from xorg-edgers:
libdrm-intel1 2.4.17+git20100209.fdcde592-0ubuntu0sarvatt
libdrm-nouveau1 2.4.17+git20100209.fdcde592-0ubuntu0sarvatt
libdrm-radeon1 2.4.17+git20100209.fdcde592-0ubuntu0sarvatt
libdrm2 2.4.17+git20100209.fdcde592-0ubuntu0sarvatt
libgl1-mesa-dri 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3
libgl1-mesa-glx 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3
libglu1-mesa 7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3
xserver-common 2:1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubuntu0sarvatt3
xserver-xorg-core 2:1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubuntu0sarvatt3
xserver-xorg-input-evdev 1:2.3.2+git20100121.e81cd935-0ubuntu0sarvatt
xserver-xorg-input-synaptics 1:1.2.0+git20100120.f7559a5e-0ubuntu0sarvatt
xserver-xorg-video-ati 1:6.12.99+git20100205.b7ca1ab1-0ubuntu0sarvatt
xserver-xorg-video-intel 2:2.10.0+git20100209.41784e15-0ubuntu0sarvatt
xserver-xorg-video-radeon 1:6.12.99+git20100205.b7ca1ab1-0ubuntu0sarvatt
xserver-xorg-video-vesa 1:2.3.0~git20100120.069c1f82-0ubuntu0sarvatt2

Preliminary testing shows things seem better with KSM/EXA/compiz. I will run this configuration over the next few days and will report back either way.
Comment 12 Jamie Strandboge 2010-02-09 11:55:49 UTC
So far no compiz crashes or X lockups, but I do see in dmesg:
[ 1619.165507] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1621.021223] radeon 0000:01:00.0: f68b6a00 reserve failed for wait
[ 1622.019113] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1625.180631] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1635.140476] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1638.083010] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1651.321702] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1654.865365] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1796.527251] radeon 0000:01:00.0: f2e8a900 reserve failed for wait
[ 1812.721192] radeon 0000:01:00.0: f3ddc100 reserve failed for wait
[ 1812.950009] radeon 0000:01:00.0: f2e8a600 reserve failed for wait
[ 1827.848932] radeon 0000:01:00.0: f3ddc100 reserve failed for wait
[ 2030.822699] radeon 0000:01:00.0: f0b5fc00 reserve failed for wait
[ 2077.402390] radeon 0000:01:00.0: f0b5fc00 reserve failed for wait
[ 2133.374053] radeon 0000:01:00.0: f4197900 reserve failed for wait
[ 2138.921975] radeon 0000:01:00.0: f4197900 reserve failed for wait
[ 2176.425268] radeon 0000:01:00.0: f68b6a00 reserve failed for wait
[ 2182.572320] radeon 0000:01:00.0: f4197900 reserve failed for wait
[ 2294.752798] radeon 0000:01:00.0: f0b5ed00 reserve failed for wait
[ 2305.080870] radeon 0000:01:00.0: f4197900 reserve failed for wait
[ 2306.921465] radeon 0000:01:00.0: f4197900 reserve failed for wait
[ 2324.561097] radeon 0000:01:00.0: f68b6a00 reserve failed for wait
[ 2353.239300] radeon 0000:01:00.0: f11f1100 reserve failed for wait
[ 2386.327292] radeon 0000:01:00.0: f0b5ff00 reserve failed for wait
[ 2387.067951] radeon 0000:01:00.0: f68b6a00 reserve failed for wait
[ 2387.880629] radeon 0000:01:00.0: f0b5ff00 reserve failed for wait
Comment 13 Jamie Strandboge 2010-02-10 09:21:59 UTC
I installed the following from xorg-edgers:
libdrm2_2.4.17+git20100209.fdcde592-0ubuntu0sarvatt_i386.deb
libdrm-intel1_2.4.17+git20100209.fdcde592-0ubuntu0sarvatt_i386.deb
libdrm-nouveau1_2.4.17+git20100209.fdcde592-0ubuntu0sarvatt_i386.deb
libdrm-radeon1_2.4.17+git20100209.fdcde592-0ubuntu0sarvatt_i386.deb
libgl1-mesa-dri_7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3_i386.deb
libgl1-mesa-glx_7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3_i386.deb
libglu1-mesa_7.8.0~git20100207.1a45c2bc-0ubuntu0sarvatt3_i386.deb
radeontool_1.5+git+20091128-0ubuntu0tormod_i386.deb
xserver-common_2%3a1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubuntu0sarvatt3_all.deb
xserver-xorg-core_2%3a1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubuntu0sarvatt3_i386.deb
xserver-xorg-input-evdev_1%3a2.3.2+git20100121.e81cd935-0ubuntu0sarvatt_i386.deb
xserver-xorg-input-synaptics_1%3a1.2.0+git20100120.f7559a5e-0ubuntu0sarvatt_i386.deb
xserver-xorg-video-ati_1%3a6.12.99+git20100205.b7ca1ab1-0ubuntu0sarvatt_i386.deb
xserver-xorg-video-intel_2%3a2.10.0+git20100209.41784e15-0ubuntu0sarvatt_i386.deb
xserver-xorg-video-radeon_1%3a6.12.99+git20100205.b7ca1ab1-0ubuntu0sarvatt_i386.deb
xserver-xorg-video-vesa_1%3a2.3.0~git20100120.069c1f82-0ubuntu0sarvatt2_i386.deb

I tried using 2.6.33-rc7 from the Ubuntu kernel dailies. This kernel was very slow (unrelated to this bug-- it seemed to be IO or possibly filesystem related).

I then tried the backported radeon fixes for the Ubuntu Lucid kernel as mentioned in the Launchpad bug:
"can someone one please test the kernel in the link below and report results back here ? http://people.ubuntu.com/~manjo/lp507148-lucid/
This kernel has the radeon fixes that might fix this issue."

Using KMS/EXA/compiz, this kernel did not crash compiz nearly as quickly on my T42, but after prolonged usage compiz crashed with this in dmesg:

[15040.618564] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
[16936.764884] [TTM] Failed moving buffer. Proposed placement 0x00060004
[16936.764891] [TTM] Out of aperture space or DRM memory quota.
[16936.764895] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
[16936.764898] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
[17015.483860] Unpin not necessary for d095f600 !

Using plymouth with KMS results in a system lockup very early during boot (with no output that I could see).

Marc Deslauriers mentioned in the Launchpad bug that his T30 (16MB of video ram as opposed to my 32MB) did not show any significant improvement with the xorg-edgers packages and backported radeon fixes.

I might also mention that connecting my T42 to an external 1680x1050 monitor (my LCD is 1400x1050) would make compiz crash readily when using xrandr.
Comment 14 Jamie Strandboge 2010-02-10 09:26:34 UTC
Created attachment 33219 [details]
T42 dmesg after updating to latest drivers
Comment 15 Jamie Strandboge 2010-02-10 09:27:15 UTC
Created attachment 33220 [details]
T42 Xorg.log after using updated drivers
Comment 16 Jamie Strandboge 2010-02-11 06:31:16 UTC
More backports from Manoj on our Ubuntu kernel did not solve the issue. From the launchpad bug:

KMS/EXA/compiz still does not work. The following is from kern.log. Compiz crashing did not occur until 'Feb 11 08:03:07', but there seemed to be problems before then too:

Feb 10 14:35:44 lupin kernel: [ 62.914451] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 10 14:37:46 lupin kernel: [ 185.291637] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 10 15:07:14 lupin kernel: [ 1952.805591] [TTM] Failed moving buffer. Proposed placement 0x00060004
Feb 10 15:07:14 lupin kernel: [ 1952.805601] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
Feb 10 15:07:14 lupin kernel: [ 1952.805604] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Feb 10 17:46:34 lupin kernel: [11512.724244] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 10 17:48:58 lupin kernel: [11656.683713] [TTM] Failed moving buffer. Proposed placement 0x00060004
Feb 10 17:48:58 lupin kernel: [11656.683721] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
Feb 10 17:48:58 lupin kernel: [11656.683725] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Feb 10 23:05:59 lupin kernel: [30677.701509] ipw2200: Firmware error detected. Restarting.
Feb 11 07:17:34 lupin kernel: [60173.557731] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 11 07:17:35 lupin kernel: [60173.785871] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 11 07:35:38 lupin kernel: [61257.151019] [TTM] Failed moving buffer. Proposed placement 0x00060004
Feb 11 07:35:38 lupin kernel: [61257.151027] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
Feb 11 07:35:38 lupin kernel: [61257.151030] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Feb 11 07:39:25 lupin kernel: [61483.682603] [TTM] Failed moving buffer. Proposed placement 0x00060004
Feb 11 07:39:25 lupin kernel: [61483.682611] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
Feb 11 07:39:25 lupin kernel: [61483.682614] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Feb 11 07:47:07 lupin kernel: [61946.073790] [drm:radeon_object_busy_domain] *ERROR* radeon: failed to reserve object for waiting.
Feb 11 08:03:07 lupin kernel: [62906.436901] [TTM] Failed moving buffer. Proposed placement 0x00060004
Feb 11 08:03:07 lupin kernel: [62906.436908] [TTM] Out of aperture space or DRM memory quota.
Feb 11 08:03:07 lupin kernel: [62906.436912] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
Feb 11 08:03:07 lupin kernel: [62906.436915] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Comment 17 Jamie Strandboge 2010-03-01 07:30:35 UTC
After trying the fully-backported drm code from .33 (see the LP bug), KMS+compiz+EXA crashed, but this time only this was in the kern.log:

[ 738.880732] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation
Comment 18 Alex Deucher 2010-03-01 08:54:15 UTC
(In reply to comment #17)
> After trying the fully-backported drm code from .33 (see the LP bug),
> KMS+compiz+EXA crashed, but this time only this was in the kern.log:
> 
> [ 738.880732] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation
> 

Was there any additional info?  Maybe in your dmesg?
Comment 19 Jamie Strandboge 2010-03-01 09:09:08 UTC
Created attachment 33665 [details] [review]
kern.log with backported drm from .33

That was from dmesg. There was nothing in XorgLog either. Here is the full kern.log for the session containing the crash.
Comment 20 Jamie Strandboge 2010-03-09 15:04:37 UTC
With a fully backported .33 DRM to 2.6.32 and the latest xorg-edgers drivers, the situation has not improved.

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

* no KMS/XAA/compiz: lockup and garbling. No errors in kern.log -- 
  https://launchpad.net/bugs/513950, https://launchpad.net/bugs/513956
* KMS/EXA/compiz: compiz crash. Errors in kern.log (see below)
  https://launchpad.net/bugs/507148

  Messages in kern.log are:
  [ 415.461546] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 1754.333393] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 1754.347688] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 2089.468099] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 2089.482369] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 3899.003282] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 3922.245559] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
  [ 3948.117491] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
Comment 21 Dave Airlie 2010-03-18 17:38:54 UTC
Created attachment 34228 [details] [review]
fallback on VRAM memory placement
Comment 22 Dave Airlie 2010-03-18 17:39:19 UTC
Created attachment 34229 [details] [review]
don't print pointless errors.
Comment 23 Dave Airlie 2010-03-18 17:40:23 UTC
I've attached two patches that let compiz start and run here as long as I dont have a screen size greater than 2048 in any direction.

compiz fails badly if > 2048 screen size.
Comment 24 Jamie Strandboge 2010-04-02 09:32:29 UTC
These patches resolve this issue completely. After a lot of automated testing and many hours of real world use with up to date packages that include these fixes, it no longer crashes. Thanks to everyone who helped fix this. :)

From our kernel changelog:
  [ Upstream Kernel Changes ]
  ...
  * drm/radeon/bo: add some fallback placements for VRAM only objects.
    - LP: #507148
  * drm/radeon/kms: don't print error on -ERESTARTSYS.
    - LP: #507148
  ...
Comment 25 Timo Jyrinki 2010-06-24 13:33:20 UTC
It seems the fallback fix is not in Linus' tree yet. The discussion continued in late April at http://lists.freedesktop.org/archives/dri-devel/2010-April/000309.html with proposed better patches, but apparently they're now waiting for testing feedback on the newest patch revision?
Comment 26 Alex Deucher 2010-10-19 19:11:32 UTC
The fix should be upstream now.
Comment 27 Vish 2010-10-22 10:44:14 UTC
The fix for this bug causes issues in RV515 , the patch was cherry-picked to fix the issue in Ubuntu in kernel 2.6.32-19-generic #28-Ubuntu .

The whole guest session starts flickering and is totally unusable.
A video capture of the issue : http://launchpadlibrarian.net/56913353/P1010994.MOV

Downstream bug report with other info :
 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/652934

Seems I'm a bit late, the only reason i was able to narrow down the issue was because the problem did not exist in the mainline kernel, but this fix seems to have been merged in mainline too now :(

What shall i do now? Shall i open a new bug report or can this be re-opened, since the patch here is the source of the problem?
Comment 28 Alex Deucher 2010-10-22 11:14:26 UTC
(In reply to comment #27)
> The fix for this bug causes issues in RV515 , the patch was cherry-picked to
> fix the issue in Ubuntu in kernel 2.6.32-19-generic #28-Ubuntu .
> 
> The whole guest session starts flickering and is totally unusable.
> A video capture of the issue :
> http://launchpadlibrarian.net/56913353/P1010994.MOV
> 
> Downstream bug report with other info :
>  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/652934
> 
> Seems I'm a bit late, the only reason i was able to narrow down the issue was
> because the problem did not exist in the mainline kernel, but this fix seems to
> have been merged in mainline too now :(

Have you verified that the upstream kernel has the same issue as the ubuntu one?  The patch that went upstream was slightly different than the one posted here.
Comment 29 Vish 2010-10-22 12:00:28 UTC
(In reply to comment #28)
> 
> Have you verified that the upstream kernel has the same issue as the ubuntu
> one?  The patch that went upstream was slightly different than the one posted
> here.

In which kernel did it get merged in?

I'v tested till ~$ uname -a
Linux Aspire-5670 2.6.35-02063504-generic #201008271919 SMP Fri Aug 27 20:27:22 UTC 2010 i686 GNU/Linux

And no problems till that version.
Comment 30 Vish 2010-11-23 03:03:36 UTC
(In reply to comment #28)
> 
> Have you verified that the upstream kernel has the same issue as the ubuntu
> one?  The patch that went upstream was slightly different than the one posted
> here.

Alex, any idea when the patch was merged and what the new patch is?

Since the patch here was cherry-picked in Ubuntu and is giving problems, it needs to be reverted and the updated patch applied instead.

I've tested with 2.6.36-020636 too which doesnt /seem/ to have the problem.
[~$ uname -a
Linux Aspire-5670 2.6.36-020636-generic #201010210905 SMP Thu Oct 21 10:17:53 UTC 2010 i686 GNU/Linux]
Comment 31 Michel Dänzer 2010-11-23 03:48:17 UTC
(In reply to comment #30)
> Alex, any idea when the patch was merged and what the new patch is?
> 
> Since the patch here was cherry-picked in Ubuntu and is giving problems, it
> needs to be reverted and the updated patch applied instead.

The fix is commit e376573f7267390f4e1bdc552564b6fb913bce76 ('drm/radeon: fall back to GTT if bo creation/validation in VRAM fails.'), and commit
2b66b50b12cabc05f05543e792d4c9c2465d5702 ('drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once.') fixes up a problem of the fix in the BO creation path.


> I've tested with 2.6.36-020636 too which doesnt /seem/ to have the problem.

Yeah, the fix first appeared in 2.6.36, though I think it was backported to some stable branch(es) as well.
Comment 32 Vish 2010-11-26 01:06:05 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > Alex, any idea when the patch was merged and what the new patch is?
> > 
> > Since the patch here was cherry-picked in Ubuntu and is giving problems, it
> > needs to be reverted and the updated patch applied instead.
> 
> The fix is commit e376573f7267390f4e1bdc552564b6fb913bce76 ('drm/radeon: fall
> back to GTT if bo creation/validation in VRAM fails.'), and commit
> 2b66b50b12cabc05f05543e792d4c9c2465d5702 ('drm/radeon/kms: Fix retrying
> ttm_bo_init() after it failed once.') fixes up a problem of the fix in the BO
> creation path.
> 
Thanks , I'll mention it in the downstream Ubuntu bug.

> 
> > I've tested with 2.6.36-020636 too which doesnt /seem/ to have the problem.
> 
> Yeah, the fix first appeared in 2.6.36, though I think it was backported to
> some stable branch(es) as well.

Yeah, with 2.6.36-020636 i yet havent been able to reproduce this flickering problem, seems better now.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.