Re: 3 questions about linux-2.4.18 and R3000

Re: 3 questions about linux-2.4.18 and R3000

[Jun Sun]

Alexandr Andreev wrote:

> 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.
> 


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)



> 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?
> 


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


> 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?
>


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

3 questions about linux-2.4.18 and R3000

[Alexandr Andreev]

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.

Re: 3 questions about linux-2.4.18 and R3000

[Alexandr Andreev]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Jun Sun wrote:

> 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

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 :(



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 990 bytes --]

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;
 

Re: 3 questions about linux-2.4.18 and R3000

[Jun Sun]

Alexandr Andreev wrote:

> Jun Sun wrote:
> 
>> 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
> 
> 
> OK, It works for me.
> 


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().


>>
>> 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 :(
> 


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

Re: 3 questions about linux-2.4.18 and R3000

[Alexandr Andreev]

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?

Re: 3 questions about linux-2.4.18 and R3000

[Gleb O. Raiko]

Jun Sun wrote:
> >>
> >> 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 :(
> >
> 
> 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.

"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 <ralf@oss.sgi.com>
To:            linux-mips@oss.sgi.com, linux-mips@fnet.fr

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 <ralf@oss.sgi.com>
To:            linux-mips@oss.sgi.com, linux-mips@fnet.fr

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.

Re: 3 questions about linux-2.4.18 and R3000

[Ralf Baechle]

On Fri, May 31, 2002 at 01:43:19PM +0400, Gleb O. Raiko wrote:

> > >> 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.

Some gcc 3.0 versions definately misscompiles the kernel; anyway 3.0 enjoys
a bad reputation for bugginess and being slow at generating slow code
beyond just the MIPS port, so why both with 3.0.  2.95.4 seems quite
reliable.

> > > I understand, but is there any __official__ recommended versions of these
> > > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :(

Send patches.

> > 
> > 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.
> 
> "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 

Nah, I don't consider myself an officer :-)

> Date:            Fri, 1 Dec 2000 03:06:19 +0100

[embarrasingly old email deleted ...]

The issues with newer toolchains have been discussed at various times on
the list; at this time I don't have a tested toolchain that is usable for
all configurations of the kernel.  Also note that my recommendation of
binutils 2.9.5 is only for the kernel.

Anyway, binutils 2.12 is looking promising so far ...

  Ralf

Re: 3 questions about linux-2.4.18 and R3000

[Maciej W. Rozycki]

On Mon, 3 Jun 2002, Ralf Baechle wrote:

> Some gcc 3.0 versions definately misscompiles the kernel; anyway 3.0 enjoys
> a bad reputation for bugginess and being slow at generating slow code
> beyond just the MIPS port, so why both with 3.0.  2.95.4 seems quite
> reliable.

 As gcc 3.1 is out, it may be worth checking.  I actually plan to do that
in not so distant future.

> The issues with newer toolchains have been discussed at various times on
> the list; at this time I don't have a tested toolchain that is usable for
> all configurations of the kernel.  Also note that my recommendation of
> binutils 2.9.5 is only for the kernel.
> 
> Anyway, binutils 2.12 is looking promising so far ...

 Well, 2.12.1 seem rock solid for me.  The package I made available at my
site only contains two patches that affect code (the rest is autoconf and
similar stuff) and then only MIPS64.  They can be safely discarded for
pure MIPS work.

 For MIPS64 they definitely do not work, OTOH, including the N32 ABI.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 3 questions about linux-2.4.18 and R3000

[Ralf Baechle]

On Mon, Jun 03, 2002 at 08:30:09PM +0200, Maciej W. Rozycki wrote:

>  Well, 2.12.1 seem rock solid for me.  The package I made available at my
> site only contains two patches that affect code (the rest is autoconf and
> similar stuff) and then only MIPS64.  They can be safely discarded for
> pure MIPS work.
> 
>  For MIPS64 they definitely do not work, OTOH, including the N32 ABI.

Are they good enough to build 64-bit kernels?

  Ralf

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

Ralf Baechle wrote:
> On Mon, Jun 03, 2002 at 08:30:09PM +0200, Maciej W. Rozycki wrote:
> 
> >  Well, 2.12.1 seem rock solid for me.  The package I made available at my
> > site only contains two patches that affect code (the rest is autoconf and
> > similar stuff) and then only MIPS64.  They can be safely discarded for
> > pure MIPS work.
> > 
> >  For MIPS64 they definitely do not work, OTOH, including the N32 ABI.
> 
> Are they good enough to build 64-bit kernels?

One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs
are zeroed out in a few cases where the assembler resolves them itself.
The rest works for me quite nice.


Thiemo


[1] http://sources.redhat.com/ml/binutils/2002-05/msg00188.html

Re: 3 questions about linux-2.4.18 and R3000

[Ralf Baechle]

On Tue, Jun 04, 2002 at 01:01:07AM +0200, Thiemo Seufer wrote:

> > >  For MIPS64 they definitely do not work, OTOH, including the N32 ABI.
> > 
> > Are they good enough to build 64-bit kernels?
> 
> One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs
> are zeroed out in a few cases where the assembler resolves them itself.
> The rest works for me quite nice.

Wonderful.  Due to the hackish way we're using to build 64-bit kernels
for the currently supported targets we don't run into this problems,
there are no R_MIPS_HIGHEST relocs ever.

  Ralf

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

Ralf Baechle wrote:
> On Tue, Jun 04, 2002 at 01:01:07AM +0200, Thiemo Seufer wrote:
> 
> > > >  For MIPS64 they definitely do not work, OTOH, including the N32 ABI.
> > > 
> > > Are they good enough to build 64-bit kernels?
> > 
> > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs
> > are zeroed out in a few cases where the assembler resolves them itself.
> > The rest works for me quite nice.
> 
> Wonderful.  Due to the hackish way we're using to build 64-bit kernels
> for the currently supported targets we don't run into this problems,
> there are no R_MIPS_HIGHEST relocs ever.

Well, for my I2 Impact I do. :-) I hope to get it running again with
the current kernel (plus my patches) in the next days.


Thiemo

Re: 3 questions about linux-2.4.18 and R3000

[Ralf Baechle]

On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote:

> > Wonderful.  Due to the hackish way we're using to build 64-bit kernels
> > for the currently supported targets we don't run into this problems,
> > there are no R_MIPS_HIGHEST relocs ever.
> 
> Well, for my I2 Impact I do. :-) I hope to get it running again with
> the current kernel (plus my patches) in the next days.

Interesting.  So you don't place the kernel into any of the 32-bit
compatibility address spaces on that machine?

  Ralf

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

Ralf Baechle wrote:
> On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote:
> 
> > > Wonderful.  Due to the hackish way we're using to build 64-bit kernels
> > > for the currently supported targets we don't run into this problems,
> > > there are no R_MIPS_HIGHEST relocs ever.
> > 
> > Well, for my I2 Impact I do. :-) I hope to get it running again with
> > the current kernel (plus my patches) in the next days.
> 
> Interesting.  So you don't place the kernel into any of the 32-bit
> compatibility address spaces on that machine?

Load address is 0xa800000020002000 (and my diff against CVS > 300k). :-)
I'm busy because of Linuxtag now, I think I have time to provide some
parts of this in about two weeks.


Thiemo

Re: 3 questions about linux-2.4.18 and R3000

[Gleb O. Raiko]

Ralf Baechle wrote:
> > > > I understand, but is there any __official__ recommended versions of these
> > > > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :(
> 
> Send patches.

Does anybody have ideas what the patch shall contain? In the other
words, what versions of binutils and gcc will be considered stable.


> Nah, I don't consider myself an officer :-)

Sure. :-)

Regards,
Gleb.

Re: 3 questions about linux-2.4.18 and R3000

[Maciej W. Rozycki]

On Mon, 3 Jun 2002, Ralf Baechle wrote:

> >  For MIPS64 they definitely do not work, OTOH, including the N32 ABI.
> 
> Are they good enough to build 64-bit kernels?

 Not yet.  For N32 gas complains about 64-bit immediates and fails.  For
64 there are a few problems I'm currently resolving, but the kernel links.
As N32 is low priority for me, I'll get 64 fixed first, at least to the
point non-PIC static executables such as Linux work.  PIC and dynamic
linking are next on my to-do list. 

 I'm working on 2.12.90, though, as the MIPS/ELF backend was positively
but extensively restructured, so the ultimate target is 2.13.  For plain
MIPS 2.12.90 seem OK. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 3 questions about linux-2.4.18 and R3000

[Maciej W. Rozycki]

On Tue, 4 Jun 2002, Thiemo Seufer wrote:

> One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs
> are zeroed out in a few cases where the assembler resolves them itself.
> The rest works for me quite nice.

 How about R_MIPS_26 relocs?  I discovered they are broken for the 64 ABI
(likely a RELA problem) and I am currently working on a fix.  As a result
of the bug a kernel executable is useless. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 3 questions about linux-2.4.18 and R3000

[Maciej W. Rozycki]

On Mon, 3 Jun 2002, Ralf Baechle wrote:

> Wonderful.  Due to the hackish way we're using to build 64-bit kernels
> for the currently supported targets we don't run into this problems,
> there are no R_MIPS_HIGHEST relocs ever.

 I've already cleaned up the crap in my tree and I'll make the changes
available as soon as I have a version of binutils that actually works. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 3 questions about linux-2.4.18 and R3000

[nick]

Do you have gfx working on i2 impact?  Is it also an R10k system, or are
you useing an r4k system?
	Thanks
		Nick

On Tue, 4 Jun 2002, Thiemo Seufer wrote:

> Ralf Baechle wrote:
> > On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote:
> > 
> > > > Wonderful.  Due to the hackish way we're using to build 64-bit kernels
> > > > for the currently supported targets we don't run into this problems,
> > > > there are no R_MIPS_HIGHEST relocs ever.
> > > 
> > > Well, for my I2 Impact I do. :-) I hope to get it running again with
> > > the current kernel (plus my patches) in the next days.
> > 
> > Interesting.  So you don't place the kernel into any of the 32-bit
> > compatibility address spaces on that machine?
> 
> Load address is 0xa800000020002000 (and my diff against CVS > 300k). :-)
> I'm busy because of Linuxtag now, I think I have time to provide some
> parts of this in about two weeks.
> 
> 
> Thiemo
> 

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

nick@snowman.net wrote:
> Do you have gfx working on i2 impact?

Nothing more than the firmware will do.

> Is it also an R10k system, or are
> you useing an r4k system?

IT's r10k. AFAIH the r4k systems have still ARCS32 and should be
able to boot a 32 bit kernel.


Thiemo

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Tue, 4 Jun 2002, Thiemo Seufer wrote:
> 
> > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs
> > are zeroed out in a few cases where the assembler resolves them itself.
> > The rest works for me quite nice.
> 
>  How about R_MIPS_26 relocs?  I discovered they are broken for the 64 ABI
> (likely a RELA problem) and I am currently working on a fix.  As a result
> of the bug a kernel executable is useless.

I forgot about this one, sorry. I have a patch for it, I think it will
go in for 2.13.


Thiemo

Re: 3 questions about linux-2.4.18 and R3000

[Ilya Volynets]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 05 June 2002 03:37 pm, Thiemo Seufer wrote:
> nick@snowman.net wrote:
> > Do you have gfx working on i2 impact?
>
> Nothing more than the firmware will do.
>
> > Is it also an R10k system, or are
> > you useing an r4k system?
>
> IT's r10k. AFAIH the r4k systems have still ARCS32 and should be
> able to boot a 32 bit kernel.
And how are you dealing with R10K speculative execution
in non-cache-coherent systems problem?

> Thiemo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8/qPR84S94bALfyURAiG0AKDoaTAi0vHNUpIO3ZRmL1NjLRHgOQCaA/En
/WCTs3jSjNdYBBN5KI8o7VE=
=0QL6
-----END PGP SIGNATURE-----

Re: 3 questions about linux-2.4.18 and R3000

[Thiemo Seufer]

Ilya Volynets wrote:
[snip]
> > > Is it also an R10k system, or are
> > > you useing an r4k system?
> >
> > IT's r10k. AFAIH the r4k systems have still ARCS32 and should be
> > able to boot a 32 bit kernel.
> And how are you dealing with R10K speculative execution
> in non-cache-coherent systems problem?

Not yet. I plan to modify the assembler for it.


Thiemo