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.
Created attachment 44628 [details] A screenshot that clearly displays corruption between program visuals
/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?
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.
Created attachment 44638 [details] [review] dmesg with KMS enabled
Created attachment 44639 [details] [review] Xorg.0.log, KMS enabled
Does: Option "ColorTiling" "False" in the device section of your xorg.conf fix the issue? This might be a duplicate of bug 33929.
No, that appears to have no effect. (thanks for taking time to troubleshoot this with me)
read the 'severity' description in 'help', and updated this to a blocker.
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.
Created attachment 44674 [details] [review] check gart table align Can you try this patch and see if it prints an error when you load the driver?
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.
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.
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
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.
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.
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.
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..
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
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.
(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 .
Might also be related to bug 37679 (interrupt problems). Can you try a similar patch to the ones on that bug?
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.
(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
Just another user reporting the same bug. Experienced with both Debian (Unstable) and Knoppix on a Gateway LT3119u netbook.
Created attachment 59703 [details] 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.
Created attachment 59704 [details] Second attachment showing corruption.
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/
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.
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.
you can use avivotool as well. same syntax.
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).
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
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
Created attachment 60735 [details] RS690 BIOS Developers Requster guide RS690 BIOS Developers Register guide
Created attachment 60736 [details] 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.
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
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
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?
(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?
There has never been a working version of the radeon driver -- last working version was radeonhd, which is a different driver.
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.
(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.
So this bug looks as if it will not be fixed. Who should I bribe^Wdonate money to in order to revive radeonhd?
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.
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 ....
Note that it can be worked around by disabling RENDER acceleration.
(In reply to comment #46) > Note that it can be worked around by disabling RENDER acceleration. Can you be more specific?
*** Bug 54704 has been marked as a duplicate of this bug. ***
Does this patch help? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4a2b6662c3632176b4fdf012243dd3751367bf1f
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).
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).
maybe this is due to irq problems? See bug 37679. Perhaps your boards need similar msi quirks?
@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.
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.
Created attachment 84746 [details] [review] possible fix Does the attached patch help?
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.
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.
35998 is exactly same bug.
*** Bug 35998 has been marked as a duplicate of this bug. ***
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
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!! :(((((
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.
..agreed, this really shouldn't be marked as a supported card since it's not actually functional.
(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.
> 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.
(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. :(
(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!
Setting radeon.vramlimit=64 is also a workaround.
> > 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.
On Wed, 2013-11-27 at 04:45 +0000, bugzilla-daemon@freedesktop.org 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.
Created attachment 89886 [details] [review] possible fix Does this patch help?
(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?
Created attachment 89895 [details] Samsung R60, xpress 1250, OpenSuse Tumbleweed, kernel 3.11, Mesa 9.2.2, login corruption
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.
(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.
Oh, wow! patch in attachment 89886 [details] [review] 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, <bugzilla-daemon@freedesktop.org> 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 <agd5f@yahoo.com> * > > Created attachment 89886 [details] [review] <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. > >
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.
(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.
Created attachment 90125 [details] [review] possible fix Please try this updated patch. thanks!
> 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.
(In reply to comment #79) > Created attachment 90125 [details] [review] [review] > possible fix > > Please try this updated patch. thanks! Ping! Anyone? It would be nice to get this fix upstream.
Sorry for the delay. I had some extra time right after I got the first patch, and tried several things, but then got very busy and I have not applied the new patch. It looks fine to me but I haven't actually compiled it in. I'll post something as soon as I have the chance. Here is what I have found so far. There is an 80x25 grid of colorful random characters in the text terminal just after the mode switch, but it is otherwise perfect as far as I could tell. I also tried 64 MiB offset instead of 128, which also worked. I also tried (with the 128 MiB offest) setting rdev->mc.igp_sideport_enabled to false, and booting with radeon.fastfb=1, which also worked for me. On Wed, Dec 11, 2013 at 8:48 AM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 81 <https://bugs.freedesktop.org/show_bug.cgi?id=35457#c81> > on bug 35457 <https://bugs.freedesktop.org/show_bug.cgi?id=35457> from Alex > Deucher <agd5f@yahoo.com> * > > (In reply to comment #79 <https://bugs.freedesktop.org/show_bug.cgi?id=35457#c79>)> Created attachment 90125 [details] [review] <https://bugs.freedesktop.org/attachment.cgi?id=90125> [details] <https://bugs.freedesktop.org/attachment.cgi?id=90125&action=edit> [review] <https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=35457&attachment=90125> [review] > > possible fix > > > > Please try this updated patch. thanks! > > Ping! Anyone? It would be nice to get this fix upstream. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
Alex, I can confirm the commented version of the patch applies against 3.12, compiles, and fixed the problem on my gateway lt3103u Thanks!
Alex, thanks so much for fixing this, and to everyone who helped. I don't have the hardware to confirm this anymore, but d4ddio has the same system that I had when I opened the bug, and confirms that the bug is fixed. Quite a few folk who couldn't use Linux with a gui now can again.
Hello comrades. I also have this isuue. ATI RS690M on notebook Gateway LT3103u, Debian Unstable, Mesa 10.0.
I tried the latest kernel 3.13 rc6 that includes this patch. Unfortunately, this patch don't fix this problem.
(In reply to comment #86) > I tried the latest kernel 3.13 rc6 that includes this patch. Unfortunately, > this patch don't fix this problem. Please attach your dmesg output both with and without the patch.
Created attachment 91519 [details] kernel 3.13 rc6 dmesg, Gateway LT3103u
Created attachment 91520 [details] kernel 3.13 rc6 (without rs690m patch) dmesg, Gateway LT3103u
*Programmist11180 <programmer11180@programist.ru>,* your dmesg looks like the patch is working as intended. what are your symptoms? This bug is not the only one affecting these cards (just the longest running) Perhaps you could post a screen capture.
Symptoms same as on screenshots in attachments. I found out that graphics corruption appears with this /etc/X11/xorg.conf Section "Device" Identifier "Radeon" Driver "radeon" Option "EXAPixmaps" "off" EndSection When "EXAPixmaps" is "on", no graphic corruption. It is fair for ALL kernels that I tested (3.2 , 3.12 , 3.13rc6). Appears only in applications that used opengl (glxgears for example).
Looks like maybe * bug 35998 <https://bugs.freedesktop.org/show_bug.cgi?id=35998> ?* *Your observation about it only happening when Exapixmaps is off might be really helpful* On Sun, Jan 5, 2014 at 10:29 AM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 91 <https://bugs.freedesktop.org/show_bug.cgi?id=35457#c91> > on bug 35457 <https://bugs.freedesktop.org/show_bug.cgi?id=35457> from > Programmist11180 <programmer11180@programist.ru> * > > Symptoms same as on screenshots in attachments. > > I found out that graphics corruption appears with this /etc/X11/xorg.conf > > Section "Device" > Identifier "Radeon" > Driver "radeon" > Option "EXAPixmaps" "off" > EndSection > > When "EXAPixmaps" is "on", no graphic corruption. > It is fair for ALL kernels that I tested (3.2 , 3.12 , 3.13rc6). > Appears only in applications that used opengl (glxgears for example). > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
Created attachment 111702 [details] GDM capture Hi, just reporting another system with this bug. My box has a RS690 X1200 card and Fedora 21 installed. I'll try the patches and workarounds commented and let you know how it goes.
Created attachment 111706 [details] Output of dmesg | grep radeon Hi, I've downloaded the kernel sources for 3.17.7-300 version (according to my current kernel) from Fedora repositories and all patches are already applied. Also tried the workarounds and nothing have changed. The attachment shows my dmesg output.
Created attachment 112436 [details] x1250, Teeworlds, Mint 17 Got a rs600m(x1250) (where exactly is the difference to rs690/why is it so mixed here?), and my problems looks almost identical to the bug(s) mentioned here. I attached a a picture from Teeworlds, I have same problem with text in other games like Warzone 2100 or menu in HalfLife. Both using Mint. Furthermore I got a problem with fresh installed Ubuntu, where the problem is the top-menubar, which also looks 'striped' that way and 'defect', but now I am back on Mint 17.1. Hopefully anyone can help :(
Created attachment 112437 [details] x1250, Warzone2100, Mint 17 Second picture, Warzone 2100. For more informations write me please, my linux-knowledge is as bad as my english, so I do not exactly know what is necessary or important here.
Some additional infos: dmesg | grep -i radeon [ 3.414242] [drm] radeon kernel modesetting enabled. [ 3.414339] fb: switching to radeondrmfb from EFI VGA [ 3.415143] radeon 0000:01:05.0: VRAM: 256M 0x0000000070000000 - 0x000000007FFFFFFF (256M used) [ 3.415146] radeon 0000:01:05.0: GTT: 512M 0x0000000080000000 - 0x000000009FFFFFFF [ 3.415274] [drm] radeon: 256M of VRAM memory ready [ 3.415276] [drm] radeon: 512M of GTT memory ready. [ 3.424768] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 3.426141] radeon 0000:01:05.0: WB enabled [ 3.426146] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000080000000 and cpu addr 0xffff880035a38000 [ 3.426166] [drm] radeon: irq initialized. [ 3.426387] [drm] radeon: ring at 0x0000000080001000 [ 3.428091] [drm] radeon atom DIG backlight initialized [ 3.428096] [drm] Radeon Display Connectors [ 4.040201] fbcon: radeondrmfb (fb0) is primary device [ 4.040282] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device [ 4.040285] radeon 0000:01:05.0: registered panic notifier [ 4.044113] [drm] Initialized radeon 2.39.0 20080528 for 0000:01:05.0 on minor 0 ------------------------------------------------------------ glxinfo | grep gl server glx vendor string: SGI server glx version string: 1.4 server glx extensions: client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vdpau_interop, ------------------------------------------------------------ I changed nomodeset at startup with shift, e - but it resulted in complete garbage - the splash-screen where I normally enter my password was completely defect, b/w and absolutely unusable. I furthermore created xorg.conf, edited it with nano at the right place and changed the line with 'Option "EXAPixmaps"' to "off", afther that it started nomal - but thats all, its also unusable. Screen corrupts in a way I've never seen before, parts were rotated completely, looked crazy. But that was not what I looked for :D ------------------------------------------------------------ These problems seems to be 4 years old (!) and affect a whole generation oflaptops/graphic-chips...and there is no solution after such a long time????? Whats going on??? I thought linux-community is very fast in solving stabilitiy-problems?! Ok, to troll around is no solution...but what/where is a solution? 4 years(!) - will there ever be a solution, or can I buy a new laptop for playing simple games even if this one is like new??? Why has such a problem not more focus/attention? When I remember right, the EEE of my ex has same looking probs, too - but thats another task.
In case this was just assigned to a nonexistent contributor, I've reset this to the default. I don't even have this card anymore -- someone who does might want to read through this, and open a new bug, closing this one. This one probably has too many comments to be trackable. If someone does take up this task, make sure to reference this bug in the newly-created one.
..that is, to read through this, and post a summary in the new one.
I have a similar problem My bug reports on other treckers and full information about my hardware: https://bugzilla.gnome.org/show_bug.cgi?id=746160 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1434826
Another year with only a half working laptop :( Is there NOTHING I can do?!???!!!??! What causes the problems? The free radeon-driver? Mesa? PLEASE HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(In reply to Micha from comment #101) > Another year with only a half working laptop :( > > Is there NOTHING I can do?!???!!!??! > > What causes the problems? The free radeon-driver? Mesa? > > PLEASE > HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!! I looked at your screenshots, Micha. Your problem looks like it has to do with the font and typeface. Both applications look like they use graphical tilesets to display fonts. I have no idea whether you are experiencing the same type of corruption described in this bug or something else. The problem with my system (which was fixed) was that the manufacturer (Gateway) put incorrect information about the amount of video ram. The manufacturer never supported Linux, and this type of graphics chip is relatively rare and odd compared to other radeon families. Open source radeon developers try to support us, but they don't have our same hardware. To be honest, I don't expect any remaining bugs with rs690 to get much attention. They are hard to find, and often problems with the firmware or hardware that radeon devs can't fix, only try to work around. Bottom line: No one is still looking at the driver for this hardware. You have access to the source code and can try looking at it yourself, but the pros haven't been able to figure it out; it might be hard or impossible to fix.
Fixing an OS by myself...I tell you how I fix it - I sell my almost new looking laptopt in which I spend a lot of money to hold it up to date while hoping the annoying problem with the graphics will be fixed hopefully in future since ~2 years - to a dumb idiot on Ebay next time as a great Linux-pc. It is useless...most Distros are completely unusable and if you find a ´working´ distro, games won´t work - that (free-)driver story was definately no good advertisment for Amd and Linux-community! Thanks anyway as you had a look at it and as it is not your fault personally.
News? LOL
Hehehe! Uh, you can just give up on this bug. Might be a better idea if you start a new bug (even if it's the same issue as this one). There's too much crap in this bug to really make any sense of it, and I (the one that started the bug) have long since bricked (and ditched) my laptop while trying to do bios workarounds for the issue, so I can't help with it at all.
Closing as "Resolved / wontfix", because there's no option for "Resolved / Nobody who has the skills cares, and nobody who cares has the skills." It's a shame, as RS690M used to be a great low-end card on Linux.
..thank you though, for those who did put in some time on this bug -- Alex Deucher, and various people who have the bug that have put in photos, logs, and diagnostic time.
Alreay made a report for x.org. Youre right, such a nice chipset/laptop - and every Raspberry Pi for a few dollars has better drivers today. Its a shame...minutes ago I found out that Ubuntu Mate seems to work, too - but not Kodi. Installed it on Ubuntu Mate and the osd while playing a video has the same striped look as the menubar of Ubuntu's Unity-desktop...not sure if it is the same problem but it looks almost the same. Kodi, most games and most distros - there is almost nothing we can do anymore with these laptops until someone repairs the driver.
Thanks for opening the new bug report, it would be nice to see this fixed at some point. I wonder if it's an issue on Wayland, too? ..in any case, I hope for a lot of peoples' sakes that the new bug finds someone who can fix the issue. :-)
Does current Mesa Git master work better WRT any of these issues? An RSxxx specific fix just landed: https://cgit.freedesktop.org/mesa/mesa/commit/?id=02675622b02742960678c438f1b239321c075f50
I still have my laptop, but I am a complete noob and do not know how to test this.... Actually installed is Mint Mate 18 if I am not wrong
Still the same problems (with latest Mint Mate + Oibaf-ppa)
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.