[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <200808301452.04634.gene.heskett@verizon.net>
Date: Sat, 30 Aug 2008 14:52:04 -0400
From: Gene Heskett <gene.heskett@...izon.net>
To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jaswinder Singh <jaswinder@...radead.org>,
xorg@...ts.freedesktop.org
Subject: Re: Linux-2.6.27-rc5, drm errors in log
Greetings all;
A re-repeat of a previous posting which has not drawn a comment. With added
content, added CC to a patch author, and some new questions.
Machine is an F8 install, Athlon xp-2800 on an nforce2 motherboard, running
an older radeon 9200SE (RV280 based) video card. No problems if I reboot
to 2.6.27-rc4.
I'm drowning in these errors:
Aug 30 13:21:05 coyote kernel: [14927.850078] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:21:05 coyote kernel: [14927.861335] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:21:05 coyote kernel: [14928.060233] [drm] wait idle failed status : 0x80076100 0x00000000
Aug 30 13:21:07 coyote kernel: [14929.557075] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:21:07 coyote kernel: [14929.568869] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:21:08 coyote kernel: [14931.028882] [drm] wait for fifo failed status : 0x80036100 0x00000000
Aug 30 13:21:08 coyote kernel: [14931.039896] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:21:18 coyote kernel: [14940.515114] [drm] wait for fifo failed status : 0x80076100 0x00000000
Aug 30 13:27:27 coyote kernel: [15310.125656] [drm] wait for fifo failed status : 0x80066107 0x00000000
I have rebuilt and rebooted several times now, adjusting things like the
timer frequency, and modular vs builtin for ati and drm stuff with no
apparent effect.
The .config is attached for the build under way now. Do I have something
fubar'd? Or is this a newly hatched bug?
Thanks.
Digging deeper, I found this in drivers/gpu/drm/radeon/radeon.c:
========
static int radeon_do_wait_for_fifo(drm_radeon_private_t * dev_priv, int entries)
{
int i;
dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
for (i = 0; i < dev_priv->usec_timeout; i++) {
int slots = (RADEON_READ(RADEON_RBBM_STATUS)
& RADEON_RBBM_FIFOCNT_MASK);
if (slots >= entries)
return 0;
DRM_UDELAY(1);
}
DRM_INFO("wait for fifo failed status : 0x%08X 0x%08X\n",
RADEON_READ(RADEON_RBBM_STATUS),
RADEON_READ(R300_VAP_CNTL_STATUS));
#if RADEON_FIFO_DEBUG
DRM_ERROR("failed!\n");
radeon_status(dev_priv);
#endif
return -EBUSY;
}
======
Now I would interpret RADEON_READ(R300_VAP_CNTL_STATUS)); as referring to
an R300 based card. This one is not, dmesg indicating it has loaded the
R200 microcode for an RV280 based card. This would explain why the 2nd value
returned is always $00000000, but the question then becomes:
Why is the driver attempting to read an R300 register from an R200 card?
Does the added code snippet that is not there in the -rc4 version
of this driver:
DRM_INFO("wait idle failed status : 0x%08X 0x%08X\n",
RADEON_READ(RADEON_RBBM_STATUS),
RADEON_READ(R300_VAP_CNTL_STATUS));
not need some sort of a conditional so it only exec's on an R300 card?
Or is my carrying forward the firmware/radeon directory, as opposed to
using the patch contained in this message
"Message-Id: <1218095497.4016.3.camel@...winder.satnam>"
the culprit? I'll have to plead that I'm in over my head here and I will
see if that patch will still apply. However, the copy the directory bit did
work just fine for -rc3 and -rc4.
I'd like to keep using the microcode as it cuts the screen switching time
by about 80% here, 10 seconds to initially load a new background image
is now a fat 2 seconds, a worthwhile improvement IMO.
Thanks for any hints or new patches.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"The only way I can lose this election is if I'm caught in bed with a dead
girl or a live boy."
-- Louisiana governor Edwin Edwards
View attachment ".config" of type "text/plain" (56327 bytes)
Powered by blists - more mailing lists