* MPC8272ADS stability issues
From: Alex Zeffertt @ 2005-11-25 15:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a question that is a bit off topic here, but you seem the most
knowledgable people to ask so please don't flame me... :)
I am using an MPC8272ADS development board. I was wondering if
anybody on this list experienced hardware reliability problems with
this platform.
I am running ELDK 3.1.1. I have seen the kernel hang several times,
and a Oops a few times too. The reason I suspect that this is a
hardware problem is that these seem to happen at completely random
times, and the Oopses, in random places. It doesn't seem to make
any difference whether I have any of my own modules loaded or not, and
I've even seen these problems occur in the bootloader.
I'm hoping for an answer along the lines of "Ah, you must have the
'fail randomly' dip switch set!"
TIA,
Alex
^ permalink raw reply
* [PATCH] cpm_uart: fix xchar sending
From: Aristeu Sergio Rozanski Filho @ 2005-11-25 14:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
Hi,
while using SCC as uart and as serial console at same time I got this:
[ 138.214258] Oops: kernel access of bad area, sig: 11 [#1]
[ 138.218832] PREEMPT
[ 138.221021] NIP: C0105C48 LR: C0105E60 SP: C03D5D10 REGS: c03d5c60 TRAP: 0300 Not tainted
[ 138.229280] MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
[ 138.234713] DAR: 00000000, DSISR: C0000000
[ 138.238745] TASK = c0349420[693] 'sh' THREAD: c03d4000
[ 138.243754] Last syscall: 6
[ 138.246402] GPR00: FEFFFFFF C03D5D10 C0349420 C01FB094 00000011 00000000 C1ECFBBC C01F24B0
[ 138.254602] GPR08: FF002820 00000000 FF0028C0 00000000 19133615 A0CBCD5E 02000300 00000000
[ 138.262804] GPR16: 00000000 01FF9E4C 00000000 7FA9A770 00000000 00000000 1003E2A8 00000000
[ 138.271003] GPR24: 100562F4 7F9B6EF4 C0210000 C02A5338 C01FB094 00000000 C01FB094 C1F14574
[ 138.279376] NIP [c0105c48] cpm_uart_tx_pump+0x4c/0x22c
[ 138.284419] LR [c0105e60] cpm_uart_start_tx+0x38/0xb0
[ 138.289361] Call trace:
[ 138.291762] [c0105e60] cpm_uart_start_tx+0x38/0xb0
[ 138.296547] [c010277c] uart_send_xchar+0x88/0x118
[ 138.301244] [c01029a0] uart_unthrottle+0x6c/0x138
[ 138.305942] [c00ece10] check_unthrottle+0x60/0x64
[ 138.310641] [c00ecec4] reset_buffer_flags+0xb0/0x138
[ 138.315595] [c00ecf64] n_tty_flush_buffer+0x18/0x78
[ 138.320465] [c00e81b0] tty_ldisc_flush+0x64/0x7c
[ 138.325078] [c010410c] uart_close+0xf0/0x2c8
[ 138.329348] [c00e9c48] release_dev+0x724/0x8d4
[ 138.333790] [c00e9e18] tty_release+0x20/0x3c
[ 138.338061] [c006e544] __fput+0x178/0x1e0
[ 138.342076] [c006c43c] filp_close+0x54/0xac
[ 138.346261] [c0002d90] ret_from_syscall+0x0/0x44
[ 138.352386] note: sh[693] exited with preempt_count 2
a easy way to reproduce it is log into the system using ssh and do:
cat >/dev/ttyCPM0
then, switch to minicom and write some stuff on it back to ssh, a control C
produce the oops
this happens because uart_close calls uart_shutdown which frees xmit.buf,
currently used by xchar sending in cpm_uart_tx_pump(), which seems wrong.
the attached patch fixes the oops and also fixes xchar sending.
Comments?
--
Aristeu
[-- Attachment #2: cpm_uart-fix_xchar_sending.patch --]
[-- Type: text/plain, Size: 498 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-11-25 10:44:14.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-11-25 10:44:26.000000000 -0200
@@ -605,7 +605,7 @@
p = cpm2cpu_addr(bdp->cbd_bufaddr);
- *p++ = xmit->buf[xmit->tail];
+ *p++ = port->x_char;
bdp->cbd_datlen = 1;
bdp->cbd_sc |= BD_SC_READY;
/* Get next BD. */
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Demke Torsten-atd012 @ 2005-11-25 14:21 UTC (permalink / raw)
To: Joakim Tjernlund, linuxppc-embedded
=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Joakim Tjernlund
> Sent: Freitag, 25. November 2005 14:28
> To: linuxppc-embedded@ozlabs.org
> Subject: Badness in 2.6.15-rc1 on 8xx
>=20
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
> Mount-cache hash table entries: 512
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00039e8] check_bug_trap+0x80/0xa8
> [c0003c1c] program_check_exception+0x20c/0x480
> [c00031e0] ret_from_except_full+0x0/0x4c
> [c01b86b8] dma_alloc_init+0x40/0xcc
> [c000225c] init+0x8c/0x288
> [c00050ac] kernel_thread+0x44/0x60
> NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems=20
> harmless, but I suspect it will bite me later.
>=20
> Something anoying:
> Why did the new cpm_uart driver change major and minor number=20
> for the tty?
> As it is now I can't boot my 2.4 rootfs as init think it=20
> should find the console on ttyS0.
> Would be great if major and minor could be configurable.
Because it's a new driver...with a new name (ttyCPM0) and a new
device number. It shared the device number and name in 2.4=20
with the "standard" device driver (8250/16550), and that made
it very difficult to use both in 2.4.=20
Maybe you should use console=3DttyCPM0 in your boot parameters for 2.6.
Regards,
Torsten
>=20
> Jocke
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Badness in 2.6.15-rc1 on 8xx
From: Joakim Tjernlund @ 2005-11-25 13:28 UTC (permalink / raw)
To: linuxppc-embedded
Anyone seen this when booting 2.6.15-rc1 on 8xx?
Mount-cache hash table entries: 512
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
[c00039e8] check_bug_trap+0x80/0xa8
[c0003c1c] program_check_exception+0x20c/0x480
[c00031e0] ret_from_except_full+0x0/0x4c
[c01b86b8] dma_alloc_init+0x40/0xcc
[c000225c] init+0x8c/0x288
[c00050ac] kernel_thread+0x44/0x60
NET: Registered protocol family 16
The kernel boots just fine into user space so it seems harmless, but I
suspect it will bite me later.
Something anoying:
Why did the new cpm_uart driver change major and minor number for the
tty?
As it is now I can't boot my 2.4 rootfs as init think it should find the
console on ttyS0.
Would be great if major and minor could be configurable.
Jocke
^ permalink raw reply
* [PATCH] cpm_uart: fix xchar sending
From: Aristeu Sergio Rozanski Filho @ 2005-11-25 13:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]
Hi,
while using SCC as uart and as serial console at same time I got this:
[ 138.214258] Oops: kernel access of bad area, sig: 11 [#1]
[ 138.218832] PREEMPT
[ 138.221021] NIP: C0105C48 LR: C0105E60 SP: C03D5D10 REGS: c03d5c60 TRAP: 0300 Not tainted
[ 138.229280] MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
[ 138.234713] DAR: 00000000, DSISR: C0000000
[ 138.238745] TASK = c0349420[693] 'sh' THREAD: c03d4000
[ 138.243754] Last syscall: 6
[ 138.246402] GPR00: FEFFFFFF C03D5D10 C0349420 C01FB094 00000011 00000000 C1ECFBBC C01F24B0
[ 138.254602] GPR08: FF002820 00000000 FF0028C0 00000000 19133615 A0CBCD5E 02000300 00000000
[ 138.262804] GPR16: 00000000 01FF9E4C 00000000 7FA9A770 00000000 00000000 1003E2A8 00000000
[ 138.271003] GPR24: 100562F4 7F9B6EF4 C0210000 C02A5338 C01FB094 00000000 C01FB094 C1F14574
[ 138.279376] NIP [c0105c48] cpm_uart_tx_pump+0x4c/0x22c
[ 138.284419] LR [c0105e60] cpm_uart_start_tx+0x38/0xb0
[ 138.289361] Call trace:
[ 138.291762] [c0105e60] cpm_uart_start_tx+0x38/0xb0
[ 138.296547] [c010277c] uart_send_xchar+0x88/0x118
[ 138.301244] [c01029a0] uart_unthrottle+0x6c/0x138
[ 138.305942] [c00ece10] check_unthrottle+0x60/0x64
[ 138.310641] [c00ecec4] reset_buffer_flags+0xb0/0x138
[ 138.315595] [c00ecf64] n_tty_flush_buffer+0x18/0x78
[ 138.320465] [c00e81b0] tty_ldisc_flush+0x64/0x7c
[ 138.325078] [c010410c] uart_close+0xf0/0x2c8
[ 138.329348] [c00e9c48] release_dev+0x724/0x8d4
[ 138.333790] [c00e9e18] tty_release+0x20/0x3c
[ 138.338061] [c006e544] __fput+0x178/0x1e0
[ 138.342076] [c006c43c] filp_close+0x54/0xac
[ 138.346261] [c0002d90] ret_from_syscall+0x0/0x44
[ 138.352386] note: sh[693] exited with preempt_count 2
a easy way to reproduce it is log into the system using ssh and do:
cat >/dev/ttyCPM0
then, switch to minicom and write some stuff on it back to ssh, a control C
produce the oops
this happens because uart_close calls uart_shutdown which frees xmit.buf,
currently used by xchar sending in cpm_uart_tx_pump(), which seems wrong.
the attached patch fixes the oops and also fixes xchar sending.
Comments?
--
Aristeu
[-- Attachment #2: cpm_uart-fix_xchar_sending.patch --]
[-- Type: text/plain, Size: 498 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-11-25 10:44:14.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-11-25 10:44:26.000000000 -0200
@@ -605,7 +605,7 @@
p = cpm2cpu_addr(bdp->cbd_bufaddr);
- *p++ = xmit->buf[xmit->tail];
+ *p++ = port->x_char;
bdp->cbd_datlen = 1;
bdp->cbd_sc |= BD_SC_READY;
/* Get next BD. */
^ permalink raw reply
* RE: [PATCH] ppc32: Add support for PM82x Boards
From: Paul Mackerras @ 2005-11-25 11:31 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <AHEILKONAKAEJPHNMOPNGELJCDAA.hs@denx.de>
Heiko Schocher writes:
> Sorry, you are right. Here comes the Patch again ...
Your mailer still seems to be stripping whitespace from the ends of
lines, which means git won't apply it. Perhaps you should gzip it and
send it to me as an attachment (or give me a URL to download it).
Paul.
^ permalink raw reply
* do_initcalls
From: Jaap de Jong @ 2005-11-25 7:41 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
In linux-2.4.25/init/main.c this function is called:
=09
static void __init do_initcalls(void)
{
initcall_t *call;
=09
call =3D &__initcall_start;
do {
(*call)();
call++
} while (call < &__initcall_end);
/* Make sure there is no pending stuff from the initcall
sequence */
flush_scheduled_tasks();
}
What is supposed to be in the section __initcall_start ..
__initcall_end?
Mine is empty and therefore causing trouble...
System.map:
//
//
c00ad880 A __initcall_end
c00ad880 A __initcall_start
//
//
The fix is obvious... But I guess I've missed something else?
Thanks in advance,
Jaap de Jong
=09
^ permalink raw reply
* Is there some articles discussing how to change bare-board code to linux driver?
From: zengshuai @ 2005-11-25 6:42 UTC (permalink / raw)
To: Linuxppc-embedded
Where can i find them?thanks.
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=Linuxppc-embedded&FullName=Linuxppc-embedded&Email=Linuxppc-embedded%40ozlabs.org&verify=777667b18eda2b5dd1bbd47542afad9b
^ permalink raw reply
* RE: [PATCH] ppc32: Add defconfig File for PM826 Board.
From: Heiko Schocher @ 2005-11-25 6:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17286.35454.210202.789136@cargo.ozlabs.ibm.com>
Hello Paul,
On Friday, November 25, 2005 4:53 AM Paul Mackerras wrote:
>> the following Patch (against 2.6 kernel.org tree, COMMIT_ID:
>> f093182d313edde9b1f86dbdaf40ba4da2dbd0e7) adds the defconfig
>> File for the PM826 Board from Microsys.
>
> Your first patch added a pm82x_defconfig; why do we need both a
> pm826_defconfig and a pm82x_defconfig?
We have 4 boards PM825/PM826/PM827/PM828 -> PM82x, but on the
PM826, we don t need CONFIG_PCI, so it have its own defconfig.
Best regards
Heiko
^ permalink raw reply
* Re: [PATCH] ppc32: Add defconfig File for PM826 Board.
From: Paul Mackerras @ 2005-11-25 3:52 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <AHEILKONAKAEJPHNMOPNEELBCDAA.hs@denx.de>
Heiko Schocher writes:
> the following Patch (against 2.6 kernel.org tree, COMMIT_ID:
> f093182d313edde9b1f86dbdaf40ba4da2dbd0e7) adds the defconfig
> File for the PM826 Board from Microsys.
Your first patch added a pm82x_defconfig; why do we need both a
pm826_defconfig and a pm82x_defconfig?
Paul.
^ permalink raw reply
* [PATCH] ibm_emac: fix graceful stop timeout handling
From: Eugene Surovegin @ 2005-11-24 22:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
This patch fixes graceful stop timeout handling in PPC4xx EMAC driver.
Currently, when we stop TX/RX channels we just do some number of loops
without relying on actual spent time. This has finally bitten me on
one of our systems (heavy network traffic during start up, RX channel
is stopped several times to configure multicast list).
Graceful channel stop can take up to 1 frame time, so I've added
device specific timeout counter which depends on current link speed
and calls to udelay() to really wait required amount of time before
giving up.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_core.c | 38 ++++++++++++++++++++++++++--------
drivers/net/ibm_emac/ibm_emac_core.h | 2 ++
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index eb7d694..1da8a66 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -65,7 +65,7 @@
*/
#define DRV_NAME "emac"
-#define DRV_VERSION "3.53"
+#define DRV_VERSION "3.54"
#define DRV_DESC "PPC 4xx OCP EMAC driver"
MODULE_DESCRIPTION(DRV_DESC);
@@ -158,6 +158,14 @@ static inline void emac_report_timeout_e
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
+/* Graceful stop timeouts in us.
+ * We should allow up to 1 frame time (full-duplex, ignoring collisions)
+ */
+#define STOP_TIMEOUT_10 1230
+#define STOP_TIMEOUT_100 124
+#define STOP_TIMEOUT_1000 13
+#define STOP_TIMEOUT_1000_JUMBO 73
+
/* Please, keep in sync with struct ibm_emac_stats/ibm_emac_error_stats */
static const char emac_stats_keys[EMAC_ETHTOOL_STATS_COUNT][ETH_GSTRING_LEN] = {
"rx_packets", "rx_bytes", "tx_packets", "tx_bytes", "rx_packets_csum",
@@ -222,10 +230,12 @@ static void emac_tx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_TXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_TXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "TX disable timeout");
}
@@ -248,9 +258,11 @@ static void emac_rx_enable(struct ocp_en
if (!(r & EMAC_MR0_RXE)) {
if (unlikely(!(r & EMAC_MR0_RXI))) {
/* Wait if previous async disable is still in progress */
- int n = 100;
- while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ int n = dev->stop_timeout;
+ while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev,
"RX disable timeout");
@@ -273,10 +285,12 @@ static void emac_rx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_RXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_RXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "RX disable timeout");
}
@@ -395,6 +409,7 @@ static int emac_configure(struct ocp_ene
r = EMAC_MR1_BASE(emac_opb_mhz()) | EMAC_MR1_VLE | EMAC_MR1_IST;
if (dev->phy.duplex == DUPLEX_FULL)
r |= EMAC_MR1_FDE;
+ dev->stop_timeout = STOP_TIMEOUT_10;
switch (dev->phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev->phy.mode)) {
@@ -409,12 +424,16 @@ static int emac_configure(struct ocp_ene
r |= EMAC_MR1_MF_1000;
r |= EMAC_MR1_RFS_16K;
gige = 1;
-
- if (dev->ndev->mtu > ETH_DATA_LEN)
+
+ if (dev->ndev->mtu > ETH_DATA_LEN) {
r |= EMAC_MR1_JPSM;
+ dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
+ } else
+ dev->stop_timeout = STOP_TIMEOUT_1000;
break;
case SPEED_100:
r |= EMAC_MR1_MF_100;
+ dev->stop_timeout = STOP_TIMEOUT_100;
/* Fall through */
default:
r |= EMAC_MR1_RFS_4K;
@@ -2048,6 +2067,7 @@ static int __init emac_probe(struct ocp_
dev->phy.duplex = DUPLEX_FULL;
dev->phy.autoneg = AUTONEG_DISABLE;
dev->phy.pause = dev->phy.asym_pause = 0;
+ dev->stop_timeout = STOP_TIMEOUT_100;
init_timer(&dev->link_timer);
dev->link_timer.function = emac_link_timer;
dev->link_timer.data = (unsigned long)dev;
diff --git a/drivers/net/ibm_emac/ibm_emac_core.h b/drivers/net/ibm_emac/ibm_emac_core.h
index e9b44d0..911abba 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.h
+++ b/drivers/net/ibm_emac/ibm_emac_core.h
@@ -189,6 +189,8 @@ struct ocp_enet_private {
struct timer_list link_timer;
int reset_failed;
+ int stop_timeout; /* in us */
+
struct ibm_emac_error_stats estats;
struct net_device_stats nstats;
^ permalink raw reply related
* [PATCH] ppc32: fix treeboot image entrypoint
From: Eugene Surovegin @ 2005-11-24 21:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, linuxppc-embedded
Correctly specify treeboot based image entrypoint. Currently makefile
uses $(ENTRYPOINT) which isn't defined anywhere. Each board port sets
entrypoint-$(CONFIG_BOARD_NAME) instead.
Without this patch I cannot boot Ocotea (PPC440GX eval board) anymore.
I was getting random "OS panic" errors from OpenBIOS for a while, but
with current kernel I get them all the time (probably because image
became bigger).
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
index 82df88b..f3e9c53 100644
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -262,11 +262,11 @@ $(images)/zImage.initrd-STRIPELF: $(obj)
skip=64 bs=1k
$(images)/zImage-TREE: $(obj)/zvmlinux $(MKTREE)
- $(MKTREE) $(obj)/zvmlinux $(images)/zImage.$(end-y) $(ENTRYPOINT)
+ $(MKTREE) $(obj)/zvmlinux $(images)/zImage.$(end-y) $(entrypoint-y)
$(images)/zImage.initrd-TREE: $(obj)/zvmlinux.initrd $(MKTREE)
$(MKTREE) $(obj)/zvmlinux.initrd $(images)/zImage.initrd.$(end-y) \
- $(ENTRYPOINT)
+ $(entrypoint-y)
$(images)/zImage-PPLUS: $(obj)/zvmlinux $(MKPREP) $(MKBUGBOOT)
$(MKPREP) -pbp $(obj)/zvmlinux $(images)/zImage.$(end-y)
^ permalink raw reply related
* Re: [PATCH] Fix USB suspend/resume crasher
From: Benjamin Herrenschmidt @ 2005-11-24 21:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <200511242214.16365.rjw@sisk.pl>
>
> FWIW, does the appended change look reasonable to you? (It apparently
> helps. ;-))
Yes. I was about to do a new patch after I finish my breakfast, but
yours applied on top of Greg's merged one works too.
Ben.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 21:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <1132866088.26560.455.camel@gaston>
On Thursday, 24 of November 2005 22:01, Benjamin Herrenschmidt wrote:
>
> >
> > Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
> > contains the patch). Do you mean it should go before the
> >
> > if (readl(&ehci->regs->configured_flag) != FLAG_CF)
> > goto restart;
> >
> > thing?
>
> Yes.
>
> > > It may be worth following it with a memory barrier actually... just in case
> > > (due to the absence of locks in that area).
> >
> > wmb()?
>
> Yup.
>
> I wrote that patch against a tree that had different things in that
> function, Greg merged it by hand but he got that little bit wrong
> unfortunately. I'll send a new patch later today.
Thanks.
FWIW, does the appended change look reasonable to you? (It apparently
helps. ;-))
Rafael
Index: linux-2.6.15-rc2-mm1/drivers/usb/host/ehci-pci.c
===================================================================
--- linux-2.6.15-rc2-mm1.orig/drivers/usb/host/ehci-pci.c 2005-11-24 21:42:34.000000000 +0100
+++ linux-2.6.15-rc2-mm1/drivers/usb/host/ehci-pci.c 2005-11-24 21:50:38.000000000 +0100
@@ -281,12 +281,13 @@
if (time_before(jiffies, ehci->next_statechange))
msleep(100);
+ set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ wmb();
+
/* If CF is clear, we lost PCI Vaux power and need to restart. */
if (readl(&ehci->regs->configured_flag) != FLAG_CF)
goto restart;
- set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-
/* If any port is suspended (or owned by the companion),
* we know we can/must resume the HC (and mustn't reset it).
* We just defer that to the root hub code.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Benjamin Herrenschmidt @ 2005-11-24 21:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <200511242150.23205.rjw@sisk.pl>
>
> Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
> contains the patch). Do you mean it should go before the
>
> if (readl(&ehci->regs->configured_flag) != FLAG_CF)
> goto restart;
>
> thing?
Yes.
> > It may be worth following it with a memory barrier actually... just in case
> > (due to the absence of locks in that area).
>
> wmb()?
Yup.
I wrote that patch against a tree that had different things in that
function, Greg merged it by hand but he got that little bit wrong
unfortunately. I'll send a new patch later today.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: serial port discovery
From: Benjamin Herrenschmidt @ 2005-11-24 20:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132852136.11921.85.camel@baythorne.infradead.org>
On Thu, 2005-11-24 at 17:08 +0000, David Woodhouse wrote:
> On Tue, 2005-11-22 at 15:49 +1100, Benjamin Herrenschmidt wrote:
> > This moves the discovery of legacy serial ports to a separate file,
> > makes it common to ppc32 and ppc64, and reworks it to use the new OF
> > address translators to get to the ports early. This new version can also
> > detect some PCI serial cards using legacy chips and will probably match
> > those discovered port with the default console choice.
>
> This makes it deal with the fact that the Pegasos firmware reports that
> its clock frequency is zero...
Gack !?!?
Sven, what's up there ? Why the hell would you do that ?
Ben.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 20:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <1132795396.26560.382.camel@gaston>
On Thursday, 24 of November 2005 02:23, Benjamin Herrenschmidt wrote:
>
> > Unfortunately with this patch the EHCI controller in my box (Asus L5D,
> > x86-64 kernel) does not resume from suspend. Appended is the relevant
> > snippet from the serial console log (EHCI is the only device using IRQ #5).
>
> Hrm... let me see... You are getting an interrupt for EHCI after it has
> been resumed, so it should work.
>
> /me double-checks the patch
>
> > ehci_hcd 0000:00:02.2: lost power, restarting
>
> Hrm... I can't find that line in the code...
>
> /me rechecks with david's other patches
>
> Ah ... I see it. There might have been some screwup between david's
> patch and mine.
>
> Make sure that
>
> set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
>
> Is still done before anything else in ehci_pci_resume().
Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
contains the patch). Do you mean it should go before the
if (readl(&ehci->regs->configured_flag) != FLAG_CF)
goto restart;
thing?
> It may be worth following it with a memory barrier actually... just in case
> (due to the absence of locks in that area).
wmb()?
Rafael
^ permalink raw reply
* Trouble getting Compact Flash IDE Interface to PPC440GP working
From: Gregg Nemas @ 2005-11-24 19:49 UTC (permalink / raw)
To: linuxppc-embedded
I have a PPC440GP-based CPU board that has a compact flash connected
to the peripheral bus in so-called "True IDE" mode. I am able to read
and write to the device using u-boot, and now I am trying to get it
working with linux 2.6.
The connection is like this:
CF A0..A2 =3D> PPC440 A30..A28 (ppc A31 not used for 16-bit bus)
CF D0..D15 =3D> PPC440 D15..D0
CF INTRQ =3D> PPC440 IRQ0 (GPIO0)
The peripheral bus is configured for 16-bit wide accesses.
I set the offsets passed to ide_setup_ports as follows:
#define CF_HD_DATA 0x00
#define CF_HD_ERROR 0x03 /* see err-bits */
#define CF_HD_NSECTOR 0x05 /* nr of sectors to read/write */
#define CF_HD_SECTOR 0x07 /* starting sector */
#define CF_HD_LCYL 0x09 /* starting cylinder */
#define CF_HD_HCYL 0x0b /* high byte of starting cyl */
#define CF_HD_SELECT 0x0d /* 101dhhhh, d=3Ddrive, hhhh=3Dhea=
d */
#define CF_HD_STATUS 0x0f /* see status-bits */
#define CF_HD_CONTROL 0x0010000d /* control/altstatus */
In order to get this working with u-boot, I had to endian swap all
16-bit data register accesses. I found that I had to do the same thing
in the ata_input_data and ata_output_data functions in ide-iops.c file
in linux before it would correctly identify the drive. I don't
understand why I have to do this in either place, given the
connections I described above, but it seems to be required.
After doing this, I get the following at bootup:
>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=3Dxx
>ide0: CF IDE interface
>Probing IDE interface ide0...
>hda: SanDisk SDCFJ-128, CFA DISK drive
>ide0 at 0xd1080000-0xd1080007,0xd118000d on irq 23
>hda: max request size: 128KiB
>hda: 250880 sectors (128 MB) w/1KiB Cache, CHS=3D980/8/32
>hda: cache flushes not supported
> hda: unknown partition table
I partitioned the drive using debian linux workstation with a pair of
type 83 partitions, and added a root file system to one of them. I can
see all this from u-boot, and can even load the kernel from it. I am
lost as to where to proceed to figure out why the kernel is having
trouble.
The other problem I am having is that after booting up, any attempt to
access /dev/hda using fdisk results in fdisk hanging, and "lost
interrupt" messages appearing on the console. If I look at
/proc/interrupts, it shows that 11 interrupts have occurred on
interrupt number 23. I have this set to level senstitive, positive
polarity.
Can someone offer some guidance?
Thanks.
Gregg
^ permalink raw reply
* Re: [PATCH] Save NVGPRS in 32-bit signal frame
From: David Woodhouse @ 2005-11-24 17:36 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1132836700.11921.58.camel@baythorne.infradead.org>
On Thu, 2005-11-24 at 12:51 +0000, David Woodhouse wrote:
> Somehow this one slipped through the cracks; when we ended up in
> do_signal() on a 32-bit kernel but without having the caller-saved
> registers into the regs, we didn't set the TIF_SAVE_NVGPRS flag to
> ensure they got saved later.
Oh, and if we actually set the flag, then we fairly quickly find out
that I was a bit overzealous in copying code from entry_64.S ... :)
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 8fed953..036b71d 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -368,7 +368,7 @@ save_user_nvgprs_cont:
b 6b
save_user_nvgprs:
- ld r8,TI_SIGFRAME(r12)
+ lwz r8,TI_SIGFRAME(r12)
.macro savewords start, end
1: stw \start,4*(\start)(r8)
@@ -386,11 +386,11 @@ save_user_nvgprs:
save_user_nvgprs_fault:
li r3,11 /* SIGSEGV */
- ld r4,TI_TASK(r12)
+ lwz r4,TI_TASK(r12)
bl force_sigsegv
rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
- ld r9,TI_FLAGS(r12)
+ lwz r9,TI_FLAGS(r12)
b save_user_nvgprs_cont
#ifdef SHOW_SYSCALLS
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] powerpc: serial port discovery
From: David Woodhouse @ 2005-11-24 17:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132634960.26560.133.camel@gaston>
On Tue, 2005-11-22 at 15:49 +1100, Benjamin Herrenschmidt wrote:
> This moves the discovery of legacy serial ports to a separate file,
> makes it common to ppc32 and ppc64, and reworks it to use the new OF
> address translators to get to the ports early. This new version can also
> detect some PCI serial cards using legacy chips and will probably match
> those discovered port with the default console choice.
This makes it deal with the fact that the Pegasos firmware reports that
its clock frequency is zero...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 28ad50e..7a685ca 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -43,7 +43,10 @@ static int __init add_legacy_port(struct
/* get clock freq. if present */
clk = (u32 *)get_property(np, "clock-frequency", NULL);
- clock = clk ? *clk : BASE_BAUD * 16;
+ if (clk && *clk)
+ clock = *clk;
+ else
+ clock = BASE_BAUD * 16;
/* get default speed if present */
spd = (u32 *)get_property(np, "current-speed", NULL);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] Fix USB suspend/resume crasher
From: Arkadiusz Miskiewicz @ 2005-11-24 16:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1132715288.26560.262.camel@gaston>
On Wednesday 23 November 2005 04:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
btw. what should happen if there are drivers which do not support=20
suspend/resume?
I'm using zd1211 wifi usb driver (which isn't state of art) from=20
http://zd1211.ath.cx/repos/trunk rev 39 and while trying to suspend on my=20
ibook g4 dec 2004 I'm getting this:
http://www.t17.ds.pwr.wroc.pl/~misiek/rozne/failed-sleep.jpg
After that the only thing I can do is turn the thing off and turn it back o=
n -=20
it just hangs. It would be nice if it just refuse to suspend or got things=
=20
back into sane state.
I'm using 2.6.15rc2git3 + both patches posted in this thread.
ps.
My usual suspend is:
/sbin/rmmod therm_adt746x
/sbin/rmmod zd1211
/sbin/rmmod usbmouse
/sbin/rmmod usbhid
/sbin/rmmod zd1211
/sbin/rmmod ehci-hcd
/sbin/rmmod ohci-hcd
/usr/sbin/snooze
(I guess that rmmod zd1211 should be enough now).
=2D-=20
Arkadiusz Mi=B6kiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 12:48 UTC (permalink / raw)
To: Clement Fabien; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F7F876@rennsmail03.eu.thmulti.com>
Clement Fabien wrote:
> Hi,
>
> Some results: alignments are now respected but it seems that the method
> I took from linux 2.4 is more efficient in terms of memory consumption.
> I will provide a complete patch today with the same mechanism for
> rh_alloc_fixed.
>
> Fabien
>
>
>
Please don't bother.
The other method messes up the deallocations, you just have to live
with the wasted space.
With rh_alloc_fixed you're suppossed to know your alignment, the align
argument is bogus.
Pantelis
^ permalink raw reply
* Re: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 12:46 UTC (permalink / raw)
To: Clement Fabien; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F54B1D@rennsmail03.eu.thmulti.com>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Clement Fabien wrote:
> Here is a patch that builds.
>
>
> -----Original Message-----
> From: Pantelis Antoniou [mailto:panto@intracom.gr]
> Sent: jeudi 24 novembre 2005 12:04
> To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
> Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
>
> Hi all.
>
> Alignments are currently handled bogusly for cpm2.
>
> Please test.
>
> Regards
>
> Pantelis
>
>
>
Updated patch....
[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-patch, Size: 4160 bytes --]
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2005-11-24 12:51 UTC (permalink / raw)
To: Clement Fabien, Pantelis Antoniou, Kumar Gala, Marcelo Tosatti,
linuxppc-embedded
Hi,
Some results: alignments are now respected but it seems that the method
I took from linux 2.4 is more efficient in terms of memory consumption.
I will provide a complete patch today with the same mechanism for
rh_alloc_fixed.
Fabien
Allocation method with offset (patch from myself)
rh_alloc - Required size =3D 0040, align =3D 0008
rh_alloc - Block size =3D 3F80, start =3D 00000080 - Off =3D 0000
rh_alloc - Alloc size =3D 0040, start =3D 00000080
rh_alloc - Required size =3D 0008, align =3D 0010
rh_alloc - Block size =3D 3F40, start =3D 000000c0 - Off =3D 0000
rh_alloc - Alloc size =3D 0010, start =3D 000000c0
rh_alloc - Required size =3D 1800, align =3D 0020
rh_alloc - Block size =3D 3F30, start =3D 000000d0 - Off =3D 0010
rh_alloc - Alloc size =3D 1810, start =3D 000000e0
rh_alloc - Required size =3D 0108, align =3D 0040
rh_alloc - Block size =3D 2720, start =3D 000018e0 - Off =3D 0020
rh_alloc - Alloc size =3D 0160, start =3D 00001900
rh_alloc - Required size =3D 0040, align =3D 0010
rh_alloc - Block size =3D 25C0, start =3D 00001a40 - Off =3D 0000
rh_alloc - Alloc size =3D 0040, start =3D 00001a40
rh_alloc - Required size =3D 0020, align =3D 0020
rh_alloc - Block size =3D 2580, start =3D 00001a80 - Off =3D 0000
rh_alloc - Alloc size =3D 0020, start =3D 00001a80
rh_alloc - Required size =3D 0010, align =3D 0010
rh_alloc - Block size =3D 2560, start =3D 00001aa0 - Off =3D 0000
rh_alloc - Alloc size =3D 0010, start =3D 00001aa0
rh_alloc - Required size =3D 000C, align =3D 0040
rh_alloc - Block size =3D 2550, start =3D 00001ab0 - Off =3D 0010
rh_alloc - Alloc size =3D 0050, start =3D 00001ac0
Allocation method without offset (Patch from Pantelis)
rh_alloc - Required size =3D 0040, align =3D 0008
rh_alloc - Block size =3D 3F80, start =3D 00000080
rh_alloc - Alloc size =3D 0047, start =3D 00000080
rh_alloc - Required size =3D 0008, align =3D 0010
rh_alloc - Block size =3D 3F39, start =3D 000000c7
rh_alloc - Alloc size =3D 0017, start =3D 000000d0
rh_alloc - Required size =3D 1800, align =3D 0020
rh_alloc - Block size =3D 3F22, start =3D 000000de
rh_alloc - Alloc size =3D 181F, start =3D 000000e0
rh_alloc - Required size =3D 0108, align =3D 0040
rh_alloc - Block size =3D 2703, start =3D 000018fd
rh_alloc - Alloc size =3D 0147, start =3D 00001900
rh_alloc - Required size =3D 0040, align =3D 0010
rh_alloc - Block size =3D 25BC, start =3D 00001a44
rh_alloc - Alloc size =3D 004F, start =3D 00001a50
rh_alloc - Required size =3D 0020, align =3D 0020
rh_alloc - Block size =3D 256D, start =3D 00001a93
rh_alloc - Alloc size =3D 003F, start =3D 00001aa0
rh_alloc - Required size =3D 0010, align =3D 0010
rh_alloc - Block size =3D 252E, start =3D 00001ad2
rh_alloc - Alloc size =3D 001F, start =3D 00001ae0
rh_alloc - Required size =3D 000C, align =3D 0040
rh_alloc - Block size =3D 250F, start =3D 00001af1
rh_alloc - Alloc size =3D 004B, start =3D 00001b00
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Clement
Fabien
Sent: jeudi 24 novembre 2005 12:26
To: Pantelis Antoniou; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: RE: [PATCH] CPM2: Fix totally bogus alignment handing of
dpalloc
Here is a patch that builds.
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]=20
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
^ permalink raw reply
* [PATCH] Save NVGPRS in 32-bit signal frame
From: David Woodhouse @ 2005-11-24 12:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Somehow this one slipped through the cracks; when we ended up in
do_signal() on a 32-bit kernel but without having the caller-saved
registers into the regs, we didn't set the TIF_SAVE_NVGPRS flag to
ensure they got saved later.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -219,6 +218,15 @@ static inline int get_old_sigaction(stru
static inline int save_general_regs(struct pt_regs *regs,
struct mcontext __user *frame)
{
+ if (!FULL_REGS(regs)) {
+ /* Zero out the unsaved GPRs to avoid information
+ leak, and set TIF_SAVE_NVGPRS to ensure that the
+ registers do actually get saved later. */
+ memset(®s->gpr[14], 0, 18 * sizeof(unsigned long));
+ current_thread_info()->nvgprs_frame = &frame->mc_gregs;
+ set_thread_flag(TIF_SAVE_NVGPRS);
+ }
+
return __copy_to_user(&frame->mc_gregs, regs, GP_REGS_SIZE);
}
--
dwmw2
^ 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