linux-kernel - Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)

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-prev] [day] [month] [year] [list]

Date:	Thu, 06 Nov 2008 18:52:41 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Paul Collins <paul@...ly.ondioline.org>
Cc:	James Cloos <cloos@...loos.com>,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [Linux-fbdev-devel] radeonfb lockup in .28-rc (bisected)

On Thu, 2008-11-06 at 19:00 +1300, Paul Collins wrote:
> Benjamin Herrenschmidt <benh@...nel.crashing.org> writes:
> > Heh, it would have been easier to do
> >
> > 	width = (image->width | 0x1f) + 1; 
> Benjamin Herrenschmidt <benh@...nel.crashing.org> writes:
> > Oh and you also need to change the src_bytes calculation 
> 
> With the slightly less embarrassing patch below applied and using the
> default 8x16 font, the machine boots successfully with the expected
> gibberish console display.  I can then setfont one of the large fonts
> and it does not lock up.  The gibberish changes and if I do dmesg I even
> get a few chunks of legible output: http://ondioline.org/~paul/corruption.png

Ok. Well, that's both good and bad news. Good news is, we have a handle
on what the bug can be, ie, the comment in X might refer to an actual HW
limitation/bug, though I find it strange that it works fine in some
cases and not others.

The bad news is, I yet to figure out if we have a proper way out of it
using the clipping etc... that doesn't involve making the acceleration
totally worthless in the first place since it's already not very
interesting on a few platforms.

I'll dig but I'm afraid chances are that I'll disable the acceleration
by default unless some special command line arg is passed so that David
can still get his faster console on sparc.

Maybe using a completely different approach such as caching pre-expanded
glyphs would lead to better results... though I think it's harder to
implement with fbcon.

Cheers,
Ben.

> 
> diff --git a/drivers/video/aty/radeon_accel.c b/drivers/video/aty/radeon_accel.c
> index 8718f73..6dbd24a 100644
> --- a/drivers/video/aty/radeon_accel.c
> +++ b/drivers/video/aty/radeon_accel.c
> @@ -176,6 +176,7 @@ static void radeonfb_prim_imageblit(struct radeonfb_info *rinfo,
>  {
>  	unsigned int src_bytes, dwords;
>  	u32 *bits;
> +	int width;
>  
>  	radeonfb_set_creg(rinfo, DP_GUI_MASTER_CNTL, &rinfo->dp_gui_mc_cache,
>  			  rinfo->dp_gui_mc_base |
> @@ -208,9 +209,11 @@ static void radeonfb_prim_imageblit(struct radeonfb_info *rinfo,
>  	 * work ok for me without that and the doco doesn't seem to imply
>  	 * there is such a restriction.
>  	 */
> -	OUTREG(DST_WIDTH_HEIGHT, (image->width << 16) | image->height);
> +	/* Let us pad. */
> +	width = (image->width | 0x1f) + 1;
> +	OUTREG(DST_WIDTH_HEIGHT, (width << 16) | image->height);
>  
> -	src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
> +	src_bytes = (((width * image->depth) + 7) / 8) * image->height;
>  	dwords = (src_bytes + 3) / 4;
>  	bits = (u32*)(image->data);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/