From owner-linux-mips@oss.sgi.com Fri Jun 1 04:45:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Bj6u11440 for linux-mips-outgoing; Fri, 1 Jun 2001 04:45:06 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Bj0h11434 for ; Fri, 1 Jun 2001 04:45:00 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 101041E4BB; Fri, 1 Jun 2001 13:44:54 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: From: Andreas Jaeger Date: 01 Jun 2001 13:44:51 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Fri, 1 Jun 2001 13:32:29 +0200 (MET DST)") Message-ID: Lines: 78 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" writes: > On 31 May 2001, Andreas Jaeger wrote: > >> Do it the following way: >> - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. >> __ASSUME_TEST_AND_SET with the appropriate guards >> - Do *both* implementations like this: >> #include >> #if __ASSUME_TEST_AND_SET >> fast code without fallback >> #else >> slow code that first tries kernel call and then falls back to sysmips >> #endif >> This way you get the fast one if you configure glibc with >> --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with >> those features. > > Thanks for the tip. It's reasonable, indeed. Now the point is to get > Linux changes (once introduced) back to Linus' tree. It would be bad to > to tie a kernel version with a feature that would be present in the CVS at > oss. > >> Check other places in glibc for details how this can be done. > > OK, how about this patch then (the kernel version has to be set once > known)? > > Maciej diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c Fri Jul 28 13:37:25 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c Thu May 31 23:21:50 2001 @@ -21,6 +21,12 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include + +#include "kernel-features.h" #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES @@ -28,3 +34,46 @@ #endif #include "sys/tas.h" + +#ifdef __NR__test_and_set +# ifdef __ASSUME__TEST_AND_SET +# define __have_no__test_and_set 0 Don't add this, compare how we do it in similar cases. diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h Sun Jan 7 04:35:41 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h Wed May 30 02:18:19 2001 @@ -22,11 +22,11 @@ #include #include -#include __BEGIN_DECLS extern int _test_and_set (int *p, int v) __THROW; +extern int ___test_and_set (int *p, int v) __THROW; Why do you export this here? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Jun 1 04:51:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51BpPe11969 for linux-mips-outgoing; Fri, 1 Jun 2001 04:51:25 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Bnbh11857 for ; Fri, 1 Jun 2001 04:49:39 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27957; Fri, 1 Jun 2001 13:32:29 +0200 (MET DST) Date: Fri, 1 Jun 2001 13:32:29 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Andreas Jaeger cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration 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 On 31 May 2001, Andreas Jaeger wrote: > Do it the following way: > - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. > __ASSUME_TEST_AND_SET with the appropriate guards > - Do *both* implementations like this: > #include > #if __ASSUME_TEST_AND_SET > fast code without fallback > #else > slow code that first tries kernel call and then falls back to sysmips > #endif > This way you get the fast one if you configure glibc with > --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with > those features. Thanks for the tip. It's reasonable, indeed. Now the point is to get Linux changes (once introduced) back to Linus' tree. It would be bad to to tie a kernel version with a feature that would be present in the CVS at oss. > Check other places in glibc for details how this can be done. OK, how about this patch then (the kernel version has to be set once known)? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + glibc-2.2.3-mips-tas.patch diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/kernel-features.h glibc-2.2.3/sysdeps/unix/sysv/linux/kernel-features.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/kernel-features.h Wed Apr 25 21:51:14 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/kernel-features.h Thu May 31 15:54:59 2001 @@ -182,3 +182,8 @@ # define __ASSUME_FCNTL64 1 # define __ASSUME_GETDENTS64_SYSCALL 1 #endif + +/* The _test_and_set syscall is available on MIPS since 2.?.?. */ +#if 0 && defined __mips__ +# define __ASSUME__TEST_AND_SET 1 +#endif diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions Wed Aug 2 21:53:16 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions Wed May 30 02:20:28 2001 @@ -16,6 +16,6 @@ libc { } GLIBC_2.2 { # _* - _test_and_set; + _test_and_set; ___test_and_set; } } diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c Fri Jul 28 13:37:25 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c Thu May 31 23:21:50 2001 @@ -21,6 +21,12 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include + +#include "kernel-features.h" #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES @@ -28,3 +34,46 @@ #endif #include "sys/tas.h" + +#ifdef __NR__test_and_set +# ifdef __ASSUME__TEST_AND_SET +# define __have_no__test_and_set 0 +# else +static int __have_no__test_and_set; +# endif +#endif + +int ___test_and_set (int *p, int v) +{ +#ifdef __NR__test_and_set + if (!__builtin_expect(__have_no__test_and_set, 0)) + { + register int *__p asm ("$4") = p; + register int __v asm ("$5") = v; + register int __n asm ("$2") = SYS_ify (_test_and_set); + register int __e asm ("$7"); + register int __r asm ("$3"); + + asm + ("syscall" + : "=r" (__r), "=r" (__e) + : "r" (__p), "r" (__v), "r" (__n) + : "$2", + "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", + "memory"); +# ifndef __ASSUME__TEST_AND_SET + if (__builtin_expect(__e, 0)) + __have_no__test_and_set = 1; + else +# endif + return __r; + } +#endif +#if !defined __NR__test_and_set || !defined __ASSUME__TEST_AND_SET + return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); +#endif +} + +#if (_MIPS_ISA < _MIPS_ISA_MIPS2) +strong_alias (___test_and_set, _test_and_set) +#endif diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h Sun Jan 7 04:35:41 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h Wed May 30 02:18:19 2001 @@ -22,11 +22,11 @@ #include #include -#include __BEGIN_DECLS extern int _test_and_set (int *p, int v) __THROW; +extern int ___test_and_set (int *p, int v) __THROW; #ifdef __USE_EXTERN_INLINES @@ -59,15 +59,7 @@ _test_and_set (int *p, int v) __THROW return r; } -# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -_EXTERN_INLINE int -_test_and_set (int *p, int v) __THROW -{ - return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); -} - -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* __USE_EXTERN_INLINES */ From owner-linux-mips@oss.sgi.com Fri Jun 1 05:29:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51CT3w14282 for linux-mips-outgoing; Fri, 1 Jun 2001 05:29:03 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51CKwh13501 for ; Fri, 1 Jun 2001 05:21:00 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA29612; Fri, 1 Jun 2001 14:18:05 +0200 (MET DST) Date: Fri, 1 Jun 2001 14:18:04 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Andreas Jaeger cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration 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 On 1 Jun 2001, Andreas Jaeger wrote: > #include "sys/tas.h" > + > +#ifdef __NR__test_and_set > +# ifdef __ASSUME__TEST_AND_SET > +# define __have_no__test_and_set 0 > > Don't add this, compare how we do it in similar cases. Hmm, I looked at sysdeps/unix/sysv/linux/getcwd.c. It does it in a similar way. What's wrong with this approach? I'm just asking -- it looks I do not always guess glibc rules right and not everything is documented. Actually I tried to avoid macros if at all possible but gcc refuses to eliminate code even if that's something like: static const int var = 1; <...> if (var) <...> It still generates the code to check the value of var, sigh... Also I feel a bit uneasy about placing the "#ifdef __ASSUME__TEST_AND_SET" condition outside -- __NR__test_and_set might be undefined due to outdated kernel headers even if someone specified the --enable-kernel option. Is it considered justified within glibc to bail out at the compilation time in this case? > extern int _test_and_set (int *p, int v) __THROW; > +extern int ___test_and_set (int *p, int v) __THROW; > > Why do you export this here? It's a syscall wrapper. We want to export syscall wrappers, don't we? And if we export a symbol, we should also declare it -- programs declaring library symbols themselves are broken and doomed to fail sooner or later -- have you seen what happens on glibc systems to old programs which declare functions due to the lack of appropriate declarations in system headers at one time? If we don't want to export the wrapper, then fine -- I'll remove both the symbol and the declaration. 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 Fri Jun 1 05:44:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51CiUK15339 for linux-mips-outgoing; Fri, 1 Jun 2001 05:44:30 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Cegh15045 for ; Fri, 1 Jun 2001 05:44:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA29071; Fri, 1 Jun 2001 13:55:12 +0200 (MET DST) Date: Fri, 1 Jun 2001 13:55:12 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: Andreas Jaeger , linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration In-Reply-To: <3B1697BE.3F3765A2@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 On Thu, 31 May 2001, Jun Sun wrote: > > This way you get the fast one if you configure glibc with > > --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with > > those features. > > > > Check other places in glibc for details how this can be done. > > This might be an overkill - the slow code on a newer kernel costs about 1 or 2 > cycle longer per call. Do you realize how often the call is invoked!? There is a number of memory stores involved in the slow implementation -- with write-trough cache it really sucks, even more than memory accesses in general. > On a second thought I feel stronger using $v1 is not a good idea - what if the > return path of syscall suddenly needs to modify $v1? Also we have generic > syscall routine in glibc, what if someday that routine starts to check $v1 as > well? We are safe here. V1 is a result register so its semantics must be preserved if at all possible. Then there is the pipe() syscall that already makes use of v1 as a result register for a long time, so we are really, really safe. There are t* registers available for the syscall handler if an additional register is needed. The coding conventions are there for a reason, aren't they? > I understand the chances of these "what if" are low (and perhaps sys_pipe() is > already this way), but I am still convinced we should the right thing. > (Whoever invented MIPS_ATOMIC_SET might have been thinking it should never > need to return an error code!) Nope -- the problem lies elsewhere. It is sysmips() that was invented to return an error code and MIPS_ATOMIC_SET violating it from the day #1. It was plain broken since the beginning. I suppose it ws just an ad hoc hack written once someone realized the operation is necessary. Just like the whole sysmips() syscall. > I don't see any "dirtiness" in using the third argument. The slowdown in > performance should be negligible under the context of the whole system call. I do believe good performance is the main goal here. The syscall is as clean as possible -- it would still be possible to make it yet faster if dirty hacks were added. > A syscall is invented to be here and stay. I personally feel more comfortable > to play a little safer rather than a littel faster. Cycles sum up, unfortunately. A strace of `ls -la' on my /usr/lib directory shows about 4500 syscall invocations of which about 4000 are invocations of _test_and_set()! 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 Fri Jun 1 06:15:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51DFkd17519 for linux-mips-outgoing; Fri, 1 Jun 2001 06:15:46 -0700 Received: from linpro.no (qmailr@mail.linpro.no [213.203.57.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51DFhh17509 for ; Fri, 1 Jun 2001 06:15:43 -0700 Received: (qmail 12692 invoked from network); 1 Jun 2001 13:15:41 -0000 Received: from false.linpro.no (213.203.57.201) by mail.linpro.no with SMTP; 1 Jun 2001 13:15:41 -0000 Received: from toffer by false.linpro.no with local (Exim 3.12 #1 (Debian)) id 155omH-0005Mf-00; Fri, 01 Jun 2001 15:15:45 +0200 To: linux-mips@oss.sgi.com Cc: drift@ping.uio.no Subject: Challenge S SCSI adapter From: Kristoffer Gleditsch Organization: Millennium Hand And Shrimp Society Date: 01 Jun 2001 15:15:44 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, We got our hands on a Challenge S the other day. We're planning to install Linux on it and let it do something useful, but we don't have any use for the SCSI adapter. If anyone out there are working on Linux drivers for these cards, we'd be happy to let them have it. If anyone is interested, send me a mail. Regards, -- Kristoffer. From owner-linux-mips@oss.sgi.com Fri Jun 1 06:48:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Dmod21399 for linux-mips-outgoing; Fri, 1 Jun 2001 06:48:50 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Dmhh21394 for ; Fri, 1 Jun 2001 06:48:44 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 4B7611E1BF; Fri, 1 Jun 2001 15:48:38 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: From: Andreas Jaeger Date: 01 Jun 2001 15:48:36 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Fri, 1 Jun 2001 14:18:04 +0200 (MET DST)") Message-ID: Lines: 67 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" writes: > On 1 Jun 2001, Andreas Jaeger wrote: > >> #include "sys/tas.h" >> + >> +#ifdef __NR__test_and_set >> +# ifdef __ASSUME__TEST_AND_SET >> +# define __have_no__test_and_set 0 >> >> Don't add this, compare how we do it in similar cases. > > Hmm, I looked at sysdeps/unix/sysv/linux/getcwd.c. It does it in a > similar way. What's wrong with this approach? I'm just asking -- it > looks I do not always guess glibc rules right and not everything is > documented. We normally do not define anything to 0 - unless there's no other way. And looking briefly over your code there should be other solutions. Sorry, I'm limited in time currently, otherwise I would rewrite it myself. Look at i386/lockf64.c for a cleaner example. > Actually I tried to avoid macros if at all possible but gcc refuses to > eliminate code even if that's something like: > > static const int var = 1; > <...> > if (var) > <...> > > It still generates the code to check the value of var, sigh... > > Also I feel a bit uneasy about placing the "#ifdef > __ASSUME__TEST_AND_SET" condition outside -- __NR__test_and_set might be > undefined due to outdated kernel headers even if someone specified the > --enable-kernel option. Is it considered justified within glibc to bail > out at the compilation time in this case? We check that for the kernel headers in configure. >> extern int _test_and_set (int *p, int v) __THROW; >> +extern int ___test_and_set (int *p, int v) __THROW; >> >> Why do you export this here? > > It's a syscall wrapper. We want to export syscall wrappers, don't > we? No, not everything - we already export _test_and_set and that should be enough. > And if we export a symbol, we should also declare it -- programs declaring > library symbols themselves are broken and doomed to fail sooner or later > -- have you seen what happens on glibc systems to old programs which > declare functions due to the lack of appropriate declarations > in system headers at one time? > > If we don't want to export the wrapper, then fine -- I'll remove both the > symbol and the declaration. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Jun 1 07:40:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Ee0R25403 for linux-mips-outgoing; Fri, 1 Jun 2001 07:40:00 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Eb5h25184 for ; Fri, 1 Jun 2001 07:37:30 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA03732; Fri, 1 Jun 2001 16:21:26 +0200 (MET DST) Date: Fri, 1 Jun 2001 16:21:26 +0200 (MET DST) From: "Maciej W. Rozycki" To: Andreas Jaeger cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration 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 On 1 Jun 2001, Andreas Jaeger wrote: > We normally do not define anything to 0 - unless there's no other > way. And looking briefly over your code there should be other > solutions. Sorry, I'm limited in time currently, otherwise I would > rewrite it myself. OK, I'll check how to write it better and still get good optimization results. Please don't bother writing it yourself -- we don't have any kernel code yet, so there is no real need to get involved so much. > Look at i386/lockf64.c for a cleaner example. Hmm, glibc rules certainly look different from Linux's ones -- I tried to avoid interspersing real code with preprocessor conditionals. Since you state it's OK, I should have no problem with coding accrdingly. > > It's a syscall wrapper. We want to export syscall wrappers, don't > > we? > > No, not everything - we already export _test_and_set and that should > be enough. OK, then. -- + 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 Jun 1 14:06:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51L68B14204 for linux-mips-outgoing; Fri, 1 Jun 2001 14:06:08 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51L67h14196 for ; Fri, 1 Jun 2001 14:06:07 -0700 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 f51L62030547; Fri, 1 Jun 2001 14:06:02 -0700 Message-ID: <3B180383.C7DDAEDC@mvista.com> Date: Fri, 01 Jun 2001 14:05:07 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Linux on PlayStation 2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I got forwarded by the following link, although in Japanese, which says Sony is selling a Linux kit for PS2. Does anybody know more details about this port? Specifically, does anyone have the source code? http://www.jp.playstation.com/linux/ Jun From owner-linux-mips@oss.sgi.com Fri Jun 1 14:32:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51LWFV19081 for linux-mips-outgoing; Fri, 1 Jun 2001 14:32:15 -0700 Received: from ukxchange.ckor.com ([212.137.21.211]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51LW9h19060; Fri, 1 Jun 2001 14:32:09 -0700 Received: from lowestoftunix.ckor.com (192.168.50.6 [192.168.50.6]) by ukxchange.ckor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MC3XFC4N; Fri, 1 Jun 2001 15:59:44 +0100 Received: from pool-63.52.247.235.ipls.grid.net by lowestoftunix.ckor.com id aa15128; 1 Jun 2001 15:35 BST Message-ID: <0000392b1397$00002cc8$00001579@63.52.247.235> To: From: evlacdim@yahoo.com Subject: Response To Inquiry 5497 Date: Mon, 04 Jun 2001 19:32:36 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk

e Earn = $1500 Or More P= er Week!

 
This offer is limited to the = first 49 people who contact me today!


Let's face it, every bus= iness opportunity is not for everyone.  You need something = that fits your needs, budget, and schedule.  That is why w= e have put together several "Real= " Income Opportunities just for you. We have sea= rched and searched and finally found and compiled the best opportunities available.  

I pr= omise, you will not regret it. You will finally find something you tr= uly can make Money with. You really can make an Extra = $200 to $1,500 a Week if you have a few hours a week to wor= k your business!

You = do not have to pay one dime to find out about these true money making opportunities.  Just Call 1(888)281-2694 and we will show you the best, = real moneymakers available.&n= bsp; It is 100% FREE, so visit us today, do not miss out on= a life changing opportunity.

This is Absolutely= No Risk, so Call 1(888)281-2694 Right Now, = and Find The Opportunity of A Lifetime!

 

Call 1(888)281-2694 Immediatly
24 Hrs / 7 Days

 
 
- Testimonials -
 
"My very first day with less than an hour of my= spare time I made over $123.00. My second da= y I duplicated that in less than 30 minutes."
Jason Vielhem
"Mr. Skeptical"
-----------= ----
 
"I literally make thousands each month fr= om the comfort of my home, heck my couch! Tha= nk you for changing my life forever!"
 
Jenna Wilson

---------------=

a

 






 

 

 

 

Put your email address in body of email and send email to here


~~~~~~~~~~~~ From owner-linux-mips@oss.sgi.com Fri Jun 1 14:35:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51LZP119869 for linux-mips-outgoing; Fri, 1 Jun 2001 14:35:25 -0700 Received: from home.knm.org (IDENT:root@[166.70.178.116]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51LZOh19858 for ; Fri, 1 Jun 2001 14:35:24 -0700 Received: (from mark@localhost) by home.knm.org (8.9.3/8.9.3) id PAA16955; Fri, 1 Jun 2001 15:35:21 -0600 Date: Fri, 1 Jun 2001 15:35:21 -0600 Message-Id: <200106012135.PAA16955@home.knm.org> X-Authentication-Warning: home.knm.org: mark set sender to mark@home.knm.org using -f From: Mark Lehrer To: jsun@mvista.com CC: linux-mips@oss.sgi.com In-reply-to: <3B180383.C7DDAEDC@mvista.com> (message from Jun Sun on Fri, 01 Jun 2001 14:05:07 -0700) Subject: Re: Linux on PlayStation 2 References: <3B180383.C7DDAEDC@mvista.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Well, the kernel is GPL'd, so Sony should have some kind of source code package available if you buy their Linux kit. Mark I got forwarded by the following link, although in Japanese, which says Sony is selling a Linux kit for PS2. Does anybody know more details about this port? Specifically, does anyone have the source code? http://www.jp.playstation.com/linux/ From owner-linux-mips@oss.sgi.com Fri Jun 1 15:06:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51M6TP26033 for linux-mips-outgoing; Fri, 1 Jun 2001 15:06:29 -0700 Received: from web11907.mail.yahoo.com (web11907.mail.yahoo.com [216.136.172.191]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51M6Sh26030 for ; Fri, 1 Jun 2001 15:06:28 -0700 Message-ID: <20010601220616.18199.qmail@web11907.mail.yahoo.com> Received: from [209.243.184.191] by web11907.mail.yahoo.com; Fri, 01 Jun 2001 15:06:16 PDT Date: Fri, 1 Jun 2001 15:06:16 -0700 (PDT) From: Wayne Gowcher Subject: Re: Linux on PlayStation 2 To: linux-mips@oss.sgi.com In-Reply-To: <200106012135.PAA16955@home.knm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Going to link http://www.jp.playstation.com/linux/dmesg.html I see that bogo mips are reported as : Calibrating delay loop... 392.40 BogoMIPS Estimated CPU clock: 294.240 MHz I thought the PS2 was a dual pipelined processor and so maybe would see a higher BogoMIPS figure ? Possibly double ? Anybody know the ins and outs of this ? Wayne __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Sat Jun 2 07:01:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52E1uX27274 for linux-mips-outgoing; Sat, 2 Jun 2001 07:01:56 -0700 Received: from dea.waldorf-gmbh.de (u-200-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.200]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52E1rh27260 for ; Sat, 2 Jun 2001 07:01:54 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f52DZoP08800; Sat, 2 Jun 2001 15:35:50 +0200 Date: Sat, 2 Jun 2001 15:35:49 +0200 From: Ralf Baechle To: Kristoffer Gleditsch Cc: linux-mips@oss.sgi.com, drift@ping.uio.no Subject: Re: Challenge S SCSI adapter Message-ID: <20010602153549.A8637@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 toffer@ping.uio.no on Fri, Jun 01, 2001 at 03:15:44PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jun 01, 2001 at 03:15:44PM +0200, Kristoffer Gleditsch wrote: > We got our hands on a Challenge S the other day. We're planning to > install Linux on it and let it do something useful, but we don't have > any use for the SCSI adapter. If anyone out there are working on > Linux drivers for these cards, we'd be happy to let them have it. If > anyone is interested, send me a mail. Currently there is no ongoing driver work for the WD33C95 secondary SCSI hostadapter in Challenge S and other SGI systems. Ralf From owner-linux-mips@oss.sgi.com Sat Jun 2 10:10:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52HA3b17992 for linux-mips-outgoing; Sat, 2 Jun 2001 10:10:03 -0700 Received: from aeon.tvd.be (aeon.tvd.be [195.162.196.20]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52HA2h17989 for ; Sat, 2 Jun 2001 10:10:02 -0700 Received: from callisto.of.borg (cable-195-162-217-46.upc.chello.be [195.162.217.46]) by aeon.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id TAA09916 for ; Sat, 2 Jun 2001 19:10:00 +0200 (MET DST) Received: from localhost (geert@localhost) by callisto.of.borg (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA23925 for ; Sat, 2 Jun 2001 19:07:46 +0200 X-Authentication-Warning: callisto.of.borg: geert owned process doing -bs Date: Sat, 2 Jun 2001 19:07:46 +0200 (CEST) From: Geert Uytterhoeven To: Linux/MIPS Development Subject: wd33c93 question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Anyone who can explain these changes? Here the MIPS tree differs from Linus' (and the m68k) tree. According to the CVS logs, this change entered in revision 1.7 due to a sync with Linus' tree (which introduced other formatting changes) somewhere in 1998. In Linus' tree it must have changed afterwards a long time ago (before 2.2.0). --- linux-2.4.5/drivers/scsi/wd33c93.c Tue Dec 5 21:43:48 2000 +++ linux-mips/drivers/scsi/wd33c93.c Mon Mar 26 02:38:20 2001 @@ -614,7 +614,6 @@ (is_dir_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR)) write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ else { - write_wd33c93_count(regp, cmd->SCp.this_residual); write_wd33c93(regp,WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); hostdata->dma = D_DMA_RUNNING; } @@ -735,7 +734,6 @@ hostdata->dma_cnt++; #endif write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); - write_wd33c93_count(regp,cmd->SCp.this_residual); if ((hostdata->level2 >= L2_DATA) || (hostdata->level2 == L2_BASIC && cmd->SCp.phase == 0)) { Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Sat Jun 2 14:29:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52LTJH30884 for linux-mips-outgoing; Sat, 2 Jun 2001 14:29:19 -0700 Received: from algonet.se (delenn.tninet.se [195.100.94.104]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52LTIh30880 for ; Sat, 2 Jun 2001 14:29:18 -0700 Received: from aristotle.algonet.se (aristotle.algonet.se [194.213.74.200]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 693603.517351.991delenn-s0 for ; Sat, 02 Jun 2001 23:29:11 +0200 Date: Sat, 2 Jun 2001 23:29:11 +0200 (MET DST) From: Yann Vernier To: linux-mips@oss.sgi.com Subject: Re: Challenge S SCSI adapter - Ethernet? In-Reply-To: <20010602153549.A8637@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 On Sat, 2 Jun 2001, Ralf Baechle wrote: > On Fri, Jun 01, 2001 at 03:15:44PM +0200, Kristoffer Gleditsch wrote: > > We got our hands on a Challenge S the other day. We're planning to > > install Linux on it and let it do something useful, but we don't have > > any use for the SCSI adapter. If anyone out there are working on > > Linux drivers for these cards, we'd be happy to let them have it. If > > anyone is interested, send me a mail. > > Currently there is no ongoing driver work for the WD33C95 secondary SCSI > hostadapter in Challenge S and other SGI systems. I have a Challenge S machine, and I'm interested in support for the other function of its GIO64 expansion card; the secondary Ethernet port, known as ec3 under Irix. Has anyone looked at getting that to work under Linux? I would like to use the machine as a router. From owner-linux-mips@oss.sgi.com Sun Jun 3 06:47:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53DlHL24314 for linux-mips-outgoing; Sun, 3 Jun 2001 06:47:17 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53DlFh24311 for ; Sun, 3 Jun 2001 06:47:16 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id B6F987FE; Sun, 3 Jun 2001 15:47:13 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C9C5642D1; Sun, 3 Jun 2001 15:47:07 +0200 (CEST) Date: Sun, 3 Jun 2001 15:47:07 +0200 From: Florian Lohoff To: Geert Uytterhoeven Cc: Linux/MIPS Development Subject: Re: wd33c93 question Message-ID: <20010603154706.D4043@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from geert@linux-m68k.org on Sat, Jun 02, 2001 at 07:07:46PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Jun 02, 2001 at 07:07:46PM +0200, Geert Uytterhoeven wrote: > Hi, > > Anyone who can explain these changes? Here the MIPS tree differs from Linus' > (and the m68k) tree. > > According to the CVS logs, this change entered in revision 1.7 due to a sync > with Linus' tree (which introduced other formatting changes) somewhere in 1998. > In Linus' tree it must have changed afterwards a long time ago (before 2.2.0). > > --- linux-2.4.5/drivers/scsi/wd33c93.c Tue Dec 5 21:43:48 2000 > +++ linux-mips/drivers/scsi/wd33c93.c Mon Mar 26 02:38:20 2001 > @@ -614,7 +614,6 @@ > (is_dir_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR)) > write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ > else { > - write_wd33c93_count(regp, cmd->SCp.this_residual); > write_wd33c93(regp,WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); > hostdata->dma = D_DMA_RUNNING; > } > @@ -735,7 +734,6 @@ > hostdata->dma_cnt++; > #endif > write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); > - write_wd33c93_count(regp,cmd->SCp.this_residual); > > if ((hostdata->level2 >= L2_DATA) || > (hostdata->level2 == L2_BASIC && cmd->SCp.phase == 0)) { I guess this is due to the fact that the HPC on the Indy/Indigo2 does the scatter gather alread so we let the HPC DMA controller do the scatter gather and just let the SCSI controller run the whole request. The corresponding codelines should be in drivers/scsi/sgiwd93.c 113 if(cmd->SCp.buffers_residual) { 114 struct scatterlist *slp = cmd->SCp.buffer; 115 int i, totlen = 0; 116 117 #ifdef DEBUG_DMA 118 printk("SCLIST<"); 119 #endif 120 for(i = 0; i <= cmd->SCp.buffers_residual; i++) { 121 #ifdef DEBUG_DMA 122 printk("[%p,%d]", slp[i].address, slp[i].length); 123 #endif 124 fill_hpc_entries (&hcp, slp[i].address, slp[i].length); 125 totlen += slp[i].length; 126 } 127 #ifdef DEBUG_DMA 128 printk(">tlen<%d>", totlen); 129 #endif 130 hdata->dma_bounce_len = totlen; /* a trick... */ 131 write_wd33c93_count(regp, totlen); 132 } else { 133 /* Non-scattered dma. */ 134 #ifdef DEBUG_DMA 135 printk("ONEBUF<%p,%d>", cmd->SCp.ptr, cmd->SCp.this_residual); 136 #endif 137 /* 138 * wd33c93 shouldn't pass us bogus dma_setups, but 139 * it does:-( The other wd33c93 drivers deal with 140 * it the same way (which isn't that obvious). 141 * IMHO a better fix would be, not to do these 142 * dma setups in the first place 143 */ 144 if (cmd->SCp.ptr == NULL) 145 return 1; 146 fill_hpc_entries (&hcp, cmd->SCp.ptr,cmd->SCp.this_residual); 147 write_wd33c93_count(regp, cmd->SCp.this_residual); 148 } So we have an incompatibility with the sgiwd93.c from the mips tree and the wd33c93.c from the linus tree where we dont want the generic part of the wd33c93.c to (re)write the length of the current transfer block (scatter gather part) as we want it to do the whole transfer in one part (From the generic wd33c93.c we dont do scatter gather). 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 Jun 4 02:36:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f549aV127224 for linux-mips-outgoing; Mon, 4 Jun 2001 02:36:31 -0700 Received: from hood.tvd.be (hood.tvd.be [195.162.196.21]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f549aUh27216 for ; Mon, 4 Jun 2001 02:36:30 -0700 Received: from callisto.of.borg (cable-195-162-217-46.upc.chello.be [195.162.217.46]) by hood.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id LAA09404; Mon, 4 Jun 2001 11:36:28 +0200 (MET DST) Received: from localhost (geert@localhost) by callisto.of.borg (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA28417; Mon, 4 Jun 2001 11:34:14 +0200 X-Authentication-Warning: callisto.of.borg: geert owned process doing -bs Date: Mon, 4 Jun 2001 11:34:14 +0200 (CEST) From: Geert Uytterhoeven To: Florian Lohoff cc: Linux/MIPS Development Subject: Re: wd33c93 question In-Reply-To: <20010603154706.D4043@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, 3 Jun 2001, Florian Lohoff wrote: > On Sat, Jun 02, 2001 at 07:07:46PM +0200, Geert Uytterhoeven wrote: > > Anyone who can explain these changes? Here the MIPS tree differs from Linus' > > (and the m68k) tree. > > > > According to the CVS logs, this change entered in revision 1.7 due to a sync > > with Linus' tree (which introduced other formatting changes) somewhere in 1998. > > In Linus' tree it must have changed afterwards a long time ago (before 2.2.0). > > > > --- linux-2.4.5/drivers/scsi/wd33c93.c Tue Dec 5 21:43:48 2000 > > +++ linux-mips/drivers/scsi/wd33c93.c Mon Mar 26 02:38:20 2001 > > @@ -614,7 +614,6 @@ > > (is_dir_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR)) > > write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */ > > else { > > - write_wd33c93_count(regp, cmd->SCp.this_residual); > > write_wd33c93(regp,WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); > > hostdata->dma = D_DMA_RUNNING; > > } > > @@ -735,7 +734,6 @@ > > hostdata->dma_cnt++; > > #endif > > write_wd33c93(regp, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_DMA); > > - write_wd33c93_count(regp,cmd->SCp.this_residual); > > > > if ((hostdata->level2 >= L2_DATA) || > > (hostdata->level2 == L2_BASIC && cmd->SCp.phase == 0)) { > > I guess this is due to the fact that the HPC on the Indy/Indigo2 does > the scatter gather alread so we let the HPC DMA controller do the scatter > gather and just let the SCSI controller run the whole request. > > The corresponding codelines should be in > > drivers/scsi/sgiwd93.c [...] > So we have an incompatibility with the sgiwd93.c from the mips tree > and the wd33c93.c from the linus tree where we dont want the generic part > of the wd33c93.c to (re)write the length of the current transfer block > (scatter gather part) as we want it to do the whole transfer in one > part (From the generic wd33c93.c we dont do scatter gather). So it's OK to protect the above lines using #ifndef CONFIG_SGIWD93_SCSI? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Jun 4 05:50:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Co6J25390 for linux-mips-outgoing; Mon, 4 Jun 2001 05:50:06 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Co4h25384 for ; Mon, 4 Jun 2001 05:50:04 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 0373D7FC; Mon, 4 Jun 2001 14:50:02 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3475242D1; Mon, 4 Jun 2001 14:34:09 +0200 (CEST) Date: Mon, 4 Jun 2001 14:34:09 +0200 From: Florian Lohoff To: Geert Uytterhoeven Cc: Linux/MIPS Development Subject: Re: wd33c93 question Message-ID: <20010604143409.A11675@paradigm.rfc822.org> References: <20010603154706.D4043@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from geert@linux-m68k.org on Mon, Jun 04, 2001 at 11:34:14AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jun 04, 2001 at 11:34:14AM +0200, Geert Uytterhoeven wrote: > > drivers/scsi/sgiwd93.c > > [...] > > > So we have an incompatibility with the sgiwd93.c from the mips tree > > and the wd33c93.c from the linus tree where we dont want the generic part > > of the wd33c93.c to (re)write the length of the current transfer block > > (scatter gather part) as we want it to do the whole transfer in one > > part (From the generic wd33c93.c we dont do scatter gather). > > So it's OK to protect the above lines using #ifndef CONFIG_SGIWD93_SCSI? I guess so - I will have a look if thats probably the cause of the fs corruption we see on SGIs with that scsi driver. From just guessing the order of setting the values is different on SGI. 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 Jun 4 10:29:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54HTaK11612 for linux-mips-outgoing; Mon, 4 Jun 2001 10:29:36 -0700 Received: from mail.palmchip.com ([63.203.52.8]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54HTXh11608 for ; Mon, 4 Jun 2001 10:29:35 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.9.3) with ESMTP id f54HTSc07776 for ; Mon, 4 Jun 2001 10:29:28 -0700 Message-ID: <3B1BC6B8.C58758FA@palmchip.com> Date: Mon, 04 Jun 2001 10:34:48 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: dcache_blast() bug? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I'm seeing some odd memory behavior around the time when blast_dcache() is called, leading me to think that the method may be a little buggy. It appears that memory is being corrupted (consistently so) over the course of flushing the dcache. This happens to my command line argument string - arcs_cmdline. Before the blast_dcache() call, it is "console=ttyS0 ramdisk_start=0x9fcf0000 load_ramdisk=1", and after the call, the corrupted data is "ttyS0 ra0". I take it this isn't supposed to happen? any ideas of why the writeback_invalidate_d cache operation may be losing data? thanks, -ian -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Mon Jun 4 10:48:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54HmJs12070 for linux-mips-outgoing; Mon, 4 Jun 2001 10:48:19 -0700 Received: from web11904.mail.yahoo.com (web11904.mail.yahoo.com [216.136.172.188]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54HmIh12067 for ; Mon, 4 Jun 2001 10:48:18 -0700 Message-ID: <20010604174818.41079.qmail@web11904.mail.yahoo.com> Received: from [209.243.184.191] by web11904.mail.yahoo.com; Mon, 04 Jun 2001 10:48:18 PDT Date: Mon, 4 Jun 2001 10:48:18 -0700 (PDT) From: Wayne Gowcher Subject: Native compile on the target using RedHat 6.1 rpms To: linux-mips@oss.sgi.com In-Reply-To: <200106012135.PAA16955@home.knm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dear All, I am trying to native compile for mipsel-linux using the declinuxroot tar file as my NFS and egcs-1.0.3a-1 as my compiler, glibc-2.0.6-5lm as my libraries as suggested by the README file in oss.sgi.com/pub/linux/mips/mipsel-linux/README. But when I try to compile I get the following error : /usr/bin/ld: /tmp/cca003091.o: uses different e_flags (0x102) fields than previous modules (0x2) Bad value: failed to merge target specific data of file /tmp/cca003091.o collect2: ld returned 1 exit status make: *** [pointer] Error 1 When I compile the same program using the RedHat 5.1 rpms / nfs the program compiles to completion OK. Anybody seen this before ? Any ideas what I am doing wrong ? missed out ? Any help appreciated. Wayne __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jun 4 12:14:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54JEXO21968 for linux-mips-outgoing; Mon, 4 Jun 2001 12:14:33 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54JEWh21961 for ; Mon, 4 Jun 2001 12:14:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA24548; Mon, 4 Jun 2001 12:14:20 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id MAA03815; Mon, 4 Jun 2001 12:14:17 -0700 (PDT) Message-ID: <02a901c0ed2b$2eac6300$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ian Thompson" , References: <3B1BC6B8.C58758FA@palmchip.com> Subject: Re: dcache_blast() bug? Date: Mon, 4 Jun 2001 21:18:39 +0200 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 What processor are you running? Kevin K. ----- Original Message ----- From: "Ian Thompson" To: Sent: Monday, June 04, 2001 7:34 PM Subject: dcache_blast() bug? > > Hi all, > > I'm seeing some odd memory behavior around the time when blast_dcache() > is called, leading me to think that the method may be a little buggy. > It appears that memory is being corrupted (consistently so) over the > course of flushing the dcache. This happens to my command line argument > string - arcs_cmdline. Before the blast_dcache() call, it is > "console=ttyS0 ramdisk_start=0x9fcf0000 load_ramdisk=1", and after the > call, the corrupted data is "ttyS0 ra0". I take it this isn't supposed > to happen? any ideas of why the writeback_invalidate_d cache operation > may be losing data? > > thanks, > -ian > > > -- > ---------------------------------------- > Ian Thompson tel: 408.952.2023 > Firmware Engineer fax: 408.570.0910 > Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Mon Jun 4 12:20:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54JK2423157 for linux-mips-outgoing; Mon, 4 Jun 2001 12:20:02 -0700 Received: from web11906.mail.yahoo.com (web11906.mail.yahoo.com [216.136.172.190]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54JK2h23154 for ; Mon, 4 Jun 2001 12:20:02 -0700 Message-ID: <20010604192001.22785.qmail@web11906.mail.yahoo.com> Received: from [209.243.184.191] by web11906.mail.yahoo.com; Mon, 04 Jun 2001 12:20:01 PDT Date: Mon, 4 Jun 2001 12:20:01 -0700 (PDT) From: Wayne Gowcher Subject: Re: Native compile on the target using RedHat 6.1 rpms - Update To: linux-mips@oss.sgi.com In-Reply-To: <20010604174818.41079.qmail@web11904.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I found out what was breaking the compile : I was setting -mcpu=r4600 -mips2. If I leave this off everything compiles OK, but now the code isn't optimized for the processor and does run slower ( of course). I also noted that if I use : -mcpu=r4000 -mips2 I get the error : /usr/bin/ld: /tmp/cca007591.o: ISA mismatch (-mips3) with previous modules (-mips1) /usr/bin/ld: /tmp/cca007591.o: uses different e_flags (0x102) fields than previous modules (0x2) Bad value: failed to merge target specific data of file /tmp/cca007591.o collect2: ld returned 1 exit status Which I totally don't understand because I never set mips3 I set mips2. I am coming to the conclusion that : the egcs-1.03a compiler as found on the sgi web site only supports mips 1. Can someone confirm or deny this ? If that is so, how does anyone compile native mips2 code ? You have to build your own compiler / libraries ? If anyone has / knows of an egcs-1.03a or higher compiler capapble of compiling mips2 I'd really like to hear from them. TIA Wayne __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jun 4 13:22:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54KMdM00593 for linux-mips-outgoing; Mon, 4 Jun 2001 13:22:39 -0700 Received: from mail.palmchip.com ([63.203.52.8]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54KMch00589 for ; Mon, 4 Jun 2001 13:22:38 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.9.3) with ESMTP id f54KMVc06899; Mon, 4 Jun 2001 13:22:31 -0700 Message-ID: <3B1BEF48.AB0E568C@palmchip.com> Date: Mon, 04 Jun 2001 13:27:52 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: dcache_blast() bug? References: <3B1BC6B8.C58758FA@palmchip.com> <02a901c0ed2b$2eac6300$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk oops sorry i meant to mention that. running a mips 4kc. "Kevin D. Kissell" wrote: > > What processor are you running? > > Kevin K. > > ----- Original Message ----- > From: "Ian Thompson" > To: > Sent: Monday, June 04, 2001 7:34 PM > Subject: dcache_blast() bug? > > > > > Hi all, > > > > I'm seeing some odd memory behavior around the time when blast_dcache() > > is called, leading me to think that the method may be a little buggy. > > It appears that memory is being corrupted (consistently so) over the > > course of flushing the dcache. This happens to my command line argument > > string - arcs_cmdline. Before the blast_dcache() call, it is > > "console=ttyS0 ramdisk_start=0x9fcf0000 load_ramdisk=1", and after the > > call, the corrupted data is "ttyS0 ra0". I take it this isn't supposed > > to happen? any ideas of why the writeback_invalidate_d cache operation > > may be losing data? > > > > thanks, > > -ian > > > > > > -- > > ---------------------------------------- > > Ian Thompson tel: 408.952.2023 > > Firmware Engineer fax: 408.570.0910 > > Palmchip Corporation www.palmchip.com -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Mon Jun 4 13:29:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54KT5Q01838 for linux-mips-outgoing; Mon, 4 Jun 2001 13:29:05 -0700 Received: from dea.waldorf-gmbh.de (u-99-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.99]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54KT1h01820 for ; Mon, 4 Jun 2001 13:29:02 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f54KSow27672; Mon, 4 Jun 2001 22:28:50 +0200 Date: Mon, 4 Jun 2001 22:28:50 +0200 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Native compile on the target using RedHat 6.1 rpms Message-ID: <20010604222850.B22903@bacchus.dhis.org> References: <200106012135.PAA16955@home.knm.org> <20010604174818.41079.qmail@web11904.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604174818.41079.qmail@web11904.mail.yahoo.com>; from wgowcher@yahoo.com on Mon, Jun 04, 2001 at 10:48:18AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jun 04, 2001 at 10:48:18AM -0700, Wayne Gowcher wrote: > /usr/bin/ld: /tmp/cca003091.o: uses different e_flags > (0x102) fields than previous modules (0x2) > Bad value: failed to merge target specific data of > file /tmp/cca003091.o > collect2: ld returned 1 exit status > make: *** [pointer] Error 1 > > When I compile the same program using the RedHat 5.1 > rpms / nfs the program compiles to completion OK. > > Anybody seen this before ? > Any ideas what I am doing wrong ? missed out ? This is a bug in certain binutils versions which gets triggered by certain kernel configurations. Upgrade to newer binutils. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 4 13:37:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Kb8L03750 for linux-mips-outgoing; Mon, 4 Jun 2001 13:37:08 -0700 Received: from dea.waldorf-gmbh.de (u-99-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.99]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Kb2h03731 for ; Mon, 4 Jun 2001 13:37:02 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f54Kaq827701; Mon, 4 Jun 2001 22:36:52 +0200 Date: Mon, 4 Jun 2001 22:36:52 +0200 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Native compile on the target using RedHat 6.1 rpms - Update Message-ID: <20010604223652.C22903@bacchus.dhis.org> References: <20010604174818.41079.qmail@web11904.mail.yahoo.com> <20010604192001.22785.qmail@web11906.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604192001.22785.qmail@web11906.mail.yahoo.com>; from wgowcher@yahoo.com on Mon, Jun 04, 2001 at 12:20:01PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jun 04, 2001 at 12:20:01PM -0700, Wayne Gowcher wrote: > /usr/bin/ld: /tmp/cca007591.o: ISA mismatch (-mips3) > with previous modules (-mips1) > /usr/bin/ld: /tmp/cca007591.o: uses different e_flags > (0x102) fields than previous modules (0x2) > Bad value: failed to merge target specific data of > file /tmp/cca007591.o > collect2: ld returned 1 exit status > > Which I totally don't understand because I never set > mips3 I set mips2. The source itself sets the assembler to mips3 mode. > I am coming to the conclusion that : > > the egcs-1.03a compiler as found on the sgi web site > only supports mips 1. Wrong. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 4 13:53:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54KrYK07554 for linux-mips-outgoing; Mon, 4 Jun 2001 13:53:34 -0700 Received: from web11901.mail.yahoo.com (web11901.mail.yahoo.com [216.136.172.185]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54KrXh07550 for ; Mon, 4 Jun 2001 13:53:33 -0700 Message-ID: <20010604205333.8499.qmail@web11901.mail.yahoo.com> Received: from [209.243.184.191] by web11901.mail.yahoo.com; Mon, 04 Jun 2001 13:53:33 PDT Date: Mon, 4 Jun 2001 13:53:33 -0700 (PDT) From: Wayne Gowcher Subject: Re: Native compile on the target using RedHat 6.1 rpms - Update To: Ralf Baechle Cc: linux-mips@oss.sgi.com In-Reply-To: <20010604223652.C22903@bacchus.dhis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf, Thanks for the reply. I was using binutils found in ftp://oss.sgi.com/pub/linux/mips/mipsel-linux/RedHat-6.1/RPMS/mipsel/ version is 2.10.91-1lm.mipsel.rpm Do you have a rpm neweer than this or know where I may get one ? TIA Wayne __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jun 4 14:17:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54LHMe12069 for linux-mips-outgoing; Mon, 4 Jun 2001 14:17:22 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54LHLh12065 for ; Mon, 4 Jun 2001 14:17:21 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA26172; Mon, 4 Jun 2001 14:17:14 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA07844; Mon, 4 Jun 2001 14:17:11 -0700 (PDT) Message-ID: <033701c0ed3c$59ccf980$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ian Thompson" Cc: References: <3B1BC6B8.C58758FA@palmchip.com> <02a901c0ed2b$2eac6300$0deca8c0@Ulysses> <3B1BEF48.AB0E568C@palmchip.com> Subject: Re: dcache_blast() bug? Date: Mon, 4 Jun 2001 23:21:40 +0200 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 Interesting, in that the 4Kc has write-through caches, which make it a good deal more difficult to get into the kind of trouble you describe. Are you running one of the 4Kc "lead vehicle" chips, or some other part? Which version of the kernel are you running, and are the CPU type and cache organization being reported correctly during boot-up? The output you report from dumping the command line sounds is interesting. The corruption seems to be in 8-byte chunks - the first 8 have disappeared, as has the third 8. Lord knows where the "0" in "ra0" comes from. Can you confirm that (a) the command line string is stored at an 8-byte aligned boundary, and (b) whether the data is actually being moved, or if the missing characters are simply being replaced with nulls or other non-printable characters? I know it's not pretty, but can you dump the same memory addresses as seen through non-cacheable kseg1 (0xa0000000-0xbfffffff), and are the cache and memory consistent? If the failure is happening on 8-byte, doubleword aligned chunks, I suspect a hardware problem more than a kernel bug. If it were my system, I'd re-seat the RAM and CPU modules to make sure I'm not simply getting screwed by a bad connection when the memory interface suddenly gets hit with a lot of traffic following the flush. Kevin K. ----- Original Message ----- From: "Ian Thompson" To: "Kevin D. Kissell" Cc: Sent: Monday, June 04, 2001 10:27 PM Subject: Re: dcache_blast() bug? > oops sorry i meant to mention that. running a mips 4kc. > > > > "Kevin D. Kissell" wrote: > > > > What processor are you running? > > > > Kevin K. > > > > ----- Original Message ----- > > From: "Ian Thompson" > > To: > > Sent: Monday, June 04, 2001 7:34 PM > > Subject: dcache_blast() bug? > > > > > > > > Hi all, > > > > > > I'm seeing some odd memory behavior around the time when blast_dcache() > > > is called, leading me to think that the method may be a little buggy. > > > It appears that memory is being corrupted (consistently so) over the > > > course of flushing the dcache. This happens to my command line argument > > > string - arcs_cmdline. Before the blast_dcache() call, it is > > > "console=ttyS0 ramdisk_start=0x9fcf0000 load_ramdisk=1", and after the > > > call, the corrupted data is "ttyS0 ra0". I take it this isn't supposed > > > to happen? any ideas of why the writeback_invalidate_d cache operation > > > may be losing data? > > > > > > thanks, > > > -ian > > > > > > > > > -- > > > ---------------------------------------- > > > Ian Thompson tel: 408.952.2023 > > > Firmware Engineer fax: 408.570.0910 > > > Palmchip Corporation www.palmchip.com > > -- > ---------------------------------------- > Ian Thompson tel: 408.952.2023 > Firmware Engineer fax: 408.570.0910 > Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Mon Jun 4 14:58:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54LwA419446 for linux-mips-outgoing; Mon, 4 Jun 2001 14:58:10 -0700 Received: from dea.waldorf-gmbh.de (u-99-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.99]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Lw3h19422 for ; Mon, 4 Jun 2001 14:58:04 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f54LshF28007; Mon, 4 Jun 2001 23:54:43 +0200 Date: Mon, 4 Jun 2001 23:54:43 +0200 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Native compile on the target using RedHat 6.1 rpms - Update Message-ID: <20010604235443.A27996@bacchus.dhis.org> References: <20010604223652.C22903@bacchus.dhis.org> <20010604205333.8499.qmail@web11901.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604205333.8499.qmail@web11901.mail.yahoo.com>; from wgowcher@yahoo.com on Mon, Jun 04, 2001 at 01:53:33PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jun 04, 2001 at 01:53:33PM -0700, Wayne Gowcher wrote: > I was using binutils found in > ftp://oss.sgi.com/pub/linux/mips/mipsel-linux/RedHat-6.1/RPMS/mipsel/ > > version is 2.10.91-1lm.mipsel.rpm > > Do you have a rpm neweer than this or know where I may > get one ? There is one in the Redhat 7.0 directory. I think we only have big endian binaries, so you may have to build little endian binaries yourself. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 4 16:28:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54NS0I32370 for linux-mips-outgoing; Mon, 4 Jun 2001 16:28:00 -0700 Received: from mail.palmchip.com ([63.203.52.8]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54NRwh32367 for ; Mon, 4 Jun 2001 16:27:58 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.9.3) with ESMTP id f54NRfc15265; Mon, 4 Jun 2001 16:27:41 -0700 Message-ID: <3B1C1AAD.3A62D636@palmchip.com> Date: Mon, 04 Jun 2001 16:33:01 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: dcache_blast() bug? References: <3B1BC6B8.C58758FA@palmchip.com> <02a901c0ed2b$2eac6300$0deca8c0@Ulysses> <3B1BEF48.AB0E568C@palmchip.com> <033701c0ed3c$59ccf980$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks for your help Kevin. It may be possible that this is a hardware bug. I am using one of the lead vehicle chips with 16k d$ & i$, although there is some custom hardware which may be causing trouble as well. Oh, and this is the 2.4.1 kernel. It appears that when I copy the arguments into the command line variable, they are 8-byte aligned, and the destination is also 8-byte aligned. However, there is an inconsistency between the data in the cache and in memory after the blast_dcache() call. Could it also be possible that the cache write buffer is not quite empty, and the data in it is being lost on the blast call? Should some implementation of wbflush be called before the cache ops are done? I just wanted to see if this could be a problem before I start trying to track down bugs in hardware... Thanks, -ian "Kevin D. Kissell" wrote: > > Interesting, in that the 4Kc has write-through caches, > which make it a good deal more difficult to get into > the kind of trouble you describe. Are you running one > of the 4Kc "lead vehicle" chips, or some other part? > Which version of the kernel are you running, and are > the CPU type and cache organization being reported > correctly during boot-up? > > The output you report from dumping the command line > sounds is interesting. The corruption seems to be in > 8-byte chunks - the first 8 have disappeared, as has > the third 8. Lord knows where the "0" in "ra0" comes > from. Can you confirm that (a) the command line string > is stored at an 8-byte aligned boundary, and (b) whether > the data is actually being moved, or if the missing > characters are simply being replaced with nulls or other > non-printable characters? I know it's not pretty, but > can you dump the same memory addresses as seen > through non-cacheable kseg1 (0xa0000000-0xbfffffff), > and are the cache and memory consistent? > > If the failure is happening on 8-byte, doubleword aligned > chunks, I suspect a hardware problem more than a > kernel bug. If it were my system, I'd re-seat the RAM > and CPU modules to make sure I'm not simply getting > screwed by a bad connection when the memory interface > suddenly gets hit with a lot of traffic following the flush. > > Kevin K. > > ----- Original Message ----- > From: "Ian Thompson" > To: "Kevin D. Kissell" > Cc: > Sent: Monday, June 04, 2001 10:27 PM > Subject: Re: dcache_blast() bug? > > > oops sorry i meant to mention that. running a mips 4kc. > > > > > > > > "Kevin D. Kissell" wrote: > > > > > > What processor are you running? > > > > > > Kevin K. > > > > > > ----- Original Message ----- > > > From: "Ian Thompson" > > > To: > > > Sent: Monday, June 04, 2001 7:34 PM > > > Subject: dcache_blast() bug? > > > > > > > > > > > Hi all, > > > > > > > > I'm seeing some odd memory behavior around the time when > blast_dcache() > > > > is called, leading me to think that the method may be a little buggy. > > > > It appears that memory is being corrupted (consistently so) over the > > > > course of flushing the dcache. This happens to my command line > argument > > > > string - arcs_cmdline. Before the blast_dcache() call, it is > > > > "console=ttyS0 ramdisk_start=0x9fcf0000 load_ramdisk=1", and after the > > > > call, the corrupted data is "ttyS0 ra0". I take it this isn't > supposed > > > > to happen? any ideas of why the writeback_invalidate_d cache > operation > > > > may be losing data? > > > > > > > > thanks, > > > > -ian > > > > > > > > > > > > -- > > > > ---------------------------------------- > > > > Ian Thompson tel: 408.952.2023 > > > > Firmware Engineer fax: 408.570.0910 > > > > Palmchip Corporation www.palmchip.com > > > > -- > > ---------------------------------------- > > Ian Thompson tel: 408.952.2023 > > Firmware Engineer fax: 408.570.0910 > > Palmchip Corporation www.palmchip.com -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com From owner-linux-mips@oss.sgi.com Tue Jun 5 01:46:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f558kZ126398 for linux-mips-outgoing; Tue, 5 Jun 2001 01:46:35 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f558kXh26388 for ; Tue, 5 Jun 2001 01:46:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA02128; Tue, 5 Jun 2001 01:46:26 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA25200; Tue, 5 Jun 2001 01:46:23 -0700 (PDT) Message-ID: <005401c0ed9c$a2ce8b20$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ian Thompson" Cc: References: <3B1BC6B8.C58758FA@palmchip.com> <02a901c0ed2b$2eac6300$0deca8c0@Ulysses> <3B1BEF48.AB0E568C@palmchip.com> <033701c0ed3c$59ccf980$0deca8c0@Ulysses> <3B1C1AAD.3A62D636@palmchip.com> Subject: Re: dcache_blast() bug? Date: Tue, 5 Jun 2001 10:50:47 +0200 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 > Thanks for your help Kevin. It may be possible that this is a hardware > bug. I am using one of the lead vehicle chips with 16k d$ & i$, > although there is some custom hardware which may be causing trouble as > well. Oh, and this is the 2.4.1 kernel. I'm also running a 4Kc lead vehicle, on a MIPS Malta board, with the 2.4.1 kernel, run the system moderately hard, and have never seen any behavior like that you describle. > It appears that when I copy the arguments into the command line > variable, they are 8-byte aligned, and the destination is also 8-byte > aligned. However, there is an inconsistency between the data in the > cache and in memory after the blast_dcache() call. Am I correct in taking this to mean that the contents of memory is correct, but that the cache is in error when you read the data back in cacheable space? That suggests that writes are working fine, but that either the blast_dcache() isn't correctly clearing the tags, or the refill from memory is getting trashed on the way to the cache. The former could result from misbehavior in the 4Kc lead vehicle chip itself (possibly provoked by some kind of marginal clock or power supply input), the later could result from any one of several problems in the path between the RAM array and the lead vehicle cache. I favor the later theory. See below. > Could it also be > possible that the cache write buffer is not quite empty, and the data in > it is being lost on the blast call? I know of no software mechanism that will cause the contents of the write buffer to be lost. I think a bus error indication from the system might cause it to be thrown away, but that's about it. The SYNC instruction forces its contents to be written to memory, not discarded. > Should some implementation of > wbflush be called before the cache ops are done? The write buffers are part of the BIU which is on the "far side" of the cache. Since the cache in write-through, the cache operations should not result in any interaction with the write buffer at all - the cache tags should get invalidated, and that's all. The reason that the 8-byte granularity of error suggests a hardware problem at the memory interface is that, while writes to memory will be 1, 2, or 4 bytes (byte, halfword, and word stores), and the cache line size and write buffer size are both 16 bytes, the 4Kc lead vehicle has a 64-bit memory interface, and reads 8 bytes at a time when doing cache fills. A botched RAM cycle during a cache fill would cause 8-byte blocks within the 16-byte cache lines to be trashed - which seems to be exactly what you are seeing. I strongly suggest that you double check all mechanical connections (CPU socket and memory slots), and if that doesn't help, check your RAM timing, your supply voltage, and the symmetry and cleanliness of your clocks. It sounds like the problem is highly reproducable, so a next step might be to stick a logic analyser on the CPU/Memory interface and watch the fill operation on the address, following the flush. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jun 5 02:32:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f559W9x01389 for linux-mips-outgoing; Tue, 5 Jun 2001 02:32:09 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f559W4h01370; Tue, 5 Jun 2001 02:32:04 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id LAB04422; Tue, 5 Jun 2001 11:32:01 +0200 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16285; Tue, 5 Jun 2001 09:50:07 +0200 (MET DST) Message-Id: <200106050750.JAA16285@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Ralf Baechle cc: Wayne Gowcher , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: Native compile on the target using RedHat 6.1 rpms - Update In-reply-to: Your message of "Mon, 04 Jun 2001 23:54:43 +0200." <20010604235443.A27996@bacchus.dhis.org> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jun 2001 09:50:06 +0200 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Mon, Jun 04, 2001 at 01:53:33PM -0700, Wayne Gowcher wrote: > > > I was using binutils found in > > ftp://oss.sgi.com/pub/linux/mips/mipsel-linux/RedHat-6.1/RPMS/mipsel/ > > > > version is 2.10.91-1lm.mipsel.rpm > > > > Do you have a rpm neweer than this or know where I may > > get one ? > > There is one in the Redhat 7.0 directory. I think we only have big endian > binaries, so you may have to build little endian binaries yourself. > I have my RH 7.0 mipsel (glibc 2.2 based) set nearly ready. Should I upload what I have for now? Regards, Karel. -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Tue Jun 5 06:22:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55DMd009532 for linux-mips-outgoing; Tue, 5 Jun 2001 06:22:39 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55DL0h09297 for ; Tue, 5 Jun 2001 06:21:02 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA20513; Tue, 5 Jun 2001 14:58:53 +0200 (MET DST) Date: Tue, 5 Jun 2001 14:58:52 +0200 (MET DST) From: "Maciej W. Rozycki" To: Andreas Jaeger cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration 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 Hi, This version should be better. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + glibc-2.2.3-mips-tas.patch diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/kernel-features.h glibc-2.2.3/sysdeps/unix/sysv/linux/kernel-features.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/kernel-features.h Wed Apr 25 21:51:14 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/kernel-features.h Thu May 31 15:54:59 2001 @@ -182,3 +182,8 @@ # define __ASSUME_FCNTL64 1 # define __ASSUME_GETDENTS64_SYSCALL 1 #endif + +/* The _test_and_set syscall is available on MIPS since 2.?.?. */ +#if 0 && defined __mips__ +# define __ASSUME__TEST_AND_SET 1 +#endif diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c Fri Jul 28 13:37:25 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c Sat Jun 2 13:04:35 2001 @@ -1,4 +1,4 @@ -/* Copyright (C) 2000 Free Software Foundation, Inc. +/* Copyright (C) 2000, 2001 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Maciej W. Rozycki , 2000. @@ -21,6 +21,12 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include + +#include "kernel-features.h" #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES @@ -28,3 +34,45 @@ #endif #include "sys/tas.h" + +#if (_MIPS_ISA < _MIPS_ISA_MIPS2) + +#if defined __NR__test_and_set && __ASSUME__TEST_AND_SET == 0 +static int __have_no__test_and_set; +#endif + +int _test_and_set (int *p, int v) +{ +#ifdef __NR__test_and_set +# if __ASSUME__TEST_AND_SET == 0 + if (!__builtin_expect(__have_no__test_and_set, 0)) +# endif + { + register int *__p asm ("$4") = p; + register int __v asm ("$5") = v; + register int __n asm ("$2") = SYS_ify (_test_and_set); + register int __e asm ("$7"); + register int __r asm ("$3"); + + asm ("syscall" + : "=r" (__r), "=r" (__e) + : "r" (__p), "r" (__v), "r" (__n) + : "$2", + "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", + "memory"); +# if __ASSUME__TEST_AND_SET > 0 + return __r; +# else + if (!__builtin_expect(__e, 0)) + return __r; + + __have_no__test_and_set = 1; +# endif + } +#endif /* __NR__test_and_set */ +#if !defined __NR__test_and_set || __ASSUME__TEST_AND_SET == 0 + return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); +#endif +} + +#endif /* _MIPS_ISA < _MIPS_ISA_MIPS2 */ diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h Sun Jan 7 04:35:41 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h Sat Jun 2 13:44:12 2001 @@ -1,4 +1,4 @@ -/* Copyright (C) 2000 Free Software Foundation, Inc. +/* Copyright (C) 2000, 2001 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Maciej W. Rozycki , 2000. @@ -22,7 +22,6 @@ #include #include -#include __BEGIN_DECLS @@ -59,15 +58,7 @@ _test_and_set (int *p, int v) __THROW return r; } -# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -_EXTERN_INLINE int -_test_and_set (int *p, int v) __THROW -{ - return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); -} - -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* __USE_EXTERN_INLINES */ From owner-linux-mips@oss.sgi.com Tue Jun 5 15:08:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55M8os10567 for linux-mips-outgoing; Tue, 5 Jun 2001 15:08:50 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55M8nh10563 for ; Tue, 5 Jun 2001 15:08:49 -0700 Received: from rjrtower (2093182197.weiderpub.com [209.3.182.197] (may be forged)) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f55M8iU03673 for ; Tue, 5 Jun 2001 15:08:44 -0700 Message-ID: <002e01c0ee0c$1572fed0$031010ac@rjrtower> From: "Robert Rusek" To: Subject: Newbie Question, Please help Date: Tue, 5 Jun 2001 15:08:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C0EDD1.68B40570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C0EDD1.68B40570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just got a SGI Challenge S. I need advice on which flavor of Linux I = should install, RedHat or Debian. Which is the better choice. I also = need to find out how to install this. I already attempted and failed to = install the RedHat 5.1. I am using a RedHat 7.0 box to do the install = (bootp/tftp/nfs) but I am not even able to get the setup to run. I am = using the latest version of DHCP/BOOTP (ics 2.0) to try to boot. It = gets the address then claims it is sending the vmlinux file via tftp. = On the SGI it just times out. Any advice, pointers, etc would be greatly appreciated. Thanks in advance, Robert Ruserk ------=_NextPart_000_002B_01C0EDD1.68B40570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just got a SGI Challenge S.  I = need advice=20 on which flavor of Linux I should install, RedHat or Debian.  Which = is the=20 better choice.  I also need to find out how to install this.  = I=20 already attempted and failed to install the RedHat 5.1.  I am using = a=20 RedHat 7.0 box to do the install (bootp/tftp/nfs) but I am not even able = to get=20 the setup to run.  I am using the latest version of DHCP/BOOTP (ics = 2.0) to=20 try to boot.  It gets the address then claims it is sending the = vmlinux=20 file via tftp.  On the SGI it just times out.
 
Any advice, pointers, etc would be = greatly=20 appreciated.
 
Thanks in advance,
Robert = Ruserk
------=_NextPart_000_002B_01C0EDD1.68B40570-- From owner-linux-mips@oss.sgi.com Tue Jun 5 15:50:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Monb17166 for linux-mips-outgoing; Tue, 5 Jun 2001 15:50:49 -0700 Received: from mailhost.taec.toshiba.com (mailhost.taec.com [209.243.128.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55MoRh17114; Tue, 5 Jun 2001 15:50:27 -0700 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 PAA07569; Tue, 5 Jun 2001 15:50:14 -0700 (PDT) Subject: Re: Newbie Question, Please help To: "Robert Rusek" Cc: linux-mips@oss.sgi.com, owner-linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Adrian.Hulse@taec.toshiba.com Date: Tue, 5 Jun 2001 15:24:11 -0700 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.5 |September 22, 2000) at 06/05/2001 03:49:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Robert, Maybe you've already tried this but. Do you know for sure that tftp works on your RedHat 7.0 box OK ? Can you use tftp to get files from directory /tftpboot ? When I installed RedHat 7.0 and tried to use tftp it wouldn't work. I think it comes with a rpm that is tftp-0.17-??.i386.rpm or something like that. To check your version type : rpm -q tftp According to bugzilla at the time you have to back install to tftp-0.16-5.i386.rpm. After doing this you will be able to use tftp. "Robert Rusek" > cc: Sent by: Subject: Newbie Question, Please help owner-linux-mips@o ss.sgi.com 06/05/01 03:08 PM the setup to run. I am using the latest version of DHCP/BOOTP (ics 2.0) to try to boot. It gets the address then claims it is sending the vmlinux file via tftp. On the SGI it just times out. Any advice, pointers, etc would be greatly appreciated. Thanks in advance, Robert Ruserk From owner-linux-mips@oss.sgi.com Tue Jun 5 16:48:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Nm9W25299 for linux-mips-outgoing; Tue, 5 Jun 2001 16:48:09 -0700 Received: from elaine27.Stanford.EDU (elaine27.Stanford.EDU [171.64.15.102]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Nm9h25296 for ; Tue, 5 Jun 2001 16:48:09 -0700 Received: (from johnd@localhost) by elaine27.Stanford.EDU (8.11.1/8.11.1) id f55Nlvq24854; Tue, 5 Jun 2001 16:47:57 -0700 (PDT) Date: Tue, 5 Jun 2001 16:47:57 -0700 (PDT) From: "John D. Davis" To: Robert Rusek cc: Subject: Re: Newbie Question, Please help In-Reply-To: <002e01c0ee0c$1572fed0$031010ac@rjrtower> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You should make sure that the vmlinux kernel is nfsroot configured. Check the config-* file for CONFIG_ROOT_NFS=y. Also read the nfsroot.txt in the cvs Documentation directory for more info. I found that getting the linux filesystem from a linux box works best. The major and minor nodes for the /dev directory are correct. Also, a useful installation page is located at: http://www.stafwag.f2s.com/indy/?lang=eng I found this helpful. john davis On Tue, 5 Jun 2001, Robert Rusek wrote: > I just got a SGI Challenge S. I need advice on which flavor of Linux I should install, RedHat or Debian. Which is the better choice. I also need to find out how to install this. I already attempted and failed to install the RedHat 5.1. I am using a RedHat 7.0 box to do the install (bootp/tftp/nfs) but I am not even able to get the setup to run. I am using the latest version of DHCP/BOOTP (ics 2.0) to try to boot. It gets the address then claims it is sending the vmlinux file via tftp. On the SGI it just times out. > > Any advice, pointers, etc would be greatly appreciated. > > Thanks in advance, > Robert Ruserk > From owner-linux-mips@oss.sgi.com Tue Jun 5 20:41:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f563fOv23592 for linux-mips-outgoing; Tue, 5 Jun 2001 20:41:24 -0700 Received: from dea.waldorf-gmbh.de (u-44-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.44]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f563fLh23586 for ; Tue, 5 Jun 2001 20:41:21 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f563ekj29581; Wed, 6 Jun 2001 05:40:46 +0200 Date: Wed, 6 Jun 2001 05:40:46 +0200 From: Ralf Baechle To: Adrian.Hulse@taec.toshiba.com Cc: Robert Rusek , linux-mips@oss.sgi.com Subject: Re: Newbie Question, Please help Message-ID: <20010606054046.A29567@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 Adrian.Hulse@taec.toshiba.com on Tue, Jun 05, 2001 at 03:24:11PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jun 05, 2001 at 03:24:11PM -0700, Adrian.Hulse@taec.toshiba.com wrote: > From: Adrian.Hulse@taec.toshiba.com > Subject: Re: Newbie Question, Please help > To: "Robert Rusek" > Cc: linux-mips@oss.sgi.com, owner-linux-mips@oss.sgi.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I wonder who is spreading the idea to send postings to the owner-linux-mips address? That address is only for contacting the listadmin and nothing else. Ralf From owner-linux-mips@oss.sgi.com Tue Jun 5 22:06:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56566R03342 for linux-mips-outgoing; Tue, 5 Jun 2001 22:06:06 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56565h03339 for ; Tue, 5 Jun 2001 22:06:05 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 524D6125BA; Tue, 5 Jun 2001 22:06:05 -0700 (PDT) Date: Tue, 5 Jun 2001 22:06:05 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: New toolchain for Linux/mips Message-ID: <20010605220605.A10997@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have a new toolchain for Linux/mips, which consists of gcc 2.96 and glibc 2.2 from RedHat 7.1 as well as my current binutils. I have used it to compile RedHat 7.1 to Linux/mipsel. I have built all RedHat 7.1 rpms necessary, except for X related, to boot up RedHat 7.1 on Linux/mipsel: # telnet xxxx ..... Escape character is '^]'. Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.3 on a mips login: My toolchain should be as capable as the x86 version in RedHat 7.1. But I do have 2 issues: 1. I got quite a few C++ exception execution failures from "make check" in gcc 2.96. But I got more C++ exception execution failures on IRIX 6.5. I guess the bugs are in gcc and/or binutils. 2. gdb in RedHat 7.1 has yet to be ported to mips. Without a working gdb, it is very hard to fix 1. I'd like to fold back my mips changes to gcc, glibc and binutils. Before I submit my changes, I'd like to get them checked out by the Linux/mips experts and users, especially on big endian mips. It will also be nice to have a working gdb and reliable C++ exception. Is there anyone interested in my new mips toolchain? Is there anyone interested in fixing gdb and C++ exception? H.J. From owner-linux-mips@oss.sgi.com Tue Jun 5 23:23:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f566N4h11969 for linux-mips-outgoing; Tue, 5 Jun 2001 23:23:04 -0700 Received: from dea.waldorf-gmbh.de (u-228-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.228]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f566N1h11959 for ; Tue, 5 Jun 2001 23:23:02 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f566MiT30296; Wed, 6 Jun 2001 08:22:44 +0200 Date: Wed, 6 Jun 2001 08:22:44 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606082243.B29567@bacchus.dhis.org> References: <20010605220605.A10997@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010605220605.A10997@lucon.org>; from hjl@lucon.org on Tue, Jun 05, 2001 at 10:06:05PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jun 05, 2001 at 10:06:05PM -0700, H . J . Lu wrote: > My toolchain should be as capable as the x86 version in RedHat 7.1. > But I do have 2 issues: > > 1. I got quite a few C++ exception execution failures from "make check" > in gcc 2.96. But I got more C++ exception execution failures on > IRIX 6.5. I guess the bugs are in gcc and/or binutils. > 2. gdb in RedHat 7.1 has yet to be ported to mips. Without a working > gdb, it is very hard to fix 1. > > I'd like to fold back my mips changes to gcc, glibc and binutils. > Before I submit my changes, I'd like to get them checked out by the > Linux/mips experts and users, especially on big endian mips. It will > also be nice to have a working gdb and reliable C++ exception. > > Is there anyone interested in my new mips toolchain? Definately. > Is there anyone interested in fixing gdb and C++ exception? We're definately interested and are painfully aware of shortcomings in those areas. Alone the limitation of days to just 48h so far has prevented us from fixing it. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 6 00:30:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f567UR420411 for linux-mips-outgoing; Wed, 6 Jun 2001 00:30:27 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f567UEh20373; Wed, 6 Jun 2001 00:30:15 -0700 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 JAA21329; Wed, 6 Jun 2001 09:30:02 +0200 (MET DST) Date: Wed, 6 Jun 2001 09:29:57 +0200 (MET DST) From: Geert Uytterhoeven To: Ralf Baechle cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606082243.B29567@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 On Wed, 6 Jun 2001, Ralf Baechle wrote: > We're definately interested and are painfully aware of shortcomings in > those areas. Alone the limitation of days to just 48h so far has prevented ^^^ > us from fixing it. You're a lucky guy! Wished mine were that long, too... :-) 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 Wed Jun 6 03:49:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56AnTW15978 for linux-mips-outgoing; Wed, 6 Jun 2001 03:49:29 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56An2h15908 for ; Wed, 6 Jun 2001 03:49:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA25049; Wed, 6 Jun 2001 12:44:04 +0200 (MET DST) Date: Wed, 6 Jun 2001 12:44:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010605220605.A10997@lucon.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 On Tue, 5 Jun 2001, H . J . Lu wrote: > 2. gdb in RedHat 7.1 has yet to be ported to mips. Without a working > gdb, it is very hard to fix 1. Gdb 5.0 works for me (and a few other people, I think). Check 'ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/gdb-5.0-6.src.rpm'. Most of the patches have been submitted. The only remaining one is the port of 4.17 changes from oss that needs copyright assignments from its authors. There might be a few insignificant issues remaining (I think "next" and "nexti" don't work properly), but this is the version of gdb that helped me very, very much to debug a few quirks in MIPS/Linux ld.so during glibc's 2.1.9x development stage. -- + 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 Jun 6 07:15:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56EFR818628 for linux-mips-outgoing; Wed, 6 Jun 2001 07:15:27 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56EFQh18624 for ; Wed, 6 Jun 2001 07:15:26 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 95815125BA; Wed, 6 Jun 2001 07:15:25 -0700 (PDT) Date: Wed, 6 Jun 2001 07:15:25 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606071525.A19423@lucon.org> References: <20010605220605.A10997@lucon.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 Wed, Jun 06, 2001 at 12:44:04PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 12:44:04PM +0200, Maciej W. Rozycki wrote: > On Tue, 5 Jun 2001, H . J . Lu wrote: > > > 2. gdb in RedHat 7.1 has yet to be ported to mips. Without a working > > gdb, it is very hard to fix 1. > > Gdb 5.0 works for me (and a few other people, I think). Check > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/gdb-5.0-6.src.rpm'. Most of the > patches have been submitted. The only remaining one is the port of 4.17 This is a very old gdb. Since gdb has changed a lot at the same time, if the patches haven't been installed, we may have to redo them. I'd like to see Linux/mips as a supported target in gdb. gdb in RedHat 7.1 is quite current. Also, my new toolchain uses stabs, not ecoff. It may need some work. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 09:02:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56G2MJ02842 for linux-mips-outgoing; Wed, 6 Jun 2001 09:02:22 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56G2Lh02837 for ; Wed, 6 Jun 2001 09:02:21 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 408EE125BC; Wed, 6 Jun 2001 09:02:20 -0700 (PDT) Date: Wed, 6 Jun 2001 09:02:20 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: ulfc@calypso.engr.sgi.com, linux-mips@oss.sgi.com Subject: An ELF patch for mips gas Message-ID: <20010606090220.A21351@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Who is the current maintainer for mips? Ulf Carlsson has not been responding for quite a while. I am working on toolchain for Linux/mips. I have quite a few patches and questions. Here is the first patch. It is needed to allow override global symbols in DSOs. Any objections? Thanks. H.J. ---- 2001-06-06 H.J. Lu * config/tc-mips.c (md_apply_fix): Don't adjust common extern/weak symbols for ELF. (md_estimate_size_before_relax): Treat weak like extern for ELF. (mips_fix_adjustable): Don't adjust extern/weak symbols for ELF. Index: config/tc-mips.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/tc-mips.c,v retrieving revision 1.37 diff -u -p -r1.37 tc-mips.c --- config/tc-mips.c 2001/05/23 18:36:05 1.37 +++ config/tc-mips.c 2001/06/06 15:52:59 @@ -9525,7 +9525,9 @@ md_apply_fix (fixP, valueP) if (fixP->fx_addsy != NULL && OUTPUT_FLAVOR == bfd_target_elf_flavour) { if (S_GET_OTHER (fixP->fx_addsy) == STO_MIPS16 - || S_IS_WEAK (fixP->fx_addsy) + || ((S_IS_WEAK (fixP->fx_addsy) + || S_IS_EXTERN (fixP->fx_addsy)) + && !S_IS_COMMON (fixP->fx_addsy)) || (symbol_used_in_reloc_p (fixP->fx_addsy) && (((bfd_get_section_flags (stdoutput, S_GET_SEGMENT (fixP->fx_addsy)) @@ -11032,8 +11034,8 @@ md_estimate_size_before_relax (fragp, se && ! bfd_is_com_section (symsec) && !linkonce #ifdef OBJ_ELF - /* A weak symbol is treated as external. */ - && ! S_IS_WEAK (sym) + /* A global or weak symbol is treated as external. */ + && ! (S_IS_EXTERN (sym) || S_IS_WEAK (sym)) #endif ); } @@ -11071,6 +11073,11 @@ int mips_fix_adjustable (fixp) fixS *fixp; { +#ifdef OBJ_ELF + /* Prevent all adjustments to global symbols. */ + if (S_IS_EXTERN (fixp->fx_addsy) || S_IS_WEAK (fixp->fx_addsy)) + return 0; +#endif if (fixp->fx_r_type == BFD_RELOC_MIPS16_JMP) return 0; if (fixp->fx_r_type == BFD_RELOC_VTABLE_INHERIT 2001-06-06 H.J. Lu * gas/testsuite/gas/mips/elf-jal.d: New file. * gas/testsuite/gas/mips/mips.exp: Run "elf-jal" instead of "jal" for ELF. Index: testsuite/gas/mips/mips.exp =================================================================== RCS file: /work/cvs/gnu/binutils/gas/testsuite/gas/mips/mips.exp,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 mips.exp --- testsuite/gas/mips/mips.exp 2001/05/25 19:07:01 1.1.1.8 +++ testsuite/gas/mips/mips.exp 2001/06/06 15:52:59 @@ -28,7 +28,11 @@ if { [istarget mips*-*-*] } then { run_dump_test "bltu" if !$ilocks { run_dump_test "div" } else { run_dump_test "div-ilocks" } run_dump_test "dli" - run_dump_test "jal" + if $svr4pic { + run_dump_test "elf-jal" + } else { + run_dump_test "jal" + } if $svr4pic { run_dump_test "jal-svr4pic" } if $svr4pic { run_dump_test "jal-xgot" } if $empic { run_dump_test "jal-empic" } --- /dev/null Fri Mar 23 20:37:44 2001 +++ testsuite/gas/mips/elf-jal.d Wed Jun 6 08:52:59 2001 @@ -0,0 +1,25 @@ +#objdump: -dr --prefix-addresses -mmips:4000 +#name: MIPS jal +#source: jal.s + +# Test the jal macro. + +.*: +file format .*mips.* + +Disassembly of section .text: +0+0000 <[^>]*> jalr t9 +0+0004 <[^>]*> nop +0+0008 <[^>]*> jalr a0,t9 +0+000c <[^>]*> nop +0+0010 <[^>]*> jal 0+ +[ ]*10: (MIPS_JMP|MIPS_JMP|JMPADDR|R_MIPS_26) text_label +0+0014 <[^>]*> nop +0+0018 <[^>]*> jal 0+ +[ ]*18: (MIPS_JMP|JMPADDR|R_MIPS_26) external_text_label +0+001c <[^>]*> nop +0+0020 <[^>]*> j 0+ +[ ]*20: (MIPS_JMP|JMPADDR|R_MIPS_26) text_label +0+0024 <[^>]*> nop +0+0028 <[^>]*> j 0+ +[ ]*28: (MIPS_JMP|JMPADDR|R_MIPS_26) external_text_label +0+002c <[^>]*> nop From owner-linux-mips@oss.sgi.com Wed Jun 6 09:08:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56G8It03220 for linux-mips-outgoing; Wed, 6 Jun 2001 09:08:18 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56G8Hh03217 for ; Wed, 6 Jun 2001 09:08:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 16335125BC; Wed, 6 Jun 2001 09:08:17 -0700 (PDT) Date: Wed, 6 Jun 2001 09:08:16 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606090816.C21351@lucon.org> References: <20010606071525.A19423@lucon.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 Wed, Jun 06, 2001 at 05:47:08PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 05:47:08PM +0200, Maciej W. Rozycki wrote: > > So the success ratio is 1/4 and for two trivial patches only -- not much > encouraging for me for further work, especially as what I have now works > for me quite well. Feel free to look at the stuff -- I might check it as > well, but I can't afford spending much time on it at the moment, sorry. There are many changes in gdb, especially in thread and C++ supports. We need those on mips also. I am willing to spend my time. But I need some help. I don't know much about mips :-(. I'd like to get gdb working first. Do you have time to answer some questions? Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 09:12:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56GCsx03522 for linux-mips-outgoing; Wed, 6 Jun 2001 09:12:54 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56GCrh03519 for ; Wed, 6 Jun 2001 09:12:53 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA06045 for ; Wed, 6 Jun 2001 09:01:53 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA05307; Wed, 6 Jun 2001 17:47:08 +0200 (MET DST) Date: Wed, 6 Jun 2001 17:47:08 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606071525.A19423@lucon.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 On Wed, 6 Jun 2001, H . J . Lu wrote: > > Gdb 5.0 works for me (and a few other people, I think). Check > > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/gdb-5.0-6.src.rpm'. Most of the > > patches have been submitted. The only remaining one is the port of 4.17 > > This is a very old gdb. Since gdb has changed a lot at the same > time, if the patches haven't been installed, we may have to redo them. If things were easy the patches would already have been installed. I submitted the ones I wrote myself a year ago -- they were current then. I believe most, if not all of them got applied. The oss one was not submitted as I had troubles finding out who were all the authors (my changes were rather cosmetic -- I tried to separate work into different patches). The patch is named "gdb-5.0-mips-linux.patch.gz" in my package. Finally I found out Dave Miller was the author of most of the patch (his name appears on a few files, but not all of them). Unfortunately, this was much, much later -- at the beginning of this year. The CVS of gdb changed meanwhile and my time constraints didn't allow me to check what needed to be updated. Therefore there was no point to bother Dave about a copyright assignment without updating the patch and making sure it'll get applied. I believe it's still the best idea to port the patch instead of starting from scratch. I've already ported it from 4.17 to 5.0 and it took no more than a few days. Porting to current shouldn't be much more difficult or time-consuming. I'd be pleased to do this work, yet I'm not sure I can afford doing it now. If you look at my spec file, there is a somewhat detailed change log, which explains the most significant changes. The "mips-linux" patch is quite small -- about 20kB and mostly adds new files, so it should be quite trivial to port. > I'd like to see Linux/mips as a supported target in gdb. gdb in RedHat > 7.1 is quite current. Also, my new toolchain uses stabs, not ecoff. > It may need some work. Since I have a current gdb snapshot handy I checked all the patches I have against it. Here are the results: 1. readline -- non-MIPS/Linux specific; a single hunk fails. Unimportant but linking against local readline statically is evil. 2. ulfc-mips -- fails for a number of hunks but already present in the current BFD; supposedly gdb shares it with binutils on sourceware. 3. gdbserver -- non-MIPS/Linux specific; applies cleanly -- I'll submit it, but it might need a semantics validity check. 4. mips-linux -- important; two hunks fail and needs a semantics validity check. 5. sim-install -- applied. 6. core-xregset -- necessary for core file analysis; one hunk fails. It might not be needed though, since I was told the generic core file handling code was to be rewritten. 7. sim-mips-clean -- applied. 8. so-lmstart -- crucial for shared library handling; fails completely -- maybe unneeded (there was a base address vs load address confusion in gdb's generic shlib handling code). 9. sign-extend -- crucial for shared library handling; fails partially. 10. mips-branch-predict -- necessary for placing breakpoints after branches; fails partially -- no idea why it wasn't applied as what is already ther is completely broken. So the success ratio is 1/4 and for two trivial patches only -- not much encouraging for me for further work, especially as what I have now works for me quite well. Feel free to look at the stuff -- I might check it as well, but I can't afford spending much time on it at the moment, sorry. 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 Wed Jun 6 09:18:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56GIl104005 for linux-mips-outgoing; Wed, 6 Jun 2001 09:18:47 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56GIlh04002 for ; Wed, 6 Jun 2001 09:18:47 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0699A125BC; Wed, 6 Jun 2001 09:18:46 -0700 (PDT) Date: Wed, 6 Jun 2001 09:18:46 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: linux-mips@oss.sgi.com Subject: mips gas is horribly broken Message-ID: <20010606091846.A21652@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Around line 9544 in gas/config/tc-mips.c, there are if (value != 0 && ! fixP->fx_pcrel) { /* In this case, the bfd_install_relocation routine will incorrectly add the symbol value back in. We just want the addend to appear in the object file. FIXME: If this makes VALUE zero, we're toast. */ value -= S_GET_VALUE (fixP->fx_addsy); } I spent several days trying to figure out why libstdc++ was miscompiled on Linux/mipsel. That was because value was zero. That is totally unacceptable for gas to knowingly generate incorrect binaries. At least, we should do value -= S_GET_VALUE (fixP->fx_addsy); assert (value != 0); But I'd like to fix it once for all. Does anyone have any suggestions? Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 09:45:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Gj7D05354 for linux-mips-outgoing; Wed, 6 Jun 2001 09:45:07 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Gj7h05351 for ; Wed, 6 Jun 2001 09:45:07 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D8156125BA; Wed, 6 Jun 2001 09:45:06 -0700 (PDT) Date: Wed, 6 Jun 2001 09:45:06 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: linux-mips@oss.sgi.com Subject: Patch to silent mips gas Message-ID: <20010606094506.A22174@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk It is very annoying for gas to warn NOPS generated from macros. It causes many "make check" failures in gcc. Here is a patch. H.J. ---- 2001-06-06 H.J. Lu * config/tc-mips.c (warn_nops): New variable. Set to 0 to disable warning about all NOPS that the assembler generates. (macro): Warn NOPS generated only if warn_nops is not 0. (md_shortopts): Add `n'. (md_parse_option): Set warn_nops to 1 for `n'. --- gas/config/tc-mips.c.warn Tue Jun 5 21:01:37 2001 +++ gas/config/tc-mips.c Tue Jun 5 21:02:36 2001 @@ -313,6 +313,9 @@ enum mips_pic_level static enum mips_pic_level mips_pic; +/* Warn about all NOPS that the assembler generates. */ +static int warn_nops = 0; + /* 1 if we should generate 32 bit offsets from the GP register in SVR4_PIC mode. Currently has no meaning in other modes. */ static int mips_big_got; @@ -3620,12 +3623,16 @@ macro (ip) /* result is always false */ if (! likely) { - as_warn (_("Branch %s is always false (nop)"), ip->insn_mo->name); + if (warn_nops) + as_warn (_("Branch %s is always false (nop)"), + ip->insn_mo->name); macro_build ((char *) NULL, &icnt, NULL, "nop", "", 0); } else { - as_warn (_("Branch likely %s is always false"), ip->insn_mo->name); + if (warn_nops) + as_warn (_("Branch likely %s is always false"), + ip->insn_mo->name); macro_build ((char *) NULL, &icnt, &offset_expr, "bnel", "s,t,p", 0, 0); } @@ -8860,7 +8867,7 @@ md_number_to_chars (buf, val, n) number_to_chars_littleendian (buf, val, n); } -CONST char *md_shortopts = "O::g::G:"; +CONST char *md_shortopts = "nO::g::G:"; struct option md_longopts[] = { @@ -8975,6 +8982,10 @@ md_parse_option (c, arg) case OPTION_EL: target_big_endian = 0; + break; + + case 'n': + warn_nops = 1; break; case 'O': From owner-linux-mips@oss.sgi.com Wed Jun 6 09:46:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Gkfv05607 for linux-mips-outgoing; Wed, 6 Jun 2001 09:46:41 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Gkbh05594 for ; Wed, 6 Jun 2001 09:46:37 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id UAA28195 for ; Wed, 6 Jun 2001 20:46:46 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id UAA01119 for linux-mips@oss.sgi.com; Wed, 6 Jun 2001 20:37:30 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id QAA05829 for ; Wed, 6 Jun 2001 16:54:26 +0400 (MSD) Message-ID: <3B1E2BF7.5C0CADB8@niisi.msk.ru> Date: Wed, 06 Jun 2001 17:11:19 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Bug in memmove Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, It seems there is a bug in our memmove routine. The condition is rare though, for example, memmove copies incorrectly, if src=5, dst=4, len=9. I guess, exact condition is: len > 8, 0 < src - dst < 8, src isn't aligned on qw (8 bytes), src - dst != 4 I may be wrong on exact condition, but at least the example works. Briefly, memmove calls memcpy if src > dst. Then, when memcpy aligns src on qw, it copies qw to dst. So, after src is aligned, it is overwritten as well. In the example, memcpy copies qw at 4 (so, new data ends on 4+8=12), but aligned src is at address 8, so a word at address 8 is overwritten. Two questions here. First, do we have a pattern that satisfies the condition, i.e. is the bug showstopper? My guess, it's not. Second, does somebody have ideas how to fix the bug? Well, I have, but want to hear somebody else. Regards, Gleb. From owner-linux-mips@oss.sgi.com Wed Jun 6 09:50:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56GoCa05932 for linux-mips-outgoing; Wed, 6 Jun 2001 09:50:12 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56GoBh05928 for ; Wed, 6 Jun 2001 09:50:11 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 62FBA125BA; Wed, 6 Jun 2001 09:50:11 -0700 (PDT) Date: Wed, 6 Jun 2001 09:50:11 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: linux-mips@oss.sgi.com Subject: Patch to report the illegal operand errors in gas/mips. Message-ID: <20010606095011.A22262@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk When you have an illegal operand, you will get a bogus error message saying "opcode not supported on this processor: xxx". This patch fixes it. --- 2001-06-06 H.J. Lu * gas/config/tc-mips.c (mips_ip): Properly report the illegal operand errors. --- gas/config/tc-mips.c.diag Tue Jun 5 20:28:20 2001 +++ gas/config/tc-mips.c Tue Jun 5 20:46:50 2001 @@ -7087,19 +7087,25 @@ mips_ip (str, ip) } else { - static char buf[100]; - sprintf (buf, - _("opcode not supported on this processor: %s (%s)"), - mips_cpu_to_str (mips_cpu), - mips_isa_to_str (mips_opts.isa)); + if (!insn_error) + { + static char buf[100]; + sprintf (buf, + _("opcode not supported on this processor: %s (%s)"), + mips_cpu_to_str (mips_cpu), + mips_isa_to_str (mips_opts.isa)); - insn_error = buf; + insn_error = buf; + } + if (save_c) + *(--s) = save_c; return; } } ip->insn_mo = insn; ip->insn_opcode = insn->match; + insn_error = NULL; for (args = insn->args;; ++args) { if (*s == ' ') @@ -7940,8 +7946,11 @@ mips_ip (str, ip) { ++insn; s = argsStart; + insn_error = _("illegal operands"); continue; } + if (save_c) + *(--s) = save_c; insn_error = _("illegal operands"); return; } From owner-linux-mips@oss.sgi.com Wed Jun 6 10:41:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56HfHp07759 for linux-mips-outgoing; Wed, 6 Jun 2001 10:41:17 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56HfFh07753 for ; Wed, 6 Jun 2001 10:41:16 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id VAA28711 for ; Wed, 6 Jun 2001 21:41:25 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA01483 for linux-mips@oss.sgi.com; Wed, 6 Jun 2001 21:31:02 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id VAA15938 for ; Wed, 6 Jun 2001 21:36:52 +0400 (MSD) Message-ID: <3B1EDB4A.4080803@niisi.msk.ru> Date: Wed, 06 Jun 2001 21:39:22 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Troubles in r2300.c Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. In the r2300.c ,in some functions ( like the r3k_cache_size and so on ), the CONFIG register is modified. To return this register to initial state, the save_and_cli(flags) and the restore_flags(flags) functions are used. The restore_flags do not modify whole STATUS register, but only the Interrupt Enable bit. So we should use the read_32bit_cp0_register and the write_32bit_cp0_register functions instead ( like it was in linux-2.4.1 ). And also, this patch adds R3081E CPU support to the ld_mmu_r2300() function. diff -u -r1.12 r2300.c --- arch/mips/mm/r2300.c 2001/05/31 14:27:32 1.12 +++ arch/mips/mm/r2300.c 2001/06/06 17:10:47 @@ -125,7 +125,7 @@ p = (volatile unsigned long *) KSEG0; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ca_flags|flags)&~ST0_IEC); @@ -147,7 +147,7 @@ if (size > 0x40000) size = 0; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); return size * sizeof(*p); } @@ -170,7 +170,7 @@ if (size > icache_size) size = icache_size; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC); @@ -212,7 +212,7 @@ p += 0x080; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS,flags); } static void r3k_flush_dcache_range(unsigned long start, unsigned long end) @@ -224,7 +224,7 @@ if (size > dcache_size) size = dcache_size; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|flags)&~ST0_IEC); @@ -266,7 +266,7 @@ p += 0x080; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS,flags); } static inline unsigned long get_phys_page (unsigned long addr, @@ -714,6 +714,7 @@ case CPU_R3000: case CPU_R3000A: case CPU_R3081: + case CPU_R3081E: r3k_probe_cache(); From owner-linux-mips@oss.sgi.com Wed Jun 6 10:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Hr9p09070 for linux-mips-outgoing; Wed, 6 Jun 2001 10:53:09 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56HoVh08855 for ; Wed, 6 Jun 2001 10:51:02 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA09122; Wed, 6 Jun 2001 19:48:25 +0200 (MET DST) Date: Wed, 6 Jun 2001 19:48:24 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606090816.C21351@lucon.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 On Wed, 6 Jun 2001, H . J . Lu wrote: > There are many changes in gdb, especially in thread and C++ supports. > We need those on mips also. I am willing to spend my time. But I need > some help. I don't know much about mips :-(. It would be nice to have at least basic C support in mainline. > I'd like to get gdb working first. Do you have time to answer some > questions? I often have time to write mails (but I don't have most of my development resources here). Feel free to ask -- I'll try to answer as I can. I haven't been into MIPS/Linux development tools for some time now, since they are mostly working for me, so my memory might be vague. I'm working on the kernel mostly these days -- my primary goal is to find out why Linux crashes hard when building binutils natively on my DECstation (the progress is at a snail speed, unfortunately). 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 Wed Jun 6 10:59:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56HxEm09563 for linux-mips-outgoing; Wed, 6 Jun 2001 10:59:14 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56HxDh09560 for ; Wed, 6 Jun 2001 10:59:13 -0700 Received: from rjrtower (2093182197.weiderpub.com [209.3.182.197] (may be forged)) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f56HxCR01722 for ; Wed, 6 Jun 2001 10:59:12 -0700 Message-ID: <006001c0eeb2$642a7f70$031010ac@rjrtower> From: "Robert Rusek" To: Subject: SGI Challenge S Serial Port (zs0) Driver question Date: Wed, 6 Jun 2001 10:59:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C0EE77.B777BB10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C0EE77.B777BB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to install RedHat 5.1 Linux on my Challenge. I finally got = the kernel to boot from the prom via bootp/tftp. The loading of the = kernel stops with the following messag: Warning: unable to open an initial console. The HOW-TO states the following: -------------------------------------------------------------------------= ------- This problem has two possible solutions. First make sure you actually = have a driver for the console of your system configured. If this is the = case and the problem persists you probably got victim of a widespead bug = in Linux distributions and root filesystems out there. The console of a = Linux systems should be a character device of major id 5, minor 1 with = permissions of 622 and owned by user and group root. If that's not the = case, cd to the root of the filesystem and execute the following = commands as root:=20 rm -f dev/console mknod --mode=3D622 dev/console =20 You can also do this on a NFS root filesystem, even on the NFS server = itself. However note that the major and minor ids are changed by NFS, = therefore you must do this from a Linux system even if it's only a NFS = client or the major / minor ID might be wrong when your Linux client = boots from it.=20 -------------------------------------------------------------------------= ------- I have followed the above instructions and still I get: Warning: unable to open an initial console. I would assume then that I need a special driver for for the serial port = (zs0). Just to clarify I am connecting a terminal to the serial port of = the Challenge. Any help would be greatly appreciated. Thank you in advance, Robert Rusek ------=_NextPart_000_005D_01C0EE77.B777BB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to install RedHat 5.1 Linux = on my=20 Challenge.  I finally got the kernel to boot from the prom via=20 bootp/tftp.  The loading of the kernel stops with the following=20 messag:
 
Warning: unable to open an initial console.

The HOW-TO states the following:

This problem has two possible solutions. First make sure you actually = have a=20 driver for the console of your system configured. If this is the case = and the=20 problem persists you probably got victim of a widespead bug in Linux=20 distributions and root filesystems out there. The console of a Linux = systems=20 should be a character device of major id 5, minor 1 with permissions of = 622 and=20 owned by user and group root. If that's not the case, cd to the root of = the=20 filesystem and execute the following commands as root: 
   rm -f =
dev/console
   mknod --mode=3D622 dev/console
 =20
You can also do this on a NFS root filesystem, even on the NFS = server=20 itself. However note that the major and minor ids are changed by NFS, = therefore=20 you must do this from a Linux system even if it's only a NFS client or = the major=20 / minor ID might be wrong when your Linux client boots from it.=20
 
I have followed the above instructions = and still I=20 get:
 
Warning: unable to open an initial console.
 
I would assume then that I need a = special driver=20 for for the serial port (zs0).  Just to clarify I am connecting a = terminal=20 to the serial port of the Challenge.
 
Any help would be greatly = appreciated.
 
Thank you in advance,
Robert Rusek
------=_NextPart_000_005D_01C0EE77.B777BB10-- From owner-linux-mips@oss.sgi.com Wed Jun 6 11:28:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56ISw510669 for linux-mips-outgoing; Wed, 6 Jun 2001 11:28:58 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56ISuh10666 for ; Wed, 6 Jun 2001 11:28:57 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06670 for ; Wed, 6 Jun 2001 11:28:43 -0700 (PDT) mail_from (drow@nevyn.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 157hbP-00060j-00; Wed, 06 Jun 2001 11:00:19 -0700 Date: Wed, 6 Jun 2001 11:00:19 -0700 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606110019.A23009@nevyn.them.org> References: <20010606090816.C21351@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Jun 06, 2001 at 07:48:24PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 07:48:24PM +0200, Maciej W. Rozycki wrote: > On Wed, 6 Jun 2001, H . J . Lu wrote: > > > There are many changes in gdb, especially in thread and C++ supports. > > We need those on mips also. I am willing to spend my time. But I need > > some help. I don't know much about mips :-(. > > It would be nice to have at least basic C support in mainline. > > > I'd like to get gdb working first. Do you have time to answer some > > questions? > > I often have time to write mails (but I don't have most of my development > resources here). Feel free to ask -- I'll try to answer as I can. I > haven't been into MIPS/Linux development tools for some time now, since > they are mostly working for me, so my memory might be vague. I'm working > on the kernel mostly these days -- my primary goal is to find out why > Linux crashes hard when building binutils natively on my DECstation (the > progress is at a snail speed, unfortunately). I've actually spent this week porting the gdb CVS head to MIPS; I've got it almost entirely working now. There's one problem with SIGTRAP that I haven't quite figured out yet, and thread attach isn't quite working, and there's a kernel bug I've been repeatedly triggering that I think I just fixed. I anticipate it all being done in a couple of days - I'll post here and on the GDB list when I have it in slightly better shape. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Wed Jun 6 11:46:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56IkpT11960 for linux-mips-outgoing; Wed, 6 Jun 2001 11:46:51 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56IkBh11862 for ; Wed, 6 Jun 2001 11:46:12 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10647; Wed, 6 Jun 2001 20:34:05 +0200 (MET DST) Date: Wed, 6 Jun 2001 20:34:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: Alexandr Andreev , Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: Troubles in r2300.c In-Reply-To: <3B1EDB4A.4080803@niisi.msk.ru> 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 On Wed, 6 Jun 2001, Alexandr Andreev wrote: > In the r2300.c ,in some functions ( like the r3k_cache_size and so on ), > the > CONFIG register is modified. To return this register to initial state, the > save_and_cli(flags) and the restore_flags(flags) functions are used. The > restore_flags do not modify whole STATUS register, but only the > Interrupt Enable > bit. So we should use the read_32bit_cp0_register and the > write_32bit_cp0_register > functions instead ( like it was in linux-2.4.1 ). Sh*t! Why do people keep "fixing" things they did not break, especially when no one is watching??? The functions were already discussed back in January or so and I already explained why read/write functions are needed instead of cli/restore! I think I'll cook up a patch with a few explicit comments so nobody touches the code unless he know what he is doing. Ralf, please apply the patch ASAP. Thanks. 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 Wed Jun 6 11:56:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56IuYr13487 for linux-mips-outgoing; Wed, 6 Jun 2001 11:56:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56IuXh13484 for ; Wed, 6 Jun 2001 11:56:33 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA01810 for ; Wed, 6 Jun 2001 11:55:11 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10647; Wed, 6 Jun 2001 20:34:05 +0200 (MET DST) Date: Wed, 6 Jun 2001 20:34:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: Alexandr Andreev , Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: Troubles in r2300.c In-Reply-To: <3B1EDB4A.4080803@niisi.msk.ru> 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 On Wed, 6 Jun 2001, Alexandr Andreev wrote: > In the r2300.c ,in some functions ( like the r3k_cache_size and so on ), > the > CONFIG register is modified. To return this register to initial state, the > save_and_cli(flags) and the restore_flags(flags) functions are used. The > restore_flags do not modify whole STATUS register, but only the > Interrupt Enable > bit. So we should use the read_32bit_cp0_register and the > write_32bit_cp0_register > functions instead ( like it was in linux-2.4.1 ). Sh*t! Why do people keep "fixing" things they did not break, especially when no one is watching??? The functions were already discussed back in January or so and I already explained why read/write functions are needed instead of cli/restore! I think I'll cook up a patch with a few explicit comments so nobody touches the code unless he know what he is doing. Ralf, please apply the patch ASAP. Thanks. 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 Wed Jun 6 12:15:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56JFqn17093 for linux-mips-outgoing; Wed, 6 Jun 2001 12:15:52 -0700 Received: from geoffk.org (desire.geoffk.org [64.2.60.52]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56JFlh17075 for ; Wed, 6 Jun 2001 12:15:51 -0700 Received: (from geoffk@localhost) by geoffk.org (8.9.3/8.9.3) id MAA01399; Wed, 6 Jun 2001 12:32:15 -0700 Date: Wed, 6 Jun 2001 12:32:15 -0700 Message-Id: <200106061932.MAA01399@geoffk.org> X-Authentication-Warning: localhost.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f From: Geoff Keating To: hjl@lucon.org CC: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com In-reply-to: <20010606091846.A21652@lucon.org> (hjl@lucon.org) Subject: Re: mips gas is horribly broken Reply-to: Geoff Keating References: <20010606091846.A21652@lucon.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Date: Wed, 6 Jun 2001 09:18:46 -0700 > From: "H . J . Lu" > Cc: linux-mips@oss.sgi.com > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > > Around line 9544 in gas/config/tc-mips.c, there are > > if (value != 0 && ! fixP->fx_pcrel) > { > /* In this case, the bfd_install_relocation routine will > incorrectly add the symbol value back in. We just want > the addend to appear in the object file. > FIXME: If this makes VALUE zero, we're toast. */ > value -= S_GET_VALUE (fixP->fx_addsy); > } > > I spent several days trying to figure out why libstdc++ was miscompiled > on Linux/mipsel. That was because value was zero. That is totally > unacceptable for gas to knowingly generate incorrect binaries. At > least, we should do > > value -= S_GET_VALUE (fixP->fx_addsy); > assert (value != 0); > > But I'd like to fix it once for all. Does anyone have any suggestions? There is no easy fix. This has been a longstanding problem, but any change to bfd_install_relocation would require modifying every port in a corresponding way, see for instance the FIXME at line 4816 or so in tc-ppc.c. -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Wed Jun 6 12:35:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56JZ5s20220 for linux-mips-outgoing; Wed, 6 Jun 2001 12:35:05 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56JZ4h20209 for ; Wed, 6 Jun 2001 12:35:04 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06629 for ; Wed, 6 Jun 2001 12:27:26 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10913; Wed, 6 Jun 2001 20:40:08 +0200 (MET DST) Date: Wed, 6 Jun 2001 20:40:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606110019.A23009@nevyn.them.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 On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > I've actually spent this week porting the gdb CVS head to MIPS; I've > got it almost entirely working now. There's one problem with SIGTRAP Make sure your kernel is flushing the icache right. > that I haven't quite figured out yet, and thread attach isn't quite > working, and there's a kernel bug I've been repeatedly triggering that > I think I just fixed. I anticipate it all being done in a couple of > days - I'll post here and on the GDB list when I have it in slightly > better shape. Great! Did you do you work from scratch -- hopefully not? -- + 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 Jun 6 12:56:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Ju3h23415 for linux-mips-outgoing; Wed, 6 Jun 2001 12:56:03 -0700 Received: from dea.waldorf-gmbh.de (u-206-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.206]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Ju0h23409 for ; Wed, 6 Jun 2001 12:56:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f56JtjI06112; Wed, 6 Jun 2001 21:55:45 +0200 Date: Wed, 6 Jun 2001 21:55:45 +0200 From: Ralf Baechle To: Alexandr Andreev Cc: linux-mips@oss.sgi.com Subject: Re: Troubles in r2300.c Message-ID: <20010606215545.A6079@bacchus.dhis.org> References: <3B1EDB4A.4080803@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1EDB4A.4080803@niisi.msk.ru>; from andreev@niisi.msk.ru on Wed, Jun 06, 2001 at 09:39:22PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alexandr, your MUA has garbled your patch, so I was forced to apply it manually. Mozilla is known to be evil in that respect like a few more mailers. For future patches please use a mailer that doesn't change patches in creative ways. Thanks for your patch, Ralf From owner-linux-mips@oss.sgi.com Wed Jun 6 13:09:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56K9tX25485 for linux-mips-outgoing; Wed, 6 Jun 2001 13:09:55 -0700 Received: from dea.waldorf-gmbh.de (u-206-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.206]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56K9ph25480 for ; Wed, 6 Jun 2001 13:09:51 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f56K9f106174; Wed, 6 Jun 2001 22:09:41 +0200 Date: Wed, 6 Jun 2001 22:09:41 +0200 From: Ralf Baechle To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: SGI Challenge S Serial Port (zs0) Driver question Message-ID: <20010606220941.C6079@bacchus.dhis.org> References: <006001c0eeb2$642a7f70$031010ac@rjrtower> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006001c0eeb2$642a7f70$031010ac@rjrtower>; from robru@teknuts.com on Wed, Jun 06, 2001 at 10:59:11AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 10:59:11AM -0700, Robert Rusek wrote: > I am trying to install RedHat 5.1 Linux on my Challenge. I finally got the kernel to boot from the prom via bootp/tftp. The loading of the kernel stops with the following messag: > > Warning: unable to open an initial console. > > The HOW-TO states the following: > > > -------------------------------------------------------------------------------- > This problem has two possible solutions. First make sure you actually have a driver for the console of your system configured. If this is the case and the problem persists you probably got victim of a widespead bug in Linux distributions and root filesystems out there. The console of a Linux systems should be a character device of major id 5, minor 1 with permissions of 622 and owned by user and group root. If that's not the case, cd to the root of the filesystem and execute the following commands as root: > > rm -f dev/console > mknod --mode=622 dev/console > > > You can also do this on a NFS root filesystem, even on the NFS server itself. However note that the major and minor ids are changed by NFS, therefore you must do this from a Linux system even if it's only a NFS client or the major / minor ID might be wrong when your Linux client boots from it. > -------------------------------------------------------------------------------- > > > I have followed the above instructions and still I get: > > Warning: unable to open an initial console. > > I would assume then that I need a special driver for for the serial port (zs0). Just to clarify I am connecting a terminal to the serial port of the Challenge. The standard SGI serial driver (CONFIG_SGI_SERIAL) supports the serial ports of the Challenge S also. Only if this one is configured you'll get all the output upto ``Warning: unable to open ...'' printed onto the serial console. You also should see a message about two serial interfaces being detected. PS: Pressing the return character once every ~ 75 characters produces properly formatted mails ... From owner-linux-mips@oss.sgi.com Wed Jun 6 13:15:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KFqx26497 for linux-mips-outgoing; Wed, 6 Jun 2001 13:15:52 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56KFqh26494 for ; Wed, 6 Jun 2001 13:15:52 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B9103125BA; Wed, 6 Jun 2001 13:15:51 -0700 (PDT) Date: Wed, 6 Jun 2001 13:15:51 -0700 From: "H . J . Lu" To: Geoff Keating Cc: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: mips gas is horribly broken Message-ID: <20010606131551.A25655@lucon.org> References: <20010606091846.A21652@lucon.org> <200106061932.MAA01399@geoffk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106061932.MAA01399@geoffk.org>; from geoffk@geoffk.org on Wed, Jun 06, 2001 at 12:32:15PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 12:32:15PM -0700, Geoff Keating wrote: > > Date: Wed, 6 Jun 2001 09:18:46 -0700 > > From: "H . J . Lu" > > Cc: linux-mips@oss.sgi.com > > Content-Disposition: inline > > User-Agent: Mutt/1.2.5i > > > > Around line 9544 in gas/config/tc-mips.c, there are > > > > if (value != 0 && ! fixP->fx_pcrel) > > { > > /* In this case, the bfd_install_relocation routine will > > incorrectly add the symbol value back in. We just want > > the addend to appear in the object file. > > FIXME: If this makes VALUE zero, we're toast. */ > > value -= S_GET_VALUE (fixP->fx_addsy); > > } > > > > I spent several days trying to figure out why libstdc++ was miscompiled > > on Linux/mipsel. That was because value was zero. That is totally > > unacceptable for gas to knowingly generate incorrect binaries. At > > least, we should do > > > > value -= S_GET_VALUE (fixP->fx_addsy); > > assert (value != 0); > > > > But I'd like to fix it once for all. Does anyone have any suggestions? > > There is no easy fix. This has been a longstanding problem, but any > change to bfd_install_relocation would require modifying every port in That is not a good excuse to knowingly generate incorrect binaries. > a corresponding way, see for instance the FIXME at line 4816 or so in > tc-ppc.c. I am willing to spend my time to fix it. Do you have any suggestions how to proceed? H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 13:20:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KK0627396 for linux-mips-outgoing; Wed, 6 Jun 2001 13:20:00 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56KJxh27390 for ; Wed, 6 Jun 2001 13:19:59 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5B6C0125BA; Wed, 6 Jun 2001 13:19:59 -0700 (PDT) Date: Wed, 6 Jun 2001 13:19:59 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606131959.B25655@lucon.org> References: <20010606090816.C21351@lucon.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 Wed, Jun 06, 2001 at 07:48:24PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 07:48:24PM +0200, Maciej W. Rozycki wrote: > resources here). Feel free to ask -- I'll try to answer as I can. I > haven't been into MIPS/Linux development tools for some time now, since > they are mostly working for me, so my memory might be vague. I'm working As far as I can tell, all the currently available Linux/mips binutils are broken. I am working on fixing it. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 13:44:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KiM931613 for linux-mips-outgoing; Wed, 6 Jun 2001 13:44:22 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56KiMh31610 for ; Wed, 6 Jun 2001 13:44:22 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05049 for ; Wed, 6 Jun 2001 13:44:15 -0700 (PDT) mail_from (drow@nevyn.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 157jqU-0007GI-00; Wed, 06 Jun 2001 13:24:02 -0700 Date: Wed, 6 Jun 2001 13:24:02 -0700 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606132402.A27901@nevyn.them.org> References: <20010606110019.A23009@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Jun 06, 2001 at 08:40:07PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 08:40:07PM +0200, Maciej W. Rozycki wrote: > On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > > I've actually spent this week porting the gdb CVS head to MIPS; I've > > got it almost entirely working now. There's one problem with SIGTRAP > > Make sure your kernel is flushing the icache right. Hmm, thanks, I'll check. I don't think that's it, though. > > that I haven't quite figured out yet, and thread attach isn't quite > > working, and there's a kernel bug I've been repeatedly triggering that > > I think I just fixed. I anticipate it all being done in a couple of > > days - I'll post here and on the GDB list when I have it in slightly > > better shape. > > Great! Did you do you work from scratch -- hopefully not? Nope. It's based mostly on the same 4.17 patch from David Miller, and some bits from Ralf, all marked as assigned to the FSF (though I'm not sure if that ever actually happened); I'll straighten out copyright once I've got the whole thing done. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Wed Jun 6 14:15:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LFj405312 for linux-mips-outgoing; Wed, 6 Jun 2001 14:15:45 -0700 Received: from dea.waldorf-gmbh.de (u-206-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.206]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LFgh05299 for ; Wed, 6 Jun 2001 14:15:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f56L99N06605; Wed, 6 Jun 2001 23:09:09 +0200 Date: Wed, 6 Jun 2001 23:09:09 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: "Maciej W. Rozycki" , "H . J . Lu" , linux-mips@oss.sgi.com, davem@redhat.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010606230909.A6540@bacchus.dhis.org> References: <20010606110019.A23009@nevyn.them.org> <20010606132402.A27901@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010606132402.A27901@nevyn.them.org>; from dan@debian.org on Wed, Jun 06, 2001 at 01:24:02PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 01:24:02PM -0700, Daniel Jacobowitz wrote: > Nope. It's based mostly on the same 4.17 patch from David Miller, and > some bits from Ralf, all marked as assigned to the FSF (though I'm not > sure if that ever actually happened); I'll straighten out copyright > once I've got the whole thing done. The FSF already has a copyright assignment for my GDB work however David to my knowledge never assigned his code to the FSF nor as he did this work during his internship at SGI do I know if SGI still has any rights on his work. Unfortunately by now I fear David's and my work is tangled in a way that we won't be able to distinguish who wrote what to the degree required by the FSF ... David, can you comment? Ralf From owner-linux-mips@oss.sgi.com Wed Jun 6 14:20:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LK7A06382 for linux-mips-outgoing; Wed, 6 Jun 2001 14:20:07 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LK6h06378 for ; Wed, 6 Jun 2001 14:20:06 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9A2AE125BC; Wed, 6 Jun 2001 14:20:05 -0700 (PDT) Date: Wed, 6 Jun 2001 14:20:05 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: linux-mips@oss.sgi.com Subject: A patch for ELF section symbols Message-ID: <20010606142005.A27310@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On mips, both _gp_disp and _DYNAMIC_LINKING/_DYNAMIC_LINK are explicitly marked as glocal section symbols. We should keep them during objcopy. H.J. ---- 2001-06-06 H.J. Lu * elf.c (swap_out_syms): Keep names for global section symbols. --- binutils/bfd/elf.c.mips Tue May 15 20:03:57 2001 +++ binutils/bfd/elf.c Tue May 15 21:20:49 2001 @@ -4395,9 +4395,9 @@ swap_out_syms (abfd, sttp, relocatable_p flagword flags = syms[idx]->flags; int type; - if ((flags & BSF_SECTION_SYM) != 0) + if ((flags & (BSF_SECTION_SYM | BSF_GLOBAL)) == BSF_SECTION_SYM) { - /* Section symbols have no name. */ + /* Local section symbols have no name. */ sym.st_name = 0; } else @@ -4506,7 +4506,12 @@ swap_out_syms (abfd, sttp, relocatable_p type = (*bed->elf_backend_get_symbol_type) (&type_ptr->internal_elf_sym, type); if (flags & BSF_SECTION_SYM) - sym.st_info = ELF_ST_INFO (STB_LOCAL, STT_SECTION); + { + if (flags & BSF_GLOBAL) + sym.st_info = ELF_ST_INFO (STB_GLOBAL, STT_SECTION); + else + sym.st_info = ELF_ST_INFO (STB_LOCAL, STT_SECTION); + } else if (bfd_is_com_section (syms[idx]->section)) sym.st_info = ELF_ST_INFO (STB_GLOBAL, type); else if (bfd_is_und_section (syms[idx]->section)) From owner-linux-mips@oss.sgi.com Wed Jun 6 14:40:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LeXi10420 for linux-mips-outgoing; Wed, 6 Jun 2001 14:40:33 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LeWh10409 for ; Wed, 6 Jun 2001 14:40:32 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E37A7125BC; Wed, 6 Jun 2001 14:40:31 -0700 (PDT) Date: Wed, 6 Jun 2001 14:40:31 -0700 From: "H . J . Lu" To: gcc-patches@gcc.gnu.org Cc: linux-mips@oss.sgi.com Subject: A patch for mips.md Message-ID: <20010606144031.A27654@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Linux/mips, I got # gcc -O0 -c gcc/testsuite/gcc.c-torture/compile/20010107-1.c /tmp/cc42wjvw.s: Assembler messages: /tmp/cc42wjvw.s:22: Error: illegal operands `move This patch seems to work for me. H.J. --- 2001-06-06 H.J. Lu (hjl@gnu.org) * config/mips/mips.md (call_internal2): Use "lw" if the target is not a register. (call_value_internal2): Likewise. (call_value_multiple_internal2): Likewise. --- gcc/config/mips/mips.md.call Fri Jun 1 23:28:12 2001 +++ gcc/config/mips/mips.md Fri Jun 1 23:35:45 2001 @@ -9547,6 +9547,8 @@ ld\\t%2,%1-%S1(%2)\;daddu\\t%2,%2,$31\;j } else if (GET_CODE (target) == CONST_INT) return \"li\\t%^,%0\\n\\tjal\\t%2,%^\"; + else if (GET_CODE (target) != REG) + return \"lw\\t%^,%0\\n\\tjal\\t%2,%^\"; else if (REGNO (target) != PIC_FUNCTION_ADDR_REGNUM) return \"move\\t%^,%0\\n\\tjal\\t%2,%^\"; else @@ -9755,6 +9757,8 @@ ld\\t%2,%1-%S1(%2)\;daddu\\t%2,%2,$31\;j } else if (GET_CODE (target) == CONST_INT) return \"li\\t%^,%1\\n\\tjal\\t%3,%^\"; + else if (GET_CODE (target) != REG) + return \"lw\\t%^,%1\\n\\tjal\\t%3,%^\"; else if (REGNO (target) != PIC_FUNCTION_ADDR_REGNUM) return \"move\\t%^,%1\\n\\tjal\\t%3,%^\"; else @@ -9890,6 +9894,8 @@ ld\\t%2,%1-%S1(%2)\;daddu\\t%2,%2,$31\;j } else if (GET_CODE (target) == CONST_INT) return \"li\\t%^,%1\\n\\tjal\\t%4,%^\"; + else if (GET_CODE (target) != REG) + return \"lw\\t%^,%1\\n\\tjal\\t%4,%^\"; else if (REGNO (target) != PIC_FUNCTION_ADDR_REGNUM) return \"move\\t%^,%1\\n\\tjal\\t%4,%^\"; else From owner-linux-mips@oss.sgi.com Wed Jun 6 14:43:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Lhcd11089 for linux-mips-outgoing; Wed, 6 Jun 2001 14:43:38 -0700 Received: from geoffk.org (desire.geoffk.org [64.2.60.52]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Lhah11085 for ; Wed, 6 Jun 2001 14:43:37 -0700 Received: (from geoffk@localhost) by geoffk.org (8.9.3/8.9.3) id OAA01491; Wed, 6 Jun 2001 14:59:19 -0700 Date: Wed, 6 Jun 2001 14:59:19 -0700 Message-Id: <200106062159.OAA01491@geoffk.org> X-Authentication-Warning: localhost: geoffk set sender to geoffk@geoffk.org using -f From: Geoff Keating To: hjl@lucon.org CC: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com In-reply-to: <20010606131551.A25655@lucon.org> (hjl@lucon.org) Subject: Re: mips gas is horribly broken Reply-to: Geoff Keating References: <20010606091846.A21652@lucon.org> <200106061932.MAA01399@geoffk.org> <20010606131551.A25655@lucon.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Date: Wed, 6 Jun 2001 13:15:51 -0700 > From: "H . J . Lu" > Cc: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > > On Wed, Jun 06, 2001 at 12:32:15PM -0700, Geoff Keating wrote: > > > Date: Wed, 6 Jun 2001 09:18:46 -0700 > > > From: "H . J . Lu" > > > Cc: linux-mips@oss.sgi.com > > > Content-Disposition: inline > > > User-Agent: Mutt/1.2.5i > > > > > > Around line 9544 in gas/config/tc-mips.c, there are > > > > > > if (value != 0 && ! fixP->fx_pcrel) > > > { > > > /* In this case, the bfd_install_relocation routine will > > > incorrectly add the symbol value back in. We just want > > > the addend to appear in the object file. > > > FIXME: If this makes VALUE zero, we're toast. */ > > > value -= S_GET_VALUE (fixP->fx_addsy); > > > } > > > > > > I spent several days trying to figure out why libstdc++ was miscompiled > > > on Linux/mipsel. That was because value was zero. That is totally > > > unacceptable for gas to knowingly generate incorrect binaries. At > > > least, we should do > > > > > > value -= S_GET_VALUE (fixP->fx_addsy); > > > assert (value != 0); > > > > > > But I'd like to fix it once for all. Does anyone have any suggestions? > > > > There is no easy fix. This has been a longstanding problem, but any > > change to bfd_install_relocation would require modifying every port in > > That is not a good excuse to knowingly generate incorrect binaries. > > > a corresponding way, see for instance the FIXME at line 4816 or so in > > tc-ppc.c. > > I am willing to spend my time to fix it. Do you have any suggestions > how to proceed? First, redesign bfd_install_relocation so that it does the right thing (there are other cases where the bfd backends have to work around it). Then, change all the users to match. Then, test all the supported platforms. It might be worthwhile, before starting this, to look and see what precisely _are_ the supported platforms. There are things in bfd that probably haven't been used for years. I guess anything supported by either GDB or by GCC should still be supported, but there are some more platforms which are supported only in GAS, typically because it doesn't make sense to have a compiler for them (small 8-bit parts, for instance). -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Wed Jun 6 14:48:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LmPk12011 for linux-mips-outgoing; Wed, 6 Jun 2001 14:48:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LmOh11999 for ; Wed, 6 Jun 2001 14:48:24 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 2A763125BC; Wed, 6 Jun 2001 14:48:23 -0700 (PDT) Date: Wed, 6 Jun 2001 14:48:23 -0700 From: "H . J . Lu" To: gcc-patches@gcc.gnu.org Cc: linux-mips@oss.sgi.com Subject: Patch for config/mips/linux.h Message-ID: <20010606144823.A27894@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Linux/mips supports .type for functions. Here is a patch. H.J. --- 2001-06-06 H.J. Lu (hjl@gnu.org) * config/mips/linux.h (ASM_DECLARE_FUNCTION_NAME): Defined. (ASM_DECLARE_FUNCTION_SIZE): Likewise. (FUNCTION_NAME_ALREADY_DECLARED): Likewise. --- gcc/config/mips/linux.h.type Tue Jun 5 10:28:29 2001 +++ gcc/config/mips/linux.h Tue Jun 5 10:29:08 2001 @@ -204,3 +204,36 @@ Boston, MA 02111-1307, USA. */ fputc ('-', FILE); \ assemble_name (FILE, LO); \ } while (0) + +#undef ASM_DECLARE_FUNCTION_NAME +#define ASM_DECLARE_FUNCTION_NAME(STREAM, NAME, DECL) \ + do { \ + if (!flag_inhibit_size_directive) \ + { \ + fputs ("\t.ent\t", STREAM); \ + assemble_name (STREAM, NAME); \ + putc ('\n', STREAM); \ + } \ + fprintf (STREAM, "\t%s\t ", TYPE_ASM_OP); \ + assemble_name (STREAM, NAME); \ + putc (',', STREAM); \ + fprintf (STREAM, TYPE_OPERAND_FMT, "function"); \ + putc ('\n', STREAM); \ + assemble_name (STREAM, NAME); \ + fputs (":\n", STREAM); \ + } while (0) + +#undef ASM_DECLARE_FUNCTION_SIZE +#define ASM_DECLARE_FUNCTION_SIZE(STREAM, NAME, DECL) \ + do { \ + if (!flag_inhibit_size_directive) \ + { \ + fputs ("\t.end\t", STREAM); \ + assemble_name (STREAM, NAME); \ + putc ('\n', STREAM); \ + } \ + } while (0) + +/* Tell function_prologue in mips.c that we have already output the .ent/.end + pseudo-ops. */ +#define FUNCTION_NAME_ALREADY_DECLARED From owner-linux-mips@oss.sgi.com Wed Jun 6 14:55:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LtaK13334 for linux-mips-outgoing; Wed, 6 Jun 2001 14:55:36 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Ltah13330 for ; Wed, 6 Jun 2001 14:55:36 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1A6AD125BC; Wed, 6 Jun 2001 14:55:34 -0700 (PDT) Date: Wed, 6 Jun 2001 14:55:34 -0700 From: "H . J . Lu" To: gcc-patches@gcc.gnu.org Cc: linux-mips@oss.sgi.com Subject: A patch for linux/mips libgcc Message-ID: <20010606145534.A28021@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This patch is against gcc 2.86-85. But it is trivial to convert it for gcc 3.0. The problem is # gcc gcc/testsuite/gcc.c-torture/execute/ieee/fp-cmp-4.c -w -O0 -ffloat-store -lm /tmp/ccaUWHSO.o: In function `test_isunordered': gcc/testsuite/gcc.c-torture/execute/ieee/fp-cmp-4.c(.text+0x44): undefined reference to `__unorddf2' I copied it from IRIX 6. H.J. --- 2001-06-06 H.J. Lu * config/mips/t-linux: New. * configure.in: Add mips/t-linux to tmake_file. --- gcc/config/mips/t-linux.fp Tue Jun 5 22:14:03 2001 +++ gcc/config/mips/t-linux Tue Jun 5 22:24:33 2001 @@ -0,0 +1,20 @@ +# We want fine grained libraries, so use the new code to build the +# floating point emulation libraries. +FPBIT = fp-bit.c +DPBIT = dp-bit.c + +dp-bit.c: $(srcdir)/config/fp-bit.c + echo '#ifdef __MIPSEL__' > dp-bit.c + echo '#define FLOAT_BIT_ORDER_MISMATCH' >> dp-bit.c + echo '#endif' >> dp-bit.c + echo '#undef US_SOFTWARE_GOFAST' >> dp-bit.c + echo '#undef FLOAT' >> dp-bit.c + cat $(srcdir)/config/fp-bit.c >> dp-bit.c + +fp-bit.c: $(srcdir)/config/fp-bit.c + echo '#ifdef __MIPSEL__' > fp-bit.c + echo '#define FLOAT_BIT_ORDER_MISMATCH' >> fp-bit.c + echo '#endif' >> fp-bit.c + echo '#undef US_SOFTWARE_GOFAST' >> fp-bit.c + echo '#define FLOAT' >> fp-bit.c + cat $(srcdir)/config/fp-bit.c >> fp-bit.c --- gcc/configure.in.fp Tue Jun 5 22:14:03 2001 +++ gcc/configure.in Tue Jun 5 22:14:03 2001 @@ -2747,7 +2747,7 @@ changequote([,])dnl mips*el-*) tm_file="elfos.h mips/elfl.h mips/linux.h" ;; *) tm_file="elfos.h mips/elf.h mips/linux.h" ;; esac - tmake_file=t-linux + tmake_file="t-linux mips/t-linux" extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o" gnu_ld=yes gas=yes From owner-linux-mips@oss.sgi.com Wed Jun 6 17:02:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f5702MO00430 for linux-mips-outgoing; Wed, 6 Jun 2001 17:02:22 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5702Mh00426 for ; Wed, 6 Jun 2001 17:02:22 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 74D1E125BA; Wed, 6 Jun 2001 17:02:21 -0700 (PDT) Date: Wed, 6 Jun 2001 17:02:21 -0700 From: "H . J . Lu" To: Geoff Keating Cc: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: mips gas is horribly broken Message-ID: <20010606170221.A30487@lucon.org> References: <20010606091846.A21652@lucon.org> <200106061932.MAA01399@geoffk.org> <20010606131551.A25655@lucon.org> <200106062159.OAA01491@geoffk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106062159.OAA01491@geoffk.org>; from geoffk@geoffk.org on Wed, Jun 06, 2001 at 02:59:19PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 02:59:19PM -0700, Geoff Keating wrote: > > First, redesign bfd_install_relocation so that it does the right thing > (there are other cases where the bfd backends have to work around > it). Then, change all the users to match. Then, test all the > supported platforms. Could you please tell me what you meant by "the right thing" and what exactly is wrong with the current design? On mips, it is addend which is handled incorrectly. Is this the only problem with bfd_install_relocation? H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 17:12:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570CnT02763 for linux-mips-outgoing; Wed, 6 Jun 2001 17:12:49 -0700 Received: from foghorn.airs.com (IDENT:qmailr@foghorn.airs.com [63.201.54.26]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570Ckh02747 for ; Wed, 6 Jun 2001 17:12:46 -0700 Received: (qmail 13071 invoked by uid 10); 7 Jun 2001 00:12:46 -0000 Received: (qmail 19602 invoked by uid 269); 7 Jun 2001 00:12:43 -0000 Mail-Followup-To: geoffk@redhat.com, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com, hjl@lucon.org From: Ian Lance Taylor To: "H . J . Lu" Cc: Geoff Keating , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: mips gas is horribly broken References: <20010606091846.A21652@lucon.org> <200106061932.MAA01399@geoffk.org> <20010606131551.A25655@lucon.org> <200106062159.OAA01491@geoffk.org> <20010606170221.A30487@lucon.org> Date: 06 Jun 2001 17:12:43 -0700 In-Reply-To: <20010606170221.A30487@lucon.org> Message-ID: Lines: 105 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" writes: > On Wed, Jun 06, 2001 at 02:59:19PM -0700, Geoff Keating wrote: > > > > First, redesign bfd_install_relocation so that it does the right thing > > (there are other cases where the bfd backends have to work around > > it). Then, change all the users to match. Then, test all the > > supported platforms. > > Could you please tell me what you meant by "the right thing" and what > exactly is wrong with the current design? On mips, it is addend > which is handled incorrectly. Is this the only problem with > bfd_install_relocation? Here is the comment from bfd_install_relocation: #if 1 /* For m68k-coff, the addend was being subtracted twice during relocation with -r. Removing the line below this comment fixes that problem; see PR 2953. However, Ian wrote the following, regarding removing the line below, which explains why it is still enabled: --djm If you put a patch like that into BFD you need to check all the COFF linkers. I am fairly certain that patch will break coff-i386 (e.g., SCO); see coff_i386_reloc in coff-i386.c where I worked around the problem in a different way. There may very well be a reason that the code works as it does. Hmmm. The first obvious point is that bfd_install_relocation should not have any tests that depend upon the flavour. It's seem like entirely the wrong place for such a thing. The second obvious point is that the current code ignores the reloc addend when producing relocateable output for COFF. That's peculiar. In fact, I really have no idea what the point of the line you want to remove is. A typical COFF reloc subtracts the old value of the symbol and adds in the new value to the location in the object file (if it's a pc relative reloc it adds the difference between the symbol value and the location). When relocating we need to preserve that property. BFD handles this by setting the addend to the negative of the old value of the symbol. Unfortunately it handles common symbols in a non-standard way (it doesn't subtract the old value) but that's a different story (we can't change it without losing backward compatibility with old object files) (coff-i386 does subtract the old value, to be compatible with existing coff-i386 targets, like SCO). So everything works fine when not producing relocateable output. When we are producing relocateable output, logically we should do exactly what we do when not producing relocateable output. Therefore, your patch is correct. In fact, it should probably always just set reloc_entry->addend to 0 for all cases, since it is, in fact, going to add the value into the object file. This won't hurt the COFF code, which doesn't use the addend; I'm not sure what it will do to other formats (the thing to check for would be whether any formats both use the addend and set partial_inplace). When I wanted to make coff-i386 produce relocateable output, I ran into the problem that you are running into: I wanted to remove that line. Rather than risk it, I made the coff-i386 relocs use a special function; it's coff_i386_reloc in coff-i386.c. The function specifically adds the addend field into the object file, knowing that bfd_install_relocation is not going to. If you remove that line, then coff-i386.c will wind up adding the addend field in twice. It's trivial to fix; it just needs to be done. The problem with removing the line is just that it may break some working code. With BFD it's hard to be sure of anything. The right way to deal with this is simply to build and test at least all the supported COFF targets. It should be straightforward if time and disk space consuming. For each target: 1) build the linker 2) generate some executable, and link it using -r (I would probably use paranoia.o and link against newlib/libc.a, which for all the supported targets would be available in /usr/cygnus/progressive/H-host/target/lib/libc.a). 3) make the change to reloc.c 4) rebuild the linker 5) repeat step 2 6) if the resulting object files are the same, you have at least made it no worse 7) if they are different you have to figure out which version is right */ Here are the comments I wrote in bfd/doc/bfdint.texi: The assembler used @samp{bfd_perform_relocation} for a while. This turned out to be the wrong thing to do, since @samp{bfd_perform_relocation} was written to handle relocations on an existing object file, while the assembler needed to create relocations in a new object file. The assembler was changed to use the new function @samp{bfd_install_relocation} instead, and @samp{bfd_install_relocation} was created as a copy of @samp{bfd_perform_relocation}. Unfortunately, the work did not progress any farther, so @samp{bfd_install_relocation} remains a simple copy of @samp{bfd_perform_relocation}, with all the odd special cases and confusing code. This again is difficult to change, because again any change can affect any assembler target, and so is difficult to test. Ian From owner-linux-mips@oss.sgi.com Wed Jun 6 17:45:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570jMo07961 for linux-mips-outgoing; Wed, 6 Jun 2001 17:45:22 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570jLh07958 for ; Wed, 6 Jun 2001 17:45:21 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E5975125BA; Wed, 6 Jun 2001 17:45:20 -0700 (PDT) Date: Wed, 6 Jun 2001 17:45:20 -0700 From: "H . J . Lu" To: gcc-patches@gcc.gnu.org Cc: linux-mips@oss.sgi.com Subject: Re: A patch for linux/mips libgcc Message-ID: <20010606174520.A31252@lucon.org> References: <20010606145534.A28021@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010606145534.A28021@lucon.org>; from hjl@lucon.org on Wed, Jun 06, 2001 at 02:55:34PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 02:55:34PM -0700, H . J . Lu wrote: > This patch is against gcc 2.86-85. But it is trivial to convert it for ^^^^^^^^^^^^ I meant to say gcc 2.96-85 from RedHat rawhide. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 6 17:58:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570wgp09750 for linux-mips-outgoing; Wed, 6 Jun 2001 17:58:42 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570wfh09745 for ; Wed, 6 Jun 2001 17:58:41 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B745A125BA; Wed, 6 Jun 2001 17:58:40 -0700 (PDT) Date: Wed, 6 Jun 2001 17:58:40 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: linux-mips@oss.sgi.com Subject: Patch: a testcase for bad mips reloc Message-ID: <20010606175840.A31485@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I checked in the following testcase for the bad object files generated by the mips assembler. H.J. ---- 2001-06-06 H.J. Lu * gas/mips/elf-rel3.s: New file. * gas/mips/elf-rel3.d: Likewise. * gas/mips/elfel-rel3.s: Likewise. * gas/mips/elfel-rel3.d: Likewise. * gas/mips/mips.exp: Run elf-rel3/elfel-rel3. Index: gas/mips/mips.exp =================================================================== RCS file: /cvs/src/src/gas/testsuite/gas/mips/mips.exp,v retrieving revision 1.9 diff -u -p -r1.9 mips.exp --- mips.exp 2001/05/25 18:39:02 1.9 +++ mips.exp 2001/06/07 00:55:30 @@ -126,6 +126,12 @@ if { [istarget mips*-*-*] } then { } if [istarget mips*el-*-*] { + run_dump_test "elfel-rel3" + } { + run_dump_test "elf-rel3" + } + + if [istarget mips*el-*-*] { run_dump_test "${tmips}elempic" } { run_dump_test "${tmips}empic" --- /dev/null Fri Mar 23 20:37:44 2001 +++ gas/mips/elf-rel3.s Wed Jun 6 17:48:43 2001 @@ -0,0 +1,11 @@ + .data + .type x,@object + .size x,4 +x: + .word 0x12121212 + .globl b + .type b,@object + .size b,8 +b: + .word b-4 + .word x --- /dev/null Fri Mar 23 20:37:44 2001 +++ gas/mips/elf-rel3.d Wed Jun 6 17:48:43 2001 @@ -0,0 +1,13 @@ +#objdump: -sr -j .data +#name: MIPS ELF reloc 3 + +.*: file format elf.*mips + +RELOCATION RECORDS FOR \[\.data\]: +OFFSET TYPE VALUE +0+0000004 R_MIPS_32 b +0+0000008 R_MIPS_32 .data + + +Contents of section .data: + 0000 12121212 fffffffc 00000000 00000000 ................ --- /dev/null Fri Mar 23 20:37:44 2001 +++ gas/mips/elfel-rel3.s Wed Jun 6 17:48:43 2001 @@ -0,0 +1,11 @@ + .data + .type x,@object + .size x,4 +x: + .word 0x12121212 + .globl b + .type b,@object + .size b,8 +b: + .word b+4 + .word x --- /dev/null Fri Mar 23 20:37:44 2001 +++ gas/mips/elfel-rel3.d Wed Jun 6 17:48:43 2001 @@ -0,0 +1,13 @@ +#objdump: -sr -j .data +#name: MIPS ELF reloc 3 + +.*: file format elf.*mips + +RELOCATION RECORDS FOR \[\.data\]: +OFFSET TYPE VALUE +0+0000004 R_MIPS_32 b +0+0000008 R_MIPS_32 .data + + +Contents of section .data: + 0000 12121212 04000000 00000000 00000000 ................ From owner-linux-mips@oss.sgi.com Wed Jun 6 21:32:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f574Wv431017 for linux-mips-outgoing; Wed, 6 Jun 2001 21:32:57 -0700 Received: from geoffk.org (desire.geoffk.org [64.2.60.52]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f574Wuh31013 for ; Wed, 6 Jun 2001 21:32:56 -0700 Received: (from geoffk@localhost) by geoffk.org (8.9.3/8.9.3) id VAA01636; Wed, 6 Jun 2001 21:48:40 -0700 Date: Wed, 6 Jun 2001 21:48:40 -0700 Message-Id: <200106070448.VAA01636@geoffk.org> X-Authentication-Warning: localhost: geoffk set sender to geoffk@geoffk.org using -f From: Geoff Keating To: hjl@lucon.org CC: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com In-reply-to: <20010606170221.A30487@lucon.org> (hjl@lucon.org) Subject: Re: mips gas is horribly broken Reply-to: Geoff Keating References: <20010606091846.A21652@lucon.org> <200106061932.MAA01399@geoffk.org> <20010606131551.A25655@lucon.org> <200106062159.OAA01491@geoffk.org> <20010606170221.A30487@lucon.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Date: Wed, 6 Jun 2001 17:02:21 -0700 > From: "H . J . Lu" > Cc: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > > On Wed, Jun 06, 2001 at 02:59:19PM -0700, Geoff Keating wrote: > > > > First, redesign bfd_install_relocation so that it does the right thing > > (there are other cases where the bfd backends have to work around > > it). Then, change all the users to match. Then, test all the > > supported platforms. > > Could you please tell me what you meant by "the right thing" and what > exactly is wrong with the current design? On mips, it is addend > which is handled incorrectly. Is this the only problem with > bfd_install_relocation? There are four occurrences of 'FIXME', and one comment starting 'Wait for the day'. It would be nice to look at them all... The particular problem you're having is possibly this line of code: #if 1 /* For m68k-coff, the addend was being subtracted twice during relocation with -r. Removing the line below this comment fixes that problem; see PR 2953. However, Ian wrote the following, regarding removing the line below, which explains why it is still enabled: --djm If you put a patch like that into BFD you need to check all the COFF linkers. I am fairly certain that patch will break coff-i386 (e.g., SCO); see coff_i386_reloc in coff-i386.c where I worked around the problem in a different way. There may very well be a reason that the code works as it does. Hmmm. The first obvious point is that bfd_install_relocation should not have any tests that depend upon the flavour. It's seem like entirely the wrong place for such a thing. The second obvious point is that the current code ignores the reloc addend when producing relocateable output for COFF. That's peculiar. In fact, I really have no idea what the point of the line you want to remove is. A typical COFF reloc subtracts the old value of the symbol and adds in the new value to the location in the object file (if it's a pc relative reloc it adds the difference between the symbol value and the location). When relocating we need to preserve that property. BFD handles this by setting the addend to the negative of the old value of the symbol. Unfortunately it handles common symbols in a non-standard way (it doesn't subtract the old value) but that's a different story (we can't change it without losing backward compatibility with old object files) (coff-i386 does subtract the old value, to be compatible with existing coff-i386 targets, like SCO). So everything works fine when not producing relocateable output. When we are producing relocateable output, logically we should do exactly what we do when not producing relocateable output. Therefore, your patch is correct. In fact, it should probably always just set reloc_entry->addend to 0 for all cases, since it is, in fact, going to add the value into the object file. This won't hurt the COFF code, which doesn't use the addend; I'm not sure what it will do to other formats (the thing to check for would be whether any formats both use the addend and set partial_inplace). When I wanted to make coff-i386 produce relocateable output, I ran into the problem that you are running into: I wanted to remove that line. Rather than risk it, I made the coff-i386 relocs use a special function; it's coff_i386_reloc in coff-i386.c. The function specifically adds the addend field into the object file, knowing that bfd_install_relocation is not going to. If you remove that line, then coff-i386.c will wind up adding the addend field in twice. It's trivial to fix; it just needs to be done. The problem with removing the line is just that it may break some working code. With BFD it's hard to be sure of anything. The right way to deal with this is simply to build and test at least all the supported COFF targets. It should be straightforward if time and disk space consuming. For each target: 1) build the linker 2) generate some executable, and link it using -r (I would probably use paranoia.o and link against newlib/libc.a, which for all the supported targets would be available in /usr/cygnus/progressive/H-host/target/lib/libc.a). 3) make the change to reloc.c 4) rebuild the linker 5) repeat step 2 6) if the resulting object files are the same, you have at least made it no worse 7) if they are different you have to figure out which version is right */ relocation -= reloc_entry->addend; #endif but I might have misread the code. Or the comment. There's certainly much more of the comment to misread :-). -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Thu Jun 7 03:57:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57AvXQ15233 for linux-mips-outgoing; Thu, 7 Jun 2001 03:57:33 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57AvHh15180 for ; Thu, 7 Jun 2001 03:57:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA05824; Thu, 7 Jun 2001 12:37:28 +0200 (MET DST) Date: Thu, 7 Jun 2001 12:37:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606132402.A27901@nevyn.them.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 On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > Make sure your kernel is flushing the icache right. > > Hmm, thanks, I'll check. I don't think that's it, though. This happened to me once. Otherwise, it looks like gdb doesn't recognize a breakpoint for some reason -- possibly it places it at a wrong address. It shouldn't be difficult to debug -- you get information of the address the trap happened. > Nope. It's based mostly on the same 4.17 patch from David Miller, and > some bits from Ralf, all marked as assigned to the FSF (though I'm not > sure if that ever actually happened); I'll straighten out copyright > once I've got the whole thing done. You need to contact David, then. -- + 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 Jun 7 04:01:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57B1At15876 for linux-mips-outgoing; Thu, 7 Jun 2001 04:01:10 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57ArYh14688 for ; Thu, 7 Jun 2001 03:56:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA05677; Thu, 7 Jun 2001 12:32:28 +0200 (MET DST) Date: Thu, 7 Jun 2001 12:32:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606131959.B25655@lucon.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 On Wed, 6 Jun 2001, H . J . Lu wrote: > As far as I can tell, all the currently available Linux/mips binutils > are broken. I am working on fixing it. That depends on how you define "broken". All software has bugs. What I currently use is sufficient to build working Linux 2.4.x, glibc 2.2.x as well as all programs I built up to date. I haven't tried C++, I admit. Libstdc++ of gcc 2.95.3 compiles fine, but I have not used it so far, so I have no idea if the binary works. If you know of particular problems, you are welcomed to fix them, of course. -- + 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 Jun 7 04:09:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57B9v417258 for linux-mips-outgoing; Thu, 7 Jun 2001 04:09:57 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57B7th17008 for ; Thu, 7 Jun 2001 04:08:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA05824; Thu, 7 Jun 2001 12:37:28 +0200 (MET DST) Date: Thu, 7 Jun 2001 12:37:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606132402.A27901@nevyn.them.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 On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > Make sure your kernel is flushing the icache right. > > Hmm, thanks, I'll check. I don't think that's it, though. This happened to me once. Otherwise, it looks like gdb doesn't recognize a breakpoint for some reason -- possibly it places it at a wrong address. It shouldn't be difficult to debug -- you get information of the address the trap happened. > Nope. It's based mostly on the same 4.17 patch from David Miller, and > some bits from Ralf, all marked as assigned to the FSF (though I'm not > sure if that ever actually happened); I'll straighten out copyright > once I've got the whole thing done. You need to contact David, then. -- + 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 Jun 7 04:23:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57BN8119467 for linux-mips-outgoing; Thu, 7 Jun 2001 04:23:08 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57BMrh19437 for ; Thu, 7 Jun 2001 04:23:02 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA05824; Thu, 7 Jun 2001 12:37:28 +0200 (MET DST) Date: Thu, 7 Jun 2001 12:37:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010606132402.A27901@nevyn.them.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 On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > Make sure your kernel is flushing the icache right. > > Hmm, thanks, I'll check. I don't think that's it, though. This happened to me once. Otherwise, it looks like gdb doesn't recognize a breakpoint for some reason -- possibly it places it at a wrong address. It shouldn't be difficult to debug -- you get information of the address the trap happened. > Nope. It's based mostly on the same 4.17 patch from David Miller, and > some bits from Ralf, all marked as assigned to the FSF (though I'm not > sure if that ever actually happened); I'll straighten out copyright > once I've got the whole thing done. You need to contact David, then. -- + 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 Jun 7 07:41:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57EfEv12539 for linux-mips-outgoing; Thu, 7 Jun 2001 07:41:14 -0700 Received: from mail.iside.net (ns2.iside.net [212.73.214.202]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57EfCh12535 for ; Thu, 7 Jun 2001 07:41:12 -0700 X-Virus-Protected-by-iSide: McAfee virus scanning engine Received: from [193.251.60.11] (HELO yoshi) by mail.iside.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 3563232 for linux-mips@oss.sgi.com; Thu, 07 Jun 2001 16:35:27 +0200 Message-ID: <00c501c0ef60$ceb4d3f0$662d44c3@yoshi> From: "julien" To: Subject: new comer question Date: Thu, 7 Jun 2001 16:47:42 +0200 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 Hi all, First of all, I apologize for asking this kind of questions here, as there is not many ressources for sgi/linux. I'm following this list's discussions since many months, and I decided to get linux running on my Indy box (R4400, Newport gfx)... To do so, I followed standard installation instructions and used the hardhat5.1 archive located at ftp://oss.sgi.com/pub/linux/mips/redhat ... I set up the tftp / bootp / nfs root on a FreeBSD box as we don't have any Linux here, but this shouldn't be a problem, should it ? At this point, the kernel seems to boot without any problems up to the mount root stage, and after it crashes. Here is the last part of the kernel outpout, transcribed by hand (hope there is all informations needed) : ... VFS: Mounted root (nfs filesystem) Freeing unused kernel memory : 44k freed page fault from irq handler : 0000 $0 : <-- do you need these dumps to understand what's happening ? $4 : ... $28 : epc : 880e3e74 Status : 1004fc02 Cause : 00000008 Aiee, killing interrupt handler Kernel panic : Attempted to kill the idle task In swapper task - not syncing I would appreciate any help, as you have many other better things to do than helping newbies. Thanx in advance -- ------------------------------- --> julien@iside.net ------------------------------- From owner-linux-mips@oss.sgi.com Thu Jun 7 08:10:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FAFr16830 for linux-mips-outgoing; Thu, 7 Jun 2001 08:10:15 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57F9uh16782; Thu, 7 Jun 2001 08:09:57 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id TAA06655; Thu, 7 Jun 2001 19:10:05 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id TAA02870; Thu, 7 Jun 2001 19:00:58 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id TAA22173; Thu, 7 Jun 2001 19:08:35 +0400 (MSD) Message-ID: <3B200A11.3020805@niisi.msk.ru> Date: Thu, 07 Jun 2001 19:11:13 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: Troubles in r2300.c References: <3B1EDB4A.4080803@niisi.msk.ru> <20010606215545.A6079@bacchus.dhis.org> Content-Type: multipart/mixed; boundary="------------090809030606070008010108" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------090809030606070008010108 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > Alexandr, > > your MUA has garbled your patch, so I was forced to apply it manually. > Mozilla is known to be evil in that respect like a few more mailers. > For future patches please use a mailer that doesn't change patches in > creative ways. Thanks for your patch, > > Ralf > Oh, I'm sorry, i forgot to substitute one save_and_cli() and restore ... Please, apply new patch. --------------090809030606070008010108 Content-Type: text/plain; name="r2300_patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r2300_patch" Index: arch/mips/mm/r2300.c =================================================================== RCS file: /share/cvs/root/linux/arch/mips/mm/r2300.c,v retrieving revision 1.12 diff -u -r1.12 r2300.c --- arch/mips/mm/r2300.c 2001/05/31 14:27:32 1.12 +++ arch/mips/mm/r2300.c 2001/06/07 14:28:29 @@ -125,7 +125,7 @@ p = (volatile unsigned long *) KSEG0; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ca_flags|flags)&~ST0_IEC); @@ -147,7 +147,7 @@ if (size > 0x40000) size = 0; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); return size * sizeof(*p); } @@ -170,7 +170,7 @@ if (size > icache_size) size = icache_size; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC); @@ -212,7 +212,7 @@ p += 0x080; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); } static void r3k_flush_dcache_range(unsigned long start, unsigned long end) @@ -224,7 +224,7 @@ if (size > dcache_size) size = dcache_size; - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|flags)&~ST0_IEC); @@ -266,7 +266,7 @@ p += 0x080; } - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); } static inline unsigned long get_phys_page (unsigned long addr, @@ -389,7 +389,7 @@ printk("csigtramp[%08lx]", addr); #endif - save_and_cli(flags); + flags = read_32bit_cp0_register(CP0_STATUS); write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC); @@ -398,7 +398,7 @@ "sb\t$0,0x008(%0)\n\t" : : "r" (addr) ); - restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); } static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size) @@ -714,6 +714,7 @@ case CPU_R3000: case CPU_R3000A: case CPU_R3081: + case CPU_R3081E: r3k_probe_cache(); --------------090809030606070008010108-- From owner-linux-mips@oss.sgi.com Thu Jun 7 08:33:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FXLn20754 for linux-mips-outgoing; Thu, 7 Jun 2001 08:33:21 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FXKh20749 for ; Thu, 7 Jun 2001 08:33:20 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 5729F3E90; Thu, 7 Jun 2001 08:30:23 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id B2CCB1416D; Thu, 7 Jun 2001 08:31:14 -0700 (PDT) Date: Thu, 7 Jun 2001 08:31:14 -0700 From: Keith M Wesolowski To: julien Cc: linux-mips@oss.sgi.com Subject: Re: new comer question Message-ID: <20010607083114.A25672@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c501c0ef60$ceb4d3f0$662d44c3@yoshi> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 04:47:42PM +0200, julien wrote: > I'm following this list's discussions since many months, and I decided > to get linux running on my Indy box (R4400, Newport gfx)... To do so, I > followed standard installation instructions and used the hardhat5.1 > archive located at ftp://oss.sgi.com/pub/linux/mips/redhat ... I set up > the tftp / bootp / nfs root on a FreeBSD box as we don't have any Linux > here, but this shouldn't be a problem, should it ? Of course not. You can use any system as the server. When you say "standard installation instructions" what does that mean exactly? More importantly, which kernel did you use and where did it come from? > $0 : <-- do you need these dumps It depends. If this kernel is a newish 2.4 kernel or current CVS 2.2, then yes, the dumps are needed to solve the problem. If this is an old or ancient kernel you might want to send the dumps anyway but most people will ignore you. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Thu Jun 7 08:51:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FpWV23758 for linux-mips-outgoing; Thu, 7 Jun 2001 08:51:32 -0700 Received: from mail.iside.net (ns2.iside.net [212.73.214.202]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FpUh23754 for ; Thu, 7 Jun 2001 08:51:30 -0700 X-Virus-Protected-by-iSide: McAfee virus scanning engine Received: from [193.251.60.11] (HELO yoshi) by mail.iside.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 3563471; Thu, 07 Jun 2001 17:46:02 +0200 Message-ID: <00f201c0ef6a$aaebb600$662d44c3@yoshi> From: "julien" To: "Keith M Wesolowski" Cc: References: <20010607083114.A25672@foobazco.org> Subject: Re: new comer question Date: Thu, 7 Jun 2001 17:58:16 +0200 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 Hi, thanx for your fast answer ;-)) > On Thu, Jun 07, 2001 at 04:47:42PM +0200, julien wrote: > > > I'm following this list's discussions since many months, and I decided > > to get linux running on my Indy box (R4400, Newport gfx)... To do so, I > > followed standard installation instructions and used the hardhat5.1 > > archive located at ftp://oss.sgi.com/pub/linux/mips/redhat ... I set up > > the tftp / bootp / nfs root on a FreeBSD box as we don't have any Linux > > here, but this shouldn't be a problem, should it ? > > Of course not. You can use any system as the server. When you say > "standard installation instructions" what does that mean exactly? > More importantly, which kernel did you use and where did it come from? by "standard installation instructions" I mean I followed instructions given in the file ftp://oss.sgi.com/pub/linux/mips/redhat/instructions. The kernel I'm using is the one included in the archive at ftp://oss.sgi.com/pub/linux/mips/redhat/hardhat-sgi-5.1.tar.gz ... I know it's a very old one (2.0x ?), but I didn't find any recent compiled kernel for IP22. Do I need to checkout the current kernel and cross compile it ? > > > $0 : <-- do you need these dumps > > It depends. If this kernel is a newish 2.4 kernel or current CVS 2.2, > then yes, the dumps are needed to solve the problem. If this is an > old or ancient kernel you might want to send the dumps anyway but most > people will ignore you. Can I try a 2.4 kernel without having to compile it myself ? If yes, do you have any link where I could find it ? If no, I guess I will have to set up cross compilation stuff... Thanx very much for your time > > -- > Keith M Wesolowski http://foobazco.org/~wesolows > ------(( Project Foobazco Coordinator and Network Administrator ))------ > "Nothing motivates a man more than to see his boss put > in an honest day's work." -- The fortune file -- ------------------------------- --> julien@iside.net ------------------------------- From owner-linux-mips@oss.sgi.com Thu Jun 7 09:28:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57GSZK26559 for linux-mips-outgoing; Thu, 7 Jun 2001 09:28:35 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57GSYh26556 for ; Thu, 7 Jun 2001 09:28:34 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 59FBF125BA; Thu, 7 Jun 2001 09:28:28 -0700 (PDT) Date: Thu, 7 Jun 2001 09:28:28 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010607092827.A13198@lucon.org> References: <20010606131959.B25655@lucon.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 Thu, Jun 07, 2001 at 12:32:27PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 12:32:27PM +0200, Maciej W. Rozycki wrote: > On Wed, 6 Jun 2001, H . J . Lu wrote: > > > As far as I can tell, all the currently available Linux/mips binutils > > are broken. I am working on fixing it. > > That depends on how you define "broken". All software has bugs. What I > currently use is sufficient to build working Linux 2.4.x, glibc 2.2.x as > well as all programs I built up to date. I haven't tried C++, I admit. > Libstdc++ of gcc 2.95.3 compiles fine, but I have not used it so far, so I > have no idea if the binary works. > > If you know of particular problems, you are welcomed to fix them, of > course. See my post on the binutils mailing list. I have reason to believe that it also misassembles the mips kernel with certain configuration. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 7 09:31:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57GVpq26854 for linux-mips-outgoing; Thu, 7 Jun 2001 09:31:51 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57GVoh26849 for ; Thu, 7 Jun 2001 09:31:50 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E5A7B125BA; Thu, 7 Jun 2001 09:31:49 -0700 (PDT) Date: Thu, 7 Jun 2001 09:31:49 -0700 From: "H . J . Lu" To: GDB , binutils@lucon.org, linux-mips@oss.sgi.com Subject: stabs or ecoff for Linux/mips Message-ID: <20010607093149.B13198@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What is the better debug format for Linux/mips in the terms of gdb and binutils, stabs or ecoff? I know the future is dwarf2. But I need something stable now. Since Linux/x86 uses stabs, I lean toward to stabs. Any comments? H.J. From owner-linux-mips@oss.sgi.com Thu Jun 7 10:02:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57H2V728014 for linux-mips-outgoing; Thu, 7 Jun 2001 10:02:31 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57H1ch27990 for ; Thu, 7 Jun 2001 10:02:28 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA19078; Thu, 7 Jun 2001 19:03:08 +0200 (MET DST) Date: Thu, 7 Jun 2001 19:03:08 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010607092827.A13198@lucon.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 On Thu, 7 Jun 2001, H . J . Lu wrote: > See my post on the binutils mailing list. I have reason to believe > that it also misassembles the mips kernel with certain configuration. I've seen them. Unfortunately I'm far from being a BFD expert, so it's not immediately obvious to me whether your fixes are fine or not. And I can't dig into BFD at the moment. Just make sure your changes adhere to the ELF ABI, both the generic part and the MIPS supplement. Also note I can only run-time test MIPS I, so if there is something wrong with higher ISAs, I wouldn't even notice unless I happen to study a dissassembly of affected code. The kernel crashes for me weirdly from time to time, indeed. I have a reproducible test case as well. I don't speak up on details, though, as I now have outdated binutils as well as the kernel I'm running is still 2.4.0-test12. Any conclusions will be sent to the list once collected and if relevant to current versions, of course. -- + 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 Jun 7 10:13:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57HDai28381 for linux-mips-outgoing; Thu, 7 Jun 2001 10:13:36 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57HDZh28378 for ; Thu, 7 Jun 2001 10:13:36 -0700 Received: from www.cgsoftware.com ([208.155.65.221]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05661 for ; Thu, 7 Jun 2001 10:13:10 -0700 (PDT) mail_from (dan@www.cgsoftware.com) Received: from localhost (dan@localhost) by www.cgsoftware.com (8.9.3/8.9.3) with ESMTP id MAA14317; Thu, 7 Jun 2001 12:56:14 -0400 Date: Thu, 7 Jun 2001 12:56:14 -0400 (EDT) From: Daniel Berlin To: "H . J . Lu" cc: GDB , , Subject: Re: stabs or ecoff for Linux/mips In-Reply-To: <20010607093149.B13198@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk STABS definitely. On Thu, 7 Jun 2001, H . J . Lu wrote: > What is the better debug format for Linux/mips in the terms of gdb > and binutils, stabs or ecoff? I know the future is dwarf2. But I need > something stable now. Since Linux/x86 uses stabs, I lean toward to > stabs. Any comments? > > > H.J. > From owner-linux-mips@oss.sgi.com Thu Jun 7 10:35:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57HZpN29027 for linux-mips-outgoing; Thu, 7 Jun 2001 10:35:51 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57HZnh29024 for ; Thu, 7 Jun 2001 10:35:49 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id C47F4125BA; Thu, 7 Jun 2001 10:35:47 -0700 (PDT) Date: Thu, 7 Jun 2001 10:35:46 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com Cc: GDB , linux-mips@oss.sgi.com Subject: Patch: Switch Linux/mips to stabs Message-ID: <20010607103546.A14690@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Based on the recommendations from Ian and Daniel, I checked in the following patches to switch Linux/mips to stabs. Thanks. --- 2001-06-07 H.J. Lu * elf32-mips.c (_bfd_mips_elf_object_p): Set the bad symtab for SGI only. * config.bfd: Remove ecoff from Linux/mips. Index: config.bfd =================================================================== RCS file: /cvs/src/src/bfd/config.bfd,v retrieving revision 1.58 diff -u -p -r1.58 config.bfd --- config.bfd 2001/06/02 17:32:09 1.58 +++ config.bfd 2001/06/07 17:28:52 @@ -675,7 +675,7 @@ case "${targ}" in ;; mips*el*-*-linux-gnu*) targ_defvec=bfd_elf32_tradlittlemips_vec - targ_selvecs="bfd_elf32_tradbigmips_vec bfd_elf64_tradlittlemips_vec bfd_elf64_tradbigmips_vec ecoff_little_vec ecoff_big_vec" + targ_selvecs="bfd_elf32_tradbigmips_vec bfd_elf64_tradlittlemips_vec bfd_elf64_tradbigmips_vec" ;; mips*-*-openbsd*) targ_defvec=bfd_elf32_bigmips_vec @@ -683,7 +683,7 @@ case "${targ}" in ;; mips*-*-linux-gnu*) targ_defvec=bfd_elf32_tradbigmips_vec - targ_selvecs="bfd_elf32_tradlittlemips_vec bfd_elf64_tradbigmips_vec bfd_elf64_tradlittlemips_vec ecoff_big_vec ecoff_little_vec" + targ_selvecs="bfd_elf32_tradlittlemips_vec bfd_elf64_tradbigmips_vec bfd_elf64_tradlittlemips_vec" ;; mn10200-*-*) targ_defvec=bfd_elf32_mn10200_vec Index: elf32-mips.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-mips.c,v retrieving revision 1.97 diff -u -p -r1.97 elf32-mips.c --- elf32-mips.c 2001/05/23 17:26:35 1.97 +++ elf32-mips.c 2001/06/07 17:29:12 @@ -2331,7 +2331,8 @@ _bfd_mips_elf_object_p (abfd) /* Irix 5 and 6 is broken. Object file symbol tables are not always sorted correctly such that local symbols precede global symbols, and the sh_info field in the symbol table is not always right. */ - elf_bad_symtab (abfd) = true; + if (SGI_COMPAT(abfd)) + elf_bad_symtab (abfd) = true; bfd_default_set_arch_mach (abfd, bfd_arch_mips, elf_mips_mach (elf_elfheader (abfd)->e_flags)); 2001-06-07 H.J. Lu * configure.in: Use MIPS_STABS_ELF for Linux/mips and remove ecoff emulation. * configure: Regenerate. Index: configure.in =================================================================== RCS file: /cvs/src/src/gas/configure.in,v retrieving revision 1.69 diff -u -p -r1.69 configure.in --- configure.in 2001/05/25 07:21:00 1.69 +++ configure.in 2001/06/07 17:20:54 @@ -346,8 +346,13 @@ changequote([,])dnl mips-*-irix*) fmt=ecoff ;; mips-*-lnews*) fmt=ecoff em=lnews ;; mips-*-riscos*) fmt=ecoff ;; - mips-*-sysv4*MP* | mips-*-linux-gnu* | mips-*-gnu*) + mips-*-sysv4*MP* | mips-*-gnu*) fmt=elf em=tmips ;; + mips-*-linux-gnu*) + fmt=elf em=tmips + AC_DEFINE(MIPS_STABS_ELF, 1, + [Use ELF stabs for MIPS, not ECOFF stabs]) + ;; mips-*-sysv*) fmt=ecoff ;; mips-*-elf* | mips-*-rtems* | mips-*-openbsd*) fmt=elf ;; @@ -602,8 +607,8 @@ changequote([,])dnl case ${generic_target}-${fmt} in mips-*-irix5*-*) emulation="mipsbelf mipslelf mipself mipsbecoff mipslecoff mipsecoff" ;; mips-*-linux-gnu*-*) case "$endian" in - big) emulation="mipsbelf mipslelf mipself mipsbecoff mipslecoff mipsecoff" ;; - *) emulation="mipslelf mipsbelf mipself mipslecoff mipsbecoff mipsecoff" ;; + big) emulation="mipsbelf mipslelf mipself" ;; + *) emulation="mipslelf mipsbelf mipself" ;; esac ;; mips-*-lnews*-ecoff) ;; mips-*-*-ecoff) case "$endian" in From owner-linux-mips@oss.sgi.com Thu Jun 7 10:38:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Hc9P29260 for linux-mips-outgoing; Thu, 7 Jun 2001 10:38:09 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Hc8h29257 for ; Thu, 7 Jun 2001 10:38:08 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B9E71125BA; Thu, 7 Jun 2001 10:38:07 -0700 (PDT) Date: Thu, 7 Jun 2001 10:38:07 -0700 From: "H . J . Lu" To: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Patch: Fix gas/mips testsuite for linux/mips Message-ID: <20010607103807.A14754@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Since linux/mips is switched to stabs, line number is not longer supported. I checked in the following patch. H.J. ---- 2001-06-07 H.J. Lu * gas/mips/mips.exp: Set xfail for "lineno" on Linux/mips. Index: gas/mips/mips.exp =================================================================== RCS file: /cvs/src/src/gas/testsuite/gas/mips/mips.exp,v retrieving revision 1.10 diff -u -p -r1.10 mips.exp --- mips.exp 2001/06/07 00:57:10 1.10 +++ mips.exp 2001/06/07 17:16:29 @@ -88,6 +88,8 @@ if { [istarget mips*-*-*] } then { run_dump_test "mips4010" run_dump_test "mips4650" run_dump_test "mips4100" + # Linux uses ELF stabs, which doesn't support line number. + setup_xfail "mips*-*-*linux*" run_dump_test "lineno" run_dump_test "sync" run_dump_test "mips32" From owner-linux-mips@oss.sgi.com Thu Jun 7 11:13:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IDPA32132 for linux-mips-outgoing; Thu, 7 Jun 2001 11:13:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IDOh32127 for ; Thu, 7 Jun 2001 11:13:24 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 46A66125BA; Thu, 7 Jun 2001 11:13:24 -0700 (PDT) Date: Thu, 7 Jun 2001 11:13:24 -0700 From: "H . J . Lu" To: Andrew Cagney Cc: GDB , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips Message-ID: <20010607111324.C15440@lucon.org> References: <20010607093332.C13198@lucon.org> <3B1FC23D.3020900@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1FC23D.3020900@cygnus.com>; from ac131313@cygnus.com on Thu, Jun 07, 2001 at 02:04:45PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote: > dwarf2 > stabs > not ecoff (er, isn't ecoff an object format like coff? I guess you mean > something like Dwarf1) Ok. I meant stabs in ecoff vs. stabs in elf. > > As Dan will probably be quick to point out, you'll get better C++ > support with dwarf2. > > There is nothing unstable about dwarf2. GDB's support for it has been > around for yonks. It is more than just gdb. For a complete dwarf2 support, we need gcc and binutils. I don't think we are there yet, at least not with stable release. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 7 11:20:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IKFQ00837 for linux-mips-outgoing; Thu, 7 Jun 2001 11:20:15 -0700 Received: from foghorn.airs.com (IDENT:qmailr@foghorn.airs.com [63.201.54.26]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IKEh00830 for ; Thu, 7 Jun 2001 11:20:14 -0700 Received: (qmail 22746 invoked by uid 10); 7 Jun 2001 18:20:09 -0000 Received: (qmail 24662 invoked by uid 269); 7 Jun 2001 18:20:05 -0000 Mail-Followup-To: ac131313@cygnus.com, gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com, hjl@lucon.org From: Ian Lance Taylor To: "H . J . Lu" Cc: Andrew Cagney , GDB , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips References: <20010607093332.C13198@lucon.org> <3B1FC23D.3020900@cygnus.com> <20010607111324.C15440@lucon.org> Date: 07 Jun 2001 11:20:05 -0700 In-Reply-To: <20010607111324.C15440@lucon.org> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" writes: > On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote: > > dwarf2 > > stabs > > not ecoff (er, isn't ecoff an object format like coff? I guess you mean > > something like Dwarf1) ECOFF is both an object file format and a debugging format. Irix (at least Irix 5) uses the ECOFF debugging format with the ELF object file format (ECOFF smuggled in ELF). The ECOFF debugging format can also be called mdebug or Third Eye, but most people simply call it ECOFF. Ian From owner-linux-mips@oss.sgi.com Thu Jun 7 11:24:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IOpe01336 for linux-mips-outgoing; Thu, 7 Jun 2001 11:24:51 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IOnh01333 for ; Thu, 7 Jun 2001 11:24:49 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA08493 for ; Thu, 7 Jun 2001 22:25:02 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id WAA03747 for linux-mips@oss.sgi.com; Thu, 7 Jun 2001 22:16:03 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA25523 for ; Thu, 7 Jun 2001 22:21:21 +0400 (MSD) Message-ID: <3B203741.8020608@niisi.msk.ru> Date: Thu, 07 Jun 2001 22:24:01 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Make dep doesn't work properly Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. I have the linux-2.4.3 kernel from your CVS. It looks like the 'make dep' comand doesn't work properly on my machine. With the mkdep.c from the linux-2.4.5 it works fine. Did anybody see the same? ----------------------------------- [linus linux_2_4_3]$ make dep if [ ! -f /extra/andreev/linux/linux_2_4_3/include/asm-mips/offset.h ]; then \ touch /extra/andreev/linux/linux_2_4_3/include/asm-mips/offset.h; \ fi; make[1]: Entering directory `/extra/andreev/linux/linux_2_4_3/arch/mips/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/extra/andreev/linux/linux_2_4_3/arch/mips/boot' scripts/mkdep -- init/*.c > .depend --: No such file or directory find /extra/andreev/linux/linux_2_4_3/include/asm /extra/andreev/linux/linux_2_4_3/include/linux /extra/andreev/linux/linux_2_4_3/include/scsi /extra/andreev/linux/linux_2_4_3/include/net -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print | env -i PATH="/home/andreev/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/home/andreev/bin" HPATH="/extra/andreev/linux/linux_2_4_3/include" xargs scripts/mkdep -- > .hdepend --: No such file or directory --: No such file or directory --: No such file or directory make _sfdep_arch/mips/tools _sfdep_kernel _sfdep_drivers _sfdep_mm _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib _sfdep_arch/mips/math-emu _sfdep_arch/mips/baget _sfdep_arch/mips/baget/prom _sfdep_arch/mips/kernel _sfdep_arch/mips/mm _sfdep_arch/mips/lib _FASTDEP_ALL_SUB_DIRS="arch/mips/tools kernel drivers mm fs net ipc lib arch/mips/math-emu arch/mips/baget arch/mips/baget/prom arch/mips/kernel arch/mips/mm arch/mips/lib" make[1]: Entering directory `/extra/andreev/linux/linux_2_4_3' make -C arch/mips/tools fastdep make[2]: Entering directory `/extra/andreev/linux/linux_2_4_3/arch/mips/tools' /extra/andreev/linux/linux_2_4_3/scripts/mkdep -I /extra/andreev/linux/linux_2_4_3/include/asm/gcc -D__KERNEL__ -I/extra/andreev/linux/linux_2_4_3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -- offset.c > .depend -I: No such file or directory mkdep: mmap: No such device -D__KERNEL__: No such file or directory -I/extra/andreev/linux/linux_2_4_3/include: No such file or directory -Wall: No such file or directory -Wstrict-prototypes: No such file or directory -O2: No such file or directory ... ------------------------------------------------------------------------------ I use : egcs-mips-linux-1.1.2-2, make-3.78.1-4 From owner-linux-mips@oss.sgi.com Thu Jun 7 11:27:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IRfk01699 for linux-mips-outgoing; Thu, 7 Jun 2001 11:27:41 -0700 Received: from localhost.cygnus.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IReh01696 for ; Thu, 7 Jun 2001 11:27:40 -0700 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id DCD523C2B; Thu, 7 Jun 2001 14:27:39 -0400 (EDT) Message-ID: <3B1FC79B.3080104@cygnus.com> Date: Thu, 07 Jun 2001 14:27:39 -0400 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD 1.5W macppc; en-US; rv:0.9) Gecko/20010605 X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" Cc: GDB , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips References: <20010607093332.C13198@lucon.org> <3B1FC23D.3020900@cygnus.com> <20010607111324.C15440@lucon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Thu, Jun 07, 2001 at 02:04:45PM -0400, Andrew Cagney wrote: > >> dwarf2 >> stabs >> not ecoff (er, isn't ecoff an object format like coff? I guess you mean >> something like Dwarf1) > > > Ok. I meant stabs in ecoff vs. stabs in elf. dwarf2 in elf Again ``There is nothing unstable about dwarf2 in elf''. Andrew From owner-linux-mips@oss.sgi.com Thu Jun 7 11:42:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IgWx02874 for linux-mips-outgoing; Thu, 7 Jun 2001 11:42:32 -0700 Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IgWh02869 for ; Thu, 7 Jun 2001 11:42:32 -0700 Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id LAA05700 for ; Thu, 7 Jun 2001 11:42:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 7 Jun 2001 11:40:49 +0100 Received: from apple.com (melos.apple.com [17.202.41.123]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id LAA04270; Thu, 7 Jun 2001 11:42:30 -0700 (PDT) Message-ID: <3B1FCAC9.2110A024@apple.com> Date: Thu, 07 Jun 2001 11:41:13 -0700 From: Stan Shebs X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: GDB , binutils@lucon.org, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips References: <20010607093149.B13198@lucon.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" wrote: > > What is the better debug format for Linux/mips in the terms of gdb > and binutils, stabs or ecoff? I know the future is dwarf2. But I need > something stable now. Since Linux/x86 uses stabs, I lean toward to > stabs. Any comments? Go with stabs and ELF. Neither ecoff's base file format nor the debug info were particularly well-documented (I remember some of the bits in GNU being figured out by reverse engineering!), perpetuating it will just make your life more difficult in the long run. It will also be easier to move to dwarf2 when the opportunity arises. Stan From owner-linux-mips@oss.sgi.com Thu Jun 7 11:46:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IktB03284 for linux-mips-outgoing; Thu, 7 Jun 2001 11:46:55 -0700 Received: from mail.eclipse.net (mail.eclipse.net [207.207.192.13]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Ikrh03281 for ; Thu, 7 Jun 2001 11:46:54 -0700 Received: from hork (njc2-04-152.dial.eclipse.net [207.207.240.152]) by mail.eclipse.net (8.9.1a/8.9.1) with ESMTP id OAA07288; Thu, 7 Jun 2001 14:46:45 -0400 (EDT) Received: from molotov by hork with local (Exim 3.22 #1 (Debian)) id 1584nw-0001Nl-00; Thu, 07 Jun 2001 14:46:48 -0400 Date: Thu, 7 Jun 2001 14:46:48 -0400 To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Newbie Question, Please help Message-ID: <20010607144648.A4949@hork> Mail-Followup-To: Robert Rusek , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <002e01c0ee0c$1572fed0$031010ac@rjrtower> User-Agent: Mutt/1.3.18i From: Chris Ruvolo Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 05, 2001 at 03:08:42PM -0700, Robert Rusek wrote: > It gets the address then claims it is sending the vmlinux file via tftp. > On the SGI it just times out. >=20 > Any advice, pointers, etc would be greatly appreciated. =46rom the HOWTO (http://www.oss.sgi.com/mips/mips-howto.html): 7.6 My machine doesn't download the kernel when I try to netboot Your machine is replying to the BOOTP packets (you may verify this using a packet sniffer like tcpdump or ethereal), but doesn't download the kernel from your BOOTP server. This happens if your boot server is running a kernel of the 2.3 series or higher. The problem may be circumvented by doing a "echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc" as root on your boot server. Good luck. -Chris --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7H8wYKO6EG1hc77ERAhQsAKDwU2CtU74sc/SaIRL/W1b0zwD6tgCg62wr tH5lGE15Eo4DGW/83qmCVeo= =jnHZ -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-linux-mips@oss.sgi.com Thu Jun 7 12:05:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57J5Gm04915 for linux-mips-outgoing; Thu, 7 Jun 2001 12:05:16 -0700 Received: from debian (adsl-138-89-121-166.nnj.adsl.bellatlantic.net [138.89.121.166]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57J5Fh04912 for ; Thu, 7 Jun 2001 12:05:16 -0700 Received: by debian (Postfix, from userid 1000) id D68122FD0; Thu, 7 Jun 2001 15:05:14 -0400 (EDT) X-Draft-From: ("nnimap+dberlin.org:gdb" 2978) To: Stan Shebs Cc: "H . J . Lu" , GDB , binutils@lucon.org, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips References: <20010607093149.B13198@lucon.org> <3B1FCAC9.2110A024@apple.com> From: Daniel Berlin Date: 07 Jun 2001 15:05:14 -0400 In-Reply-To: <3B1FCAC9.2110A024@apple.com> (Stan Shebs's message of "Thu, 07 Jun 2001 11:41:13 -0700") Message-ID: <873d9cnmad.fsf@cgsoftware.com> Lines: 31 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Stan Shebs writes: > "H . J . Lu" wrote: >> >> What is the better debug format for Linux/mips in the terms of gdb >> and binutils, stabs or ecoff? I know the future is dwarf2. But I need >> something stable now. Since Linux/x86 uses stabs, I lean toward to >> stabs. Any comments? > > Go with stabs and ELF. Neither ecoff's base file format nor the debug > info were particularly well-documented (I remember some of the bits in > GNU being figured out by reverse engineering!), perpetuating it will > just make your life more difficult in the long run. It will also be > easier to move to dwarf2 when the opportunity arises. mdebugread is also an evil piece of code. It duplicates almost all of buildsym. I've had to perform *major* surgery (and am still not done yet) to do the block hash table thing. > > Stan -- "I looked out my apartment window, and I saw a bird wearing sneakers and a button saying, "I ain't flying no where." I said, "What's your problem buddy?" He said, "I'm sick of this stuff -- winter here, summer there, winter here, summer there. I don't know who thought this stuff up, but it certainly wasn't a bird." I said, "Well, I was just making breakfast, come on in. Want some eggs? Sorry." "-Steven Wright From owner-linux-mips@oss.sgi.com Thu Jun 7 12:24:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JO8u07902 for linux-mips-outgoing; Thu, 7 Jun 2001 12:24:08 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JO7h07896 for ; Thu, 7 Jun 2001 12:24:07 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4BA5D125BA; Thu, 7 Jun 2001 12:24:06 -0700 (PDT) Date: Thu, 7 Jun 2001 12:24:05 -0700 From: "H . J . Lu" To: Daniel Berlin Cc: Stan Shebs , GDB , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips Message-ID: <20010607122405.A16724@lucon.org> References: <20010607093149.B13198@lucon.org> <3B1FCAC9.2110A024@apple.com> <873d9cnmad.fsf@cgsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <873d9cnmad.fsf@cgsoftware.com>; from dan@cgsoftware.com on Thu, Jun 07, 2001 at 03:05:14PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 03:05:14PM -0400, Daniel Berlin wrote: > Stan Shebs writes: > > > "H . J . Lu" wrote: > >> > >> What is the better debug format for Linux/mips in the terms of gdb > >> and binutils, stabs or ecoff? I know the future is dwarf2. But I need > >> something stable now. Since Linux/x86 uses stabs, I lean toward to > >> stabs. Any comments? > > > > Go with stabs and ELF. Neither ecoff's base file format nor the debug > > info were particularly well-documented (I remember some of the bits in > > GNU being figured out by reverse engineering!), perpetuating it will > > just make your life more difficult in the long run. It will also be > > easier to move to dwarf2 when the opportunity arises. > > mdebugread is also an evil piece of code. That matches my own experiences. In case you haven't noticed, I have checked in patches to switch Linux/mips to stabs in ELF :-). H.J. From owner-linux-mips@oss.sgi.com Thu Jun 7 12:28:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JSBO08800 for linux-mips-outgoing; Thu, 7 Jun 2001 12:28:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JSAh08796 for ; Thu, 7 Jun 2001 12:28:10 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04848 for ; Thu, 7 Jun 2001 12:28:09 -0700 (PDT) mail_from (drow@nevyn.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 1585Hp-0006Hp-00; Thu, 07 Jun 2001 12:17:41 -0700 Date: Thu, 7 Jun 2001 12:17:41 -0700 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010607121741.A24155@nevyn.them.org> References: <20010606132402.A27901@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jun 07, 2001 at 12:37:27PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 12:37:27PM +0200, Maciej W. Rozycki wrote: > On Wed, 6 Jun 2001, Daniel Jacobowitz wrote: > > > > Make sure your kernel is flushing the icache right. > > > > Hmm, thanks, I'll check. I don't think that's it, though. > > This happened to me once. Otherwise, it looks like gdb doesn't recognize > a breakpoint for some reason -- possibly it places it at a wrong address. > It shouldn't be difficult to debug -- you get information of the address > the trap happened. Wouldn't you hope? No such luck. Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 1024 (LWP 89)] 0x00000000 in ?? () I blame the threads handling, which I'm only about half through debugging. > > Nope. It's based mostly on the same 4.17 patch from David Miller, and > > some bits from Ralf, all marked as assigned to the FSF (though I'm not > > sure if that ever actually happened); I'll straighten out copyright > > once I've got the whole thing done. > > You need to contact David, then. Yep, I'm going to do that. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@oss.sgi.com Thu Jun 7 12:37:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JbSU10405 for linux-mips-outgoing; Thu, 7 Jun 2001 12:37:28 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JbIh10381 for ; Thu, 7 Jun 2001 12:37:26 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA23773; Thu, 7 Jun 2001 21:35:57 +0200 (MET DST) Date: Thu, 7 Jun 2001 21:35:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips In-Reply-To: <20010607121741.A24155@nevyn.them.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 On Thu, 7 Jun 2001, Daniel Jacobowitz wrote: > > This happened to me once. Otherwise, it looks like gdb doesn't recognize > > a breakpoint for some reason -- possibly it places it at a wrong address. > > It shouldn't be difficult to debug -- you get information of the address > > the trap happened. > > Wouldn't you hope? No such luck. > > Program received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 1024 (LWP 89)] > 0x00000000 in ?? () Then patch your kernel to display the address. It's trivial. See do_bp() in arch/mips/kernel/traps.c. > I blame the threads handling, which I'm only about half through > debugging. Ah, threads... They might be completely non-fuctional on MIPS/Linux. I've never run threaded programs on MIPS/Linux, but such trivial users as ls appear to work. -- + 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 Jun 7 12:52:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Jq5j12353 for linux-mips-outgoing; Thu, 7 Jun 2001 12:52:05 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Jq4h12342 for ; Thu, 7 Jun 2001 12:52:04 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03816 for ; Thu, 7 Jun 2001 12:51:59 -0700 (PDT) mail_from (drow@nevyn.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 1585fE-0006d6-00; Thu, 07 Jun 2001 12:41:52 -0700 Date: Thu, 7 Jun 2001 12:41:52 -0700 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: New toolchain for Linux/mips Message-ID: <20010607124152.A25474@nevyn.them.org> References: <20010607121741.A24155@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jun 07, 2001 at 09:35:57PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 09:35:57PM +0200, Maciej W. Rozycki wrote: > On Thu, 7 Jun 2001, Daniel Jacobowitz wrote: > > > > This happened to me once. Otherwise, it looks like gdb doesn't recognize > > > a breakpoint for some reason -- possibly it places it at a wrong address. > > > It shouldn't be difficult to debug -- you get information of the address > > > the trap happened. > > > > Wouldn't you hope? No such luck. > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > [Switching to Thread 1024 (LWP 89)] > > 0x00000000 in ?? () > > Then patch your kernel to display the address. It's trivial. See > do_bp() in arch/mips/kernel/traps.c. Good idea. Thanks. > > I blame the threads handling, which I'm only about half through > > debugging. > > Ah, threads... They might be completely non-fuctional on MIPS/Linux. > I've never run threaded programs on MIPS/Linux, but such trivial users as > ls appear to work. They work, with a couple of kernel patches and a couple of library patches. I'm sorting through them right now. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team From owner-linux-mips@linux-xfs.sgi.com Fri Jun 8 18:51:11 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591pBlS009346 for linux-mips-outgoing; Fri, 8 Jun 2001 18:51:11 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591pA3D009336 for ; Fri, 8 Jun 2001 18:51:10 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id SAA23742 for ; Fri, 8 Jun 2001 18:51:03 -0700 (PDT) Received: from hubble.mips.com (hubble [192.168.10.76]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id SAA28534 for ; Fri, 8 Jun 2001 18:51:01 -0700 (PDT) Received: from hubble (hubble [192.168.10.76]) by hubble.mips.com (8.9.3/8.9.0) with SMTP id SAA11162 for ; Fri, 8 Jun 2001 18:51:01 -0700 (PDT) Message-Id: <200106090151.SAA11162@hubble.mips.com> Date: Fri, 8 Jun 2001 18:51:01 -0700 (PDT) From: Carsten Langgaard Reply-To: Carsten Langgaard Subject: emulate_load_store_insn To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: b1eslZYE+V5oLyBKYLmx3g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Can anyone please explain the whole deal with the emulate_load_store_insn function in arch/mips/kernel/unaligned.c. Isn't there a potential hole there, where a user application makes an illegal memory access to an unaligned address and then the kernel tries to emulate that and crashes. It also look like the MF_FIXADE flag is set by default, why is that ? Shouldn't one suppose to make a syscall setting this MF_FIXADE flag ? /Carsten From owner-linux-mips@linux-xfs.sgi.com Fri Jun 8 19:46:25 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f592kPBB013385 for linux-mips-outgoing; Fri, 8 Jun 2001 19:46:25 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.waldorf-gmbh.de (u-160-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.160]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f592kJ3D013369 for ; Fri, 8 Jun 2001 19:46:22 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f592jKl12272; Sat, 9 Jun 2001 04:45:20 +0200 Date: Sat, 9 Jun 2001 04:45:20 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: emulate_load_store_insn Message-ID: <20010609044520.A12255@bacchus.dhis.org> References: <200106090151.SAA11162@hubble.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: <200106090151.SAA11162@hubble.mips.com>; from carstenl@mips.com on Fri, Jun 08, 2001 at 06:51:01PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jun 08, 2001 at 06:51:01PM -0700, Carsten Langgaard wrote: > Can anyone please explain the whole deal with the emulate_load_store_insn > function in arch/mips/kernel/unaligned.c. Some software does of unaligned accesses. Typical userspace example is fdisk and the network stack which generally tries hard to avoid unaligned loads and stores may make unaligned stores at times though. > Isn't there a potential hole there, where a user application makes an illegal > memory access to an unaligned address and then the kernel tries to emulate > that and crashes. The addresses are verified the same way as any other userspace address passed to the kernel. > It also look like the MF_FIXADE flag is set by default, why is that ? Two reasons 1) other MIPS OSes such as Risc/OS and IRIX also do it 2) crappy software doesn't know how to enable this feature ... > Shouldn't one suppose to make a syscall setting this MF_FIXADE flag ? Sysmips(2) allows to toggle this flag. Ralf From owner-linux-mips@linux-xfs.sgi.com Fri Jun 8 22:50:38 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595ocrn026381 for linux-mips-outgoing; Fri, 8 Jun 2001 22:50:38 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595ob3D026378 for ; Fri, 8 Jun 2001 22:50:37 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7D05D125BA; Fri, 8 Jun 2001 22:50:36 -0700 (PDT) Date: Fri, 8 Jun 2001 22:50:36 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Does anyone know this? Message-ID: <20010608225036.A4162@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does anyone know this? http://mail-index.netbsd.org/port-mips/2001/05/24/0002.html Do we still have the pthread problems mentioned there? H.J. From owner-linux-mips@linux-xfs.sgi.com Sat Jun 9 07:24:18 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59EOIeT012088 for linux-mips-outgoing; Sat, 9 Jun 2001 07:24:18 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.waldorf-gmbh.de (u-42-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.42]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59EOC3D012070 for ; Sat, 9 Jun 2001 07:24:15 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f59EO4o08938; Sat, 9 Jun 2001 16:24:04 +0200 Date: Sat, 9 Jun 2001 16:24:04 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: Does anyone know this? Message-ID: <20010609162404.A8916@bacchus.dhis.org> References: <20010608225036.A4162@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010608225036.A4162@lucon.org>; from hjl@lucon.org on Fri, Jun 08, 2001 at 10:50:36PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jun 08, 2001 at 10:50:36PM -0700, H . J . Lu wrote: > Does anyone know this? > > http://mail-index.netbsd.org/port-mips/2001/05/24/0002.html > > Do we still have the pthread problems mentioned there? The varargs bug afair was fixed in glibc by Chris Johnson and Andreas Jaeger and Maciej recently posted a patch for the kernel to linux-kernel. Ralf From owner-linux-mips@linux-xfs.sgi.com Sat Jun 9 10:15:30 2001 Received: (from majordomo@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59HFUsA028344 for linux-mips-outgoing; Sat, 9 Jun 2001 10:15:30 -0700 X-Authentication-Warning: linux-xfs.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59HFS3D028337 for ; Sat, 9 Jun 2001 10:15:29 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 418187F9; Sat, 9 Jun 2001 19:15:26 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 4B7FB42D0; Sat, 9 Jun 2001 19:15:36 +0200 (CEST) Date: Sat, 9 Jun 2001 19:15:36 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Current cvs does not compile Message-ID: <20010609191535.A6407@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, it seems the current cvs doesnt compile - It seems some include strategies are broken. asm-mips/io.h needs _CACHE_UNCACHED which is defined in pgtable.h pgtable.h needs mm_struct which is defined in shed.h Index: include/asm-mips/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips/io.h,v retrieving revision 1.19 diff -u -r1.19 io.h --- include/asm-mips/io.h 2001/06/06 23:46:17 1.19 +++ include/asm-mips/io.h 2001/06/09 17:12:48 @@ -14,6 +14,7 @@ #include #include #include +#include /* * Slowdown I/O port space accesses for antique hardware. Index: include/asm-mips/pgtable.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pgtable.h,v retrieving revision 1.54 diff -u -r1.54 pgtable.h --- include/asm-mips/pgtable.h 2001/06/05 23:24:07 1.54 +++ include/asm-mips/pgtable.h 2001/06/09 17:12:50 @@ -17,6 +17,7 @@ #include #include #include +#include /* Cache flushing: * Now it fails for me in pgtable.h as it needs "high_memory" which should be defined as extern (from mm/memory.c" 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 Sat Jun 9 18:56:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A1uOu08648 for linux-mips-outgoing; Sat, 9 Jun 2001 18:56:24 -0700 Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A1uNV08645 for ; Sat, 9 Jun 2001 18:56:23 -0700 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Sat, 09 Jun 2001 18:56:20 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from postal.sibyte.com (IDENT:postfix@[10.21.128.60]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA19080 for ; Sat, 9 Jun 2001 18:56:22 -0700 (PDT) Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 3637E1595F for ; Sat, 9 Jun 2001 18:56:22 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 5E169686D; Sat, 9 Jun 2001 18:56:16 -0700 (PDT) From: "Justin Carlson" Reply-to: carlson@sibyte.com Organization: Sibyte To: linux-mips@oss.sgi.com Subject: mips64 SMP for non-ip27 platforms Date: Sat, 9 Jun 2001 18:53:53 -0700 X-Mailer: KMail [version 1.0.29] MIME-Version: 1.0 Message-ID: <01060918561505.00831@plugh.sibyte.com> X-WSS-ID: 173C0C4E19626-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk A while back someone mentioned that they were doing some work on the mips64 SMP front to seperate the ip27 specific code from the platform-independent code. I'm doing some similar things and would like to coordinate, but I can't find the original mail, nor remember who the sender was. So, anyone doing stuff like this, I'd enjoy hearing from you. -Justin carlson@sibyte.com From owner-linux-mips@oss.sgi.com Sat Jun 9 20:45:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A3jjU10742 for linux-mips-outgoing; Sat, 9 Jun 2001 20:45:45 -0700 Received: from dea.waldorf-gmbh.de (u-121-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A3jgV10739 for ; Sat, 9 Jun 2001 20:45:42 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5A3jaX25446; Sun, 10 Jun 2001 05:45:36 +0200 Date: Sun, 10 Jun 2001 05:45:36 +0200 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: mips64 SMP for non-ip27 platforms Message-ID: <20010610054536.C13553@bacchus.dhis.org> References: <01060918561505.00831@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: <01060918561505.00831@plugh.sibyte.com>; from carlson@sibyte.com on Sat, Jun 09, 2001 at 06:53:53PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Jun 09, 2001 at 06:53:53PM -0700, Justin Carlson wrote: > A while back someone mentioned that they were doing some > work on the mips64 SMP front to seperate the ip27 specific > code from the platform-independent code. I'm doing some similar > things and would like to coordinate, but I can't find the original > mail, nor remember who the sender was. > > So, anyone doing stuff like this, I'd enjoy hearing from you. We're painfully aware that the mips64 port is currently fairly IP27-centric at some points ... Ralf From owner-linux-mips@oss.sgi.com Sat Jun 9 20:58:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A3wq211009 for linux-mips-outgoing; Sat, 9 Jun 2001 20:58:52 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A3wqV11006 for ; Sat, 9 Jun 2001 20:58:52 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 5F3D63E90 for ; Sat, 9 Jun 2001 20:55:39 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 7F23114181; Sat, 9 Jun 2001 20:56:42 -0700 (PDT) Date: Sat, 9 Jun 2001 20:56:41 -0700 From: Keith M Wesolowski To: linux-mips@oss.sgi.com Subject: gcc 3.0 sig11 Message-ID: <20010609205641.A27425@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk For the past few weeks (0422 is ok, 0528 and 0609 are not) gcc built for mips-linux takes sig11 during build. Specifically at /s/crossdev-build/src/gcc-3.0-20010609/gcc/unwind-dw2-fde.c:1001: Internal error: Segmentation fault. I know at least one other person has seen this. Anybody produced a patch or done any debugging on this? -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Sat Jun 9 21:05:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A45tk11182 for linux-mips-outgoing; Sat, 9 Jun 2001 21:05:55 -0700 Received: from straylight.cyberhqz.com (root@h24-78-251-235.vc.shawcable.net [24.78.251.235]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A45sV11179 for ; Sat, 9 Jun 2001 21:05:54 -0700 Received: (from rmurray@localhost) by straylight.cyberhqz.com (8.9.3/8.9.3/Debian 8.9.3-21) id VAA32615 for linux-mips@oss.sgi.com; Sat, 9 Jun 2001 21:05:54 -0700 From: Ryan Murray Date: Sat, 9 Jun 2001 21:05:54 -0700 To: linux-mips@oss.sgi.com Subject: Re: gcc 3.0 sig11 Message-ID: <20010609210554.A12904@cyberhqz.com> References: <20010609205641.A27425@foobazco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010609205641.A27425@foobazco.org>; from wesolows@foobazco.org on Sat, Jun 09, 2001 at 08:56:41PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 09, 2001 at 08:56:41PM -0700, Keith M Wesolowski wrote: > For the past few weeks (0422 is ok, 0528 and 0609 are not) gcc built > for mips-linux takes sig11 during build. Specifically at > /s/crossdev-build/src/gcc-3.0-20010609/gcc/unwind-dw2-fde.c:1001: > Internal error: Segmentation fault. >=20 > I know at least one other person has seen this. Anybody produced a > patch or done any debugging on this? I filed a bug and got the response that they do have successful build logs, so they think it is fixed. --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7IvIhN2Dbz/1mRasRAsM5AKCu4l9OsaTXYif/7GGprYbLPnqegACgqYO1 YJVYjYVAP4Uqr+A0sDFwymQ= =39se -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-linux-mips@oss.sgi.com Sun Jun 10 08:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AF0nE25394 for linux-mips-outgoing; Sun, 10 Jun 2001 08:00:49 -0700 Received: from tricom.net ([200.50.8.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AF0mV25391 for ; Sun, 10 Jun 2001 08:00:48 -0700 Received: from vaio (net0port187.tricom.net [200.50.9.4]) by tricom.net (8.11.1/8.11.1) with SMTP id f5A6vfZ11335 for ; Sun, 10 Jun 2001 10:57:41 +0400 (GMT) Message-ID: <007901c0f1bd$ff8827c0$0b0932c8@vaio> Reply-To: =?iso-8859-1?Q?Manuel_Poueri=E9?= From: =?iso-8859-1?Q?Manuel_Poueri=E9?= To: Subject: Date: Sun, 10 Jun 2001 10:59:48 -0400 Organization: CP&M MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C0F19C.775930E0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C0F19C.775930E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsuscribe correo@cpmsa.com ------=_NextPart_000_0076_01C0F19C.775930E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsuscribe correo@cpmsa.com
= ------=_NextPart_000_0076_01C0F19C.775930E0-- From owner-linux-mips@oss.sgi.com Sun Jun 10 15:03:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AM3rM05586 for linux-mips-outgoing; Sun, 10 Jun 2001 15:03:53 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AM3oV05569 for ; Sun, 10 Jun 2001 15:03:51 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id E24A67DD; Mon, 11 Jun 2001 00:03:47 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 02C2B42C3; Mon, 11 Jun 2001 00:03:59 +0200 (CEST) Date: Mon, 11 Jun 2001 00:03:59 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Kernel crash on boot with current cvs (todays) Message-ID: <20010611000359.A25631@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, i just tried to boot an Indy of mine with the current cvs (from this morning) and it crashes ksymoops 2.4.1 on i686 2.2.18ext3. Options used -v vmlinux-2.4.3 (specified) -K (specified) -L (specified) -o lib/modules/2.4.3 (specified) -m System.map-2.4.3 (specified) No modules in ksyms, skipping objects kernel BUG at semaphore.c:235! Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c $0 : 00000000 3004fc00 0000001f 89d0e000 $4 : 00000017 00000000 00000001 88669440 $8 : 0000000a 8814cc50 00000000 00000000 $12: 00000000 8814c870 fffffff9 0000000a $16: 8866977c 00000000 89d0e000 88669784 $20: 89d0ff04 89d0ff00 89d0fea0 00000009 $24: 89d0fcf2 ffffffff $28: 89d0e000 89d0fdd8 7fff7ba0 8800f02c epc : 8800f02c Using defaults from ksymoops -t elf32-little -a unknown Status: 3004fc03 Cause : 3000000c Process start-stop-daem (pid: 211, stackpage=89d0e000) Stack: 88106e30 88106e48 000000eb 00000000 8866977c 88669760 8800ed54 2aba3820 00000000 885d1280 88064cf0 88065cd4 00000000 89d0e000 88669784 88669784 fffffffe 88669760 89e24640 8866977c 89d0ff04 88064b50 89e24460 8bd1d8e0 89d0ff00 89d0ff00 89e24640 89d0ff00 89e24640 8b6d400d 89d0ff00 89d0ff04 880655d0 88065598 89e24640 88060cf4 89e24460 8b6d400d 8bd1d960 8bd1d960 88053f88 ... Call Trace: [<88106e30>] [<88106e48>] [<8800ed54>] [<88064cf0>] [<88065cd4>] [<88064b50>] [<880655d0>] [<88065598>] [<88060cf4>] [<88053f88>] [<88054074>] [<88054cc0>] [<88054c68>] [<88053794>] [<88050414>] [<8800fe08>] [<8800fe08>] Code: 240600eb 0e007d99 00000000 26040010 24050003 0e007085 24060001 0a003bf9 Error (Oops_bfd_perror): scan_arch for specified architecture Success >>RA; 8800f02c <__rwsem_wake+b8/dc> >>???; 8800f02c <__rwsem_wake+b8/dc> <===== Trace; 88106e30 <__gnu_compiled_c+d90/1204> Trace; 88106e48 <__gnu_compiled_c+da8/1204> Trace; 8800ed54 <__down_read+1dc/1e4> Trace; 88064cf0 Trace; 88065cd4 Trace; 88064b50 Trace; 880655d0 Trace; 88065598 Trace; 88060cf4 Trace; 88053f88 Trace; 88054074 Trace; 88054cc0 <__user_walk+78/94> Trace; 88054c68 <__user_walk+20/94> Trace; 88053794 Trace; 88050414 Trace; 8800fe08 Trace; 8800fe08 1 error issued. Results may not be reliable. -- 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 Sun Jun 10 20:52:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B3q5115957 for linux-mips-outgoing; Sun, 10 Jun 2001 20:52:05 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B3q2V15954 for ; Sun, 10 Jun 2001 20:52:03 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5B3r4e10207; Mon, 11 Jun 2001 13:53:04 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florian Lohoff cc: linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-reply-to: Your message of "Mon, 11 Jun 2001 00:03:59 +0200." <20010611000359.A25631@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Jun 2001 13:53:04 +1000 Message-ID: <10206.992231584@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 11 Jun 2001 00:03:59 +0200, Florian Lohoff wrote: >i just tried to boot an Indy of mine with the current cvs (from this >morning) and it crashes > >ksymoops 2.4.1 on i686 2.2.18ext3. Options used >Using defaults from ksymoops -t elf32-little -a unknown >Error (Oops_bfd_perror): scan_arch for specified architecture Success I cannot help with the oops but your ksymoops run has problems. When doing cross system oops debugging, you need to specify the target machine and architecture with the -t and -a flags. Otherwise ksymoops defaults to the current machine. Adding -t and -a will fix the above error and decode the code: line. From owner-linux-mips@oss.sgi.com Sun Jun 10 23:27:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B6ReZ01825 for linux-mips-outgoing; Sun, 10 Jun 2001 23:27:40 -0700 Received: from dea.waldorf-gmbh.de (u-91-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B6RaV01814 for ; Sun, 10 Jun 2001 23:27:37 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5B4gnO15489; Mon, 11 Jun 2001 06:42:49 +0200 Date: Mon, 11 Jun 2001 06:42:49 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010611064249.A15039@bacchus.dhis.org> References: <20010611000359.A25631@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: <20010611000359.A25631@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Jun 11, 2001 at 12:03:59AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 465 Lines: 14 On Mon, Jun 11, 2001 at 12:03:59AM +0200, Florian Lohoff wrote: > Hi, > i just tried to boot an Indy of mine with the current cvs (from this > morning) and it crashes > No modules in ksyms, skipping objects > kernel BUG at semaphore.c:235! > Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c This is a known and yet unresolved problem. Yet I'm surprised - so far I've only seen this problem on mips64. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 11 07:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BE2mm24367 for linux-mips-outgoing; Mon, 11 Jun 2001 07:02:48 -0700 Received: from exchmail.aivia.net ([63.90.239.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BE2lV24364 for ; Mon, 11 Jun 2001 07:02:47 -0700 Received: by EXCHMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 09:07:02 -0500 Message-ID: From: "Jordan, Shane" To: linux-mips@oss.sgi.com Subject: Date: Mon, 11 Jun 2001 09:07:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 29 Lines: 1 unsuscribe sjordan@aivia.net From owner-linux-mips@oss.sgi.com Mon Jun 11 07:50:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BEoQW32060 for linux-mips-outgoing; Mon, 11 Jun 2001 07:50:26 -0700 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BEoKV32041; Mon, 11 Jun 2001 07:50:20 -0700 Received: by bunny.shuttle.de (Postfix, from userid 112) id 950124AAAA; Mon, 11 Jun 2001 16:50:19 +0200 (CEST) Date: Mon, 11 Jun 2001 16:50:19 +0200 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010611165019.A17263@bunny.shuttle.de> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20010611064249.A15039@bacchus.dhis.org> User-Agent: Mutt/1.3.18i From: borenius@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11195 Lines: 275 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, On Mon, Jun 11, 2001 at 06:42:49AM +0200, Ralf Baechle wrote: > On Mon, Jun 11, 2001 at 12:03:59AM +0200, Florian Lohoff wrote: > > > Hi, > > i just tried to boot an Indy of mine with the current cvs (from this > > morning) and it crashes > > > No modules in ksyms, skipping objects > > kernel BUG at semaphore.c:235! > > Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c > > This is a known and yet unresolved problem. Yet I'm surprised - so far > I've only seen this problem on mips64. > > Ralf Just FYI: the same happens on our Indy, see trace.txt and boot.txt. Hope it helps... Regards Raoul --------------------------------------------------------------------- Raoul Gunnar Borenius Deutsches Forschungsnetz e.V. WiNShuttle Lindenspürstr.32, 70176 Stuttgart Phone : +49 711 63314-206 FAX: +49 711 63314-133 E-Mail : borenius@shuttle.de http://www.shuttle.de --------------------------------------------------------------------- --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="trace.txt" ksymoops 2.4.1 on mips 2.4.3-cvs20010611. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-cvs20010611/ (default) -m /boot/System.map-2.4.3-cvs20010611 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Starting periodic command scheduler: cronkernel BUG at semaphore.c:235! Unable to handle kernel paging request at virtual address 00000000, epc == 8800eed0, ra == 8800eed0 $0 : 00000000 1000fc00 0000001f 00000001 $4 : 00000017 0000001f 8f626000 886603a0 $8 : 000d1b70 0000003c 00079c00 00000000 $12: 88157570 fffffff9 ffffffff 8f627ce2 $16: 8866059c 00000000 8f627f00 886605a4 $20: 8f627f04 8f627f00 8f627f04 00000009 $24: 00000002 0000000a $28: 8f626000 8f627dd0 7fff7bb0 8800eed0 epc : 8800eed0 Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: 1000fc03 Cause : 0000000c Process start-stop-daem (pid: 129, stackpage=8f626000) Stack: 881080e0 881081c4 000000eb 00000002 8866059c 8f626000 8800eb5c 8806854c 00000000 8ff862e0 88067590 00000000 00000000 8f626000 886605a8 886605a8 fffffffe 88660580 8f627f00 8866059c 880672ac 880679c4 8f8deca0 8f9ad8a0 8f627f00 8f9ada20 00000000 8f9ada20 8f627f00 8814200d 8f627e98 8f627f00 88067e28 88067dc4 8f9ada20 88060364 8f627e98 8f627f00 8f8deca0 8f8deca0 8f9ada20 ... Call Trace: [<881080e0>] [<881081c4>] [<8800eb5c>] [<8806854c>] [<88067590>] [<880672ac>] [<880679c4>] [<88067e28>] [<88067dc4>] [<88060364>] [<88053da4>] [<88054488>] [<88053070>] [<8804fdf8>] [<8804fe50>] [<8800fca8>] [<8800fca8>] Code: 24a581c4 0e007c56 240600eb 26040014 24050003 0e006f4a 24060001 8fbf0018 >>RA; 8800eed0 <__rwsem_wake+98/c8> >>PC; 8800eed0 <__rwsem_wake+98/c8> <===== Trace; 881080e0 Trace; 881081c4 Trace; 8800eb5c <__down_read+84/194> Trace; 8806854c Trace; 88067590 Trace; 880672ac Trace; 880679c4 Trace; 88067e28 Trace; 88067dc4 Trace; 88060364 Trace; 88053da4 Trace; 88054488 <__user_walk+5c/90> Trace; 88053070 Trace; 8804fdf8 Trace; 8804fe50 Trace; 8800fca8 Trace; 8800fca8 Code; 8800eec4 <__rwsem_wake+8c/c8> 0000000000000000 <_PC>: Code; 8800eec4 <__rwsem_wake+8c/c8> 0: 24a581c4 addiu $a1,$a1,-32316 Code; 8800eec8 <__rwsem_wake+90/c8> 4: 0e007c56 jal 801f158 <_PC+0x801f158> 9002e01c Code; 8800eecc <__rwsem_wake+94/c8> 8: 240600eb li $a2,235 Code; 8800eed0 <__rwsem_wake+98/c8> <===== c: ae200000 sw $zero,0($s1) <===== Code; 8800eed4 <__rwsem_wake+9c/c8> 10: 26040014 addiu $a0,$s0,20 Code; 8800eed8 <__rwsem_wake+a0/c8> 14: 24050003 li $a1,3 Code; 8800eedc <__rwsem_wake+a4/c8> 18: 0e006f4a jal 801bd28 <_PC+0x801bd28> 9002abec Code; 8800eee0 <__rwsem_wake+a8/c8> 1c: 24060001 li $a2,1 Code; 8800eee4 <__rwsem_wake+ac/c8> 20: 8fbf0018 lw $ra,24($sp) 2 warnings issued. Results may not be reliable. --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="boot.txt" >> printenv SystemPartition=scsi(0)disk(1)rdisk(0)partition(8) OSLoadPartition=/dev/sda1 OSLoader=vmlinux OSLoadFilename=/vmlinux AutoLoad=Yes TimeZone=PST8PDT console=d diskless=0 dbaud=9600 volume=2 sgilogo=y autopower=y eaddr=08:00:69:08:4f:b2 ConsoleOut=serial(0) ConsoleIn=serial(0) cpufreq=100 >> boot ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4600 FPU ICACHE DCACHE Loading R4000 MMU routines. CPU revision is: 00002020 Primary instruction cache 16kb, linesize 32 bytes. Primary data cache 16kb, linesize 32 bytes. Linux version 2.4.3-cvs20010611 (raoul@bunny) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #12 Mon Jun 11 16:22:41 CEST 2001 MC: SGI memory controller Revision 3 Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 00001000 @ 00001000 (reserved) memory: 00179000 @ 08002000 (reserved) memory: 005c5000 @ 0817b000 (usable) memory: 000c0000 @ 08740000 (ROM data) memory: 07800000 @ 08800000 (usable) On node 0 totalpages: 65536 zone(0): 65536 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 Calibrating system timer... 500000 [100.00 MHz CPU] Console: colour dummy device 80x25 zs0: console input Console: ttyS0 (Zilog8530) Calibrating delay loop... 99.73 BogoMIPS Memory: 124408k/128788k available (1231k kernel code, 4380k reserved, 77k data, 52k init) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) VFS: Diskquotas version dquot_6.4.0 initialized Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 initialize_kbd: Keyboard reset failed, no ACK pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: queued sectors max/low 82378kB/27459kB, 256 slots per queue sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:08:4f:b2 SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Jun 11 2001 at 16:24:01 scsi0 : SGI WD93 sending SDTR 0103013f0csync_xfer=2c Vendor: CONNER Model: CFP2105S 2.14GB Rev: 2B4B Type: Direct-Access ANSI SCSI revision: 02 sending SDTR 0103013f0csync_xfer=2c Vendor: SGI Model: IBMDSAS-3540 Rev: S47K Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0 SCSI device sda: 4194304 512-byte hdwr sectors (2147 MB) Partition check: sda: sda1 sda2 sda3 sda4 SCSI device sdb: 1070496 512-byte hdwr sectors (548 MB) sdb: sdb1 sdb2 sdb3 SGI Zilog8530 serial driver version 1.00 tty00 at 0xbfbd9830 (irq = 21) is a Zilog8530 tty01 at 0xbfbd9838 (irq = 21) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing prom memory: 768kb freed Freeing unused kernel memory: 52k freed INIT: version 2.78 booting Activating swap... Adding Swap: 138992k swap-space (priority -1) Checking root file system... Parallelizing fsck version 1.20 (25-May-2001) /dev/sda1: clean, 28429/243840 files, 138949/487542 blocks Checking all file systems... Parallelizing fsck version 1.20 (25-May-2001) Setting kernel variables. Mounting local filesystems... tmpfs on /dev/shm type shm (rw) Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Mon Jun 11 16:31:33 CEST 2001 Cleaning: /tmp /var/lock /var/run. Initializing random number generator... done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting internet superserver: inetd. Starting OpenBSD Secure Shell server: sshd. Starting NTP server: ntpd. Starting periodic command scheduler: cronkernel BUG at semaphore.c:235! Unable to handle kernel paging request at virtual address 00000000, epc == 8800eed0, ra == 8800eed0 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 1000fc00 0000001f 00000001 $4 : 00000017 0000001f 8f626000 886603a0 $8 : 000d1b70 0000003c 00079c00 00000000 $12: 88157570 fffffff9 ffffffff 8f627ce2 $16: 8866059c 00000000 8f627f00 886605a4 $20: 8f627f04 8f627f00 8f627f04 00000009 $24: 00000002 0000000a $28: 8f626000 8f627dd0 7fff7bb0 8800eed0 epc : 8800eed0 Status: 1000fc03 Cause : 0000000c Process start-stop-daem (pid: 129, stackpage=8f626000) Stack: 881080e0 881081c4 000000eb 00000002 8866059c 8f626000 8800eb5c 8806854c 00000000 8ff862e0 88067590 00000000 00000000 8f626000 886605a8 886605a8 fffffffe 88660580 8f627f00 8866059c 880672ac 880679c4 8f8deca0 8f9ad8a0 8f627f00 8f9ada20 00000000 8f9ada20 8f627f00 8814200d 8f627e98 8f627f00 88067e28 88067dc4 8f9ada20 88060364 8f627e98 8f627f00 8f8deca0 8f8deca0 8f9ada20 ... Call Trace: [<881080e0>] [<881081c4>] [<8800eb5c>] [<8806854c>] [<88067590>] [<880672ac>] [<880679c4>] [<88067e28>] [<88067dc4>] [<88060364>] [<88053da4>] [<88054488>] [<88053070>] [<8804fdf8>] [<8804fe50>] [<8800fca8>] [<8800fca8>] Code: 24a581c4 0e007c56 240600eb 26040014 24050003 0e006f4a 24060001 8fbf0018 --2fHTh5uZTiUOsy+g-- From owner-linux-mips@oss.sgi.com Mon Jun 11 10:12:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHClH12519 for linux-mips-outgoing; Mon, 11 Jun 2001 10:12:47 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHAVV12396; Mon, 11 Jun 2001 10:10:32 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA04812; Mon, 11 Jun 2001 19:08:59 +0200 (MET DST) Date: Mon, 11 Jun 2001 19:08:58 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: Does anyone know this? In-Reply-To: <20010609162404.A8916@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 Content-Length: 823 Lines: 21 On Sat, 9 Jun 2001, Ralf Baechle wrote: > > Does anyone know this? > > > > http://mail-index.netbsd.org/port-mips/2001/05/24/0002.html > > > > Do we still have the pthread problems mentioned there? > > The varargs bug afair was fixed in glibc by Chris Johnson and Andreas > Jaeger and Maciej recently posted a patch for the kernel to linux-kernel. We have a _test_and_set() implementation in glibc for some time now, actually -- what is problematic (buggy), is the underlying kernel emulation for MIPS I systems. There is no consensus if the patch is fine, due to a bit non-standard calling convention, I'm afraid. -- + 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 Jun 11 11:25:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BIPFJ17917 for linux-mips-outgoing; Mon, 11 Jun 2001 11:25:15 -0700 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BIPCV17906 for ; Mon, 11 Jun 2001 11:25:13 -0700 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA22787 for ; Mon, 11 Jun 2001 11:25:10 -0700 (MST)] Received: [from craius.cportcorp.com ([10.14.72.61]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA05430 for ; Mon, 11 Jun 2001 11:25:10 -0700 (MST)] Received: from cportcorp.com (FRANZ [10.14.73.85]) by craius.cportcorp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MTALJHMT; Mon, 11 Jun 2001 14:24:11 -0400 Message-ID: <3B250CF9.8C966EC9@cportcorp.com> Date: Mon, 11 Jun 2001 14:24:57 -0400 From: Bob Zulawnik X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hjl@lucon.org CC: gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: stabs or ecoff for Linux/mips Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1219 Lines: 24 "H . J . Lu" wrote: > That matches my own experiences. In case you haven't noticed, I > have checked in patches to switch Linux/mips to stabs in ELF :-). For what it's worth : stabs format cannot express certain types of debug info that mdebug (used in ecoff) can. An example of that is so-called PDRs (Procedure Description Records) - they describe frame size, register masks etc.). Thus, in order to obtain information about a function (e.g. when setting a breakpoint at the entrance to a function), gdb has to resort to heuristics and read the function prolog, trying to figure out what registers are saved where, when is the frame setup complete etc. There are assumptions made in that gdb code (e.g. mips32_heuristic_proc_desc() and mips16_heuristic_proc_desc()) that have to match exactly what the compiler has done (as in "the occurrence of instruction 'x' signifies this"). Thus, using the stabs opens the debugger to potential misinterpretations of the code generated by the compiler (e.g. when a new type of frame is introduced, or maybe with some weird optimization). I understand that there are other arguments for using stabs and that dwarf2 is the long-term goal, this is just an FYI. Bob Zulawnik From owner-linux-mips@oss.sgi.com Mon Jun 11 12:05:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BJ5h424511 for linux-mips-outgoing; Mon, 11 Jun 2001 12:05:43 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BJ5WV24477 for ; Mon, 11 Jun 2001 12:05:32 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0D99E125BA; Mon, 11 Jun 2001 12:05:28 -0700 (PDT) Date: Mon, 11 Jun 2001 12:05:28 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.11.90.0.15 is released. Message-ID: <20010611120528.A31648@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11076 Lines: 411 This is the beta release of binutils 2.11.90.0.15 for Linux, which is based on binutils 2001 0610 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.15 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.15.tar.gz. Source code. 2. binutils-2.11.90.0.8-2.11.90.0.15.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.15-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.15.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 06/11/2001 From owner-linux-mips@oss.sgi.com Mon Jun 11 12:12:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BJCeM25657 for linux-mips-outgoing; Mon, 11 Jun 2001 12:12:40 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BJCdV25646 for ; Mon, 11 Jun 2001 12:12:39 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2FC8B803; Mon, 11 Jun 2001 21:12:38 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 533AA42C5; Mon, 11 Jun 2001 21:12:51 +0200 (CEST) Date: Mon, 11 Jun 2001 21:12:51 +0200 From: Florian Lohoff To: Keith Owens Cc: linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010611211251.A5749@paradigm.rfc822.org> References: <20010611000359.A25631@paradigm.rfc822.org> <10206.992231584@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <10206.992231584@ocs4.ocs-net>; from kaos@ocs.com.au on Mon, Jun 11, 2001 at 01:53:04PM +1000 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1020 Lines: 24 On Mon, Jun 11, 2001 at 01:53:04PM +1000, Keith Owens wrote: > On Mon, 11 Jun 2001 00:03:59 +0200, > Florian Lohoff wrote: > >i just tried to boot an Indy of mine with the current cvs (from this > >morning) and it crashes > > > >ksymoops 2.4.1 on i686 2.2.18ext3. Options used > >Using defaults from ksymoops -t elf32-little -a unknown > >Error (Oops_bfd_perror): scan_arch for specified architecture Success > > I cannot help with the oops but your ksymoops run has problems. When > doing cross system oops debugging, you need to specify the target > machine and architecture with the -t and -a flags. Otherwise ksymoops > defaults to the current machine. Adding -t and -a will fix the above > error and decode the code: line. Nope - it wont as it strictly uses the /usr/bin/objdump - You have to set the environment var "KSYMOOPS_OBJDUMP" 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 Jun 11 17:04:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C04uP04972 for linux-mips-outgoing; Mon, 11 Jun 2001 17:04:56 -0700 Received: from mail.technodada.com ([209.124.136.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C04tV04967 for ; Mon, 11 Jun 2001 17:04:55 -0700 Received: from mail.technodada.com (mail.technodada.com [209.124.136.148]) by mail.technodada.com (Postfix) with ESMTP id B4245CBB84 for ; Mon, 11 Jun 2001 16:04:53 -0800 (AKDT) Date: Mon, 11 Jun 2001 16:04:53 -0800 (AKDT) From: Donovan Arellano To: linux-mips@oss.sgi.com Subject: cross compile doc on sgi's site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f5C04tV04968 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 532 Lines: 15 Hi - there use to be a cross compile doc on the linux mips site. Does anyone have a copy of it or can you point me to the location that it lives. -- As ever, yr. obdt. (but pitiless) svnt., Donovan Arellano -- GNUPG Key: www.technodada.com/~donovan/gpg.key | Web Address: http://www.technodada.com/~donovan | / \ ASCII Ribbon Email Address: donovan@technodada.com | \ / Campaign ICBM Address: 61° 10' 24" N 149° 53' 34" W | X Against Chance favors the prepared mind. | / \ HTML Mail From owner-linux-mips@oss.sgi.com Mon Jun 11 17:59:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C0xiq13282 for linux-mips-outgoing; Mon, 11 Jun 2001 17:59:44 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C0xgV13279 for ; Mon, 11 Jun 2001 17:59:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id DAA19410; Tue, 12 Jun 2001 03:01:32 +0200 (MET DST) Date: Tue, 12 Jun 2001 03:01:32 +0200 (MET DST) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Keith Owens , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-Reply-To: <20010611211251.A5749@paradigm.rfc822.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 Content-Length: 651 Lines: 17 On Mon, 11 Jun 2001, Florian Lohoff wrote: > Nope - it wont as it strictly uses the /usr/bin/objdump - You have to > set the environment var "KSYMOOPS_OBJDUMP" Good it has a way to override the default, but wouldn't looking for objdump in the PATH variable (i.e. using execvp()) be more reasonable? This way ksymoops would always work in a cross-compilation environment (i.e. with $tooldir/bin preceding $bindir in PATH). Just an ad-hoc idea... -- + 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 Jun 11 18:02:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C12Ds13730 for linux-mips-outgoing; Mon, 11 Jun 2001 18:02:13 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C12CV13719 for ; Mon, 11 Jun 2001 18:02:12 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id BC4723E90; Mon, 11 Jun 2001 17:58:44 -0700 (PDT) Date: Mon, 11 Jun 2001 17:58:44 -0700 From: Keith M Wesolowski To: Donovan Arellano Cc: linux-mips@oss.sgi.com Subject: Re: cross compile doc on sgi's site Message-ID: <20010611175844.A6610@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1378 Lines: 34 On Mon, Jun 11, 2001 at 04:04:53PM -0800, Donovan Arellano wrote: > Hi - there use to be a cross compile doc on the linux mips site. Does > anyone have a copy of it or can you point me to the location that it > lives. There's a section on cross compiling in the FAQ/HOWTO at http://oss.sgi.com/mips/mips-howto.html (section 10) which has been there all along. Or, you might see http://foobazco.org/~wesolows/mips-cross.html. Of course you can always just follow standard GNU practice and pass the requisite --target=mips-linux to configure and see what happens (hint: it's close to all you need). Or, you can pick up the make-cross package from ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/, which will do all the work for you, or one of a dozen similar pieces of hackware out there. Or read one of any number of other Google-accessible information repositories with each author's own little tricks and tips for building cross-toolchains. There's really no excuse for anyone to keep asking about building cross compilers. Really, this stuff is as easy to find on the net as pr0n and pyramid schemes. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Mon Jun 11 18:04:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C14cN14168 for linux-mips-outgoing; Mon, 11 Jun 2001 18:04:38 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C14bV14162 for ; Mon, 11 Jun 2001 18:04:37 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 09BF23E90; Mon, 11 Jun 2001 18:01:09 -0700 (PDT) Date: Mon, 11 Jun 2001 18:01:09 -0700 From: Keith M Wesolowski To: "Maciej W. Rozycki" Cc: Florian Lohoff , Keith Owens , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010611180109.B6610@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 798 Lines: 16 On Tue, Jun 12, 2001 at 03:01:32AM +0200, Maciej W. Rozycki wrote: > Good it has a way to override the default, but wouldn't looking for > objdump in the PATH variable (i.e. using execvp()) be more reasonable? > This way ksymoops would always work in a cross-compilation environment > (i.e. with $tooldir/bin preceding $bindir in PATH). Actually, it would probably be preferable to try first arch-os-objdump and maybe one or two other similar variants and then search the path. Supposing I have multiple cross environments on my machine... -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Mon Jun 11 18:20:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C1KoC16871 for linux-mips-outgoing; Mon, 11 Jun 2001 18:20:50 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C1KlV16865 for ; Mon, 11 Jun 2001 18:20:48 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id DAA19671; Tue, 12 Jun 2001 03:22:15 +0200 (MET DST) Date: Tue, 12 Jun 2001 03:22:15 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Keith M Wesolowski cc: Florian Lohoff , Keith Owens , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-Reply-To: <20010611180109.B6610@foobazco.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 Content-Length: 736 Lines: 18 On Mon, 11 Jun 2001, Keith M Wesolowski wrote: > Actually, it would probably be preferable to try first arch-os-objdump > and maybe one or two other similar variants and then search the path. Sure, if you know how to guess the names (I don't). The PATH approach should work well if you choose one cross environment at a time. > Supposing I have multiple cross environments on my machine... Does anyone have only a single one? ;-) (Having a complete mipsel-linux, a basic alpha-linux and a few obscure partial environments...) -- + 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 Jun 11 19:04:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C24cc21978 for linux-mips-outgoing; Mon, 11 Jun 2001 19:04:38 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C24YV21975 for ; Mon, 11 Jun 2001 19:04:35 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5C25Jq01119; Tue, 12 Jun 2001 12:05:19 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs From: Keith Owens To: "Maciej W. Rozycki" cc: Florian Lohoff , Keith Owens , linux-mips@oss.sgi.com, kaos@ocs4.ocs-net.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-reply-to: Your message of "Tue, 12 Jun 2001 03:01:32 +0200." Date: Tue, 12 Jun 2001 12:05:19 +1000 Message-ID: <1118.992311519@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 906 Lines: 17 > On Mon, 11 Jun 2001, Florian Lohoff wrote: > > > Nope - it wont as it strictly uses the /usr/bin/objdump - You have to > > set the environment var "KSYMOOPS_OBJDUMP" > > Good it has a way to override the default, but wouldn't looking for > objdump in the PATH variable (i.e. using execvp()) be more reasonable? > This way ksymoops would always work in a cross-compilation environment > (i.e. with $tooldir/bin preceding $bindir in PATH). I originally designed ksymoops that way but there are so many different methods of naming the binutils for cross compile environments that I gave up. Using the path runs the risk of picking random versions of nm and objdump and still not being correct. Anybody running cross compile has to specify parameters for System.map, ksyms and objects, so adding paths for binutils is a small change and is the only way to guarantee that the correct versions are used. From owner-linux-mips@oss.sgi.com Mon Jun 11 21:03:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C43EU31157 for linux-mips-outgoing; Mon, 11 Jun 2001 21:03:14 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C43DV31152 for ; Mon, 11 Jun 2001 21:03:13 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 99ACA125BA; Mon, 11 Jun 2001 21:03:11 -0700 (PDT) Date: Mon, 11 Jun 2001 21:03:11 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: A new mips toolchain is available Message-ID: <20010611210311.A8768@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 548 Lines: 16 I put my new mips toolchain at http://ftp.kernel.org/pub/linux/devel/binutils/mips/ There are source rpms for RedHat 7.1. They may only be built correctly with rpm, especially binutils. I can provide mips and mipsel binaries rpms for them. But it will take at least a few days. BTW, my toolchain is for the SVR4 MIPS ABI. I don't know how compatible it is with the IRIX ABI. Old IRIX ABI binaries seem to run fine. But I don't know abour the IRIX ABI DSOs. Also my glibc is compiled with -mmips2 since kernel cannot handle mips I glibc. H.J. From owner-linux-mips@oss.sgi.com Tue Jun 12 03:21:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CALCA24142 for linux-mips-outgoing; Tue, 12 Jun 2001 03:21:12 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CAL3V24116; Tue, 12 Jun 2001 03:21:03 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 207DB7F6; Tue, 12 Jun 2001 12:21:02 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 84CF842C5; Tue, 12 Jun 2001 12:09:27 +0200 (CEST) Date: Tue, 12 Jun 2001 12:09:27 +0200 From: Florian Lohoff To: Raoul Borenius Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010612120927.B8798@paradigm.rfc822.org> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> <20010611165019.A17263@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010611165019.A17263@bunny.shuttle.de>; from borenius@shuttle.de on Mon, Jun 11, 2001 at 04:50:19PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1034 Lines: 23 On Mon, Jun 11, 2001 at 04:50:19PM +0200, Raoul Borenius wrote: > Linux version 2.4.3-cvs20010611 (raoul@bunny) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #12 Mon Jun 11 16:22:41 CEST 2001 > MC: SGI memory controller Revision 3 I got a hint that it might be the compile to produce this bug - I was suggested to use some gcc 3.0 prerelease. I now checked again and i am already using some gcc 3.0 Linux version 2.4.3 (flo@paradigm) (gcc version 3.0 20010303 (prerelease)) #1 Mon Jun 11 00:27:09 CEST 2001 (flo@paradigm)~# mips-linux-gcc -v Reading specs from /usr/local/lib/gcc-lib/mips-linux/3.0/specs Configured with: ./configure --prefix=/usr/local --target=mips-linux --enable-languages=c --with-newlib --disable-shared gcc version 3.0 20010303 (prerelease) (flo@paradigm)~# mips-linux-as -v GNU assembler version 2.11.90 (mips-linux) using BFD version 2.11.90 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 Jun 12 04:39:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CBdgV30091 for linux-mips-outgoing; Tue, 12 Jun 2001 04:39:42 -0700 Received: from dea.waldorf-gmbh.de (u-243-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CBddV30088 for ; Tue, 12 Jun 2001 04:39:39 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5CBdPI05297; Tue, 12 Jun 2001 13:39:25 +0200 Date: Tue, 12 Jun 2001 13:39:25 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010612133925.B5106@bacchus.dhis.org> References: <20010611210311.A8768@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010611210311.A8768@lucon.org>; from hjl@lucon.org on Mon, Jun 11, 2001 at 09:03:11PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 755 Lines: 24 On Mon, Jun 11, 2001 at 09:03:11PM -0700, H . J . Lu wrote: > I put my new mips toolchain at > > http://ftp.kernel.org/pub/linux/devel/binutils/mips/ > > There are source rpms for RedHat 7.1. They may only be built correctly > with rpm, especially binutils. I can provide mips and mipsel binaries > rpms for them. But it will take at least a few days. > > BTW, my toolchain is for the SVR4 MIPS ABI. I don't know how compatible > it is with the IRIX ABI. Old IRIX ABI binaries seem to run fine. But I > don't know abour the IRIX ABI DSOs. No known issues except that modutils only works ok with SVR4 ABI flavoured binaries. > Also my glibc is compiled with -mmips2 since kernel cannot handle mips I > glibc. It's noticable faster also ... Ralf From owner-linux-mips@oss.sgi.com Tue Jun 12 04:53:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CBrLK31234 for linux-mips-outgoing; Tue, 12 Jun 2001 04:53:21 -0700 Received: from dea.waldorf-gmbh.de (u-243-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CBrIV31228 for ; Tue, 12 Jun 2001 04:53:19 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5CBr6G26225; Tue, 12 Jun 2001 13:53:06 +0200 Date: Tue, 12 Jun 2001 13:53:06 +0200 From: Ralf Baechle To: Florian Lohoff Cc: Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010612135306.A26214@bacchus.dhis.org> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> <20010611165019.A17263@bunny.shuttle.de> <20010612120927.B8798@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: <20010612120927.B8798@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Jun 12, 2001 at 12:09:27PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 11 On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote: > I got a hint that it might be the compile to produce this bug - I was > suggested to use some gcc 3.0 prerelease. I now checked again and i am > already using some gcc 3.0 It's not a tool related bug but a genuine kernel bug in our semaphore code. Which - unfortunately is a bit of headache to fix but is more or less the #1 on the list of my instabilities right now. Ralf From owner-linux-mips@oss.sgi.com Tue Jun 12 09:37:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CGbNW30183 for linux-mips-outgoing; Tue, 12 Jun 2001 09:37:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CGbGV30180; Tue, 12 Jun 2001 09:37:16 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7D21D125BA; Tue, 12 Jun 2001 09:37:15 -0700 (PDT) Date: Tue, 12 Jun 2001 09:37:15 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010612093715.A20012@lucon.org> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> <20010611165019.A17263@bunny.shuttle.de> <20010612120927.B8798@paradigm.rfc822.org> <20010612135306.A26214@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: <20010612135306.A26214@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jun 12, 2001 at 01:53:06PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 981 Lines: 24 On Tue, Jun 12, 2001 at 01:53:06PM +0200, Ralf Baechle wrote: > On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote: > > > I got a hint that it might be the compile to produce this bug - I was > > suggested to use some gcc 3.0 prerelease. I now checked again and i am > > already using some gcc 3.0 > > It's not a tool related bug but a genuine kernel bug in our semaphore code. > Which - unfortunately is a bit of headache to fix but is more or less the #1 > on the list of my instabilities right now. I have some kernel crashes which are cured by some gcc/binutils changes which I don't believe should make any differences. I thought I could take out the mips64 and -march patches. But wtithout them, the user applications seem ok, but the kernel crashes in all different places. I have to put them back in. They may be kernel bugs and my gcc/binutils changes may just hide them. BTW, what is the current 2.4 kernel patches for Algorithmics P6032? Thanks. H.J. From owner-linux-mips@oss.sgi.com Tue Jun 12 09:40:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CGewb30455 for linux-mips-outgoing; Tue, 12 Jun 2001 09:40:58 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CGeuV30452; Tue, 12 Jun 2001 09:40:56 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D932E125BA; Tue, 12 Jun 2001 09:40:55 -0700 (PDT) Date: Tue, 12 Jun 2001 09:40:55 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010612094055.B20012@lucon.org> References: <20010611210311.A8768@lucon.org> <20010612133925.B5106@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: <20010612133925.B5106@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jun 12, 2001 at 01:39:25PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1141 Lines: 32 On Tue, Jun 12, 2001 at 01:39:25PM +0200, Ralf Baechle wrote: > On Mon, Jun 11, 2001 at 09:03:11PM -0700, H . J . Lu wrote: > > > I put my new mips toolchain at > > > > http://ftp.kernel.org/pub/linux/devel/binutils/mips/ > > > > There are source rpms for RedHat 7.1. They may only be built correctly > > with rpm, especially binutils. I can provide mips and mipsel binaries > > rpms for them. But it will take at least a few days. > > > > BTW, my toolchain is for the SVR4 MIPS ABI. I don't know how compatible > > it is with the IRIX ABI. Old IRIX ABI binaries seem to run fine. But I > > don't know abour the IRIX ABI DSOs. > > No known issues except that modutils only works ok with SVR4 ABI flavoured > binaries. FYI, my glibc includes * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Commented out. * sysdeps/mips/rtld-ldscript.in: Removed. * sysdeps/mips/rtld-parms: Likewise. * sysdeps/mips/mips64/rtld-parms: Likewise. * sysdeps/mips/mipsel/rtld-parms: Likewise. As I mentioned before, the resulting glibc works fine with the IRIX ABI executables. But I have no ideas about DSOs. H.J. From owner-linux-mips@oss.sgi.com Tue Jun 12 12:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJC1u02966 for linux-mips-outgoing; Tue, 12 Jun 2001 12:12:01 -0700 Received: from dea.waldorf-gmbh.de (u-238-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJBwV02963 for ; Tue, 12 Jun 2001 12:11:59 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5CJBpw28194; Tue, 12 Jun 2001 21:11:51 +0200 Date: Tue, 12 Jun 2001 21:11:51 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010612211151.A27552@bacchus.dhis.org> References: <20010611210311.A8768@lucon.org> <20010612133925.B5106@bacchus.dhis.org> <20010612094055.B20012@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010612094055.B20012@lucon.org>; from hjl@lucon.org on Tue, Jun 12, 2001 at 09:40:55AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1083 Lines: 27 On Tue, Jun 12, 2001 at 09:40:55AM -0700, H . J . Lu wrote: > FYI, my glibc includes > > * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Commented out. That means elf/dl-load.c will assume zero for the load address. That will crash static programs which expect a value of 0x5ffe0000 and are trying to dlopen a shared library which uses a different value. Most popular example is rpm. So we need to keep ``#define MAP_BASE_ADDR(l) 0x5ffe0000'' in there until we've got a real fix, unfortunately. ABI requires us to properly support DT_MIPS_BASE_ADDRESS, so that needs to fixed for real anyway ... > * sysdeps/mips/rtld-ldscript.in: Removed. > * sysdeps/mips/rtld-parms: Likewise. > * sysdeps/mips/mips64/rtld-parms: Likewise. > * sysdeps/mips/mipsel/rtld-parms: Likewise. > > As I mentioned before, the resulting glibc works fine with the IRIX ABI > executables. But I have no ideas about DSOs. This rtld stuff was an IRIX-ism which made it into Linux without the necessary reflection; nothing bad should happen if we remove it. Ralf From owner-linux-mips@oss.sgi.com Tue Jun 12 12:38:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJclg03882 for linux-mips-outgoing; Tue, 12 Jun 2001 12:38:47 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJciV03878; Tue, 12 Jun 2001 12:38:44 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7CD59125BA; Tue, 12 Jun 2001 12:38:43 -0700 (PDT) Date: Tue, 12 Jun 2001 12:38:43 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010612123843.A23567@lucon.org> References: <20010611210311.A8768@lucon.org> <20010612133925.B5106@bacchus.dhis.org> <20010612094055.B20012@lucon.org> <20010612211151.A27552@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: <20010612211151.A27552@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jun 12, 2001 at 09:11:51PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 766 Lines: 21 On Tue, Jun 12, 2001 at 09:11:51PM +0200, Ralf Baechle wrote: > On Tue, Jun 12, 2001 at 09:40:55AM -0700, H . J . Lu wrote: > > > FYI, my glibc includes > > > > * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Commented out. > > That means elf/dl-load.c will assume zero for the load address. That will > crash static programs which expect a value of 0x5ffe0000 and are trying to > dlopen a shared library which uses a different value. Most popular > example is rpm. So we need to keep ``#define MAP_BASE_ADDR(l) 0x5ffe0000'' > in there until we've got a real fix, unfortunately. > > ABI requires us to properly support DT_MIPS_BASE_ADDRESS, so that needs > to fixed for real anyway ... > Please provide me some testcases. I will look into them. H.J. From owner-linux-mips@oss.sgi.com Tue Jun 12 15:33:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMXau17148 for linux-mips-outgoing; Tue, 12 Jun 2001 15:33:36 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMXZP17145 for ; Tue, 12 Jun 2001 15:33:35 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B6991125BA; Tue, 12 Jun 2001 15:33:34 -0700 (PDT) Date: Tue, 12 Jun 2001 15:33:34 -0700 From: "H . J . Lu" To: gcc-patches@gcc.gnu.org Cc: linux-mips@oss.sgi.com Subject: PATCH: Support ident for Linux/mips Message-ID: <20010612153334.A26787@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 613 Lines: 19 It brings Linux/mips closer to other Linux targets. H.J. ---- 2001-06-12 H.J. Lu * config/mips/linux.h (ASM_OUTPUT_IDENT): Defined. --- gcc/config/mips/linux.h.ident Sun Jun 10 01:02:34 2001 +++ gcc/config/mips/linux.h Sun Jun 10 01:02:53 2001 @@ -237,3 +237,8 @@ Boston, MA 02111-1307, USA. */ /* Tell function_prologue in mips.c that we have already output the .ent/.end pseudo-ops. */ #define FUNCTION_NAME_ALREADY_DECLARED + +/* Output #ident as a .ident. */ +#undef ASM_OUTPUT_IDENT +#define ASM_OUTPUT_IDENT(FILE, NAME) \ + fprintf (FILE, "\t%s\t\"%s\"\n", IDENT_ASM_OP, NAME); From owner-linux-mips@oss.sgi.com Wed Jun 13 00:59:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D7xXQ20706 for linux-mips-outgoing; Wed, 13 Jun 2001 00:59:33 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D7wuP20696 for ; Wed, 13 Jun 2001 00:59:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA10256; Wed, 13 Jun 2001 09:57:52 +0200 (MET DST) Date: Wed, 13 Jun 2001 09:57:52 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available In-Reply-To: <20010611210311.A8768@lucon.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 Content-Length: 613 Lines: 17 On Mon, 11 Jun 2001, H . J . Lu wrote: > don't know abour the IRIX ABI DSOs. Also my glibc is compiled with > -mmips2 since kernel cannot handle mips I glibc. What's the problem with the kernel? It works fine for my R3400A DECstation. Glibc is 2.2.3 as released. If there is something wrong, I definitely want to know. Of course, you might want to run MIPS II binaries for performance reasons, anyway. -- + 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 Jun 13 04:05:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DB50608342 for linux-mips-outgoing; Wed, 13 Jun 2001 04:05:00 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DB4uP08326; Wed, 13 Jun 2001 04:04:56 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 678AE7D9; Wed, 13 Jun 2001 13:04:54 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 34FA042C5; Wed, 13 Jun 2001 12:56:10 +0200 (CEST) Date: Wed, 13 Jun 2001 12:56:10 +0200 From: Florian Lohoff To: Raoul Borenius Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010613125610.A18235@paradigm.rfc822.org> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> <20010611165019.A17263@bunny.shuttle.de> <20010612120927.B8798@paradigm.rfc822.org> <20010612135306.A26214@bacchus.dhis.org> <20010613100602.A17124@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010613100602.A17124@bunny.shuttle.de>; from borenius@shuttle.de on Wed, Jun 13, 2001 at 10:06:02AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2221 Lines: 40 On Wed, Jun 13, 2001 at 10:06:02AM +0200, Raoul Borenius wrote: > Hi, > > On Tue, Jun 12, 2001 at 01:53:06PM +0200, Ralf Baechle wrote: > > On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote: > > > > > I got a hint that it might be the compile to produce this bug - I was > > > suggested to use some gcc 3.0 prerelease. I now checked again and i am > > > already using some gcc 3.0 > > > > It's not a tool related bug but a genuine kernel bug in our semaphore code. > > Which - unfortunately is a bit of headache to fix but is more or less the #1 > > on the list of my instabilities right now. > > Thanx for the quick response. Just to confirm that, here is the same crash > with the kernel from > > ftp://ftp.rfc822.org/pub/local/debian-mips/kernel/kernel-image-2.4.3-ip22-r4k.tgz > > Using ksymoops gave a lot of warnings this time. Don't know why, the > System.map should be the right one (it's out of > kernel-image-2.4.3-ip22-r4k.tgz). This is because the system map has been generated with newer binutils which always dump the addresses as 64Bit addresses. Load the system map into an text editor and delete the first ffffffff from the addresses 1,$ s/^ffffffff// > Warning (compare_maps): mismatch on symbol EISA_bus , ksyms_base says 88162b44, System.map says ffffffff88162b44. Ignoring ksyms_base entry > Warning (compare_maps): mismatch on symbol ROOT_DEV , ksyms_base says 881711e8, System.map says ffffffff881711e8. Ignoring ksyms_base entry > Warning (compare_maps): mismatch on symbol ___strtok , ksyms_base says 88194d68, System.map says ffffffff88194d68. Ignoring ksyms_base entry > Warning (compare_maps): mismatch on symbol ___wait_on_page , ksyms_base says 88032a20, System.map says ffffffff88032a20. Ignoring ksyms_base entry > Warning (compare_maps): mismatch on symbol __alloc_pages , ksyms_base says 8803de98, System.map says ffffffff8803de98. Ignoring ksyms_base entry > Warning (compare_maps): mismatch on symbol __bforget , ksyms_base says 880472b8, System.map says ffffffff880472b8. Ignoring ksyms_base entry 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 Wed Jun 13 04:35:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DBZ1X13264 for linux-mips-outgoing; Wed, 13 Jun 2001 04:35:01 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DBYtP13246; Wed, 13 Jun 2001 04:34:56 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DBYJD07965; Wed, 13 Jun 2001 21:34:20 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florian Lohoff cc: Raoul Borenius , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-reply-to: Your message of "Wed, 13 Jun 2001 12:56:10 +0200." <20010613125610.A18235@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 21:34:18 +1000 Message-ID: <7964.992432058@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 517 Lines: 13 On Wed, 13 Jun 2001 12:56:10 +0200, Florian Lohoff wrote: >> Using ksymoops gave a lot of warnings this time. Don't know why, the >> System.map should be the right one (it's out of >> kernel-image-2.4.3-ip22-r4k.tgz). > >This is because the system map has been generated with newer binutils >which always dump the addresses as 64Bit addresses. Looks like I need to add a new option to ksymoops. -T , truncate all addresses to this bit size. Added to my list for the next ksymoops release. From owner-linux-mips@oss.sgi.com Wed Jun 13 04:37:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DBbuI13810 for linux-mips-outgoing; Wed, 13 Jun 2001 04:37:56 -0700 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DBbqP13792; Wed, 13 Jun 2001 04:37:53 -0700 Received: by bunny.shuttle.de (Postfix, from userid 112) id E47DA4A868; Wed, 13 Jun 2001 13:37:51 +0200 (CEST) Date: Wed, 13 Jun 2001 13:37:51 +0200 To: Florian Lohoff Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010613133751.A18749@bunny.shuttle.de> References: <20010611000359.A25631@paradigm.rfc822.org> <20010611064249.A15039@bacchus.dhis.org> <20010611165019.A17263@bunny.shuttle.de> <20010612120927.B8798@paradigm.rfc822.org> <20010612135306.A26214@bacchus.dhis.org> <20010613100602.A17124@bunny.shuttle.de> <20010613125610.A18235@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20010613125610.A18235@paradigm.rfc822.org> User-Agent: Mutt/1.3.18i From: borenius@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4500 Lines: 110 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Jun 13, 2001 at 12:56:10PM +0200, Florian Lohoff wrote: > > > > Using ksymoops gave a lot of warnings this time. Don't know why, the > > System.map should be the right one (it's out of > > kernel-image-2.4.3-ip22-r4k.tgz). > > This is because the system map has been generated with newer binutils > which always dump the addresses as 64Bit addresses. Load the system > map into an text editor and delete the first ffffffff from the > addresses 1,$ s/^ffffffff// Should have looked closer, sorry... I've attached the output of ksymoops. Regrds Raoul --------------------------------------------------------------------- Raoul Gunnar Borenius Deutsches Forschungsnetz e.V. WiNShuttle Lindenspürstr.32, 70176 Stuttgart Phone : +49 711 63314-206 FAX: +49 711 63314-133 E-Mail : borenius@shuttle.de http://www.shuttle.de --------------------------------------------------------------------- --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="trace.txt" ksymoops 2.4.1 on mips 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Starting periodic command scheduler: cronkernel BUG at semaphore.c:235! Unable to handle kernel paging request at virtual address 00000000, epc == 8800e e5c, ra == 8800ee5c $0 : 00000000 1000fc00 0000001f 8f63a000 $4 : 00000017 00000000 00000001 8877a3a0 $8 : 0000000a 88171cc0 00000000 00000000 $12: 00000000 881718e0 fffffff9 0000000a $16: 8877a59c 00000000 8f63a000 8877a5a4 $20: 8f63bf04 8f63bf00 8f63bea0 00000009 $24: 8f63bcf2 ffffffff $28: 8f63a000 8f63bdd8 7fff7bb0 8800ee5c epc : 8800ee5c Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: 1000fc03 Cause : 0000000c Process start-stop-daem (pid: 129, stackpage=8f63a000) Stack: 88124dc0 88124dd8 000000eb 00000000 8877a59c 8877a580 8800eb84 10011f10 00000000 8ffa02c0 88063810 880647f4 00000000 8f63a000 8877a5a4 8877a5a4 fffffffe 8877a580 8fac4840 8877a59c 8f63bf04 88063670 8fac4660 8f8cec20 8f63bf00 8f63bf00 8fac4840 8f63bf00 8fac4840 8814b00d 8f63bf00 8f63bf04 880640f0 880640b8 8fac4840 8805f7f4 8fac4660 8814b00d 8f8ceca0 8f8ceca0 88052a88 ... Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8 8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880 537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [] Code: 240600eb 0e007859 00000000 26040010 24050003 0e006b45 2406 >>RA; 8800ee5c <__rwsem_wake+b8/dc> >>PC; 8800ee5c <__rwsem_wake+b8/dc> <===== Trace; 88124dc0 Trace; 88124dd8 Trace; 8800eb84 <__down_read+1dc/1e4> Trace; 88063810 Trace; 880647f4 Code; 8800ee50 <__rwsem_wake+ac/dc> 0000000000000000 <_PC>: Code; 8800ee50 <__rwsem_wake+ac/dc> 0: 240600eb li $a2,235 Code; 8800ee54 <__rwsem_wake+b0/dc> 4: 0e007859 jal 801e164 <_PC+0x801e164> 9002cfb4 Code; 8800ee58 <__rwsem_wake+b4/dc> 8: 00000000 nop Code; 8800ee5c <__rwsem_wake+b8/dc> <===== c: ae200000 sw $zero,0($s1) <===== Code; 8800ee60 <__rwsem_wake+bc/dc> 10: 26040010 addiu $a0,$s0,16 Code; 8800ee64 <__rwsem_wake+c0/dc> 14: 24050003 li $a1,3 Code; 8800ee68 <__rwsem_wake+c4/dc> 18: 0e006b45 jal 801ad14 <_PC+0x801ad14> 90029b64 Code; 8800ee6c <__rwsem_wake+c8/dc> 1c: 24060000 li $a2,0 0001 0a003b85 2 warnings issued. Results may not be reliable. --Kj7319i9nmIyA2yE-- From owner-linux-mips@oss.sgi.com Wed Jun 13 04:46:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DBkdp15302 for linux-mips-outgoing; Wed, 13 Jun 2001 04:46:39 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DBkXP15285; Wed, 13 Jun 2001 04:46:34 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DBkKA08068; Wed, 13 Jun 2001 21:46:20 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: borenius@shuttle.de (Raoul Borenius) cc: Florian Lohoff , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-reply-to: Your message of "Wed, 13 Jun 2001 13:37:51 +0200." <20010613133751.A18749@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 21:46:20 +1000 Message-ID: <8067.992432780@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1064 Lines: 18 On Wed, 13 Jun 2001 13:37:51 +0200, borenius@shuttle.de (Raoul Borenius) wrote: >Unable to handle kernel paging request at virtual address 00000000, epc == 8800e e5c, ra == 8800ee5c >Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8 8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880 >537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [] The epc line and the call trace have embedded spaces and newlines which are preventing ksymoops from doing a full conversion. Try again with the extra characters removed, i.e. Unable to handle kernel paging request at virtual address 00000000, epc == 8800e5c, ra == 8800ee5c .... Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<88063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [] Code: ... From owner-linux-mips@oss.sgi.com Wed Jun 13 05:06:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DC6nR18573 for linux-mips-outgoing; Wed, 13 Jun 2001 05:06:49 -0700 Received: from dea.waldorf-gmbh.de (u-115-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DC6hP18551 for ; Wed, 13 Jun 2001 05:06:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5DC5ph31911; Wed, 13 Jun 2001 14:05:51 +0200 Date: Wed, 13 Jun 2001 14:05:51 +0200 From: Ralf Baechle To: Keith Owens Cc: Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010613140550.B31221@bacchus.dhis.org> References: <20010613125610.A18235@paradigm.rfc822.org> <7964.992432058@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7964.992432058@ocs4.ocs-net>; from kaos@melbourne.sgi.com on Wed, Jun 13, 2001 at 09:34:18PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1032 Lines: 24 On Wed, Jun 13, 2001 at 09:34:18PM +1000, Keith Owens wrote: > On Wed, 13 Jun 2001 12:56:10 +0200, > Florian Lohoff wrote: > >> Using ksymoops gave a lot of warnings this time. Don't know why, the > >> System.map should be the right one (it's out of > >> kernel-image-2.4.3-ip22-r4k.tgz). > > > >This is because the system map has been generated with newer binutils > >which always dump the addresses as 64Bit addresses. > > Looks like I need to add a new option to ksymoops. -T , truncate > all addresses to this bit size. Added to my list for the next ksymoops > release. That can be done automatically. For 32-bit ELF files mips*-linux binutils dump some of the addresses as 32-bit addresses, some as sign-extended (!) 64-bit addresses. So ksymops should just sign extend any 32-bit addresses to 64-bit and then work on full lenght addresses. Is ksymoops able to handle 64-bit addresses when running on a 32-bit host? That is a common case for many people when decoding their MIPS oopses. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 13 05:19:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DCJVt20599 for linux-mips-outgoing; Wed, 13 Jun 2001 05:19:31 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DCJGP20558; Wed, 13 Jun 2001 05:19:17 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DCJER08466; Wed, 13 Jun 2001 22:19:14 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ralf Baechle cc: Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: ksymoops changes for mips (was Kernel crash on boot with current cvs) In-reply-to: Your message of "Wed, 13 Jun 2001 14:05:51 +0200." <20010613140550.B31221@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 22:19:14 +1000 Message-ID: <8465.992434754@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2525 Lines: 65 On Wed, 13 Jun 2001 14:05:51 +0200, Ralf Baechle wrote: >On Wed, Jun 13, 2001 at 09:34:18PM +1000, Keith Owens wrote: >> Looks like I need to add a new option to ksymoops. -T , truncate >> all addresses to this bit size. Added to my list for the next ksymoops >> release. > >That can be done automatically. For 32-bit ELF files mips*-linux binutils >dump some of the addresses as 32-bit addresses, some as sign-extended (!) >64-bit addresses. So ksymops should just sign extend any 32-bit addresses >to 64-bit and then work on full lenght addresses. Some utilities extend with leading 0, some with leading 1, some with special values (alpha). It is safer to truncate everything to the specified width instead of guessing what the extension value is. >Is ksymoops able to handle 64-bit addresses when running on a 32-bit host? >That is a common case for many people when decoding their MIPS oopses. Yes and no. The framework is there to handle 32/64 splits, sparc already uses it. mips does not currently use the framework because the oops report does not identify the machine type 32/64, MSB/LSB. We discussed this in January and I asked for a small change to mips64 oops output (below), was that ever done? ------ From: Keith Owens To: Ralf Baechle Subject: Re: ksymoops on origin Date: Sat, 06 Jan 2001 18:21:35 +1100 ksymoops is designed to run on any build arch and debug an oops report from any other target arch, as long as binutils supports the target arch. The presence or absence of __MIPSEL__ or __MIPSEB__ on the build system says nothing about the type of the failing target, ksymoops relies on text in the oops report to determine special cases like 32 bit userland and 64 bit kernel. The best option is for a mips64 kernel to indicate that it is 64 bit and its endianess. Instead of printing "epc : %016lx\n" print "epc : %016lx (64 " #ifdef __MIPSEL__ "LSB" #else "MSB" #endif ")\n" If you make that change to arch/mips64/mm/andes.c, arch/mips64/mm/r4xx0.c and any other places that print epc on mips64 then I will change ksymoops to look for (64 [LM]SB) on the epc line and decode accordingly. While we are on the topic of 32 bit userland and 64 bit kernel, how does mips64 handle modules? modutils 2.4.0 has no support for mips64, do you have any code? Also I assume that you will want the same ability as sparc, to compile modutils as a 32 bit program which can handle both 32 and 64 bit modules. From owner-linux-mips@oss.sgi.com Wed Jun 13 06:16:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DDGql29054 for linux-mips-outgoing; Wed, 13 Jun 2001 06:16:52 -0700 Received: from bunny.shuttle.de (bunny.shuttle.de [193.174.247.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DDGjP29036; Wed, 13 Jun 2001 06:16:45 -0700 Received: by bunny.shuttle.de (Postfix, from userid 112) id 3D4964A868; Wed, 13 Jun 2001 15:16:44 +0200 (CEST) Date: Wed, 13 Jun 2001 15:16:44 +0200 To: Keith Owens Cc: Florian Lohoff , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010613151644.A19513@bunny.shuttle.de> References: <8067.992432780@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8067.992432780@ocs4.ocs-net> User-Agent: Mutt/1.3.18i From: borenius@shuttle.de (Raoul Borenius) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5160 Lines: 115 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Jun 13, 2001 at 09:46:20PM +1000, Keith Owens wrote: > On Wed, 13 Jun 2001 13:37:51 +0200, > borenius@shuttle.de (Raoul Borenius) wrote: > >Unable to handle kernel paging request at virtual address 00000000, epc == 8800e e5c, ra == 8800ee5c > >Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8 8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880 > >537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [] > > The epc line and the call trace have embedded spaces and newlines which > are preventing ksymoops from doing a full conversion. Try again with > the extra characters removed, i.e. Sorry about that. These things happen every time I try to do five or more things at the same time... Hope the trace is ok now. Regards Raoul --------------------------------------------------------------------- Raoul Gunnar Borenius Deutsches Forschungsnetz e.V. WiNShuttle Lindenspürstr.32, 70176 Stuttgart Phone : +49 711 63314-206 FAX: +49 711 63314-133 E-Mail : borenius@shuttle.de http://www.shuttle.de --------------------------------------------------------------------- --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="trace.txt" ksymoops 2.4.1 on mips 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Starting periodic command scheduler: cronkernel BUG at semaphore.c:235! Unable to handle kernel paging request at virtual address 00000000, epc == 8800e e5c, ra == 8800ee5c $0 : 00000000 1000fc00 0000001f 8f63a000 $4 : 00000017 00000000 00000001 8877a3a0 $8 : 0000000a 88171cc0 00000000 00000000 $12: 00000000 881718e0 fffffff9 0000000a $16: 8877a59c 00000000 8f63a000 8877a5a4 $20: 8f63bf04 8f63bf00 8f63bea0 00000009 $24: 8f63bcf2 ffffffff $28: 8f63a000 8f63bdd8 7fff7bb0 8800ee5c epc : 8800ee5c Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: 1000fc03 Cause : 0000000c Process start-stop-daem (pid: 129, stackpage=8f63a000) Stack: 88124dc0 88124dd8 000000eb 00000000 8877a59c 8877a580 8800eb84 10011f10 00000000 8ffa02c0 88063810 880647f4 00000000 8f63a000 8877a5a4 8877a5a4 fffffffe 8877a580 8fac4840 8877a59c 8f63bf04 88063670 8fac4660 8f8cec20 8f63bf00 8f63bf00 8fac4840 8f63bf00 8fac4840 8814b00d 8f63bf00 8f63bf04 880640f0 880640b8 8fac4840 8805f7f4 8fac4660 8814b00d 8f8ceca0 8f8ceca0 88052a88 ... Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<88063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880 537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [] Code: 240600eb 0e007859 00000000 26040010 24050003 0e006b45 24060001 0a003b85 >>RA; 8800ee5c <__rwsem_wake+b8/dc> >>PC; 8800ee5c <__rwsem_wake+b8/dc> <===== Trace; 88124dc0 Trace; 88124dd8 Trace; 8800eb84 <__down_read+1dc/1e4> Trace; 88063810 Trace; 880647f4 Trace; 88063670 Trace; 880640f0 Trace; 880640b8 Trace; 8805f7f4 Trace; 88052a88 Trace; 88052b74 Code; 8800ee50 <__rwsem_wake+ac/dc> 0000000000000000 <_PC>: Code; 8800ee50 <__rwsem_wake+ac/dc> 0: 240600eb li $a2,235 Code; 8800ee54 <__rwsem_wake+b0/dc> 4: 0e007859 jal 801e164 <_PC+0x801e164> 9002cfb4 Code; 8800ee58 <__rwsem_wake+b4/dc> 8: 00000000 nop Code; 8800ee5c <__rwsem_wake+b8/dc> <===== c: ae200000 sw $zero,0($s1) <===== Code; 8800ee60 <__rwsem_wake+bc/dc> 10: 26040010 addiu $a0,$s0,16 Code; 8800ee64 <__rwsem_wake+c0/dc> 14: 24050003 li $a1,3 Code; 8800ee68 <__rwsem_wake+c4/dc> 18: 0e006b45 jal 801ad14 <_PC+0x801ad14> 90029b64 Code; 8800ee6c <__rwsem_wake+c8/dc> 1c: 24060001 li $a2,1 Code; 8800ee70 <__rwsem_wake+cc/dc> 20: 0a003b85 j 800ee14 <_PC+0x800ee14> 9001dc64 2 warnings issued. Results may not be reliable. --UugvWAfsgieZRqgk-- From owner-linux-mips@oss.sgi.com Wed Jun 13 06:56:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DDucK00797 for linux-mips-outgoing; Wed, 13 Jun 2001 06:56:38 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DDjZP32140; Wed, 13 Jun 2001 06:51:37 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21003; Wed, 13 Jun 2001 15:44:29 +0200 (MET DST) Date: Wed, 13 Jun 2001 15:44:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Keith Owens , Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-Reply-To: <20010613140550.B31221@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 Content-Length: 1295 Lines: 27 On Wed, 13 Jun 2001, Ralf Baechle wrote: > That can be done automatically. For 32-bit ELF files mips*-linux binutils > dump some of the addresses as 32-bit addresses, some as sign-extended (!) > 64-bit addresses. So ksymops should just sign extend any 32-bit addresses > to 64-bit and then work on full lenght addresses. > > Is ksymoops able to handle 64-bit addresses when running on a 32-bit host? > That is a common case for many people when decoding their MIPS oopses. The point is whether addresses should be extended at all if a 32-bit target is selected. IMHO -- not, that's a limitation of BFD when configured for both a 32-bit and a 64-bit target and it should be fixed sooner or later (at least it's on my to-do list for some time). BFD is free to handle addresses as it likes internally, be it 64-bit or 32-bit, but they should be truncated on final output to a 32-bit target, as they already are for certain cases. I'm not sure we need to work it around in ksymoops until BFD is fixed -- `cut -c8- < System.map' works as a charm. It might be worth documenting, though. -- + 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 Jun 13 07:02:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DE20i01451 for linux-mips-outgoing; Wed, 13 Jun 2001 07:02:00 -0700 Received: from rossini.infopark (h-213.61.59.138.host.de.colt.net [213.61.59.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DE1wP01436 for ; Wed, 13 Jun 2001 07:01:58 -0700 Received: from infopark.de (dark.infopark [10.1.10.40]) by rossini.infopark (8.9.3/8.9.3) with ESMTP id PAA11718 for ; Wed, 13 Jun 2001 15:59:34 +0200 (MET DST) Message-ID: <3B2771BE.4030401@infopark.de> Date: Wed, 13 Jun 2001 15:59:26 +0200 From: Bartosch Pixa User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-4GB i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Newbie question... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 422 Lines: 21 Hi i'm quite new to the mips architecture so sorry if i ask dumb/useless questions. i just bought a used Octane (IP30 R10K ...) and now i'm curious if it's possible to get linux on it ;) Any help/hints apreciated Thx in advance Bartosch Pixa -- Bartosch Pixa, bartosch.pixa@infopark.de Infopark AG Kitzingstr. 15, D-12277 Berlin, Germany Tel +49(0)-30-747.993.0, Fax +49(0)-30-747.993.93 http://www.infopark.de/ From owner-linux-mips@oss.sgi.com Wed Jun 13 07:15:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DEFLB02862 for linux-mips-outgoing; Wed, 13 Jun 2001 07:15:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DEFIP02852; Wed, 13 Jun 2001 07:15:18 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03913; Wed, 13 Jun 2001 07:06:49 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21003; Wed, 13 Jun 2001 15:44:29 +0200 (MET DST) Date: Wed, 13 Jun 2001 15:44:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Keith Owens , Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-Reply-To: <20010613140550.B31221@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 Content-Length: 1295 Lines: 27 On Wed, 13 Jun 2001, Ralf Baechle wrote: > That can be done automatically. For 32-bit ELF files mips*-linux binutils > dump some of the addresses as 32-bit addresses, some as sign-extended (!) > 64-bit addresses. So ksymops should just sign extend any 32-bit addresses > to 64-bit and then work on full lenght addresses. > > Is ksymoops able to handle 64-bit addresses when running on a 32-bit host? > That is a common case for many people when decoding their MIPS oopses. The point is whether addresses should be extended at all if a 32-bit target is selected. IMHO -- not, that's a limitation of BFD when configured for both a 32-bit and a 64-bit target and it should be fixed sooner or later (at least it's on my to-do list for some time). BFD is free to handle addresses as it likes internally, be it 64-bit or 32-bit, but they should be truncated on final output to a 32-bit target, as they already are for certain cases. I'm not sure we need to work it around in ksymoops until BFD is fixed -- `cut -c8- < System.map' works as a charm. It might be worth documenting, though. -- + 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 Jun 13 07:16:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DEGRO03023 for linux-mips-outgoing; Wed, 13 Jun 2001 07:16:27 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DEGNP03004; Wed, 13 Jun 2001 07:16:23 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DE7Cs10109; Thu, 14 Jun 2001 00:07:12 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-reply-to: Your message of "Wed, 13 Jun 2001 15:44:28 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 00:07:12 +1000 Message-ID: <10108.992441232@ocs4.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 451 Lines: 10 On Wed, 13 Jun 2001 15:44:28 +0200 (MET DST), "Maciej W. Rozycki" wrote: > The point is whether addresses should be extended at all if a 32-bit >target is selected. IMHO -- not ... > I'm not sure we need to work it around in ksymoops until BFD is fixed -- >`cut -c8- < System.map' works as a charm. ksymoops also reads the output from nm and objdump internally, it is just a little difficult to run cut -c8- on that data ;). From owner-linux-mips@oss.sgi.com Wed Jun 13 08:07:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DF7oY07999 for linux-mips-outgoing; Wed, 13 Jun 2001 08:07:50 -0700 Received: from mail.minus-9.com (IDENT:postfix@minus-9.com [195.26.32.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DF7mP07990 for ; Wed, 13 Jun 2001 08:07:48 -0700 Received: by mail.minus-9.com (Postfix, from userid 500) id 353E4BBD2; Wed, 13 Jun 2001 16:07:45 +0100 (BST) Date: Wed, 13 Jun 2001 16:07:45 +0100 From: Mat Withers To: linux-mips@oss.sgi.com Subject: Re: Newbie question... Message-ID: <20010613160745.I2024@minus-9.com> References: <3B2771BE.4030401@infopark.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2771BE.4030401@infopark.de>; from bartosch.pixa@infopark.de on Wed, Jun 13, 2001 at 03:59:26PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1074 Lines: 38 Bartosch Pixa (bartosch.pixa@infopark.de) wrote: > Hi > > i'm quite new to the mips architecture so sorry if i ask dumb/useless > questions. i just bought a used Octane (IP30 R10K ...) and now i'm > curious if it's possible to get linux on it ;) > Any help/hints apreciated > > > Thx in advance > > Bartosch Pixa > > -- > Bartosch Pixa, bartosch.pixa@infopark.de > Infopark AG > Kitzingstr. 15, D-12277 Berlin, Germany > Tel +49(0)-30-747.993.0, Fax +49(0)-30-747.993.93 > http://www.infopark.de/ > > > I'm also quite interested in mips linux - I've got an Indigo 2 R4400SC with 128 Mb RAM sitting under my desk at home doing nothing. Is this a reasonable platform to run ? I understand that I would have to use a serial console at the moment - are there any plans to support a text console on the Indigo 2 gfx hardware (I don't really care about X). How easy is the install ? Any info would be gratefully received Cheers Mat -- Mat Withers mat@minus-9.com http://minus-9.com phone: +44 7092 019849 "a sarcasm detector, *that's* a real useful invention." From owner-linux-mips@oss.sgi.com Wed Jun 13 08:08:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DF8Uh08117 for linux-mips-outgoing; Wed, 13 Jun 2001 08:08:30 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DF8TP08114 for ; Wed, 13 Jun 2001 08:08:30 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 54FE3125BA; Wed, 13 Jun 2001 08:08:29 -0700 (PDT) Date: Wed, 13 Jun 2001 08:08:29 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010613080829.A9739@lucon.org> References: <20010611210311.A8768@lucon.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 Wed, Jun 13, 2001 at 09:57:52AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 491 Lines: 15 On Wed, Jun 13, 2001 at 09:57:52AM +0200, Maciej W. Rozycki wrote: > On Mon, 11 Jun 2001, H . J . Lu wrote: > > > don't know abour the IRIX ABI DSOs. Also my glibc is compiled with > > -mmips2 since kernel cannot handle mips I glibc. > > What's the problem with the kernel? It works fine for my R3400A > DECstation. Glibc is 2.2.3 as released. If there is something wrong, I > definitely want to know. > It has something to do with the atomic emulation in kernel for mips I. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 13 08:16:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFGwc08899 for linux-mips-outgoing; Wed, 13 Jun 2001 08:16:58 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFGvP08892 for ; Wed, 13 Jun 2001 08:16:57 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id E6C183E90; Wed, 13 Jun 2001 08:13:17 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 50CAF14059; Wed, 13 Jun 2001 08:14:35 -0700 (PDT) Date: Wed, 13 Jun 2001 08:14:35 -0700 From: Keith M Wesolowski To: Bartosch Pixa Cc: linux-mips@oss.sgi.com Subject: Re: Newbie question... Message-ID: <20010613081435.A722@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B2771BE.4030401@infopark.de> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 800 Lines: 17 On Wed, Jun 13, 2001 at 03:59:26PM +0200, Bartosch Pixa wrote: > i'm quite new to the mips architecture so sorry if i ask dumb/useless > questions. i just bought a used Octane (IP30 R10K ...) and now i'm > curious if it's possible to get linux on it ;) Not at this time, though a few people have started to look at it. If you have irix headers and an ability to mangle the kernel for the better you should probably coordinate with Ralf and get started. IP30 is not very different from IP27, so the port should not be excessively difficult. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Wed Jun 13 08:17:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFHel09019 for linux-mips-outgoing; Wed, 13 Jun 2001 08:17:40 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFHYP09009; Wed, 13 Jun 2001 08:17:34 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA04834; Wed, 13 Jun 2001 08:16:28 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA23794; Wed, 13 Jun 2001 17:08:20 +0200 (MET DST) Date: Wed, 13 Jun 2001 17:08:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens cc: Ralf Baechle , Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) In-Reply-To: <10108.992441232@ocs4.ocs-net> 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 Content-Length: 424 Lines: 12 On Thu, 14 Jun 2001, Keith Owens wrote: > ksymoops also reads the output from nm and objdump internally, it is > just a little difficult to run cut -c8- on that data ;). I see. So a workaround is likely needed for now. -- + 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 Jun 13 08:22:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFMLd09518 for linux-mips-outgoing; Wed, 13 Jun 2001 08:22:21 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFM5P09496 for ; Wed, 13 Jun 2001 08:22:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA24267; Wed, 13 Jun 2001 17:22:49 +0200 (MET DST) Date: Wed, 13 Jun 2001 17:22:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available In-Reply-To: <20010613080829.A9739@lucon.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 Content-Length: 2959 Lines: 99 On Wed, 13 Jun 2001, H . J . Lu wrote: > > What's the problem with the kernel? It works fine for my R3400A > > DECstation. Glibc is 2.2.3 as released. If there is something wrong, I > > definitely want to know. > > It has something to do with the atomic emulation in kernel for mips I. Hmm, I thought Florian's sysmips() fixes went in. Here is a patch I use successfully for some time. It doesn't work for small negative integers, but glibc doesn't use them, AFAIK. Another possibility is to use the set of two patches for sys__test_and_set() I've sent here recently. This would break portability for now, though, if you wanted to distribute glibc or kernel binaries. This is also the reason I didn't put my current patched version of glibc on my FTP site. The patch is not against a current version of the kernel -- you might need to apply it manually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test11-20001211-sysmips-0 diff -up --recursive --new-file linux-mips-2.4.0-test11-20001211.macro/arch/mips/kernel/sysmips.c linux-mips-2.4.0-test11-20001211/arch/mips/kernel/sysmips.c --- linux-mips-2.4.0-test11-20001211.macro/arch/mips/kernel/sysmips.c Sat Nov 18 05:27:01 2000 +++ linux-mips-2.4.0-test11-20001211/arch/mips/kernel/sysmips.c Tue Dec 12 23:09:57 2000 @@ -75,21 +75,31 @@ sys_sysmips(int cmd, int arg1, int arg2, } case MIPS_ATOMIC_SET: { - unsigned int tmp; + int tmp1; p = (int *) arg1; errno = verify_area(VERIFY_WRITE, p, sizeof(*p)); if (errno) return errno; + errno = 0; +#ifndef CONFIG_CPU_HAS_LLSC + + save_and_cli(tmp1); + errno |= __get_user(tmp, p); + errno |= __put_user(arg2, p); + restore_flags(tmp1); + +#else /* CONFIG_CPU_HAS_LLSC */ + __asm__(".set\tpush\t\t\t# sysmips(MIPS_ATOMIC, ...)\n\t" ".set\tmips2\n\t" ".set\tnoat\n\t" - "1:\tll\t%0, %4\n\t" - "move\t$1, %3\n\t" - "2:\tsc\t$1, %1\n\t" - "beqz\t$1, 1b\n\t" + "1:\tll\t%0, %5\n\t" + "move\t%3, %4\n\t" + "2:\tsc\t%3, %1\n\t" + "beqz\t%3, 1b\n\t" ".set\tpop\n\t" ".section\t.fixup,\"ax\"\n" "3:\tli\t%2, 1\t\t\t# error\n\t" @@ -98,23 +108,17 @@ sys_sysmips(int cmd, int arg1, int arg2, ".word\t1b, 3b\n\t" ".word\t2b, 3b\n\t" ".previous\n\t" - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) + : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno), + "=&r" (tmp1) : "r" (arg2), "o" (* (u32 *) p), "2" (errno) : "$1"); +#endif /* CONFIG_CPU_HAS_LLSC */ + if (errno) return -EFAULT; - /* We're skipping error handling etc. */ - if (current->ptrace & PT_TRACESYS) - syscall_trace(); - - __asm__ __volatile__( - "move\t$29, %0\n\t" - "j\tret_from_sys_call" - : /* No outputs */ - : "r" (&cmd)); - /* Unreached */ + return tmp; } case MIPS_FIXADE: From owner-linux-mips@oss.sgi.com Wed Jun 13 08:24:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFOIP09776 for linux-mips-outgoing; Wed, 13 Jun 2001 08:24:18 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFOHP09767 for ; Wed, 13 Jun 2001 08:24:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 47275125BA; Wed, 13 Jun 2001 08:24:17 -0700 (PDT) Date: Wed, 13 Jun 2001 08:24:17 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010613082417.C9739@lucon.org> References: <20010613080829.A9739@lucon.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 Wed, Jun 13, 2001 at 05:22:49PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1343 Lines: 36 On Wed, Jun 13, 2001 at 05:22:49PM +0200, Maciej W. Rozycki wrote: > On Wed, 13 Jun 2001, H . J . Lu wrote: > > > > What's the problem with the kernel? It works fine for my R3400A > > > DECstation. Glibc is 2.2.3 as released. If there is something wrong, I > > > definitely want to know. > > > > It has something to do with the atomic emulation in kernel for mips I. > > Hmm, I thought Florian's sysmips() fixes went in. Here is a patch I use > successfully for some time. It doesn't work for small negative integers, > but glibc doesn't use them, AFAIK. > > Another possibility is to use the set of two patches for > sys__test_and_set() I've sent here recently. This would break portability > for now, though, if you wanted to distribute glibc or kernel binaries. > This is also the reason I didn't put my current patched version of glibc > on my FTP site. > > The patch is not against a current version of the kernel -- you might > need to apply it manually. > > Maciej > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > patch-mips-2.4.0-test11-20001211-sysmips-0 I don't have problem with 2.4.0-test11. It is the change in 2.4.3 which breaks glibc. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 13 08:24:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFOxU09902 for linux-mips-outgoing; Wed, 13 Jun 2001 08:24:59 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFOxP09899 for ; Wed, 13 Jun 2001 08:24:59 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 386803E90; Wed, 13 Jun 2001 08:21:19 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 4EDEA14059; Wed, 13 Jun 2001 08:22:31 -0700 (PDT) Date: Wed, 13 Jun 2001 08:22:31 -0700 From: Keith M Wesolowski To: Mat Withers Cc: linux-mips@oss.sgi.com Subject: Re: Newbie question... Message-ID: <20010613082231.B722@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010613160745.I2024@minus-9.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1161 Lines: 23 On Wed, Jun 13, 2001 at 04:07:45PM +0100, Mat Withers wrote: > I'm also quite interested in mips linux - I've got an Indigo 2 > R4400SC with 128 Mb RAM sitting under my desk at home doing nothing. > Is this a reasonable platform to run ? I understand that I would > have to use a serial console at the moment - are there any plans to > support a text console on the Indigo 2 gfx hardware (I don't really > care about X). How easy is the install ? As the FAQ states, this box should work fine. Graphics hardware will be supported when documentation is available or someone manages to reverse-engineer it. Perhaps you'd like to volunteer? The install is a trivial matter for experienced hackers, an annoyance to people who've never strayed outside the chartered bounds of commercial Linux on peecees, and a source of unending pain and grief for newbies. Unfortunately it's getting easier all the time. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Wed Jun 13 08:44:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFiIJ12295 for linux-mips-outgoing; Wed, 13 Jun 2001 08:44:18 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFiHP12292 for ; Wed, 13 Jun 2001 08:44:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 97FB5125BA; Wed, 13 Jun 2001 08:44:16 -0700 (PDT) Date: Wed, 13 Jun 2001 08:44:16 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available Message-ID: <20010613084416.A10334@lucon.org> References: <20010613082417.C9739@lucon.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 Wed, Jun 13, 2001 at 05:39:08PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 408 Lines: 13 On Wed, Jun 13, 2001 at 05:39:08PM +0200, Maciej W. Rozycki wrote: > On Wed, 13 Jun 2001, H . J . Lu wrote: > > > I don't have problem with 2.4.0-test11. It is the change in 2.4.3 > > which breaks glibc. > > You mean someone changed sysmips() in an incompatible way? Aaarghh... I don't remeber the detail, it is eithet kernel crash or glibc crash. I switched to mips II for glibc as the result. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 13 08:46:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFkLf12664 for linux-mips-outgoing; Wed, 13 Jun 2001 08:46:21 -0700 Received: from rossini.infopark (h-213.61.59.138.host.de.colt.net [213.61.59.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFkJP12658 for ; Wed, 13 Jun 2001 08:46:19 -0700 Received: from infopark.de (dark.infopark [10.1.10.40]) by rossini.infopark (8.9.3/8.9.3) with ESMTP id RAA23603 for ; Wed, 13 Jun 2001 17:43:55 +0200 (MET DST) Message-ID: <3B278A33.5070004@infopark.de> Date: Wed, 13 Jun 2001 17:43:47 +0200 From: Bartosch Pixa User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-4GB i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-mips Subject: Re: Newbie question... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1050 Lines: 33 Julien wrote: > > Hi... > > If I remember well, currently r10k are only supported on ip22 boards > (O2, etc)... I'm quite pessimistic for your Octane (in the immediate > futur). Are you looking for Linux to use it as a full featured os ? > linux-mips is still in intensive development (for example, only the > Indy > XL graphic card is supported, all other machines need a serial console > to use them), so if you planned to use it as an Irix replacement, it's > to soon [;-)] > If you feel it, and can find enough documentation about IP30 boards, > it should be possible to do the port yourself ;-)) > > hope this answers your question thx, this is not exactly what i wanted to hear ;) but i think i'll give it a try, any hint where i should start getting into it, like i said i'm quite new to mips ...but i realy want to give it a try :) Bartosch Pixa -- Bartosch Pixa, bartosch.pixa@infopark.de Infopark AG Kitzingstr. 15, D-12277 Berlin, Germany Tel +49(0)-30-747.993.0, Fax +49(0)-30-747.993.93 http://www.infopark.de/ From owner-linux-mips@oss.sgi.com Wed Jun 13 08:46:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFkpx12782 for linux-mips-outgoing; Wed, 13 Jun 2001 08:46:51 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFjxP12622 for ; Wed, 13 Jun 2001 08:46:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA24844; Wed, 13 Jun 2001 17:39:09 +0200 (MET DST) Date: Wed, 13 Jun 2001 17:39:08 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available In-Reply-To: <20010613082417.C9739@lucon.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 Content-Length: 405 Lines: 12 On Wed, 13 Jun 2001, H . J . Lu wrote: > I don't have problem with 2.4.0-test11. It is the change in 2.4.3 > which breaks glibc. You mean someone changed sysmips() in an incompatible way? Aaarghh... -- + 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 Jun 13 10:21:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DHLld16593 for linux-mips-outgoing; Wed, 13 Jun 2001 10:21:47 -0700 Received: from sprint02.rtmx.net (IDENT:qmailr@sprint02.RTMX.NET [208.31.160.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DHLkP16590 for ; Wed, 13 Jun 2001 10:21:47 -0700 Received: (qmail 9631 invoked by uid 102); 13 Jun 2001 17:21:45 -0000 Received: from host098.momenco.com (HELO beagle) (64.169.228.98) by 208.31.160.29 with SMTP; 13 Jun 2001 17:21:45 -0000 From: "Matthew Dharm" To: "Linux-MIPS" Subject: USB controllers? Date: Wed, 13 Jun 2001 10:21:45 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 506 Lines: 13 Out of curiosity, is anyone here running their MIPS-based system with USB enabled? It's not my day job, but something I deal with anyway, so I thought I'd ask and see if (a) anyone has tried it, and (b) anyone needs any help. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Wed Jun 13 10:26:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DHQQk16712 for linux-mips-outgoing; Wed, 13 Jun 2001 10:26:26 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DHQQP16709 for ; Wed, 13 Jun 2001 10:26:26 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f5DHPU032253; Wed, 13 Jun 2001 10:25:31 -0700 Message-ID: <3B27A139.8050107@pacbell.net> Date: Wed, 13 Jun 2001 10:22:01 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Matthew Dharm CC: Linux-MIPS Subject: Re: USB controllers? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 600 Lines: 17 Matthew Dharm wrote: >Out of curiosity, is anyone here running their MIPS-based system with >USB enabled? It's not my day job, but something I deal with anyway, >so I thought I'd ask and see if (a) anyone has tried it, and (b) >anyone needs any help. > We have USB working on two (or three) mips boards -- the ITE8172 and the Alchemy PB1000. Both little endian though. I think the USB on the NEC DDB boards might be working as well but I'm not sure. One of our guys had to do quite a bit of work initially to get usb working on mips but the patches were accepted by the maintainter. Pete From owner-linux-mips@oss.sgi.com Wed Jun 13 11:22:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DIMNo18781 for linux-mips-outgoing; Wed, 13 Jun 2001 11:22:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DIMMP18778 for ; Wed, 13 Jun 2001 11:22:22 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0BDB4125BA; Wed, 13 Jun 2001 11:22:22 -0700 (PDT) Date: Wed, 13 Jun 2001 11:22:21 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Looking for a home for my mips toolchain. Message-ID: <20010613112221.B12762@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 202 Lines: 7 Currently, I put my mips toolchain on kernel.org. But I am not sure if it is the appropriate place. I am planning to remove it from kernel.org now. Is there a place I can put my mips toolchain? H.J. From owner-linux-mips@oss.sgi.com Wed Jun 13 12:11:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DJB4X22144 for linux-mips-outgoing; Wed, 13 Jun 2001 12:11:04 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DJB2P22139 for ; Wed, 13 Jun 2001 12:11:02 -0700 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 f5DIns005987; Wed, 13 Jun 2001 11:49:54 -0700 Message-ID: <3B27B56F.65BAE189@mvista.com> Date: Wed, 13 Jun 2001 11:48:15 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available References: <20010613082417.C9739@lucon.org> <20010613084416.A10334@lucon.org> Content-Type: multipart/mixed; boundary="------------ECC83C97D960AE7BCDCCC103" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2753 Lines: 86 This is a multi-part message in MIME format. --------------ECC83C97D960AE7BCDCCC103 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "H . J . Lu" wrote: > > On Wed, Jun 13, 2001 at 05:39:08PM +0200, Maciej W. Rozycki wrote: > > On Wed, 13 Jun 2001, H . J . Lu wrote: > > > > > I don't have problem with 2.4.0-test11. It is the change in 2.4.3 > > > which breaks glibc. > > > > You mean someone changed sysmips() in an incompatible way? Aaarghh... > > I don't remeber the detail, it is eithet kernel crash or glibc crash. > I switched to mips II for glibc as the result. > > H.J. The latest CVS tree removed MIPS_ATOMIC_SET for CPUs without ll/sc. See the diff below. RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v retrieving revision 1.17 retrieving revision 1.18 diff -r1.17 -r1.18 77a78 > #ifdef CONFIG_CPU_HAS_LLSC 120a122,124 > #else > printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n"); > #endif However the log says: date: 2001/04/08 13:24:27; author: ralf; state: Exp; lines: +4 -0 Fix ll/sc emulation. Extracted from Linux-VR tree by Harald. It seems that the checkin is a mistake because apparently it is not what linux-vr is doing. They used to have a piece of code for CPUs without ll/sc. And recently they moved to ll/sc instruction emulation. Ralf, the following patch includes the original vr code for MIPS_ATOMIC_SET, no ll/sc case. Although we all know it is buggy (for small negative set values), it is still better than nothing. Jun --------------ECC83C97D960AE7BCDCCC103 Content-Type: text/plain; charset=us-ascii; name="junk" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="junk" diff -Nru sysmips.c.orig sysmips.c --- sysmips.c.orig Wed Jun 13 11:32:09 2001 +++ sysmips.c Wed Jun 13 11:46:06 2001 @@ -120,7 +120,23 @@ : "r" (&cmd)); /* Unreached */ #else - printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n"); + /* this is handled in assembly now */ + panic("Unexpected MIPS_ATOMIC_SET call in sys_sysmips()"); +#else + int flags; + + /* without ll/sc, we have a broken code that kind of works */ + /* This is broken in case of page faults and SMP ... + Risc/OS fauls after maximum 20 tries with EAGAIN. */ + p = (int *) arg1; + retval = verify_area(VERIFY_WRITE, p, sizeof(*p)); + if (retval) + goto out; + save_and_cli(flags); + retval = *p; + *p = arg2; + restore_flags(flags); + goto out; #endif } --------------ECC83C97D960AE7BCDCCC103-- From owner-linux-mips@oss.sgi.com Wed Jun 13 14:48:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLmDG06633 for linux-mips-outgoing; Wed, 13 Jun 2001 14:48:13 -0700 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLmCP06630 for ; Wed, 13 Jun 2001 14:48:12 -0700 Received: from [192.168.1.3] (h00104b670a0d.ne.mediaone.net [65.96.137.220]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5DLlu622921; Wed, 13 Jun 2001 17:47:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: mjpento@pop.ne.mediaone.net Message-Id: In-Reply-To: <20010613081435.A722@foobazco.org> References: <20010613081435.A722@foobazco.org> Date: Wed, 13 Jun 2001 17:50:06 -0400 To: Keith M Wesolowski From: mjpento Subject: Re: Newbie question... Cc: linux-mips@oss.sgi.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 670 Lines: 17 Hello folks, I am actually inquiring on a similar note. I have an Indigo R3000 under my desk that is collecting dust. Firstly, I would like to port a linux kernel to this system. I am sort of a newbie to porting os's. So, I have a few questions that I would like to ask: 1. Is there someone out there working on a port to the R3000's Indigo's? If so, does someone know who it is or a link to a website??? etc ... 2. Since I am rather new to porting, is there a resource that you folks would suggest out there on the internet that would be a good starting point for information or tips on the best porting methods? Any help would be greatly appreciated, Mike From owner-linux-mips@oss.sgi.com Wed Jun 13 14:51:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLpMb07085 for linux-mips-outgoing; Wed, 13 Jun 2001 14:51:22 -0700 Received: from exchmail.aivia.net ([63.90.239.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLpLP07082 for ; Wed, 13 Jun 2001 14:51:21 -0700 Received: by EXCHMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 16:55:37 -0500 Message-ID: From: "Jordan, Shane" To: linux-mips@oss.sgi.com Subject: How to get off this list? Date: Wed, 13 Jun 2001 16:55:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 74 Lines: 2 I have tried multiple times to get off of this list. What do I do? Shane From owner-linux-mips@oss.sgi.com Wed Jun 13 19:53:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E2rlk11329 for linux-mips-outgoing; Wed, 13 Jun 2001 19:53:47 -0700 Received: from web4904.mail.yahoo.com (web4904.mail.yahoo.com [216.115.106.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E2rkP11325 for ; Wed, 13 Jun 2001 19:53:46 -0700 Message-ID: <20010614025346.16122.qmail@web4904.mail.yahoo.com> Received: from [65.29.157.102] by web4904.mail.yahoo.com; Wed, 13 Jun 2001 19:53:45 PDT Date: Wed, 13 Jun 2001 19:53:45 -0700 (PDT) From: Dominick Anggara To: linux-mips@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 176 Lines: 7 unsuscribe dominick_93@yahoo.com __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ From owner-linux-mips@oss.sgi.com Wed Jun 13 21:29:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E4ThQ20151 for linux-mips-outgoing; Wed, 13 Jun 2001 21:29:43 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E4TfP20147 for ; Wed, 13 Jun 2001 21:29:41 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B690F125BA; Wed, 13 Jun 2001 21:29:40 -0700 (PDT) Date: Wed, 13 Jun 2001 21:29:40 -0700 From: "H . J . Lu" To: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010613212940.A22683@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1422 Lines: 72 In the MIPS gas, there is case M_JAL_A: if (mips_pic == NO_PIC) macro_build ((char *) NULL, &icnt, &offset_expr, "jal", "a"); else if (mips_pic == SVR4_PIC) { /* If this is a reference to an external symbol, and we are using a small GOT, we want lw $25,($gp) (BFD_RELOC_MIPS_CALL16) nop jalr $25 nop lw $gp,cprestore($sp) The cprestore value is set using the .cprestore pseudo-op. If we are using a big GOT, we want lui $25, (BFD_RELOC_MIPS_CALL_HI16) addu $25,$25,$gp lw $25,($25) (BFD_RELOC_MIPS_CALL_LO16) nop jalr $25 nop lw $gp,cprestore($sp) If the symbol is not external, we want lw $25,($gp) (BFD_RELOC_MIPS_GOT16) nop addiu $25,$25, (BFD_RELOC_LO16) jalr $25 nop lw $gp,cprestore($sp) */ When gcc emits $LEHB5: la $25,foobar jal $31,$25 $LEHE5: It doesn't work since jal $31,$25 is expanded to jalr $25 nop lw $gp,cprestore($sp) Now we have $LEHB5: la $25,foobar jalr $25 nop lw $gp,cprestore($sp) $LEHE5: When foobar throws an exception, GP won't get restored. What we want is $LEHB5: la $25,foobar jalr $25 nop $LEHE5: lw $gp,cprestore($sp) Does anyone have any suggestions how to fix it? Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 13 22:51:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E5p1a30205 for linux-mips-outgoing; Wed, 13 Jun 2001 22:51:01 -0700 Received: from foghorn.airs.com (IDENT:qmailr@foghorn.airs.com [63.201.54.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E5oxP30202 for ; Wed, 13 Jun 2001 22:50:59 -0700 Received: (qmail 32101 invoked by uid 10); 14 Jun 2001 05:50:59 -0000 Received: (qmail 27150 invoked by uid 269); 14 Jun 2001 05:50:54 -0000 Mail-Followup-To: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com, hjl@lucon.org From: Ian Lance Taylor To: "H . J . Lu" Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. References: <20010613212940.A22683@lucon.org> Date: 13 Jun 2001 22:50:54 -0700 In-Reply-To: <20010613212940.A22683@lucon.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 25 "H . J . Lu" writes: > In the MIPS gas, there is > > case M_JAL_A: Not the relevant bit of code, not that it matters much. The instruction jal $31,$25 will be handled by the M_JAL_1 case in gas/config/tc-mips.c. > Does anyone have any suggestions how to fix it? Traditional MIPS assemblers try to make life easier by doing this sort of translation. Modern MIPS compilers sidestep the translation because they can do better. In this case gcc evidently needs to do better in order to makes it exception handling model work. gcc should generate a jalr instruction, and should restore the GP register itself. (I suppose that it would be theoretically possible for gas to recognize labels of the special form $LEHEn. But that seems quite dreadful and quite fragile.) Ian From owner-linux-mips@oss.sgi.com Wed Jun 13 22:53:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E5rmN30692 for linux-mips-outgoing; Wed, 13 Jun 2001 22:53:48 -0700 Received: from foghorn.airs.com (IDENT:qmailr@foghorn.airs.com [63.201.54.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E5rlP30689 for ; Wed, 13 Jun 2001 22:53:47 -0700 Received: (qmail 32124 invoked by uid 10); 14 Jun 2001 05:53:47 -0000 Received: (qmail 27191 invoked by uid 269); 14 Jun 2001 05:53:42 -0000 Mail-Followup-To: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com, hjl@lucon.org From: Ian Lance Taylor To: "H . J . Lu" Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. References: <20010613212940.A22683@lucon.org> Date: 13 Jun 2001 22:53:42 -0700 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 330 Lines: 16 Ian Lance Taylor writes: > "H . J . Lu" writes: > > > In the MIPS gas, there is > > > > case M_JAL_A: > > Not the relevant bit of code, not that it matters much. The > instruction > jal $31,$25 > will be handled by the M_JAL_1 case in gas/config/tc-mips.c. Sorry, M_JAL_2. Ian From owner-linux-mips@oss.sgi.com Wed Jun 13 23:08:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E68FK00344 for linux-mips-outgoing; Wed, 13 Jun 2001 23:08:15 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E68DP00337 for ; Wed, 13 Jun 2001 23:08:14 -0700 Received: from sohorob (sc-66-27-45-152.socal.rr.com [66.27.45.152]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5E68Bo04318 for ; Wed, 13 Jun 2001 23:08:12 -0700 From: "Robert Rusek" To: Subject: RedHat test-7.0 Date: Wed, 13 Jun 2001 23:08:20 -0700 Message-ID: <000701c0f498$69d77c70$6400a8c0@sohorob> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C0F45D.BD78A470" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1103 Lines: 39 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C0F45D.BD78A470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Has anyone successfully installed Red Hat test-7.0 and got the compilers working? -- Robert Rusek ------=_NextPart_000_0008_01C0F45D.BD78A470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Has anyone successfully installed Red Hat test-7.0 and got the = compilers=20 working?
--
Robert = Rusek
 
------=_NextPart_000_0008_01C0F45D.BD78A470-- From owner-linux-mips@oss.sgi.com Wed Jun 13 23:15:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E6FAh01481 for linux-mips-outgoing; Wed, 13 Jun 2001 23:15:10 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E6F9P01470 for ; Wed, 13 Jun 2001 23:15:09 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id IAA08705; Thu, 14 Jun 2001 08:15:07 +0200 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA22511; Thu, 14 Jun 2001 08:15:07 +0200 (MET DST) Message-Id: <200106140615.IAA22511@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Robert Rusek" cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: RedHat test-7.0 In-reply-to: Your message of "Wed, 13 Jun 2001 23:08:20 PDT." <000701c0f498$69d77c70$6400a8c0@sohorob> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 08:15:06 +0200 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 402 Lines: 19 > > Has anyone successfully installed Red Hat test-7.0 and got the compilers > working? > -- > Robert Rusek > Yes, On DECStations, and on SGI Indy. -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Wed Jun 13 23:23:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E6N8q02695 for linux-mips-outgoing; Wed, 13 Jun 2001 23:23:08 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E6N7P02690 for ; Wed, 13 Jun 2001 23:23:07 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id BAB0B125BA; Wed, 13 Jun 2001 23:23:06 -0700 (PDT) Date: Wed, 13 Jun 2001 23:23:06 -0700 From: "H . J . Lu" To: Ian Lance Taylor Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010613232306.A24354@lucon.org> References: <20010613212940.A22683@lucon.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 ian@zembu.com on Wed, Jun 13, 2001 at 10:50:54PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1537 Lines: 53 On Wed, Jun 13, 2001 at 10:50:54PM -0700, Ian Lance Taylor wrote: > "H . J . Lu" writes: > > > In the MIPS gas, there is > > > > case M_JAL_A: > > Not the relevant bit of code, not that it matters much. The > instruction > jal $31,$25 > will be handled by the M_JAL_1 case in gas/config/tc-mips.c. > > > Does anyone have any suggestions how to fix it? > > Traditional MIPS assemblers try to make life easier by doing this sort > of translation. Modern MIPS compilers sidestep the translation > because they can do better. In this case gcc evidently needs to do > better in order to makes it exception handling model work. gcc should > generate a jalr instruction, and should restore the GP register > itself. > > (I suppose that it would be theoretically possible for gas to > recognize labels of the special form $LEHEn. But that seems quite > dreadful and quite fragile.) The more I look at the problem, the more I doubt DAWRF2 exception will ever work with the SVR4 MIPS ABI without the full support from gcc. The problem is GP is a caller saved register in the SVR4 MIPS ABI. So every caller has to do call foo restore gp Given a piece of C++ code: try { foo (...); ..... } catch (...) { } When foo () throws an exception, it is gcc who has to make sure that GP gets properly restored. Is there a way to teach the gcc exception code that GP is a caller saved register? BTW, in IRIX 6, GP is changed to callee saved so that it is not a problem. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 14 00:44:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E7if412215 for linux-mips-outgoing; Thu, 14 Jun 2001 00:44:41 -0700 Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [212.227.116.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E7idP12206 for ; Thu, 14 Jun 2001 00:44:39 -0700 Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by mailgate3.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id f5E7ibF13477; Thu, 14 Jun 2001 09:44:37 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.1.8 #22) id m15ARnw-007naqC; Thu, 14 Jun 2001 09:44 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: Jun Sun , "H . J . Lu" Subject: Re: A new mips toolchain is available Date: Wed, 13 Jun 2001 22:55:00 +0200 X-Mailer: KMail [version 1.2] Cc: linux-mips@oss.sgi.com References: <20010613082417.C9739@lucon.org> <20010613084416.A10334@lucon.org> <3B27B56F.65BAE189@mvista.com> In-Reply-To: <3B27B56F.65BAE189@mvista.com> MIME-Version: 1.0 Message-Id: <01061322550001.00617@intel> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 863 Lines: 23 On Wednesday 13 June 2001 20:48, Jun Sun wrote: > The latest CVS tree removed MIPS_ATOMIC_SET for CPUs without ll/sc. See > the diff below. [diff snipped] > It seems that the checkin is a mistake because apparently it is not what > linux-vr is doing. They used to have a piece of code for CPUs without > ll/sc. And recently they moved to ll/sc instruction emulation. Well, you seem to have a different linux-vr tree than I do :-) > Ralf, the following patch includes the original vr code for > MIPS_ATOMIC_SET, no ll/sc case. Although we all know it is buggy (for > small negative set values), it is still better than nothing. Anyway, the linux-vr source tree has a partially working ll/sc emulation, at least enough for glibc, and MIPS_ATOMIC_SET is not neccessarily needed. In fact, MIPS_ATOMIC_SET has been removed from the vr tree. Regards, Harald From owner-linux-mips@oss.sgi.com Thu Jun 14 04:23:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EBNiK04664 for linux-mips-outgoing; Thu, 14 Jun 2001 04:23:44 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EBFUP03570 for ; Thu, 14 Jun 2001 04:16:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA20236; Thu, 14 Jun 2001 12:26:59 +0200 (MET DST) Date: Thu, 14 Jun 2001 12:26:58 +0200 (MET DST) From: "Maciej W. Rozycki" To: Harald Koerfgen cc: Jun Sun , "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: A new mips toolchain is available In-Reply-To: <01061322550001.00617@intel> 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 Content-Length: 534 Lines: 13 On Wed, 13 Jun 2001, Harald Koerfgen wrote: > Anyway, the linux-vr source tree has a partially working ll/sc emulation, at > least enough for glibc, and MIPS_ATOMIC_SET is not neccessarily needed. > In fact, MIPS_ATOMIC_SET has been removed from the vr tree. I suppose we may remove it, too, once we agree on a sane replacement. -- + 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 Jun 14 10:19:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EHJsc06341 for linux-mips-outgoing; Thu, 14 Jun 2001 10:19:54 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EHJrP06338 for ; Thu, 14 Jun 2001 10:19:53 -0700 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA23416; Thu, 14 Jun 2001 10:19:52 -0700 (PDT) Received: (from rth@localhost) by dot.cygnus.com (8.11.0/8.11.0) id f5EHJqs28846; Thu, 14 Jun 2001 10:19:52 -0700 X-Authentication-Warning: dot.cygnus.com: rth set sender to rth@redhat.com using -f Date: Thu, 14 Jun 2001 10:19:51 -0700 From: Richard Henderson To: "H . J . Lu" Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614101951.B28824@redhat.com> Mail-Followup-To: Richard Henderson , "H . J . Lu" , gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com References: <20010613212940.A22683@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010613212940.A22683@lucon.org>; from hjl@lucon.org on Wed, Jun 13, 2001 at 09:29:40PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 616 Lines: 29 On Wed, Jun 13, 2001 at 09:29:40PM -0700, H . J . Lu wrote: > Now we have > > $LEHB5: > la $25,foobar > jalr $25 > nop > lw $gp,cprestore($sp) > $LEHE5: > > When foobar throws an exception, GP won't get restored. What we want is > > $LEHB5: > la $25,foobar > jalr $25 > nop > $LEHE5: > lw $gp,cprestore($sp) Um, what exactly do you think the difference between these two is? Hint: nothing. I could have sworn there was an exception_receiver pattern on mips to handle this, but I don't see it now. It's relatively easy to fix; see TARGET_LD_BUGGY_LDGP is handled on alpha. r~ From owner-linux-mips@oss.sgi.com Thu Jun 14 11:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EIfKa08216 for linux-mips-outgoing; Thu, 14 Jun 2001 11:41:20 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EIfIP08213 for ; Thu, 14 Jun 2001 11:41:18 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id F1AAE125BA; Thu, 14 Jun 2001 11:41:17 -0700 (PDT) Date: Thu, 14 Jun 2001 11:41:17 -0700 From: "H . J . Lu" To: Richard Henderson , gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614114117.A3092@lucon.org> References: <20010613212940.A22683@lucon.org> <20010614101951.B28824@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614101951.B28824@redhat.com>; from rth@redhat.com on Thu, Jun 14, 2001 at 10:19:51AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1454 Lines: 46 On Thu, Jun 14, 2001 at 10:19:51AM -0700, Richard Henderson wrote: > > I could have sworn there was an exception_receiver pattern on mips > to handle this, but I don't see it now. It's relatively easy to fix; > see TARGET_LD_BUGGY_LDGP is handled on alpha. > Thanks. This patch seems to fix my problem. But I have several questions: 1. Is the usage of current_frame_info.args_size right? 2. What should be in the place of [(const_int 4)]? 3. Does it need other patterns for similar situations? 4. Is my patch ok? H.J. ---- 2001-06-14 H.J. Lu * config/mips/mips.md (exception_receiver): New. --- gcc/config/mips/mips.md.except Thu Jun 14 10:34:34 2001 +++ gcc/config/mips/mips.md Thu Jun 14 11:36:31 2001 @@ -10461,3 +10461,21 @@ ld\\t%2,%1-%S1(%2)\;daddu\\t%2,%2,$31\;j [(set_attr "type" "arith") (set_attr "mode" "DI") (set_attr "length" "40")]) + +;; For o32, the gp register is call clobbered, so it must +;; be saved & restored around calls by the caller. If the call +;; doesn't return normally (nonlocal goto, or an exception is +;; thrown), then the code at the exception handler label must +;; restore the gp register. +(define_insn "exception_receiver" + [(const_int 4)] + "mips_abi == ABI_32" + "* +{ + static char ldgp[40]; + sprintf (ldgp, \"lw\\t$gp,%ld($sp)\", current_frame_info.args_size); + return ldgp; +}" + [(set_attr "type" "load") + (set_attr "mode" "SI") + (set_attr "length" "4")]) From owner-linux-mips@oss.sgi.com Thu Jun 14 12:05:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJ5k109089 for linux-mips-outgoing; Thu, 14 Jun 2001 12:05:46 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJ5jP09086 for ; Thu, 14 Jun 2001 12:05:45 -0700 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA08606; Thu, 14 Jun 2001 12:05:44 -0700 (PDT) Received: (from rth@localhost) by dot.cygnus.com (8.11.0/8.11.0) id f5EJ5hR28916; Thu, 14 Jun 2001 12:05:43 -0700 X-Authentication-Warning: dot.cygnus.com: rth set sender to rth@redhat.com using -f Date: Thu, 14 Jun 2001 12:05:43 -0700 From: Richard Henderson To: "H . J . Lu" Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614120543.B28888@redhat.com> Mail-Followup-To: Richard Henderson , "H . J . Lu" , gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com References: <20010613212940.A22683@lucon.org> <20010614101951.B28824@redhat.com> <20010614114117.A3092@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614114117.A3092@lucon.org>; from hjl@lucon.org on Thu, Jun 14, 2001 at 11:41:17AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1941 Lines: 90 On Thu, Jun 14, 2001 at 11:41:17AM -0700, H . J . Lu wrote: > 1. Is the usage of current_frame_info.args_size right? Yes. > 2. What should be in the place of [(const_int 4)]? Some unspec_volatile. > 3. Does it need other patterns for similar situations? Yes, O64. > 4. Is my patch ok? No. This one should be ok. r~ Index: mips.md =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.md,v retrieving revision 1.94 diff -c -p -d -r1.94 mips.md *** mips.md 2001/05/20 00:35:24 1.94 --- mips.md 2001/06/14 18:50:32 *************** *** 30,42 **** ;; Number USE ;; 0 movsi_ul ;; 1 movsi_us, get_fnaddr - ;; 2 loadgp ;; 3 eh_set_return ;; 20 builtin_setjmp_setup ;; ;; UNSPEC_VOLATILE values ;; 0 blockage ;; 3 builtin_longjmp ;; 10 consttable_qi ;; 11 consttable_hi ;; 12 consttable_si --- 30,43 ---- ;; Number USE ;; 0 movsi_ul ;; 1 movsi_us, get_fnaddr ;; 3 eh_set_return ;; 20 builtin_setjmp_setup ;; ;; UNSPEC_VOLATILE values ;; 0 blockage + ;; 2 loadgp ;; 3 builtin_longjmp + ;; 4 exception_receiver ;; 10 consttable_qi ;; 11 consttable_hi ;; 12 consttable_si *************** ld\\t%2,%1-%S1(%2)\;daddu\\t%2,%2,$31\;j *** 9571,9576 **** --- 9572,9598 ---- operands[0]); DONE; }") + + (define_insn "exception_receiver" + [(unspec_volatile [(const_int 0)] 4)] + "TARGET_ABICALLS && (mips_abi == ABI_32 || mips_abi == ABI_O64)" + "* + { + rtx loc; + + operands[0] = gen_rtx_REG (Pmode, PIC_FUNCTION_ADDR_REGNUM); + + if (frame_pointer_needed) + loc = hard_frame_pointer_rtx; + else + loc = stack_pointer_rtx; + loc = plus_constant (loc, current_frame_info.args_size); + operands[1] = gen_rtx_MEM (Pmode, loc); + + return mips_move_1word (operands, insn, 0); + }" + [(set_attr "type" "load") + (set_attr "length" "8")]) ;; ;; .................... From owner-linux-mips@oss.sgi.com Thu Jun 14 12:25:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJPq309909 for linux-mips-outgoing; Thu, 14 Jun 2001 12:25:52 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJPpP09905 for ; Thu, 14 Jun 2001 12:25:51 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 69215125BA; Thu, 14 Jun 2001 12:25:50 -0700 (PDT) Date: Thu, 14 Jun 2001 12:25:50 -0700 From: "H . J . Lu" To: Richard Henderson Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614122550.B3668@lucon.org> References: <20010613212940.A22683@lucon.org> <20010614101951.B28824@redhat.com> <20010614114117.A3092@lucon.org> <20010614120543.B28888@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614120543.B28888@redhat.com>; from rth@redhat.com on Thu, Jun 14, 2001 at 12:05:43PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 38 On Thu, Jun 14, 2001 at 12:05:43PM -0700, Richard Henderson wrote: > + > + (define_insn "exception_receiver" > + [(unspec_volatile [(const_int 0)] 4)] > + "TARGET_ABICALLS && (mips_abi == ABI_32 || mips_abi == ABI_O64)" > + "* > + { > + rtx loc; > + > + operands[0] = gen_rtx_REG (Pmode, PIC_FUNCTION_ADDR_REGNUM); > + > + if (frame_pointer_needed) > + loc = hard_frame_pointer_rtx; > + else > + loc = stack_pointer_rtx; > + loc = plus_constant (loc, current_frame_info.args_size); > + operands[1] = gen_rtx_MEM (Pmode, loc); > + > + return mips_move_1word (operands, insn, 0); > + }" > + [(set_attr "type" "load") > + (set_attr "length" "8")]) > I have 3 questions: 1. I see PIC_FUNCTION_ADDR_REGNUM be $25. gp is $28. How does your patch restore $28? 2. I assum you set length to 8 for o64. Has anyone checked if the instruction is 8 byte on o64? 2. Did you remove (set_attr "mode" "SI") for o64? Thanks. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 14 12:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJgwG11677 for linux-mips-outgoing; Thu, 14 Jun 2001 12:42:58 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJgvP11674 for ; Thu, 14 Jun 2001 12:42:57 -0700 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA13284; Thu, 14 Jun 2001 12:42:56 -0700 (PDT) Received: (from rth@localhost) by dot.cygnus.com (8.11.0/8.11.0) id f5EJgtY28930; Thu, 14 Jun 2001 12:42:55 -0700 X-Authentication-Warning: dot.cygnus.com: rth set sender to rth@redhat.com using -f Date: Thu, 14 Jun 2001 12:42:55 -0700 From: Richard Henderson To: "H . J . Lu" Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614124255.C28888@redhat.com> Mail-Followup-To: Richard Henderson , "H . J . Lu" , gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com References: <20010613212940.A22683@lucon.org> <20010614101951.B28824@redhat.com> <20010614114117.A3092@lucon.org> <20010614120543.B28888@redhat.com> <20010614122550.B3668@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614122550.B3668@lucon.org>; from hjl@lucon.org on Thu, Jun 14, 2001 at 12:25:50PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 503 Lines: 19 On Thu, Jun 14, 2001 at 12:25:50PM -0700, H . J . Lu wrote: > 1. I see PIC_FUNCTION_ADDR_REGNUM be $25. gp is $28. How does your > patch restore $28? That should be pic_offset_table_rtx instead. > 2. I assum you set length to 8 for o64. Has anyone checked if the > instruction is 8 byte on o64? It may be 8 on o32 as well -- consider the nop that the assembler may add. > 2. Did you remove (set_attr "mode" "SI") for o64? As far as I can tell that is not used except for mult/div scheduling. r~ From owner-linux-mips@oss.sgi.com Thu Jun 14 12:55:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJtpH13540 for linux-mips-outgoing; Thu, 14 Jun 2001 12:55:51 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJtoP13536 for ; Thu, 14 Jun 2001 12:55:50 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id C1B8D125BA; Thu, 14 Jun 2001 12:55:49 -0700 (PDT) Date: Thu, 14 Jun 2001 12:55:49 -0700 From: "H . J . Lu" To: Richard Henderson Cc: gcc@gcc.gnu.org, binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: DWARF2 exception doesn't work with gcc and gas on MIPS. Message-ID: <20010614125549.A4375@lucon.org> References: <20010613212940.A22683@lucon.org> <20010614101951.B28824@redhat.com> <20010614114117.A3092@lucon.org> <20010614120543.B28888@redhat.com> <20010614122550.B3668@lucon.org> <20010614124255.C28888@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614124255.C28888@redhat.com>; from rth@redhat.com on Thu, Jun 14, 2001 at 12:42:55PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 370 Lines: 18 On Thu, Jun 14, 2001 at 12:42:55PM -0700, Richard Henderson wrote: > On Thu, Jun 14, 2001 at 12:25:50PM -0700, H . J . Lu wrote: > > 1. I see PIC_FUNCTION_ADDR_REGNUM be $25. gp is $28. How does your > > patch restore $28? > > That should be pic_offset_table_rtx instead. > I used operands[0] = pic_offset_table_rtx; It seems to work for me. Thanks a lot. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 14 20:56:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3u8G30952 for linux-mips-outgoing; Thu, 14 Jun 2001 20:56:08 -0700 Received: from viditec-netmedia.com.tw (61-220-240-70.HINET-IP.hinet.net [61.220.240.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3u5k30943 for ; Thu, 14 Jun 2001 20:56:05 -0700 Received: from kjlin (61-220-240-66.HINET-IP.hinet.net [61.220.240.66]) by viditec-netmedia.com.tw (8.10.0/8.10.0) with SMTP id f5F5Vlo09761 for ; Fri, 15 Jun 2001 13:31:58 +0800 Message-ID: <04a201c0f542$28184620$056aaac0@kjlin> From: "kjlin" To: Subject: How to trigger a binary to excute in Linux/MIPS? Date: Fri, 15 Jun 2001 10:23:04 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_049F_01C0F585.29803F20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2805 Lines: 80 This is a multi-part message in MIME format. ------=_NextPart_000_049F_01C0F585.29803F20 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, To execute a program, the load_elf_binary() loads it and descdes the = value of elf_entry, start_code, start_data....etc.. Then , the start_thread(regs, elf_entry, bprm->p) will trigger it. But it just sets up the value of regs->cp0_status, regs->cp0_epc, = regs->regs[29] and current->thread.current_ds. Why can the start_thread() trigger a program? Here is my situation : The kernel boots up and mounts the filesystem, when it tries to execute /sbin/hello i don't see any output. (Ps: /sbin/hello is a simple testing program to replace the real = /sbin/init. It just outputs some console message.) I looked at the memory and the code for hello is present at "elf_entry", so why does the start_thread not execute it ?? Any help would be really appreciated. Thanks, KJ ------=_NextPart_000_049F_01C0F585.29803F20 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
To execute a program, the load_elf_binary() loads it = and=20 descdes the value of elf_entry, start_code, = start_data....etc..
Then , the start_thread(regs, elf_entry, bprm->p) = will=20 trigger it.
But it just sets up the value of=20 regs->cp0_status, regs->cp0_epc, regs->regs[29] and=20 current->thread.current_ds.
Why can the start_thread() trigger a = program?
 
Here is my situation :
The kernel boots up and mounts the filesystem, when = it tries=20 to
execute /sbin/hello i don't see any output.
(Ps: /sbin/hello is a simple testing program to = replace the=20 real /sbin/init.
        It just = outputs=20 some console message.)
I looked at the memory and the code = for hello is=20 present at "elf_entry",
so why does the start_thread not execute it = ??
 
Any help would be really = appreciated.
Thanks,
KJ

------=_NextPart_000_049F_01C0F585.29803F20-- From owner-linux-mips@oss.sgi.com Thu Jun 14 21:10:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F4A4Y00332 for linux-mips-outgoing; Thu, 14 Jun 2001 21:10:04 -0700 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F4A3k00327 for ; Thu, 14 Jun 2001 21:10:03 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Thu, 14 Jun 2001 21:10:02 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from postal.sibyte.com (IDENT:postfix@[10.21.128.60]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id VAA01550; Thu, 14 Jun 2001 21:09:47 -0700 (PDT) Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 8C9D91595F; Thu, 14 Jun 2001 21:09:47 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id 4F20A686D; Thu, 14 Jun 2001 21:09:07 -0700 (PDT) From: "Justin Carlson" Reply-to: carlson@sibyte.com Organization: Sibyte To: kjlin Subject: Re: How to trigger a binary to excute in Linux/MIPS? Date: Thu, 14 Jun 2001 21:03:22 -0700 X-Mailer: KMail [version 1.0.29] References: <04a201c0f542$28184620$056aaac0@kjlin> In-Reply-To: <04a201c0f542$28184620$056aaac0@kjlin> cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-ID: <0106142109060Z.00831@plugh.sibyte.com> X-WSS-ID: 17375510120071-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1240 Lines: 30 On Thu, 14 Jun 2001, you wrote: > > Hi, > > To execute a program, the load_elf_binary() loads it and descdes the value of elf_entry, start_code, start_data....etc.. > Then , the start_thread(regs, elf_entry, bprm->p) will trigger it. > But it just sets up the value of regs->cp0_status, regs->cp0_epc, regs->regs[29] and current->thread.current_ds. > Why can the start_thread() trigger a program? > It does trigger a program, just not in the way you're thinking. At that point, you're in kernel space, with kernel privileges, so you can't just jump to the entry point of the elf binary; you have to drop privs first. What you're probably missing is that, when the kernel returns to userspace, it does so (in mips) via an eret, which returns to the epc. The registers are restored from the regs struct that is being modified by start_thread, so it is effectively modifying the registers for userspace, which is what it should be doing. In short, you're not going to see the new process, in your case, /sbin/hello, start executing until the syscall returns. Check out arch/mips/kernel/entry.S:ret_from_sys_call to see where this happens. You'll also want to check out include/asm-mips/stackframe.h Does this make sense? -Justin From owner-linux-mips@oss.sgi.com Fri Jun 15 06:31:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDVrj17198 for linux-mips-outgoing; Fri, 15 Jun 2001 06:31:53 -0700 Received: from air.lug-owl.de (air.lug-owl.de [62.52.24.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDVpk17195 for ; Fri, 15 Jun 2001 06:31:51 -0700 Received: by air.lug-owl.de (Postfix, from userid 1000) id 348C37C14; Fri, 15 Jun 2001 15:31:49 +0200 (CEST) Date: Fri, 15 Jun 2001 15:31:48 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Newbie question... Message-ID: <20010615153147.A7621@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20010613081435.A722@foobazco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from mjpento@mediaone.net on Wed, Jun 13, 2001 at 05:50:06PM -0400 X-Operating-System: Linux air 2.4.2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2368 Lines: 66 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2001 at 05:50:06PM -0400, mjpento wrote: [Indigo R3000] > 1. Is there someone out there working on a port to the R3000's=20 > Indigo's? If so, does someone know who it is or a link to a=20 > website??? etc ... Rumor was that Michael Engel was working on the Indigo. I've got such a beast as well (okay, it's an OEM version build by Siemens Nixdorf), but there's no Linux running on this box these days. =46rom what I've heared, the Indigo R3k is quite different to most other supported machines (Indy, Indigo2) so a port will be somewhat difficult. The machine isn't the fastest one (well,=20 mine is running wirh Irix 5.2 and the flight simulator is quite nice to play with:-), but it *would* be more then fast enough to run Linux. > 2. Since I am rather new to porting, is there a resource that you=20 > folks would suggest out there on the internet that would be a good=20 > starting point for information or tips on the best porting methods? Porting Linux to Indigo R3k is difficult. There seems to be no hardware documentation available (except Irix header files). So porting will be a means of reading header files, using an oscilloscope and disassembline Irix' kernel.=20 > Any help would be greatly appreciated, I'd really *love* to see Linux running on Indigo R3k, but I'm not experienced enough to do the port. However, I'd like to help and cooperate with more experienced programmers to make it running, but they're more or less fixed to their bigger^Wfaster machines... Michael, have you had any success with your Indigo R3k? MfG, JBG --=20 Fehler eingestehen, Gr=F6=DFe zeigen: Nehmt die Rechtschreibreform zur=FCck= !!! /* Jan-Benedict Glaw -- +49-172-7608481 */ keyID=3D0x8399E1BB fingerprint=3D250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 83= 99 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsqDkIACgkQHb1edYOZ4buQSACeMml7MtVmlNGAymlnsN7wpBB2 5m0An3eBrarbfwfSk3evQrBvJfWq/rk/ =fCKh -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-linux-mips@oss.sgi.com Fri Jun 15 09:44:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FGi7T20620 for linux-mips-outgoing; Fri, 15 Jun 2001 09:44:07 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FGi5k20616 for ; Fri, 15 Jun 2001 09:44:06 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 94FA87D9; Fri, 15 Jun 2001 18:44:03 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A618042F9; Fri, 15 Jun 2001 14:12:06 +0200 (CEST) Date: Fri, 15 Jun 2001 14:12:06 +0200 From: Florian Lohoff To: mjpento Cc: Keith M Wesolowski , linux-mips@oss.sgi.com Subject: Re: Newbie question... Message-ID: <20010615141206.A7038@paradigm.rfc822.org> References: <20010613081435.A722@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from mjpento@mediaone.net on Wed, Jun 13, 2001 at 05:50:06PM -0400 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1011 Lines: 24 On Wed, Jun 13, 2001 at 05:50:06PM -0400, mjpento wrote: > Hello folks, > > I am actually inquiring on a similar note. I have an Indigo > R3000 under my desk that is collecting dust. Firstly, I would like to > port a linux kernel to this system. I am sort of a newbie to porting > os's. So, I have a few questions that I would like to ask: > > 1. Is there someone out there working on a port to the R3000's > Indigo's? If so, does someone know who it is or a link to a > website??? etc ... > > 2. Since I am rather new to porting, is there a resource that you > folks would suggest out there on the internet that would be a good > starting point for information or tips on the best porting methods? R3000 is no problem - The Indigo (1 IP12 ?) is the problem - Its mostly undocumented and i havent heard of anyone trying to do something about it. 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 Fri Jun 15 09:58:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FGw9q20948 for linux-mips-outgoing; Fri, 15 Jun 2001 09:58:09 -0700 Received: from mail2.dk.snt.com (mail1.drscallcenter.dk [194.255.1.232]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FGw8k20944 for ; Fri, 15 Jun 2001 09:58:08 -0700 Received: from nellemann.nu (spinner.drscallcenter.dk [194.255.1.234]) by mail2.dk.snt.com (Postfix) with SMTP id 9161D35809 for ; Fri, 15 Jun 2001 18:57:47 +0200 (CEST) Received: from 62.242.140.98 (SquirrelMail authenticated user mark@nellemann.nu) by webmail.drscallcenter.dk with HTTP; Fri, 15 Jun 2001 18:51:39 +0200 (CEST) Message-ID: <31944.62.242.140.98.992623899.squirrel@webmail.drscallcenter.dk> Date: Fri, 15 Jun 2001 18:51:39 +0200 (CEST) Subject: Another newbie question, O2 this time From: "Mark Nellemann" To: X-Mailer: SquirrelMail (version 1.1.2) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_us,bP-0h=K8'4teITM4kq_On8V/2d0,aSkOS4-3LIlhV04p3:Iwh6Y4kl4dr" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 621 Lines: 24 ------=_us,bP-0h=K8'4teITM4kq_On8V/2d0,aSkOS4-3LIlhV04p3:Iwh6Y4kl4dr Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, There's a chance that I can get my hands on a O2 (with a R12000 cpu). Will Linux run on that hardware, and is it easy to install? I have been using Linux for many years, but only on x86 and recently ppc. /Mark ------=_us,bP-0h=K8'4teITM4kq_On8V/2d0,aSkOS4-3LIlhV04p3:Iwh6Y4kl4dr Content-Type: ; name="" Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= ------=_us,bP-0h=K8'4teITM4kq_On8V/2d0,aSkOS4-3LIlhV04p3:Iwh6Y4kl4dr-- From owner-linux-mips@oss.sgi.com Fri Jun 15 10:46:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FHkID22046 for linux-mips-outgoing; Fri, 15 Jun 2001 10:46:18 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FHkGk22043 for ; Fri, 15 Jun 2001 10:46:16 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA02310; Fri, 15 Jun 2001 13:46:07 -0400 Date: Fri, 15 Jun 2001 13:46:07 -0400 (EDT) From: X-Sender: nick@ns To: Mark Nellemann cc: linux-mips@oss.sgi.com Subject: Re: Another newbie question, O2 this time In-Reply-To: <31944.62.242.140.98.992623899.squirrel@webmail.drscallcenter.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 432 Lines: 18 Linux will (possibly) boot uncached, and will at some point work. If you're willing to help us get it farther that would be terrific. Nick On Fri, 15 Jun 2001, Mark Nellemann wrote: > > Hi, > > There's a chance that I can get my hands on a O2 (with a R12000 cpu). Will > Linux run on that hardware, and is it easy to install? I have been using > Linux for many years, but only on x86 and recently ppc. > > > /Mark > > From owner-linux-mips@oss.sgi.com Fri Jun 15 10:54:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FHsgN22208 for linux-mips-outgoing; Fri, 15 Jun 2001 10:54:42 -0700 Received: from mail2.dk.snt.com (mail1.drscallcenter.dk [194.255.1.232]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FHsek22204 for ; Fri, 15 Jun 2001 10:54:41 -0700 Received: from nellemann.nu (spinner.drscallcenter.dk [194.255.1.234]) by mail2.dk.snt.com (Postfix) with SMTP id 182BE35809; Fri, 15 Jun 2001 19:54:22 +0200 (CEST) Received: from 62.242.140.98 (SquirrelMail authenticated user mark@nellemann.nu) by webmail.drscallcenter.dk with HTTP; Fri, 15 Jun 2001 19:48:13 +0200 (CEST) Message-ID: <32076.62.242.140.98.992627293.squirrel@webmail.drscallcenter.dk> Date: Fri, 15 Jun 2001 19:48:13 +0200 (CEST) Subject: Re: Another newbie question, O2 this time From: "Mark Nellemann" To: In-Reply-To: References: Cc: X-Mailer: SquirrelMail (version 1.1.2) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_em7_CFpi+gD-0/d3m6/Far1wwnbV.pD_cA3yL)YSJwZ158yPbQw',,Bhl34O" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1036 Lines: 40 ------=_em7_CFpi+gD-0/d3m6/Far1wwnbV.pD_cA3yL)YSJwZ158yPbQw',,Bhl34O Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am willing to help all I can, but i'm no expert. I got an O2 R5000 at a friends place, which I can also use if that will help. Please let me know what I can do to help. /Mark > Linux will (possibly) boot uncached, and will at some point work. If > you're willing to help us get it farther that would be terrific. > Nick > > On Fri, 15 Jun 2001, Mark Nellemann wrote: > >> >> Hi, >> >> There's a chance that I can get my hands on a O2 (with a R12000 cpu). >> Will Linux run on that hardware, and is it easy to install? I have >> been using Linux for many years, but only on x86 and recently ppc. >> >> >> /Mark >> >> ------=_em7_CFpi+gD-0/d3m6/Far1wwnbV.pD_cA3yL)YSJwZ158yPbQw',,Bhl34O Content-Type: ; name="" Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= ------=_em7_CFpi+gD-0/d3m6/Far1wwnbV.pD_cA3yL)YSJwZ158yPbQw',,Bhl34O-- From owner-linux-mips@oss.sgi.com Fri Jun 15 11:11:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIB0j22462 for linux-mips-outgoing; Fri, 15 Jun 2001 11:11:00 -0700 Received: from cassidy.nuernberg.linuxtag.net (cassidy.nuernberg.linuxtag.net [212.204.83.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIAwk22459 for ; Fri, 15 Jun 2001 11:10:58 -0700 Received: from hydra.linuxtag.uni-kl.de (hydra.hq.linuxtag.net [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id 1EB00EC28F; Fri, 15 Jun 2001 20:10:21 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id ABFA95005; Fri, 15 Jun 2001 20:08:28 +0200 (CEST) Date: Fri, 15 Jun 2001 20:08:28 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: First version of sid-based root-tarball for mipsel available Message-ID: <20010615200828.A19897@linuxtag.org> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com, debian-mips@lists.debian.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 414 Lines: 12 Hallo everyone, I have put together a first version of a root-tarball for mipsel based on Debian "Sid". This is mostly untested yet and due to the SYSMIPS-problem it works only on R4K and higher. If somebody wants to try it out, please let me know the results. The tarball can be found at ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/rootfs/experimental/debian-mipsel-rootfs-20010615.tar.bz2 Greetings, Karsten From owner-linux-mips@oss.sgi.com Fri Jun 15 12:06:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJ6Mt26623 for linux-mips-outgoing; Fri, 15 Jun 2001 12:06:22 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJ6Lk26620 for ; Fri, 15 Jun 2001 12:06:21 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 413017D9; Fri, 15 Jun 2001 21:06:20 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D2D7C42FF; Fri, 15 Jun 2001 21:04:33 +0200 (CEST) Date: Fri, 15 Jun 2001 21:04:33 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: 2.4.5 in cvs - Did anyone try ? Message-ID: <20010615210433.A4282@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 392 Lines: 12 Hi, i am just trying 2.4.5 on an Indy and i have no luck. The kernel gets confused very fast on the root ext2 filesystem the 2.4.3 continues to boot from. It is spitting our "EXT2: Bit already set for inode x" and hangs in a tight loop. 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 Fri Jun 15 12:41:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJfYr27343 for linux-mips-outgoing; Fri, 15 Jun 2001 12:41:34 -0700 Received: from tennyson.netexpress.net (IDENT:root@tennyson.netexpress.net [64.22.192.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJfVk27340 for ; Fri, 15 Jun 2001 12:41:31 -0700 Received: from localhost (vorlon@localhost) by tennyson.netexpress.net (8.9.3/8.9.3) with ESMTP id OAA02136; Fri, 15 Jun 2001 14:41:30 -0500 X-Authentication-Warning: tennyson.netexpress.net: vorlon owned process doing -bs Date: Fri, 15 Jun 2001 14:41:30 -0500 (CDT) From: Steve Langasek To: cc: Subject: Re: First version of sid-based root-tarball for mipsel available In-Reply-To: <20010615200828.A19897@linuxtag.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1052 Lines: 28 Hi Karsten, On Fri, 15 Jun 2001, Karsten Merker wrote: > Hallo everyone, > I have put together a first version of a root-tarball for mipsel based on > Debian "Sid". This is mostly untested yet and due to the SYSMIPS-problem > it works only on R4K and higher. If somebody wants to try it out, please > let me know the results. > The tarball can be found at > ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/rootfs/experimental/debian-mipsel-rootfs-20010615.tar.bz2 I'd be interested to give this a try, if only I could get a recent Linux kernel booting on my system. :) My Cobalt CacheRaq has so far resisted all of my efforts to get 2.4 booting; it finds the kernel I've compiled, gets as far as starting to load the filesystems, but then goes into a loop reporting problems with 'spurious interrupts'. So either I'm running the wrong patch against the 2.4.0 sources, or the CacheRaq is not yet well-supported under 2.4. Karsten, what type of system are you doing your mipsel testing/development on? Regards, Steve Langasek postmodern programmer From owner-linux-mips@oss.sgi.com Fri Jun 15 13:00:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FK0OT27637 for linux-mips-outgoing; Fri, 15 Jun 2001 13:00:24 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FK0Mk27634 for ; Fri, 15 Jun 2001 13:00:22 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id A77813E90; Fri, 15 Jun 2001 12:56:25 -0700 (PDT) Date: Fri, 15 Jun 2001 12:56:25 -0700 From: Keith M Wesolowski To: Mark Nellemann Cc: nick@snowman.net, linux-mips@oss.sgi.com Subject: Re: Another newbie question, O2 this time Message-ID: <20010615125625.A24238@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32076.62.242.140.98.992627293.squirrel@webmail.drscallcenter.dk> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1016 Lines: 23 On Fri, Jun 15, 2001 at 07:48:13PM +0200, Mark Nellemann wrote: > I am willing to help all I can, but i'm no expert. I got an O2 R5000 at a > friends place, which I can also use if that will help. > > Please let me know what I can do to help. O2 r5k should definitely boot uncached and might even work to some extent. r12k will work in theory but nobody has ever tried. Expect problems. The most important thing you can do to help is grab the tree, build it, try it, and tell me what you have, what works, and what doesn't work. If you're a hacker, add the most important step, "Fix what doesn't work." I've reviewed the code about 5 times and haven't been able to find what's wrong. This code desperately needs additional sets of eyes peering at it. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Fri Jun 15 13:32:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FKWvU28041 for linux-mips-outgoing; Fri, 15 Jun 2001 13:32:57 -0700 Received: from cassidy.nuernberg.linuxtag.net (cassidy.nuernberg.linuxtag.net [212.204.83.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FKWuk28038 for ; Fri, 15 Jun 2001 13:32:56 -0700 Received: from hydra.linuxtag.uni-kl.de (hydra.hq.linuxtag.net [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id AEE01EC28F; Fri, 15 Jun 2001 22:32:19 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id C9A8D1BC0; Fri, 15 Jun 2001 22:30:25 +0200 (CEST) Date: Fri, 15 Jun 2001 22:30:25 +0200 From: Karsten Merker To: Steve Langasek Cc: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: Re: First version of sid-based root-tarball for mipsel available Message-ID: <20010615223025.A21400@linuxtag.org> Mail-Followup-To: Karsten Merker , Steve Langasek , linux-mips@oss.sgi.com, debian-mips@lists.debian.org References: <20010615200828.A19897@linuxtag.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.15i In-Reply-To: ; from vorlon@netexpress.net on Fri, Jun 15, 2001 at 02:41:30PM -0500 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 785 Lines: 22 On Fri, Jun 15, 2001 at 02:41:30PM -0500, Steve Langasek wrote: [root-tarball based on Debian "Sid"] > I'd be interested to give this a try, if only I could get a recent Linux > kernel booting on my system. :) My Cobalt CacheRaq has so far resisted all of > my efforts to get 2.4 booting; Sorry, I have not yet had the chance to try Linux/MIPS on Cobalt hardware. > Karsten, what type of system are you doing your mipsel testing/development on? I use a DECstation 5000/150 (50MHz R4k) and do a part of the development on repeat.rfc822.org, one of Florian Lohoff's machines (see http://www.debian.org/ports/mips). Greetings, Karsten -- Gem. §28 Abs. 3 BDSG widerspreche ich der Nutzung und Weitergabe meiner personenbezogenen Daten zum Zwecke der Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Fri Jun 15 19:15:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5G2FAY31704 for linux-mips-outgoing; Fri, 15 Jun 2001 19:15:10 -0700 Received: from dea.waldorf-gmbh.de (u-5-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5G2F7k31700 for ; Fri, 15 Jun 2001 19:15:08 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5G2Et819919; Sat, 16 Jun 2001 04:14:55 +0200 Date: Sat, 16 Jun 2001 04:14:55 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: 2.4.5 in cvs - Did anyone try ? Message-ID: <20010616041455.A19841@bacchus.dhis.org> References: <20010615210433.A4282@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: <20010615210433.A4282@paradigm.rfc822.org>; from flo@rfc822.org on Fri, Jun 15, 2001 at 09:04:33PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 419 Lines: 11 On Fri, Jun 15, 2001 at 09:04:33PM +0200, Florian Lohoff wrote: > i am just trying 2.4.5 on an Indy and i have no luck. The kernel > gets confused very fast on the root ext2 filesystem the 2.4.3 continues > to boot from. It is spitting our "EXT2: Bit already set for inode x" > and hangs in a tight loop. There was a stupid braino in include/asm-mips/bitops.h, make sure you have revision 1.16 of that file. Ralf From owner-linux-mips@oss.sgi.com Sat Jun 16 02:14:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5G9Er701587 for linux-mips-outgoing; Sat, 16 Jun 2001 02:14:53 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5G9EmZ01584; Sat, 16 Jun 2001 02:14:49 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id AEF647FD; Sat, 16 Jun 2001 11:14:46 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 431F042FF; Sat, 16 Jun 2001 11:14:43 +0200 (CEST) Date: Sat, 16 Jun 2001 11:14:43 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: 2.4.5 in cvs - Did anyone try ? Message-ID: <20010616111443.A9156@paradigm.rfc822.org> References: <20010615210433.A4282@paradigm.rfc822.org> <20010616041455.A19841@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010616041455.A19841@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jun 16, 2001 at 04:14:55AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 671 Lines: 18 On Sat, Jun 16, 2001 at 04:14:55AM +0200, Ralf Baechle wrote: > On Fri, Jun 15, 2001 at 09:04:33PM +0200, Florian Lohoff wrote: > > > i am just trying 2.4.5 on an Indy and i have no luck. The kernel > > gets confused very fast on the root ext2 filesystem the 2.4.3 continues > > to boot from. It is spitting our "EXT2: Bit already set for inode x" > > and hangs in a tight loop. > > There was a stupid braino in include/asm-mips/bitops.h, make sure you > have revision 1.16 of that file. I have 1.16 of that file. 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 Sat Jun 16 04:00:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GB06u02313 for linux-mips-outgoing; Sat, 16 Jun 2001 04:00:06 -0700 Received: from dea.waldorf-gmbh.de (u-15-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GB00Z02300 for ; Sat, 16 Jun 2001 04:00:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5G9OIl21310; Sat, 16 Jun 2001 11:24:18 +0200 Date: Sat, 16 Jun 2001 11:24:18 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Keith Owens , Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: Kernel crash on boot with current cvs (todays) Message-ID: <20010616112418.B21117@bacchus.dhis.org> References: <20010613140550.B31221@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 Wed, Jun 13, 2001 at 03:44:28PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 703 Lines: 15 On Wed, Jun 13, 2001 at 03:44:28PM +0200, Maciej W. Rozycki wrote: > The point is whether addresses should be extended at all if a 32-bit > target is selected. IMHO -- not, that's a limitation of BFD when > configured for both a 32-bit and a 64-bit target and it should be fixed > sooner or later (at least it's on my to-do list for some time). BFD is > free to handle addresses as it likes internally, be it 64-bit or 32-bit, > but they should be truncated on final output to a 32-bit target, as they > already are for certain cases. Agreed, that'd be much more readable for humans. For processing by software having some canonical form, that is 64-bit would be a bit more handy though. Ralf From owner-linux-mips@oss.sgi.com Sat Jun 16 04:05:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GB5tk02565 for linux-mips-outgoing; Sat, 16 Jun 2001 04:05:55 -0700 Received: from dea.waldorf-gmbh.de (u-43-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GB5fZ02561 for ; Sat, 16 Jun 2001 04:05:41 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5G9MKC21300; Sat, 16 Jun 2001 11:22:20 +0200 Date: Sat, 16 Jun 2001 11:22:20 +0200 From: Ralf Baechle To: Keith Owens Cc: Florian Lohoff , Raoul Borenius , linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips (was Kernel crash on boot with current cvs) Message-ID: <20010616112220.A21117@bacchus.dhis.org> References: <20010613140550.B31221@bacchus.dhis.org> <8465.992434754@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8465.992434754@ocs4.ocs-net>; from kaos@melbourne.sgi.com on Wed, Jun 13, 2001 at 10:19:14PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1319 Lines: 28 On Wed, Jun 13, 2001 at 10:19:14PM +1000, Keith Owens wrote: > >That can be done automatically. For 32-bit ELF files mips*-linux binutils > >dump some of the addresses as 32-bit addresses, some as sign-extended (!) > >64-bit addresses. So ksymops should just sign extend any 32-bit addresses > >to 64-bit and then work on full lenght addresses. > > Some utilities extend with leading 0, some with leading 1, some with > special values (alpha). It is safer to truncate everything to the > specified width instead of guessing what the extension value is. That's a processor specific thing. In case of MIPS only signed extension is correct. Some older binutils did unsigned extension and that's plain wrong. > >Is ksymoops able to handle 64-bit addresses when running on a 32-bit host? > >That is a common case for many people when decoding their MIPS oopses. > > Yes and no. The framework is there to handle 32/64 splits, sparc > already uses it. mips does not currently use the framework because the > oops report does not identify the machine type 32/64, MSB/LSB. We > discussed this in January and I asked for a small change to mips64 oops > output (below), was that ever done? Nothing - ``Guilty as charged. Filed in my "to do when I have time" folder, which overflowed about 3 years ago :(.'' Ralf From owner-linux-mips@oss.sgi.com Sat Jun 16 08:21:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GFLWH04888 for linux-mips-outgoing; Sat, 16 Jun 2001 08:21:32 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GFLTZ04883 for ; Sat, 16 Jun 2001 08:21:29 -0700 Received: from scotty.mgnet.de (pD902470A.dip.t-dialin.net [217.2.71.10]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id RAA18626 for ; Sat, 16 Jun 2001 17:21:26 +0200 (MET DST) Received: (qmail 17492 invoked from network); 16 Jun 2001 15:21:21 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 16 Jun 2001 15:21:21 -0000 Date: Sat, 16 Jun 2001 17:21:18 +0200 (CEST) From: Klaus Naumann To: Linux/MIPS list cc: Ralf Baechle Subject: [PATCH] Make serial console more friendly Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811071-2031406748-992704878=:16303" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6183 Lines: 116 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811071-2031406748-992704878=:16303 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, after a long time of being busy and absent from Linux/MIPS I got around hacking a bit again. Attached is what came out of this. The patch will make it possible to use any (supported!) speed for the serial console. How to use: Apply against any recent 2.4 cvs kernel, compile. In the PROM command monitor type "setenv dbaud 38400" (now you probably need to change the serial setup of your client, i.e. minicom) and boot the kernel. If you're getting strange chars at the login prompt you need to change your getty config. Ralf: Can you please check and apply the patch ? Thanks ! (There are also some small code beautifications in the patch) Enjoy !, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt ---1463811071-2031406748-992704878=:16303 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sgiserial.c-allspeed.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sgiserial.c-allspeed.patch" ZGlmZiAtTnVyIGxpbnV4Lm9yaWcvZHJpdmVycy9zZ2kvY2hhci9zZ2lzZXJp YWwuYyBsaW51eC9kcml2ZXJzL3NnaS9jaGFyL3NnaXNlcmlhbC5jDQotLS0g bGludXgub3JpZy9kcml2ZXJzL3NnaS9jaGFyL3NnaXNlcmlhbC5jCVRodSBK dW4gMTQgMjA6Mjg6NDYgMjAwMQ0KKysrIGxpbnV4L2RyaXZlcnMvc2dpL2No YXIvc2dpc2VyaWFsLmMJU2F0IEp1biAxNiAxNzowNDowMiAyMDAxDQpAQCAt MTMsNiArMTMsMTMgQEANCiAgKiB0aG9yb3VnaCBwYXNzIHRvIG1lcmdlIGlu IHRoZSByZXN0IG9mIHRoZSB1cGRhdGVzLg0KICAqIEJldHRlciBzdGlsbCwg c29tZW9uZSByZWFsbHkgb3VnaHQgdG8gbWFrZSBpdCBhIGNvbW1vbg0KICAq IGNvZGUgbW9kdWxlIGZvciBib3RoIHBsYXRmb3Jtcy4gICBrZXZpbmtAbWlw cy5jb20NCisgKg0KKyAqDQorICoNCisgKiAyMDAxMDYxNiAtIEtsYXVzIE5h dW1hbm4gPHNwb2NrQG1nbmV0LmRlPiA6IE1ha2Ugc2VyaWFsIGNvbnNvbGUg d29yayB3aXRoDQorICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhbnkgc3BlZWQgLSBub3Qgb25seSA5NjAwDQorICoN CisgKg0KICAqLw0KIA0KICNpbmNsdWRlIDxsaW51eC9jb25maWcuaD4gLyog Zm9yIENPTkZJR19SRU1PVEVfREVCVUcgKi8NCkBAIC05Nyw2ICsxMDQsNyBA QA0KIERFQ0xBUkVfVEFTS19RVUVVRSh0cV9zZXJpYWwpOw0KIA0KIHN0cnVj dCB0dHlfZHJpdmVyIHNlcmlhbF9kcml2ZXIsIGNhbGxvdXRfZHJpdmVyOw0K K3N0cnVjdCBjb25zb2xlICpzZ2lzZXJjb247DQogc3RhdGljIGludCBzZXJp YWxfcmVmY291bnQ7DQogDQogLyogc2VyaWFsIHN1YnR5cGUgZGVmaW5pdGlv bnMgKi8NCkBAIC02ODQsNyArNjkyLDcgQEANCiAJc2F2ZV9mbGFncyhmbGFn cyk7IGNsaSgpOw0KIA0KICNpZmRlZiBTRVJJQUxfREVCVUdfT1BFTg0KLQlw cmludGsoInN0YXJ0aW5nIHVwIHR0eXMlZCAoaXJxICVkKS4uLiIsIGluZm8t PmxpbmUsIGluZm8tPmlycSk7DQorCXByaW50aygic3RhcnRpbmcgdXAgdHR5 cyVkIChpcnEgJWQpLi4uXG4iLCBpbmZvLT5saW5lLCBpbmZvLT5pcnEpOw0K ICNlbmRpZg0KIA0KIAkvKg0KQEAgLTE3NzIsMTEgKzE3ODAsMTkgQEANCiAJ CWNoYW5nZV9zcGVlZChpbmZvKTsNCiAJfQ0KIA0KKwkvKiBJZiB0aGlzIGlz IHRoZSBzZXJpYWwgY29uc29sZSBjaGFuZ2UgdGhlIHNwZWVkIHRvIA0KKwkg KiB0aGUgcmlnaHQgdmFsdWUNCisJICovDQorCWlmIChpbmZvLT5pc19jb25z KSB7DQorCQlpbmZvLT50dHktPnRlcm1pb3MtPmNfY2ZsYWcgPSBzZ2lzZXJj b24tPmNmbGFnOw0KKwkJY2hhbmdlX3NwZWVkKGluZm8pOwkJDQorCX0NCisN CiAJaW5mby0+c2Vzc2lvbiA9IGN1cnJlbnQtPnNlc3Npb247DQogCWluZm8t PnBncnAgPSBjdXJyZW50LT5wZ3JwOw0KIA0KICNpZmRlZiBTRVJJQUxfREVC VUdfT1BFTg0KLQlwcmludGsoInJzX29wZW4gdHR5cyVkIHN1Y2Nlc3NmdWwu Li4iLCBpbmZvLT5saW5lKTsNCisJcHJpbnRrKCJyc19vcGVuIHR0eXMlZCBz dWNjZXNzZnVsLi4uXG4iLCBpbmZvLT5saW5lKTsNCiAjZW5kaWYNCiAJcmV0 dXJuIDA7DQogfQ0KQEAgLTE4MjYsOSArMTg0Miw2IEBADQogCX0NCiAJaWYo byAmJiBpKQ0KIAkJaW8gPSAxOw0KLQlpZiAoc3MtPnpzX2JhdWQgIT0gOTU2 MikJLyogRG9uJ3QgYXNrLi4uICovDQotCQlwYW5pYygiQmFkIGNvbnNvbGUg YmF1ZCByYXRlICVkIiwgc3MtPnpzX2JhdWQpOw0KLQ0KIA0KIAkvKiBTZXQg ZmxhZyB2YXJpYWJsZSBmb3IgdGhpcyBwb3J0IHNvIHRoYXQgaXQgY2Fubm90 IGJlDQogCSAqIG9wZW5lZCBmb3Igb3RoZXIgdXNlcyBieSBhY2NpZGVudC4N CkBAIC0yMDM5LDcgKzIwNTIsNiBAQA0KIHJzX2NvbnNfaG9vayhpbnQgY2hp cCwgaW50IG91dCwgaW50IGxpbmUpDQogew0KIAlpbnQgY2hhbm5lbDsNCi0N CiAJDQogCWlmKGNoaXApDQogCQlwYW5pYygicnNfY29uc19ob29rIGNhbGxl ZCB3aXRoIGNoaXAgbm90IHplcm8iKTsNCkBAIC0yMTI0LDExICsyMTM2LDEx IEBADQogc3RhdGljIGludCBfX2luaXQgenNfY29uc29sZV9zZXR1cChzdHJ1 Y3QgY29uc29sZSAqY29uLCBjaGFyICpvcHRpb25zKQ0KIHsNCiAJc3RydWN0 IHNnaV9zZXJpYWwgKmluZm87DQotCWludAliYXVkID0gOTYwMDsNCisJaW50 CWJhdWQ7DQogCWludAliaXRzID0gODsNCiAJaW50CXBhcml0eSA9ICduJzsN CiAJaW50CWNmbGFnID0gQ1JFQUQgfCBIVVBDTCB8IENMT0NBTDsNCi0JY2hh cgkqczsNCisJY2hhcgkqcywgKmRiYXVkOw0KIAlpbnQgICAgIGksIGJyZzsN CiAgICAgDQogCWlmIChvcHRpb25zKSB7DQpAQCAtMjEzOSw2ICsyMTUxLDIx IEBADQogCQlpZiAoKnMpIHBhcml0eSA9ICpzKys7DQogCQlpZiAoKnMpIGJp dHMgICA9ICpzIC0gJzAnOw0KIAl9DQorCWVsc2Ugew0KKwkJLyogSWYgdGhl IHVzZXIgZG9lc24ndCBzZXQgY29uc29sZT0uLi4gdHJ5IHRvIHJlYWQgdGhl DQorCQkgKiBQUk9NIHZhcmlhYmxlIC0gaWYgdGhpcyBmYWlscyB1c2UgOTYw MCBiYXVkIGFuZA0KKwkJICogaW5mb3JtIHRoZSB1c2VyIGFib3V0IHRoZSBw cm9ibGVtDQorCQkgKi8NCisJCWRiYXVkID0gQXJjR2V0RW52aXJvbm1lbnRW YXJpYWJsZSgiZGJhdWQiKTsNCisJCWlmKGRiYXVkKSBiYXVkID0gc2ltcGxl X3N0cnRvdWwoZGJhdWQsIE5VTEwsIDEwKTsNCisJCWVsc2Ugew0KKwkJCS8q IFVzZSBwcm9tX3ByaW50ZigpIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSB1c2Vy DQorCQkJICogaXMgZ2V0dGluZyBhbnl0aGluZyAuLi4NCisJCQkgKi8NCisJ CQlwcm9tX3ByaW50ZigiTm8gZGJhdWQgc2V0IGluIFBST00gPyE/IFVzaW5n IDk2MDAuXG4iKTsNCisJCQliYXVkID0gOTYwMDsNCisJCX0NCisJfQ0KIA0K IAkvKg0KIAkgKglOb3cgY29uc3RydWN0IGEgY2ZsYWcgc2V0dGluZy4NCkBA IC0yMTkzLDcgKzIyMjAsOCBAQA0KIAlpbmZvID0genNfc29mdCArIGNvbi0+ aW5kZXg7DQogCWluZm8tPmlzX2NvbnMgPSAxOw0KICAgICANCi0JcHJpbnRr KCJDb25zb2xlOiB0dHlTJWQgKFppbG9nODUzMClcbiIsIGluZm8tPmxpbmUp Ow0KKwlwcmludGsoIkNvbnNvbGU6IHR0eVMlZCAoWmlsb2c4NTMwKSwgJWQg YmF1ZFxuIiwgDQorCQkJCQkJaW5mby0+bGluZSwgYmF1ZCk7DQogDQogCWkg PSBjb24tPmNmbGFnICYgQ0JBVUQ7DQogCWlmIChjb24tPmNmbGFnICYgQ0JB VURFWCkgew0KQEAgLTIyMzIsNiArMjI2MCw4IEBADQogCQl6c2NvbnNfcmVn c1s0XSB8PSBTQjI7DQogCWVsc2UNCiAJCXpzY29uc19yZWdzWzRdIHw9IFNC MTsNCisJDQorCXNnaXNlcmNvbiA9IGNvbjsNCiANCiAJYnJnID0gQlBTX1RP X0JSRyhiYXVkLCBaU19DTE9DSyAvIGluZm8tPmNsa19kaXZpc29yKTsNCiAJ enNjb25zX3JlZ3NbMTJdID0gYnJnICYgMHhmZjsNCg== ---1463811071-2031406748-992704878=:16303-- From owner-linux-mips@oss.sgi.com Sat Jun 16 11:06:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GI6dj06380 for linux-mips-outgoing; Sat, 16 Jun 2001 11:06:39 -0700 Received: from dea.waldorf-gmbh.de (u-169-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.169]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GI6ZZ06377 for ; Sat, 16 Jun 2001 11:06:36 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5GI6NX23050; Sat, 16 Jun 2001 20:06:23 +0200 Date: Sat, 16 Jun 2001 20:06:23 +0200 From: Ralf Baechle To: Klaus Naumann Cc: Linux/MIPS list Subject: Re: [PATCH] Make serial console more friendly Message-ID: <20010616200623.A22976@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 spock@mgnet.de on Sat, Jun 16, 2001 at 05:21:18PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 751 Lines: 19 On Sat, Jun 16, 2001 at 05:21:18PM +0200, Klaus Naumann wrote: > after a long time of being busy and absent from Linux/MIPS > I got around hacking a bit again. > Attached is what came out of this. The patch will make it possible > to use any (supported!) speed for the serial console. > How to use: Apply against any recent 2.4 cvs kernel, compile. > In the PROM command monitor type "setenv dbaud 38400" (now you probably > need to change the serial setup of your client, i.e. minicom) and boot the > kernel. > If you're getting strange chars at the login prompt you need > to change your getty config. > > Ralf: Can you please check and apply the patch ? Thanks ! > (There are also some small code beautifications in the patch) Applied. Ralf From owner-linux-mips@oss.sgi.com Sat Jun 16 11:10:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GIAIc06454 for linux-mips-outgoing; Sat, 16 Jun 2001 11:10:18 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GIAHZ06451 for ; Sat, 16 Jun 2001 11:10:18 -0700 Received: from sohorob (sc-66-27-45-152.socal.rr.com [66.27.45.152]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5GIAFV01631 for ; Sat, 16 Jun 2001 11:10:15 -0700 From: "Robert Rusek" To: Subject: RedHat Test-7.0 Compiler problems. Date: Sat, 16 Jun 2001 11:10:16 -0700 Message-ID: <000f01c0f68f$99019d70$6400a8c0@sohorob> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C0F654.ECA2C570" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2204 Lines: 63 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C0F654.ECA2C570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Which rpm(s) contains the following files: crti.o, crt1.o... etc... I am trying to compile apache and it is telling me that the c pre-processer is not available. Do the compilers work in test-7.0? Thanks in advance, -- Robert Rusek ------=_NextPart_000_0010_01C0F654.ECA2C570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Which=20 rpm(s) contains the following files:
 
crti.o, crt1.o...=20 etc...
 
I am trying to compile apache and it is telling me that the c=20 pre-processer is not available.  = Do the=20 compilers work in test-7.0?
 
Thanks=20 in advance,
--
Robert=20 Rusek
 
------=_NextPart_000_0010_01C0F654.ECA2C570-- From owner-linux-mips@oss.sgi.com Sat Jun 16 12:51:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GJpPr14045 for linux-mips-outgoing; Sat, 16 Jun 2001 12:51:25 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GJpLZ14039 for ; Sat, 16 Jun 2001 12:51:21 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06304 for ; Sat, 16 Jun 2001 12:51:15 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15BLwM-0008Az-00 for ; Sat, 16 Jun 2001 12:41:02 -0700 Date: Sat, 16 Jun 2001 12:41:02 -0700 From: Daniel Jacobowitz To: linux-mips@oss.sgi.com Subject: [patch flood] Debugging patches Message-ID: <20010616124102.A31141@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.3.16i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13392 Lines: 425 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've been actively working on GDB for the past two weeks now. A good half of the problems I've had have turned out to be kernel bugs; one of them (shadowing res in the POKEUSR case in sys_ptrace) was already fixed in the OSS tree and not in our local tree, but the others were still somewhat interesting. The biggest one was the fact that passing arguments to the inferior in floating point registers just didn't work. I tracked this down to at least three separate problems: - We would set last_task_used_math without clearing the ST0_CU1 bit in the previous task owning the FPU. When that previous task swapped in again, it would use the existing FP registers, and lazy_fpu_switch would never be called. This happened in signal.c and in ptrace.c. - ptrace didn't look for the FP registers in the right places. This's been broken since the FPU emulator merge a while back. - We would create new processes with the ST0_CU1 bit already set if their parent process had it set. Of course, the lazy switching isn't quite as useful as it could be, since every program will eventually use the FPU if not build -msoft-float - I think it's happening in glibc. But we can possibly work around that later. It still does save a great number of switches, so it's worthwhile - when it works. Other patches in my directory that I'm submitting along with that one: - kgdb-crash-resistant.diff This makes kgdb survive an attempt to dereference bad memory. It only works after memory management has been set up, though. It's possible to do it in such a way that it works even earlier - see PowerPC for an example. We would have to set the fault handler temporarily, and basically longjmp out of the fault handler. This is much more straightforward, and met my needs at the time. - mips-gdb-with-kgdb.diff There's no good reason to trigger kgdb on any trap whose origin is in userland - it's a kernel debugger, right? So I save the traps, and pass them along to the old handlers if necessary. This way kgdb won't stop on SIGTRAP when you set a breakpoint in gdb. - mips-rtsignal.diff Thought I'd sent this already... but I guess not. setup_frame and setup_rt_frame build structures of different sizes, matching sys_sigreturn and sys_rt_sigreturn respectively. Wouldn't it be useful if the frame setup_rt_frame built returned into the right function? -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fpu-sharing.diff" Index: arch/mips/kernel/ptrace.c =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/arch/mips/kernel/ptrace.c,v retrieving revision 1.3 diff -u -r1.3 ptrace.c --- arch/mips/kernel/ptrace.c 2001/06/15 00:58:41 1.3 +++ arch/mips/kernel/ptrace.c 2001/06/16 19:06:59 @@ -149,8 +149,19 @@ save_fp(child); disable_cp1(); last_task_used_math = NULL; + regs->cp0_status &= ~ST0_CU1; } - tmp = (unsigned long) fregs[(addr - 32)]; + /* The odd registers are actually the high order bits of the values + stored in the even registers - unless we're using r2k_switch.S. */ +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R3912) + if (mips_cpu_options & MIPS_CPU_FPU) + tmp = *(unsigned long *)(fregs + addr); + else +#endif + if (addr & 1) + tmp = (unsigned long) (fregs[((addr & ~1) - 32)] >> 32); + else + tmp = (unsigned long) (fregs[(addr - 32)] & 0xffffffff); } else { tmp = -1; /* FP not yet used */ } @@ -238,8 +249,21 @@ memset(&child->thread.fpu.hard, ~0, sizeof(child->thread.fpu.hard)); child->thread.fpu.hard.control = 0; + } + /* The odd registers are actually the high order bits of the values + stored in the even registers - unless we're using r2k_switch.S. */ +#if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R3912) + if (mips_cpu_options & MIPS_CPU_FPU) + *(unsigned long *)(fregs + addr) = data; + else +#endif + if (addr & 1) { + fregs[(addr & ~1) - FPR_BASE] &= 0xffffffff; + fregs[(addr & ~1) - FPR_BASE] |= ((unsigned long long) data) << 32; + } else { + fregs[addr - FPR_BASE] &= ~0xffffffffLL; + fregs[addr - FPR_BASE] |= data; } - fregs[addr - FPR_BASE] = data; break; } case PC: Index: arch/mips/kernel/signal.c =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/arch/mips/kernel/signal.c,v retrieving revision 1.2 diff -u -r1.2 signal.c --- arch/mips/kernel/signal.c 2001/05/30 00:08:10 1.2 +++ arch/mips/kernel/signal.c 2001/06/16 19:06:59 @@ -220,8 +220,10 @@ err |= __get_user(owned_fp, &sc->sc_ownedfp); if (owned_fp) { + if (last_task_used_math && (last_task_used_math != current)) + last_task_used_math->thread.cp0_status &= ~ST0_CU1; err |= restore_fp_context(sc); last_task_used_math = current; } return err; @@ -353,12 +355,11 @@ owned_fp = (current == last_task_used_math); err |= __put_user(owned_fp, &sc->sc_ownedfp); - if (current->used_math) { /* fp is active. */ + if (owned_fp) { /* fp is active. */ set_cp0_status(ST0_CU1); err |= save_fp_context(sc); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; - current->used_math = 0; } return err; Index: include/asm-mips/processor.h =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/include/asm-mips/processor.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 processor.h --- include/asm-mips/processor.h 2001/03/27 22:01:19 1.1.1.2 +++ include/asm-mips/processor.h 2001/06/16 19:07:05 @@ -235,8 +235,8 @@ * Do necessary setup to start up a newly executed thread. */ #define start_thread(regs, new_pc, new_sp) do { \ - /* New thread looses kernel privileges. */ \ - regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU)) | KU_USER;\ + /* New thread loses kernel and FPU privileges. */ \ + regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\ regs->cp0_epc = new_pc; \ regs->regs[29] = new_sp; \ current->thread.current_ds = USER_DS; \ --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kgdb-crash-resistant.diff" Index: arch/mips/kernel/gdb-low.S =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/arch/mips/kernel/gdb-low.S,v retrieving revision 1.2 diff -u -r1.2 gdb-low.S --- arch/mips/kernel/gdb-low.S 2001/06/15 00:58:41 1.2 +++ arch/mips/kernel/gdb-low.S 2001/06/16 19:06:59 @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -314,3 +315,36 @@ .set at .set reorder END(trap_low) + +LEAF(kgdb_read_byte) + .set push + .set noreorder + .set nomacro +4: lb t0, (a0) + .set pop + sb t0, (a1) + li v0, 0 + jr ra + .section __ex_table,"a" + PTR 4b, kgdbfault + .previous + END(kgdb_read_byte) + +LEAF(kgdb_write_byte) + .set push + .set noreorder + .set nomacro +5: sb a0, (a1) + .set pop + li v0, 0 + jr ra + .section __ex_table,"a" + PTR 5b, kgdbfault + .previous + END(kgdb_write_byte) + + .type kgdbfault@function + .ent kgdbfault +kgdbfault: li v0, -EFAULT + jr ra + .end kgdbfault Index: arch/mips/kernel/gdb-stub.c =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/arch/mips/kernel/gdb-stub.c,v retrieving revision 1.2 diff -u -r1.2 gdb-stub.c --- arch/mips/kernel/gdb-stub.c 2001/06/15 00:58:41 1.2 +++ arch/mips/kernel/gdb-stub.c 2001/06/16 19:06:59 @@ -140,7 +140,6 @@ extern int putDebugChar(char c); /* write a single character */ extern char getDebugChar(void); /* read and return a single char */ -extern void fltr_set_mem_err(void); extern void trap_low(void); /* @@ -173,6 +172,10 @@ static int initialized; /* !0 means we've been initialized */ static const char hexchars[]="0123456789abcdef"; +/* Used to prevent crashes in memory access. Note that they'll crash anyway if + we haven't set up fault handlers yet... */ +int kgdb_read_byte(unsigned *address, unsigned *dest); +int kgdb_write_byte(unsigned val, unsigned *dest); /* * Convert ch from a hex digit to an int @@ -292,42 +295,18 @@ /* - * Indicate to caller of mem2hex or hex2mem that there - * has been an error. - */ -static volatile int mem_err = 0; - - -#if 0 -static void set_mem_fault_trap(int enable) -{ - mem_err = 0; - -#if 0 - if (enable) - exceptionHandler(9, fltr_set_mem_err); - else - exceptionHandler(9, trap_low); -#endif -} -#endif /* dead code */ - -/* * Convert the memory pointed to by mem into hex, placing result in buf. * Return a pointer to the last char put in buf (null), in case of mem fault, * return 0. - * If MAY_FAULT is non-zero, then we will handle memory faults by returning - * a 0, else treat a fault like any other fault in the stub. + * may_fault is non-zero if we are reading from arbitrary memory, but is currently + * not used. */ static unsigned char *mem2hex(char *mem, char *buf, int count, int may_fault) { unsigned char ch; -/* set_mem_fault_trap(may_fault); */ - while (count-- > 0) { - ch = *(mem++); - if (mem_err) + if (kgdb_read_byte(mem++, &ch) != 0) return 0; *buf++ = hexchars[ch >> 4]; *buf++ = hexchars[ch & 0xf]; @@ -335,33 +314,28 @@ *buf = 0; -/* set_mem_fault_trap(0); */ - return buf; } /* * convert the hex array pointed to by buf into binary to be placed in mem * return a pointer to the character AFTER the last byte written + * may_fault is non-zero if we are reading from arbitrary memory, but is currently + * not used. */ static char *hex2mem(char *buf, char *mem, int count, int may_fault) { int i; unsigned char ch; -/* set_mem_fault_trap(may_fault); */ - for (i=0; itt && ht->signo; ht++) - set_except_vector(ht->tt, trap_low); + saved_vectors[ht->tt] = set_except_vector(ht->tt, trap_low); /* * In case GDB is started before us, ack any packets --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mips-rtsigreturn.diff" Index: signal.c =================================================================== RCS file: /cvsroot/hhl-2.4.2/linux/arch/mips/kernel/signal.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 signal.c --- signal.c 2001/03/27 22:03:28 1.1.1.2 +++ signal.c 2001/05/25 23:46:15 @@ -464,10 +464,10 @@ /* * Set up the return code ... * - * li v0, __NR_sigreturn + * li v0, __NR_rt_sigreturn * syscall */ - err |= __put_user(0x24020000 + __NR_sigreturn, + err |= __put_user(0x24020000 + __NR_rt_sigreturn, frame->rs_code + 0); err |= __put_user(0x0000000c , frame->rs_code + 1); --6TrnltStXW4iwmi0-- From owner-linux-mips@oss.sgi.com Sat Jun 16 18:05:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H15cY02800 for linux-mips-outgoing; Sat, 16 Jun 2001 18:05:38 -0700 Received: from boss.zie.pg.gda.pl (boss.zie.pg.gda.pl [153.19.163.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H15ZZ02796 for ; Sat, 16 Jun 2001 18:05:36 -0700 Received: from team.pld.org.pl (team.pld.org.pl [153.19.163.20]) by boss.zie.pg.gda.pl (8.9.1b+Sun/8.8.7) with ESMTP id DAA18503 for ; Sun, 17 Jun 2001 03:05:29 +0200 (MET DST) Received: by team.pld.org.pl (Postfix, from userid 1023) id 168CF2989E; Sun, 17 Jun 2001 02:58:32 +0200 (CEST) Date: Sun, 17 Jun 2001 02:58:32 +0200 From: "Maciej Agaran' Pijanka" To: linux-mips@oss.sgi.com Subject: kernel 2.2.14 (cvs from oss.sgi.com) and compile problems Message-ID: <20010617025832.A18403@team.pld.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2592 Lines: 95 Hello im trying to recompile 2.2.14 from cvs (khmm 10 h ago cvsed, branch linux_2_2 ) and have problem with make boot mipsel-linux-ld -static -N -G 0 -T arch/mips/ld.script.little -Ttext 0x80040000 arch/mips/kernel/head.o arch/mips/kernel/init_task.o ini t/main.o init/version.o \ --start-group \ arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/dec/dec.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a dr ivers/video/video.a drivers/tc/tc.a \ arch/mips/lib/lib.a /home/users/pld/agaran/cvs/linux_2_2/lib/lib.a arch/mips/dec/prom/rexlib.a \ --end-group \ -o vmlinux drivers/char/char.a(tty_io.o): In function `tty_set_ldisc': tty_io.c(.text.init+0x338): undefined reference to `kbd_init' tty_io.c(.text.init+0x338): relocation truncated to fit: R_MIPS_26 kbd_init drivers/char/char.a(console.o): In function `redraw_screen': console.c(.text+0x1510): undefined reference to `compute_shiftstate' console.c(.text+0x1510): relocation truncated to fit: R_MIPS_26 compute_shiftstate drivers/char/char.a(console.o): In function `set_mode': console.c(.text+0x2ec8): undefined reference to `kbd_table' console.c(.text+0x2ed0): undefined reference to `kbd_table' and some info about kernel config and compiler egrep "^#|^$" .config CONFIG_EXPERIMENTAL=y CONFIG_DECSTATION=y CONFIG_CPU_R3000=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ELF_KERNEL=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_TC=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_PARIDE_PARPORT=m CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IPV6=m CONFIG_IPV6_EUI64=y CONFIG_IPV6_NO_PB=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_BLK_DEV_SR=m CONFIG_CHR_DEV_SG=m CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_DECNCR=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_PPP=m CONFIG_DECLANCE=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_ZS=y CONFIG_SERIAL_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=32 CONFIG_PROC_FS=y CONFIG_EXT2_FS=y CONFIG_NFS_FS=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_CROSSCOMPILE=y mipsel-linux-gcc -v Reading specs from /home/users/pld/agaran/lib/gcc-lib/mipsel-linux/egcs-2.90.27/specs gcc version egcs-2.90.27 980315 (egcs-1.0.2 release) -- Maciej 'Agaran' Pijanka agaran@team.pld.org.pl From owner-linux-mips@oss.sgi.com Sun Jun 17 02:31:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H9VSZ24893 for linux-mips-outgoing; Sun, 17 Jun 2001 02:31:28 -0700 Received: from dea.waldorf-gmbh.de (u-13-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H9VOZ24862 for ; Sun, 17 Jun 2001 02:31:25 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5H9V1w03290; Sun, 17 Jun 2001 11:31:01 +0200 Date: Sun, 17 Jun 2001 11:31:01 +0200 From: Ralf Baechle To: "Maciej Agaran' Pijanka" Cc: linux-mips@oss.sgi.com Subject: Re: kernel 2.2.14 (cvs from oss.sgi.com) and compile problems Message-ID: <20010617113100.B3216@bacchus.dhis.org> References: <20010617025832.A18403@team.pld.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010617025832.A18403@team.pld.org.pl>; from agaran@team.pld.org.pl on Sun, Jun 17, 2001 at 02:58:32AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 326 Lines: 9 On Sun, Jun 17, 2001 at 02:58:32AM +0200, Maciej Agaran' Pijanka wrote: > im trying to recompile 2.2.14 from cvs (khmm 10 h ago cvsed, branch > linux_2_2 ) and have problem with make boot There is a reason that DECstation is only selectable under CONFIG_EXPERIMENTAL in 2.2. I suggest to go for kernel 2.4 instead. Ralf From owner-linux-mips@oss.sgi.com Sun Jun 17 02:36:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H9aNA25763 for linux-mips-outgoing; Sun, 17 Jun 2001 02:36:23 -0700 Received: from dea.waldorf-gmbh.de (u-13-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H9aKZ25759 for ; Sun, 17 Jun 2001 02:36:20 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5H9a9f03309; Sun, 17 Jun 2001 11:36:09 +0200 Date: Sun, 17 Jun 2001 11:36:09 +0200 From: Ralf Baechle To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: RedHat Test-7.0 Compiler problems. Message-ID: <20010617113608.C3216@bacchus.dhis.org> References: <000f01c0f68f$99019d70$6400a8c0@sohorob> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000f01c0f68f$99019d70$6400a8c0@sohorob>; from robru@ruseks.com on Sat, Jun 16, 2001 at 11:10:16AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 348 Lines: 12 On Sat, Jun 16, 2001 at 11:10:16AM -0700, Robert Rusek wrote: > Which rpm(s) contains the following files: > > crti.o, crt1.o... etc... > > I am trying to compile apache and it is telling me that the c > pre-processer is not available. Do the compilers work in test-7.0? You'll find a great improvment if you install glibc-devel :-) Ralf From owner-linux-mips@oss.sgi.com Mon Jun 18 11:11:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIBmT17331 for linux-mips-outgoing; Mon, 18 Jun 2001 11:11:48 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIBkV17327 for ; Mon, 18 Jun 2001 11:11:47 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5IIBbq6012730 for ; Mon, 18 Jun 2001 20:11:39 +0200 Message-ID: <3B2E4458.1637A08A@murphy.dk> Date: Mon, 18 Jun 2001 20:11:36 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Problems with mips2 compiled libc and linux 2.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 774 Lines: 43 It seems that this check(in asm-mips/elf.h): #define elf_check_arch(hdr) \ ({ \ int __res = 1; \ struct elfhdr *__h = (hdr); \ \ if ((__h->e_machine != EM_MIPS) && \ (__h->e_machine != EM_MIPS_RS4_BE)) \ __res = 0; \ if (__h->e_flags & EF_MIPS_ARCH) \ __res = 0; \ \ __res; \ }) which is called in fs/binfmt_elf.c causes the loading of init to fail if it is linked with a glibc compiled with -mips2. It is the second if test which fails if any of the high 4 bits in the flags are set. According to the specs these are set for the various mipsx (x != 1) flavors - this seems to mean that we do no allow anything higher than mips1 run on linux - can this be true? If so, why? /Brian From owner-linux-mips@oss.sgi.com Mon Jun 18 11:22:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIMs218185 for linux-mips-outgoing; Mon, 18 Jun 2001 11:22:54 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIMsV18182 for ; Mon, 18 Jun 2001 11:22:54 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 56A98125BA; Mon, 18 Jun 2001 11:22:53 -0700 (PDT) Date: Mon, 18 Jun 2001 11:22:53 -0700 From: "H . J . Lu" To: Brian Murphy Cc: "linux-mips@oss.sgi.com" Subject: Re: Problems with mips2 compiled libc and linux 2.4.3 Message-ID: <20010618112253.A28744@lucon.org> References: <3B2E4458.1637A08A@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2E4458.1637A08A@murphy.dk>; from brian@murphy.dk on Mon, Jun 18, 2001 at 08:11:36PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 618 Lines: 22 On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote: > > it is linked with a glibc compiled with -mips2. It is the second if test I patched my kernel to get around it. > > which fails if any of the high 4 bits in the flags are set. According to > the > specs these are set for the various mipsx (x != 1) flavors - this seems > to mean > that we do no allow anything higher than mips1 run on linux - can this > be > true? If so, why? There is no very good reason. I think we should add a MIPS ISA level field in the mips cpuinfo so that we can check what ISA the hardware support at the run-time. H.J. From owner-linux-mips@oss.sgi.com Mon Jun 18 11:23:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IINCE18281 for linux-mips-outgoing; Mon, 18 Jun 2001 11:23:12 -0700 Received: from dea.waldorf-gmbh.de (u-95-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIN9V18271 for ; Mon, 18 Jun 2001 11:23:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5IIMdN26761; Mon, 18 Jun 2001 20:22:39 +0200 Date: Mon, 18 Jun 2001 20:22:39 +0200 From: Ralf Baechle To: Brian Murphy Cc: "linux-mips@oss.sgi.com" Subject: Re: Problems with mips2 compiled libc and linux 2.4.3 Message-ID: <20010618202239.C25814@bacchus.dhis.org> References: <3B2E4458.1637A08A@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2E4458.1637A08A@murphy.dk>; from brian@murphy.dk on Mon, Jun 18, 2001 at 08:11:36PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 21 On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote: > if (__h->e_flags & EF_MIPS_ARCH) > \ > __res = 0; > which is called in fs/binfmt_elf.c causes the loading of init to fail if > it is linked with a glibc compiled with -mips2. It is the second if test > which fails if any of the high 4 bits in the flags are set. According to > the specs these are set for the various mipsx (x != 1) flavors - this seems > to mean that we do no allow anything higher than mips1 run on linux - > can this be > true? If so, why? Older binutils didn't use to set these flags but SGI's ld did so this was a heuristc to reject IRIX binaries which are handled by irixelf.c. The fix is simple, just remove above test. Time to come up with some other plan to detec IRIX binaries ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 18 11:50:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIodl20228 for linux-mips-outgoing; Mon, 18 Jun 2001 11:50:39 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIobV20225 for ; Mon, 18 Jun 2001 11:50:38 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5IIoTq6013216 for ; Mon, 18 Jun 2001 20:50:31 +0200 Message-ID: <3B2E4D74.27E3D7FE@murphy.dk> Date: Mon, 18 Jun 2001 20:50:28 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Re: Problems with mips2 compiled libc and linux 2.4.3 References: <3B2E4458.1637A08A@murphy.dk> <20010618202239.C25814@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 382 Lines: 18 Ralf Baechle wrote: > On Mon, Jun 18, 2001 at 08:11:36PM +0200, Brian Murphy wrote: > > > if (__h->e_flags & EF_MIPS_ARCH) > > \ > > __res = 0; > > Will this be removed from the cvs version then? With all the talk of ll/sc and mips 1 and 2 in the last few months how has anyone tested/run with a mips2 libc if this test existed in their kernel? /Brian From owner-linux-mips@oss.sgi.com Mon Jun 18 12:07:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJ7Or21120 for linux-mips-outgoing; Mon, 18 Jun 2001 12:07:24 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJ7NV21113 for ; Mon, 18 Jun 2001 12:07:23 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5IJ7Gq6013331 for ; Mon, 18 Jun 2001 21:07:17 +0200 Message-ID: <3B2E5163.D130FA01@murphy.dk> Date: Mon, 18 Jun 2001 21:07:15 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Profiling support in glibc? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 251 Lines: 10 What is the status of profiling in glibc? Our (egcs-1.1.2 based) compiler fails with a missing symbol _start (glibc 2.0.6) but even if one fixes this up there are more fundamental problems. Is there a later glibc for which profiling works? /Brian From owner-linux-mips@oss.sgi.com Mon Jun 18 12:41:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJfjj22759 for linux-mips-outgoing; Mon, 18 Jun 2001 12:41:45 -0700 Received: from dea.waldorf-gmbh.de (u-95-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJfgV22755 for ; Mon, 18 Jun 2001 12:41:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5IJfHA27105; Mon, 18 Jun 2001 21:41:17 +0200 Date: Mon, 18 Jun 2001 21:41:17 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Brian Murphy , "linux-mips@oss.sgi.com" Subject: Re: Problems with mips2 compiled libc and linux 2.4.3 Message-ID: <20010618214116.A26781@bacchus.dhis.org> References: <3B2E4458.1637A08A@murphy.dk> <20010618112253.A28744@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010618112253.A28744@lucon.org>; from hjl@lucon.org on Mon, Jun 18, 2001 at 11:22:53AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 638 Lines: 19 On Mon, Jun 18, 2001 at 11:22:53AM -0700, H . J . Lu wrote: > > which fails if any of the high 4 bits in the flags are set. According to > > the > > specs these are set for the various mipsx (x != 1) flavors - this seems > > > to mean > > that we do no allow anything higher than mips1 run on linux - can this > > be > > true? If so, why? > > There is no very good reason. I think we should add a MIPS ISA level > field in the mips cpuinfo so that we can check what ISA the hardware > support at the run-time. Yes and no. It would be nice but the available flags are not an suitable representation of processor capabilities. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 18 13:26:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IKQ3D24922 for linux-mips-outgoing; Mon, 18 Jun 2001 13:26:03 -0700 Received: from dea.waldorf-gmbh.de (u-95-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IKQ1V24910 for ; Mon, 18 Jun 2001 13:26:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5IKPsp27314; Mon, 18 Jun 2001 22:25:54 +0200 Date: Mon, 18 Jun 2001 22:25:54 +0200 From: Ralf Baechle To: Brian Murphy Cc: "linux-mips@oss.sgi.com" Subject: Re: Profiling support in glibc? Message-ID: <20010618222554.B26781@bacchus.dhis.org> References: <3B2E5163.D130FA01@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2E5163.D130FA01@murphy.dk>; from brian@murphy.dk on Mon, Jun 18, 2001 at 09:07:15PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 654 Lines: 18 On Mon, Jun 18, 2001 at 09:07:15PM +0200, Brian Murphy wrote: > What is the status of profiling in glibc? Our (egcs-1.1.2 based) > compiler fails with a missing symbol > _start (glibc 2.0.6) but even if one fixes this up there are more > fundamental problems. > > Is there a later glibc for which profiling works? I've never tried profiling but remember from looking at the source of glibc 2.0.6 that there were rather obvious bugs. Also you shouldn't assume that anybody of the core developers has interest in wasting any work into 2.0.6 since 2.2 is so much better so you may want to upgrade anyway. The other issue is of course gprof ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 18 13:52:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IKqau26129 for linux-mips-outgoing; Mon, 18 Jun 2001 13:52:36 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IKqNV26109; Mon, 18 Jun 2001 13:52:23 -0700 Received: from [171.69.113.18] (earth.ayrnetworks.com [10.1.1.24]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f5IKp8312155; Mon, 18 Jun 2001 13:51:08 -0700 User-Agent: Microsoft-Entourage/9.0.2509 Date: Mon, 18 Jun 2001 14:52:32 -0600 Subject: Re: Profiling support in glibc? From: Greg Satz To: Ralf Baechle , Brian Murphy CC: "linux-mips@oss.sgi.com" Message-ID: In-Reply-To: <20010618222554.B26781@bacchus.dhis.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 219 Lines: 10 Oddly enough I didn't have to make any changes to gprof. I used the version in binutils-2.11.90.0.1. Thanks, Greg on 6/18/01 2:25 PM, Ralf Baechle at ralf@oss.sgi.com wrote: > The other issue is of course gprof ... From owner-linux-mips@oss.sgi.com Mon Jun 18 14:05:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IL5ET26698 for linux-mips-outgoing; Mon, 18 Jun 2001 14:05:14 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IL5DV26694 for ; Mon, 18 Jun 2001 14:05:13 -0700 Received: from [171.69.113.18] (earth.ayrnetworks.com [10.1.1.24]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f5IL3s312384; Mon, 18 Jun 2001 14:03:54 -0700 User-Agent: Microsoft-Entourage/9.0.2509 Date: Mon, 18 Jun 2001 15:05:18 -0600 Subject: Re: Profiling support in glibc? From: Greg Satz To: Brian Murphy , "linux-mips@oss.sgi.com" Message-ID: In-Reply-To: <3B2E5163.D130FA01@murphy.dk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 24 I was able to get profiling working using glibc-2.2.2 and gcc-2.95.3. Both packages needed changes. The compiler had a stack misalignment correction for glibc. Glibc didn't save all the registers nor treat sp/fp correctly. Currently files compiled with -pg need to be linked -static. Specs need to be updated to do this automatically. I will send diffs if there is any interest. Thanks, Greg on 6/18/01 1:07 PM, Brian Murphy at brian@murphy.dk wrote: > > What is the status of profiling in glibc? Our (egcs-1.1.2 based) > compiler fails with a missing symbol > _start (glibc 2.0.6) but even if one fixes this up there are more > fundamental problems. > > Is there a later glibc for which profiling works? > > /Brian > From owner-linux-mips@oss.sgi.com Mon Jun 18 14:11:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ILBSX27231 for linux-mips-outgoing; Mon, 18 Jun 2001 14:11:28 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ILBRV27228 for ; Mon, 18 Jun 2001 14:11:27 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 98698125BA; Mon, 18 Jun 2001 14:11:26 -0700 (PDT) Date: Mon, 18 Jun 2001 14:11:26 -0700 From: "H . J . Lu" To: Greg Satz Cc: Brian Murphy , "linux-mips@oss.sgi.com" Subject: Re: Profiling support in glibc? Message-ID: <20010618141126.B31621@lucon.org> References: <3B2E5163.D130FA01@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from satz@ayrnetworks.com on Mon, Jun 18, 2001 at 03:05:18PM -0600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 693 Lines: 18 On Mon, Jun 18, 2001 at 03:05:18PM -0600, Greg Satz wrote: > I was able to get profiling working using glibc-2.2.2 and gcc-2.95.3. Both > packages needed changes. The compiler had a stack misalignment correction > for glibc. Glibc didn't save all the registers nor treat sp/fp correctly. > Currently files compiled with -pg need to be linked -static. Specs need to > be updated to do this automatically. > The next release of my mips toolchain should be as good as the x86 version in RedHat 7.1. If you can send me patches against binutils, glibc and gcc under http://ftp.kernel.org/pub/linux/devel/binutils/mips/ I will take a look to see if I can include them in my next release. H.J. From owner-linux-mips@oss.sgi.com Mon Jun 18 17:34:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J0YC804705 for linux-mips-outgoing; Mon, 18 Jun 2001 17:34:12 -0700 Received: from dea.waldorf-gmbh.de (u-95-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J0Y9V04696 for ; Mon, 18 Jun 2001 17:34:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5J0Xo128779; Tue, 19 Jun 2001 02:33:50 +0200 Date: Tue, 19 Jun 2001 02:33:50 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: linux-mips@oss.sgi.com Subject: Re: [patch flood] Debugging patches Message-ID: <20010619023350.A28059@bacchus.dhis.org> References: <20010616124102.A31141@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010616124102.A31141@nevyn.them.org>; from dan@debian.org on Sat, Jun 16, 2001 at 12:41:02PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1598 Lines: 40 On Sat, Jun 16, 2001 at 12:41:02PM -0700, Daniel Jacobowitz wrote: > The biggest one was the fact that passing arguments to the inferior in > floating point registers just didn't work. I tracked this down to at least > three separate problems: > - We would set last_task_used_math without clearing the ST0_CU1 bit in > the previous task owning the FPU. When that previous task swapped > in again, it would use the existing FP registers, and lazy_fpu_switch > would never be called. This happened in signal.c and in ptrace.c. First signal.c segment - calling restore_fp_context should result in a proper FPU context switch. > - ptrace didn't look for the FP registers in the right places. This's > been broken since the FPU emulator merge a while back. > - We would create new processes with the ST0_CU1 bit already set if > their parent process had it set. No, copy_thread clears CU1. (Have to breed about this patch a bit more, stuff for the plane ...) > Of course, the lazy switching isn't quite as useful as it could be, since > every program will eventually use the FPU if not build -msoft-float - I > think it's happening in glibc. But we can possibly work around that later. > It still does save a great number of switches, so it's worthwhile - when it > works. Newer libcs shouldn't try to initialize $fcr31 to zero because that's already the default. > Other patches in my directory that I'm submitting along with that one: > - kgdb-crash-resistant.diff > - mips-gdb-with-kgdb.diff > - mips-rtsignal.diff These three look good, applied. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 18 20:35:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3ZQQ09369 for linux-mips-outgoing; Mon, 18 Jun 2001 20:35:26 -0700 Received: from ms.gv.com.tw (ms.gv.com.tw [203.75.221.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3ZCV09330; Mon, 18 Jun 2001 20:35:13 -0700 Received: from jmt ([192.72.4.145]) by ms.gv.com.tw (8.9.3/8.9.3) with SMTP id LAA24043; Tue, 19 Jun 2001 11:40:31 +0800 Message-ID: <001b01c0f871$6467efe0$910448c0@gv.com.tw> From: "´¿¬L©ú" To: "Ralf Baechle" Cc: References: <20010615210433.A4282@paradigm.rfc822.org> <20010616041455.A19841@bacchus.dhis.org> Subject: mipsel-linux-ld problem Date: Tue, 19 Jun 2001 11:39:06 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C0F8B4.7272C5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1304 Lines: 58 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C0F8B4.7272C5E0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit dear all, after we replace our mipsel-linux compiler tools with sgi's we meet a problem which was not occurried before: (any hint to fix? thanks alot in advanced!:) ## genromfs -v -f rom_image -d /usr/mnt/rootfs mipsel-linux-ld -EL -Tld.script.rd -b binary -o /usr/mnt/ramdisk.img rom_image ## mipsel-linux-ld: rom_image: compiled for a little endian system and target is big endian File in wrong format: failed to merge target specific data of file rom_image ## (old compiler said:compiled for a little endian system and target is little endian) ## ld.script.rd : OUTPUT_FORMAT("elf32-littlemips") OUTPUT_ARCH(mips) SECTIONS { .data : { __rd_start = .; *(.data) __rd_end = .; } } ------=_NextPart_000_0018_01C0F8B4.7272C5E0 Content-Type: application/octet-stream; name="ld.script.rd" Content-Disposition: attachment; filename="ld.script.rd" Content-Transfer-Encoding: quoted-printable OUTPUT_FORMAT("elf32-littlemips")=0A= OUTPUT_ARCH(mips)=0A= SECTIONS=0A= {=0A= .data :=0A= {=0A= __rd_start =3D .;=0A= *(.data)=0A= __rd_end =3D .;=0A= }=0A= }=0A= ------=_NextPart_000_0018_01C0F8B4.7272C5E0-- From owner-linux-mips@oss.sgi.com Tue Jun 19 01:37:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J8bUc12989 for linux-mips-outgoing; Tue, 19 Jun 2001 01:37:30 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J8bTV12986 for ; Tue, 19 Jun 2001 01:37:29 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A65281E4ED; Tue, 19 Jun 2001 10:37:23 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: Greg Satz Cc: Brian Murphy , "linux-mips@oss.sgi.com" Subject: Re: Profiling support in glibc? References: From: Andreas Jaeger Date: 19 Jun 2001 10:37:16 +0200 In-Reply-To: (Greg Satz's message of "Mon, 18 Jun 2001 15:05:18 -0600") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 577 Lines: 18 Greg Satz writes: > I was able to get profiling working using glibc-2.2.2 and gcc-2.95.3. Both > packages needed changes. The compiler had a stack misalignment correction > for glibc. Glibc didn't save all the registers nor treat sp/fp correctly. > Currently files compiled with -pg need to be linked -static. Specs need to > be updated to do this automatically. > > I will send diffs if there is any interest. Please send me diffs for glibc, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Tue Jun 19 02:34:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J9YLB13925 for linux-mips-outgoing; Tue, 19 Jun 2001 02:34:21 -0700 Received: from spider.dcg.i-data.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J9YKV13922 for ; Tue, 19 Jun 2001 02:34:21 -0700 Received: from (null) ([127.0.0.1] helo=eicon.com) by spider.dcg.i-data.com with esmtp (Exim 3.22 #1 (Debian)) id 15CHtq-0001HV-00 for ; Tue, 19 Jun 2001 11:34:18 +0200 Message-ID: <3B2F1C9A.6508A33A@eicon.com> Date: Tue, 19 Jun 2001 11:34:18 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "linux-mips@oss.sgi.com" Subject: Re: Profiling support in glibc? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 73 Lines: 8 > I will send diffs if there is any interest. > > Yes please. /Brian From owner-linux-mips@oss.sgi.com Tue Jun 19 04:11:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JBB9Z15869 for linux-mips-outgoing; Tue, 19 Jun 2001 04:11:09 -0700 Received: from intranet.medialincs.com ([210.126.9.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JBB7V15866 for ; Tue, 19 Jun 2001 04:11:08 -0700 Received: (from root@localhost) by intranet.medialincs.com (2.5 Build 2630 (Berkeley 8.8.6)/8.8.4) id UAA02823 for linux-mips@oss.sgi.com; Tue, 19 Jun 2001 20:15:16 +0900 Date: Tue, 19 Jun 2001 20:15:16 +0900 Message-Id: <200106191115.UAA02823@intranet.medialincs.com> From: =?EUC-KR?B?wba+58iv?= To: linux-mips@oss.sgi.com Cc: Subject: system freeze when __sti() called MIME-Version: 1.0 X-Mailer: IntraWorks Mailer 1.0 X-Deliver-Express: no X-Deliver-Reply: no X-Deliver-AutoReply: no Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f5JBB8V15867 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 234 Lines: 11 hello, I porting on gt-64120 with R-4700 .. after linux booting, ERL bit in STATUS register is setted so I can't enable interrupt. I tried to clear ERL bit but then system was down. I use redboot as bootloader. have any idea? From owner-linux-mips@oss.sgi.com Tue Jun 19 07:22:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JEMps19426 for linux-mips-outgoing; Tue, 19 Jun 2001 07:22:51 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JEMmV19423 for ; Tue, 19 Jun 2001 07:22:48 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3563F902; Tue, 19 Jun 2001 16:22:45 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 000A242F6; Tue, 19 Jun 2001 16:23:02 +0200 (CEST) Date: Tue, 19 Jun 2001 16:23:02 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: bitops.h ext2_ ops save/restore flags Message-ID: <20010619162302.C10106@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1559 Lines: 58 Hi, i am just staring at the bitops as it seems they are the culprit for the non working ext2 currently - While staring and comparing i found that the mips ext2_set_bit and co do an save_and_cli/restore_flags which is very obscure. I cant find any similar in other archs - I guess the above is due to a possible "atomic" requirement which ext2 doesnt seem to have (upper layer locking ?) IMHO the patch cleans this: Index: include/asm-mips/bitops.h =================================================================== RCS file: /cvs/linux/include/asm-mips/bitops.h,v retrieving revision 1.16 diff -u -r1.16 bitops.h --- include/asm-mips/bitops.h 2001/06/14 05:33:12 1.16 +++ include/asm-mips/bitops.h 2001/06/19 14:21:58 @@ -797,28 +797,24 @@ #ifdef __MIPSEB__ extern __inline__ int ext2_set_bit(int nr,void * addr) { - int mask, retval, flags; + int mask, retval; unsigned char *ADDR = (unsigned char *) addr; mask = 1 << (nr & 0x07); - save_and_cli(flags); retval = (mask & *ADDR) != 0; *ADDR |= mask; - restore_flags(flags); return retval; } extern __inline__ int ext2_clear_bit(int nr, void * addr) { - int mask, retval, flags; + int mask, retval; unsigned char *ADDR = (unsigned char *) addr; ADDR += nr >> 3; mask = 1 << (nr & 0x07); - save_and_cli(flags); retval = (mask & *ADDR) != 0; *ADDR &= ~mask; - restore_flags(flags); return retval; } Comments ? 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 Jun 19 07:36:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JEa9k19747 for linux-mips-outgoing; Tue, 19 Jun 2001 07:36:09 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JEa9V19742 for ; Tue, 19 Jun 2001 07:36:09 -0700 Received: from RJRWS1 (2093182197.weiderpub.com [209.3.182.197] (may be forged)) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5JEa5V01202 for ; Tue, 19 Jun 2001 07:36:05 -0700 Message-ID: <003d01c0f8cd$2982dc80$031010ac@RJRWS1> From: "Robert Rusek" To: Subject: Kernel-headers for Redhat test-7.0 kernel 2.4.3 Date: Tue, 19 Jun 2001 07:36:01 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 112 Lines: 8 Where do I find kernel-headers for Redhat test-7.0 kernel 2.4.3. Thanks in advance, -- Robert Rusek From owner-linux-mips@oss.sgi.com Tue Jun 19 07:36:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JEaad19818 for linux-mips-outgoing; Tue, 19 Jun 2001 07:36:36 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JEaZV19814 for ; Tue, 19 Jun 2001 07:36:35 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id E4665909; Tue, 19 Jun 2001 16:36:33 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 9670A42F6; Tue, 19 Jun 2001 16:36:51 +0200 (CEST) Date: Tue, 19 Jun 2001 16:36:51 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Re: bitops.h ext2_ ops save/restore flags Message-ID: <20010619163651.D10106@paradigm.rfc822.org> References: <20010619162302.C10106@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010619162302.C10106@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Jun 19, 2001 at 04:23:02PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1724 Lines: 43 On Tue, Jun 19, 2001 at 04:23:02PM +0200, Florian Lohoff wrote: > Hi, > i am just staring at the bitops as it seems they are the culprit for > the non working ext2 currently - While staring and comparing i found > that the mips ext2_set_bit and co do an save_and_cli/restore_flags > which is very obscure. I cant find any similar in other archs - I guess > the above is due to a possible "atomic" requirement which ext2 doesnt > seem to have (upper layer locking ?) Another one - This only fixes the big endian case - the little endian case still has the penalty of cli/restore on every bit set as the ext2 macros get defined to the "atomic" ops defined there I propose this patch Index: include/asm-mips/bitops.h =================================================================== RCS file: /cvs/linux/include/asm-mips/bitops.h,v retrieving revision 1.16 diff -u -r1.16 bitops.h --- include/asm-mips/bitops.h 2001/06/14 05:33:12 1.16 +++ include/asm-mips/bitops.h 2001/06/19 14:32:51 @@ -887,8 +883,8 @@ #else /* !(__MIPSEB__) */ /* Native ext2 byte ordering, just collapse using defines. */ -#define ext2_set_bit(nr, addr) test_and_set_bit((nr), (addr)) -#define ext2_clear_bit(nr, addr) test_and_clear_bit((nr), (addr)) +#define ext2_set_bit(nr, addr) __test_and_set_bit((nr), (addr)) +#define ext2_clear_bit(nr, addr) __test_and_clear_bit((nr), (addr)) #define ext2_test_bit(nr, addr) test_bit((nr), (addr)) #define ext2_find_first_zero_bit(addr, size) find_first_zero_bit((addr), (size)) #define ext2_find_next_zero_bit(addr, size, offset) \ Comments ? 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 Jun 19 07:43:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JEhL220008 for linux-mips-outgoing; Tue, 19 Jun 2001 07:43:21 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JEhKV20005 for ; Tue, 19 Jun 2001 07:43:20 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id A643690A; Tue, 19 Jun 2001 16:43:18 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D8CCA42F6; Tue, 19 Jun 2001 16:43:36 +0200 (CEST) Date: Tue, 19 Jun 2001 16:43:36 +0200 From: Florian Lohoff To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Kernel-headers for Redhat test-7.0 kernel 2.4.3 Message-ID: <20010619164336.E10106@paradigm.rfc822.org> References: <003d01c0f8cd$2982dc80$031010ac@RJRWS1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <003d01c0f8cd$2982dc80$031010ac@RJRWS1>; from robru@teknuts.com on Tue, Jun 19, 2001 at 07:36:01AM -0700 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 317 Lines: 10 On Tue, Jun 19, 2001 at 07:36:01AM -0700, Robert Rusek wrote: > Where do I find kernel-headers for Redhat test-7.0 kernel 2.4.3. Get the kernel source from cvs :) 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 Jun 19 09:11:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JGBf022226 for linux-mips-outgoing; Tue, 19 Jun 2001 09:11:41 -0700 Received: from miya ([194.90.113.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JGBcV22223 for ; Tue, 19 Jun 2001 09:11:39 -0700 Received: from miya (IDENT:shay@localhost.localdomain [127.0.0.1]) by miya (8.9.3/8.9.3) with SMTP id TAA12410 for ; Tue, 19 Jun 2001 19:14:22 +0300 Content-Type: text/plain; charset="iso-8859-1" From: Shay Deloya To: linux-mips@oss.sgi.com Subject: Creating a mips tool chain for mips3 Date: Tue, 19 Jun 2001 19:14:22 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01061919142200.12304@miya> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 488 Lines: 14 Hi, At the moment I use tool chain of egcs-2.90.29 glibc-2.0.6. I see that the default crtbegin (egcs) is compiled for mips1 and when I use mips-linux-gcc -mips3 hello.c , I get the following error: ISA mismatch (-mips3) with previous modules (-mips1) Bad value: failed to merge target specific data of file /tmp/ccVx4c701.o When I check I see that crtbegin & crtend are of mips1 type. How can I configure the gcc and glibc to be compiled as mips3 and not mips1 by default ? Shay From owner-linux-mips@oss.sgi.com Tue Jun 19 09:28:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JGSUQ22492 for linux-mips-outgoing; Tue, 19 Jun 2001 09:28:30 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JGSTV22489 for ; Tue, 19 Jun 2001 09:28:29 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 196D53E90; Tue, 19 Jun 2001 09:24:01 -0700 (PDT) Date: Tue, 19 Jun 2001 09:24:01 -0700 From: Keith M Wesolowski To: Shay Deloya Cc: linux-mips@oss.sgi.com Subject: Re: Creating a mips tool chain for mips3 Message-ID: <20010619092400.B6828@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01061919142200.12304@miya> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 716 Lines: 17 On Tue, Jun 19, 2001 at 07:14:22PM +0300, Shay Deloya wrote: > How can I configure the gcc and glibc to be compiled as mips3 and not mips1 > by default ? Getting libgcc built as non-mips1 is something I haven't figured out yet. At least, not without gross hacks. glibc is easy - put -mips2 in CFLAGS when you call configure. In any case you must not use mips3 userland on 32-bit kernels, on account of 64-bit istructions being used. You must use mips2. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Tue Jun 19 09:29:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JGTID22560 for linux-mips-outgoing; Tue, 19 Jun 2001 09:29:18 -0700 Received: from spider.dcg.i-data.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JGTHV22557 for ; Tue, 19 Jun 2001 09:29:17 -0700 Received: from (null) ([127.0.0.1] helo=eicon.com) by spider.dcg.i-data.com with esmtp (Exim 3.22 #1 (Debian)) id 15CONO-0001gS-00 for ; Tue, 19 Jun 2001 18:29:15 +0200 Message-ID: <3B2F7DDA.68356680@eicon.com> Date: Tue, 19 Jun 2001 18:29:14 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: core dump support in gdb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 520 Lines: 14 The gdb versions I have used on mipsel-linux do not seem to be able to read a core file generated on the same platform failing with warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x20008413 Anyone know what the problem is? Increasing the value of heuristic-fence-post does not help. The address mentioned seems not to exist in the address space of the program. Running the program from within gdb seems however to give meaningful results when the program crashes. /Brian From owner-linux-mips@oss.sgi.com Tue Jun 19 17:08:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K083Q19879 for linux-mips-outgoing; Tue, 19 Jun 2001 17:08:03 -0700 Received: from mail.palmchip.com ([63.203.52.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K082V19876 for ; Tue, 19 Jun 2001 17:08:02 -0700 Received: from palmchip.com (sabretooth.palmchip.com [10.1.10.110]) by mail.palmchip.com (8.11.0/8.11.0) with ESMTP id f5K28a207602 for ; Tue, 19 Jun 2001 19:08:36 -0700 Message-ID: <3B2FEAA1.34DD1FFB@palmchip.com> Date: Tue, 19 Jun 2001 17:13:21 -0700 From: Ian Thompson Organization: Palmchip Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Can't open root device Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1058 Lines: 25 Hi, I'm having some issues trying to open a ROM fs via initrd. It seems like kind of a paradox: mount_root() calls blkdev_get(), which calls rd_open(). In blkdev_get(), the comments mention that the block device ->open() method is not supposed to access anthing in the 'inode' argument except ->i_rdev. However, rd_open() checks inode->i_bdev when ->i_rdev isn't INITRD_MINOR (->i_rdev is set to bd_dev in blkdev_get). Currently my minor number is 0 (major is 1). Am I using the correct major/minor numbers? Should I use INITRD_MINOR instead of 0? If I am ok with 0, it appears that there is an inconsistency in the code... Also, is there another driver I should try using instead of the ramdisk driver? uClinux has a blkmem driver, but I haven't seen that here... Thanks for your time, -ian -- ---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/ From owner-linux-mips@oss.sgi.com Wed Jun 20 04:04:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KB4n101189 for linux-mips-outgoing; Wed, 20 Jun 2001 04:04:49 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KB4lV01184 for ; Wed, 20 Jun 2001 04:04:47 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05408 for ; Sun, 17 Jun 2001 13:53:10 -0700 (PDT) mail_from (robru@ruseks.com) Received: from sohorob (sc-66-27-45-152.socal.rr.com [66.27.45.152]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5HKm7N08949 for ; Sun, 17 Jun 2001 13:48:07 -0700 From: "Robert Rusek" To: Subject: Kernel-headers for Redhat test-7.0 kernel 2.4.3 Date: Sun, 17 Jun 2001 13:48:09 -0700 Message-ID: <000701c0f76e$d1adb7a0$6400a8c0@sohorob> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C0F734.254EDFA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1347 Lines: 45 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C0F734.254EDFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Where do I find kernel-headers for Redhat test-7.0 kernel 2.4.3. Thanks in advanc, -- Robert Rusek ------=_NextPart_000_0008_01C0F734.254EDFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Where do I find kernel-headers for Redhat test-7.0 kernel=20 2.4.3.
 
Thanks in advanc,
--
Robert = Rusek
 
------=_NextPart_000_0008_01C0F734.254EDFA0-- From owner-linux-mips@oss.sgi.com Wed Jun 20 04:05:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KB53J01258 for linux-mips-outgoing; Wed, 20 Jun 2001 04:05:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KB52V01248 for ; Wed, 20 Jun 2001 04:05:02 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA06604 for ; Sun, 17 Jun 2001 14:47:55 -0700 (PDT) mail_from (robru@ruseks.com) Received: from sohorob (sc-66-27-45-152.socal.rr.com [66.27.45.152]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5HLgqN09105 for ; Sun, 17 Jun 2001 14:42:52 -0700 From: "Robert Rusek" To: Subject: Kernel-headers for Redhat test-7.0 kernel 2.4.3 Date: Sun, 17 Jun 2001 14:42:54 -0700 Message-ID: <002101c0f776$7757d3a0$6400a8c0@sohorob> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C0F73B.CAF8FBA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1412 Lines: 49 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0F73B.CAF8FBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Where do I find kernel-headers for Redhat test-7.0 kernel 2.4.3. Thanks in advanc, -- Robert Rusek ------=_NextPart_000_0022_01C0F73B.CAF8FBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message


 
Where do I find kernel-headers for Redhat test-7.0 kernel=20 2.4.3.
 
Thanks in advanc,
--
Robert = Rusek
 
------=_NextPart_000_0022_01C0F73B.CAF8FBA0-- From owner-linux-mips@oss.sgi.com Wed Jun 20 08:01:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KF1xA03791 for linux-mips-outgoing; Wed, 20 Jun 2001 08:01:59 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KF1vV03788 for ; Wed, 20 Jun 2001 08:01:57 -0700 Received: from eicon.com (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5KF1lq6002287 for ; Wed, 20 Jun 2001 17:01:50 +0200 Message-ID: <3B30BADA.D7D7DC22@eicon.com> Date: Wed, 20 Jun 2001 17:01:46 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: Kernel-headers for Redhat test-7.0 kernel 2.4.3 References: <003d01c0f8cd$2982dc80$031010ac@RJRWS1> <20010619164336.E10106@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 265 Lines: 11 Florian Lohoff wrote: > Get the kernel source from cvs :) > It's actually very hard to find where the cvs is. It in only in Ralf Baechle's FAQ. There is no link to it from oss.sgi.com for example. I dont think there is a link from oss to the FAQ either. /Brian From owner-linux-mips@oss.sgi.com Wed Jun 20 08:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KF42C04099 for linux-mips-outgoing; Wed, 20 Jun 2001 08:04:02 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KF42V04096 for ; Wed, 20 Jun 2001 08:04:02 -0700 Received: from sohorob (sc-66-27-45-152.socal.rr.com [66.27.45.152]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5KF3wv01339 for ; Wed, 20 Jun 2001 08:03:58 -0700 From: "Robert Rusek" To: Subject: Newbie: RedHat Test-7.0 Compiler Question Date: Wed, 20 Jun 2001 08:04:00 -0700 Message-ID: <000901c0f99a$3cfa2480$6400a8c0@sohorob> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 468 Lines: 13 Over the past month I have been struggling trying to make my compilers work under RedHat Test-7.0. I attempted to do the rpmi -i with the rpm's in the build with not much success. Seems like the core things are missing. If possible I need help with the steps that are needed to make the compilers work. I want to be able to compile things like the kernel, bind, apache, and sendmail. Any help would be greatly appreciated. Thank you in advance. -- Robert Rusek From owner-linux-mips@oss.sgi.com Wed Jun 20 10:59:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KHx9a10965 for linux-mips-outgoing; Wed, 20 Jun 2001 10:59:09 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KHx7V10962 for ; Wed, 20 Jun 2001 10:59:08 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id VAA15981 for ; Wed, 20 Jun 2001 21:59:12 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA01515 for linux-mips@oss.sgi.com; Wed, 20 Jun 2001 21:50:18 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id VAA01777 for ; Wed, 20 Jun 2001 21:56:57 +0400 (MSD) Message-ID: <3B30E405.2090809@niisi.msk.ru> Date: Wed, 20 Jun 2001 21:57:25 +0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i586; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: How can i get current CVS of the kernel? Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11 Lines: 3 Hi. subj. From owner-linux-mips@oss.sgi.com Wed Jun 20 11:10:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KIAv111256 for linux-mips-outgoing; Wed, 20 Jun 2001 11:10:57 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KIAuV11253 for ; Wed, 20 Jun 2001 11:10:56 -0700 Received: (qmail 21329 invoked by uid 502); 20 Jun 2001 18:10:55 -0000 Content-Type: text/plain; charset="koi8-u" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Alexandr Andreev Subject: Re: How can i get current CVS of the kernel? Date: Wed, 20 Jun 2001 11:10:52 -0700 X-Mailer: KMail [version 1.2] References: <3B30E405.2090809@niisi.msk.ru> In-Reply-To: <3B30E405.2090809@niisi.msk.ru> Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-Id: <01062011105209.13634@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 602 Lines: 19 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cvs -d :pserver:cvs@oss.sgi.com:/cvs -z9 co linux No uchti, chto yesli ty nachnesh zadavat' voprosy ne prochitav Ralf's HOWTO, ty trup. http://http://oss.sgi.com/mips/mips-howto.html Povtoryauy http://oss.sgi.com/mips/mips-howto.html http://oss.sgi.com/mips/mips-howto.html http://oss.sgi.com/mips/mips-howto.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsw5y8ACgkQtKh84cA8u2ny9QCeKQLH7XviMuKOQ0FavmeORuck 8MMAoLXjrQ+L1nvCxVEOqCnyUsUY2JI4 =fTnD -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Thu Jun 21 10:29:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LHTGl14808 for linux-mips-outgoing; Thu, 21 Jun 2001 10:29:16 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LHT5V14804 for ; Thu, 21 Jun 2001 10:29:05 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0BB62125BA; Thu, 21 Jun 2001 10:28:59 -0700 (PDT) Date: Thu, 21 Jun 2001 10:28:59 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , gcc@gcc.gnu.org, GNU C Library Subject: The Linux binutils 2.11.90.0.19 is released. Message-ID: <20010621102859.A1351@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 12215 Lines: 447 It is required to upgrade to 2.11.90.0.19 if you have installed 2.11.90.0.15 or plan to use gcc 3.0. H.J. ---- This is the beta release of binutils 2.11.90.0.19 for Linux, which is based on binutils 2001 0620 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.19 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.19.tar.gz. Source code. 2. binutils-2.11.90.0.15-2.11.90.0.19.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.19-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.19.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 06/21/2001 From owner-linux-mips@oss.sgi.com Thu Jun 21 10:59:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LHxNY15463 for linux-mips-outgoing; Thu, 21 Jun 2001 10:59:23 -0700 Received: from op.teknuts.com (139.muba.lsan.lsancass.dsl.att.net [12.98.69.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LHxMV15460 for ; Thu, 21 Jun 2001 10:59:22 -0700 Received: from RJRWS1 (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by op.teknuts.com (8.11.3/8.10.1) with ESMTP id f5LHxI801885 for ; Thu, 21 Jun 2001 10:59:18 -0700 Message-ID: <001501c0fa7b$e0ea5970$031010ac@RJRWS1> From: "Robert Rusek" To: Subject: Newbie: RedHat Test-7.0 Compiler Question Date: Thu, 21 Jun 2001 10:59:12 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 470 Lines: 14 Over the past month I have been struggling trying to make my compilers work under RedHat Test-7.0. I attempted to do the rpmi -i with the rpm's in the build with not much success. Seems like the core things are missing. If possible I need help with the steps that are needed to make the compilers work. I want to be able to compile things like the kernel, bind, apache, and sendmail. Any help would be greatly appreciated. Thank you in advance. -- Robert Rusek From owner-linux-mips@oss.sgi.com Thu Jun 21 11:39:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LIdv616448 for linux-mips-outgoing; Thu, 21 Jun 2001 11:39:57 -0700 Received: from cassidy.nuernberg.linuxtag.net (cassidy.nuernberg.linuxtag.net [212.204.83.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LIdtV16445 for ; Thu, 21 Jun 2001 11:39:56 -0700 Received: from hydra.linuxtag.uni-kl.de (hydra.hq.linuxtag.net [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id BB151EC2AB for ; Thu, 21 Jun 2001 20:39:25 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id 30CCD4FDB; Thu, 21 Jun 2001 20:36:18 +0200 (CEST) Date: Thu, 21 Jun 2001 20:36:18 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Developer's meeting at LinuxTag? Message-ID: <20010621203618.B4805@linuxtag.org> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 907 Lines: 22 Hallo everybody, from July, 5th to July, 8th this year's LinuxTag will take place at the Stuttgart Exhibition Centre in Germany. Many Linux developers will be there and I would find it nice to get to know some of the Linux/MIPS people in person, so I wanted to ask if somebody of you is planning to visit LinuxTag this year. The Linux-Ports-booth (among other things showing Linux/MIPS) would be a nice meeting point in case somebody is interested. There is no entrance fee for LinuxTag, if you need further information, please take a look at http://www.linuxtag.org/ (german version) or http://www.linuxtag.org/2001/english/ (english version) or feel free to ask me by email. 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 Thu Jun 21 11:54:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LIsv316745 for linux-mips-outgoing; Thu, 21 Jun 2001 11:54:57 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LIsuV16742 for ; Thu, 21 Jun 2001 11:54:57 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 2DDB1125BA; Thu, 21 Jun 2001 11:54:55 -0700 (PDT) Date: Thu, 21 Jun 2001 11:54:55 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: The new home of the new mips toolchain and RedHat 7.1 Message-ID: <20010621115455.A2678@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 706 Lines: 20 Thanks to Ralf and SGI, I am putting the new mips toolchain and my mini port of RedHat 7.1 for mips/mipsel at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ I will upload binutils, gcc andd glibc rpms first, followed by a subset of RedHat 7.1. The whole process may take a few weeks since my network connection is not very fast. Once the upload is done, you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. BTW, the new mips toolchain has gcc-2.96-88.1, binutils-2.11.90.0.19-1 and glibc-2.2.3-11.3. They are as good as the x86 version in RedHat 7.1. The only thing missing is gdb. I am looking forward to Daniel's mips port. Thanks. H.J. From owner-linux-mips@oss.sgi.com Thu Jun 21 14:10:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LLA2B21265 for linux-mips-outgoing; Thu, 21 Jun 2001 14:10:02 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LLA2V21262 for ; Thu, 21 Jun 2001 14:10:02 -0700 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 f5LL9u031108; Thu, 21 Jun 2001 14:09:56 -0700 Message-ID: <3B326224.DE937DAA@mvista.com> Date: Thu, 21 Jun 2001 14:07:48 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: A confusing oops dump ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1447 Lines: 35 I got the following oops dump during a stress load, which I cannot make any sense out of it. The most confusing part is that the status register indicates program was running in kernel (KSU bits) while the $epc points to a userland address. How could this be ever possible at hardware level? The only possible explanation is perhaps those saved registers were corrupted between when the exception happens and core dumps, but so unlikely .... *sigh* Any insight? Jun Unable to handle kernel paging request at virtual address 100096e0, epc == 10000 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 100015d4 00000001 81e43160 $4 : 00000001 00000001 00000000 8328a680 $8 : 0000308e 00000000 800ba0dc 00000003 $12: 00000010 2ac45e7c 00000000 82f6e039 $16: 0041393c 10003510 000005f0 00000000 $20: 0000308e 00000000 fffffffc 00409350 $24: 00000000 2ab92f10 $28: 83b18000 7fff77f0 10003510 100096e0 epc : 100096e0 Status: 30017c03 Cause : 00008008 Process (pid: 0, stackpage=7fff6000) Stack: 100096e0 7fff7800 004036f0 004036d4 10003518 7fff6fec 00000000 6f727020 100096e0 7fff6930 7fff7b04 00004dd1 7fff7920 0fb64798 00000000 00000000 00000000 00000000 0fb94020 00000000 00000000 00000000 0fb600cc 00000000 00000000 00000000 00000000 00000000 00000000 0fb60104 0fb600d4 0fb600dc 0fb600e4 00000000 00000000 00000000 0fb600ec 0fb600f4 00000000 00000000 0fb600cc ... Call Trace: Code: (Bad address in epc) From owner-linux-mips@oss.sgi.com Thu Jun 21 15:51:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LMpc923199 for linux-mips-outgoing; Thu, 21 Jun 2001 15:51:38 -0700 Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LMpbV23195 for ; Thu, 21 Jun 2001 15:51:37 -0700 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Thu, 21 Jun 2001 14:24:09 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from postal.sibyte.com (IDENT:postfix@[10.21.128.60]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA14085 for ; Thu, 21 Jun 2001 14:24:14 -0700 (PDT) Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id AE5131595F for ; Thu, 21 Jun 2001 14:24:14 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id DC0FC686D; Thu, 21 Jun 2001 13:29:49 -0700 (PDT) From: "Justin Carlson" Reply-to: carlson@sibyte.com Organization: Sibyte To: linux-mips@oss.sgi.com Subject: Re: A confusing oops dump ... Date: Thu, 21 Jun 2001 13:29:31 -0700 X-Mailer: KMail [version 1.0.29] MIME-Version: 1.0 Message-ID: <01062113294906.00778@plugh.sibyte.com> X-WSS-ID: 172CBA7328058-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1124 Lines: 24 On Thu, 21 Jun 2001, you wrote: > I got the following oops dump during a stress load, which I cannot make any > sense out of it. The most confusing part is that the status register > indicates program was running in kernel (KSU bits) while the $epc points to a > userland address. How could this be ever possible at hardware level? It's very possible at the hardware level...kernel mode enables access to several segments; it doesn't disable mapped accesses. I don't think it should ever happen in linux, but there's nothing in the hardware that prevents this. > > The only possible explanation is perhaps those saved registers were corrupted > between when the exception happens and core dumps, but so unlikely .... *sigh* > > Any insight? You've got a TLBL exception, and va doesn't match epc, so presumably the processor thinks it was a load and not an ifetch that triggered this. It also follows that the processor thinks it found a valid instruction at 0x10000. If this is reproducable and the chip allows it, try dumping out the icache when you hit this, see if 0x10000 really appears in there... -Justin From owner-linux-mips@oss.sgi.com Fri Jun 22 04:24:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MBOMA01419 for linux-mips-outgoing; Fri, 22 Jun 2001 04:24:22 -0700 Received: from europa.isid.es (europa.isid.es [194.224.94.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MBOKV01416 for ; Fri, 22 Jun 2001 04:24:21 -0700 Received: from isid.es ([194.224.94.103]) by europa.isid.es (Post.Office MTA v3.1 release PO203a ID# 0-38049U2500L250S0) with ESMTP id AAA11737; Fri, 22 Jun 2001 13:12:26 +0200 Message-ID: <3B332CED.15DE02F7@isid.es> Date: Fri, 22 Jun 2001 13:33:01 +0200 From: Javier =?iso-8859-1?Q?Pay=E1n=20S=E1nchez?= X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: albacete@isid.es Subject: IRIX to LINUX Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 391 Lines: 12 Hi, everybody. I'm Javier Payan, from ISID, a Spanish company. I have a Silicon Graphics Challenge S Series computer (mod. WebFORCE), with a MIPS R5000 processor, and IRIX o.s. installed. I want to install Linux into it. So I wish to know if it is possible (it's possible to install Linux into a SGI Challenge WebFORCE), and how I can do it. Thank you for all. Javier Payán. From owner-linux-mips@oss.sgi.com Fri Jun 22 04:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MBwBe01863 for linux-mips-outgoing; Fri, 22 Jun 2001 04:58:11 -0700 Received: from storm.physik.tu-cottbus.de (storm.physik.TU-Cottbus.De [141.43.75.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MBwAV01860 for ; Fri, 22 Jun 2001 04:58:10 -0700 Received: by storm.physik.tu-cottbus.de (Postfix, from userid 7215) id 2F7436004D; Fri, 22 Jun 2001 13:58:05 +0200 (MET DST) Date: Fri, 22 Jun 2001 13:58:04 +0200 To: linux-mips@oss.sgi.com Subject: Re: Developer's meeting at LinuxTag? Message-ID: <20010622135804.B9418@physik.tu-cottbus.de> Mail-Followup-To: heinold@physik.tu-cottbus.de, linux-mips@oss.sgi.com References: <20010621203618.B4805@linuxtag.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010621203618.B4805@linuxtag.org> User-Agent: Mutt/1.3.18i From: heinold@physik.tu-cottbus.de (H.Heinold) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1083 Lines: 31 On Thu, Jun 21, 2001 at 08:36:18PM +0200, Karsten Merker wrote: > Hallo everybody, > > from July, 5th to July, 8th this year's LinuxTag will take place at the > Stuttgart Exhibition Centre in Germany. Many Linux developers will be > there and I would find it nice to get to know some of the Linux/MIPS people > in person, so I wanted to ask if somebody of you is planning to visit > LinuxTag this year. The Linux-Ports-booth (among other things showing > Linux/MIPS) would be a nice meeting point in case somebody is interested. > > There is no entrance fee for LinuxTag, if you need further information, > please take a look at http://www.linuxtag.org/ (german version) or > http://www.linuxtag.org/2001/english/ (english version) or feel free to > ask me by email. > > 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. > I will be there, even on the debian booth. -- Henning Heinold From owner-linux-mips@oss.sgi.com Fri Jun 22 13:57:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MKvkl21111 for linux-mips-outgoing; Fri, 22 Jun 2001 13:57:46 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MKvkV21108 for ; Fri, 22 Jun 2001 13:57:46 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5MKvce9018899; Fri, 22 Jun 2001 13:57:38 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5MKvcT9018895; Fri, 22 Jun 2001 13:57:38 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 22 Jun 2001 13:57:38 -0700 (PDT) From: James Simmons To: Linux Kernel Mailing List cc: linux-mips@oss.sgi.com Subject: [ANNOUNCE] Secondary mips tree. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 645 Lines: 19 Hi all, We have started a secondary tree for linux mips. This tree will be to SGI mips tree as Alan Cox's tree is to linus branch. We will test and play with "experimental patches" and then in time hand them off to the main branch Ralf Baechle maintains. Also one of the main reasons for this branch was to unite several of the mips trees into one place. Anyones patches (if good) are welcomed. The site is http://www.sf.net/projects/linux-mips We also have a mailing list which instructions are on the SF page on how to join. Thank you. P.S If anyone has the mips cobalt working with 2.4.X I really like those patches. Thank you. From owner-linux-mips@oss.sgi.com Fri Jun 22 14:46:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MLkt326256 for linux-mips-outgoing; Fri, 22 Jun 2001 14:46:55 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MLkrV26252 for ; Fri, 22 Jun 2001 14:46:54 -0700 content-class: urn:content-classes:message Subject: GCC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Jun 2001 14:46:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B05CB03@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GCC Thread-Index: AcD7ZMKiRfiW4fN7TRW4GV226wbcLA== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5MLksV26253 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2856 Lines: 70 Hi, All: I want to get your help on GCC for Linux on Mips. Here is some related information: Host: i686 Red Hat linux 7.0 Binutil- 2.8.1-1. gcc - 1.1.2-2. linux kernel 2.2.12. Malta Board. CPU R3000. Big Endian. When I compiled the kernel with -mcpu=r3000 -mips1, it gave me the following error. mips-linux-gcc -D__KERNEL__ -DCONFIG_CPU_AURORA -I/home/wenbo/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mmemcpy -fno-strict-aliasing -mno-split-addresses -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c -o init/main.o init/main.c /home/wenbo/linux/include/asm/atomic.h: In function `atomic_add': In file included from /home/wenbo/linux/include/linux/fs.h:22, from /home/wenbo/linux/include/linux/capability.h:13, from /home/wenbo/linux/include/linux/binfmts.h:5, from /home/wenbo/linux/include/linux/sched.h:8, from /home/wenbo/linux/include/linux/mm.h:4, from /home/wenbo/linux/include/linux/slab.h:14, from /home/wenbo/linux/include/linux/malloc.h:4, from /home/wenbo/linux/include/linux/proc_fs.h:5, from init/main.c:23: /home/wenbo/linux/include/asm/atomic.h:47: invalid operands to binary + /home/wenbo/linux/include/asm/atomic.h: In function `atomic_sub': /home/wenbo/linux/include/asm/atomic.h:57: invalid operands to binary - /home/wenbo/linux/include/asm/atomic.h: In function `atomic_add_return': /home/wenbo/linux/include/asm/atomic.h:67: incompatible types in assignment /home/wenbo/linux/include/asm/atomic.h:69: incompatible types in assignment /home/wenbo/linux/include/asm/atomic.h: In function `atomic_sub_return': /home/wenbo/linux/include/asm/atomic.h:81: incompatible types in assignment /home/wenbo/linux/include/asm/atomic.h:83: incompatible types in assignment /home/wenbo/linux/include/asm/timex.h: In function `get_cycles': In file included from /home/wenbo/linux/include/linux/timex.h:138, from /home/wenbo/linux/include/linux/sched.h:14, from /home/wenbo/linux/include/linux/mm.h:4, from /home/wenbo/linux/include/linux/slab.h:14, from /home/wenbo/linux/include/linux/malloc.h:4, from /home/wenbo/linux/include/linux/proc_fs.h:5, from init/main.c:23: /home/wenbo/linux/include/asm/timex.h:41: warning: implicit declaration of function `read_32bit_cp0_register' /home/wenbo/linux/include/asm/timex.h:41: `CP0_COUNT' undeclared (first use in this function) /home/wenbo/linux/include/asm/timex.h:41: (Each undeclared identifier is reported only once /home/wenbo/linux/include/asm/timex.h:41: for each function it appears in.) make: *** [init/main.o] Error 1 Nicu met the same problem but I do not know how the problem was solved. Thank you. Steven Liu From owner-linux-mips@oss.sgi.com Sat Jun 23 06:06:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ND61H10826 for linux-mips-outgoing; Sat, 23 Jun 2001 06:06:01 -0700 Received: from web1.lanscape.net (web1.lanscape.net [64.240.156.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ND60V10821 for ; Sat, 23 Jun 2001 06:06:00 -0700 Received: from fisch.cyrius.com (localhost [127.0.0.1]) by web1.lanscape.net (8.9.3/8.9.3) with ESMTP id IAA21415; Sat, 23 Jun 2001 08:05:54 -0500 Received: by fisch.cyrius.com (Postfix, from userid 1000) id E55F122CF5; Fri, 22 Jun 2001 21:58:33 +0200 (CEST) Date: Fri, 22 Jun 2001 21:58:33 +0200 From: Martin Michlmayr To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: A confusing oops dump ... Message-ID: <20010622215833.A7210@fisch.cyrius.com> References: <3B326224.DE937DAA@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B326224.DE937DAA@mvista.com>; from jsun@mvista.com on Thu, Jun 21, 2001 at 02:07:48PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1319 Lines: 25 * Jun Sun [20010621 14:07]: > Oops in fault.c:do_page_fault, line 172: Is this related to the oops I get when booting my DECstation or are these separate issues? Unable to handle kernel paging request at virtual address 00000004, epc == 80053f48, ra == 80053f00 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 10002000 80720410 00000000 80720410 00000000 00001090 00000001 $8 : 00000000 00000000 00000000 00000000 801ed867 fffffff7 ffffffff 81097470 $16: 81092000 00010000 00000000 80048020 fffffff4 00010f00 80721090 80720fe0 $24: 00000001 0000000a 80720000 80720f58 00000000 80053f00 epc : 80053f48 Status: 10002004 Cause : 30000008 Process (pid: 0, stackpage=80720000) Stack: 8005b7c4 00000001 000000c0 8005b488 801e703c 800f574c 00000000 00000000 00000000 80720f7c 80720f7c 00000023 00000000 00000000 00000000 80720f7c 80720f7c 00000023 00010f00 00010000 00000000 80048020 30464354 a0002f88 00000200 001220d2 44208a0a 8004d5d0 00000000 ffffffff ffffffff 00000000 8004deac bc180001 00010f00 00000000 80721090 bc180001 801ed867 fffffff7 00000000 ... Call Trace: [<8005b7c4>] [<8005b488>] [<800f574c>] [<80048020>] [<8004d5d0>] [<8004deac>] Code: 24630010 8e0501d4 8e030218 <8ca20004> 00000000 0043102b 1040030f 2414fff5 40046000 From owner-linux-mips@oss.sgi.com Sat Jun 23 06:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NDdnP16436 for linux-mips-outgoing; Sat, 23 Jun 2001 06:39:49 -0700 Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NDdlV16427 for ; Sat, 23 Jun 2001 06:39:47 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA25294; Fri, 22 Jun 2001 20:21:30 +0200 (MET DST) Date: Fri, 22 Jun 2001 20:21:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" , Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: Bug in memmove In-Reply-To: <3B1E2BF7.5C0CADB8@niisi.msk.ru> 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 Content-Length: 2464 Lines: 76 On Wed, 6 Jun 2001, Gleb O. Raiko wrote: > It seems there is a bug in our memmove routine. The condition is rare > though, for example, memmove copies incorrectly, if src=5, dst=4, len=9. [...] > Two questions here. First, do we have a pattern that satisfies the > condition, i.e. is the bug showstopper? My guess, it's not. Second, does > somebody have ideas how to fix the bug? Well, I have, but want to hear > somebody else. Here is a quick fix I developed after reading your report. It fixes the case you described. Now memcpy() is invoked only if there is no overlap at all -- the approach is taken from the Alpha port. The copy loop begs for optimization (the original memmove() bits do as well), but at least it works correctly. The patch applies cleanly to 2.4.5 as of today. Ralf, I think it should get applied unless someone cooks up a better solution, i.e. optimizes it. I'll optimize it myself, eventually, if no one else does, but don't hold your breath. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test12-20010110-memmove-1 diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/lib/memcpy.S linux-mips-2.4.0-test12-20010110/arch/mips/lib/memcpy.S --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/lib/memcpy.S Wed Dec 6 05:27:02 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/lib/memcpy.S Sun Jun 10 17:50:55 2001 @@ -402,16 +402,20 @@ u_end_bytes: .align 5 LEAF(memmove) - sltu t0, a0, a1 # dst < src -> memcpy - bnez t0, memcpy - addu v0, a0, a2 - sltu t0, v0, a1 # dst + len < src -> non- - bnez t0, __memcpy # overlapping, can use memcpy + addu t0, a0, a2 + sltu t0, a1, t0 # dst + len <= src -> memcpy + addu t1, a1, a2 + sltu t1, a0, t1 # dst >= src + len -> memcpy + and t0, t1 + beqz t0, __memcpy move v0, a0 /* return value */ beqz a2, r_out END(memmove) LEAF(__rmemcpy) /* a0=dst a1=src a2=len */ + sltu t0, a1, a0 + beqz t0, r_end_bytes_up # src >= dst + nop addu a0, a2 # dst = dst + len addu a1, a2 # src = src + len @@ -563,6 +567,17 @@ r_end_bytes: subu a0, a0, 0x1 r_out: + jr ra + move a2, zero + +r_end_bytes_up: + lb t0, (a1) + subu a2, a2, 0x1 + sb t0, (a0) + addu a1, a1, 0x1 + bnez a2, r_end_bytes_up + addu a0, a0, 0x1 + jr ra move a2, zero From owner-linux-mips@oss.sgi.com Sat Jun 23 07:26:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NEQIB24026 for linux-mips-outgoing; Sat, 23 Jun 2001 07:26:18 -0700 Received: from dea.waldorf-gmbh.de (u-136-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NEQFV24020 for ; Sat, 23 Jun 2001 07:26:16 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5NEMLO29995; Sat, 23 Jun 2001 16:22:21 +0200 Date: Sat, 23 Jun 2001 16:22:21 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Gleb O. Raiko" , linux-mips@oss.sgi.com Subject: Re: Bug in memmove Message-ID: <20010623162221.A29966@bacchus.dhis.org> References: <3B1E2BF7.5C0CADB8@niisi.msk.ru> 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, Jun 22, 2001 at 08:21:30PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1177 Lines: 26 On Fri, Jun 22, 2001 at 08:21:30PM +0200, Maciej W. Rozycki wrote: > > It seems there is a bug in our memmove routine. The condition is rare > > though, for example, memmove copies incorrectly, if src=5, dst=4, len=9. > [...] > > Two questions here. First, do we have a pattern that satisfies the > > condition, i.e. is the bug showstopper? My guess, it's not. Second, does > > somebody have ideas how to fix the bug? Well, I have, but want to hear > > somebody else. > > Here is a quick fix I developed after reading your report. It fixes the > case you described. Now memcpy() is invoked only if there is no overlap > at all -- the approach is taken from the Alpha port. > > The copy loop begs for optimization (the original memmove() bits do as > well), but at least it works correctly. The patch applies cleanly to > 2.4.5 as of today. > > Ralf, I think it should get applied unless someone cooks up a better > solution, i.e. optimizes it. I'll optimize it myself, eventually, if no > one else does, but don't hold your breath. Applied to my working tree. I'll commit it in a few hours once I found time to implement the same fix for 2.2 and mips64. Ralf From owner-linux-mips@oss.sgi.com Sat Jun 23 09:07:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NG7bd31511 for linux-mips-outgoing; Sat, 23 Jun 2001 09:07:37 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NG7aV31508 for ; Sat, 23 Jun 2001 09:07:36 -0700 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 f5NG7U020937; Sat, 23 Jun 2001 09:07:30 -0700 Message-ID: <3B34BE3B.B72D40F1@mvista.com> Date: Sat, 23 Jun 2001 09:05:15 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: CONFIG_MIPS_UNCACHED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 748 Lines: 18 I looked at the code and it appears this config may not work properly. My understanding is that if CPU has been running with cache enabled, and, presummably, have many dirty cache entries, and if you suddenly change config register to run kernel uncached, you *don't* get all the dirty cache lines flushed into memory. Therefore, you will be accessing stale data in memory. Is this right? If so, we need a better way to run CPU uncached. In the past, I have been a private patch to do so. It seems pretty difficult to come up a generic, because we want to figure out the CPU type and disable cache *before* kernel starts to modify any memory content. BTW, this comes to me as I observe some weired behavior when I try to run uncached. Jun From owner-linux-mips@oss.sgi.com Sat Jun 23 10:13:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NHDGA32116 for linux-mips-outgoing; Sat, 23 Jun 2001 10:13:16 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NHDFV32113 for ; Sat, 23 Jun 2001 10:13:15 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA11650; Sat, 23 Jun 2001 10:13:09 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA03077; Sat, 23 Jun 2001 10:13:06 -0700 (PDT) Message-ID: <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , References: <3B34BE3B.B72D40F1@mvista.com> Subject: Re: CONFIG_MIPS_UNCACHED Date: Sat, 23 Jun 2001 19:17:28 +0200 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 Content-Length: 2009 Lines: 49 > I looked at the code and it appears this config may not work properly. > > My understanding is that if CPU has been running with cache enabled, and, > presummably, have many dirty cache entries, and if you suddenly change config > register to run kernel uncached, you *don't* get all the dirty cache lines > flushed into memory. Therefore, you will be accessing stale data in memory. > > Is this right? If so, we need a better way to run CPU uncached. > > In the past, I have been a private patch to do so. It seems pretty difficult > to come up a generic, because we want to figure out the CPU type and disable > cache *before* kernel starts to modify any memory content. Since the kernel cache attribute is never initialized before ld_mmu_{whatever} is invoked, and since that Config field does not have a well-defined reset state on many MIPS CPUs, it would appear that we are in effect trusting the bootloader to have done something reasonable like set kseg0 to be non-cachable or write-through, either of which would be safe for the current code. Strictly speaking, if we do not wish to assume that the bootloader has corectly initialized the caches, the kernel should begin execution in kseg1and stay there until the caches have been initialized and the kseg0 cache attribute has been set to something sane. And when I say "initialized", I don't mean the writeback-invalidates used by the blast_dcache routines, since those assume a sane state of the tag ram, which cannot be guaranteed at power-up. One should write the tags directly to a sane value on CPUs that support it (on the R3000, one apparently needs to write a byte to each cache line to invalidate it.). I would suggest either that we be explicit about the assumptions about what the bootloader has done to the cache, or we go whole-hog and assume that the kernel has been branched to directly from the reset vector. Tinkering with measures in between strikes me as a waste of time. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sat Jun 23 10:51:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NHptR32428 for linux-mips-outgoing; Sat, 23 Jun 2001 10:51:55 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NHpsV32424 for ; Sat, 23 Jun 2001 10:51:54 -0700 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 f5NHpl025549; Sat, 23 Jun 2001 10:51:47 -0700 Message-ID: <3B34D6AC.9EACA819@mvista.com> Date: Sat, 23 Jun 2001 10:49:32 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS_UNCACHED References: <3B34BE3B.B72D40F1@mvista.com> <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1242 Lines: 31 "Kevin D. Kissell" wrote: > > > I looked at the code and it appears this config may not work properly. > > > > My understanding is that if CPU has been running with cache enabled, and, > > presummably, have many dirty cache entries, and if you suddenly change > config > > register to run kernel uncached, you *don't* get all the dirty cache lines > > flushed into memory. Therefore, you will be accessing stale data in > memory. > > > > Is this right? If so, we need a better way to run CPU uncached. > > > > In the past, I have been a private patch to do so. It seems pretty > difficult > > to come up a generic, because we want to figure out the CPU type and > disable > > cache *before* kernel starts to modify any memory content. > > Since the kernel cache attribute is never initialized before > ld_mmu_{whatever} is invoked, and since that Config field > does not have a well-defined reset state on many MIPS > CPUs, it would appear that we are in effect trusting the > bootloader to have done something reasonable like > set kseg0 to be non-cachable or write-through, either > of which would be safe for the current code. I think you just proposed a fix: check current config register when we turn off cache. Thanks. :-) Jun From owner-linux-mips@oss.sgi.com Sat Jun 23 13:11:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NKBbI05808 for linux-mips-outgoing; Sat, 23 Jun 2001 13:11:37 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NKBaV05805 for ; Sat, 23 Jun 2001 13:11:36 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA12168; Sat, 23 Jun 2001 13:11:30 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA06427; Sat, 23 Jun 2001 13:11:27 -0700 (PDT) Message-ID: <020c01c0fc21$51256760$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <3B34BE3B.B72D40F1@mvista.com> <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> <3B34D6AC.9EACA819@mvista.com> Subject: Re: CONFIG_MIPS_UNCACHED Date: Sat, 23 Jun 2001 22:15:49 +0200 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 Content-Length: 679 Lines: 17 > > Since the kernel cache attribute is never initialized before > > ld_mmu_{whatever} is invoked, and since that Config field > > does not have a well-defined reset state on many MIPS > > CPUs, it would appear that we are in effect trusting the > > bootloader to have done something reasonable like > > set kseg0 to be non-cachable or write-through, either > > of which would be safe for the current code. > > I think you just proposed a fix: check current config register when we turn > off cache. Thanks. :-) That's a heuristic at best. If the config register comes up random, it can appear to be sane even though the cache is in fact uninitialized. Kevin K. From owner-linux-mips@oss.sgi.com Sun Jun 24 15:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OMxUA20910 for linux-mips-outgoing; Sun, 24 Jun 2001 15:59:30 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OMwxV20819; Sun, 24 Jun 2001 15:58:59 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id AAA318552; Mon, 25 Jun 2001 00:58:57 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15EIqG-0002iF-00; Mon, 25 Jun 2001 00:58:56 +0200 Date: Mon, 25 Jun 2001 00:58:56 +0200 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: [PATCH] Make sgiseeq.c 64bit ready (was: CVS Update@oss.sgi.com: linux) Message-ID: <20010625005856.C388@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200106230445.f5N4jtg30745@oss.sgi.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10639 Lines: 325 Ralf Baechle wrote: > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 01/06/22 21:45:55 > > Modified files: > drivers/net : sgiseeq.c > > Log message: > Pull bogus 64-bit changes. This patch makes (as the original) the assumption that sizeof(void *) == 4, so it will work for 32bit only. My seemingly working code for mips64 is appeded as patch against current CVS. Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/net/sgiseeq.c linux/drivers/net/sgiseeq.c --- linux-orig/drivers/net/sgiseeq.c Sun Jun 24 19:55:01 2001 +++ linux/drivers/net/sgiseeq.c Sun Jun 24 22:34:11 2001 @@ -1,5 +1,4 @@ -/* $Id: sgiseeq.c,v 1.17 2000/03/27 23:02:57 ralf Exp $ - * +/* * sgiseeq.c: Seeq8003 ethernet driver for SGI machines. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) @@ -67,7 +66,7 @@ sp->tx_old + (SEEQ_TX_BUFFERS - 1) - sp->tx_new : \ sp->tx_old - sp->tx_new - 1) -#define DEBUG +/* #define DEBUG */ struct sgiseeq_rx_desc { struct hpc_dma_desc rdma; @@ -79,19 +78,24 @@ signed int buf_vaddr; }; -/* Warning: This structure is layed out in a certain way because - * HPC dma descriptors must be 8-byte aligned. So don't - * touch this without some care. +/* Warning: This structure is layed out in a certain way because HPC dma + * descriptors must be 8-byte aligned. So don't touch this without + * some care. + * The spec states 16-byte alignment is needed, so I changed the + * padding and aligned the whole struct accordingly. --THS */ struct sgiseeq_init_block { /* Note the name ;-) */ - /* Ptrs to the descriptors in KSEG1 uncached space. */ + /* Ptrs to the descriptors in KSEG1 or XKPHYS uncached space. */ struct sgiseeq_rx_desc *rx_desc; struct sgiseeq_tx_desc *tx_desc; - unsigned int _padding[30]; /* Pad out to largest cache line size. */ + /* Pad out to largest cache line size (64 byte with 32bit, 128 byte + * with 64bit pointers). + */ + char _padding[14 * sizeof(void *)]; struct sgiseeq_rx_desc rxvector[SEEQ_RX_BUFFERS]; struct sgiseeq_tx_desc txvector[SEEQ_TX_BUFFERS]; -}; +} __attribute__((aligned(16))); struct sgiseeq_private { volatile struct sgiseeq_init_block srings; @@ -149,6 +153,12 @@ #define RCNTCFG_INIT (HPCDMA_OWN | HPCDMA_EORP | HPCDMA_XIE) #define RCNTINFO_INIT (RCNTCFG_INIT | (PKT_BUF_SZ & HPCDMA_BCNT)) +#ifdef CONFIG_SGI_IP28 +#define THIS_K1ADDR K1ADDR +#else +#define THIS_K1ADDR KSEG1ADDR +#endif + static int seeq_init_ring(struct net_device *dev) { struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv; @@ -172,12 +182,12 @@ if(!ib->tx_desc[i].tdma.pbuf) { unsigned long buffer; - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, + GFP_KERNEL | GFP_DMA); if (!buffer) return -ENOMEM; - ib->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + ib->tx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); ib->tx_desc[i].tdma.pbuf = PHYSADDR(buffer); -// flush_cache_all(); } ib->tx_desc[i].tdma.cntinfo = (TCNTINFO_INIT); } @@ -187,12 +197,12 @@ if (!ib->rx_desc[i].rdma.pbuf) { unsigned long buffer; - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, + GFP_KERNEL | GFP_DMA); if (!buffer) return -ENOMEM; - ib->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + ib->rx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); ib->rx_desc[i].rdma.pbuf = PHYSADDR(buffer); -// flush_cache_all(); } ib->rx_desc[i].rdma.cntinfo = (RCNTINFO_INIT); } @@ -300,10 +310,6 @@ } } -#define for_each_rx(rd, sp) for((rd) = &(sp)->srings.rx_desc[(sp)->rx_new]; \ - !((rd)->rdma.cntinfo & HPCDMA_OWN); \ - (rd) = &(sp)->srings.rx_desc[(sp)->rx_new]) - static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp, volatile struct hpc3_ethregs *hregs, volatile struct sgiseeq_regs *sregs) @@ -316,7 +322,9 @@ unsigned int orig_end = PREV_RX(sp->rx_new); /* Service every received packet. */ - for_each_rx(rd, sp) { + for(rd = &sp->srings.rx_desc[sp->rx_new]; + !(rd->rdma.cntinfo & HPCDMA_OWN); + rd = &sp->srings.rx_desc[sp->rx_new]) { len = (PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3); pkt_pointer = (unsigned char *)(long)rd->buf_vaddr; pkt_status = pkt_pointer[len + 2]; @@ -338,7 +346,7 @@ sp->stats.rx_packets++; sp->stats.rx_bytes += len; } else { - printk ("%s: Memory squeeze, deferring packet.\n", + printk("%s: Memory squeeze, deferring packet.\n", dev->name); sp->stats.rx_dropped++; } @@ -370,12 +378,12 @@ /* If the HPC aint doin nothin, and there are more packets * with ETXD cleared and XIU set we must make very certain * that we restart the HPC else we risk locking up the - * adapter. The following code is only safe iff the HPCDMA + * adapter. The following code is only safe if the HPCDMA * is not active! */ while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == (HPCDMA_XIU | HPCDMA_ETXD)) - td = (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext); + td = (struct sgiseeq_tx_desc *)THIS_K1ADDR(td->tdma.pnext); if (td->tdma.cntinfo & HPCDMA_XIU) { hregs->tx_ndptr = PHYSADDR(td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; @@ -435,7 +443,7 @@ /* Always check for received packets. */ sgiseeq_rx(dev, sp, hregs, sregs); - /* Only check for tx acks iff we have something queued. */ + /* Only check for tx acks if we have something queued. */ if (sp->tx_old != sp->tx_new) sgiseeq_tx(dev, sp, hregs, sregs); @@ -497,11 +505,13 @@ return 0; } +#ifdef DEBUG void sgiseeq_my_reset(void) { printk("RESET!\n"); sgiseeq_reset(gdev); } +#endif static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) { @@ -528,7 +538,7 @@ * we have completely set up it's state. This means, do * not clear HPCDMA_EOX in the current last descritptor * until the one we are adding looks consistant and could - * be processes right now. + * be processed right now. * 3) The tx interrupt code must notice when we've added a new * entry and the HPC got to the end of the chain before we * added this new entry and restarted it. @@ -584,7 +594,6 @@ while (i < (nbufs - 1)) { buf[i].tdma.pnext = PHYSADDR(&buf[i + 1]); - buf[i].tdma.pbuf = 0; i++; } buf[i].tdma.pnext = PHYSADDR(&buf[0]); @@ -596,25 +605,22 @@ while (i < (nbufs - 1)) { buf[i].rdma.pnext = PHYSADDR(&buf[i + 1]); - buf[i].rdma.pbuf = 0; i++; } - buf[i].rdma.pbuf = 0; buf[i].rdma.pnext = PHYSADDR(&buf[0]); } static char onboard_eth_addr[6]; -#define ALIGNED(x) ((((unsigned long)(x)) + 0xf) & ~(0xf)) - -int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, - struct hpc3_ethregs *hregs, int irq) +static int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, + struct hpc3_ethregs *hregs, int irq) { static unsigned version_printed; int i; struct sgiseeq_private *sp; - dev->priv = (struct sgiseeq_private *) get_free_page(GFP_KERNEL); + dev->priv = (struct sgiseeq_private *) + get_zeroed_page(GFP_KERNEL | GFP_DMA); if (dev->priv == NULL) return -ENOMEM; @@ -635,17 +641,16 @@ gpriv = sp; gdev = dev; #endif - memset((char *)dev->priv, 0, sizeof(struct sgiseeq_private)); sp->sregs = sregs; sp->hregs = hregs; sp->name = sgiseeqstr; sp->srings.rx_desc = (struct sgiseeq_rx_desc *) - (KSEG1ADDR(ALIGNED(&sp->srings.rxvector[0]))); + (THIS_K1ADDR(&sp->srings.rxvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings.rxvector, sizeof(sp->srings.rxvector)); sp->srings.tx_desc = (struct sgiseeq_tx_desc *) - (KSEG1ADDR(ALIGNED(&sp->srings.txvector[0]))); + (THIS_K1ADDR(&sp->srings.txvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings.txvector, sizeof(sp->srings.txvector)); @@ -677,6 +682,8 @@ return 0; } +#undef THIS_K1ADDR + static inline unsigned char str2hexnum(unsigned char c) { if (c >= '0' && c <= '9') @@ -712,7 +719,6 @@ /* First get the ethernet address of the onboard interface from ARCS. * This is fragile; PROM doesn't like running from cache. - * On MIPS64 it crashes for some other, yet unknown reason ... */ ep = ArcGetEnvironmentVariable("eaddr"); str2eaddr(onboard_eth_addr, ep); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/addrspace.h linux/include/asm-mips64/addrspace.h --- linux-orig/include/asm-mips64/addrspace.h Thu Oct 26 03:18:01 2000 +++ linux/include/asm-mips64/addrspace.h Sun Jun 24 22:09:29 2001 @@ -1,5 +1,4 @@ -/* $Id: addrspace.h,v 1.5 2000/02/01 00:32:01 kanoj Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. @@ -104,9 +103,13 @@ #endif #define K2BASE 0xc000000000000000 +#define K0ADDR(x) (PHYSADDR(x) | K0BASE) +#define K1ADDR(x) (PHYSADDR(x) | K1BASE) +#define K2ADDR(x) (PHYSADDR(x) | K2BASE) + #if !defined (CONFIG_CPU_R8000) -#define COMPAT_K1BASE32 0xffffffffa0000000 -#define PHYS_TO_COMPATK1(x) ((x) | COMPAT_K1BASE32) /* 32-bit compat k1 */ +#define COMPAT_K1BASE32 0xffffffffa0000000 /* 32-bit compat k1 */ +#define PHYS_TO_COMPATK1(x) ((unsigned long)(x) | COMPAT_K1BASE32) #endif #define KDM_TO_PHYS(x) ((unsigned long)(x) & TO_PHYS_MASK) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgihpc.h linux/include/asm-mips64/sgi/sgihpc.h --- linux-orig/include/asm-mips64/sgi/sgihpc.h Sat Dec 4 04:59:13 1999 +++ linux/include/asm-mips64/sgi/sgihpc.h Sun Jun 24 23:20:21 2001 @@ -1,5 +1,4 @@ -/* $Id: sgihpc.h,v 1.2 1999/10/19 20:51:54 ralf Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. @@ -36,7 +35,8 @@ #define HPCDMA_BCNT 0x00003fff /* size in bytes of this dma buffer */ int pnext; /* paddr of next hpc_dma_desc if any */ -}; + int _padding; /* pad to quad word size */ +} __attribute__((aligned(16))); typedef volatile unsigned int hpcreg; @@ -333,8 +333,6 @@ /* We need software copies of these because they are write only. */ extern unsigned int sgi_hpc_write1, sgi_hpc_write2; - -#define SGI_KEYBOARD_IRQ 20 struct hpc_keyb { #ifdef __MIPSEB__ From owner-linux-mips@oss.sgi.com Sun Jun 24 19:06:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P26Ae09738 for linux-mips-outgoing; Sun, 24 Jun 2001 19:06:10 -0700 Received: from intranet.medialincs.com ([210.126.9.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P269V09735 for ; Sun, 24 Jun 2001 19:06:09 -0700 Received: (from root@localhost) by intranet.medialincs.com (2.5 Build 2630 (Berkeley 8.8.6)/8.8.4) id KAA00397 for linux-mips@oss.sgi.com; Mon, 25 Jun 2001 10:04:49 +0900 Date: Mon, 25 Jun 2001 10:04:49 +0900 Message-Id: <200106250104.KAA00397@intranet.medialincs.com> From: =?EUC-KR?B?wba+58iv?= To: linux-mips@oss.sgi.com Subject: SanDisk flash memory 16M MIME-Version: 1.0 X-Mailer: IntraWorks Mailer 1.0 X-Deliver-Express: no X-Deliver-Reply: no X-Deliver-AutoReply: no Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f5P26AV09736 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 290 Lines: 12 anyone have experience SanDisk flash memory porting? I finded driver for Intel & AMD driver, but this flash device is not documented.. and CFI is not ported on Big Endian machine? --------------------------------------------------------- Santa Little Helper mailto:joey@medialincs.com From owner-linux-mips@oss.sgi.com Sun Jun 24 21:44:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4ix619425 for linux-mips-outgoing; Sun, 24 Jun 2001 21:44:59 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4iwV19422 for ; Sun, 24 Jun 2001 21:44:59 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id VAA18399; Sun, 24 Jun 2001 21:42:32 -0700 Date: Sun, 24 Jun 2001 21:42:32 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS_UNCACHED Message-ID: <20010624214232.A18389@mvista.com> References: <3B34BE3B.B72D40F1@mvista.com> <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> <3B34D6AC.9EACA819@mvista.com> <020c01c0fc21$51256760$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: <020c01c0fc21$51256760$0deca8c0@Ulysses>; from kevink@mips.com on Sat, Jun 23, 2001 at 10:15:49PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 898 Lines: 21 On Sat, Jun 23, 2001 at 10:15:49PM +0200, Kevin D. Kissell wrote: > > > Since the kernel cache attribute is never initialized before > > > ld_mmu_{whatever} is invoked, and since that Config field > > > does not have a well-defined reset state on many MIPS > > > CPUs, it would appear that we are in effect trusting the > > > bootloader to have done something reasonable like > > > set kseg0 to be non-cachable or write-through, either > > > of which would be safe for the current code. > > > > I think you just proposed a fix: check current config register when we > turn > > off cache. Thanks. :-) > > That's a heuristic at best. If the config register comes up random, > it can appear to be sane even though the cache is in fact uninitialized. > For any practical reasons, we can assume there is a loader for Linux, and we can assume loader does not run with a random config register. Jun From owner-linux-mips@oss.sgi.com Sun Jun 24 23:46:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P6klu31713 for linux-mips-outgoing; Sun, 24 Jun 2001 23:46:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P6kiV31682 for ; Sun, 24 Jun 2001 23:46:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA18365; Sun, 24 Jun 2001 23:46:37 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA11952; Sun, 24 Jun 2001 23:46:34 -0700 (PDT) Message-ID: <001f01c0fd43$3865b680$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <3B34BE3B.B72D40F1@mvista.com> <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> <3B34D6AC.9EACA819@mvista.com> <020c01c0fc21$51256760$0deca8c0@Ulysses> <20010624214232.A18389@mvista.com> Subject: Re: CONFIG_MIPS_UNCACHED Date: Mon, 25 Jun 2001 08:51:01 +0200 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 Content-Length: 1314 Lines: 29 > > > > Since the kernel cache attribute is never initialized before > > > > ld_mmu_{whatever} is invoked, and since that Config field > > > > does not have a well-defined reset state on many MIPS > > > > CPUs, it would appear that we are in effect trusting the > > > > bootloader to have done something reasonable like > > > > set kseg0 to be non-cachable or write-through, either > > > > of which would be safe for the current code. > > > > > > I think you just proposed a fix: check current config register > > > when we turn off cache. Thanks. :-) > > > > That's a heuristic at best. If the config register comes up random, > > it can appear to be sane even though the cache is in fact uninitialized. > > > > For any practical reasons, we can assume there is a loader for Linux, > and we can assume loader does not run with a random config register. That's a position that would sound reasonable to someone working on Linux for legacy DEC/SGI systems, but not one that I would expect to satisfy someone working on embedded Linux. It would need to be governed by a config option, but I would think that ultimately we need to have a Linux that can be ROMed and branched to directly from the reset vector. Why force everyone doing an embedded MIPS/Linux widget to re-invent the wheel? Kevin K. From owner-linux-mips@oss.sgi.com Mon Jun 25 04:35:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBZx628391 for linux-mips-outgoing; Mon, 25 Jun 2001 04:35:59 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBZuV28382 for ; Mon, 25 Jun 2001 04:35:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA21900; Mon, 25 Jun 2001 13:36:15 +0200 (MET DST) Date: Mon, 25 Jun 2001 13:36:15 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved 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 Content-Length: 2777 Lines: 64 Hi, After extensive debugging I managed to track down the bug that was preventing me from building binutils since the beginning of February. Once again the culprit turned out to the the explicit nature of MIPS' caches. The problem lies in r3k_flush_cache_sigtramp(). It flushes three consecutive word-wide locations starting from the address passed as an argument. The argument is normally a sigreturn trampoline that is set up by setup_frame() or setup_rt_frame(). But these functions set up two opcodes only -- the third word is left untouched. In my case the address was something like 0x7???bff8. So the area to be flushed spanned a page boundary and since the third word was unreferenced, a TLB entry for the page the word was located in was absent. As a result, a TLB refill exception happened with caches isolated, which is not necessarily a win. The symptom was a solid crash. I don't see any reason to flush the third word location, so I removed the code doing it. This fixed the crashes I was observing, but since we are using mapped (KUSEG) addresses in r3k_flush_cache_sigtramp(), I believe we need more protection against unwanted TLB exceptions. The point is we are running with interrupts enabled and a reschedule may happen between touching the trampoline in setup*_frame() and flushing the cache. Hence the TLB entries for the trampoline area, even once present, may get removed meanwhile. So I added some code to explicitly load the entries, if needed, with interrupts disabled just before isolating caches. Following is a resulting patch. Ralf, this is a showstopper bug -- please apply the fix ASAP. This was a tough problem to chase, indeed... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010622-sigtramp-1 diff -up --recursive --new-file linux-mips-2.4.5-20010622.macro/arch/mips/mm/r2300.c linux-mips-2.4.5-20010622/arch/mips/mm/r2300.c --- linux-mips-2.4.5-20010622.macro/arch/mips/mm/r2300.c Mon Jun 11 04:26:13 2001 +++ linux-mips-2.4.5-20010622/arch/mips/mm/r2300.c Mon Jun 25 09:07:42 2001 @@ -391,11 +391,17 @@ static void r3k_flush_cache_sigtramp(uns flags = read_32bit_cp0_register(CP0_STATUS); + write_32bit_cp0_register(CP0_STATUS, flags&~ST0_IEC); + + /* Fill the TLB to avoid an exception with caches isolated. */ + asm ( "lw\t$0,0x000(%0)\n\t" + "lw\t$0,0x004(%0)\n\t" + : : "r" (addr) ); + write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC); asm ( "sb\t$0,0x000(%0)\n\t" "sb\t$0,0x004(%0)\n\t" - "sb\t$0,0x008(%0)\n\t" : : "r" (addr) ); write_32bit_cp0_register(CP0_STATUS, flags); From owner-linux-mips@oss.sgi.com Mon Jun 25 04:52:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBqCx28796 for linux-mips-outgoing; Mon, 25 Jun 2001 04:52:12 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBqBV28793 for ; Mon, 25 Jun 2001 04:52:11 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA01899; Mon, 25 Jun 2001 15:52:32 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA23375; Mon, 25 Jun 2001 15:43:21 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA18194; Mon, 25 Jun 2001 15:45:36 +0400 (MSD) Message-ID: <3B372893.7EB21D8C@niisi.msk.ru> Date: Mon, 25 Jun 2001 16:03:31 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Bug in memmove References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 699 Lines: 20 Maciej, "Maciej W. Rozycki" wrote: > > Ralf, I think it should get applied unless someone cooks up a better > solution, i.e. optimizes it. I'll optimize it myself, eventually, if no > one else does, but don't hold your breath. > Great! Optimized memmove is in todos of several MIPS developers. Considering your patch and my investigation though, it's not showstopper. In fact, there are a few places that call memmove, all of them aren't on "common path". However, I would consider that common path certainly depends on the way Linux is used. I may imagine the configuration where the bug may trigger. Perhaps, eliminating that known "horror fix" (you know) is more important. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Jun 25 05:02:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PC2OO29189 for linux-mips-outgoing; Mon, 25 Jun 2001 05:02:24 -0700 Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PC2LV29186 for ; Mon, 25 Jun 2001 05:02:23 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id QAA02013; Mon, 25 Jun 2001 16:02:32 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA23418; Mon, 25 Jun 2001 15:55:51 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA18618; Mon, 25 Jun 2001 15:59:51 +0400 (MSD) Message-ID: <3B372BE8.C9B3D08F@niisi.msk.ru> Date: Mon, 25 Jun 2001 16:17:44 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: =?iso-8859-1?Q?=C1=B6=BE=E7=C8=AF?= CC: linux-mips@oss.sgi.com Subject: Re: SanDisk flash memory 16M References: <200106250104.KAA00397@intranet.medialincs.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by t111.niisi.ras.ru id QAA02013 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5PC2NV29187 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 248 Lines: 12 Á¶¾çȯ wrote: > > anyone have experience SanDisk flash memory porting? > I finded driver for Intel & AMD driver, but this flash device > is not documented.. > > and CFI is not ported on Big Endian machine? Indeed. Check MTD cvs. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Jun 25 05:16:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PCGOk29454 for linux-mips-outgoing; Mon, 25 Jun 2001 05:16:24 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PCGFV29445 for ; Mon, 25 Jun 2001 05:16:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA22705; Mon, 25 Jun 2001 14:13:31 +0200 (MET DST) Date: Mon, 25 Jun 2001 14:13:31 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: Bug in memmove In-Reply-To: <3B372893.7EB21D8C@niisi.msk.ru> 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 Content-Length: 798 Lines: 21 On Mon, 25 Jun 2001, Gleb O. Raiko wrote: > Considering your patch and my investigation though, it's not > showstopper. In fact, there are a few places that call memmove, all of > them aren't on "common path". However, I would consider that common path > certainly depends on the way Linux is used. I may imagine the > configuration where the bug may trigger. Note that the non-optimal code gets only invoked if the areas do really overlap. > Perhaps, eliminating that known "horror fix" (you know) is more > important. Let's just let it remain in place until working optimization is done. -- + 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 Jun 25 06:20:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PDKaH30628 for linux-mips-outgoing; Mon, 25 Jun 2001 06:20:36 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PDKVV30625 for ; Mon, 25 Jun 2001 06:20:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23892; Mon, 25 Jun 2001 15:22:11 +0200 (MET DST) Date: Mon, 25 Jun 2001 15:22:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS_UNCACHED In-Reply-To: <3B34D6AC.9EACA819@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 Content-Length: 1188 Lines: 26 On Sat, 23 Jun 2001, Jun Sun wrote: > I think you just proposed a fix: check current config register when we turn > off cache. Thanks. :-) Note that many MIPS CPUs do not have the config register that could be used to turn the cache off. That's not a problem for the userland as it's controlled on a page-by-page basis, but the kernel runs unmapped (except from modules) and user vs kernel memory coherency problems arise. I have a patch that makes the kernel run in the KSEG1 space (which is uncached by default even on processors that have the config register). It needs a minor clean-up for exception handlers, though, as they start in KSEG0 with no possibility to override. So they should jump to KSEG1 ASAP -- hopefully two icache lines are OK; if cache in non-functional then we are screwed as using bootstrap exception vectors is not an option, usually. Cacheability of KSEG0 may be further disabled if possible. I'll send the patch soon, when I clean it up. 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 Mon Jun 25 07:04:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PE4Sh31281 for linux-mips-outgoing; Mon, 25 Jun 2001 07:04:28 -0700 Received: from dea.waldorf-gmbh.de (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id f5PE4RV31277 for ; Mon, 25 Jun 2001 07:04:27 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5P6sxG01285; Mon, 25 Jun 2001 08:54:59 +0200 Date: Mon, 25 Jun 2001 08:54:59 +0200 From: Ralf Baechle To: Raghav P Cc: linux-mips@oss.sgi.com Subject: Re: KSEG2 Segment not used on Linux? Message-ID: <20010625085459.B1220@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 raghav@ishoni.com on Thu, Jun 21, 2001 at 08:08:06PM +0530 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 492 Lines: 18 On Thu, Jun 21, 2001 at 08:08:06PM +0530, Raghav P wrote: > From: "Raghav P" > To: ^^^^^^^^^^^^^^^^ Don't send email to the owner address - it may stay unread forever! > Is KSEG2 used on Linux ports for R2300? Yes, ioremap and kernel modules use that address space on all 32-bit kernels. > Also does Linux recognise physical memory more than 512MB on MIPS system? Is > there any equivalent of highmem for MIPS? Not yet. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 25 07:53:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PErcb32121 for linux-mips-outgoing; Mon, 25 Jun 2001 07:53:38 -0700 Received: from web10201.mail.yahoo.com (web10201.mail.yahoo.com [216.136.130.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PErbV32103 for ; Mon, 25 Jun 2001 07:53:37 -0700 Message-ID: <20010625145337.67484.qmail@web10201.mail.yahoo.com> Received: from [195.143.217.178] by web10201.mail.yahoo.com; Mon, 25 Jun 2001 07:53:37 PDT Date: Mon, 25 Jun 2001 07:53:37 -0700 (PDT) From: Timothy Daly Subject: introduction To: linux-mips@oss.sgi.com In-Reply-To: <20010625085459.B1220@bacchus.dhis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 994 Lines: 31 Hi all. :) I'd like to introduce myself, if I may. My name's Tim, and I'm in Berlin at the moment. I recently picked up an Indigo2 R10000 SI, which is a very nice purple. I can't really knock Irix, but I don't have the source, and I don't have a compiler, which is like a car with no seats where you can't open the hood. Besides, I've always wanted to have a good reason to hack around on the Linux kernel a bit. So, here I am. :) I'm going to spend the next week or two getting my bearings on what's been done, and what's waiting to be done. Then, if I'm not completely out of my depth, maybe I can help with some stuff. One thing that's somewhat unfortunate is that it seems SGI still hasn't released any documentation for the Impact graphics hardware. Is there any word on that? Well, pleased to meet you all. Have fun. -Tim __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jun 25 08:51:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PFpfX01254 for linux-mips-outgoing; Mon, 25 Jun 2001 08:51:41 -0700 Received: from web13904.mail.yahoo.com (web13904.mail.yahoo.com [216.136.175.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PFpeV01251 for ; Mon, 25 Jun 2001 08:51:40 -0700 Message-ID: <20010625155138.78161.qmail@web13904.mail.yahoo.com> Received: from [61.187.62.76] by web13904.mail.yahoo.com; Mon, 25 Jun 2001 08:51:38 PDT Date: Mon, 25 Jun 2001 08:51:38 -0700 (PDT) From: Barry Wu Subject: about linux mips ext2fs To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 601 Lines: 20 Hi, all, I am new to this maillist. I want to mount root file system under mipsel linux. I got root file system from MIPS company. But I have no ready mips linux system. Therefore I have to copy this root file system to hard disk under intel linux. Using its fdisk and ext2fs. I do not know if it can work under mipsel linux. That mean mipsel linux can support same ext2fs and partition? If someone knows, please help me. Thanks in advance! Qingbo __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jun 25 09:40:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PGecT02143 for linux-mips-outgoing; Mon, 25 Jun 2001 09:40:38 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PGebV02140 for ; Mon, 25 Jun 2001 09:40:37 -0700 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 f5PGeV021424; Mon, 25 Jun 2001 09:40:31 -0700 Message-ID: <3B3768F0.19D7A773@mvista.com> Date: Mon, 25 Jun 2001 09:38:08 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS_UNCACHED References: <3B34BE3B.B72D40F1@mvista.com> <01ee01c0fc08$66e81e80$0deca8c0@Ulysses> <3B34D6AC.9EACA819@mvista.com> <020c01c0fc21$51256760$0deca8c0@Ulysses> <20010624214232.A18389@mvista.com> <001f01c0fd43$3865b680$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1956 Lines: 45 "Kevin D. Kissell" wrote: > > > > > > Since the kernel cache attribute is never initialized before > > > > > ld_mmu_{whatever} is invoked, and since that Config field > > > > > does not have a well-defined reset state on many MIPS > > > > > CPUs, it would appear that we are in effect trusting the > > > > > bootloader to have done something reasonable like > > > > > set kseg0 to be non-cachable or write-through, either > > > > > of which would be safe for the current code. > > > > > > > > I think you just proposed a fix: check current config register > > > > when we turn off cache. Thanks. :-) > > > > > > That's a heuristic at best. If the config register comes up random, > > > it can appear to be sane even though the cache is in fact uninitialized. > > > > > > > For any practical reasons, we can assume there is a loader for Linux, > > and we can assume loader does not run with a random config register. > > That's a position that would sound reasonable to someone working > on Linux for legacy DEC/SGI systems, but not one that I would > expect to satisfy someone working on embedded Linux. It would > need to be governed by a config option, but I would think > that ultimately we need to have a Linux that can be ROMed > and branched to directly from the reset vector. Why force > everyone doing an embedded MIPS/Linux widget to re-invent > the wheel? > The currenct common practice in embedded world is: 1. during development stage, using a loader to download kernel to target. 2. during productization stage, use a separate rom loader to cold-start the board and load the kernel from flash to RAM, assuming the kernel is on flash. There are a couple of other vairants, but generally you do have a first stage loader that will set up the environment right for Linux kernel. Cold-starting a board and loading a kernel is highly board and system specific. Does not seem to make sense to get included in the kernel structure. Jun From owner-linux-mips@oss.sgi.com Mon Jun 25 10:42:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PHguR03425 for linux-mips-outgoing; Mon, 25 Jun 2001 10:42:56 -0700 Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PHgsV03422 for ; Mon, 25 Jun 2001 10:42:54 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Mon, 25 Jun 2001 10:42:52 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from postal.sibyte.com (IDENT:postfix@[10.21.128.60]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA01352; Mon, 25 Jun 2001 10:42:53 -0700 (PDT) Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 326A71595F; Mon, 25 Jun 2001 10:42:53 -0700 (PDT) Received: by plugh.sibyte.com (Postfix, from userid 61017) id A441F686D; Mon, 25 Jun 2001 10:42:38 -0700 (PDT) From: "Justin Carlson" Reply-to: carlson@sibyte.com Organization: Sibyte To: "Kevin D. Kissell" Subject: Re: CONFIG_MIPS_UNCACHED Date: Mon, 25 Jun 2001 10:35:43 -0700 X-Mailer: KMail [version 1.0.29] References: <3B34BE3B.B72D40F1@mvista.com> <20010624214232.A18389@mvista.com> <001f01c0fd43$3865b680$0deca8c0@Ulysses> In-Reply-To: <001f01c0fd43$3865b680$0deca8c0@Ulysses> cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-ID: <0106251042380I.00703@plugh.sibyte.com> X-WSS-ID: 1729A796199872-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1022 Lines: 21 On Sun, 24 Jun 2001, you wrote: > That's a position that would sound reasonable to someone working > on Linux for legacy DEC/SGI systems, but not one that I would > expect to satisfy someone working on embedded Linux. It would > need to be governed by a config option, but I would think > that ultimately we need to have a Linux that can be ROMed > and branched to directly from the reset vector. Why force > everyone doing an embedded MIPS/Linux widget to re-invent > the wheel? Because there are very good reasons for having a firmware seperate from the OS. Otherwise, you're more or less proposing a new run-time-environment that has to do all the hardware sanitizations and initializations before we get to the bootstrap environment. That's going to be so system-specific and disparate from the kernel that it doesn't, IMHO, make any sense to put it there. This is especially true since *not* having it in the kernel gives you the chance to exploit the same firmware environment for non-linux OS'es. -Justin From owner-linux-mips@oss.sgi.com Mon Jun 25 11:20:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PIKEw03845 for linux-mips-outgoing; Mon, 25 Jun 2001 11:20:14 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PIKCV03839 for ; Mon, 25 Jun 2001 11:20:13 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id CA76A7F5; Mon, 25 Jun 2001 20:20:11 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 2659943AA; Mon, 25 Jun 2001 20:20:30 +0200 (CEST) Date: Mon, 25 Jun 2001 20:20:30 +0200 From: Florian Lohoff To: Barry Wu Cc: linux-mips@oss.sgi.com Subject: Re: about linux mips ext2fs Message-ID: <20010625202030.B701@paradigm.rfc822.org> References: <20010625155138.78161.qmail@web13904.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010625155138.78161.qmail@web13904.mail.yahoo.com>; from wqb123@yahoo.com on Mon, Jun 25, 2001 at 08:51:38AM -0700 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1050 Lines: 26 On Mon, Jun 25, 2001 at 08:51:38AM -0700, Barry Wu wrote: > Hi, all, > > I am new to this maillist. I want to mount root > file system under mipsel linux. I got root file > system from MIPS company. But I have no ready mips > linux system. Therefore I have to copy this root > file system to hard disk under intel linux. Using > its fdisk and ext2fs. I do not know if it can work > under mipsel linux. That mean mipsel linux can > support same ext2fs and partition? If someone knows, > please help me. Linux/mips uses ext2 - Ext2 is per definition little endian and all big endian targets use byteswap mechanisms (All but very old Linux/m68k systems). So - yes - you can read i386 written ext2 on mips machines. With the partition type - I guess all architectures are able to read dos partition tables allthough they might not be the default (On SGI we mostly use IRIX style partition tables) 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 Jun 25 12:10:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PJAJ004590 for linux-mips-outgoing; Mon, 25 Jun 2001 12:10:19 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PJAHV04587 for ; Mon, 25 Jun 2001 12:10:17 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 37A6C3E90; Mon, 25 Jun 2001 12:04:57 -0700 (PDT) Date: Mon, 25 Jun 2001 12:04:57 -0700 From: Keith M Wesolowski To: Florian Lohoff Cc: Barry Wu , linux-mips@oss.sgi.com Subject: Re: about linux mips ext2fs Message-ID: <20010625120457.A15950@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010625202030.B701@paradigm.rfc822.org> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 976 Lines: 20 On Mon, Jun 25, 2001 at 08:20:30PM +0200, Florian Lohoff wrote: > Linux/mips uses ext2 - Ext2 is per definition little endian and all > big endian targets use byteswap mechanisms (All but very old Linux/m68k > systems). So - yes - you can read i386 written ext2 on mips machines. > > With the partition type - I guess all architectures are able to read > dos partition tables allthough they might not be the default (On SGI > we mostly use IRIX style partition tables) All true, though the more standard way to get software onto your system is using network booting and nfsroot. Then you can create partition tables and filesystems locally, then copy or install appropriate software from the nfsroot onto local disk. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "Nothing motivates a man more than to see his boss put in an honest day's work." -- The fortune file From owner-linux-mips@oss.sgi.com Mon Jun 25 16:54:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PNsr328487 for linux-mips-outgoing; Mon, 25 Jun 2001 16:54:53 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PNsrV28483 for ; Mon, 25 Jun 2001 16:54:53 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6F295125BA; Mon, 25 Jun 2001 16:54:52 -0700 (PDT) Date: Mon, 25 Jun 2001 16:54:52 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: RedHat 7.1 for MIPS is available Message-ID: <20010625165452.A3723@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 26 I have uploaded the mipsel rpms. I will upload the mips rpms once the build is finished. H.J. ---- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The glibc is compiled with -mips2. 2. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. 3. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. Thanks. H.J. From owner-linux-mips@oss.sgi.com Mon Jun 25 18:53:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q1rj703095 for linux-mips-outgoing; Mon, 25 Jun 2001 18:53:45 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q1riV03092 for ; Mon, 25 Jun 2001 18:53:44 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id AE8BD1148; Mon, 25 Jun 2001 21:53:43 -0400 (EDT) Date: Mon, 25 Jun 2001 21:53:42 -0400 (EDT) From: George Gensure To: Timothy Daly Cc: Subject: Re: introduction In-Reply-To: <20010625145337.67484.qmail@web10201.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 91 Lines: 7 > very nice purple. I can't really knock Irix, but I I can... George werkt@csh.rit.edu From owner-linux-mips@oss.sgi.com Tue Jun 26 00:56:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q7utQ21873 for linux-mips-outgoing; Tue, 26 Jun 2001 00:56:55 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q7uqV21867 for ; Tue, 26 Jun 2001 00:56:53 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA24293; Tue, 26 Jun 2001 09:56:14 +0200 (MET DST) Date: Tue, 26 Jun 2001 09:56:14 +0200 (MEST) From: Geert Uytterhoeven To: Florian Lohoff cc: Barry Wu , linux-mips@oss.sgi.com Subject: Re: about linux mips ext2fs In-Reply-To: <20010625202030.B701@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 685 Lines: 19 On Mon, 25 Jun 2001, Florian Lohoff wrote: > Linux/mips uses ext2 - Ext2 is per definition little endian and all > big endian targets use byteswap mechanisms (All but very old Linux/m68k > systems). So - yes - you can read i386 written ext2 on mips machines. All but very old Linux/m68k and Linux/PPC systems. If you insist on booting such old kernels, `man e2fsck' for the flag to change the endianness. 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 Jun 26 01:46:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q8kZ724192 for linux-mips-outgoing; Tue, 26 Jun 2001 01:46:35 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q8kXV24189 for ; Tue, 26 Jun 2001 01:46:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA01081; Tue, 26 Jun 2001 01:46:26 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA24707; Tue, 26 Jun 2001 01:46:23 -0700 (PDT) Message-ID: <008a01c0fe1d$1fbd9a00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: Cc: References: <3B34BE3B.B72D40F1@mvista.com> <20010624214232.A18389@mvista.com> <001f01c0fd43$3865b680$0deca8c0@Ulysses> <0106251042380I.00703@plugh.sibyte.com> Subject: Re: CONFIG_MIPS_UNCACHED Date: Tue, 26 Jun 2001 10:50:50 +0200 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 Content-Length: 2621 Lines: 59 > > That's a position that would sound reasonable to someone working > > on Linux for legacy DEC/SGI systems, but not one that I would > > expect to satisfy someone working on embedded Linux. It would > > need to be governed by a config option, but I would think > > that ultimately we need to have a Linux that can be ROMed > > and branched to directly from the reset vector. Why force > > everyone doing an embedded MIPS/Linux widget to re-invent > > the wheel? > > Because there are very good reasons for having a firmware seperate from > the OS. Yes, and there are also very good reasons for minimizing the size and functionality of that bootloader. One could have a minimalist but functional MIPS bootloader that runs in kseg1 and hasn't the faintest idea what a cache is. As I said in an earlier message on this thread, we should either be explicit about what we assume the bootloader will have done for us, or prepare to have the relevant CPU/cache intitialization done by the kernel. > Otherwise, you're more or less proposing a new run-time-environment > that has to do all the hardware sanitizations and initializations before we > get to the bootstrap environment. That's going to be so system-specific and > disparate from the kernel that it doesn't, IMHO, make any sense to put it > there. Cache tag initialization is CPU-specific, not system specific. > This is especially true since *not* having it in the kernel gives you > the chance to exploit the same firmware environment for non-linux OS'es. The systems I'm worried about don't *have* any non-Linux OSes. I do not advocate unconditionally putting proper cache initialization code into every MIPS/Linux kernel! I wouldn't dream of preventing some one else from putting their full faith in the perfectly understood and well-documented bootloaders on their Indy or DECstation. ;-) And people who have otherwise found it to be a reasonable design trade off to build a cache-aware bootloader should not have to pay the time or footprint to initialize the cache twice. But so long as there are people who want to build new, specialized devices running embedded Linux, it is in their interest that the MIPS/Linux kernel distribution provide them with as much of the generic processor startup functionality as possible, so that they can concentrate their energies on making their products different and better instead of re-re-implementing cache initialization code (and maybe getting it wrong). But in any case, have no fear, I'm unlikely to be submitting any such patch any time soon! Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jun 26 06:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QD9qe29192 for linux-mips-outgoing; Tue, 26 Jun 2001 06:09:52 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QD9oV29189 for ; Tue, 26 Jun 2001 06:09:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA17610; Tue, 26 Jun 2001 15:11:42 +0200 (MET DST) Date: Tue, 26 Jun 2001 15:11:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: carlson@sibyte.com, linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS_UNCACHED In-Reply-To: <008a01c0fe1d$1fbd9a00$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 Content-Length: 936 Lines: 21 On Tue, 26 Jun 2001, Kevin D. Kissell wrote: > code into every MIPS/Linux kernel! I wouldn't dream of preventing > some one else from putting their full faith in the perfectly understood > and well-documented bootloaders on their Indy or DECstation. ;-) With functions like malloc(), strlen(), strcpy(), printf(), getenv(), etc. I wouldn't name the DECstation's firmware (the REX one) just a bootloader. It's more like a minimal libc with additional functionality to interface to hw, it's very well documented indeed (as opposed to most of DECstations' hw, sigh...) and it appears to present a kernel an interface that conforms to published docs. Of course, I don't expect anyone to put a libc into their embedded system's ROM. -- + 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 Jun 26 08:49:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QFn9B32479 for linux-mips-outgoing; Tue, 26 Jun 2001 08:49:09 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QFn7V32474 for ; Tue, 26 Jun 2001 08:49:08 -0700 Received: from cotw.com (ptecdev3.inter.net [192.168.10.5]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id KAA25066 for ; Tue, 26 Jun 2001 10:49:06 -0500 Message-ID: <3B38CBFF.1BE0FD8C@cotw.com> Date: Tue, 26 Jun 2001 10:53:03 -0700 From: Scott A McConnell X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: mmap problems ? in 2.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 15 I have a simple program that maps a frame buffer into user space and draws an image onto the fb. This program worked fine under 2.4.3 however under 2.4.5 the program runs but nothing appears on the FB. The memory I am writing to does not appear to be the frame buffer. Nothing has changed in my fb driver so I am wondering if anything has changed in how memory is mapped via the kernel? Thanks for your consideration -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Tue Jun 26 09:47:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QGlce00885 for linux-mips-outgoing; Tue, 26 Jun 2001 09:47:38 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QGlaV00882 for ; Tue, 26 Jun 2001 09:47:36 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f5QGl9006014; Tue, 26 Jun 2001 09:47:09 -0700 Message-ID: <3B38BB9F.9050203@pacbell.net> Date: Tue, 26 Jun 2001 09:43:11 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott A McConnell CC: linux-mips@oss.sgi.com Subject: Re: mmap problems ? in 2.4.5 References: <3B38CBFF.1BE0FD8C@cotw.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 738 Lines: 23 Scott A McConnell wrote: >I have a simple program that maps a frame buffer into user space and >draws an image >onto the fb. > >This program worked fine under 2.4.3 however under 2.4.5 the program >runs but nothing appears on the FB. The memory I am writing to does not >appear to be the frame buffer. > >Nothing has changed in my fb driver so I am wondering if anything has >changed in how memory is mapped via the kernel? > >Thanks for your consideration > I believe the frame buffer driver interface changed in 2.4.5. It supposed to be much cleaner now and the fb driver has to do less than before. You'll probably need to port your driver to 2.4.5. If you have any problems, I think the fb maintainers can help you out. Pete From owner-linux-mips@oss.sgi.com Tue Jun 26 11:20:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QIKpI04238 for linux-mips-outgoing; Tue, 26 Jun 2001 11:20:51 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QIKnV04235 for ; Tue, 26 Jun 2001 11:20:50 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f5QIKXw05858; Tue, 26 Jun 2001 11:20:33 -0700 (PDT) Date: Tue, 26 Jun 2001 11:20:33 -0700 (PDT) From: "John D. Davis" To: , Subject: I few questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 428 Lines: 15 I have a few simple questions that I have been wondering about. I am currently running the debian verison of Linux with 2.4.0 kernel on an Indy. 1) What is the difference between the Redhat and debian verison of linux? Should I use one over the other for my Indy? 2) Is there a JVM/JIT available for MIPS Linux? 3) Is there something that is available to replace sash, another bootloader? thanks for your time, john davis From owner-linux-mips@oss.sgi.com Tue Jun 26 12:19:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJJaS05976 for linux-mips-outgoing; Tue, 26 Jun 2001 12:19:36 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJJVV05973 for ; Tue, 26 Jun 2001 12:19:31 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id VAA29041; Tue, 26 Jun 2001 21:18:16 +0200 (MET DST) Date: Tue, 26 Jun 2001 21:18:10 +0200 (MET DST) From: Geert Uytterhoeven To: Pete Popov cc: Scott A McConnell , linux-mips@oss.sgi.com Subject: Re: mmap problems ? in 2.4.5 In-Reply-To: <3B38BB9F.9050203@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1101 Lines: 29 On Tue, 26 Jun 2001, Pete Popov wrote: > Scott A McConnell wrote: > >I have a simple program that maps a frame buffer into user space and > >draws an image > >onto the fb. > > > >This program worked fine under 2.4.3 however under 2.4.5 the program > >runs but nothing appears on the FB. The memory I am writing to does not > >appear to be the frame buffer. > > > >Nothing has changed in my fb driver so I am wondering if anything has > >changed in how memory is mapped via the kernel? > > > I believe the frame buffer driver interface changed in 2.4.5. It > supposed to be much cleaner now and the fb driver has to do less than > before. You'll probably need to port your driver to 2.4.5. If you have > any problems, I think the fb maintainers can help you out. No, those fundamental changes are scheduled for 2.5.x. 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 Jun 26 12:20:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJKsh06122 for linux-mips-outgoing; Tue, 26 Jun 2001 12:20:54 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJKrV06119 for ; Tue, 26 Jun 2001 12:20:53 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5QJKfe9003855; Tue, 26 Jun 2001 12:20:41 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f5QJKfFF003851; Tue, 26 Jun 2001 12:20:41 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 26 Jun 2001 12:20:40 -0700 (PDT) From: James Simmons To: Pete Popov cc: Scott A McConnell , linux-mips@oss.sgi.com Subject: Re: mmap problems ? in 2.4.5 In-Reply-To: <3B38BB9F.9050203@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 463 Lines: 10 > I believe the frame buffer driver interface changed in 2.4.5. It > supposed to be much cleaner now and the fb driver has to do less than > before. You'll probably need to port your driver to 2.4.5. If you have > any problems, I think the fb maintainers can help you out. Thats the wrapper I wrote so drivers could be written with the new api while using 2.4.X. It hasn't gone in. Plus when/if it does it should have a effect on any core code in fbcon. From owner-linux-mips@oss.sgi.com Tue Jun 26 13:07:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QK7IT11929 for linux-mips-outgoing; Tue, 26 Jun 2001 13:07:18 -0700 Received: from cvsftp.cotw.com (cvsftp.cotw.com [208.242.241.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QK7CV11911 for ; Tue, 26 Jun 2001 13:07:13 -0700 Received: from cotw.com (ptecdev3.inter.net [192.168.10.5]) by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id PAA26100; Tue, 26 Jun 2001 15:05:57 -0500 Message-ID: <3B390832.815EC58D@cotw.com> Date: Tue, 26 Jun 2001 15:09:54 -0700 From: Scott A McConnell X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: linux-mips@oss.sgi.com Subject: Re: mmap problems ? in 2.4.5 References: <3B38CBFF.1BE0FD8C@cotw.com> <3B38BB9F.9050203@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 136 Lines: 5 I can cat data to /dev/fb and the console works just fine on the fb. This looks like a mmap problem. Anyone else have problems? Scott From owner-linux-mips@oss.sgi.com Tue Jun 26 13:14:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QKEmM13213 for linux-mips-outgoing; Tue, 26 Jun 2001 13:14:48 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QKElV13210 for ; Tue, 26 Jun 2001 13:14:47 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id WAA00611 for ; Tue, 26 Jun 2001 22:14:45 +0200 (MET DST) Date: Tue, 26 Jun 2001 21:51:52 +0200 (MET DST) From: Geert Uytterhoeven To: Scott A McConnell cc: Geert Uytterhoeven Subject: Re: mmap problems ? in 2.4.5 In-Reply-To: <3B39009F.13E0C40E@cotw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 520 Lines: 24 Hi Scott, > I can cat data to /dev/fb and the console appears. > > So it is mmap that is having trouble. > > Has anyone else been having problems? Not that I'm aware of. Perhaps it's a MIPS specific problem? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Jun 26 15:17:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMH7k32212 for linux-mips-outgoing; Tue, 26 Jun 2001 15:17:07 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMH6V32209 for ; Tue, 26 Jun 2001 15:17:06 -0700 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 f5QMH1029355; Tue, 26 Jun 2001 15:17:01 -0700 Message-ID: <3B390949.7B300BD1@mvista.com> Date: Tue, 26 Jun 2001 15:14:33 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Re: PATCH: support for Vr41xx cpu family and Vr4181/Osprey References: <3B38EDC6.3ADB8148@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 565 Lines: 19 I just realize the previous email makes me greater than who really I am. :-) The VR41XX generic support is a combination of my work and Yoichi Yuasa. Most of the Vr4181/Osprey stuff is stolen from Linux-VR tree but restructured in a way to better support future Vr4181-based systems (such as Agenda VR3, any takers?). Also, here is a todo list: . use the new IRQ . use new the new time.c . use the standard serial . add sound, framebuffer and touch panel for Vr4181 The sound driver should be similar to Vrc5477 ac97 sound driver that I put in recently. Jun From owner-linux-mips@oss.sgi.com Tue Jun 26 19:23:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R2NSd03306 for linux-mips-outgoing; Tue, 26 Jun 2001 19:23:28 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R2NJV03303; Tue, 26 Jun 2001 19:23:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id EAA301202; Wed, 27 Jun 2001 04:23:15 +0200 (CEST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11464; Wed, 27 Jun 2001 12:21:57 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips In-reply-to: Your message of "Wed, 13 Jun 2001 22:19:14 +1000." <8465.992434754@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 12:21:57 +1000 Message-ID: <16633.993608517@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 967 Lines: 29 On Wed, 13 Jun 2001 22:19:14 +1000, Keith Owens wrote: >ksymoops is designed to run on any build arch and debug an oops report >from any other target arch, as long as binutils supports the target >arch. The presence or absence of __MIPSEL__ or __MIPSEB__ on the build >system says nothing about the type of the failing target, ksymoops >relies on text in the oops report to determine special cases like 32 >bit userland and 64 bit kernel. > >The best option is for a mips64 kernel to indicate that it is 64 bit >and its endianess. Instead of printing > > "epc : %016lx\n" > >print > > "epc : %016lx (64 " >#ifdef __MIPSEL__ > "LSB" >#else > "MSB" >#endif > ")\n" I have a new ksymoops release coming up. Is it OK if I include code to look for (64 LSB) and (64 MSB) in the oops and decode accordingly. I don't expect the kernel to produce this output immediately, I just want agreement on the format that will be produced. From owner-linux-mips@oss.sgi.com Wed Jun 27 02:22:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R9Me010067 for linux-mips-outgoing; Wed, 27 Jun 2001 02:22:40 -0700 Received: from abel.numerik.math.uni-siegen.de (root@abel.numerik.math.Uni-Siegen.DE [141.99.112.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R9MNV10060 for ; Wed, 27 Jun 2001 02:22:39 -0700 Received: (from engel@localhost) by abel.numerik.math.uni-siegen.de (Mailhost) id f5R9NTX9003803 for linux-mips@oss.sgi.com; Wed, 27 Jun 2001 11:23:29 +0200 From: Michael Engel Message-Id: <200106270923.f5R9NTX9003803@abel.numerik.math.uni-siegen.de> Subject: I have spare decstations (fwd) To: linux-mips@oss.sgi.com Date: Wed, 27 Jun 2001 11:23:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 169 Lines: 10 Hi, if anyone in the Bay Area is interested in obtaining a DECstation 3100 please contact Arthur. regards, Michael ----- Forwarded message from Arthur Britto ----- From engel Wed Jun 27 05:52:18 2001 From: "Arthur Britto" To: Subject: I have spare decstations Date: Tue, 26 Jun 2001 20:50:40 -0700 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 497 Lines: 18 [Charset iso-8859-1 unsupported, filtering to ASCII...] Hi, I could not find the mailing list for decstation Linux. Perhaps you could help me... I have two DecStation 3100s that I must dispose of immediately. I would happily provide them to anyone working on the port. If you know of anyone who could use the machines and is able to pick up the machines in Berkeley, California they are available for free. Thank you, Arthur Britto ----- End of forwarded message from Arthur Britto ----- From owner-linux-mips@oss.sgi.com Wed Jun 27 06:35:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RDZRY13798 for linux-mips-outgoing; Wed, 27 Jun 2001 06:35:27 -0700 Received: from dea.waldorf-gmbh.de (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id f5RDZPV13794 for ; Wed, 27 Jun 2001 06:35:26 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5RDY1p02536; Wed, 27 Jun 2001 15:34:01 +0200 Date: Wed, 27 Jun 2001 15:34:01 +0200 From: Ralf Baechle To: "John D. Davis" Cc: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: Re: I few questions Message-ID: <20010627153401.A2241@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 johnd@Stanford.EDU on Tue, Jun 26, 2001 at 11:20:33AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 794 Lines: 21 On Tue, Jun 26, 2001 at 11:20:33AM -0700, John D. Davis wrote: > I have a few simple questions that I have been wondering about. I am > currently running the debian verison of Linux with 2.4.0 kernel on an > Indy. > > 1) What is the difference between the Redhat and debian verison of linux? > Should I use one over the other for my Indy? That's a mostly a question of your personal preference. > 3) Is there something that is available to replace sash, another > bootloader? You don't need sash at all unless you want to boot a kernel from a XFS filesystem. You can write the kernel intot the volumeheader using either the Linux or IRIX version of dvhtool or boot it from NFS. If your Indy has a very old PROM which doesn't accept ELF binaries you have to convert it to ECOFF. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 27 06:51:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RDpCQ14025 for linux-mips-outgoing; Wed, 27 Jun 2001 06:51:12 -0700 Received: from dea.waldorf-gmbh.de (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id f5RDpAV14022 for ; Wed, 27 Jun 2001 06:51:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5RDnhK02604; Wed, 27 Jun 2001 15:49:43 +0200 Date: Wed, 27 Jun 2001 15:49:42 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved Message-ID: <20010627154941.A2592@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 macro@ds2.pg.gda.pl on Mon, Jun 25, 2001 at 01:36:15PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1779 Lines: 34 On Mon, Jun 25, 2001 at 01:36:15PM +0200, Maciej W. Rozycki wrote: > After extensive debugging I managed to track down the bug that was > preventing me from building binutils since the beginning of February. > Once again the culprit turned out to the the explicit nature of MIPS' > caches. > > The problem lies in r3k_flush_cache_sigtramp(). It flushes three > consecutive word-wide locations starting from the address passed as an > argument. The argument is normally a sigreturn trampoline that is set up > by setup_frame() or setup_rt_frame(). But these functions set up two > opcodes only -- the third word is left untouched. In my case the address > was something like 0x7???bff8. So the area to be flushed spanned a page > boundary and since the third word was unreferenced, a TLB entry for the > page the word was located in was absent. As a result, a TLB refill > exception happened with caches isolated, which is not necessarily a win. > The symptom was a solid crash. > > I don't see any reason to flush the third word location, so I removed the > code doing it. This fixed the crashes I was observing, but since we are > using mapped (KUSEG) addresses in r3k_flush_cache_sigtramp(), I believe we > need more protection against unwanted TLB exceptions. The point is we are > running with interrupts enabled and a reschedule may happen between > touching the trampoline in setup*_frame() and flushing the cache. Hence > the TLB entries for the trampoline area, even once present, may get > removed meanwhile. So I added some code to explicitly load the entries, > if needed, with interrupts disabled just before isolating caches. > Following is a resulting patch. > > Ralf, this is a showstopper bug -- please apply the fix ASAP. Applied. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 27 11:35:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RIZ9124977 for linux-mips-outgoing; Wed, 27 Jun 2001 11:35:09 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RIZ8V24966 for ; Wed, 27 Jun 2001 11:35:08 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 516B0125BA; Wed, 27 Jun 2001 11:35:08 -0700 (PDT) Date: Wed, 27 Jun 2001 11:35:08 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: RedHat 7.1 for mips/mipsel has been uploaded Message-ID: <20010627113507.A11169@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 812 Lines: 31 The mips rpms are there and I also updated a few mipsel rpms. I recompiled glibc without -mips2 so that it can run on MIPS I cpus. But you may have problems with some kernels. Let me know if you have successes or problems. I'd like to hear stories on mips boxes since I only have mipsel. Thanks. H.J. ---- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Jun 27 14:02:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RL2xm14373 for linux-mips-outgoing; Wed, 27 Jun 2001 14:02:59 -0700 Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RL2wV14360 for ; Wed, 27 Jun 2001 14:02:58 -0700 Received: (qmail 17285 invoked by uid 104); 27 Jun 2001 21:02:50 -0000 Received: from Trina_Littlejohns@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.421554 secs); 27/06/2001 14:02:50 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 27 Jun 2001 21:02:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5RL2ne05778; Wed, 27 Jun 2001 14:02:49 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 14:07:10 -0700 Message-ID: <60474D3886D54F4BAB0CB49A4BB6E8A8837904@bby1exp01> From: Trina Littlejohns To: "'Ralf Baechle'" , "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: RE: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved Date: Wed, 27 Jun 2001 14:07:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5RL2wV14362 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2737 Lines: 65 Dear Mr. Baechle, Thank you for your request for support on PMC-Sierra products. In order to serve you better, we require some additional contact information. This information will be used to direct your request to the appropriate factory or field applications engineer, and to help us track your support incident. Could you please reply to me with the following information: - Company Email Address · Full Name · Company Name · Company Location (city) · Mailing Address (optional) · Phone Number (optional) · Fax Number (optional) Thanks, Applications Assistant PMC-Sierra, Inc. Ph: (604) 415-4533 Fax: (604) 415-6206 apps@pmc-sierra.com http://www.pmc-sierra.com/ -----Original Message----- From: Ralf Baechle [mailto:ralf@oss.sgi.com] Sent: Wednesday, June 27, 2001 6:50 AM To: Maciej W. Rozycki Cc: linux-mips@fnet.fr; linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved On Mon, Jun 25, 2001 at 01:36:15PM +0200, Maciej W. Rozycki wrote: > After extensive debugging I managed to track down the bug that was > preventing me from building binutils since the beginning of February. > Once again the culprit turned out to the the explicit nature of MIPS' > caches. > > The problem lies in r3k_flush_cache_sigtramp(). It flushes three > consecutive word-wide locations starting from the address passed as an > argument. The argument is normally a sigreturn trampoline that is set up > by setup_frame() or setup_rt_frame(). But these functions set up two > opcodes only -- the third word is left untouched. In my case the address > was something like 0x7???bff8. So the area to be flushed spanned a page > boundary and since the third word was unreferenced, a TLB entry for the > page the word was located in was absent. As a result, a TLB refill > exception happened with caches isolated, which is not necessarily a win. > The symptom was a solid crash. > > I don't see any reason to flush the third word location, so I removed the > code doing it. This fixed the crashes I was observing, but since we are > using mapped (KUSEG) addresses in r3k_flush_cache_sigtramp(), I believe we > need more protection against unwanted TLB exceptions. The point is we are > running with interrupts enabled and a reschedule may happen between > touching the trampoline in setup*_frame() and flushing the cache. Hence > the TLB entries for the trampoline area, even once present, may get > removed meanwhile. So I added some code to explicitly load the entries, > if needed, with interrupts disabled just before isolating caches. > Following is a resulting patch. > > Ralf, this is a showstopper bug -- please apply the fix ASAP. Applied. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 27 14:03:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RL3cv14497 for linux-mips-outgoing; Wed, 27 Jun 2001 14:03:38 -0700 Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RL3cV14492 for ; Wed, 27 Jun 2001 14:03:38 -0700 Received: (qmail 17618 invoked by uid 104); 27 Jun 2001 21:03:33 -0000 Received: from Trina_Littlejohns@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.385938 secs); 27/06/2001 14:03:32 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 27 Jun 2001 21:03:32 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5RL3Ve05889; Wed, 27 Jun 2001 14:03:31 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 14:07:52 -0700 Message-ID: <60474D3886D54F4BAB0CB49A4BB6E8A8837905@bby1exp01> From: Trina Littlejohns To: "'Ralf Baechle'" , "'Maciej W. Rozycki'" Cc: "'linux-mips@fnet.fr'" , "'linux-mips@oss.sgi.com'" Subject: Recall: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved Date: Wed, 27 Jun 2001 14:07:52 -0700 Expiry-Date: Fri, 29 Jun 2001 14:05:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 111 Lines: 1 Trina Littlejohns would like to recall the message, "[patch] 2.4.5 and earlier: Mysterious lock-ups resolved". From owner-linux-mips@oss.sgi.com Wed Jun 27 14:04:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RL49K14623 for linux-mips-outgoing; Wed, 27 Jun 2001 14:04:09 -0700 Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RL48V14614 for ; Wed, 27 Jun 2001 14:04:08 -0700 Received: (qmail 27594 invoked by uid 104); 27 Jun 2001 21:04:02 -0000 Received: from Trina_Littlejohns@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.00018 secs); 27/06/2001 14:04:01 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 27 Jun 2001 21:04:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5RL40e05942; Wed, 27 Jun 2001 14:04:00 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 14:08:21 -0700 Message-ID: <60474D3886D54F4BAB0CB49A4BB6E8A8837906@bby1exp01> From: Trina Littlejohns To: "'Ralf Baechle'" , "'Maciej W. Rozycki'" Cc: "'linux-mips@fnet.fr'" , "'linux-mips@oss.sgi.com'" Subject: RE: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved Date: Wed, 27 Jun 2001 14:08:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5RL48V14619 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2727 Lines: 65 Dear Mr. Baechle, Thank you for your request for support on PMC-Sierra products. In order to serve you better, we require some additional contact information. This information will be used to direct your request to the appropriate factory or field applications engineer, and to help us track your support incident. Could you please reply to me with the following information: - Part Number · Full Name · Company Name · Company Location (city) · Mailing Address (optional) · Phone Number (optional) · Fax Number (optional) Thanks, Applications Assistant PMC-Sierra, Inc. Ph: (604) 415-4533 Fax: (604) 415-6206 apps@pmc-sierra.com http://www.pmc-sierra.com/ -----Original Message----- From: Ralf Baechle [mailto:ralf@oss.sgi.com] Sent: Wednesday, June 27, 2001 6:50 AM To: Maciej W. Rozycki Cc: linux-mips@fnet.fr; linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved On Mon, Jun 25, 2001 at 01:36:15PM +0200, Maciej W. Rozycki wrote: > After extensive debugging I managed to track down the bug that was > preventing me from building binutils since the beginning of February. > Once again the culprit turned out to the the explicit nature of MIPS' > caches. > > The problem lies in r3k_flush_cache_sigtramp(). It flushes three > consecutive word-wide locations starting from the address passed as an > argument. The argument is normally a sigreturn trampoline that is set up > by setup_frame() or setup_rt_frame(). But these functions set up two > opcodes only -- the third word is left untouched. In my case the address > was something like 0x7???bff8. So the area to be flushed spanned a page > boundary and since the third word was unreferenced, a TLB entry for the > page the word was located in was absent. As a result, a TLB refill > exception happened with caches isolated, which is not necessarily a win. > The symptom was a solid crash. > > I don't see any reason to flush the third word location, so I removed the > code doing it. This fixed the crashes I was observing, but since we are > using mapped (KUSEG) addresses in r3k_flush_cache_sigtramp(), I believe we > need more protection against unwanted TLB exceptions. The point is we are > running with interrupts enabled and a reschedule may happen between > touching the trampoline in setup*_frame() and flushing the cache. Hence > the TLB entries for the trampoline area, even once present, may get > removed meanwhile. So I added some code to explicitly load the entries, > if needed, with interrupts disabled just before isolating caches. > Following is a resulting patch. > > Ralf, this is a showstopper bug -- please apply the fix ASAP. Applied. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 27 17:57:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S0vVX18305 for linux-mips-outgoing; Wed, 27 Jun 2001 17:57:31 -0700 Received: from dea.waldorf-gmbh.de (u-51-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S0vOV18284 for ; Wed, 27 Jun 2001 17:57:24 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5S0vK002713 for linux-mips@oss.sgi.com; Thu, 28 Jun 2001 02:57:20 +0200 Date: Thu, 28 Jun 2001 02:06:04 +0200 From: Ralf Baechle To: Trina Littlejohns Cc: "'Maciej W. Rozycki'" , "'linux-mips@fnet.fr'" , "'linux-mips@oss.sgi.com'" Subject: Re: Recall: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved Message-ID: <20010628020604.D1242@bacchus.dhis.org> References: <60474D3886D54F4BAB0CB49A4BB6E8A8837905@bby1exp01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <60474D3886D54F4BAB0CB49A4BB6E8A8837905@bby1exp01>; from Trina_Littlejohns@pmc-sierra.com on Wed, Jun 27, 2001 at 11:03:43PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 411 Lines: 10 On Wed, Jun 27, 2001 at 11:03:43PM +0200, Trina Littlejohns wrote: > Subject: Recall: [patch] 2.4.5 and earlier: Mysterious lock-ups resolved > > Trina Littlejohns would like to recall the message, "[patch] 2.4.5 and earlier: Mysterious lock-ups resolved". Sent is sent. Attempting to recall produces additional noise. Anyway, I've now configured oss to bitbucket this kind of mail just like spam. Ralf From owner-linux-mips@oss.sgi.com Thu Jun 28 01:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S835203754 for linux-mips-outgoing; Thu, 28 Jun 2001 01:03:05 -0700 Received: from dsic.co.kr ([210.221.126.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S82wV03736 for ; Thu, 28 Jun 2001 01:02:59 -0700 Received: from astonlinux.com [192.168.2.173] by dsic.co.kr [210.221.126.1] with SMTP (MDaemon.v3.5.6.R) for ; Thu, 28 Jun 2001 17:01:05 +0900 Message-ID: <3B3B9C29.6898DC59@astonlinux.com> Date: Thu, 28 Jun 2001 17:05:45 -0400 From: =?EUC-KR?B?sK29xbHU?= Organization: astonlinux X-Mailer: Mozilla 4.75 [ko] (X11; U; Linux 2.2.16-21hl i686) X-Accept-Language: ko MIME-Version: 1.0 To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Help me. Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-MDRemoteIP: 192.168.2.173 X-Return-Path: cosmos@astonlinux.com X-MDaemon-Deliver-To: linux-mips@oss.sgi.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10596 Lines: 348 Hi, my name is Shinkyu Kang. I am trying to port a linux 2.4 to R3000 based system (LSI LOGIC SC2000). SC2000 have caches. one is Two-way set associative or direct mapped Instruction cache (16K) and another is Direct-mapped data cache(8K). The following show the contents of each RAM(data and tag) cache. - I-Cache Set 0 or D-Cache Data Ram 31-24(bit) : byte 3 23-16 : byte 2 15-8 : byte 1 7-0 : byte 0 - I-Cache Set 0 or D-Cache Tag Ram 23-5 : Cache Tag ID 4 : Cache Lock bit 3 : High word valid bit 2 : Third word valid bit 1 : Second word valid bit 0 : Low word valid bit - I-Cache Set 1 Data Ram 31-0 : Instruction - I-Cache Set 1 Tag Ram 22-4 : Cache Tag ID 3 : High word valid bit 2 : Third word valid bit 1 : Second word valid bit 0 : Low word valid bit SC2000 have a BBCC(Basic BIU and Cache Controller) Configuration Register like following : 31(bit) : MMU enable -> setting this bit enables the full memory management unit(MMU). 30 : Write buffer enable -> setting this bit enables the write buffer. 29-14 : reserved 13: Data error - the BBCC sets this bit when a bus error ouccurs duringa data load/store. Clearing this bit acknowledges the error. 12-10 : Page Size -> These bits inform the BBCC of the page size so that the BBCC can determine if stores are burst write transactions; in otherwords, if they are consecutive stores to the same page. --------------- ps page size 0b000 16 words 0b001 32 words 0b010 64 words 0b011 128 words 0b100 256 words 0b101 512 words 0b110 1024 words 0b111 2048 words ---------------- 9-8 : Cache Mode -> These bits determine the Cache mode. CM Cache Mode ------------------ 0b00 Nomal 0b01 I-Cache Software Test (Data Ram) 0b10 I-Cache Software Test(Tag Ram) 0b11 D-Cache Software Test(Tag Ram) ------------------- 7 : Read Priority Enable -> Setting this bit causes the BBCC to assign higher priority to loads over stores, whenever possible. 6-5 : D-Cache Block Refill Size -> These bits specify the D-cache block refill size DRS Refill Size ------------------- 0b00 1 word 0b01 2 words 0b10 4 words 0b11 8 words ------------------- 4 : D-Cache Enable -> setting this bit enable the D-cache 3-2 : I-Cache Block Refill Size -> these bits specifiy the I-cache block refill size. ------------------- 0b00 1 word 0b01 2 words 0b10 4 words 0b11 8 words ------------------- 1 : I-Cache Set 1 Enable -> setting this bit enables the I-cache Set 1. 0 : I-Cache Enable -> setting this bit enables the I-cache. ---------------------------------------------------------------------------- I modify the r2300.c and add a new file (lsi-cache.S) like following : -------------------r2300.c------------------------------- static void r3k_flush_icache_range(unsigned long start, unsigned long end) { flush_icache(); } void __init ld_mmu_r23000(void) { unsigned long config; printk("CPU revision is: %08x\n", read_32bit_cp0_register(CP0_PRID)); _clear_page = r3k_clear_page; _copy_page = r3k_copy_page; r3k_probe_cache(); _flush_cache_all = r3k_flush_cache_all; ___flush_cache_all = r3k_flush_cache_all; _flush_cache_mm = r3k_flush_cache_mm; _flush_cache_range = r3k_flush_cache_range; _flush_cache_page = r3k_flush_cache_page; _flush_cache_sigtramp = r3k_flush_cache_sigtramp; _flush_page_to_ram = r3k_flush_page_to_ram; _flush_icache_page = r3k_flush_icache_page; _flush_icache_range = r3k_flush_icache_range; _dma_cache_wback_inv = r3k_dma_cache_wback_inv; printk("Primary instruction cache %dkb, linesize %d bytes\n", (int) (icache_size >> 10), (int) icache_lsize); printk("Primary data cache %dkb, linesize %d bytes\n", (int) (dcache_size >> 10), (int) dcache_lsize); flush_tlb_all(); } ---------------lsi-cache.S-------------------------------- /* void flush_icache(void) */ LEAF(flush_icache) .set noreorder la a3, icache_size # 8Kbyte lw t4, 0(a3) mfc0 t7, CP0_STATUS # save SR nop nop and t0, t7, ~ST0_IEC # disable interrupts mtc0 t0, CP0_STATUS nop nop li t3, CBSYS # BBCC configuration register lw t8, 0(t3) # save config. register nop li t0, KSEG0 or t4, t4, t0 # end of I-cache move t5, t0 2: la t0, 3f # switch to Kseg1 or t0, KSEG1 jr t0 nop # # flush I-cache set 0 # 3: li t0, (CFG_DCEN | CFG_ICEN) or t0, CFG_CMODE_ITEST # I-cache set1 enable # D-cache enable, I-cache set0 enable # I-cache software test sw t0, 0(t3) lw zero, 0(t3) addi zero, zero, 1 move t0, t5 4: sw zero, (t0) nop lw zero, (t0) addu t0, t6 bltu t0, t4, 4b nop # # flush I-cache set 1 # li t0, (CFG_DCEN | CFG_ICEN | CFG_IS1EN) or t0, CFG_CMODE_ITEST # I-cache set1 enable # D-cache enable, I-cache set0 enable # I-cache software test sw t0, 0(t3) lw zero, 0(t3) addi zero, zero, 1 move t0, t5 5: sw zero, (t0) nop lw zero, (t0) addu t0, t6 bltu t0, t4, 5b # # restore status and config. register # sw t8, 0(t3) # restore config. register lw zero, 0(t3) addi zero, zero, 1 mtc0 t7, CP0_STATUS # restore SR nop nop j ra nop .set reorder END(flush_icache) nop ----------------------------------------------------------------------- The default setting of CBSYS register is 0xC0000013 (MMU on, Write buffer on, I, D-Cache on, I cache set 1 on) -----Question.------------ When I turn off I, D-cache, bash or sash is doing well. but when I turn on the cache, kernel die during sash or bash is up. 1. Is there more file to modified in kernel ? 2. Here is a booting message when caches are off. Starting kernel ... command line: root=/dev/ram Loading R[23]000 MMU routines. CPU Revision Number is: 00002597 Primary instruction cache 8kb, linesize 16 bytes Primary data cache 8kb, linesize 16 bytes Linux version 2.4.3 (root@localhost.localdomain) (gcc version 3.0 20010422 (prerelease)) #442 ¸ñ 6¿ù 28 16 :42:17 EDT 2001 Determined physical RAM map: memory: 01000000 @ 00000000 (usable) Initial ramdisk at: 0x800f6000 (2214364 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram sc2000 timer init... Calibrating delay loop... 6.63 BogoMIPS Memory: 12836k/16384k available (859k kernel code, 3548k reserved, 2226k data, 56k init) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 initialize_kbd: Keyboard failed self test block: queued sectors max/low 8456kB/2818kB, 64 slots per queue keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize RAMDISK: Compressed image found at block 0 Freeing initrd memory: 2162k freed loop: loaded (max 8 devices) Serial driver version 1.00 (2001-02-27) ttyS00 at 0x0000 (irq = 0) is a LSI UART VFS: Mounted root (ext2 filesystem). Freeing prom memory: 0kb freed Freeing unused kernel memory: 56k freed start padzero start new_pc : 400150, new_sp : 7fff7f80 end end Algorithmics/MIPS FPU Emulator v1.4 Stand-alone shell (version 3.4) > ---------------------------------------------- Here is a booting message when cache on. Starting kernel ... command line: root=/dev/ram Loading R[23]000 MMU routines. CPU Revision Number is: 00002597 Primary instruction cache 8kb, linesize 16 bytes Primary data cache 8kb, linesize 16 bytes Linux version 2.4.3 (root@localhost.localdomain) (gcc version 3.0 20010422 (prerelease)) #442 ¸ñ 6¿ù 28 16 :42:17 EDT 2001 Determined physical RAM map: memory: 01000000 @ 00000000 (usable) Initial ramdisk at: 0x800f6000 (2214364 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram sc2000 timer init... Calibrating delay loop... 107.72 BogoMIPS Memory: 12836k/16384k available (859k kernel code, 3548k reserved, 2226k data, 56k init) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 initialize_kbd: Keyboard failed self test block: queued sectors max/low 8456kB/2818kB, 64 slots per queue keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize RAMDISK: Compressed image found at block 0 Freeing initrd memory: 2162k freed loop: loaded (max 8 devices) Serial driver version 1.00 (2001-02-27) ttyS00 at 0x0000 (irq = 0) is a LSI UART VFS: Mounted root (ext2 filesystem). Freeing prom memory: 0kb freed Freeing unused kernel memory: 56k freed start padzero start new_pc : 400150, new_sp : 7fff7f80 ----------------------------------------------------------------- Please tell me what can I do? ----------------------------------------------------------------- Best Regards Shinkyu. From owner-linux-mips@oss.sgi.com Thu Jun 28 07:32:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SEWwK30223 for linux-mips-outgoing; Thu, 28 Jun 2001 07:32:58 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SEWuV30219 for ; Thu, 28 Jun 2001 07:32:56 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id QAA40198 for ; Thu, 28 Jun 2001 16:32:51 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Fcqh-00016p-00 for ; Thu, 28 Jun 2001 16:32:51 +0200 Date: Thu, 28 Jun 2001 16:32:51 +0200 To: linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips Message-ID: <20010628163250.D28583@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16633.993608517@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1997 Lines: 65 Keith Owens wrote: [snip] > >The best option is for a mips64 kernel to indicate that it is 64 bit > >and its endianess. Instead of printing > > > > "epc : %016lx\n" > > > >print > > > > "epc : %016lx (64 " > >#ifdef __MIPSEL__ > > "LSB" > >#else > > "MSB" > >#endif > > ")\n" > > I have a new ksymoops release coming up. Is it OK if I include code to > look for (64 LSB) and (64 MSB) in the oops and decode accordingly. I > don't expect the kernel to produce this output immediately, I just want > agreement on the format that will be produced. The appended patch introduces the new format in mips64. Maybe this speeds up agreement about it. :-) Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/andes.c linux/arch/mips64/mm/andes.c --- linux-orig/arch/mips64/mm/andes.c Sat May 26 00:25:39 2001 +++ linux/arch/mips64/mm/andes.c Thu Jun 28 15:19:32 2001 @@ -332,7 +381,13 @@ printk("Lo : %016lx\n", regs->lo); /* Saved cp0 registers. */ - printk("epc : %016lx\nbadvaddr: %016lx\n", + printk("epc : %016lx (64 " +#ifdef __MIPSEL__ + "LSB" +#else + "MSB" +#endif + ")\nbadvaddr: %016lx\n", regs->cp0_epc, regs->cp0_badvaddr); printk("Status : %08x\nCause : %08x\n", (unsigned int) regs->cp0_status, (unsigned int) regs->cp0_cause); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/r4xx0.c linux/arch/mips64/mm/r4xx0.c --- linux-orig/arch/mips64/mm/r4xx0.c Thu Mar 29 17:11:46 2001 +++ linux/arch/mips64/mm/r4xx0.c Thu Jun 28 14:51:20 2001 @@ -2125,7 +2118,13 @@ printk("Lo : %016lx\n", regs->lo); /* Saved cp0 registers. */ - printk("epc : %016lx\nbadvaddr: %016lx\n", + printk("epc : %016lx (64 " +#ifdef __MIPSEL__ + "LSB" +#else + "MSB" +#endif + ")\nbadvaddr: %016lx\n", regs->cp0_epc, regs->cp0_badvaddr); printk("Status : %08x\nCause : %08x\n", (unsigned int) regs->cp0_status, (unsigned int) regs->cp0_cause); From owner-linux-mips@oss.sgi.com Thu Jun 28 07:56:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SEu7731644 for linux-mips-outgoing; Thu, 28 Jun 2001 07:56:07 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SEu2V31627 for ; Thu, 28 Jun 2001 07:56:02 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id QAA40439 for ; Thu, 28 Jun 2001 16:56:01 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15FdD3-00017Z-00 for ; Thu, 28 Jun 2001 16:55:57 +0200 Date: Thu, 28 Jun 2001 16:55:57 +0200 To: linux-mips@oss.sgi.com Subject: Re: [PATCH] Make sgiseeq.c 64bit ready (was: CVS Update@oss.sgi.com: linux) Message-ID: <20010628165557.E28583@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010625005856.C388@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11425 Lines: 324 Thiemo Seufer wrote: [snip] > This patch makes (as the original) the assumption that > sizeof(void *) == 4, so it will work for 32bit only. > > My seemingly working code for mips64 is appeded as patch against > current CVS. And since I've overlooked the changed vaddr type it didn't work any more. The updated patch below reverts this and adds proper alignment to the DMA descriptor definition in mips64. Note1: CONFIG_SGI_IP28 reads as "has real 64bit address space", it's currently defined nowhere in CVS tree. Note2: SGI_KEYBOARD_IRQ in sgihpc.h is never used anywhere. Thiemo > diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/net/sgiseeq.c linux/drivers/net/sgiseeq.c > --- linux-orig/drivers/net/sgiseeq.c Sun Jun 24 19:55:01 2001 > +++ linux/drivers/net/sgiseeq.c Sun Jun 24 22:34:11 2001 > @@ -1,5 +1,4 @@ > -/* $Id: sgiseeq.c,v 1.17 2000/03/27 23:02:57 ralf Exp $ > - * > +/* > * sgiseeq.c: Seeq8003 ethernet driver for SGI machines. > * > * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) > @@ -67,7 +66,7 @@ > sp->tx_old + (SEEQ_TX_BUFFERS - 1) - sp->tx_new : \ > sp->tx_old - sp->tx_new - 1) > > -#define DEBUG > +/* #define DEBUG */ > > struct sgiseeq_rx_desc { > struct hpc_dma_desc rdma; > @@ -79,19 +78,24 @@ > signed int buf_vaddr; > }; > > -/* Warning: This structure is layed out in a certain way because > - * HPC dma descriptors must be 8-byte aligned. So don't > - * touch this without some care. > +/* Warning: This structure is layed out in a certain way because HPC dma > + * descriptors must be 8-byte aligned. So don't touch this without > + * some care. > + * The spec states 16-byte alignment is needed, so I changed the > + * padding and aligned the whole struct accordingly. --THS > */ > struct sgiseeq_init_block { /* Note the name ;-) */ > - /* Ptrs to the descriptors in KSEG1 uncached space. */ > + /* Ptrs to the descriptors in KSEG1 or XKPHYS uncached space. */ > struct sgiseeq_rx_desc *rx_desc; > struct sgiseeq_tx_desc *tx_desc; > - unsigned int _padding[30]; /* Pad out to largest cache line size. */ > + /* Pad out to largest cache line size (64 byte with 32bit, 128 byte > + * with 64bit pointers). > + */ > + char _padding[14 * sizeof(void *)]; > > struct sgiseeq_rx_desc rxvector[SEEQ_RX_BUFFERS]; > struct sgiseeq_tx_desc txvector[SEEQ_TX_BUFFERS]; > -}; > +} __attribute__((aligned(16))); > > struct sgiseeq_private { > volatile struct sgiseeq_init_block srings; > @@ -149,6 +153,12 @@ > #define RCNTCFG_INIT (HPCDMA_OWN | HPCDMA_EORP | HPCDMA_XIE) > #define RCNTINFO_INIT (RCNTCFG_INIT | (PKT_BUF_SZ & HPCDMA_BCNT)) > > +#ifdef CONFIG_SGI_IP28 > +#define THIS_K1ADDR K1ADDR > +#else > +#define THIS_K1ADDR KSEG1ADDR > +#endif > + > static int seeq_init_ring(struct net_device *dev) > { > struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv; > @@ -172,12 +182,12 @@ > if(!ib->tx_desc[i].tdma.pbuf) { > unsigned long buffer; > > - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); > + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, > + GFP_KERNEL | GFP_DMA); > if (!buffer) > return -ENOMEM; > - ib->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer); > + ib->tx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); > ib->tx_desc[i].tdma.pbuf = PHYSADDR(buffer); > -// flush_cache_all(); > } > ib->tx_desc[i].tdma.cntinfo = (TCNTINFO_INIT); > } > @@ -187,12 +197,12 @@ > if (!ib->rx_desc[i].rdma.pbuf) { > unsigned long buffer; > > - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); > + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, > + GFP_KERNEL | GFP_DMA); > if (!buffer) > return -ENOMEM; > - ib->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer); > + ib->rx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); > ib->rx_desc[i].rdma.pbuf = PHYSADDR(buffer); > -// flush_cache_all(); > } > ib->rx_desc[i].rdma.cntinfo = (RCNTINFO_INIT); > } > @@ -300,10 +310,6 @@ > } > } > > -#define for_each_rx(rd, sp) for((rd) = &(sp)->srings.rx_desc[(sp)->rx_new]; \ > - !((rd)->rdma.cntinfo & HPCDMA_OWN); \ > - (rd) = &(sp)->srings.rx_desc[(sp)->rx_new]) > - > static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp, > volatile struct hpc3_ethregs *hregs, > volatile struct sgiseeq_regs *sregs) > @@ -316,7 +322,9 @@ > unsigned int orig_end = PREV_RX(sp->rx_new); > > /* Service every received packet. */ > - for_each_rx(rd, sp) { > + for(rd = &sp->srings.rx_desc[sp->rx_new]; > + !(rd->rdma.cntinfo & HPCDMA_OWN); > + rd = &sp->srings.rx_desc[sp->rx_new]) { > len = (PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3); > pkt_pointer = (unsigned char *)(long)rd->buf_vaddr; > pkt_status = pkt_pointer[len + 2]; > @@ -338,7 +346,7 @@ > sp->stats.rx_packets++; > sp->stats.rx_bytes += len; > } else { > - printk ("%s: Memory squeeze, deferring packet.\n", > + printk("%s: Memory squeeze, deferring packet.\n", > dev->name); > sp->stats.rx_dropped++; > } > @@ -370,12 +378,12 @@ > /* If the HPC aint doin nothin, and there are more packets > * with ETXD cleared and XIU set we must make very certain > * that we restart the HPC else we risk locking up the > - * adapter. The following code is only safe iff the HPCDMA > + * adapter. The following code is only safe if the HPCDMA > * is not active! > */ > while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == > (HPCDMA_XIU | HPCDMA_ETXD)) > - td = (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext); > + td = (struct sgiseeq_tx_desc *)THIS_K1ADDR(td->tdma.pnext); > if (td->tdma.cntinfo & HPCDMA_XIU) { > hregs->tx_ndptr = PHYSADDR(td); > hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; > @@ -435,7 +443,7 @@ > /* Always check for received packets. */ > sgiseeq_rx(dev, sp, hregs, sregs); > > - /* Only check for tx acks iff we have something queued. */ > + /* Only check for tx acks if we have something queued. */ > if (sp->tx_old != sp->tx_new) > sgiseeq_tx(dev, sp, hregs, sregs); > > @@ -497,11 +505,13 @@ > return 0; > } > > +#ifdef DEBUG > void sgiseeq_my_reset(void) > { > printk("RESET!\n"); > sgiseeq_reset(gdev); > } > +#endif > > static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) > { > @@ -528,7 +538,7 @@ > * we have completely set up it's state. This means, do > * not clear HPCDMA_EOX in the current last descritptor > * until the one we are adding looks consistant and could > - * be processes right now. > + * be processed right now. > * 3) The tx interrupt code must notice when we've added a new > * entry and the HPC got to the end of the chain before we > * added this new entry and restarted it. > @@ -584,7 +594,6 @@ > > while (i < (nbufs - 1)) { > buf[i].tdma.pnext = PHYSADDR(&buf[i + 1]); > - buf[i].tdma.pbuf = 0; > i++; > } > buf[i].tdma.pnext = PHYSADDR(&buf[0]); > @@ -596,25 +605,22 @@ > > while (i < (nbufs - 1)) { > buf[i].rdma.pnext = PHYSADDR(&buf[i + 1]); > - buf[i].rdma.pbuf = 0; > i++; > } > - buf[i].rdma.pbuf = 0; > buf[i].rdma.pnext = PHYSADDR(&buf[0]); > } > > static char onboard_eth_addr[6]; > > -#define ALIGNED(x) ((((unsigned long)(x)) + 0xf) & ~(0xf)) > - > -int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, > - struct hpc3_ethregs *hregs, int irq) > +static int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, > + struct hpc3_ethregs *hregs, int irq) > { > static unsigned version_printed; > int i; > struct sgiseeq_private *sp; > > - dev->priv = (struct sgiseeq_private *) get_free_page(GFP_KERNEL); > + dev->priv = (struct sgiseeq_private *) > + get_zeroed_page(GFP_KERNEL | GFP_DMA); > if (dev->priv == NULL) > return -ENOMEM; > > @@ -635,17 +641,16 @@ > gpriv = sp; > gdev = dev; > #endif > - memset((char *)dev->priv, 0, sizeof(struct sgiseeq_private)); > sp->sregs = sregs; > sp->hregs = hregs; > sp->name = sgiseeqstr; > > sp->srings.rx_desc = (struct sgiseeq_rx_desc *) > - (KSEG1ADDR(ALIGNED(&sp->srings.rxvector[0]))); > + (THIS_K1ADDR(&sp->srings.rxvector[0])); > dma_cache_wback_inv((unsigned long)&sp->srings.rxvector, > sizeof(sp->srings.rxvector)); > sp->srings.tx_desc = (struct sgiseeq_tx_desc *) > - (KSEG1ADDR(ALIGNED(&sp->srings.txvector[0]))); > + (THIS_K1ADDR(&sp->srings.txvector[0])); > dma_cache_wback_inv((unsigned long)&sp->srings.txvector, > sizeof(sp->srings.txvector)); > > @@ -677,6 +682,8 @@ > return 0; > } > > +#undef THIS_K1ADDR > + > static inline unsigned char str2hexnum(unsigned char c) > { > if (c >= '0' && c <= '9') > @@ -712,7 +719,6 @@ > > /* First get the ethernet address of the onboard interface from ARCS. > * This is fragile; PROM doesn't like running from cache. > - * On MIPS64 it crashes for some other, yet unknown reason ... > */ > ep = ArcGetEnvironmentVariable("eaddr"); > str2eaddr(onboard_eth_addr, ep); > diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/addrspace.h linux/include/asm-mips64/addrspace.h > --- linux-orig/include/asm-mips64/addrspace.h Thu Oct 26 03:18:01 2000 > +++ linux/include/asm-mips64/addrspace.h Sun Jun 24 22:09:29 2001 > @@ -1,5 +1,4 @@ > -/* $Id: addrspace.h,v 1.5 2000/02/01 00:32:01 kanoj Exp $ > - * > +/* > * This file is subject to the terms and conditions of the GNU General Public > * License. See the file "COPYING" in the main directory of this archive > * for more details. > @@ -104,9 +103,13 @@ > #endif > #define K2BASE 0xc000000000000000 > > +#define K0ADDR(x) (PHYSADDR(x) | K0BASE) > +#define K1ADDR(x) (PHYSADDR(x) | K1BASE) > +#define K2ADDR(x) (PHYSADDR(x) | K2BASE) > + > #if !defined (CONFIG_CPU_R8000) > -#define COMPAT_K1BASE32 0xffffffffa0000000 > -#define PHYS_TO_COMPATK1(x) ((x) | COMPAT_K1BASE32) /* 32-bit compat k1 */ > +#define COMPAT_K1BASE32 0xffffffffa0000000 /* 32-bit compat k1 */ > +#define PHYS_TO_COMPATK1(x) ((unsigned long)(x) | COMPAT_K1BASE32) > #endif > > #define KDM_TO_PHYS(x) ((unsigned long)(x) & TO_PHYS_MASK) > diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgihpc.h linux/include/asm-mips64/sgi/sgihpc.h > --- linux-orig/include/asm-mips64/sgi/sgihpc.h Sat Dec 4 04:59:13 1999 > +++ linux/include/asm-mips64/sgi/sgihpc.h Sun Jun 24 23:20:21 2001 > @@ -1,5 +1,4 @@ > -/* $Id: sgihpc.h,v 1.2 1999/10/19 20:51:54 ralf Exp $ > - * > +/* > * This file is subject to the terms and conditions of the GNU General Public > * License. See the file "COPYING" in the main directory of this archive > * for more details. > @@ -36,7 +35,8 @@ > #define HPCDMA_BCNT 0x00003fff /* size in bytes of this dma buffer */ > > int pnext; /* paddr of next hpc_dma_desc if any */ > -}; > + int _padding; /* pad to quad word size */ > +} __attribute__((aligned(16))); > > typedef volatile unsigned int hpcreg; > > @@ -333,8 +333,6 @@ > > /* We need software copies of these because they are write only. */ > extern unsigned int sgi_hpc_write1, sgi_hpc_write2; > - > -#define SGI_KEYBOARD_IRQ 20 > > struct hpc_keyb { > #ifdef __MIPSEB__ From owner-linux-mips@oss.sgi.com Thu Jun 28 08:05:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SF56032318 for linux-mips-outgoing; Thu, 28 Jun 2001 08:05:06 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SF52V32314 for ; Thu, 28 Jun 2001 08:05:02 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id RAA40435 for ; Thu, 28 Jun 2001 17:05:01 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15FdLo-0001A0-00 for ; Thu, 28 Jun 2001 17:05:00 +0200 Date: Thu, 28 Jun 2001 17:05:00 +0200 To: linux-mips@oss.sgi.com Subject: Re: [PATCH] Make sgiseeq.c 64bit ready (was: CVS Update@oss.sgi.com: linux) Message-ID: <20010628170500.F28583@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010628165557.E28583@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 11051 Lines: 333 Thiemo Seufer wrote: > Thiemo Seufer wrote: > [snip] > > This patch makes (as the original) the assumption that > > sizeof(void *) == 4, so it will work for 32bit only. > > > > My seemingly working code for mips64 is appeded as patch against > > current CVS. > > And since I've overlooked the changed vaddr type it didn't work > any more. The updated patch below reverts this and adds proper > alignment to the DMA descriptor definition in mips64. > > Note1: CONFIG_SGI_IP28 reads as "has real 64bit address space", > it's currently defined nowhere in CVS tree. > > Note2: SGI_KEYBOARD_IRQ in sgihpc.h is never used anywhere. And I'm an idiot and sent an old patch as update. Next try... Thiemo diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/drivers/net/sgiseeq.c linux/drivers/net/sgiseeq.c --- linux-orig/drivers/net/sgiseeq.c Sun Jun 24 19:55:01 2001 +++ linux/drivers/net/sgiseeq.c Thu Jun 28 13:56:24 2001 @@ -1,5 +1,4 @@ -/* $Id: sgiseeq.c,v 1.17 2000/03/27 23:02:57 ralf Exp $ - * +/* * sgiseeq.c: Seeq8003 ethernet driver for SGI machines. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) @@ -67,31 +66,36 @@ sp->tx_old + (SEEQ_TX_BUFFERS - 1) - sp->tx_new : \ sp->tx_old - sp->tx_new - 1) -#define DEBUG +/* #define DEBUG */ struct sgiseeq_rx_desc { struct hpc_dma_desc rdma; - signed int buf_vaddr; + signed long buf_vaddr; }; struct sgiseeq_tx_desc { struct hpc_dma_desc tdma; - signed int buf_vaddr; + signed long buf_vaddr; }; -/* Warning: This structure is layed out in a certain way because - * HPC dma descriptors must be 8-byte aligned. So don't - * touch this without some care. +/* Warning: This structure is layed out in a certain way because HPC dma + * descriptors must be 8-byte aligned. So don't touch this without + * some care. + * The spec states 16-byte alignment is needed, so I changed the + * padding and aligned the whole struct accordingly. --THS */ struct sgiseeq_init_block { /* Note the name ;-) */ - /* Ptrs to the descriptors in KSEG1 uncached space. */ + /* Ptrs to the descriptors in KSEG1 or XKPHYS uncached space. */ struct sgiseeq_rx_desc *rx_desc; struct sgiseeq_tx_desc *tx_desc; - unsigned int _padding[30]; /* Pad out to largest cache line size. */ + /* Pad out to largest cache line size (64 byte with 32bit, 128 byte + * with 64bit pointers). + */ + char _padding[14 * sizeof(void *)]; struct sgiseeq_rx_desc rxvector[SEEQ_RX_BUFFERS]; struct sgiseeq_tx_desc txvector[SEEQ_TX_BUFFERS]; -}; +} __attribute__((aligned(16))); struct sgiseeq_private { volatile struct sgiseeq_init_block srings; @@ -149,6 +153,12 @@ #define RCNTCFG_INIT (HPCDMA_OWN | HPCDMA_EORP | HPCDMA_XIE) #define RCNTINFO_INIT (RCNTCFG_INIT | (PKT_BUF_SZ & HPCDMA_BCNT)) +#ifdef CONFIG_SGI_IP28 +#define THIS_K1ADDR K1ADDR +#else +#define THIS_K1ADDR KSEG1ADDR +#endif + static int seeq_init_ring(struct net_device *dev) { struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv; @@ -172,12 +182,12 @@ if(!ib->tx_desc[i].tdma.pbuf) { unsigned long buffer; - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, + GFP_KERNEL | GFP_DMA); if (!buffer) return -ENOMEM; - ib->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + ib->tx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); ib->tx_desc[i].tdma.pbuf = PHYSADDR(buffer); -// flush_cache_all(); } ib->tx_desc[i].tdma.cntinfo = (TCNTINFO_INIT); } @@ -187,12 +197,12 @@ if (!ib->rx_desc[i].rdma.pbuf) { unsigned long buffer; - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); + buffer = (unsigned long)kmalloc(PKT_BUF_SZ, + GFP_KERNEL | GFP_DMA); if (!buffer) return -ENOMEM; - ib->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + ib->rx_desc[i].buf_vaddr = THIS_K1ADDR(buffer); ib->rx_desc[i].rdma.pbuf = PHYSADDR(buffer); -// flush_cache_all(); } ib->rx_desc[i].rdma.cntinfo = (RCNTINFO_INIT); } @@ -300,10 +310,6 @@ } } -#define for_each_rx(rd, sp) for((rd) = &(sp)->srings.rx_desc[(sp)->rx_new]; \ - !((rd)->rdma.cntinfo & HPCDMA_OWN); \ - (rd) = &(sp)->srings.rx_desc[(sp)->rx_new]) - static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp, volatile struct hpc3_ethregs *hregs, volatile struct sgiseeq_regs *sregs) @@ -316,7 +322,9 @@ unsigned int orig_end = PREV_RX(sp->rx_new); /* Service every received packet. */ - for_each_rx(rd, sp) { + for(rd = &sp->srings.rx_desc[sp->rx_new]; + !(rd->rdma.cntinfo & HPCDMA_OWN); + rd = &sp->srings.rx_desc[sp->rx_new]) { len = (PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3); pkt_pointer = (unsigned char *)(long)rd->buf_vaddr; pkt_status = pkt_pointer[len + 2]; @@ -338,7 +346,7 @@ sp->stats.rx_packets++; sp->stats.rx_bytes += len; } else { - printk ("%s: Memory squeeze, deferring packet.\n", + printk("%s: Memory squeeze, deferring packet.\n", dev->name); sp->stats.rx_dropped++; } @@ -370,12 +378,12 @@ /* If the HPC aint doin nothin, and there are more packets * with ETXD cleared and XIU set we must make very certain * that we restart the HPC else we risk locking up the - * adapter. The following code is only safe iff the HPCDMA + * adapter. The following code is only safe if the HPCDMA * is not active! */ while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == (HPCDMA_XIU | HPCDMA_ETXD)) - td = (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext); + td = (struct sgiseeq_tx_desc *)THIS_K1ADDR(td->tdma.pnext); if (td->tdma.cntinfo & HPCDMA_XIU) { hregs->tx_ndptr = PHYSADDR(td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; @@ -435,7 +443,7 @@ /* Always check for received packets. */ sgiseeq_rx(dev, sp, hregs, sregs); - /* Only check for tx acks iff we have something queued. */ + /* Only check for tx acks if we have something queued. */ if (sp->tx_old != sp->tx_new) sgiseeq_tx(dev, sp, hregs, sregs); @@ -497,11 +505,13 @@ return 0; } +#ifdef DEBUG void sgiseeq_my_reset(void) { printk("RESET!\n"); sgiseeq_reset(gdev); } +#endif static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) { @@ -528,7 +538,7 @@ * we have completely set up it's state. This means, do * not clear HPCDMA_EOX in the current last descritptor * until the one we are adding looks consistant and could - * be processes right now. + * be processed right now. * 3) The tx interrupt code must notice when we've added a new * entry and the HPC got to the end of the chain before we * added this new entry and restarted it. @@ -584,7 +594,6 @@ while (i < (nbufs - 1)) { buf[i].tdma.pnext = PHYSADDR(&buf[i + 1]); - buf[i].tdma.pbuf = 0; i++; } buf[i].tdma.pnext = PHYSADDR(&buf[0]); @@ -596,25 +605,22 @@ while (i < (nbufs - 1)) { buf[i].rdma.pnext = PHYSADDR(&buf[i + 1]); - buf[i].rdma.pbuf = 0; i++; } - buf[i].rdma.pbuf = 0; buf[i].rdma.pnext = PHYSADDR(&buf[0]); } static char onboard_eth_addr[6]; -#define ALIGNED(x) ((((unsigned long)(x)) + 0xf) & ~(0xf)) - -int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, - struct hpc3_ethregs *hregs, int irq) +static int sgiseeq_init(struct net_device *dev, struct sgiseeq_regs *sregs, + struct hpc3_ethregs *hregs, int irq) { static unsigned version_printed; int i; struct sgiseeq_private *sp; - dev->priv = (struct sgiseeq_private *) get_free_page(GFP_KERNEL); + dev->priv = (struct sgiseeq_private *) + get_zeroed_page(GFP_KERNEL | GFP_DMA); if (dev->priv == NULL) return -ENOMEM; @@ -635,17 +641,16 @@ gpriv = sp; gdev = dev; #endif - memset((char *)dev->priv, 0, sizeof(struct sgiseeq_private)); sp->sregs = sregs; sp->hregs = hregs; sp->name = sgiseeqstr; sp->srings.rx_desc = (struct sgiseeq_rx_desc *) - (KSEG1ADDR(ALIGNED(&sp->srings.rxvector[0]))); + (THIS_K1ADDR(&sp->srings.rxvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings.rxvector, sizeof(sp->srings.rxvector)); sp->srings.tx_desc = (struct sgiseeq_tx_desc *) - (KSEG1ADDR(ALIGNED(&sp->srings.txvector[0]))); + (THIS_K1ADDR(&sp->srings.txvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings.txvector, sizeof(sp->srings.txvector)); @@ -677,6 +682,8 @@ return 0; } +#undef THIS_K1ADDR + static inline unsigned char str2hexnum(unsigned char c) { if (c >= '0' && c <= '9') @@ -712,7 +719,6 @@ /* First get the ethernet address of the onboard interface from ARCS. * This is fragile; PROM doesn't like running from cache. - * On MIPS64 it crashes for some other, yet unknown reason ... */ ep = ArcGetEnvironmentVariable("eaddr"); str2eaddr(onboard_eth_addr, ep); diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/addrspace.h linux/include/asm-mips64/addrspace.h --- linux-orig/include/asm-mips64/addrspace.h Thu Oct 26 03:18:01 2000 +++ linux/include/asm-mips64/addrspace.h Thu Jun 28 13:56:24 2001 @@ -1,5 +1,4 @@ -/* $Id: addrspace.h,v 1.5 2000/02/01 00:32:01 kanoj Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. @@ -104,9 +103,13 @@ #endif #define K2BASE 0xc000000000000000 +#define K0ADDR(x) (PHYSADDR(x) | K0BASE) +#define K1ADDR(x) (PHYSADDR(x) | K1BASE) +#define K2ADDR(x) (PHYSADDR(x) | K2BASE) + #if !defined (CONFIG_CPU_R8000) -#define COMPAT_K1BASE32 0xffffffffa0000000 -#define PHYS_TO_COMPATK1(x) ((x) | COMPAT_K1BASE32) /* 32-bit compat k1 */ +#define COMPAT_K1BASE32 0xffffffffa0000000 /* 32-bit compat k1 */ +#define PHYS_TO_COMPATK1(x) ((unsigned long)(x) | COMPAT_K1BASE32) #endif #define KDM_TO_PHYS(x) ((unsigned long)(x) & TO_PHYS_MASK) diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/include/asm-mips64/sgi/sgihpc.h linux/include/asm-mips64/sgi/sgihpc.h --- linux-orig/include/asm-mips64/sgi/sgihpc.h Sat Dec 4 04:59:13 1999 +++ linux/include/asm-mips64/sgi/sgihpc.h Thu Jun 28 14:04:18 2001 @@ -1,5 +1,4 @@ -/* $Id: sgihpc.h,v 1.2 1999/10/19 20:51:54 ralf Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. @@ -36,7 +35,8 @@ #define HPCDMA_BCNT 0x00003fff /* size in bytes of this dma buffer */ int pnext; /* paddr of next hpc_dma_desc if any */ -}; + int _padding; /* pad to quad word size */ +} __attribute__((aligned(16))); typedef volatile unsigned int hpcreg; @@ -333,8 +333,6 @@ /* We need software copies of these because they are write only. */ extern unsigned int sgi_hpc_write1, sgi_hpc_write2; - -#define SGI_KEYBOARD_IRQ 20 struct hpc_keyb { #ifdef __MIPSEB__ From owner-linux-mips@oss.sgi.com Thu Jun 28 09:43:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SGhNf02463 for linux-mips-outgoing; Thu, 28 Jun 2001 09:43:23 -0700 Received: from mr200.netcologne.de (IDENT:mirapoint@mr200.netcologne.de [194.8.194.109]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SGhJV02457 for ; Thu, 28 Jun 2001 09:43:20 -0700 Received: from valen.metzler (dial-194-8-195-26.netcologne.de [194.8.195.26]) by mr200.netcologne.de (Mirapoint) with ESMTP id AHS19099; Thu, 28 Jun 2001 18:41:20 +0200 (CEST) Received: (from rjkm@localhost) by valen.metzler (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f5SGhSQ03160; Thu, 28 Jun 2001 18:43:28 +0200 From: Ralph Metzler Message-ID: <15163.24240.316758.268911@valen.metzler> Date: Thu, 28 Jun 2001 18:43:28 +0200 (CEST) To: =?EUC-KR?B?sK29xbHU?= Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Help me. In-Reply-To: <3B3B9C29.6898DC59@astonlinux.com> References: <3B3B9C29.6898DC59@astonlinux.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2577 Lines: 90 Hi, =?EUC-KR?B?sK29xbHU?= writes: > I am trying to port a linux 2.4 to R3000 based system (LSI LOGIC > SC2000). > SC2000 have caches. one is Two-way set associative or direct mapped > Instruction cache (16K) and another is Direct-mapped data cache(8K). I also spent one or two weeks with Linux on an SC2000 a while ago but had to stop due to other more important projects. I also ran into problems with the caching. Without caching I got it to boot via NFS. Anyway, at least one mistake is in this part: > ---------------lsi-cache.S-------------------------------- > > /* void flush_icache(void) */ > LEAF(flush_icache) > .set noreorder > > la a3, icache_size # 8Kbyte > lw t4, 0(a3) > > mfc0 t7, CP0_STATUS # save SR > nop > nop > > and t0, t7, ~ST0_IEC # disable interrupts > mtc0 t0, CP0_STATUS > nop > nop > > li t3, CBSYS # BBCC configuration register > lw t8, 0(t3) # save config. register > nop > > li t0, KSEG0 > or t4, t4, t0 # end of I-cache > > move t5, t0 > > 2: la t0, 3f # switch to Kseg1 > or t0, KSEG1 > jr t0 > nop > > # > # flush I-cache set 0 > # > 3: > li t0, (CFG_DCEN | CFG_ICEN) > or t0, CFG_CMODE_ITEST # I-cache set1 enable > # D-cache enable, I-cache set0 > enable > # I-cache software test > sw t0, 0(t3) > lw zero, 0(t3) > addi zero, zero, 1 > > move t0, t5 > 4: sw zero, (t0) > nop > lw zero, (t0) > addu t0, t6 > bltu t0, t4, 4b > nop Where does t6 get set? This bug already is in the LSI sample code. I think they just copied the loop code from the cache invalidation functions (where they actually do determine t6 from the cache line size) and forgot to adjust it. Best regards, Ralph -- /--------------------------------------------------------------------\ | Dr. Ralph J.K. Metzler | Convergence integrated media | |--------------------------------|-----------------------------------| | rjkm@convergence.de | http://www.convergence.de/ | \--------------------------------------------------------------------/ From owner-linux-mips@oss.sgi.com Thu Jun 28 17:25:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T0PfB21286 for linux-mips-outgoing; Thu, 28 Jun 2001 17:25:41 -0700 Received: from dsic.co.kr ([210.221.126.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T0PZV21283 for ; Thu, 28 Jun 2001 17:25:38 -0700 Received: from astonlinux.com [192.168.2.173] by dsic.co.kr [210.221.126.1] with SMTP (MDaemon.v3.5.6.R) for ; Fri, 29 Jun 2001 09:24:02 +0900 Message-ID: <3B3C8288.51AD1CCB@astonlinux.com> Date: Fri, 29 Jun 2001 09:28:40 -0400 From: =?EUC-KR?B?sK29xbHU?= Organization: astonlinux X-Mailer: Mozilla 4.75 [ko] (X11; U; Linux 2.2.16-21hl i686) X-Accept-Language: ko MIME-Version: 1.0 To: Ralph Metzler CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Help me. References: <3B3B9C29.6898DC59@astonlinux.com> <15163.24240.316758.268911@valen.metzler> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-MDRemoteIP: 192.168.2.173 X-Return-Path: cosmos@astonlinux.com X-MDaemon-Deliver-To: linux-mips@oss.sgi.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2818 Lines: 94 Ralph Metzler wrote: > Hi, > > =?EUC-KR?B?sK29xbHU?= writes: > > I am trying to port a linux 2.4 to R3000 based system (LSI LOGIC > > SC2000). > > SC2000 have caches. one is Two-way set associative or direct mapped > > Instruction cache (16K) and another is Direct-mapped data cache(8K). > > I also spent one or two weeks with Linux on an SC2000 a while ago > but had to stop due to other more important projects. I also ran > into problems with the caching. Without caching I got it to boot > via NFS. Anyway, at least one mistake is in this part: > > > ---------------lsi-cache.S-------------------------------- > > > > /* void flush_icache(void) */ > > LEAF(flush_icache) > > .set noreorder > > > > la a3, icache_size # 8Kbyte > > lw t4, 0(a3) > > > > mfc0 t7, CP0_STATUS # save SR > > nop > > nop > > > > and t0, t7, ~ST0_IEC # disable interrupts > > mtc0 t0, CP0_STATUS > > nop > > nop > > > > li t3, CBSYS # BBCC configuration register > > lw t8, 0(t3) # save config. register > > nop > > > > li t0, KSEG0 > > or t4, t4, t0 # end of I-cache > > > > move t5, t0 > > > > 2: la t0, 3f # switch to Kseg1 > > or t0, KSEG1 > > jr t0 > > nop > > > > # > > # flush I-cache set 0 > > # > > 3: > > li t0, (CFG_DCEN | CFG_ICEN) > > or t0, CFG_CMODE_ITEST # I-cache set1 enable > > # D-cache enable, I-cache set0 > > enable > > # I-cache software test > > sw t0, 0(t3) > > lw zero, 0(t3) > > addi zero, zero, 1 > > > > move t0, t5 > > 4: sw zero, (t0) > > nop > > lw zero, (t0) > > addu t0, t6 > > bltu t0, t4, 4b > > nop > > Where does t6 get set? > This bug already is in the LSI sample code. > I think they just copied the loop code from the cache invalidation > functions (where they actually do determine t6 from the cache > line size) and forgot to adjust it. > > Best regards, > Ralph > > -- > /--------------------------------------------------------------------\ > | Dr. Ralph J.K. Metzler | Convergence integrated media | > |--------------------------------|-----------------------------------| > | rjkm@convergence.de | http://www.convergence.de/ | > \--------------------------------------------------------------------/ Thank you. I changed 't6' into '0x4'. but the problem is same. Regards, Shinkyu. From owner-linux-mips@oss.sgi.com Sat Jun 30 02:16:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5U9GxW12820 for linux-mips-outgoing; Sat, 30 Jun 2001 02:16:59 -0700 Received: from arianne.in.ishoni.com ([164.164.83.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5U9GrV12794 for ; Sat, 30 Jun 2001 02:16:54 -0700 Received: from raghav ([192.168.1.172]) by arianne.in.ishoni.com (8.11.1/8.11.1) with SMTP id f5U9HeX17487 for ; Sat, 30 Jun 2001 14:47:40 +0530 Reply-To: From: "Raghav P" To: Subject: Are page tables allocated in KSEG0 or in KSEG2? Date: Sat, 30 Jun 2001 14:51:17 +0530 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1362 Lines: 43 I was going thru the TLB exception for R2300 and had the following doubts which I hope someone can help me out with. ( am sorry if this is a newbie question but since this is MIPS specific I am posting here) The code is in arch/mips/kernel/head.S for user TLB: /* TLB refill, EXL == 0, R[23]00 version */ LEAF(except_vec0_r2300) .set noat .set mips1 mfc0 k0, CP0_BADVADDR lw k1, current_pgd # get pgd pointer srl k0, k0, 22 sll k0, k0, 2 addu k1, k1, k0 mfc0 k0, CP0_CONTEXT lw k1, (k1) and k0, k0, 0xffc addu k1, k1, k0 lw k0, (k1) nop mtc0 k0, CP0_ENTRYLO0 mfc0 k1, CP0_EPC tlbwr jr k1 rfe END(except_vec0_r2300) My linux book says that pgd and pte entries are not setup by the kernel until a pagefault exception occurs. The above code will work only if the pgd and pte tables are stored in kseg2; if they were stored in kseg0 then if a pgd has an invalid pte entry the above code will index into an invalid pte page and get a wrong physical address. But the pgd_alloc() and pte_alloc() routines seem to be allocating physical pages from kseg0 for pgd and pte tables. Am I missing something here??? Thanks Raghav From owner-linux-mips@oss.sgi.com Sat Jun 30 16:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UNXNk27809 for linux-mips-outgoing; Sat, 30 Jun 2001 16:33:23 -0700 Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com [216.136.175.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UNXNV27806 for ; Sat, 30 Jun 2001 16:33:23 -0700 Message-ID: <20010630233322.81749.qmail@web13903.mail.yahoo.com> Received: from [61.187.63.244] by web13903.mail.yahoo.com; Sat, 30 Jun 2001 16:33:22 PDT Date: Sat, 30 Jun 2001 16:33:22 -0700 (PDT) From: Barry Wu Subject: about IDE0 interrupt To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 799 Lines: 24 Hi, all, I am porting linux to our mipsel system. I make a ext2fs system on my intel system, then copy root file system to this hard disk. Finally I attach this disk to our mipsel system. Our system use Acer Lab Ali1535D south bridge. When linux kernel start, it can report disk volume information and partition information, and root file system is mounted. But the time is very long, and I could not get any ide0 interrupt. The time is wasted on schedule(), but if I use ramdisk, the system is running fast. I think the problem is my IDE controller driver or hardware problem. Does some one know the reason? If so, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/