Current bk on ppc32: kernel text corruption

Current bk on ppc32: kernel text corruption

[Benjamin Herrenschmidt]

Ok, we may not be over with memory corruption bugs yet. ppc64 now seem
stable running LTP overnight, but my laptop has a page of kernel .text
replaced with zero's as soon as I launch X (and just X, no need to launc
the whole desktop environment).

I suspect remap_pfn_range() but I haven't checked yet.

Ben.

Re: Current bk on ppc32: kernel text corruption

[Benjamin Herrenschmidt]

On Fri, 2005-02-18 at 18:09 +1100, Benjamin Herrenschmidt wrote:
> Ok, we may not be over with memory corruption bugs yet. ppc64 now seem
> stable running LTP overnight, but my laptop has a page of kernel .text
> replaced with zero's as soon as I launch X (and just X, no need to launc
> the whole desktop environment).
> 
> I suspect remap_pfn_range() but I haven't checked yet.

Ok, I found it. It's a bug that was there forever it seems, where
radeonfb accel ops may corrupt kernel memory (via bus master from the
radeon chip) when switching back from X, due to X remapping some areas
of the card vs. fbcon calling some radeonfb accel ops before radeonfb
has a chance to re-initialize the chip (when switching back from X).

I'm cooking a workaround patch for 2.6.11, will be ready as soon as I
have tested. Proper fix is to make sure fbcon never calls any fbdev
accel op before the chip has been properly restored (by a set_var call),
but that is beyond the scope of 2.6.11 I suppose...

Ben.

[PATCH] radeonfb: Workaround memory corruption accel problem

[Benjamin Herrenschmidt]

Hi !

A conflict between X and radeonfb can cause system memory corruption
when switching console from X (note that this is not realted to the
recent radeonfb patches, the problem has been there forever as far as I
can tell).

This patch works around it in radeonfb by making sure the "offsets"
register that driver the memory mapping of the accel engine are always
properly set before every accel op. A better fix should be done in fbcon
ultimately.

Please apply to 2.6.11

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Index: linux-work/drivers/video/aty/radeon_accel.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_accel.c	2005-01-24 17:09:44.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_accel.c	2005-02-20 10:41:37.000000000 +1100
@@ -4,6 +4,41 @@
  * "ACCEL_MMIO" ifdef branches in XFree86
  * --dte
  */
+
+static void radeon_fixup_offset(struct radeonfb_info *rinfo)
+{
+	u32 local_base;
+
+	/* *** Ugly workaround *** */
+	/*
+	 * On some platforms, the video memory is mapped at 0 in radeon chip space
+	 * (like PPCs) by the firmware. X will always move it up so that it's seen
+	 * by the chip to be at the same address as the PCI BAR.
+	 * That means that when switching back from X, there is a mismatch between
+	 * the offsets programmed into the engine. This means that potentially,
+	 * accel operations done before radeonfb has a chance to re-init the engine
+	 * will have incorrect offsets, and potentially trash system memory !
+	 *
+	 * The correct fix is for fbcon to never call any accel op before the engine
+	 * has properly been re-initialized (by a call to set_var), but this is a
+	 * complex fix. This workaround in the meantime, called before every accel
+	 * operation, makes sure the offsets are in sync.
+	 */
+
+	radeon_fifo_wait (1);
+	local_base = INREG(MC_FB_LOCATION) << 16;
+	if (local_base == rinfo->fb_local_base)
+		return;
+
+	rinfo->fb_local_base = local_base;
+
+	radeon_fifo_wait (3);
+	OUTREG(DEFAULT_PITCH_OFFSET, (rinfo->pitch << 0x16) |
+				     (rinfo->fb_local_base >> 10));
+	OUTREG(DST_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base >> 10));
+	OUTREG(SRC_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base >> 10));
+}
+
 static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, 
 				   const struct fb_fillrect *region)
 {
@@ -38,6 +73,8 @@
 		return;
 	}
 
+	radeon_fixup_offset(rinfo);
+
 	vxres = info->var.xres_virtual;
 	vyres = info->var.yres_virtual;
 
@@ -105,6 +142,8 @@
 		return;
 	}
 
+	radeon_fixup_offset(rinfo);
+
 	vxres = info->var.xres_virtual;
 	vyres = info->var.yres_virtual;