* Please pull from 'misc' branch of powerpc
From: Kumar Gala @ 2006-03-28 0:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Please pull from 'misc' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/prom.c | 14 +-------------
arch/ppc/lib/strcase.c | 2 +-
2 files changed, 2 insertions(+), 14 deletions(-)
Kumar Gala:
ppc: fix strncasecmp prototype
powerpc: use memparse() for mem= command line parsing
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 5a24415..95d15eb 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1030,25 +1030,13 @@ static int __init early_init_dt_scan_cho
if (strstr(cmd_line, "mem=")) {
char *p, *q;
- unsigned long maxmem = 0;
for (q = cmd_line; (p = strstr(q, "mem=")) != 0; ) {
q = p + 4;
if (p > cmd_line && p[-1] != ' ')
continue;
- maxmem = simple_strtoul(q, &q, 0);
- if (*q == 'k' || *q == 'K') {
- maxmem <<= 10;
- ++q;
- } else if (*q == 'm' || *q == 'M') {
- maxmem <<= 20;
- ++q;
- } else if (*q == 'g' || *q == 'G') {
- maxmem <<= 30;
- ++q;
- }
+ memory_limit = memparse(q, &q);
}
- memory_limit = maxmem;
}
/* break now */
diff --git a/arch/ppc/lib/strcase.c b/arch/ppc/lib/strcase.c
index 36b5210..d988578 100644
--- a/arch/ppc/lib/strcase.c
+++ b/arch/ppc/lib/strcase.c
@@ -11,7 +11,7 @@ int strcasecmp(const char *s1, const cha
return c1 - c2;
}
-int strncasecmp(const char *s1, const char *s2, int n)
+int strncasecmp(const char *s1, const char *s2, size_t n)
{
int c1, c2;
^ permalink raw reply related
* Kernel for MPC Lite 5200 will not compile
From: Matthias Fechner @ 2006-03-28 0:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I installed today ELDK 4.0 for the LITE5200 board (icecube).
./install -d /usr/local/eldk ppc_6xx
After compiling u-boot and playing a little bit with it, i tried to
compile the kernel 2.6.
For this I used the git repository.
I copied the file arch/ppc/configs/lite5200_defconfig to .config, and
tried the following one:
make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
But i got a failure with the following error message:
CC arch/ppc/syslib/bestcomm/bestcomm.o arch/ppc/syslib/bestcomm/bestcomm.c: In function 'mpc52xx_sdma_probe':
arch/ppc/syslib/bestcomm/bestcomm.c:269: warning: implicit declaration of function 'to_platform_device'
arch/ppc/syslib/bestcomm/bestcomm.c:269: warning: initialization makes pointer from integer without a cast
arch/ppc/syslib/bestcomm/bestcomm.c:278: warning: implicit declaration of function 'platform_get_resource'
arch/ppc/syslib/bestcomm/bestcomm.c:278: warning: assignment makes pointer from integer without a cast
arch/ppc/syslib/bestcomm/bestcomm.c:279: warning: assignment makes pointer from integer without a cast
arch/ppc/syslib/bestcomm/bestcomm.c: At top level:
arch/ppc/syslib/bestcomm/bestcomm.c:367: error: 'platform_bus_type' undeclared here (not in a function)
make[2]: *** [arch/ppc/syslib/bestcomm/bestcomm.o] Fehler 1
make[1]: *** [arch/ppc/syslib/bestcomm] Fehler 2
make: *** [arch/ppc/syslib] Fehler 2
What is wrong here, I think i did an error on any step...
Thx for help!
Best regards,
Matthias
^ permalink raw reply
* Re: [PATCH] powerpc: Unify the 32 and 64 bit idle loops
From: Kumar Gala @ 2006-03-28 0:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17448.26428.269343.872893@cargo.ozlabs.ibm.com>
On Mar 27, 2006, at 4:29 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> I'm now seeing the following kernel panic on an 83xx system (603
>> core) w/preempt on (2.6.16 is ok on this system):
>
> My mistake. I just pushed a fix.
Thanks, that works better.
- kumar
^ permalink raw reply
* [PATCH] Workaround for RTAS bug
From: Mike Kravetz @ 2006-03-27 23:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A bug in the RTAS services incorrectly interprets some bits in the CR
when called from the OS. Specifically, bits in CR4. The result could
be a firmware crash that also takes down the partition. A firmware
fix is in the works. We have seen this situation when performing DLPAR
operations. As a temporary workaround, clear the CR in enter_rtas().
Note that enter_rtas() will not set any bits in CR4 before calling RTAS.
Also note that the 32 bit version of enter_rtas() should have the same
work around even though the chances of hitting the bug are much smaller
due to the lack of DLPAR on 32 bit kernels. However, my assembly skills
are a bit rusty and the 32 bit code doesn't seem to follow the conventions
for where things should be saved. In addition, I don't have a system
to test 32 bit kernels. Help creating and at least touch testing the
same workaround for 32 bit would be appreciated.
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.16/arch/powerpc/kernel/entry_64.S linux-2.6.16.work/arch/powerpc/kernel/entry_64.S
--- linux-2.6.16/arch/powerpc/kernel/entry_64.S 2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16.work/arch/powerpc/kernel/entry_64.S 2006-03-27 17:17:59.000000000 +0000
@@ -616,6 +616,12 @@ _GLOBAL(enter_rtas)
mfsrr1 r10
std r10,_SRR1(r1)
+ /* Temporary workaround to clear CR until RTAS can be modified to
+ * ignore all bits.
+ */
+ li r0,0
+ mtcr r0
+
/* There is no way it is acceptable to get here with interrupts enabled,
* check it with the asm equivalent of WARN_ON
*/
^ permalink raw reply
* Re: [PATCH] powerpc: Unify the 32 and 64 bit idle loops
From: Paul Mackerras @ 2006-03-27 22:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <0ED6B216-1F6E-40E7-9EB8-399F4066E273@kernel.crashing.org>
Kumar Gala writes:
> I'm now seeing the following kernel panic on an 83xx system (603
> core) w/preempt on (2.6.16 is ok on this system):
My mistake. I just pushed a fix.
Paul.
^ permalink raw reply
* Re: [PATCH] sigaltstack bad behavior on powerpc64
From: Paul Mackerras @ 2006-03-27 22:20 UTC (permalink / raw)
To: Laurent MEYER; +Cc: linuxppc-dev, olh
In-Reply-To: <1143452261.3911.16.camel@localhost.localdomain>
Laurent MEYER writes:
> I may have found a bug in powerpc64 arch specific code.
Yes, you're right, it's a bug.
> I wrote a small patch to add a condition in get_sigframe().
Looks correct. Thanks. I'll put it in.
Paul.
^ permalink raw reply
* KW: wrong state
From: Giuliano Pochini @ 2006-03-27 22:01 UTC (permalink / raw)
To: LinuxPPC-dev
Dual G4 MDD,
Linux Jay 2.6.16 #2 SMP Sun Mar 26 00:19:01 CET 2006 ppc 7455, altivec supported PowerMac3,6 GNU/Linux
writes these messages at boot. The fan control seems to work fine, though.
i2c /dev entries driver
PowerMac i2c bus pmu 2 registered
PowerMac i2c bus pmu 1 registered
PowerMac i2c bus mac-io 0 registered
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 06)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
PowerMac i2c bus uni-n 1 registered
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
DS1775 digital thermometer [@49]
Temp: 24.5 C Hyst: 75.0 C OS: 80.0 C
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
ADM1030 fan controller [@2c]
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02)
PowerMac i2c bus uni-n 0 registered
I cannot stop the second CPU with "echo 0 > /sys/devices/system/cpu/cpu1/online"
dmesg says "CPU 1 refused to die!". I don't know if it's related to the errors above.
--
Giuliano.
^ permalink raw reply
* Re: [PATCH] powerpc: Unify the 32 and 64 bit idle loops
From: Kumar Gala @ 2006-03-27 20:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17443.49609.63829.380622@cargo.ozlabs.ibm.com>
I'm now seeing the following kernel panic on an 83xx system (603
core) w/preempt on (2.6.16 is ok on this system):
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:db:00:04:fe
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
Marvell 88E1101: Registered new driver
i2c /dev entries driver
NET: Registered protocol family 2
Non-recoverable exception at PC=c0009498 MSR=8000
Oops: nonrecoverable exception, sig: 9 [#1]
Modules linked in:
NIP: C0009498 LR: C0007E78 CTR: C00093D8
REGS: c022bef0 TRAP: 0900 Not tainted (2.6.16-g9618edab)
MSR: 00008000 <EE> CR: 24024048 XER: 20000000
TASK = c01f5da8[0] 'swapper' THREAD: c022a000
GPR00: 00000000 C022BFA0 C01F5DA8 00800000 8090C000 00E00000 00000001
00048000
GPR08: 00000000 C00093D8 22024022 00000010 000009D3 9D410001 0FFFF000
007FFFFA
GPR16: 00000001 FFFFFFFF 00000000 0FFFA0E4 00000000 007FFF00 0FFA7758
00000002
GPR24: 00000000 00800000 40000000 C0249370 C0249370 00000010 C022A024
C022A000
NIP [C0009498] ppc6xx_idle+0xc0/0xcc
LR [C0007E78] cpu_idle+0x9c/0xf0
Call Trace:
[C022BFA0] [00800000] 0x800000 (unreliable)
[C022BFC0] [C00037A4] rest_init+0x28/0x38
[C022BFD0] [C022C6A0] start_kernel+0x1b8/0x1f8
[C022BFF0] [00003378] 0x3378
Instruction dump:
64a50080 7c842878 7c841b78 64840010 7c90fba6 60000000 60000000 60e78000
64e70004 7c0004ac 4c00012c 7ce00124 <4c00012c> 7c0004ac 4e800020
7d70faa6
<0>Kernel panic - not syncing: Attempted to kill the idle task!
<0>Rebooting in 180 seconds..
On Mar 24, 2006, at 3:54 AM, Paul Mackerras wrote:
> This unifies the 32-bit (ARCH=ppc and ARCH=powerpc) and 64-bit idle
> loops. It brings over the concept of having a ppc_md.power_save
> function from 32-bit to ARCH=powerpc, which lets us get rid of
> native_idle(). With that, we can also reduce the amount of special
> code for pSeries and cell because the special code has only to do what
> needs to be done when there is no work to do, rather than being a
> complete idle loop.
>
> iSeries still has its own idle loops because it wants to test
> hvlpevents_pending() as well as need_resched() etc. I don't know if
> that is essential but I have left it as-is for now.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* [PATCH] fix __init/__exit annotations for spufs
From: Arnd Bergmann @ 2006-03-27 19:27 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20060323203423.620978000@dyn-9-152-242-103.boeblingen.de.ibm.com>
spufs_init and spufs_exit should be marked correctly so
they can be removed when not needed.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/arch/powerpc/platforms/cell/spufs/inode.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spufs/inode.c
+++ linus-2.6/arch/powerpc/platforms/cell/spufs/inode.c
@@ -442,7 +442,7 @@ static struct file_system_type spufs_typ
.kill_sb = kill_litter_super,
};
-static int spufs_init(void)
+static int __init spufs_init(void)
{
int ret;
ret = -ENOMEM;
@@ -472,7 +472,7 @@ out:
}
module_init(spufs_init);
-static void spufs_exit(void)
+static void __exit spufs_exit(void)
{
spu_sched_exit();
unregister_spu_syscalls(&spufs_calls);
^ permalink raw reply
* [updated patch 2/2] powerpc: add hvc backend for rtas
From: Arnd Bergmann @ 2006-03-27 19:26 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Arnd Bergmann, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <17447.25413.486950.115568@cargo.ozlabs.ibm.com>
Current Cell hardware is using the console through a set
of rtas calls. This driver is needed to get console
output on those boards.
Signed-off-by: Arnd Bergmann <abergman@de.ibm.com>
Index: linus-2.6/drivers/char/hvc_rtas.c
===================================================================
--- /dev/null
+++ linus-2.6/drivers/char/hvc_rtas.c
@@ -0,0 +1,138 @@
+/*
+ * IBM RTAS driver interface to hvc_console.c
+ *
+ * (C) Copyright IBM Corporation 2001-2005
+ * (C) Copyright Red Hat, Inc. 2005
+ *
+ * Author(s): Maximino Augilar <IBM STI Design Center>
+ * : Ryan S. Arnold <rsa@us.ibm.com>
+ * : Utz Bacher <utz.bacher@de.ibm.com>
+ * : David Woodhouse <dwmw2@infradead.org>
+ *
+ * inspired by drivers/char/hvc_console.c
+ * written by Anton Blanchard and Paul Mackerras
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/moduleparam.h>
+#include <linux/types.h>
+
+#include <asm/irq.h>
+#include <asm/rtas.h>
+#include "hvc_console.h"
+
+#define hvc_rtas_cookie 0x67781e15
+struct hvc_struct *hvc_rtas_dev;
+
+#define RTASCONS_PUT_ATTEMPTS 16
+
+static int rtascons_put_char_token = RTAS_UNKNOWN_SERVICE;
+static int rtascons_get_char_token = RTAS_UNKNOWN_SERVICE;
+static int rtascons_put_delay = 100;
+module_param_named(put_delay, rtascons_put_delay, int, 0644);
+
+static inline int hvc_rtas_write_console(uint32_t vtermno, const char *buf, int count)
+{
+ int done;
+
+ /* if there is more than one character to be displayed, wait a bit */
+ for (done = 0; done < count; done++) {
+ int result;
+ result = rtas_call(rtascons_put_char_token, 1, 1, NULL, buf[done]);
+ if (result)
+ break;
+ }
+ /* the calling routine expects to receive the number of bytes sent */
+ return done;
+}
+
+static int hvc_rtas_read_console(uint32_t vtermno, char *buf, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ int c, err;
+
+ err = rtas_call(rtascons_get_char_token, 0, 2, &c);
+ if (err)
+ break;
+
+ buf[i] = c;
+ }
+
+ return i;
+}
+
+static struct hv_ops hvc_rtas_get_put_ops = {
+ .get_chars = hvc_rtas_read_console,
+ .put_chars = hvc_rtas_write_console,
+};
+
+static int hvc_rtas_init(void)
+{
+ struct hvc_struct *hp;
+
+ if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
+ rtascons_put_char_token = rtas_token("put-term-char");
+ if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
+ return -EIO;
+
+ if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
+ rtascons_get_char_token = rtas_token("get-term-char");
+ if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
+ return -EIO;
+
+ BUG_ON(hvc_rtas_dev);
+
+ /* Allocate an hvc_struct for the console device we instantiated
+ * earlier. Save off hp so that we can return it on exit */
+ hp = hvc_alloc(hvc_rtas_cookie, NO_IRQ, &hvc_rtas_get_put_ops);
+ if (IS_ERR(hp))
+ return PTR_ERR(hp);
+ hvc_rtas_dev = hp;
+ return 0;
+}
+module_init(hvc_rtas_init);
+
+/* This will tear down the tty portion of the driver */
+static void __exit hvc_rtas_exit(void)
+{
+ /* Really the fun isn't over until the worker thread breaks down and the
+ * tty cleans up */
+ if (hvc_rtas_dev)
+ hvc_remove(hvc_rtas_dev);
+}
+module_exit(hvc_rtas_exit);
+
+/* This will happen prior to module init. There is no tty at this time? */
+static int hvc_rtas_console_init(void)
+{
+ rtascons_put_char_token = rtas_token("put-term-char");
+ if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
+ return -EIO;
+ rtascons_get_char_token = rtas_token("get-term-char");
+ if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
+ return -EIO;
+
+ hvc_instantiate(hvc_rtas_cookie, 0, &hvc_rtas_get_put_ops );
+ add_preferred_console("hvc", 0, NULL);
+ return 0;
+}
+console_initcall(hvc_rtas_console_init);
Index: linus-2.6/drivers/char/Makefile
===================================================================
--- linus-2.6.orig/drivers/char/Makefile
+++ linus-2.6/drivers/char/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_SX) += sx.o generic_serial
obj-$(CONFIG_RIO) += rio/ generic_serial.o
obj-$(CONFIG_HVC_DRIVER) += hvc_console.o
obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi.o
+obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o
obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
obj-$(CONFIG_MMTIMER) += mmtimer.o
Index: linus-2.6/drivers/char/Kconfig
===================================================================
--- linus-2.6.orig/drivers/char/Kconfig
+++ linus-2.6/drivers/char/Kconfig
@@ -579,6 +579,13 @@ config HVC_CONSOLE
console. This driver allows each pSeries partition to have a console
which is accessed via the HMC.
+config HVC_RTAS
+ bool "IBM RTAS Console support"
+ depends on PPC_RTAS
+ select HVC_DRIVER
+ help
+ IBM Console device driver which makes use of RTAS
+
config HVCS
tristate "IBM Hypervisor Virtual Console Server support"
depends on PPC_PSERIES
^ permalink raw reply
* [updated patch 1/2] powerpc: hvc_console updates
From: Arnd Bergmann @ 2006-03-27 19:25 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Arnd Bergmann, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <17447.25413.486950.115568@cargo.ozlabs.ibm.com>
These are some updates from both Ryan and Arnd for the hvc_console
driver:
The main point is to enable the inclusion of a console driver
for rtas, which is currrently needed for the cell platform.
Also shuffle around some data-type declarations and moves some
functions out of include/asm-ppc64/hvconsole.h and into a new
drivers/char/hvc_console.h file.
From: "Ryan S. Arnold" <rsa@us.ibm.com>
Signed-off-by: "Ryan S. Arnold" <rsa@us.ibm.com>
Signed-off-by: Arnd Bergmann <abergman@de.ibm.com>
Index: linus-2.6/drivers/char/hvc_console.c
===================================================================
--- linus-2.6.orig/drivers/char/hvc_console.c
+++ linus-2.6/drivers/char/hvc_console.c
@@ -39,8 +39,10 @@
#include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/delay.h>
+
#include <asm/uaccess.h>
-#include <asm/hvconsole.h>
+
+#include "hvc_console.h"
#define HVC_MAJOR 229
#define HVC_MINOR 0
@@ -54,17 +56,14 @@
#define HVC_CLOSE_WAIT (HZ/100) /* 1/10 of a second */
/*
- * The Linux TTY code does not support dynamic addition of tty derived devices
- * so we need to know how many tty devices we might need when space is allocated
- * for the tty device. Since this driver supports hotplug of vty adapters we
- * need to make sure we have enough allocated.
+ * These sizes are most efficient for vio, because they are the
+ * native transfer size. We could make them selectable in the
+ * future to better deal with backends that want other buffer sizes.
*/
-#define HVC_ALLOC_TTY_ADAPTERS 8
-
#define N_OUTBUF 16
#define N_INBUF 16
-#define __ALIGNED__ __attribute__((__aligned__(8)))
+#define __ALIGNED__ __attribute__((__aligned__(sizeof(long))))
static struct tty_driver *hvc_driver;
static struct task_struct *hvc_task;
@@ -154,7 +153,7 @@ static uint32_t vtermnos[MAX_NR_HVC_CONS
void hvc_console_print(struct console *co, const char *b, unsigned count)
{
- char c[16] __ALIGNED__;
+ char c[N_OUTBUF] __ALIGNED__;
unsigned i = 0, n = 0;
int r, donecr = 0, index = co->index;
@@ -473,8 +472,10 @@ static void hvc_push(struct hvc_struct *
n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf);
if (n <= 0) {
- if (n == 0)
+ if (n == 0) {
+ hp->do_wakeup = 1;
return;
+ }
/* throw away output on error; this happens when
there is no session connected to the vterm. */
hp->n_outbuf = 0;
@@ -486,12 +487,19 @@ static void hvc_push(struct hvc_struct *
hp->do_wakeup = 1;
}
-static inline int __hvc_write_kernel(struct hvc_struct *hp,
- const unsigned char *buf, int count)
+static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count)
{
+ struct hvc_struct *hp = tty->driver_data;
unsigned long flags;
int rsize, written = 0;
+ /* This write was probably executed during a tty close. */
+ if (!hp)
+ return -EPIPE;
+
+ if (hp->count <= 0)
+ return -EIO;
+
spin_lock_irqsave(&hp->lock, flags);
/* Push pending writes */
@@ -510,26 +518,8 @@ static inline int __hvc_write_kernel(str
}
spin_unlock_irqrestore(&hp->lock, flags);
- return written;
-}
-static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count)
-{
- struct hvc_struct *hp = tty->driver_data;
- int written;
-
- /* This write was probably executed during a tty close. */
- if (!hp)
- return -EPIPE;
-
- if (hp->count <= 0)
- return -EIO;
-
- written = __hvc_write_kernel(hp, buf, count);
-
/*
* Racy, but harmless, kick thread if there is still pending data.
- * There really is nothing wrong with kicking the thread, even if there
- * is no buffered data.
*/
if (hp->n_outbuf)
hvc_kick();
@@ -614,6 +604,13 @@ static int hvc_poll(struct hvc_struct *h
spin_unlock_irqrestore(&hp->lock, flags);
tty_hangup(tty);
spin_lock_irqsave(&hp->lock, flags);
+ } else if ( n == -EAGAIN ) {
+ /*
+ * Some back-ends can only ensure a certain min
+ * num of bytes read, which may be > 'count'.
+ * Let the tty clear the flip buff to make room.
+ */
+ poll_mask |= HVC_POLL_READ;
}
break;
}
@@ -635,16 +632,7 @@ static int hvc_poll(struct hvc_struct *h
tty_insert_flip_char(tty, buf[i], 0);
}
- /*
- * Account for the total amount read in one loop, and if above
- * 64 bytes, we do a quick schedule loop to let the tty grok
- * the data and eventually throttle us.
- */
read_total += n;
- if (read_total >= 64) {
- poll_mask |= HVC_POLL_QUICK;
- break;
- }
}
throttled:
/* Wakeup write queue if necessary */
@@ -767,7 +755,8 @@ struct hvc_struct __devinit *hvc_alloc(u
* see if this vterm id matches one registered for console.
*/
for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
- if (vtermnos[i] == hp->vtermno)
+ if (vtermnos[i] == hp->vtermno &&
+ cons_ops[i] == hp->ops)
break;
/* no matching slot, just use a counter */
Index: linus-2.6/drivers/char/hvc_console.h
===================================================================
--- /dev/null
+++ linus-2.6/drivers/char/hvc_console.h
@@ -0,0 +1,63 @@
+/*
+ * hvc_console.h
+ * Copyright (C) 2005 IBM Corporation
+ *
+ * Author(s):
+ * Ryan S. Arnold <rsa@us.ibm.com>
+ *
+ * hvc_console header information:
+ * moved here from include/asm-powerpc/hvconsole.h
+ * and drivers/char/hvc_console.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef HVC_CONSOLE_H
+#define HVC_CONSOLE_H
+
+/*
+ * This is the max number of console adapters that can/will be found as
+ * console devices on first stage console init. Any number beyond this range
+ * can't be used as a console device but is still a valid tty device.
+ */
+#define MAX_NR_HVC_CONSOLES 16
+
+/*
+ * The Linux TTY code does not support dynamic addition of tty derived devices
+ * so we need to know how many tty devices we might need when space is allocated
+ * for the tty device. Since this driver supports hotplug of vty adapters we
+ * need to make sure we have enough allocated.
+ */
+#define HVC_ALLOC_TTY_ADAPTERS 8
+
+
+/* implemented by a low level driver */
+struct hv_ops {
+ int (*get_chars)(uint32_t vtermno, char *buf, int count);
+ int (*put_chars)(uint32_t vtermno, const char *buf, int count);
+};
+
+struct hvc_struct;
+
+/* Register a vterm and a slot index for use as a console (console_init) */
+extern int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops);
+
+/* register a vterm for hvc tty operation (module_init or hotplug add) */
+extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int irq,
+ struct hv_ops *ops);
+/* remove a vterm from hvc tty operation (modele_exit or hotplug remove) */
+extern int __devexit hvc_remove(struct hvc_struct *hp);
+
+#endif // HVC_CONSOLE_H
Index: linus-2.6/include/asm-powerpc/hvconsole.h
===================================================================
--- linus-2.6.orig/include/asm-powerpc/hvconsole.h
+++ linus-2.6/include/asm-powerpc/hvconsole.h
@@ -24,28 +24,18 @@
#ifdef __KERNEL__
/*
- * This is the max number of console adapters that can/will be found as
- * console devices on first stage console init. Any number beyond this range
- * can't be used as a console device but is still a valid tty device.
+ * PSeries firmware will only send/recv up to 16 bytes of character data per
+ * hcall.
*/
-#define MAX_NR_HVC_CONSOLES 16
+#define MAX_VIO_PUT_CHARS 16
+#define SIZE_VIO_GET_CHARS 16
-/* implemented by a low level driver */
-struct hv_ops {
- int (*get_chars)(uint32_t vtermno, char *buf, int count);
- int (*put_chars)(uint32_t vtermno, const char *buf, int count);
-};
+/*
+ * Vio firmware always attempts to fetch MAX_VIO_GET_CHARS chars. The 'count'
+ * parm is included to conform to put_chars() function pointer template
+ */
extern int hvc_get_chars(uint32_t vtermno, char *buf, int count);
extern int hvc_put_chars(uint32_t vtermno, const char *buf, int count);
-struct hvc_struct;
-
-/* Register a vterm and a slot index for use as a console (console_init) */
-extern int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops);
-/* register a vterm for hvc tty operation (module_init or hotplug add) */
-extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int irq,
- struct hv_ops *ops);
-/* remove a vterm from hvc tty operation (modele_exit or hotplug remove) */
-extern int __devexit hvc_remove(struct hvc_struct *hp);
#endif /* __KERNEL__ */
#endif /* _PPC64_HVCONSOLE_H */
Index: linus-2.6/drivers/char/Kconfig
===================================================================
--- linus-2.6.orig/drivers/char/Kconfig
+++ linus-2.6/drivers/char/Kconfig
@@ -561,9 +561,19 @@ config TIPAR
If unsure, say N.
+config HVC_DRIVER
+ bool
+ help
+ Users of pSeries machines that want to utilize the hvc console front-end
+ module for their backend console driver should select this option.
+ It will automatically be selected if one of the back-end console drivers
+ is selected.
+
+
config HVC_CONSOLE
bool "pSeries Hypervisor Virtual Console support"
depends on PPC_PSERIES
+ select HVC_DRIVER
help
pSeries machines when partitioned support a hypervisor virtual
console. This driver allows each pSeries partition to have a console
Index: linus-2.6/drivers/char/Makefile
===================================================================
--- linus-2.6.orig/drivers/char/Makefile
+++ linus-2.6/drivers/char/Makefile
@@ -41,7 +41,8 @@ obj-$(CONFIG_N_HDLC) += n_hdlc.o
obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o
obj-$(CONFIG_SX) += sx.o generic_serial.o
obj-$(CONFIG_RIO) += rio/ generic_serial.o
-obj-$(CONFIG_HVC_CONSOLE) += hvc_console.o hvc_vio.o hvsi.o
+obj-$(CONFIG_HVC_DRIVER) += hvc_console.o
+obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi.o
obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
obj-$(CONFIG_MMTIMER) += mmtimer.o
Index: linus-2.6/drivers/char/hvc_vio.c
===================================================================
--- linus-2.6.orig/drivers/char/hvc_vio.c
+++ linus-2.6/drivers/char/hvc_vio.c
@@ -31,10 +31,13 @@
#include <linux/types.h>
#include <linux/init.h>
+
#include <asm/hvconsole.h>
#include <asm/vio.h>
#include <asm/prom.h>
+#include "hvc_console.h"
+
char hvc_driver_name[] = "hvc_console";
static struct vio_device_id hvc_driver_table[] __devinitdata = {
@@ -48,6 +51,14 @@ static int filtered_get_chars(uint32_t v
unsigned long got;
int i;
+ /*
+ * Vio firmware will read up to SIZE_VIO_GET_CHARS at its own discretion
+ * so we play safe and avoid the situation where got > count which could
+ * overload the flip buffer.
+ */
+ if (count < SIZE_VIO_GET_CHARS)
+ return -EAGAIN;
+
got = hvc_get_chars(vtermno, buf, count);
/*
Index: linus-2.6/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/pseries/hvconsole.c
+++ linus-2.6/arch/powerpc/platforms/pseries/hvconsole.c
@@ -62,6 +62,11 @@ int hvc_put_chars(uint32_t vtermno, cons
unsigned long *lbuf = (unsigned long *) buf;
long ret;
+
+ /* hcall will ret H_PARAMETER if 'count' exceeds firmware max.*/
+ if (count > MAX_VIO_PUT_CHARS)
+ count = MAX_VIO_PUT_CHARS;
+
ret = plpar_hcall_norets(H_PUT_TERM_CHAR, vtermno, count, lbuf[0],
lbuf[1]);
if (ret == H_Success)
^ permalink raw reply
* Re: Interpreting /proc/meminfo. How much free memory do I have?
From: Jeff Angielski @ 2006-03-27 16:49 UTC (permalink / raw)
To: antonio.dibacco; +Cc: linuxppc-embedded
In-Reply-To: <20060327093822.480.qmail@mx1.aruba.it>
On Mon, 2006-03-27 at 09:38 +0000, antonio.dibacco wrote:
> I don't understand the meaning of "Inactive". They are not used but the
> kernel cannot give this memory to a requesting process because we tipically
> don't have a swap device on a linux embedded board. Where we can store the
> Inactive page? Am I wrong?
> If I run a process that continuosly allocates memory and print out the total
> allocated memory when it receives SIGINT or SIGTERM, I think I get the real
> "free memory"!
The "big picture" is that the kernel assumes that any physical memory
that is not used is being wasted. The kernel tries to anticipate what
data you will need and loads it into memory before you actually require
it. This way there is no time delay when you want to access it. So the
numbers are reflecting what the system/kernel is currentl using.
Even if you are on a system with no swap parition like your embedded
board, pages in memory that are read-only can still be swapped out since
they can always be read back in when needed. Sections like a
processes .text fit this category.
If you are trying to look at a specific process, perhaps looking at
the /proc/<pid>/status might help you analyze your memory needs.
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: Kumar Gala @ 2006-03-27 16:18 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1143446542.24304.8.camel@lamorak.int.avalon.com.au>
On Mar 27, 2006, at 2:02 AM, Phil Nitschke wrote:
> On Thu, 2006-03-23 at 09:44 -0600, Kumar Gala wrote:
>> On Mar 23, 2006, at 8:21 AM, Wyse, Chris wrote:
>>
>>> Hi,
>>>
>>> I'm trying to map a PCI memory region 1 into user space from my
>>> driver (PPC440GX, Linux 2.6.10). Here's the mmap routine of the
>>> driver that I'm using:
>>
>> Why don't use the mmap file exposed by sysfs so you dont have to
>> write your own code?
>>
>> See Documentation/filesystems/sysfs-pci.txt. But effectively down
>> under /sys/bus/pci/devices/[domain:bus:dev:func]/ you will get
>> resource[0..N-1] that corresponds to each BAR on the device. This is
>> a mmap file to access that region.
>
> I have some custom hardware that appears on the PCI bus as follows:
>
> bash-3.00# lspci -vv
> 00:01.0 Class 0680: 1172:0004 (rev 01)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort+
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 128, Cache Line Size 08
> Interrupt: pin A routed to IRQ 71
> Region 0: Memory at 000000009ffff000 (32-bit, non-prefetchable)
> [size=4K]
> Region 1: Memory at 000000009fc00000 (32-bit, non-prefetchable)
> [size=2M]
>
> But when I try to access resource0 or resource1, I get a read error.
> What characteristic of the device or driver determines whether it will
> allow mmap-ing?
>
> (I've written the driver for this device myself.)
Nothing special beyond normal unix perms on the resource[0..n] files
to my knowledge. When you say you get a read error what exactly does
that mean?
- kumar
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-27 16:05 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1143446542.24304.8.camel@lamorak.int.avalon.com.au>
> I have some custom hardware that appears on the PCI bus as follows:
>
> bash-3.00# lspci -vv
> 00:01.0 Class 0680: 1172:0004 (rev 01)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort+
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 128, Cache Line Size 08
> Interrupt: pin A routed to IRQ 71
> Region 0: Memory at 000000009ffff000 (32-bit, non-prefetchable)
> [size=4K]
> Region 1: Memory at 000000009fc00000 (32-bit, non-prefetchable)
> [size=2M]
>
> But when I try to access resource0 or resource1, I get a read error.
> What characteristic of the device or driver determines whether it will
> allow mmap-ing?
>
> (I've written the driver for this device myself.)
>
Hi Phil,
The board tells you you have 4K of non-prefetchable memory in two BAR
regions. Which is what you've already determined I am sure.
Try building an insmodding the pci_io driver I posted, it'll pick
up the two BAR regions and allow you to access them, and you can
add more debugging comments to that code fairly easily.
If things don't work then, you probably have a hardware error and
would benefit from looking at the PCI bus with a logic analyzer to
see if the device is generating an error.
http://www.ovro.caltech.edu/~dwh/pci_io.tar.gz
Regards,
Dave
^ permalink raw reply
* Re: [PATCH] kdump: Fix for machine checkstop on DMA fault
From: Olof Johansson @ 2006-03-27 14:06 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Olaf Hering, Paul Mackerras, Milton Miller, linuxppc-dev
In-Reply-To: <1143435899.28580.7.camel@localhost.localdomain>
On Mon, Mar 27, 2006 at 04:04:58PM +1100, Michael Ellerman wrote:
> I disagree. In most cases the kdump kernel will be loaded by the boot
> scripts, so reserving TCE space then is ~= reserving it for the life of
> the first kernel. Given that TCE space is a scarce commodity I don't
> think reserving it in the first kernel is a viable option.
Well, hopefully the kdump kernel doesn't need as much table space as a
regular kernel, so the loss would be limited, but if you're willing to
do the reserve instead; that'd be better.
> What we should do is modify the second kernel so that instead of
> clearing the TCE tables it instead walks the tables and detects existing
> mappings, and then marks those as reserved so they're not overwritten.
Yep, that's exactly what my first proposal was.
> This should give us 100% safety from the second kernel reusing a mapping
> and copping a rogue DMA, and doesn't inflict any penalty on the first
> kernel. It does fall down if there's no TCE space left for a device when
> the second kernel comes up, but I think that's the best trade off.
Correct. The time it could be a disadvantage is when there's been a
driver bug that leaks mappings that causes the machine to go down (i.e.
into the kdump kernel). Whatever device has been leaking might not be
usable since the table will be 100% full.
-Olof
^ permalink raw reply
* Re: freescale 8xx: which architecture to use ? ppc - powerpc ?
From: Vitaly Bordug @ 2006-03-27 13:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4427E693.6060601@cs.fau.de>
On Mon, 27 Mar 2006 15:20:19 +0200
Josef Angermeier <Josef.Angermeier@informatik.uni-erlangen.de> wrote:
>
> Hello,
>
> i want to run linux (2.6.15) on my MPC875 board. I wonder which
> architecture to choose: "powerpc" or "ppc" ? - menuconfig shows a
> "freescale 8xx" option when used with "powerpc", and a "8xx" option when
> used with ARCH=ppc. Because i use a embedded freescale 8xx i wanted to
> use the "powerpc" architecture. BUT: i seems to be unstable, i got some
> undefined referencies. Or am i wrong ?
You should use ppc for now. Work to move the 8xx stuff to the powerpc is ongoing, but quite far from complete state as you see...
>
> thanks
> Josef
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Freescale MPC8xx USB support
From: Vitaly Bordug @ 2006-03-27 13:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4427E4BB.5090509@cs.fau.de>
On Mon, 27 Mar 2006 15:12:27 +0200
Josef Angermeier <Josef.Angermeier@informatik.uni-erlangen.de> wrote:
> Hello,
>
> in the last linux stable release 2.6.15 i couldn't find any driver for
> the USB-hostcontroller embedded in Freescale MPC875. Is there some work
> ongoing or must i start writing my own driver ?
>
No, there are no active projects covering it afaik. Some patches are
floating around
http://www.heeltoe.com/software/usb/usb.html, but it should be reworked to 2.6, and there are no guarantee that it'll work after all...
> thanks in advance
> Josef
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] sigaltstack bad behavior on powerpc64
From: Andreas Schwab @ 2006-03-27 13:48 UTC (permalink / raw)
To: Laurent MEYER; +Cc: linuxppc-dev
In-Reply-To: <1143452261.3911.16.camel@localhost.localdomain>
Laurent MEYER <meyerlau@fr.ibm.com> writes:
> Index: linux-2.6.16-mcr/arch/powerpc/kernel/signal_64.c
> ===================================================================
> --- linux-2.6.16-mcr.orig/arch/powerpc/kernel/signal_64.c 2006-03-27 11:09:02.000000000 +0200
> +++ linux-2.6.16-mcr/arch/powerpc/kernel/signal_64.c 2006-03-27 11:14:16.986879573 +0200
> @@ -213,7 +213,7 @@
> /* Default to using normal stack */
> newsp = regs->gpr[1];
>
> - if (ka->sa.sa_flags & SA_ONSTACK) {
> + if ((ka->sa.sa_flags & SA_ONSTACK) && current->sas_ss_size) {
> if (! on_sig_stack(regs->gpr[1]))
This should use sas_ss_flags.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Freescale MPC8xx USB support
From: Josef Angermeier @ 2006-03-27 13:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
in the last linux stable release 2.6.15 i couldn't find any driver for
the USB-hostcontroller embedded in Freescale MPC875. Is there some work
ongoing or must i start writing my own driver ?
thanks in advance
Josef
^ permalink raw reply
* freescale 8xx: which architecture to use ? ppc - powerpc ?
From: Josef Angermeier @ 2006-03-27 13:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i want to run linux (2.6.15) on my MPC875 board. I wonder which
architecture to choose: "powerpc" or "ppc" ? - menuconfig shows a
"freescale 8xx" option when used with "powerpc", and a "8xx" option when
used with ARCH=ppc. Because i use a embedded freescale 8xx i wanted to
use the "powerpc" architecture. BUT: i seems to be unstable, i got some
undefined referencies. Or am i wrong ?
thanks
Josef
^ permalink raw reply
* [PATCH] sigaltstack bad behavior on powerpc64
From: Laurent MEYER @ 2006-03-27 9:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Hello,
I may have found a bug in powerpc64 arch specific code.
*) When setting a sighandler using sigaction() call, if the flag
SA_ONSTACK is set and no alternate stack is provided via sigaltstack(),
the kernel still try to install the alternate stack. This behavior is
the opposite of the one which is documented in Single Unix
Specifications V3.
*) Also when setting an alternate stack using sigaltstack() with the flag SS_DISABLE,
the kernel try to install the alternate stack on signal delivery.
These two use cases makes the process crash at signal delivery.
I wrote a small patch to add a condition in get_sigframe().
Hope that is relevant and helpfull.
Regards,
Laurent MEYER.
Signed-off-by: Laurent Meyer <meyerlau@fr.ibm.com>
[-- Attachment #2: sigaltstack.fix.patch --]
[-- Type: text/x-patch, Size: 605 bytes --]
Index: linux-2.6.16-mcr/arch/powerpc/kernel/signal_64.c
===================================================================
--- linux-2.6.16-mcr.orig/arch/powerpc/kernel/signal_64.c 2006-03-27 11:09:02.000000000 +0200
+++ linux-2.6.16-mcr/arch/powerpc/kernel/signal_64.c 2006-03-27 11:14:16.986879573 +0200
@@ -213,7 +213,7 @@
/* Default to using normal stack */
newsp = regs->gpr[1];
- if (ka->sa.sa_flags & SA_ONSTACK) {
+ if ((ka->sa.sa_flags & SA_ONSTACK) && current->sas_ss_size) {
if (! on_sig_stack(regs->gpr[1]))
newsp = (current->sas_ss_sp + current->sas_ss_size);
}
^ permalink raw reply
* Re: Interpreting /proc/meminfo. How much free memory do I have?
From: antonio.dibacco @ 2006-03-27 9:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4427A9C1.3060000@berghof.com>
I don't understand the meaning of "Inactive". They are not used but the
kernel cannot give this memory to a requesting process because we tipically
don't have a swap device on a linux embedded board. Where we can store the
Inactive page? Am I wrong?
If I run a process that continuosly allocates memory and print out the total
allocated memory when it receives SIGINT or SIGTERM, I think I get the real
"free memory"!
Bye,
Antonio.
Eberhard Stoll Scrive:
> Roger Larsson schrieb:
>
>>On måndag 27 mars 2006 08.49, antonio.dibacco wrote:
>>
>>
>>>Hi,
>>>
>>>I'm a little bit puzzled with the fields in /proc/meminfo. Which fields
>>>have I to sum up to get the amount of free memory?
>>>
>>>
>>
>>>From a 2.6 /proc/meminfo
>>
>>MemTotal: 515532 kB
>>MemFree: 6012 kB
>>Buffers: 79964 kB
>>Cached: 83264 kB
>>SwapCached: 82840 kB
>>Active: 294024 kB
>>Inactive: 130304 kB
>>- - -
>>
>>Completely free is only MemFree. But those pages are only needed for
>>interrupt handlers (close enough).
>>
>>Cached pages are also free but since they contain data that maybe will
>>be needed again (unmodified data that already is on disk) they are not
>>returned to MemFree state.
>>
>>Inactive pages has not been in use for awhile and can be written out
>>if needed (some are probably unmodified and quick to get)
>>
>>
> Active + Inactive + MemFree is not equal MemTotal. Where can i find the
> offset?
>
> Thanks,
> Eberhard
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* "[PATCH] tvec_bases too large for per-cpu data" breaks 440 user-space
From: Eugene Surovegin @ 2006-03-27 9:10 UTC (permalink / raw)
To: linuxppc-dev
Hi!
latest kernel.org's 2.6 fails to boot on 440GX eval board (init
hangs).
git-bisect points to this generic change:
a4a6198b80cf82eb8160603c98da218d1bd5e104
[PATCH] tvec_bases too large for per-cpu data
I cannot tell now why this is causing problems, benh thinks that
"changes cpu/per-cpu" might be responsible.
It's likely that other PPC subarchs are affected as well.
--
Eugene
^ permalink raw reply
* Re: Interpreting /proc/meminfo. How much free memory do I have?
From: Eberhard Stoll @ 2006-03-27 9:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200603270953.11079.roger.larsson@norran.net>
Roger Larsson schrieb:
>On måndag 27 mars 2006 08.49, antonio.dibacco wrote:
>
>
>>Hi,
>>
>>I'm a little bit puzzled with the fields in /proc/meminfo. Which fields
>>have I to sum up to get the amount of free memory?
>>
>>
>
>>From a 2.6 /proc/meminfo
>
>MemTotal: 515532 kB
>MemFree: 6012 kB
>Buffers: 79964 kB
>Cached: 83264 kB
>SwapCached: 82840 kB
>Active: 294024 kB
>Inactive: 130304 kB
>- - -
>
>Completely free is only MemFree. But those pages are only needed for
>interrupt handlers (close enough).
>
>Cached pages are also free but since they contain data that maybe will
>be needed again (unmodified data that already is on disk) they are not
>returned to MemFree state.
>
>Inactive pages has not been in use for awhile and can be written out
>if needed (some are probably unmodified and quick to get)
>
>
Active + Inactive + MemFree is not equal MemTotal. Where can i find the
offset?
Thanks,
Eberhard
^ permalink raw reply
* Re: Interpreting /proc/meminfo. How much free memory do I have?
From: Roger Larsson @ 2006-03-27 7:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060327064907.23992.qmail@mx1.aruba.it>
On m=E5ndag 27 mars 2006 08.49, antonio.dibacco wrote:
> Hi,
>
> I'm a little bit puzzled with the fields in /proc/meminfo. Which fields
> have I to sum up to get the amount of free memory?
=46rom a 2.6 /proc/meminfo
MemTotal: 515532 kB
MemFree: 6012 kB
Buffers: 79964 kB
Cached: 83264 kB
SwapCached: 82840 kB
Active: 294024 kB
Inactive: 130304 kB
=2D - -
Completely free is only MemFree. But those pages are only needed for
interrupt handlers (close enough).
Cached pages are also free but since they contain data that maybe will
be needed again (unmodified data that already is on disk) they are not
returned to MemFree state.
Inactive pages has not been in use for awhile and can be written out
if needed (some are probably unmodified and quick to get)
/RogerL
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox