Subject: 3 questions about linux-2.4.18 and R3000

From: Alexandr Andreev <[email-masked]>
Date: Fri, 24 May 2002 18:16:09 -0400

Hi, list.
I have three little questions with linux-2.4.18 on my machine.

My configuration is:
MIPS R3000, linux-2.4.18 kernel from CVS,
egcs-mips-linux-1.1.2-4 (egcs-2.91.66) and binutils-mips-linux-2.8.1-2

1. When i use MIPS specific arch_get_unmapped_area() function, my kernel
  hangs. It looks like this:
  ...
  Freeing unused kernel memory: 108k freed
  do_page_fault() #2: sending SIGSEGV to init for illegal read access 
from       
  0fb65330 (epc == 0fb65330, ra == 0fb851dc)
  ... and so on. Last message is printed infinitely.

  So, i have to give up HAVE_ARCH_UNMAPPED_AREA feature, and to use
  common arch_get_unmapped_area() routine.

2. There is a strange code in the local_flush_tlb_page() function
  (tlb-r3k.c and tlb-r4k.c):
     ...
         if (!vma || vma->vm_mm->context != 0) {
               unsigned long flags;
               int oldpid, newpid, idx;
  #ifdef DEBUG_TLB
               printk("[tlbpage<%lu,0x%08lx>]", vma->vm_mm->context, page);
  #endif
               newpid = (vma->vm_mm->context & 0xfc0);
                         ^^^^^
  Hmm... the kernel will crash if vma ==0. I guess that this code must look
  like this:

         if (vma && vma->vm_mm->context !=0) {
 
  Is any patches required?

3. I have some problems, when i try to compile latest kernels with my egcs
  and binutils, such as problems with "__INIT" and "__FINI" assembler 
macroses:

  # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0
   -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c entry.S -o entry.o
  entry.S: Assembler messages:
  entry.S:179: Error: .previous without corresponding .section; ignored

  ... and ".macro" assembler command usage:

  # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0 
   -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c head.S -o head.o
  head.S: Assembler messages:
  head.S:224: Error: .size expression too complicated to fix up
  head.S:224: Error: .size expression too complicated to fix up
  head.S:224: Error: .size expression too complicated to fix up
  head.S:224: Error: .size expression too complicated to fix up
  make[1]: *** [head.o] Error 1

  I know that my binutils are obsolete and so, I tried to use some newer
   binutils (2.9.5-1, 2.9.5-3), but my kernel crashed :(. Please, can 
you answer
   me, what egcs & binutils are suitable for linux-2.4.18 and MIPS R3000
   compliant?

  Any help will be appriciated.

---

From: Jun Sun <[email-masked]>
Date: Fri, 24 May 2002 14:10:55 -0700

Alexandr Andreev wrote:

> from        0fb65330 (epc == 0fb65330, ra == 0fb851dc)

I took a look of the arch_get_unmapped_area(),  and it looks fine to me.

Can you try the following changes and let me know what happens?

1) change COLOUR_ALIGN
#define COLOUR_ALIGN(addr,pgoff) 	addr

2) I don't understand why we need color alignment if file is not NULL.  (Can 
someone explain?).  So you can try to remove that condition:

diff -Nru ./arch/mips/kernel/syscall.c.orig ./arch/mips/kernel/syscall.c
--- ./arch/mips/kernel/syscall.c.orig   Sat May 11 00:05:34 2002
+++ ./arch/mips/kernel/syscall.c        Fri May 24 13:54:47 2002
@@ -77,7 +77,7 @@
         if (len > TASK_SIZE)
                 return -ENOMEM;
         do_color_align = 0;
-       if (filp || (flags & MAP_SHARED))
+       if (flags & MAP_SHARED)
                 do_color_align = 1;
         if (addr) {
                 if (do_color_align)

>         if (vma && vma->vm_mm->context !=0) {

I think you just found a bug.  The fix looks good to me.

>   binutils (2.9.5-1, 2.9.5-3), but my kernel crashed :(. Please, can you 
> answer

We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for quite a 
while with no problems.  It seems newer gcc and binutiles are fine too.

Jun

---

From: Alexandr Andreev <[email-masked]>
Date: Mon, 27 May 2002 17:13:33 -0400

> #define COLOUR_ALIGN(addr,pgoff)     addr

OK, It works for me.

>
> We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for 
> quite a  while with no problems.  It seems newer gcc and binutiles are 
> fine too.
>
I understand, but is there any __official__ recommended versions of these
utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :(

diff -pru linux_2_4_18_orig/arch/mips/mm/tlb-r3k.c linux_2_4_18/arch/mips/mm/tlb-r3k.c
--- linux_2_4_18_orig/arch/mips/mm/tlb-r3k.c	Fri Apr 26 07:50:07 2002
+++ linux_2_4_18/arch/mips/mm/tlb-r3k.c	Mon May 27 16:36:14 2002
@@ -118,7 +118,7 @@ void local_flush_tlb_range(struct mm_str
 
 void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page)
 {
-	if (!vma || vma->vm_mm->context != 0) {
+	if (vma && vma->vm_mm->context) {
 		unsigned long flags;
 		int oldpid, newpid, idx;
 
diff -pru linux_2_4_18_orig/arch/mips/mm/tlb-r4k.c linux_2_4_18/arch/mips/mm/tlb-r4k.c
--- linux_2_4_18_orig/arch/mips/mm/tlb-r4k.c	Fri Apr 26 07:50:07 2002
+++ linux_2_4_18/arch/mips/mm/tlb-r4k.c	Mon May 27 16:31:45 2002
@@ -140,7 +140,7 @@ void local_flush_tlb_range(struct mm_str
 
 void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page)
 {
-	if (!vma || vma->vm_mm->context != 0) {
+	if (vma && vma->vm_mm->context) {
 		unsigned long flags;
 		int oldpid, newpid, idx;

---

From: Jun Sun <[email-masked]>
Date: Tue, 28 May 2002 10:15:55 -0700

>> #define COLOUR_ALIGN(addr,pgoff)     addr

That indicate the logic of function works.

So the problems might lie on something else:

1) some caller pass in non-zero addr but does not check the return addr and 
assume the addr remains the same.

2) given the reported toolchain, I will double-check to see if COLOUR_ALIGN() 
is compiled correctly.  It is mildly complex.

I would be also interested to know if removing filp condition would solve your 
problem.  Nobody has explained why this condition is needed for doing 
COLOUR_ALIGN().

> utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :(

Who are the "officiers" to decide on __official__ versions? :-)  If you are 
really uncomfortable with non-official stuff, you might want to consider 
paying some vendor and I am sure you will be given an "official" version.

Jun

---

From: Alexandr Andreev <[email-masked]>
Date: Wed, 29 May 2002 20:18:39 -0400

Jun Sun wrote:

>
> I would be also interested to know if removing filp condition would 
> solve your problem.  Nobody has explained why this condition is needed 
> for doing COLOUR_ALIGN().
>
Removing of filp condition solves the problem too. So, as I understand, I
need to remove filp condition instead of fix COLOUR_ALIGN(), isn't it?
And what about that patch of local_flush_tlb_page(), will anybody apply it
to CVS?

---

From: "Gleb O. Raiko" <[email-masked]>
Date: Fri, 31 May 2002 13:43:19 +0400

> paying some vendor and I am sure you will be given an "official" version.

"Official" means "if I report a bug w/o a patch in this list, I don't
get a message which requests to change the tools". 

I think, Ralf is the "officier" who decides what the right toolchain is.
Now, last toolchain Ralf announced was 

- binutils

Date:            Fri, 1 Dec 2000 03:06:19 +0100
From:            Ralf Baechle <[email-masked]>
To:            [email-masked], [email-masked]

Binutils were buggy handling a cases involving empty object files.  I've
uploaded fixed binutils 2.8.1 cross-linker packages to oss.sgi.com; 
I'll
upload fixed binutils 2.9.5 binaries (mips64 only) later.  The
worarounds
for this bug have been removed from the CVS archive that is updating is
required for building a current 2.4 kernel.

  Ralf

- compiler

Subject:            New crosscompilers
Date:            Wed, 18 Apr 2001 18:42:07 -0300
From:            Ralf Baechle <[email-masked]>
To:            [email-masked], [email-masked]

I've uploaded new egcs 1.1.2 based crosscompiler to oss.sgi.com into
/pub/linux/mips/crossdev/.  The only change for version 1.1.2-4 affects
mips64-linux and mips64el-linux targets where asking for alignments
larger than 8 bytes was ignored with a warning message.  This did
possibly result in some performance penalty for mips64 kernels.

  Ralf

The faq does mention this toolchain still.

Ralf, are you going to announce new toolchain given the lastest kernel
can't be compiled with old one? Or shall we change back the sources?

Regards,
Gleb.