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. 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
