Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)
From: Benjamin Herrenschmidt
Date: Sun Nov 02 2008 - 16:49:36 EST
> /* 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?
Possibly.
> 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.
Well, setting DST_Y_X is what triggers the transfer. The above means
that the FIFO isn't emptying (ie, the engine is locked up).
There's a few things we can do from here:
- We can try indeed to do the alignment things though that involves
using the clipper etc... and thus complicates things significantly
- We can also try putting a few more bubbles in the FIFO in case that's
where the problem is
- We can blacklist that chip for imageblit (it's not a huge improvement
on x86 anyway).
- We can be smart, reduce the timeout above, and "detect" the lockup,
when it happens, reset the engine and disable the acceleration that
locked up.
Now, the problem is ... My second son was just born last wed. so I'm
pretty unavailable right now. Thus, for .29, I'm tempted to go for the
simpler approach which is to blacklist M7's from imageblit acceleration.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/