LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Cloos <cloos@jhcloos.com>
Cc: linux-fbdev-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)
Date: Mon, 03 Nov 2008 08:48:59 +1100	[thread overview]
Message-ID: <1225662539.8004.237.camel@pasglop> (raw)
In-Reply-To: <m3k5bt2hsc.fsf@lugabout.jhcloos.org>


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


  reply	other threads:[~2008-11-02 21:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m31vy1k3ea.fsf@lugabout.jhcloos.org>
2008-10-28  0:00 ` David Miller
2008-10-28  1:46   ` James Cloos
2008-10-28  0:05 ` Benjamin Herrenschmidt
2008-10-28  1:50   ` James Cloos
2008-10-28  9:24   ` James Cloos
2008-11-02 21:48     ` Benjamin Herrenschmidt [this message]
2008-11-03  7:01       ` [Linux-fbdev-devel] " Paul Collins
2008-11-03  7:34         ` Benjamin Herrenschmidt
2008-11-04  6:49           ` Paul Collins
2008-11-04 21:33             ` Benjamin Herrenschmidt
2008-11-06  6:00               ` Paul Collins
2008-11-06  7:52                 ` Benjamin Herrenschmidt
2008-11-04 21:36             ` Benjamin Herrenschmidt
2008-11-05  8:39         ` Benjamin Herrenschmidt
2008-11-05 10:28           ` Paul Collins
2008-11-05 20:31             ` Benjamin Herrenschmidt
2008-11-06  3:49             ` Benjamin Herrenschmidt
2008-11-06  4:49               ` Paul Collins
2008-11-03 15:33       ` James Cloos
2008-11-03 20:22         ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225662539.8004.237.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=cloos@jhcloos.com \
    --cc=davem@davemloft.net \
    --cc=khc@pm.waw.pl \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).