Resending [PATCH] 2.6 ppc64 RTAS: use dynamic buffer size

[Linas Vepstas]

Resending,

Trying to work around a mail gateway bug; sorry if you are receiving
this message a second time.

(If you suspect that folks are not getting your email, contact me,
I think I now understand about half the problem.  You need to configure
your exim/postfix/sendmail to use a "smarthost".  Valid smarthosts
are austin.ibm.com, us.ibm.com, smtp.linux.ibm.com.  If you don't
use the smarthost, your email will go through pixpat.austin.ibm.com
which is appearently blackholed by spam black-lists).

--linas


----- Forwarded message from Mail Delivery System <Mailer-Daemon at bilge> -----
------ This is a copy of the message, including all the headers. ------

Return-path: <linas at bilge>
Received: from linas by bilge with local (Exim 3.36 #1 (Debian))
	id 1BmhA1-0002N0-00; Mon, 19 Jul 2004 18:03:05 -0500
Date: Mon, 19 Jul 2004 18:03:05 -0500
To: paulus at au1.ibm.com, paulus at samba.org
Cc: linuxppc64-dev at lists.linuxppc.org, antonb at samba.org,
	benh at kernel.crashing.org
Subject: [PATCH] 2.6 ppc64 RTAS: use dynamic buffer size
Message-ID: <20040719230305.GH7544 at bilge>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="32u276st3Jlj2kUU"
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040523i
From: Linas Vepstas <linas at bilge>


--32u276st3Jlj2kUU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Paul,

Please review & forward as appropriate.

Firmware expects error log sizes to be of a very specific size,
but different versions of firmware appearently expect different
sizes; using the wrong size results in a painful, hard-to-debug
crash in firmware.   Benh provided a patch for this some months
ago,  but appreantly missed this code path.   This patch sets up
the log buffer size dynamically; it also fixes a bug with the
return code not being handled correctly.

Signed-off-by: Linas Vepstas <linas at linas.org>

--linas

--32u276st3Jlj2kUU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rtas-log-length.patch"

===== arch/ppc64/kernel/rtas.c 1.38 vs edited =====
--- 1.38/arch/ppc64/kernel/rtas.c	Wed Jul 14 15:27:37 2004
+++ edited/arch/ppc64/kernel/rtas.c	Mon Jul 19 17:11:51 2004
@@ -22,7 +22,6 @@
 #include <asm/rtas.h>
 #include <asm/semaphore.h>
 #include <asm/machdep.h>
-#include <asm/paca.h>
 #include <asm/page.h>
 #include <asm/param.h>
 #include <asm/system.h>
@@ -73,7 +72,6 @@
 	return tokp ? *tokp : RTAS_UNKNOWN_SERVICE;
 }

-
 /** Return a copy of the detailed error text associated with the
  *  most recent failed call to rtas.  Because the error text
  *  might go stale if there are any other intervening rtas calls,
@@ -84,18 +82,26 @@
 __fetch_rtas_last_error(void)
 {
 	struct rtas_args err_args, save_args;
+	u32 bufsz;
+
+	bufsz = rtas_token ("rtas-error-log-max");
+	if ((bufsz == RTAS_UNKNOWN_SERVICE) ||
+	    (bufsz > RTAS_ERROR_LOG_MAX)) {
+		printk (KERN_WARNING "RTAS: bad log buffer size %d\n", bufsz);
+		bufsz = RTAS_ERROR_LOG_MAX;
+	}

 	err_args.token = rtas_token("rtas-last-error");
 	err_args.nargs = 2;
 	err_args.nret = 1;
-	err_args.rets = (rtas_arg_t *)&(err_args.args[2]);

 	err_args.args[0] = (rtas_arg_t)__pa(rtas_err_buf);
-	err_args.args[1] = RTAS_ERROR_LOG_MAX;
+	err_args.args[1] = bufsz;
 	err_args.args[2] = 0;

 	save_args = rtas.args;
 	rtas.args = err_args;
+	rtas.args.rets = (rtas_arg_t *)&(rtas.args.args[2]);

 	PPCDBG(PPCDBG_RTAS, "\tentering rtas with 0x%lx\n",
 	       __pa(&err_args));
@@ -105,6 +111,7 @@
 	err_args = rtas.args;
 	rtas.args = save_args;

+	err_args.rets = (rtas_arg_t *)&(err_args.args[2]);
 	return err_args.rets[0];
 }


--32u276st3Jlj2kUU--

----- End forwarded message -----

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/