----- 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 (00000000), setting to 29002901 > > > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (02000000), setting to > > 02000000 > > > > > Hey! I have these as well, exactly: > > > > > (WW) RADEON(0): Restoring MEM_CNTL (00000000), setting to 29002901 > > > > (WW) RADEON(0): Restoring CONFIG_MEMSIZE (02000000), setting to 02000000 > > > > > > 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. > > +----------------------------------+-----------------------------------+ > | 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 > _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
