linuxsh-dev

[linuxsh-dev] Another patch

[NIIBE Y. <gn...@m1...>]

Stuart Menefy wrote:
 > The problem we were seeing was that if a thread yield'ed, and the
 > new thread which was selected had never run before, then the yield
 > flag on the previous thread was never cleared, so it never got
 > rescheduled.
 > 
 > While I was at it I also added a missing call into syscall_trace for
 > the newly created task.

Please go ahead and install it.

BTW, with much help of Masahiro Abe (of RTLinux for SuperH fame), I
think that the kernel in CVS has been stabilized now again.  And the
exec-time (at least) is much improved.
-- 

[linuxsh-dev] Announcement : SynCE project

[Ludovic L. <lud...@fr...>]

Hello,

First of all sorry for the intrusion, but I think this may be of 
interest for some of you.



SynCE project's ambitious goal is to provide a mean of synchronising 
handhelds devices with a (desktop) computer.

By handheld, we mean any portable / embedded / PDA.... device, that 
needs to synchronize its data with a less mobile computer.
(An exemple would be any PDA/PocketPC running Windows CE, or any PDA 
running Linux, etc...)


The first step of this project is to provide a full (client & server) 
implementation of Microsoft's RAPI protocol, which is the low-level 
protocol used in ActiveSync synchronisation.
This will allow, when completed :
 - a Windows CE device to communicate with any (non-Microsoft) computer,
 - A Linux device to communicate with a Microsoft computer and benefits 
from the existing tools,
 - etc, etc...

The second step will be to provide a set of tools to synchronize data 
with 'standard' open or closed source application : Mozilla, KMail, etc....


Right now, the project is in its early, early stages ( we don't even 
have an alpha release ! ), but yet there are some bits that allow an 
implementation of the client part of the RAPI protocol, to query 
informations (registry, filesystem, databases,...) from a WindowsCE device.
One tool (DBBackup) allows a full dump of the databases of the device.


I won't interfere more with the list, and I invite all people interested 
to have a look on the project page ( 
http://www.sourceforge.net/projetcs/synce  & 
http://synce.sourceforge.net ) and to subscribe to the mailing-list.
We currently are looking for developper, and for testers having mobile 
devices still under Windows CE (PDA, PocketPC, etc...) and an unix-like 
desktop environment.


Best regards,

Ludovic LANGE

[linuxsh-dev] Another patch

[Stuart M. <Stu...@st...>]

Folks

Attached is a small patch which fixes some problems we've been having.

The problem we were seeing was that if a thread yield'ed, and the
new thread which was selected had never run before, then the yield
flag on the previous thread was never cleared, so it never got
rescheduled.

While I was at it I also added a missing call into syscall_trace for
the newly created task.

Any problems, let me know

Stuart

[linuxsh-dev] Re: "pte_clear" needed in copy_user_page? (was Re: System reset while INIT processing)

[Masahiro A. <m-...@aa...>]

On Tue, 17 Jul 2001 12:13:24 +0900
SUGIOKA Toshinobu <su...@it...> wrote:

> I hope that following patch will solve the problem.
> I'm not so sure that this is absolutely correct, but it will be safe anyway.

Thank you so much Sugioka-san, it works beautifully. 

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Re: "pte_clear" needed in copy_user_page? (was Re: System reset while INIT processing)

[SUGIOKA T. <su...@it...>]

At 10:55 01/07/17 +0900, Masahiro Abe <m-...@aa...> wrote:
>Current arch/sh/mm/cache.c in CVS gives me Oops error on our custom
>board, while INIT. (This doesn't happen on SolutionEngine 7750S.)
>
>Errors are "Unable to handle kernel paging request at virtual address
>c0000000", with address varies to c0001000/c0002000/c0003000. Errors
>occur at PC=8800c488, which is within __flush_dcache_region.
>
>copy_user_page and clear_user_page were modified to call pte_clear after
>copy_page/clear_page. If I comment this call out, then Oops errors
>disappear. (In fact, after comment out, the system is so stable so far
>that RTLinux is running reliably.)
>
>I still don't understand the reason of call to it, but I would like to
>know if it is necessary to call it or not. If it is, then what do you
>think I should do to kill this Oops error?

I hope that following patch will solve the problem.
I'm not so sure that this is absolutely correct, but it will be safe anyway.

Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.43
diff -u -r1.43 cache.c
--- arch/sh/mm/cache.c	2001/07/16 05:08:19	1.43
+++ arch/sh/mm/cache.c	2001/07/17 03:06:10
@@ -553,9 +553,9 @@
 		__flush_tlb_page(get_asid(), p3_addr);
 		update_mmu_cache(NULL, p3_addr, entry);
 		clear_page((void *)p3_addr);
+		__flush_dcache_region(p3_addr, p3_addr+PAGE_SIZE);
 		pte_clear(pte);
 		restore_flags(flags);
-		__flush_dcache_region(p3_addr, p3_addr+PAGE_SIZE);
 	}
 }
 
@@ -592,9 +592,9 @@
 		__flush_tlb_page(get_asid(), p3_addr);
 		update_mmu_cache(NULL, p3_addr, entry);
 		copy_page((void *)p3_addr, from);
+		__flush_dcache_region(p3_addr, p3_addr+PAGE_SIZE);
 		pte_clear(pte);
 		restore_flags(flags);
-		__flush_dcache_region(p3_addr, p3_addr+PAGE_SIZE);
 	}
 }
 #endif

----
SUGIOKA Toshinobu

[linuxsh-dev] "pte_clear" needed in copy_user_page? (was Re: System reset while INIT processing)

[Masahiro A. <m-...@aa...>]

Sugioka-san, Niibe-san and all,

Current arch/sh/mm/cache.c in CVS gives me Oops error on our custom
board, while INIT. (This doesn't happen on SolutionEngine 7750S.)

Errors are "Unable to handle kernel paging request at virtual address
c0000000", with address varies to c0001000/c0002000/c0003000. Errors
occur at PC=8800c488, which is within __flush_dcache_region.

copy_user_page and clear_user_page were modified to call pte_clear after
copy_page/clear_page. If I comment this call out, then Oops errors
disappear. (In fact, after comment out, the system is so stable so far
that RTLinux is running reliably.)

I still don't understand the reason of call to it, but I would like to
know if it is necessary to call it or not. If it is, then what do you
think I should do to kill this Oops error?

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Electric Fence problems

[Bao C. H. <ba...@se...>]

I am building the Electric Fence for an SH4, Bigsur.  It consistently fails
one of the test suite, eftest.

When memory is accessed at below the allocated space, it just hangs.
Crtl-C (SIGINT) will bring it back.  Gdb could not step through it.  Memory
access above the allocated space will return a SIGSEV, as expected.

Has anybody seen this behavior?  

Thanks.
Bao

[linuxsh-dev] Memory Leak?

[Masahiro A. <m-...@aa...>]

Hello,

Has anybody seen this kind of behavior with current CVS kernel?

1. repeatedly issuing "free", used memory size keeps increasing
slightly (about 24k byte). Even the HelloWorld wastes similar size of
memory.
2. after launching "bash" and exiting from it, used memory size
increases about 180k byte.
3. following script wastes 10 or more Megabytes, or worse, never finish.
(Taken from regression.sh of RTLinux 3.0)
-----
#! /bin/sh
s=`date`
CNT=1000
while [ ${CNT} != 0 ]; do
	CNT=`expr $CNT - 1`
	/bin/true
done
-----

Those occur on both SolutionEngine 7750S and our custom board.

None of those happen with 2.4.5 kernel with patches those I assembled.

I feel that there is some kind of memory leak in current CVS kernel. I'm
trying to figure out why, but I can't think of how to do that yet.

If you have any info, please let me know. I appreciate that.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] SH4 DMA

[Dustin M. <du...@se...>]

> +		if(irq >= BIGSUR_IRQ_LOW && irq < BIGSUR_IRQ_HIGH)
> +			enable_bigsur_l1irq(irq);
> +		else
> +			enable_bigsur_l2irq(irq);
> +	}
>  }
>
>  static unsigned int startup_bigsur_irq(unsigned int irq)
> diff -ruN linux-cvs0712/arch/sh/kernel/setup_cqreek.c
> linux-cvs0712+/arch/sh/kernel/setup_cqreek.c
> --- linux-cvs0712/arch/sh/kernel/setup_cqreek.c	Thu Jul 12
> 18:16:28 2001
> +++ linux-cvs0712+/arch/sh/kernel/setup_cqreek.c	Fri Jul 13
> 19:54:23 2001
> @@ -93,7 +93,8 @@
>
>  static void end_cqreek_irq(unsigned int irq)
>  {
> -	enable_cqreek_irq(irq);
> +	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
> +		enable_cqreek_irq(irq);
>  }
>
>  static unsigned int startup_cqreek_irq(unsigned int irq)
> diff -ruN linux-cvs0712/arch/sh/kernel/setup_dc.c
> linux-cvs0712+/arch/sh/kernel/setup_dc.c
> --- linux-cvs0712/arch/sh/kernel/setup_dc.c	Thu Jul 12 18:16:28 2001
> +++ linux-cvs0712+/arch/sh/kernel/setup_dc.c	Fri Jul 13 19:59:49 2001
> @@ -98,7 +98,8 @@
>  /* After a IRQ has been ack'd and responded to, it needs to be
> renabled */
>  static void end_systemasic_irq(unsigned int irq)
>  {
> -	enable_systemasic_irq(irq);
I noticed that DMA is supported for the SH's DMA channels in
arch/sh/kernel/dma.c.  It looks like dma.c can be built as a kernel module,
but the file doesn't seem to be built by the Makefiles.  Has the DMA code
been tested?  Is there a reason it doesn't get built into the kernel?  I've
got an audio peripheral that needs to use the DMA channels, but I'm unsure
whether the SH DMA code is working.

Dustin.

[linuxsh-dev] end_XXX_irq change (was Re: IRQ Autoprobing problem?)

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 17:17:29 +0900 (JST)
NIIBE Yutaka <gn...@m1...> wrote:

> The semantics has been changed.  I simply forgot to update
> irq_{imask,intc2,ipr}.c.  We need not to enable (unmask) the IRQ if
> it's disabled.  Your irq_maskreg.c needs similar change.  Please look at
> the change I've done (just committed).

I've found some more changes needed. Please apply if those are
appropriate.

-----
diff -ruN linux-cvs0712/arch/sh/kernel/irq_ipr.c linux-cvs0712+/arch/sh/kernel/irq_ipr.c
--- linux-cvs0712/arch/sh/kernel/irq_ipr.c	Thu Jul 12 18:22:32 2001
+++ linux-cvs0712+/arch/sh/kernel/irq_ipr.c	Fri Jul 13 19:46:43 2001
@@ -177,7 +177,8 @@
 
 static void end_pint_irq(unsigned int irq)
 {
-	enable_pint_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		enable_pint_irq(irq);
 }
 
 void make_pint_irq(unsigned int irq)
diff -ruN linux-cvs0712/arch/sh/kernel/setup_bigsur.c linux-cvs0712+/arch/sh/kernel/setup_bigsur.c
--- linux-cvs0712/arch/sh/kernel/setup_bigsur.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_bigsur.c	Fri Jul 13 19:57:29 2001
@@ -181,10 +181,12 @@
 static void end_bigsur_irq(unsigned int irq)
 {
    	DPRINTK("end_bigsur_irq IRQ %d\n", irq);
-	if(irq >= BIGSUR_IRQ_LOW && irq < BIGSUR_IRQ_HIGH)	
-		enable_bigsur_l1irq(irq);
-	else
-		enable_bigsur_l2irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) {
+		if(irq >= BIGSUR_IRQ_LOW && irq < BIGSUR_IRQ_HIGH)	
+			enable_bigsur_l1irq(irq);
+		else
+			enable_bigsur_l2irq(irq);
+	}
 }
 
 static unsigned int startup_bigsur_irq(unsigned int irq)
diff -ruN linux-cvs0712/arch/sh/kernel/setup_cqreek.c linux-cvs0712+/arch/sh/kernel/setup_cqreek.c
--- linux-cvs0712/arch/sh/kernel/setup_cqreek.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_cqreek.c	Fri Jul 13 19:54:23 2001
@@ -93,7 +93,8 @@
 
 static void end_cqreek_irq(unsigned int irq)
 {
-	enable_cqreek_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		enable_cqreek_irq(irq);
 }
 
 static unsigned int startup_cqreek_irq(unsigned int irq)
diff -ruN linux-cvs0712/arch/sh/kernel/setup_dc.c linux-cvs0712+/arch/sh/kernel/setup_dc.c
--- linux-cvs0712/arch/sh/kernel/setup_dc.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_dc.c	Fri Jul 13 19:59:49 2001
@@ -98,7 +98,8 @@
 /* After a IRQ has been ack'd and responded to, it needs to be renabled */
 static void end_systemasic_irq(unsigned int irq)
 {
-	enable_systemasic_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		enable_systemasic_irq(irq);
 }
 
 static unsigned int startup_systemasic_irq(unsigned int irq)
diff -ruN linux-cvs0712/arch/sh/kernel/setup_ec3104.c linux-cvs0712+/arch/sh/kernel/setup_ec3104.c
--- linux-cvs0712/arch/sh/kernel/setup_ec3104.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_ec3104.c	Fri Jul 13 20:02:35 2001
@@ -167,7 +167,8 @@
 
 static void end_ec3104_irq(unsigned int irq)
 {
-	unmask_ec3104_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		unmask_ec3104_irq(irq);
 }
 
 static unsigned int startup_ec3104_irq(unsigned int irq)
diff -ruN linux-cvs0712/arch/sh/kernel/setup_hd64461.c linux-cvs0712+/arch/sh/kernel/setup_hd64461.c
--- linux-cvs0712/arch/sh/kernel/setup_hd64461.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_hd64461.c	Fri Jul 13 20:09:59 2001
@@ -57,7 +57,8 @@
 
 static void end_hd64461_irq(unsigned int irq)
 {
-	enable_hd64461_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		enable_hd64461_irq(irq);
 }
 
 
diff -ruN linux-cvs0712/arch/sh/kernel/setup_hd64465.c linux-cvs0712+/arch/sh/kernel/setup_hd64465.c
--- linux-cvs0712/arch/sh/kernel/setup_hd64465.c	Thu Jul 12 18:16:28 2001
+++ linux-cvs0712+/arch/sh/kernel/setup_hd64465.c	Fri Jul 13 20:10:16 2001
@@ -70,7 +70,8 @@
 
 static void end_hd64465_irq(unsigned int irq)
 {
-	enable_hd64465_irq(irq);
+	if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
+		enable_hd64465_irq(irq);
 }
 
 
-----

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Fri, 13 Jul 2001 15:02:34 +0900
Masahiro Abe <m-...@aa...> wrote:

> On Fri, 13 Jul 2001 14:48:47 +0900
> SUGIOKA Toshinobu <su...@it...> wrote:
> 
> > that patch flashes before adding new temporal TLB entry, but it might better to flash immediately after
> > copy/clear memory.
> 
> So this means that instead of calling __flush_tlb_page BEFORE
> update_mmu_cache, we should call it AFTER copy_page? I'm gonna try that.

Simply moving __flush_tlb_page call after copy_page call didn't work.
Maybe I'm doing something stupid.

I can go with original Sugioka-san's patch for now.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Re: [linux-sh:01781] Re: SH4 hardware problem

[<bar...@ya...>]

Gareth:

Thanks for the tips. It provides instant boot up
without worrying about external memories.

However, I went a step further. Since I am not good at
using GDB. I wrote a small procedure in sh-ipl+g and a
PC software that talks on serial line. The combination
loads a binary file (sh executable file mapped on to
part of the cache ram) on to the spare area of the
cache ram. Upon completion of downloading the binary,
sh-ipl+g jumps to the starting address of the download
binary and start executing the file as a procedure.

The downloaded binary has to be small enough to fit
into the cache ram (it is basically just entry.S and
main.c). This binary sets up SDRAM (all neccessary
parameters only) and does SDRAM memory read-write test
within the requested block then it outputs the results
back to PC on serial line. 
Well, this may sound complex, but it is just a work
around for me to avoid using GDB.

Thanks for the tip again.

Mark.


_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Fri, 13 Jul 2001 14:48:47 +0900
SUGIOKA Toshinobu <su...@it...> wrote:

> At 14:03 01/07/13 +0900, Masahiro Abe <m-...@aa...> wrote:
> 
> >I would like to ask you about this patch. Is this real fix, or (kind of)
> >hiding the problem caused by another source? Sorry if this sounds silly,
> >I still don't understand the fundamentals of MMU and cache.
> 
> 'copy_user_page/clear_user_page' creates temporal TLB entry to avoid cache alias issue on some situation.
> and uses temporal virtual address (in P3) instead of requested address (in U0).
> 
> This entry should be flashed before adding next temporal TLB entry on this virtual address,
> otherwise multiple TLB hit will occur.

Thank you for your detailed explanation. It will help me a lot to
understand the situation.

> that patch flashes before adding new temporal TLB entry, but it might better to flash immediately after
> copy/clear memory.

So this means that instead of calling __flush_tlb_page BEFORE
update_mmu_cache, we should call it AFTER copy_page? I'm gonna try that.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Re: System reset while INIT processing

[SUGIOKA T. <su...@it...>]

At 14:03 01/07/13 +0900, Masahiro Abe <m-...@aa...> wrote:
>
>> Does this patch change your situation ?
>
>Yes, now the system passes INIT process and I could log in. I can say
>this patch fixes the problem. Sugioka-san, Thank you so much!
>

Good!!

>I would like to ask you about this patch. Is this real fix, or (kind of)
>hiding the problem caused by another source? Sorry if this sounds silly,
>I still don't understand the fundamentals of MMU and cache.
>

'copy_user_page/clear_user_page' creates temporal TLB entry to avoid cache alias issue on some situation.
and uses temporal virtual address (in P3) instead of requested address (in U0).

This entry should be flashed before adding next temporal TLB entry on this virtual address,
otherwise multiple TLB hit will occur.

that patch flashes before adding new temporal TLB entry, but it might better to flash immediately after
copy/clear memory.


----
SUGIOKA Toshinobu

[linuxsh-dev] Re: [linux-sh:01814] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

Thank you Sugioka-san.

On Fri, 13 Jul 2001 13:30:16 +0900
SUGIOKA Toshinobu <su...@it...> wrote:

> Does this patch change your situation ?

Yes, now the system passes INIT process and I could log in. I can say
this patch fixes the problem. Sugioka-san, Thank you so much!

I would like to ask you about this patch. Is this real fix, or (kind of)
hiding the problem caused by another source? Sorry if this sounds silly,
I still don't understand the fundamentals of MMU and cache.

BTW, power-up-to-login-prompt time became much shorter than 2.4.5 kernel.
I feel like it's become less than one-third (1/3).
This is the reason why I wanted to upgrade to the CVS kernel.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: System reset while INIT processing

[SUGIOKA T. <su...@it...>]

At 11:18 01/07/13 +0900, Masahiro Abe <m-...@aa...> wrote:
>Some more reports.
>- calling sequence until reboot is
>  copy_user_page(arch/sh/mm/cache.c)
>    +-update_mmu_cache(arch/sh/mm/fault.c)
>    +-copy_page : #defined as memcpy(arch/sh/lib/memcpy.S)
>  Last two functions are called at line 588 and 589 of cache.c,
>  respectively.
>- most of the time, exception occurs at line 86 of memcpy.S, which is
>	mov.l	r1,@-r0
>  at this time, @r0=0xc0002ffc
>- TEA has 0xc0002ffc at the time of exception/reboot. So, this is
>  multiple data TLB hit exception.
>- 0xc0002ffc is within the area that p3_cache_init allocated with
>  remap_area_pages. This area is from 0xc0000000 to 0xc0003fff.

Does this patch change your situation ?

Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.41
diff -u -r1.41 cache.c
--- arch/sh/mm/cache.c	2001/07/12 06:27:37	1.41
+++ arch/sh/mm/cache.c	2001/07/13 04:21:45
@@ -18,6 +18,7 @@
 #include <asm/cache.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
+#include <asm/mmu_context.h>
 
 #if defined(__sh3__)
 #define CCR		0xffffffec	/* Address of Cache Control Register */
@@ -519,6 +520,8 @@
 /* Page is 4K, OC size is 16K, there are four lines. */
 #define CACHE_ALIAS 0x00003000
 
+extern void __flush_tlb_page(unsigned long asid, unsigned long page);
+
 /*
  * clear_user_page
  * @to: P1 address
@@ -548,6 +551,7 @@
 		save_and_cli(flags);
 		entry = mk_pte_phys(phys_addr, pgprot);
 		set_pte(pte, entry);
+		__flush_tlb_page(get_asid(), p3_addr&PAGE_MASK);
 		update_mmu_cache(NULL, p3_addr, entry);
 		clear_page((void *)p3_addr);
 		restore_flags(flags);
@@ -585,6 +589,7 @@
 		save_and_cli(flags);
 		entry = mk_pte_phys(phys_addr, pgprot);
 		set_pte(pte, entry);
+		__flush_tlb_page(get_asid(), p3_addr&PAGE_MASK);
 		update_mmu_cache(NULL, p3_addr, entry);
 		copy_page((void *)p3_addr, from);
 		restore_flags(flags);
Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.40
diff -u -r1.40 fault.c
--- arch/sh/mm/fault.c	2001/07/06 13:11:32	1.40
+++ arch/sh/mm/fault.c	2001/07/13 04:21:46
@@ -28,7 +28,7 @@
 #include <asm/mmu_context.h>
 
 extern void die(const char *,struct pt_regs *,long);
-static void __flush_tlb_page(unsigned long asid, unsigned long page);
+void __flush_tlb_page(unsigned long asid, unsigned long page);
 
 /*
  * Ugly, ugly, but the goto's result in better assembly..
@@ -322,7 +322,7 @@
 	restore_flags(flags);
 }
 
-static void __flush_tlb_page(unsigned long asid, unsigned long page)
+void __flush_tlb_page(unsigned long asid, unsigned long page)
 {
 	unsigned long addr, data;
 

----
SUGIOKA Toshinobu

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 22:14:54 +0900
Masahiro Abe <m-...@aa...> wrote:

> Sorry for too much posts today. Hopefully this will be today's last one.
> 
> I've learned how to use JTAG debugger, and managed to get some
> information at system reboot. This is what I've found:
> When reboot (PC<-0xa0000000),
> - SPC points inside memcpy(arch/sh/lib/memcpy.S), but the exact address
> changes time to time.
> - EXPEVT is 0x140, which is multiple TLB(either data or instruction) hit
> exception.
> - If it means something, both SR and SSR are 0x700000F1
> 
> I can't interpret those yet. If anyone have thought about something
> related, I deadly would like to know.

Some more reports.
- calling sequence until reboot is
  copy_user_page(arch/sh/mm/cache.c)
    +-update_mmu_cache(arch/sh/mm/fault.c)
    +-copy_page : #defined as memcpy(arch/sh/lib/memcpy.S)
  Last two functions are called at line 588 and 589 of cache.c,
  respectively.
- most of the time, exception occurs at line 86 of memcpy.S, which is
	mov.l	r1,@-r0
  at this time, @r0=0xc0002ffc
- TEA has 0xc0002ffc at the time of exception/reboot. So, this is
  multiple data TLB hit exception.
- 0xc0002ffc is within the area that p3_cache_init allocated with
  remap_area_pages. This area is from 0xc0000000 to 0xc0003fff.

I still can't understand what is causing this exception, and why this
doesn't happen on SolutionEngine or other SH4 system.
I appreciate any input on this.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Fri, 13 Jul 2001 09:31:31 +0900
kaz Kojima <kk...@rr...> wrote:

> You have only to update binutils and glibc.
> 
> The new ABI changes PLT. So it makes binary imcompatibility on
> shared libraries and all dynamically linked programs which use
> PLT. But the new ld.so in glibc can handle old/new objects at
> the same time and you have not to recompile shared libraries and
> userland programs at all.
> Of course, kernel doesn't use PLT and is never affected this
> ABI change.

Thank you. Now I understand that:

-My problem is not related to ABI change issue, so I can update binutils
and glibc later.
-When I need to update, I only have to do it on binutils and glibc. No
code change needed for gcc, other libraries, kernel. I don't have to
rebuild them, but I can.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: System reset while INIT processing

[kaz K. <kk...@rr...>]

Masahiro Abe <m-...@aa...> wrote:
>> It affects shared libraries only.
> 
> I'm sorry but I can't understand this.
> 
> Should I update my gcc+glibc for ABI change, and rebuild CVS kernel,
> glibc, other libraries, and all userland programs?
>
> Or
> 
> Should I update my gcc+glibc for ABI change, and rebuild CVS kernel,
> glibc and other libraries, but NOT userland programs?
> 
> Or
> 
> ABI change is not needed for CVS kernel and glibc?

You have only to update binutils and glibc.

The new ABI changes PLT. So it makes binary imcompatibility on
shared libraries and all dynamically linked programs which use
PLT. But the new ld.so in glibc can handle old/new objects at
the same time and you have not to recompile shared libraries and
userland programs at all.
Of course, kernel doesn't use PLT and is never affected this
ABI change.

	kaz

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

Hello Kojima-san, thank you for your comment.

On Thu, 12 Jul 2001 22:39:35 +0900
kaz Kojima <kk...@rr...> wrote:

> Hi,
> 
> Masahiro Abe <m-...@aa...> wrote:
> > Just as small thing that came to my mind.
> > I'm using glibc which is built with kernel 2.4.5 and gcc w/o
> > Kojima-san's ABI change. Could this be the source of the problem? Should
> > I rebuild glibc, or incorporate ABI change for current kernel?
> > I guess those are not needed, but just wanted to make sure.
> 
> It affects shared libraries only.

I'm sorry but I can't understand this.

Should I update my gcc+glibc for ABI change, and rebuild CVS kernel,
glibc, other libraries, and all userland programs?

Or

Should I update my gcc+glibc for ABI change, and rebuild CVS kernel,
glibc and other libraries, but NOT userland programs?

Or

ABI change is not needed for CVS kernel and glibc?

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: System reset while INIT processing

[kaz K. <kk...@rr...>]

Hi,

Masahiro Abe <m-...@aa...> wrote:
> Just as small thing that came to my mind.
> I'm using glibc which is built with kernel 2.4.5 and gcc w/o
> Kojima-san's ABI change. Could this be the source of the problem? Should
> I rebuild glibc, or incorporate ABI change for current kernel?
> I guess those are not needed, but just wanted to make sure.

It affects shared libraries only.

	kaz

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

Sorry for too much posts today. Hopefully this will be today's last one.

I've learned how to use JTAG debugger, and managed to get some
information at system reboot. This is what I've found:
When reboot (PC<-0xa0000000),
- SPC points inside memcpy(arch/sh/lib/memcpy.S), but the exact address
changes time to time.
- EXPEVT is 0x140, which is multiple TLB(either data or instruction) hit
exception.
- If it means something, both SR and SSR are 0x700000F1

I can't interpret those yet. If anyone have thought about something
related, I deadly would like to know.

---
Just as small thing that came to my mind.
I'm using glibc which is built with kernel 2.4.5 and gcc w/o
Kojima-san's ABI change. Could this be the source of the problem? Should
I rebuild glibc, or incorporate ABI change for current kernel?
I guess those are not needed, but just wanted to make sure.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: IRQ Autoprobing problem? (was Re : System reset while INIT processing)

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 17:17:29 +0900 (JST)
NIIBE Yutaka <gn...@m1...> wrote:

> Masahiro Abe wrote:
>  > What is the proper way to solve this problem? Has anybody seen this?
>  > What did you do then? Or, my assumption is not correct?
>  > I appreciate any input.
> 
> The semantics has been changed.  I simply forgot to update
> irq_{imask,intc2,ipr}.c.  We need not to enable (unmask) the IRQ if
> it's disabled.  Your irq_maskreg.c needs similar change.  Please look at
> the change I've done (just committed).
> 
> Thanks a lot for your report.

Thanks! IRQ auto-probing is working now.

Somehow, it became that INIT can go further before reboot than before
applying this change. These may be related...

-----
BTW, I see the message from "make" that "cyclic dependencies between
include/linux/bootmem.h and include/linux/mmzone.h has been discarded"
(I see this message in Japanese, so the exact wording may be different).
Is this related to discontiguous memory support?

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] IRQ Autoprobing problem? (was Re : System reset while INIT processing)

[NIIBE Y. <gn...@m1...>]

Masahiro Abe wrote:
 > What is the proper way to solve this problem? Has anybody seen this?
 > What did you do then? Or, my assumption is not correct?
 > I appreciate any input.

The semantics has been changed.  I simply forgot to update
irq_{imask,intc2,ipr}.c.  We need not to enable (unmask) the IRQ if
it's disabled.  Your irq_maskreg.c needs similar change.  Please look at
the change I've done (just committed).

Thanks a lot for your report.
-- 

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 16:22:34 +0900 (JST)
NIIBE Yutaka <gn...@m1...> wrote:

> Masahiro Abe wrote:
>  > No, it didn't work. It's got relatively backward, seldom see the message
>  > from INIT.
> 
> Then, what you see is another bug.  In my environments (CqREEK &
> SolutionEngine), it works fine now.
> 
> The email attached may be related to your issue.

Thank you for the info. It seems like not related to my problem. I've
tried, had no luck.
But it may fix the problem that Dustin is having.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+