gnome-shell weird lines

[Mattia Donato]

In gnome-shell font are corrupted and are present weird lines. I'm reffering to Ubuntu 12.04 full installed, and Ubuntu 12.10 gnome remix live edition.

Video card: Ati x1250

Please check also this link to have a picture http://img827.imageshack.us/img827/8899/gnome3.jpg and more detail on http://ubuntuforums.org/showthread.php?t=1938251

[Brian Ealdwine (eode)]

This is a severe issue, that prevents me (and a decent number of others) from using accelerated graphics.

This bug has the following behaviors:

* Corrupts the displayed graphics of every running program (as far as I can tell).
* Often corrupts the pointer graphics
* Corrupts fonts
* Corrupts the terminal display with noise from X, if you switch to a terminal
* Exists in accelerated and unaccelerated modes, but is marginal when not accelerated.
* Is made worse by KMS
* Is made worse by Compositing.
* Affects a rather large number of users (many with the rs690/x1200/x1250 cards, which are common in netbooks)

The previous workaround has been to disable KMS, which I believe somehow caused the radonhd driver to be used (uncertain about this). Either way, it brought the garbage to a usable level, and still allowed acceleration. However, that is not the case now. Using nomodeset results in a non-accelerated desktop.

Please let me know what pieces of information I should supply, and how I can be of assistance regarding this.

Note that glxinfo currently (with kms disabled) reports me to be using SGI and Mesa. Direct Rendering is "Yes", but it's actually using software, yes?. Even with this totally different driver set, I still sometimes get the corruptions (particularly after a long time running).

Is it possible that some fundamental thing (like a base memory address, or how much shared memory is to be used, or something) is being misreported and causing all these issues? This seems to be a very difficult bug to sort out, as it has been around a while.

[Brian Ealdwine (eode)]

Created attachment 44628
A screenshot that clearly displays corruption between program visuals

[Airlied-freedesktop (airlied-freedesktop)]

/var/log/Xorg.0.log and dmesg with KMS enabled.

Does your bios have an option for sideport RAM, do you know if you have sideport?

[Brian Ealdwine (eode)]

Yes, I believe I do have sideport ram. In discussion in bug #25469, (A duplicate of bug #27529, which got marked 'resolved--fixed'), someone stated they have the same issue, and that they have the same model of laptop as myself, and that the sideport ram can't be disabled in the bios (which is true in my case as well).

I am currently running xorg 1.10.0, with ati drivers from the git repo (xf86-video-ati), pulled yesterday.

[Brian Ealdwine (eode)]

Created attachment 44638
dmesg with KMS enabled

[Brian Ealdwine (eode)]

Created attachment 44639
Xorg.0.log, KMS enabled

[agd5f (agd5f)]

Does:
Option "ColorTiling" "False"
in the device section of your xorg.conf fix the issue? This might be a duplicate of bug 33929.

[Brian Ealdwine (eode)]

No, that appears to have no effect.
(thanks for taking time to troubleshoot this with me)

[Brian Ealdwine (eode)]

read the 'severity' description in 'help', and updated this to a blocker.

[agd5f (agd5f)]

The gart table buffer needs to be aligned to size (table address needs to be 512k aligned for 512 MB GART). I'm not sure if the Linux DMA API provides any mechanism to request that.

[agd5f (agd5f)]

Created attachment 44674
check gart table align

Can you try this patch and see if it prints an error when you load the driver?

[Brian Ealdwine (eode)]

Unfamiliar with working with compiling the kernel, so it took me a while.

The module loads without complaint, either to the terminal or to dmesg.
I checked the strings in radeon.ko to make sure I had installed the right .ko file, and it's the right one.

[Brian Ealdwine (eode)]

Just to clarify, since there's been no activity on the bug, in case there was a misunderstanding:

by "The module loads without complaint," I didn't mean that it was working properly, just that the module loaded.

[krmolot (krmolot)]

It's a same problem?
https://bugs.archlinux.org/task/23215?string=x1250&project=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
https://bugzilla.novell.com/show_bug.cgi?id=678264

p.s. My computer is crash whis screen cooruption when GDM is start when KMS is enable (kernel 2.6.37). Together with kernel 2.6.38 in gxgears i see black screen. When KMS is disable it's switch to the software 3d rendering. Tested distros: Ubuntu 11.04, Arch
notebook: eMachines D620, video: x1250

[axel (simon-simonfoley)]

Hi Guys,
       do not know if you are aware but this issue affects a lot of netbooks built by the same company Gateway,Acer,Packard Bell.

Its been plaguing me for over 2 years, like most people I disabled KMS to get it working in the interim or just did not use compiz.

Problem is now Ubuntu is launching 11.4 next week ....with as you are aware Unity. Unity and any desktop affects will no no longer work because of this bug,
as will all compix desktop effects!!

We are about to get a "lot" of bad Ubuntu user experience with Unity next week.

Is this going to be another argument for Wayland and justifies MS's controversial move?

Can I assist in any way ? Lets prove him wrong.

I have pulled in the latest main git repo and compiled the latest driver.

Its an holiday in the UK I can dedicate a few days of my time to this if it helps?

I can compile and add patches at your disposal.

[André Oliva (gandreoliva)]

I also have this problem. In my case, the corruption is not in the form of horizontal lines; simply the area inside any window that requires 3d graphics is black or frozen. I use Ubuntu 11.04. Compiz simply doesn't start, and the same behavior for programs like Stellarium or the visual module in Python (that I use very often). This behavior was **not present** a year ago in Ubuntu < 10.04. 2D acceleration works well (as a workaround, I can use `export LIBGL_ALWAYS_SOFTWARE=1`, but of course that is not a solution because graphics are extremelly slow).

The issue does not occur always. "Sometimes" I have an slow 3d acceleration (that I suspect it's really software rendering), and "sometimes" I have normal 3d acceleration (fast, smooth, as expected). I really don't understand when it works and when it doesn't work. If you give me instructions, I can help to clarify this. /var/log/Xorg.0.log has nothing strange.

[André Oliva (gandreoliva)]

The bug that I reported in Launchpad was incorrectly marked as a duplicate of this bug. I filed bug 37679 here in Freedesktop about this issue.

[Brian Ealdwine (eode)]

From Launchpad:

Setting VBLANK_MODE=0 seems to delay the appearance of corruption. Example:

Starting a regular, non-accelerated gnome-session, and then running:
VBLANK_MODE=0 glxgears

..it takes a while (and some dragging of glxgears around the screen) before the corruption appears, whereas normally it would appear rather quickly.

As noted before, the corruption isn't limited to the accelerated areas, and can happen when running a non-composited desktop under normal usage. Running openGL programs or compositing makes it appear very readily, though.

I believe it was mentioned in the Launchpad bug, but not here -- Once corruption begins, changes in an X-Session can affect other virtual consoles (e.g., once corruption begins, start a slow-loading program, switch to a virtual console, and as the program maps its graphical components, the console graphics get corrupted).

Hope this helps..

[Stillcompiling (stillcompiling)]

I am a long-time sufferer of this problem.
I have the Gateway LT3103u, which is

I have not yet applied Alex's patch, but I recently tried playing with the gartsize and vramlimit options.
gartsize seems to have no effect.
However, setting the vramlimit to 64 seems (2 reboots later) to clear up the corruption.
vramlimit of 128, 256, and 0 (0 is ignored) each result in corruption

The card normally reports 384 MB of vram and 512 MB of gtt memory.

Is it possible this computer is misreporting the amount of sideport ram? I read someplace that th x1270 can only have up to 128, but that there is some "Hypermemory" mumbo jumbo going on that adds some of your system ram to the mix.

Unfortunately, the Gateway LT3103u has a terrible bios config. you can't change anything, and you can't see much of anything either.

So, for the record: adding "radeon.vramlimit=64" to the kernel parameters in grub seems to alleviate the problem.

I'm running gentoo amd64, kernel 3.2.6-gentoo and git mesa

[Stillcompiling (stillcompiling)]

Experienced my first bit of corruption since adding "radeon.vramlimt=64" to my kernel params.
When switching from tuxracer back to the native desktop mode 1366x768, the pointer was corrupted.

One of the striking characteristics of this problem has always been that the pointer and character glyphs would always get clobbered. Only the pointer was affected this time

Happily the first time a popup happened that covered the cursor for a moment it was restored.

Other than that my experience has been great with the vramlimit in place.

One more observation:
It does not look to me like the problem is an byte alignment issue. When vramlimit is disabled, I can trigger the issue very quickly by going to a google image search page in firefox and scrolling down through the images.
I can see what looks to me like linear versions of the images filling up the display from top to bottom. If I correctly guess where firefox tabs are the tabs will usually repaint that part of the window correctly, though there is competition between (I'm guessing) the image cache and the screen, with one overwriting the other, until you restart the X session. I would speculate that either the size or location of the shared "hypermemory" vram is being miscalculated, or that some of that 384 the bios reports as vram should be treated as gtt memory.

BTW, I am a C programmer... If I knew where to start, I'd love to work on this problem from a code angle. I've looked at the code somewhat, but even in the code specific to my driver there is a lot of code in different places.

[Michel Dänzer (michel-daenzer)]

(In reply to comment #18)
> I have not yet applied Alex's patch, [...]

Have you been able to test it in the meantime? It doesn't seem very likely it'll help, but...

> However, setting the vramlimit to 64 seems (2 reboots later) to clear up the
> corruption.
> vramlimit of 128, 256, and 0 (0 is ignored) each result in corruption

Can others affected by the problem confirm this?

Can you attach the dmesg output from with and without the working vramlimit?

(In reply to comment #19)
> When switching from tuxracer back to the native desktop mode 1366x768, the
> pointer was corrupted.
[...]
> Happily the first time a popup happened that covered the cursor for a moment
> it was restored.

Sounds like that was just intermittent corruption of the hardware cursor memory buffer then, e.g. due to a 3D driver bug causing it to be accidentally overridden. Probably not the same problem this report is about.

> BTW, I am a C programmer... If I knew where to start, I'd love to work on this
> problem from a code angle. I've looked at the code somewhat, but even in the
> code specific to my driver there is a lot of code in different places.

See e.g. rs690_mc_init() in drivers/gpu/drm/radeon/rs690.c .

[agd5f (agd5f)]

Might also be related to bug 37679 (interrupt problems). Can you try a similar patch to the ones on that bug?

[Cboulte (cboulte)]

I have a packard bell dot m/a (radeon x1270) and have the issue described in this bug. My setup:
 * kernel 3.2
 * libdrm 2.4.30
 * mesa 7.11.2

I replaced the bios with a modded one that allow tweaking of video ram type. I tried two settings: uma only and uma+sideport.

 * UMA (256M)
   * No graphic corruption
   * No laggy window movement
   * glxgear fps ~= 360

 * UMA+sideport (256M+64M)
   * Massive graphic corruption
   * Laggy window movement
   * glxgears fps ~= 200

A diff between dmesg output:
$ diff dmesg.uma dmesg.uma+sideport
9c9
< [drm] Detected VRAM RAM=256M, BAR=256M
---
> [drm] Detected VRAM RAM=384M, BAR=256M
11c11
< [drm] radeon: 256M of VRAM memory ready
---
> [drm] radeon: 384M of VRAM memory ready
15c15
< [drm] PCIE GART of 512M enabled (table at 0x000000006C180000).
---
> [drm] PCIE GART of 512M enabled (table at 0x000000006B800000).
31a32
> [drm] radeon: power management initialized

Hope it can help. I can make more test if needed.

[Stillcompiling (stillcompiling)]

(In reply to comment #20)
> (In reply to comment #18)
> > I have not yet applied Alex's patch, [...]
>
> Have you been able to test it in the meantime? It doesn't seem very likely
> it'll help, but...
>
I did finallly try the gart alignment patch (required a minor tweak, gart.table.ram.ptr changed to gart.ptr)
No change and no line in dmesg.

> > BTW, I am a C programmer... If I knew where to start, I'd love to work on this
> > problem from a code angle. I've looked at the code somewhat, but even in the
> > code specific to my driver there is a lot of code in different places.
>
> See e.g. rs690_mc_init() in drivers/gpu/drm/radeon/rs690.c .

Thanks! I am poking around in drm/radeon. I wonder if it is possible to step through loading radeon.ko in gdb... There is no serial port on this puppy

(In reply to comment #21)
> Might also be related to bug 37679 (interrupt problems). Can you try a similar
> patch to the ones on that bug?

The quirks in bug 37679 seem to just force msi.
Thesymtos do not seem to apply. interrup count steadily rises with glxgears. I also booted with radeon.msi=1 (which has the same effect). No difference other than being assigned a different irq
(In reply to comment #22)
> I have a packard bell dot m/a (radeon x1270) and have the issue described in
> this bug. My setup:
> * kernel 3.2
> * libdrm 2.4.30
> * mesa 7.11.2
>
> I replaced the bios with a modded one that allow tweaking of video ram type. I
> tried two settings: uma only and uma+sideport.
>
> * UMA (256M)
> * No graphic corruption
> * No laggy window movement
> * glxgear fps ~= 360
>
> * UMA+sideport (256M+64M)
> * Massive graphic corruption
> * Laggy window movement
> * glxgears fps ~= 200
>
> A diff between dmesg output:
> $ diff dmesg.uma dmesg.uma+sideport
> 9c9
> < [drm] Detected VRAM RAM=256M, BAR=256M
> ---
> > [drm] Detected VRAM RAM=384M, BAR=256M
> 11c11
> < [drm] radeon: 256M of VRAM memory ready
> ---
> > [drm] radeon: 384M of VRAM memory ready
> 15c15
> < [drm] PCIE GART of 512M enabled (table at 0x000000006C180000).
> ---
> > [drm] PCIE GART of 512M enabled (table at 0x000000006B800000).
> 31a32
> > [drm] radeon: power management initialized
>
> Hope it can help. I can make more test if needed.

That 384 number seems like the most likely suspect.
I see indications several places that theres only 64M of sideport VRAM, but 384 == 128 + 256

I'm not sure where that specific piece of data (the 128M of internal vram) is coming from, or whether it can be "fixed" by poking 64 * 1024 * 1024 into some register...
I tried arbitrarily setting rdev->mc.real_vram_size to 320M as soon as it was set, but that had no effect

[Carl Fink (carl-finknetwork)]

Just another user reporting the same bug. Experienced with both Debian (Unstable) and Knoppix on a Gateway LT3119u netbook.

[Carl Fink (carl-finknetwork)]

Created attachment 59703
Another screenshot showing corruption

I'm uploading two more screenshots taken from my Gateway LT3119u netbook, running Debian Unstable. I've also duplicated the phenomenon on Knoppix. I hope this additional information will both prove useful and prod the team to fix this long-ago-reported bug.

[Carl Fink (carl-finknetwork)]

Created attachment 59704
Second attachment showing corruption.

[agd5f (agd5f)]

Do either of these help?

(as root):

radeonreg regset 0x6564 0xffffffff
radeonreg regset 0x6568 0xffffffff
radeonreg regset 0x656c 0xffffffff
radeonreg regset 0x6570 0xffffffff

or:

radeonreg regset 0x6acc 0x00000000

You can grab radeonreg here:
http://cgit.freedesktop.org/~airlied/radeontool/

[Stillcompiling (stillcompiling)]

archaeopteryx radeontool # ./radeonreg regset 0x6564 0xffffffff
OLD: 0x6564 (6564) 0x7fff7fff (2147450879)
NEW: 0x6564 (6564) 0x7fff7fff (2147450879)
archaeopteryx radeontool # ./radeonreg regset 0x6568 0xffffffff
OLD: 0x6568 (6568) 0x7fff7fff (2147450879)
NEW: 0x6568 (6568) 0x7fff7fff (2147450879)
archaeopteryx radeontool # ./radeonreg regset 0x656c 0xffffffff
OLD: 0x656c (656c) 0x7fff7fff (2147450879)
NEW: 0x656c (656c) 0x7fff7fff (2147450879)
archaeopteryx radeontool # ./radeonreg regset 0x6570 0xffffffff
OLD: 0x6570 (6570) 0x7fff7fff (2147450879)
NEW: 0x6570 (6570) 0x7fff7fff (2147450879)
archaeopteryx radeontool # ./radeonreg regset 0x6acc 0x00000000
OLD: 0x6acc (6acc) 0x00000000 (0)
NEW: 0x6acc (6acc) 0x00000000 (0)
archaeopteryx radeontool #

It did not prevent the corruption. I don't know if the 0x7ff7fff resultant value is significant.

[Carl Fink (carl-finknetwork)]

Your radeontool package is different from the radeontool package that comes with Debian-name collision?

After running autoconf.sh and then make ... there is still no radeonreg program, making it impossible to test your suggested commands.

[agd5f (agd5f)]

you can use avivotool as well. same syntax.

[Carl Fink (carl-finknetwork)]

Thanks to Alex's tip on avivotool, I was able to try the suggested settings. According to the output, those were already the values stored in the registers and the commands had no effect.

FWIW, I discovered that I can reliably cause the corruption to happen in seconds by loading the game "Secret Maryo Chronicles" (smc).

[Brian Ealdwine (eode)]

I've installed (and since deinstalled) the modified bios, but it enabled me to do some testing. The system was unstable, and would freeze hard every 3-5 minutes or so when in either sideport-only or uma-only modes. However:
Graphics *seem* to work fine (either way, work much better) with things set either to Sideport only or UMA-only. Using sideport+uma caused massive corruption, as 'normal'.

Interestingly, although the BIOS states that there are 64mb of sideport ram, the system thinks I have 128mb when sideport-only is set in the bios.

This seems to correlate with d4ddio's observation:
> I see indications several places that theres only 64M of sideport VRAM, but 384 == 128 + 256

[axel (simon-simonfoley)]

Hi Brian,
       I have been a bit quiet on this bug because of work commitments. I too flashed my Packard Bell dot ma with the Gateway v1.3302 BIOS (Although I have lost VT support which is a pain)

I initially achieved graphics stability by changing the UMA+Sideport to just UMA in the Advanced Northbridge Options.

In Sideport only Mode it indicates that there is only 64MB of video memory and when I try to boot with sideport only the laptop hangs on boot.

Have you tried the following?

Internal Video Mode: UMA+Sideport
Video Memory: Auto
Dual Mode Interleaving: Enabled
Dual Mode Non-Interleaving SP Size: 0MB
Dual Mode Interleav Ratio: 1:7

In theory this should allocate 512 MB of video ram (UMA=448 + 64 Sideport)
Ratio of 1x64 Sideport to 7x64 UMA.
If you look up the specs of the RS690 this is its theoretical MAX addressable memory and so they back each other up.

http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units

As such it suggest that the main BIOS Page is incorrect in reporting 384 MB
video RAM (256MB Max UMA + 128MB Sideport) as Sideport is probably only 64MB as reported accurately by the "Advance NB Options Page". Also note if Main page of the BIOS is correct why when you set the UMA Memory manually to e.g. 32MB does the value reported in that page not drop ?

It all looks to me like sideport is only 64MB.

Since I have been running the settings above I cannot recreate the problem
with UMA+Sideport and Graphics performance has massively improved. I can now play iPlayer full screen with the standard un-accelerated ati driver.

>> I would like somebody else to test these settings because I suspect that
I may not be seeing the corruption because Unity has defaulted to 2d mode regardless of what I choose on the login screen.

For those that want the background as to what these BIOS options mean see the link below;
http://www.tomshardware.co.uk/forum/322592-15-difference-sideport-mode

I will also attach some BIOS Developers guides for the chipsets for reference

[axel (simon-simonfoley)]

Created attachment 60735
RS690 BIOS Developers Requster guide

RS690 BIOS Developers Register guide

[axel (simon-simonfoley)]

Created attachment 60736
RS780G BIOS Developers Guide

RS780G BIOS Developers Guide
Not the same as the RS690 but this doc seems to have many similarities with gateway bios and provide some interesting insights to the chip-sets capabilities.

[axel (simon-simonfoley)]

by the way I should also point out .... that despite me setting the values above ....the 2048 MB System Memory and theoretical 512MB Video Memory allocation..... I only see the total system memory drop by 256K not 512MB.

So perhaps with this BIOS you can not allocate more that 256K

[mattocompleto (mattocompleto)]

I confirm also to have similar problems on my laptop.It's a Samsung P200 with an ATI X1250, the chipset should be the R600 chipset with installed Ubuntu 12.04 LTS.

In Unity I can see weird lines below the bar
[IMG]http://i46.tinypic.com/2ur55yp.png[/IMG]
[IMG]http://i49.tinypic.com/10hr30y.png[/IMG]

and also I can see font corruptions on the bars of gnome-shell.
[IMG]http://img827.imageshack.us/img827/8899/gnome3.jpg[/IMG]

$ lspci -nn | grep VGA
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Radeon Xpress 1250 [1002:7942]

see this on ubuntuforums
http://ubuntuforums.org/showthread.php?t=1967462&highlight=x1250

[Carl Fink (carl-finknetwork)]

Since this bug was reported over a year ago and no real progress has been made in fixing it, may I ask a knowledgeable person what the last working version of the code was, before this bug was introduced? Is there any way to create a "radeon-unsupported" module for those of us who have chipsets X.org doesn't plan to support with their newer versions?

[Stillcompiling (stillcompiling)]

(In reply to comment #38)
> Since this bug was reported over a year ago and no real progress has been made
> in fixing it, may I ask a knowledgeable person what the last working version of
> the code was, before this bug was introduced? Is there any way to create a
> "radeon-unsupported" module for those of us who have chipsets X.org doesn't
> plan to support with their newer versions?

The simple answer is that (afaik) this particular hardware set of hardware has had trouble since kernel mode-setting was introduce. There is not going to be a git bisect-able place where the problem started happening.

...

I do have a question for devs... I have been all over the initialization code and I cannot find a place where the sideport RAM is treated as distinct from the UMA "vram". Is this stuff set up by the atombios? Is there a way to see what hardware addresses ranges are assigned? Is there a way to fix the GART (table) if the bios is setting up overlapping or otherwise broken addresses for GTT, UMA and sideport vram?

[Brian Ealdwine (eode)]

There has never been a working version of the radeon driver -- last
working version
was radeonhd, which is a different driver.

[Brian Ealdwine (eode)]

Sorry, comment #40 was in response to comment #38 -- I did not see that d4dd10 had responded (accurately and in more specific detail) already.

Note -- I'm out of the running on this for now, I've bricked my laptop with a modified bios, and it'll probably take a bit of work to undo.

[agd5f (agd5f)]

(In reply to comment #39)
>
> I do have a question for devs... I have been all over the initialization code
> and I cannot find a place where the sideport RAM is treated as distinct from
> the UMA "vram". Is this stuff set up by the atombios? Is there a way to see
> what hardware addresses ranges are assigned? Is there a way to fix the GART
> (table) if the bios is setting up overlapping or otherwise broken addresses for
> GTT, UMA and sideport vram?

It's not treated separately from UMA from the driver's perspective (or the HW for that matter). The hw as an FB aperture that points to stolen system memory (for UMA only) or some combination of sideport and stolen system memory for (sideport+UMA or sideport only). The bios normally sets up the sideport and UMA as interleaved if both are enabled for maximum performance. GART is a separate aperture and has nothing to do with sideport or the stolen system memory block.

[Carl Fink (carl-finknetwork)]

So this bug looks as if it will not be fixed. Who should I bribe^Wdonate money to in order to revive radeonhd?

[Brian Ealdwine (eode)]

It's disappointing, but I think there are just too many bugs and not
enough coders to fix them, and they've got to prioritize. -- on top of
that, there's not a *really* good method out there of evaluating the
impact of a problem. This is obviously a high-impact problem,
considering how common the card is, but it's slipped between the cracks.

As to your idea -- I think that radeonhd drivers are incompatible with
the newer versions of X -- which is why they were phased out anyways.
Unfortunately, the newer drivers obviously don't work right for a lot of
people.

The best bet to getting a fix is probably emailing the maintainers of
the new driver -- getting on mailing lists and discussing it. I long
ago gave up on fighting this particular fight.

If it helps, this is definitely a sideport ram issue, and disabling
sideport ram in the BIOS fixes the problem -- however, many BIOSes do
not allow you to do this.

[Carl Fink (carl-finknetwork)]

Replying to #44: I know that RadeonHD is not compatible with the current version. Thus my suggestion it be "revived" as a project. If it were compatible I'd just compile it.

I'm short of time these days. Rather than making huge efforts to have X.Org fix the bug, I'll just remove the Debian partition from my netbook. Windows 7 works fine ....

[Josselin Mouette (joss)]

Note that it can be worked around by disabling RENDER acceleration.

[Carl Fink (carl-finknetwork)]

(In reply to comment #46)
> Note that it can be worked around by disabling RENDER acceleration.

Can you be more specific?

[agd5f (agd5f)]

*** Bug 54704 has been marked as a duplicate of this bug. ***

[agd5f (agd5f)]

Does this patch help?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4a2b6662c3632176b4fdf012243dd3751367bf1f

[Nicolas Delvaux (malizor)]

I will try this patch later but, AFAIK, dma32 is only used on 64 bits systems, isn't it?
I have the same problem (having to disable modeseting) with both 32 and 64 bits kernels (Ubuntu 12.04).

[Nicolas Delvaux (malizor)]

Unfortunately, this patch changed nothing here.
I'm still enable to start unity/gnome-shell and I have some graphic corruptions when using a fallback such as Unity 2D.

This is on a Acer Emachine e625 laptop. I tested the patch on both 32 and 32-pae kernels from Ubuntu 12.04 (3.2.0-31.50).

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1049630

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

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

[Mattia Donato (mattia-donato)]

sorry I just realize that is a duplicate of https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=35457

[agd5f (agd5f)]

maybe this is due to irq problems? See bug 37679. Perhaps your boards need similar msi quirks?

[Nicolas Delvaux (malizor)]

@Alex Deucher: it's weird in fact.

I changed the WIFI card of this laptop last week (because of regular disconnections) and now I'm able to start Unity 3D and Gnome-Shell. I don't understand what happened. Note that everything worked fine on Windows with the old WIFI card.

I posted on the other bug regarding enabling MSI.

[Nicolas Delvaux (malizor)]

I put the old WIFI card back in the laptop for testing (nb. everything works on Windows, the card does not seem to be defective)

Without MSI: Compiz starts but the desktop is a fixed image. I see no special error in .xsession-errors.
With MSI: Compiz and Unity 3D start.

With or without MSI, Unity 3D starts when putting the other WIFI card in.

I should add that, with or without MSI, I get regular network disconnections (both WIFI cards, the replacement one used to work well with Linux on its former laptop).

So yes, enabling MSI is a win on this laptop. But I don't quite get why the WIFI card can affect the GPU. There might be some other bug somewhere, but I don't know what it is and where I should report it.

[agd5f (agd5f)]

Created attachment 84746
possible fix

Does the attached patch help?

[Nicolas Delvaux (malizor)]

Hi Alex,

I'm afraid I don't have access to this laptop anymore, so I can't test your patch.
Hopefully someone from the CC list may be able to help?

Thanks anyway.

[Stillcompiling (stillcompiling)]

I just had time to try this latest patch.
Unfortunately it does not correct the issue.
Is there any way to check or change the beginning and ending addresses of
sideport memory and stolen system memory once the system is up?
If there are registers I can read or write to experiment I will be happy to
try it,but I am afraid I was unable to comprehend a lot of the register
documentation from AMD.

[Boomer (gbmr)]

I have laptop with Radeon x1250 graphics card and can try to do some testing. Actually, I'm very interested in fixing this bug. It prevents me from using linux on my laptop.

[penalvch (penalvch)]

Mattia Donato, 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 linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[ShinobiTeno (lct-mail)]

35998 is exactly same bug.

[ShinobiTeno (lct-mail)]

*** Bug 35998 has been marked as a duplicate of this bug. ***

[ShinobiTeno (lct-mail)]

Dear Developers!!

Please tell us what are the chances that this bug can be fixed? Do you want paypal tips? Is this bug really not worth the time that selling the machines is a better way to go?

If you respond that its probably unfixable, please mark the radeon feature page correspondingly, that this Card (1250) is NOT supported, because this bug really makes the machine unusable.

Also affected notebooks: Samsung R20

Kind regards

[ShinobiTeno (lct-mail)]

I have installed 2 GiB of SODIMM DDR2 today, replacing the old 1 GiB module.
At OpenSuse Tumbleweed (13.1; knel 3.11/Mesa 9.2) at login screen AFTER Xorg has started I have hexagon (8x8) colored squares, each of them made of two triangles.
Each time I move mouse or type something, the triangles in approximate area change colors.

After login, the screen is back to normal, sans gnome-shell specific font corruption and some extra (below).

This defects are not present with 1GiB.

Also, the Gnome3 gnome-shell border right now has "flightmode" symbol, which is completely white square and sound icon that is divided in four pieces.

I suggest this is strictly bug of Xorg driver, this is strictly bug within Mesa texture transfer, the content of those triangles is NOT copied right, this bug does NOT appear outside of Xorg or outside of OpenGL (Grub2 boots perfectly with zero errors via VESA) this bug's effects repeat themselves unless memory configuration change. With different memory config other sorts pop up, but previous stay. This is not bug due to insufficient memory. This bug does not change if different memory window is set in BIOS (I have 128 or 256, I have NO sideport or similar).

Please help me fix the bug! I am no programmer or developer, but give me some tools to run on the machine or I can give you VNC/root at any time + paypal tip and a thank you.

Please do not be ignorant!! :(((((

[ShinobiTeno (lct-mail)]

I have observed the case a bit more.
When machine is coming out of hibernation - the opensuse boot screen experiences corruption: 1/4 of the screen is drawn correct - the rest contains garbage. The pattern is pretty same - the screen is cut by four triangles with basements along the sides.

Important thing I noticed - the screen recovers itself after some time. Although font damage in gnome-shell is permanent, refreshing parts of the screen with some content has some chance to make it work as it should. THEN it stays correct.

Also,
I suspect that initial four triangle show right after login, is gnome 3 trying to blend-in, by applying a four-triangle surface filled with black and then increasing the alpha. The moment alpha is all way up, gnome removes them. With this bug - it looks like triangle flash which then suddenly correct.

To sum up,
I am totally sure this is about texture memory transfer within OpenGL context, I am nearly sure it happens because the texture memory IS NOT CLEARED when its asked or the content is overwritten when stored, or the memory is not protected from being overwritten by garbage. However, the system is fully stable even when I used it with 1GiB constantly swapping.

Please, help.

[Brian Ealdwine (eode)]

..agreed, this really shouldn't be marked as a supported card since it's
not actually functional.

[agd5f (agd5f)]

(In reply to comment #63)
> ..agreed, this really shouldn't be marked as a supported card since it's
> not actually functional.

It works just fine a quite a few RS690 boards.

[Brian Ealdwine (eode)]

> It works just fine a quite a few RS690 boards.

ah. ..well, it also doesn't work for quite a few RS690 boards.

I guess it's academic for me, at this point, though -- I've long since
moved on, since I had to keep working and current, and the old driver
was dropped.

If you're reading this bug and have this issue, it's been open for
nearly three years, and isn't likely to be fixed, as far as I can tell.
If 3d acceleration is important to you, it's almost definitely worth it
to get some hardware that is better supported. I went with Intel
graphics -- there's a lot less likelihood that support will be dropped
for that, since Intel's more helpful than ATI regarding open-source
drivers for their graphics hardware.

[ShinobiTeno (lct-mail)]

(In reply to comment #65)
> I guess it's academic for me, at this point, though -- I've long since
> moved on, since I had to keep working and current, and the old driver
> was dropped.
>
> If you're reading this bug and have this issue, it's been open for
> nearly three years, and isn't likely to be fixed, as far as I can tell.
> If 3d acceleration is important to you, it's almost definitely worth it
> to get some hardware that is better supported. I went with Intel
> graphics -- there's a lot less likelihood that support will be dropped
> for that, since Intel's more helpful than ATI regarding open-source
> drivers for their graphics hardware.

Well, Brian, its true regarding older hardware, lets not be blind about all the post x1*** - 6*** cards, they are actually okay.

Also, "3D is important" is a bit exaggerated, because 3D pipeline and *everything* except this bug work really fine. There are many factors in play on modern desktop for it to "just work", but this only one bug really damages it.

On the other hand, its so damn shame that no one wants to give a look, even if offered full remote access to affected machine, in do what you want, ask what you wish, mode. :(

[ShinobiTeno (lct-mail)]

(In reply to comment #64)
> (In reply to comment #63)
> > ..agreed, this really shouldn't be marked as a supported card since it's
> > not actually functional.
>
> It works just fine a quite a few RS690 boards.

Hello Mr Deucher, could you please be a bit more specific which mobile xpress x1250 are not affected? Right now I have R60 and R20, both of which show same issues...

Can you please suggest any patch to clear the texture memory when asked prior to submitting it for writing (within the OpenGL-specific context)?

Right now, the more one works, the more triangle surface is flawless.

Only freshly booted or freshly hibernated under go it and as time passes these surfaces are eventually clear, except for those that never get a chance of rewrite, like fonts textures in gnome-shell.

Also, switching TTYs is still an issue as system can simply become unable to switch back to Xorg TTY, with screen constantly flashing/pulsating in black. But this is not a huge blocker.

Thank you!

[agd5f (agd5f)]

Setting radeon.vramlimit=64 is also a workaround.

[Brian Ealdwine (eode)]

> > If you're reading this bug and have this issue, it's been open for
> > nearly three years, and isn't likely to be fixed, as far as I can tell.
> > If 3d acceleration is important to you, it's almost definitely worth it
> > to get some hardware that is better supported. I went with Intel
> > graphics -- there's a lot less likelihood that support will be dropped
> > for that, since Intel's more helpful than ATI regarding open-source
> > drivers for their graphics hardware.
>
> Well, Brian, its true regarding older hardware, lets not be blind about all the
> post x1*** - 6*** cards, they are actually okay.

Regardless, the RS690M was listed as supported, I bought hardware that I
thought would be supported for that specific reason, and then that
changed, and that leaves me with no experience or reason to recommend
ATI or the radeon driver at this point, and plenty of reason to
recommend against it. ..the stuff that is new now becomes old
later. ..why should I think that my experience with any other ATI card
should be different? ..at least on the Intel side, there's the blessing
(and support) of the chip maker.

> Also, "3D is important" is a bit exaggerated, because 3D pipeline and
> *everything* except this bug work really fine.

No disagreement there. I've got an Intel graphics card that works
superbly, and there are others out there with nVidia and ATI cards that
run great, too. What I was said was saying was (indented, so that the
if statements and their subjective clauses are more apparent):

* If you're reading this and have this issue
 * This issue has been open for nearly three years
 * It isn't likely to be fixed, from what I can tell
 * If 3d is important to you
  * It is almost definitely worth it to get some hardware that is better
supported.

..I stand by that statement.

> There are many factors in play
> on modern desktop for it to "just work", but this only one bug really damages
> it.

*nod* and a lot of them work fine, and this one doesn't. ..a perfectly
functional car with a broken drive shaft that no one knows how to fix is
still valuable -- it's just not valuable to someone who wants to drive a
car, unless that person knows how to fix it, or can sell that car, and
get another car which many people know how to fix, and which appears
less likely to break.

..I'm not looking at this and thinking "That's bad work they've done",
I'm looking at it and saying "No one has had the time, know-how, and
the access to the hardware to fix this, so if you are waiting for it to
get done, my opinion is that you're better off buying more compatible
hardware in this particular case."

..then again, all it takes is someone who does have the time, know-how,
and hardware to fix this, and who wishes to donate their work. ..if
someone does do that -- thank you. ..that specifically won't benefit me
at this point, but thank you just on the general principle of it, and
for the people that it will benefit. ..and thank you to everyone else
who has contributed to Linux, X, and all the layers in between and on
top -- it's phenomenal work that provides a genuine alternative to the
proprietary operating systems that are out there.

[Brian Ealdwine (eode)]

On Wed, 2013-11-27 at 04:45 +0000, <email address hidden>
wrote:
> Comment # 68 on bug 35457 from Alex Deucher
> Setting radeon.vramlimit=64 is also a workaround.
>
> ______________________________________________________________________
> You are receiving this mail because:
> * You reported the bug.

If setting the vramlimit does work (I'm unable to test it at this point
since I no longer have the hardware) than that's a reasonable option.
Up until the time I had to get something else, none of the proposed
solutions had worked for me -- but if a functional workaround is
present, that's often preferable to buying new hardware.

[agd5f (agd5f)]

Created attachment 89886
possible fix

Does this patch help?

[agd5f (agd5f)]

(In reply to comment #70)
> If setting the vramlimit does work (I'm unable to test it at this point
> since I no longer have the hardware) than that's a reasonable option.
> Up until the time I had to get something else, none of the proposed
> solutions had worked for me -- but if a functional workaround is
> present, that's often preferable to buying new hardware.

It is reported as a valid workaround on this very bug report. Has anyone else tried it?

[ShinobiTeno (lct-mail)]

Created attachment 89895
Samsung R60, xpress 1250, OpenSuse Tumbleweed, kernel 3.11, Mesa 9.2.2, login corruption

[ShinobiTeno (lct-mail)]

Dear Mr. Deutcher, thank you for will and readiness to help in this problem!!

I am using radeon.gart=1024, it does not help.
Then I upgraded to Tumbleweed (3.11)
Glxinfo reports:

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RS600
OpenGL version string: 2.1 Mesa 9.2.2
OpenGL shading language version string: 1.20

Then I added radeon.dpm=1, there are no information about dpm or powermanagement what so ever in dmesg (unlike 5850 card that I have). I suggest dpm is not supported on this chip. Not great deal, but for example, 5850 is unstable withOUT dpm in 3.11.

Lastly, of course I read all patches and responses from people in these two bugs, and tested first switching from 256 VGA memory to 128 via BIOS (only two options), it didn't help.

Then I appended "radeon.vramlimit=64" to grub2 kernel line, updated grub, rebooted. Nothing changed. I attach the screenshot showing the issue with gnome-shell corruption and the login triangle issue, that is even more agressive when system comes out of hibernation.

dmesg | grep -i radeon says:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.6-4-desktop root=UUID=29100748-63ff-45a1-8642-b795f20d4aea resume=/dev/disk/by-id/ata-WDC_WD1200BEVS-22UST0_WD-WXC208783969-part2 splash=silent quiet showopts radeon.dpm=1 radeon.gartsize=1024 radeon.vramlimit=64
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.11.6-4-desktop root=UUID=29100748-63ff-45a1-8642-b795f20d4aea resume=/dev/disk/by-id/ata-WDC_WD1200BEVS-22UST0_WD-WXC208783969-part2 splash=silent quiet showopts radeon.dpm=1 radeon.gartsize=1024 radeon.vramlimit=64
[ 2.276384] [drm] radeon kernel modesetting enabled.
[ 2.276584] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
[ 2.279337] radeon 0000:01:05.0: VRAM: 128M 0x0000000078000000 - 0x000000007FFFFFFF (64M used)
[ 2.279345] radeon 0000:01:05.0: GTT: 1024M 0x0000000080000000 - 0x00000000BFFFFFFF
[ 2.281879] [drm] radeon: 64M of VRAM memory ready
[ 2.281885] [drm] radeon: 1024M of GTT memory ready.
[ 2.304378] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 2.309271] radeon 0000:01:05.0: WB enabled
[ 2.309286] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000080000000 and cpu addr 0xffff880036bbe000
[ 2.309352] [drm] radeon: irq initialized.
[ 2.310247] [drm] radeon: ring at 0x0000000080001000
[ 2.312584] [drm] radeon atom DIG backlight initialized
[ 2.312592] [drm] Radeon Display Connectors
[ 2.902375] fbcon: radeondrmfb (fb0) is primary device
[ 3.227074] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device
[ 3.227080] radeon 0000:01:05.0: registered panic notifier
[ 3.227124] [drm] Initialized radeon 2.34.0 20080528 for 0000:01:05.0 on minor 0

I will test the patch today.
At your will, I will give you remote login to the notebook for any kind of testing you so desire.

[agd5f (agd5f)]

(In reply to comment #74)
> Dear Mr. Deutcher, thank you for will and readiness to help in this problem!!
>
> I am using radeon.gart=1024, it does not help.
> Then I upgraded to Tumbleweed (3.11)
> Glxinfo reports:
>
> OpenGL vendor string: X.Org R300 Project
> OpenGL renderer string: Gallium 0.4 on ATI RS600
> OpenGL version string: 2.1 Mesa 9.2.2
> OpenGL shading language version string: 1.20

You are experiencing a different bug (bug 35998). Despite similar symptions, it is not the same root issue. I don't think any of the suggestions or workarounds on this bug are relevant on your system.

[Stillcompiling (stillcompiling)]

Oh, wow!
patch in attachment 89886 seems to fix this issue for me.

Today is thanksgiving here in the USA.
I am thankful for open source radeon drivers.
I am thankful for your efforts, Alex Deucher.

This would confirm that it is a bogus BIOS setting where the bios reports
384, but it is actually only 256.
I tried something similar on my own earlier, but I did not understand the
memory layout well enough to know to adjust the base address.
Thank you for trying yet again to fix this, Alex.
I am testing now. Anyone else on this bug able to test this proposed fix?

On Tue, Nov 26, 2013 at 9:03 PM, <email address hidden> wrote:

> *Comment # 71 <https://bugs.freedesktop.org/show_bug.cgi?id=35457#c71>
> on bug 35457 <https://bugs.freedesktop.org/show_bug.cgi?id=35457> from Alex
> Deucher <email address hidden> *
>
> Created attachment 89886 <https://bugs.freedesktop.org/attachment.cgi?id=89886> [details] <https://bugs.freedesktop.org/attachment.cgi?id=89886&action=edit> [review] <https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=35457&attachment=89886>
> possible fix
>
> Does this patch help?
>
> ------------------------------
> You are receiving this mail because:
>
> - You are on the CC list for the bug.
>
>

[ShinobiTeno (lct-mail)]

Hello Mr. Deucher, hello d4ddi0; sorry for not responding, unfortunately I can only test it on this weekend, sorry for polluting maillist with my ego status.

[agd5f (agd5f)]

(In reply to comment #77)
> Hello Mr. Deucher, hello d4ddi0; sorry for not responding, unfortunately I
> can only test it on this weekend, sorry for polluting maillist with my ego
> status.

As I mentioned in a previous comment, this patch won't affect your system. RS600 chips don't support sideport memory and they use a different code path in the driver to configure the memory controller. Please use bug 35998.

[agd5f (agd5f)]

Created attachment 90125
possible fix

Please try this updated patch. thanks!

[Brian Ealdwine (eode)]

> It is reported as a valid workaround on this very bug report. Has anyone else
> tried it?

I had already gotten a new laptop at the time it was reported, and I
don't have access to the old hardware anymore. Hopefully someone else
can test it.

[Launchpad Janitor (janitor)]

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

[penalvch (penalvch)]

Micha, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

[Micha (m-st-w)]

Why?

Why are you setting the statut here to ´new´?!?
T
his problem here is unsolved since 2011, still the same graphical corruptions!

For what do you need a new report from me??? HERE are...10? people all complaining the same, without solution....since 2011!
And you say, it helps "immensely" if I file a new report (again)?

I do not think so, but as I have soo much time to waste and to make you happy, I´ll try now...even if I already know its a waste of time...again and again.

2011....5 years already without a proper solution.

[penalvch (penalvch)]

Micha, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.