linux-kernel - Re: Linux-2.6.27-rc5, drm errors in log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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)