Re: radeonfb lockup in .28-rc (bisected)

quoted

quoted

quoted

quoted

"Benjamin" == Benjamin Herrenschmidt [off-list ref] writes:

Benjamin> First, let's see if it's related to the imageblit. Can you
Benjamin> re-apply the reverted patch and apply this little hack on top:

Benjamin> +#if 0
Benjamin>  	/* We only do 1 bpp color expansion for now */
Benjamin>  	if (info->flags & FBINFO_HWACCEL_DISABLED || image->depth != 1)
Benjamin>  		goto fallback;
Benjamin> @@ -275,6 +276,7 @@ void radeonfb_imageblit(struct fb_info *
Benjamin>  	return;
 
Benjamin>   fallback:
Benjamin> +#endif

Benjamin> And let me know if that makes it not lockup.

Indeed, if-zero-ing out that block does work.

Since that if essentially removes to call to radeonfb_prim_imageblit(),
I wonder whether:

        /* X here pads width to a multiple of 32 and uses the clipper to
         * adjust the result. Is that really necessary ? Things seem to
         * work ok for me without that and the doco doesn't seem to imply
         * there is such a restriction.
         */

is relevant?

Or whether the card is unhappy with the creg settings.  It does seem,
now that I read the code, that:

void radeon_fifo_update_and_wait(struct radeonfb_info *rinfo, int entries)
{
        int i;

        for (i=0; i<2000000; i++) {
                rinfo->fifo_free = INREG(RBBM_STATUS) & 0x7f;
                if (rinfo->fifo_free >= entries)
                        return;
                udelay(10);
        }
        printk(KERN_ERR "radeonfb: FIFO Timeout !\n");
        /* XXX Todo: attempt to reset the engine */
}

is in play.  It is probably spinning through all of the 2000000 possible
udelay(10) calls.  I don't think I ever gave it twenty seconds before
giving up.  And certainly not forty seconds, if the freeze happens after
setting the DST_Y_X register.

-JimC
-- 
James Cloos [off-list ref]         OpenPGP: 1024D/ED7DAEA6