When the server comes up the screen is colourfull garbled snow, and a mousepointer square of different texture is visible and movable at snappy speed. killing the server with 'ctrl alt backspace' dumps me back in the linux console (non-FB, plaintext) which is messed up colourfully entirely also. reboot required to reset. Driver "radeon" Default options, everything autoprobed. Varying options has no effect. Also affects xorg 7.0 in the same way. Temp solution: This card only works with "vesa" driver for me: Driver "vesa" Option "ShadowFB" "0" #for cvs ## Card details: ## Integrated on Asus P4RD1-MX Mainboard, PCIE, ## Assigned 128MB System Ram. ## > lspci -n 01:05.0 Class 0300: 1002:5a41 ## > lspci -v 01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5a41 (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 81c3 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at b000 [size=256] Memory at cfff0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at cffc0000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- ## Log: (--) PCI:*(1:5:0) ATI Technologies Inc RS400 [Radeon Xpress 200] rev 0, Mem @ 0xd8000000/27, 0xd7ff00 00/16, I/O @ 0xb000/8, BIOS @ 0xd7fc0000/17
can you attach your xorg log and config when running the radeon driver?
Created attachment 4779 [details] Xorg Log
Created attachment 4780 [details] xorg.conf
Created attachment 4781 [details] test_ignore
Does xorg from cvs work? There were some recent fixes for XPRESS chips that went in after 7.0 was released.
(In reply to comment #5) > Does xorg from cvs work? this is xorg xserver from cvs, on top of 7.0
(In reply to comment #6) > (In reply to comment #5) > > Does xorg from cvs work? > > this is xorg xserver from cvs, on top of 7.0 or even just the radeon driver from cvs on top of 7.0. you can grab binary snapshots here too if you prefer: http://dri.freedesktop.org/wiki/Download#head-55420c59a1c2e9a70f07a6fa02f0d228ffb87b76
(In reply to comment #7) lrwxrwxrwx 1 root root 17 2006-02-28 17:46 radeon_drv.so -> radeon_drv.so_cvs -rwxr-xr-x 1 root root 281K 2006-02-28 17:41 radeon_drv.so_cvs -rwxr-xr-x 1 root root 273K 2006-02-26 21:04 radeon_drv.so_orig The 2006-02-28cvs copy works better than my original2006-02-26cvs copy, and the 7.0 copy. It renders stuff visibly atleast, but it's slow, with second long irresponsiveness when switching between windows, and still has rendering/image update errors. On the positve side XV seems to work and the refresh is like I'm used to (85 comapred to 60 for vesa.)
(In reply to comment #8) > (In reply to comment #7) > > lrwxrwxrwx 1 root root 17 2006-02-28 17:46 radeon_drv.so -> radeon_drv.so_cvs > -rwxr-xr-x 1 root root 281K 2006-02-28 17:41 radeon_drv.so_cvs > -rwxr-xr-x 1 root root 273K 2006-02-26 21:04 radeon_drv.so_orig > > The 2006-02-28cvs copy works better than my original2006-02-26cvs copy, and the > 7.0 copy. > > It renders stuff visibly atleast, but it's slow, with second long > irresponsiveness when switching between windows, and still has rendering/image > update errors. > On the positve side XV seems to work and the refresh is like I'm used to (85 > comapred to 60 for vesa.) > can you post a log from the cvs driver?
> can you post a log from the cvs driver? The upload function is broken.
Created attachment 4789 [details] cvs 28/2 Xorg log
(In reply to comment #11) > Created an attachment (id=4789) [edit] > cvs 28/2 Xorg log > The log looks ok. can you get a shot of the corruption you are seeing? Unfortunately we have no documentation on the XPRESS chips so they are complete guess work. For one thing they have a different memory controller from the other radeons. Try setting the following options and see if they help: Option "Videoram" "131072" # try other common amounts like 32MB, 64MB as well Option "DisplayPriority" "high" Also does your XPRESS chip have discrete vram or does it use system ram (or some combination)? The XPRESS chips can use various combinations of discrete and system ram which will probably need special handling.
(In reply to comment #12) > Try setting the following options and see if they help: > Option "Videoram" "131072" # try other common amounts like 32MB, 64MB as well > Option "DisplayPriority" "high" I tried that, it seems to fall back to the 16 MB still. I tried to make a screenshot with "dump", but it doesnt display what I see on screen. I can describe the major flaw though, it doesnt update parts that were covered by menus sometimes. And in Seamokey 1.0 (firefox) when I start with a blank page, the page frame is rendered in the background color, or black. The location bar field also has this problem sometimes. Page rendering is normal otherwise, with some overlapping (unupdated) text sometimes. AA xterm Text rendering is also verry slow. Gtk2 menu rendering speed is fast, but also sometimes buttons arent shown that are supposed to be there, they willr eappear when mouseovering, but sometimes stay away.
(In reply to comment #13) > (In reply to comment #12) > > Try setting the following options and see if they help: > > Option "Videoram" "131072" # try other common amounts like 32MB, 64MB as well > > Option "DisplayPriority" "high" > > I tried that, it seems to fall back to the 16 MB still. > > I tried to make a screenshot with "dump", but it doesnt display what I see on > screen. I can describe the major flaw though, it doesnt update parts that were > covered by menus sometimes. > And in Seamokey 1.0 (firefox) when I start with a blank page, the page frame is > rendered in the background color, or black. The location bar field also has this > problem sometimes. Page rendering is normal otherwise, with some overlapping > (unupdated) text sometimes. > AA xterm Text rendering is also verry slow. Gtk2 menu rendering speed is fast, > but also sometimes buttons arent shown that are supposed to be there, they willr > eappear when mouseovering, but sometimes stay away. > > Does setting "NoAccel" help? How about switching "AccelMethod" between EXA and XAA?
(In reply to comment #14) > "AccelMethod" between EXA and XAA? Yes, that fixed most of the layer/update issues, also feels a little faster. Text cursor behaves a little odd still. Sometimes disappears or is placed in the wrong spot. so now I have: Section "Device" Identifier "ATI X200" Driver "radeon" Option "Videoram" "131072" ### no noticable effect Option "NoAccel" "0" ### 1/0 no noticable effect Option "AccelMethod" "EXA" ### Fixes update problems Option "DisplayPriority" "high" ### no noticable effect Screen 0 EndSection
Created attachment 4992 [details] fglrx xorg.log fglrx xorg.log, just to show how it initializes memory, may be of help?
*** Bug 6398 has been marked as a duplicate of this bug. ***
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Is this problem still occurring with that latest driver from git?
closing due to inactivity.
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.