* [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Joakim Tjernlund @ 2010-02-26 8:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1267172983-28721-1-git-send-email-Joakim.Tjernlund@transmode.se>
This removes a couple of insn's from the TLB Miss
handlers whithout changing functionality.
---
arch/powerpc/kernel/head_8xx.S | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 3ef743f..ecc4a02 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -343,17 +343,14 @@ InstructionTLBMiss:
cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
bne- cr0, 2f
- /* Clear PP lsb, 0x400 */
- rlwinm r10, r10, 0, 22, 20
-
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 22 and 28 must be clear.
+ * Software indicator bits 21 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
li r11, 0x00f0
- rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
+ rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
@@ -444,9 +441,7 @@ DataStoreTLBMiss:
/* Honour kernel RO, User NA */
/* 0x200 == Extended encoding, bit 22 */
- /* r11 = (r10 & _PAGE_USER) >> 2 */
- rlwinm r11, r10, 32-2, 0x200
- or r10, r11, r10
+ rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
/* r11 = (r10 & _PAGE_RW) >> 1 */
rlwinm r11, r10, 32-1, 0x200
or r10, r11, r10
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Joakim Tjernlund @ 2010-02-26 8:29 UTC (permalink / raw)
To: linuxppc-dev
This set of tries to optimize the TLB code on 8xx even
more. If they work, it should be a noticable performance
boost.
I would be very happy if you could test them for me.
Joakim Tjernlund (4):
8xx: Optimze TLB Miss handlers
8xx: Avoid testing for kernel space in ITLB Miss.
8xx: Don't touch ACCESSED when no SWAP.
8xx: Use SPRG2 and DAR registers to stash r11 and cr.
arch/powerpc/kernel/head_8xx.S | 70 +++++++++++++++++++++++++++-------------
1 files changed, 47 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 2/4] 8xx: Avoid testing for kernel space in ITLB Miss.
From: Joakim Tjernlund @ 2010-02-26 8:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1267172983-28721-2-git-send-email-Joakim.Tjernlund@transmode.se>
Only modules will cause ITLB Misses as we always pin
the first 8MB of kernel memory.
---
arch/powerpc/kernel/head_8xx.S | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index ecc4a02..84ca1d9 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -318,12 +318,16 @@ InstructionTLBMiss:
/* If we are faulting a kernel address, we have to use the
* kernel page tables.
*/
+#ifdef CONFIG_MODULES
+ /* Only modules will cause ITLB Misses as we always
+ * pin the first 8MB of kernel memory */
andi. r11, r10, 0x0800 /* Address >= 0x80000000 */
beq 3f
lis r11, swapper_pg_dir@h
ori r11, r11, swapper_pg_dir@l
rlwimi r10, r11, 0, 2, 19
3:
+#endif
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/4] 8xx: Don't touch ACCESSED when no SWAP.
From: Joakim Tjernlund @ 2010-02-26 8:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1267172983-28721-3-git-send-email-Joakim.Tjernlund@transmode.se>
Only the swap function cares about the ACCESSED bit in
the pte. Do not waste cycles updateting ACCESSED when swap
is not compiled into the kernel.
---
arch/powerpc/kernel/head_8xx.S | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 84ca1d9..6478a96 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -343,10 +343,11 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
+#ifdef CONFIG_SWAP
andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
bne- cr0, 2f
-
+#endif
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 21 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
@@ -439,10 +440,11 @@ DataStoreTLBMiss:
* r11 = ((r10 & PRESENT) & ((r10 & ACCESSED) >> 5));
* r10 = (r10 & ~PRESENT) | r11;
*/
+#ifdef CONFIG_SWAP
rlwinm r11, r10, 32-5, _PAGE_PRESENT
and r11, r11, r10
rlwimi r10, r11, 0, _PAGE_PRESENT
-
+#endif
/* Honour kernel RO, User NA */
/* 0x200 == Extended encoding, bit 22 */
rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 4/4] 8xx: Use SPRG2 and DAR registers to stash r11 and cr.
From: Joakim Tjernlund @ 2010-02-26 8:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1267172983-28721-4-git-send-email-Joakim.Tjernlund@transmode.se>
This avoids storing these registers in memory.
CPU6 errata will still use the old way.
Remove some G2 leftover accesses from 2.4
---
arch/powerpc/kernel/head_8xx.S | 49 +++++++++++++++++++++++++++++----------
1 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6478a96..1f1a04b 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -71,9 +71,6 @@ _ENTRY(_start);
* in the first level table, but that would require many changes to the
* Linux page directory/table functions that I don't want to do right now.
*
- * I used to use SPRG2 for a temporary register in the TLB handler, but it
- * has since been put to other uses. I now use a hack to save a register
- * and the CCR at memory location 0.....Someday I'll fix this.....
* -- Dan
*/
.globl __start
@@ -302,8 +299,13 @@ InstructionTLBMiss:
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
+#ifdef CONFIG_8xx_CPU6
stw r10, 0(r0)
stw r11, 4(r0)
+#else
+ mtspr SPRN_DAR, r10
+ mtspr SPRN_SPRG2, r11
+#endif
mfspr r10, SPRN_SRR0 /* Get effective address of fault */
#ifdef CONFIG_8xx_CPU15
addi r11, r10, 0x1000
@@ -359,13 +361,19 @@ InstructionTLBMiss:
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
rfi
2:
mfspr r11, SPRN_SRR1
@@ -375,13 +383,20 @@ InstructionTLBMiss:
rlwinm r11, r11, 0, 0xffff
mtspr SPRN_SRR1, r11
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ li r11, 0x00f0
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
b InstructionAccess
. = 0x1200
@@ -392,8 +407,13 @@ DataStoreTLBMiss:
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
+#ifdef CONFIG_8xx_CPU6
stw r10, 0(r0)
stw r11, 4(r0)
+#else
+ mtspr SPRN_DAR, r10
+ mtspr SPRN_SPRG2, r11
+#endif
mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
/* If we are faulting a kernel address, we have to use the
@@ -461,18 +481,24 @@ DataStoreTLBMiss:
* of the MMU.
*/
2: li r11, 0x00f0
- mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
+ mtspr SPRN_DAR, r11 /* Tag DAR */
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
@@ -684,9 +710,6 @@ start_here:
tophys(r4,r2)
addi r4,r4,THREAD /* init task's THREAD */
mtspr SPRN_SPRG_THREAD,r4
- li r3,0
- /* XXX What is that for ? SPRG2 appears otherwise unused on 8xx */
- mtspr SPRN_SPRG2,r3 /* 0 => r1 has kernel sp */
/* stack */
lis r1,init_thread_union@ha
--
1.6.4.4
^ permalink raw reply related
* [PATCH] hvc_console: Fix a race between hvc_close and hvc_remove
From: Amit Shah @ 2010-02-26 11:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Amit Shah, linuxppc-dev, Rusty Russell, Alan Cox
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp->tty
unlock
lock
hp->tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty->ops will be NULL
NULL->...
This patch adds some tty krefs and also converts to using tty_vhangup()
before putting the tty kref.
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
---
I can't be sure if this is all that's needed. tty people, please take
a look!
drivers/char/hvc_console.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d8dac58..3983e32 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -106,6 +106,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
spin_lock_irqsave(&hp->lock, flags);
if (hp->index == index) {
kref_get(&hp->kref);
+ tty_kref_get(hp->tty);
spin_unlock_irqrestore(&hp->lock, flags);
spin_unlock(&hvc_structs_lock);
return hp;
@@ -390,6 +391,7 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
}
kref_put(&hp->kref, destroy_hvc_struct);
+ tty_kref_put(tty);
}
static void hvc_hangup(struct tty_struct *tty)
@@ -806,6 +808,7 @@ int hvc_remove(struct hvc_struct *hp)
unsigned long flags;
struct tty_struct *tty;
+ tty_kref_get(hp->tty);
spin_lock_irqsave(&hp->lock, flags);
tty = hp->tty;
@@ -830,7 +833,9 @@ int hvc_remove(struct hvc_struct *hp)
* cleaned up the hvc_struct.
*/
if (tty)
- tty_hangup(tty);
+ tty_vhangup(tty);
+
+ tty_kref_put(hp->tty);
return 0;
}
EXPORT_SYMBOL_GPL(hvc_remove);
--
1.6.2.5
^ permalink raw reply related
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 11:51 UTC (permalink / raw)
To: avorontsov
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet, davem
In-Reply-To: <20100225165141.GA9686@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
> [...]
>
>>> nfs: server 192.168.0.1 not responding, still trying
>>>
>>>
>> Further testing has shown that this isn't restricted to warm reboots, it
>> happens from cold as well. In addition, the exact timing of the failure
>> seems to vary, some boots have got further before failing.
>>
>
> Unfortunately I don't have any 8641 boards near me, so I can't
> debug this myself. Though, I tested gianfar on MPC8568E-MDS with
> 2.6.33 kernel, and it seems to work just fine.
>
> I see you use SMP. Can you try to turn it off? If that will fix
> the issue, then it'll be a good data point.
>
> Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
> know the results.
>
> Thanks
I removed the second core from the dts file rather than truly disabling
SMP in the kernel config. Doing this allowed the board to boot reliably.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 12:06 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev list, netdev, linux-kernel, Paul Gortmaker,
Sandeep Gopalpet, davem
In-Reply-To: <20100226031452.GA11319@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
> [...]
>
>> I was able to reproduce it on an 8641D and bisected it down to this:
>>
>> -----------
>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Date: Tue Nov 10 14:11:10 2009 +0000
>>
>> gianfar: Revive SKB recycling
>>
>
> Thanks for the bisect. I have a guess why tx hangs in
> SMP case. Could anyone try the patch down below?
>
Yup, no problem. I'm afraid it doesn't resolve the problem for me.
> [...]
>
>> ...which probably explains why you weren't seeing it on non-SMP.
>> I'd imagine it would show up on any of the e500mc boards too.
>>
>
> Yeah.. Pity, I don't have SMP boards anymore. I'll try
> to get one though.
>
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 8bd3c9f..3ff3bd0 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget)
> tx_queue = priv->tx_queue[rx_queue->qindex];
>
> tx_cleaned += gfar_clean_tx_ring(tx_queue);
> + if (!tx_cleaned && !tx_queue->num_txbdfree)
> + tx_cleaned += 1; /* don't complete napi */
> rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue,
> budget_per_queue);
> rx_cleaned += rx_cleaned_per_queue;
>
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?
From: David Woodhouse @ 2010-02-26 12:30 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, linuxppc-dev, François Galea
In-Reply-To: <4A8ED239.4060609@am.sony.com>
On Fri, 2009-08-21 at 09:58 -0700, geoffrey.levand@am.sony.com wrote:
> The feature of "Install Other OS" was removed from the new
> "Slim" PS3 model to focus on delivering games and other
> entertainment content.
>
> Please be assured that SCE is committed to continue
> the support for previously sold models that have the
> "Install Other OS" feature and that this feature will
> not be disabled in future firmware releases.
Although it's disappointing that Sony have removed the feature from new
models, It's good to have this public assurance from Sony that at least
the feature won't be removed from older models which are already
working.
I suppose it shouldn't be too much of a surprise -- if people have
bought PS3s specifically to use the advertised 'OtherOS' feature and
Sony were to break that with a firmware update, then there may well be
legal ramifications. But it's nice to have the promise in writing
anyway.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Fix lwsync feature fixup vs. modules on 64-bit
From: Sachin Sant @ 2010-02-26 13:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux/PPC Development
In-Reply-To: <1267169407.23523.1798.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Anton's commit enabling the use of the lwsync fixup mechanism on 64-bit
> breaks modules. The lwsync fixup section uses .long instead of the
> FTR_ENTRY_OFFSET macro used by other fixups sections, and thus will
> generate 32-bit relocations that our module loader cannot resolve.
>
> This changes it to use the same type as other feature sections.
>
> Note however that we might want to consider using 32-bit for all the
> feature fixup offsets and add support for R_PPC_REL32 to module_64.c
> instead as that would reduce the size of the kernel image. I'll leave
> that as an exercise for the reader for now...
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/feature-fixups.h | 2 +-
> arch/powerpc/lib/feature-fixups.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
Thanks for the patch Ben.
I can boot -next on my power boxes with it.
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-26 14:35 UTC (permalink / raw)
To: Martyn Welch
Cc: Paul Gortmaker, netdev, linux-kernel, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <4B87B937.6010204@ge.com>
On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
> Anton Vorontsov wrote:
> > On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
> > [...]
> >
> >> I was able to reproduce it on an 8641D and bisected it down to this:
> >>
> >> -----------
> >> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
> >> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> >> Date: Tue Nov 10 14:11:10 2009 +0000
> >>
> >> gianfar: Revive SKB recycling
> >>
> >
> > Thanks for the bisect. I have a guess why tx hangs in
> > SMP case. Could anyone try the patch down below?
> >
>
> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
Hm.. I found a p2020 board and I was able to reproduce the issue.
The patch down below fixed it completely for me... hm.
I'll look further, thanks!
> > [...]
> >
> >> ...which probably explains why you weren't seeing it on non-SMP.
> >> I'd imagine it would show up on any of the e500mc boards too.
> >>
> >
> > Yeah.. Pity, I don't have SMP boards anymore. I'll try
> > to get one though.
> >
> >
> > diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> > index 8bd3c9f..3ff3bd0 100644
> > --- a/drivers/net/gianfar.c
> > +++ b/drivers/net/gianfar.c
> > @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget)
> > tx_queue = priv->tx_queue[rx_queue->qindex];
> >
> > tx_cleaned += gfar_clean_tx_ring(tx_queue);
> > + if (!tx_cleaned && !tx_queue->num_txbdfree)
> > + tx_cleaned += 1; /* don't complete napi */
> > rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue,
> > budget_per_queue);
> > rx_cleaned += rx_cleaned_per_queue;
> >
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 15:18 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet,
avorontsov, davem
In-Reply-To: <4B87E01E.4070704@windriver.com>
Paul Gortmaker wrote:
> On 10-02-26 09:35 AM, Anton Vorontsov wrote:
>
>> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>>
>>> Anton Vorontsov wrote:
>>>
>>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>>> [...]
>>>>
>>>>
>>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>>
>>>>> -----------
>>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>>> Author: Anton Vorontsov<avorontsov@ru.mvista.com>
>>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>>
>>>>> gianfar: Revive SKB recycling
>>>>>
>>>>>
>>>> Thanks for the bisect. I have a guess why tx hangs in
>>>> SMP case. Could anyone try the patch down below?
>>>>
>>>>
>>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>>>
>> Hm.. I found a p2020 board and I was able to reproduce the issue.
>> The patch down below fixed it completely for me... hm.
>>
>
> Interesting. I just tested the patch on the sbc8641d, and it
> still has the issue with your patch applied. I'm using NFSroot
> just like Martyn was and it still appears bound up on that
> gianfar tx lock. I'll see if I can get a SysRq backtrace in
> case that will help you see how it manages to get there...
>
I've got a p2020ds here as well, so I'll give NFSroot on that a try with
your patch.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-26 15:34 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet,
avorontsov, davem
In-Reply-To: <4B87E662.3080106@ge.com>
Martyn Welch wrote:
> Paul Gortmaker wrote:
>
>> On 10-02-26 09:35 AM, Anton Vorontsov wrote:
>>
>>
>>> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>>>
>>>
>>>> Anton Vorontsov wrote:
>>>>
>>>>
>>>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>>>> [...]
>>>>>
>>>>>
>>>>>
>>>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>>>
>>>>>> -----------
>>>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>>>> Author: Anton Vorontsov<avorontsov@ru.mvista.com>
>>>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>>>
>>>>>> gianfar: Revive SKB recycling
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks for the bisect. I have a guess why tx hangs in
>>>>> SMP case. Could anyone try the patch down below?
>>>>>
>>>>>
>>>>>
>>>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>>>>
>>>>
>>> Hm.. I found a p2020 board and I was able to reproduce the issue.
>>> The patch down below fixed it completely for me... hm.
>>>
>>>
>> Interesting. I just tested the patch on the sbc8641d, and it
>> still has the issue with your patch applied. I'm using NFSroot
>> just like Martyn was and it still appears bound up on that
>> gianfar tx lock. I'll see if I can get a SysRq backtrace in
>> case that will help you see how it manages to get there...
>>
>>
>
> I've got a p2020ds here as well, so I'll give NFSroot on that a try with
> your patch.
>
Out of 10 boot attempts, 7 failed.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-26 16:10 UTC (permalink / raw)
To: Martyn Welch
Cc: Paul Gortmaker, netdev, linux-kernel, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <4B87E9EF.3010604@ge.com>
On Fri, Feb 26, 2010 at 03:34:07PM +0000, Martyn Welch wrote:
[...]
> Out of 10 boot attempts, 7 failed.
OK, I see why. With ip=on (dhcp boot) it's much harder to trigger
it. With static ip config can I see the same.
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Paul Gortmaker @ 2010-02-26 14:52 UTC (permalink / raw)
To: avorontsov
Cc: netdev, linux-kernel, Martyn Welch, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <20100226143532.GA31622@oksana.dev.rtsoft.ru>
On 10-02-26 09:35 AM, Anton Vorontsov wrote:
> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>> Anton Vorontsov wrote:
>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>> [...]
>>>
>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>
>>>> -----------
>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>> Author: Anton Vorontsov<avorontsov@ru.mvista.com>
>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>
>>>> gianfar: Revive SKB recycling
>>>>
>>>
>>> Thanks for the bisect. I have a guess why tx hangs in
>>> SMP case. Could anyone try the patch down below?
>>>
>>
>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>
> Hm.. I found a p2020 board and I was able to reproduce the issue.
> The patch down below fixed it completely for me... hm.
Interesting. I just tested the patch on the sbc8641d, and it
still has the issue with your patch applied. I'm using NFSroot
just like Martyn was and it still appears bound up on that
gianfar tx lock. I'll see if I can get a SysRq backtrace in
case that will help you see how it manages to get there...
Paul.
----
nfs: server not responding, still trying
[repeated ~15 times, then...]
INFO: task rc.sysinit:837 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
rc.sysinit D 0fef73f4 0 837 836 0x00000000
Call Trace:
[dfb7d9b0] [c000a144] __switch_to+0x8c/0xf8
[dfb7d9d0] [c03443dc] schedule+0x380/0x954
[dfb7da50] [c0344a0c] io_schedule+0x5c/0x90
[dfb7da70] [c0074b0c] sync_page+0x4c/0x74
[dfb7da80] [c0344f44] __wait_on_bit_lock+0xb0/0x148
[dfb7dab0] [c0074a8c] __lock_page+0x94/0xa4
[dfb7dae0] [c0074d5c] find_lock_page+0x8c/0xa4
[dfb7db00] [c0075674] filemap_fault+0x1ec/0x4fc
[dfb7db40] [c008d548] __do_fault+0x98/0x53c
[dfb7dba0] [c0018478] do_page_fault+0x2d0/0x500
[dfb7dc50] [c00149d4] handle_page_fault+0xc/0x80
--- Exception: 301 at __clear_user+0x14/0x7c
LR = load_elf_binary+0x670/0x1270
[dfb7dd10] [c00f6ca0] load_elf_binary+0x620/0x1270 (unreliable)
[dfb7dd90] [c00b1f78] search_binary_handler+0x17c/0x394
[dfb7dde0] [c00f4f50] load_script+0x274/0x288
[dfb7de90] [c00b1f78] search_binary_handler+0x17c/0x394
[dfb7dee0] [c00b3580] do_execve+0x240/0x29c
[dfb7df20] [c000a46c] sys_execve+0x68/0xa4
[dfb7df40] [c00145a4] ret_from_syscall+0x0/0x38
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Paul Gortmaker @ 2010-02-26 16:27 UTC (permalink / raw)
To: avorontsov
Cc: netdev, linux-kernel, Martyn Welch, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <20100226161058.GA22954@oksana.dev.rtsoft.ru>
On 10-02-26 11:10 AM, Anton Vorontsov wrote:
> On Fri, Feb 26, 2010 at 03:34:07PM +0000, Martyn Welch wrote:
> [...]
>> Out of 10 boot attempts, 7 failed.
>
> OK, I see why. With ip=on (dhcp boot) it's much harder to trigger
> it. With static ip config can I see the same.
I'd kind of expected to see us stuck in gianfar on that lock, but
the SysRQ-T doesn't show us hung up anywhere in gianfar itself.
[This was on a base 2.6.33, with just a small sysrq fix patch]
Paul.
----------
SysRq : Changing Loglevel
Loglevel set to 9
nfs: server not responding, still trying
SysRq : Show State
task PC stack pid father
init D 0ff1c380 0 1 0 0x00000000
Call Trace:
[df841a30] [c0009fc4] __switch_to+0x8c/0xf8
[df841a50] [c0350160] schedule+0x354/0x92c
[df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54
[df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108
[df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4
[df841b40] [c0331cf0] __rpc_execute+0x16c/0x398
[df841b90] [c0329abc] rpc_run_task+0x48/0x9c
[df841ba0] [c0329c40] rpc_call_sync+0x54/0x88
[df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8
[df841c20] [c014eb60] nfs_lookup+0x12c/0x230
[df841d50] [c00b9680] do_lookup+0x118/0x288
[df841d80] [c00bb904] link_path_walk+0x194/0x1118
[df841df0] [c00bcb08] path_walk+0x8c/0x168
[df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c
[df841e40] [c00be148] do_filp_open+0x5d4/0xba4
[df841f10] [c00abe94] do_sys_open+0xac/0x190
[df841f40] [c001437c] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff1c380
LR = 0xfec6d98
kthreadd S 00000000 0 2 0 0x00000000
Call Trace:
[df843e50] [c002e788] wake_up_new_task+0x128/0x16c (unreliable)
[df843f10] [c0009fc4] __switch_to+0x8c/0xf8
[df843f30] [c0350160] schedule+0x354/0x92c
[df843fc0] [c004d154] kthreadd+0x130/0x134
[df843ff0] [c00141a0] kernel_thread+0x4c/0x68
migration/0 S 00000000 0 3 2 0x00000000
Call Trace:
[df847de0] [ffffffff] 0xffffffff (unreliable)
[df847ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df847ec0] [c0350160] schedule+0x354/0x92c
[df847f50] [c002d074] migration_thread+0x29c/0x448
[df847fb0] [c004d020] kthread+0x80/0x84
[df847ff0] [c00141a0] kernel_thread+0x4c/0x68
ksoftirqd/0 S 00000000 0 4 2 0x00000000
Call Trace:
[df84be10] [00000800] 0x800 (unreliable)
[df84bed0] [c0009fc4] __switch_to+0x8c/0xf8
[df84bef0] [c0350160] schedule+0x354/0x92c
[df84bf80] [c0038454] run_ksoftirqd+0x14c/0x1e0
[df84bfb0] [c004d020] kthread+0x80/0x84
[df84bff0] [c00141a0] kernel_thread+0x4c/0x68
watchdog/0 S 00000000 0 5 2 0x00000000
Call Trace:
[df84dee0] [c0009fc4] __switch_to+0x8c/0xf8
[df84df00] [c0350160] schedule+0x354/0x92c
[df84df90] [c006b8e8] watchdog+0x48/0x88
[df84dfb0] [c004d020] kthread+0x80/0x84
[df84dff0] [c00141a0] kernel_thread+0x4c/0x68
migration/1 S 00000000 0 6 2 0x00000000
Call Trace:
[df84fea0] [c0009fc4] __switch_to+0x8c/0xf8
[df84fec0] [c0350160] schedule+0x354/0x92c
[df84ff50] [c002d074] migration_thread+0x29c/0x448
[df84ffb0] [c004d020] kthread+0x80/0x84
[df84fff0] [c00141a0] kernel_thread+0x4c/0x68
ksoftirqd/1 S 00000000 0 7 2 0x00000000
Call Trace:
[df853ed0] [c0009fc4] __switch_to+0x8c/0xf8
[df853ef0] [c0350160] schedule+0x354/0x92c
[df853f80] [c0038454] run_ksoftirqd+0x14c/0x1e0
[df853fb0] [c004d020] kthread+0x80/0x84
[df853ff0] [c00141a0] kernel_thread+0x4c/0x68
watchdog/1 S 00000000 0 8 2 0x00000000
Call Trace:
[df857ee0] [c0009fc4] __switch_to+0x8c/0xf8
[df857f00] [c0350160] schedule+0x354/0x92c
[df857f90] [c006b8e8] watchdog+0x48/0x88
[df857fb0] [c004d020] kthread+0x80/0x84
[df857ff0] [c00141a0] kernel_thread+0x4c/0x68
events/0 S 00000000 0 9 2 0x00000000
Call Trace:
[df859ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df859ec0] [c0350160] schedule+0x354/0x92c
[df859f50] [c0048718] worker_thread+0x1fc/0x200
[df859fb0] [c004d020] kthread+0x80/0x84
[df859ff0] [c00141a0] kernel_thread+0x4c/0x68
events/1 S 00000000 0 10 2 0x00000000
Call Trace:
[df85bea0] [c0009fc4] __switch_to+0x8c/0xf8
[df85bec0] [c0350160] schedule+0x354/0x92c
[df85bf50] [c0048718] worker_thread+0x1fc/0x200
[df85bfb0] [c004d020] kthread+0x80/0x84
[df85bff0] [c00141a0] kernel_thread+0x4c/0x68
khelper S 00000000 0 11 2 0x00000000
Call Trace:
[df85dde0] [c0030564] do_fork+0x1b0/0x344 (unreliable)
[df85dea0] [c0009fc4] __switch_to+0x8c/0xf8
[df85dec0] [c0350160] schedule+0x354/0x92c
[df85df50] [c0048718] worker_thread+0x1fc/0x200
[df85dfb0] [c004d020] kthread+0x80/0x84
[df85dff0] [c00141a0] kernel_thread+0x4c/0x68
async/mgr S 00000000 0 15 2 0x00000000
Call Trace:
[df8a7df0] [000000fc] 0xfc (unreliable)
[df8a7eb0] [c0009fc4] __switch_to+0x8c/0xf8
[df8a7ed0] [c0350160] schedule+0x354/0x92c
[df8a7f60] [c00565c0] async_manager_thread+0x120/0x174
[df8a7fb0] [c004d020] kthread+0x80/0x84
[df8a7ff0] [c00141a0] kernel_thread+0x4c/0x68
sync_supers S 00000000 0 85 2 0x00000000
Call Trace:
[df951e30] [00000400] 0x400 (unreliable)
[df951ef0] [c0009fc4] __switch_to+0x8c/0xf8
[df951f10] [c0350160] schedule+0x354/0x92c
[df951fa0] [c008d714] bdi_sync_supers+0x30/0x5c
[df951fb0] [c004d020] kthread+0x80/0x84
[df951ff0] [c00141a0] kernel_thread+0x4c/0x68
bdi-default S 00000000 0 87 2 0x00000000
Call Trace:
[df957e30] [c0009fc4] __switch_to+0x8c/0xf8
[df957e50] [c0350160] schedule+0x354/0x92c
[df957ee0] [c0350b14] schedule_timeout+0x15c/0x23c
[df957f30] [c008e510] bdi_forker_task+0x2f8/0x30c
[df957fb0] [c004d020] kthread+0x80/0x84
[df957ff0] [c00141a0] kernel_thread+0x4c/0x68
kblockd/0 S 00000000 0 88 2 0x00000000
Call Trace:
[df8bdde0] [00000800] 0x800 (unreliable)
[df8bdea0] [c0009fc4] __switch_to+0x8c/0xf8
[df8bdec0] [c0350160] schedule+0x354/0x92c
[df8bdf50] [c0048718] worker_thread+0x1fc/0x200
[df8bdfb0] [c004d020] kthread+0x80/0x84
[df8bdff0] [c00141a0] kernel_thread+0x4c/0x68
kblockd/1 S 00000000 0 89 2 0x00000000
Call Trace:
[df959de0] [00000800] 0x800 (unreliable)
[df959ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df959ec0] [c0350160] schedule+0x354/0x92c
[df959f50] [c0048718] worker_thread+0x1fc/0x200
[df959fb0] [c004d020] kthread+0x80/0x84
[df959ff0] [c00141a0] kernel_thread+0x4c/0x68
rpciod/0 S 00000000 0 111 2 0x00000000
Call Trace:
[df93fea0] [c0009fc4] __switch_to+0x8c/0xf8
[df93fec0] [c0350160] schedule+0x354/0x92c
[df93ff50] [c0048718] worker_thread+0x1fc/0x200
[df93ffb0] [c004d020] kthread+0x80/0x84
[df93fff0] [c00141a0] kernel_thread+0x4c/0x68
rpciod/1 S 00000000 0 112 2 0x00000000
Call Trace:
[df931de0] [00000001] 0x1 (unreliable)
[df931ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df931ec0] [c0350160] schedule+0x354/0x92c
[df931f50] [c0048718] worker_thread+0x1fc/0x200
[df931fb0] [c004d020] kthread+0x80/0x84
[df931ff0] [c00141a0] kernel_thread+0x4c/0x68
khungtaskd S 00000000 0 141 2 0x00000000
Call Trace:
[df979db0] [00000800] 0x800 (unreliable)
[df979e70] [c0009fc4] __switch_to+0x8c/0xf8
[df979e90] [c0350160] schedule+0x354/0x92c
[df979f20] [c0350b14] schedule_timeout+0x15c/0x23c
[df979f70] [c006bd38] watchdog+0x98/0x294
[df979fb0] [c004d020] kthread+0x80/0x84
[df979ff0] [c00141a0] kernel_thread+0x4c/0x68
kswapd0 S 00000000 0 142 2 0x00000000
Call Trace:
[df97bd60] [c04383a0] 0xc04383a0 (unreliable)
[df97be20] [c0009fc4] __switch_to+0x8c/0xf8
[df97be40] [c0350160] schedule+0x354/0x92c
[df97bed0] [c00868a8] kswapd+0x81c/0x858
[df97bfb0] [c004d020] kthread+0x80/0x84
[df97bff0] [c00141a0] kernel_thread+0x4c/0x68
aio/0 S 00000000 0 143 2 0x00000000
Call Trace:
[df97dde0] [ffffffff] 0xffffffff (unreliable)
[df97dea0] [c0009fc4] __switch_to+0x8c/0xf8
[df97dec0] [c0350160] schedule+0x354/0x92c
[df97df50] [c0048718] worker_thread+0x1fc/0x200
[df97dfb0] [c004d020] kthread+0x80/0x84
[df97dff0] [c00141a0] kernel_thread+0x4c/0x68
aio/1 S 00000000 0 144 2 0x00000000
Call Trace:
[df97fde0] [ffffffff] 0xffffffff (unreliable)
[df97fea0] [c0009fc4] __switch_to+0x8c/0xf8
[df97fec0] [c0350160] schedule+0x354/0x92c
[df97ff50] [c0048718] worker_thread+0x1fc/0x200
[df97ffb0] [c004d020] kthread+0x80/0x84
[df97fff0] [c00141a0] kernel_thread+0x4c/0x68
nfsiod S 00000000 0 145 2 0x00000000
Call Trace:
[df9a5de0] [00000003] 0x3 (unreliable)
[df9a5ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df9a5ec0] [c0350160] schedule+0x354/0x92c
[df9a5f50] [c0048718] worker_thread+0x1fc/0x200
[df9a5fb0] [c004d020] kthread+0x80/0x84
[df9a5ff0] [c00141a0] kernel_thread+0x4c/0x68
crypto/0 S 00000000 0 146 2 0x00000000
Call Trace:
[df9a7de0] [00000800] 0x800 (unreliable)
[df9a7ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df9a7ec0] [c0350160] schedule+0x354/0x92c
[df9a7f50] [c0048718] worker_thread+0x1fc/0x200
[df9a7fb0] [c004d020] kthread+0x80/0x84
[df9a7ff0] [c00141a0] kernel_thread+0x4c/0x68
crypto/1 S 00000000 0 147 2 0x00000000
Call Trace:
[df9a9ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df9a9ec0] [c0350160] schedule+0x354/0x92c
[df9a9f50] [c0048718] worker_thread+0x1fc/0x200
[df9a9fb0] [c004d020] kthread+0x80/0x84
[df9a9ff0] [c00141a0] kernel_thread+0x4c/0x68
mtdblockd S 00000000 0 779 2 0x00000000
Call Trace:
[dfae1e00] [00000800] 0x800 (unreliable)
[dfae1ec0] [c0009fc4] __switch_to+0x8c/0xf8
[dfae1ee0] [c0350160] schedule+0x354/0x92c
[dfae1f70] [c02232dc] mtd_blktrans_thread+0x1c4/0x394
[dfae1fb0] [c004d020] kthread+0x80/0x84
[dfae1ff0] [c00141a0] kernel_thread+0x4c/0x68
kstriped S 00000000 0 826 2 0x00000000
Call Trace:
[df935de0] [00000800] 0x800 (unreliable)
[df935ea0] [c0009fc4] __switch_to+0x8c/0xf8
[df935ec0] [c0350160] schedule+0x354/0x92c
[df935f50] [c0048718] worker_thread+0x1fc/0x200
[df935fb0] [c004d020] kthread+0x80/0x84
[df935ff0] [c00141a0] kernel_thread+0x4c/0x68
ksnapd S 00000000 0 828 2 0x00000000
Call Trace:
[dfae9de0] [00000800] 0x800 (unreliable)
[dfae9ea0] [c0009fc4] __switch_to+0x8c/0xf8
[dfae9ec0] [c0350160] schedule+0x354/0x92c
[dfae9f50] [c0048718] worker_thread+0x1fc/0x200
[dfae9fb0] [c004d020] kthread+0x80/0x84
[dfae9ff0] [c00141a0] kernel_thread+0x4c/0x68
Sched Debug Version: v0.09, 2.6.33-00001-g8c31d07 #1
now at 35747.705693 msecs
.jiffies : 4294901234
.sysctl_sched_latency : 10.000000
.sysctl_sched_min_granularity : 2.000000
.sysctl_sched_wakeup_granularity : 2.000000
.sysctl_sched_child_runs_first : 0.000000
.sysctl_sched_features : 7917179
.sysctl_sched_tunable_scaling : 1 (logaritmic)
cpu#0
.nr_running : 0
.load : 0
.nr_switches : 2809
.nr_load_updates : 8950
.nr_uninterruptible : 1
.next_balance : 4294.901248
.curr->pid : 0
.clock : 35832.063536
.cpu_load[0] : 0
.cpu_load[1] : 0
.cpu_load[2] : 0
.cpu_load[3] : 0
.cpu_load[4] : 0
cfs_rq[0] for UID: 0
.exec_clock : 0.000000
.MIN_vruntime : 0.000001
.min_vruntime : 4129.195888
.max_vruntime : 0.000001
.spread : 0.000000
.spread0 : 4048.261385
.nr_running : 0
.load : 0
.nr_spread_over : 0
.shares : 0
.se->exec_start : 35836.116992
.se->vruntime : 80.934503
.se->sum_exec_runtime : 123.815984
.se->load.weight : 1024
rt_rq[0]:
.rt_nr_running : 0
.rt_throttled : 0
.rt_time : 0.000000
.rt_runtime : 950.000000
runnable tasks:
task PID tree-key switches prio exec-runtime
sum-exec sum-sleep
--------------------------------------------------------------------------------
--------------------------
cpu#1
.nr_running : 0
.load : 0
.nr_switches : 4069
.nr_load_updates : 8689
.nr_uninterruptible : 0
.next_balance : 4294.901019
.curr->pid : 0
.clock : 34909.104304
.cpu_load[0] : 0
.cpu_load[1] : 0
.cpu_load[2] : 0
.cpu_load[3] : 0
.cpu_load[4] : 0
cfs_rq[1] for UID: 0
.exec_clock : 0.000000
.MIN_vruntime : 0.000001
.min_vruntime : 509.424556
.max_vruntime : 0.000001
.spread : 0.000000
.spread0 : 428.490053
.nr_running : 0
.load : 0
.nr_spread_over : 0
.shares : 0
.se->exec_start : 34909.104304
.se->vruntime : 273.153007
.se->sum_exec_runtime : 503.971344
.se->load.weight : 1024
rt_rq[1]:
.rt_nr_running : 0
.rt_throttled : 0
.rt_time : 0.000000
.rt_runtime : 950.000000
runnable tasks:
task PID tree-key switches prio exec-runtime
sum-exec sum-sleep
--------------------------------------------------------------------------------
--------------------------
^ permalink raw reply
* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: Frederic Weisbecker @ 2010-02-26 17:52 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Mahesh Salgaonkar, Will Deacon, David Gibson, linuxppc-dev,
Alan Stern, paulus, Roland McGrath
In-Reply-To: <20100223105715.GA17358@in.ibm.com>
On Tue, Feb 23, 2010 at 04:27:15PM +0530, K.Prasad wrote:
> On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
> > On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
> > > On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
> [snipped]
> > > Also, do you think addr/len/type is enough to abstract out
> > > any ppc breakpoints?
> > >
> > > This looks enough to me to express range breakpoints and
> > > simple breakpoints. But what about value comparison?
> > > (And still, there may be other trickier implementations
> > > I don't know in ppc).
> > >
> >
> > The above implementation is for PPC64 architecture that supports only
> > 'simple' breakpoints of fixed length (no range breakpoints, no value
> > comparison). More on that below.
> >
>
> Looks like I forgot the 'more on that below' part :-)....here are some
> thoughts...
>
> Architectures like PPC Book-E have support for a variety of
> sophisticated debug features and our generic framework, in its present
> form, cannot easily port itself to these processors. In order to extend
> the framework for PPC Book-E, I intend the following to begin with:
>
> - Implement support for data breakpoints through DAC registers with all
> the 'bells and whistles'...support for instruction breakpoints through
> IAC can come in later (without precluding its use through ptrace).
>
> - Embed the flags/variables to store DVC, masked address mode, etc. in
> 'struct arch_hw_breakpoint', which will be populated by the user of
> register_breakpoint interface.
Agreed.
>
> Apart from the above extensions to the framework, changes in the generic
> code would be required as described in an earlier LKML mail (ref:
> message-id: 20091127190705.GB18408@in.ibm.com)....relevant contents
> pasted below:
>
> "I think the register_<> interfaces can become wrappers around functions
> that do the following:
>
> - arch_validate(): Validate request by invoking an arch-dependant
> routine. Proceed if returned valid.
> - arch-specific debugreg availability: Do something like
> if (arch_hw_breakpoint_availabile())
> bp = perf_event_create_kernel_counter();
This is already what does register_hw_break....(), it fails
if a slot is not available:
perf_event_create_kernel_counter -> perf_bp_init() -> reserve_bp_slot()
Having a:
if (arch_hw_breakpoint_availabile())
bp = perf_event_create_kernel_counter();
would be racy.
>
> perf_event_create_kernel_counter()--->arch_install_hw_breakpoint();
>
> This way, all book-keeping related work (no. of pinned/flexible/per-cpu)
> will be moved to arch-specific files (will be helpful for PPC Book-E
> implementation having two types of debug registers). Every new
> architecture that intends to port to the new hw-breakpoint
> implementation must define their arch_validate(),
> arch_hw_breakpoint_available() and an arch_install_hw_breakpoint(),
> while the hw-breakpoint code will be flexible enough to extend itself to
> each of these archs."
>
> Let me know what you think of the above.
We certainly need the slot reservation in arch (a part of it at least).
But we also need a kind of new interface for arch predefined attributes,
instead of generic attributes.
Probably we need a kind of perf_event_create_kernel_counter() that
can accept either a perf_event_attr (for perf syscall or ftrace)
and an arch structure that can be passed to the breakpoint API,
so that we don't need the generic translation.
>
> Thanks,
> K.Prasad
>
^ permalink raw reply
* Re: Does Linux 2.6.32 support NAND flash connect with MPC8247 through localbus with GPCM mode?
From: Scott Wood @ 2010-02-26 18:35 UTC (permalink / raw)
To: Peter Pan; +Cc: linuxppc-dev
In-Reply-To: <48abf2c21002251808v4d40ea42s869b1307dfc3817@mail.gmail.com>
On Fri, Feb 26, 2010 at 10:08:09AM +0800, Peter Pan wrote:
> I'm recently porting Linux 2.6.32 to our custom board with MPC8247. We have a
> NAND flash connected using GPCM mode of local bus. But after I search
> through the Linux
> source, there is no compatible like "fsl,gpcm-nand". And I can not
> find any driver
> that seems works for our scene.
There isn't one. I was not under the impression that such a configuration
was even possible (how do you control ALE/CLE, for example?). There is a
NAND driver that uses UPM, though -- perhaps you could use that?
How specifically is NAND connected to the SoC on your board? What about it
suggests GPCM?
-Scott
^ permalink raw reply
* Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?
From: Geoff Levand @ 2010-02-26 18:59 UTC (permalink / raw)
To: David Woodhouse
Cc: cbe-oss-dev@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org,
François Galea
In-Reply-To: <1267187451.30247.10776.camel@macbook.infradead.org>
Hi All,
On 02/26/2010 04:30 AM, David Woodhouse wrote:
> On Fri, 2009-08-21 at 09:58 -0700, geoffrey.levand@am.sony.com wrote:
>> The feature of "Install Other OS" was removed from the new
>> "Slim" PS3 model to focus on delivering games and other
>> entertainment content.
>>
>> Please be assured that SCE is committed to continue
>> the support for previously sold models that have the
>> "Install Other OS" feature and that this feature will
>> not be disabled in future firmware releases.
>
> Although it's disappointing that Sony have removed the feature from new
> models, It's good to have this public assurance from Sony that at least
> the feature won't be removed from older models which are already
> working.
Please understand that in my position as PS3-Linux maintainer
I can really only provide users with technical support for
Linux and the LV1 hcall interface.
The text above was provided to me by SCE management. If
you have any questions regarding it or any other feature
of the PS3 please contact the Playstation Customer Support
in your country. Using Playstation Customer Support will
insure your inquiry is processed through the correct
channels within SCE.
-Geoff
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Kumar Gala @ 2010-02-26 19:42 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <1267212301-26851-1-git-send-email-paul.gortmaker@windriver.com>
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
> chips seems to cause a short lived IRQ storm (/proc/interrupts
> typically shows somewhere between 300 and 1500 events). Unfortunately
> this renders SysRQ over the serial console completely inoperable.
> Testing with obvious things like ACKing the event doesn't seem to
> change anything vs. a completely dumb approach of just ignoring
> it and waiting for it to stop, so that is what is implemented here.
>=20
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>=20
> This is a refresh of a patch I'd done earlier -- I've tried to make
> the bug support as generic as possible to minimize having board
> specific ifdef crap in 8250.c -- any suggestions on how to further
> improve it are welcome.
>=20
> drivers/serial/8250.c | 6 ++++++
> drivers/serial/8250.h | 20 ++++++++++++++++++++
> drivers/serial/Kconfig | 14 ++++++++++++++
> include/linux/serial_reg.h | 2 ++
> 4 files changed, 42 insertions(+), 0 deletions(-)
>=20
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index e9b15c3..850b0e9 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct =
uart_8250_port *up)
>=20
> status =3D serial_inp(up, UART_LSR);
>=20
> + if ((up->bugs & UART_BUG_PPC) && (status =3D=3D =
UART_LSR_RFE_ERROR_BITS)) {
> + spin_unlock_irqrestore(&up->port.lock, flags);
> + return;
> + }
> +
> DEBUG_INTR("status =3D %x...", status);
>=20
> if (status & (UART_LSR_DR | UART_LSR_BI))
> @@ -1948,6 +1953,7 @@ static int serial8250_startup(struct uart_port =
*port)
>=20
> up->capabilities =3D uart_config[up->port.type].flags;
> up->mcr =3D 0;
> + up->bugs |=3D UART_KNOWN_BUGS;
>=20
> if (up->port.iotype !=3D up->cur_iotype)
> set_io_from_upio(port);
> diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h
> index 6e19ea3..2074ce1 100644
> --- a/drivers/serial/8250.h
> +++ b/drivers/serial/8250.h
> @@ -49,6 +49,7 @@ struct serial8250_config {
> #define UART_BUG_TXEN (1 << 1) /* UART has buggy TX IIR status =
*/
> #define UART_BUG_NOMSR (1 << 2) /* UART has buggy MSR =
status bits (Au1x00) */
> #define UART_BUG_THRE (1 << 3) /* UART has buggy THRE =
reassertion */
> +#define UART_BUG_PPC (1 << 4) /* UART has buggy PPC break IRQ =
storm */
>=20
> #define PROBE_RSA (1 << 0)
> #define PROBE_ANY (~0)
> @@ -78,3 +79,22 @@ struct serial8250_config {
> #else
> #define ALPHA_KLUDGE_MCR 0
> #endif
> +
> +/*
> + * The following UART bugs are currently dynamically detected and not
> + * required to be contingent on any particular compile time options.
> + */
> +#define HAS_BUG_QUOT 0 /* assign UART_BUG_QUOT to enable */
> +#define HAS_BUG_TXEN 0 /* assign UART_BUG_TXEN to enable */
> +#define HAS_BUG_NOMSR 0 /* assign UART_BUG_NOMSR to =
enable */
> +#define HAS_BUG_THRE 0 /* assign UART_BUG_THRE to enable */
> +
> +#ifdef CONFIG_SERIAL_8250_PPC_BUG
> +#define HAS_BUG_PPC UART_BUG_PPC
> +#else
> +#define HAS_BUG_PPC 0
> +#endif
> +
> +#define UART_KNOWN_BUGS (HAS_BUG_QUOT | HAS_BUG_TXEN | HAS_BUG_NOMSR =
| \
> + HAS_BUG_THRE | HAS_BUG_PPC)
> +
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 9ff47db..e01a411 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -70,6 +70,20 @@ config SERIAL_8250_CONSOLE
>=20
> If unsure, say N.
>=20
> +config SERIAL_8250_PPC_BUG
> + bool "Fix 8250/16550 to handle IRQ storm after receipt of a =
break"
> + depends on SERIAL_8250 && PPC32
> + ---help---
> + If you say Y here, addional checks will be added in the =
handling of
> + interrupts on the serial ports which will prevent ill effects =
of
> + an interrupt storm triggered by a break on the serial line. =
Without
> + this enabled, a Sysrq via the serial console can be unusable =
on
> + some systems.
> +
> + This is commonly observed on PPC32 MPC83xx/85xx/86xx based =
boards.
> +
> + If unsure, say N.
> +
is there harm caused if we have SERIAL_8250_PPC_BUG set and dont need =
it?
- k=
^ permalink raw reply
* Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Scott Wood @ 2010-02-26 19:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1267172983-28721-2-git-send-email-Joakim.Tjernlund@transmode.se>
On Fri, Feb 26, 2010 at 09:29:40AM +0100, Joakim Tjernlund wrote:
> This removes a couple of insn's from the TLB Miss
> handlers whithout changing functionality.
> ---
Did a quick test of the patchset, seems to work OK (without CONFIG_SWAP or
CONFIG_MODULES). Didn't try with CONFIG_8xx_CPU6.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Kumar Gala @ 2010-02-26 20:10 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1267172983-28721-2-git-send-email-Joakim.Tjernlund@transmode.se>
On Feb 26, 2010, at 2:29 AM, Joakim Tjernlund wrote:
> li r11, 0x00f0
> - rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
> + rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
> DO_8xx_CPU6(0x2d80, r3)
> mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
Cool, didn't know 'as' supported this notation.
- k
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
From: Anatolij Gustschin @ 2010-02-26 20:18 UTC (permalink / raw)
To: David Miller; +Cc: wd, dzu, netdev, linuxppc-dev
In-Reply-To: <20100222.034452.193720264.davem@davemloft.net>
Hi David,
On Mon, 22 Feb 2010 03:44:52 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Anatolij Gustschin <agust@denx.de>
> Date: Mon, 22 Feb 2010 12:37:24 +0100
>
> > Could you please comment on this patch series.
>
> It's in the net-next-2.6 tree.
>
> If you need to make any more changes, they need to be relative
> to what went into my tree.
I've pulled your net-next-2.6 tree again and I don't see them
in net-next-2.6 tree. Could you please check it again. Thanks!
Anatolij
^ permalink raw reply
* RE: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
From: Bounine, Alexandre @ 2010-02-26 20:20 UTC (permalink / raw)
To: Micha Nelissen
Cc: Alexandre Bounine, linux-kernel, thomas.moll, linuxppc-dev,
thomas.moll.ext
In-Reply-To: <4B86E572.6090101@neli.hopto.org>
Micha Nelissen wrote:
> Bounine, Alexandre wrote:
> > Micha Nelissen wrote:
> >> Alexandre Bounine wrote:
> >>> /**
> >>> + * rio_em_set_ops- Sets Error Managment operations for a
particular
> > vendor switch
> >>> + * @rdev: RIO device
> >>> + *
> >>> + * Searches the RIO EM ops table for known switch types. If the
vid
> >>> + * and did match a switch table entry, then set the em_init() and
> >>> + * em_handle() ops to the table entry values.
> >> Shouldn't any RIO device be able to support error management, not
just
> >> switches?
> >
> > Only if a device reports this capability by having Error Management
> > Extended Features block.
> > Ideally, we have to provide default handler for every such device (I
am
> > planning it for some future updates). It should be the same as for
> > routing operations - if the standard feature exists, it has to be
used
> > unless something else takes over.
>=20
> Yes, therefore I thought that: or the EM_OPS are per driver, or they
can
> be integrated in the switch hooks list.
Or combination of both methods as I implemented it. I want to have it
flexible enough to be adopted to further development of RapidIO
ecosystem. =20
=20
> > For now I keep all port-write messages from end-points serviced by
their
> > individual drivers. One of reasons for this: the EM PW message
format
>=20
> Maybe have a generic rio function that can be called by any driver
that
> knows a particular port-write was due to error management causes? This
> function would read the standard defined EF block registers. Then the
> driver part can be quite small.
I think this echoes what I mentioned above as default handler.
>=20
> >>> + if (port->ops->pwenable)
> >>> + port->ops->pwenable(port, enable);
> >>> +}
> >>> +
> >> Maybe this can be done by switch->init function?
> >
> > This is not per-switch function. This function enables mport to
receive
> > incoming PW messages. Per-switch PW enable is done in switch->init
as
> > for Tsi57x.
>=20
> Oops, I meant this comment for the em_init function call.
>=20
> >>> + rio_mport_write_config_32(mport, destid,
> > hopcount,
> >>> + rdev->phys_efptr +
> >>> + RIO_PORT_N_ACK_STS_CSR(portnum),
> >>> + RIO_PORT_N_ACK_CLEAR);
> >> This doesn't work for the 568; but the 568 has no special handling?
> >
> > Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its
> > em_init().
>=20
> Why?
Because Tsi568 requires special handling which is not implemented
(yet?).=20
=20
>=20
> >>> +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578,
tsi57x_em_init,
> > tsi57x_em_handler);
> >> Why not declare these along with the other ops?
> >
> > Because the EM extensions is a separate capability. It is not
guaranteed
> > to be in every switch.
>=20
> They might initialize them with NULL to indicate they don't support
it?
My preference is to keep unrelated capabilities separately. Otherwise,
these long ops lists may become unmanageable later when new extensions
will be added into RIO spec.
Cheers,
Alex.
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Paul Gortmaker @ 2010-02-26 20:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <EB2B2912-24C3-46C9-B894-0A84D593570F@kernel.crashing.org>
On 10-02-26 02:42 PM, Kumar Gala wrote:
>
> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>
[...]
>>
>> + if ((up->bugs& UART_BUG_PPC)&& (status == UART_LSR_RFE_ERROR_BITS)) {
>> + spin_unlock_irqrestore(&up->port.lock, flags);
>> + return;
>> + }
>> +
[...]
>
> is there harm caused if we have SERIAL_8250_PPC_BUG set and dont need it?
In theory, no -- strip away all the window dressing and we are
left with the above change. So, you'd have to have some UART
implementation that was setting those bits and still relying
on its interrupt event to be processed normally. But since
there are so many different 8250 implementations out there,
I was being cautious and taking the absolute safe approach.
P.
>
> - k
^ 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