From macro@ds2.pg.gda.pl Fri Jun 1 13:49:16 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA12160; Fri, 1 Jun 2001 13:49:16 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 13:49:16 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd012097; Fri Jun 1 13:44:55 2001 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 Content-Length: 4783 Lines: 153 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 aj@suse.de Fri Jun 1 13:44:56 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA12100; Fri, 1 Jun 2001 13:44:56 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 13:44:56 +0200 (MET DST) Received: from ns.suse.de(213.95.15.193), claiming to be "Cantor.suse.de" via SMTP by guadalquivir.fnet.fr, id smtpd012098; Fri Jun 1 13:44:55 2001 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 Sender: aj@suse.de 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: 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 Content-Length: 2481 Lines: 78 "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 macro@ds2.pg.gda.pl Fri Jun 1 14:36:36 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA13909; Fri, 1 Jun 2001 14:36:36 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 14:36:36 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd013899; Fri Jun 1 14:35:54 2001 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 Content-Length: 2656 Lines: 60 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 macro@ds2.pg.gda.pl Fri Jun 1 14:17:46 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA13283; Fri, 1 Jun 2001 14:17:46 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 14:17:46 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd013281; Fri Jun 1 14:17:37 2001 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 Content-Length: 1845 Lines: 52 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 aj@suse.de Fri Jun 1 15:48:46 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA14951; Fri, 1 Jun 2001 15:48:46 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 15:48:46 +0200 (MET DST) Received: from ns.suse.de(213.95.15.193), claiming to be "Cantor.suse.de" via SMTP by guadalquivir.fnet.fr, id smtpd014949; Fri Jun 1 15:48:40 2001 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 Sender: aj@suse.de 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: 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 Content-Length: 2269 Lines: 67 "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 macro@ds2.pg.gda.pl Fri Jun 1 16:36:25 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA16217; Fri, 1 Jun 2001 16:36:25 +0200 (MET DST) Received-Date: Fri, 1 Jun 2001 16:36:25 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd016178; Fri Jun 1 16:35:35 2001 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 Content-Length: 1116 Lines: 29 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 macro@ds2.pg.gda.pl Tue Jun 5 15:38:33 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA26159; Tue, 5 Jun 2001 15:38:33 +0200 (MET DST) Received-Date: Tue, 5 Jun 2001 15:38:33 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd026157; Tue Jun 5 15:37:50 2001 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 Content-Length: 3835 Lines: 126 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 cosmos@astonlinux.com Sat Jun 9 04:49:17 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id EAA04976; Sat, 9 Jun 2001 04:49:17 +0200 (MET DST) Received-Date: Sat, 9 Jun 2001 04:49:17 +0200 (MET DST) Received: from UNKNOWN(210.221.126.1), claiming to be "dsic.co.kr" via SMTP by guadalquivir.fnet.fr, id smtpd004974; Sat Jun 9 04:49:16 2001 Received: from cosmos [192.168.2.173] by dsic.co.kr [210.221.126.1] with SMTP (MDaemon.v3.5.6.R) for ; Sat, 09 Jun 2001 11:47:58 +0900 Message-ID: <001201c0f08f$249b21f0$ad02a8c0@cosmos> From: "Shinkyu Kang" To: Subject: I have question related for caches in R3000. Date: Sat, 9 Jun 2001 11:51:54 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C0F0DA.94672BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MDRemoteIP: 192.168.2.173 X-Return-Path: cosmos@astonlinux.com X-MDaemon-Deliver-To: linux-mips@fnet.fr Content-Length: 2739 Lines: 47 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C0F0DA.94672BA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLCBteSBuYW1lIGlzIFNoaW5reXUgS2FuZy4NCg0KSScgYW0gdHJ5aW5nIHRvIHRvIHBv cnQgbGludXggMi40LjMgaW4gTUlQUyBSMzAwMCBiYXNlZCBzeXN0ZW0gKExTSSBTQzIwMDApLg0K DQpUaGlzIHN5c3RlbSBzdXBwb3J0cyBmdWxsIG1tdSB1bml0Lg0KDQpUaGlzIHN5c3RlbSBoYXZl IGFsc28gdHdvLXdheSBzZXQgYXNzb2NpYXRpdmUgb3IgZGlyZWN0LW1hcHBlZCBpbnN0cnVjdGlv biBjYWNoZSgxNmspDQphbmQgZGlyZWN0LW1hcHBlZCBkYXRhIGNhY2hlICg4aykuDQoNCldoZW4g SS1jYWNoZSBhbmQgRC1jYWNoZSBhcmUgb2ZmLCB0aGUga2VybmVsIGlzIHVwLCANCmJ1dCBjYXNo ZXMgYXJlIG9uLCB0aGUga2VybmVsIGlzIGRvd24uDQoNCndoYXQgY2FuIEkgZG8/IA0Kd2hhdCBp cyBtb2RpZmllZCBpbiBrZXJuZWw/DQoNCnJlZ2FyZHMuDQpzaGlua3l1Lg0KDQoNCg0KDQoNCg0K ------=_NextPart_000_000F_01C0F0DA.94672BA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2M4ZTBkOD4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbCwgbXkg bmFtZSBpcyBTaGlua3l1IEthbmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SScgYW0gdHJ5aW5nIHRvJm5ic3A7 dG8gcG9ydCZuYnNwO2xpbnV4IDIuNC4zIGluIE1JUFMgUjMwMDAgDQpiYXNlZCBzeXN0ZW0gKExT SSBTQzIwMDApLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5UaGlzIHN5c3RlbSBzdXBwb3J0cyBmdWxsIG1tdSB1bml0LjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGlzIHN5c3RlbSBoYXZlIGFsc28g dHdvLXdheSBzZXQgYXNzb2NpYXRpdmUgb3IgZGlyZWN0LW1hcHBlZCANCmluc3RydWN0aW9uIGNh Y2hlKDE2ayk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbmQgZGlyZWN0LW1hcHBl ZCBkYXRhIGNhY2hlICg4aykuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPldoZW4gSS1jYWNoZSBhbmQgRC1jYWNoZSBhcmUgb2ZmLCB0aGUga2VybmVs IGlzIHVwLCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmJ1dCBjYXNoZXMgYXJl IG9uLCB0aGUga2VybmVsIGlzIGRvd24uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPndoYXQgY2FuIEkgZG8/IDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPndoYXQgaXMgbW9kaWZpZWQgaW4ga2VybmVsPzwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5yZWdhcmRzLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPnNoaW5reXUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000F_01C0F0DA.94672BA0-- From ralf@dea.waldorf-gmbh.de Tue Jun 12 17:21:40 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA09053; Tue, 12 Jun 2001 17:21:40 +0200 (MET DST) Received-Date: Tue, 12 Jun 2001 17:21:40 +0200 (MET DST) Received: from u-74-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.74), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd009049; Tue Jun 12 17:21:27 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5CC5pC26301; Tue, 12 Jun 2001 14:05:51 +0200 Date: Tue, 12 Jun 2001 14:05:51 +0200 From: Ralf Baechle To: Shinkyu Kang Cc: linux-mips@fnet.fr Subject: Re: I have question related for caches in R3000. Message-ID: <20010612140551.A5285@bacchus.dhis.org> References: <001201c0f08f$249b21f0$ad02a8c0@cosmos> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001201c0f08f$249b21f0$ad02a8c0@cosmos>; from cosmos@astonlinux.com on Sat, Jun 09, 2001 at 11:51:54AM +0900 X-Accept-Language: de,en,fr Content-Length: 637 Lines: 19 On Sat, Jun 09, 2001 at 11:51:54AM +0900, Shinkyu Kang wrote: > This system supports full mmu unit. > > This system have also two-way set associative or direct-mapped instruction cache(16k) > and direct-mapped data cache (8k). > > When I-cache and D-cache are off, the kernel is up, > but cashes are on, the kernel is down. > > what can I do? > what is modified in kernel? Our code assumes real R3000s which means physically indexed write-through direct mapped caches that are accessible through a particular interface. Your CPU is not one of those and therefore you'll have to make a few changes to arch/mips/mm/r2300.c. Ralf From donovan@technodada.com Tue Jun 12 23:41:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id XAA13257; Tue, 12 Jun 2001 23:41:38 +0200 (MET DST) Received-Date: Tue, 12 Jun 2001 23:41:38 +0200 (MET DST) Received: from UNKNOWN(209.124.136.151), claiming to be "mail.technodada.com" via SMTP by guadalquivir.fnet.fr, id smtpd013255; Tue Jun 12 23:41:33 2001 Received: from mail.technodada.com (mail.technodada.com [209.124.136.148]) by mail.technodada.com (Postfix) with ESMTP id 97804CB7CB for ; Tue, 12 Jun 2001 13:41:28 -0800 (AKDT) Date: Tue, 12 Jun 2001 13:41:28 -0800 (AKDT) From: Donovan Arellano To: linux-mips@fnet.fr Subject: acer pica 61/netpower 100 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Length: 634 Lines: 15 Hi - how does one add a machine specs to the machine detection. I have a netpower 100 that I do not belive is being recognized correctly. I belive it is having problems w/ the L2 cache size not being set properly. Any help would be great. --=20 As ever, yr. obdt. (but pitiless) svnt., Donovan Arellano=20 -- GNUPG Key: www.technodada.com/~donovan/gpg.key | =20 Web Address: http://www.technodada.com/~donovan | / \ ASCII Ribbon Email Address: donovan@technodada.com | \ / Campaign ICBM Address: 61=B0 10' 24" N 149=B0 53' 34" W | X Against Chance favors the prepared mind. | / \ HTML Mail From macro@ds2.pg.gda.pl Wed Jun 13 13:26:43 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA19216; Wed, 13 Jun 2001 13:26:43 +0200 (MET DST) Received-Date: Wed, 13 Jun 2001 13:26:43 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019209; Wed Jun 13 13:26:35 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA16488; Wed, 13 Jun 2001 13:06:57 +0200 (MET DST) Date: Wed, 13 Jun 2001 13:06:56 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Shinkyu Kang , linux-mips@fnet.fr Subject: Re: I have question related for caches in R3000. In-Reply-To: <20010612140551.A5285@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 396 Lines: 11 On Tue, 12 Jun 2001, Ralf Baechle wrote: > Your CPU is not one of those and therefore you'll have to make a few > changes to arch/mips/mm/r2300.c. A separate new file might be a better idea... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Wed Jun 13 13:56:33 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA19851; Wed, 13 Jun 2001 13:56:33 +0200 (MET DST) Received-Date: Wed, 13 Jun 2001 13:56:33 +0200 (MET DST) Received: from u-115-20.karlsruhe.ipdial.viaginterkom.de(62.180.20.115), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd019802; Wed Jun 13 13:56:03 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5DBlkl31770; Wed, 13 Jun 2001 13:47:46 +0200 Date: Wed, 13 Jun 2001 13:47:46 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Shinkyu Kang , linux-mips@fnet.fr Subject: Re: I have question related for caches in R3000. Message-ID: <20010613134746.A31758@bacchus.dhis.org> References: <20010612140551.A5285@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 01:06:56PM +0200 X-Accept-Language: de,en,fr Content-Length: 411 Lines: 12 On Wed, Jun 13, 2001 at 01:06:56PM +0200, Maciej W. Rozycki wrote: > > Your CPU is not one of those and therefore you'll have to make a few > > changes to arch/mips/mm/r2300.c. > > A separate new file might be a better idea... Splitting all those files into TLB, cache and all the rest is long overdue and if we keep supporting more and more hardware we'll still have to do it in the 2.4 timeframe. Ralf From ralf@dea.waldorf-gmbh.de Wed Jun 13 18:41:32 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA23759; Wed, 13 Jun 2001 18:41:32 +0200 (MET DST) Received-Date: Wed, 13 Jun 2001 18:41:32 +0200 (MET DST) Received: from u-195-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.195), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd023757; Wed Jun 13 18:41:23 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5DCTlI32049; Wed, 13 Jun 2001 14:29:47 +0200 Date: Wed, 13 Jun 2001 14:29:47 +0200 From: Ralf Baechle To: Donovan Arellano Cc: linux-mips@fnet.fr Subject: Re: acer pica 61/netpower 100 Message-ID: <20010613142947.D31221@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 donovan@technodada.com on Tue, Jun 12, 2001 at 01:41:28PM -0800 X-Accept-Language: de,en,fr Content-Length: 868 Lines: 19 On Tue, Jun 12, 2001 at 01:41:28PM -0800, Donovan Arellano wrote: > Date: Tue, 12 Jun 2001 13:41:28 -0800 (AKDT) > From: Donovan Arellano > To: linux-mips@fnet.fr > Subject: acer pica 61/netpower 100 > > Hi - how does one add a machine specs to the machine detection. I have a > netpower 100 that I do not belive is being recognized correctly. I belive > it is having problems w/ the L2 cache size not being set properly. Any > help would be great. The support for Acer PICA is a bit rotten which is probably the reason for why we never ran on Netpower. The machine detection is in arch/mips/arc/identify.c; you probably have to add an entry to the array mach_table and maybe also entries to include/asm-mips/bootinfo.h. There is probably more hacking required, I haven't heared of anybody running Linux on a PICA in all eternity. Ralf From jsun@mvista.com Wed Jun 13 20:25:42 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA25257; Wed, 13 Jun 2001 20:25:42 +0200 (MET DST) Received-Date: Wed, 13 Jun 2001 20:25:42 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "hermes.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd025255; Wed Jun 13 20:25:38 2001 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 f5DINs004028; Wed, 13 Jun 2001 11:23:54 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3B27AF57.E6E9E7C3@mvista.com> Date: Wed, 13 Jun 2001 11:22: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: Ralf Baechle CC: "Maciej W. Rozycki" , Shinkyu Kang , linux-mips@fnet.fr Subject: Re: I have question related for caches in R3000. References: <20010612140551.A5285@bacchus.dhis.org> <20010613134746.A31758@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 585 Lines: 18 Ralf Baechle wrote: > > On Wed, Jun 13, 2001 at 01:06:56PM +0200, Maciej W. Rozycki wrote: > > > > Your CPU is not one of those and therefore you'll have to make a few > > > changes to arch/mips/mm/r2300.c. > > > > A separate new file might be a better idea... > > Splitting all those files into TLB, cache and all the rest is long overdue > and if we keep supporting more and more hardware we'll still have to do it > in the 2.4 timeframe. > How soon will 2.5 come? Splitting TLB and cache support should not take too long - except it is indeed a big change in structure. Jun From ralf@dea.waldorf-gmbh.de Wed Jun 13 20:35:02 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA25347; Wed, 13 Jun 2001 20:35:02 +0200 (MET DST) Received-Date: Wed, 13 Jun 2001 20:35:02 +0200 (MET DST) Received: from u-195-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.195), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd025339; Wed Jun 13 20:34:55 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5DIWVE05990; Wed, 13 Jun 2001 20:32:31 +0200 Date: Wed, 13 Jun 2001 20:32:31 +0200 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , Shinkyu Kang , linux-mips@fnet.fr Subject: Re: I have question related for caches in R3000. Message-ID: <20010613203231.G31221@bacchus.dhis.org> References: <20010612140551.A5285@bacchus.dhis.org> <20010613134746.A31758@bacchus.dhis.org> <3B27AF57.E6E9E7C3@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: <3B27AF57.E6E9E7C3@mvista.com>; from jsun@mvista.com on Wed, Jun 13, 2001 at 11:22:15AM -0700 X-Accept-Language: de,en,fr Content-Length: 508 Lines: 13 On Wed, Jun 13, 2001 at 11:22:15AM -0700, Jun Sun wrote: > > Splitting all those files into TLB, cache and all the rest is long overdue > > and if we keep supporting more and more hardware we'll still have to do it > > in the 2.4 timeframe. > > How soon will 2.5 come? Splitting TLB and cache support should not take too > long - except it is indeed a big change in structure. With all the bugs still hiding in mm and vfs it'll still be a while. Nor do I expect the 2.5 cycle to be a short one. Ralf From macro@ds2.pg.gda.pl Mon Jun 25 13:35:39 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA23399; Mon, 25 Jun 2001 13:35:39 +0200 (MET DST) Received-Date: Mon, 25 Jun 2001 13:35:39 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd023397; Mon Jun 25 13:35:32 2001 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 Content-Length: 2776 Lines: 63 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 ralf@dea.waldorf-gmbh.de Wed Jun 27 15:51:23 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA04036; Wed, 27 Jun 2001 15:51:23 +0200 (MET DST) Received-Date: Wed, 27 Jun 2001 15:51:23 +0200 (MET DST) Received: from oss.sgi.com(216.32.174.27) via SMTP by guadalquivir.fnet.fr, id smtpd004034; Wed Jun 27 15:51:18 2001 Received: from dea.waldorf-gmbh.de (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id f5RDp8V14018 for ; Wed, 27 Jun 2001 06:51:08 -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 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 ralf@dea.waldorf-gmbh.de Thu Jun 28 02:11:40 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id CAA10414; Thu, 28 Jun 2001 02:11:40 +0200 (MET DST) Received-Date: Thu, 28 Jun 2001 02:11:40 +0200 (MET DST) Received: from u-51-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.51), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd010412; Thu Jun 28 02:11:30 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f5S064S02319; Thu, 28 Jun 2001 02:06:04 +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 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