Launchpad has imported 52 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=35457.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-03-19T23:24:50+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/0 ------------------------------------------------------------------------ On 2011-03-19T23:30:11+00:00 Brian Visel wrote: Created attachment 44628 A screenshot that clearly displays corruption between program visuals Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/1 ------------------------------------------------------------------------ On 2011-03-19T23:40:35+00:00 Airlied-freedesktop wrote: /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? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/2 ------------------------------------------------------------------------ On 2011-03-20T08:05:49+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/3 ------------------------------------------------------------------------ On 2011-03-20T08:07:25+00:00 Brian Visel wrote: Created attachment 44638 dmesg with KMS enabled Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/4 ------------------------------------------------------------------------ On 2011-03-20T08:08:21+00:00 Brian Visel wrote: Created attachment 44639 Xorg.0.log, KMS enabled Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/5 ------------------------------------------------------------------------ On 2011-03-20T08:51:36+00:00 agd5f wrote: Does: Option "ColorTiling" "False" in the device section of your xorg.conf fix the issue? This might be a duplicate of bug 33929. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/6 ------------------------------------------------------------------------ On 2011-03-20T11:11:05+00:00 Brian Visel wrote: No, that appears to have no effect. (thanks for taking time to troubleshoot this with me) Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/7 ------------------------------------------------------------------------ On 2011-03-21T09:38:40+00:00 Brian Visel wrote: read the 'severity' description in 'help', and updated this to a blocker. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/8 ------------------------------------------------------------------------ On 2011-03-21T09:53:31+00:00 agd5f wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/9 ------------------------------------------------------------------------ On 2011-03-21T10:16:24+00:00 agd5f wrote: Created attachment 44674 check gart table align Can you try this patch and see if it prints an error when you load the driver? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/10 ------------------------------------------------------------------------ On 2011-03-21T14:43:07+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/11 ------------------------------------------------------------------------ On 2011-03-26T16:22:20+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/12 ------------------------------------------------------------------------ On 2011-04-15T21:43:52+00:00 krmolot wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/13 ------------------------------------------------------------------------ On 2011-04-22T02:22:31+00:00 axel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/14 ------------------------------------------------------------------------ On 2011-05-08T08:30:54+00:00 André Oliva wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/15 ------------------------------------------------------------------------ On 2011-05-28T05:20:28+00:00 André Oliva wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/16 ------------------------------------------------------------------------ On 2011-06-02T13:07:01+00:00 Brian Visel wrote: >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.. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/17 ------------------------------------------------------------------------ On 2012-02-25T01:20:16+00:00 Stillcompiling wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/18 ------------------------------------------------------------------------ On 2012-03-10T05:26:27+00:00 Stillcompiling wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/19 ------------------------------------------------------------------------ On 2012-03-12T05:32:06+00:00 Michel-daenzer wrote: (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 . Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/20 ------------------------------------------------------------------------ On 2012-03-12T06:39:06+00:00 agd5f wrote: Might also be related to bug 37679 (interrupt problems). Can you try a similar patch to the ones on that bug? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/21 ------------------------------------------------------------------------ On 2012-03-14T14:43:19+00:00 Cboulte wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/22 ------------------------------------------------------------------------ On 2012-03-15T19:33:58+00:00 Stillcompiling wrote: (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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/23 ------------------------------------------------------------------------ On 2012-03-28T13:06:20+00:00 Carl Fink wrote: Just another user reporting the same bug. Experienced with both Debian (Unstable) and Knoppix on a Gateway LT3119u netbook. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/24 ------------------------------------------------------------------------ On 2012-04-09T20:06:52+00:00 Carl Fink wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/25 ------------------------------------------------------------------------ On 2012-04-09T20:07:41+00:00 Carl Fink wrote: Created attachment 59704 Second attachment showing corruption. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/26 ------------------------------------------------------------------------ On 2012-04-12T07:32:13+00:00 agd5f wrote: 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/ Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/27 ------------------------------------------------------------------------ On 2012-04-12T18:58:27+00:00 Stillcompiling wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/28 ------------------------------------------------------------------------ On 2012-04-12T20:06:52+00:00 Carl Fink wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/29 ------------------------------------------------------------------------ On 2012-04-12T20:29:13+00:00 agd5f wrote: you can use avivotool as well. same syntax. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/30 ------------------------------------------------------------------------ On 2012-04-13T19:43:42+00:00 Carl Fink wrote: 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). Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/31 ------------------------------------------------------------------------ On 2012-04-27T13:50:55+00:00 Brian Visel wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/32 ------------------------------------------------------------------------ On 2012-04-28T05:41:07+00:00 axel wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/33 ------------------------------------------------------------------------ On 2012-04-28T05:47:44+00:00 axel wrote: Created attachment 60735 RS690 BIOS Developers Requster guide RS690 BIOS Developers Register guide Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/34 ------------------------------------------------------------------------ On 2012-04-28T05:51:25+00:00 axel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/35 ------------------------------------------------------------------------ On 2012-04-28T05:59:11+00:00 axel wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/36 ------------------------------------------------------------------------ On 2012-04-28T13:48:49+00:00 mattocompleto wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/37 ------------------------------------------------------------------------ On 2012-05-06T05:39:04+00:00 Carl Fink wrote: 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? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/38 ------------------------------------------------------------------------ On 2012-05-06T11:36:54+00:00 Stillcompiling wrote: (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? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/39 ------------------------------------------------------------------------ On 2012-05-07T18:09:56+00:00 Brian Visel wrote: There has never been a working version of the radeon driver -- last working version was radeonhd, which is a different driver. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/40 ------------------------------------------------------------------------ On 2012-05-07T18:19:59+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/41 ------------------------------------------------------------------------ On 2012-05-09T06:48:46+00:00 agd5f wrote: (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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/42 ------------------------------------------------------------------------ On 2012-07-23T02:37:48+00:00 Carl Fink wrote: So this bug looks as if it will not be fixed. Who should I bribe^Wdonate money to in order to revive radeonhd? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/43 ------------------------------------------------------------------------ On 2012-07-23T06:20:41+00:00 Brian Visel wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/44 ------------------------------------------------------------------------ On 2012-07-24T01:58:45+00:00 Carl Fink wrote: 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 .... Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/45 ------------------------------------------------------------------------ On 2012-07-24T07:34:48+00:00 Josselin Mouette wrote: Note that it can be worked around by disabling RENDER acceleration. Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/46 ------------------------------------------------------------------------ On 2012-07-24T10:15:36+00:00 Carl Fink wrote: (In reply to comment #46) > Note that it can be worked around by disabling RENDER acceleration. Can you be more specific? Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/47 ------------------------------------------------------------------------ On 2012-09-10T13:03:22+00:00 agd5f wrote: *** Bug 54704 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/48 ------------------------------------------------------------------------ On 2012-09-10T13:04:26+00:00 agd5f wrote: Does this patch help? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4a2b6662c3632176b4fdf012243dd3751367bf1f Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/49 ------------------------------------------------------------------------ On 2012-09-10T13:59:10+00:00 Nicolas Delvaux wrote: 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). Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/50 ------------------------------------------------------------------------ On 2012-09-12T08:02:07+00:00 Nicolas Delvaux wrote: 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). Reply at: https://bugs.launchpad.net/linux/+bug/1049630/comments/51 ** Changed in: linux Status: Unknown => Confirmed ** Changed in: linux Importance: Unknown => Critical ** Bug watch added: Novell/SUSE Bugzilla #678264 https://bugzilla.novell.com/show_bug.cgi?id=678264 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1049630 Title: gnome-shell weird lines To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1049630/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
