Re: [XFree86] Have you dropped radeon 7200 support?
- Original Message - From: "Marc Aurele La France" <[EMAIL PROTECTED]> To: "hy0" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 8:06 AM Subject: Re: [XFree86] Have you dropped radeon 7200 support? > On Thu, 23 Jan 2003, hy0 wrote: > > > > > > No, but these warnings are special: > > > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to > > 0200 > > > > > Hey! I have these as well, exactly: > > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > > > > > Don't know if they could explain the problem though. > > > > > Since they have something to do with memory, I am tending to think so, > > > > because one of the other symptoms of this problem is that even once I > > > > exit the Xserver, the console display is corrupt, as if video memory > > > > was being tampled on. > > > > Indeed, this is the most outstanding thing in common between both of > > > you. I suspect it could be related to int10. Something like Option > > > "NoInt10" and/or not loading the int10 module might work for testing > > > that, assuming the BIOS initializes the card on bootup. > > > I noticed there is a patch (CVS radeon_driver.c v1.72) a few weeks ago which > > enabled some __alpha__ path code for initializing MEM_CNTL etc. Not sure if > > the change is added intentionally or accidentally and if it's well tested on > > all supported cards. This doesn't seem to cause problem on all my cards. But > > it still looks suspicious. The code also writes to some MPP registers which > > don't even exist on Radeon chips. > > This is only partially true. The register does in fact exist. It's just > that the driver refers to it with an incorrect name. The register has > more to do with the chip's PCI memory decoding than with MPP. > > Anyway, this change was introduced to fix two separate problems: > > 1) If MEM_CNTL and CONFIG_MEMSIZE are not re-initialised to their power-up >value, a BIOS bug ends up corrupting the chip's memory interface. > > 2) If the misnamed MPP_TB_CONFIG register is not set properly, a bug in >the chip causes it to return zeroes for read-outs of its PCI ROM. > > Both issues have been seen using various Radeon cores, including R200, > RV200, etc. > > The second problem appears to be a carry-over from the original R128 core. > I've been able to duplicate the behaviour using a number of Rage 128's > (where MPP_TB_CONFIG is indeed correctly named). The Rage 128 aspect of > this issue has yet to be dealt with in our code. > > All these issues show up when an attempt is made to initialise the adapter > more than once between resets (i.e. reboots). For secondary adapters, > this occurs when the server is re-run. For primary adapters, when used on > platforms that don't make the initialised adapter BIOS available. > > The original patch submission for this #ifdef'ed itself for Alpha's. But > the truth is that these are adapter issues. That they show up more on > certain architectures than others is irrelevent. Thanks for the explanations, now I can see what this is about. However I still have some concerns about this code. Indeed, Radeon chips do have 0x1c0 (misnamed MPP_TB_CONFIG) as SEPROM_CNTL register. Modifying/restoring its SCK_PRESCALE field is unlikely to be the cause of this screen corruption problem. In the current code path, even for a properly POSTed card, MEM_CNTL is set to zero and then restored back. This step may cause some side effect to the memory controller. Properly initializing MEM_CNTL/MEM_SIZE should take several steps (I may miss something): 1. wait for memory control idle (MC_STATUS). 2. configure each channel (MEM_CNTL). 3. reset memory (MEM_SDRAM_MOD_REG). 4. check if each channel works correctly. Simply setting MEM_CNTL to zero and then restoring it back may put memory controller in some bad state. Since Cedric doesn't seem to have this problem with old CVS code, maybe he can try to change the current CVS code from #if 0/* !defined(__alpha__) */ back to #if !defined(__alpha__) See if it can make any difference. At least we can rule out MEM_CNTL related code being the cause. All in all, bringing up an un-POSTed card takes quite a few steps (not only MEM_CNTL). This is not properly/completely implemented in the current Radeon driver which makes multi-card set up unreliable. Hui > Marc. > > +---
Re: [XFree86] Have you dropped radeon 7200 support?
On Thu, 23 Jan 2003, Brian J. Murrell wrote: > > All these issues show up when an attempt is made to initialise the adapter > > more than once between resets (i.e. reboots). > Yes. I have noticed that the first invocation of the server after a > reboot (at least starts out) is clean. But it seems to degrade. Using > the 20030122 snapshot, I have a mostly clear screen, but it gets the > corruption artifacts when certain "pixmap" operations are performed. > For instance, Galeon 1.3.1 frequently shows the corruption in it's > windows while other parts of the screen are not corrupt. If I scroll > the galeon HTML widget the corruption follows the scroll and if I > scroll back, it comes back clean. > At various other times every window on the screen including the root > window will show the corruption, but often I can just move a window > around the screen and "wipe" the corruption away. If performance degrades during a single server invocation, that's a separate problem than what we're discussing here. > > The original patch submission for this #ifdef'ed itself for Alpha's. But > > the truth is that these are adapter issues. That they show up more on > > certain architectures than others is irrelevent. > So can we have the code that is #ifdef'd for Alphas not #ifdefe'd > before the next snapshot then? Let's see if it improves the problems > on Intel platforms too. You need better glasses. This code isn't currently #ifdef'ed for Alpha. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
On Thu, Jan 23, 2003 at 09:06:00AM -0700, Marc Aurele La France wrote: > > All these issues show up when an attempt is made to initialise the adapter > more than once between resets (i.e. reboots). Yes. I have noticed that the first invocation of the server after a reboot (at least starts out) is clean. But it seems to degrade. Using the 20030122 snapshot, I have a mostly clear screen, but it gets the corruption artifacts when certain "pixmap" operations are performed. For instance, Galeon 1.3.1 frequently shows the corruption in it's windows while other parts of the screen are not corrupt. If I scroll the galeon HTML widget the corruption follows the scroll and if I scroll back, it comes back clean. At various other times every window on the screen including the root window will show the corruption, but often I can just move a window around the screen and "wipe" the corruption away. > The original patch submission for this #ifdef'ed itself for Alpha's. But > the truth is that these are adapter issues. That they show up more on > certain architectures than others is irrelevent. So can we have the code that is #ifdef'd for Alphas not #ifdefe'd before the next snapshot then? Let's see if it improves the problems on Intel platforms too. Thanx, b. -- Brian J. Murrell msg00940/pgp0.pgp Description: PGP signature
Re: [XFree86] Have you dropped radeon 7200 support?
On Thu, 23 Jan 2003, hy0 wrote: > > > > No, but these warnings are special: > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to > 0200 > > > Hey! I have these as well, exactly: > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > > > Don't know if they could explain the problem though. > > > Since they have something to do with memory, I am tending to think so, > > > because one of the other symptoms of this problem is that even once I > > > exit the Xserver, the console display is corrupt, as if video memory > > > was being tampled on. > > Indeed, this is the most outstanding thing in common between both of > > you. I suspect it could be related to int10. Something like Option > > "NoInt10" and/or not loading the int10 module might work for testing > > that, assuming the BIOS initializes the card on bootup. > I noticed there is a patch (CVS radeon_driver.c v1.72) a few weeks ago which > enabled some __alpha__ path code for initializing MEM_CNTL etc. Not sure if > the change is added intentionally or accidentally and if it's well tested on > all supported cards. This doesn't seem to cause problem on all my cards. But > it still looks suspicious. The code also writes to some MPP registers which > don't even exist on Radeon chips. This is only partially true. The register does in fact exist. It's just that the driver refers to it with an incorrect name. The register has more to do with the chip's PCI memory decoding than with MPP. Anyway, this change was introduced to fix two separate problems: 1) If MEM_CNTL and CONFIG_MEMSIZE are not re-initialised to their power-up value, a BIOS bug ends up corrupting the chip's memory interface. 2) If the misnamed MPP_TB_CONFIG register is not set properly, a bug in the chip causes it to return zeroes for read-outs of its PCI ROM. Both issues have been seen using various Radeon cores, including R200, RV200, etc. The second problem appears to be a carry-over from the original R128 core. I've been able to duplicate the behaviour using a number of Rage 128's (where MPP_TB_CONFIG is indeed correctly named). The Rage 128 aspect of this issue has yet to be dealt with in our code. All these issues show up when an attempt is made to initialise the adapter more than once between resets (i.e. reboots). For secondary adapters, this occurs when the server is re-run. For primary adapters, when used on platforms that don't make the initialised adapter BIOS available. The original patch submission for this #ifdef'ed itself for Alpha's. But the truth is that these are adapter issues. That they show up more on certain architectures than others is irrelevent. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
> On Mit, 2003-01-22 at 03:26, Brian J. Murrell wrote: > > On Mon, Jan 20, 2003 at 11:15:17PM +0100, Michel Dänzer wrote: > > > > > > No, but these warnings are special: > > > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > > > Hey! I have these as well, exactly: > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > > > > Don't know if they could explain the problem though. > > > > Since they have something to do with memory, I am tending to think so, > > because one of the other symptoms of this problem is that even once I > > exit the Xserver, the console display is corrupt, as if video memory > > was being tampled on. > > Indeed, this is the most outstanding thing in common between both of > you. I suspect it could be related to int10. Something like Option > "NoInt10" and/or not loading the int10 module might work for testing > that, assuming the BIOS initializes the card on bootup. I noticed there is a patch (CVS radeon_driver.c v1.72) a few weeks ago which enabled some __alpha__ path code for initializing MEM_CNTL etc. Not sure if the change is added intentionally or accidentally and if it's well tested on all supported cards. This doesn't seem to cause problem on all my cards. But it still looks suspicious. The code also writes to some MPP registers which don't even exist on Radeon chips. Hui > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > XFree86 mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xfree86 > ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
On Wed, Jan 22, 2003 at 07:41:42PM +0100, Michel Dänzer wrote: > > Indeed, this is the most outstanding thing in common between both of > you. Indeed considering Cedric's card is AGP and mine PCI. > I suspect it could be related to int10. Something like Option > "NoInt10" OK, I have added that. Just waiting for some currently running tasks to complete before restarting X. > and/or not loading the int10 module Is there a more straightforward way of preventing this module from loading than just moving it out of the way on the filesystem? > might work for testing > that, assuming the BIOS initializes the card on bootup. I will give both of these a try and report back. b. -- Brian J. Murrell msg00876/pgp0.pgp Description: PGP signature
Re: [XFree86] Have you dropped radeon 7200 support?
On Mit, 2003-01-22 at 03:26, Brian J. Murrell wrote: > On Mon, Jan 20, 2003 at 11:15:17PM +0100, Michel Dänzer wrote: > > > > No, but these warnings are special: > > > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > Hey! I have these as well, exactly: > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > > > Don't know if they could explain the problem though. > > Since they have something to do with memory, I am tending to think so, > because one of the other symptoms of this problem is that even once I > exit the Xserver, the console display is corrupt, as if video memory > was being tampled on. Indeed, this is the most outstanding thing in common between both of you. I suspect it could be related to int10. Something like Option "NoInt10" and/or not loading the int10 module might work for testing that, assuming the BIOS initializes the card on bootup. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
On Mon, Jan 20, 2003 at 11:15:17PM +0100, Michel Dänzer wrote: > > No, but these warnings are special: > > (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Hey! I have these as well, exactly: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 > Don't know if they could explain the problem though. Since they have something to do with memory, I am tending to think so, because one of the other symptoms of this problem is that even once I exit the Xserver, the console display is corrupt, as if video memory was being tampled on. > They're still supported, a 7200 is working fine in a Cube here. PCI or AGP? > Does the problem also occur with the DRI disabled? Yes. I had to disable DRI for a while while I got DRM into the kernel. Now that it is, I have it enabled again, but it don't work on my card anyway due to it being PCI. DRI seems to want to work with AGP only. So the summary is, that it's corrupt with or without DRI. > If not, does lowering > the AGPMode value help? Mine is a PCI card. Perhaps this has something to do with the problem? My XFree86.0.log and configuration file can be found in a message to this list on Mon, 20 Jan 2003 20:01:31 -0500 under the subject "display corruption on Radeon QD". Any ideas? b. -- Brian J. Murrell msg00830/pgp0.pgp Description: PGP signature
Re: [XFree86] Have you dropped radeon 7200 support?
On Mon, 2003-01-20 at 10:25, Cedric De Wilde wrote: > > The log file(in attachement) didn't mention any special errors. No, but these warnings are special: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Don't know if they could explain the problem though. > Is there any solution instead of using the vesa driver? I'm not the only > one user who have reported this bug, why did nobody answer? I don't think > it's complicated to answer that those card are not supported anymore. They're still supported, a 7200 is working fine in a Cube here. > At least, I'll be sure it's not my fault(my XF86Config is also in > attachement) Does the problem also occur with the DRI disabled? If not, does lowering the AGPMode value help? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
On Mon, 20 Jan 2003, Cedric De Wilde wrote: > Hi, > > Yesterday, I've tested current cvs and my display corruption is always > present( http://daique.dyndns.org/screenshot/xfree-cvs_20030119.png ) > > The log file(in attachement) didn't mention any special errors. Is there > any solution instead of using the vesa driver? I'm not the only one user > who have reported this bug, why did nobody answer? I don't think it's > complicated to answer that those card are not supported anymore. At > least, I'll be sure it's not my fault(my XF86Config is also in > attachement) and that I have to bought a new card, but I'm sure it's a > bug because october cvs work pretty well and that I haven't modified > something. We haven't dropped support for the Radeon 7200. However, we are (almost) all volounteers; there is no-one whose job it is to solve your problem. If we don't have an answer yet there is no point in saying anything until we have worked out a solution, or until we need to contact you for more information. I'm afraid the sad truth is that we cannot assign an engineer to every bug report we recieve, and contact you to say that we are dealing with your problem. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Have you dropped radeon 7200 support?
Hi, Yesterday, I've tested current cvs and my display corruption is always present( http://daique.dyndns.org/screenshot/xfree-cvs_20030119.png ) The log file(in attachement) didn't mention any special errors. Is there any solution instead of using the vesa driver? I'm not the only one user who have reported this bug, why did nobody answer? I don't think it's complicated to answer that those card are not supported anymore. At least, I'll be sure it's not my fault(my XF86Config is also in attachement) and that I have to bought a new card, but I'm sure it's a bug because october cvs work pretty well and that I haven't modified something. Thanks in advance Cedric This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.3 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 14 January 2003 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 20 09:32:45 2003 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "layout1" (**) |-->Screen "screen1" (0) (**) | |-->Monitor "monitor1" (**) | |-->Device "device1" (**) |-->Input Device "Keyboard1" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "be" (**) XKB: layout: "be" (WW) Option "XkbOptions" requires an string value (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse1" (**) FontPath set to "unix/:-1,/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/TTF/" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "AllowMouseOpenFail" (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.99.3, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.2.99.3, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10b9,1647 card , rev b0 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 10b9,5247 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 10b9,5237 card 10b9,5237 rev 03 class 0c,03,10 hdr 00 (II) PCI: 00:04:0: chip 10b9,5229 card 1043,8053 rev c4 class 01,01,fa hdr 00 (II) PCI: 00:06:0: chip 10b9,5237 card 10b9,5237 rev 03 class 0c,03,10 hdr 00 (II) PCI: 00:07:0: chip 10b9,1533 card 10b9,1533 rev 00 class 06,01,00 hdr 00 (II) PCI: 00:09:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: 00:0d:0: chip 1106,3065 card 1186,1400 rev 43 class 02,00,00 hdr 00 (II) PCI: 00:11:0: chip 10b9,7101 card , rev 00 class 06,80,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5144 card 1002,0008 rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory
