From owner-linux-mips@oss.sgi.com Mon Jan 1 06:25:47 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 06:25:27 -0800 Received: from blackdog.wirespeed.com ([208.170.106.25]:18451 "EHLO blackdog.wirespeed.com") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 06:25:07 -0800 Received: from redhat.com (IDENT:joe@dhcp-252.wirespeed.com [172.16.17.252] (may be forged)) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id IAA23957; Mon, 1 Jan 2001 08:17:23 -0600 Message-ID: <3A5092A7.1060304@redhat.com> Date: Mon, 01 Jan 2001 08:22:31 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Steven J. Hill" CC: linux-mips@oss.sgi.com Subject: Re: Simple problem with second stage MIPS GCC compiler... References: <3A2FB3CB.3566F805@mips.com> <3A5018A0.6B43960B@cotw.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing The problem you have is that gcc doesn't know where the glibc headers are. You probably need to pass "--with-includes=/usr/local/mips/mipsel-linux-include" or alternatively put the headers in {prefix}/sys-include . There is also another list for cross compiling with gcc (crossgcc@sources.redhat.com) which might give more informative answers than the simple one I have... good luck with it! Steven J. Hill wrote: > Well, I almost have a complete toolchain. I succesfully got binutils, > first stage GCC-2.95.2 and GLIBC-2.2 installed just fine. I am having > problems with rebuilding GCC. Below is the configuration and make > directives that I am currently using along with the output. I have > verified that the header files are in /usr/local/mips/mipsel-linux-include. > Any help or thoughts are need and appreciated. Yes, I read the mailing > list archives. TIA. > > -Steve > > ************************************************************* > AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib ../gcc-2.95.2/configure > --prefix=/usr/local/mips --target=mipsel-linux i686-pc-linux-gnu --enable-shared > --enable-threads --enable-languages=c > > make LANGUAGES=c ALL_TARGET_MODULES= CONFIGURE_TARGET_MODULES= > INSTALL_TARGET_MODULES= SUBDIRS="libiberty gcc" > > ************************************************************* > make[2]: Leaving directory `/data/mips-stuff/build-gcc2/gcc/intl' > rm -f tmplibgcc2.a > for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _ashldi3 > _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf > _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi > _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf __gcc_bcmp > _varargs __dummy _eprintf _bb _shtab _clear_cache _trampoline __main _exit > _ctors _pure; \ > do \ > echo ${name}; \ > /data/mips-stuff/build-gcc2/gcc/xgcc -B/data/mips-stuff/build-gcc2/gcc/ > -B/usr/local/mips/mipsel-linux/bin/ -I/usr/local/mips/mipsel-linux/include -O2 > -DCROSS_COMPILE -DIN_GCC -g -O2 -I./include -fPIC -g1 -DHAVE_GTHR_DEFAULT > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I../../gcc-2.95.2/gcc > -I../../gcc-2.95.2/gcc/config -I../../gcc-2.95.2/gcc/../include -c -DL${name} \ > ../../gcc-2.95.2/gcc/libgcc2.c -o ${name}.o; \ > if [ $? -eq 0 ] ; then true; else exit 1; fi; \ > mipsel-linux-ar rc tmplibgcc2.a ${name}.o; \ > rm -f ${name}.o; \ > done > _muldi3 > .../../gcc-2.95.2/gcc/libgcc2.c:41: stdlib.h: No such file or directory > .../../gcc-2.95.2/gcc/libgcc2.c:42: unistd.h: No such file or directory > make[1]: *** [libgcc2.a] Error 1 > make[1]: Leaving directory `/data/mips-stuff/build-gcc2/gcc' > make: *** [all-gcc] Error 2 -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From owner-linux-mips@oss.sgi.com Tue Jan 2 10:24:25 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 10:24:15 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:18322 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 10:24:04 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA24269; Tue, 2 Jan 2001 19:12:58 +0100 (MET) Date: Tue, 2 Jan 2001 19:12:57 +0100 (MET) From: "Maciej W. Rozycki" To: Harald Koerfgen cc: ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: SGI/ARCS related fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Sun, 31 Dec 2000, Harald Koerfgen wrote: > wanting to bring my O2 patches up to date I stumbled over some minor hickups. [...] > --- /nfs/cvs/linux-2.3/linux/arch/mips/arc/memory.c Mon Dec 11 18:07:34 2000 > +++ linux/arch/mips/arc/memory.c Sat Dec 30 21:49:32 2000 > @@ -124,7 +124,7 @@ > size = p->pages << PAGE_SHIFT; > type = prom_memtype_classify(p->type); > > - add_memory_region(base, pages, type); > + add_memory_region(base, size, type); > } > } > That is fine. I actually included the fix in my set of memory map patches (patch-mips-2.4.0-test11-20001212-mem_map-37) I sent Ralf a few days ago. They still appear to wait to be applied. > @@ -143,12 +143,13 @@ > addr = boot_mem_map.map[i].addr; > while (addr < boot_mem_map.map[i].addr > + boot_mem_map.map[i].size) { > - ClearPageReserved(virt_to_page(__va(addr))); > - set_page_count(virt_to_page(__va(addr)), 1); > - free_page(__va(addr)); > + ClearPageReserved(virt_to_page(addr)); > + set_page_count(virt_to_page(addr), 1); > + free_page(addr); > addr += PAGE_SIZE; > freed += PAGE_SIZE; > } > } > printk("Freeing prom memory: %ldkb freed\n", freed >> 10); > } > + That's probably incorrect. These functions expect a virtual address while "addr" is a physical address. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jan 2 16:52:17 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 16:52:07 -0800 Received: from gateway-1237.mvista.com ([12.44.186.158]:51705 "EHLO hermes.mvista.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 16:51:46 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f030nSC25232; Tue, 2 Jan 2001 16:49:28 -0800 Message-ID: <3A5277C6.89170BAD@mvista.com> Date: Tue, 02 Jan 2001 16:52:22 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: missing data cache flush in trap_init? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Ralf, Someone reported this bug to me. I think it is a valid one. Basically trap_init() installs the vectors through kseg0 address and then flushes icache. It is possible that the vectors are still in the data cache and not written back to memory yet. If an exception happens it may get the corrupted the vector value. The following patch should fix it. I am not sure if I can use flush_cache_range() to have potentially better performance. Jun --- linux/arch/mips/kernel/traps.c.orig Tue Jan 2 16:24:16 2001 +++ linux/arch/mips/kernel/traps.c Tue Jan 2 16:50:59 2001 @@ -767,7 +767,7 @@ default: panic("Unknown CPU type"); } - flush_icache_range(KSEG0, KSEG0 + 0x200); + flush_cache_all(); atomic_inc(&init_mm.mm_count); /* XXX UP? */ current->active_mm = &init_mm; From owner-linux-mips@oss.sgi.com Wed Jan 3 03:32:33 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 03:32:13 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:35738 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 03:31:49 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA21067; Wed, 3 Jan 2001 12:29:18 +0100 (MET) Date: Wed, 3 Jan 2001 12:29:18 +0100 (MET) From: "Maciej W. Rozycki" To: Jun Sun cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: missing data cache flush in trap_init? In-Reply-To: <3A5277C6.89170BAD@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, 2 Jan 2001, Jun Sun wrote: > The following patch should fix it. I am not sure if I can use > flush_cache_range() to have potentially better performance. Yes, flush_cache_range() is the right function and it should be used even if no performance gain is achieved (it is in this case, though). I can't comment if that's needed at all, though. R3k which I use has its data cache write-through so it doesn't need such a change. I might check IDT R4k and possibly IDT R5k docs yet but I have no idea about other implementations. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Jan 3 09:15:07 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 09:14:46 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:52212 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 09:14:19 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Wed, 3 Jan 2001 15:05:35 -0200 Date: Wed, 3 Jan 2001 15:05:35 -0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: missing data cache flush in trap_init? Message-ID: <20010103150535.B904@bacchus.dhis.org> References: <3A5277C6.89170BAD@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A5277C6.89170BAD@mvista.com>; from jsun@mvista.com on Tue, Jan 02, 2001 at 04:52:22PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 02, 2001 at 04:52:22PM -0800, Jun Sun wrote: > Someone reported this bug to me. I think it is a valid one. Basically > trap_init() installs the vectors through kseg0 address and then flushes > icache. It is possible that the vectors are still in the data cache and not > written back to memory yet. If an exception happens it may get the corrupted > the vector value. > > The following patch should fix it. I am not sure if I can use > flush_cache_range() to have potentially better performance. Flush_icache_range is correct; the function is expected to do any dcache writebacks etc. to make dcache / icache / memory coherent. Is it possible that you're using a CPU with additional vectors that aren't flushed by this flush_icache_call or? Ralf From owner-linux-mips@oss.sgi.com Wed Jan 3 10:18:57 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 10:18:38 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:33521 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 10:18:24 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Wed, 3 Jan 2001 16:09:53 -0200 Date: Wed, 3 Jan 2001 16:09:53 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: SGI/ARCS related fixes Message-ID: <20010103160953.A3795@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Tue, Jan 02, 2001 at 07:12:57PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 02, 2001 at 07:12:57PM +0100, Maciej W. Rozycki wrote: > > --- /nfs/cvs/linux-2.3/linux/arch/mips/arc/memory.c Mon Dec 11 18:07:34 2000 > > +++ linux/arch/mips/arc/memory.c Sat Dec 30 21:49:32 2000 > > @@ -124,7 +124,7 @@ > > size = p->pages << PAGE_SHIFT; > > type = prom_memtype_classify(p->type); > > > > - add_memory_region(base, pages, type); > > + add_memory_region(base, size, type); > > } > > } > > > > That is fine. I actually included the fix in my set of memory map > patches (patch-mips-2.4.0-test11-20001212-mem_map-37) I sent Ralf a few > days ago. They still appear to wait to be applied. I suspect your patch got lost from cvs in the recent disk crash. I reapplied it now. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 3 10:22:37 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 10:22:28 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:33521 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 10:22:15 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Wed, 3 Jan 2001 16:13:55 -0200 Date: Wed, 3 Jan 2001 16:13:54 -0200 From: Ralf Baechle To: Harald Koerfgen Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: SGI/ARCS related fixes Message-ID: <20010103161354.A3856@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Harald.Koerfgen@home.ivm.de on Sun, Dec 31, 2000 at 12:41:11PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Sun, Dec 31, 2000 at 12:41:11PM +0100, Harald Koerfgen wrote: > > wanting to bring my O2 patches up to date I stumbled over some minor hickups. > > I don't have the appropriate hardware to test, ok to commit? I've applied the sgialib.h and misc.c parts. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 3 17:39:31 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 17:39:12 -0800 Received: from mail.cosinecom.com ([63.88.104.16]:37895 "EHLO exchsrv1.cosinecom.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 17:38:55 -0800 Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 17:36:46 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com> From: John Van Horne To: "'linux-mips@oss.sgi.com'" Cc: "'wesolows@foobazco.org'" Subject: Date: Wed, 3 Jan 2001 17:36:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075EE.CBD95CA0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075EE.CBD95CA0 Content-Type: text/plain; charset="iso-8859-1" Hello, I downloaded cross-all-001027.tar from oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev, built it on my ix86 Linux box, and have tried to use it on our Linux application and Linux kernel. I'm getting errors which we didn't see when we were using binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a. First, while the kernel builds just fine, when we use objcopy to convert the elf image into a binary image which we can download to our target, objcopy fails with warnings saying that it is writing sections to huge (i.e. negative) file offsets. When I use objdump to analyze the kernel image, I see that our start address of 0x80102584 has been turned into 0xffffffff80102584. I'm thinking that I need to tell ld something to stop it from doing this. Any ideas? Second, the way we build our application, we first create a partially linked image, with the -r flag. Then we run ld on this (and an additional object file). When we do this with the tools from cross-all-001027 we get the following error on the second link step: mips-linux-ld: BFD internal error, aborting at /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c line 6942 in _bfd_mips_elf_relocate_section mips-linux-ld: Please report this bug. Actually, on the application we didn't get this far using binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a, so I have nothing to compare it to. I'm not sure if this is a bug or if I should be passing some flags to gcc or ld. Any help you can provide would be appreciated. Thanks, -John ------_=_NextPart_001_01C075EE.CBD95CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I downloaded cross-all-001027.tar from = oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev,
built it on my ix86 Linux box, and = have tried to use it on our Linux application and Linux kernel.
I'm getting errors which we didn't = see when we were using binutils-mips-linux-2.8.1 and
egcs-mips-linux-1.0.3a.

First, while the kernel builds just = fine, when we use objcopy to convert the elf image into a binary
image which we can download to our = target, objcopy fails with warnings saying that it is writing
sections to huge (i.e. negative) file = offsets. When I use objdump to analyze the kernel image,
I see that our start address of = 0x80102584 has been turned into 0xffffffff80102584. I'm thinking = that
I need to tell ld something to stop = it from doing this. Any ideas?

Second, the way we build our = application, we first create a partially linked image, with the -r = flag. Then
we run ld on this (and an additional = object file). When we do this with the tools from = cross-all-001027
we get the following error on the = second link step:

mips-linux-ld:  BFD internal = error, aborting at = /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mip= s.c line 6942 in _bfd_mips_elf_relocate_section

mips-linux-ld: Please report this = bug.

Actually, on the application we didn't = get this far using binutils-mips-linux-2.8.1 and = egcs-mips-linux-1.0.3a,
so I have nothing to compare it = to.  I'm not sure if this is a bug or if I should be passing some = flags to gcc or ld.

Any help you can provide would be = appreciated.

Thanks,
-John


------_=_NextPart_001_01C075EE.CBD95CA0-- From owner-linux-mips@oss.sgi.com Wed Jan 3 19:26:22 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 19:26:12 -0800 Received: from gateway-1237.mvista.com ([12.44.186.158]:55537 "EHLO hermes.mvista.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 19:25:50 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f043NUC27427; Wed, 3 Jan 2001 19:23:30 -0800 Message-ID: <3A53ED5F.EC5E936F@mvista.com> Date: Wed, 03 Jan 2001 19:26:23 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: missing data cache flush in trap_init? References: <3A5277C6.89170BAD@mvista.com> <20010103150535.B904@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Ralf Baechle wrote: > > On Tue, Jan 02, 2001 at 04:52:22PM -0800, Jun Sun wrote: > > > Someone reported this bug to me. I think it is a valid one. Basically > > trap_init() installs the vectors through kseg0 address and then flushes > > icache. It is possible that the vectors are still in the data cache and not > > written back to memory yet. If an exception happens it may get the corrupted > > the vector value. > > > > The following patch should fix it. I am not sure if I can use > > flush_cache_range() to have potentially better performance. > > Flush_icache_range is correct; the function is expected to do any dcache > writebacks etc. to make dcache / icache / memory coherent. > > Is it possible that you're using a CPU with additional vectors that aren't > flushed by this flush_icache_call or? > > Ralf You are right - flush_icache_range() practically flushes both caches in the current implementation. There might be some other problems. Aside of that, the name of flush_icache_range() seems to be misleading. Also in general how does it know which part of dcache to flush() without a given process mm struct? If it does not know, the only choice is to flush the whole dcache, which seems to make this function very close to flush_all(). Is this function introduced by other CPU platforms? How would it make a difference there? I am just curious ... Jun From owner-linux-mips@oss.sgi.com Thu Jan 4 07:46:22 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 07:46:13 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:53497 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 07:45:56 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Thu, 4 Jan 2001 13:36:29 -0200 Date: Thu, 4 Jan 2001 13:36:29 -0200 From: Ralf Baechle To: John Van Horne Cc: "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail Message-ID: <20010104133629.C936@bacchus.dhis.org> References: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com>; from JohnVan.Horne@cosinecom.com on Wed, Jan 03, 2001 at 05:36:44PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote: > First, while the kernel builds just fine, when we use objcopy to convert the > elf image into a binary > image which we can download to our target, objcopy fails with warnings > saying that it is writing > sections to huge (i.e. negative) file offsets. When I use objdump to analyze > the kernel image, > I see that our start address of 0x80102584 has been turned into > 0xffffffff80102584. I'm thinking that > I need to tell ld something to stop it from doing this. Any ideas? That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses. Older binutils used to zero-extend addresses which was broken. So what you observe is actually the sympthom of a bug that got fixed. > Second, the way we build our application, we first create a partially linked > image, with the -r flag. Then > we run ld on this (and an additional object file). When we do this with the > tools from cross-all-001027 > we get the following error on the second link step: > > mips-linux-ld: BFD internal error, aborting at > /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c > line 6942 in _bfd_mips_elf_relocate_section > > mips-linux-ld: Please report this bug. Not good ... Two possibilities. - it's fairly easy to make ld die in funny ways by feeding it with nonsense options, linker scripts or similar. - it's really a bug. Assuming it's really a bug, can you extract a small test case that demonstrate this bug? > Actually, on the application we didn't get this far using > binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a, > so I have nothing to compare it to. I'm not sure if this is a bug or if I > should be passing some flags to gcc or ld. It may well be a bug; especially -r is used relativly rarely so the code isn't getting excercised too well. I'd like to see it get fixed in the current linker, though. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 4 08:26:53 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 08:26:43 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:52141 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 08:26:20 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA11844; Thu, 4 Jan 2001 17:22:52 +0100 (MET) Date: Thu, 4 Jan 2001 17:22:51 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <20010104133629.C936@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, Ralf Baechle wrote: > > I see that our start address of 0x80102584 has been turned into > > 0xffffffff80102584. I'm thinking that > > I need to tell ld something to stop it from doing this. Any ideas? > > That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses. > Older binutils used to zero-extend addresses which was broken. So what > you observe is actually the sympthom of a bug that got fixed. I'm not sure that's the best solution, I'm afraid. For elf32-mips addresses should be 32-bit and not 64-bit. It would be consistent with other 32-bit platforms, it would make interoperability easier (ksymoops cannot make use of System.map to grok kernel oopses which provide 32-bit addresses) and it would make objdump outputs more readable. Fixing this problem with BFD is on my to do list (but has a low priority assigned). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 4 08:49:53 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 08:49:43 -0800 Received: from blackdog.wirespeed.com ([208.170.106.25]:1546 "EHLO blackdog.wirespeed.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 08:49:21 -0800 Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id KAA09708; Thu, 4 Jan 2001 10:35:04 -0600 Message-ID: <3A54A789.1070608@redhat.com> Date: Thu, 04 Jan 2001 10:40:41 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing If the BFD stuff is built with any support for 64 bit (even as an optional target) it will maintain all addresses as 64-bit values, even if the file is 32 bit. There is a bug in that "some" newer versions of objcopy will not allow you to translate these sign-extended 32 bit addresses into Intel Hex format. If you're really only doing 32-bit mips you might consider removing the 64 bit targets in the config.bfd... I think that will solve the problems. Maciej W. Rozycki wrote: > On Thu, 4 Jan 2001, Ralf Baechle wrote: > > >>> I see that our start address of 0x80102584 has been turned into >>> 0xffffffff80102584. I'm thinking that >>> I need to tell ld something to stop it from doing this. Any ideas? >> >> That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses. >> Older binutils used to zero-extend addresses which was broken. So what >> you observe is actually the sympthom of a bug that got fixed. > > > I'm not sure that's the best solution, I'm afraid. For elf32-mips > addresses should be 32-bit and not 64-bit. It would be consistent with > other 32-bit platforms, it would make interoperability easier (ksymoops > cannot make use of System.map to grok kernel oopses which provide 32-bit > addresses) and it would make objdump outputs more readable. > > Fixing this problem with BFD is on my to do list (but has a low priority > assigned). From owner-linux-mips@oss.sgi.com Thu Jan 4 09:23:13 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:22:53 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:2043 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:22:42 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Thu, 4 Jan 2001 15:13:42 -0200 Date: Thu, 4 Jan 2001 15:13:34 -0200 From: Ralf Baechle To: Joe deBlaquiere Cc: "Maciej W. Rozycki" , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail Message-ID: <20010104151334.C2525@bacchus.dhis.org> References: <3A54A789.1070608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A54A789.1070608@redhat.com>; from jadb@redhat.com on Thu, Jan 04, 2001 at 10:40:41AM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote: > There is a bug in that "some" newer versions of objcopy will not allow > you to translate these sign-extended 32 bit addresses into Intel Hex > format. I couldn't care less ... > If you're really only doing 32-bit mips you might consider removing the > 64 bit targets in the config.bfd... I think that will solve the problems. Doesn't really solve the problem. For example on an Origin we have a 32-bit userland but 64-bit kernel addresses which confuses ksymops and procps. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 4 09:32:43 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:32:23 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32430 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:32:12 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA13739; Thu, 4 Jan 2001 18:18:42 +0100 (MET) Date: Thu, 4 Jan 2001 18:18:41 +0100 (MET) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <3A54A789.1070608@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, Joe deBlaquiere wrote: > If the BFD stuff is built with any support for 64 bit (even as an > optional target) it will maintain all addresses as 64-bit values, even > if the file is 32 bit. I do consider it fine BFD handles all addresses as 64-bit internally. I just think it should truncate them to 32-bits upon printing (and always whenever appropriate) when the selected target is 32-bit. It does so (it has to!) for output anyway, so what's the deal? > If you're really only doing 32-bit mips you might consider removing the > 64 bit targets in the config.bfd... I think that will solve the problems. Nope, I insist 32-bit targets need to work correctly regardless of whether there are any 64-bit ones supported by a particular BFD binary or not. Do you think elf32-i386 should switch to printing 64-bit addresses if elf64-alpha is also supported by a given configuration of BFD? I don't. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 4 09:35:13 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:35:03 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:25597 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:34:53 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Thu, 4 Jan 2001 15:25:53 -0200 Date: Thu, 4 Jan 2001 15:25:53 -0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: missing data cache flush in trap_init? Message-ID: <20010104152553.D2525@bacchus.dhis.org> References: <3A5277C6.89170BAD@mvista.com> <20010103150535.B904@bacchus.dhis.org> <3A53ED5F.EC5E936F@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A53ED5F.EC5E936F@mvista.com>; from jsun@mvista.com on Wed, Jan 03, 2001 at 07:26:23PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Wed, Jan 03, 2001 at 07:26:23PM -0800, Jun Sun wrote: > Aside of that, the name of flush_icache_range() seems to be misleading. Also > in general how does it know which part of dcache to flush() without a given > process mm struct? The function is only intended to flush kernel addresses for which no mm exists. Yes, it's being abused in creative ways but that's the purpose it was designed for ... > If it does not know, the only choice is to flush the whole > dcache, which seems to make this function very close to flush_all(). > > Is this function introduced by other CPU platforms? How would it make a > difference there? I am just curious ... Others such as for example m68k need it as well. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 4 09:45:44 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:45:24 -0800 Received: from blackdog.wirespeed.com ([208.170.106.25]:41738 "EHLO blackdog.wirespeed.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:45:04 -0800 Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id LAA11147; Thu, 4 Jan 2001 11:40:52 -0600 Message-ID: <3A54B6F4.7000909@redhat.com> Date: Thu, 04 Jan 2001 11:46:28 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail References: <3A54A789.1070608@redhat.com> <20010104151334.C2525@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Ralf Baechle wrote: > On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote: > > If you're really only doing 32-bit mips you might consider removing the >> 64 bit targets in the config.bfd... I think that will solve the problems. > > > Doesn't really solve the problem. For example on an Origin we have a 32-bit > userland but 64-bit kernel addresses which confuses ksymops and procps. > > Ralf It was meant as a workaround... Perhaps we could have an option to objcopy that would allow you to copy the addresses without sign extension? Joe From owner-linux-mips@oss.sgi.com Thu Jan 4 10:21:35 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 10:21:25 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:25519 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 10:20:59 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA15729; Thu, 4 Jan 2001 19:12:21 +0100 (MET) Date: Thu, 4 Jan 2001 19:12:20 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <3A54B6F4.7000909@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, Joe deBlaquiere wrote: > It was meant as a workaround... > > Perhaps we could have an option to objcopy that would allow you to copy > the addresses without sign extension? Please do either implement a clean solution or wait until someone else (possibly me) does. We don't want any more hacks -- MIPS/Linux already has enough of them. This is my view of the situation at present. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 4 11:02:34 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 11:02:15 -0800 Received: from pop.mainstreet.net ([207.5.0.4]:60654 "EHLO pop.mainstreet.net") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 11:01:54 -0800 Received: from innovisiontv.com ([63.100.187.130]) by pop.mainstreet.net (8.9.2/8.9.2) with ESMTP id LAA11403 for ; Thu, 4 Jan 2001 11:01:53 -0800 (PST) Message-ID: <3A54C8BA.3050300@innovisiontv.com> Date: Thu, 04 Jan 2001 11:02:18 -0800 From: Glenn Serre User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Cross-gdb for mipsel on i386? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Good morning, Does anyone know where I can get a precompiled cross-gdb for a mipsel target hosted on an i386 (Redhat 7.0)? I didn't see one on the oss.sgi.com, but maybe I was just looking in the wrong place. Thanks! --Glenn S. From owner-linux-mips@oss.sgi.com Thu Jan 4 11:37:34 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 11:37:25 -0800 Received: from gateway-1237.mvista.com ([12.44.186.158]:48626 "EHLO hermes.mvista.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 11:37:14 -0800 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f04JYpC01619; Thu, 4 Jan 2001 11:34:51 -0800 Message-ID: <3A54D12C.FB92DC29@mvista.com> Date: Thu, 04 Jan 2001 11:38:20 -0800 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) X-Accept-Language: bg, en MIME-Version: 1.0 To: Glenn Serre CC: "linux-mips@oss.sgi.com" Subject: Re: Cross-gdb for mipsel on i386? References: <3A54C8BA.3050300@innovisiontv.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Glenn Serre wrote: > > Good morning, > > Does anyone know where I can get a precompiled cross-gdb for a mipsel > target hosted on an i386 (Redhat 7.0)? I didn't see one on the > oss.sgi.com, but maybe I was just looking in the wrong place. ftp.mvista.com:/pub/Area51/ddb-5476 The names of the packages will probably change by the time we officially release this and other mips boards, but that shouldn't matter for you. Note that Redhat 7.0 is not yet one of our supported hosts, but it should work. Pete From owner-linux-mips@oss.sgi.com Thu Jan 4 12:11:25 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 12:11:06 -0800 Received: from mail.cosinecom.com ([63.88.104.16]:36869 "EHLO exchsrv1.cosinecom.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 12:10:36 -0800 Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 12:08:26 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A29113D7356@exchsrv1.cosinecom.com> From: John Van Horne To: "'Maciej W. Rozycki'" Cc: "'linux-mips@oss.sgi.com'" Subject: objcopy error -- was RE: your mail Date: Thu, 4 Jan 2001 12:08:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0768A.18471550" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0768A.18471550 Content-Type: text/plain; charset="iso-8859-1" Is there anyway to get more information out of objcopy? When I run it, I get the warnings I mentioned before, but no errors, however the target file is empty. Here is an abridged copy of what I get: [jvhorne@guava-lx linux]$ make orionboot make -C arch/mips/orion orionboot make[1]: Entering directory `/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/orion' mips-linux-objcopy -Obinary --verbose ../../../vmlinux orion.nosym copy from ../../../vmlinux(elf32-bigmips) to orion.nosym(binary) BFD: Warning: Writing section `.app_header' to huge (ie negative) file offset 0x800fec30. BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0x80100c30. BFD: Warning: Writing section `.fixup' to huge (ie negative) file offset 0x80236930. BFD: Warning: Writing section `.text.exit' to huge (ie negative) file offset 0x80237830. . . . mips-linux-objcopy: orion.nosym: File truncated Do you think that the reason objcopy fails is because it isn't treating the addresses as 32 bit addresses, or could it be something else? Thanks, -John -----Original Message----- From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] Sent: Thursday, January 04, 2001 8:23 AM To: Ralf Baechle Cc: John Van Horne; 'linux-mips@oss.sgi.com'; 'wesolows@foobazco.org' Subject: Re: your mail On Thu, 4 Jan 2001, Ralf Baechle wrote: > > I see that our start address of 0x80102584 has been turned into > > 0xffffffff80102584. I'm thinking that > > I need to tell ld something to stop it from doing this. Any ideas? > > That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses. > Older binutils used to zero-extend addresses which was broken. So what > you observe is actually the sympthom of a bug that got fixed. I'm not sure that's the best solution, I'm afraid. For elf32-mips addresses should be 32-bit and not 64-bit. It would be consistent with other 32-bit platforms, it would make interoperability easier (ksymoops cannot make use of System.map to grok kernel oopses which provide 32-bit addresses) and it would make objdump outputs more readable. Fixing this problem with BFD is on my to do list (but has a low priority assigned). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ------_=_NextPart_001_01C0768A.18471550 Content-Type: text/html; charset="iso-8859-1" objcopy error -- was RE: your mail

Is there anyway to get more information out of objcopy?  When I run it,
I get the warnings I mentioned before, but no errors, however the target
file is empty.  Here is an abridged copy of what I get:

[jvhorne@guava-lx linux]$ make orionboot
make -C arch/mips/orion orionboot
make[1]: Entering directory `/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/orion'
mips-linux-objcopy -Obinary --verbose ../../../vmlinux orion.nosym
copy from ../../../vmlinux(elf32-bigmips) to orion.nosym(binary)
BFD: Warning: Writing section `.app_header' to huge (ie negative) file offset 0x800fec30.
BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0x80100c30.
BFD: Warning: Writing section `.fixup' to huge (ie negative) file offset 0x80236930.
BFD: Warning: Writing section `.text.exit' to huge (ie negative) file offset 0x80237830.
.
.
.
mips-linux-objcopy: orion.nosym: File truncated


Do you think that the reason objcopy fails is because it isn't treating
the addresses as 32 bit addresses, or could it be something else?

Thanks,
-John


-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
Sent: Thursday, January 04, 2001 8:23 AM
To: Ralf Baechle
Cc: John Van Horne; 'linux-mips@oss.sgi.com'; 'wesolows@foobazco.org'
Subject: Re: your mail


On Thu, 4 Jan 2001, Ralf Baechle wrote:

> > I see that our start address of 0x80102584 has been turned into
> > 0xffffffff80102584. I'm thinking that
> > I need to tell ld something to stop it from doing this. Any ideas?
>
> That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
> Older binutils used to zero-extend addresses which was broken.  So what
> you observe is actually the sympthom of a bug that got fixed.

 I'm not sure that's the best solution, I'm afraid.  For elf32-mips
addresses should be 32-bit and not 64-bit.  It would be consistent with
other 32-bit platforms, it would make interoperability easier (ksymoops
cannot make use of System.map to grok kernel oopses which provide 32-bit
addresses) and it would make objdump outputs more readable.

 Fixing this problem with BFD is on my to do list (but has a low priority
assigned).

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

------_=_NextPart_001_01C0768A.18471550-- From owner-linux-mips@oss.sgi.com Thu Jan 4 12:43:25 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 12:43:05 -0800 Received: from mailgate1.zdv.Uni-Mainz.DE ([134.93.8.56]:7841 "EHLO mailgate1.zdv.Uni-Mainz.DE") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 12:42:49 -0800 Received: from arthur.zdv.Uni-Mainz.DE (arthur.zdv.Uni-Mainz.DE [134.93.8.145]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f04KgkM22121; Thu, 4 Jan 2001 21:42:46 +0100 (MET) Received: (from martin@localhost) by arthur.zdv.Uni-Mainz.DE (8.10.2/8.10.2) id f04Kgk522700; Thu, 4 Jan 2001 21:42:46 +0100 (MET) From: Christoph Martin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> Date: Thu, 4 Jan 2001 21:42:44 +0100 (MET) To: ralf@oss.sgi.com Cc: Christoph.Martin@uni-mainz.de, linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org, Andreas Jaeger Subject: glibc 2.2 on MIPS X-Mailer: VM 6.75 under Emacs 19.34.1 Organization: Johannes Gutenberg-Universitaet Mainz Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hi Ralf, On Thu, 12 Oct 2000 04:04:44 +0200, Ralf Baechle wrote: > On Thu, Oct 12, 2000 at 12:24:21AM +0200, Florian Lohoff wrote: > > We are trying :) I am currently basing all my Debian-mips(el) things > > on glibc 2.0.6. It is the only stable solution right now. I am experimenting > > with the glibc 2.1.94-3 debian source package which i managed to get > > compiled with unmodified cvs binutils and gcc + the gcse patch. > > > > Ralf reported bugs in the ld where he send me a patch. With that patch > > i get a "Bus Error" from the ld.so within the glibc build. > There patch is ok; you get those bus errors because there are bugs in > both ld and binutils that in most cases compensate each other. If you > fix only one of them you get all sorts of funnies ... I just tried to build glibc-2.2 (CVS-2000-12-28) for debian-mips and it still has the "Bus Error" problem. We are currently using binutils 2.10.1.0.2 and gcc 2.95.2 + CVS from 2.95 branch. Can you please post both patches, so that we can verify which one is missing in our build. > Even with the fixes ld is not yet perfect - for example emacs and X still > fail. The gcc/binutils combination seams to work correctly as far as I can see. I managed to compile xfree 4.0.2 linked agains 2.1.95-1.1. What problems did you have with X? Christoph From owner-linux-mips@oss.sgi.com Thu Jan 4 13:17:55 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 13:17:45 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:23218 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 13:17:29 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA22435; Thu, 4 Jan 2001 22:17:33 +0100 (MET) Date: Thu, 4 Jan 2001 22:17:33 +0100 (MET) From: "Maciej W. Rozycki" To: John Van Horne cc: "'linux-mips@oss.sgi.com'" Subject: Re: objcopy error -- was RE: your mail In-Reply-To: <7EB7C6B62C4FD41196A80090279A29113D7356@exchsrv1.cosinecom.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, John Van Horne wrote: > [jvhorne@guava-lx linux]$ make orionboot > make -C arch/mips/orion orionboot > make[1]: Entering directory > `/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/orion' > mips-linux-objcopy -Obinary --verbose ../../../vmlinux orion.nosym > copy from ../../../vmlinux(elf32-bigmips) to orion.nosym(binary) > BFD: Warning: Writing section `.app_header' to huge (ie negative) file > offset 0x800fec30. > BFD: Warning: Writing section `.text' to huge (ie negative) file offset > 0x80100c30. > BFD: Warning: Writing section `.fixup' to huge (ie negative) file offset > 0x80236930. > BFD: Warning: Writing section `.text.exit' to huge (ie negative) file offset > 0x80237830. > . > . > . > mips-linux-objcopy: orion.nosym: File truncated > > > Do you think that the reason objcopy fails is because it isn't treating > the addresses as 32 bit addresses, or could it be something else? Note that the binary BFD target fills all "holes" with zeroes. I suspect one or more sections are placed at an offset lower than 0x80000000. Objcopy would have to make a huge file in this case and it gives up. You probably need to fix your linker script. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 4 13:35:45 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 13:35:25 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:42930 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 13:35:03 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA23098; Thu, 4 Jan 2001 22:34:40 +0100 (MET) Date: Thu, 4 Jan 2001 22:34:40 +0100 (MET) From: "Maciej W. Rozycki" To: Christoph Martin cc: ralf@oss.sgi.com, Christoph.Martin@uni-mainz.de, linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org, Andreas Jaeger Subject: Re: glibc 2.2 on MIPS In-Reply-To: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, Christoph Martin wrote: > I just tried to build glibc-2.2 (CVS-2000-12-28) for debian-mips and > it still has the "Bus Error" problem. We are currently using binutils > 2.10.1.0.2 and gcc 2.95.2 + CVS from 2.95 branch. > > Can you please post both patches, so that we can verify which one is > missing in our build. The 2.2 release of glibc needs no patches. The current CVS version is even better as a few unrelated fixes has been applied meanwhile. For binutils 2.10.1 the following fix makes binaries be built as ld.so expects. Other fixes might be needed for 2.10.1 to work at all -- they are all available from: ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/binutils-2.10.1-3.src.rpm (or use a mirror at: ftp://ftp.rfc822.org/pub/mirror/ftp.ds2.pg.gda.pl/...). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + binutils-2.10-mips-dyn-addend.patch diff -up --recursive --new-file binutils-2.10.macro/bfd/elf32-mips.c binutils-2.10/bfd/elf32-mips.c --- binutils-2.10.macro/bfd/elf32-mips.c Sat Mar 11 02:23:10 2000 +++ binutils-2.10/bfd/elf32-mips.c Sat Oct 28 17:19:52 2000 @@ -5675,15 +5675,16 @@ mips_elf_create_dynamic_relocation (outp /* The relocation we're building is section-relative. Therefore, the original addend must be adjusted by the section offset. */ - *addendp += symbol - sec->output_section->vma; + *addendp += section_offset; /* Now, the relocation is just against the section. */ symbol = sec->output_section->vma; } - /* If the relocation was previously an absolute relocation, we - must adjust it by the value we give it in the dynamic symbol - table. */ - if (r_type != R_MIPS_REL32) + /* If the relocation was previously an absolute relocation and + this symbol will not be referred to by the relocation, we must + adjust it by the value we give it in the dynamic symbol table. + Otherwise leave the job up to the dynamic linker. */ + if (!indx && r_type != R_MIPS_REL32) *addendp += symbol; /* The relocation is always an REL32 relocation because we don't From owner-linux-mips@oss.sgi.com Thu Jan 4 14:03:45 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 14:03:26 -0800 Received: from mail.cosinecom.com ([63.88.104.16]:39435 "EHLO exchsrv1.cosinecom.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 14:03:09 -0800 Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 14:00:59 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A29113D7357@exchsrv1.cosinecom.com> From: John Van Horne To: "'Maciej W. Rozycki'" Cc: "'linux-mips@oss.sgi.com'" Subject: RE: objcopy error -- was RE: your mail Date: Thu, 4 Jan 2001 14:00:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07699.D1E8E970" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07699.D1E8E970 Content-Type: text/plain; charset="iso-8859-1" This is the same script that worked fine when we were using egcs-mips-linux-1.0.3a and binutils-mips-linux-2.8.1. Have there been any changes in the linker that would affect how we write our linker script? Thanks, -John -----Original Message----- From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] Sent: Thursday, January 04, 2001 1:18 PM To: John Van Horne Cc: 'linux-mips@oss.sgi.com' Subject: Re: objcopy error -- was RE: your mail On Thu, 4 Jan 2001, John Van Horne wrote: > [jvhorne@guava-lx linux]$ make orionboot > make -C arch/mips/orion orionboot > make[1]: Entering directory > `/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/orion' > mips-linux-objcopy -Obinary --verbose ../../../vmlinux orion.nosym > copy from ../../../vmlinux(elf32-bigmips) to orion.nosym(binary) > BFD: Warning: Writing section `.app_header' to huge (ie negative) file > offset 0x800fec30. > BFD: Warning: Writing section `.text' to huge (ie negative) file offset > 0x80100c30. > BFD: Warning: Writing section `.fixup' to huge (ie negative) file offset > 0x80236930. > BFD: Warning: Writing section `.text.exit' to huge (ie negative) file offset > 0x80237830. > . > . > . > mips-linux-objcopy: orion.nosym: File truncated > > > Do you think that the reason objcopy fails is because it isn't treating > the addresses as 32 bit addresses, or could it be something else? Note that the binary BFD target fills all "holes" with zeroes. I suspect one or more sections are placed at an offset lower than 0x80000000. Objcopy would have to make a huge file in this case and it gives up. You probably need to fix your linker script. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ------_=_NextPart_001_01C07699.D1E8E970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: objcopy error -- was RE: your mail

This is the same script that worked fine when we were = using
egcs-mips-linux-1.0.3a and = binutils-mips-linux-2.8.1.  Have
there been any changes in the linker that would = affect how
we write our linker script?

Thanks,
-John

-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
Sent: Thursday, January 04, 2001 1:18 PM
To: John Van Horne
Cc: 'linux-mips@oss.sgi.com'
Subject: Re: objcopy error -- was RE: your = mail


On Thu, 4 Jan 2001, John Van Horne wrote:

> [jvhorne@guava-lx linux]$ make orionboot
> make -C arch/mips/orion orionboot
> make[1]: Entering directory
> = `/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/ori= on'
> mips-linux-objcopy -Obinary --verbose = ../../../vmlinux orion.nosym
> copy from ../../../vmlinux(elf32-bigmips) to = orion.nosym(binary)
> BFD: Warning: Writing section `.app_header' to = huge (ie negative) file
> offset 0x800fec30.
> BFD: Warning: Writing section `.text' to huge = (ie negative) file offset
> 0x80100c30.
> BFD: Warning: Writing section `.fixup' to huge = (ie negative) file offset
> 0x80236930.
> BFD: Warning: Writing section `.text.exit' to = huge (ie negative) file offset
> 0x80237830.
> .
> .
> .
> mips-linux-objcopy: orion.nosym: File = truncated
>
>
> Do you think that the reason objcopy fails is = because it isn't treating
> the addresses as 32 bit addresses, or could it = be something else?

 Note that the binary BFD target fills all = "holes" with zeroes.  I suspect
one or more sections are placed at an offset lower = than 0x80000000.
Objcopy would have to make a huge file in this case = and it gives up.  You
probably need to fix your linker script.

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

------_=_NextPart_001_01C07699.D1E8E970-- From owner-linux-mips@oss.sgi.com Thu Jan 4 16:44:37 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 16:44:27 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57646 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 16:44:02 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA04955; Thu, 4 Jan 2001 16:52:40 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id LAA12000; Fri, 5 Jan 2001 11:42:42 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Ralf Baechle cc: "'linux-mips@oss.sgi.com'" Subject: ksymoops on origin In-reply-to: Your message of "Thu, 04 Jan 2001 15:13:34 -0200." <20010104151334.C2525@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2001 11:42:42 +1100 Message-ID: <1123.978655362@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001 15:13:34 -0200, Ralf Baechle wrote: >Doesn't really solve the problem. For example on an Origin we have a 32-bit >userland but 64-bit kernel addresses which confuses ksymops and procps. In what way does ksymoops get confused? All its address handling should be 64 bit. As long as the kernel prints its addresses in full, without removing the high order word, then the text handling should be OK. The only problem will be the default object format which is taken from ksymoops itself. Sparc also has this problem, from oops.c, function Oops_eip. /* Special case for sparc64. If the output target is defaulting to the * same format as ksymoops then the default is wrong, kernel is 64 bit, * ksymoops is 32 bit. When we see an EIP from sparc64, set the correct * default. */ if (!options->target && !options->architecture && strcmp(bfd_get_target(ibfd), "elf32-sparc")) { options->target = "elf64-sparc"; options->architecture = "sparc:v9a"; } I will add a special case for Origin if somebody can tell me: What oops string identifies a 64 bit kernel instead of 32 bit. What bfd_get_target() reports for a 32 bit ksymoops on Origin. What target and architecture to use for a 64 bit kernel. Even without special case code for Origin, you can run ksymoops with the -t and -a options to force the desired format, instead of defaulting to the format of ksymoops. From owner-linux-mips@oss.sgi.com Thu Jan 4 17:50:27 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 17:50:18 -0800 Received: from mailhost.taec.com ([209.243.128.33]:978 "EHLO mailhost.taec.toshiba.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 17:50:02 -0800 Received: from hdqmta.taec.toshiba.com (hdqmta [209.243.180.59]) by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id RAA15176 for ; Thu, 4 Jan 2001 17:49:55 -0800 (PST) Subject: questions on the cross-compiler To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Lisa.Hsu@taec.toshiba.com Date: Thu, 4 Jan 2001 17:44:36 -0800 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.5 |September 22, 2000) at 01/04/2001 05:48:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Dear All, I am working on our TX39xx(32-bit MIPS) reference board . The problem occurs in the assembly code generation for "la" instruction. The line, "la t3, mips_cputype" , generated the following two assembly codes: lui $t3,0x8019 daddiu $t3,$t3,14712 <---- my system crashed at this 64-bit instruction I would like to know why the "daddiu" instruction is generated instead of "addiu" for MIP1 code. The following lists my development environment: 1. Cross compiler: binutils-mips-linux-2.8.1-1.i386 and egcs-mips-linux-1.0.3a-2.i386 2. Linux Kernel source: linux-2.2.13-20000211 3. The gcc command line display by specify -v option: gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) /usr/lib/gcc-lib/mips-linux/egcs-2.90.29/cpp -lang-asm -v -I/work/adhawk/linux-2.2.13-20000211/include -undef -$ -D__ELF__ -D__PIC__ -D__pic__ -Dunix -Dmips -DR3000 -DMIPSEB -Dlinux -D__ELF__ -D__PIC__ -D__pic__ -D__unix__ -D__mips__ -D__R3000__ -D__MIPSEB__ -D__linux__ -D__unix -D__mips -D__R3000 -D__MIPSEB -D__linux -Asystem(linux) -Asystem(posix) -Acpu(mips) -Amachine(mips) -D__ASSEMBLER__ -D__OPTIMIZE__ -Wall -Wstrict-prototypes -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY -DLANGUAGE_ASSEMBLY -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D_MIPS_FPSET=16 -D_MIPS_ISA=_MIPS_ISA_MIPS1 -D_MIPS_SIM=_MIPS_SIM_ABI32 -D_MIPS_SZINT=32 -D__SIZE_TYPE__=unsigned int -D__SSIZE_TYPE__=int -D__PTRDIFF_TYPE__=int -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 -U__mips64 -U__PIC__ -U__pic__ -D__KERNEL__ -DADHAWK head.S I am quite new to the Linux world. There are definitely something that I did not setup properly. If anyone know the reason, your help is highly appreciated. Also, what are the latest and stable tool-chain for MIP1 big-endian development? Thanks, Lisa Hsu Multimedia Application Group TAEC, Toshiba 408-526-2771 lisa.hsu@taec.toshiba.com From owner-linux-mips@oss.sgi.com Fri Jan 5 00:49:48 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 00:49:39 -0800 Received: from router.isratech.ro ([193.226.114.69]:20238 "EHLO router.isratech.ro") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 00:49:26 -0800 Received: from isratech.ro (calin.cs.tuiasi.ro [193.231.15.163]) by router.isratech.ro (8.10.2/8.10.2) with ESMTP id f058mNp28516; Fri, 5 Jan 2001 10:48:23 +0200 Message-ID: <3A55F882.4B693DE3@isratech.ro> Date: Fri, 05 Jan 2001 11:38:27 -0500 From: Nicu Popovici X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.15-2.5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Martin CC: ralf@oss.sgi.com, Christoph.Martin@uni-mainz.de, linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org, Andreas Jaeger Subject: Re: glibc 2.2 on MIPS References: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> Content-Type: multipart/mixed; boundary="------------9A6E0E45F076F1CC308E1BCA" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This is a multi-part message in MIME format. --------------9A6E0E45F076F1CC308E1BCA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, My question is somehow related on the problems showed in this email. Sorry if this will bother you. I am trying to setup a cross toolchain for mips and I have to use binutils 2.10 and gcc 2.95.2 and glibc2.1.3. Currently I am trying to setup binutils 2.10 with egcs1.0.3a and with glibc.2.0.6 . Do you have any patches for binutils 2.10 or for gcc2.95.2 for mips ? If you have and if you have some ideeas please tell me .. Thank You Nicu Christoph Martin wrote: > Hi Ralf, > > On Thu, 12 Oct 2000 04:04:44 +0200, Ralf Baechle wrote: > > > On Thu, Oct 12, 2000 at 12:24:21AM +0200, Florian Lohoff wrote: > > > > We are trying :) I am currently basing all my Debian-mips(el) things > > > on glibc 2.0.6. It is the only stable solution right now. I am experimenting > > > with the glibc 2.1.94-3 debian source package which i managed to get > > > compiled with unmodified cvs binutils and gcc + the gcse patch. > > > > > > Ralf reported bugs in the ld where he send me a patch. With that patch > > > i get a "Bus Error" from the ld.so within the glibc build. > > > There patch is ok; you get those bus errors because there are bugs in > > both ld and binutils that in most cases compensate each other. If you > > fix only one of them you get all sorts of funnies ... > > I just tried to build glibc-2.2 (CVS-2000-12-28) for debian-mips and > it still has the "Bus Error" problem. We are currently using binutils > 2.10.1.0.2 and gcc 2.95.2 + CVS from 2.95 branch. > > Can you please post both patches, so that we can verify which one is > missing in our build. > > > Even with the fixes ld is not yet perfect - for example emacs and X still > > fail. > > The gcc/binutils combination seams to work correctly as far as I can > see. I managed to compile xfree 4.0.2 linked agains 2.1.95-1.1. What > problems did you have with X? > > Christoph --------------9A6E0E45F076F1CC308E1BCA Content-Type: text/x-vcard; charset=us-ascii; name="octavp.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Nicu Popovici Content-Disposition: attachment; filename="octavp.vcf" begin:vcard n:POPOVICI;Nicolae Octavian tel;cell:+40 93 605020 x-mozilla-html:FALSE org:SC Silicon Service SRL;Software adr:;;;;;; version:2.1 email;internet:octavp@isratech.ro title:Software engineer x-mozilla-cpt:;0 fn:Nicolae Octavian POPOVICI end:vcard --------------9A6E0E45F076F1CC308E1BCA-- From owner-linux-mips@oss.sgi.com Fri Jan 5 02:30:09 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 02:29:50 -0800 Received: from mailgate1.zdv.Uni-Mainz.DE ([134.93.8.56]:21738 "EHLO mailgate1.zdv.Uni-Mainz.DE") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 02:29:35 -0800 Received: from arthur.zdv.Uni-Mainz.DE (arthur.zdv.Uni-Mainz.DE [134.93.8.145]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f05ATXM27303; Fri, 5 Jan 2001 11:29:33 +0100 (MET) Received: (from martin@localhost) by arthur.zdv.Uni-Mainz.DE (8.10.2/8.10.2) id f05ATW124161; Fri, 5 Jan 2001 11:29:32 +0100 (MET) From: Christoph Martin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14933.41481.359719.747161@arthur.zdv.Uni-Mainz.DE> Date: Fri, 5 Jan 2001 11:29:29 +0100 (MET) To: Nicu Popovici Cc: Christoph Martin , linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org Subject: Re: glibc 2.2 on MIPS In-Reply-To: <3A55F882.4B693DE3@isratech.ro> References: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> <3A55F882.4B693DE3@isratech.ro> X-Mailer: VM 6.75 under Emacs 19.34.1 Organization: Johannes Gutenberg-Universitaet Mainz Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Nicu Popovici writes: > Hello all, > > My question is somehow related on the problems showed in this email. Sorry if this > will bother you. > I am trying to setup a cross toolchain for mips and I have to use binutils 2.10 > and gcc 2.95.2 and glibc2.1.3. Currently I am trying to setup binutils 2.10 with > egcs1.0.3a and with glibc.2.0.6 . Do you have any patches for binutils 2.10 or for > gcc2.95.2 for mips ? If you have and if you have some ideeas please tell me .. > Look for the patches in the respective archives on: ftp.ds2.pg.gda.pl/pub/macro/SRPMS/ Christoph From owner-linux-mips@oss.sgi.com Fri Jan 5 04:04:00 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 04:03:41 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:50363 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 04:03:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA19949; Fri, 5 Jan 2001 12:55:42 +0100 (MET) Date: Fri, 5 Jan 2001 12:55:41 +0100 (MET) From: "Maciej W. Rozycki" To: John Van Horne cc: "'linux-mips@oss.sgi.com'" Subject: RE: objcopy error -- was RE: your mail In-Reply-To: <7EB7C6B62C4FD41196A80090279A29113D7357@exchsrv1.cosinecom.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001, John Van Horne wrote: > This is the same script that worked fine when we were using > egcs-mips-linux-1.0.3a and binutils-mips-linux-2.8.1. Have > there been any changes in the linker that would affect how > we write our linker script? It's possible the linker emits unnecessary sections. Try the following patch to see if it helps. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + 2000-11-30 Ralf Baechle * elf32-mips.c (elf32_mips_merge_private_bfd_data): Always permit BFDs containing no sections or empty .text, .data or .bss sections to be merged, regardless of their flags. diff -urN binutils-cygnus/bfd/elf32-mips.c binutils/bfd/elf32-mips.c --- binutils-cygnus/bfd/elf32-mips.c Sat Oct 14 14:21:14 2000 +++ binutils/bfd/elf32-mips.c Thu Nov 30 16:13:09 2000 @@ -2475,6 +2475,8 @@ flagword old_flags; flagword new_flags; boolean ok; + boolean null_input_bfd = true; + asection *sec; /* Check if we have the same endianess */ if (_bfd_generic_verify_endian_match (ibfd, obfd) == false) @@ -2512,6 +2514,27 @@ old_flags &= ~EF_MIPS_NOREORDER; if (new_flags == old_flags) + return true; + + /* Check to see if the input BFD actually contains any sections. + If not, its flags may not have been initialised either, but it cannot + actually cause any incompatibility. */ + for (sec = ibfd->sections; sec != NULL; sec = sec->next) + { + /* Ignore synthetic sections and empty .text, .data and .bss sections + which are automatically generated by gas. */ + if (strcmp (sec->name, ".reginfo") + && strcmp (sec->name, ".mdebug") + && ((!strcmp (sec->name, ".text") + || !strcmp (sec->name, ".data") + || !strcmp (sec->name, ".bss")) + && sec->_raw_size != 0)) + { + null_input_bfd = false; + break; + } + } + if (null_input_bfd) return true; ok = true; From owner-linux-mips@oss.sgi.com Fri Jan 5 07:07:22 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 07:07:12 -0800 Received: from router.isratech.ro ([193.226.114.69]:14344 "EHLO router.isratech.ro") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 07:06:51 -0800 Received: from isratech.ro (calin.cs.tuiasi.ro [193.231.15.163]) by router.isratech.ro (8.10.2/8.10.2) with ESMTP id f05ESRl08255 for ; Fri, 5 Jan 2001 16:28:28 +0200 Message-ID: <3A56483D.17B57BD5@isratech.ro> Date: Fri, 05 Jan 2001 17:18:37 -0500 From: Nicu Popovici X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.15-2.5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Kernel compile error. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello to you all, I have the folowing cross toolchain ( binutils-2.10.1, egcs-1.0.3a , and glibc-2.0.6) and I can crosscompile some c c++ files on my intel machine and run the executables on the mips. BUT I can not cross compile the kernel for mips. I get the following error ======================================================================= /crossdev/bin/mips-linux-gcc -D__KERNEL__ -I/home/nicu/JUNGO/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mno-split-addresses -D__SMP__ -pipe -c -o init/main.o init/main.c /home/nicu/JUNGO/linux/include/asm/io.h: In function `copro_timeout': /home/nicu/JUNGO/linux/include/asm/io.h:87: `asm' operand requires impossible reload /home/nicu/JUNGO/linux/include/asm/io.h:87: `asm' operand requires impossible reload /home/nicu/JUNGO/linux/include/asm/bugs.h: In function `check_fpu': In file included from init/main.c:34: /home/nicu/JUNGO/linux/include/asm/bugs.h:137: internal error--insn does not satisfy its constraints: (insn 244 241 250 (set (reg:SI 66 accum) (reg:SI 6 a2)) 170 {movsi_internal2} (insn_list 241 (insn_list:REG_DEP_ANTI 98 (insn_list:REG_DEP_OUTPUT 138 (insn_list:REG_DEP_ANTI 247 (insn_list:REG_DEP_ANTI 150 (nil)))))) (nil)) mips-linux-gcc: Internal compiler error: program cc1 got fatal signal 6 make: *** [init/main.o] Error 1 [nicu@ares linux]$ {standard input}: Assembler messages: {standard input}:47: Error: unrecognized opcode `movl %cr0,$2' {standard input}:52: Error: unrecognized opcode `movl $2,%cr0' {standard input}:100: Error: unrecognized opcode `andl %esp,$5' {standard input}:108: Error: unrecognized opcode `outb accum,$7' {standard input}:109: Error: unrecognized opcode `outb %al,$0x80' {standard input}:114: Error: unrecognized opcode `outb accum,$7' ======================================================================= I have to mention that egcs and glibc are tested and I know for sure that this one are good. Does anyone know something related to this ? Regards, Octav From owner-linux-mips@oss.sgi.com Fri Jan 5 07:14:02 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 07:13:52 -0800 Received: from router.isratech.ro ([193.226.114.69]:29960 "EHLO router.isratech.ro") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 07:13:41 -0800 Received: from isratech.ro (calin.cs.tuiasi.ro [193.231.15.163]) by router.isratech.ro (8.10.2/8.10.2) with ESMTP id f05FDBl09523; Fri, 5 Jan 2001 17:13:11 +0200 Message-ID: <3A5652B9.1D509038@isratech.ro> Date: Fri, 05 Jan 2001 18:03:21 -0500 From: Nicu Popovici X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.15-2.5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Martin CC: ralf@oss.sgi.com, Christoph.Martin@uni-mainz.de, linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org, Andreas Jaeger Subject: Re: glibc 2.2 on MIPS References: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello , I am bothering you again. Related to gcc 2.95.2 --- it has any patches for porting to mips or not ? I mean , where do I find the patches for gcc-2.95.2 for mips if there are some files. I saw that you said something like that "gcc 2.95.2 + CVS from 2.95 branch." What do you mean ? Regards, Nicu Christoph Martin wrote: > Hi Ralf, > > On Thu, 12 Oct 2000 04:04:44 +0200, Ralf Baechle wrote: > > > On Thu, Oct 12, 2000 at 12:24:21AM +0200, Florian Lohoff wrote: > > > > We are trying :) I am currently basing all my Debian-mips(el) things > > > on glibc 2.0.6. It is the only stable solution right now. I am experimenting > > > with the glibc 2.1.94-3 debian source package which i managed to get > > > compiled with unmodified cvs binutils and gcc + the gcse patch. > > > > > > Ralf reported bugs in the ld where he send me a patch. With that patch > > > i get a "Bus Error" from the ld.so within the glibc build. > > > There patch is ok; you get those bus errors because there are bugs in > > both ld and binutils that in most cases compensate each other. If you > > fix only one of them you get all sorts of funnies ... > > I just tried to build glibc-2.2 (CVS-2000-12-28) for debian-mips and > it still has the "Bus Error" problem. We are currently using binutils > 2.10.1.0.2 and gcc 2.95.2 + CVS from 2.95 branch. > > Can you please post both patches, so that we can verify which one is > missing in our build. > > > Even with the fixes ld is not yet perfect - for example emacs and X still > > fail. > > The gcc/binutils combination seams to work correctly as far as I can > see. I managed to compile xfree 4.0.2 linked agains 2.1.95-1.1. What > problems did you have with X? > > Christoph From owner-linux-mips@oss.sgi.com Fri Jan 5 12:37:24 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 12:37:14 -0800 Received: from mailhost.taec.com ([209.243.128.33]:11908 "EHLO mailhost.taec.toshiba.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 12:37:01 -0800 Received: from hdqmta.taec.toshiba.com (hdqmta [209.243.180.59]) by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id MAA11598 for ; Fri, 5 Jan 2001 12:36:54 -0800 (PST) Subject: Re: questions on the cross-compiler To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Lisa.Hsu@taec.toshiba.com Date: Fri, 5 Jan 2001 12:31:31 -0800 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.5 |September 22, 2000) at 01/05/2001 12:35:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing With the help from Kevin Kissell, I've found out that the compilation directives "set .mips3[4]" were turned on before cpu_probe() and cpu_probe () functions in my head.S file. This is the reason why I've got that wrong code generated although I've specified mip1 in the gcc options. I 've temporarily used #define to add "set .mips1" in the code to fix the problem. My question now, is: how can we make the kernel code flexible to free from the problem of the one that I've got? Thanks, Lisa "Kevin D. Kissell" To: Subject: Re: questions on the cross-compiler 01/05/01 11:14 AM > Thanks so much for replying my email. From the specs file, I did see > -U__mips64 which means it was undefined. But undefining the symbol __mips64 is not really the same thing as setting the internal compiler state to generate mips1, mips2, or whatever. In assembler code, one can generally control this with something like ".set mips1" or "set .mips1" (I forget the semantics), but I didn't think that the code generator or assembler paid any attention to __mips64 or any other compile-time symbol. > We have another reference board uses the same processor but is running in > little-endian. I've checked the gcc -v output on it and compare with mine. > The options are the same but it correctly generated "addiu" instruction > instead of the wrong "daddiu" instruction. I've tried to configure to > little-endian and re-compiled. The result of the "la" instruction still > the same. So the tool chain is not the problem. At some level, there is an option being fed to the tool chain in one environment that is not being supplied in the other. The behavior you are seeing is completely correct behavior for 64-bit code generation, but 64-bit is not normally the default. *Something* is turning it on, either in the gcc specs, a makefile or make-include file, or in the source code itself. It's not out of the question, by the way, that your source code is really doing this to you. Is there a "mips3" or "mips4" string anywhere in the head.S file, or in anything it includes? It may be that there's some set of conditional compilation directives such that a .mips3 directive is being turned on by mistake for your particular platform. It wouldn't be the first time I came across Linux kernel code that was allegedly for MIPS in general, but which was in fact specific to R4000-and-above CPUs. > The gcc -v listed out all the options as shown in my original email under > #3. Do you know what else I can check? Well, you can eliminate the specs file and compiler defaults as suspects if you just generate a file containing just the "la" instruction and run "gcc-mips -c foo.S" with no fancy flags, includes, or make artifacts, and see what instructions it generates. > > Thanks and Best Regards, > > Lisa > > > > > "Kevin D. > Kissell" To: > com> Subject: Re: questions on the cross-compiler > > 01/04/01 > 11:47 PM > > > > > > > Hi Lisa, > > Sounds like someone has set the default compiler/assembler > options in gcc to default to 64-bit ISA code generation, which > is rather unusual. Normally, the default should be "mips1", > which is the lowest-common-denominator 32-bit ISA of the > R2000/R3000. The TX39 is more like MIPS II, in fact. In > general, in gcc this is controlled by a command line option: > > -mips1 R2000/3000/3081 > -mips2 R6000. R39xx should be a subset > -mips3 Basic 64-bit: R4x00 > -mips4 R5000/8000/10000/12000 > -mips32 New 32-bit ISA standard > -mips64 New 64-bit ISA standard > -mips16 Compressed ISA > > So you either need to figure out where in the gcc configuration > this is being set to "mips3", "mips4", or "mips64" (check the > specs file that you will find by running "gcc -v"), or you need > to make -mips1 or -mips2 explicit in your makefile. > > Regards, > > Kevin K. > > ----- Original Message ----- > From: > To: > Sent: Friday, January 05, 2001 2:44 AM > Subject: questions on the cross-compiler > > > > > > Dear All, > > > > I am working on our TX39xx(32-bit MIPS) reference board . The problem > > occurs in the assembly code generation for "la" instruction. > > > > The line, "la t3, mips_cputype" , generated the following two assembly > > codes: > > > > lui $t3,0x8019 > > daddiu $t3,$t3,14712 <---- my system crashed at this 64-bit > > instruction > > > > I would like to know why the "daddiu" instruction is generated instead of > > "addiu" for MIP1 code. > > > > The following lists my development environment: > > 1. Cross compiler: binutils-mips-linux-2.8.1-1.i386 and > > egcs-mips-linux-1.0.3a-2.i386 > > 2. Linux Kernel source: linux-2.2.13-20000211 > > 3. The gcc command line display by specify -v option: > > > > gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) > > /usr/lib/gcc-lib/mips-linux/egcs-2.90.29/cpp -lang-asm -v > > -I/work/adhawk/linux-2.2.13-20000211/include -undef -$ -D__ELF__ > -D__PIC__ > > -D__pic__ -Dunix -Dmips -DR3000 -DMIPSEB -Dlinux -D__ELF__ -D__PIC__ > > -D__pic__ -D__unix__ -D__mips__ -D__R3000__ -D__MIPSEB__ -D__linux__ > > -D__unix -D__mips -D__R3000 -D__MIPSEB -D__linux -Asystem(linux) > > -Asystem(posix) -Acpu(mips) -Amachine(mips) -D__ASSEMBLER__ > -D__OPTIMIZE__ > > -Wall -Wstrict-prototypes -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY > > -DLANGUAGE_ASSEMBLY -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int > > -D_MIPS_FPSET=16 -D_MIPS_ISA=_MIPS_ISA_MIPS1 -D_MIPS_SIM =_MIPS_SIM_ABI32 > > -D_MIPS_SZINT=32 -D__SIZE_TYPE__=unsigned int -D__SSIZE_TYPE__=int > > -D__PTRDIFF_TYPE__=int -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 > -D_MIPS_SZLONG=3 > 2 > > -D_MIPS_SZPTR=32 -U__mips64 -U__PIC__ -U__pic__ -D__KERNEL__ -DADHAWK > > head.S > > > > I am quite new to the Linux world. There are definitely something that I > > did not setup properly. If anyone know the reason, your help is highly > > appreciated. Also, what are the latest and stable tool-chain for MIP1 > > big-endian development? > > > > Thanks, > > > > Lisa Hsu > > > > Multimedia Application Group > > TAEC, Toshiba > > 408-526-2771 > > lisa.hsu@taec.toshiba.com > > > > > > > > From owner-linux-mips@oss.sgi.com Fri Jan 5 12:40:34 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 12:40:24 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32450 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 12:40:10 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA10114; Fri, 5 Jan 2001 21:39:55 +0100 (MET) Date: Fri, 5 Jan 2001 21:39:54 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Nicu Popovici cc: linux-mips@oss.sgi.com Subject: Re: Kernel compile error. In-Reply-To: <3A56483D.17B57BD5@isratech.ro> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Fri, 5 Jan 2001, Nicu Popovici wrote: > /home/nicu/JUNGO/linux/include/asm/bugs.h:137: internal error--insn does > not satisfy its constraints: > (insn 244 241 250 (set (reg:SI 66 accum) > (reg:SI 6 a2)) 170 {movsi_internal2} (insn_list 241 > (insn_list:REG_DEP_ANTI 98 (insn_list:REG_DEP_OUTPUT 138 > (insn_list:REG_DEP_ANTI 247 (insn_list:REG_DEP_ANTI 150 (nil)))))) > (nil)) > mips-linux-gcc: Internal compiler error: program cc1 got > fatal signal 6 > make: *** [init/main.o] Error 1 > [nicu@ares linux]$ {standard input}: Assembler messages: > {standard input}:47: Error: unrecognized opcode `movl > %cr0,$2' You are trying to assemble i386 instructions -- probably your include/asm symlink is incorrect. Make sure the ARCH make variable is set to "mips", i.e. either run `make ARCH=mips ' or modify the top-level Makefile (the one from our CVS appears to have ARCH hardcoded to "mips" already). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 5 12:52:54 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 12:52:34 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:38594 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 12:52:14 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA10408; Fri, 5 Jan 2001 21:52:29 +0100 (MET) Date: Fri, 5 Jan 2001 21:52:29 +0100 (MET) From: "Maciej W. Rozycki" To: Lisa.Hsu@taec.toshiba.com cc: linux-mips@oss.sgi.com Subject: Re: questions on the cross-compiler In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Fri, 5 Jan 2001 Lisa.Hsu@taec.toshiba.com wrote: > With the help from Kevin Kissell, I've found out that the compilation > directives "set .mips3[4]" were turned on before cpu_probe() and cpu_probe > () functions in my head.S file. This is the reason why I've got that wrong > code generated although I've specified mip1 in the gcc options. > > I 've temporarily used #define to add "set .mips1" in the code to fix the > problem. My question now, is: how can we make the kernel code flexible > to free from the problem of the one that I've got? 1. Don't use "set .mips*" unless absolutely needed. The right ISA level is already set via a compiler option depending on the host CPU selected upon kernel configuration. 2. If you can't avoid "set .mips*" for some reason, then always restore the default state after the relevant code, either by ".set mips0" or by ".set push" and ".set pop". -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 5 13:10:54 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 13:10:44 -0800 Received: from mailgate2.zdv.Uni-Mainz.DE ([134.93.8.57]:14845 "EHLO mailgate2.zdv.Uni-Mainz.DE") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 13:10:34 -0800 Received: from arthur.zdv.Uni-Mainz.DE (arthur.zdv.Uni-Mainz.DE [134.93.8.145]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f05LAW022811; Fri, 5 Jan 2001 22:10:32 +0100 (MET) Received: (from martin@localhost) by arthur.zdv.Uni-Mainz.DE (8.10.2/8.10.2) id f05LAVD25800; Fri, 5 Jan 2001 22:10:31 +0100 (MET) From: Christoph Martin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14934.14407.120130.469971@arthur.zdv.Uni-Mainz.DE> Date: Fri, 5 Jan 2001 22:10:31 +0100 (MET) To: Nicu Popovici Cc: Christoph Martin , linux-mips@oss.sgi.com, linux-mips@fnet.fr, debian-mips@lists.debian.org Subject: Re: glibc 2.2 on MIPS In-Reply-To: <3A5652B9.1D509038@isratech.ro> References: <14932.57412.617757.439688@arthur.zdv.Uni-Mainz.DE> <3A5652B9.1D509038@isratech.ro> X-Mailer: VM 6.75 under Emacs 19.34.1 Organization: Johannes Gutenberg-Universitaet Mainz Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Nicu Popovici writes: > Hello , > > I am bothering you again. > Related to gcc 2.95.2 --- it has any patches for porting to mips or not ? I mean , > where do I find the patches for gcc-2.95.2 for mips if there are some files. I saw > that you said something like that "gcc 2.95.2 + CVS from 2.95 branch." What do you > mean ? "gcc 2.95.2 + CVS from 2.95 branch." is what debian has in its gcc-2.95.2. The mips patches are - as I said - in the src.rpm's on ftp.ds2.pg.gda.pl/pub/macro/SRPMS/ C From owner-linux-mips@oss.sgi.com Fri Jan 5 14:19:26 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 14:19:15 -0800 Received: from mx.mips.com ([206.31.31.226]:56748 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 14:18:54 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA06583; Fri, 5 Jan 2001 14:18:48 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA11050; Fri, 5 Jan 2001 14:18:34 -0800 (PST) Message-ID: <006c01c07765$fdd26440$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , Cc: References: Subject: Re: questions on the cross-compiler Date: Fri, 5 Jan 2001 23:22:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > With the help from Kevin Kissell, I've found out that the compilation > > directives "set .mips3[4]" were turned on before cpu_probe() and cpu_probe > > () functions in my head.S file. This is the reason why I've got that wrong > > code generated although I've specified mip1 in the gcc options. > > > > I 've temporarily used #define to add "set .mips1" in the code to fix the > > problem. My question now, is: how can we make the kernel code flexible > > to free from the problem of the one that I've got? > > 1. Don't use "set .mips*" unless absolutely needed. The right ISA level > is already set via a compiler option depending on the host CPU selected > upon kernel configuration. Lisa's underlying problem may be that there isn't a Config option for the R39xx CPUs, and she's ended up getting an R4000 (or whatever) configuration by default. At some point specific support for the R3900 features (MIPS II ISA, seperate hardware interrupt vector, etc.) should go into the kernel, but for the moment, you should make sure that when you do the initial "make config" (or xconfig or menuconfig or whatever) you select an R3000 CPU. You won't get it by default. You may also need to hack the head.S code to detect an R39xx PrID value and replace it with an R3000 value before it gets used by the kernel. Otherwise, you may need to generate additional cases/conditionals for R3900 wherever you see R3000 called out in the existing code. If your kernel base has my cpu_probe() in C, adding R39xx support will be much easier, but while I *think* I set it up such that, if the R4K_EXCEPTION_MODEL option bit isn't set, the kernel assumes an R3K model, I never tested that option - not having any R3xxx platforms in the lab! Kevin K. From owner-linux-mips@oss.sgi.com Fri Jan 5 14:42:26 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 14:42:16 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:35011 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 14:41:56 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA14271; Fri, 5 Jan 2001 23:41:35 +0100 (MET) Date: Fri, 5 Jan 2001 23:41:34 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Lisa.Hsu@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: questions on the cross-compiler In-Reply-To: <006c01c07765$fdd26440$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Fri, 5 Jan 2001, Kevin D. Kissell wrote: > Lisa's underlying problem may be that there isn't a Config > option for the R39xx CPUs, and she's ended up getting an > R4000 (or whatever) configuration by default. It's easy to add right options for yet another CPU -- see arch/mips/Makefile. Anyway, for the mips port (as opposed to mips64) you'll never get anything beyond "-mips2" passed to the toolchain. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 5 17:47:27 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 17:47:17 -0800 Received: from chmls05.mediaone.net ([24.147.1.143]:9977 "EHLO chmls05.mediaone.net") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 17:47:02 -0800 Received: from decoy (h00a0cc39f081.ne.mediaone.net [24.218.248.129]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id UAA09492; Fri, 5 Jan 2001 20:46:45 -0500 (EST) From: "Jay Carlson" To: "Kevin D. Kissell" , "Maciej W. Rozycki" , Cc: Subject: RE: questions on the cross-compiler Date: Fri, 5 Jan 2001 20:46:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <006c01c07765$fdd26440$0deca8c0@Ulysses> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Kevin D. Kissell writes: > Lisa's underlying problem may be that there isn't a Config > option for the R39xx CPUs, and she's ended up getting an > R4000 (or whatever) configuration by default. > > At some point specific support for the R3900 features > (MIPS II ISA, seperate hardware interrupt vector, etc.) > should go into the kernel, [...] http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/mips/r39xx/?cvsroot =linux-vr The TX3912 is supported by the Linux VR kernel tree. I'm not sure it's been tested in a while, but kernel sources from a few months ago run nice on my VTech Helio. Jay From owner-linux-mips@oss.sgi.com Sat Jan 6 09:37:39 2001 Received: by oss.sgi.com id ; Sat, 6 Jan 2001 09:37:31 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:25341 "EHLO lappi") by oss.sgi.com with ESMTP id ; Sat, 6 Jan 2001 09:37:17 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Sat, 6 Jan 2001 15:27:25 -0200 Date: Sat, 6 Jan 2001 15:27:22 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Nicu Popovici , linux-mips@oss.sgi.com Subject: Re: Kernel compile error. Message-ID: <20010106152722.C2841@bacchus.dhis.org> References: <3A56483D.17B57BD5@isratech.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Jan 05, 2001 at 09:39:54PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Fri, Jan 05, 2001 at 09:39:54PM +0100, Maciej W. Rozycki wrote: > You are trying to assemble i386 instructions -- probably your include/asm > symlink is incorrect. Make sure the ARCH make variable is set to "mips", > i.e. either run `make ARCH=mips ' or modify the top-level > Makefile (the one from our CVS appears to have ARCH hardcoded to "mips" > already). The MIPS sources have ARCH hardwired to mips so his problem means he's trying to compile some other source tree - which probably will fail even with your hints. Ralf From owner-linux-mips@oss.sgi.com Sun Jan 7 06:22:49 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 06:22:39 -0800 Received: from router.isratech.ro ([193.226.114.69]:36359 "EHLO router.isratech.ro") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 06:22:22 -0800 Received: from isratech.ro (calin.cs.tuiasi.ro [193.231.15.163]) by router.isratech.ro (8.10.2/8.10.2) with ESMTP id f07EM6l21409 for ; Sun, 7 Jan 2001 16:22:07 +0200 Message-ID: <3A58E9B1.459A33C1@isratech.ro> Date: Sun, 07 Jan 2001 17:12:02 -0500 From: Nicu Popovici X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.15-2.5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Loading srec imagine problem. Content-Type: multipart/mixed; boundary="------------9AAF69DA117558ADC28E8C31" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This is a multi-part message in MIME format. --------------9AAF69DA117558ADC28E8C31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello , I have now the following cross toolchain binutils 2.10.1 - egcs.1.0.3a - glibc-2.0.6. I manage to cross compile the kernel for mips and when I try to load the srec imagine on the mips I get the following error. For this srec imagine I used mips-linux-objcopy -O srec vmlinux srecimagine. **************************** Exception occurred **************************** TLB exception (store) CAUSE = 0x8080000c STATUS = 0x00000403 EPC = 0x80024a0c BADVADDR = 0x000036e0 ERROREPC = 0x800131f0 $ 0(zr):0x00000000 $ 8(t0):0x00000081 $16(s0):0x80060000 $24(t8):0x80030f68 $ 1(at):0x00000000 $ 9(t1):0x80026178 $17(s1):0x80060f80 $25(t9):0x00000009 $ 2(v0):0x000036e0 $10(t2):0x00000000 $18(s2):0x0000003a $26(k0):0x00000000 $ 3(v1):0x00000000 $11(t3):0x80108390 $19(s3):0x80032bd8 $27(k1):0x00000000 $ 4(a0):0x000036e4 $12(t4):0x80020000 $20(s4):0x0000d004 $28(gp):0x80037b98 $ 5(a1):0x80060ec4 $13(t5):0x00000081 $21(s5):0x00000002 $29(sp):0x80060e50 $ 6(a2):0x00000010 $14(t6):0x00000080 $22(s6):0x00000002 $30(s8):0x80030000 $ 7(a3):0x80060ed0 $15(t7):0x80026178 $23(s7):0x80030f68 $31(ra):0x8001f57c *************************************************************************** What am I doing wrong here ? Regards, Nicu --------------9AAF69DA117558ADC28E8C31 Content-Type: text/x-vcard; charset=us-ascii; name="octavp.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Nicu Popovici Content-Disposition: attachment; filename="octavp.vcf" begin:vcard n:POPOVICI;Nicolae Octavian tel;cell:+40 93 605020 x-mozilla-html:FALSE org:SC Silicon Service SRL;Software adr:;;;;;; version:2.1 email;internet:octavp@isratech.ro title:Software engineer x-mozilla-cpt:;0 fn:Nicolae Octavian POPOVICI end:vcard --------------9AAF69DA117558ADC28E8C31-- From owner-linux-mips@oss.sgi.com Sun Jan 7 07:20:39 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 07:20:30 -0800 Received: from tele-post-20.mail.demon.net ([194.217.242.20]:56836 "EHLO tele-post-20.mail.demon.net") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 07:20:10 -0800 Received: from nebulas.demon.co.uk ([194.222.197.186]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14FHc7-000DKx-0K for linux-mips@oss.sgi.com; Sun, 7 Jan 2001 15:20:07 +0000 Received: from nebulas.demon.co.uk (IDENT:laguest@localhost [127.0.0.1]) by nebulas.demon.co.uk (8.11.0/8.11.0) with SMTP id f07FO9H01320 for ; Sun, 7 Jan 2001 15:24:09 GMT From: "Luke A. Guest" To: linux-mips@oss.sgi.com Subject: Buying an old SGI machine. Date: Sun, 7 Jan 2001 15:24:08 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01010715240800.01310@nebulas.demon.co.uk> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hi, I'm new to the list and have been looking to buy an old SGI machine, for development purposes. This means that I would be looking for a machine that has a decent compile time, also, I want to play around with OpenGL, so decent graphics is a must. Now, I read in the archives some time ago that somebody knew of a place he could get O2's (in Germany) for around $600; I don't know if this is true - or just SPAM - but could that person get in touch with me please? Anyway, I have been looking at the purple Indigo2 as these seem to really cheap machines and rather expandable, but I can never seem to find anyone who is selling Irix media - why is this? I know that Linux doesn't work with I2's yet, but I'm also willing to "try" to work on helping with that, as I'm currently looking into OS concepts on my PC, so knowledge of other architecture's would be helpful. But how would I get access to documentation for I2's? I see (do far) that the docs aren't available yet, what would I have to do? Thanks, Luke A. Guest. From owner-linux-mips@oss.sgi.com Sun Jan 7 07:35:19 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 07:35:10 -0800 Received: from [194.90.113.98] ([194.90.113.98]:50692 "EHLO yes.home.krftech.com") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 07:35:04 -0800 Received: from jungo.com (kobie.home.krftech.com [199.204.71.69]) by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id SAA17579 for ; Sun, 7 Jan 2001 18:38:21 +0200 Message-ID: <3A588C36.771FFC16@jungo.com> Date: Sun, 07 Jan 2001 17:33:10 +0200 From: Michael Shmulevich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Compiling MILO on big-emdian References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello all, I was compiling a milo-0.27 lately on i586 machine for mips32 platform. I am using binutils 2.8.1 egcs1.0.3a, and glibc 2.0.6. I am using some custom MIPS board with QED RM5261 processor. I use patched 2.2.14 kernel which is known to compile and run on my hardware. ./configure went smoothly, but at a build time I started to get problems. First, I got missing . After a short search I have found one in annals of the Internet. This didn't really help me, because finally I got an assembler errors for libstand/cachectl.o: [michaels@kobie libstand]$ make mips-linux-gcc -Wall -O2 -mips2 -Wa,-mips3 -mcpu=r4400 -D__KERNEL__ -DLOADADDR=0x80600000 -DKERNELBASE=0x80000000 -DVERSION=0.27 -DDEBUG=1 -DBOOTMETHOD_ARC -nostdinc -I/usr/local/lib/gcc-lib/mips-linux/egcs-2.90.29/include -I/home/michaels/atlas/rg.mips/linux/include -I../libstand/include -I../libarc/include -c cachectl.S -o cachectl.o cachectl.S: Assembler messages: cachectl.S:58: Error: absolute expression required `li' cachectl.S:59: Warning: Instruction cache requires absolute expression cachectl.S:60: Warning: Instruction cache requires absolute expression cachectl.S:61: Warning: Instruction cache requires absolute expression cachectl.S:62: Warning: Instruction cache requires absolute expression cachectl.S:63: Warning: Instruction cache requires absolute expression cachectl.S:64: Warning: Instruction cache requires absolute expression cachectl.S:65: Warning: Instruction cache requires absolute expression cachectl.S:66: Warning: Instruction cache requires absolute expression Line 58 is li t1,CACHELINES-1 Line 59 is cache Index_Writeback_Inv_D,32(t0) and obviously CACHELINES is not defined anywhere, not even within the kernel source tree. At least not my patched 2.2.14. Also, I am confused what causes cache to go crazy on Index_Writeback_Inv_D ... So, if anyone has ideas, plase forward them on. Also, I wonder if there is a public CVS repository for milo or any other "authoritative" storage. Thanks in advance, Michael. From owner-linux-mips@oss.sgi.com Sun Jan 7 11:15:21 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 11:15:11 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:38895 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 11:15:03 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Sun, 7 Jan 2001 17:05:34 -0200 Date: Sun, 7 Jan 2001 17:05:28 -0200 From: Ralf Baechle To: Michael Shmulevich Cc: linux-mips@oss.sgi.com Subject: Re: Compiling MILO on big-emdian Message-ID: <20010107170528.A870@bacchus.dhis.org> References: <3A588C36.771FFC16@jungo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A588C36.771FFC16@jungo.com>; from michaels@jungo.com on Sun, Jan 07, 2001 at 05:33:10PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Sun, Jan 07, 2001 at 05:33:10PM +0200, Michael Shmulevich wrote: > I was compiling a milo-0.27 lately on i586 machine for mips32 platform. The answer is easy - don't use Milo; it's not used since a loooong time for any of the supported systems anymore. Ralf From owner-linux-mips@oss.sgi.com Sun Jan 7 11:36:22 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 11:36:12 -0800 Received: from haliga.physik.TU-Cottbus.De ([141.43.75.9]:31762 "HELO haliga.physik.tu-cottbus.de") by oss.sgi.com with SMTP id ; Sun, 7 Jan 2001 11:35:50 -0800 Received: by haliga.physik.tu-cottbus.de (Postfix, from userid 7215) id 723F48D67; Sun, 7 Jan 2001 20:35:45 +0100 (CET) Date: Sun, 7 Jan 2001 20:35:45 +0100 To: linux-mips@oss.sgi.com Subject: Re: Buying an old SGI machine. Message-ID: <20010107203545.A26852@physik.tu-cottbus.de> References: <01010715240800.01310@nebulas.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01010715240800.01310@nebulas.demon.co.uk>; from laguest@nebulas.demon.co.uk on Sun, Jan 07, 2001 at 03:24:08PM +0000 From: heinold@physik.tu-cottbus.de (H.Heinold) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Sun, Jan 07, 2001 at 03:24:08PM +0000, Luke A. Guest wrote: > Hi, > > I'm new to the list and have been looking to buy an old SGI machine, for > development purposes. This means that I would be looking for a machine that > has a decent compile time, also, I want to play around with OpenGL, so decent > graphics is a must. > For the I2 series the specs for the graphics cars are lost. X is only supported for the indys, please read the archieve. > Now, I read in the archives some time ago that somebody knew of a place he > could get O2's (in Germany) for around $600; I don't know if this is true - > or just SPAM - but could that person get in touch with me please? > $600 are around DM1200 for this money you get an indigo2 but not an O2. > Anyway, I have been looking at the purple Indigo2 as these seem to really > cheap machines and rather expandable, but I can never seem to find anyone who > is selling Irix media - why is this? > A purple Indigo2 stands in front of me. You got Irix installations media when ypu buy a new machine or take in an auction of ebay. > I know that Linux doesn't work with I2's yet, but I'm also willing to "try" > to work on helping with that, as I'm currently looking into OS concepts on my > PC, so knowledge of other architecture's would be helpful. > False Linux runs on Iindigo2 but not not on O2, please read the archieve of the ml. > But how would I get access to documentation for I2's? I see (do far) that the > docs aren't available yet, what would I have to do? > Read the archieve of ml and ask the guys at sgi. > Thanks, > Luke A. Guest. -- Henning Heinold From owner-linux-mips@oss.sgi.com Mon Jan 8 00:06:54 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 00:06:44 -0800 Received: from [194.90.113.98] ([194.90.113.98]:54276 "EHLO yes.home.krftech.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 00:06:27 -0800 Received: from jungo.com (kobie.home.krftech.com [199.204.71.69]) by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id LAA21266; Mon, 8 Jan 2001 11:09:41 +0200 Message-ID: <3A59748C.BB3D5A2F@jungo.com> Date: Mon, 08 Jan 2001 10:04:28 +0200 From: Michael Shmulevich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: Compiling MILO on big-emdian References: <3A588C36.771FFC16@jungo.com> <20010107170528.A870@bacchus.dhis.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Ralf, Thank you for reply. I wonder if I can take the initialization routines from it to use in my custom flash bootloader? I do not mean "cut & paste" bu rather ideas. I need a loader that will copy the kernel with a ramdisk from flash to ram and start the kernel. I saw that there is something similar in milo. By the way, how do supported machines boot nowadays? Lilo? Thanks, michael. Ralf Baechle wrote: > On Sun, Jan 07, 2001 at 05:33:10PM +0200, Michael Shmulevich wrote: > > > I was compiling a milo-0.27 lately on i586 machine for mips32 platform. > > The answer is easy - don't use Milo; it's not used since a loooong time > for any of the supported systems anymore. > > Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 01:41:15 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 01:41:05 -0800 Received: from mx.mips.com ([206.31.31.226]:16326 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 01:40:54 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA16939 for ; Mon, 8 Jan 2001 01:40:50 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA18334 for ; Mon, 8 Jan 2001 01:40:47 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id KAA12624 for ; Mon, 8 Jan 2001 10:40:13 +0100 (MET) Message-ID: <3A598AFC.83204F56@mips.com> Date: Mon, 08 Jan 2001 10:40:12 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: User applications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing I have a few questions about user applications. When a new user process is started will its user space be cleared by the kernel or is there a potential leak from an older user process ? What about the registers values, are they cleared for each new user application or will it simply contain the current value it got when the user application is started ? How can you flush the data and instruction cashes from a user application ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jan 8 03:44:46 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 03:44:36 -0800 Received: from noose.gt.owl.de ([62.52.19.4]:24585 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 8 Jan 2001 03:44:23 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id D41187F3; Mon, 8 Jan 2001 12:44:19 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 22624F44B; Mon, 8 Jan 2001 10:09:30 +0100 (CET) Date: Mon, 8 Jan 2001 10:09:30 +0100 From: Florian Lohoff To: Nicu Popovici Cc: linux-mips@oss.sgi.com Subject: Re: Loading srec imagine problem. Message-ID: <20010108100930.A6841@paradigm.rfc822.org> References: <3A58E9B1.459A33C1@isratech.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A58E9B1.459A33C1@isratech.ro>; from octavp@isratech.ro on Sun, Jan 07, 2001 at 05:12:02PM -0500 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Sun, Jan 07, 2001 at 05:12:02PM -0500, Nicu Popovici wrote: > Hello , > > I have now the following cross toolchain > binutils 2.10.1 - egcs.1.0.3a - glibc-2.0.6. > > I manage to cross compile the kernel for mips and when I try to load the > srec imagine on the mips I get the following error. > > For this srec imagine I used mips-linux-objcopy -O srec vmlinux > srecimagine. Wouldnt this use the original load address of the vmlinux as the srec address ? Wouldnt this mean you are probably overwriting your monitor while loading the srec ? Ususally you would load the image via srec to a different location with a small copy and run type code in front. Without a memory map etc one cant help here ... Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Mon Jan 8 03:56:35 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 03:56:26 -0800 Received: from router.isratech.ro ([193.226.114.69]:47109 "EHLO router.isratech.ro") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 03:56:12 -0800 Received: from isratech.ro (calin.cs.tuiasi.ro [193.231.15.163]) by router.isratech.ro (8.10.2/8.10.2) with ESMTP id f08Bsnl07495; Mon, 8 Jan 2001 13:54:50 +0200 Message-ID: <3A5A18B4.D7339CF1@isratech.ro> Date: Mon, 08 Jan 2001 14:44:52 -0500 From: Nicu Popovici X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.15-2.5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florian Lohoff CC: linux-mips@oss.sgi.com Subject: Re: Loading srec imagine problem. References: <3A58E9B1.459A33C1@isratech.ro> <20010108100930.A6841@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello , Florian Lohoff wrote: > On Sun, Jan 07, 2001 at 05:12:02PM -0500, Nicu Popovici wrote: > > Hello , > > > > I have now the following cross toolchain > > binutils 2.10.1 - egcs.1.0.3a - glibc-2.0.6. > > > > I manage to cross compile the kernel for mips and when I try to load the > > srec imagine on the mips I get the following error. > > > > For this srec imagine I used mips-linux-objcopy -O srec vmlinux > > srecimagine. > > Wouldnt this use the original load address of the vmlinux as the srec > address ? Wouldnt this mean you are probably overwriting your monitor > while loading the srec ? Ususally you would load the image via srec to > a different location with a small copy and run type code in front. I do not know if this is the problem. I made objdump on this srec imagine and it looks like the sections begin somewhere below 0x80100000 address and for the srec imagine ( the one that I can load on ) the sections begin after 0x8010000 address. So the problem is here , something with setting the write address for this srec imagine. Maybe from objcopy ( but I do not think so ) or from linker. Nicu From owner-linux-mips@oss.sgi.com Mon Jan 8 05:33:26 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 05:33:06 -0800 Received: from [194.90.113.98] ([194.90.113.98]:9221 "EHLO yes.home.krftech.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 05:32:53 -0800 Received: from jungo.com (kobie.home.krftech.com [199.204.71.69]) by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id QAA23718; Mon, 8 Jan 2001 16:35:48 +0200 Message-ID: <3A59C0FB.62E52EF0@jungo.com> Date: Mon, 08 Jan 2001 15:30:35 +0200 From: Michael Shmulevich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Carsten Langgaard , "linux-mips@oss.sgi.com" Subject: Re: User applications References: <3A598AFC.83204F56@mips.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Carsten Langgaard wrote: > I have a few questions about user applications. > > When a new user process is started will its user space be cleared by the > kernel or is there a potential leak from an older user process ? Usually it is defied by the loader. If the data section contents is set to LOAD, then the contents of the section will be loaded from disk (no leak), if not -- whatever values left i nmemory will be there, or exactly, the virtual page of some other proccess that was swapped out or ended. > What about the registers values, are they cleared for each new user > application or will it simply contain the current value it got when the > user application is started ? It depends on the context switch algorithm of the processor, I think. > How can you flush the data and instruction cashes from a user > application ? > As far as I understand, ASID must take care of it. It contains unique IDs per process virtual space, so that even though virtual addresses may be found in TLB, their ASID will be different, causing TLB miss and probably page fault. > > /Carsten > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com Michael. From owner-linux-mips@oss.sgi.com Mon Jan 8 05:53:56 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 05:53:46 -0800 Received: from mx.mips.com ([206.31.31.226]:4296 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 05:53:25 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA17844; Mon, 8 Jan 2001 05:52:49 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA23644; Mon, 8 Jan 2001 05:52:46 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id OAA23151; Mon, 8 Jan 2001 14:52:11 +0100 (MET) Message-ID: <3A59C60A.71FA35E0@mips.com> Date: Mon, 08 Jan 2001 14:52:10 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Shmulevich CC: "linux-mips@oss.sgi.com" Subject: Re: User applications References: <3A598AFC.83204F56@mips.com> <3A59C0FB.62E52EF0@jungo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Michael Shmulevich wrote: > Carsten Langgaard wrote: > > > I have a few questions about user applications. > > > > When a new user process is started will its user space be cleared by the > > kernel or is there a potential leak from an older user process ? > > Usually it is defied by the loader. If the data section contents is set to > LOAD, then the contents of the section will be loaded from disk (no leak), > if not -- whatever values left i nmemory will be there, or exactly, the > virtual page of some other proccess that was swapped out or ended. > > > What about the registers values, are they cleared for each new user > > application or will it simply contain the current value it got when the > > user application is started ? > > It depends on the context switch algorithm of the processor, I think. > > > How can you flush the data and instruction cashes from a user > > application ? > > > > As far as I understand, ASID must take care of it. It contains unique IDs > per process virtual space, so that even > though virtual addresses may be found in TLB, their ASID will be different, > causing TLB miss and probably page fault. > My problem is that I want to make self-modified code, so I need to flush both the instruction and data cache. > > > > > /Carsten > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com > > Michael. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jan 8 06:12:26 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 06:12:07 -0800 Received: from mx.mips.com ([206.31.31.226]:14280 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 06:11:45 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA17923; Mon, 8 Jan 2001 06:11:09 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA23967; Mon, 8 Jan 2001 06:11:06 -0800 (PST) Message-ID: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Carsten Langgaard" , "Michael Shmulevich" References: <3A598AFC.83204F56@mips.com> <3A59C0FB.62E52EF0@jungo.com> Subject: Re: User applications Date: Mon, 8 Jan 2001 15:14:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > When a new user process is started will its user space be cleared by the > > kernel or is there a potential leak from an older user process ? > > Usually it is defied by the loader. If the data section contents is set to > LOAD, then the contents of the section will be loaded from disk (no leak), > if not -- whatever values left i nmemory will be there, or exactly, the > virtual page of some other proccess that was swapped out or ended. Note that what you are describing here is the "exec()" behavior. I believe Carsten was talking about what happens on a "fork()". > > What about the registers values, are they cleared for each new user > > application or will it simply contain the current value it got when the > > user application is started ? > > It depends on the context switch algorithm of the processor, I think. On a fork() (or presumably clone()) operation, the set of registers is copied. Loading a new program ("exec()") should set up the registers that point to the base of the new stack, the environment, etc. Historically, it's up to the runtime startup code ("crt0" in old Unix systems) to do any other register initialization. > > How can you flush the data and instruction cashes from a user > > application ? > > > > As far as I understand, ASID must take care of it. It contains unique IDs > per process virtual space, so that even > though virtual addresses may be found in TLB, their ASID will be different, > causing TLB miss and probably page fault. That won't necessarily affect the caches, though. While it would be possible to do so, I don't believe any existing MIPS implementations include ASID in the cache tags. Hits are determined by an address match, period. Back in the Ancient Old Days of System V, every architecture had an architecture-specific system call entry, the first parameter of which expressed what needed to be done. Do we have such a thing in Linux? That would be the logical place to things like cache flush and the atomic operations that were being discussed here a couple of weeks ago. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 8 06:17:26 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 06:17:16 -0800 Received: from mx.mips.com ([206.31.31.226]:16584 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 06:16:59 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA17947; Mon, 8 Jan 2001 06:16:54 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA24047; Mon, 8 Jan 2001 06:16:51 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id PAA24266; Mon, 8 Jan 2001 15:16:17 +0100 (MET) Message-ID: <3A59CBB0.24160437@mips.com> Date: Mon, 08 Jan 2001 15:16:16 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications References: <3A598AFC.83204F56@mips.com> <3A59C0FB.62E52EF0@jungo.com> <00d801c0797d$5cc410c0$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing "Kevin D. Kissell" wrote: > > > When a new user process is started will its user space be cleared by the > > > kernel or is there a potential leak from an older user process ? > > > > Usually it is defied by the loader. If the data section contents is set to > > LOAD, then the contents of the section will be loaded from disk (no leak), > > if not -- whatever values left i nmemory will be there, or exactly, the > > virtual page of some other proccess that was swapped out or ended. > > Note that what you are describing here is the "exec()" behavior. > I believe Carsten was talking about what happens on a "fork()". > > > > What about the registers values, are they cleared for each new user > > > application or will it simply contain the current value it got when the > > > user application is started ? > > > > It depends on the context switch algorithm of the processor, I think. > > On a fork() (or presumably clone()) operation, the set of registers > is copied. Loading a new program ("exec()") should set up the > registers that point to the base of the new stack, the environment, > etc. Historically, it's up to the runtime startup code ("crt0" in old > Unix systems) to do any other register initialization. > > > > How can you flush the data and instruction cashes from a user > > > application ? > > > > > > > As far as I understand, ASID must take care of it. It contains unique IDs > > per process virtual space, so that even > > though virtual addresses may be found in TLB, their ASID will be > different, > > causing TLB miss and probably page fault. > > That won't necessarily affect the caches, though. While it > would be possible to do so, I don't believe any existing > MIPS implementations include ASID in the cache tags. > Hits are determined by an address match, period. > > Back in the Ancient Old Days of System V, every architecture > had an architecture-specific system call entry, the first parameter > of which expressed what needed to be done. Do we have > such a thing in Linux? That would be the logical place to > things like cache flush and the atomic operations that were > being discussed here a couple of weeks ago. I think I just found it. The system call is sysmips(FLUSH_CACHE). > > Regards, > > Kevin K. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jan 8 06:31:27 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 06:31:08 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:7140 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 06:29:45 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA00208; Mon, 8 Jan 2001 15:16:47 +0100 (MET) Date: Mon, 8 Jan 2001 15:16:46 +0100 (MET) From: "Maciej W. Rozycki" To: Michael Shmulevich cc: Carsten Langgaard , "linux-mips@oss.sgi.com" Subject: Re: User applications In-Reply-To: <3A59C0FB.62E52EF0@jungo.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Michael Shmulevich wrote: > > When a new user process is started will its user space be cleared by the > > kernel or is there a potential leak from an older user process ? > > Usually it is defied by the loader. If the data section contents is set to > LOAD, then the contents of the section will be loaded from disk (no leak), > if not -- whatever values left i nmemory will be there, or exactly, the > virtual page of some other proccess that was swapped out or ended. What!??? I'm assume you are writing about executing a new program and not forking a new process here. In the latter case no memory is changed. When you exec a new program, any allocated memory is cleared by the kernel before returning to the user space. It would be a huge security hole otherwise. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 06:52:57 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 06:52:47 -0800 Received: from noose.gt.owl.de ([62.52.19.4]:40206 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 8 Jan 2001 06:52:25 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 024857F6; Mon, 8 Jan 2001 15:52:22 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id DA104F44B; Mon, 8 Jan 2001 15:53:02 +0100 (CET) Date: Mon, 8 Jan 2001 15:53:02 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Current CVS kernel no-go on R4k Decstation Message-ID: <20010108155302.A18422@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hi, i am seeing this on my R4k Decstation (5000/150) This was the first try [...] Freeing unused PROM memory: 124k freed Freeing unused kernel memory: 60k freed [init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc [init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc Second try doesnt give me any output at all after the "Freeing unused kernel ..." CVS Checkout @ 20010108 ~15:00 MESZ This DECstation is a DS5000/1xx Loading R4000 MMU routines. CPU revision is: 00000430 Primary instruction cache 8kb, linesize 16 bytes. Primary data cache 8kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 32 bytes. Linux version 2.4.0-test11 (flo@paradigm) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Mon Jan 8 15:35:19 CET 2001 Determined physical RAM map: memory: 04000000 @ 00000000 (usable) On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS2 root=/dev/sda2 Calibrating delay loop... 49.81 BogoMIPS Memory: 62600k/65536k available (1269k kernel code, 2936k reserved, 69k data, 60k init) [...] Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Mon Jan 8 07:09:48 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 07:09:39 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:44260 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 07:09:21 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA02303; Mon, 8 Jan 2001 16:07:32 +0100 (MET) Date: Mon, 8 Jan 2001 16:07:31 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications In-Reply-To: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Kevin D. Kissell wrote: > Back in the Ancient Old Days of System V, every architecture > had an architecture-specific system call entry, the first parameter > of which expressed what needed to be done. Do we have > such a thing in Linux? That would be the logical place to > things like cache flush and the atomic operations that were > being discussed here a couple of weeks ago. The only case caches need to be synchronized is modifying some code. The ptrace syscall does it automatically for text writes -- it's needed and used by gdb to set breakpoints, for example. For other code there is cacheflush() which allows you to flush a cache range relevant to a given virtual address (I see it's not implemented very well at the moment). Obviously, you don't want to allow unprivileged users to flush caches as a whole as it could lead to a DoS. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 07:18:47 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 07:18:27 -0800 Received: from mx.mips.com ([206.31.31.226]:62920 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 07:18:25 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA18355; Mon, 8 Jan 2001 07:17:48 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA25341; Mon, 8 Jan 2001 07:17:45 -0800 (PST) Message-ID: <010701c07986$ac768180$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: , "Carsten Langgaard" , "Michael Shmulevich" References: Subject: Re: User applications Date: Mon, 8 Jan 2001 16:21:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing ----- Original Message ----- From: "Maciej W. Rozycki" To: "Kevin D. Kissell" Cc: ; "Carsten Langgaard" ; "Michael Shmulevich" Sent: Monday, January 08, 2001 4:07 PM Subject: Re: User applications > On Mon, 8 Jan 2001, Kevin D. Kissell wrote: > > > Back in the Ancient Old Days of System V, every architecture > > had an architecture-specific system call entry, the first parameter > > of which expressed what needed to be done. Do we have > > such a thing in Linux? That would be the logical place to > > things like cache flush and the atomic operations that were > > being discussed here a couple of weeks ago. > > The only case caches need to be synchronized is modifying some code. Which just happens to be the case under discussion here. >The ptrace syscall does it automatically for text writes -- it's needed and > used by gdb to set breakpoints, for example. For other code there is > cacheflush() which allows you to flush a cache range relevant to a given > virtual address (I see it's not implemented very well at the moment). > > Obviously, you don't want to allow unprivileged users to flush caches as > a whole as it could lead to a DoS. By that logic, we should not allow users to allocate more virtual memory than there is physical memory in the system! A pathological swap program is arguably far a far worse denial of service attack than flushing the caches - so long as by "flush" we mean invalidate with writeback (on copyback caches), of course. From owner-linux-mips@oss.sgi.com Mon Jan 8 08:02:18 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:02:08 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:18917 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:01:55 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA03849; Mon, 8 Jan 2001 16:40:07 +0100 (MET) Date: Mon, 8 Jan 2001 16:40:06 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications In-Reply-To: <010701c07986$ac768180$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Kevin D. Kissell wrote: > > Obviously, you don't want to allow unprivileged users to flush caches as > > a whole as it could lead to a DoS. > > By that logic, we should not allow users to allocate more virtual > memory than there is physical memory in the system! A pathological > swap program is arguably far a far worse denial of service attack There are limits -- see `info setrlimit'. There is no way to prevent a program from executing: while (1) flush_cache_all(); though but the system's performance would suffer much. Remember there is real world out there... Which means sysmips(FLUSH_CACHE, ...) needs to be fixed or removed. > than flushing the caches - so long as by "flush" we mean invalidate > with writeback (on copyback caches), of course. What's wrong with cacheflush(addr, count, which) that actually checks if lies within the caller's address space before performing the flush and returns -EPERM otherwise? It would make the caller crawl like a turtle if it wished to but it would leave other processes alone. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 08:13:38 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:13:17 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:3826 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:13:02 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:03:06 -0200 Date: Mon, 8 Jan 2001 14:03:04 -0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications Message-ID: <20010108140304.A886@bacchus.dhis.org> References: <3A598AFC.83204F56@mips.com> <3A59C0FB.62E52EF0@jungo.com> <00d801c0797d$5cc410c0$0deca8c0@Ulysses> <3A59CBB0.24160437@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A59CBB0.24160437@mips.com>; from carstenl@mips.com on Mon, Jan 08, 2001 at 03:16:16PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 03:16:16PM +0100, Carsten Langgaard wrote: > I think I just found it. > The system call is sysmips(FLUSH_CACHE). Don't. Sysmips(FLUSH_CACHE, ...) only allows very coarse flush operation, that is flushing all caches. The whole sysmips(2) call exists in Linux only as a stone age compatibility thing. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 08:15:18 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:15:08 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:30706 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:14:57 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:05:06 -0200 Date: Mon, 8 Jan 2001 14:05:06 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications Message-ID: <20010108140506.B886@bacchus.dhis.org> References: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 08, 2001 at 04:07:31PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 04:07:31PM +0100, Maciej W. Rozycki wrote: > The only case caches need to be synchronized is modifying some code. The > ptrace syscall does it automatically for text writes -- it's needed and > used by gdb to set breakpoints, for example. For other code there is > cacheflush() which allows you to flush a cache range relevant to a given > virtual address (I see it's not implemented very well at the moment). > > Obviously, you don't want to allow unprivileged users to flush caches as > a whole as it could lead to a DoS. You obviously want to allow partial cache flushes or trampolines don't work and flushing the entire cache can be constructed from that. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 08:24:37 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:24:18 -0800 Received: from mx.mips.com ([206.31.31.226]:57545 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:24:03 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA18989; Mon, 8 Jan 2001 08:23:59 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id IAA26782; Mon, 8 Jan 2001 08:23:56 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id RAA29505; Mon, 8 Jan 2001 17:23:21 +0100 (MET) Message-ID: <3A59E978.873182CB@mips.com> Date: Mon, 08 Jan 2001 17:23:20 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications References: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> <20010108140506.B886@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Ralf Baechle wrote: > On Mon, Jan 08, 2001 at 04:07:31PM +0100, Maciej W. Rozycki wrote: > > > The only case caches need to be synchronized is modifying some code. The > > ptrace syscall does it automatically for text writes -- it's needed and > > used by gdb to set breakpoints, for example. For other code there is > > cacheflush() which allows you to flush a cache range relevant to a given > > virtual address (I see it's not implemented very well at the moment). > > > > Obviously, you don't want to allow unprivileged users to flush caches as > > a whole as it could lead to a DoS. > > You obviously want to allow partial cache flushes or trampolines don't work > and flushing the entire cache can be constructed from that. > What we need is a mechanism to partial invalidate the I-cache and a mechanism to write-back and/or invalidate the D-cache. /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jan 8 08:35:47 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:35:38 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:28661 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:35:16 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:25:13 -0200 Date: Mon, 8 Jan 2001 14:25:13 -0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: User applications Message-ID: <20010108142513.C886@bacchus.dhis.org> References: <3A598AFC.83204F56@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A598AFC.83204F56@mips.com>; from carstenl@mips.com on Mon, Jan 08, 2001 at 10:40:12AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 10:40:12AM +0100, Carsten Langgaard wrote: > When a new user process is started will its user space be cleared by the > kernel or is there a potential leak from an older user process ? A new process is started by the clone(2) or fork(2) syscalls. Module the options that can be passed to clone(2) the two only create an identical copy of the invoking process, so they're designed to leak information by design ;-) execve(2) replaces the existing mappings with a new process image loaded from files plus a newly created stack area. No old mappings survive, so there in memory there is no information leak. > What about the registers values, are they cleared for each new user > application or will it simply contain the current value it got when the > user application is started ? We make no attempt at the integer registers for a new process, so some information might be leaked in registers. All the callee saved registers will be passed unchanged to the child process; the caller saved registers except those that are used as syscall return values will return random garbage. Floating point registers will be cleared with SNANs as soon as the process is attempting to use a FPU for the first time, that is we won't leak information via fpu registers. (Ooops, we're not Orange Book B1 compliant, how sad ;-) > How can you flush the data and instruction cashes from a user application ? cacheflush(2). See man page. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 08:38:08 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:37:48 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:55797 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:37:35 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:27:29 -0200 Date: Mon, 8 Jan 2001 14:27:29 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications Message-ID: <20010108142729.D886@bacchus.dhis.org> References: <010701c07986$ac768180$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 08, 2001 at 04:40:06PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 04:40:06PM +0100, Maciej W. Rozycki wrote: > > than flushing the caches - so long as by "flush" we mean invalidate > > with writeback (on copyback caches), of course. > > What's wrong with cacheflush(addr, count, which) that actually checks if > lies within the caller's address space before > performing the flush and returns -EPERM otherwise? It would make the > caller crawl like a turtle if it wished to but it would leave other > processes alone. cacheflush(2) actually is supposed to handle things that way. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 08:40:37 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:40:18 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:55797 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:40:17 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:30:14 -0200 Date: Mon, 8 Jan 2001 14:30:14 -0200 From: Ralf Baechle To: Carsten Langgaard Cc: Ralf Baechle , "Maciej W. Rozycki" , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications Message-ID: <20010108143014.E886@bacchus.dhis.org> References: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> <20010108140506.B886@bacchus.dhis.org> <3A59E978.873182CB@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A59E978.873182CB@mips.com>; from carstenl@mips.com on Mon, Jan 08, 2001 at 05:23:20PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 05:23:20PM +0100, Carsten Langgaard wrote: > What we need is a mechanism to partial invalidate the I-cache and a mechanism > to write-back and/or invalidate the D-cache. There is this nice little man page which should even be installed on your Linux/Inhell box: CACHEFLUSH(2) Linux Programmer's Manual CACHEFLUSH(2) NAME cacheflush - flush contents of instruction and/or data cache SYNOPSIS #include int cacheflush(char *addr, int nbytes, int cache); DESCRIPTION cacheflush flushes contents of indicated cache(s) for user addresses in the range addr to (addr+nbytes-1). Cache may be one of: ICACHE Flush the instruction cache. DCACHE Write back to memory and invalidate the affected valid cache lines. BCACHE Same as (ICACHE|DCACHE). RETURN VALUE cacheflush returns 0 on success or -1 on error. If errors are detected, errno will indicate the error. ERRORS EINVAL cache parameter is not one of ICACHE, DCACHE, or BCACHE. EFAULT Some or all of the address range addr to (addr+nbytes-1) is not accessible. BUGS The current implementation ignores the addr and nbytes parameters. Therefore always the whole cache is flushed. NOTE This system call is only available on MIPS based systems. It should not be used in programs intended to be portable. Linux 2.0.32 27 June 95 1 From owner-linux-mips@oss.sgi.com Mon Jan 8 08:44:38 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:44:18 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:48869 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:44:08 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA06414; Mon, 8 Jan 2001 17:34:06 +0100 (MET) Date: Mon, 8 Jan 2001 17:34:05 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications In-Reply-To: <20010108140506.B886@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Ralf Baechle wrote: > You obviously want to allow partial cache flushes or trampolines don't work > and flushing the entire cache can be constructed from that. It depends on the implementation. The current one obviously allows it. ;-) I'm writing of the design. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 08:45:57 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:45:38 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:56805 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:45:32 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA06739; Mon, 8 Jan 2001 17:43:26 +0100 (MET) Date: Mon, 8 Jan 2001 17:43:24 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications In-Reply-To: <20010108142729.D886@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Ralf Baechle wrote: > > What's wrong with cacheflush(addr, count, which) that actually checks if > > lies within the caller's address space before > > performing the flush and returns -EPERM otherwise? It would make the > > caller crawl like a turtle if it wished to but it would leave other > > processes alone. > > cacheflush(2) actually is supposed to handle things that way. Didn't I write it clearly-enough? ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 08:51:37 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:51:27 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:25592 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:51:05 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 14:41:11 -0200 Date: Mon, 8 Jan 2001 14:41:11 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, Carsten Langgaard , Michael Shmulevich Subject: Re: User applications Message-ID: <20010108144111.F886@bacchus.dhis.org> References: <20010108142729.D886@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 08, 2001 at 05:43:24PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 05:43:24PM +0100, Maciej W. Rozycki wrote: > > > What's wrong with cacheflush(addr, count, which) that actually checks if > > > lies within the caller's address space before > > > performing the flush and returns -EPERM otherwise? It would make the > > > caller crawl like a turtle if it wished to but it would leave other > > > processes alone. > > > > cacheflush(2) actually is supposed to handle things that way. > > Didn't I write it clearly-enough? ;-) return -EOVERBLOODINCAFFEIN; Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 08:51:57 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:51:37 -0800 Received: from mx.mips.com ([206.31.31.226]:18890 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:51:34 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA19265; Mon, 8 Jan 2001 08:51:29 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id IAA27482; Mon, 8 Jan 2001 08:51:26 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id RAA00674; Mon, 8 Jan 2001 17:50:51 +0100 (MET) Message-ID: <3A59EFEB.9D35514E@mips.com> Date: Mon, 08 Jan 2001 17:50:51 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications References: <00d801c0797d$5cc410c0$0deca8c0@Ulysses> <20010108140506.B886@bacchus.dhis.org> <3A59E978.873182CB@mips.com> <20010108143014.E886@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Exactly that I need, but I don't think it is implemented properly for mips. It simply flushes all the caches, no matter what options you gives it. /Carsten Ralf Baechle wrote: > On Mon, Jan 08, 2001 at 05:23:20PM +0100, Carsten Langgaard wrote: > > > What we need is a mechanism to partial invalidate the I-cache and a mechanism > > to write-back and/or invalidate the D-cache. > > There is this nice little man page which should even be installed on your > Linux/Inhell box: > > CACHEFLUSH(2) Linux Programmer's Manual CACHEFLUSH(2) > > NAME > cacheflush - flush contents of instruction and/or data > cache > > SYNOPSIS > #include > > int cacheflush(char *addr, int nbytes, int cache); > > DESCRIPTION > cacheflush flushes contents of indicated cache(s) for user > addresses in the range addr to (addr+nbytes-1). Cache may > be one of: > > ICACHE Flush the instruction cache. > > DCACHE Write back to memory and invalidate the affected > valid cache lines. > > BCACHE Same as (ICACHE|DCACHE). > > RETURN VALUE > cacheflush returns 0 on success or -1 on error. If errors > are detected, errno will indicate the error. > > ERRORS > EINVAL cache parameter is not one of ICACHE, DCACHE, or > BCACHE. > > EFAULT Some or all of the address range addr to > (addr+nbytes-1) is not accessible. > > BUGS > The current implementation ignores the addr and nbytes > parameters. Therefore always the whole cache is flushed. > > NOTE > This system call is only available on MIPS based systems. > It should not be used in programs intended to be portable. > > Linux 2.0.32 27 June 95 1 -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jan 8 09:45:57 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 09:45:49 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:48358 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 09:45:33 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA06652; Mon, 8 Jan 2001 17:40:24 +0100 (MET) Date: Mon, 8 Jan 2001 17:40:23 +0100 (MET) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications In-Reply-To: <3A59E978.873182CB@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Carsten Langgaard wrote: > What we need is a mechanism to partial invalidate the I-cache and a mechanism > to write-back and/or invalidate the D-cache. What's wrong with the already mentioned cachectl? $ mipsel-linux-objdump -T /usr/mipsel-linux/lib/libc-2.2.so | grep cachectl 00000000600ca0a0 w DF *ABS* 0000000000000000 GLIBC_2.0 cachectl $ ls /usr/mipsel-linux/include/sys/cachectl.h /usr/mipsel-linux/include/sys/cachectl.h -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 09:52:58 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 09:52:38 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:65266 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 09:52:27 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 15:42:32 -0200 Date: Mon, 8 Jan 2001 15:42:32 -0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Carsten Langgaard , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications Message-ID: <20010108154232.A4436@bacchus.dhis.org> References: <3A59E978.873182CB@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 08, 2001 at 05:40:23PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 05:40:23PM +0100, Maciej W. Rozycki wrote: > > What we need is a mechanism to partial invalidate the I-cache and a mechanism > > to write-back and/or invalidate the D-cache. > > What's wrong with the already mentioned cachectl? > > $ mipsel-linux-objdump -T /usr/mipsel-linux/lib/libc-2.2.so | grep cachectl > 00000000600ca0a0 w DF *ABS* 0000000000000000 GLIBC_2.0 cachectl > $ ls /usr/mipsel-linux/include/sys/cachectl.h > /usr/mipsel-linux/include/sys/cachectl.h cachectl(2) is a syscall that is manipulates the cachability of a memory area. And not yet implemented ... Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 10:00:47 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 10:00:38 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:61926 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 10:00:23 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09825; Mon, 8 Jan 2001 18:58:57 +0100 (MET) Date: Mon, 8 Jan 2001 18:58:57 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Carsten Langgaard , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications In-Reply-To: <20010108154232.A4436@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Ralf Baechle wrote: > > $ mipsel-linux-objdump -T /usr/mipsel-linux/lib/libc-2.2.so | grep cachectl > > 00000000600ca0a0 w DF *ABS* 0000000000000000 GLIBC_2.0 cachectl > > $ ls /usr/mipsel-linux/include/sys/cachectl.h > > /usr/mipsel-linux/include/sys/cachectl.h > > cachectl(2) is a syscall that is manipulates the cachability of a memory > area. And not yet implemented ... s/cachectl$/cacheflush/, of course (but the header is still valid). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 10:05:48 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 10:05:27 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:61414 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 10:05:11 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09757; Mon, 8 Jan 2001 18:56:56 +0100 (MET) Date: Mon, 8 Jan 2001 18:56:55 +0100 (MET) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , "Kevin D. Kissell" , linux-mips@oss.sgi.com, Michael Shmulevich Subject: Re: User applications In-Reply-To: <3A59EFEB.9D35514E@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, 8 Jan 2001, Carsten Langgaard wrote: > Exactly that I need, but I don't think it is implemented properly for mips. > It simply flushes all the caches, no matter what options you gives it. Yep, it's just a limitation of the implementation. But it's the right function and now that I know of the problem it goes to my to do list (but processing of the list is not that fast these days, so anyone feel free to do it oneself). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 8 10:42:38 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 10:42:28 -0800 Received: from [62.145.23.107] ([62.145.23.107]:53339 "HELO fileserv2.Cologne.DE") by oss.sgi.com with SMTP id ; Mon, 8 Jan 2001 10:42:23 -0800 Received: from localhost (1940 bytes) by fileserv2.Cologne.DE via rmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Mon, 8 Jan 2001 19:42:21 +0100 (CET) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19) Received: (from karsten@localhost) by excalibur.cologne.de (8.9.3/8.8.7) id TAA00920 for linux-mips@oss.sgi.com; Mon, 8 Jan 2001 19:30:10 +0100 Date: Mon, 8 Jan 2001 19:30:10 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Current CVS kernel no-go on R4k Decstation Message-ID: <20010108193010.B887@excalibur.cologne.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20010108155302.A18422@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010108155302.A18422@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Jan 08, 2001 at 03:53:02PM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Mon, Jan 08, 2001 at 03:53:02PM +0100, Florian Lohoff wrote: > Hi, > i am seeing this on my R4k Decstation (5000/150) > > This was the first try > > [...] > Freeing unused PROM memory: 124k freed > Freeing unused kernel memory: 60k freed > [init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc > [init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc > > Second try doesnt give me any output at all after > the "Freeing unused kernel ..." > > CVS Checkout @ 20010108 ~15:00 MESZ ^^^^ Is it still summer in Westfalen :-) ? Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET), except that I do not get the "illigal instruction" lines. Harald has the same problem on his /260. It looks like sometime in December 2000 something has gone broken in the R4K-support, or are we perhaps triggering a compiler bug in egcs 1.1.2? Greetings, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Mon Jan 8 12:00:59 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 12:00:49 -0800 Received: from mail.ivm.net ([62.204.1.4]:30564 "EHLO mail.ivm.net") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 12:00:28 -0800 Received: from franz.no.dom (port91.duesseldorf.ivm.de [195.247.65.91]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id VAA29754; Mon, 8 Jan 2001 21:00:13 +0100 X-To: linux-mips@oss.sgi.com Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010108193010.B887@excalibur.cologne.de> Date: Tue, 30 Oct 1979 04:28:38 +0100 (CET) Reply-To: Harald Koerfgen Organization: none From: Harald Koerfgen To: Karsten Merker Subject: Re: Current CVS kernel no-go on R4k Decstation Cc: linux-mips@oss.sgi.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On 08-Jan-01 Karsten Merker wrote: > On Mon, Jan 08, 2001 at 03:53:02PM +0100, Florian Lohoff wrote: > >> Hi, >> i am seeing this on my R4k Decstation (5000/150) >> >> This was the first try >> >> [...] >> Freeing unused PROM memory: 124k freed >> Freeing unused kernel memory: 60k freed >> [init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc >> [init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc >> >> Second try doesnt give me any output at all after >> the "Freeing unused kernel ..." >> >> CVS Checkout @ 20010108 ~15:00 MESZ > ^^^^ > Is it still summer in Westfalen :-) ? > > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET), > except that I do not get the "illigal instruction" lines. Harald has the > same problem on his /260. It looks like sometime in December 2000 > something has gone broken in the R4K-support, or are we perhaps > triggering a compiler bug in egcs 1.1.2? I don't think so. This hang appeared in the middle of December and may or may not be related to the MIPS32 patches which were commited then. Unfortunately I haven't had the time to track this down. Anyway, is anybody else with a R4X00 machines seeing this? -- Regards, Harald From owner-linux-mips@oss.sgi.com Mon Jan 8 14:03:18 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 14:03:09 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:4596 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 14:03:00 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Mon, 8 Jan 2001 19:53:02 -0200 Date: Mon, 8 Jan 2001 19:53:02 -0200 From: Ralf Baechle To: Harald Koerfgen Cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: Current CVS kernel no-go on R4k Decstation Message-ID: <20010108195302.B9198@bacchus.dhis.org> References: <20010108193010.B887@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Harald.Koerfgen@home.ivm.de on Tue, Oct 30, 1979 at 04:28:38AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Oct 30, 1979 at 04:28:38AM +0100, Harald Koerfgen wrote: > > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET), > > except that I do not get the "illigal instruction" lines. Harald has the > > same problem on his /260. It looks like sometime in December 2000 > > something has gone broken in the R4K-support, or are we perhaps > > triggering a compiler bug in egcs 1.1.2? > > I don't think so. This hang appeared in the middle of December and may or may > not be related to the MIPS32 patches which were commited then. Unfortunately I > haven't had the time to track this down. > > Anyway, is anybody else with a R4X00 machines seeing this? I can tell you that this patch provoked other alergic reactions, for example with the R7000. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 8 14:30:18 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 14:30:09 -0800 Received: from mx.mips.com ([206.31.31.226]:9935 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 14:30:04 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA22416; Mon, 8 Jan 2001 14:29:55 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA07962; Mon, 8 Jan 2001 14:29:52 -0800 (PST) Message-ID: <01b401c079c3$095c4740$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Harald Koerfgen" , "Karsten Merker" Cc: References: Subject: Re: Current CVS kernel no-go on R4k Decstation Date: Mon, 8 Jan 2001 23:33:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET), > > except that I do not get the "illigal instruction" lines. Harald has the > > same problem on his /260. It looks like sometime in December 2000 > > something has gone broken in the R4K-support, or are we perhaps > > triggering a compiler bug in egcs 1.1.2? > > I don't think so. This hang appeared in the middle of December and may or may > not be related to the MIPS32 patches which were commited then. Unfortunately I > haven't had the time to track this down. If you're referring to the MIPS32 patches that came from the MIPS 2.2 tree, we generally test those on an R4600 Indy and a couple R5xxx platforms as a matter of routine. This is not to say that there might not be some change to the R4x00 support between 2.2 and 2.4 that interacts pathologically with the MIPS32 code... Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 8 15:41:19 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 15:41:00 -0800 Received: from noose.gt.owl.de ([62.52.19.4]:50440 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 8 Jan 2001 15:40:30 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id AA3757FE; Tue, 9 Jan 2001 00:40:27 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id AD476F44C; Tue, 9 Jan 2001 00:41:01 +0100 (CET) Date: Tue, 9 Jan 2001 00:41:01 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: MIPS32 patches breaking DecStation Message-ID: <20010109004101.B27674@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hi, i found this snippet from arch/mips/kernel/head.S breaking DecStations: @@ -68,9 +76,9 @@ mtc0 k0, CP0_ENTRYLO0 # load it srl k1, k1, 6 # convert to entrylo1 mtc0 k1, CP0_ENTRYLO1 # load it - b 1f - tlbwr # write random tlb entry -1: + nop # Need 2 cycles between mtc0 + nop # and tlbwr (CP0 hazard). + tlbwr # write random tlb entry nop eret # return from trap END(except_vec0_r4000) >From the Documentation and how i understand it this is perfectly valid as the mtc0 instruction causes a cp0 hazard within the next 2 instruction thought the delay of 2 cycles would be ok. This is probably related to the Decstations having REALLY old R4000 silicion revisions - Probably one should look through the erratas for these flo@repeat:~$ cat /proc/cpuinfo cpu : MIPS cpu model : R4000SC V3.0 system type : Digital DECstation 5000/1xx OK - I just had a look at the errata - This IS a workaround to a Mips R4000SC 2.0, 3.0 errata - I restored the original code back. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Mon Jan 8 16:31:49 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 16:31:40 -0800 Received: from mx.mips.com ([206.31.31.226]:13009 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 16:31:22 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA23890; Mon, 8 Jan 2001 16:31:18 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA12210; Mon, 8 Jan 2001 16:31:14 -0800 (PST) Message-ID: <000501c079d3$fefe1a60$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Florian Lohoff" , References: <20010109004101.B27674@paradigm.rfc822.org> Subject: Re: MIPS32 patches breaking DecStation Date: Tue, 9 Jan 2001 01:34:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Florian, Could you do me a huge favor and try a build that uses 3 or 4 nops instead of the branch to the instruction after the delay slot? There was a reason that I eliminated the branch construct from the MIPS internal Linux source base - it's a hack that works perfectly on R4000's, but it's pretty much a coincidence that it does so. Yes, the code fragment in question is R4K-specific, but we really need to migrate towards the use of consistent mechanisms that work across the full range of MIPS CPUs. Ideally, *all* CP0 hazards should some day be padded out with "ssnops" (sll $0,$0,1, if I recall), which force a 1 cycle delay per instruction even on superscalar MIPS CPUs. Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 8 18:13:39 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 18:13:30 -0800 Received: from dorian.blic.net ([217.23.192.5]:43794 "EHLO dorian.blic.net") convert rfc822-to-8bit by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 18:13:06 -0800 Received: from quake.blic.net (pmalic@quake.blic.net [217.23.192.7]) by dorian.blic.net (8.9.3/8.9.3) with ESMTP id CAA00705 for ; Tue, 9 Jan 2001 02:57:20 +0100 Date: Tue, 9 Jan 2001 03:16:20 +0100 (CET) From: Predrag Malicevic To: Subject: O200 problem... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hi, I'm trying to install Linux on an Origin 200 and I'm having problems with booting the kernel (CVS tree linux from oss.sgi.com). I've included below a console session of my tries to boot the kernel. In two cases below I used the default kernel configuration but without the SCSI driver. In the first case I used parameters root=/dev/nfs and nfsroot=.... It reached 'Calibrating delay loop' and then 'Got dbe at 0xffffffff8013e970'. After that, I guess, some kind of register dump followed (I'm working with MIPS architecture for the first time). In the second case it reached "TCP: Hash tables configured". Besides these two tries, I've tried using different kernel configuration options in the machine selection category and besides the obvious ones (IP27, IP27 N-Mode and Multi-Processing), I'm clueless about the meaning of other options. I would really appreciate some guidance on making the kernel boot... Thanks in advance and sorry for such a long email. **** The recorded console session from minicom **** IP27 PROM SGI Version 5.28 built 11:17:13 AM Sep 24, 1998 Master testing hub interrupts Testing/Initializing memory CPU A testing secondary cache (1 MB) Discovering local IO ... Using console at /hw/module/1/MotherBoard Running serial_dma diag (Bridge base = 0x9200000008000000 PCI dev = 2) Local IO discover DONE. Running Hub Chip BTE test. BTE0 completed. BTE1 completed. Checking Local Link Connection. Discovering CrayLink connectivity Local hub CrayLink is down. *** Local network link down Discovered 1 objects (1 hubs, 0 routers) Waiting for peers to complete discovery. No other nodes present; becoming global master Global master is /hw/module/1/slot/MotherBoard Loading BASEIO prom Uncompressing segment BASEIO prom Jumping to entry point 0xa800000001c00140 Numbering nodes... 1 CPUs on 1 nodes found. Clocks synchronized. Modules numbered. Updating module serial numbers. BASEIO PROM Monitor SGI Version 5.28 built 11:16:22 AM Sep 24, 1998 (BE64) Sizing caches... Initializing environment Initializing software and devices. Installing Devices... Running enet_all diag (Bridge base = 0x9200000008000000 PCI dev = 2 Mode = 0) Running scsi_ram diag (Bridge base = 0x9200000008000000 PCI dev = 0) Running scsi_dma diag (Bridge base = 0x9200000008000000 PCI dev = 0) Running scsi_controller diag (Bridge base = 0x9200000008000000 PCI dev = 0) Walking SCSI Adapter 0 (/hw/module/1/slot/MotherBoard), (pci id 0) 1+ 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 1 device(s) Running scsi_ram diag (Bridge base = 0x9200000008000000 PCI dev = 1) Running scsi_dma diag (Bridge base = 0x9200000008000000 PCI dev = 1) Running scsi_controller diag (Bridge base = 0x9200000008000000 PCI dev = 1) Walking SCSI Adapter 1 (/hw/module/1/slot/MotherBoard), (pci id 1) 1- 2- 3- 4- 5+ 6+ 7- = 2 device(s) Initializing devices... Checking hardware inventory... **** System Configuration and Diagnostics Summary **** CONFIG: No. of NODEs enabled = 1 No. of NODEs disabled = 0 No. of CPUs enabled = 1 No. of CPUs disabled = 0 Mem enabled = 64 MB Mem disabled = 0 MB No. of RTRs enabled = 0 No. of RTRs disabled = 0 DIAG RESULTS: ALL DIAGS PASSED! **** End System Configuration and Diagnostics Summary **** System Maintenance Menu 1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor Option? 5 Command Monitor. Type "exit" to return to the menu. >> hinv -v IP27 Node Board, Module 1, Slot MotherBoard ASIC HUB Rev 3, 90 MHz, (nasid 0) Processor A: 180 MHz R10000, Rev 2.6, 1M secondary cache, (cpu 0) R10000FPC Rev 0 Memory on board, 64 MBytes (Standard) Bank 0, 64 MBytes <-- (Physical Bank 0) BASEIO IO Board, Module 1, Slot MotherBoard ASIC BRIDGE Rev 4, (widget 8) adapter PCI-SCSI Rev 5, (pci id 0) peripheral SCSI DISK, ID 1, SGI IBM DCHS04Y adapter PCI-SCSI Rev 5, (pci id 1) peripheral SCSI TAPE, ID 5, ARCHIVE Python 02779-XXX peripheral SCSI CDROM, ID 6, TOSHIBA CD-ROM XM-5701TA adapter IOC3 Rev 1, (pci id 2) controller multi function SuperIO controller Ethernet Rev 1 >> hinv -mvvv location: /hw/module/1/slot/MotherBoard Part:013-1895-001;Name:PIMM_1XT5_1MB;Serial:GCK618;Revision:F;Group:ff;Capability:ffffffff;Variety:ff;Laser:000000178518; location: /hw/module/1/slot/MotherBoard Part:030-1244-001;Name:IP29;Serial:GCH576;Revision:H;Group:ff;Capability:ffffffff;Variety:ff;Laser:00000017a582; >> version BASEIO PROM Monitor SGI Version 5.28 built 11:16:22 AM Sep 24, 1998 (BE64) >> printenv AutoLoad=No dbgtty=/dev/tty/ioc30 root=dks0d1s0 nonstop=0 rbaud=19200 SystemPartition=dksc(0,1,8) OSLoadPartition=dksc(0,1,0) OSLoader=sash OSLoadFilename=unix TimeZone=PST8PDT console=d oldConsolePath=/hw/module/1/slot/MotherBoard gConsoleIn=default gConsoleOut=default diskless=0 scsihostid=0 ProbeAllScsi=n dbaud=9600 volume=80 sgilogo=y netaddr=192.168.21.231 ConsoleOut=/dev/tty/ioc30 ConsoleIn=/dev/tty/ioc30 cpufreq=180 ConsolePath=/hw/module/1/slot/MotherBoard >> opts SGI Version 5.28 built 11:16:22 AM Sep 24, 1998 Libkl was built as follows: -xansi -fullwarn -D_STANDALONE -DMP -DDISCONTIG_PHYSMEM -DNUMA_BASE -DNUMA_PM -DNUMA_TBORROW -DNUMA_MIGR_CONTROL -DNUMA_REPLICATION -DNUMA_REPL_CONTROL -DNUMA_SCHED -DLARGE_CPU_COUNT -DHUB2_NACK_WAR -DBRIDGE_ERROR_INTR_WAR -DMAPPED_KERNEL -DBHV_SYNCH -DHUB_ERR_STS_WAR -DHUB_MIGR_WAR -DNCR16C550 -DTL16PIR552 -DSN0_INTR_BROKEN -DFRU -DSN0_USE_BTE -DBTE_BZERO_WAR -DREV1_BRIDGE_SUPPORTED -DHUB_II_IFDR_WAR -DRTINT_WAR -DPCOUNT_WAR -DBRIDGE_B_DATACORR_WAR -D_KERNEL -DR10000 -D_PAGESZ=16384 -DIP27 -DPROM -U__INLINE_INTRINSICS -DSN0 -I../../../include -I../../../IP27prom -non_shared -elf -64 -G 0 -mips4 -OPT:space=ON -OPT:quad_align_branch_targets=FALSE -OPT:quad_align_with_memops=FALSE -TENV:misalignment=1 -OPT:unroll_times_max=0 -OPT:unroll_size=0 -TENV:kernel -IPA:inline=off:cprop=off:cgi=off:autognum=off -ipa -Wl,-tt1:1 -nostdinc -I/u1/people/ayoung/6.4-patch3292/root/usr/include -O2 -MDupdate Makedepend.SN0 -woff 1685,515,608,658,799,803,852,1048,1233,1499,1068,1185,1209,1505,1506,1692,1174 Libsk was built as follows: -xansi -fullwarn -D_STANDALONE -DMP -DDISCONTIG_PHYSMEM -DNUMA_BASE -DNUMA_PM -DNUMA_TBORROW -DNUMA_MIGR_CONTROL -DNUMA_REPLICATION -DNUMA_REPL_CONTROL -DNUMA_SCHED -DLARGE_CPU_COUNT -DHUB2_NACK_WAR -DBRIDGE_ERROR_INTR_WAR -DMAPPED_KERNEL -DBHV_SYNCH -DHUB_ERR_STS_WAR -DHUB_MIGR_WAR -DNCR16C550 -DTL16PIR552 -DSN0_INTR_BROKEN -DFRU -DSN0_USE_BTE -DBTE_BZERO_WAR -DREV1_BRIDGE_SUPPORTED -DHUB_II_IFDR_WAR -DRTINT_WAR -DPCOUNT_WAR -DBRIDGE_B_DATACORR_WAR -D_KERNEL -DR10000 -D_PAGESZ=16384 -DIP27 -DSN0 -I../../../include -non_shared -elf -64 -G 0 -mips4 -OPT:space=ON -OPT:quad_align_branch_targets=FALSE -OPT:quad_align_with_memops=FALSE -TENV:misalignment=1 -OPT:unroll_times_max=0 -OPT:unroll_size=0 -TENV:kernel -IPA:inline=off:cprop=off:cgi=off:autognum=off -ipa -Wl,-tt1:1 -nostdinc -I/u1/people/ayoung/6.4-patch3292/root/usr/include -O2 -MDupdate Makedepend.SN0 -woff 1685,515,608,658,799,803,852,1048,1233,1499,1068,1185,1209,1505,1506,1692,1174 The IO6prom was built as follows: -xansi -fullwarn -D_STANDALONE -DMP -DDISCONTIG_PHYSMEM -DNUMA_BASE -DNUMA_PM -DNUMA_TBORROW -DNUMA_MIGR_CONTROL -DNUMA_REPLICATION -DNUMA_REPL_CONTROL -DNUMA_SCHED -DLARGE_CPU_COUNT -DHUB2_NACK_WAR -DBRIDGE_ERROR_INTR_WAR -DMAPPED_KERNEL -DBHV_SYNCH -DHUB_ERR_STS_WAR -DHUB_MIGR_WAR -DNCR16C550 -DTL16PIR552 -DSN0_INTR_BROKEN -DFRU -DSN0_USE_BTE -DBTE_BZERO_WAR -DREV1_BRIDGE_SUPPORTED -DHUB_II_IFDR_WAR -DRTINT_WAR -DPCOUNT_WAR -DBRIDGE_B_DATACORR_WAR -D_KERNEL -DR10000 -D_PAGESZ=16384 -DIP27 -DPROM -DNO_tpsc -DSN0 -I../include -I../IP27prom -non_shared -elf -64 -G 0 -mips4 -OPT:space=ON -OPT:quad_align_branch_targets=FALSE -OPT:quad_align_with_memops=FALSE -TENV:misalignment=1 -OPT:unroll_times_max=0 -OPT:unroll_size=0 -TENV:kernel -IPA:inline=off:cprop=off:cgi=off:autognum=off -ipa -Wl,-tt1:1 -nostdinc -I/u1/people/ayoung/6.4-patch3292/root/usr/include -O2 -MDupdate Makedepend.SN0 -woff 1685,515,608,658,799,803,852,1048,1233,1499,1068,1185,1209,1505,1506,1692,1174 >> bootp():vmlinux root=/dev/nfs nfsroot=/ 192.168.21.220:/MIPS Obtaining vmlinux from server itlab4   1160272 |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+374720 |/-\|/-\|/-\|/-\|/-\|/-\+228460 entry: 0xa80000000013c000 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Discovered 1 cpus on 1 nodes Total memory probed : 0x4000 pages Linux version 2.4.0-test11 (pmalic@itlab4) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Thu Dec 28 13:36:59 CET 2000 Loading R10000 MMU routines. CPU revision is: 00000926 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has no secondary CPU. Machine is in M mode. Cpu 0, Nasid 0x0, pcibr_setup(): found partnum= 0xc002...is bridge CPU 0 clock is 65535MHz. On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs nfsroot=192.168.21.220:/MIPS Entering 64-bit mode. Calibrating delay loop... 179.81 BogoMIPS Got dbe at 0xffffffff8013e970 Cpu 0 $0 : 0000000000000000 ffffffff94201ce0 a8000000001cf680 0000000000000000 $4 : 00000000000000d0 0000000000000039 0000000000000000 a8000000001cf000 $8 : 0000000000004000 0000000000000000 ffffffff80196039 ffffffff801c8828 $12 : 0000000000000010 0000000000000000 000000000000000a ffffffff8012f330 $16 : a8000000011bbe58 0000000000003439 0000000000003048 ffffffff801ca4a8 $20 : 0000000000004000 0000000000000001 0000000000000001 0000000000000000 $24 : 0000000000000000 0000000000000030 $28 : ffffffff80138000 ffffffff8013bdc0 a80000000013c000 ffffffff8013e9ac Hi : 0000000000000000 Lo : 0000000000003438 epc : ffffffff8013e970 badvaddr: ffffffff801c8828 badvaddr: ffffffff801c8828 Status : 94201ce3 Cause : 0000901c Cause : 0000901c Index: 0 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 1 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 2 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 3 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 4 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 5 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 6 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 7 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 8 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 9 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 10 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 11 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 12 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 13 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 14 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 15 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 16 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 17 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 18 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 19 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 20 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 21 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 22 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 23 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 24 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 25 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 26 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 27 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 28 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 29 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 30 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 31 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 32 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 33 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 34 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 35 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 36 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 37 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 38 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 39 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 40 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 41 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 42 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 43 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 44 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 45 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 46 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 47 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 48 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 49 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 50 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 51 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 52 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 53 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 54 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 55 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 56 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 57 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 58 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 59 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 60 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 61 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 62 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 63 pgmask=00000000 va=c0000fff80000000 asid=00 [pa=000000 c=0 d=0 v=0 g=0] [pa=000000 c=0 d=0 v=0 g=0] [ Here the machine hangs and I restart it. For brevity, I've removed the lines that are written to the screen while booting. ] [ Now I'm tring to boot another kernel: ] >> bootp():vmlinux Obtaining vmlinux from server itlab4   1160272 |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+374704 |/-\|/-\|/-\|/-\|/-\|/-\+228460 entry: 0xa80000000013c000 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Discovered 1 cpus on 1 nodes Total memory probed : 0x4000 pages Linux version 2.4.0-test11 (pmalic@itlab4) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #2 Thu Dec 28 13:46:29 CET 2000 Loading R10000 MMU routines. CPU revision is: 00000926 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has no secondary CPU. Machine is in M mode. Cpu 0, Nasid 0x0, pcibr_setup(): found partnum= 0xc002...is bridge CPU 0 clock is 65535MHz. On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: Entering 64-bit mode. Calibrating delay loop... 179.81 BogoMIPS Memory: 61496k/65536k available (1133k kernel code, 4040k reserved, 129k data, 216k init) Dentry-cache hash table entries: 8192 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 3, 32768 bytes) Page-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 4096 (order: 4, 65536 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX PCI: Probing PCI hardware on host bus 0. PCI: Fixing isp1020 in [bus:slot.fn] 00:00.0 PCI: Fixing isp1020 in [bus:slot.fn] 00:01.0 PCI: Fixing base addresses for IOC3 device 00:02.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabledttyS00 at iomem 0x9200000008620178 (irq = 0) is a 16550A Using PHY 31, vendor 0x20005c0, model 0, rev 1. eth0: MII transceiver found at MDIO address 31, config 3100 status 786f. IOC3 SSRAM has 128 kbyte. Found DS1981U NIC registration number 39:e6:02:00:70:5e, CRC 19. Ethernet address is 08:00:69:05:73:0e. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 256 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) [ Here the machines hangs again. I've tried many more times with different kernel configurations, but it's the same thing. It either "gets a dbe" or just stops after "TCP: Hash tables ..." ] --pm From owner-linux-mips@oss.sgi.com Mon Jan 8 18:52:30 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 18:52:09 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:57846 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 18:51:48 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 00:41:38 -0200 Date: Tue, 9 Jan 2001 00:41:38 -0200 From: Ralf Baechle To: Predrag Malicevic Cc: Subject: Re: O200 problem... Message-ID: <20010109004138.A12181@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pmalic@blic.net on Tue, Jan 09, 2001 at 03:16:20AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 03:16:20AM +0100, Predrag Malicevic wrote: > I'm trying to install Linux on an Origin 200 and I'm having problems with > booting the kernel (CVS tree linux from oss.sgi.com). I've included below > a console session of my tries to boot the kernel. In two cases below I > used the default kernel configuration but without the SCSI driver. In the > first case I used parameters root=/dev/nfs and nfsroot=.... It reached > 'Calibrating delay loop' and then 'Got dbe at 0xffffffff8013e970'. After > that, I guess, some kind of register dump followed (I'm working with MIPS > architecture for the first time). In the second case it reached "TCP: > Hash tables configured". Besides these two tries, I've tried using > different kernel configuration options in the machine selection category > and besides the obvious ones (IP27, IP27 N-Mode and Multi-Processing), I'm > clueless about the meaning of other options. > CPU 0 clock is 65535MHz. Something's fishy. I guess ;-) > [ Here the machines hangs again. I've tried many more times with different kernel configurations, but it's the same thing. It either "gets a dbe" or just stops after "TCP: Hash tables ..." ] I assume it's your specific configuration that's triggering the problem. I've got the current CVS kernel running on 2 dual processor O200 and a 32 processor Origin 2000, so it can't be all broken. I think all known to be working configuratons are machines with significantly more memory; dunno if that's really related or not. Thanks for sending the oops message; however without additional data provided I can't use it. Can you please point please put the kernel image that resulted in the oops online? Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 00:58:02 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 00:57:53 -0800 Received: from noose.gt.owl.de ([62.52.19.4]:51729 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Tue, 9 Jan 2001 00:57:28 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 050A07DD; Tue, 9 Jan 2001 09:57:26 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 4F282F44C; Tue, 9 Jan 2001 09:58:04 +0100 (CET) Date: Tue, 9 Jan 2001 09:54:38 +0100 From: Florian Lohoff To: "Kevin D. Kissell" Subject: Re: MIPS32 patches breaking DecStation Message-ID: <20010109095438.A10683@paradigm.rfc822.org> References: <20010109004101.B27674@paradigm.rfc822.org> <000501c079d3$fefe1a60$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000501c079d3$fefe1a60$0deca8c0@Ulysses>; from kevink@mips.com on Tue, Jan 09, 2001 at 01:34:47AM +0100 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 01:34:47AM +0100, Kevin D. Kissell wrote: > Florian, > > Could you do me a huge favor and try a build that > uses 3 or 4 nops instead of the branch to the instruction > after the delay slot? There was a reason that I eliminated No problem - Done - doesnt work > the branch construct from the MIPS internal Linux source > base - it's a hack that works perfectly on R4000's, but > it's pretty much a coincidence that it does so. Yes, > the code fragment in question is R4K-specific, but > we really need to migrate towards the use of consistent > mechanisms that work across the full range of MIPS > CPUs. Ideally, *all* CP0 hazards should some day be > padded out with "ssnops" (sll $0,$0,1, if I recall), which > force a 1 cycle delay per instruction even on superscalar > MIPS CPUs. It immediatly after starting init goes crazy with "Illegal instruction" and dies like this: [ ... a couple hundret Illegal instruction ... ] [init:1] Illegal instruction 8f9983d4 at 0fb68df8 ra=0fb68a20 [init:1] Illegal instruction 8fbc0018 at 0fb68e08 ra=0fb68a20 [init:1] Illegal instruction 02402021 at 0fb68e10 ra=0fb68a20 [init:1] Illegal instruction 00000000 at 0fb68e18 ra=0fb68a20 Kernel panic: Attempted to kill init! BUG IN DYNAMIC LINKER ld.so: dl-minimal.c: 67: malloc: Assertion `n <= _dl_page! It seems we need a R4000 2.0/3.0 special except_vec_r4000 like we already have for the R4600 and some other kinds of mips CPUs. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue Jan 9 02:20:34 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 02:20:14 -0800 Received: from dorian.blic.net ([217.23.192.5]:58377 "EHLO dorian.blic.net") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 02:19:58 -0800 Received: from quake.blic.net (pmalic@quake.blic.net [217.23.192.7]) by dorian.blic.net (8.9.3/8.9.3) with ESMTP id LAA08675; Tue, 9 Jan 2001 11:04:12 +0100 Date: Tue, 9 Jan 2001 11:23:17 +0100 (CET) From: Predrag Malicevic To: Ralf Baechle cc: Subject: Re: O200 problem... In-Reply-To: <20010109004138.A12181@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, 9 Jan 2001, Ralf Baechle wrote: > > CPU 0 clock is 65535MHz. > > Something's fishy. I guess ;-) It is really strange... 65 GHz? ;) > Thanks for sending the oops message; however without additional data > provided I can't use it. Can you please point please put the kernel image > that resulted in the oops online? Ok, I'll put it by Thursday (I can't come to the machines earlier). P.S. I was first building kernels on an i386 system running RedHat 7.0, but later on I switched to a faster machine running Slackware 7.0. In both cases I used binutils-mips64-linux-2.9.5-3/egcs-mips64-linux-1.1.2-3 RPMs from oss.sgi.com. Kernels from both machines behaved the same way. --pm From owner-linux-mips@oss.sgi.com Tue Jan 9 02:51:34 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 02:51:24 -0800 Received: from mx.mips.com ([206.31.31.226]:46807 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 02:51:03 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA27789 for ; Tue, 9 Jan 2001 02:50:58 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA25195 for ; Tue, 9 Jan 2001 02:50:55 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id LAA17080 for ; Tue, 9 Jan 2001 11:50:21 +0100 (MET) Message-ID: <3A5AECED.99A9C4A1@mips.com> Date: Tue, 09 Jan 2001 11:50:21 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: 64bit TLB refill handler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing The XTLB refill handler in the 64bit code is for the R10000, is there any reason that it shouldn't work on R4000's ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jan 9 04:12:44 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 04:12:25 -0800 Received: from [194.90.113.98] ([194.90.113.98]:22547 "EHLO yes.home.krftech.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 04:12:16 -0800 Received: from jungo.com (kobie.home.krftech.com [199.204.71.69]) by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id OAA00798; Tue, 9 Jan 2001 14:54:42 +0200 Message-ID: <3A5AFAC8.CA682600@jungo.com> Date: Tue, 09 Jan 2001 13:49:29 +0200 From: Michael Shmulevich X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: User applications References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing As a side question, I would like to to know why exactly the CPU cache operations are promoted to the syscall status? What is the situation that a user in its program would like to call cacheflush() ? Unless, of course, he is doing DoS. I can understand why we need this in kernel, for context switch, for example, but as a syscall?... Michael. "Maciej W. Rozycki" wrote: > On Mon, 8 Jan 2001, Ralf Baechle wrote: > > > > $ mipsel-linux-objdump -T /usr/mipsel-linux/lib/libc-2.2.so | grep cachectl > > > 00000000600ca0a0 w DF *ABS* 0000000000000000 GLIBC_2.0 cachectl > > > $ ls /usr/mipsel-linux/include/sys/cachectl.h > > > /usr/mipsel-linux/include/sys/cachectl.h > > > > cachectl(2) is a syscall that is manipulates the cachability of a memory > > area. And not yet implemented ... > > s/cachectl$/cacheflush/, of course (but the header is still valid). > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jan 9 04:19:54 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 04:19:44 -0800 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:20491 "EHLO the-village.bc.nu") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 04:19:28 -0800 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14FxiT-0006XP-00; Tue, 9 Jan 2001 12:17:29 +0000 Subject: Re: User applications To: michaels@jungo.com (Michael Shmulevich) Date: Tue, 9 Jan 2001 12:17:26 +0000 (GMT) Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-mips@oss.sgi.com In-Reply-To: <3A5AFAC8.CA682600@jungo.com> from "Michael Shmulevich" at Jan 09, 2001 01:49:29 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > promoted to the syscall status? What is the situation that a user in its program > would like > to call cacheflush() ? Unless, of course, he is doing DoS. A cache flush is not a denial of service attack. Its no less effective than a 1Mb memcpy > I can understand why we need this in kernel, for context switch, for example, but > as a syscall?... Self modifying code, dynamic compilation, glibc trampolines From owner-linux-mips@oss.sgi.com Tue Jan 9 04:24:14 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 04:23:55 -0800 Received: from mail.sonytel.be ([193.74.243.200]:43952 "EHLO mail.sonytel.be") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 04:23:43 -0800 Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA08971; Tue, 9 Jan 2001 13:15:50 +0100 (MET) Date: Tue, 9 Jan 2001 13:15:47 +0100 (MET) From: Geert Uytterhoeven To: Michael Shmulevich cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: User applications In-Reply-To: <3A5AFAC8.CA682600@jungo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, 9 Jan 2001, Michael Shmulevich wrote: > As a side question, I would like to to know why exactly the CPU cache operations > are > promoted to the syscall status? What is the situation that a user in its program > would like > to call cacheflush() ? Unless, of course, he is doing DoS. > > I can understand why we need this in kernel, for context switch, for example, but > as a syscall?... For trampolines. These are small pieces of code created on the stack, and require flushing of the caches before they are excuted. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jan 9 05:08:36 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 05:08:26 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:50418 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 05:08:02 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA13529; Tue, 9 Jan 2001 14:00:03 +0100 (MET) Date: Tue, 9 Jan 2001 14:00:01 +0100 (MET) From: "Maciej W. Rozycki" To: Michael Shmulevich cc: linux-mips@oss.sgi.com Subject: Re: User applications In-Reply-To: <3A5AFAC8.CA682600@jungo.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, 9 Jan 2001, Michael Shmulevich wrote: > As a side question, I would like to to know why exactly the CPU cache operations > are > promoted to the syscall status? What is the situation that a user in its program > would like > to call cacheflush() ? Unless, of course, he is doing DoS. Any software that modifes text needs it. For example the dynamic linker or libdl. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jan 9 07:20:45 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 07:20:36 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:7417 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 07:20:27 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 13:09:58 -0200 Date: Tue, 9 Jan 2001 13:09:58 -0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "Florian Lohoff" , Subject: Re: MIPS32 patches breaking DecStation Message-ID: <20010109130958.B1047@bacchus.dhis.org> References: <20010109004101.B27674@paradigm.rfc822.org> <000501c079d3$fefe1a60$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000501c079d3$fefe1a60$0deca8c0@Ulysses>; from kevink@mips.com on Tue, Jan 09, 2001 at 01:34:47AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 01:34:47AM +0100, Kevin D. Kissell wrote: > uses 3 or 4 nops instead of the branch to the instruction > after the delay slot? There was a reason that I eliminated > the branch construct from the MIPS internal Linux source > base - it's a hack that works perfectly on R4000's, but > it's pretty much a coincidence that it does so. Yes, > the code fragment in question is R4K-specific, but > we really need to migrate towards the use of consistent > mechanisms that work across the full range of MIPS > CPUs. Ideally, *all* CP0 hazards should some day be > padded out with "ssnops" (sll $0,$0,1, if I recall), which > force a 1 cycle delay per instruction even on superscalar > MIPS CPUs. While we could come up with a common TLB fault handler I really don't want to. For many applications this TLB fault handler is extremly performance sensitive; every single cycle directly translates into application performance. Seems like we'll need some more TLB fault handler. And a complete TLB fault handler rewrite would be a good ide anyway, sigh ... Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 07:47:26 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 07:47:16 -0800 Received: from mx.mips.com ([206.31.31.226]:31962 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 07:47:08 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA29351; Tue, 9 Jan 2001 07:47:03 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA01638; Tue, 9 Jan 2001 07:47:01 -0800 (PST) Message-ID: <012801c07a53$ed06e460$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "Florian Lohoff" , References: <20010109004101.B27674@paradigm.rfc822.org> <000501c079d3$fefe1a60$0deca8c0@Ulysses> <20010109130958.B1047@bacchus.dhis.org> Subject: Re: MIPS32 patches breaking DecStation Date: Tue, 9 Jan 2001 16:50:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > Yes, the code fragment in question is R4K-specific, but > > we really need to migrate towards the use of consistent > > mechanisms that work across the full range of MIPS > > CPUs. Ideally, *all* CP0 hazards should some day be > > padded out with "ssnops" (sll $0,$0,1, if I recall), which > > force a 1 cycle delay per instruction even on superscalar > > MIPS CPUs. > > While we could come up with a common TLB fault handler I really don't want > to. For many applications this TLB fault handler is extremly performance > sensitive; every single cycle directly translates into application > performance. Seems like we'll need some more TLB fault handler. And a > complete TLB fault handler rewrite would be a good ide anyway, sigh ... Sorry if I wasn't clear. I am not suggesting a "one size fits all" TLB handler - though as the old SGI hardware gets retired and the newer, more standardized MIPS32 and MIPS64 parts become the principal targets, we may see a greater convergence. I am simply suggesting that, even if there are differences in policy necessitated by different CPU implementations, they should use the same mechanisms. If all CP0 hazards are avoided by using ssnops, for example, we could evolve from writing a new handler for every R4K variant to having a routine that generates a handler with the right pipeline hazard management, based on a set of paramters for the CPU. And, while Ralf and I sometimes disagree on the importance of this, in my own opinion, being consistent in these small details helps avoid errors when a systems programmer new to the architecture and/or the OS needs to work on the system. You may say that I'm a dreamer, but I'm not the only one. ;-) Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 9 08:59:05 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 08:58:55 -0800 Received: from mail.ivm.net ([62.204.1.4]:23136 "EHLO mail.ivm.net") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 08:58:35 -0800 Received: from franz.no.dom (port30.duesseldorf.ivm.de [195.247.65.30]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id RAA20533; Tue, 9 Jan 2001 17:58:24 +0100 X-To: linux-mips@oss.sgi.com Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010109004101.B27674@paradigm.rfc822.org> Date: Tue, 09 Jan 2001 17:43:08 +0100 (CET) Reply-To: Harald Koerfgen Organization: none From: Harald Koerfgen To: Florian Lohoff Subject: RE: MIPS32 patches breaking DecStation Cc: linux-mips@oss.sgi.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On 08-Jan-01 Florian Lohoff wrote: > OK - I just had a look at the errata - This IS a workaround to a > Mips R4000SC 2.0, 3.0 errata - I restored the original code back. Where have you found those errata? -- Regards, Harald From owner-linux-mips@oss.sgi.com Tue Jan 9 09:17:55 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 09:17:45 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:25084 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 09:17:34 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 15:01:42 -0200 Date: Tue, 9 Jan 2001 15:01:42 -0200 From: Ralf Baechle To: Harald Koerfgen Cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: MIPS32 patches breaking DecStation Message-ID: <20010109150142.A3866@bacchus.dhis.org> References: <20010109004101.B27674@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Harald.Koerfgen@home.ivm.de on Tue, Jan 09, 2001 at 05:43:08PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 05:43:08PM +0100, Harald Koerfgen wrote: > On 08-Jan-01 Florian Lohoff wrote: > > OK - I just had a look at the errata - This IS a workaround to a > > Mips R4000SC 2.0, 3.0 errata - I restored the original code back. > > Where have you found those errata? Go to www.mips.com, follow the publications link. Yes, MIPS be praised for having errata and docs for rotten old silicon online! Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 09:26:55 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 09:26:36 -0800 Received: from mail.ivm.net ([62.204.1.4]:29192 "EHLO mail.ivm.net") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 09:26:29 -0800 Received: from franz.no.dom (port108.duesseldorf.ivm.de [195.247.65.108]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id SAA23170 for ; Tue, 9 Jan 2001 18:26:16 +0100 X-To: Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010109095438.A10683@paradigm.rfc822.org> Date: Tue, 09 Jan 2001 18:11:00 +0100 (CET) Reply-To: Harald Koerfgen Organization: none From: Harald Koerfgen To: linux-mips@oss.sgi.com Subject: Re: MIPS32 patches breaking DecStation Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On 09-Jan-01 Florian Lohoff wrote: > On Tue, Jan 09, 2001 at 01:34:47AM +0100, Kevin D. Kissell wrote: >> Florian, >> >> Could you do me a huge favor and try a build that >> uses 3 or 4 nops instead of the branch to the instruction >> after the delay slot? There was a reason that I eliminated > > No problem - Done - doesnt work Same here on my /260 (R4400SC V4.0). Neither inserting four "sll $0,$0,1" nor four "nop" seem to work. The branch, on the other hand, does. -- Regards, Harald From owner-linux-mips@oss.sgi.com Tue Jan 9 10:39:35 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 10:39:16 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:19962 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 10:39:03 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 16:28:35 -0200 Date: Tue, 9 Jan 2001 16:28:35 -0200 From: Ralf Baechle To: Harald Koerfgen Cc: linux-mips@oss.sgi.com Subject: Re: MIPS32 patches breaking DecStation Message-ID: <20010109162835.B4232@bacchus.dhis.org> References: <20010109095438.A10683@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Harald.Koerfgen@home.ivm.de on Tue, Jan 09, 2001 at 06:11:00PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 06:11:00PM +0100, Harald Koerfgen wrote: > > No problem - Done - doesnt work > > Same here on my /260 (R4400SC V4.0). Neither inserting four "sll $0,$0,1" nor > four "nop" seem to work. The branch, on the other hand, does. Note the ssnops only make sense on superscalar CPUs, so not on the R4000. Also note that the branch is equivalent to three nops. One for the branch instruction itself, the two more for instructions in the pipeline that get killed. On the R4600 / R500 where the hazard is only a single instruction the branch is equivalent to only a single nop. So while unobvious the branch is a rather neat idea. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 11:27:07 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 11:26:48 -0800 Received: from mx.mips.com ([206.31.31.226]:8926 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 11:26:35 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA01915; Tue, 9 Jan 2001 11:26:30 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA09526; Tue, 9 Jan 2001 11:26:26 -0800 (PST) Message-ID: <019901c07a72$94d19f00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Harald Koerfgen" Cc: References: <20010109095438.A10683@paradigm.rfc822.org> <20010109162835.B4232@bacchus.dhis.org> Subject: Re: MIPS32 patches breaking DecStation Date: Tue, 9 Jan 2001 20:30:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > Same here on my /260 (R4400SC V4.0). Neither inserting four "sll $0,$0,1" nor > > four "nop" seem to work. The branch, on the other hand, does. Then it's apparently more than just a garden-variety CP0 hazard. > Note the ssnops only make sense on superscalar CPUs, so not on the R4000. My point is that an SSNOP should cause a 1 cycle stall on *any* MIPS implementation to date, superscalar or not. It's not documented that way for the R10000, but if I recall correctly, it works there too. If one wants to standardize on a single mechanism, that's the one to use. That's all I'm saying. > Also note that the branch is equivalent to three nops. One for the > branch instruction itself, the two more for instructions in the pipeline > that get killed. On the R4600 / R500 where the hazard is only a single > instruction the branch is equivalent to only a single nop. So while > unobvious the branch is a rather neat idea. Yes, it's cute, but it relies on accidents of implementation to work, and could easily fail on other CPUs otherwise compatible with the R4000. In principle, such a branch might incur no delay at all on an advanced 64-bit processor. By all means, use it for the specific cases of the CPUs on which it is known to work, but it should not be used in "default" MIPS CP0 handlers. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 9 12:04:57 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 12:04:37 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:23287 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 12:04:32 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 17:54:16 -0200 Date: Tue, 9 Jan 2001 17:54:16 -0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "Harald Koerfgen" , Subject: Re: MIPS32 patches breaking DecStation Message-ID: <20010109175416.A5383@bacchus.dhis.org> References: <20010109095438.A10683@paradigm.rfc822.org> <20010109162835.B4232@bacchus.dhis.org> <019901c07a72$94d19f00$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <019901c07a72$94d19f00$0deca8c0@Ulysses>; from kevink@mips.com on Tue, Jan 09, 2001 at 08:30:05PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 08:30:05PM +0100, Kevin D. Kissell wrote: > My point is that an SSNOP should cause a 1 cycle stall on *any* MIPS > implementation to date, superscalar or not. It's not documented that > way for the R10000, but if I recall correctly, it works there too. If one > wants to standardize on a single mechanism, that's the one to use. > That's all I'm saying. I agree on that - except that I haven't seen the various various flavours of nops documented anywhere except in IRIX's ... > > Also note that the branch is equivalent to three nops. One for the > > branch instruction itself, the two more for instructions in the pipeline > > that get killed. On the R4600 / R500 where the hazard is only a single > > instruction the branch is equivalent to only a single nop. So while > > unobvious the branch is a rather neat idea. > > Yes, it's cute, but it relies on accidents of implementation to work, > and could easily fail on other CPUs otherwise compatible with > the R4000. In principle, such a branch might incur no delay at > all on an advanced 64-bit processor. By all means, use it for > the specific cases of the CPUs on which it is known to work, > but it should not be used in "default" MIPS CP0 handlers. This behaviour of the R4000 branch is documented in the R4000 manual's description of the pipeline. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 12:30:28 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 12:30:07 -0800 Received: from mx.mips.com ([206.31.31.226]:64478 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 12:29:48 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA02504; Tue, 9 Jan 2001 12:29:43 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id MAA11181; Tue, 9 Jan 2001 12:29:40 -0800 (PST) Message-ID: <01c201c07a7b$696b9c40$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "Harald Koerfgen" , References: <20010109095438.A10683@paradigm.rfc822.org> <20010109162835.B4232@bacchus.dhis.org> <019901c07a72$94d19f00$0deca8c0@Ulysses> <20010109175416.A5383@bacchus.dhis.org> Subject: Re: MIPS32 patches breaking DecStation Date: Tue, 9 Jan 2001 21:33:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing > > Yes, it's cute, but it relies on accidents of implementation to work, > > and could easily fail on other CPUs otherwise compatible with > > the R4000. In principle, such a branch might incur no delay at > > all on an advanced 64-bit processor. By all means, use it for > > the specific cases of the CPUs on which it is known to work, > > but it should not be used in "default" MIPS CP0 handlers. > > This behaviour of the R4000 branch is documented in the R4000 manual's > description of the pipeline. Yes, yes, like I said, use it whenever you see an R4000 PrID if you like. Just don't use it as the handler installed for a PrID not otherwise known to the kernel. Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 9 14:31:37 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 14:31:28 -0800 Received: from sovereign.org ([209.180.91.170]:59530 "EHLO lux.homenet") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 14:31:09 -0800 Received: (from jfree@localhost) by lux.homenet (8.11.1/8.11.1/Debian 8.11.0-6) id f09MVEO13271 for linux-mips@oss.sgi.com; Tue, 9 Jan 2001 15:31:14 -0700 From: Jim Freeman Date: Tue, 9 Jan 2001 15:31:14 -0700 To: linux-mips@oss.sgi.com Subject: -ac to include mips update Message-ID: <20010109153114.A13239@sovereign.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Does Alan Cox have a current mips snapshot in his -ac series ( ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ ) so that he can feed it to Linus for the mainstream 2.4.n? ...jfree From owner-linux-mips@oss.sgi.com Tue Jan 9 15:43:37 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 15:43:27 -0800 Received: from gandalf.physik.uni-konstanz.de ([134.34.144.69]:6155 "EHLO gandalf.physik.uni-konstanz.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 15:43:12 -0800 Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 14G8Py-0008R6-00; Wed, 10 Jan 2001 00:43:06 +0100 Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 14G8Px-0001m4-00; Wed, 10 Jan 2001 00:43:05 +0100 Date: Wed, 10 Jan 2001 00:43:05 +0100 From: Guido Guenther To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: sgialib.h Message-ID: <20010110004305.A6815@bilbo.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Building of latest cvs kernel for IP22 fails for me in arch/mips/arc/init.c and arch/mips/kernel/setup.c due to a typemismatch in the declaration of prom_init in the above mentioned files and sgialib.h. The attached patch fixes this. -- Guido --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sgialib.diff" --- include/asm-mips/sgialib.h.orig Wed Jan 10 00:24:13 2001 +++ include/asm-mips/sgialib.h Wed Jan 10 00:26:55 2001 @@ -20,7 +20,7 @@ * Init the PROM library and it's internal data structures. Called * at boot time from head.S before start_kernel is invoked. */ -extern int prom_init(int argc, char **argv, char **envp, int *prom_vec); +extern void prom_init(int argc, char **argv, char **envp, int *prom_vec); /* Simple char-by-char console I/O. */ extern void prom_putchar(char c); --zhXaljGHf11kAtnf-- From owner-linux-mips@oss.sgi.com Tue Jan 9 16:32:17 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 16:32:07 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:60654 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 16:32:00 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Tue, 9 Jan 2001 22:21:42 -0200 Date: Tue, 9 Jan 2001 22:21:42 -0200 From: Ralf Baechle To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: sgialib.h Message-ID: <20010109222142.A8077@bacchus.dhis.org> References: <20010110004305.A6815@bilbo.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010110004305.A6815@bilbo.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Wed, Jan 10, 2001 at 12:43:05AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Wed, Jan 10, 2001 at 12:43:05AM +0100, Guido Guenther wrote: > Building of latest cvs kernel for IP22 fails for me in > arch/mips/arc/init.c and arch/mips/kernel/setup.c > due to a typemismatch in the declaration of prom_init in the above > mentioned files and sgialib.h. The attached patch fixes this. Thanks, applied. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 17:59:38 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 17:59:18 -0800 Received: from pobox.sibyte.com ([208.12.96.20]:33809 "HELO pobox.sibyte.com") by oss.sgi.com with SMTP id ; Tue, 9 Jan 2001 17:58:58 -0800 Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21]) by pobox.sibyte.com (Postfix) with SMTP id CEAAB205FC for ; Tue, 9 Jan 2001 17:58:52 -0800 (PST) Received: from SMTP agent by mail gateway Tue, 09 Jan 2001 17:53:31 -0800 Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 1ABC415961 for ; Tue, 9 Jan 2001 17:58:53 -0800 (PST) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 5A970686D; Tue, 9 Jan 2001 17:59:01 -0800 (PST) From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: linux-mips@oss.sgi.com Subject: _clear_page semantics Date: Tue, 9 Jan 2001 17:48:11 -0800 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01010917590106.07691@plugh.sibyte.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32 in the mips/ tree, I see everyone issuing cache op 0xd for the address range of the page being cleared. I'm wondering what the purpose is of these cache flushes...given a physically tagged dcache, my understanding of the semantics of clear_page are that it just zeros the page, in which case the cache ops are pointless overhead. Especially in the mips32 case, which uses cache op 0xd, which is undefined implementation dependent according to my mips32 spec. Am I missing something here? Thanks, Justin From owner-linux-mips@oss.sgi.com Tue Jan 9 21:14:51 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 21:14:30 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:65521 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 21:14:10 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Wed, 10 Jan 2001 03:03:26 -0200 Date: Wed, 10 Jan 2001 03:03:26 -0200 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: _clear_page semantics Message-ID: <20010110030326.B8489@bacchus.dhis.org> References: <01010917590106.07691@plugh.sibyte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01010917590106.07691@plugh.sibyte.com>; from carlson@sibyte.com on Tue, Jan 09, 2001 at 05:48:11PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 05:48:11PM -0800, Justin Carlson wrote: > Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32 > in the mips/ tree, I see everyone issuing cache op 0xd for the address range of > the page being cleared. > > I'm wondering what the purpose is of these cache flushes...given a physically > tagged dcache, my understanding of the semantics of clear_page are that it just > zeros the page, in which case the cache ops are pointless overhead. > > Especially in the mips32 case, which uses cache op 0xd, which is undefined > implementation dependent according to my mips32 spec. The idea is to avoid unnecessary memory reads - all the read data would be overwritten anyway. The last time I benchmarked this routine on some machine it made a difference of about 4000 vs. 2500 c0_count cycles. I think that was on a R4600 RM200. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 9 21:14:51 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 21:14:30 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:65521 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 21:14:15 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Wed, 10 Jan 2001 03:03:44 -0200 Date: Wed, 10 Jan 2001 03:03:44 -0200 From: Ralf Baechle To: Jim Freeman Cc: linux-mips@oss.sgi.com Subject: Re: -ac to include mips update Message-ID: <20010110030344.C8489@bacchus.dhis.org> References: <20010109153114.A13239@sovereign.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010109153114.A13239@sovereign.org>; from jfree@sovereign.org on Tue, Jan 09, 2001 at 03:31:14PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Tue, Jan 09, 2001 at 03:31:14PM -0700, Jim Freeman wrote: > From: Jim Freeman > Date: Tue, 9 Jan 2001 15:31:14 -0700 > To: linux-mips@oss.sgi.com > Subject: -ac to include mips update > > Does Alan Cox have a current mips snapshot in his -ac series > ( ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ ) > so that he can feed it to Linus for the mainstream 2.4.n? Obviously not. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 10 00:09:42 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 00:09:22 -0800 Received: from mx.mips.com ([206.31.31.226]:65510 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 00:08:52 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA07632; Wed, 10 Jan 2001 00:08:47 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA28625; Wed, 10 Jan 2001 00:08:44 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id JAA18451; Wed, 10 Jan 2001 09:08:09 +0100 (MET) Message-ID: <3A5C1868.A6B54E57@mips.com> Date: Wed, 10 Jan 2001 09:08:08 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: carlson@sibyte.com CC: linux-mips@oss.sgi.com Subject: Re: _clear_page semantics References: <01010917590106.07691@plugh.sibyte.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Justin Carlson wrote: > Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32 > in the mips/ tree, I see everyone issuing cache op 0xd for the address range of > the page being cleared. > > I'm wondering what the purpose is of these cache flushes...given a physically > tagged dcache, my understanding of the semantics of clear_page are that it just > zeros the page, in which case the cache ops are pointless overhead. > > Especially in the mips32 case, which uses cache op 0xd, which is undefined > implementation dependent according to my mips32 spec. You are absolutely right, it is implementation dependent. I just tend to use the mips32 implementation for my R4000s as well, and here as Ralf mention it is performance improving. Actually we have included a CPU option flag (MIPS_CPU_CACHE_CDEX), what tells us if the CPU has the Create_Dirty_Exclusive CACHE operation available. So we should probably use it, now it is here :-) Thanks. > > Am I missing something here? > > Thanks, > Justin -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jan 10 07:46:04 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 07:45:44 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:59891 "EHLO lappi.waldorf-gmbh.de") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 07:45:36 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Wed, 10 Jan 2001 13:34:39 -0200 Date: Wed, 10 Jan 2001 13:34:39 -0200 From: Ralf Baechle To: Carsten Langgaard Cc: carlson@sibyte.com, linux-mips@oss.sgi.com Subject: Re: _clear_page semantics Message-ID: <20010110133438.A2103@bacchus.dhis.org> References: <01010917590106.07691@plugh.sibyte.com> <3A5C1868.A6B54E57@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5C1868.A6B54E57@mips.com>; from carstenl@mips.com on Wed, Jan 10, 2001 at 09:08:08AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Wed, Jan 10, 2001 at 09:08:08AM +0100, Carsten Langgaard wrote: > You are absolutely right, it is implementation dependent. > I just tend to use the mips32 implementation for my R4000s as well, and here as > Ralf mention it is performance improving. > Actually we have included a CPU option flag (MIPS_CPU_CACHE_CDEX), what tells us > if the CPU has the Create_Dirty_Exclusive CACHE operation available. > So we should probably use it, now it is here :-) Homework for somebody with some time at his hands - we have a large number of unrolled loops for all sorts of cache variations in r4xx0.c. Benchmark if they actually improve performance. I wouldn't wonder if due to a large number of pipeline stalls in one of those routines the whole unrolling business doesn't buy us anything. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 10 13:14:24 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 13:14:04 -0800 Received: from woody.ichilton.co.uk ([216.29.174.40]:62470 "HELO woody.ichilton.co.uk") by oss.sgi.com with SMTP id ; Wed, 10 Jan 2001 13:13:43 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id 7E71C7CF5; Wed, 10 Jan 2001 21:13:41 +0000 (GMT) Date: Wed, 10 Jan 2001 21:13:41 +0000 From: Ian Chilton To: linux-mips@oss.sgi.com Subject: R4X00 Kernel Message-ID: <20010110211341.A26347@woody.ichilton.co.uk> Reply-To: Ian Chilton Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.12i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello, I just compiled a kernel with my new toolchain... I it using gcc 2.95.2 + binutils 2.10.1 and the kernel from today's cvs (10/01/01) which is just after Ralf checked in test12... 08:58PM Exception: 08:58PM Status register: 0x10044803 08:58PM Cause register: 0x3000c000 08:58PM Exception PC: 0x8814c7b4 08:58PM Interrupt exception 08:58PM CPU Parity Error Interrupt 08:58PM Local I/O interrupt register 2: 0xc8 08:58PM CPU parity error register: 0x302 08:59PM CPU parity error: address: 0xa572f88 08:59PM Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): 08:59PM arg: 8a572fc0 0 2530044 881d8000 08:59PM ð penguin42/#mipslinux has sore fingers 08:59PM Opening an Indy is easy 08:59PM tmp: 4 8ad30040 1000 0 0 881b591f fffffff6 ffffffff 08:59PM sve: 8ad31 88800000 881bb280 8ad31 1 2530044 20 1 08:59PM t8 88009dd5 t9 a at 10044800 v0 88800000 v1 0 k1 bad11bad 08:59PM gp 88008000 fp 1f sp 88009e70 ra 881921ec 08:59PM 08:59PM PANIC: Unexpected exception 08:59PM 08:59PM [Press reset or ENTER to restart.] This is on an I2.. Any ideas? Thanks! Bye for Now, Ian \|||/ (o o) /---------------------------ooO-(_)-Ooo---------------------------\ | Ian Chilton (IRC Nick - GadgetMan) ICQ #: 16007717 | |-----------------------------------------------------------------| | E-Mail: ian@ichilton.co.uk Web: http://www.ichilton.co.uk | |-----------------------------------------------------------------| | Budget: A method for going broke methodically. | \-----------------------------------------------------------------/ From owner-linux-mips@oss.sgi.com Wed Jan 10 14:03:25 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 14:03:06 -0800 Received: from gateway-1237.mvista.com ([12.44.186.158]:54267 "EHLO hermes.mvista.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 14:02:44 -0800 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f0AM09C21716 for ; Wed, 10 Jan 2001 14:00:09 -0800 Message-ID: <3A5CDC3A.FE21F363@mvista.com> Date: Wed, 10 Jan 2001 14:03:38 -0800 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) X-Accept-Language: bg, en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: CPU Nevada Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing I can't find any information on a CPU Nevada, which supposedly is a 56x0 type. Is "R56x0 CONFIG_CPU_NEVADA" really meant to be "R52x0 CONFIG_CPU_NEVADA"? The product id code of 0x2800 matches the QED 52xx processors (at least the 5231) -- I can't find anything on a 56x0 CPU. Pete From owner-linux-mips@oss.sgi.com Wed Jan 10 16:37:17 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 16:37:07 -0800 Received: from mx.mips.com ([206.31.31.226]:41971 "EHLO mx.mips.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 16:36:56 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA15822; Wed, 10 Jan 2001 16:36:49 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA25565; Wed, 10 Jan 2001 16:36:46 -0800 (PST) Message-ID: <012301c07b67$19b95c40$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Pete Popov" , References: <3A5CDC3A.FE21F363@mvista.com> Subject: Re: CPU Nevada Date: Thu, 11 Jan 2001 01:40:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing C'mon Pete, it's obviously a typo! It predates my involvement with the code - hell, I never even knew that "Nevada" was the QED code name for the R5200 family before I started hacking on the MIPS Linux kernel, even though I had an R5230 system in my lab. The "6" is probably shifted left one position from "R5260", which was, I believe, the first chip of the Nevada family to ship. Kevin K. ----- Original Message ----- From: "Pete Popov" To: Sent: Wednesday, January 10, 2001 11:03 PM Subject: CPU Nevada > > I can't find any information on a CPU Nevada, which supposedly is a 56x0 > type. Is "R56x0 CONFIG_CPU_NEVADA" really meant to be "R52x0 > CONFIG_CPU_NEVADA"? The product id code of 0x2800 matches the QED 52xx > processors (at least the 5231) -- I can't find anything on a 56x0 CPU. > > Pete From owner-linux-mips@oss.sgi.com Wed Jan 10 16:47:47 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 16:47:37 -0800 Received: from gateway-1237.mvista.com ([12.44.186.158]:7926 "EHLO hermes.mvista.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 16:47:12 -0800 Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f0B0ibC02174; Wed, 10 Jan 2001 16:44:37 -0800 Message-ID: <3A5D02C6.FA7B9B06@mvista.com> Date: Wed, 10 Jan 2001 16:48:06 -0800 From: Pete Popov Organization: Monta Vista Software X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586) X-Accept-Language: bg, en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: CPU Nevada References: <3A5CDC3A.FE21F363@mvista.com> <012301c07b67$19b95c40$0deca8c0@Ulysses> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing "Kevin D. Kissell" wrote: > > C'mon Pete, it's obviously a typo! It predates my involvement > with the code - hell, I never even knew that "Nevada" was the > QED code name for the R5200 family before I started hacking > on the MIPS Linux kernel, even though I had an R5230 system > in my lab. The "6" is probably shifted left one position from > "R5260", which was, I believe, the first chip of the Nevada > family to ship. That's what I figured, but hey, it doesn't hurt to make sure. I'm working with a 5231 and wanted to make sure I don't need to add another cpu type. Pete > ----- Original Message ----- > From: "Pete Popov" > To: > Sent: Wednesday, January 10, 2001 11:03 PM > Subject: CPU Nevada > > > > > I can't find any information on a CPU Nevada, which supposedly is a 56x0 > > type. Is "R56x0 CONFIG_CPU_NEVADA" really meant to be "R52x0 > > CONFIG_CPU_NEVADA"? The product id code of 0x2800 matches the QED 52xx > > processors (at least the 5231) -- I can't find anything on a 56x0 CPU. > > > > Pete From owner-linux-mips@oss.sgi.com Wed Jan 10 19:26:27 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 19:26:17 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:38395 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 19:26:05 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Thu, 11 Jan 2001 01:15:05 -0200 Date: Thu, 11 Jan 2001 01:14:56 -0200 From: Ralf Baechle To: Ian Chilton Cc: linux-mips@oss.sgi.com Subject: Re: R4X00 Kernel Message-ID: <20010111011456.A21226@bacchus.dhis.org> References: <20010110211341.A26347@woody.ichilton.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010110211341.A26347@woody.ichilton.co.uk>; from ian@ichilton.co.uk on Wed, Jan 10, 2001 at 09:13:41PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Wed, Jan 10, 2001 at 09:13:41PM +0000, Ian Chilton wrote: > I just compiled a kernel with my new toolchain... > > I it using gcc 2.95.2 + binutils 2.10.1 and the kernel from today's cvs > (10/01/01) which is just after Ralf checked in test12... Since wealready know that this compiler is fishy I'm going to ignore this report for now. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 10 20:17:27 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 20:17:17 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:30702 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 20:16:58 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Thu, 11 Jan 2001 02:06:05 -0200 Date: Thu, 11 Jan 2001 02:06:05 -0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "Pete Popov" , Subject: Re: CPU Nevada Message-ID: <20010111020604.A24721@bacchus.dhis.org> References: <3A5CDC3A.FE21F363@mvista.com> <012301c07b67$19b95c40$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012301c07b67$19b95c40$0deca8c0@Ulysses>; from kevink@mips.com on Thu, Jan 11, 2001 at 01:40:28AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, Jan 11, 2001 at 01:40:28AM +0100, Kevin D. Kissell wrote: > C'mon Pete, it's obviously a typo! It predates my involvement > with the code - hell, I never even knew that "Nevada" was the > QED code name for the R5200 family before I started hacking > on the MIPS Linux kernel, even though I had an R5230 system > in my lab. The "6" is probably shifted left one position from > "R5260", which was, I believe, the first chip of the Nevada > family to ship. No idea how the 6 ended up there; I wrote the Nevada support for Cobalt's Qube which originally using a R5230, the small brother of the 5260 with just a 32 bit external bus. Anyway, I fixed that buglet. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 10 23:31:08 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 23:30:58 -0800 Received: from [194.90.113.98] ([194.90.113.98]:516 "EHLO yes.home.krftech.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 23:30:39 -0800 Received: from jungo.com (kobie.home.krftech.com [199.204.71.69]) by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id KAA00736; Thu, 11 Jan 2001 10:34:17 +0200 Message-ID: <3A5D609C.2080201@jungo.com> Date: Thu, 11 Jan 2001 09:28:28 +0200 From: Michael Shmulevich User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 CC: busybox@opensource.lineo.com, "linux-mips@oss.sgi.com" Subject: Re: [BusyBox] 0.48 - Can't mount /proc References: <3A5CAC53.60700@jungo.com> <20010110122159.A24714@lineo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Erik, No, doesn't help. bash# mount proc /proc -t proc mount: Mounting proc on /proc failed: Unknown error 716878944 Maybe people in mips-linux know something about this? Erik Andersen wrote: > On Wed Jan 10, 2001 at 08:39:15PM +0200, Michael Shmulevich wrote: > >> Hello, >> >> This is my first mail to this list, but I have already seen similar >> question being unanswered. >> I am developing an embedded system based on MIPS board. I am >> cross-compiling the BusyBox 0.48 on x86 with gcc 2.90.29 (egcs 1.0.3a). >> >> While trying to mount /proc either atomatically in script or by hand, >> the command fails with following message: >> >> bash# mount /proc -t proc >> mount: Mounting none on /proc failed: Unknown error 716878944 > > > mount proc /proc -t proc > > -Erik > > -- > Erik B. Andersen email: andersen@lineo.com > --This message was written using 73% post-consumer electrons-- From owner-linux-mips@oss.sgi.com Thu Jan 11 02:10:19 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 02:10:09 -0800 Received: from woody.ichilton.co.uk ([216.29.174.40]:9735 "HELO woody.ichilton.co.uk") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 02:09:54 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id 6ED567CF3; Thu, 11 Jan 2001 10:09:52 +0000 (GMT) Date: Thu, 11 Jan 2001 10:09:52 +0000 From: Ian Chilton To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: R4X00 Kernel Message-ID: <20010111100952.A27640@woody.ichilton.co.uk> Reply-To: Ian Chilton References: <20010110211341.A26347@woody.ichilton.co.uk> <20010111011456.A21226@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010111011456.A21226@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, Jan 11, 2001 at 01:14:56AM -0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello, > > I it using gcc 2.95.2 + binutils 2.10.1 and the kernel from today's cvs > > (10/01/01) which is just after Ralf checked in test12... > > Since wealready know that this compiler is fishy I'm going to ignore this > report for now. What do you mean? It's Macro's stuff...you said you trusted his code :) Or do you mean the PIC thing? I told you I already fixed that! root@dale:~# echo __PIC__ | gcc -E -P - 1 So are you saying this is a compiler thing, not a kernel thing? Bye for Now, Ian \|||/ (o o) /---------------------------ooO-(_)-Ooo---------------------------\ | Ian Chilton (IRC Nick - GadgetMan) ICQ #: 16007717 | |-----------------------------------------------------------------| | E-Mail: ian@ichilton.co.uk Web: http://www.ichilton.co.uk | |-----------------------------------------------------------------| | Budget: A method for going broke methodically. | \-----------------------------------------------------------------/ From owner-linux-mips@oss.sgi.com Thu Jan 11 03:48:39 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 03:48:30 -0800 Received: from slag.lineo.com ([64.50.107.170]:43781 "HELO slag.lineo.com") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 03:48:15 -0800 Received: by slag.lineo.com (Postfix, from userid 1000) id EB095188721; Thu, 11 Jan 2001 04:48:08 -0700 (MST) Date: Thu, 11 Jan 2001 04:48:08 -0700 From: Erik Andersen To: Michael Shmulevich Cc: busybox@opensource.lineo.com, "linux-mips@oss.sgi.com" Subject: Re: [BusyBox] 0.48 - Can't mount /proc Message-ID: <20010111044808.A1592@lineo.com> Reply-To: andersen@lineo.com References: <3A5CAC53.60700@jungo.com> <20010110122159.A24714@lineo.com> <3A5D609C.2080201@jungo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5D609C.2080201@jungo.com>; from michaels@jungo.com on Thu, Jan 11, 2001 at 09:28:28AM +0200 X-Operating-System: Linux 2.2.18pre9, AMD Athlon, 704.938 MHz X-No-Junk-Mail: I do not want to get *any* junk mail. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu Jan 11, 2001 at 09:28:28AM +0200, Michael Shmulevich wrote: > Erik, > > No, doesn't help. > > bash# mount proc /proc -t proc > > mount: Mounting proc on /proc failed: Unknown error 716878944 > > > Maybe people in mips-linux know something about this? Yes, this does sound like a kernel specific problem then, since this works on (at least) arm, ppc, sh, and x86. I havn't tried it on anything else. -Erik -- Erik B. Andersen email: andersen@lineo.com --This message was written using 73% post-consumer electrons-- From owner-linux-mips@oss.sgi.com Thu Jan 11 04:04:40 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 04:04:30 -0800 Received: from noose.gt.owl.de ([62.52.19.4]:54798 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 04:04:09 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id DBDEB7F3; Thu, 11 Jan 2001 13:04:06 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5E7F0F597; Thu, 11 Jan 2001 13:04:50 +0100 (CET) Date: Thu, 11 Jan 2001 13:04:50 +0100 From: Florian Lohoff To: Erik Andersen Cc: Michael Shmulevich , busybox@opensource.lineo.com, "linux-mips@oss.sgi.com" Subject: Re: [BusyBox] 0.48 - Can't mount /proc Message-ID: <20010111130450.B5811@paradigm.rfc822.org> References: <3A5CAC53.60700@jungo.com> <20010110122159.A24714@lineo.com> <3A5D609C.2080201@jungo.com> <20010111044808.A1592@lineo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111044808.A1592@lineo.com>; from andersen@lineo.com on Thu, Jan 11, 2001 at 04:48:08AM -0700 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, Jan 11, 2001 at 04:48:08AM -0700, Erik Andersen wrote: > On Thu Jan 11, 2001 at 09:28:28AM +0200, Michael Shmulevich wrote: > > Erik, > > > > No, doesn't help. > > > > bash# mount proc /proc -t proc > > > > mount: Mounting proc on /proc failed: Unknown error 716878944 > > > > > > Maybe people in mips-linux know something about this? > > Yes, this does sound like a kernel specific problem then, > since this works on (at least) arm, ppc, sh, and x86. > I havn't tried it on anything else. Henning Heinold has done a lot with busybox on mips (debian installer) Might this be due to kernel 2.4 and /proc/mounts includeing a / in front of proc (flo@ping)~# cat /proc/mounts /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sda7 /usr ext2 rw 0 0 /dev/sda8 /var ext2 rw 0 0 /dev/sda9 /tmp ext2 rw 0 0 /dev/sda10 /home ext2 rw 0 0 /dev/hda5 /var/tmp ext3 rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 automount(pid19472) /mnt autofs rw 0 0 (flo@ping)~# uname -a Linux ping.mediaways.net 2.2.18ext3 #1 Thu Dec 14 18:24:45 CET 2000 i686 unknown Or flo@resume:~$ cat /proc/mounts /dev/root / ext2 rw 0 0 /proc /proc proc rw 0 0 /dev/sdb1 /home2 ext2 rw 0 0 /dev/sdc1 /home3 ext2 rw 0 0 /dev/sdd1 /ftp.rfc822.org ext2 rw 0 0 /dev/sde1 /home4 ext2 rw 0 0 shmfs /var/shm shm rw 0 0 devpts /home4/dev/pts devpts rw 0 0 proc /home4/proc proc rw 0 0 flo@resume:~$ uname -a Linux resume.rfc822.org 2.4.0-test6 #2 Sun Aug 27 12:37:51 GMT 2000 mips unknown Henning has fought with this IIRC. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Thu Jan 11 05:05:30 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 05:05:20 -0800 Received: from woody.ichilton.co.uk ([216.29.174.40]:12551 "HELO woody.ichilton.co.uk") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 05:05:06 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id AA5057CF5; Thu, 11 Jan 2001 13:05:04 +0000 (GMT) Date: Thu, 11 Jan 2001 13:05:04 +0000 From: Ian Chilton To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: Re: R4X00 Kernel Message-ID: <20010111130504.A30705@woody.ichilton.co.uk> Reply-To: Ian Chilton Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello, I just compiled a kernel from 001027 with the same toolchain and quintella booted it on the same I2.... Looks like the test12 in CVS is broken :) Bye for Now, Ian \|||/ (o o) /---------------------------ooO-(_)-Ooo---------------------------\ | Ian Chilton (IRC Nick - GadgetMan) ICQ #: 16007717 | |-----------------------------------------------------------------| | E-Mail: ian@ichilton.co.uk Web: http://www.ichilton.co.uk | |-----------------------------------------------------------------| | Proofread carefully to see if you any words out. | \-----------------------------------------------------------------/ From owner-linux-mips@oss.sgi.com Thu Jan 11 07:52:51 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 07:52:32 -0800 Received: from stereotomy.lineo.com ([64.50.107.151]:51722 "HELO stereotomy.lineo.com") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 07:52:10 -0800 Received: from Lineo.COM (localhost.localdomain [127.0.0.1]) by stereotomy.lineo.com (Postfix) with ESMTP id DAE7B4CC6F; Thu, 11 Jan 2001 08:52:08 -0700 (MST) Message-ID: <3A5DD6A8.1040600@Lineo.COM> Date: Thu, 11 Jan 2001 08:52:08 -0700 From: Quinn Jensen Organization: Lineo, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: owner-linux-mips@oss.sgi.com Cc: Erik Andersen , Michael Shmulevich , busybox@opensource.lineo.com, "linux-mips@oss.sgi.com" Subject: Re: [BusyBox] 0.48 - Can't mount /proc References: <3A5CAC53.60700@jungo.com> <20010110122159.A24714@lineo.com> <3A5D609C.2080201@jungo.com> <20010111044808.A1592@lineo.com> <20010111130450.B5811@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Here's a kernel patch. The __access_ok macro looks one byte too far and fails. Since copy_mount_options() isn't sure how long the string arguments are, it just copies to the end of the page. Since this is on busybox's stack, the copy wants to go all the way to 0x7FFFFFF and hits this corner case. Quinn Jensen jensenq@lineo.com --- linux-sgi-2.4.0-test11-pristine/include/asm-mips/uaccess.h Wed Oct 4 19:19:02 2000 +++ linux/include/asm-mips/uaccess.h Wed Jan 10 16:20:35 2001 @@ -46,7 +46,7 @@ * - OR we are in kernel mode. */ #define __access_ok(addr,size,mask) \ - (((__signed__ long)((mask)&(addr | size | (addr+size)))) >= 0) + (((__signed__ long)((mask)&(addr | size | (addr+size-1)))) >= 0) #define __access_mask ((long)(get_fs().seg)) #define access_ok(type,addr,size) \ From owner-linux-mips@oss.sgi.com Thu Jan 11 12:37:33 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 12:37:23 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:29938 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 12:37:08 -0800 Received: (ralf@lappi.waldorf-gmbh.de) by bacchus.dhis.org id ; Thu, 11 Jan 2001 18:25:51 -0200 Date: Thu, 11 Jan 2001 18:25:50 -0200 From: Ralf Baechle To: Michael Shmulevich Cc: busybox@opensource.lineo.com, "linux-mips@oss.sgi.com" Subject: Re: [BusyBox] 0.48 - Can't mount /proc Message-ID: <20010111182550.A894@bacchus.dhis.org> References: <3A5CAC53.60700@jungo.com> <20010110122159.A24714@lineo.com> <3A5D609C.2080201@jungo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5D609C.2080201@jungo.com>; from michaels@jungo.com on Thu, Jan 11, 2001 at 09:28:28AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, Jan 11, 2001 at 09:28:28AM +0200, Michael Shmulevich wrote: > bash# mount proc /proc -t proc > > mount: Mounting proc on /proc failed: Unknown error 716878944 716878944 is 0x2abab460, a typical address of a shared library or malloced memory allocated via mmap(2). Ralf From owner-linux-mips@oss.sgi.com Thu Jan 11 14:42:44 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 14:42:34 -0800 Received: from woody.ichilton.co.uk ([216.29.174.40]:25095 "HELO woody.ichilton.co.uk") by oss.sgi.com with SMTP id ; Thu, 11 Jan 2001 14:42:06 -0800 Received: by woody.ichilton.co.uk (Postfix, from userid 1000) id AD2457CFE; Thu, 11 Jan 2001 22:42:05 +0000 (GMT) Date: Thu, 11 Jan 2001 22:42:05 +0000 From: Ian Chilton To: linux-mips@oss.sgi.com Subject: Current CVS Kernel Broken on MIPS (010111 - 2.4.0) Message-ID: <20010111224205.A2429@woody.ichilton.co.uk> Reply-To: Ian Chilton Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Hello, Klaus tried booting the kernel I compiled using current CVS (010111) I used the same GCC 2.95.2 + Binutils 2.10.1 that worked when compiling 001027. This output was from an I2 Command Monitor. Type "exit" to return to the menu. >> bootp():vmlinux console=ttyS0 Setting $netaddr to 192.168.1.2 (from server scotty) Obtaining vmlinux from server scotty \ Exception: Status register: 0x10044803 Cause register: 0x3000c01c Exception PC: 0x88141554, Exception RA: 0x881821d4 Data Bus error GIO Timeout Interrupt Local I/O interrupt register 1: 0x80 Local I/O interrupt register 2: 0xca GIO parity error register: 0x400