linuxsh-dev

a synonym problem

[Hideo S. <sa...@de...>]

Hi, I am H.Saito.

It seems that a synonym problem issues on linux-2.6.20 for SH4.
The problem is that some virtual addresses are mapped onto a single physical address as follows. The following log is our debugger's log when broke at line 257 in fs/binfmt_elf.c.

#d 8eab33c0
   LOC.     0         4         8         c              ASCII-CODE
----------------------------------------------------------------------
8eab 33c0 : 3334 3330 3030 3000 3030 3030 0034 3433 / 0343.0000000344.
8eab 33d0 : 3030 3030 3330 3030 3000 3534 3030 3030 / 0000000345.00000
8eab 33e0 : 3433 3030 3030 0036 3030 3030 3734 3330 / 00346.0000000347
8eab 33f0 : 3030 3000 3030 3030 0038 3433 3030 3030 / .0000000348.0000
8eab 3400 : 3330 3030 3000 3934 3030 3030 3533 3030 / 000349.000000035
8eab 3410 : 3030 0030 3030 3030 3135 3330 3030 3000 / 0.0000000351.000
8eab 3420 : 3030 3030 0032 3533 3030 3030 3330 3030 / 0000352.00000003
8eab 3430 : 3000 3335 3030 3030 3533 3030 3030 0034 / 53.0000000354.00
#d 7bd823c0
   LOC.     0         4         8         c              ASCII-CODE
----------------------------------------------------------------------
7bd8 23c0 : 0000 0000 0000 0000 0000 0000 0000 0000 / ................
7bd8 23d0 : 0000 0000 0000 0000 0000 0000 0000 0000 / ................
7bd8 23e0 : 3433 3030 3030 0036 3030 3030 3734 3330 / 00346.0000000347
7bd8 23f0 : 3030 3000 3030 3030 0038 3433 3030 3030 / .0000000348.0000
7bd8 2400 : 3330 3030 3000 3934 3030 3030 3533 3030 / 000349.000000035
7bd8 2410 : 3030 0030 3030 3030 3135 3330 3030 3000 / 0.0000000351.000
7bd8 2420 : 3030 3030 0032 3533 3030 3030 3330 3030 / 0000352.00000003
7bd8 2430 : 3000 3335 3030 3030 3533 3030 3030 0034 / 53.0000000354.00
#s f40053c0
f400 53c0 : 4eab 3003 
#s f40043c0
f400 43c0 : 4eab 3001 

OC address array for 0x8eab33c0 is 0xf40053c0 on way2.
OC address array for 0x7bd823c0 is 0xf40043c0 on way2.
The physical memory area is in from 0x48000000 to 0x48ffffff.

The cached data line on 0x7bd823c0 can not be read because the data line on 0x8eab33c0 is not moved to the physical address yet.

This problem is caused when a process is executed after vfork. In the result, the executed process can not read the arguments correctly.

I think that the copied arguments from parent process should be copied back to the physical memory as following patch, in other words, a mapped page to process should be copied back to the physical memory unconditionally.

--- fs/exec.c.org       Mon Feb  5 03:44:54 2007
+++ fs/exec.c   Sat Feb 17 17:54:53 2007
@@ -308,17 +308,21 @@ void install_arg_page(struct vm_area_str
 {
        struct mm_struct *mm = vma->vm_mm;
        pte_t * pte;
        spinlock_t *ptl;
 
        if (unlikely(anon_vma_prepare(vma)))
                goto out;
 
+#if 0
        flush_dcache_page(page);
+#else
+       __flush_wback_region((void *)P1SEGADDR(PHYSADDR(page_address(page))), PA
GE_SIZE);
+#endif
        pte = get_locked_pte(mm, address, &ptl);
        if (!pte)
                goto out;
        if (!pte_none(*pte)) {
                pte_unmap_unlock(pte, ptl);
                goto out;
        }
        inc_mm_counter(mm, anon_rss);

Re: Why flush cache in insw/outsw ?

[Paul M. <le...@li...>]

On Tue, Feb 20, 2007 at 07:35:46AM +0900, tak...@op... wrote:
> > You may want to add a sensible definition for SH-3 as well, but I'm not
> > sure how heavily you're hitting the libata drivers.
> mmm, Because I don't have SH3 board with libata enabled, I'd like to leave it blank now.

You aren't booting off of CF or PCMCIA with pata_platform?

> How about following patch? I put them into io_generic.c near
> insw/outsw, but cache_flush.h, since these seems a kind of workaround.
> # SH3/4 compatible cache flush API may be wanted in somewhere else,
> someday, though.
> 
Yes, we can do that. It would be interesting to know if the SH-3 caches
will need this too, at the very least, SH7705 will.

Iwamatsu-san, are you able to add shmin in to your build scripts? It
would be good to get at least one SH-3 (and an SH-2) in to the nightly
builds.

Re: Why flush cache in insw/outsw ?

[<tak...@op...>]

Thank you, Paul.

> We needed these for some of the IDE cases, it was something that was hit
> in the PG_dcache_dirty conversion. <snip>
Oh, that's exactly what I guess. Happy.

> You may want to add a sensible definition for SH-3 as well, but I'm not
> sure how heavily you're hitting the libata drivers.
mmm, Because I don't have SH3 board with libata enabled, I'd like to leave it blank now.
How about following patch? I put them into io_generic.c near insw/outsw, but cache_flush.h,
 since these seems a kind of workaround.
# SH3/4 compatible cache flush API may be wanted in somewhere else, someday, though.

Regards,
/yoshii
# sorry for trivial patches always...

Signed-off-by: Takashi YOSHII <tak...@op...>

diff --git a/arch/sh/kernel/io_generic.c b/arch/sh/kernel/io_generic.c
index 66626c0..7893718 100644
--- a/arch/sh/kernel/io_generic.c
+++ b/arch/sh/kernel/io_generic.c
@@ -25,6 +25,13 @@ #else
 #define dummy_read()
 #endif
 
+#if defined(CONFIG_CPU_SH4)
+/* We need these for some of the IDE cases. */
+#define flush_cache()	flush_dcache_all()
+#else
+#define flush_cache()	/* XXX: flushing might be needed */
+#endif
+
 unsigned long generic_io_base;
 
 static inline void delay(void)
@@ -96,7 +103,7 @@ void generic_insw(unsigned long port, vo
 	while (count--)
 		*buf++ = *port_addr;
 
-	flush_dcache_all();
+	flush_cache();
 	dummy_read();
 }
 
@@ -171,7 +178,7 @@ void generic_outsw(unsigned long port, c
 	while (count--)
 		*port_addr = *buf++;
 
-	flush_dcache_all();
+	flush_cache();
 	dummy_read();
 }
 

Re: Why flush cache in insw/outsw ?

[Paul M. <le...@li...>]

On Mon, Feb 19, 2007 at 11:38:15PM +0900, tak...@op... wrote:
> Currently, shmin can't compiled because of flush_dcache_all() in io_generic.c.
> SH3 doesn't have flush_"d"cache_all().

Ah, that's right, I forgot to stub it for SH-3.

> Could you please tell me why the flush operations has come here?
> Adding dummy flush_dcache_all() in cache_flush.h is easy, though.

We needed these for some of the IDE cases, it was something that was hit
in the PG_dcache_dirty conversion. We used to do this in the CONFIG_IDE
case by overloading the PIO I/O ops with an explicit flush, but that sort
of infrastructure no longer exists with libata. As the IDE code is really
the only user of the insw/outsw routines, this was the easy place to add
it.

You may want to add a sensible definition for SH-3 as well, but I'm not
sure how heavily you're hitting the libata drivers.

Why flush cache in insw/outsw ?

[<tak...@op...>]

Currently, shmin can't compiled because of flush_dcache_all() in io_generic.c.
SH3 doesn't have flush_"d"cache_all().
Could you please tell me why the flush operations has come here?
Adding dummy flush_dcache_all() in cache_flush.h is easy, though.
/yoshii

cg-diff -pr 9c57548f17806ffd8e4dc4f7973ce78bbfbc2079 arch/sh/kernel/io_generic.c
...
> @@ -96,6 +96,7 @@ void generic_insw(unsigned long port, vo
>         while (count--)
>                 *buf++ = *port_addr;
>  
> +       flush_dcache_all();
>         dummy_read();
>  }
>  
> @@ -170,6 +171,7 @@ void generic_outsw(unsigned long port, c
>         while (count--)
>                 *port_addr = *buf++;
>  
> +       flush_dcache_all();
>         dummy_read();
>  }

Re: [PATCH] kmap: SH-4 user page copy/clear overhaul

[Paul M. <le...@li...>]

Iwamatsu-san,

On Sat, Feb 17, 2007 at 02:50:16PM +0900, Nobuhiro Iwamatsu wrote:
> On Wed, 7 Feb 2007 21:23:06 +0900
> Paul Mundt <pau...@re...> wrote:
> > This introduces the first attempt at overhauling the user page copy/clear
> > interface for the aliasing VIPT cases (only SH-4 and SH-4A right now,
> > SH7705 should be able to use it directly, though, when in 32k cache mode).
> > 
> I m checking this patch on Solution Engine 7750 and LANTANK( 7751R ) and sh-min( 7706 ).
> I confirmed the kernel and the user land worked on Solution Engine 7750. 
> And I m testing in the environment of 7751R now. 
> 
It's not likely to have any effect on shmin given that it's SH-4
specific. I don't recall offhand if SH7706 includes extended aliasing
caches like SH7705 or not, but these patches can easily be extended as a
more generic solution to handle those cases too.

> BTW , I want to be doing this test adequately. Is there something a good idea?
> I checked start of the kernel and LTP on the user land where busybox was used , now .
> 
I'd be interested in various workloads, anything that stresses these
particular routines is of course of the most interest (you can use basic
profiling with readprofile to see which workloads end up being heavier in
this area than others).

Jamie suggested offlist that the busybox syslogd in IPC buffer mode is
something that accomplishes this, but I've not been able to reproduce his
problems yet on any of my boards.

Re: [PATCH] kmap: SH-4 user page copy/clear overhaul

[Nobuhiro I. <he...@t-...>]

Hi , Paul.

On Wed, 7 Feb 2007 21:23:06 +0900
Paul Mundt <pau...@re...> wrote:

> This introduces the first attempt at overhauling the user page copy/clear
> interface for the aliasing VIPT cases (only SH-4 and SH-4A right now,
> SH7705 should be able to use it directly, though, when in 32k cache mode).
> 
snip
> 
> I'll queue this for 2.6.21 unless someone manages to break it. Against
> current git, but should apply to 2.6.20 too.
> 


Sorry, I'm sorry I'm late.
I report on the current state for the time being. 

I m checking this patch on Solution Engine 7750 and LANTANK( 7751R ) and sh-min( 7706 ).
I confirmed the kernel and the user land worked on Solution Engine 7750. 
And I m testing in the environment of 7751R now. 

I report as soon as the result of this test comes out. 

BTW , I want to be doing this test adequately. Is there something a good idea?
I checked start of the kernel and LTP on the user land where busybox was used , now .

regards 
 Nobuhiro.

-- 
Nobuhiro Iwamatsu
	E-Mail : he...@t-...
	GPG ID : 3170EBE9 

Re: 2.6.20 instability

[Paul M. <le...@li...>]

On Tue, Feb 13, 2007 at 10:46:42AM +0100, Manuel Lauss wrote:
> On Fri, Feb 09, 2007 at 08:46:53PM +0900, Paul Mundt wrote:
> > On Fri, Feb 09, 2007 at 12:38:41PM +0100, Manuel Lauss wrote:
> > > On Fri, Feb 09, 2007 at 07:23:16PM +0900, Paul Mundt wrote:
> > > > Once you've pre-faulted the page, please try to dump the whole page
> > > > and see if it manages to blow up at that same location. You can setup the
> > > > translation with:
> > > > 
> > > > 	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
> > > > 	update_mmu_cache(NULL, 0xc0600000, entry);
> > > 
> > > Inserted this after the p3_ioremap() call; still oopsing at the same
> > > address.
> > > 
> > > The oops is triggered at drivers/net/pcmcia/pcnet_cs::get_hwinfo(),
> > > by the first readb().
> > >  
> > That makes me suspect that we're doing something evil to PTEA. Can you
> > try reverting the fast-path TLB miss handler (may need a bit of
> > munging..)?
> 
> Sorry for the late reply;
> Vanilla 2.6.20 with the TLB miss handler fast path reverted
> looks ok. Kernel survives 100+ insert/ejects of the pcnet_cs
> card just fine, also with the (default) 4MB memory windows.
> 
> Thanks!
> 
That's what I was afraid of. I've hit a few other problems with it as
well, so I think the right thing to do for now is to simply revert it. We
can toss it back in once it's recieved some more testing, since the
fast-path bits are quite small on their own.

It might also be worth checking the __do_page_fault() ->
update_mmu_cache() path for PG_dcache_dirty tests that might be causing
PTEA problems, but this is obviously something that needs to be looked
at more closely, especially for the legacy parts.

Thanks for the exhaustive testing!

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Fri, Feb 09, 2007 at 08:46:53PM +0900, Paul Mundt wrote:
> On Fri, Feb 09, 2007 at 12:38:41PM +0100, Manuel Lauss wrote:
> > On Fri, Feb 09, 2007 at 07:23:16PM +0900, Paul Mundt wrote:
> > > Once you've pre-faulted the page, please try to dump the whole page
> > > and see if it manages to blow up at that same location. You can setup the
> > > translation with:
> > > 
> > > 	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
> > > 	update_mmu_cache(NULL, 0xc0600000, entry);
> > 
> > Inserted this after the p3_ioremap() call; still oopsing at the same
> > address.
> > 
> > The oops is triggered at drivers/net/pcmcia/pcnet_cs::get_hwinfo(),
> > by the first readb().
> >  
> That makes me suspect that we're doing something evil to PTEA. Can you
> try reverting the fast-path TLB miss handler (may need a bit of
> munging..)?

Sorry for the late reply;
Vanilla 2.6.20 with the TLB miss handler fast path reverted
looks ok. Kernel survives 100+ insert/ejects of the pcnet_cs
card just fine, also with the (default) 4MB memory windows.

Thanks!

-- 
 ml.

Re: 2.6.20 instability

[Paul M. <pau...@re...>]

On Fri, Feb 09, 2007 at 12:38:41PM +0100, Manuel Lauss wrote:
> On Fri, Feb 09, 2007 at 07:23:16PM +0900, Paul Mundt wrote:
> > Once you've pre-faulted the page, please try to dump the whole page
> > and see if it manages to blow up at that same location. You can setup the
> > translation with:
> > 
> > 	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
> > 	update_mmu_cache(NULL, 0xc0600000, entry);
> 
> Inserted this after the p3_ioremap() call; still oopsing at the same
> address.
> 
> The oops is triggered at drivers/net/pcmcia/pcnet_cs::get_hwinfo(),
> by the first readb().
>  
That makes me suspect that we're doing something evil to PTEA. Can you
try reverting the fast-path TLB miss handler (may need a bit of
munging..)?

commit 9b3a53ab76771e3669e50086c131e1574fe25847
Author: Stuart Menefy <stu...@st...>
Date:   Fri Nov 24 11:42:24 2006 +0900

    sh: TLB miss fast-path optimizations.
    
    Handle simple TLB miss faults which can be resolved completely
    from the page table in assembler.
    
    Signed-off-by: Stuart Menefy <stu...@st...>
    Signed-off-by: Paul Mundt <le...@li...>

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index a03f155..48308dc 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -379,6 +379,9 @@ config CPU_HAS_SR_RB
 	  See <file:Documentation/sh/register-banks.txt> for further
 	  information on SR.RB and register banking in the kernel in general.
 
+config CPU_HAS_PTEA
+	bool
+
 endmenu
 
 menu "Timer support"
diff --git a/arch/sh/kernel/cpu/sh3/entry.S b/arch/sh/kernel/cpu/sh3/entry.S
index 869d56f..5de99b4 100644
--- a/arch/sh/kernel/cpu/sh3/entry.S
+++ b/arch/sh/kernel/cpu/sh3/entry.S
@@ -13,8 +13,10 @@
 #include <linux/linkage.h>
 #include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
-#include <asm/cpu/mmu_context.h>
 #include <asm/unistd.h>
+#include <asm/cpu/mmu_context.h>
+#include <asm/pgtable.h>
+#include <asm/page.h>
 
 ! NOTE:
 ! GNU as (as of 2.9.1) changes bf/s into bt/s and bra, when the address
@@ -136,29 +138,14 @@ ENTRY(tlb_protection_violation_store)
 
 call_dpf:
 	mov.l	1f, r0
-	mov	r5, r8
-	mov.l	@r0, r6
-	mov	r6, r9
-	mov.l	2f, r0
-	sts	pr, r10
-	jsr	@r0
-	 mov	r15, r4
-	!
-	tst	r0, r0
-	bf/s	0f
-	 lds	r10, pr
-	rts
-	 nop
-0:	sti
+ 	mov.l	@r0, r6		! address
 	mov.l	3f, r0
-	mov	r9, r6
-	mov	r8, r5
+	sti
 	jmp	@r0
-	 mov	r15, r4
+ 	 mov	r15, r4		! regs
 
 	.align 2
 1:	.long	MMU_TEA
-2:	.long	__do_page_fault
 3:	.long	do_page_fault
 
 	.align	2
@@ -344,9 +331,176 @@ general_exception:
 2:	.long	ret_from_exception
 !
 !
+
+/* This code makes some assumptions to improve performance.
+ * Make sure they are stil true. */
+#if PTRS_PER_PGD != PTRS_PER_PTE
+#error PDG and PTE sizes don't match
+#endif
+
+/* gas doesn't flag impossible values for mov #immediate as an error */
+#if (_PAGE_PRESENT >> 2) > 0x7f
+#error cannot load PAGE_PRESENT as an immediate
+#endif
+#if _PAGE_DIRTY > 0x7f
+#error cannot load PAGE_DIRTY as an immediate
+#endif
+#if (_PAGE_PRESENT << 2) != _PAGE_ACCESSED
+#error cannot derive PAGE_ACCESSED from PAGE_PRESENT
+#endif
+
+#if defined(CONFIG_CPU_SH4)
+#define ldmmupteh(r)	mov.l	8f, r
+#else
+#define ldmmupteh(r)	mov	#MMU_PTEH, r
+#endif
+
 	.balign 	1024,0,1024
 tlb_miss:
-	mov.l	1f, k2
+#ifdef COUNT_EXCEPTIONS
+	! Increment the counts
+	mov.l	9f, k1
+	mov.l	@k1, k2
+	add	#1, k2
+	mov.l	k2, @k1
+#endif
+
+	! k0 scratch
+	! k1 pgd and pte pointers
+	! k2 faulting address
+	! k3 pgd and pte index masks
+	! k4 shift
+
+	! Load up the pgd entry (k1)
+
+	ldmmupteh(k0)			!  9 LS (latency=2)	MMU_PTEH
+
+	mov.w	4f, k3			!  8 LS (latency=2)	(PTRS_PER_PGD-1) << 2
+	mov	#-(PGDIR_SHIFT-2), k4	!  6 EX
+
+	mov.l	@(MMU_TEA-MMU_PTEH,k0), k2	! 18 LS (latency=2)
+
+	mov.l	@(MMU_TTB-MMU_PTEH,k0), k1	! 18 LS (latency=2)
+
+	mov	k2, k0			!   5 MT (latency=0)
+	shld	k4, k0			!  99 EX
+
+	and	k3, k0			!  78 EX
+
+	mov.l	@(k0, k1), k1		!  21 LS (latency=2)
+	mov	#-(PAGE_SHIFT-2), k4	!   6 EX
+
+	! Load up the pte entry (k2)
+
+	mov	k2, k0			!   5 MT (latency=0)
+	shld	k4, k0			!  99 EX
+
+	tst	k1, k1			!  86 MT
+
+	bt	20f			! 110 BR
+
+	and	k3, k0			!  78 EX
+	mov.w	5f, k4			!   8 LS (latency=2)	_PAGE_PRESENT
+
+	mov.l	@(k0, k1), k2		!  21 LS (latency=2)
+	add	k0, k1			!  49 EX
+
+#ifdef CONFIG_CPU_HAS_PTEA
+	! Test the entry for present and _PAGE_ACCESSED
+
+	mov	#-28, k3		!   6 EX
+	mov	k2, k0			!   5 MT (latency=0)
+
+	tst	k4, k2			!  68 MT
+	shld	k3, k0			!  99 EX
+
+	bt	20f			! 110 BR
+
+	! Set PTEA register
+	! MMU_PTEA = ((pteval >> 28) & 0xe) | (pteval & 0x1)
+	!
+	! k0=pte>>28, k1=pte*, k2=pte, k3=<unused>, k4=_PAGE_PRESENT
+
+	and	#0xe, k0		!  79 EX
+
+	mov	k0, k3			!   5 MT (latency=0)
+	mov	k2, k0			!   5 MT (latency=0)
+
+	and	#1, k0			!  79 EX
+
+	or	k0, k3			!  82 EX
+
+	ldmmupteh(k0)			!   9 LS (latency=2)
+	shll2	k4			! 101 EX		_PAGE_ACCESSED
+
+	tst	k4, k2			!  68 MT
+
+	mov.l	k3, @(MMU_PTEA-MMU_PTEH,k0)	! 27 LS
+
+	mov.l	7f, k3			!   9 LS (latency=2)	_PAGE_FLAGS_HARDWARE_MASK
+
+	! k0=MMU_PTEH, k1=pte*, k2=pte, k3=_PAGE_FLAGS_HARDWARE, k4=_PAGE_ACCESSED
+#else
+
+	! Test the entry for present and _PAGE_ACCESSED
+
+	mov.l	7f, k3			!   9 LS (latency=2)	_PAGE_FLAGS_HARDWARE_MASK
+	tst	k4, k2			!  68 MT
+
+	shll2	k4			! 101 EX		_PAGE_ACCESSED
+	ldmmupteh(k0)			!   9 LS (latency=2)
+
+	bt	20f			! 110 BR
+	tst	k4, k2			!  68 MT
+
+	! k0=MMU_PTEH, k1=pte*, k2=pte, k3=_PAGE_FLAGS_HARDWARE, k4=_PAGE_ACCESSED
+
+#endif
+
+	! Set up the entry
+
+	and	k2, k3			!  78 EX
+	bt/s	10f			! 108 BR
+
+	 mov.l	k3, @(MMU_PTEL-MMU_PTEH,k0)	! 27 LS
+
+	ldtlb				! 128 CO
+
+	! At least one instruction between ldtlb and rte
+	nop				! 119 NOP
+
+	rte				! 126 CO
+
+	 nop				! 119 NOP
+
+
+10:	or	k4, k2			!  82 EX
+
+	ldtlb				! 128 CO
+
+	! At least one instruction between ldtlb and rte
+	mov.l	k2, @k1			!  27 LS
+
+	rte				! 126 CO
+
+	! Note we cannot execute mov here, because it is executed after
+	! restoring SSR, so would be executed in user space.
+	 nop				! 119 NOP
+
+
+	.align 5
+	! Once cache line if possible...
+1:	.long	swapper_pg_dir
+4:	.short	(PTRS_PER_PGD-1) << 2
+5:	.short	_PAGE_PRESENT
+7:	.long	_PAGE_FLAGS_HARDWARE_MASK
+8:	.long	MMU_PTEH
+#ifdef COUNT_EXCEPTIONS
+9:	.long	exception_count_miss
+#endif
+
+	! Either pgd or pte not present
+20:	mov.l	1f, k2
 	mov.l	4f, k3
 	bra	handle_exception
 	 mov.l	@k2, k2
@@ -496,6 +650,15 @@ skip_save:
 	bf	interrupt_exception
 	shlr2	r8
 	shlr	r8
+
+#ifdef COUNT_EXCEPTIONS
+	mov.l	5f, r9
+	add	r8, r9
+	mov.l	@r9, r10
+	add	#1, r10
+	mov.l	r10, @r9
+#endif
+
 	mov.l	4f, r9
 	add	r8, r9
 	mov.l	@r9, r9
@@ -509,6 +672,9 @@ skip_save:
 2:	.long	0x000080f0	! FD=1, IMASK=15
 3:	.long	0xcfffffff	! RB=0, BL=0
 4:	.long	exception_handling_table
+#ifdef COUNT_EXCEPTIONS
+5:	.long	exception_count_table
+#endif
 
 interrupt_exception:
 	mov.l	1f, r9
diff --git a/arch/sh/kernel/cpu/sh4/probe.c b/arch/sh/kernel/cpu/sh4/probe.c
index c294de1..afe0f1b 100644
--- a/arch/sh/kernel/cpu/sh4/probe.c
+++ b/arch/sh/kernel/cpu/sh4/probe.c
@@ -79,16 +79,16 @@ int __init detect_cpu_and_cache_system(void)
 	case 0x205:
 		cpu_data->type = CPU_SH7750;
 		cpu_data->flags |= CPU_HAS_P2_FLUSH_BUG | CPU_HAS_FPU |
-				   CPU_HAS_PERF_COUNTER | CPU_HAS_PTEA;
+				   CPU_HAS_PERF_COUNTER;
 		break;
 	case 0x206:
 		cpu_data->type = CPU_SH7750S;
 		cpu_data->flags |= CPU_HAS_P2_FLUSH_BUG | CPU_HAS_FPU |
-				   CPU_HAS_PERF_COUNTER | CPU_HAS_PTEA;
+				   CPU_HAS_PERF_COUNTER;
 		break;
 	case 0x1100:
 		cpu_data->type = CPU_SH7751;
-		cpu_data->flags |= CPU_HAS_FPU | CPU_HAS_PTEA;
+		cpu_data->flags |= CPU_HAS_FPU;
 		break;
 	case 0x2000:
 		cpu_data->type = CPU_SH73180;
@@ -126,23 +126,22 @@ int __init detect_cpu_and_cache_system(void)
 		break;
 	case 0x8000:
 		cpu_data->type = CPU_ST40RA;
-		cpu_data->flags |= CPU_HAS_FPU | CPU_HAS_PTEA;
+		cpu_data->flags |= CPU_HAS_FPU;
 		break;
 	case 0x8100:
 		cpu_data->type = CPU_ST40GX1;
-		cpu_data->flags |= CPU_HAS_FPU | CPU_HAS_PTEA;
+		cpu_data->flags |= CPU_HAS_FPU;
 		break;
 	case 0x700:
 		cpu_data->type = CPU_SH4_501;
 		cpu_data->icache.ways = 2;
 		cpu_data->dcache.ways = 2;
-		cpu_data->flags |= CPU_HAS_PTEA;
 		break;
 	case 0x600:
 		cpu_data->type = CPU_SH4_202;
 		cpu_data->icache.ways = 2;
 		cpu_data->dcache.ways = 2;
-		cpu_data->flags |= CPU_HAS_FPU | CPU_HAS_PTEA;
+		cpu_data->flags |= CPU_HAS_FPU;
 		break;
 	case 0x500 ... 0x501:
 		switch (prr) {
@@ -160,7 +159,7 @@ int __init detect_cpu_and_cache_system(void)
 		cpu_data->icache.ways = 2;
 		cpu_data->dcache.ways = 2;
 
-		cpu_data->flags |= CPU_HAS_FPU | CPU_HAS_PTEA;
+		cpu_data->flags |= CPU_HAS_FPU;
 
 		break;
 	default:
@@ -173,6 +172,10 @@ int __init detect_cpu_and_cache_system(void)
 	cpu_data->dcache.ways = 1;
 #endif
 
+#ifdef CONFIG_CPU_HAS_PTEA
+	cpu_data->flags |= CPU_HAS_PTEA;
+#endif
+
 	/*
 	 * On anything that's not a direct-mapped cache, look to the CVR
 	 * for I/D-cache specifics.
diff --git a/arch/sh/mm/Kconfig b/arch/sh/mm/Kconfig
index 88e9663..6cd6d00 100644
--- a/arch/sh/mm/Kconfig
+++ b/arch/sh/mm/Kconfig
@@ -20,6 +20,7 @@ config CPU_SH4
 	bool
 	select CPU_HAS_INTEVT
 	select CPU_HAS_SR_RB
+	select CPU_HAS_PTEA if !CPU_SUBTYPE_ST40
 
 config CPU_SH4A
 	bool
diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
index 128907e..123fb80 100644
--- a/arch/sh/mm/fault.c
+++ b/arch/sh/mm/fault.c
@@ -223,89 +223,3 @@ do_sigbus:
 	if (!user_mode(regs))
 		goto no_context;
 }
-
-#ifdef CONFIG_SH_STORE_QUEUES
-/*
- * This is a special case for the SH-4 store queues, as pages for this
- * space still need to be faulted in before it's possible to flush the
- * store queue cache for writeout to the remapped region.
- */
-#define P3_ADDR_MAX		(P4SEG_STORE_QUE + 0x04000000)
-#else
-#define P3_ADDR_MAX		P4SEG
-#endif
-
-/*
- * Called with interrupts disabled.
- */
-asmlinkage int __kprobes __do_page_fault(struct pt_regs *regs,
-					 unsigned long writeaccess,
-					 unsigned long address)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
-	pte_t entry;
-	struct mm_struct *mm = current->mm;
-	spinlock_t *ptl;
-	int ret = 1;
-
-#ifdef CONFIG_SH_KGDB
-	if (kgdb_nofault && kgdb_bus_err_hook)
-		kgdb_bus_err_hook();
-#endif
-
-	/*
-	 * We don't take page faults for P1, P2, and parts of P4, these
-	 * are always mapped, whether it be due to legacy behaviour in
-	 * 29-bit mode, or due to PMB configuration in 32-bit mode.
-	 */
-	if (address >= P3SEG && address < P3_ADDR_MAX) {
-		pgd = pgd_offset_k(address);
-		mm = NULL;
-	} else {
-		if (unlikely(address >= TASK_SIZE || !mm))
-			return 1;
-
-		pgd = pgd_offset(mm, address);
-	}
-
-	pud = pud_offset(pgd, address);
-	if (pud_none_or_clear_bad(pud))
-		return 1;
-	pmd = pmd_offset(pud, address);
-	if (pmd_none_or_clear_bad(pmd))
-		return 1;
-
-	if (mm)
-		pte = pte_offset_map_lock(mm, pmd, address, &ptl);
-	else
-		pte = pte_offset_kernel(pmd, address);
-
-	entry = *pte;
-	if (unlikely(pte_none(entry) || pte_not_present(entry)))
-		goto unlock;
-	if (unlikely(writeaccess && !pte_write(entry)))
-		goto unlock;
-
-	if (writeaccess)
-		entry = pte_mkdirty(entry);
-	entry = pte_mkyoung(entry);
-
-#ifdef CONFIG_CPU_SH4
-	/*
-	 * ITLB is not affected by "ldtlb" instruction.
-	 * So, we need to flush the entry by ourselves.
-	 */
-	__flush_tlb_page(get_asid(), address & PAGE_MASK);
-#endif
-
-	set_pte(pte, entry);
-	update_mmu_cache(NULL, address, entry);
-	ret = 0;
-unlock:
-	if (mm)
-		pte_unmap_unlock(pte, ptl);
-	return ret;
-}
diff --git a/include/asm-sh/pgtable.h b/include/asm-sh/pgtable.h
index b1f21e7..fa62524 100644
--- a/include/asm-sh/pgtable.h
+++ b/include/asm-sh/pgtable.h
@@ -43,12 +43,12 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 /* PGD bits */
 #define PGDIR_SHIFT	(PTE_SHIFT + PTE_BITS)
 #define PGDIR_BITS	(32 - PGDIR_SHIFT)
-#define PGDIR_SIZE	(1UL << PGDIR_SHIFT)
+#define PGDIR_SIZE	(1 << PGDIR_SHIFT)
 #define PGDIR_MASK	(~(PGDIR_SIZE-1))
 
 /* Entries per level */
-#define PTRS_PER_PTE	(1UL << PTE_BITS)
-#define PTRS_PER_PGD	(1UL << PGDIR_BITS)
+#define PTRS_PER_PTE	(1 << PTE_BITS)
+#define PTRS_PER_PGD	(1 << PGDIR_BITS)
 
 #define USER_PTRS_PER_PGD	(TASK_SIZE/PGDIR_SIZE)
 #define FIRST_USER_ADDRESS	0

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Fri, Feb 09, 2007 at 07:23:16PM +0900, Paul Mundt wrote:
> On Fri, Feb 09, 2007 at 10:32:49AM +0100, Manuel Lauss wrote:
> > On Fri, Feb 09, 2007 at 05:34:24PM +0900, Paul Mundt wrote:
> > > On Thu, Feb 08, 2007 at 12:02:47PM +0100, Manuel Lauss wrote:
> > > > On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> > > > > Assuming no luck and you hit the same problem again, but at a different
> > > > > offset, and it's repeatable, can you walk the page tables and print out
> > > > > the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> > > > > each remapped PTE?

> The page tables look perfectly sane, so that's quite interesting. At
> least we know it's not a problem of a bogus page table mapping, or pgprot
> oddities.
> 
> The next thing to try would be to pre-fault the translation and make sure
> it's in the TLB so we don't take a TLB miss for the dying page to see if
> the issue persists for that page, or if it's bumped to the next one.
> You're clearly on a system that has the old-style PTEA, that might be

a (old?) SH7760 rev. AD

> something else to look at (and that's also set in the update_mmu_cache()
> path). The fact that this fault happens at a fixed location suggestions
> that it's not actually having a problem faulting in the translation, so I
> would imagine you're not going to find much in the TLB miss case.
> 
> Once you've pre-faulted the page, please try to dump the whole page
> and see if it manages to blow up at that same location. You can setup the
> translation with:
> 
> 	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
> 	update_mmu_cache(NULL, 0xc0600000, entry);

Inserted this after the p3_ioremap() call; still oopsing at the same
address.

The oops is triggered at drivers/net/pcmcia/pcnet_cs::get_hwinfo(),
by the first readb().
 
> or you can of course just hack something stupid in to the dump code to
> pre-fault and bail out early (ie, a dummy read for every PTE).
> 
> The next question would be what register you have at 0x18000ff0, whether
> you can use 16 or 32-bit reads, and if so, whether it's the same location
> that blows up. The fact it worked the first few times and it's an
> uncached mapping almost suggests a timing problem, oddly.

Yes, if I power the board off for a few minutes and try again,
sometimes the card is recognized without a hitch 1-2 times, then
it starts acting up again. However, it works perfectly with 2.6.19,
and I can insert/remove the card >100 times.

-- 
 ml.

Re: 2.6.20 instability

[Paul M. <pau...@re...>]

On Fri, Feb 09, 2007 at 10:32:49AM +0100, Manuel Lauss wrote:
> On Fri, Feb 09, 2007 at 05:34:24PM +0900, Paul Mundt wrote:
> > On Thu, Feb 08, 2007 at 12:02:47PM +0100, Manuel Lauss wrote:
> > > On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> > > > Assuming no luck and you hit the same problem again, but at a different
> > > > offset, and it's repeatable, can you walk the page tables and print out
> > > > the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> > > > each remapped PTE?
> > > 
> > > That may take a (long) while, I don't know yet where to start :)
> > > 
> > Try this..
> 
> Thank you.
> 
> Courisouly, with the dumping enabled the oops did not occur
> the first 3 times, strange, but after a another reset it is
> as oops-happy as ever.
> 
> This is the log of the first few *working* cases:
> http://mlau.at/sh/sh4-ptedumper.txt
> 
> And here from the oopsing ones:
> http://mlau.at/sh/sh4-ptedumper-2.txt
> http://mlau.at/sh/sh4-ptedumper-3.txt
> 
> I'll try to find something with the JTAG probe next.
> 
The page tables look perfectly sane, so that's quite interesting. At
least we know it's not a problem of a bogus page table mapping, or pgprot
oddities.

The next thing to try would be to pre-fault the translation and make sure
it's in the TLB so we don't take a TLB miss for the dying page to see if
the issue persists for that page, or if it's bumped to the next one.
You're clearly on a system that has the old-style PTEA, that might be
something else to look at (and that's also set in the update_mmu_cache()
path). The fact that this fault happens at a fixed location suggestions
that it's not actually having a problem faulting in the translation, so I
would imagine you're not going to find much in the TLB miss case.

Once you've pre-faulted the page, please try to dump the whole page
and see if it manages to blow up at that same location. You can setup the
translation with:

	pte_t entry = pfn_pte(0x18000000 >> PAGE_SHIFT, pgprot);
	update_mmu_cache(NULL, 0xc0600000, entry);

or you can of course just hack something stupid in to the dump code to
pre-fault and bail out early (ie, a dummy read for every PTE).

The next question would be what register you have at 0x18000ff0, whether
you can use 16 or 32-bit reads, and if so, whether it's the same location
that blows up. The fact it worked the first few times and it's an
uncached mapping almost suggests a timing problem, oddly.

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Fri, Feb 09, 2007 at 05:34:24PM +0900, Paul Mundt wrote:
> On Thu, Feb 08, 2007 at 12:02:47PM +0100, Manuel Lauss wrote:
> > On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> > > Assuming no luck and you hit the same problem again, but at a different
> > > offset, and it's repeatable, can you walk the page tables and print out
> > > the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> > > each remapped PTE?
> > 
> > That may take a (long) while, I don't know yet where to start :)
> > 
> Try this..

Thank you.

Courisouly, with the dumping enabled the oops did not occur
the first 3 times, strange, but after a another reset it is
as oops-happy as ever.

This is the log of the first few *working* cases:
http://mlau.at/sh/sh4-ptedumper.txt

And here from the oopsing ones:
http://mlau.at/sh/sh4-ptedumper-2.txt
http://mlau.at/sh/sh4-ptedumper-3.txt

I'll try to find something with the JTAG probe next.

-- 
 ml.

Re: 2.6.20 instability

[Paul M. <pau...@re...>]

On Thu, Feb 08, 2007 at 12:02:47PM +0100, Manuel Lauss wrote:
> On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> > Assuming no luck and you hit the same problem again, but at a different
> > offset, and it's repeatable, can you walk the page tables and print out
> > the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> > each remapped PTE?
> 
> That may take a (long) while, I don't know yet where to start :)
> 
Try this..

diff --git a/arch/sh/mm/ioremap.c b/arch/sh/mm/ioremap.c
index be03d74..643b9f7 100644
--- a/arch/sh/mm/ioremap.c
+++ b/arch/sh/mm/ioremap.c
@@ -23,6 +23,85 @@
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
 
+#define DEBUG
+
+#ifdef DEBUG
+static inline void
+show_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end)
+{
+	pte_t *ptep;
+	spinlock_t *ptl;
+
+	printk_ratelimit();
+
+	ptep = pte_offset_map_lock(&init_mm, pmd, addr, &ptl);
+	do {
+		pte_t pte = *ptep;
+		unsigned long pteval;
+
+		if (!pte_present(pte))
+			continue;
+
+		pteval = pte_val(pte);
+
+		printk("ADDR -> %08lx, PHYS -> %08lx, FLAGS -> %08lx\n",
+		       addr, pteval & PTE_PHYS_MASK,
+		       pteval & ~(PTE_PHYS_MASK | _PAGE_DUMP));
+	} while (ptep++, addr += PAGE_SIZE, addr != end);
+
+	pte_unmap_unlock(ptep - 1, ptl);
+	cond_resched();
+}
+
+static inline void
+show_pmd_range(pud_t *pud, unsigned long addr, unsigned long end)
+{
+	unsigned long next;
+	pmd_t *pmd;
+
+	pmd = pmd_offset(pud, addr);
+	do {
+		next = pmd_addr_end(addr, end);
+		if (pmd_none_or_clear_bad(pmd))
+			break;
+		show_pte_range(pmd, addr, next);
+	} while (pmd++, addr = next, addr != end);
+}
+
+static inline void
+show_pud_range(pgd_t *pgd, unsigned long addr, unsigned long end)
+{
+	unsigned long next;
+	pud_t *pud;
+
+	pud = pud_offset(pgd, addr);
+	do {
+		next = pud_addr_end(addr, end);
+		if (pud_none_or_clear_bad(pud))
+			break;
+		show_pmd_range(pud, addr, next);
+	} while (pud++, addr = next, addr != end);
+}
+
+static void show_pgtables(unsigned long addr, unsigned long end)
+{
+	unsigned long next;
+	pgd_t *pgd;
+
+	pgd = pgd_offset_k(addr);
+
+	printk("Dumping page tables for %08lx -> %08lx\n", addr, end);
+	do {
+		next = pgd_addr_end(addr, end);
+		if (pgd_none_or_clear_bad(pgd))
+			break;
+		show_pud_range(pgd, addr, next);
+	} while (pgd++, addr = next, addr != end);
+}
+#else
+#define show_pgtables(addr, end)	do { } while (0)
+#endif
+
 /*
  * Remap an arbitrary physical address space into the kernel virtual
  * address space. Needed when the kernel wants to access high addresses
@@ -108,6 +187,9 @@ void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
 			return NULL;
 		}
 
+	if (unlikely(flags & _PAGE_DUMP))
+		show_pgtables(addr, addr + size);
+
 	return (void __iomem *)(offset + (char *)orig_addr);
 }
 EXPORT_SYMBOL(__ioremap);
diff --git a/include/asm-sh/pgtable.h b/include/asm-sh/pgtable.h
index 3721a44..a10dec0 100644
--- a/include/asm-sh/pgtable.h
+++ b/include/asm-sh/pgtable.h
@@ -81,7 +81,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
  * - Bit 9 is reserved by everyone and used by _PAGE_PROTNONE.
  *
  * - Bits 10 and 11 are low bits of the PPN that are reserved on >= 4K pages.
- *   Bit 10 is used for _PAGE_ACCESSED, bit 11 remains unused.
+ *   Bit 10 is used for _PAGE_ACCESSED, bit 11 is used for _PAGE_DUMP.
  *
  * - Bits 31, 30, and 29 remain unused by everyone and can be used for future
  *   software flags, although care must be taken to update _PAGE_CLEAR_FLAGS.
@@ -115,6 +115,8 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 #define _PAGE_ACCESSED	0x400		/* software: page referenced */
 #define _PAGE_FILE	_PAGE_WT	/* software: pagecache or swap? */
 
+#define _PAGE_DUMP	0x800		/* software: debug flag, pgtable dump */
+
 /* Extended mode bits */
 #define _PAGE_EXT_ESZ0		0x0010	/* ESZ0-bit: Size of page */
 #define _PAGE_EXT_ESZ1		0x0020	/* ESZ1-bit: Size of page */
@@ -153,9 +155,10 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 #ifdef CONFIG_CPU_SH3
 #define _PAGE_CLEAR_FLAGS	(_PAGE_PROTNONE | _PAGE_ACCESSED| \
 				 _PAGE_FILE	| _PAGE_SZ1	| \
-				 _PAGE_HW_SHARED)
+				 _PAGE_HW_SHARED| _PAGE_DUMP)
 #else
-#define _PAGE_CLEAR_FLAGS	(_PAGE_PROTNONE | _PAGE_ACCESSED | _PAGE_FILE)
+#define _PAGE_CLEAR_FLAGS	(_PAGE_PROTNONE | _PAGE_ACCESSED | \
+				 _PAGE_FILE | _PAGE_DUMP)
 #endif
 
 #define _PAGE_FLAGS_HARDWARE_MASK	(0x1fffffff & ~(_PAGE_CLEAR_FLAGS))

Re: 2.6.20 instability

[Paul M. <le...@li...>]

On Thu, Feb 08, 2007 at 12:02:47PM +0100, Manuel Lauss wrote:
> On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> > This looks quite strange indeed. First, are you doing anything strange
> > with VMALLOC_START? If not, can you set it to P3 + 4MB and see if you hit
> > the same problem elsewhere outside of the p3_ioremap() context (or
> > optionally just remap an empty hole to bump it up)?
> 
> The faulting address increases by the amount of added to VMALLOC_START.
> System is usable though until the card is removed, then it blows up
> completely. I can even insert/remove a CF card multiple times without
> incident.
> 
So you're saying this improves the situation? Or that there's no change?
The oops seems to confirm the latter. These addresses will be faulted
regardless, it's only the unhandled faults we care about.

> > Assuming no luck and you hit the same problem again, but at a different
> > offset, and it's repeatable, can you walk the page tables and print out
> > the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> > each remapped PTE?
> 
> That may take a (long) while, I don't know yet where to start :)
> 
I'll hack something together quickly then and send it to you off-list.

> exm7760_ss:  \-> p3_ioremap(18000000, 400000, 60000534) = C0600000
> exm7760_ss: set_memmap:(1) map=1 flags=0x0021 ss=0xc0600000 cs=0x00000000 [ ACT ATTRIB]
> Unable to handle kernel paging request at virtual address c0600ff0
> pc = 8c006374
> get_TTB() = 8f512000  TTB()+pgd_index() = 8f512301

That looks ok.

> *pde = 00000000

That looks questionable.

> [<8c155d12>] pccardd+0x15a/0x270
> [<8c00d264>] default_wake_function+0x0/0x18
> [<8c00d264>] default_wake_function+0x0/0x18
> [<8c021384>] kthread+0xd4/0x124
> [<8c00d39c>] complete+0x0/0x58
> [<8c02129c>] kthread_should_stop+0x0/0x14
> [<8c003004>] kernel_thread_helper+0x4/0x10

There have been some reports of the child stack pointer getting corrupted
in relation to some kernel thread handling, however, this is quite early
on in your backtrace, and the stacktrace itself looks reasonably sane, so
I don't imagine it's related. We should know more from the PTEs at least..

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Thu, Feb 08, 2007 at 05:26:23PM +0900, Paul Mundt wrote:
> On Thu, Feb 08, 2007 at 08:43:39AM +0100, Manuel Lauss wrote:
> > It seems the error condition is depeding on the size of the
> > window getting p3_ioremap()ed in the socket driver.
> > For example, a minimal kernel with SCIF/pcmcia/net/ide support
> > will NOT oops when the window size is reduced to 2MB
> > (the MAP_SIZE constant in exm7760_ss.c).
> > 
> > For a larger kernel with more built-in hardware I need to
> > reduce the window size to 1MB.
> > 
> > Oopses occur when something tries to access beyond 0xc0400000.
> > (just a guess though)
> > 
> This looks quite strange indeed. First, are you doing anything strange
> with VMALLOC_START? If not, can you set it to P3 + 4MB and see if you hit
> the same problem elsewhere outside of the p3_ioremap() context (or
> optionally just remap an empty hole to bump it up)?

The faulting address increases by the amount of added to VMALLOC_START.
System is usable though until the card is removed, then it blows up
completely. I can even insert/remove a CF card multiple times without
incident.

 
> Assuming no luck and you hit the same problem again, but at a different
> offset, and it's repeatable, can you walk the page tables and print out
> the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
> each remapped PTE?

That may take a (long) while, I don't know yet where to start :)

> Going by the oops, it looks like you have a bogus PGD. Can you print out
> the value of get_TTB() (and also get_TTB() + pgd_index(addr)) in
> do_page_fault() under the oops path before the die()?

output below

> If that still doesn't provide any hints, can you trap the faulting
> address in the TLB miss handler and see whether you're coming out alive
> or not? Any branches in to handle_exception() from tlb_miss() you might
> be able to spot with a JTAG on that faulting range would be interesting.

okay, I'll try

Thanks!

exm7760_ss:  \-> p3_ioremap(18000000, 400000, 60000534) = C0600000
exm7760_ss: set_memmap:(1) map=1 flags=0x0021 ss=0xc0600000 cs=0x00000000 [ ACT ATTRIB]
Unable to handle kernel paging request at virtual address c0600ff0
pc = 8c006374
get_TTB() = 8f512000  TTB()+pgd_index() = 8f512301
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:

Pid : 206, Comm:              pccardd
PC is at generic_readb+0x0/0x6
PC  : 8c006374 SP  : 8fd2fb6c SR  : 40008101 TEA : c0600ff0    Not tainted
R0  : 8c006374 R1  : 003fffff R2  : 00000000 R3  : 00000001
R4  : c0600ff0 R5  : 0000242a R6  : 60000534 R7  : 000000f0
R8  : 8c2ce94c R9  : c0600ff0 R10 : 8c2ce948 R11 : c0600000
R12 : 8f992000 R13 : 00000000 R14 : 8c2b9860
MACH: 000003da MACL: 00000000 GBR : 00000000 PR  : 8c12629c

Call trace:
[<8c0101ca>] __set_personality+0x6e/0x14c
[<8c0058e2>] handle_timer_tick+0x2a/0xe4
[<8c01824c>] run_timer_softirq+0x54/0x15c
[<8c0180b4>] cascade+0x0/0x5c
[<8c00a224>] tmu_timer_interrupt+0x1c/0x3c
[<8c014e7c>] __do_softirq+0x3c/0x98
[<8c014f02>] do_softirq+0x2a/0x58
[<8c014f02>] do_softirq+0x2a/0x58
[<8c005120>] do_IRQ+0x50/0x78
[<8c0070cc>] ret_from_exception+0x0/0x14
[<8c0050d0>] do_IRQ+0x0/0x78
[<8c2b001c>] __kstrtab_pcmcia_unregister_driver+0x0/0x1c
[<8c0109a4>] __call_console_drivers+0x3c/0x58
[<8c010d18>] release_console_sem+0x138/0x226
[<8c011060>] vprintk+0x244/0x2a0
[<8c26bf48>] __func__.0+0x53584/0x89a44
[<8c014f02>] do_softirq+0x2a/0x58
[<8c014f02>] do_softirq+0x2a/0x58
[<8c0f0bc8>] number+0x108/0x26c
[<8c0110cc>] printk+0x10/0x1c
[<8c0110cc>] printk+0x10/0x1c
[<8c0110bc>] printk+0x0/0x1c
[<8c15b64a>] exm_set_memmap+0xaa/0x230
[<8c1562c8>] set_cis_map+0x78/0xb4
[<8c1566ac>] read_cis_cache+0x8c/0xe8
[<8c1566bc>] read_cis_cache+0x9c/0xe8
[<8c156d86>] pccard_get_tuple_data+0x4e/0x5c
[<8c1579c6>] pccard_read_tuple+0x6e/0x9c
[<8c1588a6>] pcmcia_device_probe+0xc6/0x178
[<8c076b23>] sysfs_create_link+0xab/0x120
[<8c11be14>] really_probe+0x78/0x140
[<8c11bf72>] driver_probe_device+0x7e/0xb0
[<8c11bd9c>] really_probe+0x0/0x140
[<8c11b47c>] bus_for_each_drv+0x34/0x70
[<8c11bfa4>] __device_attach+0x0/0xc
[<8c11c012>] device_attach+0x62/0xc0
[<8c11b620>] bus_attach_device+0x24/0x58
[<8c119fee>] device_add+0x2e6/0x494
[<8c158e6e>] pcmcia_device_add+0x17e/0x284
[<8c159018>] pcmcia_card_add+0xa4/0xe0
[<8c155bb8>] pccardd+0x0/0x270
[<8c28f778>] __func__.0+0x76db4/0x89a44
[<8c155bb8>] pccardd+0x0/0x270
[<8c1fed16>] schedule_timeout+0x66/0xa8
[<8c018958>] process_timeout+0x0/0xc
[<8c0ee29c>] kobject_get+0x10/0x1c
[<8c159d4e>] ds_event+0x7a/0xb4
[<8c1553e2>] send_event+0x9a/0xd0
[<8c15598c>] socket_insert+0xd0/0x130
[<8c154e88>] cs_debug_level+0x0/0x10
[<8c0110bc>] printk+0x0/0x1c
[<8c155d12>] pccardd+0x15a/0x270
[<8c00d264>] default_wake_function+0x0/0x18
[<8c00d264>] default_wake_function+0x0/0x18
[<8c021384>] kthread+0xd4/0x124
[<8c00d39c>] complete+0x0/0x58
[<8c02129c>] kthread_should_stop+0x0/0x14
[<8c003004>] kernel_thread_helper+0x4/0x10

Process: pccardd (pid: 206, stack limit = 8fd2e001)
Stack: (0x8fd2fb6c to 0x8fd30000)
fb60:                            00000000 0000001b 00000100 00000000 00000061
fb80: 8000141b 00000014 8fd2fd00 00110020 63ce4801 0000003f 0007a120 0006ddd0
fba0: 00086470 00030d40 00030d40 0003d090 8c2bbb04 8c2bba00 00000001 00000000
fbc0: 00000000 00000000 00000001 00000000 00000000 8c2bbb00 00000000 00000000
fbe0: 00000000 8fd2fbe4 8fd2fbe4 ffffffff 00000000 000002bc 00000001 00000000
fc00: 8fc12040 00000000 00000024 8c0101ca 00000300 00000020 8c0058e2 00000007
fc20: 8fc1bf8c 8c2bc064 8c01824c 00000000 8c319108 8c0180b4 8c00a224 8fd2fc3c
fc40: 8fd2fc3c 8c014e7c 8c323a24 00000021 8c318ec0 0000000a 8c318f04 00000001
fc60: 8c014f02 8c014f02 8c2f89ef 00000000 000000f0 8c005120 8c31d2d0 8c0070cc
fc80: 8c0050d0 ffffffff 00000000 00000000 00000030 0000ffff 8c2b001c 00000042
fca0: 00000007 000000f0 ffffffff 8c0109a4 000000f0 00002072 00002070 8c2cb190
fcc0: 8c010d18 8c2ba76c 00002072 00002072 8c011060 00000021 8c323a25 8c2f89ea
fce0: 8c26bf48 ffffffff 8c318f04 00000001 8c014f02 8c014f02 8c2f8a36 00000000
fd00: 3f1d81e0 255d4d55 72fc2d25 030060ca ffff301f 8c0f0bc8 44434234 35343433
fd20: 40008100 00000000 8c0110cc 00000000 8c0110cc 8c0110bc 8c323a24 00000021
fd40: 8c323a25 00000000 8c323a0c 8c323bc8 8c15b64a 00000042 00000007 000000f0
fd60: 8c1562c8 8c2d1428 8c323a0c 00000021 00000000 00000000 8c323a24 8c323a0c
fd80: 00000006 c0600000 00400000 00000000 000000b4 00000001 8fc200c5 00000002
fda0: 00000021 8c1566ac 8c2d1428 00000001 8c323a0c 8fc200c0 0000005a 00000005
fdc0: 8c1566bc 00000000 8c156d86 8f992000 00000000 8c320000 8fd2fe24 8c1579c6
fde0: 00000000 8fb5d400 8fb5d700 00000002 00000000 8f992040 8fb5d400 0000005a
fe00: ff00051a 8c1588a6 8c2d1428 8c322e8c 8c3236c0 8f992084 8f992000 8c2cbfec
fe20: 8f992040 8c076b23 000003f8 00000003 00000000 00000000 00000000 8f992000
fe40: 8c11be14 8fea08c0 8c2cc004 00000000 8f992084 8f992140 8c11bf72 00000000
fe60: 00000000 8c11bd9c 8f992084 8c2cc080 8fea08c0 8c11b47c 00000000 00000000
fe80: 8f992084 8c11bfa4 00000000 8c2d1284 8c2d1284 8c2cc064 8c11c012 8c2d1174
fea0: 8f992084 8f992100 8c11b620 8f992084 8f992100 8c119fee 8f992140 8f992084
fec0: 8f992180 8c158e6e 8c3236c0 8f992009 00000000 8c323b48 8c323a0c 8f992000
fee0: 8f992010 8c159018 00000000 fffffffc 8c155bb8 00000000 8c323a0c 00000001
ff00: 00000001 8c28f778 ffffffff 00000000 fffffffc 8c155bb8 8c1fed16 ffff99ef
ff20: 8c2bb560 ffff99ef 00000000 00200200 ffff99ef 8c018958 8fc12040 8c319108
ff40: 8c0ee29c 8c323b70 0000000f 8c159d4e 8c323a0c 8c323a0c 00000004 8c1553e2
ff60: 00000000 00000004 8c323a0c 8c323b48 8c15598c 8c154e88 00000000 8c0110bc
ff80: 8c323a0c 8c155d12 8c323b08 8c323a0c 8fd2e000 00000080 00000000 8fc12040
ffa0: 8c00d264 8c323b3c 8c323b3c 00000000 8fc12040 8c00d264 00000000 00000000
ffc0: 000010c0 8c021384 8c323a0c 8c3d9f38 8c00d39c 8c02129c ffffffff ffffffff
ffe0: 00000001 8c003004 00000000 00000000 00000000 00000000 00000000 00000000

Re: 2.6.20 instability

[Paul M. <le...@li...>]

On Thu, Feb 08, 2007 at 08:43:39AM +0100, Manuel Lauss wrote:
> It seems the error condition is depeding on the size of the
> window getting p3_ioremap()ed in the socket driver.
> For example, a minimal kernel with SCIF/pcmcia/net/ide support
> will NOT oops when the window size is reduced to 2MB
> (the MAP_SIZE constant in exm7760_ss.c).
> 
> For a larger kernel with more built-in hardware I need to
> reduce the window size to 1MB.
> 
> Oopses occur when something tries to access beyond 0xc0400000.
> (just a guess though)
> 
This looks quite strange indeed. First, are you doing anything strange
with VMALLOC_START? If not, can you set it to P3 + 4MB and see if you hit
the same problem elsewhere outside of the p3_ioremap() context (or
optionally just remap an empty hole to bump it up)?

Assuming no luck and you hit the same problem again, but at a different
offset, and it's repeatable, can you walk the page tables and print out
the pgprot encoding as well as the corresponding pfn << PAGE_SHIFT for
each remapped PTE?

Going by the oops, it looks like you have a bogus PGD. Can you print out
the value of get_TTB() (and also get_TTB() + pgd_index(addr)) in
do_page_fault() under the oops path before the die()?

If that still doesn't provide any hints, can you trap the faulting
address in the TLB miss handler and see whether you're coming out alive
or not? Any branches in to handle_exception() from tlb_miss() you might
be able to spot with a JTAG on that faulting range would be interesting.

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Wed, Feb 07, 2007 at 01:31:50PM +0100, Manuel Lauss wrote:
> On Wed, Feb 07, 2007 at 07:40:02PM +0900, Paul Mundt wrote:
> > On Fri, Feb 02, 2007 at 11:48:43AM +0100, Manuel Lauss wrote:
> > > I don't run -git kernels so patch 1 is not applied anyway and
> > > without patch 2 the situation is much worse: 
> > > Kernel oopses every time a pcmcia ethernet card is inserted
> > > (cf cards are not affected or much less frequently).
> > > The difference is that for the ethernet card io ports are allocated
> > > starting from 0x300, while the cf card io ports start at 0x0.
> > > Also, the oops does not occur if the ethernet card is already in the
> > > socket when kernel boots. I can then also reapeatedly eject/insert
> > > it without problems.
> > > 
> > Can you post the log of the oops?
> 
> Please grab it here:
> 
> http://mlau.at/sh/pcnet_cs-oops-1.txt
> 
> For reference the debug output with a cf card (ide-cs)
> http://mlau.at/sh/pcmcia_cfcard.txt
> 
> Also, the socket driver source:
> http://mlau.at/sh/exm7760_ss.c

I have a little more info:

It seems the error condition is depeding on the size of the
window getting p3_ioremap()ed in the socket driver.
For example, a minimal kernel with SCIF/pcmcia/net/ide support
will NOT oops when the window size is reduced to 2MB
(the MAP_SIZE constant in exm7760_ss.c).

For a larger kernel with more built-in hardware I need to
reduce the window size to 1MB.

Oopses occur when something tries to access beyond 0xc0400000.
(just a guess though)

more logs here:
http://mlau.at/sh/exm7760-2.6.20-pcmcia_net-oopses-3.txt

-- 
 ml.

Re: create sh-boot's git repository

[Nobuhiro I. <he...@t-...>]

Hi , Paul.

Thank you for your comment.

On Tue, 6 Feb 2007 14:53:34 +0900
Paul Mundt <le...@li...> wrote:

> DOYU-san also had quite a lot of new things merged in his arch tree, have
> you consolidated with his work in this area also? (I have mirrors of this
> if you need a copy of the source). 
Yes , I know arch Repogetori of DOYU-san exists.
But his WEB server and arch server seem to have downed.
If yours offers his mirror, I  work to merge the changes .
Could you send it?

> There's still some consolidation that
> needs to happen between those and the newer Renesas versions. In the
> latter case, we have many ports hanging around that might be of general
> interest (ie, Izanagi), even if there's no real push for the part itself.

Does Renesas 's sh-boot that you write indicate the thing of www.superh-linux.
org?
If it is correct , I am importing those change to git repsitory.

I think that sh-boot is still at an important position. 
# For example , porting is easy and have many users.

> The other concern is u-boot. We now have the SH7785 work which is somewhat
> disjoint from the SH7343 port that was done some time ago, and then ST also
> has their ST-40 port. We've also been looking at it for SH7756. This also
> needs to be desperately consolidated before we have any _more_
> fragmentation. I assume ST will also be open to rebasing their ST-40
> stuff on top of generic SH support in u-boot.
> 
> Given that, is there really much point in dragging sh-boot along? Perhaps
> it's best left in a maintenance-only mode for the existing users, with
> the new ports leaning more towards u-boot.

Yes, I am interested about u-boot, and working now.
But I can not contribute the content of the activity to ML for a variety of reasons  . ;-)
I plan to make it merge with u-boot latest as for code of ST's u-boot , if I have time.

regards ,
 Nobuhiro

-- 
Nobuhiro Iwamatsu
	E-Mail : he...@t-...
	GPG ID : 3170EBE9 

Re: 2.6.20 instability

[Manuel L. <ma...@ro...>]

On Wed, Feb 07, 2007 at 07:40:02PM +0900, Paul Mundt wrote:
> On Fri, Feb 02, 2007 at 11:48:43AM +0100, Manuel Lauss wrote:
> > I don't run -git kernels so patch 1 is not applied anyway and
> > without patch 2 the situation is much worse: 
> > Kernel oopses every time a pcmcia ethernet card is inserted
> > (cf cards are not affected or much less frequently).
> > The difference is that for the ethernet card io ports are allocated
> > starting from 0x300, while the cf card io ports start at 0x0.
> > Also, the oops does not occur if the ethernet card is already in the
> > socket when kernel boots. I can then also reapeatedly eject/insert
> > it without problems.
> > 
> Can you post the log of the oops?

Please grab it here:

http://mlau.at/sh/pcnet_cs-oops-1.txt

For reference the debug output with a cf card (ide-cs)
http://mlau.at/sh/pcmcia_cfcard.txt

Also, the socket driver source:
http://mlau.at/sh/exm7760_ss.c


Does not seem to be irq related; pcnet_cs does not get that
far, and the CD irq is debounced in a CPLD.

Thanks!

-- 
 ml.

[PATCH] kmap: SH-4 user page copy/clear overhaul

[Paul M. <pau...@re...>]

This introduces the first attempt at overhauling the user page copy/clear
interface for the aliasing VIPT cases (only SH-4 and SH-4A right now,
SH7705 should be able to use it directly, though, when in 32k cache mode).

Previously we used a reserved 1MB chunk of the address space starting at
P3 (and bumping up the vmalloc base as a result), then using an array of
mutexes per page colour for gauranteeing exclusion to the page being
operated on and manually poking at the PTEs when operating on the user
page. This also required special copy/clear page ops that were handling
the cache handling based on user page colour directly. Additionally, the
mutex exclusion was also bogus given that it invariably is called under a
spinlock.

This uses a slightly different approach, where we use fixmap addresses
for the various colours, with the fixmap addresses being fixed virtual
for each address space. This permits us to use the normal page copy/clear
ops directly, and vastly simplifies things in the process. And we can
finally turn on mutex debugging without the p3map_mutex blowing up.

With the light testing I've given this so far it seems to hold up, but
I'd be interested to see if this breaks on systems with different cache
models (I've only tested on SH7722 and SH7780, which are both 4-way).

I'll queue this for 2.6.21 unless someone manages to break it. Against
current git, but should apply to 2.6.20 too.

--

 arch/sh/kernel/sh_ksyms.c |    3 -
 arch/sh/mm/cache-sh4.c    |   18 -------
 arch/sh/mm/clear_page.S   |   47 -------------------
 arch/sh/mm/copy_page.S    |   64 --------------------------
 arch/sh/mm/pg-sh4.c       |  110 +++++++++++++++++++++-------------------------
 include/asm-sh/fixmap.h   |    8 ++-
 include/asm-sh/page.h     |   13 +++--
 include/asm-sh/pgtable.h  |    6 --
 8 files changed, 71 insertions(+), 198 deletions(-)

diff --git a/arch/sh/kernel/sh_ksyms.c b/arch/sh/kernel/sh_ksyms.c
index fe1b276..a70bf70 100644
--- a/arch/sh/kernel/sh_ksyms.c
+++ b/arch/sh/kernel/sh_ksyms.c
@@ -100,8 +100,7 @@ EXPORT_SYMBOL(flush_dcache_page);
 EXPORT_SYMBOL(__flush_purge_region);
 #endif
 
-#if defined(CONFIG_MMU) && (defined(CONFIG_CPU_SH4) || \
-	defined(CONFIG_SH7705_CACHE_32KB))
+#if defined(CONFIG_MMU) && defined(CONFIG_SH7705_CACHE_32KB)
 EXPORT_SYMBOL(clear_user_page);
 #endif
 
diff --git a/arch/sh/mm/cache-sh4.c b/arch/sh/mm/cache-sh4.c
index e0cd4b7..9414945 100644
--- a/arch/sh/mm/cache-sh4.c
+++ b/arch/sh/mm/cache-sh4.c
@@ -2,7 +2,7 @@
  * arch/sh/mm/cache-sh4.c
  *
  * Copyright (C) 1999, 2000, 2002  Niibe Yutaka
- * Copyright (C) 2001 - 2006  Paul Mundt
+ * Copyright (C) 2001 - 2007  Paul Mundt
  * Copyright (C) 2003  Richard Curnow
  *
  * This file is subject to the terms and conditions of the GNU General Public
@@ -11,8 +11,8 @@
  */
 #include <linux/init.h>
 #include <linux/mm.h>
+#include <linux/pagemap.h>
 #include <linux/io.h>
-#include <linux/mutex.h>
 #include <asm/mmu_context.h>
 #include <asm/cacheflush.h>
 
@@ -77,16 +77,8 @@ static void __init emit_cache_params(void)
 /*
  * SH-4 has virtually indexed and physically tagged cache.
  */
-
-/* Worst case assumed to be 64k cache, direct-mapped i.e. 4 synonym bits. */
-#define MAX_P3_MUTEXES 16
-
-struct mutex p3map_mutex[MAX_P3_MUTEXES];
-
 void __init p3_cache_init(void)
 {
-	int i;
-
 	compute_alias(&current_cpu_data.icache);
 	compute_alias(&current_cpu_data.dcache);
 
@@ -106,12 +98,6 @@ void __init p3_cache_init(void)
 	}
 
 	emit_cache_params();
-
-	if (ioremap_page_range(P3SEG, P3SEG + (PAGE_SIZE * 4), 0, PAGE_KERNEL))
-		panic("%s failed.", __FUNCTION__);
-
-	for (i = 0; i < current_cpu_data.dcache.n_aliases; i++)
-		mutex_init(&p3map_mutex[i]);
 }
 
 /*
diff --git a/arch/sh/mm/clear_page.S b/arch/sh/mm/clear_page.S
index 8a70613..3ef3c82 100644
--- a/arch/sh/mm/clear_page.S
+++ b/arch/sh/mm/clear_page.S
@@ -1,5 +1,5 @@
 /*
- * __clear_user_page, __clear_user, clear_page implementation of SuperH
+ * __clear_user, clear_page implementation of SuperH
  *
  * Copyright (C) 2001  Kaz Kojima
  * Copyright (C) 2001, 2002  Niibe Yutaka
@@ -150,48 +150,3 @@ ENTRY(__clear_user)
 	.long	8b, .Lbad_clear_user
 	.long	9b, .Lbad_clear_user
 .previous
-
-#if defined(CONFIG_CPU_SH4)
-/*
- * __clear_user_page
- * @to: P3 address (with same color)
- * @orig_to: P1 address
- *
- * void __clear_user_page(void *to, void *orig_to)
- */
-
-/*
- * r0 --- scratch 
- * r4 --- to
- * r5 --- orig_to
- * r6 --- to + PAGE_SIZE
- */
-ENTRY(__clear_user_page)
-	mov.l	.Lpsz,r0
-	mov	r4,r6
-	add	r0,r6
-	mov	#0,r0
-	!
-1:	ocbi	@r5
-	add	#32,r5
-	movca.l	r0,@r4
-	mov	r4,r1
-	add	#32,r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	mov.l	r0,@-r4
-	add	#28,r4
-	cmp/eq	r6,r4
-	bf/s	1b
-	 ocbwb	@r1
-	!
-	rts
-	 nop
-.Lpsz:	.long	PAGE_SIZE
-
-#endif
-
diff --git a/arch/sh/mm/copy_page.S b/arch/sh/mm/copy_page.S
index 397c94c..e43c788 100644
--- a/arch/sh/mm/copy_page.S
+++ b/arch/sh/mm/copy_page.S
@@ -1,5 +1,5 @@
 /*
- * copy_page, __copy_user_page, __copy_user implementation of SuperH
+ * copy_page, __copy_user implementation of SuperH
  *
  * Copyright (C) 2001  Niibe Yutaka & Kaz Kojima
  * Copyright (C) 2002  Toshinobu Sugioka
@@ -67,68 +67,6 @@ ENTRY(copy_page_slow)
 	mov.l	@r15+,r8
 	rts
 	 nop
-
-#if defined(CONFIG_CPU_SH4)
-/*
- * __copy_user_page
- * @to: P1 address (with same color)
- * @from: P1 address
- * @orig_to: P1 address
- *
- * void __copy_user_page(void *to, void *from, void *orig_to)
- */
-
-/*
- * r0, r1, r2, r3, r4, r5, r6, r7 --- scratch 
- * r8 --- from + PAGE_SIZE
- * r9 --- orig_to
- * r10 --- to
- * r11 --- from
- */
-ENTRY(__copy_user_page)
-	mov.l	r8,@-r15
-	mov.l	r9,@-r15
-	mov.l	r10,@-r15
-	mov.l	r11,@-r15
-	mov	r4,r10
-	mov	r5,r11
-	mov	r6,r9
-	mov	r5,r8
-	mov.l	.Lpsz,r0
-	add	r0,r8
-	!
-1:	ocbi	@r9
-	add	#32,r9
-	mov.l	@r11+,r0
-	mov.l	@r11+,r1
-	mov.l	@r11+,r2
-	mov.l	@r11+,r3
-	mov.l	@r11+,r4
-	mov.l	@r11+,r5
-	mov.l	@r11+,r6
-	mov.l	@r11+,r7
-	movca.l	r0,@r10
-	mov	r10,r0
-	add	#32,r10
-	mov.l	r7,@-r10
-	mov.l	r6,@-r10
-	mov.l	r5,@-r10
-	mov.l	r4,@-r10
-	mov.l	r3,@-r10
-	mov.l	r2,@-r10
-	mov.l	r1,@-r10
-	ocbwb	@r0
-	cmp/eq	r11,r8
-	bf/s	1b
-	 add	#28,r10
-	!
-	mov.l	@r15+,r11
-	mov.l	@r15+,r10
-	mov.l	@r15+,r9
-	mov.l	@r15+,r8
-	rts
-	 nop
-#endif
 .Lpsz:	.long	PAGE_SIZE
 /*
  * __kernel_size_t __copy_user(void *to, const void *from, __kernel_size_t n);
diff --git a/arch/sh/mm/pg-sh4.c b/arch/sh/mm/pg-sh4.c
index 969efec..b627cd5 100644
--- a/arch/sh/mm/pg-sh4.c
+++ b/arch/sh/mm/pg-sh4.c
@@ -2,83 +2,75 @@
  * arch/sh/mm/pg-sh4.c
  *
  * Copyright (C) 1999, 2000, 2002  Niibe Yutaka
- * Copyright (C) 2002 - 2005  Paul Mundt
+ * Copyright (C) 2002 - 2007  Paul Mundt
  *
  * Released under the terms of the GNU GPL v2.0.
  */
 #include <linux/mm.h>
-#include <linux/mutex.h>
+#include <linux/module.h>
+#include <linux/highmem.h>
 #include <asm/mmu_context.h>
 #include <asm/cacheflush.h>
+#include <asm/fixmap.h>
 
-extern struct mutex p3map_mutex[];
+static inline void *kmap_coherent(struct page *page, unsigned long addr)
+{
+	enum fixed_addresses idx;
+	unsigned long vaddr, flags;
+	pte_t pte;
 
-#define CACHE_ALIAS (current_cpu_data.dcache.alias_mask)
+	inc_preempt_count();
 
-/*
- * clear_user_page
- * @to: P1 address
- * @address: U0 address to be mapped
- * @page: page (virt_to_page(to))
- */
-void clear_user_page(void *to, unsigned long address, struct page *page)
+	idx = (addr & current_cpu_data.dcache.alias_mask) >> PAGE_SHIFT;
+	vaddr = __fix_to_virt(FIX_CMAP_END - idx);
+	pte = mk_pte(page, PAGE_KERNEL);
+
+	local_irq_save(flags);
+	local_flush_tlb_one(get_asid(), vaddr);
+	local_irq_restore(flags);
+
+	update_mmu_cache(NULL, vaddr, pte);
+
+	return (void *)vaddr;
+}
+
+static inline void kunmap_coherent(struct page *page)
+{
+	dec_preempt_count();
+	preempt_check_resched();
+}
+
+void copy_user_highpage(struct page *to, struct page *from,
+			unsigned long vaddr, struct vm_area_struct *vma)
 {
-	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0)
-		clear_page(to);
-	else {
-		unsigned long phys_addr = PHYSADDR(to);
-		unsigned long p3_addr = P3SEG + (address & CACHE_ALIAS);
-		pgd_t *pgd = pgd_offset_k(p3_addr);
-		pud_t *pud = pud_offset(pgd, p3_addr);
-		pmd_t *pmd = pmd_offset(pud, p3_addr);
-		pte_t *pte = pte_offset_kernel(pmd, p3_addr);
-		pte_t entry;
-		unsigned long flags;
+	void *vfrom, *vto;
+
+	vto = kmap_atomic(to, KM_USER1);
+	vfrom = kmap_coherent(from, vaddr);
+	copy_page(vto, vfrom);
+	kunmap_coherent(from);
+
+	if ((vma->vm_flags & VM_EXEC) &&
+	    ((vaddr ^ (unsigned long)vto) & current_cpu_data.dcache.alias_mask))
+		__flush_wback_region(vto, PAGE_SIZE);
 
-		entry = pfn_pte(phys_addr >> PAGE_SHIFT, PAGE_KERNEL);
-		mutex_lock(&p3map_mutex[(address & CACHE_ALIAS)>>12]);
-		set_pte(pte, entry);
-		local_irq_save(flags);
-		flush_tlb_one(get_asid(), p3_addr);
-		local_irq_restore(flags);
-		update_mmu_cache(NULL, p3_addr, entry);
-		__clear_user_page((void *)p3_addr, to);
-		pte_clear(&init_mm, p3_addr, pte);
-		mutex_unlock(&p3map_mutex[(address & CACHE_ALIAS)>>12]);
-	}
+	kunmap_atomic(vto, KM_USER1);
+	smp_wmb();
 }
+EXPORT_SYMBOL(copy_user_highpage);
 
 /*
- * copy_user_page
+ * clear_user_page
  * @to: P1 address
- * @from: P1 address
  * @address: U0 address to be mapped
  * @page: page (virt_to_page(to))
  */
-void copy_user_page(void *to, void *from, unsigned long address,
-		    struct page *page)
+void clear_user_page(void *to, unsigned long address, struct page *page)
 {
-	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0)
-		copy_page(to, from);
-	else {
-		unsigned long phys_addr = PHYSADDR(to);
-		unsigned long p3_addr = P3SEG + (address & CACHE_ALIAS);
-		pgd_t *pgd = pgd_offset_k(p3_addr);
-		pud_t *pud = pud_offset(pgd, p3_addr);
-		pmd_t *pmd = pmd_offset(pud, p3_addr);
-		pte_t *pte = pte_offset_kernel(pmd, p3_addr);
-		pte_t entry;
-		unsigned long flags;
+	clear_page(to);
 
-		entry = pfn_pte(phys_addr >> PAGE_SHIFT, PAGE_KERNEL);
-		mutex_lock(&p3map_mutex[(address & CACHE_ALIAS)>>12]);
-		set_pte(pte, entry);
-		local_irq_save(flags);
-		flush_tlb_one(get_asid(), p3_addr);
-		local_irq_restore(flags);
-		update_mmu_cache(NULL, p3_addr, entry);
-		__copy_user_page((void *)p3_addr, from, to);
-		pte_clear(&init_mm, p3_addr, pte);
-		mutex_unlock(&p3map_mutex[(address & CACHE_ALIAS)>>12]);
-	}
+	if (((address ^ (unsigned long)to) &
+	      current_cpu_data.dcache.alias_mask))
+		__flush_wback_region(to, PAGE_SIZE);
 }
+EXPORT_SYMBOL(clear_user_page);
diff --git a/include/asm-sh/cacheflush.h b/include/asm-sh/cacheflush.h
diff --git a/include/asm-sh/fixmap.h b/include/asm-sh/fixmap.h
index 458e9fa..8a56617 100644
--- a/include/asm-sh/fixmap.h
+++ b/include/asm-sh/fixmap.h
@@ -46,6 +46,9 @@
  * fix-mapped?
  */
 enum fixed_addresses {
+#define FIX_N_COLOURS 16
+	FIX_CMAP_BEGIN,
+	FIX_CMAP_END = FIX_CMAP_BEGIN + FIX_N_COLOURS,
 #ifdef CONFIG_HIGHMEM
 	FIX_KMAP_BEGIN,	/* reserved pte's for temporary kernel mappings */
 	FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
@@ -53,8 +56,8 @@ enum fixed_addresses {
 	__end_of_fixed_addresses
 };
 
-extern void __set_fixmap (enum fixed_addresses idx,
-					unsigned long phys, pgprot_t flags);
+extern void __set_fixmap(enum fixed_addresses idx,
+			 unsigned long phys, pgprot_t flags);
 
 #define set_fixmap(idx, phys) \
 		__set_fixmap(idx, phys, PAGE_KERNEL)
@@ -106,5 +109,4 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
 	BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
 	return __virt_to_fix(vaddr);
 }
-
 #endif
diff --git a/include/asm-sh/page.h b/include/asm-sh/page.h
index ac4b467..bb5bbec 100644
--- a/include/asm-sh/page.h
+++ b/include/asm-sh/page.h
@@ -71,10 +71,15 @@ extern void copy_page_nommu(void *to, void *from);
 #if defined(CONFIG_MMU) && (defined(CONFIG_CPU_SH4) || \
 	defined(CONFIG_SH7705_CACHE_32KB))
 struct page;
-extern void clear_user_page(void *to, unsigned long address, struct page *pg);
-extern void copy_user_page(void *to, void *from, unsigned long address, struct page *pg);
-extern void __clear_user_page(void *to, void *orig_to);
-extern void __copy_user_page(void *to, void *from, void *orig_to);
+struct vm_area_struct;
+void clear_user_page(void *to, unsigned long address, struct page *pg);
+void copy_user_page(void *to, void *from, unsigned long address,
+		    struct page *pg);
+#ifdef CONFIG_CPU_SH4
+void copy_user_highpage(struct page *to, struct page *from,
+	unsigned long vaddr, struct vm_area_struct *vma);
+#define __HAVE_ARCH_COPY_USER_HIGHPAGE
+#endif
 #elif defined(CONFIG_CPU_SH2) || defined(CONFIG_CPU_SH3) || !defined(CONFIG_MMU)
 #define clear_user_page(page, vaddr, pg)	clear_page(page)
 #define copy_user_page(to, from, vaddr, pg)	copy_page(to, from)
diff --git a/include/asm-sh/pgtable.h b/include/asm-sh/pgtable.h
index 3721a44..4d6c3b6 100644
--- a/include/asm-sh/pgtable.h
+++ b/include/asm-sh/pgtable.h
@@ -55,11 +55,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 
 #define PTE_PHYS_MASK		(0x20000000 - PAGE_SIZE)
 
-/*
- * First 1MB map is used by fixed purpose.
- * Currently only 4-entry (16kB) is used (see arch/sh/mm/cache.c)
- */
-#define VMALLOC_START	(P3SEG+0x00100000)
+#define VMALLOC_START	P3SEG
 #define VMALLOC_END	(FIXADDR_START-2*PAGE_SIZE)
 
 /*

Re: 2.6.20 instability

[Paul M. <pau...@re...>]

On Fri, Feb 02, 2007 at 11:48:43AM +0100, Manuel Lauss wrote:
> I don't run -git kernels so patch 1 is not applied anyway and
> without patch 2 the situation is much worse: 
> Kernel oopses every time a pcmcia ethernet card is inserted
> (cf cards are not affected or much less frequently).
> The difference is that for the ethernet card io ports are allocated
> starting from 0x300, while the cf card io ports start at 0x0.
> Also, the oops does not occur if the ethernet card is already in the
> socket when kernel boots. I can then also reapeatedly eject/insert
> it without problems.
> 
Can you post the log of the oops?

> > We're still not quite all the way there with the kmap_coherent() stuff
> > (and the move to copy_user_highpage()), so that's still going to take a
> > bit of work. While I think most of the page colouring problems are now
> > taken care of, it seems in the PG_dcache_dirty route we're _still_
> > missing some flushing that seems to break in certain paths regardless of
> > the kmap state.
> 
> I guess I should study the mm code more closely to understand all that :)
> 
The PG_dcache_dirty problem ended up being related to the fact that we
were just doing less flushing, which was causing troubles for IDE PIO in
the outsw()/insw() cases, adding some explicit dcache handling there like
we had for CONFIG_IDE fixed up those issues, so it's likely not related
to the problem you're seeing. Though that does seem to be the last
outstanding issue for PG_dcache_dirty..

Now the kmap mess is next on the list..

> What logs do you need?
> 
It would be interesting to know for starters whether your oops is IRQ
related or not? Any sort of debug output you can provide would be useful.
Oopsing if the card isn't available at boot time is certainly something
we need to fix.

Re: create sh-boot's git repository

[Paul M. <le...@li...>]

On Fri, Feb 02, 2007 at 11:30:38PM +0900, Nobuhiro Iwamatsu wrote:
> I create sh-boot's git repository.
>  http://git.nigauri.org
> 
> In git repository, a lot of boards are supported newly than cvs of sf.net.
> I plan to maintain this repository positively.
> 
DOYU-san also had quite a lot of new things merged in his arch tree, have
you consolidated with his work in this area also? (I have mirrors of this
if you need a copy of the source). There's still some consolidation that
needs to happen between those and the newer Renesas versions. In the
latter case, we have many ports hanging around that might be of general
interest (ie, Izanagi), even if there's no real push for the part itself.

The other concern is u-boot. We now have the SH7785 work which is somewhat
disjoint from the SH7343 port that was done some time ago, and then ST also
has their ST-40 port. We've also been looking at it for SH7756. This also
needs to be desperately consolidated before we have any _more_
fragmentation. I assume ST will also be open to rebasing their ST-40
stuff on top of generic SH support in u-boot.

Given that, is there really much point in dragging sh-boot along? Perhaps
it's best left in a maintenance-only mode for the existing users, with
the new ports leaning more towards u-boot.

Re: [PATCH] SHMIN's address of register different

[Paul M. <pau...@re...>]

On Fri, Feb 02, 2007 at 08:56:09PM +0900, Nobuhiro Iwamatsu wrote:
> SHMIN's address of register different.
> I append the patch to correct it. 
> 
Applied, thanks.

create sh-boot's git repository

[Nobuhiro I. <he...@t-...>]

Hi , all.

I create sh-boot's git repository.
 http://git.nigauri.org

In git repository, a lot of boards are supported newly than cvs of sf.net.
I plan to maintain this repository positively.

I welcome your suggestions for this topics.

regards,
 Nobuhiro.
--
Nobuhiro Iwamatsu
	E-Mail : he...@t-...
	GPG ID : 3170EBE9