From owner-linux-mips@oss.sgi.com Mon Jul 1 02:09:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g6199jnC018508 for ; Mon, 1 Jul 2002 02:09:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g6199jVK018507 for linux-mips-outgoing; Mon, 1 Jul 2002 02:09:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g6199YnC017601; Mon, 1 Jul 2002 02:09:34 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 4F458133AA; Mon, 1 Jul 2002 11:13:22 +0200 (CEST) Date: Mon, 1 Jul 2002 11:13:22 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 Message-ID: <20020701091321.GO17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com, Ralf Baechle References: <20020629220513.GC17216@lug-owl.de> <20020630174717.GI17216@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0Wg1ddIY7KV0vpwL" Content-Disposition: inline In-Reply-To: <20020630174717.GI17216@lug-owl.de> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --0Wg1ddIY7KV0vpwL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2002-06-30 19:47:17 +0200, Jan-Benedict Glaw wrote in message <20020630174717.GI17216@lug-owl.de>: > On Sun, 2002-06-30 00:05:13 +0200, Jan-Benedict Glaw > wrote in message <20020629220513.GC17216@lug-owl.de>: > [...] > > 10: bc600060 0xbc600060 > > Code; 88016ce0 > > 14: bc600080 0xbc600080 >=20 > Well, I've bulid the same kernel with CONFIG_MIPS_UNCACHED and the box > is running^Wsnailing fine with it. I'm experiencing a little peformance > drop (100 BogoMips -> 2.79 BogoMips), but it comes up in finite time:-) I've got some mail that support for my early R4600 (well, the bug fixes for it...) got removed some time ago. I've looked at the diff of r1.3 (2.4.16) and r1.3.2.3 (2.4.19-rc1) and it seems that mostly calls to __save_and_cli() and __restore_flags() got removed. Reading , it really seems that this is causing my problem. Ralf, would you accept a patch adding these lines again surrounded by #ifdef CONFIG_CPU_R4X00 ... #endif /* CONFIG_CPU_R4X00 */? The current state however isn't that fine: running uncached is no fun:-( MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --0Wg1ddIY7KV0vpwL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IB0wHb1edYOZ4bsRAs6oAJ47OhWL/0AShhQPW+rUSmBeTLsJVgCeJsHg HpoWThOHhN1lSyMS2Ksosos= =VToj -----END PGP SIGNATURE----- --0Wg1ddIY7KV0vpwL-- From owner-linux-mips@oss.sgi.com Mon Jul 1 02:40:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g619eRnC019504 for ; Mon, 1 Jul 2002 02:40:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g619eRga019503 for linux-mips-outgoing; Mon, 1 Jul 2002 02:40:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g619eBnC019479; Mon, 1 Jul 2002 02:40:11 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0752013373; Mon, 1 Jul 2002 11:43:59 +0200 (CEST) Date: Mon, 1 Jul 2002 11:43:59 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 Message-ID: <20020701094359.GP17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com, Ralf Baechle References: <20020629220513.GC17216@lug-owl.de> <20020630174717.GI17216@lug-owl.de> <20020701091321.GO17216@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/F2XdnRjS8y2HUtp" Content-Disposition: inline In-Reply-To: <20020701091321.GO17216@lug-owl.de> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --/F2XdnRjS8y2HUtp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-01 11:13:22 +0200, Jan-Benedict Glaw wrote in message <20020701091321.GO17216@lug-owl.de>: > On Sun, 2002-06-30 19:47:17 +0200, Jan-Benedict Glaw > wrote in message <20020630174717.GI17216@lug-owl.de>: > > On Sun, 2002-06-30 00:05:13 +0200, Jan-Benedict Glaw > > wrote in message <20020629220513.GC17216@lug-owl.de>: > > [...] > > > 10: bc600060 0xbc600060 > > > Code; 88016ce0 > > > 14: bc600080 0xbc600080 > >=20 > > Well, I've bulid the same kernel with CONFIG_MIPS_UNCACHED and the box > > is running^Wsnailing fine with it. I'm experiencing a little peformance > > drop (100 BogoMips -> 2.79 BogoMips), but it comes up in finite time:-) >=20 > I've got some mail that support for my early R4600 (well, the bug fixes > for it...) got removed some time ago. I've looked at the diff of r1.3 > (2.4.16) and r1.3.2.3 (2.4.19-rc1) and it seems that mostly calls to > __save_and_cli() and __restore_flags() got removed. Reading , > it really seems that this is causing my problem. >=20 > Ralf, would you accept a patch adding these lines again surrounded by > #ifdef CONFIG_CPU_R4X00 ... #endif /* CONFIG_CPU_R4X00 */? The current > state however isn't that fine: running uncached is no fun:-( Okay, stupid idea. All these flush functions seem to be never called in parallel or recursive, so if might be possible to have a global flags variable and instead of always calling __save..() and __restore..(), we bulid a pair of inline functions doing this. This wouldn't give any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much as all those #ifdef and #endif's would do... I'll test my suggestion as fast as I reach my Indy again (is powered down at home...). #ifdef CONFIG_CPU_R4X00 long buggy_r4600_flags; #endif /* CONFIG_CPU_R4X00 */ static inline void r4600_bug_start() { #ifdef CONFIG_CPU_R4x00 __save_and_cli(buggy_r4600_flags); #endif /* CONFIG_CPU_R4x00 */ return; } static inline void r4600_bug_finish() { #ifdef CONFIG_CPU_R4x00 __restore_flags(buggy_r4600_flags); #endif /* CONFIG_CPU_R4x00 */ return; } MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --/F2XdnRjS8y2HUtp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ICReHb1edYOZ4bsRAg4SAJ9qm8iPV6A0ylxrhn9AyHxVKCSPhACfaZBb ECRyU7vndNJlT8On8hDqxy8= =B0TB -----END PGP SIGNATURE----- --/F2XdnRjS8y2HUtp-- From owner-linux-mips@oss.sgi.com Mon Jul 1 07:24:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61EO6nC006197 for ; Mon, 1 Jul 2002 07:24:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61EO6e2006196 for linux-mips-outgoing; Mon, 1 Jul 2002 07:24:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61ENvnC005990; Mon, 1 Jul 2002 07:23:58 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA09519; Mon, 1 Jul 2002 16:28:14 +0200 (MET DST) Date: Mon, 1 Jul 2002 16:28:13 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 In-Reply-To: <20020701094359.GP17216@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > Okay, stupid idea. All these flush functions seem to be never called in > parallel or recursive, so if might be possible to have a global flags > variable and instead of always calling __save..() and __restore..(), > we bulid a pair of inline functions doing this. This wouldn't give > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much > as all those #ifdef and #endif's would do... I'll test my suggestion > as fast as I reach my Indy again (is powered down at home...). Feel free to use the change privately. Otherwise please code a real fix, i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means other processors as well, e.g. R4000 or R4400 which are fine here. Actually blocking interrupts for over 0.01s as it used to be done is unacceptable, even for buggy R4600 processors. A fix should use a more fine-grained interrupt masking. 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 Jul 1 08:10:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61FALnC007700 for ; Mon, 1 Jul 2002 08:10:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61FALP3007699 for linux-mips-outgoing; Mon, 1 Jul 2002 08:10:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61FAAnC007684 for ; Mon, 1 Jul 2002 08:10:11 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 439DE133AA; Mon, 1 Jul 2002 17:13:59 +0200 (CEST) Date: Mon, 1 Jul 2002 17:13:59 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 Message-ID: <20020701151359.GR17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020701094359.GP17216@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Og4V1LL7XI16KR+9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Og4V1LL7XI16KR+9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki wrote in message : > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: >=20 > > Okay, stupid idea. All these flush functions seem to be never called in > > parallel or recursive, so if might be possible to have a global flags > > variable and instead of always calling __save..() and __restore..(), > > we bulid a pair of inline functions doing this. This wouldn't give > > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much > > as all those #ifdef and #endif's would do... I'll test my suggestion > > as fast as I reach my Indy again (is powered down at home...). >=20 > Feel free to use the change privately. Otherwise please code a real fix, > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means > other processors as well, e.g. R4000 or R4400 which are fine here.=20 >=20 > Actually blocking interrupts for over 0.01s as it used to be done is Ah. That would explain the huge time drifts when the box is under load... > unacceptable, even for buggy R4600 processors. A fix should use a more > fine-grained interrupt masking.=20 I'm just compiling with my proposed "fix". However, is it really a good idea to duplicate so much code? Taking my 2nd idea (having inline functions for saveing/restoring flags which are complete no-ops if !CONFIG_CPU_R4X00), would it be much overhead for 4400 and 4000 to check if we need to shuffle around flags and cut off interrupts? I'm not really familiar w/ cache and interrupt handling/masking, and I don't (yet) exactly know how to check for the buggy old R4600, but I think I'll have to become an expert around that:-O Any hints for online resources? I've had a look at idt.com (found it in =2E/asm-mips/war.h), but I cannot find the resources there:-( MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --Og4V1LL7XI16KR+9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IHG2Hb1edYOZ4bsRAhLRAJ9hcQ++TJ7XjmjsVDv5FGeXsbRfegCgkWaO NFb9LBirwGu+mQjNMFV0b70= =RhOT -----END PGP SIGNATURE----- --Og4V1LL7XI16KR+9-- From owner-linux-mips@oss.sgi.com Mon Jul 1 08:26:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61FQ1nC008258 for ; Mon, 1 Jul 2002 08:26:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61FQ1WF008257 for linux-mips-outgoing; Mon, 1 Jul 2002 08:26:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61FPmnC008242 for ; Mon, 1 Jul 2002 08:25:49 -0700 Received: from tmrini by opus.bloom.county with local (Exim 3.35 #1 (Debian)) id 17P370-0005jM-00; Mon, 01 Jul 2002 08:29:10 -0700 Date: Mon, 1 Jul 2002 08:29:10 -0700 From: Tom Rini To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com, linux-alpha@vger.kernel.org Subject: [PATCH 2.4.19-rc1] Make sure drivers/input/Config.in goes before drivers/char/Config.in Message-ID: <20020701152910.GD20920@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This makes drivers/input/Config.in always comes before drivers/char/Config.in. Currently, alpha, mips and mips64 source drivers/input/Config.in after drivers/char/Config.in. But as noted in most of the other arches config.in, drivers/input/Config.in must come before drivers/char/Config.in for all depenancies to be worked out. This adds that comments to these arches as well as fixing the dependancy. On the off chance that this is intentional, linux-mips and linux-alpha are CC'ed as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ===== arch/alpha/config.in 1.15 vs edited ===== --- 1.15/arch/alpha/config.in Sat May 25 19:37:06 2002 +++ edited/arch/alpha/config.in Mon Jul 1 07:16:45 2002 @@ -362,6 +362,10 @@ fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in @@ -397,7 +401,6 @@ endmenu source drivers/usb/Config.in -source drivers/input/Config.in source net/bluetooth/Config.in ===== arch/mips/config.in 1.6 vs edited ===== --- 1.6/arch/mips/config.in Thu Feb 28 06:57:19 2002 +++ edited/arch/mips/config.in Mon Jul 1 07:17:22 2002 @@ -563,6 +563,10 @@ fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in source drivers/media/Config.in @@ -628,7 +632,6 @@ fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' ===== arch/mips64/config.in 1.6 vs edited ===== --- 1.6/arch/mips64/config.in Thu Feb 28 06:57:19 2002 +++ edited/arch/mips64/config.in Mon Jul 1 07:17:38 2002 @@ -284,6 +284,10 @@ fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in @@ -325,7 +329,6 @@ fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' From owner-linux-mips@oss.sgi.com Mon Jul 1 08:53:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61Fr4nC009182 for ; Mon, 1 Jul 2002 08:53:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61Fr4iG009181 for linux-mips-outgoing; Mon, 1 Jul 2002 08:53:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61Fq2nC009148 for ; Mon, 1 Jul 2002 08:52:03 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 3461513373; Mon, 1 Jul 2002 17:55:52 +0200 (CEST) Date: Mon, 1 Jul 2002 17:55:52 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Buggy R4600 support (was: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1) Message-ID: <20020701155552.GT17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020701094359.GP17216@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HL+2C3YiDdBCOf2R" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --HL+2C3YiDdBCOf2R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki wrote in message : > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > > Okay, stupid idea. All these flush functions seem to be never called in > > parallel or recursive, so if might be possible to have a global flags > > variable and instead of always calling __save..() and __restore..(), > > we bulid a pair of inline functions doing this. This wouldn't give > > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much > > as all those #ifdef and #endif's would do... I'll test my suggestion > > as fast as I reach my Indy again (is powered down at home...). >=20 > Feel free to use the change privately. Otherwise please code a real fix, > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means > other processors as well, e.g. R4000 or R4400 which are fine here.=20 Well, here's step 1. I've created inline functions for save/restore flags and dropped them in where (as of 2.4.16) the calls where. My Indy already runs (fine) with this. Now, there are two possibilities: I could double all the cache handling functions for old R4600 and set appropriate pointers in all the __init functions at the end of c-r4k.c. The other variant would be to work on the inline functions to only save/restore if this is a buggy CPU. The next step could be to only mask out some interrupts as suggested, but I'm currently not experienced enough to do this. I've now also looked at www.mips.com, but I cannot find the erratta for R4600:-( I'm too dumb... However, here's what I currently have. Feel free to throw stones at me: Ralf: There's a little spellinck ficks at patches end... Index: c-r4k.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 c-r4k.c --- c-r4k.c 2002/05/29 03:03:17 1.3.2.3 +++ c-r4k.c 2002/07/01 15:40:03 @@ -54,6 +54,10 @@ =20 struct bcache_ops *bcops =3D &no_sc_ops; =20 +#ifdef CONFIG_CPU_R4X00 +unsigned long r4600_buggy_flags; +#endif /* CONFIG_CPU_R4X00 */ + /* * On processors with QED R4600 style two set assosicative cache * this is the bit which selects the way in the cache for the @@ -62,6 +66,26 @@ #define icache_waybit (icache_size >> 1) #define dcache_waybit (dcache_size >> 1) =20 +static inline void +r4600_bug_start(void) +{ +#ifdef CONFIG_CPU_R4X00 + __save_and_cli(r4600_buggy_flags); + __asm__ __volatile__("nop;nop;nop;nop"); +#endif /* CONFIG_CPU_R4X00 */ + return; +} + +static inline void +r4600_bug_finish(void) +{ +#ifdef CONFIG_CPU_R4X00 + __restore_flags(r4600_buggy_flags); +#endif /* CONFIG_CPU_R4X00 */ + return; +} + + /* * If you think for one second that this stuff coming up is a lot * of bulky code eating too many kernel cache lines. Think _again_. @@ -77,47 +101,65 @@ =20 static inline void r4k_flush_cache_all_s16d16i16(void) { + r4600_bug_start(); blast_dcache16(); blast_icache16(); blast_scache16(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s32d16i16(void) { + r4600_bug_start(); blast_dcache16(); blast_icache16(); blast_scache32(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s64d16i16(void) { + r4600_bug_start(); blast_dcache16(); blast_icache16(); blast_scache64(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s128d16i16(void) { + r4600_bug_start(); blast_dcache16(); blast_icache16(); blast_scache128(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s32d32i32(void) { + r4600_bug_start(); blast_dcache32(); blast_icache32(); blast_scache32(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s64d32i32(void) { + r4600_bug_start(); blast_dcache32(); blast_icache32(); blast_scache64(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_s128d32i32(void) { + r4600_bug_start(); blast_dcache32(); blast_icache32(); blast_scache128(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_d16i16(void) { + r4600_bug_start(); blast_dcache16(); blast_icache16(); + r4600_bug_finish(); } =20 static inline void r4k_flush_cache_all_d32i32(void) { + r4600_bug_start(); blast_dcache32(); blast_icache32(); + r4600_bug_finish(); } =20 static void @@ -143,6 +185,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while (start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -152,6 +195,7 @@ blast_scache16_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -179,6 +223,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -188,6 +233,7 @@ blast_scache32_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -214,6 +260,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -223,6 +270,7 @@ blast_scache64_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -249,6 +297,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -258,6 +307,7 @@ blast_scache128_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -284,6 +334,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -293,6 +344,7 @@ blast_scache32_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -319,6 +371,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -328,6 +381,7 @@ blast_scache64_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -354,6 +408,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_bug_start(); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -363,6 +418,7 @@ blast_scache128_page(start); start +=3D PAGE_SIZE; } + r4600_bug_finish(); } } } @@ -375,7 +431,9 @@ #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + r4600_bug_start(); blast_dcache16(); blast_icache16(); + r4600_bug_finish(); } } =20 @@ -387,7 +445,9 @@ #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + r4600_bug_start(); blast_dcache32(); blast_icache32(); + r4600_bug_finish(); } } =20 @@ -504,6 +564,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -533,6 +594,7 @@ } else blast_scache16_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s32d16i16(struct vm_area_struct *vma, @@ -553,6 +615,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -581,6 +644,7 @@ } else blast_scache32_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s64d16i16(struct vm_area_struct *vma, @@ -601,6 +665,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -629,6 +694,7 @@ } else blast_scache64_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s128d16i16(struct vm_area_struct *vma, @@ -649,6 +715,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -678,6 +745,7 @@ } else blast_scache128_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s32d32i32(struct vm_area_struct *vma, @@ -698,6 +766,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -727,6 +796,7 @@ } else blast_scache32_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s64d32i32(struct vm_area_struct *vma, @@ -747,6 +817,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -776,6 +847,7 @@ } else blast_scache64_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_s128d32i32(struct vm_area_struct *vma, @@ -796,6 +868,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -824,6 +897,7 @@ } else blast_scache128_page(page); out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_d16i16(struct vm_area_struct *vma, @@ -844,6 +918,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -872,6 +947,7 @@ blast_dcache16_page_indexed(page); } out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_d32i32(struct vm_area_struct *vma, @@ -892,6 +968,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -921,6 +998,7 @@ blast_dcache32_page_indexed(page); } out: + r4600_bug_finish(); } =20 static void r4k_flush_cache_page_d32i32_r4600(struct vm_area_struct *vma, @@ -941,6 +1019,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_bug_start(); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -970,6 +1049,7 @@ blast_dcache32_page_indexed(page ^ dcache_waybit); } out: + r4600_bug_finish(); } =20 /* If the addresses passed to these routines are valid, they are @@ -1063,7 +1143,7 @@ flush_cache_all(); } else { #ifdef R4600_V2_HIT_CACHEOP_WAR - /* Workaround for R4600 bug. See comment in . */ + /* Workaround for R4600 bug. See comment in . */ __save_and_cli(flags); *(volatile unsigned long *)KSEG1; #endif --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --HL+2C3YiDdBCOf2R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IHuHHb1edYOZ4bsRAneZAJ9+xZy/m8yDHgNfaKN9x/NQsElwIgCeIxop q4rldnK6hGpUbRMX095cCBY= =v5/7 -----END PGP SIGNATURE----- --HL+2C3YiDdBCOf2R-- From owner-linux-mips@oss.sgi.com Mon Jul 1 09:58:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61GwQnC011588 for ; Mon, 1 Jul 2002 09:58:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61GwQjV011587 for linux-mips-outgoing; Mon, 1 Jul 2002 09:58:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61GwInC011571 for ; Mon, 1 Jul 2002 09:58:19 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA12073; Mon, 1 Jul 2002 19:02:39 +0200 (MET DST) Date: Mon, 1 Jul 2002 19:02:38 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 In-Reply-To: <20020701151359.GR17216@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > I'm just compiling with my proposed "fix". However, is it really a good > idea to duplicate so much code? Taking my 2nd idea (having inline > functions for saveing/restoring flags which are complete no-ops if > !CONFIG_CPU_R4X00), would it be much overhead for 4400 and 4000 to check > if we need to shuffle around flags and cut off interrupts? No need to duplicate anything -- templates may be used with bits substituted as needed depending on what file is generated. See e.g. arch/mips64/kernel/binfmt_elf32.c for an example idea. > I'm not really familiar w/ cache and interrupt handling/masking, and I > don't (yet) exactly know how to check for the buggy old R4600, but I > think I'll have to become an expert around that:-O The check is already in place -- see setup_noscache_funcs() in arch/mips/mm/c-r4k.c, only the implementation is incomplete which started biting after interrupts became active. > Any hints for online resources? I've had a look at idt.com (found it in > ./asm-mips/war.h), but I cannot find the resources there:-( I contacted them some time ago, soon after the fix for interrupt masking went in (someone reported a problem with an old R4600 then). Unfortunately my conversation with them was disappointing and currently I lack incentive to code a workaround for their buggy chips. Especially as I have tasks I consider more important to do. 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 Jul 1 10:18:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61HIXnC012247 for ; Mon, 1 Jul 2002 10:18:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61HIW2c012246 for linux-mips-outgoing; Mon, 1 Jul 2002 10:18:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61HIPnC012233 for ; Mon, 1 Jul 2002 10:18:25 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 374CD13373; Mon, 1 Jul 2002 19:22:15 +0200 (CEST) Date: Mon, 1 Jul 2002 19:22:15 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 Message-ID: <20020701172215.GU17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020701151359.GR17216@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RGwttE/plSABi47o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --RGwttE/plSABi47o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-01 19:02:38 +0200, Maciej W. Rozycki wrote in message : > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > > I'm not really familiar w/ cache and interrupt handling/masking, and I > > don't (yet) exactly know how to check for the buggy old R4600, but I > > think I'll have to become an expert around that:-O >=20 > The check is already in place -- see setup_noscache_funcs() in > arch/mips/mm/c-r4k.c, only the implementation is incomplete which started > biting after interrupts became active. Hmmm... I think Ill have to read some heavy MIPS books first:-) MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --RGwttE/plSABi47o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9II/GHb1edYOZ4bsRAuRjAKCJdshLt93XOuDo0ssio30B6JPfZACfZNqj UBJz8X7++n+Syp96bm3o1Uo= =zHV1 -----END PGP SIGNATURE----- --RGwttE/plSABi47o-- From owner-linux-mips@oss.sgi.com Mon Jul 1 10:21:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61HLGnC012416 for ; Mon, 1 Jul 2002 10:21:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61HLGk8012415 for linux-mips-outgoing; Mon, 1 Jul 2002 10:21:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61HLAnC012397 for ; Mon, 1 Jul 2002 10:21:10 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.9.3) with ESMTP id g61HP0N16567; Mon, 1 Jul 2002 19:25:00 +0200 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id TAA16476; Mon, 1 Jul 2002 19:25:00 +0200 (MET DST) From: Karel van Houten Message-Id: <200207011725.TAA16476@sparta.research.kpn.com> Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 To: jbglaw@lug-owl.de Date: Mon, 1 Jul 2002 19:24:59 +0200 (MET DST) Cc: linux-mips@oss.sgi.com In-Reply-To: <20020701151359.GR17216@lug-owl.de> from "jbglaw@lug-owl.de" at Jul 01, 2002 05:13:59 PM X-Url: http://www-lsdm.research.kpn.com/~karel X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki > wrote in message > : > > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > > > > > Okay, stupid idea. All these flush functions seem to be never called in > > > parallel or recursive, so if might be possible to have a global flags > > > variable and instead of always calling __save..() and __restore..(), > > > we bulid a pair of inline functions doing this. This wouldn't give > > > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much > > > as all those #ifdef and #endif's would do... I'll test my suggestion > > > as fast as I reach my Indy again (is powered down at home...). > > > > Feel free to use the change privately. Otherwise please code a real fix, > > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means > > other processors as well, e.g. R4000 or R4400 which are fine here. > > > > Actually blocking interrupts for over 0.01s as it used to be done is > > Ah. That would explain the huge time drifts when the box is under > load... > Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and DS5000/200 can keep exact time, even under heavy load. Btw, I use a R4400SC CPU. -- 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 Mon Jul 1 10:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61HNjnC012599 for ; Mon, 1 Jul 2002 10:23:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61HNjCs012598 for linux-mips-outgoing; Mon, 1 Jul 2002 10:23:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61HNZnC012584 for ; Mon, 1 Jul 2002 10:23:36 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id DC6D8133AB; Mon, 1 Jul 2002 19:27:25 +0200 (CEST) Date: Mon, 1 Jul 2002 19:27:25 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 Message-ID: <20020701172725.GW17216@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020701151359.GR17216@lug-owl.de> <200207011725.TAA16476@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ddJi1IsAv4W/kcDl" Content-Disposition: inline In-Reply-To: <200207011725.TAA16476@sparta.research.kpn.com> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --ddJi1IsAv4W/kcDl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-01 19:24:59 +0200, Karel van Houten wrote in message <200207011725.TAA16476@sparta.research.kpn.com>: > > On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki > > wrote in message > > : > > > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote: > > > Feel free to use the change privately. Otherwise please code a real= fix, > > > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 mea= ns > > > other processors as well, e.g. R4000 or R4400 which are fine here.=20 > > >=20 > > > Actually blocking interrupts for over 0.01s as it used to be done is > >=20 > > Ah. That would explain the huge time drifts when the box is under > > load... >=20 > Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and > DS5000/200 can keep exact time, even under heavy load. > Btw, I use a R4400SC CPU. Oh. Lucke you, unlucky /me... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --ddJi1IsAv4W/kcDl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IJD8Hb1edYOZ4bsRAm8DAJ4zZ1wFo0FQl4JXzAV1M1shfQEphACePsdB D8kx5PORf14pTBE85b1g6H8= =PWwx -----END PGP SIGNATURE----- --ddJi1IsAv4W/kcDl-- From owner-linux-mips@oss.sgi.com Mon Jul 1 10:41:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61HflnC013234 for ; Mon, 1 Jul 2002 10:41:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61Hflpv013233 for linux-mips-outgoing; Mon, 1 Jul 2002 10:41:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61HffnC013221 for ; Mon, 1 Jul 2002 10:41:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA12750; Mon, 1 Jul 2002 19:46:02 +0200 (MET DST) Date: Mon, 1 Jul 2002 19:46:01 +0200 (MET DST) From: "Maciej W. Rozycki" To: Karel van Houten cc: linux-mips@oss.sgi.com Subject: Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1 In-Reply-To: <200207011725.TAA16476@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 1 Jul 2002, Karel van Houten wrote: > Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and > DS5000/200 can keep exact time, even under heavy load. Well, for the /200 you should have always had stable time, although with a coarse resolution, due to the lack of a high-precision timer (which for the DECstation family is available either internally in R4k CPUs or externally in the I/O ASIC). -- + 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 Jul 1 11:58:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61IwLnC015768 for ; Mon, 1 Jul 2002 11:58:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61IwLDv015767 for linux-mips-outgoing; Mon, 1 Jul 2002 11:58:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61IwEnC015745; Mon, 1 Jul 2002 11:58:14 -0700 Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by deliverator.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 MAA09660; Mon, 1 Jul 2002 12:01:55 -0700 (PDT) mail_from (brad@ltc.com) Received: from dev1.mshome.net ([192.168.0.245] helo=dev1) by lahoo.mshome.net with esmtp (Exim 3.12 #1 (Debian)) id 17P6E9-0001VK-00; Mon, 01 Jul 2002 14:48:45 -0400 Received: from brad by dev1 with local (Exim 3.35 #1 (Debian)) id 17P6FZ-00051a-00; Mon, 01 Jul 2002 14:50:13 -0400 Date: Mon, 1 Jul 2002 14:50:13 -0400 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: [PATCH] better bar size calculation Message-ID: <20020701145012.A19315@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" X-Spam-Status: No, hits=-3.7 required=5.0 tests=MAY_BE_FORGED,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk # 02/07/01 brad@dev1.(none) 1.72 # better bar size calculation diff -Nru a/arch/mips/kernel/pci_auto.c b/arch/mips/kernel/pci_auto.c --- a/arch/mips/kernel/pci_auto.c Mon Jul 1 14:48:47 2002 +++ b/arch/mips/kernel/pci_auto.c Mon Jul 1 14:48:47 2002 @@ -35,6 +35,7 @@ #include #include #include +#include #include @@ -152,7 +153,7 @@ /* Calculate requested size */ - bar_size = ~(bar_response & addr_mask) + 1; + bar_size = 1 << (ffs(bar_response & addr_mask) - 1); /* Allocate a base address */ bar_value = ((*lower_limit - 1) & ~(bar_size - 1)) + bar_size; From owner-linux-mips@oss.sgi.com Mon Jul 1 12:12:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61JC1nC016394 for ; Mon, 1 Jul 2002 12:12:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61JC1YQ016393 for linux-mips-outgoing; Mon, 1 Jul 2002 12:12:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61JBsnC016379; Mon, 1 Jul 2002 12:11:55 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 5A9BF8D35; Mon, 1 Jul 2002 21:15:45 +0200 (CEST) Date: Mon, 1 Jul 2002 21:15:45 +0200 From: Guido Guenther To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20020701211545.D6454@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Ralf Baechle , linux-mips@oss.sgi.com References: <200206301157.g5UBvrwF019470@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206301157.g5UBvrwF019470@oss.sgi.com>; from ralf@oss.sgi.com on Sun, Jun 30, 2002 at 04:57:53AM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Jun 30, 2002 at 04:57:53AM -0700, Ralf Baechle wrote: > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 02/06/30 04:57:53 > > Modified files: > drivers/char : Tag: linux_2_4 Config.in > > Log message: > Delete duplicate and braindead code for CONFIG_INDYDOG. You killed the wrong one: http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.2/1209.html -- Guido From owner-linux-mips@oss.sgi.com Mon Jul 1 12:27:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61JR8nC017024 for ; Mon, 1 Jul 2002 12:27:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61JR84g017023 for linux-mips-outgoing; Mon, 1 Jul 2002 12:27:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61JPdnC016943; Mon, 1 Jul 2002 12:25:39 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g61JTKC25499; Mon, 1 Jul 2002 21:29:20 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g61JTKTF008090; Mon, 1 Jul 2002 21:29:20 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17P6rQ-0007FW-00; Mon, 01 Jul 2002 21:29:20 +0200 Date: Mon, 1 Jul 2002 21:29:20 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] O2 ethernet support Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-970882123-1025551760=:27848" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.2 required=5.0 tests=MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-970882123-1025551760=:27848 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here is a patch to fix the SGI O2 onboard ethernet driver, which was not working at all. It also adds support for autodetection of 10Mbps or 100Mbps link. Known remaining issues: * sometimes hangs under heavy load (rare) Please comment and/or apply. regards, Vivien Chappelier. --279724308-970882123-1025551760=:27848 Content-Type: TEXT/plain; name="linux-O2-meth.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-meth.diff" LS0tIGxpbnV4L2RyaXZlcnMvbmV0L21ldGguYwlUaHUgRGVjIDIwIDE4OjMw OjUxIDIwMDENCisrKyBsaW51eC5idWlsZC9kcml2ZXJzL25ldC9tZXRoLmMJ VHVlIEphbiAyMiAxNjo1MTowMiAyMDAyDQpAQCAtMSw1ICsxLDUgQEANCiAv Kg0KLSAqIG1ldGguYyAtLSBPMiBCdWlsdGluIDEwLzEwMCBFdGhlcm5ldCBk cml2ZXIsIHRoYXQgZG9lc24ndCB3b3JrIGF0IHRoZSBtb21lbnQNCisgKiBt ZXRoLmMgLS0gTzIgQnVpbHRpbiAxMC8xMDAgRXRoZXJuZXQgZHJpdmVyDQog ICoNCiAgKiBDb3B5cmlnaHQgKEMpIDIwMDEgSWx5YSBWb2x5bmV0cw0KICAq DQpAQCAtMTgsNyArMTgsNyBAQA0KICNlbmRpZg0KIA0KICNpZiBNRkVfREVC VUc+PTENCi0jZGVmaW5lIERQUklOVEsoc3RyLGFyZ3MuLi4pIHByaW50ayAo S0VSTl9ERUJVRyAibWV0aDogJXM6ICIgc3RyLCBfX0ZVTkNUSU9OX18gLCAj IyBhcmdzKQ0KKyNkZWZpbmUgRFBSSU5USyhzdHIsYXJncy4uLikgcHJpbnRr IChLRVJOX0RFQlVHICJtZXRoKCVsZCk6ICVzOiAiIHN0ciwgamlmZmllcywg X19GVU5DVElPTl9fICwgIyMgYXJncykNCiAjZGVmaW5lIE1GRV9SWF9ERUJV RyAyDQogI2Vsc2UNCiAjZGVmaW5lIERQUklOVEsoc3RyLGFyZ3MuLi4pDQpA QCAtNjQsMTIgKzY0LDE2IEBADQogLyogVGhpcyBpcyBhIGxvYWQtdGltZSBv cHRpb25zICovDQogLypzdGF0aWMgaW50IGV0aCA9IDA7DQogTU9EVUxFX1BB Uk0oZXRoLCAiaSIpOyovDQotLyoNCisNCisjZGVmaW5lIEhBVkVfVFhfVElN RU9VVA0KKy8qIFRoZSBtYXhpbXVtIHRpbWUgd2FpdGVkIChpbiBqaWZmaWVz KSBiZWZvcmUgYXNzdW1pbmcgYSBUeCBmYWlsZWQuICg0MDBtcykgKi8NCisj ZGVmaW5lIFRYX1RJTUVPVVQgKDQwMCpIWi8xMDAwKQ0KKw0KICNpZmRlZiBI QVZFX1RYX1RJTUVPVVQNCi1zdGF0aWMgaW50IHRpbWVvdXQgPSAwOw0KK3N0 YXRpYyBpbnQgdGltZW91dCA9IFRYX1RJTUVPVVQ7DQogTU9EVUxFX1BBUk0o dGltZW91dCwgImkiKTsNCiAjZW5kaWYNCi0qLw0KKw0KIGludCBtZXRoX2V0 aDsNCiANCiANCkBAIC04OSw2ICs5Myw3IEBADQogCXN0cnVjdCBza19idWZm ICp0eF9za2JzW1RYX1JJTkdfRU5UUklFU107DQogCWRtYV9hZGRyX3QgICAg ICB0eF9za2JfZG1hc1tUWF9SSU5HX0VOVFJJRVNdOw0KIAlpbnQgdHhfcmVh ZCx0eF93cml0ZTsNCisJaW50IHR4X2NvdW50Ow0KIA0KIAlyeF9wYWNrZXQg KnJ4X3JpbmdbUlhfUklOR19FTlRSSUVTXTsNCiAJZG1hX2FkZHJfdCByeF9y aW5nX2RtYXNbUlhfUklOR19FTlRSSUVTXTsNCkBAIC0xMDUsNyArMTEwLDcg QEANCiBjaGFyIG8ybWV0aF9lYWRkcls4XT17MCwwLDAsMCwwLDAsMCwwfTsN CiANCiBzdGF0aWMgaW5saW5lIHZvaWQgbG9hZF9lYWRkcihzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LA0KLQkJCQkgICB2b2xhdGlsZSBzdHJ1Y3QgbWV0aF9y ZWdzICpyZWdzKQ0KKwkJCSAgICAgIHZvbGF0aWxlIHN0cnVjdCBtZXRoX3Jl Z3MgKnJlZ3MpDQogew0KIAlpbnQgaTsNCiAJRFBSSU5USygiTG9hZGluZyBN QUMgQWRkcmVzczogJTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4OiUwMnhcbiIs DQpAQCAtMTQ4LDEzICsxNTMsMTMgQEANCiAJdm9sYXRpbGUgbWV0aF9yZWdz KiByZWdzPXByaXYtPnJlZ3M7DQogCWludCBydmFsOw0KIC8vLwlEUFJJTlRL KCJUcnlpbmcgdG8gd3JpdGUgdmFsdWUgJWkgdG8gcmVndXN0ZXIgJWlcbiIs dmFsLCBwZnlyZWcpOw0KLS8vLwlzcGluX2xvY2tfaXJxKCZwcml2LT5tZXRo X2xvY2spOw0KKwlzcGluX2xvY2tfaXJxKCZwcml2LT5tZXRoX2xvY2spOw0K IAlXQUlUX0ZPUl9QSFkocmVncyxydmFsKQ0KIAlyZWdzLT5waHlfcmVnaXN0 ZXJzPShwcml2LT5waHlfYWRkcjw8NSl8KHBmeXJlZyYweDFmKTsNCiAJcmVn cy0+cGh5X2RhdGE9dmFsOw0KIAl1ZGVsYXkoMjUpOw0KIAlXQUlUX0ZPUl9Q SFkocmVncyxydmFsKQ0KLS8vLwlzcGluX3VubG9ja19pcnEoJnByaXYtPm1l dGhfbG9jayk7DQorCXNwaW5fdW5sb2NrX2lycSgmcHJpdi0+bWV0aF9sb2Nr KTsNCiB9DQogDQogLyogTW9kaWZ5IHBoeSByZWdpc3RlciB1c2luZyBnaXZl biBtYXNrIGFuZCB2YWx1ZSAqLw0KQEAgLTE3OSw3ICsxODQsNyBAQA0KIAkv KiBjaGVjayBpZiBwaHkgaXMgZGV0ZWN0ZWQgYWxyZWFkeSAqLw0KIAlpZihw cml2LT5waHlfYWRkcj49MCYmcHJpdi0+cGh5X2FkZHI8MzIpDQogCQlyZXR1 cm4gMDsNCi0Jc3Bpbl9sb2NrX2lycShwcml2LT5tZXRoX2xvY2spOw0KKwlz cGluX2xvY2tfaXJxKCZwcml2LT5tZXRoX2xvY2spOw0KIAlmb3IgKGk9MDtp PDMyOysraSl7DQogCQlwcml2LT5waHlfYWRkcj0oY2hhcilpOw0KIAkJcDI9 bWRpb19yZWFkKHByaXYsMik7DQpAQCAtMjA1LDcgKzIxMCw3IEBADQogCQkJ YnJlYWs7DQogCQl9DQogCX0NCi0Jc3Bpbl91bmxvY2tfaXJxKHByaXYtPm1l dGhfbG9jayk7DQorCXNwaW5fdW5sb2NrX2lycSgmcHJpdi0+bWV0aF9sb2Nr KTsNCiAJaWYocHJpdi0+cGh5X2FkZHI8MzIpIHsNCiAJCXJldHVybiAwOw0K IAl9DQpAQCAtMjE0LDE3ICsyMTksNTQgQEANCiAJcmV0dXJuIC1FTk9ERVY7 DQogfQ0KIA0KK3N0YXRpYyB2b2lkIG1ldGhfY2hlY2tfbGluayhzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KK3sNCisJc3RydWN0IG1ldGhfcHJpdmF0ZSAq cHJpdiA9IChzdHJ1Y3QgbWV0aF9wcml2YXRlICopIGRldi0+cHJpdjsNCisJ aW50IG1paV9wYXJ0bmVyID0gbWRpb19yZWFkKHByaXYsIDUpOw0KKwlpbnQg bWlpX2FkdmVydGlzaW5nID0gbWRpb19yZWFkKHByaXYsIDQpOw0KKwlpbnQg bmVnb3RpYXRlZCA9IG1paV9hZHZlcnRpc2luZyAmIG1paV9wYXJ0bmVyOw0K KwlpbnQgZHVwbGV4LCBzcGVlZDsNCisNCisJaWYgKG1paV9wYXJ0bmVyID09 IDB4ZmZmZikNCisJCXJldHVybjsNCisNCisJZHVwbGV4ID0gKChuZWdvdGlh dGVkICYgMHgwMTAwKSB8fCAobmVnb3RpYXRlZCAmIDB4MDFDMCkgPT0gMHgw MDQwKT9NRVRIX1BIWV9GRFg6MDsNCisJc3BlZWQgPSAobmVnb3RpYXRlZCAm IDB4MDM4MCk/TUVUSF8xMDBNQklUOjA7DQorDQorCWlmICgocHJpdi0+bW9k ZSAmIE1FVEhfUEhZX0ZEWCkgXiBkdXBsZXgpDQorCXsNCisJCURQUklOVEso IlNldHRpbmcgJXMtZHVwbGV4XG4iLCBkdXBsZXggPyAiZnVsbCIgOiAiaGFs ZiIpOw0KKwkJaWYgKGR1cGxleCkNCisJCQlwcml2LT5tb2RlIHw9IE1FVEhf UEhZX0ZEWDsNCisJCWVsc2UNCisJCQlwcml2LT5tb2RlICY9IH5NRVRIX1BI WV9GRFg7DQorCQlwcml2LT5yZWdzLT5tYWNfY3RybCA9IHByaXYtPm1vZGU7 DQorCX0NCisNCisJaWYgKChwcml2LT5tb2RlICYgTUVUSF8xMDBNQklUKSBe IHNwZWVkKQ0KKwl7DQorCQlEUFJJTlRLKCJTZXR0aW5nICVkTWJzIG1vZGVc biIsIHNwZWVkID8gMTAwIDogMTApOw0KKwkJaWYgKGR1cGxleCkNCisJCQlw cml2LT5tb2RlIHw9IE1FVEhfMTAwTUJJVDsNCisJCWVsc2UNCisJCQlwcml2 LT5tb2RlICY9IH5NRVRIXzEwME1CSVQ7DQorCQlwcml2LT5yZWdzLT5tYWNf Y3RybCA9IHByaXYtPm1vZGU7DQorCX0NCit9DQorDQorDQogc3RhdGljIGlu dCBtZXRoX2luaXRfdHhfcmluZyhtZXRoX3ByaXZhdGUgKnByaXYpDQogew0K IAkvKiBJbml0IFRYIHJpbmcgKi8NCiAJRFBSSU5USygiSW5pdGlhbGl6aW5n IFRYIHJpbmdcbiIpOw0KLQlwcml2LT50eF9yaW5nPSh0eF9wYWNrZXQqKXBj aV9hbGxvY19jb25zaXN0ZW50KE5VTEwsVFhfUklOR19CVUZGRVJfU0laRSwm KHByaXYtPnR4X3JpbmdfZG1hKSk7DQorCXByaXYtPnR4X3JpbmcgPSAodHhf cGFja2V0ICopIHBjaV9hbGxvY19jb25zaXN0ZW50KE5VTEwsVFhfUklOR19C VUZGRVJfU0laRSwmKHByaXYtPnR4X3JpbmdfZG1hKSk7DQogCWlmKCFwcml2 LT50eF9yaW5nKQ0KIAkJcmV0dXJuIC1FTk9NRU07DQotCW1lbXNldChwcml2 LT50eF9yaW5nLDAsVFhfUklOR19CVUZGRVJfU0laRSk7DQotCXByaXYtPnJl Z3MtPnR4X3JpbmdfYmFzZT1wcml2LT50eF9yaW5nX2RtYTsNCi0JcHJpdi0+ ZnJlZV9zcGFjZT1UWF9SSU5HX0VOVFJJRVM7DQotCS8qIE5vdyBpbml0IGtz YiBzYXZlIGFyZWEgKi8NCisJbWVtc2V0KHByaXYtPnR4X3JpbmcsIDAsIFRY X1JJTkdfQlVGRkVSX1NJWkUpOw0KKwlwcml2LT50eF9jb3VudCA9IHByaXYt PnR4X3JlYWQgPSBwcml2LT50eF93cml0ZSA9IDA7DQorCXByaXYtPnJlZ3Mt PnR4X3JpbmdfYmFzZSA9IHByaXYtPnR4X3JpbmdfZG1hOw0KKwlwcml2LT5m cmVlX3NwYWNlID0gVFhfUklOR19FTlRSSUVTOw0KKwkvKiBOb3cgaW5pdCBz a2Igc2F2ZSBhcmVhICovDQogCW1lbXNldChwcml2LT50eF9za2JzLDAsc2l6 ZW9mKHByaXYtPnR4X3NrYnMpKTsNCiAJbWVtc2V0KHByaXYtPnR4X3NrYl9k bWFzLDAsc2l6ZW9mKHByaXYtPnR4X3NrYl9kbWFzKSk7DQogCURQUklOVEso IkRvbmUgd2l0aCBUWCByaW5nIGluaXRcbiIpOw0KQEAgLTIzNiwyNyArMjc4 LDc5IEBADQogCWludCBpOw0KIAlEUFJJTlRLKCJJbml0aWFsaXppbmcgUlgg cmluZ1xuIik7DQogCWZvcihpPTA7aTxSWF9SSU5HX0VOVFJJRVM7aSsrKXsN Ci0JCURQUklOVEsoIlx0MTpcdCVpXG4iLGkpOw0KKwkJRFBSSU5USygiXHQx Olx0JWlcdCIsaSk7DQogCQkvKmlmKCEocHJpdi0+cnhfcmluZ1tpXT1nZXRf ZnJlZV9wYWdlKEdGUF9LRVJORUwpKSkNCiAJCQlyZXR1cm4gLUVOT01FTTsN CiAJCURQUklOVEsoIlx0MjpcdCVpXG4iLGkpOyovDQogCQlwcml2LT5yeF9y aW5nW2ldPShyeF9wYWNrZXQqKXBjaV9hbGxvY19jb25zaXN0ZW50KE5VTEws TUVUSF9SWF9CVUZGX1NJWkUsJihwcml2LT5yeF9yaW5nX2RtYXNbaV0pKTsN CiAJCS8qIEknbGwgbmVlZCB0byByZS1zeW5jIGl0IGFmdGVyIGVhY2ggUlgg Ki8NCi0JCURQUklOVEsoIlx0MjpcdCVpXG4iLGkpOw0KKwkJRFBSSU5USygi XHQlcFxuIixwcml2LT5yeF9yaW5nW2ldKTsNCiAJCXByaXYtPnJlZ3MtPnJ4 X2ZpZm89cHJpdi0+cnhfcmluZ19kbWFzW2ldOw0KIAl9DQorCXByaXYtPnJ4 X3dyaXRlID0gMDsNCiAJRFBSSU5USygiRG9uZSB3aXRoIFJYIHJpbmdcbiIp Ow0KIAlyZXR1cm4gMDsNCiB9DQogc3RhdGljIHZvaWQgbWV0aF9mcmVlX3R4 X3JpbmcobWV0aF9wcml2YXRlICpwcml2KQ0KIHsNCi0JcGNpX2ZyZWVfY29u c2lzdGVudChOVUxMLFRYX1JJTkdfQlVGRkVSX1NJWkUscHJpdi0+dHhfcmlu Zyxwcml2LT50eF9yaW5nX2RtYSk7DQorCWludCBpOw0KKw0KKwkvKiBSZW1v dmUgYW55IHBlbmRpbmcgc2tiICovDQorCWZvciAoaSA9IDA7IGkgPCBUWF9S SU5HX0VOVFJJRVM7IGkrKykgew0KKwkgIGlmIChwcml2LT50eF9za2JzW2ld KQ0KKwkJZGV2X2tmcmVlX3NrYihwcml2LT50eF9za2JzW2ldKTsNCisJCXBy aXYtPnR4X3NrYnNbaV0gPSBOVUxMOw0KKwl9DQorCXBjaV9mcmVlX2NvbnNp c3RlbnQoTlVMTCwNCisJCQkgICAgVFhfUklOR19CVUZGRVJfU0laRSwNCisJ CQkgICAgcHJpdi0+dHhfcmluZywNCisJCQkgICAgcHJpdi0+dHhfcmluZ19k bWEpOw0KIH0NCiBzdGF0aWMgdm9pZCBtZXRoX2ZyZWVfcnhfcmluZyhtZXRo X3ByaXZhdGUgKnByaXYpDQogew0KIAlpbnQgaTsNCisNCiAJZm9yKGk9MDtp PFJYX1JJTkdfRU5UUklFUztpKyspDQotCQlwY2lfZnJlZV9jb25zaXN0ZW50 KE5VTEwsVFhfUklOR19CVUZGRVJfU0laRSxwcml2LT5yeF9yaW5nW2ldLHBy aXYtPnJ4X3JpbmdfZG1hc1tpXSk7DQorCQlwY2lfZnJlZV9jb25zaXN0ZW50 KE5VTEwsDQorCQkJCSAgICBNRVRIX1JYX0JVRkZfU0laRSwNCisJCQkJICAg IHByaXYtPnJ4X3JpbmdbaV0sDQorCQkJCSAgICBwcml2LT5yeF9yaW5nX2Rt YXNbaV0pOw0KK30NCisNCitpbnQgbWV0aF9yZXNldChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KQ0KK3sNCisJc3RydWN0IG1ldGhfcHJpdmF0ZSAqcHJpdiA9 IChzdHJ1Y3QgbWV0aF9wcml2YXRlICopIGRldi0+cHJpdjsNCisNCisJLyog UmVzZXQgY2FyZCAqLw0KKwlwcml2LT5yZWdzLT5tYWNfY3RybCA9IFNHSV9N QUNfUkVTRVQ7DQorCXByaXYtPnJlZ3MtPm1hY19jdHJsID0gMDsNCisJdWRl bGF5KDI1KTsNCisJRFBSSU5USygiTUFDIGNvbnRyb2wgYWZ0ZXIgcmVzZXQ6 ICUwMTZseFxuIiwgcHJpdi0+cmVncy0+bWFjX2N0cmwpOw0KKw0KKwkvKiBM b2FkIGV0aGVybmV0IGFkZHJlc3MgKi8NCisJbG9hZF9lYWRkcihkZXYsIHBy aXYtPnJlZ3MpOw0KKwkvKiBTaG91bGQgbG9hZCBzb21lICJlcnJhdGEiLCBi dXQgbGF0ZXIgKi8NCisJDQorCS8qIENoZWNrIGZvciBkZXZpY2UgKi8NCisJ aWYobWRpb19wcm9iZShwcml2KSA8IDApIHsNCisJCURQUklOVEsoIlVuYWJs ZSB0byBmaW5kIFBIWVxuIik7DQorCQlyZXR1cm4gLUVOT0RFVjsNCisJfQ0K Kw0KKwkvKiBJbml0aWFsIG1vZGUgLS0gMTB8SGFsZi1kdXBsZXh8QWNjZXB0 IG5vcm1hbCBwYWNrZXRzICovDQorCXByaXYtPm1vZGU9TUVUSF9BQ0NFUFRf TUNBU1R8TUVUSF9ERUZBVUxUX0lQRzsNCisJaWYoZGV2LT5mbGFncyB8IElG Rl9QUk9NSVNDKQ0KKwkJcHJpdi0+bW9kZSB8PSBNRVRIX1BST01JU0M7DQor CXByaXYtPnJlZ3MtPm1hY19jdHJsID0gcHJpdi0+bW9kZTsNCisNCisJLyog QXV0b25lZ29jaWF0ZSBzcGVlZCBhbmQgZHVwbGV4IG1vZGUgKi8NCisJbWV0 aF9jaGVja19saW5rKGRldik7DQorDQorCS8qIE5vdyBzZXQgZG1hIGNvbnRy b2wsIGJ1dCBkb24ndCBlbmFibGUgRE1BLCB5ZXQgKi8NCisJcHJpdi0+cmVn cy0+ZG1hX2N0cmw9ICg0IDw8IE1FVEhfUlhfT0ZGU0VUX1NISUZUKSB8DQor CQkgICAgICAgICAgICAgIChSWF9SSU5HX0VOVFJJRVMgPDwgTUVUSF9SWF9E RVBUSF9TSElGVCk7DQorDQorCXJldHVybigwKTsNCiB9DQogDQogLyo9PT09 PT09PT09PT1FbmQgSGVscGVyIFJvdXRpbmVzPT09PT09PT09PT09PT09PT09 PT09Ki8NCkBAIC0yNjksMTkgKzM2MywyMSBAQA0KIHsNCiAJbWV0aF9wcml2 YXRlICpwcml2PWRldi0+cHJpdjsNCiAJdm9sYXRpbGUgbWV0aF9yZWdzICpy ZWdzPXByaXYtPnJlZ3M7DQotICAgIE1PRF9JTkNfVVNFX0NPVU5UOw0KKw0K KwlNT0RfSU5DX1VTRV9DT1VOVDsNCisNCiAJLyogU3RhcnQgRE1BICovDQog CXJlZ3MtPmRtYV9jdHJsfD0NCi0JCU1FVEhfRE1BX1RYX0VOfC8qTUVUSF9E TUFfVFhfSU5UX0VOfCovDQorCSAgICAgICAgTUVUSF9ETUFfVFhfRU58LypN RVRIX0RNQV9UWF9JTlRfRU58Ki8NCiAJCU1FVEhfRE1BX1JYX0VOfE1FVEhf RE1BX1JYX0lOVF9FTjsNCiANCiAJaWYocmVxdWVzdF9pcnEoZGV2LT5pcnEs bWV0aF9pbnRlcnJ1cHQsU0FfU0hJUlEsbWV0aF9zdHIsZGV2KSl7DQogCQlw cmludGsoS0VSTl9FUlIgIiVzOiBDYW4ndCBnZXQgaXJxICVkXG4iLCBkZXYt Pm5hbWUsIGRldi0+aXJxKTsNCiAJCXJldHVybiAtRUFHQUlOOw0KIAl9DQot ICAgIG5ldGlmX3N0YXJ0X3F1ZXVlKGRldik7DQorCW5ldGlmX3N0YXJ0X3F1 ZXVlKGRldik7DQogCURQUklOVEsoIk9wZW5lZC4uLiBETUEgY29udHJvbD0w eCUwOGx4XG4iLCByZWdzLT5kbWFfY3RybCk7DQotICAgIHJldHVybiAwOw0K KwlyZXR1cm4gMDsNCiB9DQogDQogaW50IG1ldGhfcmVsZWFzZShzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KQEAgLTMzMCw2MCArNDI2LDg3IEBADQogICAg IHN0cnVjdCBtZXRoX3ByaXZhdGUgKnByaXYgPSAoc3RydWN0IG1ldGhfcHJp dmF0ZSAqKSBkZXYtPnByaXY7DQogCXJ4X3BhY2tldCAqcnhiOw0KIAlEUFJJ TlRLKCJSWC4uLlxuIik7DQorCS8vIFRFTVAJd2hpbGUoKHJ4Yj1wcml2LT5y eF9yaW5nW3ByaXYtPnJ4X3dyaXRlXSktPnN0YXR1cy5yYXcmMHg4MDAwMDAw MDAwMDAwMDAwKXsNCiAJd2hpbGUoKHJ4Yj1wcml2LT5yeF9yaW5nW3ByaXYt PnJ4X3dyaXRlXSktPnN0YXR1cy5yYXcmMHg4MDAwMDAwMDAwMDAwMDAwKXsN Ci0JCWludCBsZW49cnhiLT5zdGF0dXMucGFyc2VkLnJ4X2xlbjsNCi0JCURQ UklOVEsoIlx0cHJpdi0+dHhfd3JpdGU9JWlcbiIscHJpdi0+cnhfd3JpdGUp Ow0KKwkgICAgICAgIGludCBsZW49cnhiLT5zdGF0dXMucGFyc2VkLnJ4X2xl biAtIDQ7IC8qIG9taXQgQ1JDICovDQorCQlEUFJJTlRLKCIoJWkpXG4iLHBy aXYtPnJ4X3dyaXRlKTsNCisJCS8qIGxlbmd0aCBzYW5pdHkgY2hlY2sgKi8N CisJCWlmKGxlbiA8IDYwIHx8IGxlbiA+IDE1MTgpIHsNCisJCSAgcHJpbnRr KEtFUk5fREVCVUcgIiVzOiBib2d1cyBwYWNrZXQgc2l6ZTogJWQsIHN0YXR1 cz0lIzJ4LlxuIiwNCisJCQkgZGV2LT5uYW1lLCBwcml2LT5yeF93cml0ZSwg cnhiLT5zdGF0dXMucmF3KTsNCisJCSAgcHJpdi0+c3RhdHMucnhfZXJyb3Jz Kys7DQorCQkgIHByaXYtPnN0YXRzLnJ4X2xlbmd0aF9lcnJvcnMrKzsNCisJ CX0NCiAJCWlmKCEocnhiLT5zdGF0dXMucmF3Jk1FVEhfUlhfU1RBVFVTX0VS Uk9SUykpew0KLQkJCURQUklOVEsoIlBhY2tldCBoYWQgbm8gZXJyb3JzLi4u XG4iKTsNCiAJCQlza2I9YWxsb2Nfc2tiKGxlbisyLEdGUF9BVE9NSUMpOy8q IFNob3VsZCBiZSBhdG9taWMgLS0gd2UgYXJlIGluIGludGVycnVwdCAqLw0K IAkJCWlmKCFza2Ipew0KIAkJCQkvKiBPdWNoISBObyBtZW1vcnkhIERyb3Ag cGFja2V0IG9uIHRoZSBmbG9vciAqLw0KIAkJCQlEUFJJTlRLKCIhISE+Pj5P dWNoISBOb3QgZW5vdWdoIE1lbW9yeSBmb3IgUlggYnVmZmVyIVxuIik7DQot CQkJCXByaXYtPnN0YXRzLnR4X2Ryb3BwZWQrKzsNCisJCQkJcHJpdi0+c3Rh dHMucnhfZHJvcHBlZCsrOw0KIAkJCX0gZWxzZSB7DQotCQkJCURQUklOVEso IkFuZCB0aGVyZSB3YXMgbm8gcHJvYmxlbSBnZXR0aW5nIG5ldyBza2IuLi5c biIpOw0KIAkJCQlza2JfcmVzZXJ2ZShza2IsIDIpOyAvKiBhbGlnbiBJUCBv biAxNkIgYm91bmRhcnkgKi8gIA0KICAgICAJCQltZW1jcHkoc2tiX3B1dChz a2IsIGxlbiksIHJ4Yi0+YnVmLCBsZW4pOw0KIAkJCSAgICAvKiBXcml0ZSBt ZXRhZGF0YSwgYW5kIHRoZW4gcGFzcyB0byB0aGUgcmVjZWl2ZSBsZXZlbCAq Lw0KIAkJCSAgICBza2ItPmRldiA9IGRldjsNCiAJCQkgICAgc2tiLT5wcm90 b2NvbCA9IGV0aF90eXBlX3RyYW5zKHNrYiwgZGV2KTsNCiAJCQkJLy9za2It PmlwX3N1bW1lZCA9IENIRUNLU1VNX1VOTkVDRVNTQVJZOyAvKiBkb24ndCBj aGVjayBpdCAqLw0KLQkJCSAgICBwcml2LT5zdGF0cy5yeF9wYWNrZXRzKys7 DQotCQkJCURQUklOVEsoIldlIGFyZSBhYm91dCB0byBwYXNzIHBhY2tldCB1 cFxuIik7DQotICAgIAkJCW5ldGlmX3J4KHNrYik7DQorCQkJICAgDQorCQkJ CURQUklOVEsoInBhc3NpbmcgcGFja2V0XG4iKTsNCisJCQkJRFBSSU5USygi bGVuID0gJWQgcnhiLT5zdGF0dXMgPSAleFxuIiwNCisJCQkJCWxlbiwgcnhi LT5zdGF0dXMucmF3KTsNCisJCQkJbmV0aWZfcngoc2tiKTsNCisJCQkJZGV2 LT5sYXN0X3J4ID0gamlmZmllczsNCisJCQkJcHJpdi0+c3RhdHMucnhfcGFj a2V0cysrOw0KKwkJCQlwcml2LT5zdGF0cy5yeF9ieXRlcys9bGVuOw0KIAkJ CQlEUFJJTlRLKCJUaGVyZSB3ZSBnby4uLiBXaGV3Li4uXG4iKTsNCiAJCQl9 DQogCQl9DQotCQlyeGItPnN0YXR1cy5yYXc9MDsNCiAJCXByaXYtPnJlZ3Mt PnJ4X2ZpZm89cHJpdi0+cnhfcmluZ19kbWFzW3ByaXYtPnJ4X3dyaXRlXTsN CisJCXJ4Yi0+c3RhdHVzLnJhdz0wOwkJDQogCQlwcml2LT5yeF93cml0ZT0o cHJpdi0+cnhfd3JpdGUrMSkmKFJYX1JJTkdfRU5UUklFUy0xKTsNCiAJfQ0K IH0NCiANCitzdGF0aWMgaW50IG1ldGhfdHhfZnVsbChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KQ0KK3sNCisJc3RydWN0IG1ldGhfcHJpdmF0ZSAqcHJpdiA9 IChzdHJ1Y3QgbWV0aF9wcml2YXRlICopIGRldi0+cHJpdjsNCisNCisJcmV0 dXJuKHByaXYtPnR4X2NvdW50ID49IFRYX1JJTkdfRU5UUklFUy0xKTsNCit9 DQorDQogdm9pZCBtZXRoX3R4X2NsZWFudXAoc3RydWN0IG5ldF9kZXZpY2Uq IGRldiwgaW50IHJwdHIpDQogew0KIAltZXRoX3ByaXZhdGUgKnByaXY9ZGV2 LT5wcml2Ow0KLQkvL3ZvbGF0aWxlIG1ldGhfcmVncyogcmVncz1wcml2LT5y ZWdzOw0KIAl0eF9wYWNrZXQqIHN0YXR1czsNCi0Jc3RydWN0IHNrX2J1ZmYq IHNrYjsNCi0JRFBSSU5USygiVFguLi5cbiIpOw0KKwlzdHJ1Y3Qgc2tfYnVm ZiAqc2tiOw0KKw0KIAlzcGluX2xvY2soJnByaXYtPm1ldGhfbG9jayk7DQot CXByaXYtPnJlZ3MtPmRtYV9jdHJsJj1+KE1FVEhfRE1BX1RYX0lOVF9FTik7 DQotCXdoaWxlKHByaXYtPnR4X3JlYWQhPXJwdHIpew0KLQkJc2tiPXByaXYt PnR4X3NrYnNbcHJpdi0+dHhfcmVhZF07DQotCQlzdGF0dXM9JnByaXYtPnR4 X3JpbmdbcHJpdi0+dHhfcmVhZF07DQorDQorCS8qIFN0b3AgRE1BICovDQor CXByaXYtPnJlZ3MtPmRtYV9jdHJsICY9IH4oTUVUSF9ETUFfVFhfSU5UX0VO KTsNCisNCisJd2hpbGUocHJpdi0+dHhfcmVhZCAhPSBycHRyKXsNCisJCXNr YiA9IHByaXYtPnR4X3NrYnNbcHJpdi0+dHhfcmVhZF07DQorCQlzdGF0dXMg PSAmcHJpdi0+dHhfcmluZ1twcml2LT50eF9yZWFkXTsNCiAJCWlmKCFzdGF0 dXMtPmhlYWRlci5yZXMuc2VudCkNCiAJCQlicmVhazsNCi0JCWlmKHN0YXR1 cy0+aGVhZGVyLnJhdyZNRVRIX1RYX1NUQVRVU19ET05FKXsNCisJCWlmKHN0 YXR1cy0+aGVhZGVyLnJhdyAmIE1FVEhfVFhfU1RBVFVTX0RPTkUpIHsNCiAJ CQlwcml2LT5zdGF0cy50eF9wYWNrZXRzKys7DQotCQkJcHJpdi0+c3RhdHMu dHhfYnl0ZXMrPXNrYi0+bGVuOw0KKwkJCXByaXYtPnN0YXRzLnR4X2J5dGVz ICs9IHNrYi0+bGVuOw0KIAkJfQ0KLSAgICAgICAgZGV2X2tmcmVlX3NrYihz a2IpOw0KLQkJc3RhdHVzLT5oZWFkZXIucmF3PTA7DQotCQlwcml2LT50eF9y ZWFkPShwcml2LT50eF9yZWFkKzEpJihUWF9SSU5HX0VOVFJJRVMtMSk7DQor CQlkZXZfa2ZyZWVfc2tiX2lycShza2IpOw0KKwkJcHJpdi0+dHhfc2tic1tw cml2LT50eF9yZWFkXSA9IE5VTEw7DQorCQlzdGF0dXMtPmhlYWRlci5yYXcg PSAwOw0KKwkJcHJpdi0+dHhfcmVhZCA9IChwcml2LT50eF9yZWFkKzEpJihU WF9SSU5HX0VOVFJJRVMtMSk7DQorCQlwcml2LT50eF9jb3VudCAtLTsNCiAJ fQ0KKw0KKwkvKiB3YWtlIHVwIHF1ZXVlIGlmIGl0IHdhcyBzdG9wcGVkICov DQorCWlmIChuZXRpZl9xdWV1ZV9zdG9wcGVkKGRldikgJiYgISBtZXRoX3R4 X2Z1bGwoZGV2KSkgew0KKwkJbmV0aWZfd2FrZV9xdWV1ZShkZXYpOw0KKwl9 DQorDQogCXNwaW5fdW5sb2NrKHByaXYtPm1ldGhfbG9jayk7DQotCW5ldGlm X3dha2VfcXVldWUoZGV2KTsNCiB9DQogDQogLyoNCkBAIC0zOTEsOCArNTE0 LDcgQEANCiAgKi8NCiB2b2lkIG1ldGhfaW50ZXJydXB0KGludCBpcnEsIHZv aWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnByZWdzKQ0KIHsNCi0gICAg c3RydWN0IG1ldGhfcHJpdmF0ZSAqcHJpdjsNCi0JLy92b2xhdGlsZSBtZXRo X3JlZ3MqIHJlZ3M7DQorCXN0cnVjdCBtZXRoX3ByaXZhdGUgKnByaXY7DQog CXVuaW9uIHsNCiAJCXUzMglyZWc7IC8qV2hvbGUgc3RhdHVzIHJlZ2lzdGVy ICovDQogCQlzdHJ1Y3Qgew0KQEAgLTQwNCw0OCArNTI2LDU0IEBADQogCQkJ CWludF9tYXNrOgk4Ow0KIAkJfSBwYXJzZWQ7DQogCX0gc3RhdHVzOw0KLSAg ICAvKg0KLSAgICAgKiBBcyB1c3VhbCwgY2hlY2sgdGhlICJkZXZpY2UiIHBv aW50ZXIgZm9yIHNoYXJlZCBoYW5kbGVycy4NCi0gICAgICogVGhlbiBhc3Np Z24gInN0cnVjdCBkZXZpY2UgKmRldiINCi0gICAgICovDQotICAgIHN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSAoc3RydWN0IG5ldF9kZXZpY2UgKilkZXZf aWQ7DQotICAgIC8qIC4uLiBhbmQgY2hlY2sgd2l0aCBodyBpZiBpdCdzIHJl YWxseSBvdXJzICovDQotDQotICAgIGlmICghZGV2IC8qcGFyYW5vaWQqLyAp IHJldHVybjsNCi0NCi0gICAgLyogTG9jayB0aGUgZGV2aWNlICovDQotICAg IHByaXYgPSAoc3RydWN0IG1ldGhfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQot ICAgIHNwaW5fbG9jaygmcHJpdi0+bWV0aF9sb2NrKTsNCisJLyoNCisJICog QXMgdXN1YWwsIGNoZWNrIHRoZSAiZGV2aWNlIiBwb2ludGVyIGZvciBzaGFy ZWQgaGFuZGxlcnMuDQorCSAqIFRoZW4gYXNzaWduICJzdHJ1Y3QgZGV2aWNl ICpkZXYiDQorCSAqLw0KKwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gKHN0 cnVjdCBuZXRfZGV2aWNlICopZGV2X2lkOw0KKwkvKiAuLi4gYW5kIGNoZWNr IHdpdGggaHcgaWYgaXQncyByZWFsbHkgb3VycyAqLw0KIA0KLSAgICBzdGF0 dXMucmVnID0gcHJpdi0+cmVncy0+aW50X2ZsYWdzOw0KLQlwcml2LT5yZWdz LT5pbnRfZmxhZ3M9c3RhdHVzLnJlZyYweGZmOyAvKiBjbGVhciBpbnRlcnJ1 cHRzICovDQorCWlmICghZGV2IC8qcGFyYW5vaWQqLyApIHJldHVybjsNCisN CisJLyogTG9jayB0aGUgZGV2aWNlICovDQorCXByaXYgPSAoc3RydWN0IG1l dGhfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQorDQorCXN0YXR1cy5yZWcgPSBw cml2LT5yZWdzLT5pbnRfZmxhZ3M7DQorICAgIA0KIAlEUFJJTlRLKCJJbnRl cnJ1cHQsIHN0YXR1cyAlMDh4Li4uXG4iLHN0YXR1cy5yZWcpOw0KLSAgICBp ZiAoc3RhdHVzLnBhcnNlZC5pbnRfbWFzayAmIE1FVEhfSU5UX1JYX1RIUkVT SE9MRCkgew0KLSAgICAgICAgLyogc2VuZCBpdCB0byBtZXRoX3J4IGZvciBo YW5kbGluZyAqLw0KLSAgICAgICAgbWV0aF9yeChkZXYpOw0KLSAgICB9DQot ICAgIGlmIChzdGF0dXMucGFyc2VkLmludF9tYXNrICYgKE1FVEhfSU5UX1RY X0VNUFRZfE1FVEhfSU5UX1RYX1BLVCkpIHsNCi0gICAgICAgIC8qIGEgdHJh bnNtaXNzaW9uIGlzIG92ZXI6IGZyZWUgdGhlIHNrYiAqLw0KLQkJbWV0aF90 eF9jbGVhbnVwKGRldixzdGF0dXMucGFyc2VkLnR4X3JlYWQpOw0KLSAgICB9 DQotCS8qIGNoZWNrIGZvciBlcnJvcnMgdG9vLi4uICovDQorCWlmIChzdGF0 dXMucGFyc2VkLmludF9tYXNrICYgTUVUSF9JTlRfUlhfVEhSRVNIT0xEKSB7 DQorCQkvKiBzZW5kIGl0IHRvIG1ldGhfcnggZm9yIGhhbmRsaW5nICovDQor CQltZXRoX3J4KGRldik7DQorCX0NCiANCisJaWYgKHN0YXR1cy5wYXJzZWQu aW50X21hc2sgJiAoTUVUSF9JTlRfVFhfRU1QVFl8TUVUSF9JTlRfVFhfUEtU KSkgew0KKwkJLyogYSB0cmFuc21pc3Npb24gaXMgb3ZlcjogZnJlZSB0aGUg c2tiICovDQorCQltZXRoX3R4X2NsZWFudXAoZGV2LCBzdGF0dXMucGFyc2Vk LnR4X3JlYWQpOw0KKwl9DQorCS8qIGNoZWNrIGZvciBlcnJvcnMgdG9vLi4u ICovDQorCWlmIChzdGF0dXMucGFyc2VkLmludF9tYXNrICYgKE1FVEhfSU5U X1RYX0xJTktfRkFJTCkpDQorCQlwcmludGsoS0VSTl9XQVJOSU5HICJtZXRo OiBsaW5rIGZhaWx1cmVcbiIpOw0KKwlpZiAoc3RhdHVzLnBhcnNlZC5pbnRf bWFzayAmIChNRVRIX0lOVF9NRU1fRVJST1IpKQ0KKwkJcHJpbnRrKEtFUk5f V0FSTklORyAibWV0aDogbWVtb3J5IGVycm9yXG4iKTsNCisJaWYgKHN0YXR1 cy5wYXJzZWQuaW50X21hc2sgJiAoTUVUSF9JTlRfVFhfQUJPUlQpKQ0KKwkJ cHJpbnRrKEtFUk5fV0FSTklORyAibWV0aDogYWJvcnRlZFxuIik7DQogCURQ UklOVEsoIkludGVycnVwdCBoYW5kbGluZyBkb25lLi4uXG4iKTsNCi0gICAg LyogVW5sb2NrIHRoZSBkZXZpY2UgYW5kIHdlIGFyZSBkb25lICovDQotICAg IHNwaW5fdW5sb2NrKCZwcml2LT5tZXRoX2xvY2spOw0KKwkNCisJcHJpdi0+ cmVncy0+aW50X2ZsYWdzPXN0YXR1cy5yZWcmMHhmZjsgLyogY2xlYXIgaW50 ZXJydXB0cyAqLw0KIH0NCiANCiAvKg0KLSAqIFRyYW5zbWl0cyBwYWNrZXRz IHRoYXQgZml0IGludG8gVFggZGVzY3JpYnRvciAoYXJlIDw9MTIwQikNCisg KiBUcmFuc21pdHMgcGFja2V0cyB0aGF0IGZpdCBpbnRvIFRYIGRlc2NyaXB0 b3IgKGFyZSA8PTEyMEIpDQogICovDQogc3RhdGljIHZvaWQgbWV0aF90eF9z aG9ydF9wcmVwYXJlKG1ldGhfcHJpdmF0ZSogcHJpdiwgc3RydWN0IHNrX2J1 ZmYqIHNrYikNCiB7DQogCXR4X3BhY2tldCAqZGVzYz0mcHJpdi0+dHhfcmlu Z1twcml2LT50eF93cml0ZV07DQotCWludCBsZW49KHNrYi0+bGVuPEVUSF9a TEVOKT9FVEhfWkxFTjpza2ItPmxlbjsNCi0JRFBSSU5USygiU2hvcnQgcGFj a2V0Li4uIFxuIik7DQotCS8qIGFteWJlIEkgc2hvdWxkIHNldCB3aG9sZSB0 aGluZyB0byAwIGZpcnN0Li4uICovDQorCWludCBsZW4gPSAoc2tiLT5sZW48 RVRIX1pMRU4pP0VUSF9aTEVOOnNrYi0+bGVuOw0KKw0KKwlEUFJJTlRLKCJw cmVwYXJpbmcgc2hvcnQgcGFja2V0XG4iKTsNCisJLyogbWF5YmUgSSBzaG91 bGQgc2V0IHdob2xlIHRoaW5nIHRvIDAgZmlyc3QuLi4gKi8NCiAJbWVtY3B5 KGRlc2MtPmRhdGEuZHQrKDEyMC1sZW4pLHNrYi0+ZGF0YSxza2ItPmxlbik7 DQotCWlmKHNrYi0+bGVuPGxlbikNCisJaWYoc2tiLT5sZW4gPCBsZW4pDQog CQltZW1zZXQoZGVzYy0+ZGF0YS5kdCsxMjAtbGVuK3NrYi0+bGVuLDAsbGVu LXNrYi0+bGVuKTsNCiAJZGVzYy0+aGVhZGVyLnJhdz1NRVRIX1RYX0NNRF9J TlRfRU58KGxlbi0xKXwoKDEyOC1sZW4pPDwxNik7DQogCURQUklOVEsoImRl c2M9JTAxNmx4XG4iLGRlc2MtPmhlYWRlci5yYXcpOw0KQEAgLTQ1NCw4NiAr NTgyLDE3MiBAQA0KIHN0YXRpYyB2b2lkIG1ldGhfdHhfMXBhZ2VfcHJlcGFy ZShtZXRoX3ByaXZhdGUqIHByaXYsIHN0cnVjdCBza19idWZmKiBza2IpDQog ew0KIAl0eF9wYWNrZXQgKmRlc2M9JnByaXYtPnR4X3JpbmdbcHJpdi0+dHhf d3JpdGVdOw0KLQl2b2lkICpkYXRhPXNrYi0+ZGF0YTsNCi0JaW50IGxlbj0o dTY0KWRhdGEmMHg3Ow0KKwl2b2lkICpidWZmZXJfZGF0YSA9ICh2b2lkICop KCgodTY0KXNrYi0+ZGF0YSArIDdVTEwpICYgKH43VUxMKSk7DQorCWludCB1 bmFsaWduZWRfbGVuID0gKGludCkoKHU2NClidWZmZXJfZGF0YSAtICh1NjQp c2tiLT5kYXRhKTsNCisJaW50IGJ1ZmZlcl9sZW4gPSBza2ItPmxlbiAtIHVu YWxpZ25lZF9sZW47DQogCWRtYV9hZGRyX3QgY2F0YnVmOw0KKw0KKwlEUFJJ TlRLKCJwcmVwYXJpbmcgMSBwYWdlLi4uXG4iKTsNCisJRFBSSU5USygibGVu Z3RoPSVkIGRhdGE9JXBcbiIsIHNrYi0+bGVuLCBza2ItPmRhdGEpOw0KKwlE UFJJTlRLKCJ1bmFsaWduZWRfbGVuPSVkXG4iLCB1bmFsaWduZWRfbGVuKTsN CisJRFBSSU5USygiYnVmZmVyX2RhdGE9JXAgYnVmZmVyX2xlbj0lZFxuIiwN CisJICAgICAgIGJ1ZmZlcl9kYXRhLA0KKwkgICAgICAgYnVmZmVyX2xlbik7 DQorDQogCWRlc2MtPmhlYWRlci5yYXc9TUVUSF9UWF9DTURfSU5UX0VOfFRY X0NBVEJVRjF8KHNrYi0+bGVuLTEpOw0KLQlpZihsZW4pew0KLQkJbWVtY3B5 KGRlc2MtPmRhdGEuZHQrKDEyMC1sZW4pLGRhdGEsbGVuKTsNCi0JCWRlc2Mt PmhlYWRlci5yYXd8PSgxMjgtbGVuKTw8MTY7DQotCX0NCi0JZGF0YSs9bGVu Ow0KLQkvKiBJJ2xsIGp1c3QgcHJldGVuZCBJIGtub3cgZm9yIHN1cmUgdGhh dCBwY2lfdW5tYXBfc2luZ2xlIGlzIE5PUCAqLw0KLQljYXRidWY9cGNpX21h cF9zaW5nbGUoTlVMTCxkYXRhLHNrYi0+bGVuLWxlbixQQ0lfRE1BX1RPREVW SUNFKTsNCi0JZGVzYy0+ZGF0YS5jYXRfYnVmWzBdLnJhdz1jYXRidWZ8KChz a2ItPmxlbi1sZW4tMSk8PDMxKTsNCisNCisJLyogdW5hbGlnbmVkIHBhcnQg Ki8NCisJaWYodW5hbGlnbmVkX2xlbil7DQorCQltZW1jcHkoZGVzYy0+ZGF0 YS5kdCsoMTIwLXVuYWxpZ25lZF9sZW4pLA0KKwkJICAgICAgIHNrYi0+ZGF0 YSwgdW5hbGlnbmVkX2xlbik7DQorCQlkZXNjLT5oZWFkZXIucmF3IHw9ICgx MjgtdW5hbGlnbmVkX2xlbikgPDwgMTY7DQorCX0NCisNCisJLyogZmlyc3Qg cGFnZSAqLw0KKwljYXRidWYgPSBwY2lfbWFwX3NpbmdsZShOVUxMLA0KKwkJ CQlidWZmZXJfZGF0YSwNCisJCQkJYnVmZmVyX2xlbiwNCisJCQkJUENJX0RN QV9UT0RFVklDRSk7DQorCURQUklOVEsoImNhdGJ1Zj0leFxuIiwgY2F0YnVm KTsNCisJZGVzYy0+ZGF0YS5jYXRfYnVmWzBdLmZvcm0uc3RhcnRfYWRkciA9 IGNhdGJ1ZiA+PiAzOw0KKwlkZXNjLT5kYXRhLmNhdF9idWZbMF0uZm9ybS5s ZW4gPSBidWZmZXJfbGVuLTE7DQorCURQUklOVEsoImRlc2M9JTAxNmx4XG4i LGRlc2MtPmhlYWRlci5yYXcpOw0KKwlEUFJJTlRLKCJjYXRfYnVmWzBdLnJh dz0lMDE2bHhcbiIsZGVzYy0+ZGF0YS5jYXRfYnVmWzBdLnJhdyk7DQogfQ0K ICNkZWZpbmUgVFhfQ0FUQlVGMiBCSVQoMjYpDQogc3RhdGljIHZvaWQgbWV0 aF90eF8ycGFnZV9wcmVwYXJlKG1ldGhfcHJpdmF0ZSogcHJpdiwgc3RydWN0 IHNrX2J1ZmYqIHNrYikNCiB7DQogCXR4X3BhY2tldCAqZGVzYz0mcHJpdi0+ dHhfcmluZ1twcml2LT50eF93cml0ZV07DQotCXZvaWQgKmRhdGE9c2tiLT5k YXRhOw0KLQlpbnQgbGVuPSh1NjQpZGF0YSYweDc7DQotCWRtYV9hZGRyX3Qg Y2F0YnVmMSxjYXRidWYyOw0KKwl2b2lkICpidWZmZXIxX2RhdGEgPSAodm9p ZCAqKSgoKHU2NClza2ItPmRhdGEgKyA3VUxMKSAmICh+N1VMTCkpOw0KKwl2 b2lkICpidWZmZXIyX2RhdGEgPSAodm9pZCAqKVBBR0VfQUxJR04oKHU2NClz a2ItPmRhdGEpOw0KKwlpbnQgdW5hbGlnbmVkX2xlbiA9IChpbnQpKCh1NjQp YnVmZmVyMV9kYXRhIC0gKHU2NClza2ItPmRhdGEpOw0KKwlpbnQgYnVmZmVy MV9sZW4gPSAoaW50KSgodTY0KWJ1ZmZlcjJfZGF0YSAtICh1NjQpYnVmZmVy MV9kYXRhKTsNCisJaW50IGJ1ZmZlcjJfbGVuID0gc2tiLT5sZW4gLSBidWZm ZXIxX2xlbiAtIHVuYWxpZ25lZF9sZW47DQorCWRtYV9hZGRyX3QgY2F0YnVm MSwgY2F0YnVmMjsNCisNCisJRFBSSU5USygicHJlcGFyaW5nIDIgcGFnZXMu Li4gXG4iKTsNCisJRFBSSU5USygibGVuZ3RoPSVkIGRhdGE9JXBcbiIsIHNr Yi0+bGVuLCBza2ItPmRhdGEpOw0KKwlEUFJJTlRLKCJ1bmFsaWduZWRfbGVu PSVkXG4iLCB1bmFsaWduZWRfbGVuKTsNCisJRFBSSU5USygiYnVmZmVyMV9k YXRhPSVwIGJ1ZmZlcjFfbGVuPSVkXG4iLA0KKwkgICAgICAgYnVmZmVyMV9k YXRhLA0KKwkgICAgICAgYnVmZmVyMV9sZW4pOw0KKwlEUFJJTlRLKCJidWZm ZXIyX2RhdGE9JXAgYnVmZmVyMl9sZW49JWRcbiIsDQorCSAgICAgICBidWZm ZXIyX2RhdGEsDQorCSAgICAgICBidWZmZXIyX2xlbik7DQorDQogCWRlc2Mt PmhlYWRlci5yYXc9TUVUSF9UWF9DTURfSU5UX0VOfFRYX0NBVEJVRjF8VFhf Q0FUQlVGMnwoc2tiLT5sZW4tMSk7DQotCWlmKGxlbil7DQotCQltZW1jcHko ZGVzYy0+ZGF0YS5kdCsoMTIwLWxlbiksZGF0YSxsZW4pOw0KLQkJZGVzYy0+ aGVhZGVyLnJhd3w9KDEyOC1sZW4pPDwxNjsNCi0JfQ0KLQlkYXRhKz1sZW47 DQotCS8qIEknbGwganVzdCBwcmV0ZW5kIEkga25vdyBmb3Igc3VyZSB0aGF0 IHBjaV91bm1hcF9zaW5nbGUgaXMgTk9QICovDQotCWNhdGJ1ZjE9cGNpX21h cF9zaW5nbGUoTlVMTCxkYXRhLHNrYi0+bGVuLWxlbixQQ0lfRE1BX1RPREVW SUNFKTsNCi0JZGVzYy0+ZGF0YS5jYXRfYnVmWzBdLnJhdz1jYXRidWYxfCgo c2tiLT5sZW4tbGVuLTEpPDwzMSk7DQotCWxlbj0odTY0KWRhdGEmMHhGRkY7 DQotCWRhdGErPWxlbjsNCi0JY2F0YnVmMj1wY2lfbWFwX3NpbmdsZShOVUxM LGRhdGEsc2tiLT5sZW4tKCh1NjQpZGF0YS0odTY0KXNrYi0+ZGF0YSksUENJ X0RNQV9UT0RFVklDRSk7DQotCWRlc2MtPmRhdGEuY2F0X2J1ZlsxXS5yYXc9 Y2F0YnVmMnwoKHNrYi0+bGVuLSgodTY0KWRhdGEtKHU2NClza2ItPmRhdGEp KTw8MzEpOw0KKwkvKiB1bmFsaWduZWQgcGFydCAqLw0KKwlpZih1bmFsaWdu ZWRfbGVuKXsNCisJCW1lbWNweShkZXNjLT5kYXRhLmR0KygxMjAtdW5hbGln bmVkX2xlbiksDQorCQkgICAgICAgc2tiLT5kYXRhLCB1bmFsaWduZWRfbGVu KTsNCisJCWRlc2MtPmhlYWRlci5yYXcgfD0gKDEyOC11bmFsaWduZWRfbGVu KSA8PCAxNjsNCisJfQ0KKw0KKwkvKiBmaXJzdCBwYWdlICovDQorCWNhdGJ1 ZjEgPSBwY2lfbWFwX3NpbmdsZShOVUxMLA0KKwkJCQkgYnVmZmVyMV9kYXRh LA0KKwkJCQkgYnVmZmVyMV9sZW4sDQorCQkJCSBQQ0lfRE1BX1RPREVWSUNF KTsNCisJRFBSSU5USygiY2F0YnVmMT0leFxuIiwgY2F0YnVmMSk7DQorCWRl c2MtPmRhdGEuY2F0X2J1ZlswXS5mb3JtLnN0YXJ0X2FkZHIgPSBjYXRidWYx ID4+IDM7DQorCWRlc2MtPmRhdGEuY2F0X2J1ZlswXS5mb3JtLmxlbiA9IGJ1 ZmZlcjFfbGVuLTE7DQorCS8qIHNlY29uZCBwYWdlICovDQorCWNhdGJ1ZjIg PSBwY2lfbWFwX3NpbmdsZShOVUxMLA0KKwkJCQkgYnVmZmVyMl9kYXRhLA0K KwkJCQkgYnVmZmVyMl9sZW4sDQorCQkJCSBQQ0lfRE1BX1RPREVWSUNFKTsN CisJRFBSSU5USygiY2F0YnVmMj0leFxuIiwgY2F0YnVmMik7DQorCWRlc2Mt PmRhdGEuY2F0X2J1ZlsxXS5mb3JtLnN0YXJ0X2FkZHIgPSBjYXRidWYyID4+ IDM7DQorCWRlc2MtPmRhdGEuY2F0X2J1ZlsxXS5mb3JtLmxlbiA9IGJ1ZmZl cjJfbGVuLTE7DQorCURQUklOVEsoImRlc2M9JTAxNmx4XG4iLGRlc2MtPmhl YWRlci5yYXcpOw0KKwlEUFJJTlRLKCJjYXRfYnVmWzBdLnJhdz0lMDE2bHhc biIsZGVzYy0+ZGF0YS5jYXRfYnVmWzBdLnJhdyk7DQorCURQUklOVEsoImNh dF9idWZbMV0ucmF3PSUwMTZseFxuIixkZXNjLT5kYXRhLmNhdF9idWZbMV0u cmF3KTsNCiB9DQorDQorDQordm9pZCBtZXRoX2FkZF90b190eF9yaW5nKG1l dGhfcHJpdmF0ZSAqcHJpdiwgc3RydWN0IHNrX2J1ZmYqIHNrYikNCit7DQor CURQUklOVEsoIlRyYW5zbWl0dGluZyBkYXRhLi4uXG4iKTsNCisJaWYoc2ti LT5sZW4gPD0gMTIwKSB7DQorCQkvKiBXaG9sZSBwYWNrZXQgZml0cyBpbnRv IGRlc2NyaXB0b3IgKi8NCisJCW1ldGhfdHhfc2hvcnRfcHJlcGFyZShwcml2 LHNrYik7DQorCX0gZWxzZSBpZihQQUdFX0FMSUdOKCh1NjQpc2tiLT5kYXRh KSAhPQ0KKwkJICBQQUdFX0FMSUdOKCh1NjQpc2tiLT5kYXRhK3NrYi0+bGVu LTEpKSB7DQorCQkvKiBQYWNrZXQgY3Jvc3NlcyBwYWdlIGJvdW5kYXJ5ICov DQorCQltZXRoX3R4XzJwYWdlX3ByZXBhcmUocHJpdixza2IpOw0KKwl9IGVs c2Ugew0KKwkJLyogUGFja2V0IGlzIGluIG9uZSBwYWdlICovDQorCQltZXRo X3R4XzFwYWdlX3ByZXBhcmUocHJpdixza2IpOw0KKwl9DQorDQorCS8qIFJl bWVtYmVyIHRoZSBza2IsIHNvIHdlIGNhbiBmcmVlIGl0IGF0IGludGVycnVw dCB0aW1lICovDQorCXByaXYtPnR4X3NrYnNbcHJpdi0+dHhfd3JpdGVdID0g c2tiOw0KKwlwcml2LT50eF93cml0ZSA9IChwcml2LT50eF93cml0ZSsxKSAm IChUWF9SSU5HX0VOVFJJRVMtMSk7DQorCXByaXYtPnJlZ3MtPnR4X2luZm8u d3B0ciA9IHByaXYtPnR4X3dyaXRlOw0KKwlwcml2LT50eF9jb3VudCArKzsN CisJLyogRW5hYmxlIERNQSB0cmFuc2ZlciAqLw0KKwlwcml2LT5yZWdzLT5k bWFfY3RybCB8PSBNRVRIX0RNQV9UWF9JTlRfRU47DQorfQ0KKw0KIC8qDQog ICogVHJhbnNtaXQgYSBwYWNrZXQgKGNhbGxlZCBieSB0aGUga2VybmVsKQ0K ICAqLw0KIGludCBtZXRoX3R4KHN0cnVjdCBza19idWZmICpza2IsIHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQogew0KLSAgICBzdHJ1Y3QgbWV0aF9wcml2 YXRlICpwcml2ID0gKHN0cnVjdCBtZXRoX3ByaXZhdGUgKikgZGV2LT5wcml2 Ow0KKwlzdHJ1Y3QgbWV0aF9wcml2YXRlICpwcml2ID0gKHN0cnVjdCBtZXRo X3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KIA0KLSAgICBzcGluX2xvY2soJnBy aXYtPm1ldGhfbG9jayk7DQotCURQUklOVEsoIlRyYW5zbWl0dGluZyBkYXRh Li4uXG4iKTsNCi0JaWYoc2tiLT5sZW48PTEyMCkgLyogV2hvbGUgdGhpbmcg Zml0cyBpbnRvIGRlc2NyaXB0b3IgKi8NCi0JCW1ldGhfdHhfc2hvcnRfcHJl cGFyZShwcml2LHNrYik7DQotCWVsc2UgaWYoKCh1NjQpKHNrYi0+ZGF0YSkm MHhGRkYpPHNrYi0+bGVuKSAvKiBQYWNrZXQgY3Jvc3NlcyBwYWdlIGJvdW5k YXJ5ICovDQotCQltZXRoX3R4XzJwYWdlX3ByZXBhcmUocHJpdixza2IpOw0K LQllbHNlIC8qIFBhY2tldCBpcyBpbiBvbmUgcGFnZSAqLw0KLQkJbWV0aF90 eF8xcGFnZV9wcmVwYXJlKHByaXYsc2tiKTsNCi0gICAgZGV2LT50cmFuc19z dGFydCA9IGppZmZpZXM7IC8qIHNhdmUgdGhlIHRpbWVzdGFtcCAqLw0KKwlz cGluX2xvY2tfaXJxKCZwcml2LT5tZXRoX2xvY2spOw0KIA0KLSAgICAvKiBS ZW1lbWJlciB0aGUgc2tiLCBzbyB3ZSBjYW4gZnJlZSBpdCBhdCBpbnRlcnJ1 cHQgdGltZSAqLw0KLSAgICBwcml2LT50eF9za2JzW3ByaXYtPnR4X3dyaXRl XSA9IHNrYjsNCi0JcHJpdi0+cmVncy0+dHhfaW5mby53cHRyPXByaXYtPnR4 X3dyaXRlOw0KLQlwcml2LT50eF93cml0ZT0ocHJpdi0+dHhfd3JpdGUrMSkm KFRYX1JJTkdfRU5UUklFUy0xKTsNCisJbWV0aF9hZGRfdG9fdHhfcmluZyhw cml2LCBza2IpOw0KKwlkZXYtPnRyYW5zX3N0YXJ0ID0gamlmZmllczsgLyog c2F2ZSB0aGUgdGltZXN0YW1wICovDQogDQotCXByaXYtPnJlZ3MtPmRtYV9j dHJsfD1NRVRIX0RNQV9UWF9JTlRfRU47DQorCS8qIElmIFRYIHJpbmcgaXMg ZnVsbCwgdGVsbCB0aGUgdXBwZXIgbGF5ZXIgdG8gc3RvcCBzZW5kaW5nIHBh Y2tldHMgKi8NCisJaWYgKG1ldGhfdHhfZnVsbChkZXYpKSB7DQorCSAgICAg ICAgRFBSSU5USygiVFggZnVsbDogc3RvcHBpbmdcbiIpOw0KKwkJbmV0aWZf c3RvcF9xdWV1ZShkZXYpOw0KKwl9DQogDQotCXNwaW5fdW5sb2NrKCZwcml2 LT5tZXRoX2xvY2spOw0KKwlzcGluX3VubG9ja19pcnEoJnByaXYtPm1ldGhf bG9jayk7DQogDQotICAgIHJldHVybiAwOw0KKwlyZXR1cm4gMDsNCiB9DQog DQogLyoNCiAgKiBEZWFsIHdpdGggYSB0cmFuc21pdCB0aW1lb3V0Lg0KICAq Lw0KLSAvKg0KKw0KIHZvaWQgbWV0aF90eF90aW1lb3V0IChzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2KQ0KIHsNCi0gICAgc3RydWN0IG1ldGhfcHJpdmF0ZSAq cHJpdiA9IChzdHJ1Y3QgbWV0aF9wcml2YXRlICopIGRldi0+cHJpdjsNCisJ c3RydWN0IG1ldGhfcHJpdmF0ZSAqcHJpdiA9IChzdHJ1Y3QgbWV0aF9wcml2 YXRlICopIGRldi0+cHJpdjsNCisJDQorCXByaW50ayhLRVJOX1dBUk5JTkcg IiVzOiB0cmFuc21pdCB0aW1lZCBvdXRcbiIsIGRldi0+bmFtZSk7DQogDQot ICAgIERQUklOVEsoIlRyYW5zbWl0IHRpbWVvdXQgYXQgJWxkLCBsYXRlbmN5 ICVsZFxuIiwgamlmZmllcywNCi0gICAgICAgICAgICAgICAgICAgIGppZmZp ZXMgLSBkZXYtPnRyYW5zX3N0YXJ0KTsNCi0gICAgcHJpdi0+c3RhdHVzID0g bWV0aF9UWF9JTlRSOw0KLSAgICBtZXRoX2ludGVycnVwdCgwLCBkZXYsIE5V TEwpOw0KLSAgICBwcml2LT5zdGF0cy50eF9lcnJvcnMrKzsNCi0gICAgbmV0 aWZfd2FrZV9xdWV1ZShkZXYpOw0KLSAgICByZXR1cm47DQorCS8qIFByb3Rl Y3QgYWdhaW5zdCBjb25jdXJyZW50IHJ4IGludGVycnVwdHMgKi8NCisJc3Bp bl9sb2NrX2lycSgmcHJpdi0+bWV0aF9sb2NrKTsNCisNCisJLyogVHJ5IHRv IHJlc2V0IHRoZSBhZGFwdG9yLiAqLw0KKwltZXRoX3Jlc2V0KGRldik7DQor DQorCXByaXYtPnN0YXRzLnR4X2Vycm9ycysrOw0KKw0KKwkvKiBDbGVhciBh bGwgcmluZ3MgKi8NCisJbWV0aF9mcmVlX3R4X3JpbmcocHJpdik7DQorCW1l dGhfZnJlZV9yeF9yaW5nKHByaXYpOw0KKwltZXRoX2luaXRfdHhfcmluZyhw cml2KTsNCisJbWV0aF9pbml0X3J4X3JpbmcocHJpdik7DQorDQorCS8qIFJl c3RhcnQgZG1hICovDQorCXByaXYtPnJlZ3MtPmRtYV9jdHJsfD1NRVRIX0RN QV9UWF9FTnxNRVRIX0RNQV9SWF9FTnxNRVRIX0RNQV9SWF9JTlRfRU47DQor DQorCS8qIEVuYWJsZSBpbnRlcnJ1cHQgKi8NCisJc3Bpbl91bmxvY2tfaXJx KCZwcml2LT5tZXRoX2xvY2spOw0KKw0KKwlkZXYtPnRyYW5zX3N0YXJ0ID0g amlmZmllczsNCisJbmV0aWZfd2FrZV9xdWV1ZShkZXYpOw0KKw0KKwlyZXR1 cm47DQogfQ0KLSovDQorDQogLyoNCiAgKiBJb2N0bCBjb21tYW5kcyANCiAg Ki8NCkBAIC01NjAsNzUgKzc3NCw1OCBAQA0KIGludCBtZXRoX2luaXQoc3Ry dWN0IG5ldF9kZXZpY2UgKmRldikNCiB7DQogCW1ldGhfcHJpdmF0ZSAqcHJp djsNCi0Jdm9sYXRpbGUgbWV0aF9yZWdzKiByZWdzOw0KIAlpbnQgcmV0Ow0K LSAgICAvKiANCi0gICAgICogVGhlbiwgYXNzaWduIG90aGVyIGZpZWxkcyBp biBkZXYsIHVzaW5nIGV0aGVyX3NldHVwKCkgYW5kIHNvbWUNCi0gICAgICog aGFuZCBhc3NpZ25tZW50cw0KLSAgICAgKi8NCi0gICAgZXRoZXJfc2V0dXAo ZGV2KTsgLyogYXNzaWduIHNvbWUgb2YgdGhlIGZpZWxkcyAqLw0KLQ0KLSAg ICBkZXYtPm9wZW4gICAgICAgICAgICA9IG1ldGhfb3BlbjsNCi0gICAgZGV2 LT5zdG9wICAgICAgICAgICAgPSBtZXRoX3JlbGVhc2U7DQotICAgIGRldi0+ c2V0X2NvbmZpZyAgICAgID0gbWV0aF9jb25maWc7DQotICAgIGRldi0+aGFy ZF9zdGFydF94bWl0ID0gbWV0aF90eDsNCi0gICAgZGV2LT5kb19pb2N0bCAg ICAgICAgPSBtZXRoX2lvY3RsOw0KLSAgICBkZXYtPmdldF9zdGF0cyAgICAg ICA9IG1ldGhfc3RhdHM7DQotLyojaWZkZWYgSEFWRV9UWF9USU1FT1VUDQot ICAgIGRldi0+dHhfdGltZW91dCAgICAgPSBtZXRoX3R4X3RpbWVvdXQ7DQot ICAgIGRldi0+d2F0Y2hkb2dfdGltZW8gPSB0aW1lb3V0Ow0KLSNlbmRpZiov DQotCWRldi0+aXJxCQkJPSBNQUNFX0VUSEVSTkVUX0lSUTsNCi0gICAgU0VU X01PRFVMRV9PV05FUihkZXYpOw0KLQ0KLSAgICAvKg0KLSAgICAgKiBUaGVu LCBhbGxvY2F0ZSB0aGUgcHJpdiBmaWVsZC4gVGhpcyBlbmNsb3NlcyB0aGUg c3RhdGlzdGljcw0KLSAgICAgKiBhbmQgYSBmZXcgcHJpdmF0ZSBmaWVsZHMu DQotICAgICAqLw0KLSAgICBwcml2ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0 IG1ldGhfcHJpdmF0ZSksIEdGUF9LRVJORUwpOw0KLSAgICBpZiAocHJpdiA9 PSBOVUxMKQ0KLSAgICAgICAgcmV0dXJuIC1FTk9NRU07DQorCS8qIA0KKwkg KiBUaGVuLCBhc3NpZ24gb3RoZXIgZmllbGRzIGluIGRldiwgdXNpbmcgZXRo ZXJfc2V0dXAoKSBhbmQgc29tZQ0KKwkgKiBoYW5kIGFzc2lnbm1lbnRzDQor CSAqLw0KKwlldGhlcl9zZXR1cChkZXYpOyAvKiBhc3NpZ24gc29tZSBvZiB0 aGUgZmllbGRzICovDQorDQorCWRldi0+b3BlbiAgICAgICAgICAgID0gbWV0 aF9vcGVuOw0KKwlkZXYtPnN0b3AgICAgICAgICAgICA9IG1ldGhfcmVsZWFz ZTsNCisJZGV2LT5zZXRfY29uZmlnICAgICAgPSBtZXRoX2NvbmZpZzsNCisJ ZGV2LT5oYXJkX3N0YXJ0X3htaXQgPSBtZXRoX3R4Ow0KKwlkZXYtPmRvX2lv Y3RsICAgICAgICA9IG1ldGhfaW9jdGw7DQorCWRldi0+Z2V0X3N0YXRzICAg ICAgID0gbWV0aF9zdGF0czsNCisjaWZkZWYgSEFWRV9UWF9USU1FT1VUDQor CWRldi0+dHhfdGltZW91dCAgICAgID0gbWV0aF90eF90aW1lb3V0Ow0KKwlk ZXYtPndhdGNoZG9nX3RpbWVvICA9IHRpbWVvdXQ7DQorI2VuZGlmDQorCWRl di0+aXJxCQkgPSBNQUNFX0VUSEVSTkVUX0lSUTsNCisJU0VUX01PRFVMRV9P V05FUihkZXYpOw0KKw0KKwkvKg0KKwkgKiBUaGVuLCBhbGxvY2F0ZSB0aGUg cHJpdiBmaWVsZC4gVGhpcyBlbmNsb3NlcyB0aGUgc3RhdGlzdGljcw0KKwkg KiBhbmQgYSBmZXcgcHJpdmF0ZSBmaWVsZHMuDQorCSAqLw0KKwlwcml2ID0g a21hbGxvYyhzaXplb2Yoc3RydWN0IG1ldGhfcHJpdmF0ZSksIEdGUF9LRVJO RUwpOw0KKwlpZiAocHJpdiA9PSBOVUxMKQ0KKwkJcmV0dXJuIC1FTk9NRU07 DQogCWRldi0+cHJpdj1wcml2Ow0KLSAgICBtZW1zZXQocHJpdiwgMCwgc2l6 ZW9mKHN0cnVjdCBtZXRoX3ByaXZhdGUpKTsNCi0gICAgc3Bpbl9sb2NrX2lu aXQoJiAoc3RydWN0IG1ldGhfcHJpdmF0ZSAqKSAoZGV2LT5wcml2KS0+bWV0 aF9sb2NrKTsNCi0gICAgLyoNCi0gICAgICogTWFrZSB0aGUgdXN1YWwgY2hl Y2tzOiBjaGVja19yZWdpb24oKSwgcHJvYmUgaXJxLCAuLi4gIC1FTk9ERVYN Ci0gICAgICogc2hvdWxkIGJlIHJldHVybmVkIGlmIG5vIGRldmljZSBmb3Vu ZC4gIE5vIHJlc291cmNlIHNob3VsZCBiZQ0KLSAgICAgKiBncmFiYmVkOiB0 aGlzIGlzIGRvbmUgb24gb3BlbigpLiANCi0gICAgICovDQorCW1lbXNldChw cml2LCAwLCBzaXplb2Yoc3RydWN0IG1ldGhfcHJpdmF0ZSkpOw0KKwlzcGlu X2xvY2tfaW5pdCgmKChzdHJ1Y3QgbWV0aF9wcml2YXRlICopIGRldi0+cHJp diktPm1ldGhfbG9jayk7DQorCS8qDQorCSAqIE1ha2UgdGhlIHVzdWFsIGNo ZWNrczogY2hlY2tfcmVnaW9uKCksIHByb2JlIGlycSwgLi4uICAtRU5PREVW DQorCSAqIHNob3VsZCBiZSByZXR1cm5lZCBpZiBubyBkZXZpY2UgZm91bmQu ICBObyByZXNvdXJjZSBzaG91bGQgYmUNCisJICogZ3JhYmJlZDogdGhpcyBp cyBkb25lIG9uIG9wZW4oKS4gDQorCSAqLw0KIAlwcml2LT5yZWdzPShtZXRo X3JlZ3MqKVNHSV9NRkU7DQogCWRldi0+YmFzZV9hZGRyPVNHSV9NRkU7DQor CXByaXYtPnBoeV9hZGRyID0gLTE7IC8qIE5vIHBoeSBpcyBrbm93biB5ZXQu Li4gKi8NCiANCi0JcmVncz0obWV0aF9yZWdzKilTR0lfTUZFOw0KLQ0KLQkv KiBSZXNldCBjYXJkICovDQotCXJlZ3MtPm1hY19jdHJsPVNHSV9NQUNfUkVT RVQ7DQotCXJlZ3MtPm1hY19jdHJsPTA7DQotCXVkZWxheSgyNSk7DQotCURQ UklOVEsoIk1BQyBjb250cm9sIGFmdGVyIHJlc2V0OiAlMDE2bHhcbiIscmVn cy0+bWFjX2N0cmwpOw0KLQlwcmludGsoIlNHSSBPMiBGYXN0IEV0aGVybmV0 IHJldi4gJWxkXG4iLHJlZ3MtPm1hY19jdHJsPj4yOSk7DQotDQotCWxvYWRf ZWFkZHIoZGV2LHJlZ3MpOw0KLQlwcml2LT5waHlfYWRkcj0tMTsgLyogTm8g cGh5IGlzIGtub3duIHlldC4uLiAqLw0KLQlpZihtZGlvX3Byb2JlKHByaXYp PDApew0KLQkJRFBSSU5USygiVW5hYmxlIHRvIGZpbmQgUEhZXG4iKTsNCi0J CXJldHVybiAtRU5PREVWOw0KLQl9DQotCS8qIFNob3VsZCBsb2FkIHNvbWUg ImVycmF0YSIsIGJ1dCBsYXRlciAqLw0KLQkNCi0JLyogSW5pdGlhbCBtb2Rl IC0tIDEwMHxIYWxmLWR1cGxleHxBY2VwdCBub3JtYWwgcGFja2V0cyAqLw0K LQlwcml2LT5tb2RlPU1FVEhfQUNDRVBUX01DQVNUfE1FVEhfMTAwTUJJVHxN RVRIX0RFRkFVTFRfSVBHOw0KLQlpZihkZXYtPmZsYWdzfElGRl9QUk9NSVND KQ0KLQkJcHJpdi0+bW9kZXw9TUVUSF9QUk9NSVNDOw0KLQlyZWdzLT5tYWNf Y3RybD1wcml2LT5tb2RlOw0KKwkvKiBJbml0aWFsaXplIHRoZSBoYXJkd2Fy ZSAqLw0KKwlpZigocmV0PW1ldGhfcmVzZXQoZGV2KSkgPCAwKQ0KKwkgICAg ICAgIHJldHVybiByZXQ7DQogDQorCS8qIEFsbG9jYXRlIHRoZSByaW5nIGJ1 ZmZlcnMgKi8NCiAJaWYoKHJldD1tZXRoX2luaXRfdHhfcmluZyhwcml2KSk8 MHx8KHJldD1tZXRoX2luaXRfcnhfcmluZyhwcml2KSk8MCl7DQogCQltZXRo X2ZyZWVfdHhfcmluZyhwcml2KTsNCiAJCW1ldGhfZnJlZV9yeF9yaW5nKHBy aXYpOw0KIAkJcmV0dXJuIHJldDsNCiAJfQ0KLQkvKiBOb3cgc2V0IGRtYSBj b250cm9sLCBidXQgZG9uJ3QgZW5hYmxlIERNQSwgeWV0ICovDQotCXByaXYt PnJlZ3MtPmRtYV9jdHJsPSg0PDxNRVRIX1JYX09GRlNFVF9TSElGVCl8KFJY X1JJTkdfRU5UUklFUzw8TUVUSF9SWF9ERVBUSF9TSElGVCk7DQorDQorCXBy aW50aygiU0dJIE8yIEZhc3QgRXRoZXJuZXQgcmV2LiAlbGRcbiIsIHByaXYt PnJlZ3MtPm1hY19jdHJsID4+IDI5KTsNCisNCiAgICAgcmV0dXJuIDA7DQog fQ0KIA0KQEAgLTY0NiwyMCArODQzLDE5IEBADQogDQogaW50IG1ldGhfaW5p dF9tb2R1bGUodm9pZCkNCiB7DQotDQotICAgIGludCByZXN1bHQsIGRldmlj ZV9wcmVzZW50ID0gMDsNCisJaW50IHJlc3VsdCwgZGV2aWNlX3ByZXNlbnQg PSAwOw0KIA0KIAlzdHJjcHkobWV0aF9kZXZzWzBdLm5hbWUsICJldGglZCIp Ow0KIA0KIAlpZiAoIChyZXN1bHQgPSByZWdpc3Rlcl9uZXRkZXYobWV0aF9k ZXZzKSkgKQ0KLSAgICAgICAgcHJpbnRrKCJtZXRoOiBlcnJvciAlaSByZWdp c3RlcmluZyBkZXZpY2UgXCIlc1wiXG4iLA0KLSAgICAgICAgICAgICAgICAg ICByZXN1bHQsIG1ldGhfZGV2cy0+bmFtZSk7DQorCQlwcmludGsoIm1ldGg6 IGVycm9yICVpIHJlZ2lzdGVyaW5nIGRldmljZSBcIiVzXCJcbiIsDQorCQkg ICAgICAgcmVzdWx0LCBtZXRoX2RldnMtPm5hbWUpOw0KIAllbHNlIGRldmlj ZV9wcmVzZW50Kys7DQogI2lmbmRlZiBNRVRIX0RFQlVHDQotICAgIEVYUE9S VF9OT19TWU1CT0xTOw0KKwlFWFBPUlRfTk9fU1lNQk9MUzsNCiAjZW5kaWYN Ci0NCi0gICAgcmV0dXJuIGRldmljZV9wcmVzZW50ID8gMCA6IC1FTk9ERVY7 DQorCQ0KKwlyZXR1cm4gZGV2aWNlX3ByZXNlbnQgPyAwIDogLUVOT0RFVjsN CiB9DQogDQogdm9pZCBtZXRoX2NsZWFudXAodm9pZCkNCi0tLSBsaW51eC9k cml2ZXJzL25ldC9tZXRoLmgJU3VuIERlYyAgOSAxNTo0OToyNSAyMDAxDQor KysgbGludXguYnVpbGQvZHJpdmVycy9uZXQvbWV0aC5oCVN1biBKYW4gIDYg MTU6NDU6NDMgMjAwMg0KQEAgLTEwOCw4ICsxMDgsOSBAQA0KIA0KIHR5cGVk ZWYgc3RydWN0IHJ4X3BhY2tldCB7DQogCXJ4X3N0YXR1c192ZWN0b3Igc3Rh dHVzOw0KLQl1NjQgcGFkWzRdOyAvKiBGb3Igd2hhdGV2ZXIgcmVhc29uLCB0 aGVyZSBuZWVkcyB0byBiZSA0IGRvdWJsZS13b3JkIG9mZnNldCAqLw0KLQlj aGFyIGJ1ZltNRVRIX1JYX0JVRkZfU0laRS1zaXplb2Yocnhfc3RhdHVzX3Zl Y3Rvciktc2l6ZW9mKHU2NCldOy8qIGRhdGEgKi8NCisgICAgICAgIHU2NCBw YWRbM107IC8qIEZvciB3aGF0ZXZlciByZWFzb24sIHRoZXJlIG5lZWRzIHRv IGJlIDQgZG91YmxlLXdvcmQgb2Zmc2V0ICovDQorICAgICAgICB1MTYgcGFk MjsNCisJY2hhciBidWZbTUVUSF9SWF9CVUZGX1NJWkUtc2l6ZW9mKHJ4X3N0 YXR1c192ZWN0b3IpLTMqc2l6ZW9mKHU2NCktc2l6ZW9mKHUxNildOy8qIGRh dGEgKi8NCiB9IHJ4X3BhY2tldDsNCiANCiB0eXBlZGVmIHN0cnVjdCBtZXRo X3JlZ3Mgew0KQEAgLTIzOSwxMyArMjQwLDEzIEBADQogI2RlZmluZSBNRVRI X0lOVF9SWF9VTkRFUkZMT1cJQklUKDYpCS8qIDA6IE5vIGludGVycnVwdCBw ZW5kaW5nLCAxOiBGSUZPIHdhcyBlbXB0eSwgcGFja2V0IGNvdWxkIG5vdCBi ZSBxdWV1ZWQgKi8NCiAjZGVmaW5lIE1FVEhfSU5UX1JYX09WRVJGTE9XCQlC SVQoNykJLyogMDogTm8gaW50ZXJydXB0IHBlbmRpbmcsIDE6IERNQSBGSUZP IE92ZXJmbG93LCBETUEgc3RvcHBlZCwgRkFUQUwgKi8NCiANCi0JCQkJCQkv KiBCaXRzIDggdGhyb3VnaCAxMiBhbGlhcyBvZiBSWCByZWFkLXBvaW50ZXIg Ki8NCisjZGVmaW5lIE1FVEhfSU5UX1JYX1JQVFJfTUFTSyAweDAwMDFGMDAJ CS8qIEJpdHMgOCB0aHJvdWdoIDEyIGFsaWFzIG9mIFJYIHJlYWQtcG9pbnRl ciAqLw0KIA0KIAkJCQkJCS8qIEJpdHMgMTMgdGhyb3VnaCAxNSBhcmUgYWx3 YXlzIDAuICovDQogDQotI2RlZmluZSBNRVRIX0lOVF9SUFRSX01BU0sgMHgx RkYwMDAwCS8qIEJpdHMgMTYgdGhyb3VnaCAyNCBhbGlhcyBvZiBUWCByZWFk LXBvaW50ZXIgKi8NCisjZGVmaW5lIE1FVEhfSU5UX1RYX1JQVFJfTUFTSyAw eDFGRjAwMDAJICAgICAgICAvKiBCaXRzIDE2IHRocm91Z2ggMjQgYWxpYXMg b2YgVFggcmVhZC1wb2ludGVyICovDQogDQotCQkJCQkJLyogQml0cyAyNSB0 aHJvdWdoIDI5IGFyZSB0aGUgc3RhcnRpbmcgc2VxIG51bWJlciBmb3IgdGhl IG1lc3NhZ2UgYXQgdGhlICovDQorI2RlZmluZSBNRVRIX0lOVF9TRVFfTUFT SyAgICAweDJFMDAwMDAwCSAgICAgICAgLyogQml0cyAyNSB0aHJvdWdoIDI5 IGFyZSB0aGUgc3RhcnRpbmcgc2VxIG51bWJlciBmb3IgdGhlIG1lc3NhZ2Ug YXQgdGhlICovDQogCQkJCQkJLyogdG9wIG9mIHRoZSBxdWV1ZSAqLw0KIA0K ICNkZWZpbmUgTUVUSF9FUlJPUlMgKCBcDQo= --279724308-970882123-1025551760=:27848-- From owner-linux-mips@oss.sgi.com Mon Jul 1 12:29:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61JTNnC017170 for ; Mon, 1 Jul 2002 12:29:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61JTN6h017169 for linux-mips-outgoing; Mon, 1 Jul 2002 12:29:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61JTHnC017160; Mon, 1 Jul 2002 12:29:18 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g61JX2C25639; Mon, 1 Jul 2002 21:33:02 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g61JX3TF008349; Mon, 1 Jul 2002 21:33:03 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17P6v0-0007Fu-00; Mon, 01 Jul 2002 21:33:02 +0200 Date: Mon, 1 Jul 2002 21:33:02 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] O2 ethernet support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi again, Sorry, forgot to mention that the patch is against CVS HEAD, not 2.4. Vivien. From owner-linux-mips@oss.sgi.com Mon Jul 1 13:43:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61KhLnC019648 for ; Mon, 1 Jul 2002 13:43:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61KhL6p019647 for linux-mips-outgoing; Mon, 1 Jul 2002 13:43:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61Kh4nC019591; Mon, 1 Jul 2002 13:43:05 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g61KkmC30247; Mon, 1 Jul 2002 22:46:48 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g61KknTF012277; Mon, 1 Jul 2002 22:46:49 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17P84P-0007Jz-00; Mon, 01 Jul 2002 22:46:49 +0200 Date: Mon, 1 Jul 2002 22:46:49 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] r4k icache flushing for mips64 CVS HEAD Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1408155667-1025556409=:28140" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.2 required=5.0 tests=MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-1408155667-1025556409=:28140 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This fixes icache flushing for the r4xx0 processor in the current (CVS HEAD) 2.5.1 tree. The flush_cache_all function does nothing there, that's why I moved it to flush_cache_l1. Vivien. --279724308-1408155667-1025556409=:28140 Content-Type: TEXT/plain; name="linux-mips64-r4k_icache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips64-r4k_icache.diff" ZGlmZiAtTmF1ciAvc2hhcmUvbGludXguY3ZzL2FyY2gvbWlwczY0L21tL2xv YWRtbXUuYyBsaW51eC5wYXRjaGVkL2FyY2gvbWlwczY0L21tL2xvYWRtbXUu Yw0KLS0tIC9zaGFyZS9saW51eC5jdnMvYXJjaC9taXBzNjQvbW0vbG9hZG1t dS5jCVN1biBNYXIgIDMgMTk6NTA6MzkgMjAwMg0KKysrIGxpbnV4LnBhdGNo ZWQvYXJjaC9taXBzNjQvbW0vbG9hZG1tdS5jCVRodSBNYXkgMTYgMjM6MTI6 MjEgMjAwMg0KQEAgLTMwLDExICszMCwxNCBAQA0KIHZvaWQgKCpfZmx1c2hf Y2FjaGVfcGFnZSkoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsIHVuc2ln bmVkIGxvbmcgcGFnZSk7DQogdm9pZCAoKl9mbHVzaF9wYWdlX3RvX3JhbSko c3RydWN0IHBhZ2UgKiBwYWdlKTsNCiANCit2b2lkICgqX2ZsdXNoX2ljYWNo ZV9yYW5nZSkodW5zaWduZWQgbG9uZyBzdGFydCwgdW5zaWduZWQgbG9uZyBl bmQpOw0KK3ZvaWQgKCpfZmx1c2hfaWNhY2hlX3BhZ2UpKHN0cnVjdCB2bV9h cmVhX3N0cnVjdCAqdm1hLCBzdHJ1Y3QgcGFnZSAqcGFnZSk7DQordm9pZCAo Kl9mbHVzaF9pY2FjaGVfYWxsKSh2b2lkKTsNCisNCiAvKiBNSVBTIHNwZWNp ZmljIGNhY2hlIG9wZXJhdGlvbnMgKi8NCiB2b2lkICgqX2ZsdXNoX2NhY2hl X3NpZ3RyYW1wKSh1bnNpZ25lZCBsb25nIGFkZHIpOw0KIHZvaWQgKCpfZmx1 c2hfY2FjaGVfbDIpKHZvaWQpOw0KIHZvaWQgKCpfZmx1c2hfY2FjaGVfbDEp KHZvaWQpOw0KLQ0KIA0KIC8qIERNQSBjYWNoZSBvcGVyYXRpb25zLiAqLw0K IHZvaWQgKCpfZG1hX2NhY2hlX3diYWNrX2ludikodW5zaWduZWQgbG9uZyBz dGFydCwgdW5zaWduZWQgbG9uZyBzaXplKTsNCmRpZmYgLU5hdXIgL3NoYXJl L2xpbnV4LmN2cy9pbmNsdWRlL2FzbS1taXBzNjQvcGd0YWJsZS5oIGxpbnV4 LnBhdGNoZWQvaW5jbHVkZS9hc20tbWlwczY0L3BndGFibGUuaA0KLS0tIC9z aGFyZS9saW51eC5jdnMvaW5jbHVkZS9hc20tbWlwczY0L3BndGFibGUuaAlT dW4gTWF5ICA1IDE1OjAzOjM5IDIwMDINCisrKyBsaW51eC5wYXRjaGVkL2lu Y2x1ZGUvYXNtLW1pcHM2NC9wZ3RhYmxlLmgJVGh1IE1heSAxNiAyMzowMTo0 NiAyMDAyDQpAQCAtNjAsMTIgKzYwLDIyIEBADQogDQogI2Vsc2UNCiANCitl eHRlcm4gdm9pZCAoKl9mbHVzaF9pY2FjaGVfYWxsKSh2b2lkKTsNCitleHRl cm4gdm9pZCAoKl9mbHVzaF9pY2FjaGVfcmFuZ2UpKHVuc2lnbmVkIGxvbmcg c3RhcnQsIHVuc2lnbmVkIGxvbmcgZW5kKTsNCitleHRlcm4gdm9pZCAoKl9m bHVzaF9pY2FjaGVfcGFnZSkoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEs IHN0cnVjdCBwYWdlICpwYWdlKTsNCisNCiAjZGVmaW5lIGZsdXNoX2NhY2hl X21tKG1tKQkJX2ZsdXNoX2NhY2hlX21tKG1tKQ0KICNkZWZpbmUgZmx1c2hf Y2FjaGVfcmFuZ2UobW0sc3RhcnQsZW5kKQlfZmx1c2hfY2FjaGVfcmFuZ2Uo bW0sc3RhcnQsZW5kKQ0KICNkZWZpbmUgZmx1c2hfY2FjaGVfcGFnZSh2bWEs cGFnZSkJX2ZsdXNoX2NhY2hlX3BhZ2Uodm1hLCBwYWdlKQ0KICNkZWZpbmUg Zmx1c2hfcGFnZV90b19yYW0ocGFnZSkJCV9mbHVzaF9wYWdlX3RvX3JhbShw YWdlKQ0KICNkZWZpbmUgZmx1c2hfaWNhY2hlX3JhbmdlKHN0YXJ0LCBlbmQp CV9mbHVzaF9pY2FjaGVfcmFuZ2Uoc3RhcnQsIGVuZCkNCiAjZGVmaW5lIGZs dXNoX2ljYWNoZV9wYWdlKHZtYSwgcGFnZSkJX2ZsdXNoX2ljYWNoZV9wYWdl KHZtYSwgcGFnZSkNCisjaWZkZWYgQ09ORklHX1ZUQUdfSUNBQ0hFDQorI2Rl ZmluZSBmbHVzaF9pY2FjaGVfYWxsKCkJCV9mbHVzaF9pY2FjaGVfYWxsKCkN CisjZWxzZQ0KKyNkZWZpbmUgZmx1c2hfaWNhY2hlX2FsbCgpCQlkbyB7IH0g d2hpbGUoMCkNCisjZW5kaWYNCisNCiANCiAjZW5kaWYgLyogIUNPTkZJR19D UFVfUjEwMDAwICovDQogDQpkaWZmIC1OYXVyIGxpbnV4L2FyY2gvbWlwczY0 L21tL3I0eHgwLmMgbGludXgucGF0Y2gvYXJjaC9taXBzNjQvbW0vcjR4eDAu Yw0KLS0tIGxpbnV4L2FyY2gvbWlwczY0L21tL3I0eHgwLmMJTW9uIEp1bCAg MSAyMTozNjozNyAyMDAyDQorKysgbGludXgucGF0Y2gvYXJjaC9taXBzNjQv bW0vcjR4eDAuYwlNb24gSnVsICAxIDIyOjIyOjE1IDIwMDINCkBAIC0xNjI1 LDcgKzE2MjUsNyBAQA0KIHN0YXRpYyB2b2lkDQogcjRrX2ZsdXNoX2ljYWNo ZV9yYW5nZSh1bnNpZ25lZCBsb25nIHN0YXJ0LCB1bnNpZ25lZCBsb25nIGVu ZCkNCiB7DQotCWZsdXNoX2NhY2hlX2FsbCgpOw0KKwlmbHVzaF9jYWNoZV9s MSgpOw0KIH0NCiANCiBzdGF0aWMgdm9pZA0K --279724308-1408155667-1025556409=:28140-- From owner-linux-mips@oss.sgi.com Mon Jul 1 14:30:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61LU6nC020356 for ; Mon, 1 Jul 2002 14:30:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61LU66D020355 for linux-mips-outgoing; Mon, 1 Jul 2002 14:30:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-103.ka.dial.de.ignite.net [62.180.196.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61LTxnC020339 for ; Mon, 1 Jul 2002 14:30:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g61LXY432118; Mon, 1 Jul 2002 23:33:34 +0200 Date: Mon, 1 Jul 2002 23:33:34 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] O2 ethernet support Message-ID: <20020701233334.A32068@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Mon, Jul 01, 2002 at 09:33:02PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 01, 2002 at 09:33:02PM +0200, Vivien Chappelier wrote: > Sorry, forgot to mention that the patch is against CVS HEAD, not > 2.4. Applies to both :-) Ralf From owner-linux-mips@oss.sgi.com Mon Jul 1 15:42:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g61Mg1nC021071 for ; Mon, 1 Jul 2002 15:42:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g61Mg1Gg021070 for linux-mips-outgoing; Mon, 1 Jul 2002 15:42:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-103.ka.dial.de.ignite.net [62.180.196.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g61MftnC021059 for ; Mon, 1 Jul 2002 15:41:57 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g61Mjgm32719; Tue, 2 Jul 2002 00:45:42 +0200 Date: Tue, 2 Jul 2002 00:45:42 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] r4k icache flushing for mips64 CVS HEAD Message-ID: <20020702004542.B32068@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Mon, Jul 01, 2002 at 10:46:49PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 01, 2002 at 10:46:49PM +0200, Vivien Chappelier wrote: > This fixes icache flushing for the r4xx0 processor in the current > (CVS HEAD) 2.5.1 tree. The flush_cache_all function does nothing there, > that's why I moved it to flush_cache_l1. Not right, I checked in a variation of it ... Ralf From owner-linux-mips@oss.sgi.com Mon Jul 1 19:05:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g62256nC023023 for ; Mon, 1 Jul 2002 19:05:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g62256aM023022 for linux-mips-outgoing; Mon, 1 Jul 2002 19:05:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g62250nC022995 for ; Mon, 1 Jul 2002 19:05:00 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g622A1Q14168; Mon, 1 Jul 2002 19:10:02 -0700 Subject: Re: MIPS GOT overflow in gcc 3.2. From: Eric Christopher To: "H. J. Lu" Cc: linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com In-Reply-To: <20020701184640.A2043@lucon.org> References: <20020701184640.A2043@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Jul 2002 19:07:11 -0700 Message-Id: <1025575632.30577.64.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > For gcc 3.1.1, I got > > [17] .got PROGBITS 0068b8a0 64b8a0 00ff90 04 WAp 0 0 > 16 > > 0x00ff90 is very close to 64K. I thought it would only happen to KDE. AFAIK it happens to mozilla as well. Guh. -eric -- I will not carve gods From owner-linux-mips@oss.sgi.com Mon Jul 1 20:07:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g6237wnC024302 for ; Mon, 1 Jul 2002 20:07:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g6237wM4024301 for linux-mips-outgoing; Mon, 1 Jul 2002 20:07:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g6237qnC024291 for ; Mon, 1 Jul 2002 20:07:52 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g623CnQ14285; Mon, 1 Jul 2002 20:12:49 -0700 Subject: Re: MIPS GOT overflow in gcc 3.2. From: Eric Christopher To: Eric Christopher Cc: "H. J. Lu" , linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com In-Reply-To: <1025575632.30577.64.camel@ghostwheel.cygnus.com> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Jul 2002 20:09:59 -0700 Message-Id: <1025579401.1785.0.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > AFAIK it happens to mozilla as well. > > Guh. There are a few different possible solutions, one is to do the -fPIC/-fpic split, another is to copy to SGI multigot, I'm sure there are other solutions as well... -eric -- I will not carve gods From owner-linux-mips@oss.sgi.com Mon Jul 1 23:55:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g626t8nC029959 for ; Mon, 1 Jul 2002 23:55:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g626t8Hp029958 for linux-mips-outgoing; Mon, 1 Jul 2002 23:55:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g626t2nC029944 for ; Mon, 1 Jul 2002 23:55:02 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702065850.OAAY15755.rwcrmhc53.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 06:58:50 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4CBAF125D3; Mon, 1 Jul 2002 23:58:49 -0700 (PDT) Date: Mon, 1 Jul 2002 23:58:49 -0700 From: "H. J. Lu" To: Eric Christopher Cc: linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com Subject: Re: MIPS GOT overflow in gcc 3.2. Message-ID: <20020701235849.A6382@lucon.org> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025579401.1785.0.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Jul 01, 2002 at 08:09:59PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 01, 2002 at 08:09:59PM -0700, Eric Christopher wrote: > > > AFAIK it happens to mozilla as well. > > > > Guh. > > There are a few different possible solutions, one is to do the > -fPIC/-fpic split, another is to copy to SGI multigot, I'm sure there > are other solutions as well... > I am testing this patch now. It will take a day to verify it. H.J. ---- 2002-07-02 H.J. Lu * ltcf-gcj.sh (ac_cv_prog_cc_pic): Add "-Wa,-xgot" for Linux/mips. --- ltcf-gcj.sh.xgot Mon Sep 10 08:39:17 2001 +++ ltcf-gcj.sh Mon Jul 1 23:49:06 2002 @@ -639,6 +639,14 @@ fi ac_cv_prog_cc_pic=-Kconform_pic fi ;; + linux*) + ac_cv_prog_cc_pic='-fPIC' + case $host_cpu in + mips*) + ac_cv_prog_cc_pic="$ac_cv_prog_cc_pic -Wa,-xgot" + ;; + esac + ;; *) ac_cv_prog_cc_pic='-fPIC' ;; From owner-linux-mips@oss.sgi.com Tue Jul 2 02:49:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g629n0nC010900 for ; Tue, 2 Jul 2002 02:49:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g629n0sD010899 for linux-mips-outgoing; Tue, 2 Jul 2002 02:49:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from msr.hinet.net (msr17.hinet.net [168.95.4.117]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g629munC010887 for ; Tue, 2 Jul 2002 02:48:57 -0700 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by msr.hinet.net (8.9.3/8.9.3) with ESMTP id RAA26637 for ; Tue, 2 Jul 2002 17:53:06 +0800 (CST) Message-ID: <000901c221ae$2a9a0c00$780411ac@sam> From: "Sam" To: Subject: # trap handler example Date: Tue, 2 Jul 2002 17:52:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit 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-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi everybody, I want to write a trap handler for unalignment memory read/write error. Is there any example for reference? thanks all~ --Sam From owner-linux-mips@oss.sgi.com Tue Jul 2 09:15:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62GFIRw008338 for ; Tue, 2 Jul 2002 09:15:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62GFIxQ008337 for linux-mips-outgoing; Tue, 2 Jul 2002 09:15:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62GFERw008301 for ; Tue, 2 Jul 2002 09:15:14 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702022417.IUSW29588.sccrmhc01.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 02:24:17 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 29EE9125D3; Mon, 1 Jul 2002 19:24:16 -0700 (PDT) Date: Mon, 1 Jul 2002 19:24:15 -0700 From: "H. J. Lu" To: Eric Christopher Cc: bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Kernel ll/sc emulation? Message-ID: <20020701192415.A2617@lucon.org> References: <20020701110145.A27314@lucon.org> <1025548213.1438.7.camel@ghostwheel.cygnus.com> <20020701122313.35d7dd56.bkoz@redhat.com> <1025562305.28484.1.camel@ghostwheel.cygnus.com> <20020701153438.A31602@lucon.org> <1025568244.30577.16.camel@ghostwheel.cygnus.com> <20020701182418.A1600@lucon.org> <1025574335.30581.44.camel@ghostwheel.cygnus.com> <20020701185158.A2134@lucon.org> <1025574717.30577.48.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025574717.30577.48.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Jul 01, 2002 at 06:51:57PM -0700 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 01, 2002 at 06:51:57PM -0700, Eric Christopher wrote: > > > What do you meant by "it'll be emulated if it fails"? I didn't see any > > ll/sc emulation in the Linux mips kernel. If you use ll/sc on CPU which > > doesn't implement ll/sc, your binary will just dump core. > > The kernel should trap and emulate the instruction at that point, at > least as far as I've been told. > That is a news to me. I couldn't find it anywhere in the Linux mips kernel. Could someone point me to the right place in the Linux mips kernel source tree? Thanks. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 2 09:20:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62GKTRw009118 for ; Tue, 2 Jul 2002 09:20:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62GKTdN009117 for linux-mips-outgoing; Tue, 2 Jul 2002 09:20:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62GKORw009098 for ; Tue, 2 Jul 2002 09:20:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA06330; Tue, 2 Jul 2002 18:24:40 +0200 (MET DST) Date: Tue, 2 Jul 2002 18:24:40 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H. J. Lu" cc: Eric Christopher , bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Re: Kernel ll/sc emulation? In-Reply-To: <20020701192415.A2617@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 1 Jul 2002, H. J. Lu wrote: > That is a news to me. I couldn't find it anywhere in the Linux mips > kernel. Could someone point me to the right place in the Linux mips > kernel source tree? See do_ri() in arch/mips/kernel/traps.c. -- + 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 Jul 2 09:27:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62GRvRw010097 for ; Tue, 2 Jul 2002 09:27:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62GRvuN010096 for linux-mips-outgoing; Tue, 2 Jul 2002 09:27:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62GRrRw010068 for ; Tue, 2 Jul 2002 09:27:53 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702163143.HQXH8262.rwcrmhc52.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 16:31:43 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7BE5B125D3; Tue, 2 Jul 2002 09:31:42 -0700 (PDT) Date: Tue, 2 Jul 2002 09:31:42 -0700 From: "H. J. Lu" To: "Maciej W. Rozycki" Cc: Eric Christopher , bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Re: Kernel ll/sc emulation? Message-ID: <20020702093142.A14419@lucon.org> References: <20020701192415.A2617@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Tue, Jul 02, 2002 at 06:24:40PM +0200 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 06:24:40PM +0200, Maciej W. Rozycki wrote: > On Mon, 1 Jul 2002, H. J. Lu wrote: > > > That is a news to me. I couldn't find it anywhere in the Linux mips > > kernel. Could someone point me to the right place in the Linux mips > > kernel source tree? > > See do_ri() in arch/mips/kernel/traps.c. > Great. What is the first working ll/sc emulation kernel version? H.J. From owner-linux-mips@oss.sgi.com Tue Jul 2 09:39:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62GdHRw024973 for ; Tue, 2 Jul 2002 09:39:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62GdH0C024972 for linux-mips-outgoing; Tue, 2 Jul 2002 09:39:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62GdCRw024958 for ; Tue, 2 Jul 2002 09:39:12 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) 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 JAA09640 for ; Tue, 2 Jul 2002 09:43:27 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17PQYH-000vml-00; Tue, 02 Jul 2002 18:30:53 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17PQaX-0003UW-00; Tue, 02 Jul 2002 18:33:13 +0200 Date: Tue, 2 Jul 2002 18:33:13 +0200 To: "H. J. Lu" Cc: Eric Christopher , bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Re: Kernel ll/sc emulation? Message-ID: <20020702163313.GN16753@rembrandt.csv.ica.uni-stuttgart.de> References: <1025548213.1438.7.camel@ghostwheel.cygnus.com> <20020701122313.35d7dd56.bkoz@redhat.com> <1025562305.28484.1.camel@ghostwheel.cygnus.com> <20020701153438.A31602@lucon.org> <1025568244.30577.16.camel@ghostwheel.cygnus.com> <20020701182418.A1600@lucon.org> <1025574335.30581.44.camel@ghostwheel.cygnus.com> <20020701185158.A2134@lucon.org> <1025574717.30577.48.camel@ghostwheel.cygnus.com> <20020701192415.A2617@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020701192415.A2617@lucon.org> User-Agent: Mutt/1.3.28i From: Thiemo Seufer X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H. J. Lu wrote: > On Mon, Jul 01, 2002 at 06:51:57PM -0700, Eric Christopher wrote: > > > > > What do you meant by "it'll be emulated if it fails"? I didn't see any > > > ll/sc emulation in the Linux mips kernel. If you use ll/sc on CPU which > > > doesn't implement ll/sc, your binary will just dump core. > > > > The kernel should trap and emulate the instruction at that point, at > > least as far as I've been told. > > > > That is a news to me. I couldn't find it anywhere in the Linux mips > kernel. Could someone point me to the right place in the Linux mips > kernel source tree? grep -rI LLSC arch/mips/kernel HTH, Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 2 11:37:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62IbWRw007849 for ; Tue, 2 Jul 2002 11:37:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62IbWLs007848 for linux-mips-outgoing; Tue, 2 Jul 2002 11:37:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62IauRw007737 for ; Tue, 2 Jul 2002 11:36:56 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702184046.BIQG29588.sccrmhc01.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 18:40:46 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 59A7E125D3; Tue, 2 Jul 2002 11:40:45 -0700 (PDT) Date: Tue, 2 Jul 2002 11:40:45 -0700 From: "H. J. Lu" To: linux-mips@oss.sgi.com, GNU C Library Subject: PATCH: Always use ll/sc for mips Message-ID: <20020702114045.A16197@lucon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The ll/sc emulation is implemented in 2.4.0 and above. This patch makes glibc always use ll/sc. H.J. --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glibc-mips-llsc.patch" 2002-07-02 H.J. Lu * sysdeps/mips/pspinlock.c: Don't include . Always use ll/sc. * sysdeps/mips/pt-machine.h: Liekwise. 2002-07-02 H.J. Lu * sysdeps/mips/atomicity.h: Don't include . Always use ll/sc. * sysdeps/unix/sysv/linux/mips/sys/tas.h: Likewise. * sysdeps/unix/sysv/linux/configure.in: Set arch_minimum_kernel to 2.4.0 for mips. * sysdeps/unix/sysv/linux/configure: Regenerated. --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Fri Feb 8 09:08:40 2002 +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Tue Jul 2 10:58:42 2002 @@ -19,12 +19,9 @@ #include #include -#include #include #include "internals.h" -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - /* This implementation is similar to the one used in the Linux kernel. */ int __pthread_spin_lock (pthread_spinlock_t *lock) @@ -34,10 +31,13 @@ __pthread_spin_lock (pthread_spinlock_t asm volatile ("\t\t\t# spin_lock\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %1,%3\n\t" "li %2,1\n\t" "bnez %1,1b\n\t" "sc %2,%0\n\t" + ".set pop\n\t" "beqz %2,1b" : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) @@ -46,17 +46,6 @@ __pthread_spin_lock (pthread_spinlock_t return 0; } -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -int -__pthread_spin_lock (pthread_spinlock_t *lock) -{ - while (_test_and_set ((int *) lock, 1)); - return 0; -} - -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - weak_alias (__pthread_spin_lock, pthread_spin_lock) --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Wed Apr 10 11:38:44 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Tue Jul 2 10:58:21 2002 @@ -23,7 +23,6 @@ #ifndef _PT_MACHINE_H #define _PT_MACHINE_H 1 -#include #include #ifndef PT_EI @@ -51,8 +50,6 @@ register char * stack_pointer __asm__ (" /* Compare-and-swap for semaphores. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - #define HAS_COMPARE_AND_SWAP PT_EI int __compare_and_swap (long int *p, long int oldval, long int newval) @@ -62,11 +59,14 @@ __compare_and_swap (long int *p, long in __asm__ __volatile__ ("/* Inline compare & swap */\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %1,%5\n\t" "move %0,$0\n\t" "bne %1,%3,2f\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" + ".set pop\n\t" "beqz %0,1b\n" "2:\n\t" "/* End compare & swap */" @@ -77,6 +77,4 @@ __compare_and_swap (long int *p, long in return ret; } -#endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - #endif /* pt-machine.h */ --- libc/sysdeps/mips/atomicity.h.llsc Fri Feb 8 09:09:06 2002 +++ libc/sysdeps/mips/atomicity.h Tue Jul 2 10:58:05 2002 @@ -20,11 +20,8 @@ #ifndef _MIPS_ATOMICITY_H #define _MIPS_ATOMICITY_H 1 -#include #include -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - static inline int __attribute__ ((unused)) exchange_and_add (volatile uint32_t *mem, int val) @@ -34,9 +31,12 @@ exchange_and_add (volatile uint32_t *mem __asm__ __volatile__ ("/* Inline exchange & add */\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %0,%3\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" + ".set pop\n\t" "beqz %1,1b\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) @@ -55,9 +55,12 @@ atomic_add (volatile uint32_t *mem, int __asm__ __volatile__ ("/* Inline atomic add */\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %0,%2\n\t" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" + ".set pop\n\t" "beqz %0,1b\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) @@ -74,11 +77,14 @@ compare_and_swap (volatile long int *p, __asm__ __volatile__ ("/* Inline compare & swap */\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %1,%5\n\t" "move %0,$0\n\t" "bne %1,%3,2f\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" + ".set pop\n\t" "beqz %0,1b\n" "2:\n\t" "/* End compare & swap */" @@ -89,37 +95,4 @@ compare_and_swap (volatile long int *p, return ret; } -#else /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -#warning MIPS I atomicity functions are not atomic - -static inline int -__attribute__ ((unused)) -exchange_and_add (volatile uint32_t *mem, int val) -{ - int result = *mem; - *mem += val; - return result; -} - -static inline void -__attribute__ ((unused)) -atomic_add (volatile uint32_t *mem, int val) -{ - *mem += val; -} - -static inline int -__attribute__ ((unused)) -compare_and_swap (volatile long int *p, long int oldval, long int newval) -{ - if (*p != oldval) - return 0; - - *p = newval; - return 1; -} - -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - #endif /* atomicity.h */ --- libc/sysdeps/unix/sysv/linux/configure.in.llsc Tue May 21 11:30:10 2002 +++ libc/sysdeps/unix/sysv/linux/configure.in Tue Jul 2 10:32:35 2002 @@ -59,7 +59,7 @@ case "$machine" in libc_cv_gcc_unwind_find_fde=yes ;; mips*) - arch_minimum_kernel=2.2.15 + arch_minimum_kernel=2.4.0 libc_cv_gcc_unwind_find_fde=yes ;; powerpc*) --- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Fri Feb 8 09:09:06 2002 +++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h Tue Jul 2 10:57:14 2002 @@ -21,8 +21,6 @@ #define _SYS_TAS_H 1 #include -#include -#include __BEGIN_DECLS @@ -34,8 +32,6 @@ extern int _test_and_set (int *p, int v) # define _EXTERN_INLINE extern __inline # endif -# if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - _EXTERN_INLINE int _test_and_set (int *p, int v) __THROW { @@ -44,10 +40,13 @@ _test_and_set (int *p, int v) __THROW __asm__ __volatile__ ("/* Inline test and set */\n" "1:\n\t" + ".set push\n\t" + ".set mips2\n\t" "ll %0,%3\n\t" "move %1,%4\n\t" "beq %0,%4,2f\n\t" "sc %1,%2\n\t" + ".set pop\n\t" "beqz %1,1b\n" "2:\n\t" "/* End test and set */" @@ -58,16 +57,6 @@ _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 /* __USE_EXTERN_INLINES */ __END_DECLS --ikeVEW9yuYc//A+q-- From owner-linux-mips@oss.sgi.com Tue Jul 2 11:47:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62IlHRw009110 for ; Tue, 2 Jul 2002 11:47:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62IlHYn009109 for linux-mips-outgoing; Tue, 2 Jul 2002 11:47:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62IlFRw009096 for ; Tue, 2 Jul 2002 11:47:15 -0700 Received: (qmail 17733 invoked from network); 2 Jul 2002 18:51:08 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 2 Jul 2002 18:51:08 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g62Imh701942 for linux-mips@oss.sgi.com; Tue, 2 Jul 2002 11:48:43 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 2 Jul 2002 11:48:43 -0700 From: Greg Lindahl To: linux-mips@oss.sgi.com Subject: Re: MIPS GOT overflow in gcc 3.2. Message-ID: <20020702114843.B1896@wumpus.internal.keyresearch.com> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025579401.1785.0.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Jul 01, 2002 at 08:09:59PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > AFAIK it happens to mozilla as well. On AlphaLinux, we eventually acquired multigot. Many large apps were tripping on this problem; many big C++ programs essentially use whole-program compilation, and many HPC codes link a bazillion large libraries. I don't understand if -fpic or -fPIC are as good of a solution as multigot. greg From owner-linux-mips@oss.sgi.com Tue Jul 2 11:51:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62IpdRw009822 for ; Tue, 2 Jul 2002 11:51:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62Ipdbb009821 for linux-mips-outgoing; Tue, 2 Jul 2002 11:51:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62IpaRw009793 for ; Tue, 2 Jul 2002 11:51:36 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702185526.MDMA8262.rwcrmhc52.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 18:55:26 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id F3A75125D3; Tue, 2 Jul 2002 11:55:25 -0700 (PDT) Date: Tue, 2 Jul 2002 11:55:25 -0700 From: "H. J. Lu" To: Greg Lindahl Cc: linux-mips@oss.sgi.com Subject: Re: MIPS GOT overflow in gcc 3.2. Message-ID: <20020702115525.A16419@lucon.org> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> <20020702114843.B1896@wumpus.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702114843.B1896@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Tue, Jul 02, 2002 at 11:48:43AM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 11:48:43AM -0700, Greg Lindahl wrote: > > AFAIK it happens to mozilla as well. > > On AlphaLinux, we eventually acquired multigot. Many large apps were > tripping on this problem; many big C++ programs essentially use > whole-program compilation, and many HPC codes link a bazillion large > libraries. I don't understand if -fpic or -fPIC are as good of a > solution as multigot. FYI, it is -Wa,-xgot, not -fPIC. multigot may be better. But it is not supported on mips. Until someone adds it, it is not an option. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 2 11:54:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62IsSRw010233 for ; Tue, 2 Jul 2002 11:54:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62IsSwF010232 for linux-mips-outgoing; Tue, 2 Jul 2002 11:54:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62IsNRw010212 for ; Tue, 2 Jul 2002 11:54:23 -0700 Received: from [216.254.114.110] (helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17PSqk-000640-00; Tue, 02 Jul 2002 13:58:07 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17PSqh-0001me-00; Tue, 02 Jul 2002 14:58:03 -0400 Date: Tue, 2 Jul 2002 14:58:03 -0400 From: Daniel Jacobowitz To: "H. J. Lu" Cc: Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: MIPS GOT overflow in gcc 3.2. Message-ID: <20020702185803.GA6785@nevyn.them.org> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> <20020702114843.B1896@wumpus.internal.keyresearch.com> <20020702115525.A16419@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020702115525.A16419@lucon.org> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 11:55:25AM -0700, H. J. Lu wrote: > On Tue, Jul 02, 2002 at 11:48:43AM -0700, Greg Lindahl wrote: > > > AFAIK it happens to mozilla as well. > > > > On AlphaLinux, we eventually acquired multigot. Many large apps were > > tripping on this problem; many big C++ programs essentially use > > whole-program compilation, and many HPC codes link a bazillion large > > libraries. I don't understand if -fpic or -fPIC are as good of a > > solution as multigot. > > FYI, it is -Wa,-xgot, not -fPIC. multigot may be better. But it is not > supported on mips. Until someone adds it, it is not an option. No, it's the difference between -fpic and -fPIC. Also not yet implemented. I intend to implement multigot in a couple of months if no one else bothers to first. You can not link modules with different GOT models together last I checked, HJ. That means that if any static code from libgcc is used in libjava you'll lose badly with -Wa,-xgot. Ditto libc_nonshared.a. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jul 2 11:55:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62IsxRw010391 for ; Tue, 2 Jul 2002 11:54:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62Isx24010390 for linux-mips-outgoing; Tue, 2 Jul 2002 11:54:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62IstRw010364 for ; Tue, 2 Jul 2002 11:54:55 -0700 Received: from [216.254.114.110] (helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17PSrP-000649-00; Tue, 02 Jul 2002 13:58:48 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17PSrR-0001mi-00; Tue, 02 Jul 2002 14:58:49 -0400 Date: Tue, 2 Jul 2002 14:58:48 -0400 From: Daniel Jacobowitz To: "H. J. Lu" Cc: Eric Christopher , bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Re: Kernel ll/sc emulation? Message-ID: <20020702185848.GB6785@nevyn.them.org> References: <1025548213.1438.7.camel@ghostwheel.cygnus.com> <20020701122313.35d7dd56.bkoz@redhat.com> <1025562305.28484.1.camel@ghostwheel.cygnus.com> <20020701153438.A31602@lucon.org> <1025568244.30577.16.camel@ghostwheel.cygnus.com> <20020701182418.A1600@lucon.org> <1025574335.30581.44.camel@ghostwheel.cygnus.com> <20020701185158.A2134@lucon.org> <1025574717.30577.48.camel@ghostwheel.cygnus.com> <20020701192415.A2617@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020701192415.A2617@lucon.org> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 01, 2002 at 07:24:15PM -0700, H. J. Lu wrote: > On Mon, Jul 01, 2002 at 06:51:57PM -0700, Eric Christopher wrote: > > > > > What do you meant by "it'll be emulated if it fails"? I didn't see any > > > ll/sc emulation in the Linux mips kernel. If you use ll/sc on CPU which > > > doesn't implement ll/sc, your binary will just dump core. > > > > The kernel should trap and emulate the instruction at that point, at > > least as far as I've been told. > > > > That is a news to me. I couldn't find it anywhere in the Linux mips > kernel. Could someone point me to the right place in the Linux mips > kernel source tree? Early 2.4; after 2.4.2 but before 2.4.9 or so. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jul 2 12:27:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62JRFRw014347 for ; Tue, 2 Jul 2002 12:27:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62JRFAN014346 for linux-mips-outgoing; Tue, 2 Jul 2002 12:27:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62JPeRw014153 for ; Tue, 2 Jul 2002 12:25:41 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.2/Debian -5) with ESMTP id g62JTUXK005259 for ; Tue, 2 Jul 2002 21:29:30 +0200 Message-ID: <3D21FF19.5020606@murphy.dk> Date: Tue, 02 Jul 2002 21:29:29 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Patch for NEC VR5000 support (part 1 of several for lasat board support) Content-Type: multipart/mixed; boundary="------------070509040506040600040500" X-Spam-Status: No, hits=-5.0 required=5.0 tests=REAL_THING,PORN_10,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------070509040506040600040500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have attached a patch which applies to the 2.4 branch and adds support for the NEC VR5000. This would be a first step in adding support for the Lasat architectures. A comment from someone with cvs commit access would be nice this time. /Brian --------------070509040506040600040500 Content-Type: text/plain; name="vr5000.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vr5000.diff" ? arch/mips/mm/c-r5000.c --- arch/mips/Makefile 2002/06/25 15:46:52 1.78.2.3 +++ arch/mips/Makefile 2002/07/02 18:46:38 @@ -78,6 +78,9 @@ ifdef CONFIG_CPU_R5000 GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap endif +ifdef CONFIG_CPU_VR5000 +GCCFLAGS += -mcpu=vr5000 -mips2 -Wa,--trap +endif ifdef CONFIG_CPU_R5432 GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap endif --- arch/mips/config.in 2002/06/26 22:35:17 1.154.2.20 +++ arch/mips/config.in 2002/07/02 18:46:39 @@ -324,6 +339,7 @@ R4x00 CONFIG_CPU_R4X00 \ R49XX CONFIG_CPU_TX49XX \ R5000 CONFIG_CPU_R5000 \ + VR5000 CONFIG_CPU_VR5000 \ R5432 CONFIG_CPU_R5432 \ RM7000 CONFIG_CPU_RM7000 \ R52xx CONFIG_CPU_NEVADA \ @@ -355,6 +371,7 @@ if [ "$CONFIG_CPU_R4X00" = "y" -o \ "$CONFIG_CPU_R5000" = "y" -o \ + "$CONFIG_CPU_VR5000" = "y" -o \ "$CONFIG_CPU_RM7000" = "y" -o \ "$CONFIG_CPU_R10000" = "y" -o \ "$CONFIG_CPU_SB1" = "y" -o \ --- arch/mips/kernel/Makefile 2002/06/25 15:47:00 1.51.2.2 +++ arch/mips/kernel/Makefile 2002/07/02 18:46:39 @@ -29,6 +29,7 @@ obj-$(CONFIG_CPU_R4300) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R4X00) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R5000) += r4k_fpu.o r4k_switch.o +obj-$(CONFIG_CPU_VR5000) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R5432) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_RM7000) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_NEVADA) += r4k_fpu.o r4k_switch.o --- arch/mips/mm/Makefile 2002/06/25 15:47:00 1.27.2.1 +++ arch/mips/mm/Makefile 2002/07/02 18:46:41 @@ -21,6 +21,7 @@ obj-$(CONFIG_CPU_R4X00) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_VR41XX) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R5000) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o +obj-$(CONFIG_CPU_VR5000) += pg-r4k.o c-r5000.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_NEVADA) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R5432) += pg-r5432.o c-r5432.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_RM7000) += pg-rm7k.o c-rm7k.o tlb-r4k.o tlbex-r4k.o --- arch/mips/mm/loadmmu.c 2001/11/29 04:47:24 1.45 +++ arch/mips/mm/loadmmu.c 2002/07/02 18:46:41 @@ -52,6 +52,7 @@ extern void ld_mmu_r23000(void); extern void ld_mmu_r4xx0(void); +extern void ld_mmu_r5000(void); extern void ld_mmu_tx39(void); extern void ld_mmu_tx49(void); extern void ld_mmu_r5432(void); @@ -72,6 +73,10 @@ defined(CONFIG_CPU_R4300) || defined(CONFIG_CPU_R5000) || \ defined(CONFIG_CPU_NEVADA) ld_mmu_r4xx0(); + r4k_tlb_init(); +#endif +#if defined(CONFIG_CPU_VR5000) + ld_mmu_r5000(); r4k_tlb_init(); #endif #if defined(CONFIG_CPU_RM7000) Index: include/asm-mips/cacheops.h =================================================================== RCS file: /cvs/linux/include/asm-mips/cacheops.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 cacheops.h --- include/asm-mips/cacheops.h 1997/06/01 03:17:12 1.1.1.1 +++ include/asm-mips/cacheops.h 2002/07/02 18:46:56 @@ -35,6 +35,7 @@ #define Hit_Writeback_Inv_D 0x15 /* 0x16 is unused */ #define Hit_Writeback_Inv_SD 0x17 +#define Page_Invalidate 0x17 #define Hit_Writeback_I 0x18 #define Hit_Writeback_D 0x19 /* 0x1a is unused */ Index: include/asm-mips/cpu.h =================================================================== RCS file: /cvs/linux/include/asm-mips/cpu.h,v retrieving revision 1.24.2.8 diff -u -r1.24.2.8 cpu.h --- include/asm-mips/cpu.h 2002/06/27 14:21:23 1.24.2.8 +++ include/asm-mips/cpu.h 2002/07/02 18:46:56 @@ -53,6 +53,7 @@ #define PRID_IMP_R4640 0x2200 #define PRID_IMP_R4650 0x2200 /* Same as R4640 */ #define PRID_IMP_R5000 0x2300 +#define PRID_IMP_VR5000 0x2300 #define PRID_IMP_TX49 0x2d00 #define PRID_IMP_SONIC 0x2400 #define PRID_IMP_MAGIC 0x2500 @@ -128,7 +129,7 @@ CPU_RM7000, CPU_R5432, CPU_4KC, CPU_5KC, CPU_R4310, CPU_SB1, CPU_TX3912, CPU_TX3922, CPU_TX3927, CPU_AU1000, CPU_4KEC, CPU_4KSC, CPU_VR41XX, CPU_R5500, CPU_TX49XX, CPU_TX39XX, CPU_AU1500, CPU_20KC, - CPU_LAST + CPU_VR5000, CPU_LAST }; #endif /* !__ASSEMBLY__ */ Index: include/asm-mips/r4kcache.h =================================================================== RCS file: /cvs/linux/include/asm-mips/r4kcache.h,v retrieving revision 1.8 diff -u -r1.8 r4kcache.h --- include/asm-mips/r4kcache.h 2001/10/31 02:31:23 1.8 +++ include/asm-mips/r4kcache.h 2002/07/02 18:46:59 @@ -76,6 +76,19 @@ "i" (Hit_Writeback_Inv_D)); } +extern inline void flush_dcache_line_wb(unsigned long addr) +{ + __asm__ __volatile__( + ".set noreorder\n\t" + ".set mips3\n\t" + "cache %1, (%0)\n\t" + ".set mips0\n\t" + ".set reorder" + : + : "r" (addr), + "i" (Hit_Writeback_D)); +} + static inline void invalidate_dcache_line(unsigned long addr) { __asm__ __volatile__( @@ -606,6 +619,40 @@ static inline void blast_scache128_page_indexed(unsigned long page) { cache128_unroll32(page,Index_Writeback_Inv_SD); +} + + +#define cache_unroll(base,op) \ + __asm__ __volatile__(" \ + .set noreorder; \ + .set mips3; \ + cache %1, (%0); \ + .set mips0; \ + .set reorder" \ + : \ + : "r" (base), \ + "i" (op)); + +extern inline void blast_r5000_scache(void) +{ + unsigned long start = KSEG0; + unsigned long end = KSEG0 + scache_size; + + while(start < end) { + cache_unroll(start,Page_Invalidate); + start += 128*sc_lsize; + } +} + +extern inline void blast_r5000_scache_page_indexed(unsigned long page) +{ + unsigned long start = page; + unsigned long end = page + PAGE_SIZE; + + while(start < end) { + cache_unroll(start,Page_Invalidate); + start += 128*sc_lsize; + } } #endif /* !(_MIPS_R4KCACHE_H) */ --- /dev/null Sun Apr 14 10:11:55 2002 +++ arch/mips/mm/c-r5000.c Wed May 29 13:20:24 2002 @@ -0,0 +1,528 @@ +/* + * 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. + * + * r5000.c: R5000 processor variant specific MMU/Cache routines. + * + * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) + * Copyright (C) 1997, 1998, 1999, 2000 Ralf Baechle ralf@gnu.org + * + * To do: + * + * - this code is a overbloated pig + * - many of the bug workarounds are not efficient at all, but at + * least they are functional ... + */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +/* Primary cache parameters. */ +static int icache_size, dcache_size; /* Size in bytes */ +static int ic_lsize, dc_lsize; /* LineSize in bytes */ + +/* Secondary cache (if present) parameters. */ +static unsigned int scache_size, sc_lsize; /* Again, in bytes */ +static int sc_present = 0; + +#include +#include + +#undef DEBUG_CACHE + +/* + * On processors with QED R4600 style two set assosicative cache + * this is the bit which selects the way in the cache for the + * indexed cachops. + */ +#define icache_waybit (icache_size >> 1) +#define dcache_waybit (dcache_size >> 1) + +/* + * If you think for one second that this stuff coming up is a lot + * of bulky code eating too many kernel cache lines. Think _again_. + * + * Consider: + * 1) Taken branches have a 3 cycle penalty on R4k + * 2) The branch itself is a real dead cycle on even R4600/R5000. + * 3) Only one of the following variants of each type is even used by + * the kernel based upon the cache parameters we detect at boot time. + * + * QED. + */ + +static inline void r4k_flush_cache_all_d32i32(void) +{ + unsigned long flags; + + __save_and_cli(flags); + blast_dcache32(); blast_icache32(); + __restore_flags(flags); +} + + +static void r5k_flush_cache_range(struct mm_struct *mm, + unsigned long start, + unsigned long end) +{ + struct vm_area_struct *vma; + unsigned long flags; + + if (mm->context == 0) + return; + + start &= PAGE_MASK; +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + vma = find_vma(mm, start); + if (vma) { + if (mm->context != current->active_mm->context) { + _flush_cache_all(); + } else { + pgd_t *pgd; + pmd_t *pmd; + pte_t *pte; + int text; + + __save_and_cli(flags); + text = vma->vm_flags & VM_EXEC; + while (start < end) { + pgd = pgd_offset(mm, start); + pmd = pmd_offset(pgd, start); + pte = pte_offset(pmd, start); + + if (pte_val(*pte) & _PAGE_VALID) { + blast_dcache32_page(start); + if (text) + blast_icache32_page(start); + } + start += PAGE_SIZE; + } + __restore_flags(flags); + } + } +} + + +/* + * On architectures like the Sparc, we could get rid of lines in + * the cache created only by a certain context, but on the MIPS + * (and actually certain Sparc's) we cannot. + */ + +static void r4k_flush_cache_mm_d32i32(struct mm_struct *mm) +{ + if (mm->context != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + r4k_flush_cache_all_d32i32(); + } +} + + +static void r4k_flush_cache_page_d32i32_r4600(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + unsigned long flags; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + int text; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (mm->context == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + __save_and_cli(flags); + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* + * If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if (!(pte_val(*ptep) & _PAGE_PRESENT)) + goto out; + + text = vma->vm_flags & VM_EXEC; + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) { + blast_dcache32_page(page); + if (text) + blast_icache32_page(page); + } else { + /* Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + page = (KSEG0 + (page & (dcache_size - 1))); + blast_dcache32_page_indexed(page); + blast_dcache32_page_indexed(page ^ dcache_waybit); + if (text) { + blast_icache32_page_indexed(page); + blast_icache32_page_indexed(page ^ icache_waybit); + } + } +out: + __restore_flags(flags); +} + + +/* If the addresses passed to these routines are valid, they are + * either: + * + * 1) In KSEG0, so we can do a direct flush of the page. + * 2) In KSEG2, and since every process can translate those + * addresses all the time in kernel mode we can do a direct + * flush. + * 3) In KSEG1, no flush necessary. + */ + +static void r4k_flush_page_to_ram_d32(struct page *page) +{ + blast_dcache32_page((unsigned long)page_address(page)); +} + + +static void +r4k_flush_icache_range(unsigned long start, unsigned long end) +{ + flush_cache_all(); +} + +/* + * Ok, this seriously sucks. We use them to flush a user page but don't + * know the virtual address, so we have to blast away the whole icache + * which is significantly more expensive than the real thing. + */ +static void +r4k_flush_icache_page_p(struct vm_area_struct *vma, struct page *page) +{ + if (!(vma->vm_flags & VM_EXEC)) + return; + + flush_cache_all(); +} + + +/* + * Writeback and invalidate the primary cache dcache before DMA. + */ + +static void +r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + blast_r5000_scache(); + return; + } + + /* We assume the address is in KSEG0. On the R5000 we + * cannot invalidate less than a page at a time, and + * there is no Hit_xxx cache operations. + */ + a = addr & ~(PAGE_SIZE - 1); + end = (addr + size - 1) & ~(PAGE_SIZE - 1); + while (a <= end) { + blast_r5000_scache_page_indexed(a); /* Page_Invalidate */ + a += PAGE_SIZE; + } +} + +static void +r5k_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + a += dc_lsize; + } + } + if (sc_present) + r5k_dma_cache_inv_sc(addr, size); +} + +static void +r5k_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + invalidate_dcache_line(a); /* Hit_Invalidate_D */ + a += dc_lsize; + } + } + if (sc_present) + r5k_dma_cache_inv_sc(addr, size); +} + +static void +r5k_dma_cache_wback(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + flush_dcache_line_wb(a); /* Hit_Writeback_D */ + a += dc_lsize; + } + } +} + + +/* + * While we're protected against bad userland addresses we don't care + * very much about what happens in that case. Usually a segmentation + * fault will dump the process later on anyway ... + */ +static void r4k_flush_cache_sigtramp(unsigned long addr) +{ + unsigned long daddr, iaddr; + + daddr = addr & ~(dc_lsize - 1); + __asm__ __volatile__("nop;nop;nop;nop"); /* R4600 V1.7 */ + protected_writeback_dcache_line(daddr); + protected_writeback_dcache_line(daddr + dc_lsize); + iaddr = addr & ~(ic_lsize - 1); + protected_flush_icache_line(iaddr); + protected_flush_icache_line(iaddr + ic_lsize); +} + + +/* Detect and size the various r4k caches. */ +static void __init probe_icache(unsigned long config) +{ + icache_size = 1 << (12 + ((config >> 9) & 7)); + ic_lsize = 16 << ((config >> 5) & 1); + + printk("Primary instruction cache %dkb, linesize %d bytes.\n", + icache_size >> 10, ic_lsize); +} + +static void __init probe_dcache(unsigned long config) +{ + dcache_size = 1 << (12 + ((config >> 6) & 7)); + dc_lsize = 16 << ((config >> 4) & 1); + + printk("Primary data cache %dkb, linesize %d bytes.\n", + dcache_size >> 10, dc_lsize); +} + + +/* If you even _breathe_ on this function, look at the gcc output + * and make sure it does not pop things on and off the stack for + * the cache sizing loop that executes in KSEG1 space or else + * you will crash and burn badly. You have been warned. + */ +static int __init probe_scache(unsigned long config) +{ + extern unsigned long stext; + unsigned long flags, addr, begin, end, pow2; + int tmp; + + tmp = ((config >> 17) & 1); + if(tmp) + return 0; + tmp = ((config >> 22) & 3); + switch(tmp) { + case 0: + sc_lsize = 16; + break; + case 1: + sc_lsize = 32; + break; + case 2: + sc_lsize = 64; + break; + case 3: + sc_lsize = 128; + break; + } + + begin = (unsigned long) &stext; + begin &= ~((4 * 1024 * 1024) - 1); + end = begin + (4 * 1024 * 1024); + + /* This is such a bitch, you'd think they would make it + * easy to do this. Away you daemons of stupidity! + */ + __save_and_cli(flags); + + /* Fill each size-multiple cache line with a valid tag. */ + pow2 = (64 * 1024); + for(addr = begin; addr < end; addr = (begin + pow2)) { + unsigned long *p = (unsigned long *) addr; + __asm__ __volatile__("nop" : : "r" (*p)); /* whee... */ + pow2 <<= 1; + } + + /* Load first line with zero (therefore invalid) tag. */ + set_taglo(0); + set_taghi(0); + __asm__ __volatile__("nop; nop; nop; nop;"); /* avoid the hazard */ + __asm__ __volatile__("\n\t.set noreorder\n\t" + ".set mips3\n\t" + "cache 8, (%0)\n\t" + ".set mips0\n\t" + ".set reorder\n\t" : : "r" (begin)); + __asm__ __volatile__("\n\t.set noreorder\n\t" + ".set mips3\n\t" + "cache 9, (%0)\n\t" + ".set mips0\n\t" + ".set reorder\n\t" : : "r" (begin)); + __asm__ __volatile__("\n\t.set noreorder\n\t" + ".set mips3\n\t" + "cache 11, (%0)\n\t" + ".set mips0\n\t" + ".set reorder\n\t" : : "r" (begin)); + + /* Now search for the wrap around point. */ + pow2 = (128 * 1024); + tmp = 0; + for(addr = (begin + (128 * 1024)); addr < (end); addr = (begin + pow2)) { + __asm__ __volatile__("\n\t.set noreorder\n\t" + ".set mips3\n\t" + "cache 7, (%0)\n\t" + ".set mips0\n\t" + ".set reorder\n\t" : : "r" (addr)); + __asm__ __volatile__("nop; nop; nop; nop;"); /* hazard... */ + if(!get_taglo()) + break; + pow2 <<= 1; + } + __restore_flags(flags); + addr -= begin; + printk("Secondary cache sized at %dK linesize %d bytes.\n", + (int) (addr >> 10), sc_lsize); + scache_size = addr; + return 1; +} + +static void __init setup_noscache_funcs(void) +{ + /* For the NEC Vr5000 cachelines are always 32 bytes, so + * we don't test for this explicitly. */ + + _clear_page = r4k_clear_page_d32; + _copy_page = r4k_copy_page_d32; + _flush_cache_all = r4k_flush_cache_all_d32i32; + _flush_cache_range = r5k_flush_cache_range; + _flush_cache_mm = r4k_flush_cache_mm_d32i32; + _flush_cache_page = r4k_flush_cache_page_d32i32_r4600; + _flush_page_to_ram = r4k_flush_page_to_ram_d32; + + ___flush_cache_all = _flush_cache_all; + _flush_icache_page = r4k_flush_icache_page_p; + _dma_cache_wback_inv = r5k_dma_cache_wback_inv; + _dma_cache_wback = r5k_dma_cache_wback; + _dma_cache_inv = r5k_dma_cache_inv; +} + +static void __init setup_scache_funcs(void) +{ + /* The level 2 cache on R5000 is not quite like the one on + * good old R4000. E.g. it cannot have dirty lines, so it has + * no Create_Dirty_Exclusive or xxx_Writeback_Invalidate. + * We assume here that it is sufficient for the flush_cache + * routines to sync the caches to RAM and invalidate the + * primary caches. The secondary cache may still contain + * valid data though. + */ + /* For the NEC Vr5000 cachelines are always 32 bytes, so + * we don't test for this explicitly. */ + + _clear_page = r4k_clear_page_d32; + _copy_page = r4k_copy_page_d32; + _flush_cache_all = r4k_flush_cache_all_d32i32; + _flush_cache_range = r5k_flush_cache_range; + _flush_cache_mm = r4k_flush_cache_mm_d32i32; + _flush_cache_page = r4k_flush_cache_page_d32i32_r4600; + _flush_page_to_ram = r4k_flush_page_to_ram_d32; + + ___flush_cache_all = _flush_cache_all; + _flush_icache_page = r4k_flush_icache_page_p; + _dma_cache_wback_inv = r5k_dma_cache_wback_inv; + _dma_cache_wback = r5k_dma_cache_wback; + _dma_cache_inv = r5k_dma_cache_inv; +} + +typedef int (*probe_func_t)(unsigned long); + +static inline void __init setup_scache(unsigned int config) +{ + probe_func_t probe_scache_kseg1; + + /* Maybe the cpu knows about a l2 cache? */ + probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache)); + sc_present = probe_scache_kseg1(config); + + if (sc_present) { + setup_scache_funcs(); + return; + } + + setup_noscache_funcs(); +} + +void __init ld_mmu_r5000(void) +{ + unsigned long config = read_32bit_cp0_register(CP0_CONFIG); + +#ifdef CONFIG_MIPS_UNCACHED + change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); +#else + change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); +#endif + + probe_icache(config); + probe_dcache(config); + setup_scache(config); + + _flush_cache_sigtramp = r4k_flush_cache_sigtramp; + _flush_icache_range = r4k_flush_icache_range; /* Ouch */ + + __flush_cache_all(); +} --------------070509040506040600040500-- From owner-linux-mips@oss.sgi.com Tue Jul 2 12:58:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62JwtRw018360 for ; Tue, 2 Jul 2002 12:58:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62Jwtwr018359 for linux-mips-outgoing; Tue, 2 Jul 2002 12:58:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-157.ka.dial.de.ignite.net [62.180.196.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62JwnRw018336 for ; Tue, 2 Jul 2002 12:58:50 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g62K2RU09771; Tue, 2 Jul 2002 22:02:27 +0200 Date: Tue, 2 Jul 2002 22:02:27 +0200 From: Ralf Baechle To: Brian Murphy Cc: linux-mips@oss.sgi.com Subject: Re: Patch for NEC VR5000 support (part 1 of several for lasat board support) Message-ID: <20020702220227.A9566@dea.linux-mips.net> References: <3D21FF19.5020606@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D21FF19.5020606@murphy.dk>; from brian@murphy.dk on Tue, Jul 02, 2002 at 09:29:29PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 09:29:29PM +0200, Brian Murphy wrote: > I have attached a patch which applies to the 2.4 branch and adds > support for the NEC VR5000. This would be a first step in > adding support for the Lasat architectures. > > A comment from someone with cvs commit access would be nice > this time. As NEC's VR5000 is a plain normal R5000 why are you duplicating the processor support with slight variations? Ralf From owner-linux-mips@oss.sgi.com Tue Jul 2 13:03:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62K37Rw018968 for ; Tue, 2 Jul 2002 13:03:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62K36En018967 for linux-mips-outgoing; Tue, 2 Jul 2002 13:03:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-157.ka.dial.de.ignite.net [62.180.196.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62K31Rw018943 for ; Tue, 2 Jul 2002 13:03:02 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g62K6pA09827; Tue, 2 Jul 2002 22:06:51 +0200 Date: Tue, 2 Jul 2002 22:06:51 +0200 From: Ralf Baechle To: "H. J. Lu" Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020702220651.B9566@dea.linux-mips.net> References: <20020702114045.A16197@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702114045.A16197@lucon.org>; from hjl@lucon.org on Tue, Jul 02, 2002 at 11:40:45AM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote: > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > glibc always use ll/sc. Which means the overhead of two syscalls instead of one sysmips() call for something that is assumed to be dirt cheap. R3000, R5900 etc. users won't this patch you, which'll have significant impact on their glibc performance. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 2 13:03:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62K3tRw019156 for ; Tue, 2 Jul 2002 13:03:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62K3tFx019155 for linux-mips-outgoing; Tue, 2 Jul 2002 13:03:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-157.ka.dial.de.ignite.net [62.180.196.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62K3oRw019135 for ; Tue, 2 Jul 2002 13:03:51 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g62K7Xg09848; Tue, 2 Jul 2002 22:07:33 +0200 Date: Tue, 2 Jul 2002 22:07:33 +0200 From: Ralf Baechle To: Sam Cc: linux-mips@oss.sgi.com Subject: Re: # trap handler example Message-ID: <20020702220733.C9566@dea.linux-mips.net> References: <000901c221ae$2a9a0c00$780411ac@sam> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000901c221ae$2a9a0c00$780411ac@sam>; from iskoo@ms45.hinet.net on Tue, Jul 02, 2002 at 05:52:22PM +0800 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 05:52:22PM +0800, Sam wrote: > I want to write a trap handler for unalignment memory read/write error. arch/mips/kernel/unaligned.c. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 2 13:05:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62K5RRw019439 for ; Tue, 2 Jul 2002 13:05:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62K5RHw019438 for linux-mips-outgoing; Tue, 2 Jul 2002 13:05:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-157.ka.dial.de.ignite.net [62.180.196.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62K5LRw019418 for ; Tue, 2 Jul 2002 13:05:23 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g62K8pI09860; Tue, 2 Jul 2002 22:08:51 +0200 Date: Tue, 2 Jul 2002 22:08:51 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: "H. J. Lu" , Eric Christopher , bkoz@redhat.com, linux-mips@oss.sgi.com Subject: Re: Kernel ll/sc emulation? Message-ID: <20020702220851.D9566@dea.linux-mips.net> References: <20020701122313.35d7dd56.bkoz@redhat.com> <1025562305.28484.1.camel@ghostwheel.cygnus.com> <20020701153438.A31602@lucon.org> <1025568244.30577.16.camel@ghostwheel.cygnus.com> <20020701182418.A1600@lucon.org> <1025574335.30581.44.camel@ghostwheel.cygnus.com> <20020701185158.A2134@lucon.org> <1025574717.30577.48.camel@ghostwheel.cygnus.com> <20020701192415.A2617@lucon.org> <20020702185848.GB6785@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702185848.GB6785@nevyn.them.org>; from dan@debian.org on Tue, Jul 02, 2002 at 02:58:48PM -0400 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 02:58:48PM -0400, Daniel Jacobowitz wrote: > Early 2.4; after 2.4.2 but before 2.4.9 or so. The code is actually there quite a bit longer but by then it finally got fixed ... Ralf From owner-linux-mips@oss.sgi.com Tue Jul 2 13:06:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62K6qRw019712 for ; Tue, 2 Jul 2002 13:06:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62K6q9o019711 for linux-mips-outgoing; Tue, 2 Jul 2002 13:06:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62K6RRw019639 for ; Tue, 2 Jul 2002 13:06:28 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.2/Debian -5) with ESMTP id g62KAIXK007464 for ; Tue, 2 Jul 2002 22:10:18 +0200 Message-ID: <3D2208AA.6040009@murphy.dk> Date: Tue, 02 Jul 2002 22:10:18 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: LASAT board mtd support Content-Type: multipart/mixed; boundary="------------050402030206010203080203" X-Spam-Status: No, hits=-4.3 required=5.0 tests=TO_LOCALPART_EQ_REAL,PORN_10,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------050402030206010203080203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find attached a patch to add mtd support for the Lasat platforms. Patch applies to the 2.4 CVS branch. /Brian --------------050402030206010203080203 Content-Type: text/plain; name="mtd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mtd.diff" --- drivers/mtd/maps/Config.in 2002/06/26 22:35:49 1.3.2.3 +++ drivers/mtd/maps/Config.in 2002/07/02 18:46:45 @@ -57,6 +57,7 @@ int ' Bus width in octets' CONFIG_MTD_CSTM_MIPS_IXX_BUSWIDTH 2 fi dep_tristate ' Momenco Ocelot boot flash device' CONFIG_MTD_OCELOT $CONFIG_MOMENCO_OCELOT + dep_tristate ' LASAT flash device' CONFIG_MTD_LASAT $CONFIG_MTD_CFI $CONFIG_LASAT fi if [ "$CONFIG_SUPERH" = "y" ]; then --- drivers/mtd/maps/Makefile 2002/06/26 22:35:49 1.2.2.3 +++ drivers/mtd/maps/Makefile 2002/07/02 18:46:45 @@ -38,6 +38,7 @@ obj-$(CONFIG_MTD_PCI) += pci.o obj-$(CONFIG_MTD_PB1000) += pb1xxx-flash.o obj-$(CONFIG_MTD_PB1500) += pb1xxx-flash.o +obj-$(CONFIG_MTD_LASAT) += lasat.o obj-$(CONFIG_MTD_AUTCPU12) += autcpu12-nvram.o include $(TOPDIR)/Rules.make --- /dev/null Sun Apr 14 10:11:55 2002 +++ drivers/mtd/maps/lasat.c Wed May 29 13:20:24 2002 @@ -0,0 +1,136 @@ +/* + * Flash device on lasat 100 and 200 boards + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static struct mtd_info *mymtd; + +static volatile unsigned int *wpreg = (void *)(LASAT_FLASHWP_REG); + +static __u8 sp_read8(struct map_info *map, unsigned long ofs) +{ + return __raw_readb(map->map_priv_1 + ofs); +} + +static __u16 sp_read16(struct map_info *map, unsigned long ofs) +{ + return __raw_readw(map->map_priv_1 + ofs); +} + +static __u32 sp_read32(struct map_info *map, unsigned long ofs) +{ + return __raw_readl(map->map_priv_1 + ofs); +} + +static void sp_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len) +{ + memcpy_fromio(to, map->map_priv_1 + from, len); +} + +static void sp_write8(struct map_info *map, __u8 d, unsigned long adr) +{ + __raw_writeb(d, map->map_priv_1 + adr); + mb(); +} + +static void sp_write16(struct map_info *map, __u16 d, unsigned long adr) +{ + __raw_writew(d, map->map_priv_1 + adr); + mb(); +} + +static void sp_write32(struct map_info *map, __u32 d, unsigned long adr) +{ + __raw_writel(d, map->map_priv_1 + adr); + mb(); +} + +static void sp_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len) +{ + memcpy_toio(map->map_priv_1 + to, from, len); +} + +static struct map_info sp_map = { + name: "SP flash", + buswidth: 4, + read8: sp_read8, + read16: sp_read16, + read32: sp_read32, + copy_from: sp_copy_from, + write8: sp_write8, + write16: sp_write16, + write32: sp_write32, + copy_to: sp_copy_to +}; + +/* partition_info gives details on the logical partitions that the split the + * single flash device into. If the size if zero we use up to the end of the + * device. */ +static struct mtd_partition partition_info[LASAT_MTD_LAST]; +static char *lasat_mtd_partnames[] = {"Bootloader", "Service", "Normal", "Filesystem", "Config"}; + +static int __init init_sp(void) +{ + int i; + /* this does not play well with the old flash code which + * protects and uprotects the flash when necessary */ + printk(KERN_NOTICE "Unprotecting flash\n"); + *wpreg |= LASAT_FLASHWP_DIS; + + sp_map.map_priv_1 = flash_partition_start(LASAT_MTD_BOOTLOADER); + sp_map.size = lasat_board_info.li_flash_size; + + printk(KERN_NOTICE "sp flash device: %lx at %lx\n", + sp_map.size, sp_map.map_priv_1); + + for (i=0; i < LASAT_MTD_LAST; i++) + partition_info[i].name = lasat_mtd_partnames[i]; + + mymtd = do_map_probe("cfi_probe", &sp_map); + if (mymtd) { + u32 size, offset = 0; + + mymtd->module = THIS_MODULE; + + for (i=0; i < LASAT_MTD_LAST; i++) { + size = flash_partition_size(i); + partition_info[i].size = size; + partition_info[i].offset = offset; + offset += size; + } + + add_mtd_partitions( mymtd, partition_info, LASAT_MTD_LAST ); + return 0; + } + + return -ENXIO; +} + +static void __exit cleanup_sp(void) +{ + if (mymtd) { + del_mtd_partitions(mymtd); + map_destroy(mymtd); + } + if (sp_map.map_priv_1) { + sp_map.map_priv_1 = 0; + } +} + +module_init(init_sp); +module_exit(cleanup_sp); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Brian Murphy "); +MODULE_DESCRIPTION("Lasat Safepipe/Masquerade MTD map driver"); --------------050402030206010203080203-- From owner-linux-mips@oss.sgi.com Tue Jul 2 13:39:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g62KdTRw023856 for ; Tue, 2 Jul 2002 13:39:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g62KdTdv023855 for linux-mips-outgoing; Tue, 2 Jul 2002 13:39:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g62KdMRw023822 for ; Tue, 2 Jul 2002 13:39:23 -0700 Received: from murphy.dk (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.2/Debian -5) with ESMTP id g62KhCXK012716 for ; Tue, 2 Jul 2002 22:43:13 +0200 Message-ID: <3D221060.80602@murphy.dk> Date: Tue, 02 Jul 2002 22:43:12 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: Re: Patch for NEC VR5000 support (part 1 of several for lasat board support) References: <3D21FF19.5020606@murphy.dk> <20020702220227.A9566@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: >On Tue, Jul 02, 2002 at 09:29:29PM +0200, Brian Murphy wrote: > >>I have attached a patch which applies to the 2.4 branch and adds >>support for the NEC VR5000. This would be a first step in >>adding support for the Lasat architectures. >> >>A comment from someone with cvs commit access would be nice >>this time. >> > >As NEC's VR5000 is a plain normal R5000 why are you duplicating the >processor support with slight variations? > > Ralf > I believe the problem is in the (lack of) secondary cache support when the R5000 target is selected in the standard kernel. I thought that making a seperate VR5000 cpu was then a safer option leaving the R5000 as it is and presumably working on the platforms it is used on. I have no possibility of testing on those platforms to ensure any integration is successful. /Brian From owner-linux-mips@oss.sgi.com Tue Jul 2 22:44:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g635iRRw015258 for ; Tue, 2 Jul 2002 22:44:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g635iRS7015257 for linux-mips-outgoing; Tue, 2 Jul 2002 22:44:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from r-bu.iij4u.or.jp (r-bu.iij4u.or.jp [210.130.0.89]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g635iMRw015248 for ; Tue, 2 Jul 2002 22:44:23 -0700 Received: from pudding ([202.216.29.50]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g635mJG24727 for ; Wed, 3 Jul 2002 14:48:19 +0900 (JST) Date: Wed, 3 Jul 2002 14:44:04 +0900 From: Yoichi Yuasa To: linux-mips@oss.sgi.com Subject: Small correction for fault.c Message-Id: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> Organization: MontaVista Software Japan Inc. X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I found a include file required for "arch/mips/mm/fault.c". This is for unblank_screen(). --- linux.orig/arch/mips/mm/fault.c Thu Jun 27 14:14:14 2002 +++ linux/arch/mips/mm/fault.c Wed Jul 3 14:37:03 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include -Yoichi From owner-linux-mips@oss.sgi.com Wed Jul 3 01:11:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g638BvRw019527 for ; Wed, 3 Jul 2002 01:11:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g638BvA1019526 for linux-mips-outgoing; Wed, 3 Jul 2002 01:11:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g638BmRw019510 for ; Wed, 3 Jul 2002 01:11:48 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17PfGK-000x2D-00 for linux-mips@oss.sgi.com; Wed, 03 Jul 2002 10:13:20 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17PfIa-0003nx-00 for ; Wed, 03 Jul 2002 10:15:40 +0200 Date: Wed, 3 Jul 2002 10:15:40 +0200 To: linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c Message-ID: <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> References: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> User-Agent: Mutt/1.3.28i From: Thiemo Seufer X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Yoichi Yuasa wrote: > Hi, > > I found a include file required for "arch/mips/mm/fault.c". > This is for unblank_screen(). > > --- linux.orig/arch/mips/mm/fault.c Thu Jun 27 14:14:14 2002 > +++ linux/arch/mips/mm/fault.c Wed Jul 3 14:37:03 2002 > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include For MIPS64 this fails (MAX_NR_CONSOLES is defined in linux/tty.h): In file included from fault.c:23: /bigdisk/combined/source-linux/include/linux/vt_kern.h:32: error: MAX_NR_CONSOLES' undeclared here (not in a function) I would prefer the patch below. Thiemo diff -BurpNX /bigdisk/src/dontdiff source-linux-orig/arch/mips/mm/fault.c source-linux/arch/mips/mm/fault.c --- source-linux-orig/arch/mips/mm/fault.c Sat Jun 1 22:41:25 2002 +++ source-linux/arch/mips/mm/fault.c Wed Jul 3 10:13:26 2002 @@ -44,6 +44,8 @@ extern spinlock_t timerlist_lock; */ void bust_spinlocks(int yes) { + extern void unblank_screen(void); + spin_lock_init(&timerlist_lock); if (yes) { oops_in_progress = 1; diff -BurpNX /bigdisk/src/dontdiff source-linux-orig/arch/mips64/mm/fault.c source-linux/arch/mips64/mm/fault.c --- source-linux-orig/arch/mips64/mm/fault.c Mon Jul 1 12:05:04 2002 +++ source-linux/arch/mips64/mm/fault.c Wed Jul 3 10:13:26 2002 @@ -66,6 +66,8 @@ extern spinlock_t timerlist_lock; */ void bust_spinlocks(int yes) { + extern void unblank_screen(void); + spin_lock_init(&timerlist_lock); if (yes) { oops_in_progress = 1; From owner-linux-mips@oss.sgi.com Wed Jul 3 02:17:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g639HKRw021536 for ; Wed, 3 Jul 2002 02:17:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g639HKQM021535 for linux-mips-outgoing; Wed, 3 Jul 2002 02:17:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from r-bu.iij4u.or.jp (r-bu.iij4u.or.jp [210.130.0.89]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g639HDRw021523 for ; Wed, 3 Jul 2002 02:17:13 -0700 Received: from pudding ([202.216.29.50]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g639L6G15793; Wed, 3 Jul 2002 18:21:07 +0900 (JST) Date: Wed, 3 Jul 2002 18:16:51 +0900 From: Yoichi Yuasa To: Thiemo Seufer Cc: yoichi_yuasa@montavista.co.jp, linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c Message-Id: <20020703181651.779116be.yoichi_yuasa@montavista.co.jp> In-Reply-To: <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> References: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> Organization: MontaVista Software Japan Inc. X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Thiemo, On Wed, 3 Jul 2002 10:15:40 +0200 Thiemo Seufer wrote: > Yoichi Yuasa wrote: > > Hi, > > > > I found a include file required for "arch/mips/mm/fault.c". > > This is for unblank_screen(). > > > > --- linux.orig/arch/mips/mm/fault.c Thu Jun 27 14:14:14 2002 > > +++ linux/arch/mips/mm/fault.c Wed Jul 3 14:37:03 2002 > > @@ -19,6 +19,7 @@ > > #include > > #include > > #include > > +#include > > For MIPS64 this fails (MAX_NR_CONSOLES is defined in linux/tty.h): > > In file included from fault.c:23: > /bigdisk/combined/source-linux/include/linux/vt_kern.h:32: error: > MAX_NR_CONSOLES' undeclared here (not in a function) I did checkout cvs and I checked also about MIPS64. There was no problem by my correction. "arch/mips64/mm/fault.c" is including . is including . -Yoichi From owner-linux-mips@oss.sgi.com Wed Jul 3 02:58:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g639wIRw023560 for ; Wed, 3 Jul 2002 02:58:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g639wIFN023559 for linux-mips-outgoing; Wed, 3 Jul 2002 02:58:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g639wERw023549 for ; Wed, 3 Jul 2002 02:58:14 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by deliverator.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 DAA06021 for ; Wed, 3 Jul 2002 03:02:11 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17Pglv-000xEO-00 for linux-mips@oss.sgi.com; Wed, 03 Jul 2002 11:50:03 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17PgoD-0008JD-00 for ; Wed, 03 Jul 2002 11:52:25 +0200 Date: Wed, 3 Jul 2002 11:52:24 +0200 To: linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c Message-ID: <20020703095224.GV16753@rembrandt.csv.ica.uni-stuttgart.de> References: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> <20020703181651.779116be.yoichi_yuasa@montavista.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020703181651.779116be.yoichi_yuasa@montavista.co.jp> User-Agent: Mutt/1.3.28i From: Thiemo Seufer X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Yoichi Yuasa wrote: [snip] > > In file included from fault.c:23: > > /bigdisk/combined/source-linux/include/linux/vt_kern.h:32: error: > > MAX_NR_CONSOLES' undeclared here (not in a function) > > I did checkout cvs and I checked also about MIPS64. > There was no problem by my correction. > > "arch/mips64/mm/fault.c" is including . > is including . Then you are using a different CVS than I do. In CVS at oss.sgi.com, linux/sched.h does not include linux/tty.h. Thiemo From owner-linux-mips@oss.sgi.com Wed Jul 3 03:24:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63AOpRw027355 for ; Wed, 3 Jul 2002 03:24:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63AOpmK027354 for linux-mips-outgoing; Wed, 3 Jul 2002 03:24:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from r-bu.iij4u.or.jp (r-bu.iij4u.or.jp [210.130.0.89]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63AOjRw027342 for ; Wed, 3 Jul 2002 03:24:46 -0700 Received: from pudding ([202.216.29.50]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g63AShG24119 for ; Wed, 3 Jul 2002 19:28:43 +0900 (JST) Date: Wed, 3 Jul 2002 19:24:28 +0900 From: Yoichi Yuasa To: linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c Message-Id: <20020703192428.78aa0c58.yoichi_yuasa@montavista.co.jp> In-Reply-To: <20020703095224.GV16753@rembrandt.csv.ica.uni-stuttgart.de> References: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> <20020703181651.779116be.yoichi_yuasa@montavista.co.jp> <20020703095224.GV16753@rembrandt.csv.ica.uni-stuttgart.de> Organization: MontaVista Software Japan Inc. X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Thiemo, On Wed, 3 Jul 2002 11:52:24 +0200 Thiemo Seufer wrote: > Yoichi Yuasa wrote: > [snip] > > > In file included from fault.c:23: > > > /bigdisk/combined/source-linux/include/linux/vt_kern.h:32: error: > > > MAX_NR_CONSOLES' undeclared here (not in a function) > > > > I did checkout cvs and I checked also about MIPS64. > > There was no problem by my correction. > > > > "arch/mips64/mm/fault.c" is including . > > is including . > > Then you are using a different CVS than I do. In CVS at oss.sgi.com, > linux/sched.h does not include linux/tty.h. I use version 2.4.19-rc1(linux_2_4 tag) on oss.sgi.com. -Yoichi From owner-linux-mips@oss.sgi.com Wed Jul 3 04:43:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63Bh4Rw030411 for ; Wed, 3 Jul 2002 04:43:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63Bh4es030410 for linux-mips-outgoing; Wed, 3 Jul 2002 04:43:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63Bh1Rw030401 for ; Wed, 3 Jul 2002 04:43:01 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) 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 DAA08075 for ; Wed, 3 Jul 2002 03:57:04 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17Phcj-000xKw-00 for linux-mips@oss.sgi.com; Wed, 03 Jul 2002 12:44:37 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17Phf1-0001HQ-00 for ; Wed, 03 Jul 2002 12:46:59 +0200 Date: Wed, 3 Jul 2002 12:46:59 +0200 To: linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c Message-ID: <20020703104659.GX16753@rembrandt.csv.ica.uni-stuttgart.de> References: <20020703144404.4d349037.yoichi_yuasa@montavista.co.jp> <20020703081539.GU16753@rembrandt.csv.ica.uni-stuttgart.de> <20020703181651.779116be.yoichi_yuasa@montavista.co.jp> <20020703095224.GV16753@rembrandt.csv.ica.uni-stuttgart.de> <20020703192428.78aa0c58.yoichi_yuasa@montavista.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020703192428.78aa0c58.yoichi_yuasa@montavista.co.jp> User-Agent: Mutt/1.3.28i From: Thiemo Seufer X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Yoichi Yuasa wrote: [snip] > > Then you are using a different CVS than I do. In CVS at oss.sgi.com, > > linux/sched.h does not include linux/tty.h. > > I use version 2.4.19-rc1(linux_2_4 tag) on oss.sgi.com. I use HEAD. The change from CVS Revision 1.61 to 1.62 was dropping the tty.h include. Apparently a 2.5 cleanup. Thiemo From owner-linux-mips@oss.sgi.com Wed Jul 3 09:31:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63GVcRw009960 for ; Wed, 3 Jul 2002 09:31:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63GVcZK009959 for linux-mips-outgoing; Wed, 3 Jul 2002 09:31:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63GVORw009940 for ; Wed, 3 Jul 2002 09:31:25 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020703163519.IVNN15755.rwcrmhc53.attbi.com@ocean.lucon.org>; Wed, 3 Jul 2002 16:35:19 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9351D125D3; Wed, 3 Jul 2002 09:35:18 -0700 (PDT) Date: Wed, 3 Jul 2002 09:35:18 -0700 From: "H. J. Lu" To: Eric Christopher Cc: linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com, gcc@gcc.gnu.org Subject: RFC: Use -Wa,-xgot for Linux/mips (Re: MIPS GOT overflow in gcc 3.2.) Message-ID: <20020703093518.A2401@lucon.org> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025579401.1785.0.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Jul 01, 2002 at 08:09:59PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 01, 2002 at 08:09:59PM -0700, Eric Christopher wrote: > > > AFAIK it happens to mozilla as well. > > > > Guh. > > There are a few different possible solutions, one is to do the > -fPIC/-fpic split, another is to copy to SGI multigot, I'm sure there > are other solutions as well... > I am enclosing a kludge here. With that, I got http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00062.html Any comments? H.J. --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libjava-xgot.patch" 2002-07-02 H.J. Lu * ltcf-c.sh (ac_cv_prog_cc_pic): Add "-Wa,-xgot" for Linux/mips. * ltcf-cxx.sh (ac_cv_prog_cc_pic): Likewise. * ltcf-gcj.sh (ac_cv_prog_cc_pic): Likewise. --- gcc/ltcf-c.sh.xgot Mon Sep 10 08:39:17 2001 +++ gcc/ltcf-c.sh Tue Jul 2 00:06:54 2002 @@ -672,6 +672,14 @@ else ac_cv_prog_cc_pic=-Kconform_pic fi ;; + linux*) + ac_cv_prog_cc_pic='-fPIC' + case "$host_cpu" in + mips*) + ac_cv_prog_cc_pic="$ac_cv_prog_cc_pic -Wa,-xgot" + ;; + esac + ;; *) ac_cv_prog_cc_pic='-fPIC' ;; --- gcc/ltcf-cxx.sh.xgot Mon Sep 10 08:39:17 2001 +++ gcc/ltcf-cxx.sh Tue Jul 2 13:40:41 2002 @@ -707,6 +707,14 @@ if test "$with_gcc" = yes; then ac_cv_prog_cc_pic=-Kconform_pic fi ;; + linux*) + ac_cv_prog_cc_pic='-fPIC' + case "$host_cpu" in + mips*) + ac_cv_prog_cc_pic="$ac_cv_prog_cc_pic -Wa,-xgot" + ;; + esac + ;; *) ac_cv_prog_cc_pic='-fPIC' ;; --- gcc/ltcf-gcj.sh.xgot Mon Sep 10 08:39:17 2001 +++ gcc/ltcf-gcj.sh Mon Jul 1 23:49:06 2002 @@ -639,6 +639,14 @@ fi ac_cv_prog_cc_pic=-Kconform_pic fi ;; + linux*) + ac_cv_prog_cc_pic='-fPIC' + case "$host_cpu" in + mips*) + ac_cv_prog_cc_pic="$ac_cv_prog_cc_pic -Wa,-xgot" + ;; + esac + ;; *) ac_cv_prog_cc_pic='-fPIC' ;; --MGYHOYXEY6WxJCY8-- From owner-linux-mips@oss.sgi.com Wed Jul 3 09:36:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63GamRw010196 for ; Wed, 3 Jul 2002 09:36:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63GalsT010195 for linux-mips-outgoing; Wed, 3 Jul 2002 09:36:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63GagRw010175 for ; Wed, 3 Jul 2002 09:36:42 -0700 Received: from dsl254-114-096.nyc1.dsl.speakeasy.net ([216.254.114.96] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17PnBD-0007Pj-00; Wed, 03 Jul 2002 11:40:35 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17PnBH-0003KE-00; Wed, 03 Jul 2002 12:40:39 -0400 Date: Wed, 3 Jul 2002 12:40:39 -0400 From: Daniel Jacobowitz To: "H. J. Lu" Cc: Eric Christopher , linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: Use -Wa,-xgot for Linux/mips (Re: MIPS GOT overflow in gcc 3.2.) Message-ID: <20020703164039.GA12583@nevyn.them.org> Mail-Followup-To: "H. J. Lu" , Eric Christopher , linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com, gcc@gcc.gnu.org References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> <20020703093518.A2401@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020703093518.A2401@lucon.org> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 03, 2002 at 09:35:18AM -0700, H. J. Lu wrote: > On Mon, Jul 01, 2002 at 08:09:59PM -0700, Eric Christopher wrote: > > > > > AFAIK it happens to mozilla as well. > > > > > > Guh. > > > > There are a few different possible solutions, one is to do the > > -fPIC/-fpic split, another is to copy to SGI multigot, I'm sure there > > are other solutions as well... > > > > I am enclosing a kludge here. With that, I got > > http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00062.html > > Any comments? Did you see my message about mixing GOT models? I'd need Ralf or Eric to confirm this, but I'm pretty sure there's a lot of luck involved in your workaround. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Jul 3 09:46:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63GkFRw010734 for ; Wed, 3 Jul 2002 09:46:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63GkFc8010733 for linux-mips-outgoing; Wed, 3 Jul 2002 09:46:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63GkARw010722 for ; Wed, 3 Jul 2002 09:46:10 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020703165005.RGDG8262.rwcrmhc52.attbi.com@ocean.lucon.org>; Wed, 3 Jul 2002 16:50:05 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id F1424125D3; Wed, 3 Jul 2002 09:50:03 -0700 (PDT) Date: Wed, 3 Jul 2002 09:50:03 -0700 From: "H. J. Lu" To: Eric Christopher , linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: Use -Wa,-xgot for Linux/mips (Re: MIPS GOT overflow in gcc 3.2.) Message-ID: <20020703095003.B2527@lucon.org> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> <20020703093518.A2401@lucon.org> <20020703164039.GA12583@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020703164039.GA12583@nevyn.them.org>; from dan@debian.org on Wed, Jul 03, 2002 at 12:40:39PM -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 03, 2002 at 12:40:39PM -0400, Daniel Jacobowitz wrote: > On Wed, Jul 03, 2002 at 09:35:18AM -0700, H. J. Lu wrote: > > On Mon, Jul 01, 2002 at 08:09:59PM -0700, Eric Christopher wrote: > > > > > > > AFAIK it happens to mozilla as well. > > > > > > > > Guh. > > > > > > There are a few different possible solutions, one is to do the > > > -fPIC/-fpic split, another is to copy to SGI multigot, I'm sure there > > > are other solutions as well... > > > > > > > I am enclosing a kludge here. With that, I got > > > > http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00062.html > > > > Any comments? > > Did you see my message about mixing GOT models? I'd need Ralf or Eric to A testcase? H.J. From owner-linux-mips@oss.sgi.com Wed Jul 3 14:51:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63LpCRw003789 for ; Wed, 3 Jul 2002 14:51:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63LpCFZ003788 for linux-mips-outgoing; Wed, 3 Jul 2002 14:51:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-235.ka.dial.de.ignite.net [62.180.196.235]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63Lp7Rw003769 for ; Wed, 3 Jul 2002 14:51:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g63Lt6Y21822 for linux-mips@oss.sgi.com; Wed, 3 Jul 2002 23:55:06 +0200 Date: Wed, 3 Jul 2002 23:55:06 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com Subject: MIPS Atlas board Message-ID: <20020703235506.A21798@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Accept-Language: de,en,fr X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Anybody actually still using the MIPS Atlas board? If so, what kernel versions? I've not had any feedback about the Atlas in many moons, so I'm considering to drop support for it for 2.5. Comment? Ralf From owner-linux-mips@oss.sgi.com Wed Jul 3 15:59:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g63Mx0Rw017342 for ; Wed, 3 Jul 2002 15:59:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g63Mx0pO017341 for linux-mips-outgoing; Wed, 3 Jul 2002 15:59:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-235.ka.dial.de.ignite.net [62.180.196.235]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g63MwrRw017287 for ; Wed, 3 Jul 2002 15:58:54 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g63N2WB22402; Thu, 4 Jul 2002 01:02:32 +0200 Date: Thu, 4 Jul 2002 01:02:32 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: "H. J. Lu" , Eric Christopher , linux-mips@oss.sgi.com, GNU C Library , binutils@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: Use -Wa,-xgot for Linux/mips (Re: MIPS GOT overflow in gcc 3.2.) Message-ID: <20020704010232.A21624@dea.linux-mips.net> References: <20020701184640.A2043@lucon.org> <1025575632.30577.64.camel@ghostwheel.cygnus.com> <1025579401.1785.0.camel@ghostwheel.cygnus.com> <20020703093518.A2401@lucon.org> <20020703164039.GA12583@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020703164039.GA12583@nevyn.them.org>; from dan@debian.org on Wed, Jul 03, 2002 at 12:40:39PM -0400 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 03, 2002 at 12:40:39PM -0400, Daniel Jacobowitz wrote: > Did you see my message about mixing GOT models? I'd need Ralf or Eric to > confirm this, but I'm pretty sure there's a lot of luck involved in > your workaround. I've not seen your posting but yes, due to other static objects involved into linking there definately is luck involved. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 3 17:19:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g640JPRw023371 for ; Wed, 3 Jul 2002 17:19:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g640JPp6023370 for linux-mips-outgoing; Wed, 3 Jul 2002 17:19:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g640JMRw023355 for ; Wed, 3 Jul 2002 17:19:22 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020704002318.DFDY8262.rwcrmhc52.attbi.com@ocean.lucon.org> for ; Thu, 4 Jul 2002 00:23:18 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id CDEEB125D3; Wed, 3 Jul 2002 17:23:17 -0700 (PDT) Date: Wed, 3 Jul 2002 17:23:17 -0700 From: "H. J. Lu" To: linux-mips@oss.sgi.com Subject: gcc 3.1 is available for RedHat 7.3 Message-ID: <20020703172317.A9327@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The gcc 3.1 and glibc-devel 2.2.5-36.2 mips/mipsel binary rpms for RedHat 7.3 are at ftp://oss.sgi.com/pub/linux/mips/redhat/7.3/test/ The simple install instructions are in INSTALL. I am intested in any feedbacks. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 3 23:27:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g646R0Rw008613 for ; Wed, 3 Jul 2002 23:27:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g646R0Aq008612 for linux-mips-outgoing; Wed, 3 Jul 2002 23:27:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from r-bu.iij4u.or.jp (r-bu.iij4u.or.jp [210.130.0.89]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g646QaRw008597 for ; Wed, 3 Jul 2002 23:26:36 -0700 Received: from pudding ([202.216.29.50]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g646UaG02192 for ; Thu, 4 Jul 2002 15:30:36 +0900 (JST) Date: Thu, 4 Jul 2002 15:26:20 +0900 From: Yoichi Yuasa To: linux-mips@oss.sgi.com Subject: patch for little problems Message-Id: <20020704152620.47209cdd.yoichi_yuasa@montavista.co.jp> Organization: MontaVista Software Japan Inc. X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Thu__4_Jul_2002_15:26:20_+0900_08259f40" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --Multipart_Thu__4_Jul_2002_15:26:20_+0900_08259f40 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Here is a patch for small problems. This patch can keep silent about some warning from gcc. Please commit linux_2_4 tag on CVS. -Yoichi --Multipart_Thu__4_Jul_2002_15:26:20_+0900_08259f40 Content-Type: text/plain; name="little-problems.patch" Content-Disposition: attachment; filename="little-problems.patch" Content-Transfer-Encoding: 7bit diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/pci-dma.c linux/arch/mips/kernel/pci-dma.c --- linux.orig/arch/mips/kernel/pci-dma.c Mon Nov 26 20:14:37 2001 +++ linux/arch/mips/kernel/pci-dma.c Wed Jul 3 18:59:44 2002 @@ -30,7 +30,7 @@ memset(ret, 0, size); #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long) ret, size); - ret = KSEG1ADDR(ret); + ret = (void *)KSEG1ADDR(ret); #endif *dma_handle = virt_to_bus(ret); } diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/scall_o32.S linux/arch/mips/kernel/scall_o32.S --- linux.orig/arch/mips/kernel/scall_o32.S Wed Jul 3 11:19:27 2002 +++ linux/arch/mips/kernel/scall_o32.S Wed Jul 3 19:00:33 2002 @@ -17,6 +17,9 @@ #include #include +/* This duplicates the definition from */ +#define PT_TRACESYS 0x00000002 /* tracing system calls */ + /* Highest syscall used of any syscall flavour */ #define MAX_SYSCALL_NO __NR_Linux + __NR_Linux_syscalls diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c --- linux.orig/arch/mips/kernel/setup.c Mon Jul 1 11:46:55 2002 +++ linux/arch/mips/kernel/setup.c Wed Jul 3 19:01:22 2002 @@ -517,8 +517,6 @@ asmlinkage void __init init_arch(int argc, char **argv, char **envp, int *prom_vec) { - unsigned int s; - /* Determine which MIPS variant we are running on. */ cpu_probe(); @@ -866,7 +864,7 @@ max_low_pfn = MAXMEM_PFN; #ifndef CONFIG_HIGHMEM /* Maximum memory usable is what is directly addressable */ - printk(KERN_WARNING "Warning only %ldMB will be used.\n", + printk(KERN_WARNING "Warning only %dMB will be used.\n", MAXMEM>>20); printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n"); #endif diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c --- linux.orig/arch/mips/kernel/traps.c Wed Jul 3 11:19:27 2002 +++ linux/arch/mips/kernel/traps.c Wed Jul 3 19:02:19 2002 @@ -67,6 +67,8 @@ extern int fpu_emulator_cop1Handler(struct pt_regs *); +extern void dump_tlb_all(void); + char watch_available = 0; int (*be_board_handler)(struct pt_regs *regs, int is_fixup); @@ -705,8 +707,6 @@ asmlinkage void do_watch(struct pt_regs *regs) { - extern void dump_tlb_all(void); - /* * We use the watch exception where available to detect stack * overflows. diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/lib/dump_tlb.c linux/arch/mips/lib/dump_tlb.c --- linux.orig/arch/mips/lib/dump_tlb.c Mon Feb 25 20:25:17 2002 +++ linux/arch/mips/lib/dump_tlb.c Wed Jul 3 19:03:24 2002 @@ -32,6 +32,7 @@ case PM_256M: return "256Mb"; #endif } + return "unknown"; } void dump_tlb(int first, int last) @@ -153,8 +154,8 @@ addr = (unsigned int) address; printk("Addr == %08x\n", addr); - printk("task == %08p\n", t); - printk("task->mm == %08p\n", t->mm); + printk("task == %p\n", t); + printk("task->mm == %p\n", t->mm); //printk("tasks->mm.pgd == %08x\n", (unsigned int) t->mm->pgd); if (addr > KSEG0) @@ -179,7 +180,7 @@ #ifdef CONFIG_64BIT_PHYS_ADDR printk("page == %08Lx\n", (unsigned long long) pte_val(page)); #else - printk("page == %08lx\n", (unsigned int) pte_val(page)); + printk("page == %08x\n", (unsigned int) pte_val(page)); #endif val = pte_val(page); diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/fault.c linux/arch/mips/mm/fault.c --- linux.orig/arch/mips/mm/fault.c Thu Jun 27 14:14:14 2002 +++ linux/arch/mips/mm/fault.c Thu Jul 4 11:02:37 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/mm/init.c linux/arch/mips/mm/init.c --- linux.orig/arch/mips/mm/init.c Thu Jun 27 14:14:15 2002 +++ linux/arch/mips/mm/init.c Thu Jul 4 11:01:47 2002 @@ -161,6 +161,8 @@ extern char _ftext, _etext, _fdata, _edata; extern char __init_begin, __init_end; +#ifdef CONFIG_HIGHMEM + static void __init fixrange_init (unsigned long start, unsigned long end, pgd_t *pgd_base) { @@ -190,12 +192,17 @@ } } +#endif + void __init pagetable_init(void) { + pgd_t *pgd_base; +#ifdef CONFIG_HIGHMEM unsigned long vaddr; - pgd_t *pgd, *pgd_base; + pgd_t *pgd; pmd_t *pmd; pte_t *pte; +#endif /* Initialize the entire pgd. */ pgd_init((unsigned long)swapper_pg_dir); diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/tools/offset.c linux/arch/mips/tools/offset.c --- linux.orig/arch/mips/tools/offset.c Wed Jul 3 11:19:31 2002 +++ linux/arch/mips/tools/offset.c Thu Jul 4 11:11:06 2002 @@ -82,7 +82,6 @@ text("/* MIPS task_struct offsets. */"); offset("#define TASK_STATE ", struct task_struct, state); offset("#define TASK_FLAGS ", struct task_struct, flags); - constant(" #define PT_TRACESYS ", PT_TRACESYS); offset("#define TASK_SIGPENDING ", struct task_struct, sigpending); offset("#define TASK_NEED_RESCHED ", struct task_struct, need_resched); offset("#define TASK_PTRACE ", struct task_struct, ptrace); @@ -92,7 +91,6 @@ offset("#define TASK_PROCESSOR ", struct task_struct, processor); offset("#define TASK_PID ", struct task_struct, pid); size( "#define TASK_STRUCT_SIZE ", struct task_struct); - constant("#define PT_TRACESYS ", PT_TRACESYS); linefeed; } --Multipart_Thu__4_Jul_2002_15:26:20_+0900_08259f40-- From owner-linux-mips@oss.sgi.com Thu Jul 4 00:38:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g647cjRw010741 for ; Thu, 4 Jul 2002 00:38:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g647cjLS010740 for linux-mips-outgoing; Thu, 4 Jul 2002 00:38:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g647cbRw010715; Thu, 4 Jul 2002 00:38:37 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702210452.VXFA903.sccrmhc03.attbi.com@ocean.lucon.org>; Tue, 2 Jul 2002 21:04:52 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 767E8125D3; Tue, 2 Jul 2002 14:04:51 -0700 (PDT) Date: Tue, 2 Jul 2002 14:04:51 -0700 From: "H. J. Lu" To: Ralf Baechle Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020702140451.A18214@lucon.org> References: <20020702114045.A16197@lucon.org> <20020702220651.B9566@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702220651.B9566@dea.linux-mips.net>; from ralf@oss.sgi.com on Tue, Jul 02, 2002 at 10:06:51PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 02, 2002 at 10:06:51PM +0200, Ralf Baechle wrote: > On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote: > > > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > > glibc always use ll/sc. > > Which means the overhead of two syscalls instead of one sysmips() call > for something that is assumed to be dirt cheap. R3000, R5900 etc. > users won't this patch you, which'll have significant impact on their > glibc performance. > Not all ll/sc usages are implemented with sysmips. Does mips care about those? In case of libstdc++, should mips use ll/sc emulation? H.J. From owner-linux-mips@oss.sgi.com Thu Jul 4 00:55:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g647tqRw011460 for ; Thu, 4 Jul 2002 00:55:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g647tqVC011459 for linux-mips-outgoing; Thu, 4 Jul 2002 00:55:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g647tiRw011449; Thu, 4 Jul 2002 00:55:45 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA12529; Thu, 4 Jul 2002 10:00:14 +0200 (MET DST) Date: Thu, 4 Jul 2002 10:00:14 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H. J. Lu" cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips In-Reply-To: <20020702140451.A18214@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2 Jul 2002, H. J. Lu wrote: > > Which means the overhead of two syscalls instead of one sysmips() call > > for something that is assumed to be dirt cheap. R3000, R5900 etc. > > users won't this patch you, which'll have significant impact on their > > glibc performance. > > Not all ll/sc usages are implemented with sysmips. Does mips care about > those? In case of libstdc++, should mips use ll/sc emulation? Anything external to glibc should use _test_and_set() which is a published interface. -- + 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 Jul 4 01:43:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g648hkRw013673 for ; Thu, 4 Jul 2002 01:43:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g648hjws013672 for linux-mips-outgoing; Thu, 4 Jul 2002 01:43:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g648haRw013659; Thu, 4 Jul 2002 01:43:36 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.5/8.12.5) with ESMTP id g648lV8j029767; Thu, 4 Jul 2002 01:47:32 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA22799; Thu, 4 Jul 2002 01:47:28 -0700 (PDT) Message-ID: <00d401c22337$7e731580$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" , "H. J. Lu" Cc: , "GNU C Library" References: <20020702114045.A16197@lucon.org> <20020702220651.B9566@dea.linux-mips.net> Subject: Re: PATCH: Always use ll/sc for mips Date: Thu, 4 Jul 2002 10:47:41 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=1.3 required=5.0 tests=PORN_12,PORN_3,PORN_10 version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote: > > > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > > glibc always use ll/sc. > > Which means the overhead of two syscalls instead of one sysmips() call > for something that is assumed to be dirt cheap. R3000, R5900 etc. > users won't this patch you, which'll have significant impact on their > glibc performance. The R5900 kernel for the Playstation 2 does not use system calls. It uses a memory-mapped pseudo-device hack that the guys at Sony came up with, which is much faster. We at MIPS came up with an even faster hack which uses the destruction of a "k" register value, but which requires the branch-likely instruction and thus only workson MIPS II CPUs and above (R39xxx, R4xxx, R5xxx, but not the classic R3K). See my message "Re: patches for test-and-set without ll/sc" of January 22. I consider it to be very important for MIPS/Linux that the embedded/workstation kernel and libraries merge with the Playstation 2 "consumer" Linux, and I don't think that will happen if we try to push the PS2 people to use something far less efficient than what they already have. "Entia non sunt multiplicanda praeter necessitatem", as a wise old guy once said, but could we not consider a MIPS/Linux universe where R3000 binaries use system calls, non-LL/SC MIPSII+ binaries use k-register destruction, real, manly, MIPS binaries use LL/SC instructions, and where the MIPS/Linux kernel (a) supports an appropriate system call, (b) makes a contract with userland to destroy k-regs predictably, and (c) contains the emulation logic for LL/SC? That should give us full cross-platform binary compatibility, with optimal performance on each platform when an appropriately configured set of libraries and tools is installed. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Jul 4 02:12:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g649CERw014614 for ; Thu, 4 Jul 2002 02:12:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g649CEmj014613 for linux-mips-outgoing; Thu, 4 Jul 2002 02:12:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g649C7Rw014600 for ; Thu, 4 Jul 2002 02:12:08 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA13894; Thu, 4 Jul 2002 11:16:38 +0200 (MET DST) Date: Thu, 4 Jul 2002 11:16:38 +0200 (MET DST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: Small correction for fault.c In-Reply-To: <20020703104659.GX16753@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 3 Jul 2002, Thiemo Seufer wrote: > I use HEAD. The change from CVS Revision 1.61 to 1.62 was dropping > the tty.h include. Apparently a 2.5 cleanup. Well, the trunk is outdated -- it's 2.5.1, while the rest of the world uses 2.5.24. I'm using 2.4 for development, too, and I only syntactically port changes to the trunk. Adding a local declaration is the worst that can happen and it should not be used if at all possible (sometimes it's not, but the cases are rare). What if the interface changes? The correct fix is to include the appropriate header either in the header that depends on it or in the sources that include it. I prefer the former, but it may sometimes lead to circular dependencies because of a few Linux headers being too coarse. -- + 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 Jul 4 04:18:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64BI3Rw032505 for ; Thu, 4 Jul 2002 04:18:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64BI3lJ032504 for linux-mips-outgoing; Thu, 4 Jul 2002 04:18:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BHsRw032494; Thu, 4 Jul 2002 04:17:55 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g64BLoC09099; Thu, 4 Jul 2002 13:21:50 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g64BLmTF026734; Thu, 4 Jul 2002 13:21:49 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17Q4gG-0000Q1-00; Thu, 04 Jul 2002 13:21:48 +0200 Date: Thu, 4 Jul 2002 13:21:48 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: lib/Config.in missing in CVS HEAD ? Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-269209624-1025781708=:1601" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-269209624-1025781708=:1601 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, arch/mips64/config.in includes lib/Config.in which is missing. Please either put that file on CVS HEAD if it exists and is needed, or update arch/mips64/config.in with the following patch. Currently, 'make menuconfig ARCH=mips64' crashes because of this. thanks, Vivien Chappelier. --279724308-269209624-1025781708=:1601 Content-Type: TEXT/plain; name="linux-mips64-lib_Config.in_missing.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips64-lib_Config.in_missing.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9jb25maWcuaW4gbGludXgu cGF0Y2gvYXJjaC9taXBzNjQvY29uZmlnLmluDQotLS0gbGludXgvYXJjaC9t aXBzNjQvY29uZmlnLmluCU1vbiBKdWwgIDEgMjA6MjU6NTkgMjAwMg0KKysr IGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L2NvbmZpZy5pbglUaHUgSnVsICA0 IDEyOjAzOjA3IDIwMDINCkBAIC0zMTksNCArMzE5LDMgQEANCiBmaQ0KIGVu ZG1lbnUNCiANCi1zb3VyY2UgbGliL0NvbmZpZy5pbg0K --279724308-269209624-1025781708=:1601-- From owner-linux-mips@oss.sgi.com Thu Jul 4 04:24:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64BOgRw000869 for ; Thu, 4 Jul 2002 04:24:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64BOgCJ000868 for linux-mips-outgoing; Thu, 4 Jul 2002 04:24:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BOSRw000845; Thu, 4 Jul 2002 04:24:28 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g64BSNC09518; Thu, 4 Jul 2002 13:28:23 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g64BSJTF026918; Thu, 4 Jul 2002 13:28:19 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17Q4mZ-0000Qt-00; Thu, 04 Jul 2002 13:28:19 +0200 Date: Thu, 4 Jul 2002 13:28:19 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] CVS HEAD mips64 assembler options Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-2020090313-1025782099=:1601" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.2 required=5.0 tests=MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-2020090313-1025782099=:1601 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, There's been some rework on the Makefile for the mips64 target, however the line for the assembler options was forgotten, causing assembly source code to be wronly compiled, and crashing the linker afterwards. This patch fixes it, and also removes a few warnings about structures declared in parameter list. regards, Vivien Chappelier. --279724308-2020090313-1025782099=:1601 Content-Type: TEXT/plain; name="linux-mips64-build.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips64-build.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9NYWtlZmlsZSBsaW51eC5w YXRjaC9hcmNoL21pcHM2NC9NYWtlZmlsZQ0KLS0tIGxpbnV4L2FyY2gvbWlw czY0L01ha2VmaWxlCVRodSBKdWwgIDQgMTA6MTI6MjcgMjAwMg0KKysrIGxp bnV4LnBhdGNoL2FyY2gvbWlwczY0L01ha2VmaWxlCVRodSBKdWwgIDQgMTE6 MTc6NTQgMjAwMg0KQEAgLTcxLDEwICs3MSw2IEBADQogZW5kaWYNCiBlbmRp Zg0KIA0KLUFGTEFHUwkJKz0gJChHQ0NGTEFHUykNCi1DRkxBR1MJCSs9ICQo R0NDRkxBR1MpDQotDQotDQogIw0KICMgV2UgdW5jb25kaXRpb25hbGx5IGJ1 aWxkIHRoZSBtYXRoIGVtdWxhdG9yDQogIw0KQEAgLTE2Myw3ICsxNTksNyBA QA0KICMgY29udmVydCB0byBFQ09GRiB1c2luZyBlbGYyZWNvZmYuDQogIw0K IGlmZGVmIENPTkZJR19CT09UX0VMRjMyDQotQ0ZMQUdTICs9IC1XYSwtMzIN CitHQ0NGTEFHUyArPSAtV2EsLTMyDQogTElOS0ZMQUdTICs9IC1UIGFyY2gv bWlwczY0L2xkLnNjcmlwdC5lbGYzMg0KIGVuZGlmDQogIw0KQEAgLTE3MSw3 ICsxNjcsNyBAQA0KICMgRUxGIGZpbGVzIGZyb20gMzItYml0IGZpbGVzIGJ5 IGNvbnZlcnNpb24uDQogIw0KIGlmZGVmIENPTkZJR19CT09UX0VMRjY0DQot Q0ZMQUdTICs9IC1XYSwtMzINCitHQ0NGTEFHUyArPSAtV2EsLTMyDQogTElO S0ZMQUdTICs9IC1UIGFyY2gvbWlwczY0L2xkLnNjcmlwdC5lbGYzMg0KICNB UyArPSAtNjQNCiAjTEQgKz0gLW0gZWxmNjRibWlwDQpAQCAtMTkzLDYgKzE4 OSw5IEBADQogZWxzZQ0KIDY0Yml0LWJmZCA9IGVsZjY0LWJpZ21pcHMNCiBl bmRpZg0KKw0KK0FGTEFHUwkJKz0gJChHQ0NGTEFHUykNCitDRkxBR1MJCSs9 ICQoR0NDRkxBR1MpDQogDQogdm1saW51eDogYXJjaC9taXBzNjQvbGQuc2Ny aXB0LmVsZjMyDQogYXJjaC9taXBzNjQvbGQuc2NyaXB0LmVsZjMyOiBhcmNo L21pcHM2NC9sZC5zY3JpcHQuZWxmMzIuUw0KZGlmZiAtTmF1ciBsaW51eC9p bmNsdWRlL2FzbS1taXBzNjQvcHJvY2Vzc29yLmggbGludXgucGF0Y2gvaW5j bHVkZS9hc20tbWlwczY0L3Byb2Nlc3Nvci5oDQotLS0gbGludXgvaW5jbHVk ZS9hc20tbWlwczY0L3Byb2Nlc3Nvci5oCU1vbiBKdWwgIDEgMjA6MjY6NDEg MjAwMg0KKysrIGxpbnV4LnBhdGNoL2luY2x1ZGUvYXNtLW1pcHM2NC9wcm9j ZXNzb3IuaAlUaHUgSnVsICA0IDExOjE3OjI4IDIwMDINCkBAIC0xMyw2ICsx MywxMCBAQA0KIA0KICNpbmNsdWRlIDxsaW51eC9jb25maWcuaD4NCiANCisj aWZuZGVmIF9MQU5HVUFHRV9BU1NFTUJMWQ0KK3N0cnVjdCB0YXNrX3N0cnVj dDsNCisjZW5kaWYNCisNCiAvKg0KICAqIFJldHVybiBjdXJyZW50ICogaW5z dHJ1Y3Rpb24gcG9pbnRlciAoInByb2dyYW0gY291bnRlciIpLg0KICAqLw0K ZGlmZiAtTmF1ciAvc2hhcmUvbGludXgtMi41LmN2cy9pbmNsdWRlL2FzbS1t aXBzNjQvc3lzdGVtLmggbGludXgucGF0Y2gvaW5jbHVkZS9hc20tbWlwczY0 L3N5c3RlbS5oDQotLS0gbGludXgvaW5jbHVkZS9hc20tbWlwczY0L3N5c3Rl bS5oCVRodSBKdWwgIDQgMTA6MTI6NTYgMjAwMg0KKysrIGxpbnV4LnBhdGNo L2luY2x1ZGUvYXNtLW1pcHM2NC9zeXN0ZW0uaAlUaHUgSnVsICA0IDExOjE3 OjM4IDIwMDINCkBAIC0xNSw2ICsxNSw4IEBADQogI2luY2x1ZGUgPGFzbS9w dHJhY2UuaD4NCiAjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQogDQorc3Ry dWN0IHRhc2tfc3RydWN0Ow0KKw0KIF9fYXNtX18gKA0KIAkiLm1hY3JvXHRf X3N0aVxuXHQiDQogCSIuc2V0XHRwdXNoXG5cdCINCi0tLSBsaW51eC9pbmNs dWRlL2FzbS1taXBzNjQvdHJhcHMuaAlXZWQgSnVuIDI2IDE1OjAxOjIzIDIw MDINCisrKyBsaW51eC5wYXRjaC9pbmNsdWRlL2FzbS1taXBzNjQvdHJhcHMu aAlUaHUgSnVsICA0IDEyOjI2OjU4IDIwMDINCkBAIC0xMyw2ICsxMyw4IEBA DQogI2lmbmRlZiBfX0FTTV9NSVBTNjRfVFJBUFNfSA0KICNkZWZpbmUgX19B U01fTUlQUzY0X1RSQVBTX0gNCiANCitzdHJ1Y3QgcHRfcmVnczsNCisNCiAv Kg0KICAqIFBvc3NpYmxlIHN0YXR1cyByZXNwb25zZXMgZm9yIGEgYmVfYm9h cmRfaGFuZGxlciBiYWNrZW5kLg0KICAqLw0K --279724308-2020090313-1025782099=:1601-- From owner-linux-mips@oss.sgi.com Thu Jul 4 04:25:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64BPQRw000962 for ; Thu, 4 Jul 2002 04:25:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64BPQ00000961 for linux-mips-outgoing; Thu, 4 Jul 2002 04:25:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.28.123] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BPKRw000952 for ; Thu, 4 Jul 2002 04:25:21 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64BTGb26998; Thu, 4 Jul 2002 13:29:16 +0200 Date: Thu, 4 Jul 2002 13:29:16 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: lib/Config.in missing in CVS HEAD ? Message-ID: <20020704132916.A26943@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Thu, Jul 04, 2002 at 01:21:48PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 01:21:48PM +0200, Vivien Chappelier wrote: > arch/mips64/config.in includes lib/Config.in which is > missing. Please either put that file on CVS HEAD if it exists and is > needed, or update arch/mips64/config.in with the following patch. > Currently, 'make menuconfig ARCH=mips64' crashes because of this. Now you know that I'm not using menuconfig :-) Patch applied. Btw, do me a favor, send patches inline, not as attachment unless your mailer does funny things to them. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 04:28:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64BSqRw001061 for ; Thu, 4 Jul 2002 04:28:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64BSqvt001060 for linux-mips-outgoing; Thu, 4 Jul 2002 04:28:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.28.123] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BSlRw001051 for ; Thu, 4 Jul 2002 04:28:48 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64BWpp27047; Thu, 4 Jul 2002 13:32:51 +0200 Date: Thu, 4 Jul 2002 13:32:51 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] CVS HEAD mips64 assembler options Message-ID: <20020704133251.A27007@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Thu, Jul 04, 2002 at 01:28:19PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 01:28:19PM +0200, Vivien Chappelier wrote: > There's been some rework on the Makefile for the mips64 target, > however the line for the assembler options was forgotten, causing > assembly source code to be wronly compiled, and crashing the linker > afterwards. This patch fixes it, and also removes a few warnings about > structures declared in parameter list. I know those warnings and I simply take them as the proof that our header are too spaghettiish, so I'm not taking the easy way out ... Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 04:29:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64BTVRw002776 for ; Thu, 4 Jul 2002 04:29:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64BTVM7002775 for linux-mips-outgoing; Thu, 4 Jul 2002 04:29:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BTKRw002578; Thu, 4 Jul 2002 04:29:20 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g64BXFC10129; Thu, 4 Jul 2002 13:33:15 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g64BXFTF027116; Thu, 4 Jul 2002 13:33:15 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17Q4rL-0000RJ-00; Thu, 04 Jul 2002 13:33:15 +0200 Date: Thu, 4 Jul 2002 13:33:15 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] Re: [PATCH] r4k icache flushing for mips64 CVS HEAD In-Reply-To: <20020702004542.B32068@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-703588063-1025782395=:1601" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-703588063-1025782395=:1601 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 2 Jul 2002, Ralf Baechle wrote: > > This fixes icache flushing for the r4xx0 processor in the current > > (CVS HEAD) 2.5.1 tree. The flush_cache_all function does nothing there, > > that's why I moved it to flush_cache_l1. > > Not right, I checked in a variation of it ... Ok, but you forgot some things. The following patch adds the declaration of _flush_cache_all in loadmmu.c and pgtables.h I guess 3 patches is enough for today ;) More coming later ;) regards, Vivien. --279724308-703588063-1025782395=:1601 Content-Type: TEXT/plain; name="linux-mips64-r4k_flush_cache_all.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips64-r4k_flush_cache_all.diff" ZGlmZiAtTmF1ciBsaW51eC9pbmNsdWRlL2FzbS1taXBzNjQvcGd0YWJsZS5o IGxpbnV4LnBhdGNoL2luY2x1ZGUvYXNtLW1pcHM2NC9wZ3RhYmxlLmgNCi0t LSBsaW51eC9pbmNsdWRlL2FzbS1taXBzNjQvcGd0YWJsZS5oCVRodSBKdWwg IDQgMTA6MTI6NTYgMjAwMg0KKysrIGxpbnV4LnBhdGNoL2luY2x1ZGUvYXNt LW1pcHM2NC9wZ3RhYmxlLmgJVGh1IEp1bCAgNCAxMToxNzoyMyAyMDAyDQpA QCAtMjcsNiArMjcsNyBAQA0KICAqICAtIGZsdXNoX2NhY2hlX3JhbmdlKG1t LCBzdGFydCwgZW5kKSBmbHVzaGVzIGEgcmFuZ2Ugb2YgcGFnZXMNCiAgKiAg LSBmbHVzaF9wYWdlX3RvX3JhbShwYWdlKSB3cml0ZSBiYWNrIGtlcm5lbCBw YWdlIHRvIHJhbQ0KICAqLw0KK2V4dGVybiB2b2lkICgqX2ZsdXNoX2NhY2hl X2FsbCkodm9pZCk7DQogZXh0ZXJuIHZvaWQgKCpfZmx1c2hfY2FjaGVfbW0p KHN0cnVjdCBtbV9zdHJ1Y3QgKm1tKTsNCiBleHRlcm4gdm9pZCAoKl9mbHVz aF9jYWNoZV9yYW5nZSkoc3RydWN0IG1tX3N0cnVjdCAqbW0sIHVuc2lnbmVk IGxvbmcgc3RhcnQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdW5zaWduZWQgbG9uZyBlbmQpOw0KZGlmZiAtTmF1ciBsaW51eC9hcmNo L21pcHM2NC9tbS9sb2FkbW11LmMgbGludXgucGF0Y2gvYXJjaC9taXBzNjQv bW0vbG9hZG1tdS5jDQotLS0gbGludXgvYXJjaC9taXBzNjQvbW0vbG9hZG1t dS5jCVRodSBKdWwgIDQgMTA6MTI6MjggMjAwMg0KKysrIGxpbnV4LnBhdGNo L2FyY2gvbWlwczY0L21tL2xvYWRtbXUuYwlUaHUgSnVsICA0IDExOjMyOjQ1 IDIwMDINCkBAIC0yNCw2ICsyNCw3IEBADQogdm9pZCAoKl9jb3B5X3BhZ2Up KHZvaWQgKiB0bywgdm9pZCAqIGZyb20pOw0KIA0KIC8qIENhY2hlIG9wZXJh dGlvbnMuICovDQordm9pZCAoKl9mbHVzaF9jYWNoZV9hbGwpKHZvaWQpOw0K IHZvaWQgKCpfZmx1c2hfY2FjaGVfbW0pKHN0cnVjdCBtbV9zdHJ1Y3QgKm1t KTsNCiB2b2lkICgqX2ZsdXNoX2NhY2hlX3JhbmdlKShzdHJ1Y3QgbW1fc3Ry dWN0ICptbSwgdW5zaWduZWQgbG9uZyBzdGFydCwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGVuZCk7DQo= --279724308-703588063-1025782395=:1601-- From owner-linux-mips@oss.sgi.com Thu Jul 4 04:37:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64Bb0Rw002994 for ; Thu, 4 Jul 2002 04:37:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64Bb079002993 for linux-mips-outgoing; Thu, 4 Jul 2002 04:37:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.28.123] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64BasRw002984 for ; Thu, 4 Jul 2002 04:36:55 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64BewK27138; Thu, 4 Jul 2002 13:40:58 +0200 Date: Thu, 4 Jul 2002 13:40:58 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] Re: [PATCH] r4k icache flushing for mips64 CVS HEAD Message-ID: <20020704134058.A27135@dea.linux-mips.net> References: <20020702004542.B32068@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Thu, Jul 04, 2002 at 01:33:15PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 01:33:15PM +0200, Vivien Chappelier wrote: > > > This fixes icache flushing for the r4xx0 processor in the current > > > (CVS HEAD) 2.5.1 tree. The flush_cache_all function does nothing there, > > > that's why I moved it to flush_cache_l1. > > > > Not right, I checked in a variation of it ... > > Ok, but you forgot some things. The following patch adds the declaration > of _flush_cache_all in loadmmu.c and pgtables.h > > I guess 3 patches is enough for today ;) More coming later ;) Looks right, applied to 2.5 only. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 06:19:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64DJARw006807 for ; Thu, 4 Jul 2002 06:19:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64DJANP006806 for linux-mips-outgoing; Thu, 4 Jul 2002 06:19:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64DIuRw006795; Thu, 4 Jul 2002 06:18:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA18393; Thu, 4 Jul 2002 15:23:29 +0200 (MET DST) Date: Thu, 4 Jul 2002 15:23:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Vivien Chappelier , linux-mips@oss.sgi.com Subject: Re: [PATCH] CVS HEAD mips64 assembler options In-Reply-To: <20020704133251.A27007@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 4 Jul 2002, Ralf Baechle wrote: > > There's been some rework on the Makefile for the mips64 target, > > however the line for the assembler options was forgotten, causing > > assembly source code to be wronly compiled, and crashing the linker > > afterwards. This patch fixes it, and also removes a few warnings about > > structures declared in parameter list. > > I know those warnings and I simply take them as the proof that our > header are too spaghettiish, so I'm not taking the easy way out ... But the Makefile part is right -- I am responsible for the breakage, but since I use non-crippled tools, I haven't got a chance to verify this bit. I am checking in the fix, with minor spacing updates (and adjusting 2.4 for consistency). -- + 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 Jul 4 06:37:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64DbPRw007037 for ; Thu, 4 Jul 2002 06:37:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64DbPZO007036 for linux-mips-outgoing; Thu, 4 Jul 2002 06:37:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.28.100] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64DbIRw007027 for ; Thu, 4 Jul 2002 06:37:20 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64Df6j28229; Thu, 4 Jul 2002 15:41:06 +0200 Date: Thu, 4 Jul 2002 15:41:06 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Vivien Chappelier , linux-mips@oss.sgi.com Subject: Re: [PATCH] CVS HEAD mips64 assembler options Message-ID: <20020704154106.A28207@dea.linux-mips.net> References: <20020704133251.A27007@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jul 04, 2002 at 03:23:28PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 03:23:28PM +0200, Maciej W. Rozycki wrote: > > > There's been some rework on the Makefile for the mips64 target, > > > however the line for the assembler options was forgotten, causing > > > assembly source code to be wronly compiled, and crashing the linker > > > afterwards. This patch fixes it, and also removes a few warnings about > > > structures declared in parameter list. > > > > I know those warnings and I simply take them as the proof that our > > header are too spaghettiish, so I'm not taking the easy way out ... > > But the Makefile part is right -- I am responsible for the breakage, but > since I use non-crippled tools, I haven't got a chance to verify this bit. > I am checking in the fix, with minor spacing updates (and adjusting 2.4 > for consistency). Yep, just didn't yet get to sort it. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 06:53:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64DreRw007277 for ; Thu, 4 Jul 2002 06:53:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64DreTu007276 for linux-mips-outgoing; Thu, 4 Jul 2002 06:53:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.28.100] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64DrURw007267 for ; Thu, 4 Jul 2002 06:53:32 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64DvQc28363; Thu, 4 Jul 2002 15:57:26 +0200 Date: Thu, 4 Jul 2002 15:57:26 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "H. J. Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020704155726.A28268@dea.linux-mips.net> References: <20020702114045.A16197@lucon.org> <20020702220651.B9566@dea.linux-mips.net> <00d401c22337$7e731580$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00d401c22337$7e731580$10eca8c0@grendel>; from kevink@mips.com on Thu, Jul 04, 2002 at 10:47:41AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,PORN_12,PORN_3,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 10:47:41AM +0200, Kevin D. Kissell wrote: > The R5900 kernel for the Playstation 2 does not use system > calls. It uses a memory-mapped pseudo-device hack that > the guys at Sony came up with, which is much faster. We > at MIPS came up with an even faster hack which uses > the destruction of a "k" register value, but which requires > the branch-likely instruction and thus only workson > MIPS II CPUs and above (R39xxx, R4xxx, R5xxx, > but not the classic R3K). See my message > "Re: patches for test-and-set without ll/sc" of January 22. > > I consider it to be very important for MIPS/Linux > that the embedded/workstation kernel and libraries > merge with the Playstation 2 "consumer" Linux, and > I don't think that will happen if we try to push the > PS2 people to use something far less efficient than > what they already have. "Entia non sunt multiplicanda > praeter necessitatem", as a wise old guy once said, > but could we not consider a MIPS/Linux universe > where R3000 binaries use system calls, non-LL/SC > MIPSII+ binaries use k-register destruction, real, > manly, MIPS binaries use LL/SC instructions, and > where the MIPS/Linux kernel (a) supports an appropriate > system call, (b) makes a contract with userland to > destroy k-regs predictably, and (c) contains the > emulation logic for LL/SC? That should give us > full cross-platform binary compatibility, with optimal > performance on each platform when an appropriately > configured set of libraries and tools is installed. No, Sony's ABI isn't MP proof and will break silently on MP systems. As such I can't consider it anything else but a hack. sysmips(MIPS_ATOMIC_SET, ...) and ll/sc however are MP proof. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 07:10:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64EAPRw007484 for ; Thu, 4 Jul 2002 07:10:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64EAP8G007483 for linux-mips-outgoing; Thu, 4 Jul 2002 07:10:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64EAARw007472; Thu, 4 Jul 2002 07:10:13 -0700 Received: from mail7.sony.co.jp ([43.0.1.209]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g64EE8l39494; Thu, 4 Jul 2002 23:14:08 +0900 (JST) Received: from mail7.sony.co.jp (localhost [127.0.0.1]) by mail7.sony.co.jp (R8/Sony) with ESMTP id g64EE8704428; Thu, 4 Jul 2002 23:14:08 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail7.sony.co.jp (R8/Sony) with ESMTP id g64EE7V04424; Thu, 4 Jul 2002 23:14:07 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id XAA03937; Thu, 4 Jul 2002 23:13:16 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id XAA05243; Thu, 4 Jul 2002 23:14:06 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g64EE6S16036; Thu, 4 Jul 2002 23:14:06 +0900 (JST) Date: Thu, 04 Jul 2002 23:14:06 +0900 (JST) Message-Id: <20020704.231406.103018688.machida@sm.sony.co.jp> To: ralf@oss.sgi.com Cc: kevink@mips.com, hjl@lucon.org, linux-mips@oss.sgi.com, libc-alpha@sources.redhat.com Subject: Re: PATCH: Always use ll/sc for mips From: Hiroyuki Machida In-Reply-To: <20020704155726.A28268@dea.linux-mips.net> References: <20020702220651.B9566@dea.linux-mips.net> <00d401c22337$7e731580$10eca8c0@grendel> <20020704155726.A28268@dea.linux-mips.net> X-Mailer: Mew version 2.1.51 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: Ralf Baechle Subject: Re: PATCH: Always use ll/sc for mips Date: Thu, 4 Jul 2002 15:57:26 +0200 > No, Sony's ABI isn't MP proof and will break silently on MP systems. As > such I can't consider it anything else but a hack. sysmips(MIPS_ATOMIC_SET, > ...) and ll/sc however are MP proof. We can support MP with few modifications. On MP system, the pseudo-device will provide ll/sc if CPU support it. Otherwise, the pseudo-device will be failed to open. In this case, sysmips() will be used as last resort in libc. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Thu Jul 4 07:45:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64EjrRw007792 for ; Thu, 4 Jul 2002 07:45:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64EjrAk007791 for linux-mips-outgoing; Thu, 4 Jul 2002 07:45:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from snog.front.onramp.ca (snog.front.onramp.ca [198.163.180.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64EjkRw007782 for ; Thu, 4 Jul 2002 07:45:47 -0700 Received: (qmail 30045 invoked from network); 4 Jul 2002 14:49:49 -0000 Received: from gateway.hgeng.com (HELO shadowfax.hgeng.com) (199.246.74.82) by 0 with SMTP; 4 Jul 2002 14:49:49 -0000 Received: from dilbert.hgeng.com (dilbert.hgeng.com [192.168.1.6]) by shadowfax.hgeng.com (8.12.1/8.12.1/Debian -3) with ESMTP id g64EnmgO020933 for ; Thu, 4 Jul 2002 10:49:48 -0400 Subject: Re: X server blanking out virtual consoles? From: Michael Hill To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jul 2002 10:49:48 -0400 Message-Id: <1025794188.10696.205.camel@dilbert> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Guido, On Tue, 2002-06-11 at 03:55, Guido Guenther wrote: > On Tue, Jun 11, 2002 at 09:04:49AM +1000, vik wrote: > > > Just about everything is working on my indy with debian, but when I run > > X, everything on the virtual consoles disappear. I can see the cursor > > but that's all. The card is an 8 bit newport. > > Known issue that I really have to debug someday. Until then try the > patch by Dominik Behr at: > http://honk.physik.uni-konstanz.de/linux-mips/x/x.html#bugs Works brilliantly for me with one small side effect. Mike From owner-linux-mips@oss.sgi.com Thu Jul 4 08:22:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64FMbRw008246 for ; Thu, 4 Jul 2002 08:22:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64FMbCG008245 for linux-mips-outgoing; Thu, 4 Jul 2002 08:22:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64FMXRw008236 for ; Thu, 4 Jul 2002 08:22:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.5/8.12.5) with ESMTP id g64FQV8j003027 for ; Thu, 4 Jul 2002 08:26:31 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id IAA03876 for ; Thu, 4 Jul 2002 08:26:29 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g64FQTb00718 for ; Thu, 4 Jul 2002 17:26:29 +0200 (MEST) Message-ID: <3D246924.542682B2@mips.com> Date: Thu, 04 Jul 2002 17:26:28 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: LTP testing (shmat01) Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 (in include/asm-mips/shmparam.h). For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone know why we are different ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 4 10:31:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64HVGRw012331 for ; Thu, 4 Jul 2002 10:31:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64HVG00012330 for linux-mips-outgoing; Thu, 4 Jul 2002 10:31:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.30.48] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64HUoRw012321 for ; Thu, 4 Jul 2002 10:31:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64HYEq29590; Thu, 4 Jul 2002 19:34:14 +0200 Date: Thu, 4 Jul 2002 19:34:14 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) Message-ID: <20020704193414.A29570@dea.linux-mips.net> References: <3D246924.542682B2@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D246924.542682B2@mips.com>; from carstenl@mips.com on Thu, Jul 04, 2002 at 05:26:28PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 05:26:28PM +0200, Carsten Langgaard wrote: > The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 > (in include/asm-mips/shmparam.h). > For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone > know why we are different ? Sounds like a broken test. The value of SHMLBA is ABI mandated. Technically we could use any power of 2 >= 32kB easily and with plenty of headache any power of 2 > PAGE_SIZE. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 11:10:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64IAGRw012785 for ; Thu, 4 Jul 2002 11:10:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64IAGsc012784 for linux-mips-outgoing; Thu, 4 Jul 2002 11:10:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64IA9Rw012774; Thu, 4 Jul 2002 11:10:09 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.5/8.12.5) with ESMTP id g64IE68j004040; Thu, 4 Jul 2002 11:14:06 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA08616; Thu, 4 Jul 2002 11:14:05 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g64IE5b06807; Thu, 4 Jul 2002 20:14:05 +0200 (MEST) Message-ID: <3D249181.D9147AAE@mips.com> Date: Thu, 04 Jul 2002 20:18:41 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Jul 04, 2002 at 05:26:28PM +0200, Carsten Langgaard wrote: > > > The LTP test shmat01 fails on MIPS, because SHMLBA is defined to 0x40000 > > (in include/asm-mips/shmparam.h). > > For all other architectures SHMLBA is defined to PAGE_SIZE, does anyone > > know why we are different ? > > Sounds like a broken test. The value of SHMLBA is ABI mandated. Technically > we could use any power of 2 >= 32kB easily and with plenty of headache > any power of 2 > PAGE_SIZE. Ok, I see, but is there any reason for us to be different than the rest of the world ? > > Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 12:52:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g64JqNRw016631 for ; Thu, 4 Jul 2002 12:52:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g64JqNfo016630 for linux-mips-outgoing; Thu, 4 Jul 2002 12:52:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.30.48] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g64JqFRw016619 for ; Thu, 4 Jul 2002 12:52:17 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g64JuEo01591; Thu, 4 Jul 2002 21:56:14 +0200 Date: Thu, 4 Jul 2002 21:56:14 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) Message-ID: <20020704215614.B29422@dea.linux-mips.net> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D249181.D9147AAE@mips.com>; from carstenl@mips.com on Thu, Jul 04, 2002 at 08:18:41PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote: > > any power of 2 > PAGE_SIZE. > > Ok, I see, but is there any reason for us to be different than the > rest of the world ? Imho the your question already wrong :-) Any assumption about the constant's value in a piece of code is wrong. The reason why the constant's value was choosen are virtually indexed caches. The value allows attaching of shared memory segment without any cache flushes. Other architectures also use different values from PAGE_SIZE like IA64 1MB, SH 16kB and Sparc not even a constant value accross all architectures variants, so unlike what your posting implicates we're not that unusual. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 4 23:26:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g656QxRw000890 for ; Thu, 4 Jul 2002 23:26:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g656Qx4O000889 for linux-mips-outgoing; Thu, 4 Jul 2002 23:26:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g656QnRw000880; Thu, 4 Jul 2002 23:26:49 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.12.5/8.12.5) with ESMTP id g656Um8j008525; Thu, 4 Jul 2002 23:30:48 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA04088; Thu, 4 Jul 2002 23:30:48 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g656Umb20658; Fri, 5 Jul 2002 08:30:48 +0200 (MEST) Message-ID: <3D253D18.3BE59AED@mips.com> Date: Fri, 05 Jul 2002 08:30:48 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote: > > > > any power of 2 > PAGE_SIZE. > > > > Ok, I see, but is there any reason for us to be different than the > > rest of the world ? > > Imho the your question already wrong :-) Any assumption about the > constant's value in a piece of code is wrong. > > The reason why the constant's value was choosen are virtually indexed > caches. The value allows attaching of shared memory segment without > any cache flushes. > > Other architectures also use different values from PAGE_SIZE like IA64 1MB, > SH 16kB and Sparc not even a constant value accross all architectures > variants, so unlike what your posting implicates we're not that unusual. Using PAGE_SIZE is ok, even though it may differ from different architecture, because SHMLBA is defined as the following in /usr/include/sys/shm.h: #define SHMLBA (__getpagesize ()) So I would expect the user application and the kernel should have the same idea of what the size is. > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Fri Jul 5 07:34:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65EY5Rw021687 for ; Fri, 5 Jul 2002 07:34:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65EY5E3021686 for linux-mips-outgoing; Fri, 5 Jul 2002 07:34:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (dialinpool.tiscali.de [62.246.30.80] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65EXwRw021674 for ; Fri, 5 Jul 2002 07:34:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g65Ebs631979; Fri, 5 Jul 2002 16:37:54 +0200 Date: Fri, 5 Jul 2002 16:37:54 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) Message-ID: <20020705163754.C31881@dea.linux-mips.net> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D253D18.3BE59AED@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D253D18.3BE59AED@mips.com>; from carstenl@mips.com on Fri, Jul 05, 2002 at 08:30:48AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jul 05, 2002 at 08:30:48AM +0200, Carsten Langgaard wrote: > Using PAGE_SIZE is ok, even though it may differ from different architecture, > because SHMLBA is defined as the following in /usr/include/sys/shm.h: > #define SHMLBA (__getpagesize ()) > > So I would expect the user application and the kernel should have the same > idea of what the size is. Definately. I just checked it - this is an antique bug that was already present in glibc 2.0.6. I'm amazed people we got away with that one for so long ... Ralf From owner-linux-mips@oss.sgi.com Fri Jul 5 08:25:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65FP8Rw004445 for ; Fri, 5 Jul 2002 08:25:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65FP8b2004444 for linux-mips-outgoing; Fri, 5 Jul 2002 08:25:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65FOjRw004432 for ; Fri, 5 Jul 2002 08:24:45 -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 IAA06267 for ; Fri, 5 Jul 2002 08:29:14 -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 RAA12700; Fri, 5 Jul 2002 17:21:35 +0200 (MET DST) Date: Fri, 5 Jul 2002 17:21:34 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: Cache coherency fixes Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf, Following is a fix for the currently broken TLB cache coherency attributes setup. Of R4[04]00 processors only the MC versions support cache coherency. Looking at the current setup I infer SB1 is another CPU that supports it -- for any other CPU, the patch will have to be updated. Then it's only relevant for SMP setups. My R4400SC locks up solid (and I mean it, even NMI doesn't work) when a write back of a line marked as CACHABLE_COW is to happen. Somebody's laziness costed me a week of debugging, sigh... :-( OK to apply? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020705-cache-coherency-2 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020705.macro/arch/mips/config.in linux-mips-2.4.19-rc1-20020705/arch/mips/config.in --- linux-mips-2.4.19-rc1-20020705.macro/arch/mips/config.in 2002-06-27 02:57:13.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020705/arch/mips/config.in 2002-07-05 14:58:52.000000000 +0000 @@ -393,6 +393,19 @@ else fi fi fi + +if [ "$CONFIG_CPU_R4X00" = "y" -o "$CONFIG_CPU_SB1" = "y" ]; then + define_bool CONFIG_CPU_CACHE_COHERENCY $CONFIG_SMP +else + define_bool CONFIG_CPU_CACHE_COHERENCY n +fi + +if [ "$CONFIG_VTAG_ICACHE" != "y" ]; then + define_bool CONFIG_VTAG_ICACHE n +fi +if [ "$CONFIG_CPU_HAS_PREFETCH" != "y" ]; then + define_bool CONFIG_CPU_HAS_PREFETCH n +fi endmenu mainmenu_option next_comment diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020705.macro/arch/mips64/config.in linux-mips-2.4.19-rc1-20020705/arch/mips64/config.in --- linux-mips-2.4.19-rc1-20020705.macro/arch/mips64/config.in 2002-06-27 02:57:26.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020705/arch/mips64/config.in 2002-07-05 14:59:16.000000000 +0000 @@ -126,7 +126,6 @@ choice 'CPU type' \ R8000 CONFIG_CPU_R8000 \ R10000 CONFIG_CPU_R10000 \ SB1 CONFIG_CPU_SB1" R4x00 -endmenu if [ "$CONFIG_CPU_SB1" = "y" ]; then bool ' Workarounds for pass 1 sb1 bugs' CONFIG_SB1_PASS_1_WORKAROUNDS @@ -137,6 +136,20 @@ fi define_bool CONFIG_CPU_HAS_LLSC y define_bool CONFIG_CPU_HAS_LLDSCD y +if [ "$CONFIG_CPU_R4X00" = "y" -o "$CONFIG_CPU_SB1" = "y" ]; then + define_bool CONFIG_CPU_CACHE_COHERENCY $CONFIG_SMP +else + define_bool CONFIG_CPU_CACHE_COHERENCY n +fi + +if [ "$CONFIG_VTAG_ICACHE" != "y" ]; then + define_bool CONFIG_VTAG_ICACHE n +fi +if [ "$CONFIG_CPU_HAS_PREFETCH" != "y" ]; then + define_bool CONFIG_CPU_HAS_PREFETCH n +fi +endmenu + mainmenu_option next_comment comment 'General setup' diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020705.macro/include/asm-mips/pgtable-bits.h linux-mips-2.4.19-rc1-20020705/include/asm-mips/pgtable-bits.h --- linux-mips-2.4.19-rc1-20020705.macro/include/asm-mips/pgtable-bits.h 2002-04-15 07:50:23.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020705/include/asm-mips/pgtable-bits.h 2002-07-05 14:52:59.000000000 +0000 @@ -74,9 +74,9 @@ #define _CACHE_CACHABLE_WA (1<<9) /* R4600 only */ #define _CACHE_UNCACHED (2<<9) /* R4[0246]00 */ #define _CACHE_CACHABLE_NONCOHERENT (3<<9) /* R4[0246]00 */ -#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00 only */ -#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00 only */ -#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00 only */ +#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00MC only */ +#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00MC only */ +#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00MC only */ #define _CACHE_UNCACHED_ACCELERATED (7<<9) /* R10000 only */ #endif @@ -87,12 +87,20 @@ #define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_MODIFIED | _CACHE_MASK) -#ifdef CONFIG_MIPS_UNCACHED + +#if defined(CONFIG_MIPS_UNCACHED) + #define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED -#elif CONFIG_CPU_SB1 + +#elif defined(CONFIG_CPU_CACHE_COHERENCY) + #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW + #else + #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT + #endif + #endif /* _ASM_CACHINGMODES_H */ diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020705.macro/include/asm-mips64/pgtable.h linux-mips-2.4.19-rc1-20020705/include/asm-mips64/pgtable.h --- linux-mips-2.4.19-rc1-20020705.macro/include/asm-mips64/pgtable.h 2002-07-03 02:58:29.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020705/include/asm-mips64/pgtable.h 2002-07-05 14:52:59.000000000 +0000 @@ -191,9 +191,9 @@ extern void (*_flush_icache_page)(struct #define _CACHE_CACHABLE_WA (1<<9) /* R4600 only */ #define _CACHE_UNCACHED (2<<9) /* R4[0246]00 */ #define _CACHE_CACHABLE_NONCOHERENT (3<<9) /* R4[0246]00 */ -#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00 only */ -#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00 only */ -#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00 only */ +#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00MC only */ +#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00MC only */ +#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00MC only */ #define _CACHE_UNCACHED_ACCELERATED (7<<9) /* R10000 only */ #define _CACHE_MASK (7<<9) @@ -202,15 +202,21 @@ extern void (*_flush_icache_page)(struct #define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_MODIFIED | _CACHE_MASK) -#ifdef CONFIG_MIPS_UNCACHED -#define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED -#else /* ! UNCACHED */ -#ifdef CONFIG_SGI_IP22 -#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT -#else /* ! IP22 */ -#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW -#endif /* IP22 */ -#endif /* UNCACHED */ + +#if defined(CONFIG_MIPS_UNCACHED) + +#define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED + +#elif defined(CONFIG_CPU_CACHE_COHERENCY) + +#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW + +#else + +#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT + +#endif + #define PAGE_NONE __pgprot(_PAGE_PRESENT | PAGE_CACHABLE_DEFAULT) #define PAGE_SHARED __pgprot(_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \ From owner-linux-mips@oss.sgi.com Fri Jul 5 09:09:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65G97Rw007217 for ; Fri, 5 Jul 2002 09:09:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65G96o1007216 for linux-mips-outgoing; Fri, 5 Jul 2002 09:09:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nt_server.stellartec.com (mail.stellartec.com [65.107.16.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65G94Rw007206 for ; Fri, 5 Jul 2002 09:09:04 -0700 Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 568-43562U100L2S100) with SMTP id AAA161 for ; Fri, 5 Jul 2002 09:13:11 -0700 Reply-To: From: sseeger@stellartec.com (Steven Seeger) To: Subject: sys_execve problem Date: Fri, 5 Jul 2002 09:15:20 -0700 Message-ID: <01c501c2243f$2951c700$3501a8c0@wssseeger> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hey guys. I have compiled 2.4.19-ac1 from the CVS with the linux_2_4 tag for my NEC Osprey board (NEC VR4181) It boots fine and stuff, but doesn't load init. I've confirmed with simple print statements that do_execve is returning a 0 at the point in fs/exec.c where it says "/* execve success */" and yet init doesn't load. The system just sits there. I see on a scope that my timer interrupt is firing every 10 ms and the serial console responds properly. It echos characters and stops the echo when it receives a ctrl-S and resumes it on ctrl-Q. Obviously this is the last little part of the kernel to work though here. Any ideas? Steve From owner-linux-mips@oss.sgi.com Fri Jul 5 16:45:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65NjtRw014327 for ; Fri, 5 Jul 2002 16:45:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65Njtm4014326 for linux-mips-outgoing; Fri, 5 Jul 2002 16:45:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65NjnRw014316 for ; Fri, 5 Jul 2002 16:45:49 -0700 Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by deliverator.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 QAA05061 for ; Fri, 5 Jul 2002 16:49:50 -0700 (PDT) mail_from (brad@ltc.com) Received: from [192.168.0.76] (helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17QccH-0004ii-01; Fri, 05 Jul 2002 19:35:57 -0400 Message-ID: <006401c2247d$3356e580$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: Cc: References: <01c501c2243f$2951c700$3501a8c0@wssseeger> Subject: Re: sys_execve problem Date: Fri, 5 Jul 2002 19:39:24 -0400 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Is your init static? Does it need ld.so? Is ld.so executable (that's a tricky one). Regards, Brad ----- Original Message ----- From: "Steven Seeger" To: Sent: Friday, July 05, 2002 12:15 PM Subject: sys_execve problem > Hey guys. I have compiled 2.4.19-ac1 from the CVS with the linux_2_4 tag for > my NEC Osprey board (NEC VR4181) It boots fine and stuff, but doesn't load > init. I've confirmed with simple print statements that do_execve is > returning a 0 at the point in fs/exec.c where it says "/* execve success */" > and yet init doesn't load. The system just sits there. I see on a scope that > my timer interrupt is firing every 10 ms and the serial console responds > properly. It echos characters and stops the echo when it receives a ctrl-S > and resumes it on ctrl-Q. Obviously this is the last little part of the > kernel to work though here. Any ideas? > > Steve From owner-linux-mips@oss.sgi.com Fri Jul 5 16:51:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g65NpMRw014473 for ; Fri, 5 Jul 2002 16:51:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g65NpMFK014472 for linux-mips-outgoing; Fri, 5 Jul 2002 16:51:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nt_server.stellartec.com (mail.stellartec.com [65.107.16.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g65NpDRw014463 for ; Fri, 5 Jul 2002 16:51:13 -0700 Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 568-43562U100L2S100) with SMTP id AAA536; Fri, 5 Jul 2002 16:55:15 -0700 Reply-To: From: sseeger@stellartec.com (Steven Seeger) To: "'Bradley D. LaRonde'" Cc: Subject: RE: sys_execve problem Date: Fri, 5 Jul 2002 16:57:27 -0700 Message-ID: <01da01c2247f$b80c5e20$3501a8c0@wssseeger> 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) In-Reply-To: <006401c2247d$3356e580$4c00a8c0@prefect> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk By init do you mean the init_task_union? That's in the data segment and not static. ld.so is needed but it's also executable. It boots fine under other kernels. I either have this problem with 2.4.19 or the 2.4.18 problem where kfree doesn't free any memory and the system eventually runs out of memory because of the buffer caches. I'd love to get 2.4.19 booting because then I wouldn't have to mess with a problem with 2.4.16 from SF where the current->user gets set to 0 somewhere in kernel_thread and crashes in do_fork. I know the kfree works on 2.4.19 because the system doesn't freeze up when the rom block driver tries to call fsync_dev in rom_release like it does on the 2.4.18. (It freezes up in sync_inodes) I'm about to look for a new job here. :) Steve >-----Original Message----- >From: Bradley D. LaRonde [mailto:brad@ltc.com] >Sent: Friday, July 05, 2002 4:39 PM >To: sseeger@stellartec.com >Cc: linux-mips@oss.sgi.com >Subject: Re: sys_execve problem > > >Is your init static? Does it need ld.so? Is ld.so executable >(that's a >tricky one). > >Regards, >Brad > >----- Original Message ----- >From: "Steven Seeger" >To: >Sent: Friday, July 05, 2002 12:15 PM >Subject: sys_execve problem > > >> Hey guys. I have compiled 2.4.19-ac1 from the CVS with the >linux_2_4 tag >for >> my NEC Osprey board (NEC VR4181) It boots fine and stuff, >but doesn't load >> init. I've confirmed with simple print statements that do_execve is >> returning a 0 at the point in fs/exec.c where it says "/* >execve success >*/" >> and yet init doesn't load. The system just sits there. I see >on a scope >that >> my timer interrupt is firing every 10 ms and the serial >console responds >> properly. It echos characters and stops the echo when it >receives a ctrl-S >> and resumes it on ctrl-Q. Obviously this is the last little >part of the >> kernel to work though here. Any ideas? >> >> Steve > From owner-linux-mips@oss.sgi.com Fri Jul 5 19:28:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g662SRRw015402 for ; Fri, 5 Jul 2002 19:28:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g662SRXX015401 for linux-mips-outgoing; Fri, 5 Jul 2002 19:28:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g662S4Rw015392 for ; Fri, 5 Jul 2002 19:28:10 -0700 Received: from [192.168.0.76] (helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17QfJO-0004tY-00; Fri, 05 Jul 2002 22:28:38 -0400 Message-ID: <01bd01c22495$53e99820$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: Cc: References: <01da01c2247f$b80c5e20$3501a8c0@wssseeger> Subject: Re: sys_execve problem Date: Fri, 5 Jul 2002 22:32:08 -0400 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I meant "is /sbin/init statically linked?" What /sbin/init are you using? Have you tried a statically linked busybox init? Regards, Brad ----- Original Message ----- From: "Steven Seeger" To: "'Bradley D. LaRonde'" Cc: Sent: Friday, July 05, 2002 7:57 PM Subject: RE: sys_execve problem > By init do you mean the init_task_union? That's in the data segment and not > static. ld.so is needed but it's also executable. It boots fine under other > kernels. I either have this problem with 2.4.19 or the 2.4.18 problem where > kfree doesn't free any memory and the system eventually runs out of memory > because of the buffer caches. I'd love to get 2.4.19 booting because then I > wouldn't have to mess with a problem with 2.4.16 from SF where the > current->user gets set to 0 somewhere in kernel_thread and crashes in > do_fork. I know the kfree works on 2.4.19 because the system doesn't freeze > up when the rom block driver tries to call fsync_dev in rom_release like it > does on the 2.4.18. (It freezes up in sync_inodes) > > I'm about to look for a new job here. :) > > Steve > > >-----Original Message----- > >From: Bradley D. LaRonde [mailto:brad@ltc.com] > >Sent: Friday, July 05, 2002 4:39 PM > >To: sseeger@stellartec.com > >Cc: linux-mips@oss.sgi.com > >Subject: Re: sys_execve problem > > > > > >Is your init static? Does it need ld.so? Is ld.so executable > >(that's a > >tricky one). > > > >Regards, > >Brad > > > >----- Original Message ----- > >From: "Steven Seeger" > >To: > >Sent: Friday, July 05, 2002 12:15 PM > >Subject: sys_execve problem > > > > > >> Hey guys. I have compiled 2.4.19-ac1 from the CVS with the > >linux_2_4 tag > >for > >> my NEC Osprey board (NEC VR4181) It boots fine and stuff, > >but doesn't load > >> init. I've confirmed with simple print statements that do_execve is > >> returning a 0 at the point in fs/exec.c where it says "/* > >execve success > >*/" > >> and yet init doesn't load. The system just sits there. I see > >on a scope > >that > >> my timer interrupt is firing every 10 ms and the serial > >console responds > >> properly. It echos characters and stops the echo when it > >receives a ctrl-S > >> and resumes it on ctrl-Q. Obviously this is the last little > >part of the > >> kernel to work though here. Any ideas? > >> > >> Steve > > > > From owner-linux-mips@oss.sgi.com Sat Jul 6 14:35:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g66LZERw027804 for ; Sat, 6 Jul 2002 14:35:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g66LZEFa027803 for linux-mips-outgoing; Sat, 6 Jul 2002 14:35:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nt_server.stellartec.com (mail.stellartec.com [65.107.16.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g66LZ5Rw027794 for ; Sat, 6 Jul 2002 14:35:06 -0700 Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 568-43562U100L2S100) with SMTP id AAA573 for ; Sat, 6 Jul 2002 14:39:15 -0700 Reply-To: From: sseeger@stellartec.com (Steven Seeger) To: Subject: FW: [Linux-mips-kernel]my slab problem Date: Sat, 6 Jul 2002 14:41:31 -0700 Message-ID: <01fe01c22535$e4fc9c90$3501a8c0@wssseeger> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ok I've narrowed down my problem with the SF tree's 2.4.18 kernel and with the OSS 2.4.18 tree (tag linux_2_4, from about 3 weeks ago). I'm running on an NEC Osprey board. I've confirmed that XIP in ROM isn't causing this problem. I have a module that kmallocs almost all of the free memory in the system on insmod, and kfrees the memory on rmmod. Then, when I try to run a program that needs a lot of memory it page faults somewhere in the __wake_up function trying to wake up kswapd. kswapd actually does wake up and runs after the page fault, but doesn't find any slabs to reap. In my working kernel with all the slab debug stuff turned on, I'll see that slabs from the 131072 slab size (my kmallocs were 90000 bytes each) will get reaped as needed. This doesn't happen with the SF kernel. In fact, kmem_cache_reap gets to the comment that says /* couldn't find anything to reap */ I don't know if it isn't finding anything because of the page fault in __wake_up (which oddly enough doesn't crash the system..it just kills the process that was running, ie the memory hog) My working kernel is the 2.4.0-test9 kernel that Brad did a lot of work on. I really would like to get the later and greater kernel up and running. If anybody can offer some advice please let me know. I figure I'll figure this problem out before messing with the execve problem in the OSS 2.5.2 and 2.4.19 kernel since for all I know if I get those booting I'll run into this problem here. :) If anybody can point me in the right direction I'd appreciate it. Steve ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf _______________________________________________ Linux-mips-kernel mailing list Linux-mips-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-mips-kernel From owner-linux-mips@oss.sgi.com Sat Jul 6 15:03:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g66M3gRw028011 for ; Sat, 6 Jul 2002 15:03:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g66M3g6F028010 for linux-mips-outgoing; Sat, 6 Jul 2002 15:03:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nt_server.stellartec.com (mail.stellartec.com [65.107.16.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g66M3dRw028001 for ; Sat, 6 Jul 2002 15:03:39 -0700 Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 568-43562U100L2S100) with SMTP id AAA573; Sat, 6 Jul 2002 15:07:48 -0700 Reply-To: From: sseeger@stellartec.com (Steven Seeger) To: , Subject: more on my slab problem Date: Sat, 6 Jul 2002 15:10:04 -0700 Message-ID: <020001c22539$e23e4310$3501a8c0@wssseeger> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The page fault is happening in __wake_up_common() On the 3rd time through the list_for_each() block, a wait_queue_t *curr = list_entry(tmp, wait_queue_t, task_list); line returns a curr of 0xFFFFFFF8 and it page faults on the p = curr->task line because obviously that's a bad address. (page faults on 0xFFFFFFFC) I'm sorry to write to both lists but neither has a lot of activity and I'm hoping somebody on one of the lists could help. Steve From owner-linux-mips@oss.sgi.com Sat Jul 6 15:28:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g66MSVRw028208 for ; Sat, 6 Jul 2002 15:28:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g66MSV7H028207 for linux-mips-outgoing; Sat, 6 Jul 2002 15:28:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nt_server.stellartec.com (mail.stellartec.com [65.107.16.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g66MSSRw028198 for ; Sat, 6 Jul 2002 15:28:28 -0700 Received: from wssseeger ([192.168.1.53]) by nt_server.stellartec.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 568-43562U100L2S100) with SMTP id AAA448; Sat, 6 Jul 2002 15:32:38 -0700 Reply-To: From: sseeger@stellartec.com (Steven Seeger) To: , Subject: never mind Date: Sat, 6 Jul 2002 15:34:54 -0700 Message-ID: <020401c2253d$5a4cca90$3501a8c0@wssseeger> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Well I fixed it. Somehow kswapd_wait gets a bad entry in its task_list and it's always 0xffffffff8. So, putting a hack in __wake_up_common to look for that address and break out (since that always seems to be at the end of the list) fixed the problem. How odd. Of course I really should find out why that bad value gets in there, but I'm so lazy. Steve From owner-linux-mips@oss.sgi.com Sun Jul 7 02:34:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g679YqRw032148 for ; Sun, 7 Jul 2002 02:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g679YpuH032147 for linux-mips-outgoing; Sun, 7 Jul 2002 02:34:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g679YiRw032138 for ; Sun, 7 Jul 2002 02:34:45 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g679cmC16116; Sun, 7 Jul 2002 11:38:53 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g679ciTF019002; Sun, 7 Jul 2002 11:38:44 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17R8V9-0000Bk-00; Sun, 07 Jul 2002 11:38:43 +0200 Date: Sun, 7 Jul 2002 11:38:43 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Steven Seeger cc: linux-mips@oss.sgi.com Subject: Re: more on my slab problem In-Reply-To: <020001c22539$e23e4310$3501a8c0@wssseeger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 6 Jul 2002, Steven Seeger wrote: > The page fault is happening in __wake_up_common() On the 3rd time through > the list_for_each() block, a wait_queue_t *curr = list_entry(tmp, > wait_queue_t, task_list); line returns a curr of 0xFFFFFFF8 and it page > faults on the p = curr->task line because obviously that's a bad address. > (page faults on 0xFFFFFFFC) > > I'm sorry to write to both lists but neither has a lot of activity and I'm > hoping somebody on one of the lists could help. Hi, I've already encountered a similar problem before, binutils was producing bad data for the initialization of the waitq. This was with binutils 2.11.92.0.10. I worked around the problem by simply moving DECLARE_WAIT_QUEUE_HEAD(kswapd_wait); to the beginning of the mm/vmscan.c file, however, you should consider upgrading your toolchain if you're using the same version of binutils I used. references: http://www.spinics.net/lists/mips/msg09771.html http://www.spinics.net/lists/mips/msg09210.html regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Sun Jul 7 02:41:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g679f6Rw032276 for ; Sun, 7 Jul 2002 02:41:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g679f5Ls032275 for linux-mips-outgoing; Sun, 7 Jul 2002 02:41:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from matell.enst-bretagne.fr (matell.enst-bretagne.fr [192.108.115.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g679f2Rw032266 for ; Sun, 7 Jul 2002 02:41:03 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by matell.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g679iuc02467 for ; Sun, 7 Jul 2002 11:44:56 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g679iuTF019158 for ; Sun, 7 Jul 2002 11:44:56 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17R8bA-0000CU-00 for ; Sun, 07 Jul 2002 11:44:56 +0200 Date: Sun, 7 Jul 2002 11:44:56 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: linux-mips@oss.sgi.com Subject: Re: more on my slab problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > This was with binutils 2.11.92.0.10. Sorry, this was actually binutils 2.9.5 From owner-linux-mips@oss.sgi.com Sun Jul 7 07:34:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67EY7Rw030693 for ; Sun, 7 Jul 2002 07:34:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67EY7lm030692 for linux-mips-outgoing; Sun, 7 Jul 2002 07:34:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67EY3Rw030683 for ; Sun, 7 Jul 2002 07:34:03 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020707143814.CIZX8262.rwcrmhc52.attbi.com@ocean.lucon.org>; Sun, 7 Jul 2002 14:38:14 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id E92A3125D5; Sun, 7 Jul 2002 07:38:13 -0700 (PDT) Date: Sun, 7 Jul 2002 07:38:13 -0700 From: "H. J. Lu" To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: more on my slab problem Message-ID: <20020707073813.B23481@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Sun, Jul 07, 2002 at 11:44:56AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Jul 07, 2002 at 11:44:56AM +0200, Vivien Chappelier wrote: > > This was with binutils 2.11.92.0.10. > > Sorry, this was actually binutils 2.9.5 > That binutils is broken. The binutils in my RedHat/mips 7.1/7.3 should be ok. If not, I'd like to see a testcase. H.J. From owner-linux-mips@oss.sgi.com Sun Jul 7 11:10:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67IAwRw032189 for ; Sun, 7 Jul 2002 11:10:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67IAw4h032188 for linux-mips-outgoing; Sun, 7 Jul 2002 11:10:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67IAoRw032168; Sun, 7 Jul 2002 11:10:50 -0700 Received: from Muruga.localdomain (adsl-63-201-59-18.dsl.snfc21.pacbell.net [63.201.59.18]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g67IF6O295560; Sun, 7 Jul 2002 14:15:06 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g67I90i25902; Sun, 7 Jul 2002 11:09:00 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Sun, 7 Jul 2002 11:09:00 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: Ralf Baechle cc: Subject: Re: MIPS Atlas board In-Reply-To: <20020703235506.A21798@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 3 Jul 2002, Ralf Baechle wrote: > Anybody actually still using the MIPS Atlas board? If so, what kernel > versions? I've not had any feedback about the Atlas in many moons, so > I'm considering to drop support for it for 2.5. Comment? Oh no, I am using Atlas board with 2.4 kernel and I know few others also using it (guess they dont care anymore :( . If its not a time killer could you please add it to 2.5 also. BTW I was running network performance tools and the max I could read from Atlas board is ~0.3M. Is this a problem with the hardware? Thanks a lot, Muthu. > > Ralf > From owner-linux-mips@oss.sgi.com Sun Jul 7 12:15:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67JFSRw032648 for ; Sun, 7 Jul 2002 12:15:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67JFSn2032647 for linux-mips-outgoing; Sun, 7 Jul 2002 12:15:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (free197-x30.dialo.tiscali.de [62.246.30.197] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67JFLRw032638 for ; Sun, 7 Jul 2002 12:15:23 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g67JJU632345; Sun, 7 Jul 2002 21:19:30 +0200 Date: Sun, 7 Jul 2002 21:19:30 +0200 From: Ralf Baechle To: Muthukumar Ratty Cc: linux-mips@oss.sgi.com Subject: Re: MIPS Atlas board Message-ID: <20020707211930.A26692@dea.linux-mips.net> References: <20020703235506.A21798@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from muthu5@sbcglobal.net on Sun, Jul 07, 2002 at 11:09:00AM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Jul 07, 2002 at 11:09:00AM -0700, Muthukumar Ratty wrote: > > Anybody actually still using the MIPS Atlas board? If so, what kernel > > versions? I've not had any feedback about the Atlas in many moons, so > > I'm considering to drop support for it for 2.5. Comment? > > Oh no, I am using Atlas board with 2.4 kernel and I know few others also > using it (guess they dont care anymore :( . If its not a time killer > could you please add it to 2.5 also. Ok. Consider my posting simply a poll, nothing more. > BTW I was running network performance tools and the max I could read from > Atlas board is ~0.3M. Is this a problem with the hardware? Hard to say without any kind of closer analysis. The number certainly seems to be too low. What network benchmark did you run, what processor and clock rate does your Atlas have? Ralf From owner-linux-mips@oss.sgi.com Sun Jul 7 13:33:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67KXURw000784 for ; Sun, 7 Jul 2002 13:33:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67KXUJN000783 for linux-mips-outgoing; Sun, 7 Jul 2002 13:33:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67KXLRw000774 for ; Sun, 7 Jul 2002 13:33:22 -0700 Received: from excalibur.cologne.de (pD9E402E2.dip.t-dialin.net [217.228.2.226]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id WAA02961 for ; Sun, 7 Jul 2002 22:37:32 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17RIog-0003bw-00 for ; Sun, 07 Jul 2002 22:39:34 +0200 Date: Sun, 7 Jul 2002 22:39:34 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Linux-Kongress 2002: Call for Workshops Message-ID: <20020707223934.A13872@excalibur.cologne.de> 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.2.5i X-No-Archive: yes X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hallo everybody, I am forwarding this in case some of you are interested. The official deadline is tomorrow, but later applications may also be accepted. Regards, Karsten ----- Forwarded message ----- Linux-Kongress 2002 ------------------- Call for Workshops As in the last two years the German Unix User Group (GUUG) with the support of the German Ministry of Education and Research (BMBF) is planning to hold five 3-day workshops from Sunday, September 1, to Wednesday, September 4 just before the Linux-Kongress. The workshops will give Open Source developers from around the world the chance to meet in person and work on their projects. All Open Source projects are encouraged to apply for sponsorship. All expenses, including travel, accommodation and conference fees for the Linux-Kongress will be paid for participating projects. This is a unique chance for people who have been working together over the Internet but never seen each other to meet face-to-face and give their common project a push. Maybe you can use this workshop to finally get the 1.0 version done, or you need to come together to redesign your API, or maybe you just want to write some code non-stop for a few days. Workshops will take place at the "Kloster Walberberg", a former medieval castle and now a monastery and conference hotel set in a beautiful park. Everything, food, drinks, Internet connection will be provided for, so you can really concentrate on the job. Meeting rooms will be open 24h a day for your hacking pleasure. Please see the FAQ at http://www.linux-kongress.org/2002/workshops/faq.html for all the details and information about how to apply. Please make sure to apply soon as the planning time is quite short. If you have any questions don't hesitate to contact Jochen Topf at jochen.topf@guug.de. ----- End forwarded message ----- -- #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 Sun Jul 7 13:38:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g67KceRw000910 for ; Sun, 7 Jul 2002 13:38:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g67Kcdf8000909 for linux-mips-outgoing; Sun, 7 Jul 2002 13:38:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g67KcZRw000900 for ; Sun, 7 Jul 2002 13:38:36 -0700 Received: from Muruga.localdomain (adsl-63-201-59-18.dsl.snfc21.pacbell.net [63.201.59.18]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g67KgpO193098; Sun, 7 Jul 2002 16:42:51 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g67KaiY26329; Sun, 7 Jul 2002 13:36:44 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Sun, 7 Jul 2002 13:36:44 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: cc: Subject: Re: MIPS Atlas board In-Reply-To: <02a401c225f2$1ef39b30$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks kevin, I will use the PCI slot then. > > If you're using the on-board multi-I/O wonder chip > (serial, ethernet, etc) there are some serious problems > with it that limit both the serial line and ethernet > performance. It's good for downloading, and > that's about it. Most of us at MIPS put an AMD > PCnet card in the PCI slot to make the system > usable for NFS, FTP, etc. > > Regards, > > Kevin K. > From owner-linux-mips@oss.sgi.com Mon Jul 8 00:12:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g687CvRw007972 for ; Mon, 8 Jul 2002 00:12:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g687Cv4I007971 for linux-mips-outgoing; Mon, 8 Jul 2002 00:12:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g687CmRw007960; Mon, 8 Jul 2002 00:12:48 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA27616; Mon, 8 Jul 2002 00:16:58 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02435; Mon, 8 Jul 2002 00:16:59 -0700 (PDT) Received: from coplin09.mips.com (IDENT:root@coplin09 [192.168.205.79]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g687Gvb08858; Mon, 8 Jul 2002 09:16:57 +0200 (MEST) Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g687GvM10243; Mon, 8 Jul 2002 09:16:57 +0200 From: Hartvig Ekner Message-Id: <200207080716.g687GvM10243@coplin09.mips.com> Subject: Re: MIPS Atlas board To: ralf@oss.sgi.com (Ralf Baechle) Date: Mon, 8 Jul 2002 09:16:57 +0200 (CEST) Cc: muthu5@sbcglobal.net (Muthukumar Ratty), linux-mips@oss.sgi.com In-Reply-To: <20020707211930.A26692@dea.linux-mips.net> from "Ralf Baechle" at Jul 07, 2002 09:19:30 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle writes: > On Sun, Jul 07, 2002 at 11:09:00AM -0700, Muthukumar Ratty wrote: > > BTW I was running network performance tools and the max I could read from > > Atlas board is ~0.3M. Is this a problem with the hardware? > > Hard to say without any kind of closer analysis. The number certainly > seems to be too low. What network benchmark did you run, what processor > and clock rate does your Atlas have? There are known issues with the ethernet controller in the Philips 9730 device. For network-intensive applications, use a plug-in card. /Hartvig From owner-linux-mips@oss.sgi.com Mon Jul 8 00:14:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g687EURw008064 for ; Mon, 8 Jul 2002 00:14:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g687ETnP008063 for linux-mips-outgoing; Mon, 8 Jul 2002 00:14:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g687EMRw008049 for ; Mon, 8 Jul 2002 00:14:22 -0700 Received: from Muruga.localdomain (adsl-63-201-59-18.dsl.snfc21.pacbell.net [63.201.59.18]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g687IfO31896 for ; Mon, 8 Jul 2002 03:18:41 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g687CSU29969 for ; Mon, 8 Jul 2002 00:12:29 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Mon, 8 Jul 2002 00:12:28 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: Subject: Problem with sizeof? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, In my MIPS system sizeof(struct tc_stats) returns 40 but it returns 36 in i386 PC. tc_stats is defined in include/linux/pkt_sched.c as struct tc_stats { __u64 bytes; /* NUmber of enqueues bytes */ __u32 packets; /* Number of enqueued packets */ __u32 drops; /* Packets dropped because of lack of resources */ __u32 overlimits; /* Number of throttle events when this * flow goes out of allocated bandwidth*/ __u32 bps; /* Current flow byte rate */ __u32 pps; /* Current flow packet rate */ __u32 qlen; __u32 backlog; #ifdef __KERNEL__ spinlock_t *lock; #endif }; I printed the offsets of individual fields and they are same in i386 and MIPS. If the "spinlock_t" is defined then this may be the case but I am compiling an application, so it shouldnt be there? Right now I think the problem could be with the "sizeof" operator. Could someone please let me know if this is the case or I am doing something wrong. Also any solution. The versions are kernel : 2.4.3 gcc : gcc version 3.1 binutils : 2.11.93 glibc : 2.2.5 Thanks, Muthu. From owner-linux-mips@oss.sgi.com Mon Jul 8 01:08:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6888iRw008650 for ; Mon, 8 Jul 2002 01:08:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6888iPq008649 for linux-mips-outgoing; Mon, 8 Jul 2002 01:08:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6888YRw008638 for ; Mon, 8 Jul 2002 01:08:34 -0700 Received: from Muruga.localdomain (adsl-63-201-59-18.dsl.snfc21.pacbell.net [63.201.59.18]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g688CrK338932; Mon, 8 Jul 2002 04:12:53 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g6886eJ30957; Mon, 8 Jul 2002 01:06:40 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Mon, 8 Jul 2002 01:06:40 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: Venkatesh M R cc: Subject: Re: Problem with sizeof? In-Reply-To: <3D293FEF.40C04FD2@multitech.co.in> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I am not sure, but can this be memory allignment problem ? > you can check this by adding one more (dummy ) element of __u32 length (MIPS > should print 40 insted of 44 and pc shuld print 40 as expected ) You are right. when I add a __u32 dummy to the tc_stats then it still prints the size as 40. Is it get padded at the end? My main concern is, is this a normal behavior or do I need to upgrade my MIPS build environment? Thanks a lot, Muthu. > > if it works then you can get rid of the above problem by changing the > compilar settings. > > Regards, > venkatesh M R > > > > > Muthukumar Ratty wrote: > > > Hi, > > In my MIPS system sizeof(struct tc_stats) returns 40 but it returns 36 in > > i386 PC. > > > > tc_stats is defined in include/linux/pkt_sched.c as > > struct tc_stats > > { > > __u64 bytes; /* NUmber of enqueues bytes */ > > __u32 packets; /* Number of enqueued packets */ > > __u32 drops; /* Packets dropped because of lack > > of resources */ > > __u32 overlimits; /* Number of throttle events when > > this > > * flow goes out of allocated > > bandwidth*/ > > __u32 bps; /* Current flow byte rate */ > > __u32 pps; /* Current flow packet rate */ > > __u32 qlen; > > __u32 backlog; > > #ifdef __KERNEL__ > > spinlock_t *lock; > > #endif > > }; > > I printed the offsets of individual fields and they are same in i386 and > > MIPS. If the "spinlock_t" is defined then this may be the case but I > > am compiling an application, so it shouldnt be there? Right now I > > think the problem could be with the "sizeof" operator. > > Could someone please let me know if this is the case or I am doing > > something wrong. Also any solution. > > > > The versions are > > kernel : 2.4.3 > > gcc : gcc version 3.1 > > binutils : 2.11.93 > > glibc : 2.2.5 > > > > Thanks, > > Muthu. > From owner-linux-mips@oss.sgi.com Mon Jul 8 01:27:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g688RvRw008852 for ; Mon, 8 Jul 2002 01:27:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g688Rvku008851 for linux-mips-outgoing; Mon, 8 Jul 2002 01:27:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g688RiRw008842 for ; Mon, 8 Jul 2002 01:27:45 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA09141; Mon, 8 Jul 2002 10:31:45 +0200 (MET DST) Date: Mon, 8 Jul 2002 10:31:45 +0200 (MEST) From: Geert Uytterhoeven To: Muthukumar Ratty cc: Venkatesh M R , Linux/MIPS Development Subject: Re: Problem with sizeof? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 8 Jul 2002, Muthukumar Ratty wrote: > > I am not sure, but can this be memory allignment problem ? > > you can check this by adding one more (dummy ) element of __u32 length (MIPS > > should print 40 insted of 44 and pc shuld print 40 as expected ) > > You are right. when I add a __u32 dummy to the tc_stats then it still > prints the size as 40. Is it get padded at the end? My main concern is, > is this a normal behavior or do I need to upgrade my MIPS build > environment? The alignment rule for 64-bit value is 8 bytes on MIPS, and only 4 bytes on ia32. Since sizeof(struct ...) must return a value that's a multiple of the alignment rule for the largest element in the struct, it returns 40 on MIPS. > Thanks a lot, > Muthu. > > > > > if it works then you can get rid of the above problem by changing the > > compilar settings. > > > > Regards, > > venkatesh M R > > > > > > > > > > Muthukumar Ratty wrote: > > > > > Hi, > > > In my MIPS system sizeof(struct tc_stats) returns 40 but it returns 36 in > > > i386 PC. > > > > > > tc_stats is defined in include/linux/pkt_sched.c as > > > struct tc_stats > > > { > > > __u64 bytes; /* NUmber of enqueues bytes */ > > > __u32 packets; /* Number of enqueued packets */ > > > __u32 drops; /* Packets dropped because of lack > > > of resources */ > > > __u32 overlimits; /* Number of throttle events when > > > this > > > * flow goes out of allocated > > > bandwidth*/ > > > __u32 bps; /* Current flow byte rate */ > > > __u32 pps; /* Current flow packet rate */ > > > __u32 qlen; > > > __u32 backlog; > > > #ifdef __KERNEL__ > > > spinlock_t *lock; > > > #endif > > > }; > > > I printed the offsets of individual fields and they are same in i386 and > > > MIPS. If the "spinlock_t" is defined then this may be the case but I > > > am compiling an application, so it shouldnt be there? Right now I > > > think the problem could be with the "sizeof" operator. > > > Could someone please let me know if this is the case or I am doing > > > something wrong. Also any solution. 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 Jul 8 01:39:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g688d6Rw009037 for ; Mon, 8 Jul 2002 01:39:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g688d6rd009036 for linux-mips-outgoing; Mon, 8 Jul 2002 01:39:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g688csRw009025 for ; Mon, 8 Jul 2002 01:38:54 -0700 Received: from Muruga.localdomain (adsl-63-201-59-18.dsl.snfc21.pacbell.net [63.201.59.18]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g688h8A375678; Mon, 8 Jul 2002 04:43:08 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g688asC31134; Mon, 8 Jul 2002 01:36:54 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Mon, 8 Jul 2002 01:36:54 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: Geert Uytterhoeven cc: Muthukumar Ratty , Venkatesh M R , Linux/MIPS Development Subject: Re: Problem with sizeof? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Geert, The main reason I thought my environment could be broken is because I got the problem with iproute2 by Alexey!! Anyway I sent a mail to Alexey to check with him. Thanks, Muthu On Mon, 8 Jul 2002, Geert Uytterhoeven wrote: > On Mon, 8 Jul 2002, Muthukumar Ratty wrote: > > > I am not sure, but can this be memory allignment problem ? > > > you can check this by adding one more (dummy ) element of __u32 length (MIPS > > > should print 40 insted of 44 and pc shuld print 40 as expected ) > > > > You are right. when I add a __u32 dummy to the tc_stats then it still > > prints the size as 40. Is it get padded at the end? My main concern is, > > is this a normal behavior or do I need to upgrade my MIPS build > > environment? > > The alignment rule for 64-bit value is 8 bytes on MIPS, and only 4 bytes on > ia32. > > Since sizeof(struct ...) must return a value that's a multiple of the alignment > rule for the largest element in the struct, it returns 40 on MIPS. > > > Thanks a lot, > > Muthu. > > > > > > > > if it works then you can get rid of the above problem by changing the > > > compilar settings. > > > > > > Regards, > > > venkatesh M R > > > > > > > > > > > > > > > Muthukumar Ratty wrote: > > > > > > > Hi, > > > > In my MIPS system sizeof(struct tc_stats) returns 40 but it returns 36 in > > > > i386 PC. > > > > > > > > tc_stats is defined in include/linux/pkt_sched.c as > > > > struct tc_stats > > > > { > > > > __u64 bytes; /* NUmber of enqueues bytes */ > > > > __u32 packets; /* Number of enqueued packets */ > > > > __u32 drops; /* Packets dropped because of lack > > > > of resources */ > > > > __u32 overlimits; /* Number of throttle events when > > > > this > > > > * flow goes out of allocated > > > > bandwidth*/ > > > > __u32 bps; /* Current flow byte rate */ > > > > __u32 pps; /* Current flow packet rate */ > > > > __u32 qlen; > > > > __u32 backlog; > > > > #ifdef __KERNEL__ > > > > spinlock_t *lock; > > > > #endif > > > > }; > > > > I printed the offsets of individual fields and they are same in i386 and > > > > MIPS. If the "spinlock_t" is defined then this may be the case but I > > > > am compiling an application, so it shouldnt be there? Right now I > > > > think the problem could be with the "sizeof" operator. > > > > Could someone please let me know if this is the case or I am doing > > > > something wrong. Also any solution. > > 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 Jul 8 10:23:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68HN6Rw027847 for ; Mon, 8 Jul 2002 10:23:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68HN631027846 for linux-mips-outgoing; Mon, 8 Jul 2002 10:23:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68HN0Rw027837 for ; Mon, 8 Jul 2002 10:23:01 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA06996; Mon, 8 Jul 2002 19:27:45 +0200 (MET DST) Date: Mon, 8 Jul 2002 19:27:45 +0200 (MET DST) From: "Maciej W. Rozycki" To: Steven Seeger cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: never mind In-Reply-To: <020401c2253d$5a4cca90$3501a8c0@wssseeger> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 6 Jul 2002, Steven Seeger wrote: > Well I fixed it. Somehow kswapd_wait gets a bad entry in its task_list and > it's always 0xffffffff8. So, putting a hack in __wake_up_common to look for > that address and break out (since that always seems to be at the end of the > list) fixed the problem. How odd. Of course I really should find out why > that bad value gets in there, but I'm so lazy. And the bug will remain uncovered, waiting for another victim forever... -- + 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 Jul 8 10:24:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68HOxRw027948 for ; Mon, 8 Jul 2002 10:24:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68HOxYA027947 for linux-mips-outgoing; Mon, 8 Jul 2002 10:24:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68HOnRw027926; Mon, 8 Jul 2002 10:24:49 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA12281; Mon, 8 Jul 2002 10:29:05 -0700 Message-ID: <3D29CA34.1050306@mvista.com> Date: Mon, 08 Jul 2002 10:21:56 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralf Baechle CC: "Kevin D. Kissell" , "H. J. Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips References: <20020702114045.A16197@lucon.org> <20020702220651.B9566@dea.linux-mips.net> <00d401c22337$7e731580$10eca8c0@grendel> <20020704155726.A28268@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=PORN_12,PORN_3,PORN_10 version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Jul 04, 2002 at 10:47:41AM +0200, Kevin D. Kissell wrote: > > >>The R5900 kernel for the Playstation 2 does not use system >>calls. It uses a memory-mapped pseudo-device hack that >>the guys at Sony came up with, which is much faster. We >>at MIPS came up with an even faster hack which uses >>the destruction of a "k" register value, but which requires >>the branch-likely instruction and thus only workson >>MIPS II CPUs and above (R39xxx, R4xxx, R5xxx, >>but not the classic R3K). See my message >>"Re: patches for test-and-set without ll/sc" of January 22. >> >>I consider it to be very important for MIPS/Linux >>that the embedded/workstation kernel and libraries >>merge with the Playstation 2 "consumer" Linux, and >>I don't think that will happen if we try to push the >>PS2 people to use something far less efficient than >>what they already have. "Entia non sunt multiplicanda >>praeter necessitatem", as a wise old guy once said, >>but could we not consider a MIPS/Linux universe >>where R3000 binaries use system calls, non-LL/SC >>MIPSII+ binaries use k-register destruction, real, >>manly, MIPS binaries use LL/SC instructions, and >>where the MIPS/Linux kernel (a) supports an appropriate >>system call, (b) makes a contract with userland to >>destroy k-regs predictably, and (c) contains the >>emulation logic for LL/SC? That should give us >>full cross-platform binary compatibility, with optimal >>performance on each platform when an appropriately >>configured set of libraries and tools is installed. >> > > No, Sony's ABI isn't MP proof and will break silently on MP systems. As > such I can't consider it anything else but a hack. sysmips(MIPS_ATOMIC_SET, > ...) and ll/sc however are MP proof. > sysmips(MIPS_ATOMIC_SET, ...) as it is is not MP-safe. Two processors can set the variable at the same time since no spinlock is used to protect the access. This is also a problem when I was writing preemptiable kernel patch. Jun From owner-linux-mips@oss.sgi.com Mon Jul 8 10:30:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68HUjRw028067 for ; Mon, 8 Jul 2002 10:30:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68HUj9s028066 for linux-mips-outgoing; Mon, 8 Jul 2002 10:30:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (free168-x28.dialo.tiscali.de [62.246.28.168] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68HUcRw028057 for ; Mon, 8 Jul 2002 10:30:39 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g68HYdU02797; Mon, 8 Jul 2002 19:34:39 +0200 Date: Mon, 8 Jul 2002 19:34:38 +0200 From: Ralf Baechle To: Jun Sun Cc: "Kevin D. Kissell" , "H. J. Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020708193438.A2758@dea.linux-mips.net> References: <20020702114045.A16197@lucon.org> <20020702220651.B9566@dea.linux-mips.net> <00d401c22337$7e731580$10eca8c0@grendel> <20020704155726.A28268@dea.linux-mips.net> <3D29CA34.1050306@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D29CA34.1050306@mvista.com>; from jsun@mvista.com on Mon, Jul 08, 2002 at 10:21:56AM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 08, 2002 at 10:21:56AM -0700, Jun Sun wrote: > > No, Sony's ABI isn't MP proof and will break silently on MP systems. As > > such I can't consider it anything else but a hack. sysmips(MIPS_ATOMIC_SET, > > ...) and ll/sc however are MP proof. > > > > > sysmips(MIPS_ATOMIC_SET, ...) as it is is not MP-safe. Two processors can > set the variable at the same time since no spinlock is used to protect the > access. Note there are two cases in the code, one using ll/sc which is MP proof and a second implementation for machines that don't have these instructions. At least for now Linux/MIPS SMP systems by definition have ll/sc, so I don't see any problem. > This is also a problem when I was writing preemptiable kernel patch. Thanks for the reminder. I'm just working on the merge with 2.5.4 which has all the preemption stuff. Another one for the to-do list ... Ralf From owner-linux-mips@oss.sgi.com Mon Jul 8 10:34:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68HYLRw028170 for ; Mon, 8 Jul 2002 10:34:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68HYLud028169 for linux-mips-outgoing; Mon, 8 Jul 2002 10:34:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68HYFRw028160; Mon, 8 Jul 2002 10:34:15 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA12684; Mon, 8 Jul 2002 10:38:31 -0700 Message-ID: <3D29CC6B.5090004@mvista.com> Date: Mon, 08 Jul 2002 10:31:23 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralf Baechle CC: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Jul 04, 2002 at 08:18:41PM +0200, Carsten Langgaard wrote: > > >>>any power of 2 > PAGE_SIZE. >>> >>Ok, I see, but is there any reason for us to be different than the >>rest of the world ? >> > > Imho the your question already wrong :-) Any assumption about the > constant's value in a piece of code is wrong. > > The reason why the constant's value was choosen are virtually indexed > caches. The value allows attaching of shared memory segment without > any cache flushes. > I think this is also an effective way to avoid cache aliasing. As long as your cache size is less than 256K, you don't get cache aliasing through shared memory. Perhaps other arches don't have cache aliasing? I know for sure i386 does not have that effect. Jun From owner-linux-mips@oss.sgi.com Mon Jul 8 10:41:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68HfYRw029695 for ; Mon, 8 Jul 2002 10:41:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68HfYk9029694 for linux-mips-outgoing; Mon, 8 Jul 2002 10:41:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (free168-x28.dialo.tiscali.de [62.246.28.168] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68HfRRw029684 for ; Mon, 8 Jul 2002 10:41:29 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g68Hjd902907; Mon, 8 Jul 2002 19:45:39 +0200 Date: Mon, 8 Jul 2002 19:45:39 +0200 From: Ralf Baechle To: Jun Sun Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) Message-ID: <20020708194539.C2758@dea.linux-mips.net> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D29CC6B.5090004@mvista.com>; from jsun@mvista.com on Mon, Jul 08, 2002 at 10:31:23AM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 08, 2002 at 10:31:23AM -0700, Jun Sun wrote: > I think this is also an effective way to avoid cache aliasing. Correct. At the same time the choice of this value also tends to cause bad use of L2 caches ... > As long as your cache size is less than 256K, you don't get cache aliasing > through shared memory. Actually the "alias set" has to be less than 256kB. On existing MIPS implementations it's at most 16kB; a sillyness of the R4000 / R4400 VCE exceptions makes a value of 32kB mandatory for poerformance reasons. > Perhaps other arches don't have cache aliasing? I know for sure i386 > does not have that effect. The problem doesn't exist on physically indexed caches. Also on read-only caches such as the instruction cache it usually can be ignored. So for example the R2000, R3000, SB1 cores, RM7000, R4kc and R5kc in the right configurations and the R10000 family don't suffer from aliases. Details are messy :) Ralf From owner-linux-mips@oss.sgi.com Mon Jul 8 11:05:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68I53Rw000515 for ; Mon, 8 Jul 2002 11:05:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68I53MC000514 for linux-mips-outgoing; Mon, 8 Jul 2002 11:05:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68I4tRw000494; Mon, 8 Jul 2002 11:04:55 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id LAA29611; Mon, 8 Jul 2002 11:09:07 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA24314; Mon, 8 Jul 2002 11:09:07 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g68I97b06690; Mon, 8 Jul 2002 20:09:07 +0200 (MEST) Message-ID: <3D29D65C.84630789@mips.com> Date: Mon, 08 Jul 2002 20:13:48 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Jun Sun , linux-mips@oss.sgi.com Subject: Re: LTP testing (shmat01) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have no preferences of the value of SHMLBA, as long as the define in /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync. /Carsten Ralf Baechle wrote: > On Mon, Jul 08, 2002 at 10:31:23AM -0700, Jun Sun wrote: > > > I think this is also an effective way to avoid cache aliasing. > > Correct. At the same time the choice of this value also tends to cause > bad use of L2 caches ... > > > As long as your cache size is less than 256K, you don't get cache aliasing > > through shared memory. > > Actually the "alias set" has to be less than 256kB. On existing MIPS > implementations it's at most 16kB; a sillyness of the R4000 / R4400 VCE > exceptions makes a value of 32kB mandatory for poerformance reasons. > > > Perhaps other arches don't have cache aliasing? I know for sure i386 > > does not have that effect. > > The problem doesn't exist on physically indexed caches. Also on read-only > caches such as the instruction cache it usually can be ignored. So for > example the R2000, R3000, SB1 cores, RM7000, R4kc and R5kc in the right > configurations and the R10000 family don't suffer from aliases. Details > are messy :) > > Ralf From owner-linux-mips@oss.sgi.com Mon Jul 8 11:25:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68IPARw000733 for ; Mon, 8 Jul 2002 11:25:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68IPAD1000732 for linux-mips-outgoing; Mon, 8 Jul 2002 11:25:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68IOoRw000720; Mon, 8 Jul 2002 11:24:51 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020708182906.TMTA6023.sccrmhc02.attbi.com@ocean.lucon.org>; Mon, 8 Jul 2002 18:29:06 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id E7A86125D6; Mon, 8 Jul 2002 11:29:03 -0700 (PDT) Date: Mon, 8 Jul 2002 11:29:03 -0700 From: "H. J. Lu" To: Carsten Langgaard Cc: Ralf Baechle , Jun Sun , linux-mips@oss.sgi.com, GNU C Library Subject: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01)) Message-ID: <20020708112903.A14451@lucon.org> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> <3D29D65C.84630789@mips.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D29D65C.84630789@mips.com>; from carstenl@mips.com on Mon, Jul 08, 2002 at 08:13:48PM +0200 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote: > I have no preferences of the value of SHMLBA, as long as the define in > /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync. > > /Carsten > How about this patch? H.J. --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glibc-mips-shm.patch" 2002-07-08 H.J. Lu * sysdeps/unix/sysv/linux/mips/sys/shm.h: New. --- sysdeps/unix/sysv/linux/mips/sys/shm.h.mips Mon Jul 8 11:27:12 2002 +++ sysdeps/unix/sysv/linux/mips/sys/shm.h Mon Jul 8 11:27:06 2002 @@ -0,0 +1,67 @@ +/* Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#ifndef _SYS_SHM_H +#define _SYS_SHM_H 1 + +#include + +#define __need_size_t +#include + +/* Get common definition of System V style IPC. */ +#include + +/* Get system dependent definition of `struct shmid_ds' and more. */ +#include + +/* Define types required by the standard. */ +#define __need_time_t +#include + +#ifdef __USE_XOPEN +# ifndef __pid_t_defined +typedef __pid_t pid_t; +# define __pid_t_defined +# endif +#endif /* X/Open */ + +__BEGIN_DECLS + +/* Segment low boundary address multiple. */ +#define SHMLBA 0x40000 + +/* The following System V style IPC functions implement a shared memory + facility. The definition is found in XPG4.2. */ + +/* Shared memory control operation. */ +extern int shmctl (int __shmid, int __cmd, struct shmid_ds *__buf) __THROW; + +/* Get shared memory segment. */ +extern int shmget (key_t __key, size_t __size, int __shmflg) __THROW; + +/* Attach shared memory segment. */ +extern void *shmat (int __shmid, __const void *__shmaddr, int __shmflg) + __THROW; + +/* Detach shared memory segment. */ +extern int shmdt (__const void *__shmaddr) __THROW; + +__END_DECLS + +#endif /* sys/shm.h */ --82I3+IH0IqGh5yIs-- From owner-linux-mips@oss.sgi.com Mon Jul 8 11:29:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g68ITeRw000850 for ; Mon, 8 Jul 2002 11:29:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g68ITe9x000849 for linux-mips-outgoing; Mon, 8 Jul 2002 11:29:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (free168-x28.dialo.tiscali.de [62.246.28.168] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g68ITZRw000839 for ; Mon, 8 Jul 2002 11:29:37 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g68IXg003451; Mon, 8 Jul 2002 20:33:42 +0200 Date: Mon, 8 Jul 2002 20:33:42 +0200 From: Ralf Baechle To: "H. J. Lu" Cc: Carsten Langgaard , Jun Sun , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01)) Message-ID: <20020708203342.A3223@dea.linux-mips.net> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> <3D29D65C.84630789@mips.com> <20020708112903.A14451@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020708112903.A14451@lucon.org>; from hjl@lucon.org on Mon, Jul 08, 2002 at 11:29:03AM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 08, 2002 at 11:29:03AM -0700, H. J. Lu wrote: > How about this patch? Yes, please apply. Ralf From owner-linux-mips@oss.sgi.com Mon Jul 8 23:07:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69677Rw026311 for ; Mon, 8 Jul 2002 23:07:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69677a7026310 for linux-mips-outgoing; Mon, 8 Jul 2002 23:07:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6966rRw026276; Mon, 8 Jul 2002 23:06:53 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g696B4Xb002128; Mon, 8 Jul 2002 23:11:04 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA20879; Mon, 8 Jul 2002 23:11:05 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g696B5b19705; Tue, 9 Jul 2002 08:11:05 +0200 (MEST) Message-ID: <3D2A7E79.605DA06@mips.com> Date: Tue, 09 Jul 2002 08:11:05 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" CC: Ralf Baechle , Jun Sun , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01)) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> <3D29D65C.84630789@mips.com> <20020708112903.A14451@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Looks fine to me. Thanks /Carsten "H. J. Lu" wrote: > On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote: > > I have no preferences of the value of SHMLBA, as long as the define in > > /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync. > > > > /Carsten > > > > How about this patch? > > H.J. > > ------------------------------------------------------------------------ > > glibc-mips-shm.patchName: glibc-mips-shm.patch > Type: Plain Text (text/plain) -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jul 8 23:30:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g696UJRw028014 for ; Mon, 8 Jul 2002 23:30:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g696UJXI028013 for linux-mips-outgoing; Mon, 8 Jul 2002 23:30:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g696UARw028004; Mon, 8 Jul 2002 23:30:10 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E34B1142D0; Tue, 9 Jul 2002 08:34:28 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: "H. J. Lu" Cc: Carsten Langgaard , Ralf Baechle , Jun Sun , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01)) References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> <3D29D65C.84630789@mips.com> <20020708112903.A14451@lucon.org> From: Andreas Jaeger Date: Tue, 09 Jul 2002 08:34:27 +0200 In-Reply-To: <20020708112903.A14451@lucon.org> ("H. J. Lu"'s message of "Mon, 8 Jul 2002 11:29:03 -0700") Message-ID: Lines: 9 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk thanks, committed to both mainline and glibc 2.2, 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 Jul 9 13:38:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69KckRw031827 for ; Tue, 9 Jul 2002 13:38:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69KckqD031826 for linux-mips-outgoing; Tue, 9 Jul 2002 13:38:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KcYRw031807; Tue, 9 Jul 2002 13:38:35 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g69KgpC06213; Tue, 9 Jul 2002 22:42:51 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g69KgqTF009221; Tue, 9 Jul 2002 22:42:52 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17S1ox-00064f-00; Tue, 09 Jul 2002 22:42:51 +0200 Date: Tue, 9 Jul 2002 22:42:51 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] O2 berr file fix Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-458953353-1026247371=:23345" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.8 required=5.0 tests=MIME_NULL_BLOCK,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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. --279724308-458953353-1026247371=:23345 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This fixes a basic error: copy/pasting stuff from ip27 to ip32 :) Please apply, Vivien. --- linux/arch/mips64/sgi-ip32/ip32-berr.c Wed Jun 26 15:01:23 2002 +++ linux.patch/arch/mips64/sgi-ip32/ip32-berr.c Thu Jul 4 12:27:21 2002 @@ -32,5 +32,5 @@ void __init bus_error_init(void) { - be_board_handler = be_ip27_handler; + be_board_handler = be_ip32_handler; } --279724308-458953353-1026247371=:23345 Content-Type: TEXT/plain; name="linux-O2-berr.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-berr.diff" LS0tIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzItYmVyci5jCVdl ZCBKdW4gMjYgMTU6MDE6MjMgMjAwMg0KKysrIGxpbnV4LnBhdGNoL2FyY2gv bWlwczY0L3NnaS1pcDMyL2lwMzItYmVyci5jCVRodSBKdWwgIDQgMTI6Mjc6 MjEgMjAwMg0KQEAgLTMyLDUgKzMyLDUgQEANCiB2b2lkIF9faW5pdA0KIGJ1 c19lcnJvcl9pbml0KHZvaWQpDQogew0KLQliZV9ib2FyZF9oYW5kbGVyID0g YmVfaXAyN19oYW5kbGVyOw0KKwliZV9ib2FyZF9oYW5kbGVyID0gYmVfaXAz Ml9oYW5kbGVyOw0KIH0NCg== --279724308-458953353-1026247371=:23345-- From owner-linux-mips@oss.sgi.com Tue Jul 9 13:50:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69KokRw032350 for ; Tue, 9 Jul 2002 13:50:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69Kok5l032349 for linux-mips-outgoing; Tue, 9 Jul 2002 13:50:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69KoZRw032336; Tue, 9 Jul 2002 13:50:35 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g69KssC06793; Tue, 9 Jul 2002 22:54:54 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g69KstTF009646; Tue, 9 Jul 2002 22:54:55 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17S20d-00065i-00; Tue, 09 Jul 2002 22:54:55 +0200 Date: Tue, 9 Jul 2002 22:54:55 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] setup reboot handlers for ip27 and ip32 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, This is a patch setup the reboot handlers for the ip27 and ip32 machines. Please apply, Vivien. diff -Naur linux/arch/mips64/sgi-ip27/ip27-setup.c linux.patch/arch/mips64/sgi-ip27/ip27-setup.c --- linux/arch/mips64/sgi-ip27/ip27-setup.c Wed Jan 2 22:56:41 2002 +++ linux.patch/arch/mips64/sgi-ip27/ip27-setup.c Wed Jan 2 23:14:19 2002 @@ -276,6 +276,7 @@ extern void ip27_setup_console(void); extern void ip27_time_init(void); +extern void ip27_reboot_setup(void); void __init ip27_setup(void) { @@ -283,6 +284,7 @@ hubreg_t p, e; ip27_setup_console(); + ip27_reboot_setup(); num_bridges = 0; /* diff -Naur linux/arch/mips64/sgi-ip32/ip32-setup.c linux.patch/arch/mips64/sgi-ip32/ip32-setup.c --- linux/arch/mips64/sgi-ip32/ip32-setup.c Wed Jan 2 22:56:41 2002 +++ linux.patch/arch/mips64/sgi-ip32/ip32-setup.c Wed Jan 2 23:14:21 2002 @@ -58,6 +58,7 @@ #endif extern void ip32_time_init(void); +extern void ip32_reboot_setup(void); void __init bus_error_init(void) { @@ -92,6 +93,7 @@ #ifdef CONFIG_VT conswitchp = &dummy_con; #endif + ip32_reboot_setup(); rtc_ops = &ip32_rtc_ops; board_time_init = ip32_time_init; From owner-linux-mips@oss.sgi.com Tue Jul 9 15:20:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69MKtRw003478 for ; Tue, 9 Jul 2002 15:20:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69MKtRL003477 for linux-mips-outgoing; Tue, 9 Jul 2002 15:20:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69MKjRw003467; Tue, 9 Jul 2002 15:20:45 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g69MP4C11971; Wed, 10 Jul 2002 00:25:04 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g69MP5TF013051; Wed, 10 Jul 2002 00:25:05 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17S3Pt-0000B9-00; Wed, 10 Jul 2002 00:25:05 +0200 Date: Wed, 10 Jul 2002 00:25:05 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [PATCH] 2.5.4 fixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Here is a fix to have mips64 compile on the new 2.5.4 CVS HEAD kernel. Just a few missing headers. Vivien. diff -Naur linux/arch/mips64/kernel/entry.S linux.patch/arch/mips64/kernel/entry.S --- linux/arch/mips64/kernel/entry.S Tue Jul 9 22:02:18 2002 +++ linux.patch/arch/mips64/kernel/entry.S Tue Jul 9 23:44:24 2002 @@ -13,6 +13,7 @@ #include #include #include +#include #define KU_USER 0x10 diff -Naur linux/arch/mips64/kernel/scall_64.S linux.patch/arch/mips64/kernel/scall_64.S --- linux/arch/mips64/kernel/scall_64.S Tue Jul 9 22:02:19 2002 +++ linux.patch/arch/mips64/kernel/scall_64.S Tue Jul 9 23:49:53 2002 @@ -15,6 +15,7 @@ #include #include #include +#include #ifndef CONFIG_MIPS32_COMPAT #define handle_sys64 handle_sys diff -Naur linux/include/asm-mips64/pgalloc.h linux.patch/include/asm-mips64/pgalloc.h --- linux/include/asm-mips64/pgalloc.h Mon Jul 8 22:28:12 2002 +++ linux.patch/include/asm-mips64/pgalloc.h Tue Jul 9 23:22:04 2002 @@ -9,6 +9,7 @@ #ifndef _ASM_PGALLOC_H #define _ASM_PGALLOC_H +#include #include /* TLB flushing: From owner-linux-mips@oss.sgi.com Tue Jul 9 16:52:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g69NqXRw005925 for ; Tue, 9 Jul 2002 16:52:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g69NqWRP005924 for linux-mips-outgoing; Tue, 9 Jul 2002 16:52:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (penta89-d28.dialo.tiscali.de [62.246.28.89] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g69NqQRw005915 for ; Tue, 9 Jul 2002 16:52:28 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g69NuSK19796; Wed, 10 Jul 2002 01:56:28 +0200 Date: Wed, 10 Jul 2002 01:56:28 +0200 From: Ralf Baechle To: p2@mind.be, geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be, linux-mips@oss.sgi.com Subject: Re: [PATCH] DDB5074 support Message-ID: <20020710015628.A19778@dea.linux-mips.net> References: <20020709133630.GB9075@mind.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020709133630.GB9075@mind.be>; from p2@mind.be on Tue, Jul 09, 2002 at 03:36:30PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 09, 2002 at 03:36:30PM +0200, Peter De Schrijver wrote: > The attached patch adds support for the NEC DDB-5074 board. Something went wrong with this patch, looks like you were manually editing it or so. When trying to apply it I get: patch: **** malformed patch at line 1501: diff -r -N -u -w oss-2.4/linux/include/asm-mips/ddb5xxx/ddb5074.h oss-2.4-ddb5074/linux/include/asm-mips/ddb5xxx/ddb5074.h Can you re-diff? Ralf From owner-linux-mips@oss.sgi.com Tue Jul 9 23:51:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6A6pYRw023403 for ; Tue, 9 Jul 2002 23:51:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6A6pY89023402 for linux-mips-outgoing; Tue, 9 Jul 2002 23:51:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from myware.mynet (cpe-24-221-190-179.ca.sprintbbd.net [24.221.190.179]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6A6pNRw023393; Tue, 9 Jul 2002 23:51:24 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by myware.mynet (8.12.3/8.12.3) with ESMTP id g6A6v1rv025965; Tue, 9 Jul 2002 23:57:01 -0700 Subject: Re: PATCH: Fix SHMLBA for mips (Re: LTP testing (shmat01)) From: Ulrich Drepper To: "H. J. Lu" Cc: Carsten Langgaard , Ralf Baechle , Jun Sun , linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20020708112903.A14451@lucon.org> References: <3D246924.542682B2@mips.com> <20020704193414.A29570@dea.linux-mips.net> <3D249181.D9147AAE@mips.com> <20020704215614.B29422@dea.linux-mips.net> <3D29CC6B.5090004@mvista.com> <20020708194539.C2758@dea.linux-mips.net> <3D29D65C.84630789@mips.com> <20020708112903.A14451@lucon.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SgIusYTMPIy4UteC3JRA" X-Mailer: Ximian Evolution 1.0.7 (1.0.7-2) Date: 09 Jul 2002 23:57:01 -0700 Message-Id: <1026284222.25809.67.camel@myware.mynet> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-SgIusYTMPIy4UteC3JRA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-07-08 at 11:29, H. J. Lu wrote: > On Mon, Jul 08, 2002 at 08:13:48PM +0200, Carsten Langgaard wrote: > > I have no preferences of the value of SHMLBA, as long as the define in > > /usr/include/sys/shm.c and include/asm-mips/shmparam.h are in sync. > >=20 > > /Carsten > >=20 >=20 > How about this patch? No. As Roland said, define SHMLBA in the mips bits/shm.h file and change sys/shm.h to define SHMLBA only if it wasn't defined before. --=20 ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ --=-SgIusYTMPIy4UteC3JRA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9K9q92ijCOnn/RHQRAgmoAKCWfZLBu34YhIokKeNzIL0nWyjcUwCZAcUj gJk9ISBKbh7L2xBI0elTTD0= =lYhQ -----END PGP SIGNATURE----- --=-SgIusYTMPIy4UteC3JRA-- From owner-linux-mips@oss.sgi.com Wed Jul 10 07:12:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6AECiRw031638 for ; Wed, 10 Jul 2002 07:12:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6AECiBn031637 for linux-mips-outgoing; Wed, 10 Jul 2002 07:12:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6AEC7Rw031626 for ; Wed, 10 Jul 2002 07:12:08 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6AEIJE17140 for ; Wed, 10 Jul 2002 15:18:19 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6AEH8R01023 for ; Wed, 10 Jul 2002 15:17:08 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF2.004ECC0B ; Wed, 10 Jul 2002 15:20:40 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: linux-mips@oss.sgi.com Message-ID: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> Date: Wed, 10 Jul 2002 15:16:21 +0100 Subject: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Symptom: ==== The linux mips 2.4.17 kernel compiled with gcc-2.96-110 (from H.J.Lu) hangs before reaching the 'Calibrating delay loop'. When the same kernel is compiled with gcc-3.0.4 or egcs-1.1.2 it works OK. I have included what I think is the cause, some patches to test the theory and some possible fixes. Cause: ==== I tracked the problem back to the CP0_STATUS being corrupted by the mips32_flush_cache_all_pc routine, leading to a lockup once interrupts are enabled. Looking at a disassembly of the code suggests the broken code changes the value of the AT register while the working code leaves it alone. The compiler is allowed to do this, but it exposes the real problem which appears to be a problem between the 'cache' instruction of blast_icache() and the 'mfc0' of the __restore_flags(). The 'mfc0 at, $12' seems to be ignored. This isn't a problem with the gcc-3.0.4 code since AT still contains the value of CP0_STATUS from the __save_and_cli at the start of the routine. This may be caused by the cache routines running from the a cached kseg0, it looks like it can be fixed by making sure that the are always called via KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the setup_cache_funcs code. I have included a patch below which starts this, but I haven't caught all combinations of how the routines are called. Alternatively it could be a CP0 pipeline interaction of the cache instruction and mfc0 but I can't find anything detailed about it. I thought this was the problem initially and have included a patch below which adds an extra nop. I believe the root of the problem is that the routines are running in kseg0, but If anyone has any other ideas as to what could causing the problem then i'd be glad to know. You can test this by inserting some extra code to change AT between the save & restore and see if it causes a problem (see included patches below) Current source: static inline void mips32_flush_cache_all_pc(void) { unsigned long flags; __save_and_cli(flags); blast_dcache(); blast_icache(); __restore_flags(flags); } Disassembly of mips32_flush_cache_all_pc() for broken code gcc-2.96: 00000c30 : c30: 40066000 mfc0 a2,$12 c34: 00000000 nop c38: 34c10001 ori at,a2,0x1 c3c: 38210001 xori at,at,0x1 c40: 40816000 mtc0 at,$12 c44: 00000040 ssnop c48: 00000040 ssnop c4c: 00000040 ssnop c50: 3c030000 lui v1,0x0 c54: 8c630000 lw v1,0(v1) c58: 3c048000 lui a0,0x8000 c5c: 3c018000 lui at,0x8000 *** See here how the compiler has changed AT here c60: 00231821 addu v1,at,v1 c64: 0083102b sltu v0,a0,v1 c68: 10400008 beqz v0,c8c c6c: 00000000 nop c70: 3c050000 lui a1,0x0 c74: 8ca50000 lw a1,0(a1) c78: bc810000 cache 0x1,0(a0) c7c: 00852021 addu a0,a0,a1 c80: 0083102b sltu v0,a0,v1 c84: 1440fffc bnez v0,c78 c88: 00000000 nop c8c: 3c030000 lui v1,0x0 c90: 8c630000 lw v1,0(v1) c94: 3c048000 lui a0,0x8000 c98: 3c018000 lui at,0x8000 c9c: 00231821 addu v1,at,v1 ca0: 0083102b sltu v0,a0,v1 ca4: 10400008 beqz v0,cc8 ca8: 00000000 nop cac: 3c050000 lui a1,0x0 cb0: 8ca50000 lw a1,0(a1) cb4: bc800000 cache 0x0,0(a0) cb8: 00852021 addu a0,a0,a1 cbc: 0083102b sltu v0,a0,v1 cc0: 1440fffc bnez v0,cb4 cc4: 00000000 nop cc8: 40016000 mfc0 at,$12 *** The instruction above is the one which seems to be skipped. ccc: 30c60001 andi a2,a2,0x1 cd0: 34210001 ori at,at,0x1 cd4: 38210001 xori at,at,0x1 cd8: 00c13025 or a2,a2,at cdc: 40866000 mtc0 a2,$12 ... cec: 03e00008 jr ra cf0: 00000000 nop Patches to demonstrate the problem: ==== Here is a patch to change AT in the cache_flush routine to show that this corrupts the CP0_STATUS value (for a mips32 processor with no secondary cache). When this is applied in conjunction with the patch above you should see the CP0_STATUS being corrupted and the kernel will probably hang. I have demonstrated that this change is enough to break a working kernel/compiler combination. --- linux/arch/mips/mm/c-mips32.c-orig Wed Jul 10 14:12:09 2002 +++ linux/arch/mips/mm/c-mips32.c Wed Jul 10 14:18:17 2002 @@ -74,7 +74,9 @@ unsigned long flags; __save_and_cli(flags); - blast_dcache(); blast_icache(); + blast_dcache(); + __asm__("lui\t$at, 0x8000\n\t"); + blast_icache(); __restore_flags(flags); } Here is the patch that I used to catch the problem when CP0_STATUS is being corrupted by the cache flush routine. The CP0_STATUS should not be changed by the call to the cache flush routine. --- linux/arch/mips/kernel/traps.c Thu May 23 15:19:35 2002 +++ ../traps.c Wed Jul 10 13:46:54 2002 @@ -889,7 +889,10 @@ memcpy((void *)(KSEG0 + 0x80), &except_vec1_generic, 0x80); memcpy((void *)(KSEG0 + 0x100), &except_vec2_generic, 0x80); memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); + + printk("CP0_STATUS before flush = 0x%x\n", read_32bit_cp0_register(CP0_STATUS)); flush_icache_range(KSEG0 + 0x80, KSEG0 + 0x200); + printk("CP0_STATUS after flush = 0x%x\n", read_32bit_cp0_register(CP0_STATUS)); /* * Setup default vectors */ Fix (to call cache routines via uncached Kseg1) ==== Assuming the root of the problem is that the cache flush routines are running from cached kseg0. This patch needs a bit more work to make sure that all the other routines are called similarly. --- linux/arch/mips/mm/c-mips32.c-orig Wed Jul 10 14:12:09 2002 +++ linux/arch/mips/mm/c-mips32.c Wed Jul 10 14:45:03 2002 @@ -606,8 +608,13 @@ { _clear_page = (void *)mips32_clear_page_dc; _copy_page = (void *)mips32_copy_page_dc; +#if 1 + _flush_cache_all = (void (*)(u32,u32)) KSEG1ADDR((unsigned long)mips32_flush_cache_all_pc); + ___flush_cache_all = (void (*)(u32,u32)) KSEG1ADDR((unsigned long)mips32_flush_cache_all_pc); +#else _flush_cache_all = mips32_flush_cache_all_pc; ___flush_cache_all = mips32_flush_cache_all_pc; +#endif _flush_cache_mm = mips32_flush_cache_mm_pc; _flush_cache_range = mips32_flush_cache_range_pc; _flush_cache_page = mips32_flush_cache_page_pc; Fix (If the root of the problem is a pipeline hazard) ==== The patch below fix is to insert an extra 'nop' at the end of the various blast_[id]cache routines to clear the hazard condition before the code returns. The 'sc' routines may need a similar fix. A different workaround places a 'nop' at the start of the __restore_flags routine, but I believe it is better to fix the problem at the source of the hazard. --- linux/include/asm-mips/mips32_cache.h Wed Apr 10 22:53:12 2002 +++ ../mips32_cache.h Wed Jul 10 13:10:40 2002 @@ -189,73 +189,85 @@ static inline void blast_dcache(void) { unsigned long start = KSEG0; unsigned long end = (start + dcache_size); while(start < end) { cache_unroll(start,Index_Writeback_Inv_D); start += dc_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_dcache_page(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Hit_Writeback_Inv_D); start += dc_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_dcache_page_indexed(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Index_Writeback_Inv_D); start += dc_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_icache(void) { unsigned long start = KSEG0; unsigned long end = (start + icache_size); while(start < end) { cache_unroll(start,Index_Invalidate_I); start += ic_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_icache_page(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Hit_Invalidate_I); start += ic_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_icache_page_indexed(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Index_Invalidate_I); start += ic_lsize; } + /* Prevent hazard with following mfc0 */ + __asm__("nop\n\t"); } static inline void blast_scache(void) { unsigned long start = KSEG0; unsigned long end = KSEG0 + scache_size; while(start < end) { cache_unroll(start,Index_Writeback_Inv_SD); Jon Burgess From owner-linux-mips@oss.sgi.com Wed Jul 10 14:57:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ALvMRw021376 for ; Wed, 10 Jul 2002 14:57:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ALvM0Z021375 for linux-mips-outgoing; Wed, 10 Jul 2002 14:57:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ALt2Rw021316; Wed, 10 Jul 2002 14:55:02 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA16471; Wed, 10 Jul 2002 14:59:28 -0700 Message-ID: <3D2CAC86.9070809@mvista.com> Date: Wed, 10 Jul 2002 14:52:06 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com, Ralf Baechle Subject: [2.4 PATCH] DDB5xxx update and rockhopper II support Content-Type: multipart/mixed; boundary="------------080905060902040806040503" X-Spam-Status: No, hits=-4.9 required=5.0 tests=PORN_10,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------080905060902040806040503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ralf, This patch is an update for DDB5xxx boards. It adds support to the latest rockhopper II baseboard. A couple of nice new features are added as well, such as automatical run-time board detection and bus frequency detection, etc. Credits should go to Brad LeRonde and Alice Hennessy who did much of the work in this patch. This patch does not apply to 2.5. I will create one or more new patches later for 2.5. Jun --------------080905060902040806040503 Content-Type: text/plain; name="rockhopper2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rockhopper2.patch" diff -Nru linux/arch/mips/ddb5xxx/common/irq.c.orig linux/arch/mips/ddb5xxx/common/irq.c --- linux/arch/mips/ddb5xxx/common/irq.c.orig Wed Dec 19 10:23:48 2001 +++ linux/arch/mips/ddb5xxx/common/irq.c Tue Jul 9 18:18:46 2002 @@ -13,6 +13,7 @@ */ #include #include +#include void (*irq_setup)(void); diff -Nru linux/arch/mips/ddb5xxx/common/prom.c.orig linux/arch/mips/ddb5xxx/common/prom.c --- linux/arch/mips/ddb5xxx/common/prom.c.orig Wed Dec 26 15:17:29 2001 +++ linux/arch/mips/ddb5xxx/common/prom.c Tue Jul 9 18:43:47 2002 @@ -33,9 +33,15 @@ case MACH_NEC_DDB5476: return "NEC DDB Vrc-5476"; case MACH_NEC_DDB5477: return "NEC DDB Vrc-5477"; case MACH_NEC_ROCKHOPPER: return "NEC Rockhopper"; + case MACH_NEC_ROCKHOPPERII: return "NEC RockhopperII"; + default: return "Unknown DDB machine"; } } +#if defined(CONFIG_DDB5477) +void ddb5477_runtime_detection(void); +#endif + /* [jsun@junsun.net] PMON passes arguments in C main() style */ void __init prom_init(int argc, const char **arg) { @@ -92,6 +98,13 @@ around just after that. */ + /* We can only use the PCI bus to distinquish between + the Rockhopper and RockhopperII backplanes and this must + wait until ddb5477_board_init() in setup.c after the 5477 + is initialized. So, until then handle + both Rockhopper and RockhopperII backplanes as Rockhopper 1 + */ + test_offset = (char *)KSEG1ADDR(DEFAULT_LCS1_BASE + 0x800); saved_test_byte = *test_offset; diff -Nru linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c.orig linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c --- linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c.orig Mon Dec 17 13:00:15 2001 +++ linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c Tue Jul 9 17:11:22 2002 @@ -18,6 +18,7 @@ * This file exports one function: * vrc5477_irq_init(u32 irq_base); */ + #include #include #include @@ -115,15 +116,6 @@ vrc5477_irq_base = irq_base; } - -int vrc5477_irq_to_irq(int irq) -{ - db_assert(irq >= 0); - db_assert(irq < NUM_5477_IRQ); - - return irq + vrc5477_irq_base; -} - void ll_vrc5477_irq_route(int vrc5477_irq, int ip) { u32 reg_value; diff -Nru linux/arch/mips/ddb5xxx/ddb5477/irq.c.orig linux/arch/mips/ddb5xxx/ddb5477/irq.c --- linux/arch/mips/ddb5xxx/ddb5477/irq.c.orig Mon Dec 17 13:00:15 2001 +++ linux/arch/mips/ddb5xxx/ddb5477/irq.c Tue Jul 9 18:44:49 2002 @@ -19,6 +19,8 @@ #include #include #include +#include +#include #include @@ -69,9 +71,12 @@ ddb_out32(pci, reg_value); } +extern void init_i8259_irqs (void); extern void vrc5477_irq_init(u32 base); extern void mips_cpu_irq_init(u32 base); extern asmlinkage void ddb5477_handle_int(void); +extern int setup_irq(unsigned int irq, struct irqaction *irqaction); +static struct irqaction irq_cascade = { no_action, 0, 0, "cascade", NULL, NULL }; void ddb5477_irq_setup(void) @@ -91,7 +96,10 @@ /* setup PCI interrupt attributes */ set_pci_int_attr(PCI0, INTA, ACTIVE_LOW, LEVEL_SENSE); set_pci_int_attr(PCI0, INTB, ACTIVE_LOW, LEVEL_SENSE); - set_pci_int_attr(PCI0, INTC, ACTIVE_LOW, LEVEL_SENSE); + if (mips_machtype == MACH_NEC_ROCKHOPPERII) + set_pci_int_attr(PCI0, INTC, ACTIVE_HIGH, LEVEL_SENSE); + else + set_pci_int_attr(PCI0, INTC, ACTIVE_LOW, LEVEL_SENSE); set_pci_int_attr(PCI0, INTD, ACTIVE_LOW, LEVEL_SENSE); set_pci_int_attr(PCI0, INTE, ACTIVE_LOW, LEVEL_SENSE); @@ -121,13 +129,34 @@ ll_vrc5477_irq_route(31, 1); ll_vrc5477_irq_enable(31); /* init all controllers */ - mips_cpu_irq_init(0); - vrc5477_irq_init(8); + init_i8259_irqs(); + mips_cpu_irq_init(CPU_IRQ_BASE); + vrc5477_irq_init(VRC5477_IRQ_BASE); + + + /* setup cascade interrupts */ + setup_irq(VRC5477_IRQ_BASE + VRC5477_I8259_CASCADE, &irq_cascade); + setup_irq(CPU_IRQ_BASE + CPU_VRC5477_CASCADE, &irq_cascade); /* hook up the first-level interrupt handler */ set_except_vector(0, ddb5477_handle_int); } +u8 i8259_interrupt_ack(void) +{ + u8 irq; + u32 reg; + + /* Set window 0 for interrupt acknowledge */ + reg = ddb_in32(DDB_PCIINIT10); + + ddb_set_pmr(DDB_PCIINIT10, DDB_PCICMD_IACK, 0, DDB_PCI_ACCESS_32); + irq = *(volatile u8 *) KSEG1ADDR(DDB_PCI_IACK_BASE); + ddb_out32(DDB_PCIINIT10, reg); + + /* i8259.c set the base vector to be 0x0 */ + return irq + I8259_IRQ_BASE; +} /* * the first level int-handler will jump here if it is a vrc5477 irq */ @@ -154,10 +183,21 @@ } intStatus = ddb_in32(DDB_INT0STAT); + + if (mips_machtype == MACH_NEC_ROCKHOPPERII) { + /* check for i8259 interrupts */ + if (intStatus & (1 << VRC5477_I8259_CASCADE)) { + int i8259_irq = i8259_interrupt_ack(); + do_IRQ(I8259_IRQ_BASE + i8259_irq, regs); + return; + } + } + for (i=0, bitmask=1; i<= NUM_5477_IRQS; bitmask <<=1, i++) { /* do we need to "and" with the int mask? */ if (intStatus & bitmask) { - do_IRQ(8 + i, regs); + do_IRQ(VRC5477_IRQ_BASE + i, regs); + return; } } } diff -Nru linux/arch/mips/ddb5xxx/ddb5477/pci.c.orig linux/arch/mips/ddb5xxx/ddb5477/pci.c --- linux/arch/mips/ddb5xxx/ddb5477/pci.c.orig Tue Jul 9 15:05:24 2002 +++ linux/arch/mips/ddb5xxx/ddb5477/pci.c Tue Jul 9 18:11:44 2002 @@ -10,12 +10,14 @@ * option) any later version. * */ + #include #include #include #include #include +#include #include #include @@ -23,13 +25,13 @@ static struct resource extpci_io_resource = { "ext pci IO space", - DDB_PCI0_IO_BASE - DDB_PCI_IO_BASE, + DDB_PCI0_IO_BASE - DDB_PCI_IO_BASE + 0x4000, DDB_PCI0_IO_BASE - DDB_PCI_IO_BASE + DDB_PCI0_IO_SIZE -1, IORESOURCE_IO}; static struct resource extpci_mem_resource = { "ext pci memory space", - DDB_PCI0_MEM_BASE, + DDB_PCI0_MEM_BASE + 0x100000, DDB_PCI0_MEM_BASE + DDB_PCI0_MEM_SIZE -1, IORESOURCE_MEM}; @@ -59,79 +61,108 @@ * we fix up irqs based on the slot number. * The first entry is at AD:11. * Fortunately this works because, although we have two pci buses, - * they all have different slot numbers. + * they all have different slot numbers (except for rockhopper slot 20 + * which is handled below). * - * This does not work for devices on sub-buses. - * - * Note that the irq number in the array is relative number in vrc5477. - * We need to translate it to global irq number. - */ - -/* - * irq mapping : PCI int # -> vrc5477 irq # - * based on vrc5477 manual page 46 */ -#define PCI_EXT_INTA 8 -#define PCI_EXT_INTB 9 -#define PCI_EXT_INTC 10 -#define PCI_EXT_INTD 11 -#define PCI_EXT_INTE 12 - -#define PCI_IO_INTA 16 -#define PCI_IO_INTB 17 -#define PCI_IO_INTC 18 -#define PCI_IO_INTD 19 /* - * irq mapping : device -> pci int #, + * irq mapping : device -> pci int # -> vrc4377 irq# , * ddb5477 board manual page 4 and vrc5477 manual page 46 */ -#define INT_ONBOARD_TULIP PCI_EXT_INTA -#define INT_SLOT1 PCI_EXT_INTB -#define INT_SLOT2 PCI_EXT_INTC -#define INT_SLOT3 PCI_EXT_INTD -#define INT_SLOT4 PCI_EXT_INTE - -#define INT_USB_HOST PCI_IO_INTA -#define INT_USB_PERI PCI_IO_INTB -#define INT_AC97 PCI_IO_INTC /* * based on ddb5477 manual page 11 */ #define MAX_SLOT_NUM 21 static unsigned char irq_map[MAX_SLOT_NUM] = { - /* AD:11 */ 0xff, 0xff, 0xff, 0xff, - /* AD:15 */ INT_ONBOARD_TULIP, INT_SLOT1, INT_SLOT2, INT_SLOT3, - /* AD:19 */ INT_SLOT4, 0xff, 0xff, 0xff, - /* AD:23 */ 0xff, 0xff, 0xff, 0xff, - /* AD:27 */ 0xff, 0xff, INT_AC97, INT_USB_PERI, - /* AD:31 */ INT_USB_HOST + /* SLOT: 0, AD:11 */ 0xff, + /* SLOT: 1, AD:12 */ 0xff, + /* SLOT: 2, AD:13 */ 0xff, + /* SLOT: 3, AD:14 */ 0xff, + /* SLOT: 4, AD:15 */ VRC5477_IRQ_INTA, /* onboard tulip */ + /* SLOT: 5, AD:16 */ VRC5477_IRQ_INTB, /* slot 1 */ + /* SLOT: 6, AD:17 */ VRC5477_IRQ_INTC, /* slot 2 */ + /* SLOT: 7, AD:18 */ VRC5477_IRQ_INTD, /* slot 3 */ + /* SLOT: 8, AD:19 */ VRC5477_IRQ_INTE, /* slot 4 */ + /* SLOT: 9, AD:20 */ 0xff, + /* SLOT: 10, AD:21 */ 0xff, + /* SLOT: 11, AD:22 */ 0xff, + /* SLOT: 12, AD:23 */ 0xff, + /* SLOT: 13, AD:24 */ 0xff, + /* SLOT: 14, AD:25 */ 0xff, + /* SLOT: 15, AD:26 */ 0xff, + /* SLOT: 16, AD:27 */ 0xff, + /* SLOT: 17, AD:28 */ 0xff, + /* SLOT: 18, AD:29 */ VRC5477_IRQ_IOPCI_INTC, /* vrc5477 ac97 */ + /* SLOT: 19, AD:30 */ VRC5477_IRQ_IOPCI_INTB, /* vrc5477 usb peri */ + /* SLOT: 20, AD:31 */ VRC5477_IRQ_IOPCI_INTA, /* vrc5477 usb host */ +}; +static unsigned char rockhopperII_irq_map[MAX_SLOT_NUM] = { + /* SLOT: 0, AD:11 */ 0xff, + /* SLOT: 1, AD:12 */ VRC5477_IRQ_INTB, /* onboard AMD PCNET */ + /* SLOT: 2, AD:13 */ 0xff, + /* SLOT: 3, AD:14 */ 0xff, + /* SLOT: 4, AD:15 */ 14, /* M5229 ide ISA irq */ + /* SLOT: 5, AD:16 */ VRC5477_IRQ_INTD, /* slot 3 */ + /* SLOT: 6, AD:17 */ VRC5477_IRQ_INTA, /* slot 4 */ + /* SLOT: 7, AD:18 */ VRC5477_IRQ_INTD, /* slot 5 */ + /* SLOT: 8, AD:19 */ 0, /* M5457 modem nop */ + /* SLOT: 9, AD:20 */ VRC5477_IRQ_INTA, /* slot 2 */ + /* SLOT: 10, AD:21 */ 0xff, + /* SLOT: 11, AD:22 */ 0xff, + /* SLOT: 12, AD:23 */ 0xff, + /* SLOT: 13, AD:24 */ 0xff, + /* SLOT: 14, AD:25 */ 0xff, + /* SLOT: 15, AD:26 */ 0xff, + /* SLOT: 16, AD:27 */ 0xff, + /* SLOT: 17, AD:28 */ 0, /* M7101 PMU nop */ + /* SLOT: 18, AD:29 */ VRC5477_IRQ_IOPCI_INTC, /* vrc5477 ac97 */ + /* SLOT: 19, AD:30 */ VRC5477_IRQ_IOPCI_INTB, /* vrc5477 usb peri */ + /* SLOT: 20, AD:31 */ VRC5477_IRQ_IOPCI_INTA, /* vrc5477 usb host */ }; -extern int vrc5477_irq_to_irq(int irq); void __init pcibios_fixup_irqs(void) { struct pci_dev *dev; int slot_num; + unsigned char *slot_irq_map; + unsigned char irq; + + if (mips_machtype == MACH_NEC_ROCKHOPPERII) + slot_irq_map = rockhopperII_irq_map; + else + slot_irq_map = irq_map; + pci_for_each_dev(dev) { slot_num = PCI_SLOT(dev->devfn); - - /* we don't do IRQ fixup for sub-bus yet */ - if (dev->bus->parent != NULL) { - db_run(printk("Don't know how to fixup irq for PCI device %d on sub-bus %d\n", - slot_num, dev->bus->number)); - continue; - } + irq = slot_irq_map[slot_num]; db_assert(slot_num < MAX_SLOT_NUM); - db_assert(irq_map[slot_num] != 0xff); + + db_assert(irq != 0xff); pci_write_config_byte(dev, PCI_INTERRUPT_LINE, - irq_map[slot_num]); - dev->irq = vrc5477_irq_to_irq(irq_map[slot_num]); + irq); + + dev->irq = irq; + + if (mips_machtype == MACH_NEC_ROCKHOPPERII) { + /* hack to distinquish overlapping slot 20s, one + * on bus 0 (ALI USB on the M1535 on the backplane), + * and one on bus 2 (NEC USB controller on the CPU board) + * Make the M1535 USB - ISA IRQ number 9. + */ + if (slot_num == 20 && dev->bus->number == 0) { + pci_write_config_byte(dev, + PCI_INTERRUPT_LINE, + 9); + dev->irq = 9; + } + } + } } @@ -139,7 +170,7 @@ extern void jsun_scan_pci_bus(void); extern void jsun_assign_pci_resource(void); #endif -void __init ddb_pci_reset_bus(void) +void ddb_pci_reset_bus(void) { u32 temp; @@ -175,5 +206,43 @@ void __init pcibios_fixup(void) { + if (mips_machtype == MACH_NEC_ROCKHOPPERII) { + struct pci_dev *dev; + +#define M1535_CONFIG_PORT 0x3f0 +#define M1535_INDEX_PORT 0x3f0 +#define M1535_DATA_PORT 0x3f1 + + printk("Configuring ALI M1535 Super I/O mouse irq.\n"); + + request_region(M1535_CONFIG_PORT, 2, "M1535 Super I/O config"); + + /* Enter config mode. */ + outb(0x51, M1535_CONFIG_PORT); + outb(0x23, M1535_CONFIG_PORT); + + /* Select device 0x07. */ + outb(0x07, M1535_INDEX_PORT); + outb(0x07, M1535_DATA_PORT); + + /* Set mouse irq (register 0x72) to 12. */ + outb(0x72, M1535_INDEX_PORT); + outb(0x0c, M1535_DATA_PORT); + + /* Exit config mode. */ + outb(0xbb, M1535_CONFIG_PORT); + + pci_for_each_dev(dev) { + if(dev->vendor == PCI_VENDOR_ID_AL) + if(dev->device == PCI_DEVICE_ID_AL_M1535 + || dev->device == PCI_DEVICE_ID_AL_M1533) { + u8 old; + printk("Enabling ALI M1533/35 PS2 keyboard/mouse.\n"); + pci_read_config_byte(dev, 0x41, &old); + pci_write_config_byte(dev, 0x41, old | 0xd0); + } + } + + } } diff -Nru linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig linux/arch/mips/ddb5xxx/ddb5477/setup.c --- linux/arch/mips/ddb5xxx/ddb5477/setup.c.orig Tue Jul 9 15:05:24 2002 +++ linux/arch/mips/ddb5xxx/ddb5477/setup.c Tue Jul 9 17:34:09 2002 @@ -24,6 +24,7 @@ #include #include /* for HZ */ +#include #include #include #include @@ -31,8 +32,11 @@ #include #include #include -#include #include +#include +#ifdef CONFIG_PC_KEYB +#include +#endif #include @@ -41,15 +45,13 @@ // #define USE_CPU_COUNTER_TIMER /* whether we use cpu counter */ -#ifdef USE_CPU_COUNTER_TIMER -#define CPU_COUNTER_FREQUENCY 83000000 -#else -/* otherwise we use special timer 1 */ -#define SP_TIMER_FREQUENCY 83000000 +#ifndef USE_CPU_COUNTER_TIMER #define SP_TIMER_BASE DDB_SPT1CTRL_L -#define SP_TIMER_IRQ (8 + 6) +#define SP_TIMER_IRQ VRC5477_IRQ_SPT1 #endif +static int bus_frequency = CONFIG_DDB5477_BUS_FREQUENCY*1000; + static void ddb_machine_restart(char *command) { static void (*back_to_prom) (void) = (void (*)(void)) 0xbfc00000; @@ -80,19 +82,71 @@ while (1); } +static unsigned int __init detect_bus_frequency(unsigned long rtc_base) +{ + unsigned int freq; + unsigned char c; + unsigned int t1, t2; + unsigned i; + unsigned preset_freq[]={ + 0, 83330000, 100000000, 124000000,133300000, 0xffffffff}; + + ddb_out32(SP_TIMER_BASE, 0xffffffff); + ddb_out32(SP_TIMER_BASE+4, 0x1); + ddb_out32(SP_TIMER_BASE+8, 0xffffffff); + c= *(volatile unsigned char*)rtc_base; + for(i=0; (i<100000000) && (c == *(volatile unsigned char*)rtc_base); i++); + + if (c == *(volatile unsigned char*)rtc_base) { + printk("Failed to detect bus frequency. Use default 83.3MHz.\n"); + return 83333000; + } + + /* we are now at the turn of 1/100th second */ + t1 = ddb_in32(SP_TIMER_BASE+8); + + c= *(volatile unsigned char*)rtc_base; + while (c == *(volatile unsigned char*)rtc_base); + + /* we are now at the turn of another 1/100th second */ + t2 = ddb_in32(SP_TIMER_BASE+8); + ddb_out32(SP_TIMER_BASE+4, 0x0); /* disable it again */ + freq = (t1 - t2)*100; + + /* find the nearest preset freq */ + for (i=0; freq > preset_freq[i+1]; i++); + if ((freq - preset_freq[i]) >= (preset_freq[i+1]-freq)) + i++; + + printk("DDB bus frequency detection : %d -> %d\n", freq, preset_freq[i]); + return preset_freq[i]; +} + extern void rtc_ds1386_init(unsigned long base); static void __init ddb_time_init(void) { -#if defined(USE_CPU_COUNTER_TIMER) - mips_counter_frequency = CPU_COUNTER_FREQUENCY; -#endif + unsigned long rtc_base; + unsigned int i; /* we have ds1396 RTC chip */ - if (mips_machtype == MACH_NEC_ROCKHOPPER) { - rtc_ds1386_init(KSEG1ADDR(DDB_LCS2_BASE)); + if (mips_machtype == MACH_NEC_ROCKHOPPER + || mips_machtype == MACH_NEC_ROCKHOPPERII) { + rtc_base = KSEG1ADDR(DDB_LCS2_BASE); } else { - rtc_ds1386_init(KSEG1ADDR(DDB_LCS1_BASE)); + rtc_base = KSEG1ADDR(DDB_LCS1_BASE); + } + rtc_ds1386_init(rtc_base); + + /* do we need to do run-time detection of bus speed? */ + if (bus_frequency == 0) { + bus_frequency = detect_bus_frequency(rtc_base); } + + /* mips_counter_frequency is 1/2 of the cpu core freq */ + i = (read_32bit_cp0_register(CP0_CONFIG) >> 28 ) & 7; + if ((mips_cpu.cputype == CPU_R5432) && (i == 3)) + i = 4; + mips_counter_frequency = bus_frequency*(i+4)/4; } extern int setup_irq(unsigned int irq, struct irqaction *irqaction); @@ -102,7 +156,7 @@ unsigned int count; /* we are using the cpu counter for timer interrupts */ - setup_irq(7, irq); + setup_irq(CPU_IRQ_BASE + 7, irq); /* to generate the first timer interrupt */ count = read_32bit_cp0_register(CP0_COUNT); @@ -110,18 +164,16 @@ #else - /* if we don't use Special purpose timer 1 */ - ddb_out32(SP_TIMER_BASE, SP_TIMER_FREQUENCY/HZ); + /* if we use Special purpose timer 1 */ + ddb_out32(SP_TIMER_BASE, bus_frequency/HZ); ddb_out32(SP_TIMER_BASE+4, 0x1); setup_irq(SP_TIMER_IRQ, irq); #endif } - void __init bus_error_init(void) { /* nothing */ } - static void ddb5477_board_init(void); extern void ddb5477_irq_setup(void); @@ -132,6 +184,12 @@ void __init ddb_setup(void) { extern int panic_timeout; +#ifdef CONFIG_BLK_DEV_IDE + extern struct ide_ops std_ide_ops; +#endif + + /* initialize board - we don't trust the loader */ + ddb5477_board_init(); irq_setup = ddb5477_irq_setup; set_io_port_base(KSEG1ADDR(DDB_PCI_IO_BASE)); @@ -150,13 +208,15 @@ /* Reboot on panic */ panic_timeout = 180; +#ifdef CONFIG_BLK_DEV_IDE + ide_ops = &std_ide_ops; +#endif + + #ifdef CONFIG_FB conswitchp = &dummy_con; #endif - /* initialize board - we don't trust the loader */ - ddb5477_board_init(); - #if defined(CONFIG_BLK_DEV_INITRD) ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); initrd_start = (unsigned long)&__rd_start; @@ -166,6 +226,9 @@ static void __init ddb5477_board_init() { +#ifdef CONFIG_PC_KEYB + extern struct kbd_ops std_kbd_ops; +#endif /* ----------- setup PDARs ------------ */ /* SDRAM should have been set */ @@ -261,16 +324,117 @@ ddb_set_pdar(DDB_BARP01, DDB_PCI0_MEM_BASE, DDB_PCI0_MEM_SIZE, 32, 0, 1); ddb_set_pdar(DDB_BARP11, DDB_PCI0_IO_BASE, DDB_PCI0_IO_SIZE, 32, 0, 1); + if (mips_machtype == MACH_NEC_ROCKHOPPER + || mips_machtype == MACH_NEC_ROCKHOPPERII) { + /* Disable bus diagnostics. */ + ddb_out32(DDB_PCICTL0_L, 0); + ddb_out32(DDB_PCICTL0_H, 0); + ddb_out32(DDB_PCICTL1_L, 0); + ddb_out32(DDB_PCICTL1_H, 0); + } + + if (mips_machtype == MACH_NEC_ROCKHOPPER) { + u16 vid; + struct pci_bus bus; + struct pci_dev dev_m1533; + extern struct pci_ops ddb5477_ext_pci_ops; + + bus.parent = NULL; /* we scan the top level only */ + bus.ops = &ddb5477_ext_pci_ops; + dev_m1533.bus = &bus; + dev_m1533.sysdata = NULL; + dev_m1533.devfn = 7*8; // slot 7: M1533 SouthBridge. + pci_read_config_word(&dev_m1533, 0, &vid); + if (vid == PCI_VENDOR_ID_AL) { + printk("Changing mips_machtype to MACH_NEC_ROCKHOPPERII\n"); + mips_machtype = MACH_NEC_ROCKHOPPERII; + } + } + /* enable USB input buffers */ ddb_out32(DDB_PIBMISC, 0x00000007); /* For dual-function pins, make them all non-GPIO */ ddb_out32(DDB_GIUFUNSEL, 0x0); // ddb_out32(DDB_GIUFUNSEL, 0xfe0fcfff); /* NEC recommanded value */ + + if (mips_machtype == MACH_NEC_ROCKHOPPERII) { +#ifdef CONFIG_PC_KEYB + printk("kdb_ops is std\n"); + kbd_ops = &std_kbd_ops; +#endif + } - if (mips_machtype == MACH_NEC_ROCKHOPPER) { + if (mips_machtype == MACH_NEC_ROCKHOPPERII) { + + /* enable IDE controller on Ali chip (south bridge) */ + u8 temp8; + struct pci_bus bus; + struct pci_dev dev_m1533; + struct pci_dev dev_m5229; + extern struct pci_ops ddb5477_ext_pci_ops; + + /* Setup M1535 registers */ + bus.parent = NULL; /* we scan the top level only */ + bus.ops = &ddb5477_ext_pci_ops; + dev_m1533.bus = &bus; + dev_m1533.sysdata = NULL; + dev_m1533.devfn = 7*8; // slot 7: M1533 SouthBridge. + + /* setup IDE controller + * enable IDE controller (bit 6 - 1) + * IDE IDSEL to be addr:A15 (bit 4:5 - 11) + * disable IDE ATA Secondary Bus Signal Pad Control (bit 3 - 0) + * enable IDE ATA Primary Bus Signal Pad Control (bit 2 - 1) + */ + pci_write_config_byte(&dev_m1533, 0x58, 0x74); + + /* + * positive decode (bit6 -0) + * enable IDE controler interrupt (bit 4 -1) + * setup SIRQ to point to IRQ 14 (bit 3:0 - 1101) + */ + pci_write_config_byte(&dev_m1533, 0x44, 0x1d); + + /* Setup M5229 registers */ + dev_m5229.bus = &bus; + dev_m5229.sysdata = NULL; + dev_m5229.devfn = 4*8; // slot 4 (AD15): M5229 IDE + + /* + * enable IDE in the M5229 config register 0x50 (bit 0 - 1) + * M5229 IDSEL is addr:15; see above setting + */ + pci_read_config_byte(&dev_m5229, 0x50, &temp8); + pci_write_config_byte(&dev_m5229, 0x50, temp8 | 0x1); + + /* + * enable bus master (bit 2) and IO decoding (bit 0) + */ + pci_read_config_byte(&dev_m5229, 0x04, &temp8); + pci_write_config_byte(&dev_m5229, 0x04, temp8 | 0x5); + + /* + * enable native, copied from arch/ppc/k2boot/head.S + * TODO - need volatile, need to be portable + */ + pci_write_config_byte(&dev_m5229, 0x09, 0xef); + + /* Set Primary Channel Command Block Timing */ + pci_write_config_byte(&dev_m5229, 0x59, 0x31); + + /* + * Enable primary channel 40-pin cable + * M5229 register 0x4a (bit 0) + */ + pci_read_config_byte(&dev_m5229, 0x4a, &temp8); + pci_write_config_byte(&dev_m5229, 0x4a, temp8 | 0x1); + } + + if (mips_machtype == MACH_NEC_ROCKHOPPER + || mips_machtype == MACH_NEC_ROCKHOPPERII) { printk("lcd44780: initializing\n"); lcd44780_init(); - lcd44780_puts("Linux/MIPS rolls"); + lcd44780_puts("MontaVista Linux"); } } diff -Nru linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c.orig linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c --- linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c.orig Fri Nov 16 02:54:42 2001 +++ linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c Tue Jul 9 18:45:53 2002 @@ -300,114 +300,3 @@ iopci_write_config_dword }; -#if defined(CONFIG_DEBUG) -void jsun_scan_pci_bus(void) -{ - struct pci_bus bus; - struct pci_dev dev; - unsigned int devfn; - int j; - - bus.parent = NULL; /* we scan the top level only */ - dev.bus = &bus; - dev.sysdata = NULL; - - /* scan ext pci bus and io pci bus*/ - for (j=0; j< 2; j++) { - if (j == 0) { - printk("scan ddb5477 external PCI bus:\n"); - bus.ops = &ddb5477_ext_pci_ops; - } else { - printk("scan ddb5477 IO PCI bus:\n"); - bus.ops = &ddb5477_io_pci_ops; - } - - for (devfn = 0; devfn < 0x100; devfn += 8) { - u32 temp; - u16 temp16; - u8 temp8; - int i; - - dev.devfn = devfn; - db_verify(pci_read_config_dword(&dev, 0, &temp), - == PCIBIOS_SUCCESSFUL); - if (temp == 0xffffffff) continue; - - printk("slot %d: (addr %d) \n", devfn/8, 11+devfn/8); - - /* verify read word and byte */ - db_verify(pci_read_config_word(&dev, 2, &temp16), - == PCIBIOS_SUCCESSFUL); - db_assert(temp16 == (temp >> 16)); - db_verify(pci_read_config_byte(&dev, 3, &temp8), - == PCIBIOS_SUCCESSFUL); - db_assert(temp8 == (temp >> 24)); - db_verify(pci_read_config_byte(&dev, 1, &temp8), - == PCIBIOS_SUCCESSFUL); - db_assert(temp8 == ((temp >> 8) & 0xff)); - - for (i=0; i < 16; i++) { - db_verify(pci_read_config_dword(&dev, i*4, &temp), - == PCIBIOS_SUCCESSFUL); - printk("\t%08X", temp); - if ((i%4) == 3) printk("\n"); - } - } - } -} - - -static void jsun_hardcode_pci_resources_eepro(void) -{ - struct pci_bus bus; - struct pci_dev dev; - u32 temp; - - bus.parent = NULL; /* we scan the top level only */ - bus.ops = &ddb5477_ext_pci_ops; - dev.bus = &bus; - dev.sysdata = NULL; - - /* for slot 5 (ext pci 1) eepro card */ - dev.devfn = 5*8; - pci_read_config_dword(&dev, 0, &temp); - db_assert(temp == 0x12298086); - - pci_write_config_dword(&dev, PCI_BASE_ADDRESS_0, DDB_PCI0_MEM_BASE); - pci_write_config_dword(&dev, PCI_BASE_ADDRESS_1, 0); - pci_write_config_dword(&dev, PCI_BASE_ADDRESS_2, DDB_PCI0_MEM_BASE+0x100000); - pci_write_config_dword(&dev, PCI_INTERRUPT_LINE, 17); -} - -static void jsun_hardcode_pci_resources_onboard_tulip(void) -{ - struct pci_bus bus; - struct pci_dev dev; - u32 temp; - - bus.parent = NULL; /* we scan the top level only */ - bus.ops = &ddb5477_ext_pci_ops; - dev.bus = &bus; - dev.sysdata = NULL; - - /* for slot 4 on board ether chip */ - dev.devfn = 4*8; - pci_read_config_dword(&dev, 0, &temp); - db_assert(temp == 0x00191011); - - pci_write_config_dword(&dev, PCI_BASE_ADDRESS_0, 0x1000); - pci_write_config_dword(&dev, PCI_BASE_ADDRESS_1, DDB_PCI0_MEM_BASE); - pci_write_config_dword(&dev, PCI_INTERRUPT_LINE, 16); -} - -static void jsun_hardcode_pci_resources(void) -{ - jsun_hardcode_pci_resources_onboard_tulip(); -} - -void jsun_assign_pci_resource(void) -{ - jsun_hardcode_pci_resources(); -} - -#endif diff -Nru linux/arch/mips/Makefile.orig linux/arch/mips/Makefile --- linux/arch/mips/Makefile.orig Tue Jul 9 15:05:23 2002 +++ linux/arch/mips/Makefile Tue Jul 9 15:18:31 2002 @@ -294,7 +294,7 @@ SUBDIRS += arch/mips/ddb5xxx/common arch/mips/ddb5xxx/ddb5477 LIBS += arch/mips/ddb5xxx/common/ddb5xxx.o \ arch/mips/ddb5xxx/ddb5477/ddb5477.o -LOADADDR := 0x80080000 +LOADADDR := 0x80100000 endif # diff -Nru linux/arch/mips/config.in.orig linux/arch/mips/config.in --- linux/arch/mips/config.in.orig Tue Jul 9 15:05:23 2002 +++ linux/arch/mips/config.in Tue Jul 9 18:21:21 2002 @@ -55,6 +55,9 @@ dep_bool 'Support for NEC DDB Vrc-5074 (EXPERIMENTAL)' CONFIG_DDB5074 $CONFIG_EXPERIMENTAL bool 'Support for NEC DDB Vrc-5476' CONFIG_DDB5476 bool 'Support for NEC DDB Vrc-5477' CONFIG_DDB5477 +if [ "$CONFIG_DDB5477" = "y" ]; then + int ' bus frequency (in kHZ, 0 for auto-detect)' CONFIG_DDB5477_BUS_FREQUENCY 0 +fi bool 'Support for NEC Osprey board' CONFIG_NEC_OSPREY bool 'Support for Olivetti M700-10' CONFIG_OLIVETTI_M700 dep_bool 'Support for Philips Nino (EXPERIMENTAL)' CONFIG_NINO $CONFIG_EXPERIMENTAL @@ -251,6 +254,7 @@ define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_DUMMY_KEYB y + define_bool CONFIG_I8259 y fi if [ "$CONFIG_NEC_OSPREY" = "y" ]; then define_bool CONFIG_VR4181 y diff -Nru linux/arch/mips/defconfig-ddb5477.orig linux/arch/mips/defconfig-ddb5477 --- linux/arch/mips/defconfig-ddb5477.orig Tue Jul 9 15:05:23 2002 +++ linux/arch/mips/defconfig-ddb5477 Wed Jul 10 13:56:19 2002 @@ -36,6 +36,7 @@ # CONFIG_DDB5074 is not set # CONFIG_DDB5476 is not set CONFIG_DDB5477=y +CONFIG_DDB5477_BUS_FREQUENCY=0 # CONFIG_NEC_OSPREY is not set # CONFIG_OLIVETTI_M700 is not set # CONFIG_NINO is not set @@ -54,6 +55,7 @@ CONFIG_NONCOHERENT_IO=y CONFIG_PCI_AUTO=y CONFIG_DUMMY_KEYB=y +CONFIG_I8259=y # CONFIG_MIPS_AU1000 is not set # @@ -264,7 +266,7 @@ # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y -# CONFIG_PCNET32 is not set +CONFIG_PCNET32=y # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set diff -Nru linux/include/asm-mips/ddb5xxx/ddb5477.h.orig linux/include/asm-mips/ddb5xxx/ddb5477.h --- linux/include/asm-mips/ddb5xxx/ddb5477.h.orig Tue Jul 9 15:13:10 2002 +++ linux/include/asm-mips/ddb5xxx/ddb5477.h Tue Jul 9 18:38:08 2002 @@ -216,6 +216,7 @@ /* * DDB5477 specific functions */ +#ifndef __ASSEMBLY__ extern void ddb5477_irq_setup(void); /* route irq to cpu int pin */ @@ -224,10 +225,110 @@ /* low-level routine for enabling vrc5477 irq, bypassing high-level */ extern void ll_vrc5477_irq_enable(int vrc5477_irq); extern void ll_vrc5477_irq_disable(int vrc5477_irq); +#endif /* !__ASSEMBLY__ */ + +/* PCI intr ack share PCIW0 with PCI IO */ +#define DDB_PCI_IACK_BASE DDB_PCI_IO_BASE + +/* + * Interrupt mapping + * + * We have three interrupt controllers: + * + * . CPU itself - 8 sources + * . i8259 - 16 sources + * . vrc5477 - 32 sources + * + * They connected as follows: + * all vrc5477 interrupts are routed to cpu IP2 (by software setting) + * all i8359 are routed to INTC in vrc5477 (by hardware connection) + * + * All VRC5477 PCI interrupts are level-triggered (no ack needed). + * All PCI irq but INTC are active low. + */ + +/* + * irq number block assignment + */ + +#define NUM_CPU_IRQ 8 +#define NUM_I8259_IRQ 16 +#define NUM_VRC5477_IRQ 32 + +#define DDB_IRQ_BASE 0 + +#define I8259_IRQ_BASE DDB_IRQ_BASE +#define VRC5477_IRQ_BASE (I8259_IRQ_BASE + NUM_I8259_IRQ) +#define CPU_IRQ_BASE (VRC5477_IRQ_BASE + NUM_VRC5477_IRQ) + +/* + * vrc5477 irq defs + */ + +#define VRC5477_IRQ_CPCE (0 + VRC5477_IRQ_BASE) /* cpu parity error */ +#define VRC5477_IRQ_CNTD (1 + VRC5477_IRQ_BASE) /* cpu no target */ +#define VRC5477_IRQ_I2C (2 + VRC5477_IRQ_BASE) /* I2C */ +#define VRC5477_IRQ_DMA (3 + VRC5477_IRQ_BASE) /* DMA */ +#define VRC5477_IRQ_UART0 (4 + VRC5477_IRQ_BASE) +#define VRC5477_IRQ_WDOG (5 + VRC5477_IRQ_BASE) /* watchdog timer */ +#define VRC5477_IRQ_SPT1 (6 + VRC5477_IRQ_BASE) /* special purpose timer 1 */ +#define VRC5477_IRQ_LBRT (7 + VRC5477_IRQ_BASE) /* local bus read timeout */ +#define VRC5477_IRQ_INTA (8 + VRC5477_IRQ_BASE) /* PCI INT #A */ +#define VRC5477_IRQ_INTB (9 + VRC5477_IRQ_BASE) /* PCI INT #B */ +#define VRC5477_IRQ_INTC (10 + VRC5477_IRQ_BASE) /* PCI INT #C */ +#define VRC5477_IRQ_INTD (11 + VRC5477_IRQ_BASE) /* PCI INT #D */ +#define VRC5477_IRQ_INTE (12 + VRC5477_IRQ_BASE) /* PCI INT #E */ +#define VRC5477_IRQ_RESERVED_13 (13 + VRC5477_IRQ_BASE) /* reserved */ +#define VRC5477_IRQ_PCIS (14 + VRC5477_IRQ_BASE) /* PCI SERR # */ +#define VRC5477_IRQ_PCI (15 + VRC5477_IRQ_BASE) /* PCI internal error */ +#define VRC5477_IRQ_IOPCI_INTA (16 + VRC5477_IRQ_BASE) /* USB-H */ +#define VRC5477_IRQ_IOPCI_INTB (17 + VRC5477_IRQ_BASE) /* USB-P */ +#define VRC5477_IRQ_IOPCI_INTC (18 + VRC5477_IRQ_BASE) /* AC97 */ +#define VRC5477_IRQ_IOPCI_INTD (19 + VRC5477_IRQ_BASE) /* Reserved */ +#define VRC5477_IRQ_UART1 (20 + VRC5477_IRQ_BASE) +#define VRC5477_IRQ_SPT0 (21 + VRC5477_IRQ_BASE) /* special purpose timer 0 */ +#define VRC5477_IRQ_GPT0 (22 + VRC5477_IRQ_BASE) /* general purpose timer 0 */ +#define VRC5477_IRQ_GPT1 (23 + VRC5477_IRQ_BASE) /* general purpose timer 1 */ +#define VRC5477_IRQ_GPT2 (24 + VRC5477_IRQ_BASE) /* general purpose timer 2 */ +#define VRC5477_IRQ_GPT3 (25 + VRC5477_IRQ_BASE) /* general purpose timer 3 */ +#define VRC5477_IRQ_GPIO (26 + VRC5477_IRQ_BASE) +#define VRC5477_IRQ_SIO0 (27 + VRC5477_IRQ_BASE) +#define VRC5477_IRQ_SIO1 (28 + VRC5477_IRQ_BASE) +#define VRC5477_IRQ_RESERVED_29 (29 + VRC5477_IRQ_BASE) /* reserved */ +#define VRC5477_IRQ_IOPCISERR (30 + VRC5477_IRQ_BASE) /* IO PCI SERR # */ +#define VRC5477_IRQ_IOPCI (31 + VRC5477_IRQ_BASE) + +/* + * i2859 irq assignment + */ +#define I8259_IRQ_RESERVED_0 (0 + I8259_IRQ_BASE) +#define I8259_IRQ_KEYBOARD (1 + I8259_IRQ_BASE) /* M1543 default */ +#define I8259_IRQ_CASCADE (2 + I8259_IRQ_BASE) +#define I8259_IRQ_UART_B (3 + I8259_IRQ_BASE) /* M1543 default, may conflict with RTC according to schematic diagram */ +#define I8259_IRQ_UART_A (4 + I8259_IRQ_BASE) /* M1543 default */ +#define I8259_IRQ_PARALLEL (5 + I8259_IRQ_BASE) /* M1543 default */ +#define I8259_IRQ_RESERVED_6 (6 + I8259_IRQ_BASE) +#define I8259_IRQ_RESERVED_7 (7 + I8259_IRQ_BASE) +#define I8259_IRQ_RTC (8 + I8259_IRQ_BASE) /* who set this? */ +#define I8259_IRQ_USB (9 + I8259_IRQ_BASE) /* ddb_setup */ +#define I8259_IRQ_PMU (10 + I8259_IRQ_BASE) /* ddb_setup */ +#define I8259_IRQ_RESERVED_11 (11 + I8259_IRQ_BASE) +#define I8259_IRQ_RESERVED_12 (12 + I8259_IRQ_BASE) /* m1543_irq_setup */ +#define I8259_IRQ_RESERVED_13 (13 + I8259_IRQ_BASE) +#define I8259_IRQ_HDC1 (14 + I8259_IRQ_BASE) /* default and ddb_setup */ +#define I8259_IRQ_HDC2 (15 + I8259_IRQ_BASE) /* default */ + + +/* + * misc + */ +#define VRC5477_I8259_CASCADE (VRC5477_IRQ_INTC - VRC5477_IRQ_BASE) +#define CPU_VRC5477_CASCADE 2 /* * debug routines */ +#ifndef __ASSEMBLY__ #if defined(CONFIG_DEBUG) extern void vrc5477_show_pdar_regs(void); extern void vrc5477_show_pci_regs(void); @@ -240,5 +341,6 @@ * RAM size */ extern int board_ram_size; +#endif /* !__ASSEMBLY__ */ #endif /* __ASM_DDB5XXX_DDB5477_H */ diff -Nru linux/include/asm-mips/bootinfo.h.orig linux/include/asm-mips/bootinfo.h --- linux/include/asm-mips/bootinfo.h.orig Tue Jul 9 15:13:03 2002 +++ linux/include/asm-mips/bootinfo.h Tue Jul 9 17:57:18 2002 @@ -100,6 +100,7 @@ #define MACH_NEC_DDB5476 1 /* NEC DDB Vrc-5476 */ #define MACH_NEC_DDB5477 2 /* NEC DDB Vrc-5477 */ #define MACH_NEC_ROCKHOPPER 3 /* Rockhopper base board */ +#define MACH_NEC_ROCKHOPPERII 4 /* Rockhopper II base board */ /* * Valid machtype for group BAGET diff -Nru linux/include/asm-mips/serial.h.orig linux/include/asm-mips/serial.h --- linux/include/asm-mips/serial.h.orig Tue Jul 9 18:22:04 2002 +++ linux/include/asm-mips/serial.h Tue Jul 9 18:54:14 2002 @@ -268,12 +268,13 @@ #endif #ifdef CONFIG_DDB5477 -#define DDB5477_SERIAL_PORT_DEFNS \ - { baud_base: BASE_BAUD, irq: 12, flags: STD_COM_FLAGS, \ - iomem_base: (u8*)0xbfa04200, iomem_reg_shift: 3, \ +#include +#define DDB5477_SERIAL_PORT_DEFNS \ + { baud_base: BASE_BAUD, irq: VRC5477_IRQ_UART0, flags: STD_COM_FLAGS, \ + iomem_base: (u8*)0xbfa04200, iomem_reg_shift: 3, \ io_type: SERIAL_IO_MEM},\ - { baud_base: BASE_BAUD, irq: 28, flags: STD_COM_FLAGS, \ - iomem_base: (u8*)0xbfa04240, iomem_reg_shift: 3, \ + { baud_base: BASE_BAUD, irq: VRC5477_IRQ_UART1, flags: STD_COM_FLAGS, \ + iomem_base: (u8*)0xbfa04240, iomem_reg_shift: 3, \ io_type: SERIAL_IO_MEM}, #else #define DDB5477_SERIAL_PORT_DEFNS diff -Nru linux/include/linux/pci_ids.h.orig linux/include/linux/pci_ids.h --- linux/include/linux/pci_ids.h.orig Tue Jul 9 15:07:04 2002 +++ linux/include/linux/pci_ids.h Tue Jul 9 18:14:36 2002 @@ -811,6 +811,7 @@ #define PCI_DEVICE_ID_AL_M1523 0x1523 #define PCI_DEVICE_ID_AL_M1531 0x1531 #define PCI_DEVICE_ID_AL_M1533 0x1533 +#define PCI_DEVICE_ID_AL_M1535 0x1535 #define PCI_DEVICE_ID_AL_M1541 0x1541 #define PCI_DEVICE_ID_AL_M1621 0x1621 #define PCI_DEVICE_ID_AL_M1631 0x1631 --------------080905060902040806040503-- From owner-linux-mips@oss.sgi.com Wed Jul 10 14:59:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ALxERw021481 for ; Wed, 10 Jul 2002 14:59:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ALxEXv021480 for linux-mips-outgoing; Wed, 10 Jul 2002 14:59:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ALx4Rw021469; Wed, 10 Jul 2002 14:59:05 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA16556; Wed, 10 Jul 2002 15:03:30 -0700 Message-ID: <3D2CAD78.9070609@mvista.com> Date: Wed, 10 Jul 2002 14:56:08 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com, Ralf Baechle Subject: [2.4 PATCH] pcnet32.c - tx underflow error Content-Type: multipart/mixed; boundary="------------040900060000070504050505" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------040900060000070504050505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram. The patch is already accepted by Marcelo for the 2.4 tree, I think. Jun --------------040900060000070504050505 Content-Type: text/plain; name="pcnet32.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pcnet32.patch" diff -Nru linux/drivers/net/pcnet32.c.orig linux/drivers/net/pcnet32.c --- linux/drivers/net/pcnet32.c.orig Tue Jul 9 15:05:55 2002 +++ linux/drivers/net/pcnet32.c Tue Jul 9 18:28:19 2002 @@ -569,7 +569,7 @@ break; case 0x2625: chipname = "PCnet/FAST III 79C973"; /* PCI */ - fdx = 1; mii = 1; + fdx = 1; mii = 1; fset = 1; break; case 0x2626: chipname = "PCnet/Home 79C978"; /* PCI */ @@ -613,7 +613,7 @@ if(fset) { a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0800)); - a->write_csr(ioaddr, 80, (a->read_csr(ioaddr, 80) & 0x0C00) | 0x0c00); + a->write_csr(ioaddr, 80, (a->read_csr(ioaddr, 80) & ~0x0C00) | 0x0c00); dxsuflo = 1; ltint = 1; } --------------040900060000070504050505-- From owner-linux-mips@oss.sgi.com Wed Jul 10 16:23:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ANNlRw023670 for ; Wed, 10 Jul 2002 16:23:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ANNlCI023669 for linux-mips-outgoing; Wed, 10 Jul 2002 16:23:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ANNcRw023655; Wed, 10 Jul 2002 16:23:40 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17SRFB-00087H-00; Thu, 11 Jul 2002 00:51:37 +0100 Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error To: jsun@mvista.com (Jun Sun) Date: Thu, 11 Jul 2002 00:51:37 +0100 (BST) Cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com (Ralf Baechle), marcelo@conectiva.com.br In-Reply-To: <3D2CAD78.9070609@mvista.com> from "Jun Sun" at Jul 10, 2002 02:56:08 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > This patch fixes a tx underflow error for 79c973 chip. It essentially delay > the transmission until the whole packet is received into the on-chip sdram. > > The patch is already accepted by Marcelo for the 2.4 tree, I think. Which slows the stuff down for people with real computers. Please apply some kind of heuristic to this - eg switch to delaying if you exceed 50 failures in a 60 second period. Alan From owner-linux-mips@oss.sgi.com Wed Jul 10 16:31:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ANVqRw023825 for ; Wed, 10 Jul 2002 16:31:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ANVqQH023824 for linux-mips-outgoing; Wed, 10 Jul 2002 16:31:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ANVeRw023814 for ; Wed, 10 Jul 2002 16:31:40 -0700 Received: from av.mvista.com (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 QAA06224 for ; Wed, 10 Jul 2002 16:36:35 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA23383; Wed, 10 Jul 2002 16:20:13 -0700 Message-ID: <3D2CBF73.50001@mvista.com> Date: Wed, 10 Jul 2002 16:12:51 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Malta crashes on the latest 2.4 kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk See the crash scene. Anybody knows the cause? It is strange to see the reserved exception. Jun FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de pcnet32: PCnet/FAST III 79C973 at 0x1200, 00 d0 a0 00 01 e7 assigned IRQ 10. eth0: registered as PCnet/FAST III 79C973 pcnet32: 1 cards_found. SCSI subsystem driver Revision: 1.00 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 10.0.0.75, my address is 10.0.18.6 IP-Config: Complete: device=eth0, addr=10.0.18.6, mask=255.255.0.0, gw=255.255.255.255, host=10.0.18.6, domain=, nis-domain=(none), bootserver=10.0.0.75, rootserver=10.0.0.75, rootpath=/opt/mvl-installs/mvl2 .1/hardhat/devkit/mips/fp_le/target NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 10.0.0.75 Looking up port of RPC 100005/1 on 10.0.0.75 VFS: Mounted root (nfs filesystem). Freeing prom memory: 956kb freed Freeing unused kernel memory: 84k freed Algorithmics/MIPS FPU Emulator v1.5 INIT: version 2.78 booting $0 : 00000000 80000000 80002000 00000006 00000006 0040c000 0040c000 00000001 $8 : 80000000 00000034 8004bde8 8004bbf0 8004bde8 00000080 8004baf8 00000001 $16: 00800000 800071c0 1000fc01 8004c008 0000b000 8004c008 00800000 0040b000 $24: 00000000 00000080 8004a000 8004ba78 0000000b 8011db6c Hi : ffffe4f4 Lo : 00000904 epc : 8010d528 Not tainted Status: 1020fc02 Cause : 00800060 Kernel panic: Caught reserved exception - should not happen. ==========================================================ffffffff8010d490: 92240080 lbu $a0,128($s1) ffffffff8010d494: 3c088000 lui $t0,0x8000 ffffffff8010d498: 00a41025 or $v0,$a1,$a0 ffffffff8010d49c: 40825000 mtc0 $v0,$10 ffffffff8010d4a0: 24a52000 addiu $a1,$a1,8192 ... ffffffff8010d4bc: 42000008 tlbp ... ffffffff8010d4d8: 40070000 mfc0 $a3,$0 ffffffff8010d4dc: 00000000 nop ffffffff8010d4e0: 00e01021 move $v0,$a3 ffffffff8010d4e4: 40801000 mtc0 $zero,$2 ffffffff8010d4e8: 00000000 nop ffffffff8010d4ec: 40801800 mtc0 $zero,$3 ffffffff8010d4f0: 00000000 nop ffffffff8010d4f4: 40885000 mtc0 $t0,$10 ffffffff8010d4f8: 04400013 bltz $v0,ffffffff8010d548 ffffffff8010d4fc: 00a6102b sltu $v0,$a1,$a2 ... ffffffff8010d518: 00071340 sll $v0,$a3,0xd ffffffff8010d51c: 3c018000 lui $at,0x8000 ffffffff8010d520: 00221021 addu $v0,$at,$v0 ffffffff8010d524: 40825000 mtc0 $v0,$10 ffffffff8010d528: 42000002 tlbwi ... ffffffff8010d544: 00a6102b sltu $v0,$a1,$a2 ffffffff8010d548: 1440ffd4 bnez $v0,ffffffff8010d49c ffffffff8010d54c: 00a41025 or $v0,$a1,$a0 ffffffff8010d550: 40835000 mtc0 $v1,$10 ffffffff8010d554: 08043569 j ffffffff8010d5a4 ffffffff8010d558: 00000000 nop ffffffff8010d55c: 3c108025 lui $s0,0x8025 ffffffff8010d560: 8e105910 lw $s0,22800($s0) ffffffff8010d564: 26100001 addiu $s0,$s0,1 ffffffff8010d568: 320200ff andi $v0,$s0,0xff ffffffff8010d56c: 14400005 bnez $v0,ffffffff8010d584 ffffffff8010d570: 00000000 nop From owner-linux-mips@oss.sgi.com Wed Jul 10 16:44:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ANicRw024088 for ; Wed, 10 Jul 2002 16:44:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ANicQU024087 for linux-mips-outgoing; Wed, 10 Jul 2002 16:44:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ANiaRw024078 for ; Wed, 10 Jul 2002 16:44:36 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020710234902.WFQB29588.sccrmhc01.attbi.com@ocean.lucon.org>; Wed, 10 Jul 2002 23:49:02 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1CB95125D6; Wed, 10 Jul 2002 16:49:01 -0700 (PDT) Date: Wed, 10 Jul 2002 16:49:00 -0700 From: "H. J. Lu" To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel Message-ID: <20020710164900.A28911@lucon.org> References: <3D2CBF73.50001@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D2CBF73.50001@mvista.com>; from jsun@mvista.com on Wed, Jul 10, 2002 at 04:12:51PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 10, 2002 at 04:12:51PM -0700, Jun Sun wrote: > > See the crash scene. Anybody knows the cause? It is strange to see the > reserved exception. > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 10 16:55:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ANt1Rw024271 for ; Wed, 10 Jul 2002 16:55:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ANt1Fv024270 for linux-mips-outgoing; Wed, 10 Jul 2002 16:55:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ANsqRw024259; Wed, 10 Jul 2002 16:54:53 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA24490; Wed, 10 Jul 2002 16:59:07 -0700 Message-ID: <3D2CC891.1010506@mvista.com> Date: Wed, 10 Jul 2002 16:51:45 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Cox CC: linux-mips@oss.sgi.com, Ralf Baechle , marcelo@conectiva.com.br Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alan Cox wrote: >>This patch fixes a tx underflow error for 79c973 chip. It essentially delay >>the transmission until the whole packet is received into the on-chip sdram. >> >>The patch is already accepted by Marcelo for the 2.4 tree, I think. >> > > Which slows the stuff down for people with real computers. Contrary to what it might appear at first glance, it does not really. While it delays the start of a transmission of the first packet, the delay does not aggregate in a steam of data. The bottle neck is either in upper layer (how fact upper layer generates packets) or in the link layer (when we exceed the maximum bandwitch of the wire, in which case we always have plenty of full packets to send). The delay itself is small (should be < 100us typically). So there is no impact on interactive packets. Note if the delay is not small (e.g., on system where PCI bus arbitration may be broken), then you *will* have the tx underflow problem. So on a good system the delay should be really small (especially if you compare to what it takes to transmit the whole packet to the other end). On a bad system where the delay can be long, then you will need the fix anyway. Jun > Please apply > some kind of heuristic to this - eg switch to delaying if you exceed > 50 failures in a 60 second period. > > Alan > From owner-linux-mips@oss.sgi.com Wed Jul 10 17:11:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B0BmRw025284 for ; Wed, 10 Jul 2002 17:11:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B0BmMf025282 for linux-mips-outgoing; Wed, 10 Jul 2002 17:11:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B0BfRw025233; Wed, 10 Jul 2002 17:11:41 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA25088; Wed, 10 Jul 2002 17:15:58 -0700 Message-ID: <3D2CCC83.6090304@mvista.com> Date: Wed, 10 Jul 2002 17:08:35 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Cox CC: linux-mips@oss.sgi.com, Ralf Baechle , marcelo@conectiva.com.br Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alan Cox wrote: >>This patch fixes a tx underflow error for 79c973 chip. It essentially delay >>the transmission until the whole packet is received into the on-chip sdram. >> >>The patch is already accepted by Marcelo for the 2.4 tree, I think. >> > > Which slows the stuff down for people with real computers. BTW, I have seen this problem on four boards (including Malta, two NEC boards and a Hitachi board). Not surprisingly the problem mostly happens when you connect to 100Mb/s network. I even suspect this is the default setting on PCI cards on PC. Can someone verify? If that is the case, that will explain why driver never sets this bit. Maybe we don't have any "real computers" after all. :-) Jun From owner-linux-mips@oss.sgi.com Wed Jul 10 17:11:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B0BfRw025243 for ; Wed, 10 Jul 2002 17:11:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B0Bfof025242 for linux-mips-outgoing; Wed, 10 Jul 2002 17:11:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f88.dialo.tiscali.de [62.246.16.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B0BXRw025232 for ; Wed, 10 Jul 2002 17:11:35 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6B0Fs407501; Thu, 11 Jul 2002 02:15:54 +0200 Date: Thu, 11 Jul 2002 02:15:54 +0200 From: Ralf Baechle To: Jon Burgess Cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Message-ID: <20020711021554.A3207@dea.linux-mips.net> References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <80256BF2.004ECBE6.00@notesmta.eur.3com.com>; from Jon_Burgess@eur.3com.com on Wed, Jul 10, 2002 at 03:16:21PM +0100 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 10, 2002 at 03:16:21PM +0100, Jon Burgess wrote: > This may be caused by the cache routines running from the a cached kseg0, it > looks like it can be fixed by making sure that the are always called via > KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the > setup_cache_funcs code. I have included a patch below which starts this, but I > haven't caught all combinations of how the routines are called. While that could be done it's not a good idea; running code in KSEG1 is very slow. > Alternatively it could be a CP0 pipeline interaction of the cache instruction > and mfc0 but I can't find anything detailed about it. I thought this was the > problem initially and have included a patch below which adds an extra nop. Running uncached is so slow that the pipeline will slip and stall basically every cycle which should get you around the hazard. Anyway, there's no hazard for mfc0 documented in the MIPS32 spec so this smells like a silicon bug. Which particular CPU and revision are you using? Ralf From owner-linux-mips@oss.sgi.com Wed Jul 10 18:26:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B1QHRw030096 for ; Wed, 10 Jul 2002 18:26:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B1QHMI030094 for linux-mips-outgoing; Wed, 10 Jul 2002 18:26:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B1Q6Rw030067; Wed, 10 Jul 2002 18:26:07 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by deliverator.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 SAA00424; Wed, 10 Jul 2002 18:30:37 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA26657; Wed, 10 Jul 2002 18:25:31 -0700 Message-ID: <3D2CDCD0.7040704@mvista.com> Date: Wed, 10 Jul 2002 18:18:08 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "H. J. Lu" , Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> Content-Type: multipart/mixed; boundary="------------090008060701090105000000" X-Spam-Status: No, hits=-3.7 required=5.0 tests=MAY_BE_FORGED,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------090008060701090105000000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit H. J. Lu wrote: > On Wed, Jul 10, 2002 at 04:12:51PM -0700, Jun Sun wrote: > >>See the crash scene. Anybody knows the cause? It is strange to see the >>reserved exception. >> >> > > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. > Ralf, Apparently this is a well-known problem. So *please* apply this patch or give some constructive advice if the patch cannot be applied as it is. Jun --------------090008060701090105000000 Content-Type: text/plain; name="junk" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="junk" diff -Nru arch/mips/mm/tlb-r4k.c.orig arch/mips/mm/tlb-r4k.c --- arch/mips/mm/tlb-r4k.c.orig Thu Jun 27 14:12:40 2002 +++ arch/mips/mm/tlb-r4k.c Wed Jul 10 18:06:34 2002 @@ -125,6 +125,7 @@ BARRIER; /* Make sure all entries differ. */ set_entryhi(KSEG0+idx*0x2000); + BARRIER; tlb_write_indexed(); BARRIER; } --------------090008060701090105000000-- From owner-linux-mips@oss.sgi.com Wed Jul 10 18:48:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B1m1Rw030631 for ; Wed, 10 Jul 2002 18:48:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B1m1mu030630 for linux-mips-outgoing; Wed, 10 Jul 2002 18:48:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B1lqRw030621; Wed, 10 Jul 2002 18:47:55 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17STUx-0008LR-00; Thu, 11 Jul 2002 03:16:03 +0100 Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error To: jsun@mvista.com (Jun Sun) Date: Thu, 11 Jul 2002 03:16:03 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-mips@oss.sgi.com, ralf@oss.sgi.com (Ralf Baechle), marcelo@conectiva.com.br In-Reply-To: <3D2CCC83.6090304@mvista.com> from "Jun Sun" at Jul 10, 2002 05:08:35 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I even suspect this is the default setting on PCI cards on PC. Can someone > verify? If that is the case, that will explain why driver never sets this > bit. Maybe we don't have any "real computers" after all. :-) Most PC hardware can deliver that kind of DMA guarantee. UDMA100 doesn't work very well otherwise. From owner-linux-mips@oss.sgi.com Wed Jul 10 18:53:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B1rLRw030978 for ; Wed, 10 Jul 2002 18:53:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B1rLGC030977 for linux-mips-outgoing; Wed, 10 Jul 2002 18:53:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B1r8Rw030951; Wed, 10 Jul 2002 18:53:15 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17STa3-0008M5-00; Thu, 11 Jul 2002 03:21:19 +0100 Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error To: jsun@mvista.com (Jun Sun) Date: Thu, 11 Jul 2002 03:21:19 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-mips@oss.sgi.com, ralf@oss.sgi.com (Ralf Baechle), marcelo@conectiva.com.br In-Reply-To: <3D2CC891.1010506@mvista.com> from "Jun Sun" at Jul 10, 2002 04:51:45 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Which slows the stuff down for people with real computers. > > Contrary to what it might appear at first glance, it does not really. Throughput and latency are quite different things. Try that on a latency sensitive setup like a beowulf. From owner-linux-mips@oss.sgi.com Wed Jul 10 19:31:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B2VqRw032606 for ; Wed, 10 Jul 2002 19:31:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B2Vqd4032605 for linux-mips-outgoing; Wed, 10 Jul 2002 19:31:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f88.dialo.tiscali.de [62.246.16.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B2VkRw032596 for ; Wed, 10 Jul 2002 19:31:48 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6B2a2S08906; Thu, 11 Jul 2002 04:36:02 +0200 Date: Thu, 11 Jul 2002 04:36:02 +0200 From: Ralf Baechle To: "H. J. Lu" Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel Message-ID: <20020711043601.B3207@dea.linux-mips.net> References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020710164900.A28911@lucon.org>; from hjl@lucon.org on Wed, Jul 10, 2002 at 04:49:00PM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jul 10, 2002 at 04:49:00PM -0700, H. J. Lu wrote: > > See the crash scene. Anybody knows the cause? It is strange to see the > > reserved exception. > > > > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. Jun's patch certainly is correct for some MIPS32 CPUs; others may get away without this one. Previous experience with pipeline hazards on MIPS processors has shown that at times hazards may change even between minor revisions of a CPU; documentation isn't always trustworthy about such minor details of the pipeline. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 10 20:32:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B3WrRw003055 for ; Wed, 10 Jul 2002 20:32:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B3Wr7J003054 for linux-mips-outgoing; Wed, 10 Jul 2002 20:32:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pd3mo2so.prod.shaw.ca (h24-71-223-10.cg.shawcable.net [24.71.223.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B3WlRw003044 for ; Wed, 10 Jul 2002 20:32:47 -0700 Received: from pd5mr2so.prod.shaw.ca (pd5mr2so-qfe3.prod.shaw.ca [10.0.141.233]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0GZ2001OQDPXSV@l-daemon> for linux-mips@oss.sgi.com; Wed, 10 Jul 2002 21:01:09 -0600 (MDT) Received: from pn2ml1so.prod.shaw.ca (pn2ml1so-qfe0.prod.shaw.ca [10.0.121.145]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0GZ2005AHDPYA9@l-daemon> for linux-mips@oss.sgi.com; Wed, 10 Jul 2002 21:01:10 -0600 (MDT) Received: from wakko.debian.net (h24-86-210-128.ed.shawcable.net [24.86.210.128]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0GZ200KAADPXNH@l-daemon> for linux-mips@oss.sgi.com; Wed, 10 Jul 2002 21:01:10 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=wakko.debian.net ident=jgg) by wakko.debian.net with smtp (Exim 3.16 #1 (Debian)) id 17SUCb-0005ov-00; Wed, 10 Jul 2002 21:01:09 -0600 Date: Wed, 10 Jul 2002 21:01:09 -0600 (MDT) From: Jason Gunthorpe Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error In-reply-to: <3D2CC891.1010506@mvista.com> X-Sender: jgg@wakko.debian.net To: Jun Sun Cc: Alan Cox , linux-mips@oss.sgi.com, marcelo@conectiva.com.br Reply-to: Jason Gunthorpe Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 10 Jul 2002, Jun Sun wrote: > > Which slows the stuff down for people with real computers. > > Contrary to what it might appear at first glance, it does not really. I studied this sort of a problem to some extent on my system using a 8139 card.. Eventually it turned out to be poor arbitrartion between the PCI interface and the CPU within the system controller. What happens is that the memcpy from the skbuf to the packet ring in the driver ends up generating a steady stream of very small writes that starve out PCI access. This is a particular quirk of our system controller but I wouldn't be surprised if other controllers had a simlar problem. A good fix is to use a cached+flushed tx buffer which will lower the observed DMA latency considerably. There are some situations where a badly implemented PCI controller can cause high enough latency if other devices are trying to use the bus, it depends on how much the interface can burst and where the low watermark is on the ethernet card. Most scenarios are unlikely though IMHO. If you have access to a PCI bus tracer you can determine where the problem lies pretty quickly. > The delay itself is small (should be < 100us typically). So there is no Actually it should be << 30us on an unloaded system. Measurements I've done on my box are about 13us for a 8139 to read a 1.5K pkt over PCI. Jason From owner-linux-mips@oss.sgi.com Wed Jul 10 23:15:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B6F9Rw012756 for ; Wed, 10 Jul 2002 23:15:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B6F9Ap012755 for linux-mips-outgoing; Wed, 10 Jul 2002 23:15:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B6EwRw012743; Wed, 10 Jul 2002 23:14:59 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B6JKXb010809; Wed, 10 Jul 2002 23:19:20 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA29604; Wed, 10 Jul 2002 23:19:19 -0700 (PDT) Message-ID: <005c01c228a2$fb2bf450$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" , "H. J. Lu" Cc: "Jun Sun" , References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> <20020711043601.B3207@dea.linux-mips.net> Subject: Re: Malta crashes on the latest 2.4 kernel Date: Thu, 11 Jul 2002 08:19:55 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.7 required=5.0 tests=PORN_12,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Wed, Jul 10, 2002 at 04:49:00PM -0700, H. J. Lu wrote: > > > > See the crash scene. Anybody knows the cause? It is strange to see the > > > reserved exception. > > > > > > > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. > > Jun's patch certainly is correct for some MIPS32 CPUs; others may get > away without this one. Previous experience with pipeline hazards on MIPS > processors has shown that at times hazards may change even between minor > revisions of a CPU; documentation isn't always trustworthy about such > minor details of the pipeline. Excuse me, but I've seen this statement used by others in the past as an excuse for doing something silly or not doing something reasonable, and it generally hasn't washed. In what specific cases have the CP0 pipeline hazards changed between minor revisions of any production MIPS CPU? The *documentation* may have been corrected, but these hazards are fairly fundamental artifacts of the pipeline microarchitecture of a given processor. The CP0 hazard between a write of EntryHi and a subsequent TLBWI instruction is flagged in the MIPS32 spec and noted as being "typically" 2 cycles. I'm not going to spend the time going through my full set of users manuals, but a representative sampling shows this hazard as being specified for every R4xxx and R5xxx CPU I checked. The fact that a given CPU *may* get away with it is no excuse for not protecting common code. I note that Ralf has, in fact, applied the fix to the OSS CVS repository. I also note that "BARRIER" is still defined to be a string of 6 nops. I would argue (again) that those really, really ought to be ssnops, and that if they *were* ssnops, one could probably have fewer of them. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Jul 10 23:23:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B6N1Rw015018 for ; Wed, 10 Jul 2002 23:23:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B6N15w015017 for linux-mips-outgoing; Wed, 10 Jul 2002 23:23:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B6MrRw015008; Wed, 10 Jul 2002 23:22:54 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id IAA07996; Thu, 11 Jul 2002 08:26:18 +0200 (MET DST) Date: Thu, 11 Jul 2002 08:26:18 +0200 (MEST) From: Geert Uytterhoeven To: Peter De Schrijver cc: Wim Peeters , lionel@sonycom.com, thomasv@sonycom.com, Nico De Ranter , tea@sonycom.com, joel@sonycom.com, Tom Michiels , Gorik De Samblanx , Peter De Schrijver , Ralf Baechle , Linux/MIPS Development Subject: Re: Patch for DDB5074 support In-Reply-To: <20020710234935.A31932@ace.ulyssis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 10 Jul 2002, Peter De Schrijver wrote: > This patch should be the right one for ddb-5074. I think you need a few more s/547./5074/. 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 Wed Jul 10 23:52:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B6q7Rw015425 for ; Wed, 10 Jul 2002 23:52:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B6q7aR015424 for linux-mips-outgoing; Wed, 10 Jul 2002 23:52:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B6pxRw015415; Wed, 10 Jul 2002 23:52:00 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id IAA09556; Thu, 11 Jul 2002 08:56:18 +0200 (MET DST) Date: Thu, 11 Jul 2002 08:56:17 +0200 (MEST) From: Geert Uytterhoeven To: "Kevin D. Kissell" cc: Ralf Baechle , "H. J. Lu" , Jun Sun , Linux/MIPS Development Subject: Re: Malta crashes on the latest 2.4 kernel In-Reply-To: <005c01c228a2$fb2bf450$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > I note that Ralf has, in fact, applied the fix to the > OSS CVS repository. I also note that "BARRIER" > is still defined to be a string of 6 nops. I would argue > (again) that those really, really ought to be ssnops, > and that if they *were* ssnops, one could probably > have fewer of them. Sorry for being ignorant, but what's the difference between nop and ssnop? I see that SSNOP is defined to be `sll zero,zero,1' in , but that doesn't give me any clue. 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 Thu Jul 11 00:30:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B7UsRw015855 for ; Thu, 11 Jul 2002 00:30:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B7UsGN015854 for linux-mips-outgoing; Thu, 11 Jul 2002 00:30:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B7UHRw015844 for ; Thu, 11 Jul 2002 00:30:17 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B7YUXb010999; Thu, 11 Jul 2002 00:34:34 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA01957; Thu, 11 Jul 2002 00:34:29 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6B7YTb16347; Thu, 11 Jul 2002 09:34:29 +0200 (MEST) Message-ID: <3D2D3504.164F4988@mips.com> Date: Thu, 11 Jul 2002 09:34:28 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jon Burgess CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This sound more like a hardware bug to me. What CPU are you running on ? /Carsten Jon Burgess wrote: > Symptom: > ==== > The linux mips 2.4.17 kernel compiled with gcc-2.96-110 (from H.J.Lu) hangs > before reaching the 'Calibrating delay loop'. When the same kernel is compiled > with gcc-3.0.4 or egcs-1.1.2 it works OK. I have included what I think is the > cause, some patches to test the theory and some possible fixes. > > Cause: > ==== > I tracked the problem back to the CP0_STATUS being corrupted by the > mips32_flush_cache_all_pc routine, leading to a lockup once interrupts are > enabled. Looking at a disassembly of the code suggests the broken code changes > the value of the AT register while the working code leaves it alone. The > compiler is allowed to do this, but it exposes the real problem which appears to > be a problem between the 'cache' instruction of blast_icache() and the 'mfc0' of > the __restore_flags(). The 'mfc0 at, $12' seems to be ignored. This isn't a > problem with the gcc-3.0.4 code since AT still contains the value of CP0_STATUS > from the __save_and_cli at the start of the routine. > > This may be caused by the cache routines running from the a cached kseg0, it > looks like it can be fixed by making sure that the are always called via > KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the > setup_cache_funcs code. I have included a patch below which starts this, but I > haven't caught all combinations of how the routines are called. > > Alternatively it could be a CP0 pipeline interaction of the cache instruction > and mfc0 but I can't find anything detailed about it. I thought this was the > problem initially and have included a patch below which adds an extra nop. > > I believe the root of the problem is that the routines are running in kseg0, but > If anyone has any other ideas as to what could causing the problem then i'd be > glad to know. > > You can test this by inserting some extra code to change AT between the save & > restore and see if it causes a problem (see included patches below) > > Current source: > static inline void mips32_flush_cache_all_pc(void) > { > unsigned long flags; > > __save_and_cli(flags); > blast_dcache(); blast_icache(); > __restore_flags(flags); > } > > Disassembly of mips32_flush_cache_all_pc() for broken code gcc-2.96: > 00000c30 : > c30: 40066000 mfc0 a2,$12 > c34: 00000000 nop > c38: 34c10001 ori at,a2,0x1 > c3c: 38210001 xori at,at,0x1 > c40: 40816000 mtc0 at,$12 > c44: 00000040 ssnop > c48: 00000040 ssnop > c4c: 00000040 ssnop > c50: 3c030000 lui v1,0x0 > c54: 8c630000 lw v1,0(v1) > c58: 3c048000 lui a0,0x8000 > c5c: 3c018000 lui at,0x8000 > *** See here how the compiler has changed AT here > c60: 00231821 addu v1,at,v1 > c64: 0083102b sltu v0,a0,v1 > c68: 10400008 beqz v0,c8c > c6c: 00000000 nop > c70: 3c050000 lui a1,0x0 > c74: 8ca50000 lw a1,0(a1) > c78: bc810000 cache 0x1,0(a0) > c7c: 00852021 addu a0,a0,a1 > c80: 0083102b sltu v0,a0,v1 > c84: 1440fffc bnez v0,c78 > c88: 00000000 nop > c8c: 3c030000 lui v1,0x0 > c90: 8c630000 lw v1,0(v1) > c94: 3c048000 lui a0,0x8000 > c98: 3c018000 lui at,0x8000 > c9c: 00231821 addu v1,at,v1 > ca0: 0083102b sltu v0,a0,v1 > ca4: 10400008 beqz v0,cc8 > ca8: 00000000 nop > cac: 3c050000 lui a1,0x0 > cb0: 8ca50000 lw a1,0(a1) > cb4: bc800000 cache 0x0,0(a0) > cb8: 00852021 addu a0,a0,a1 > cbc: 0083102b sltu v0,a0,v1 > cc0: 1440fffc bnez v0,cb4 > cc4: 00000000 nop > cc8: 40016000 mfc0 at,$12 > *** The instruction above is the one which seems to be skipped. > ccc: 30c60001 andi a2,a2,0x1 > cd0: 34210001 ori at,at,0x1 > cd4: 38210001 xori at,at,0x1 > cd8: 00c13025 or a2,a2,at > cdc: 40866000 mtc0 a2,$12 > ... > cec: 03e00008 jr ra > cf0: 00000000 nop > > Patches to demonstrate the problem: > ==== > Here is a patch to change AT in the cache_flush routine to show that this > corrupts the CP0_STATUS value (for a mips32 processor with no secondary cache). > When this is applied in conjunction with the patch above you should see the > CP0_STATUS being corrupted and the kernel will probably hang. I have > demonstrated that this change is enough to break a working kernel/compiler > combination. > > --- linux/arch/mips/mm/c-mips32.c-orig Wed Jul 10 14:12:09 2002 > +++ linux/arch/mips/mm/c-mips32.c Wed Jul 10 14:18:17 2002 > @@ -74,7 +74,9 @@ > unsigned long flags; > > __save_and_cli(flags); > - blast_dcache(); blast_icache(); > + blast_dcache(); > + __asm__("lui\t$at, 0x8000\n\t"); > + blast_icache(); > __restore_flags(flags); > } > > Here is the patch that I used to catch the problem when CP0_STATUS is being > corrupted by the cache flush routine. The CP0_STATUS should not be changed by > the call to the cache flush routine. > > --- linux/arch/mips/kernel/traps.c Thu May 23 15:19:35 2002 > +++ ../traps.c Wed Jul 10 13:46:54 2002 > @@ -889,7 +889,10 @@ > memcpy((void *)(KSEG0 + 0x80), &except_vec1_generic, 0x80); > memcpy((void *)(KSEG0 + 0x100), &except_vec2_generic, 0x80); > memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, 0x80); > + > + printk("CP0_STATUS before flush = 0x%x\n", > read_32bit_cp0_register(CP0_STATUS)); > flush_icache_range(KSEG0 + 0x80, KSEG0 + 0x200); > + printk("CP0_STATUS after flush = 0x%x\n", > read_32bit_cp0_register(CP0_STATUS)); > /* > * Setup default vectors > */ > > Fix (to call cache routines via uncached Kseg1) > ==== > Assuming the root of the problem is that the cache flush routines are running > from cached kseg0. This patch needs a bit more work to make sure that all the > other routines are called similarly. > > --- linux/arch/mips/mm/c-mips32.c-orig Wed Jul 10 14:12:09 2002 > +++ linux/arch/mips/mm/c-mips32.c Wed Jul 10 14:45:03 2002 > @@ -606,8 +608,13 @@ > { > _clear_page = (void *)mips32_clear_page_dc; > _copy_page = (void *)mips32_copy_page_dc; > +#if 1 > + _flush_cache_all = (void (*)(u32,u32)) KSEG1ADDR((unsigned > long)mips32_flush_cache_all_pc); > + ___flush_cache_all = (void (*)(u32,u32)) KSEG1ADDR((unsigned > long)mips32_flush_cache_all_pc); > +#else > _flush_cache_all = mips32_flush_cache_all_pc; > ___flush_cache_all = mips32_flush_cache_all_pc; > +#endif > _flush_cache_mm = mips32_flush_cache_mm_pc; > _flush_cache_range = mips32_flush_cache_range_pc; > _flush_cache_page = mips32_flush_cache_page_pc; > > Fix (If the root of the problem is a pipeline hazard) > ==== > The patch below fix is to insert an extra 'nop' at the end of the various > blast_[id]cache routines to clear the hazard condition before the code returns. > The 'sc' routines may need a similar fix. A different workaround places a 'nop' > at the start of the __restore_flags routine, but I believe it is better to fix > the problem at the source of the hazard. > > --- linux/include/asm-mips/mips32_cache.h Wed Apr 10 22:53:12 2002 > +++ ../mips32_cache.h Wed Jul 10 13:10:40 2002 > @@ -189,73 +189,85 @@ > static inline void blast_dcache(void) > { > unsigned long start = KSEG0; > unsigned long end = (start + dcache_size); > > while(start < end) { > cache_unroll(start,Index_Writeback_Inv_D); > start += dc_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_dcache_page(unsigned long page) > { > unsigned long start = page; > unsigned long end = (start + PAGE_SIZE); > > while(start < end) { > cache_unroll(start,Hit_Writeback_Inv_D); > start += dc_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_dcache_page_indexed(unsigned long page) > { > unsigned long start = page; > unsigned long end = (start + PAGE_SIZE); > > while(start < end) { > cache_unroll(start,Index_Writeback_Inv_D); > start += dc_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_icache(void) > { > unsigned long start = KSEG0; > unsigned long end = (start + icache_size); > > while(start < end) { > cache_unroll(start,Index_Invalidate_I); > start += ic_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_icache_page(unsigned long page) > { > unsigned long start = page; > unsigned long end = (start + PAGE_SIZE); > > while(start < end) { > cache_unroll(start,Hit_Invalidate_I); > start += ic_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_icache_page_indexed(unsigned long page) > { > unsigned long start = page; > unsigned long end = (start + PAGE_SIZE); > > while(start < end) { > cache_unroll(start,Index_Invalidate_I); > start += ic_lsize; > } > + /* Prevent hazard with following mfc0 */ > + __asm__("nop\n\t"); > } > > static inline void blast_scache(void) > { > unsigned long start = KSEG0; > unsigned long end = KSEG0 + scache_size; > > while(start < end) { > cache_unroll(start,Index_Writeback_Inv_SD); > > Jon Burgess -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 00:40:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B7eoRw016001 for ; Thu, 11 Jul 2002 00:40:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B7eogf016000 for linux-mips-outgoing; Thu, 11 Jul 2002 00:40:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B7eXRw015988 for ; Thu, 11 Jul 2002 00:40:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B7ioXb011031; Thu, 11 Jul 2002 00:44:50 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02274; Thu, 11 Jul 2002 00:44:52 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6B7iqb16776; Thu, 11 Jul 2002 09:44:53 +0200 (MEST) Message-ID: <3D2D3774.2DECC6FE@mips.com> Date: Thu, 11 Jul 2002 09:44:52 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel References: <3D2CBF73.50001@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sounds like a problem I so a couple of months ago, I thought the fix was already in the CVS. Here is my previous mail: There seems to be a hazard problem in the local_flush_tlb_range function in tlb-r4k.c, which the patch below will fix. It could hit anyone, but it probably only a problem on CPUs, which doesn't allow matching entries in the TLB. /Carsten Index: arch/mips/mm/tlb-r4k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/tlb-r4k.c,v retrieving revision 1.6.2.3 diff -u -r1.6.2.3 tlb-r4k.c --- arch/mips/mm/tlb-r4k.c 2002/01/18 03:16:24 1.6.2.3 +++ arch/mips/mm/tlb-r4k.c 2002/05/17 11:36:58 @@ -119,12 +119,11 @@ idx = get_index(); set_entrylo0(0); set_entrylo1(0); - set_entryhi(KSEG0); if (idx < 0) continue; - BARRIER; /* Make sure all entries differ. */ set_entryhi(KSEG0+idx*0x2000); + BARRIER; tlb_write_indexed(); BARRIER; } Jun Sun wrote: > See the crash scene. Anybody knows the cause? It is strange to see the > reserved exception. > > Jun > > FDC 0 is a post-1991 82077 > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de > pcnet32: PCnet/FAST III 79C973 at 0x1200, 00 d0 a0 00 01 e7 assigned IRQ 10. > eth0: registered as PCnet/FAST III 79C973 > pcnet32: 1 cards_found. > SCSI subsystem driver Revision: 1.00 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 4096 bind 4096) > Sending BOOTP requests . OK > IP-Config: Got BOOTP answer from 10.0.0.75, my address is 10.0.18.6 > IP-Config: Complete: > device=eth0, addr=10.0.18.6, mask=255.255.0.0, gw=255.255.255.255, > host=10.0.18.6, domain=, nis-domain=(none), > bootserver=10.0.0.75, rootserver=10.0.0.75, rootpath=/opt/mvl-installs/mvl2 > .1/hardhat/devkit/mips/fp_le/target > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Looking up port of RPC 100003/2 on 10.0.0.75 > Looking up port of RPC 100005/1 on 10.0.0.75 > VFS: Mounted root (nfs filesystem). > Freeing prom memory: 956kb freed > Freeing unused kernel memory: 84k freed > Algorithmics/MIPS FPU Emulator v1.5 > INIT: version 2.78 booting > $0 : 00000000 80000000 80002000 00000006 00000006 0040c000 0040c000 00000001 > $8 : 80000000 00000034 8004bde8 8004bbf0 8004bde8 00000080 8004baf8 00000001 > $16: 00800000 800071c0 1000fc01 8004c008 0000b000 8004c008 00800000 0040b000 > $24: 00000000 00000080 8004a000 8004ba78 0000000b 8011db6c > Hi : ffffe4f4 > Lo : 00000904 > epc : 8010d528 Not tainted > Status: 1020fc02 > Cause : 00800060 > Kernel panic: Caught reserved exception - should not happen. > > ==========================================================ffffffff8010d490: > 92240080 lbu $a0,128($s1) > ffffffff8010d494: 3c088000 lui $t0,0x8000 > ffffffff8010d498: 00a41025 or $v0,$a1,$a0 > ffffffff8010d49c: 40825000 mtc0 $v0,$10 > ffffffff8010d4a0: 24a52000 addiu $a1,$a1,8192 > ... > ffffffff8010d4bc: 42000008 tlbp > ... > ffffffff8010d4d8: 40070000 mfc0 $a3,$0 > ffffffff8010d4dc: 00000000 nop > ffffffff8010d4e0: 00e01021 move $v0,$a3 > ffffffff8010d4e4: 40801000 mtc0 $zero,$2 > ffffffff8010d4e8: 00000000 nop > ffffffff8010d4ec: 40801800 mtc0 $zero,$3 > ffffffff8010d4f0: 00000000 nop > ffffffff8010d4f4: 40885000 mtc0 $t0,$10 > ffffffff8010d4f8: 04400013 bltz $v0,ffffffff8010d548 h_tlb_range+0x150> > ffffffff8010d4fc: 00a6102b sltu $v0,$a1,$a2 > ... > ffffffff8010d518: 00071340 sll $v0,$a3,0xd > ffffffff8010d51c: 3c018000 lui $at,0x8000 > ffffffff8010d520: 00221021 addu $v0,$at,$v0 > ffffffff8010d524: 40825000 mtc0 $v0,$10 > ffffffff8010d528: 42000002 tlbwi > ... > ffffffff8010d544: 00a6102b sltu $v0,$a1,$a2 > ffffffff8010d548: 1440ffd4 bnez $v0,ffffffff8010d49c h_tlb_range+0xa4> > ffffffff8010d54c: 00a41025 or $v0,$a1,$a0 > ffffffff8010d550: 40835000 mtc0 $v1,$10 > ffffffff8010d554: 08043569 j ffffffff8010d5a4 b_range+0x1ac> > ffffffff8010d558: 00000000 nop > ffffffff8010d55c: 3c108025 lui $s0,0x8025 > ffffffff8010d560: 8e105910 lw $s0,22800($s0) > ffffffff8010d564: 26100001 addiu $s0,$s0,1 > ffffffff8010d568: 320200ff andi $v0,$s0,0xff > ffffffff8010d56c: 14400005 bnez $v0,ffffffff8010d584 h_tlb_range+0x18c> > ffffffff8010d570: 00000000 nop -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 00:46:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B7k9Rw016199 for ; Thu, 11 Jul 2002 00:46:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B7k9IC016198 for linux-mips-outgoing; Thu, 11 Jul 2002 00:46:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B7k0Rw016189; Thu, 11 Jul 2002 00:46:01 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B7oLXb011040; Thu, 11 Jul 2002 00:50:21 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02436; Thu, 11 Jul 2002 00:50:23 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6B7oNb17092; Thu, 11 Jul 2002 09:50:23 +0200 (MEST) Message-ID: <3D2D38BE.F1C6AC73@mips.com> Date: Thu, 11 Jul 2002 09:50:22 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "H. J. Lu" , Jun Sun , linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> <20020711043601.B3207@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Wed, Jul 10, 2002 at 04:49:00PM -0700, H. J. Lu wrote: > > > > See the crash scene. Anybody knows the cause? It is strange to see the > > > reserved exception. > > > > > > > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. > > Jun's patch certainly is correct for some MIPS32 CPUs; others may get > away without this one. Previous experience with pipeline hazards on MIPS > processors has shown that at times hazards may change even between minor > revisions of a CPU; documentation isn't always trustworthy about such > minor details of the pipeline. I actually discovered the hazard problem on a 4Kc, based on some older RTL, but the hazard some how disappear on a newer revision. So you are absolutely right. > > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 01:08:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B88VRw016464 for ; Thu, 11 Jul 2002 01:08:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B88VaM016463 for linux-mips-outgoing; Thu, 11 Jul 2002 01:08:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from elvis.franken.de (mail@dns.franken.de [193.175.24.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B88NRw016454; Thu, 11 Jul 2002 01:08:24 -0700 Received: from tsbogend by elvis.franken.de with local (Exim 3.22 #1) id 17SZ47-0003wd-00; Thu, 11 Jul 2002 10:12:43 +0200 Date: Thu, 11 Jul 2002 10:12:43 +0200 From: Thomas Bogendoerfer To: Alan Cox Cc: Jun Sun , linux-mips@oss.sgi.com, Ralf Baechle , marcelo@conectiva.com.br Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error Message-ID: <20020711081243.GA14912@elvis.franken.de> Reply-To: tsbogend@alpha.franken.de References: <3D2CCC83.6090304@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 03:16:03AM +0100, Alan Cox wrote: > > I even suspect this is the default setting on PCI cards on PC. Can someone > > verify? If that is the case, that will explain why driver never sets this > > bit. Maybe we don't have any "real computers" after all. :-) > > Most PC hardware can deliver that kind of DMA guarantee. UDMA100 doesn't > work very well otherwise. I've seen this problem on a lot of PC hardware, too. The best fix would be to enable full packet mode, when the driver sees too much TX underruns. Thomas. From owner-linux-mips@oss.sgi.com Thu Jul 11 01:30:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B8UbRw016608 for ; Thu, 11 Jul 2002 01:30:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B8Ubp0016607 for linux-mips-outgoing; Thu, 11 Jul 2002 01:30:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B8UVRw016597 for ; Thu, 11 Jul 2002 01:30:31 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B8YoXb011163; Thu, 11 Jul 2002 01:34:50 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA03975; Thu, 11 Jul 2002 01:34:49 -0700 (PDT) Message-ID: <009001c228b5$e87e0600$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Geert Uytterhoeven" Cc: "Linux/MIPS Development" References: Subject: Re: Malta crashes on the latest 2.4 kernel Date: Thu, 11 Jul 2002 10:35:12 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > > I note that Ralf has, in fact, applied the fix to the > > OSS CVS repository. I also note that "BARRIER" > > is still defined to be a string of 6 nops. I would argue > > (again) that those really, really ought to be ssnops, > > and that if they *were* ssnops, one could probably > > have fewer of them. > > Sorry for being ignorant, but what's the difference between nop and ssnop? > > I see that SSNOP is defined to be `sll zero,zero,1' in , but that > doesn't give me any clue. SSNOPs are "super-scalar NOPs", which were first invented (but not documented at the time) for the R8000, which was the first superscalar MIPS implementation. They wanted to be able to absorb the standard "overhead" NOPS associated with unfilled branch delay slots, etc, in the dual-issue mechanism, but still have some means to handle CP0 hazards such that it could be assured to force a 1 cycle stall per instruction. While it wasn't officially a part of the architecture until the late 1990's, the convention was carried forward by the R5xxx and R1xxxx families. There have been rumours of superscalar MIPS processors that do not enforce single-issue on SSNOPs, but I don't know of any offhand, and the MIPS32/MIPS64 specs formalize the definition. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Jul 11 01:43:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B8hcRw016748 for ; Thu, 11 Jul 2002 01:43:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B8hc8n016747 for linux-mips-outgoing; Thu, 11 Jul 2002 01:43:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B8hSRw016737; Thu, 11 Jul 2002 01:43:29 -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 MAA03223; Thu, 11 Jul 2002 12:47:49 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA24622; Thu, 11 Jul 2002 12:47:04 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA13258; Thu, 11 Jul 2002 12:44:23 +0400 (MSK) Message-ID: <3D2D465C.FA06D50A@niisi.msk.ru> Date: Thu, 11 Jul 2002 12:48:28 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ralf Baechle CC: Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Wed, Jul 10, 2002 at 03:16:21PM +0100, Jon Burgess wrote: > > > This may be caused by the cache routines running from the a cached kseg0, it > > looks like it can be fixed by making sure that the are always called via > > KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the > > setup_cache_funcs code. I have included a patch below which starts this, but I > > haven't caught all combinations of how the routines are called. > > While that could be done it's not a good idea; running code in KSEG1 is > very slow. > Unfortunately, it's required by manuals for some processors. As I know, IDT HW manuals clearly state cache flush routines must operate from uncached code and must access uncached data only. Examples are R30x1 CPU series. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Jul 11 02:03:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B93bRw022477 for ; Thu, 11 Jul 2002 02:03:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B93bsU022476 for linux-mips-outgoing; Thu, 11 Jul 2002 02:03:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B93VRw022465 for ; Thu, 11 Jul 2002 02:03:31 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B97vXb011255 for ; Thu, 11 Jul 2002 02:07:57 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA05099 for ; Thu, 11 Jul 2002 02:07:56 -0700 (PDT) Message-ID: <00b401c228ba$88b29bf0$10eca8c0@grendel> From: "Kevin D. Kissell" To: Subject: Sigcontext->sc_pc Passed to User Date: Thu, 11 Jul 2002 11:08:21 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk In responding to an enquiry from one of MIPS' third-party software vendors, I noted something that seems a little broken to me in the current (and maybe all historical) MIPS/Linux kernels. Please forgive me for opening old wounds if this has been beaten to death in the past. When a user catches a signal, such as SIGBUS, the signal "payload" includes a pointer to a sigcontext structure on the stack, containing the state of the CPU when the exception associated with the signal occurred. But not exactly. We seem to consistently call compute_return_epc() before send_sig() or force_sig(). This results in the user being passed an indication of the faulting PC that is one instruction past the true location. That would be no problem, except that the faulting instruction may have been in a branch delay slot, such that there is no practical and reliable way for the signal handler to determine which instruction failed on the basis of the sigcontext data. It is, of course, important that execution resume at the instruction following any instruction generating an exception/signal. But that's not the same thing as saying that the sigcontext should report the resumption EPC instead of the faulting EPC. There are various ways of dealing with this, but before going into any of them, I'm curious as to whether this has been discussed before, and whether anyone thinks that things really should be the way they are. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Jul 11 02:15:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B9FWRw022631 for ; Thu, 11 Jul 2002 02:15:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B9FWeA022630 for linux-mips-outgoing; Thu, 11 Jul 2002 02:15:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B9FNRw022621; Thu, 11 Jul 2002 02:15:23 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6B9J2Xb011289; Thu, 11 Jul 2002 02:19:02 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA05438; Thu, 11 Jul 2002 02:19:00 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6B9J0b24488; Thu, 11 Jul 2002 11:19:00 +0200 (MEST) Message-ID: <3D2D4D83.B2694DF1@mips.com> Date: Thu, 11 Jul 2002 11:18:59 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Gleb O. Raiko" wrote: > Ralf Baechle wrote: > > > > On Wed, Jul 10, 2002 at 03:16:21PM +0100, Jon Burgess wrote: > > > > > This may be caused by the cache routines running from the a cached kseg0, it > > > looks like it can be fixed by making sure that the are always called via > > > KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the > > > setup_cache_funcs code. I have included a patch below which starts this, but I > > > haven't caught all combinations of how the routines are called. > > > > While that could be done it's not a good idea; running code in KSEG1 is > > very slow. > > > > Unfortunately, it's required by manuals for some processors. As I know, > IDT HW manuals clearly state cache flush routines must operate from > uncached code and must access uncached data only. Examples are R30x1 CPU > series. Yes, that's true. But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache routines. > > Regards, > Gleb. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 02:46:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6B9kDRw023086 for ; Thu, 11 Jul 2002 02:46:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6B9kDgG023085 for linux-mips-outgoing; Thu, 11 Jul 2002 02:46:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6B9jpRw023075; Thu, 11 Jul 2002 02:45:52 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6B9ptE06829; Thu, 11 Jul 2002 10:51:55 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6B9ohR25066; Thu, 11 Jul 2002 10:50:43 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF3.003669E3 ; Thu, 11 Jul 2002 10:54:20 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@oss.sgi.com, carstenl@mips.com Message-ID: <80256BF3.00366849.00@notesmta.eur.3com.com> Date: Thu, 11 Jul 2002 10:49:55 +0100 Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >This sound more like a hardware bug to me. >What CPU are you running on ? > >/Carsten The CPU is a Broadcom BCM6352 which contains a 225Mhz Mips32 core with cache as follows: 16Kb Instruction cache, linesize 16 bytes (2 ways) 4Kb Data cache, linesize 16 byes (2 ways) I don't know the exact variant of the core but the chip has only been recently released. I will try asking my Broadcom contacts to see if they can shed any further light on this. >Ralf Baechle wrote: >> >> While that could be done it's not a good idea; running code in KSEG1 is >> very slow. >> > >Unfortunately, it's required by manuals for some processors. As I know, >IDT HW manuals clearly state cache flush routines must operate from >uncached code and must access uncached data only. Examples are R30x1 CPU >series. > >Regards, >Gleb. I'm fairly sure i've seen comments that say that cache manipulation code should be run uncached. My current thought is that it is probably safe to manipulate the d-cache with cached code, but I-cache manipulation which could invalidate the cacheline containing the currently executing code really should be run uncached. I think the CPU probably then skips instructions until it gets to the next cacheline, what effect this has depends on how the instructions are aligned relative to the cacheline. Given how hit-and-miss this is I am suspicous that this problem could simply be lurking undiscovered. The patch below makes the I-Cache routines run via kseg1, it is a bit ugly but seems to work. I have not measured the performance impact of this patch. diff -Nruw --exclude=CVS include/asm-mips-old/mips32_cache.h include/asm-mips/mips32_cache.h --- include/asm-mips-old/mips32_cache.h Wed Apr 10 22:53:12 2002 +++ include/asm-mips/mips32_cache.h Thu Jul 11 10:25:06 2002 @@ -219,37 +219,24 @@ } } +/* Call I-cache manipulation routines via uncached kseg1 */ +extern void mips32_blast_icache(void); +extern void mips32_blast_icache_page(unsigned long page); +extern void mips32_blast_icache_page_indexed(unsigned long page); + static inline void blast_icache(void) { - unsigned long start = KSEG0; - unsigned long end = (start + icache_size); - - while(start < end) { - cache_unroll(start,Index_Invalidate_I); - start += ic_lsize; - } + ((void (*)(void))KSEG1ADDR((unsigned long)mips32_blast_icache))(); } static inline void blast_icache_page(unsigned long page) { - unsigned long start = page; - unsigned long end = (start + PAGE_SIZE); - - while(start < end) { - cache_unroll(start,Hit_Invalidate_I); - start += ic_lsize; - } + ((void (*)(unsigned long))KSEG1ADDR((unsigned long)mips32_blast_icache_page))(page); } static inline void blast_icache_page_indexed(unsigned long page) { - unsigned long start = page; - unsigned long end = (start + PAGE_SIZE); - - while(start < end) { - cache_unroll(start,Index_Invalidate_I); - start += ic_lsize; - } + ((void (*)(unsigned long))KSEG1ADDR((unsigned long)mips32_blast_icache_page_indexed))(page); } static inline void blast_scache(void) diff -Nurw arch/mips/mm-old/c-mips32.c arch/mips/mm/c-mips32.c --- arch/mips/mm-old/c-mips32.c Thu May 23 15:19:36 2002 +++ arch/mips/mm/c-mips32.c Thu Jul 11 10:21:02 2002 @@ -708,3 +708,36 @@ __flush_cache_all(); } + +void mips32_blast_icache(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + icache_size); + + while(start < end) { + cache_unroll(start,Index_Invalidate_I); + start += ic_lsize; + } +} + +void mips32_blast_icache_page(unsigned long page) +{ + unsigned long start = page; + unsigned long end = (start + PAGE_SIZE); + + while(start < end) { + cache_unroll(start,Hit_Invalidate_I); + start += ic_lsize; + } +} + +void mips32_blast_icache_page_indexed(unsigned long page) +{ + unsigned long start = page; + unsigned long end = (start + PAGE_SIZE); + + while(start < end) { + cache_unroll(start,Index_Invalidate_I); + start += ic_lsize; + } +} Jon Burgess From owner-linux-mips@oss.sgi.com Thu Jul 11 03:03:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BA3lRw023515 for ; Thu, 11 Jul 2002 03:03:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BA3lMh023514 for linux-mips-outgoing; Thu, 11 Jul 2002 03:03:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BA3cRw023505; Thu, 11 Jul 2002 03:03:39 -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 OAA04093; Thu, 11 Jul 2002 14:07:49 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA25059; Thu, 11 Jul 2002 14:05:44 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA16131; Thu, 11 Jul 2002 14:02:41 +0400 (MSK) Message-ID: <3D2D58A6.2E5D9695@niisi.msk.ru> Date: Thu, 11 Jul 2002 14:06:30 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Carsten Langgaard CC: Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Carsten Langgaard wrote: > > Unfortunately, it's required by manuals for some processors. As I know, > > IDT HW manuals clearly state cache flush routines must operate from > > uncached code and must access uncached data only. Examples are R30x1 CPU > > series. > > Yes, that's true. > But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache > routines. I don't wonder if other IDT CPUs also require this, including those that conform MIPS32. Basically, requirement of uncached run makes hadrware logic much simpler and allows to save silicon a bit. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Jul 11 03:12:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BACFRw023686 for ; Thu, 11 Jul 2002 03:12:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BACFd9023685 for linux-mips-outgoing; Thu, 11 Jul 2002 03:12:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BAC7Rw023676; Thu, 11 Jul 2002 03:12:07 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6BAFmXb011430; Thu, 11 Jul 2002 03:15:48 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA07218; Thu, 11 Jul 2002 03:15:47 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6BAFlb28861; Thu, 11 Jul 2002 12:15:47 +0200 (MEST) Message-ID: <3D2D5AD2.1B254721@mips.com> Date: Thu, 11 Jul 2002 12:15:46 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> <3D2D58A6.2E5D9695@niisi.msk.ru> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Gleb O. Raiko" wrote: > Carsten Langgaard wrote: > > > Unfortunately, it's required by manuals for some processors. As I know, > > > IDT HW manuals clearly state cache flush routines must operate from > > > uncached code and must access uncached data only. Examples are R30x1 CPU > > > series. > > > > Yes, that's true. > > But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache > > routines. > > I don't wonder if other IDT CPUs also require this, including those that > conform MIPS32. > Basically, requirement of uncached run makes hadrware logic much simpler > and allows to save silicon a bit. That could be true, but then again I suggest making specific cache routines for those CPUs. It would be a real performance hit for the rest of us, if we have to operate from uncached space. > > Regards, > Gleb. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 03:33:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BAXdRw024047 for ; Thu, 11 Jul 2002 03:33:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BAXduA024046 for linux-mips-outgoing; Thu, 11 Jul 2002 03:33:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BAXQRw024037; Thu, 11 Jul 2002 03:33:30 -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 OAA04443; Thu, 11 Jul 2002 14:37:48 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA25198; Thu, 11 Jul 2002 14:34:28 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA17554; Thu, 11 Jul 2002 14:32:49 +0400 (MSK) Message-ID: <3D2D5FA5.5D964B68@niisi.msk.ru> Date: Thu, 11 Jul 2002 14:36:21 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Carsten Langgaard CC: Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> <3D2D58A6.2E5D9695@niisi.msk.ru> <3D2D5AD2.1B254721@mips.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Carsten Langgaard wrote: > > "Gleb O. Raiko" wrote: > > Basically, requirement of uncached run makes hadrware logic much simpler > > and allows to save silicon a bit. > > That could be true, but then again I suggest making specific cache routines for those > CPUs. > It would be a real performance hit for the rest of us, if we have to operate from > uncached space. > In theory, yes, there is a performance penalty. In practice, I doubt this penalty is significant. Sure, Linux likes to flush cahces, not to say more. But, did somebody measure the penalty of uncached runs? Even with microbencnmarks like lmbench. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Jul 11 03:43:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BAhERw024371 for ; Thu, 11 Jul 2002 03:43:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BAhEC6024370 for linux-mips-outgoing; Thu, 11 Jul 2002 03:43:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BAh2Rw024361; Thu, 11 Jul 2002 03:43:02 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6BAkdXb011496; Thu, 11 Jul 2002 03:46:39 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA08157; Thu, 11 Jul 2002 03:46:38 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6BAkcb01181; Thu, 11 Jul 2002 12:46:38 +0200 (MEST) Message-ID: <3D2D620D.95E1BF30@mips.com> Date: Thu, 11 Jul 2002 12:46:37 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> <3D2D58A6.2E5D9695@niisi.msk.ru> <3D2D5AD2.1B254721@mips.com> <3D2D5FA5.5D964B68@niisi.msk.ru> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Gleb O. Raiko" wrote: > Carsten Langgaard wrote: > > > > "Gleb O. Raiko" wrote: > > > Basically, requirement of uncached run makes hadrware logic much simpler > > > and allows to save silicon a bit. > > > > That could be true, but then again I suggest making specific cache routines for those > > CPUs. > > It would be a real performance hit for the rest of us, if we have to operate from > > uncached space. > > > > In theory, yes, there is a performance penalty. In practice, I doubt > this penalty is significant. Sure, Linux likes to flush cahces, not to > say more. But, did somebody measure the penalty of uncached runs? Even > with microbencnmarks like lmbench. Yes, I have tried running linux this way, because I wanted to eliminate the reason I sow cache problems on one of our tests chip, was due to execute the cache operating instruction from cached space. I didn't thought it was that big a penalty, because you are flushing the cache anyway, but I didn't had to run any benchmarks, so obviously was it when I booted my system. > > Regards, > Gleb. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Jul 11 04:19:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BBJ0Rw025304 for ; Thu, 11 Jul 2002 04:19:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BBJ0g4025303 for linux-mips-outgoing; Thu, 11 Jul 2002 04:19:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BBIoRw025294; Thu, 11 Jul 2002 04:18:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA09051; Thu, 11 Jul 2002 13:23:37 +0200 (MET DST) Date: Thu, 11 Jul 2002 13:23:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Carsten Langgaard , Ralf Baechle , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D2D58A6.2E5D9695@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Gleb O. Raiko wrote: > > But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache > > routines. > > I don't wonder if other IDT CPUs also require this, including those that > conform MIPS32. Well, for r3k it may seem somewhat justified as cache flushing requires cache isolation. But the IDT manual for their whole family of processors claims the D-cache can function as an I-cache (when swapped; doesn't apply when not, obviously) and cache flushing can run from KSEG0. See "IDT MIPS Microprocessor Family Software Reference Manual", chapter 5 "Cache Management", section "Invalidation": "To invalidate the cache in the R30xx: [...] The invalidate routine is normally executed with its instructions cacheable. This sounds like a lot of trouble; but in fact shouldnt require any extra steps to run cached. An invalidation routine in uncached space will run 4-10 times slower." That's right as the IsC bit only isolates the D-cache (either the real one or the I-cache, when swapped) and not the I-cache, so no need to waste cycles running uncached as the I-cache works normally. > Basically, requirement of uncached run makes hadrware logic much simpler > and allows to save silicon a bit. Why? I see no dependency. What's the problem with interleaving cache fills and invalidations? -- + 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 Jul 11 05:07:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BC7BRw025994 for ; Thu, 11 Jul 2002 05:07:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BC7B4Y025993 for linux-mips-outgoing; Thu, 11 Jul 2002 05:07:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BC6qRw025983; Thu, 11 Jul 2002 05:06:53 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6BCCvE18002; Thu, 11 Jul 2002 13:12:57 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6BCBmR06363; Thu, 11 Jul 2002 13:11:48 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF3.00435429 ; Thu, 11 Jul 2002 13:15:24 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: Carsten Langgaard cc: "Gleb O. Raiko" , Ralf Baechle , linux-mips@oss.sgi.com Message-ID: <80256BF3.00435388.00@notesmta.eur.3com.com> Date: Thu, 11 Jul 2002 13:11:02 +0100 Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >> I don't wonder if other IDT CPUs also require this, including those that >> conform MIPS32. >> Basically, requirement of uncached run makes hadrware logic much simpler >> and allows to save silicon a bit. > >That could be true, but then again I suggest making specific cache routines for those >CPUs. >It would be a real performance hit for the rest of us, if we have to operate from >uncached space. I pulled together the relevant code to generate a module to test this problem and it looks like the CPU always misses 1 instruction following the end of the cache loop. If I add some nop's to change the alignment of the code it doesn't seem to make any difference. The same thing seems to happen even if I change the cache flush to a 'Hit_invalidate' of some completely different memory region. One thing I thought might happen is the CPU ending the loop early as soon as it invalidates the cacheline containing the current instructions, but this doesn't seem to be the case, the 'end' address is always correct. Perhaps this really is a hardware problem. The test module below does a blast_icache then a few well known instructions and signifies if anything has been missed. I typically get the following on our board. Cacheop skipped 1 instructions, end = 0x80004000 The end address is correct, so the cache flush completes, but 1 instruction is missed. I would be interested to know if someone can test this on another mips32 processor since I don't have any others available. Simply adding an extra nop after the cache loop might be a good workaround for this board. Module compiled with: /tmp/crossdev/mips/bin/mips-linux-gcc -G 0 -mips2 -mno-abicalls -fno-pic -mlong-calls -fno-common -O2 -fno-strict-aliasing -I/usr/src/linux/include -Wall -DMODULE -D__KERNEL__ -fno-common -c -o test_tmp.o test.c /tmp/crossdev/mips/bin/mips-linux-ld -r -G0 -o test.o test_tmp.o #include #include #include #include #include #include #include #include #include #include #define icache_size (16 * 1024) #define ic_lsize (16) #define cache_unroll(base,op) \ __asm__ __volatile__(" \ .set noreorder; \ .set mips3; \ cache %1, (%0); \ .set mips0; \ .set reorder" \ : \ : "r" (base), \ "i" (op)); static inline unsigned test_blast_icache(void) { unsigned long start = KSEG0; unsigned long end = (start + icache_size); while(start < end) { cache_unroll(start,Index_Invalidate_I); start += ic_lsize; } return start; } static int __init init(void) { int i = 4; unsigned int end; end = test_blast_icache(); __asm__( ".set push \n" ".set noreorder \n" " addu %0,-1 \n" " addu %0,-1 \n" " addu %0,-1 \n" " addu %0,-1 \n" ".set pop \n" : "=r" (i) : "r" (i)); printk("Cacheop skipped %u instructions, end = 0x%x\n", i, end); return 0; } static void __exit fini(void) { } module_init(init); module_exit(fini); From owner-linux-mips@oss.sgi.com Thu Jul 11 06:08:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BD8aRw030015 for ; Thu, 11 Jul 2002 06:08:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BD8anM030014 for linux-mips-outgoing; Thu, 11 Jul 2002 06:08:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BD8ORw030005 for ; Thu, 11 Jul 2002 06:08:25 -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 RAA06424; Thu, 11 Jul 2002 17:12:46 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id RAA25914; Thu, 11 Jul 2002 17:10: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 RAA23766; Thu, 11 Jul 2002 17:06:52 +0400 (MSK) Message-ID: <3D2D83FF.A2FAAB38@niisi.msk.ru> Date: Thu, 11 Jul 2002 17:11:27 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Thu, 11 Jul 2002, Gleb O. Raiko wrote: > > I don't wonder if other IDT CPUs also require this, including those that > > conform MIPS32. > > Well, for r3k it may seem somewhat justified as cache flushing requires > cache isolation. But the IDT manual for their whole family of processors > claims the D-cache can function as an I-cache (when swapped; doesn't > apply when not, obviously) and cache flushing can run from KSEG0. > > See "IDT MIPS Microprocessor Family Software Reference Manual", chapter 5 > "Cache Management", section "Invalidation": > > "To invalidate the cache in the R30xx: > [...] > The invalidate routine is normally executed with its instructions > cacheable. This sounds like a lot of trouble; but in fact shouldnt > require any extra steps to run cached. An invalidation routine in uncached > space will run 4-10 times slower." > Aha, you also stepped on this rake. :-) The problem with IDT manuals that they frequently contradict itself. You're right, SW manual allows cached flushes, but hardware manuals for the family prohibit this and state that flashes must be uncahed. (a hw manual on family, the same chapter, the same section :-) ) It's not only the place where IDT manuals are wrong. For example, their wbflush example suggests *(int*)KSEG0 instead *(int*)KSEG1. > > Basically, requirement of uncached run makes hadrware logic much simpler > > and allows to save silicon a bit. > > Why? I see no dependency. What's the problem with interleaving cache > fills and invalidations? There're two possible optimization: 1. (Requires only the instruction that swaps caches must run uncached) CPU may skip implementation of double check of cache hit on loads. Scenario: mtc0 with cache swapping with ensuring next instructions are in cache (pipelining here!); swap occurs; must check again the instructions are in the cache because the same cacheline in the data cache may have valid bit set and CPU will get data instead of code. 2. (Requires the whole routine must run uncached) CPU may skip check of cache hit on loads from an isolated cache. i don't know what optimization IDT made, perhaps, number 3. But, 1. is really worth to implement. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Jul 11 06:12:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BDCsRw030136 for ; Thu, 11 Jul 2002 06:12:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BDCsJp030135 for linux-mips-outgoing; Thu, 11 Jul 2002 06:12:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BDCiRw030124 for ; Thu, 11 Jul 2002 06:12:45 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11339; Thu, 11 Jul 2002 15:17:47 +0200 (MET DST) Date: Thu, 11 Jul 2002 15:17:47 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User In-Reply-To: <00b401c228ba$88b29bf0$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > In responding to an enquiry from one of MIPS' third-party > software vendors, I noted something that seems a little > broken to me in the current (and maybe all historical) > MIPS/Linux kernels. Please forgive me for opening > old wounds if this has been beaten to death in the past. :-/ > When a user catches a signal, such as SIGBUS, the > signal "payload" includes a pointer to a sigcontext > structure on the stack, containing the state of the > CPU when the exception associated with the signal > occurred. But not exactly. We seem to consistently > call compute_return_epc() before send_sig() or > force_sig(). This results in the user being passed > an indication of the faulting PC that is one instruction > past the true location. That would be no problem, > except that the faulting instruction may have been > in a branch delay slot, such that there is no practical > and reliable way for the signal handler to determine > which instruction failed on the basis of the sigcontext > data. That needs to be done globally, once and forever for all kinds of signals passed to a program. I have partial fixes that I am using privately already, but a complete solution is on my to-do list. > It is, of course, important that execution resume > at the instruction following any instruction generating > an exception/signal. But that's not the same thing > as saying that the sigcontext should report the resumption > EPC instead of the faulting EPC. There are various > ways of dealing with this, but before going into any > of them, I'm curious as to whether this has been > discussed before, and whether anyone thinks that > things really should be the way they are. I believe the resumption should happen with EPC unmodified. A handler may set EPC differently if it wants (possibly with longjmp() or by interpreting code at EPC and modifying EPC appropriately). For the three signal handling possibilities, I'd do that as follows (assuming SIGBUS, SIGSEGV, etc. lethal signals): - SIG_IGN: return to EPC with no action. A program will loop indefinitely, but if that's what a user wants... - SIG_DFL: kill. - HANDLER: call a handler with the signal context unmodified and let the user code decide what to do. 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 Thu Jul 11 06:36:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BDaZRw030907 for ; Thu, 11 Jul 2002 06:36:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BDaZKL030906 for linux-mips-outgoing; Thu, 11 Jul 2002 06:36:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BDaQRw030897 for ; Thu, 11 Jul 2002 06:36:27 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11724; Thu, 11 Jul 2002 15:41:25 +0200 (MET DST) Date: Thu, 11 Jul 2002 15:41:25 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D2D83FF.A2FAAB38@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Gleb O. Raiko wrote: > Aha, you also stepped on this rake. :-) The problem with IDT manuals > that they frequently contradict itself. You're right, SW manual allows > cached flushes, but hardware manuals for the family prohibit this and > state that flashes must be uncahed. > (a hw manual on family, the same chapter, the same section :-) ) Wonderful... Add their non-existent support to that. I'm afraid I'll have to ignore problem reports which involve their processors. :-( > > Why? I see no dependency. What's the problem with interleaving cache > > fills and invalidations? > > There're two possible optimization: > 1. (Requires only the instruction that swaps caches must run uncached) > CPU may skip implementation of double check of cache hit on loads. > Scenario: mtc0 with cache swapping with ensuring next instructions are > in cache > (pipelining here!); swap occurs; must check again the instructions are > in > the cache because the same cacheline in the data cache may have valid > bit set > and CPU will get data instead of code. I can't really see a problem here for proper implementations. The CPU may have fetched a few instructions beyond the mtc0 doing a cache swap. It's OK since we didn't modify the code. As long as the swap doesn't complete, the CPU is using the real I-cache. Once it's completed, it uses the D-cache. Since the new cache is used in the normal mode of operation, now tag matches and line replacements occur here as if it was the real I-cache. No need to do any extra checks at any stage. > 2. (Requires the whole routine must run uncached) > CPU may skip check of cache hit on loads from an isolated cache. But the other cache isn't isolated -- IsC only works on the cache that plays the role of the D-cache. > i don't know what optimization IDT made, perhaps, number 3. But, 1. is > really worth to implement. It's possible they broke something, simply. -- + 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 Jul 11 08:13:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFDKRw005977 for ; Thu, 11 Jul 2002 08:13:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFDKl7005976 for linux-mips-outgoing; Thu, 11 Jul 2002 08:13:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFD9Rw005959 for ; Thu, 11 Jul 2002 08:13:09 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6BFGtXb012060; Thu, 11 Jul 2002 08:16:55 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id IAA17179; Thu, 11 Jul 2002 08:16:54 -0700 (PDT) Message-ID: <003201c228ee$1377c8e0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: References: Subject: Re: Sigcontext->sc_pc Passed to User Date: Thu, 11 Jul 2002 17:16:14 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: "Maciej W. Rozycki" [snip] > I believe the resumption should happen with EPC unmodified. A handler > may set EPC differently if it wants (possibly with longjmp() or by > interpreting code at EPC and modifying EPC appropriately). For the three > signal handling possibilities, I'd do that as follows (assuming SIGBUS, > SIGSEGV, etc. lethal signals): > > - SIG_IGN: return to EPC with no action. A program will loop > indefinitely, but if that's what a user wants... I don't think that this is the right thing to do, philosophically. Hanging in an infinite loop and making no forward progress is not, to me "ignoring" an event. The old X/Open specs I've got say that SIGFPE, SIGILL, and SIGSEGV behavior is undefined if bound to SIG_IGN (curiously, they don't call out SIGBUS), but I think that in practical terms we need to provide whatever behavior people expect from Linux on x86 and PPC. What happens on those platforms? A quick look at the x86 kernel code makes me think that they do, indeed, do the "wrong" thing and beat their heads against the ignored event for all eternity, but I'm insufficiently an expert in x86 trap semantics to know for certain whether that's the case. If it is, right or wrong, that's what we ought to do. > - SIG_DFL: kill. > > - HANDLER: call a handler with the signal context unmodified and let the > user code decide what to do. Independently of what we do for the SIG_IGN cases, this is important, and the user code cannot decide what to do if it cannot know what instruction caused the fault. Fixups on SIGFPE must be able to find the FP instruction, which is not currently possible if it was in a branch delay slot. Similarly, user-mode emulation of "memory" via signal handlers cannot work unless the loads and stores can be identified. But, having "done the deed", return from the signal handler should resume at the instruction *following* the one generating the fault, and not replay the same instruction. We *could* punt that to the signal handler, but making every signal package carry its own copy of compute_return_epc() to handle the branch delay slot cases strikes me as being unfriendly to the user and is arguably slightly less reliable. I guess I'd like things to be rigged so that the sigcontext structure contains the address of the faulting instruction as the sc_pc, but where the return from signal goes to the address calculated by compute_return_epc(). But again, what do people expect in the "mainstream" world of x86 Linux? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Jul 11 08:23:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFNXRw006270 for ; Thu, 11 Jul 2002 08:23:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFNWMR006269 for linux-mips-outgoing; Thu, 11 Jul 2002 08:23:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFNLRw006259 for ; Thu, 11 Jul 2002 08:23:25 -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 TAA07679; Thu, 11 Jul 2002 19:27:44 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id TAA26446; Thu, 11 Jul 2002 19:24:57 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id TAA27419; Thu, 11 Jul 2002 19:22:46 +0400 (MSK) Message-ID: <3D2DA3D5.66664759@niisi.msk.ru> Date: Thu, 11 Jul 2002 19:27:17 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > > There're two possible optimization: > > 1. (Requires only the instruction that swaps caches must run uncached) > > CPU may skip implementation of double check of cache hit on loads. > > Scenario: mtc0 with cache swapping with ensuring next instructions are > > in cache > > (pipelining here!); swap occurs; must check again the instructions are > > in > > the cache because the same cacheline in the data cache may have valid > > bit set > > and CPU will get data instead of code. > > I can't really see a problem here for proper implementations. The CPU > may have fetched a few instructions beyond the mtc0 doing a cache swap. Load from memory into I-cache, setting the valid bit. > It's OK since we didn't modify the code. As long as the swap doesn't > complete, the CPU is using the real I-cache. Once it's completed, it uses > the D-cache. Since the new cache is used in the normal mode of operation, > now tag matches and line replacements occur here as if it was the real > I-cache. No need to do any extra checks at any stage. Have to check the cacheline at given address again. D-cache may have the valid bit set for the cacheline at the same address. Address means location in a cache, not memory. Check at address requires one extra tick as opposed to checking the bit. Please, note that CPU isn't a monolitic program, but rather a set of functional blocks, so "proper implementation" may require additional signals on wires and delays. > > It's possible they broke something, simply. My guess they implemented No. 1. more or less. Anybody from IDT here with strong willing to broke NDA ? :-) Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Jul 11 08:54:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFsIRw006844 for ; Thu, 11 Jul 2002 08:54:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFsIGo006843 for linux-mips-outgoing; Thu, 11 Jul 2002 08:54:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFsCRw006834 for ; Thu, 11 Jul 2002 08:54:12 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA14333; Thu, 11 Jul 2002 17:59:15 +0200 (MET DST) Date: Thu, 11 Jul 2002 17:59:15 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D2DA3D5.66664759@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Gleb O. Raiko wrote: > Have to check the cacheline at given address again. D-cache may have the > valid bit set for the cacheline at the same address. Address means > location in a cache, not memory. Check at address requires one extra > tick as opposed to checking the bit. Well, you issue an instruction word read from the cache. The answer is either a hit, providing a word at the data bus at the same time (so you can't get a hit from one cache and data from the other) or a miss with no valid data -- you have to stall in this case, waiting for a refill. Then when data from the main memory arrives, it is latched in the cache (it doesn't really matter, which one now -- if it's the wrong one, then another refill will happen next time the memory address is dereferenced) and provided to the CPU at the same time. > Please, note that CPU isn't a monolitic program, but rather a set of > functional blocks, so "proper implementation" may require additional > signals on wires and delays. Some kind of synchronization is needed as everywhere in the CPU, as it's mostly a synchronous circuit. As long as the state at clock edges is consistent, there is no problem with cache swapping. That's what I mean by a "proper implementation". -- + 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 Jul 11 08:56:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFuYRw007098 for ; Thu, 11 Jul 2002 08:56:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFuYNn007097 for linux-mips-outgoing; Thu, 11 Jul 2002 08:56:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f21.dialo.tiscali.de [62.246.18.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFuKRw007059 for ; Thu, 11 Jul 2002 08:56:23 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6BCDWk12070; Thu, 11 Jul 2002 14:13:32 +0200 Date: Thu, 11 Jul 2002 14:13:32 +0200 From: Ralf Baechle To: Jon Burgess Cc: "Gleb O. Raiko" , linux-mips@oss.sgi.com, carstenl@mips.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Message-ID: <20020711141332.C11700@dea.linux-mips.net> References: <80256BF3.00366849.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <80256BF3.00366849.00@notesmta.eur.3com.com>; from Jon_Burgess@eur.3com.com on Thu, Jul 11, 2002 at 10:49:55AM +0100 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 10:49:55AM +0100, Jon Burgess wrote: > I'm fairly sure i've seen comments that say that cache manipulation code > should be run uncached. My current thought is that it is probably safe to > manipulate the d-cache with cached code, but I-cache manipulation which > could invalidate the cacheline containing the currently executing code > really should be run uncached. I think the CPU probably then skips > instructions until it gets to the next cacheline, what effect this has > depends on how the instructions are aligned relative to the cacheline. > Given how hit-and-miss this is I am suspicous that this problem could > simply be lurking undiscovered. > > The patch below makes the I-Cache routines run via kseg1, it is a bit > ugly but seems to work. I have not measured the performance impact of > this patch. Have you tried to insert a large number of nops instead? Or preferably, how about replacing the __restore_flags() in your example with the following piece of inline assembler: __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory"); Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 08:56:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFusRw007174 for ; Thu, 11 Jul 2002 08:56:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFusGQ007173 for linux-mips-outgoing; Thu, 11 Jul 2002 08:56:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f21.dialo.tiscali.de [62.246.18.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFuhRw007159 for ; Thu, 11 Jul 2002 08:56:44 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6BBxvJ12000; Thu, 11 Jul 2002 13:59:57 +0200 Date: Thu, 11 Jul 2002 13:59:57 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "H. J. Lu" , Jun Sun , linux-mips@oss.sgi.com Subject: Re: Malta crashes on the latest 2.4 kernel Message-ID: <20020711135957.A11816@dea.linux-mips.net> References: <3D2CBF73.50001@mvista.com> <20020710164900.A28911@lucon.org> <20020711043601.B3207@dea.linux-mips.net> <005c01c228a2$fb2bf450$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005c01c228a2$fb2bf450$10eca8c0@grendel>; from kevink@mips.com on Thu, Jul 11, 2002 at 08:19:55AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,PORN_12,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 08:19:55AM +0200, Kevin D. Kissell wrote: > Excuse me, but I've seen this statement used by others in > the past as an excuse for doing something silly or not doing > something reasonable, and it generally hasn't washed. > In what specific cases have the CP0 pipeline hazards > changed between minor revisions of any production > MIPS CPU? The *documentation* may have been > corrected, but these hazards are fairly fundamental > artifacts of the pipeline microarchitecture of a given > processor. Ancient TLB exception handler code was assuming out of order execution of the instruction stream in cp0 based on the documentation in appendix H of the R4400 manual, version 2. I wrote that code for a R4400 version 5.0 and it was running fine on R4000 3.0 but somebody found it to break on R4000 version 2.2. At least that are the details as I remember them. I don't blame MIPS (well, probably SGI at that time ...) for not documenting these details perfectly right for each and every R4[04]00 implementation. The code broken was written extremly aggressivly and eventually had to be changed anyway for the sake of other processors. > The CP0 hazard between a write of EntryHi > and a subsequent TLBWI instruction is flagged > in the MIPS32 spec and noted as being "typically" > 2 cycles. I'm not going to spend the time going > through my full set of users manuals, but a representative > sampling shows this hazard as being specified for > every R4xxx and R5xxx CPU I checked. The fact > that a given CPU *may* get away with it is no > excuse for not protecting common code. No argument about this one. We definately were lucky. > I note that Ralf has, in fact, applied the fix to the > OSS CVS repository. I also note that "BARRIER" > is still defined to be a string of 6 nops. I would argue > (again) that those really, really ought to be ssnops, > and that if they *were* ssnops, one could probably > have fewer of them. I've applied it because I think the whole update_mmu_cache implementation is ready for a reimplementation anyway. On the performance this isn't going to have measurable impact anyway as update_mmu_cache is only being called once per page fault. BARRIER is defined as 6 nops since it was written somewhen during the summer '96. By that time Linux didn't yet support any processor that was featuring ssnop, so 6 nops certainly were too paranoid. These days you're certainly right, ssnops are the way to go, especially because they don't have any negative impact on pre-ssnop implementations. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 08:57:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFv1Rw007233 for ; Thu, 11 Jul 2002 08:57:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFv1Yc007230 for linux-mips-outgoing; Thu, 11 Jul 2002 08:57:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f21.dialo.tiscali.de [62.246.18.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFusRw007172 for ; Thu, 11 Jul 2002 08:56:55 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6BBjnt11932; Thu, 11 Jul 2002 13:45:49 +0200 Date: Thu, 11 Jul 2002 13:45:49 +0200 From: Ralf Baechle To: Geert Uytterhoeven Cc: "Kevin D. Kissell" , "H. J. Lu" , Jun Sun , Linux/MIPS Development Subject: Re: Malta crashes on the latest 2.4 kernel Message-ID: <20020711134549.B11700@dea.linux-mips.net> References: <005c01c228a2$fb2bf450$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from geert@linux-m68k.org on Thu, Jul 11, 2002 at 08:56:17AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 08:56:17AM +0200, Geert Uytterhoeven wrote: > On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > > I note that Ralf has, in fact, applied the fix to the > > OSS CVS repository. I also note that "BARRIER" > > is still defined to be a string of 6 nops. I would argue > > (again) that those really, really ought to be ssnops, > > and that if they *were* ssnops, one could probably > > have fewer of them. > > Sorry for being ignorant, but what's the difference between nop and ssnop? > > I see that SSNOP is defined to be `sll zero,zero,1' in , but that > doesn't give me any clue. Ssnop is a superscalar nop. It's instruction encoding is the same as of sll, zero, zero, 1. Unlike a normal nop a ssnop is guaranteed to single issue even on superscalar implementations. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 08:57:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BFvFRw007314 for ; Thu, 11 Jul 2002 08:57:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BFvFQD007313 for linux-mips-outgoing; Thu, 11 Jul 2002 08:57:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f21.dialo.tiscali.de [62.246.18.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BFv6Rw007277 for ; Thu, 11 Jul 2002 08:57:08 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6BBClD11743; Thu, 11 Jul 2002 13:12:47 +0200 Date: Thu, 11 Jul 2002 13:12:47 +0200 From: Ralf Baechle To: "Gleb O. Raiko" Cc: Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Message-ID: <20020711131247.A11700@dea.linux-mips.net> References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> <3D2D58A6.2E5D9695@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D2D58A6.2E5D9695@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Jul 11, 2002 at 02:06:30PM +0400 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 02:06:30PM +0400, Gleb O. Raiko wrote: > > > Unfortunately, it's required by manuals for some processors. As I know, > > > IDT HW manuals clearly state cache flush routines must operate from > > > uncached code and must access uncached data only. Examples are R30x1 CPU > > > series. > > > > Yes, that's true. > > But that code belongs in the R30xx specific cache routines, not in the > > MIPS32 cache routines. > > I don't wonder if other IDT CPUs also require this, including those that > conform MIPS32. > Basically, requirement of uncached run makes hadrware logic much simpler > and allows to save silicon a bit. The R3000 cache manipulation mechanism is implemented by giving magic meaning to store instruction while the isolate cache and swap cache bits are in use. By their very implementation they're both incompatible with normal operation of caches and therefore can only be used from uncached space. For most part of it the situation for R4000 class CPUs is easier; a cache instruction either hits or fails. The only problem I could imagine an access conflict in the i-cache when both normal instruction fetch and the cache instruction are going to operate on the i-cache and that sounds like a less likely problem to me. Of course not having read the RTL of all CPUs there is a bit of speculation here :) Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 09:29:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGToRw008079 for ; Thu, 11 Jul 2002 09:29:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGTnT1008078 for linux-mips-outgoing; Thu, 11 Jul 2002 09:29:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGTeRw008066; Thu, 11 Jul 2002 09:29:41 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6BGZnE09609; Thu, 11 Jul 2002 17:35:49 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6BGYdR27830; Thu, 11 Jul 2002 17:34:39 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF3.005B650B ; Thu, 11 Jul 2002 17:38:16 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: Ralf Baechle cc: "Gleb O. Raiko" , linux-mips@oss.sgi.com, carstenl@mips.com Message-ID: <80256BF3.005B6446.00@notesmta.eur.3com.com> Date: Thu, 11 Jul 2002 17:33:53 +0100 Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Ralf wrote: >Have you tried to insert a large number of nops instead? My investigation suggests that a single extra nop is sufficient. I have also tried inserting extra nops before the cache routine to see if the relative alignment of the instructions with respect to the cacheline has an influence, but it has no effect. I am suspicious that if this occurs with the instruction following the loop then something odd might be occuring on every loop iteration as well. I might try adjusting the instructions in the loop to see if that has any effect. > Or preferably, >how about replacing the __restore_flags() in your example with the >following piece of inline assembler: > > __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory"); I am happy that the current assembler code looks correct, but this change would make it simpler. Jon From owner-linux-mips@oss.sgi.com Thu Jul 11 09:47:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGlPRw008512 for ; Thu, 11 Jul 2002 09:47:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGlPTV008511 for linux-mips-outgoing; Thu, 11 Jul 2002 09:47:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGlBRw008497 for ; Thu, 11 Jul 2002 09:47:12 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA15072; Thu, 11 Jul 2002 18:52:15 +0200 (MET DST) Date: Thu, 11 Jul 2002 18:52:14 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User In-Reply-To: <003201c228ee$1377c8e0$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > > - SIG_IGN: return to EPC with no action. A program will loop > > indefinitely, but if that's what a user wants... > > I don't think that this is the right thing to do, philosophically. > Hanging in an infinite loop and making no forward progress > is not, to me "ignoring" an event. The old X/Open specs I've > got say that SIGFPE, SIGILL, and SIGSEGV behavior is > undefined if bound to SIG_IGN (curiously, they don't call > out SIGBUS), but I think that in practical terms we need to > provide whatever behavior people expect from Linux on > x86 and PPC. What happens on those platforms? A > quick look at the x86 kernel code makes me think that > they do, indeed, do the "wrong" thing and beat their > heads against the ignored event for all eternity, but I'm > insufficiently an expert in x86 trap semantics to know > for certain whether that's the case. If it is, right or > wrong, that's what we ought to do. Yes, they loop indefinitely. That my be useful for debugging -- you may attach to a running program and you'll be sure to get at the faulting instruction. Otherwise the warning from the libc manual applies: "If you block or ignore these signals or establish handlers for them that return normally, your program will probably break horribly when such signals happen, unless they are generated by `raise' or `kill' instead of a real error." So a user (programmer) has been warned. > > - HANDLER: call a handler with the signal context unmodified and let the > > user code decide what to do. > > Independently of what we do for the SIG_IGN cases, > this is important, and the user code cannot decide what > to do if it cannot know what instruction caused the fault. > Fixups on SIGFPE must be able to find the FP instruction, > which is not currently possible if it was in a branch delay > slot. Similarly, user-mode emulation of "memory" via Well, the Cause register is passed to the userland, so only EPC needs to be fixed. > signal handlers cannot work unless the loads and stores > can be identified. But, having "done the deed", return > from the signal handler should resume at the instruction > *following* the one generating the fault, and not replay > the same instruction. We *could* punt that to the signal > handler, but making every signal package carry its own > copy of compute_return_epc() to handle the branch > delay slot cases strikes me as being unfriendly to the > user and is arguably slightly less reliable. I guess I'd like things > to be rigged so that the sigcontext structure contains the address > of the faulting instruction as the sc_pc, but where the return > from signal goes to the address calculated by > compute_return_epc(). But again, what do people expect > in the "mainstream" world of x86 Linux? ;-) FPE faults on the x87 fault before the *following* FP instruction (which is a regular one or the special "wait" one). The context of the faulting instruction (both the instruction and data addresses and the opcode) is saved in special registers (as usually with i386, the most complex way was chosen) and can be retrieved by dumping the FPU context to memory (see the "fnstenv" and "fnsave" instructions). So the i386 is very different and can't really be used as a reference. However, a brief look at the Alpha port (which is mature and also the Alpha CPU is much similar to MIPS) reveals the code never modifies the saved PC in the kernel. But again, the FPU traps happen after faulting instructions (for older models even imprecisely -- see the search back code in alpha_fp_emul_imprecise()). With current specifications I think the best way for the SIGFPE handler (since it's somewhat special) would be to provide the address of the faulting instruction in siginfo_t.si_addr and have the EPC in sigcontext set up for a continuation (that would still allow longjmp(), etc.). Ideally, I'd see it reversely, i.e. EPC unchanged and siginfo_t.si_addr containing an address to continue, so that a handler would have to explicitly copy the address to EPC if it decided it handled the signal successfully (so that a program doesn't continue unpredictably after an integer division by zero, because the handler expected only real FP faults) -- maybe we should extend siginfo_t? For other exceptions, I'd just leave EPC alone. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jul 11 09:57:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGv5Rw008756 for ; Thu, 11 Jul 2002 09:57:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGv5RH008755 for linux-mips-outgoing; Thu, 11 Jul 2002 09:57:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGuvRw008746; Thu, 11 Jul 2002 09:56:58 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA15221; Thu, 11 Jul 2002 19:01:58 +0200 (MET DST) Date: Thu, 11 Jul 2002 19:01:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Gleb O. Raiko" , Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <20020711131247.A11700@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Ralf Baechle wrote: > The R3000 cache manipulation mechanism is implemented by giving magic > meaning to store instruction while the isolate cache and swap cache bits > are in use. By their very implementation they're both incompatible with > normal operation of caches and therefore can only be used from uncached > space. Well, docs state only the cache that acts as the D-cache gets isolated and the one that acts as the I-cache always functions normally (and the real D-cache has all the logic needed to pretend it's an I-cache successfully). Thus running from an uncached space is not needed. I haven't checked it explicitly, but the flushing functions would fail (hang) quite soon otherwise and they don't. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jul 11 09:57:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BGvRRw008831 for ; Thu, 11 Jul 2002 09:57:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BGvR1p008830 for linux-mips-outgoing; Thu, 11 Jul 2002 09:57:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BGvGRw008790; Thu, 11 Jul 2002 09:57:17 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA11090; Thu, 11 Jul 2002 10:01:25 -0700 Message-ID: <3D2DB826.6000208@mvista.com> Date: Thu, 11 Jul 2002 09:53:58 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Jon Burgess CC: Carsten Langgaard , "Gleb O. Raiko" , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF3.00435388.00@notesmta.eur.3com.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jon Burgess wrote: > >>>I don't wonder if other IDT CPUs also require this, including those that >>>conform MIPS32. >>>Basically, requirement of uncached run makes hadrware logic much simpler >>>and allows to save silicon a bit. >>> >>That could be true, but then again I suggest making specific cache routines for >> > those > >>CPUs. >>It would be a real performance hit for the rest of us, if we have to operate >> > from > >>uncached space. >> > > I pulled together the relevant code to generate a module to test this problem > and it looks like the CPU always misses 1 instruction following the end of the > cache loop. If I add some nop's to change the alignment of the code it doesn't > seem to make any difference. The same thing seems to happen even if I change the > cache flush to a 'Hit_invalidate' of some completely different memory region. > One thing I thought might happen is the CPU ending the loop early as soon as it > invalidates the cacheline containing the current instructions, but this doesn't > seem to be the case, the 'end' address is always correct. Perhaps this really is > a hardware problem. > > The test module below does a blast_icache then a few well known instructions and > signifies if anything has been missed. I typically get the following on our > board. > Cacheop skipped 1 instructions, end = 0x80004000 Here is the test results from Malta 4kc Cacheop skipped 0 instructions, end = 0x80004000 root@10.0.18.6:~# cat /proc/cpuinfo processor : 0 cpu model : MIPS 4Kc V0.1 BogoMIPS : 79.66 wait instruction : no microsecond timers : yes extra interrupt vector : yes hardware watchpoint : yes VCED exceptions : not available VCEI exceptions : not available Jun From owner-linux-mips@oss.sgi.com Thu Jul 11 10:23:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BHNERw011509 for ; Thu, 11 Jul 2002 10:23:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BHND8G011508 for linux-mips-outgoing; Thu, 11 Jul 2002 10:23:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ace.ulyssis.org (IDENT:root@ace.ulyssis.student.kuleuven.ac.be [193.190.253.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BHLsRw011491; Thu, 11 Jul 2002 10:21:55 -0700 Received: (from p2@localhost) by ace.ulyssis.org (8.11.6/8.11.6) id g6BHQME04622; Thu, 11 Jul 2002 19:26:22 +0200 Date: Thu, 11 Jul 2002 19:26:22 +0200 From: Peter De Schrijver To: geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be, p2@mind.be, ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: ds1286 \\\\ Message-ID: <20020711192622.A4119@ace.ulyssis.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.2i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This patch moves ralf's ds1286 driver to drivers/char and makes it selectable for the ddb5074 board as well. I don't have an SGI here to check if it still works for an indy though. It should though :) test results welcome :) Cheers, Peter. --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffje-ds1286 diff -r -N -u -w oss-2.4/linux/drivers/char/Config.in oss-2.4-ddb5074/linux/drivers/char/Config.in --- oss-2.4/linux/drivers/char/Config.in Mon Jul 1 22:45:39 2002 +++ oss-2.4-ddb5074/linux/drivers/char/Config.in Thu Jul 11 19:16:33 2002 @@ -268,6 +268,9 @@ if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then bool 'Tadpole ANA H8 Support' CONFIG_H8 fi +if [ "$CONFIG_DDB5074" = "y" -o "$CONFIG_SGI" = "y" ]; then + bool 'DS1286 RTC support' CONFIG_RTC_DS1286 +fi tristate 'Double Talk PC internal speech card support' CONFIG_DTLK tristate 'Siemens R3964 line discipline' CONFIG_R3964 diff -r -N -u -w oss-2.4/linux/drivers/char/Makefile oss-2.4-ddb5074/linux/drivers/char/Makefile --- oss-2.4/linux/drivers/char/Makefile Thu Jun 27 00:35:32 2002 +++ oss-2.4-ddb5074/linux/drivers/char/Makefile Tue Jul 9 15:19:26 2002 @@ -179,6 +179,7 @@ obj-$(CONFIG_BVME6000_SCC) += generic_serial.o vme_scc.o obj-$(CONFIG_SERIAL_TX3912) += generic_serial.o serial_tx3912.o obj-$(CONFIG_TXX927_SERIAL) += serial_txx927.o +obj-$(CONFIG_RTC_DS1286) += ds1286.o subdir-$(CONFIG_RIO) += rio subdir-$(CONFIG_INPUT) += joystick diff -r -N -u -w oss-2.4/linux/drivers/char/ds1286.c oss-2.4-ddb5074/linux/drivers/char/ds1286.c --- oss-2.4/linux/drivers/char/ds1286.c Thu Jan 1 01:00:00 1970 +++ oss-2.4-ddb5074/linux/drivers/char/ds1286.c Tue Jul 9 15:30:02 2002 @@ -0,0 +1,533 @@ +/* + * DS1286 Real Time Clock interface for Linux + * + * Copyright (C) 1998, 1999, 2000 Ralf Baechle + * + * Based on code written by Paul Gortmaker. + * + * This driver allows use of the real time clock (built into nearly all + * computers) from user space. It exports the /dev/rtc interface supporting + * various ioctl() and also the /proc/rtc pseudo-file for status + * information. + * + * The ioctls can be used to set the interrupt behaviour and generation rate + * from the RTC via IRQ 8. Then the /dev/rtc interface can be used to make + * use of these timer interrupts, be they interval or alarm based. + * + * The /dev/rtc interface will block on reads until an interrupt has been + * received. If a RTC interrupt has already happened, it will output an + * unsigned long and then block. The output value contains the interrupt + * status in the low byte and the number of interrupts since the last read + * in the remaining high bytes. The /dev/rtc interface can also be used with + * the select(2) call. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define DS1286_VERSION "1.0" + +/* + * We sponge a minor off of the misc major. No need slurping + * up another valuable major dev number for this. If you add + * an ioctl, make sure you don't conflict with SPARC's RTC + * ioctls. + */ + +static DECLARE_WAIT_QUEUE_HEAD(ds1286_wait); + +static ssize_t ds1286_read(struct file *file, char *buf, + size_t count, loff_t *ppos); + +static int ds1286_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg); + +static unsigned int ds1286_poll(struct file *file, poll_table *wait); + +void ds1286_get_alm_time (struct rtc_time *alm_tm); +void ds1286_get_time(struct rtc_time *rtc_tm); +int ds1286_set_time(struct rtc_time *rtc_tm); + +void set_rtc_irq_bit(unsigned char bit); +void clear_rtc_irq_bit(unsigned char bit); + +static inline unsigned char ds1286_is_updating(void); + +static spinlock_t ds1286_lock = SPIN_LOCK_UNLOCKED; + +/* + * Bits in rtc_status. (7 bits of room for future expansion) + */ + +#define RTC_IS_OPEN 0x01 /* means /dev/rtc is in use */ +#define RTC_TIMER_ON 0x02 /* missed irq timer active */ + +unsigned char ds1286_status; /* bitmapped status byte. */ +unsigned long ds1286_freq; /* Current periodic IRQ rate */ + +unsigned char days_in_mo[] = +{0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; + +/* + * Now all the various file operations that we export. + */ + +static ssize_t ds1286_read(struct file *file, char *buf, + size_t count, loff_t *ppos) +{ + return -EIO; +} + +static int ds1286_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + + struct rtc_time wtime; + + switch (cmd) { + case RTC_AIE_OFF: /* Mask alarm int. enab. bit */ + { + unsigned int flags; + unsigned char val; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + spin_lock_irqsave(&ds1286_lock, flags); + val = CMOS_READ(RTC_CMD); + val |= RTC_TDM; + CMOS_WRITE(val, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + return 0; + } + case RTC_AIE_ON: /* Allow alarm interrupts. */ + { + unsigned int flags; + unsigned char val; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + spin_lock_irqsave(&ds1286_lock, flags); + val = CMOS_READ(RTC_CMD); + val &= ~RTC_TDM; + CMOS_WRITE(val, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + return 0; + } + case RTC_WIE_OFF: /* Mask watchdog int. enab. bit */ + { + unsigned int flags; + unsigned char val; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + spin_lock_irqsave(&ds1286_lock, flags); + val = CMOS_READ(RTC_CMD); + val |= RTC_WAM; + CMOS_WRITE(val, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + return 0; + } + case RTC_WIE_ON: /* Allow watchdog interrupts. */ + { + unsigned int flags; + unsigned char val; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + spin_lock_irqsave(&ds1286_lock, flags); + val = CMOS_READ(RTC_CMD); + val &= ~RTC_WAM; + CMOS_WRITE(val, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + return 0; + } + case RTC_ALM_READ: /* Read the present alarm time */ + { + /* + * This returns a struct rtc_time. Reading >= 0xc0 + * means "don't care" or "match all". Only the tm_hour, + * tm_min, and tm_sec values are filled in. + */ + + ds1286_get_alm_time(&wtime); + break; + } + case RTC_ALM_SET: /* Store a time into the alarm */ + { + /* + * This expects a struct rtc_time. Writing 0xff means + * "don't care" or "match all". Only the tm_hour, + * tm_min and tm_sec are used. + */ + unsigned char hrs, min, sec; + struct rtc_time alm_tm; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + if (copy_from_user(&alm_tm, (struct rtc_time*)arg, + sizeof(struct rtc_time))) + return -EFAULT; + + hrs = alm_tm.tm_hour; + min = alm_tm.tm_min; + + if (hrs >= 24) + hrs = 0xff; + + if (min >= 60) + min = 0xff; + + BIN_TO_BCD(sec); + BIN_TO_BCD(min); + BIN_TO_BCD(hrs); + + spin_lock(&ds1286_lock); + CMOS_WRITE(hrs, RTC_HOURS_ALARM); + CMOS_WRITE(min, RTC_MINUTES_ALARM); + spin_unlock(&ds1286_lock); + + return 0; + } + case RTC_RD_TIME: /* Read the time/date from RTC */ + { + ds1286_get_time(&wtime); + break; + } + case RTC_SET_TIME: /* Set the RTC */ + { + struct rtc_time rtc_tm; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + if (copy_from_user(&rtc_tm, (struct rtc_time*)arg, + sizeof(struct rtc_time))) + return -EFAULT; + + return ds1286_set_time(&rtc_tm); + } + default: + return -EINVAL; + } + return copy_to_user((void *)arg, &wtime, sizeof wtime) ? -EFAULT : 0; +} + +/* + * We enforce only one user at a time here with the open/close. + * Also clear the previous interrupt data on an open, and clean + * up things on a close. + */ + +static int ds1286_open(struct inode *inode, struct file *file) +{ + spin_lock_irq(&ds1286_lock); + + if (ds1286_status & RTC_IS_OPEN) + goto out_busy; + + ds1286_status |= RTC_IS_OPEN; + + spin_lock_irq(&ds1286_lock); + return 0; + +out_busy: + spin_lock_irq(&ds1286_lock); + return -EBUSY; +} + +static int ds1286_release(struct inode *inode, struct file *file) +{ + ds1286_status &= ~RTC_IS_OPEN; + + return 0; +} + +static unsigned int ds1286_poll(struct file *file, poll_table *wait) +{ + poll_wait(file, &ds1286_wait, wait); + + return 0; +} + +/* + * The various file operations we support. + */ + +static struct file_operations ds1286_fops = { + llseek: no_llseek, + read: ds1286_read, + poll: ds1286_poll, + ioctl: ds1286_ioctl, + open: ds1286_open, + release: ds1286_release, +}; + +static struct miscdevice ds1286_dev= +{ + RTC_MINOR, + "rtc", + &ds1286_fops +}; + +int __init ds1286_init(void) +{ + printk(KERN_INFO "DS1286 Real Time Clock Driver v%s\n", DS1286_VERSION); + misc_register(&ds1286_dev); + + return 0; +} + +static char *days[] = { + "***", "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" +}; + +/* + * Info exported via "/proc/rtc". + */ +int get_ds1286_status(char *buf) +{ + char *p, *s; + struct rtc_time tm; + unsigned char hundredth, month, cmd, amode; + + p = buf; + + ds1286_get_time(&tm); + hundredth = CMOS_READ(RTC_HUNDREDTH_SECOND); + BCD_TO_BIN(hundredth); + + p += sprintf(p, + "rtc_time\t: %02d:%02d:%02d.%02d\n" + "rtc_date\t: %04d-%02d-%02d\n", + tm.tm_hour, tm.tm_min, tm.tm_sec, hundredth, + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday); + + /* + * We implicitly assume 24hr mode here. Alarm values >= 0xc0 will + * match any value for that particular field. Values that are + * greater than a valid time, but less than 0xc0 shouldn't appear. + */ + ds1286_get_alm_time(&tm); + p += sprintf(p, "alarm\t\t: %s ", days[tm.tm_wday]); + if (tm.tm_hour <= 24) + p += sprintf(p, "%02d:", tm.tm_hour); + else + p += sprintf(p, "**:"); + + if (tm.tm_min <= 59) + p += sprintf(p, "%02d\n", tm.tm_min); + else + p += sprintf(p, "**\n"); + + month = CMOS_READ(RTC_MONTH); + p += sprintf(p, + "oscillator\t: %s\n" + "square_wave\t: %s\n", + (month & RTC_EOSC) ? "disabled" : "enabled", + (month & RTC_ESQW) ? "disabled" : "enabled"); + + amode = ((CMOS_READ(RTC_MINUTES_ALARM) & 0x80) >> 5) | + ((CMOS_READ(RTC_HOURS_ALARM) & 0x80) >> 6) | + ((CMOS_READ(RTC_DAY_ALARM) & 0x80) >> 7); + if (amode == 7) s = "each minute"; + else if (amode == 3) s = "minutes match"; + else if (amode == 1) s = "hours and minutes match"; + else if (amode == 0) s = "days, hours and minutes match"; + else s = "invalid"; + p += sprintf(p, "alarm_mode\t: %s\n", s); + + cmd = CMOS_READ(RTC_CMD); + p += sprintf(p, + "alarm_enable\t: %s\n" + "wdog_alarm\t: %s\n" + "alarm_mask\t: %s\n" + "wdog_alarm_mask\t: %s\n" + "interrupt_mode\t: %s\n" + "INTB_mode\t: %s_active\n" + "interrupt_pins\t: %s\n", + (cmd & RTC_TDF) ? "yes" : "no", + (cmd & RTC_WAF) ? "yes" : "no", + (cmd & RTC_TDM) ? "disabled" : "enabled", + (cmd & RTC_WAM) ? "disabled" : "enabled", + (cmd & RTC_PU_LVL) ? "pulse" : "level", + (cmd & RTC_IBH_LO) ? "low" : "high", + (cmd & RTC_IPSW) ? "unswapped" : "swapped"); + + return p - buf; +} + +/* + * Returns true if a clock update is in progress + */ +static inline unsigned char ds1286_is_updating(void) +{ + return CMOS_READ(RTC_CMD) & RTC_TE; +} + + +void ds1286_get_time(struct rtc_time *rtc_tm) +{ + unsigned char save_control; + unsigned int flags; + unsigned long uip_watchdog = jiffies; + + /* + * read RTC once any update in progress is done. The update + * can take just over 2ms. We wait 10 to 20ms. There is no need to + * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP. + * If you need to know *exactly* when a second has started, enable + * periodic update complete interrupts, (via ioctl) and then + * immediately read /dev/rtc which will block until you get the IRQ. + * Once the read clears, read the RTC time (again via ioctl). Easy. + */ + + if (ds1286_is_updating() != 0) + while (jiffies - uip_watchdog < 2*HZ/100) + barrier(); + + /* + * Only the values that we read from the RTC are set. We leave + * tm_wday, tm_yday and tm_isdst untouched. Even though the + * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated + * by the RTC when initially set to a non-zero value. + */ + spin_lock_irqsave(&ds1286_lock, flags); + save_control = CMOS_READ(RTC_CMD); + CMOS_WRITE((save_control|RTC_TE), RTC_CMD); + + rtc_tm->tm_sec = CMOS_READ(RTC_SECONDS); + rtc_tm->tm_min = CMOS_READ(RTC_MINUTES); + rtc_tm->tm_hour = CMOS_READ(RTC_HOURS) & 0x1f; + rtc_tm->tm_mday = CMOS_READ(RTC_DATE); + rtc_tm->tm_mon = CMOS_READ(RTC_MONTH) & 0x1f; + rtc_tm->tm_year = CMOS_READ(RTC_YEAR); + + CMOS_WRITE(save_control, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + BCD_TO_BIN(rtc_tm->tm_sec); + BCD_TO_BIN(rtc_tm->tm_min); + BCD_TO_BIN(rtc_tm->tm_hour); + BCD_TO_BIN(rtc_tm->tm_mday); + BCD_TO_BIN(rtc_tm->tm_mon); + BCD_TO_BIN(rtc_tm->tm_year); + + /* + * Account for differences between how the RTC uses the values + * and how they are defined in a struct rtc_time; + */ + if (rtc_tm->tm_year < 45) + rtc_tm->tm_year += 30; + if ((rtc_tm->tm_year += 40) < 70) + rtc_tm->tm_year += 100; + + rtc_tm->tm_mon--; +} + +int ds1286_set_time(struct rtc_time *rtc_tm) +{ + unsigned char mon, day, hrs, min, sec, leap_yr; + unsigned char save_control; + unsigned int yrs, flags; + + + yrs = rtc_tm->tm_year + 1900; + mon = rtc_tm->tm_mon + 1; /* tm_mon starts at zero */ + day = rtc_tm->tm_mday; + hrs = rtc_tm->tm_hour; + min = rtc_tm->tm_min; + sec = rtc_tm->tm_sec; + + if (yrs < 1970) + return -EINVAL; + + leap_yr = ((!(yrs % 4) && (yrs % 100)) || !(yrs % 400)); + + if ((mon > 12) || (day == 0)) + return -EINVAL; + + if (day > (days_in_mo[mon] + ((mon == 2) && leap_yr))) + return -EINVAL; + + if ((hrs >= 24) || (min >= 60) || (sec >= 60)) + return -EINVAL; + + if ((yrs -= 1940) > 255) /* They are unsigned */ + return -EINVAL; + + if (yrs >= 100) + yrs -= 100; + + BIN_TO_BCD(sec); + BIN_TO_BCD(min); + BIN_TO_BCD(hrs); + BIN_TO_BCD(day); + BIN_TO_BCD(mon); + BIN_TO_BCD(yrs); + + spin_lock_irqsave(&ds1286_lock, flags); + save_control = CMOS_READ(RTC_CMD); + CMOS_WRITE((save_control|RTC_TE), RTC_CMD); + + CMOS_WRITE(yrs, RTC_YEAR); + CMOS_WRITE(mon, RTC_MONTH); + CMOS_WRITE(day, RTC_DATE); + CMOS_WRITE(hrs, RTC_HOURS); + CMOS_WRITE(min, RTC_MINUTES); + CMOS_WRITE(sec, RTC_SECONDS); + CMOS_WRITE(0, RTC_HUNDREDTH_SECOND); + + CMOS_WRITE(save_control, RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + return 0; +} + +void ds1286_get_alm_time(struct rtc_time *alm_tm) +{ + unsigned char cmd; + unsigned int flags; + + /* + * Only the values that we read from the RTC are set. That + * means only tm_wday, tm_hour, tm_min. + */ + spin_lock_irqsave(&ds1286_lock, flags); + alm_tm->tm_min = CMOS_READ(RTC_MINUTES_ALARM) & 0x7f; + alm_tm->tm_hour = CMOS_READ(RTC_HOURS_ALARM) & 0x1f; + alm_tm->tm_wday = CMOS_READ(RTC_DAY_ALARM) & 0x07; + cmd = CMOS_READ(RTC_CMD); + spin_unlock_irqrestore(&ds1286_lock, flags); + + BCD_TO_BIN(alm_tm->tm_min); + BCD_TO_BIN(alm_tm->tm_hour); + alm_tm->tm_sec = 0; +} + +module_init(ds1286_init) diff -r -N -u -w oss-2.4/linux/drivers/char/misc.c oss-2.4-ddb5074/linux/drivers/char/misc.c --- oss-2.4/linux/drivers/char/misc.c Thu Jun 27 00:35:33 2002 +++ oss-2.4-ddb5074/linux/drivers/char/misc.c Thu Jul 11 19:19:24 2002 @@ -261,9 +261,6 @@ #ifdef CONFIG_BVME6000 rtc_DP8570A_init(); #endif -#ifdef CONFIG_SGI_DS1286 - ds1286_init(); -#endif #ifdef CONFIG_PMAC_PBOOK pmu_device_init(); #endif --liOOAslEiF7prFVr-- From owner-linux-mips@oss.sgi.com Thu Jul 11 12:34:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BJY8Rw020950 for ; Thu, 11 Jul 2002 12:34:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BJY8OD020949 for linux-mips-outgoing; Thu, 11 Jul 2002 12:34:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from snog.front.onramp.ca (snog.front.onramp.ca [198.163.180.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BJY2Rw020937 for ; Thu, 11 Jul 2002 12:34:03 -0700 Received: (qmail 15217 invoked from network); 11 Jul 2002 19:38:37 -0000 Received: from gateway.hgeng.com (HELO shadowfax.hgeng.com) (199.246.74.82) by 0 with SMTP; 11 Jul 2002 19:38:37 -0000 Received: from dilbert.hgeng.com (dilbert.hgeng.com [192.168.1.6]) by shadowfax.hgeng.com (8.12.1/8.12.1/Debian -3) with ESMTP id g6BJcagO008515 for ; Thu, 11 Jul 2002 15:38:36 -0400 Subject: Re: X server blanking out virtual consoles? From: Michael Hill To: linux-mips@oss.sgi.com In-Reply-To: <1025794188.10696.205.camel@dilbert> References: <1025794188.10696.205.camel@dilbert> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1026416316.1138.59.camel@dilbert> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Jul 2002 15:38:36 -0400 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-07-04 at 10:49, I wrote: > On Tue, 2002-06-11 at 03:55, Guido Guenther wrote: > > Known issue that I really have to debug someday. Until then try the > > patch by Dominik Behr at: > > http://honk.physik.uni-konstanz.de/linux-mips/x/x.html#bugs > > Works brilliantly for me with one small side effect. Xserver from CVS using Dominik's patch mostly fixes a Window Maker colour issue with the server from 4.2.0 (similarly patched) on my 8-bit Indy. Virtual consoles are visible, wmaker complains like this: /usr/bin/WindowMaker warning: could not allocate color "rgb:93/0d/29" /usr/bin/WindowMaker warning: could not get color for key "CClipTitleColor" /usr/bin/WindowMaker warning: using default "#454045" instead /usr/bin/WindowMaker warning: could not allocate color "#454045" /usr/bin/WindowMaker warning: could not get color for key "CClipTitleColor" /usr/bin/WindowMaker warning: could not allocate color "#73091d" /usr/bin/WindowMaker warning: could not get color for key "IconTitleBack" /usr/bin/WindowMaker warning: using default "black" instead A few of the adornments are indeed black but it's much brighter, and it's more tolerable than having everything black (Sawfish looks the same, but it was okay before). Thanks Guido (and Florian). Mike From owner-linux-mips@oss.sgi.com Thu Jul 11 15:35:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BMZcRw024942 for ; Thu, 11 Jul 2002 15:35:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BMZct5024941 for linux-mips-outgoing; Thu, 11 Jul 2002 15:35:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BMZSRw024932; Thu, 11 Jul 2002 15:35:29 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6BMdsC26624; Fri, 12 Jul 2002 00:39:54 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6BMdtTF015340; Fri, 12 Jul 2002 00:39:55 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17SmbK-0001dQ-00; Fri, 12 Jul 2002 00:39:54 +0200 Date: Fri, 12 Jul 2002 00:39:54 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] __ffs implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Fixes __ffs(x) implementation for the 2.5.4 kernel on mips and mips64 : ffz(~x) instead of ffz(x). Vivien. --- linux/include/asm-mips/bitops.h Mon Jul 8 22:28:08 2002 +++ linux.patch/include/asm-mips/bitops.h Fri Jul 12 00:04:26 2002 @@ -732,7 +732,7 @@ */ static __inline__ unsigned long __ffs(unsigned long word) { - return ffz(word); + return ffz(~word); } #ifdef __KERNEL__ --- linux/include/asm-mips64/bitops.h Wed Jul 10 00:30:31 2002 +++ linux.patch/include/asm-mips64/bitops.h Fri Jul 12 00:04:13 2002 @@ -444,7 +444,7 @@ */ static __inline__ unsigned long __ffs(unsigned long word) { - return ffz(word); + return ffz(~word); } /* From owner-linux-mips@oss.sgi.com Thu Jul 11 15:57:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6BMvvRw025758 for ; Thu, 11 Jul 2002 15:57:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6BMvvPa025757 for linux-mips-outgoing; Thu, 11 Jul 2002 15:57:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6BMveRw025748; Thu, 11 Jul 2002 15:57:43 -0700 Received: from gladsmuir.algor.co.uk (root@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g6BN1vv09749; Fri, 12 Jul 2002 00:01:58 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15662.3715.334923.669657@gladsmuir.algor.co.uk> Date: Fri, 12 Jul 2002 00:02:27 +0100 To: "Maciej W. Rozycki" Cc: Ralf Baechle , "Gleb O. Raiko" , Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: References: <20020711131247.A11700@dea.linux-mips.net> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Well, docs state only the cache that acts as the D-cache gets isolated > and the one that acts as the I-cache always functions normally (and the > real D-cache has all the logic needed to pretend it's an I-cache > successfully). Thus running from an uncached space is not needed. I > haven't checked it explicitly, but the flushing functions would fail > (hang) quite soon otherwise and they don't. I wrote the IDT software manual (I later used bits of it as the basis of parts of "See MIPS Run".) Of course, every word of it is true. I can't comment on IDT's hardware manuals, though in my experience they were somewhat better than the average. Algorithmics produced cached routines to manipulate R3000-style caches and they work reliably; what's more, the hardware specs say they should. Yes, it seems a bit strange to run with 'isolated'; but 'isolated' really only stops loads and stores from reading/writing at the bus interface. It's use in cache functions was an accident; the original R2000 caches did not support partial-word writes and could be invalidated just by writing a byte to them. When this was discovered to be unacceptable, the 'isolated' bit (intended for diagnostics) was pressed into service. It is extraordinarily inefficient to run invalidate or writeback routines uncached. It will add perhaps 4-10 instruction fetches (external memory reads) for each cache line invalidated; that's probably double the memory overhead of the DMA operation which necessitated the invalidation. That's something production-quality code shouldn't do. PS: my standard appeal. When you say you 'flush' a cache do you mean invalidate, write-back, or both? If (as I suspect) not all of you mean the same thing, should you not instead speak of 'invalidate' and 'writeback'... sloppy language surely leads to sloppy programming? -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Thu Jul 11 17:27:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C0RIRw027122 for ; Thu, 11 Jul 2002 17:27:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C0RI1D027121 for linux-mips-outgoing; Thu, 11 Jul 2002 17:27:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f102.dialo.tiscali.de [62.246.18.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C0RBRw027112 for ; Thu, 11 Jul 2002 17:27:13 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6C0Osc16584; Fri, 12 Jul 2002 02:24:54 +0200 Date: Fri, 12 Jul 2002 02:24:54 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: "Maciej W. Rozycki" , "Gleb O. Raiko" , Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Message-ID: <20020712022454.A16457@dea.linux-mips.net> References: <20020711131247.A11700@dea.linux-mips.net> <15662.3715.334923.669657@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15662.3715.334923.669657@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Fri, Jul 12, 2002 at 12:02:27AM +0100 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jul 12, 2002 at 12:02:27AM +0100, Dominic Sweetman wrote: > PS: my standard appeal. When you say you 'flush' a cache do you mean > invalidate, write-back, or both? If (as I suspect) not all of you > mean the same thing, should you not instead speak of 'invalidate' and > 'writeback'... sloppy language surely leads to sloppy programming? I already had discussions with 68k people about this problem of terminology. It seems there is no unambigous terms for the whole ``cachology'' in the industry. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 18:35:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C1ZrRw000858 for ; Thu, 11 Jul 2002 18:35:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C1Zq3K000857 for linux-mips-outgoing; Thu, 11 Jul 2002 18:35:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f102.dialo.tiscali.de [62.246.18.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C1ZhRw000840 for ; Thu, 11 Jul 2002 18:35:45 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6C1eF117333; Fri, 12 Jul 2002 03:40:15 +0200 Date: Fri, 12 Jul 2002 03:40:15 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User Message-ID: <20020712034015.C16608@dea.linux-mips.net> References: <00b401c228ba$88b29bf0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00b401c228ba$88b29bf0$10eca8c0@grendel>; from kevink@mips.com on Thu, Jul 11, 2002 at 11:08:21AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jul 11, 2002 at 11:08:21AM +0200, Kevin D. Kissell wrote: > In responding to an enquiry from one of MIPS' third-party > software vendors, I noted something that seems a little > broken to me in the current (and maybe all historical) > MIPS/Linux kernels. Please forgive me for opening > old wounds if this has been beaten to death in the past. > > When a user catches a signal, such as SIGBUS, the > signal "payload" includes a pointer to a sigcontext > structure on the stack, containing the state of the > CPU when the exception associated with the signal > occurred. But not exactly. We seem to consistently > call compute_return_epc() before send_sig() or > force_sig(). This results in the user being passed > an indication of the faulting PC that is one instruction > past the true location. That would be no problem, > except that the faulting instruction may have been > in a branch delay slot, such that there is no practical > and reliable way for the signal handler to determine > which instruction failed on the basis of the sigcontext > data. > > It is, of course, important that execution resume > at the instruction following any instruction generating > an exception/signal. But that's not the same thing > as saying that the sigcontext should report the resumption > EPC instead of the faulting EPC. There are various > ways of dealing with this, but before going into any > of them, I'm curious as to whether this has been > discussed before, and whether anyone thinks that > things really should be the way they are. Our signal stackframe is almost the same as on IRIX5 which is what some software expects. Maybe time to checkout what IRIX does ... Ralf From owner-linux-mips@oss.sgi.com Thu Jul 11 20:40:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C3eqRw007855 for ; Thu, 11 Jul 2002 20:40:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C3eqxQ007854 for linux-mips-outgoing; Thu, 11 Jul 2002 20:40:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C3ekRw007843 for ; Thu, 11 Jul 2002 20:40:47 -0700 Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 65FDF38DC6 for ; Fri, 12 Jul 2002 00:45:21 -0300 (EST) Received: (qmail 25748 invoked by uid 0); 12 Jul 2002 03:45:37 -0000 Received: from freak.distro.conectiva (10.0.17.22) by burns.conectiva with SMTP; 12 Jul 2002 03:45:37 -0000 Date: Thu, 11 Jul 2002 23:51:10 -0300 (BRT) From: Marcelo Tosatti X-X-Sender: marcelo@freak.distro.conectiva To: Alan Cox Cc: Jun Sun , , Ralf Baechle , Jeff Garzik Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 11 Jul 2002, Alan Cox wrote: > > This patch fixes a tx underflow error for 79c973 chip. It essentially delay > > the transmission until the whole packet is received into the on-chip sdram. > > > > The patch is already accepted by Marcelo for the 2.4 tree, I think. > > Which slows the stuff down for people with real computers. Please apply > some kind of heuristic to this - eg switch to delaying if you exceed > 50 failures in a 60 second period. I haven't applied it yet. I'll let it come to me throught Jeff Garzik after the issues are resolved. From owner-linux-mips@oss.sgi.com Fri Jul 12 00:54:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C7s0Rw015708 for ; Fri, 12 Jul 2002 00:54:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C7s05b015707 for linux-mips-outgoing; Fri, 12 Jul 2002 00:54:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C7rqRw015698 for ; Fri, 12 Jul 2002 00:53:53 -0700 Received: (qmail 30946 invoked by uid 0); 12 Jul 2002 07:58:23 -0000 Received: from unknown (HELO bogon.ms20.nix) (134.34.147.122) by mail.gmx.net (mp001-rz3) with SMTP; 12 Jul 2002 07:58:23 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 9C2C43646B; Fri, 12 Jul 2002 09:55:50 +0200 (CEST) Date: Fri, 12 Jul 2002 09:55:50 +0200 From: Guido Guenther To: Michael Hill Cc: linux-mips@oss.sgi.com Subject: Re: X server blanking out virtual consoles? Message-ID: <20020712075549.GA1569@bogon.ms20.nix> Mail-Followup-To: Michael Hill , linux-mips@oss.sgi.com References: <1025794188.10696.205.camel@dilbert> <1026416316.1138.59.camel@dilbert> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <1026416316.1138.59.camel@dilbert> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Micheal, On Thu, Jul 11, 2002 at 03:38:36PM -0400, Michael Hill wrote: > /usr/bin/WindowMaker warning: could not allocate color "rgb:93/0d/29" > /usr/bin/WindowMaker warning: could not get color for key > "CClipTitleColor" > /usr/bin/WindowMaker warning: using default "#454045" instead > /usr/bin/WindowMaker warning: could not allocate color "#454045" > /usr/bin/WindowMaker warning: could not get color for key > "CClipTitleColor" > /usr/bin/WindowMaker warning: could not allocate color "#73091d" > /usr/bin/WindowMaker warning: could not get color for key > "IconTitleBack" > /usr/bin/WindowMaker warning: using default "black" instead This is possibly as close as one can get with 8bpp. You can try to edit GNUstep/defaults/WindowMaker to reduce the needed colors further. thanks a lot for the report, -- Guido --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9LouFn88szT8+ZCYRAvQZAJ4s+2uNoKG+5pXAH10cQWssDQ1LWwCfTXN5 EGknYQsHOegpYy+0Jf8BiXk= =xezG -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-linux-mips@oss.sgi.com Fri Jul 12 00:55:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C7tiRw016147 for ; Fri, 12 Jul 2002 00:55:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C7tiG3016146 for linux-mips-outgoing; Fri, 12 Jul 2002 00:55:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C7tYRw016123; Fri, 12 Jul 2002 00:55:34 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6C803Xb015492; Fri, 12 Jul 2002 01:00:03 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA25730; Fri, 12 Jul 2002 01:00:03 -0700 (PDT) Message-ID: <003301c2297a$380ed400$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: References: <00b401c228ba$88b29bf0$10eca8c0@grendel> <20020712034015.C16608@dea.linux-mips.net> Subject: Re: Sigcontext->sc_pc Passed to User Date: Fri, 12 Jul 2002 10:00:27 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: "Ralf Baechle" > On Thu, Jul 11, 2002 at 11:08:21AM +0200, Kevin D. Kissell wrote: [snip] > > When a user catches a signal, such as SIGBUS, the > > signal "payload" includes a pointer to a sigcontext > > structure on the stack, containing the state of the > > CPU when the exception associated with the signal > > occurred. But not exactly. We seem to consistently > > call compute_return_epc() before send_sig() or > > force_sig(). This results in the user being passed > > an indication of the faulting PC that is one instruction > > past the true location. That would be no problem, > > except that the faulting instruction may have been > > in a branch delay slot, such that there is no practical > > and reliable way for the signal handler to determine > > which instruction failed on the basis of the sigcontext > > data. > > > > It is, of course, important that execution resume > > at the instruction following any instruction generating > > an exception/signal. But that's not the same thing > > as saying that the sigcontext should report the resumption > > EPC instead of the faulting EPC. There are various > > ways of dealing with this, but before going into any > > of them, I'm curious as to whether this has been > > discussed before, and whether anyone thinks that > > things really should be the way they are. > > Our signal stackframe is almost the same as on IRIX5 which is what > some software expects. Maybe time to checkout what IRIX does ... The IRIX team made some stunningly bad design decisions over the years, my favorite being "virtual swap space" and its side effect of deliberately killing system daemons at random under load. A signal scheme such as we have now in MIPS/Linux, where a user program *cannot* identify the instruction causing a signal if that instruction was in the delay slot of a taken branch, is broken from first principles. Kevin K. From owner-linux-mips@oss.sgi.com Fri Jul 12 02:04:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C945Rw016853 for ; Fri, 12 Jul 2002 02:04:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C945Ss016852 for linux-mips-outgoing; Fri, 12 Jul 2002 02:04:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C93nRw016838 for ; Fri, 12 Jul 2002 02:03:50 -0700 Received: from e02.toshiba.de ([194.76.49.35]) by smtp01ffm.de.uu.net (5.5.5/5.5.5) with SMTP id LAA26656 for ; Fri, 12 Jul 2002 11:08:25 +0200 (MET DST) Received: FROM dus05a.tsb-eu.com BY e02.toshiba.de ; Fri Jul 12 11:08:22 2002 +0200 Received: from dus04a.tsb-eu.com ([194.39.88.158]) by dus05a.tsb-eu.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 11:08:22 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Date: Fri, 12 Jul 2002 11:08:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Thread-Index: AcIo+RJwV6xhrMQsQLyh3JmpnsUzjwAfFEjA From: "Sedjai, Mohamed" To: "Jon Burgess" , "Ralf Baechle" Cc: "Gleb O. Raiko" , , X-OriginalArrivalTime: 12 Jul 2002 09:08:23.0132 (UTC) FILETIME=[AC8001C0:01C22983] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6C93pRw016841 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello everybody, I've been following this thread with much attention and interest, and I would like to give my small contribution, even though my expertise is far lower than yours. Our TX49 (R4000 based) manual also states that "if the CACHE instruction is issued for the line in which this instruction exists the operation is not guaranted". As you can see from the arch/mips/mm/r4xx0.c file, TX49 routines always disable caches before operating. Recently, one of our customer, raised the question since he was comparing performance between TX49 and another comparable MIPS architecture. He noticed a huge difference in favor of the other vendor. For information it was a multimedia application. Investigations showed that the other vendor was running cache flushing operations cached. He tried to also run TX49 cached and, miracle, TX49 performed much better than the other chip. And the application could run for hours without crashing. I have contacted our designers, and the answer I got so far is that a problem can occur depending on the alignement of the CACHE instructions and on the set in which they are located (TX49 cache is 4 way set). This confirms Jon's investigation. Carsten, can you comment this, as a MIPS insider ? Which CPUs are concerned ? Further investigation are now ongoing to find a proper workaround and thus suggestions are highly apreciated. >From my side I have a very simple question: If you run instruction cache flushing cached, then the cache will be dirty when the routine returns. At least the line(s) containing the routine itself ? Or am I missing something ? Best Regards, Mohamed SEDJAI TOSHIBA Electronics Europe PS: Sorry Dominic for a possible misusage of the terminology. BTW I found your book wonderfully well written and consider it as a reference to anyone who wants to write a technical book. -----Original Message----- From: Jon Burgess [mailto:Jon_Burgess@eur.3com.com] Sent: Donnerstag, 11. Juli 2002 18:34 To: Ralf Baechle Cc: Gleb O. Raiko; linux-mips@oss.sgi.com; carstenl@mips.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 > Ralf wrote: >Have you tried to insert a large number of nops instead? My investigation suggests that a single extra nop is sufficient. I have also tried inserting extra nops before the cache routine to see if the relative alignment of the instructions with respect to the cacheline has an influence, but it has no effect. I am suspicious that if this occurs with the instruction following the loop then something odd might be occuring on every loop iteration as well. I might try adjusting the instructions in the loop to see if that has any effect. > Or preferably, >how about replacing the __restore_flags() in your example with the >following piece of inline assembler: > > __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory"); I am happy that the current assembler code looks correct, but this change would make it simpler. Jon From owner-linux-mips@oss.sgi.com Fri Jul 12 02:15:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C9FdRw017070 for ; Fri, 12 Jul 2002 02:15:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C9Fd0H017069 for linux-mips-outgoing; Fri, 12 Jul 2002 02:15:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C9EgRw017051; Fri, 12 Jul 2002 02:14:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6C9IRXb015663; Fri, 12 Jul 2002 02:18:27 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA28385; Fri, 12 Jul 2002 02:18:24 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6C9IOb12196; Fri, 12 Jul 2002 11:18:24 +0200 (MEST) Message-ID: <3D2E9EDF.C8DA9FF5@mips.com> Date: Fri, 12 Jul 2002 11:18:23 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jon Burgess CC: "Gleb O. Raiko" , Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <80256BF3.00366849.00@notesmta.eur.3com.com> Content-Type: multipart/mixed; boundary="------------21F4CFB1A6461EDD2D3FD0B4" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------21F4CFB1A6461EDD2D3FD0B4 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit One thing that just stroke me, I've made some changes to the MIPS32 cache routine last month. I just realized it hadn't made it into the CVS tree. It doesn't explain what you are seeing, but it fixes some problem that you might get. One of the things it fix, is a typo, which will hit you because you have different size of the I- and D-caches. But it also fix, that in a lot of the cache routine, we only flush one of the ways. Please see the attached patch, I think Ralf didn't liked it, because it wasn't optimized for speed, but at least it's better than what we got. /Carsten Jon Burgess wrote: > >This sound more like a hardware bug to me. > >What CPU are you running on ? > > > >/Carsten > > The CPU is a Broadcom BCM6352 which contains a 225Mhz Mips32 core with cache as > follows: > 16Kb Instruction cache, linesize 16 bytes (2 ways) > 4Kb Data cache, linesize 16 byes (2 ways) > I don't know the exact variant of the core but the chip has only been recently > released. I will try asking my Broadcom contacts to see if they can shed any > further light on this. > > >Ralf Baechle wrote: > >> > >> While that could be done it's not a good idea; running code in KSEG1 is > >> very slow. > >> > > > >Unfortunately, it's required by manuals for some processors. As I know, > >IDT HW manuals clearly state cache flush routines must operate from > >uncached code and must access uncached data only. Examples are R30x1 CPU > >series. > > > >Regards, > >Gleb. > > I'm fairly sure i've seen comments that say that cache manipulation code should > be run uncached. My current thought is that it is probably safe to manipulate > the d-cache with cached code, but I-cache manipulation which could invalidate > the cacheline containing the currently executing code really should be run > uncached. I think the CPU probably then skips instructions until it gets to the > next cacheline, what effect this has depends on how the instructions are aligned > relative to the cacheline. Given how hit-and-miss this is I am suspicous that > this problem could simply be lurking undiscovered. > > The patch below makes the I-Cache routines run via kseg1, it is a bit ugly but > seems to work. I have not measured the performance impact of this patch. > > diff -Nruw --exclude=CVS include/asm-mips-old/mips32_cache.h > include/asm-mips/mips32_cache.h > --- include/asm-mips-old/mips32_cache.h Wed Apr 10 22:53:12 2002 > +++ include/asm-mips/mips32_cache.h Thu Jul 11 10:25:06 2002 > @@ -219,37 +219,24 @@ > } > } > > +/* Call I-cache manipulation routines via uncached kseg1 */ > +extern void mips32_blast_icache(void); > +extern void mips32_blast_icache_page(unsigned long page); > +extern void mips32_blast_icache_page_indexed(unsigned long page); > + > static inline void blast_icache(void) > { > - unsigned long start = KSEG0; > - unsigned long end = (start + icache_size); > - > - while(start < end) { > - cache_unroll(start,Index_Invalidate_I); > - start += ic_lsize; > - } > + ((void (*)(void))KSEG1ADDR((unsigned long)mips32_blast_icache))(); > } > > static inline void blast_icache_page(unsigned long page) > { > - unsigned long start = page; > - unsigned long end = (start + PAGE_SIZE); > - > - while(start < end) { > - cache_unroll(start,Hit_Invalidate_I); > - start += ic_lsize; > - } > + ((void (*)(unsigned long))KSEG1ADDR((unsigned > long)mips32_blast_icache_page))(page); > } > > static inline void blast_icache_page_indexed(unsigned long page) > { > - unsigned long start = page; > - unsigned long end = (start + PAGE_SIZE); > - > - while(start < end) { > - cache_unroll(start,Index_Invalidate_I); > - start += ic_lsize; > - } > + ((void (*)(unsigned long))KSEG1ADDR((unsigned > long)mips32_blast_icache_page_indexed))(page); > } > > static inline void blast_scache(void) > diff -Nurw arch/mips/mm-old/c-mips32.c arch/mips/mm/c-mips32.c > --- arch/mips/mm-old/c-mips32.c Thu May 23 15:19:36 2002 > +++ arch/mips/mm/c-mips32.c Thu Jul 11 10:21:02 2002 > @@ -708,3 +708,36 @@ > > __flush_cache_all(); > } > + > +void mips32_blast_icache(void) > +{ > + unsigned long start = KSEG0; > + unsigned long end = (start + icache_size); > + > + while(start < end) { > + cache_unroll(start,Index_Invalidate_I); > + start += ic_lsize; > + } > +} > + > +void mips32_blast_icache_page(unsigned long page) > +{ > + unsigned long start = page; > + unsigned long end = (start + PAGE_SIZE); > + > + while(start < end) { > + cache_unroll(start,Hit_Invalidate_I); > + start += ic_lsize; > + } > +} > + > +void mips32_blast_icache_page_indexed(unsigned long page) > +{ > + unsigned long start = page; > + unsigned long end = (start + PAGE_SIZE); > + > + while(start < end) { > + cache_unroll(start,Index_Invalidate_I); > + start += ic_lsize; > + } > +} > > Jon Burgess -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com --------------21F4CFB1A6461EDD2D3FD0B4 Content-Type: text/plain; charset=iso-8859-15; name="cache.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cache.patch" --- arch/mips/mm/c-mips32.c Wed May 29 05:03:17 2002 +++ ../../linux-2.4.18/sw/linux-2.4.18/arch/mips/mm/c-mips32.c Thu Jul 11 09:55:08 2002 @@ -17,7 +17,6 @@ * * MIPS32 CPU variant specific MMU/Cache routines. */ -#include #include #include #include @@ -75,7 +74,8 @@ unsigned long flags; __save_and_cli(flags); - blast_dcache(); blast_icache(); + blast_dcache(); + blast_icache(); __restore_flags(flags); } @@ -303,7 +303,7 @@ if (!(vma->vm_flags & VM_EXEC)) return; - address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (dcache_size - 1)); + address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (icache_size - 1)); blast_icache_page_indexed(address); } @@ -317,7 +317,7 @@ unsigned int flags; if (size >= dcache_size) { - flush_cache_all(); + blast_dcache(); } else { __save_and_cli(flags); a = addr & ~(dc_lsize - 1); @@ -338,7 +338,7 @@ unsigned long end, a; if (size >= scache_size) { - flush_cache_all(); + blast_scache(); return; } @@ -358,13 +358,13 @@ unsigned int flags; if (size >= dcache_size) { - flush_cache_all(); + blast_dcache(); } else { __save_and_cli(flags); a = addr & ~(dc_lsize - 1); end = (addr + size) & ~(dc_lsize - 1); while (1) { - flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + invalidate_dcache_line(a); /* Hit_Inv_D */ if (a == end) break; a += dc_lsize; } @@ -380,14 +380,14 @@ unsigned long end, a; if (size >= scache_size) { - flush_cache_all(); + blast_scache(); return; } a = addr & ~(sc_lsize - 1); end = (addr + size) & ~(sc_lsize - 1); while (1) { - flush_scache_line(a); /* Hit_Writeback_Inv_SD */ + invalidate_scache_line(a); /* Hit_Writeback_Inv_SD */ if (a == end) break; a += sc_lsize; } --- include/asm-mips/mips32_cache.h Wed Jul 3 08:30:08 2002 +++ ../../linux-2.4.18/sw/linux-2.4.18/include/asm-mips/mips32_cache.h Mon Jun 24 13:17:36 2002 @@ -37,41 +37,65 @@ static inline void flush_icache_line_indexed(unsigned long addr) { - __asm__ __volatile__( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache %1, (%0)\n\t" - ".set mips0\n\t" - ".set reorder" - : - : "r" (addr), - "i" (Index_Invalidate_I)); + unsigned long waystep = icache_size/mips_cpu.icache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.icache.ways; way++) + { + __asm__ __volatile__( + ".set noreorder\n\t" + ".set mips3\n\t" + "cache %1, (%0)\n\t" + ".set mips0\n\t" + ".set reorder" + : + : "r" (addr), + "i" (Index_Invalidate_I)); + + addr += waystep; + } } static inline void flush_dcache_line_indexed(unsigned long addr) { - __asm__ __volatile__( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache %1, (%0)\n\t" - ".set mips0\n\t" - ".set reorder" - : - : "r" (addr), - "i" (Index_Writeback_Inv_D)); + unsigned long waystep = dcache_size/mips_cpu.dcache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.dcache.ways; way++) + { + __asm__ __volatile__( + ".set noreorder\n\t" + ".set mips3\n\t" + "cache %1, (%0)\n\t" + ".set mips0\n\t" + ".set reorder" + : + : "r" (addr), + "i" (Index_Writeback_Inv_D)); + + addr += waystep; + } } static inline void flush_scache_line_indexed(unsigned long addr) { - __asm__ __volatile__( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache %1, (%0)\n\t" - ".set mips0\n\t" - ".set reorder" - : - : "r" (addr), - "i" (Index_Writeback_Inv_SD)); + unsigned long waystep = scache_size/mips_cpu.scache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.scache.ways; way++) + { + __asm__ __volatile__( + ".set noreorder\n\t" + ".set mips3\n\t" + "cache %1, (%0)\n\t" + ".set mips0\n\t" + ".set reorder" + : + : "r" (addr), + "i" (Index_Writeback_Inv_SD)); + + addr += waystep; + } } static inline void flush_icache_line(unsigned long addr) @@ -210,12 +234,17 @@ static inline void blast_dcache_page_indexed(unsigned long page) { - unsigned long start = page; - unsigned long end = (start + PAGE_SIZE); - - while(start < end) { - cache_unroll(start,Index_Writeback_Inv_D); - start += dc_lsize; + unsigned long start; + unsigned long end = (page + PAGE_SIZE); + unsigned long waystep = dcache_size/mips_cpu.dcache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.dcache.ways; way++) { + start = page + way*waystep; + while(start < end) { + cache_unroll(start,Index_Writeback_Inv_D); + start += dc_lsize; + } } } @@ -243,12 +272,17 @@ static inline void blast_icache_page_indexed(unsigned long page) { - unsigned long start = page; - unsigned long end = (start + PAGE_SIZE); - - while(start < end) { - cache_unroll(start,Index_Invalidate_I); - start += ic_lsize; + unsigned long start; + unsigned long end = (page + PAGE_SIZE); + unsigned long waystep = icache_size/mips_cpu.icache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.icache.ways; way++) { + start = page + way*waystep; + while(start < end) { + cache_unroll(start,Index_Invalidate_I); + start += ic_lsize; + } } } @@ -276,12 +310,17 @@ static inline void blast_scache_page_indexed(unsigned long page) { - unsigned long start = page; - unsigned long end = page + PAGE_SIZE; - - while(start < end) { - cache_unroll(start,Index_Writeback_Inv_SD); - start += sc_lsize; + unsigned long start; + unsigned long end = (page + PAGE_SIZE); + unsigned long waystep = scache_size/mips_cpu.scache.ways; + unsigned int way; + + for (way = 0; way < mips_cpu.scache.ways; way++) { + start = page + way*waystep; + while(start < end) { + cache_unroll(start,Index_Writeback_Inv_SD); + start += sc_lsize; + } } } --------------21F4CFB1A6461EDD2D3FD0B4-- From owner-linux-mips@oss.sgi.com Fri Jul 12 02:22:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C9MwRw017253 for ; Fri, 12 Jul 2002 02:22:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C9Mw9I017252 for linux-mips-outgoing; Fri, 12 Jul 2002 02:22:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C9MdRw017237; Fri, 12 Jul 2002 02:22:42 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA15525; Fri, 12 Jul 2002 11:26:41 +0200 (MET DST) Date: Fri, 12 Jul 2002 11:26:41 +0200 (MEST) From: Geert Uytterhoeven To: "Sedjai, Mohamed" cc: Jon Burgess , Ralf Baechle , "Gleb O. Raiko" , Linux/MIPS Development , carstenl@mips.com Subject: RE: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 12 Jul 2002, Sedjai, Mohamed wrote: > If you run instruction cache flushing cached, then the cache will be dirty > when the routine returns. At least the line(s) containing the routine itself ? > Or am I missing something ? Since the contents of the instruction cache are never changed (except by a cache load), an instruction cache line can never become dirty. Dirty cache lines and cache line write back are an exclusive privilege of write back data caches. 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 Fri Jul 12 02:37:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C9bZRw017856 for ; Fri, 12 Jul 2002 02:37:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C9bZ2D017854 for linux-mips-outgoing; Fri, 12 Jul 2002 02:37:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C9bHRw017844; Fri, 12 Jul 2002 02:37:18 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6C9f2Xb015725; Fri, 12 Jul 2002 02:41:02 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA29174; Fri, 12 Jul 2002 02:41:00 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6C9f0b14558; Fri, 12 Jul 2002 11:41:00 +0200 (MEST) Message-ID: <3D2EA42B.5270BF76@mips.com> Date: Fri, 12 Jul 2002 11:40:59 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Sedjai, Mohamed" CC: Jon Burgess , Ralf Baechle , "Gleb O. Raiko" , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Sedjai, Mohamed" wrote: > Hello everybody, > > I've been following this thread with much attention and interest, > and I would like to give my small contribution, even though my expertise > is far lower than yours. > > Our TX49 (R4000 based) manual also states that "if the CACHE instruction > is issued for the line in which this instruction exists the operation > is not guaranted". As you can see from the arch/mips/mm/r4xx0.c file, > TX49 routines always disable caches before operating. > > Recently, one of our customer, raised the question since he was comparing > performance between TX49 and another comparable MIPS architecture. > He noticed a huge difference in favor of the other vendor. > For information it was a multimedia application. Investigations > showed that the other vendor was running cache flushing operations cached. > He tried to also run TX49 cached and, miracle, TX49 performed much better > than the other chip. And the application could run for hours without > crashing. > > I have contacted our designers, and the answer I got so far is that a problem can > occur depending on the alignement of the CACHE instructions and on the set > in which they are located (TX49 cache is 4 way set). This confirms Jon's > investigation. Carsten, can you comment this, as a MIPS insider ? Which > CPUs are concerned ? I can only speak for our own products (4Kc serie, 5Kc serie and 20Kc). They have no problem with running the cache routine from cached space. "Index load/store Tag" cache operation instructions, however should be executed from uncached space, but they are not used in linux. > > Further investigation are now ongoing to find a proper workaround and thus suggestions > are highly apreciated. > > >From my side I have a very simple question: > > If you run instruction cache flushing cached, then the cache will be dirty > when the routine returns. At least the line(s) containing the routine itself ? > Or am I missing something ? > > Best Regards, > > Mohamed SEDJAI > TOSHIBA Electronics Europe > > PS: Sorry Dominic for a possible misusage of the terminology. BTW I found your book > wonderfully well written and consider it as a reference to anyone who wants > to write a technical book. > > -----Original Message----- > From: Jon Burgess [mailto:Jon_Burgess@eur.3com.com] > Sent: Donnerstag, 11. Juli 2002 18:34 > To: Ralf Baechle > Cc: Gleb O. Raiko; linux-mips@oss.sgi.com; carstenl@mips.com > Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with > gcc-2.96 > > > Ralf wrote: > >Have you tried to insert a large number of nops instead? > > My investigation suggests that a single extra nop is sufficient. I have also > tried inserting extra nops before the cache routine to see if the relative > alignment of the instructions with respect to the cacheline has an influence, > but it has no effect. I am suspicious that if this occurs with the instruction > following the loop then something odd might be occuring on every loop iteration > as well. I might try adjusting the instructions in the loop to see if that has > any effect. > > > Or preferably, > >how about replacing the __restore_flags() in your example with the > >following piece of inline assembler: > > > > __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory"); > > I am happy that the current assembler code looks correct, but this change would > make it simpler. > > Jon -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Fri Jul 12 02:56:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6C9u1Rw018040 for ; Fri, 12 Jul 2002 02:56:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6C9u1Kv018039 for linux-mips-outgoing; Fri, 12 Jul 2002 02:56:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f201.dialo.tiscali.de [62.246.18.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6C9trRw018021 for ; Fri, 12 Jul 2002 02:55:54 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6CA0O820810; Fri, 12 Jul 2002 12:00:24 +0200 Date: Fri, 12 Jul 2002 12:00:24 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User Message-ID: <20020712120024.A20727@dea.linux-mips.net> References: <00b401c228ba$88b29bf0$10eca8c0@grendel> <20020712034015.C16608@dea.linux-mips.net> <003301c2297a$380ed400$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003301c2297a$380ed400$10eca8c0@grendel>; from kevink@mips.com on Fri, Jul 12, 2002 at 10:00:27AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jul 12, 2002 at 10:00:27AM +0200, Kevin D. Kissell wrote: > The IRIX team made some stunningly bad design > decisions over the years, my favorite being "virtual > swap space" and its side effect of deliberately killing > system daemons at random under load. A signal scheme > such as we have now in MIPS/Linux, where a user program > *cannot* identify the instruction causing a signal if > that instruction was in the delay slot of a taken branch, > is broken from first principles. Certainly you're right when you say a signal handler show know which instruction was causing a fault. Ours is simply a too bad implementation of their interface ... IRIX virtual swap space is simply memory overcommit. Linux has that too and it's been subject to frequent religious discussions on Linux kernel. Non-overcommit means large amounts of memory are required when forking of a new process. The standard example is a fat bloated Mozilla forking for printing. Non-overcommit means you need those 50 or 100 megs of Mozilla process size once more and if not as physical memory then at least as swap space. Deciede yourself if you're paranoid and want that operation to only succeed if that much memory is actually available or if you take the risk of the fork & exec operation failing the other way. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 12 03:23:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CANHRw018284 for ; Fri, 12 Jul 2002 03:23:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CANHDO018283 for linux-mips-outgoing; Fri, 12 Jul 2002 03:23:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CAN6Rw018274 for ; Fri, 12 Jul 2002 03:23:10 -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 OAA19376; Fri, 12 Jul 2002 14:27:30 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA32163; Fri, 12 Jul 2002 14:25:05 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA24830; Fri, 12 Jul 2002 14:22:26 +0400 (MSK) Message-ID: <3D2EAEF2.C06AFD05@niisi.msk.ru> Date: Fri, 12 Jul 2002 14:26:58 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Thu, 11 Jul 2002, Gleb O. Raiko wrote: > > > Have to check the cacheline at given address again. D-cache may have the > > valid bit set for the cacheline at the same address. Address means > > location in a cache, not memory. Check at address requires one extra > > tick as opposed to checking the bit. > > Well, you issue an instruction word read from the cache. The answer is > either a hit, providing a word at the data bus at the same time (so you > can't get a hit from one cache and data from the other) or a miss with no > valid data -- you have to stall in this case, waiting for a refill. Let it be miss and stall. >Then > when data from the main memory arrives, it is latched in the cache (it > doesn't really matter, which one now -- if it's the wrong one, then > another refill will happen next time the memory address is dereferenced) > and provided to the CPU at the same time. At this time, CPU continues the execution of previous stalled instruction. CPU knows the stalled instruction is in I-cache, but, unfortunately, caches have been swapped already. The same cacheline in the D-cache was valid bit set. CPU get data instead of code. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Jul 12 03:33:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CAXdRw018484 for ; Fri, 12 Jul 2002 03:33:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CAXdnu018483 for linux-mips-outgoing; Fri, 12 Jul 2002 03:33:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CAXURw018474; Fri, 12 Jul 2002 03:33:32 -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 OAA19583; Fri, 12 Jul 2002 14:37:29 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA32220; Fri, 12 Jul 2002 14:35:13 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA25312; Fri, 12 Jul 2002 14:32:38 +0400 (MSK) Message-ID: <3D2EB157.E90A2CBC@niisi.msk.ru> Date: Fri, 12 Jul 2002 14:37:11 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Dominic Sweetman CC: "Maciej W. Rozycki" , Ralf Baechle , Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: <20020711131247.A11700@dea.linux-mips.net> <15662.3715.334923.669657@gladsmuir.algor.co.uk> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dominic Sweetman wrote: > PS: my standard appeal. When you say you 'flush' a cache do you mean > invalidate, write-back, or both? I personally mean the routine has 'flush' in its name. So, 'to flush a cache' just mens 'to call this routine'. Considering the name belongs to the common code (as opposed to the arch specific code), I doubt the name shall be changed. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Jul 12 04:44:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CBidRw019460 for ; Fri, 12 Jul 2002 04:44:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CBidEf019459 for linux-mips-outgoing; Fri, 12 Jul 2002 04:44:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CBiTRw019450; Fri, 12 Jul 2002 04:44:29 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6CBmxXb015987; Fri, 12 Jul 2002 04:49:00 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA03764; Fri, 12 Jul 2002 04:48:58 -0700 (PDT) Message-ID: <008e01c2299a$3268da30$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: References: <00b401c228ba$88b29bf0$10eca8c0@grendel> <20020712034015.C16608@dea.linux-mips.net> <003301c2297a$380ed400$10eca8c0@grendel> <20020712120024.A20727@dea.linux-mips.net> Subject: Re: Sigcontext->sc_pc Passed to User Date: Fri, 12 Jul 2002 13:49:15 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: "Ralf Baechle" > On Fri, Jul 12, 2002 at 10:00:27AM +0200, Kevin D. Kissell wrote: > > > The IRIX team made some stunningly bad design > > decisions over the years, my favorite being "virtual > > swap space" and its side effect of deliberately killing > > system daemons at random under load. A signal scheme > > such as we have now in MIPS/Linux, where a user program > > *cannot* identify the instruction causing a signal if > > that instruction was in the delay slot of a taken branch, > > is broken from first principles. > > Certainly you're right when you say a signal handler show know which > instruction was causing a fault. Ours is simply a too bad implementation > of their interface ... > > IRIX virtual swap space is simply memory overcommit. Linux has that too > and it's been subject to frequent religious discussions on Linux kernel. > Non-overcommit means large amounts of memory are required when forking > of a new process. The standard example is a fat bloated Mozilla forking > for printing. Non-overcommit means you need those 50 or 100 megs of > Mozilla process size once more and if not as physical memory then at > least as swap space. Deciede yourself if you're paranoid and want that > operation to only succeed if that much memory is actually available or > if you take the risk of the fork & exec operation failing the other way. Whenever it's been my design responsibility, I made forks fail if there wasn't enough backing store to handle the process. Frankly, there are limits to the degree to which an OS should compromise its integrity for the sake of supporting badly concieved applications, be they Mozilla or the SGI integrated CAD environment. But even if you prefer to take the "speculative" or "optimistic" model for handling the situation, what IRIX did was insane: When, after having allowed too many unsupportable forks to succeed, they detected deadlock in the swap system, they killed processes *at random*. Including system daemons. At a *minimum*, a system should only terminate processes belonging to the user (and preferably the process group) who has been granted speculative fork success. Anything else is a massive "breach of contract" for a multiuser OS. IMHO, if someone really wanted to fix this in the OS, we'd get beyond the traditional Unix "fork" model. And if someone really wanted to avoid the problem in Mozilla or an IDE, one would have all subprograms launched by a tiny "launcher", who would recieve instructions and data via some form of IPC, fork itself, and exec as appropriate. But this is getting a bit off the topic. Is anyone aware of any IRIX applications ported to Linux that would break if we corrected the signal payload semantics? Kevin K. From owner-linux-mips@oss.sgi.com Fri Jul 12 05:59:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CCxNRw024815 for ; Fri, 12 Jul 2002 05:59:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CCxNEp024814 for linux-mips-outgoing; Fri, 12 Jul 2002 05:59:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CCxKRw024805 for ; Fri, 12 Jul 2002 05:59:20 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6CD3pXb016106 for ; Fri, 12 Jul 2002 06:03:51 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA07976 for ; Fri, 12 Jul 2002 06:03:51 -0700 (PDT) Message-ID: <00ce01c229a4$a7d4ed40$10eca8c0@grendel> From: "Kevin D. Kissell" To: Subject: Mipsel libc with LL/SC online anywhere? Date: Fri, 12 Jul 2002 15:04:07 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm benchmarking some code that does lots of semaphores, and with the libc from the "standard" MIPS/SGI RH 7.1 distribution, those are done using sysmips, in the interest of universality. Regardles of whether and how the ongoing argument of How Things Should Be is settled, is there a copy of an up-to-date glibc package built to use ll/sc out there on anyone's FTP or web server? I suppose I could extract and replace the necessary routines by hand, but that would be slow and fraught with the risk of error... Regards, Kevin K. From owner-linux-mips@oss.sgi.com Fri Jul 12 06:16:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CDGsRw025246 for ; Fri, 12 Jul 2002 06:16:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CDGsiI025245 for linux-mips-outgoing; Fri, 12 Jul 2002 06:16:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CDGhRw025234; Fri, 12 Jul 2002 06:16:46 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17T03Y-0002tg-00; Fri, 12 Jul 2002 14:01:56 +0100 Subject: Re: Sigcontext->sc_pc Passed to User To: ralf@oss.sgi.com (Ralf Baechle) Date: Fri, 12 Jul 2002 14:01:56 +0100 (BST) Cc: kevink@mips.com (Kevin D. Kissell), linux-mips@oss.sgi.com In-Reply-To: <20020712120024.A20727@dea.linux-mips.net> from "Ralf Baechle" at Jul 12, 2002 12:00:24 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Non-overcommit means large amounts of memory are required when forking > of a new process. The standard example is a fat bloated Mozilla forking > for printing. Non-overcommit means you need those 50 or 100 megs of > Mozilla process size once more and if not as physical memory then at > least as swap space. Deciede yourself if you're paranoid and want that > operation to only succeed if that much memory is actually available or > if you take the risk of the fork & exec operation failing the other way. Your numbers are ridiculously off. A mozilla instance on x86 commits 17Mb of potentially swap backed memory when viewing the mozilla 1.0 start page. (Its actually a bit less but there is delay in the garbage collector) 2.4.18/19-ac support non overcommit, and its rather useful Alan From owner-linux-mips@oss.sgi.com Fri Jul 12 07:19:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CEJMRw025767 for ; Fri, 12 Jul 2002 07:19:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CEJLL2025766 for linux-mips-outgoing; Fri, 12 Jul 2002 07:19:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f41.dialo.tiscali.de [62.246.16.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CEJCRw025757 for ; Fri, 12 Jul 2002 07:19:14 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6CENMK18810; Fri, 12 Jul 2002 16:23:22 +0200 Date: Fri, 12 Jul 2002 16:23:22 +0200 From: Ralf Baechle To: Alan Cox Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User Message-ID: <20020712162322.A18691@dea.linux-mips.net> References: <20020712120024.A20727@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Jul 12, 2002 at 02:01:56PM +0100 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jul 12, 2002 at 02:01:56PM +0100, Alan Cox wrote: > > Non-overcommit means large amounts of memory are required when forking > > of a new process. The standard example is a fat bloated Mozilla forking > > for printing. Non-overcommit means you need those 50 or 100 megs of > > Mozilla process size once more and if not as physical memory then at > > least as swap space. Deciede yourself if you're paranoid and want that > > operation to only succeed if that much memory is actually available or > > if you take the risk of the fork & exec operation failing the other way. > > Your numbers are ridiculously off. > > A mozilla instance on x86 commits 17Mb of potentially swap backed memory > when viewing the mozilla 1.0 start page. (Its actually a bit less but there > is delay in the garbage collector) These were typical numbers of the last Mozilla I hacked myself on MIPS. It can grow larger without doing alot. Aside of that this isn't Mozilla specific; any arbitrary program that does some fork & exec thing and it's memory size could be choosen. > 2.4.18/19-ac support non overcommit, and its rather useful No doubt about that. I just say non overcommit has been subject to long discussions and as usually in such religious discussions both sides had valid arguments. I leave it to everybody to choose his / her own poison. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 12 08:08:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CF8NRw031076 for ; Fri, 12 Jul 2002 08:08:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CF8N9t031075 for linux-mips-outgoing; Fri, 12 Jul 2002 08:08:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CF7vRw031066; Fri, 12 Jul 2002 08:08:14 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17T2Sz-0003EN-00; Fri, 12 Jul 2002 16:36:21 +0100 Subject: Re: Sigcontext->sc_pc Passed to User To: ralf@oss.sgi.com (Ralf Baechle) Date: Fri, 12 Jul 2002 16:36:21 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), kevink@mips.com (Kevin D. Kissell), linux-mips@oss.sgi.com In-Reply-To: <20020712162322.A18691@dea.linux-mips.net> from "Ralf Baechle" at Jul 12, 2002 04:23:22 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > A mozilla instance on x86 commits 17Mb of potentially swap backed memory > > when viewing the mozilla 1.0 start page. (Its actually a bit less but there > > is delay in the garbage collector) > > These were typical numbers of the last Mozilla I hacked myself on MIPS. > It can grow larger without doing alot. Aside of that this isn't Mozilla > specific; any arbitrary program that does some fork & exec thing and > it's memory size could be choosen. These are precise page accurate measurements from the real world. What most people forget is that very little of an ELF application is actually swap backed as opposed to file backed read only From owner-linux-mips@oss.sgi.com Fri Jul 12 08:20:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CFKqRw006599 for ; Fri, 12 Jul 2002 08:20:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CFKpY2006598 for linux-mips-outgoing; Fri, 12 Jul 2002 08:20:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CFKiRw006589; Fri, 12 Jul 2002 08:20:44 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6CFQwE28852; Fri, 12 Jul 2002 16:26:58 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6CFPmR19242; Fri, 12 Jul 2002 16:25:48 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF4.00551741 ; Fri, 12 Jul 2002 16:29:25 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: Carsten Langgaard cc: "Gleb O. Raiko" , Ralf Baechle , linux-mips@oss.sgi.com Message-ID: <80256BF4.005515BA.00@notesmta.eur.3com.com> Date: Fri, 12 Jul 2002 16:24:59 +0100 Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >One of the things it fix, is a typo, which will hit you because you have different >size of the I- and D-caches. >But it also fix, that in a lot of the cache routine, we only flush one of the ways. > >Please see the attached patch, I think Ralf didn't liked it, because it wasn't >optimized for speed, but at least it's better than what we got. > >/Carsten The typo was fixed in the code which Broadcom supplied to us. I noticed this was not fixed in the mainstream code and was meaning to submit a patch for it. I will check out the other changes next week. Thanks for the patch. Jon From owner-linux-mips@oss.sgi.com Fri Jul 12 08:25:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CFPNRw006716 for ; Fri, 12 Jul 2002 08:25:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CFPNAP006715 for linux-mips-outgoing; Fri, 12 Jul 2002 08:25:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f41.dialo.tiscali.de [62.246.16.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CFPDRw006706 for ; Fri, 12 Jul 2002 08:25:14 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6CFTkM19542; Fri, 12 Jul 2002 17:29:46 +0200 Date: Fri, 12 Jul 2002 17:29:46 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: Sigcontext->sc_pc Passed to User Message-ID: <20020712172946.B18691@dea.linux-mips.net> References: <00b401c228ba$88b29bf0$10eca8c0@grendel> <20020712034015.C16608@dea.linux-mips.net> <003301c2297a$380ed400$10eca8c0@grendel> <20020712120024.A20727@dea.linux-mips.net> <008e01c2299a$3268da30$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <008e01c2299a$3268da30$10eca8c0@grendel>; from kevink@mips.com on Fri, Jul 12, 2002 at 01:49:15PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Jul 12, 2002 at 01:49:15PM +0200, Kevin D. Kissell wrote: > Whenever it's been my design responsibility, I made forks fail if > there wasn't enough backing store to handle the process. Frankly, > there are limits to the degree to which an OS should compromise > its integrity for the sake of supporting badly concieved applications, > be they Mozilla or the SGI integrated CAD environment. But > even if you prefer to take the "speculative" or "optimistic" model > for handling the situation, what IRIX did was insane: When, after > having allowed too many unsupportable forks to succeed, they > detected deadlock in the swap system, they killed processes > *at random*. Including system daemons. At a *minimum*, > a system should only terminate processes belonging to the > user (and preferably the process group) who has been granted > speculative fork success. Anything else is a massive "breach of > contract" for a multiuser OS. See linux/mm/oom_kill.c:oom_kill() ... > IMHO, if someone really wanted to fix this in the OS, > we'd get beyond the traditional Unix "fork" model. > And if someone really wanted to avoid the problem in Mozilla or > an IDE, one would have all subprograms launched by a tiny > "launcher", who would recieve instructions and data via some > form of IPC, fork itself, and exec as appropriate. That or more Linux specific a clone/vfork & exec approach. > But this is getting a bit off the topic. Is anyone aware of any > IRIX applications ported to Linux that would break if we > corrected the signal payload semantics? As I said we even missimplemented the IRIX semantics. In IRIX the sc_pc field of the frame is pointing to the instruction that was causing the signal while we try to skip over it - with all the side effects that we're just discussing. I tried that for both trap and break instructions. So I suggest we simply remove the compute_return_epc() calls from do_bp and do_trap. I haven't tested this but I'd assume this would also be the behaviour that gdb is expecting. So that would follow the example given by Linux/i386 and IRIX and should your ISV's problem. What more could we ask for. I still have to look over the other exceptions that may call compute_return_epc() but it seems we should do the same thing for all of them and not call compute_return_epc if we're going to send a signal. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 12 08:49:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CFnKRw007172 for ; Fri, 12 Jul 2002 08:49:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CFnK6K007171 for linux-mips-outgoing; Fri, 12 Jul 2002 08:49:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from snog.front.onramp.ca (snog.front.onramp.ca [198.163.180.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CFnFRw007159 for ; Fri, 12 Jul 2002 08:49:15 -0700 Received: (qmail 21547 invoked from network); 12 Jul 2002 15:53:52 -0000 Received: from gateway.hgeng.com (HELO shadowfax.hgeng.com) (199.246.74.82) by 0 with SMTP; 12 Jul 2002 15:53:52 -0000 Received: from dilbert.hgeng.com (dilbert.hgeng.com [192.168.1.6]) by shadowfax.hgeng.com (8.12.1/8.12.1/Debian -3) with ESMTP id g6CFidgO011142 for ; Fri, 12 Jul 2002 11:44:39 -0400 Subject: Re: X server blanking out virtual consoles? From: Michael Hill To: linux-mips@oss.sgi.com In-Reply-To: <20020712075549.GA1569@bogon.ms20.nix> References: <20020712075549.GA1569@bogon.ms20.nix> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1026488672.7814.115.camel@dilbert> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 12 Jul 2002 11:44:33 -0400 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2002-07-12 at 03:55, Guido Guenther wrote: > On Thu, Jul 11, 2002 at 03:38:36PM -0400, Michael Hill wrote: > > /usr/bin/WindowMaker warning: could not allocate color "rgb:93/0d/29" > > etc > This is possibly as close as one can get with 8bpp. I spoke too quickly: even these go away when wmaker is launched from the display manager, rather than from sawfish. CVS Xserver + Dominik's patch = works as expected. Mike From owner-linux-mips@oss.sgi.com Fri Jul 12 11:29:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CITrRw010978 for ; Fri, 12 Jul 2002 11:29:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CITr5x010977 for linux-mips-outgoing; Fri, 12 Jul 2002 11:29:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CITdRw010966; Fri, 12 Jul 2002 11:29:39 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA10764; Fri, 12 Jul 2002 11:33:41 -0700 Message-ID: <3D2F1F41.8030204@mvista.com> Date: Fri, 12 Jul 2002 11:26:09 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Marcelo Tosatti CC: Alan Cox , linux-mips@oss.sgi.com, Ralf Baechle , Jeff Garzik Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Marcelo Tosatti wrote: > > On Thu, 11 Jul 2002, Alan Cox wrote: > > >>>This patch fixes a tx underflow error for 79c973 chip. It essentially delay >>>the transmission until the whole packet is received into the on-chip sdram. >>> >>>The patch is already accepted by Marcelo for the 2.4 tree, I think. >>> >>Which slows the stuff down for people with real computers. Please apply >>some kind of heuristic to this - eg switch to delaying if you exceed >>50 failures in a 60 second period. >> > > I haven't applied it yet. > > I'll let it come to me throught Jeff Garzik after the issues are resolved. > Like I said earlier, I don't believe the benefit of run-time approach is worth the effort. BTW, the heuristic method is not simple, mainly because there are mixed bags of chips in this family which requires different handling in this regard. Since Alan seems to oppose this patch, I will fix this problem for now in the board code/firmware, which is not a totally unreasonable solution anyway. After all the firmware knows this board bus cannot handle 100Mb/s net. If more people report the same problem later, that might be a better time to how to solve this problem. Jun From owner-linux-mips@oss.sgi.com Fri Jul 12 11:35:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CIZNRw011098 for ; Fri, 12 Jul 2002 11:35:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CIZNHG011097 for linux-mips-outgoing; Fri, 12 Jul 2002 11:35:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CIZGRw011088; Fri, 12 Jul 2002 11:35:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA11412; Fri, 12 Jul 2002 20:40:18 +0200 (MET DST) Date: Fri, 12 Jul 2002 20:40:17 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Dominic Sweetman cc: Ralf Baechle , "Gleb O. Raiko" , Carsten Langgaard , Jon Burgess , linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <15662.3715.334923.669657@gladsmuir.algor.co.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 12 Jul 2002, Dominic Sweetman wrote: > PS: my standard appeal. When you say you 'flush' a cache do you mean > invalidate, write-back, or both? If (as I suspect) not all of you > mean the same thing, should you not instead speak of 'invalidate' and > 'writeback'... sloppy language surely leads to sloppy programming? For me, a "flush" is both (i.e., as Gleb noticed, that's what functions with the word in names do). For a lone write back or invalidation, I would use these terms respectively. Well, for the R3k the term is unambiguous 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 Fri Jul 12 11:57:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6CIvhRw011395 for ; Fri, 12 Jul 2002 11:57:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6CIvhhi011394 for linux-mips-outgoing; Fri, 12 Jul 2002 11:57:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6CIvZRw011385 for ; Fri, 12 Jul 2002 11:57:36 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA11662; Fri, 12 Jul 2002 21:02:42 +0200 (MET DST) Date: Fri, 12 Jul 2002 21:02:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D2EAEF2.C06AFD05@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 12 Jul 2002, Gleb O. Raiko wrote: > > Well, you issue an instruction word read from the cache. The answer is > > either a hit, providing a word at the data bus at the same time (so you > > can't get a hit from one cache and data from the other) or a miss with no > > valid data -- you have to stall in this case, waiting for a refill. > > Let it be miss and stall. > > >Then > > when data from the main memory arrives, it is latched in the cache (it > > doesn't really matter, which one now -- if it's the wrong one, then > > another refill will happen next time the memory address is dereferenced) > > and provided to the CPU at the same time. > > At this time, CPU continues the execution of previous stalled We don't care of previous instructions. The pipeline is stalled at the intruction word fetch stage. Previously fetched instructions continue being processed until they leave the pipeline. > instruction. CPU knows the stalled instruction is in I-cache, but, > unfortunately, caches have been swapped already. The same cacheline in > the D-cache was valid bit set. CPU get data instead of code. Well, I certainly understand what you mean, from the beginning, actually, but I still can't see why this would happen for a real implementation. When a cache miss happens an instruction word is read directly from the main memory to the pipeline and a cache fill happens "accidentally". What you describe, would require a CPU to query a cache status somehow during a fill (what if another fill is in progress? -- a cache controller may perform a fill of additional lines itself as it happens in certain implementations) and then issue a second read when the fill completes. That looks weird to me -- why would you design it this way? -- + 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 Sat Jul 13 04:11:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6DBBXRw026926 for ; Sat, 13 Jul 2002 04:11:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6DBBX8p026925 for linux-mips-outgoing; Sat, 13 Jul 2002 04:11:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6DBBQRw026914 for ; Sat, 13 Jul 2002 04:11:26 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6DBG1Xb018992 for ; Sat, 13 Jul 2002 04:16:01 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA24873 for ; Sat, 13 Jul 2002 04:15:59 -0700 (PDT) Message-ID: <023e01c22a5e$c013f120$10eca8c0@grendel> From: "Kevin D. Kissell" To: Subject: Gcc v2.96 versus Trolltech QtEmbedded Window System Date: Sat, 13 Jul 2002 13:15:54 +0200 Organization: MIPS Technologies, Inc. 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to build the GPL version of the Trolltech QT embedded windowing system on my Malta, using what I believe to be H.J. Lu's most recent tool chain: [root@localhost release-emb-generic]# g++ -v Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux-gnu/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1) The QT build process is a little unusual - the configure script causes a fairly huge (640KB) C++ source file to be generated, which is then thrown at the compiler. I would expect that to take a while, but after about 20 hours with zero output passed to the assembler stage (it runs with -pipe) and the gradual accretion of about 90MB of virtual memory (on my poor 32MB system) I concluded that it was probably trapped in an infinite loop. As I have seen this sort of thing occur in the past in optimizer stages, I hacked the makefile to replace -O2 with -O0. It hasn't run for 20 hours at -O0 yet, but after a couple of hours the memory allocation dynamic looks to be the same, only faster (72MB after only a couple of hours), so I'm not optimistic. My questions to the assembled panel of experts are: Are there known problems with gcc 2.96.110.1 in this regard? Is there a native toolchain that would be more likely to be able to handle the build of QT? I'm considering trying the 2.95 set on Maciej's site out of desperation. Has anyone succeeded in building QT Embedded for mips(el) Linux, either native or using cross-tools? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sat Jul 13 05:13:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6DCDcRw028720 for ; Sat, 13 Jul 2002 05:13:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6DCDcBL028719 for linux-mips-outgoing; Sat, 13 Jul 2002 05:13:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6DCDNRw028710 for ; Sat, 13 Jul 2002 05:13:25 -0700 Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17TLoD-0002ls-00; Sat, 13 Jul 2002 08:15:33 -0400 Message-ID: <003c01c22a67$0aab1ee0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Kevin D. Kissell" , References: <023e01c22a5e$c013f120$10eca8c0@grendel> Subject: Re: Gcc v2.96 versus Trolltech QtEmbedded Window System Date: Sat, 13 Jul 2002 08:15:56 -0400 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've built qt 2.3.2 with various toolchains that I've built myself. Most recently I built qt 2.3.2 for mipsel with binutils 2.12, gcc 3.1, and glibc 2.4. Here is how I build my toolchains: http://www.ltc.com/~brad/mips/mips-cross-toolchain I configure qt starting like this: ./configure -xplatform linux-mips-g++ Regards, Brad ----- Original Message ----- From: "Kevin D. Kissell" To: Sent: Saturday, July 13, 2002 7:15 AM Subject: Gcc v2.96 versus Trolltech QtEmbedded Window System > I am trying to build the GPL version of the Trolltech > QT embedded windowing system on my Malta, using > what I believe to be H.J. Lu's most recent tool chain: > > [root@localhost release-emb-generic]# g++ -v > Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux-gnu/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1) > > The QT build process is a little unusual - the configure > script causes a fairly huge (640KB) C++ source file > to be generated, which is then thrown at the compiler. > I would expect that to take a while, but after about > 20 hours with zero output passed to the assembler > stage (it runs with -pipe) and the gradual accretion > of about 90MB of virtual memory (on my poor 32MB > system) I concluded that it was probably trapped in > an infinite loop. As I have seen this sort of thing occur > in the past in optimizer stages, I hacked the makefile > to replace -O2 with -O0. It hasn't run for 20 hours > at -O0 yet, but after a couple of hours the memory > allocation dynamic looks to be the same, only faster > (72MB after only a couple of hours), so I'm not > optimistic. > > My questions to the assembled panel of experts are: > > Are there known problems with gcc 2.96.110.1 in > this regard? > > Is there a native toolchain that would be more > likely to be able to handle the build of QT? > I'm considering trying the 2.95 set on Maciej's > site out of desperation. > > Has anyone succeeded in building QT Embedded > for mips(el) Linux, either native or using cross-tools? > > Regards, > > Kevin K. > > From owner-linux-mips@oss.sgi.com Sat Jul 13 08:55:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6DFtnRw030082 for ; Sat, 13 Jul 2002 08:55:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6DFtnw9030081 for linux-mips-outgoing; Sat, 13 Jul 2002 08:55:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6DFteRw030070 for ; Sat, 13 Jul 2002 08:55:40 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020713160018.EOUH6023.sccrmhc02.attbi.com@ocean.lucon.org>; Sat, 13 Jul 2002 16:00:18 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0A895125D6; Sat, 13 Jul 2002 09:00:16 -0700 (PDT) Date: Sat, 13 Jul 2002 09:00:16 -0700 From: "H. J. Lu" To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: Gcc v2.96 versus Trolltech QtEmbedded Window System Message-ID: <20020713090016.A18723@lucon.org> References: <023e01c22a5e$c013f120$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <023e01c22a5e$c013f120$10eca8c0@grendel>; from kevink@mips.com on Sat, Jul 13, 2002 at 01:15:54PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Jul 13, 2002 at 01:15:54PM +0200, Kevin D. Kissell wrote: > I am trying to build the GPL version of the Trolltech > QT embedded windowing system on my Malta, using > what I believe to be H.J. Lu's most recent tool chain: > > [root@localhost release-emb-generic]# g++ -v > Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux-gnu/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1) > > The QT build process is a little unusual - the configure > script causes a fairly huge (640KB) C++ source file > to be generated, which is then thrown at the compiler. > I would expect that to take a while, but after about > 20 hours with zero output passed to the assembler > stage (it runs with -pipe) and the gradual accretion > of about 90MB of virtual memory (on my poor 32MB > system) I concluded that it was probably trapped in > an infinite loop. As I have seen this sort of thing occur > in the past in optimizer stages, I hacked the makefile > to replace -O2 with -O0. It hasn't run for 20 hours > at -O0 yet, but after a couple of hours the memory > allocation dynamic looks to be the same, only faster > (72MB after only a couple of hours), so I'm not > optimistic. > > My questions to the assembled panel of experts are: > > Are there known problems with gcc 2.96.110.1 in > this regard? Have you tried the same C++ code with the same version of the cross toolchain on Linux/x86? It may just take huge amount of memory. > > Is there a native toolchain that would be more > likely to be able to handle the build of QT? > I'm considering trying the 2.95 set on Maciej's > site out of desperation. > You can try my gcc 3.1 for RedHat 7.3. But it may need more memory. H.J. From owner-linux-mips@oss.sgi.com Sun Jul 14 02:47:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6E9lvRw004284 for ; Sun, 14 Jul 2002 02:47:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6E9lu2W004283 for linux-mips-outgoing; Sun, 14 Jul 2002 02:47:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6E9lqRw004274 for ; Sun, 14 Jul 2002 02:47:53 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6E9qUXb020314 for ; Sun, 14 Jul 2002 02:52:30 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA03294; Sun, 14 Jul 2002 02:52:30 -0700 (PDT) Message-ID: <00a801c22b1c$446a6fe0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , References: <023e01c22a5e$c013f120$10eca8c0@grendel> Subject: Re: Gcc v2.96 versus Trolltech QtEmbedded Window System Date: Sun, 14 Jul 2002 11:53:10 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 613 Lines: 15 Many thanks to all of you who replied with suggestions. I was able to repeat the experiment on a system with essentially the same configuration as my own, except with 256MB of memory instead of 32M. The compilation that took 20 hours to get to 90MB if virtual size completed in something like 5 minutes, with the last sampled virtual footprint being 94MB. Now all I've gotta do is to squeeze the resulting build tree across an ISDN line back to my own system to install, but even if that comes out to hundreds of megabytes, it'll be faster than a local build. ;-) Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sun Jul 14 06:27:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EDReRw010503 for ; Sun, 14 Jul 2002 06:27:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EDRe3U010502 for linux-mips-outgoing; Sun, 14 Jul 2002 06:27:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ux1.ibb.net (ux1.ibb.net [62.8.32.146]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EDRaRw010493 for ; Sun, 14 Jul 2002 06:27:37 -0700 Received: from localhost (dimitri@localhost) by ux1.ibb.net (8.9.3/8.9.3/UX1TT) with ESMTP id PAA03554 for ; Sun, 14 Jul 2002 15:29:35 +0200 Date: Sun, 14 Jul 2002 15:29:35 +0200 (MET DST) From: Dimitri Ars To: Subject: Challenge S second ethernet support ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 183 Lines: 11 Hi all, Is the 2nd ethernet on a challenge S (or indy?) already supported by linux-mips ? (or is there something to try/test ?). I'd love to get that one going ! Thanks, Dimitri From owner-linux-mips@oss.sgi.com Sun Jul 14 06:38:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EDcqRw010614 for ; Sun, 14 Jul 2002 06:38:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EDcq04010613 for linux-mips-outgoing; Sun, 14 Jul 2002 06:38:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from d141-234-174.home.cgocable.net (d141-229-7.home.cgocable.net [24.141.229.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EDcmRw010604 for ; Sun, 14 Jul 2002 06:38:48 -0700 Received: from overlord.linux-dude.com (localhost.localdomain [127.0.0.1]) by d141-234-174.home.cgocable.net (8.11.6/8.8.7) with SMTP id g6EDhW121887 for ; Sun, 14 Jul 2002 09:43:34 -0400 Date: Sun, 14 Jul 2002 09:43:31 -0400 From: Mike Martin To: linux-mips@oss.sgi.com Subject: New Debian Indy... Message-Id: <20020714094331.5207794b.mike@overlord.linux-dude.com> Reply-To: mike.martin@cogeco.ca X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.9; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 589 Lines: 16 I've just successfully loaded Debian/MIPS onto my recently aquired Indy. A huge thank you to all the developers! A few things do not work and I was wondering whether they shouldn't work (ie not supported yet) or whether I've done something wrong. I've checked the resources I know about - but I can't find a good reference on what is and is not supported. Things that don't work: X in 24 bit mode (I have the XL-24, 8 bit X works great) Indy Cam Sound If these should work, I'd appreciate if someone could help me find out how to fix mine! Thanks! Mike Martin mike.martin@cogeco.ca From owner-linux-mips@oss.sgi.com Sun Jul 14 07:03:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EE3PRw010828 for ; Sun, 14 Jul 2002 07:03:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EE3PYV010827 for linux-mips-outgoing; Sun, 14 Jul 2002 07:03:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EE3KRw010818 for ; Sun, 14 Jul 2002 07:03:21 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id DBE9A8D36; Sun, 14 Jul 2002 16:08:06 +0200 (CEST) Date: Sun, 14 Jul 2002 16:08:06 +0200 From: Guido Guenther To: mike.martin@cogeco.ca Cc: linux-mips@oss.sgi.com Subject: Re: New Debian Indy... Message-ID: <20020714160806.A31002@gandalf.physik.uni-konstanz.de> Mail-Followup-To: mike.martin@cogeco.ca, linux-mips@oss.sgi.com References: <20020714094331.5207794b.mike@overlord.linux-dude.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020714094331.5207794b.mike@overlord.linux-dude.com>; from mike@overlord.linux-dude.com on Sun, Jul 14, 2002 at 09:43:31AM -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6EE3LRw010819 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 456 Lines: 19 Hi Mike, On Sun, Jul 14, 2002 at 09:43:31AM -0400, Mike Martin wrote: [..snip..] > Things that don't work: > X in 24 bit mode (I have the XL-24, 8 bit X works great) Not supported in the debian packages but flaky support in XFree86 4.2.0. See http://honk.physik.uni-konstanz.de/linux-mips/x/x.html for details. > Indy Cam Not supported yet. > Sound Install at least the kernel-image-2.4.17-r4k-ip22 package and load the HAL module. Regards, -- Guido From owner-linux-mips@oss.sgi.com Sun Jul 14 12:50:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EJomRw013596 for ; Sun, 14 Jul 2002 12:50:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EJomDH013595 for linux-mips-outgoing; Sun, 14 Jul 2002 12:50:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EJoZRw013585; Sun, 14 Jul 2002 12:50:36 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6EJtFC10297; Sun, 14 Jul 2002 21:55:15 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6EJtGTF018325; Sun, 14 Jul 2002 21:55:16 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17TpSd-0002AB-00; Sun, 14 Jul 2002 21:55:15 +0200 Date: Sun, 14 Jul 2002 21:55:15 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] O2 irq handling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1745 Lines: 57 Hi, Here is a patch for the SGI O2 that fixes a typo in the edge interrupt range checking and protects the irq handler from reentrancy. Vivien. ================================================================================ --- linux/arch/mips64/sgi-ip32/ip32-irq.c Thu Jan 3 21:24:55 2002 +++ linux.build/arch/mips64/sgi-ip32/ip32-irq.c Tue Jan 22 13:01:30 2002 @@ -199,9 +201,9 @@ unsigned long flags; /* Edge triggered interrupts must be cleared. */ - if ((irq <= CRIME_GBE0_IRQ && irq >= CRIME_GBE3_IRQ) - || (irq <= CRIME_RE_EMPTY_E_IRQ && irq >= CRIME_RE_IDLE_E_IRQ) - || (irq <= CRIME_SOFT0_IRQ && irq >= CRIME_SOFT2_IRQ)) { + if ((irq >= CRIME_GBE0_IRQ && irq <= CRIME_GBE3_IRQ) + || (irq >= CRIME_RE_EMPTY_E_IRQ && irq <= CRIME_RE_IDLE_E_IRQ) + || (irq >= CRIME_SOFT0_IRQ && irq <= CRIME_SOFT2_IRQ)) { save_and_cli(flags); crime_mask = crime_read_64(CRIME_HARD_INT); crime_mask &= ~(1 << (irq - 1)); @@ -473,9 +475,18 @@ /* CRIME 1.1 appears to deliver all interrupts to this one pin. */ void ip32_irq0(struct pt_regs *regs) { - u64 crime_int = crime_read_64 (CRIME_INT_STAT); + u64 crime_int; + u64 crime_mask; int irq = 0; - + unsigned long flags; + + save_and_cli (flags); + /* disable crime interrupts */ + crime_mask = crime_read_64(CRIME_INT_MASK); + crime_write_64(CRIME_INT_MASK, 0); + + crime_int = crime_read_64(CRIME_INT_STAT); + if (crime_int & CRIME_MACE_INT_MASK) { crime_int &= CRIME_MACE_INT_MASK; irq = ffs (crime_int); @@ -498,6 +510,10 @@ ip32_unknown_interrupt(regs); DBG("*irq %u*\n", irq); do_IRQ(irq, regs); + + /* enable crime interrupts */ + crime_write_64(CRIME_INT_MASK, crime_mask); + restore_flags (flags); } void ip32_irq1(struct pt_regs *regs) From owner-linux-mips@oss.sgi.com Sun Jul 14 14:03:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EL3LRw014833 for ; Sun, 14 Jul 2002 14:03:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EL3LPg014832 for linux-mips-outgoing; Sun, 14 Jul 2002 14:03:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EL31Rw014820; Sun, 14 Jul 2002 14:03:01 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) 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 OAA05787; Sun, 14 Jul 2002 14:08:10 -0700 (PDT) mail_from (vivien.chappelier@enst-bretagne.fr) Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6EKndC11913; Sun, 14 Jul 2002 22:49:39 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6EKneTF020519; Sun, 14 Jul 2002 22:49:40 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17TqJI-0002F8-00; Sun, 14 Jul 2002 22:49:40 +0200 Date: Sun, 14 Jul 2002 22:49:39 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] O2 coherency Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4632 Lines: 138 Hi, This is a patch to ensure DMA coherency on the SGI O2, by adding the appropriate cache flushes before and after DMA, and setting the default page attribute to cacheable non-coherent. It also fixes the flushed address for the ip27 (offset was missing). Vivien. ================================================================================ diff -Naur linux/arch/mips64/sgi-ip27/ip27-pci-dma.c linux.patch/arch/mips64/sgi-ip27/ip27-pci-dma.c --- linux/arch/mips64/sgi-ip27/ip27-pci-dma.c Thu Jan 3 21:24:54 2002 +++ linux.patch/arch/mips64/sgi-ip27/ip27-pci-dma.c Sun Jul 14 22:29:34 2002 @@ -98,7 +98,8 @@ /* Make sure that gcc doesn't leave the empty loop body. */ for (i = 0; i < nents; i++, sg++) { - sg->address = (char *)(bus_to_baddr[hwdev->bus->number] | __pa(sg->address)); + address = page_address(sg->page) + sg->offset; + sg->dvma_address = (char *)(bus_to_baddr[hwdev->bus->number] | __pa(address)); } return nents; diff -Naur linux/arch/mips64/sgi-ip32/ip32-pci-dma.c linux.patch/arch/mips64/sgi-ip32/ip32-pci-dma.c --- linux/arch/mips64/sgi-ip32/ip32-pci-dma.c Thu Jan 3 21:24:55 2002 +++ linux.patch/arch/mips64/sgi-ip32/ip32-pci-dma.c Sun Jul 14 22:29:34 2002 @@ -44,7 +44,7 @@ dma_cache_wback_inv((unsigned long) ret, size); *dma_handle = ( __pa (ret)); DPRINTK("pci_alloc_consistent: addr=%016lx; dma_handle=%08x\n",(u64)KSEG1ADDR(ret),*dma_handle); - return KSEG1ADDR(ret); + return((void *)KSEG1ADDR(ret)); } DPRINTK("pci_alloc_consistent2: addr=%016lx; dma_handle=%08x\n",(u64)KSEG1ADDR(ret),*dma_handle); return NULL; @@ -85,7 +85,10 @@ if (direction == PCI_DMA_NONE) BUG(); DPRINTK("pci_unmap_single\n"); - /* Nothing to do */ + if (direction != PCI_DMA_TODEVICE) { + mips_wbflush(); + dma_cache_wback_inv((unsigned long)__va(dma_addr), size); + } } /* @@ -108,6 +111,7 @@ int nents, int direction) { int i; + unsigned long address; if (direction == PCI_DMA_NONE) BUG(); @@ -117,9 +121,10 @@ DPRINTK("pci_map_sg\n"); /* Make sure that gcc doesn't leave the empty loop body. */ for (i = 0; i < nents; i++, sg++) { + address = page_address(sg->page) + sg->offset; mips_wbflush(); - dma_cache_wback_inv((unsigned long)sg->address, sg->length); - sg->address = (char *)(__pa(sg->address)); + dma_cache_wback_inv(address, sg->length); + sg->dvma_address = __pa(address); } return nents; @@ -133,10 +138,19 @@ void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { + int i; + unsigned long address; + if (direction == PCI_DMA_NONE) BUG(); DPRINTK("pci_unmap_sg\n"); - /* Nothing to do */ + for (i = 0; i < nents; i++, sg++) { + if (direction != PCI_DMA_TODEVICE) { + address = page_address(sg->page) + sg->offset; + mips_wbflush(); + dma_cache_wback_inv(address, sg->length); + } + } } /* @@ -174,13 +188,16 @@ int nelems, int direction) { int i; + unsigned long address; + if (direction == PCI_DMA_NONE) BUG(); DPRINTK("pci_dma_sync_sg\n"); /* Make sure that gcc doesn't leave the empty loop body. */ for (i = 0; i < nelems; i++, sg++){ + address = page_address(sg->page) + sg->offset; mips_wbflush(); - dma_cache_wback_inv((unsigned long)__va(sg->address), sg->length); + dma_cache_wback_inv(address, sg->length); } /* if(direction==PCI_DMA_TODEVICE) mace_inv_read_buffers();*/ diff -Naur linux/include/asm-mips64/pci.h linux.patch/include/asm-mips64/pci.h --- linux/include/asm-mips64/pci.h Tue Jul 9 22:03:12 2002 +++ linux.patch/include/asm-mips64/pci.h Sun Jul 14 22:29:34 2002 @@ -343,7 +343,7 @@ * returns, or alternatively stop on the first sg_dma_len(sg) which * is 0. */ -#define sg_dma_address(sg) ((unsigned long)((sg)->address)) +#define sg_dma_address(sg) ((sg)->dvma_address) #define sg_dma_len(sg) ((sg)->length) #endif /* __KERNEL__ */ diff -Naur linux/include/asm-mips64/pgtable.h linux.patch/include/asm-mips64/pgtable.h --- linux/include/asm-mips64/pgtable.h Mon Jul 8 22:28:12 2002 +++ linux.patch/include/asm-mips64/pgtable.h Sun Jul 14 22:29:34 2002 @@ -188,11 +188,11 @@ #ifdef CONFIG_MIPS_UNCACHED #define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED #else /* ! UNCACHED */ -#ifdef CONFIG_SGI_IP22 +#if defined(CONFIG_SGI_IP22) || defined(CONFIG_SGI_IP32) #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT -#else /* ! IP22 */ +#else /* ! (IP22 || IP32)*/ #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW -#endif /* IP22 */ +#endif /* (IP22 || IP32) */ #endif /* UNCACHED */ #define PAGE_NONE __pgprot(_PAGE_PRESENT | PAGE_CACHABLE_DEFAULT) From owner-linux-mips@oss.sgi.com Sun Jul 14 14:09:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6EL9XRw014995 for ; Sun, 14 Jul 2002 14:09:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6EL9X7h014994 for linux-mips-outgoing; Sun, 14 Jul 2002 14:09:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6EL87Rw014971; Sun, 14 Jul 2002 14:08:07 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6ELCdC12626; Sun, 14 Jul 2002 23:12:39 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6ELCZTF021330; Sun, 14 Jul 2002 23:12:35 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17TqfS-0002gu-00; Sun, 14 Jul 2002 23:12:34 +0200 Date: Sun, 14 Jul 2002 23:12:34 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: Brian Murphy , linux-mips@oss.sgi.com Subject: [2.5 patch] R5K SC support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 17642 Lines: 651 Hi, This patch adds support for the secondary cache controller in the R5000 processors. It's quite similar to Brian Murphy's patch (thanks BTW) except it's based on the current R4K code. There is code for variants with 16 bytes cache lines if they exist.. if they don't just remove :) Comments welcome, Vivien. diff -Naur linux/arch/mips64/mm/r4xx0.c linux.patch/arch/mips64/mm/r4xx0.c --- linux/arch/mips64/mm/r4xx0.c Mon Jul 8 22:26:10 2002 +++ linux.patch/arch/mips64/mm/r4xx0.c Mon Jul 8 23:05:51 2002 @@ -736,6 +736,16 @@ blast_dcache32(); blast_icache32(); } +static inline void r5k_flush_cache_all_sXXd16i16(void) +{ + blast_dcache16(); blast_icache16(); r5k_blast_scache(); +} + +static inline void r5k_flush_cache_all_sXXd32i32(void) +{ + blast_dcache32(); blast_icache32(); r5k_blast_scache(); +} + static void r4k_flush_cache_range_s16d16i16(struct vm_area_struct *vma, unsigned long start, unsigned long end) { @@ -1000,6 +1010,80 @@ } } +static void r5k_flush_cache_range_sXXd16i16(struct vm_area_struct *vma, + unsigned long start, unsigned long end) +{ + struct mm_struct *mm = vma->vm_mm; + + if (CPU_CONTEXT(smp_processor_id(), mm) == 0) + return; + + blast_dcache16(); blast_icache16(); + + start &= PAGE_MASK; +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + vma = find_vma(mm, start); + if(vma) { + if (CPU_CONTEXT(smp_processor_id(), mm) != + CPU_CONTEXT(smp_processor_id(), current->mm)) { + r5k_flush_cache_all_sXXd16i16(); + } else { + pgd_t *pgd; + pmd_t *pmd; + pte_t *pte; + + while(start < end) { + pgd = pgd_offset(mm, start); + pmd = pmd_offset(pgd, start); + pte = pte_offset(pmd, start); + + if(pte_val(*pte) & _PAGE_VALID) + r5k_blast_scache_page(start); + start += PAGE_SIZE; + } + } + } +} + +static void r5k_flush_cache_range_sXXd32i32(struct vm_area_struct *vma, + unsigned long start, unsigned long end) +{ + struct mm_struct *mm = vma->vm_mm; + + if (CPU_CONTEXT(smp_processor_id(), mm) == 0) + return; + + blast_dcache32(); blast_icache32(); + + start &= PAGE_MASK; +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + vma = find_vma(mm, start); + if(vma) { + if (CPU_CONTEXT(smp_processor_id(), mm) != + CPU_CONTEXT(smp_processor_id(), current->mm)) { + r5k_flush_cache_all_sXXd32i32(); + } else { + pgd_t *pgd; + pmd_t *pmd; + pte_t *pte; + + while(start < end) { + pgd = pgd_offset(mm, start); + pmd = pmd_offset(pgd, start); + pte = pte_offset(pmd, start); + + if(pte_val(*pte) & _PAGE_VALID) + r5k_blast_scache_page(start); + start += PAGE_SIZE; + } + } + } +} + /* * On architectures like the Sparc, we could get rid of lines in * the cache created only by a certain context, but on the MIPS @@ -1095,6 +1179,26 @@ } } +static void r5k_flush_cache_mm_sXXd16i16(struct mm_struct *mm) +{ + if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + r5k_flush_cache_all_sXXd16i16(); + } +} + +static void r5k_flush_cache_mm_sXXd32i32(struct mm_struct *mm) +{ + if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + r5k_flush_cache_all_sXXd32i32(); + } +} + static void r4k_flush_cache_page_s16d16i16(struct vm_area_struct *vma, unsigned long page) { @@ -1580,6 +1684,112 @@ out: } +static void r5k_flush_cache_page_sXXd16i16(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (CPU_CONTEXT(smp_processor_id(), mm) == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if(!(pte_val(*ptep) & _PAGE_VALID)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if(mm == current->mm) { + blast_dcache16_page(page); + r5k_blast_scache_page(page); + } else { + /* Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + unsigned long index; + index = KSEG0 + (page & (dcache_size - 1)); + blast_dcache16_page_indexed(index); + blast_dcache16_page_indexed(index ^ dcache_waybit); + index = KSEG0 + (page & (scache_size - 1)); + r5k_blast_scache_page(index); + } +out: +} + +static void r5k_flush_cache_page_sXXd32i32(struct vm_area_struct *vma, + unsigned long page) +{ + struct mm_struct *mm = vma->vm_mm; + pgd_t *pgdp; + pmd_t *pmdp; + pte_t *ptep; + + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (CPU_CONTEXT(smp_processor_id(), mm) == 0) + return; + +#ifdef DEBUG_CACHE + printk("cpage[%d,%08lx]", (int)mm->context, page); +#endif + page &= PAGE_MASK; + pgdp = pgd_offset(mm, page); + pmdp = pmd_offset(pgdp, page); + ptep = pte_offset(pmdp, page); + + /* + * If the page isn't marked valid, the page cannot possibly be + * in the cache. + */ + if(!(pte_val(*ptep) & _PAGE_PRESENT)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since stupid R4k caches do a TLB translation + * for every cache flush operation. So we do indexed flushes + * in that case, which doesn't overly flush the cache too much. + */ + if((mm == current->mm) && (pte_val(*ptep) & _PAGE_VALID)) { + blast_dcache32_page(page); + r5k_blast_scache_page(page); + } else { + /* + * Do indexed flush, too much work to get the (possible) + * tlb refills to work correctly. + */ + unsigned long index; + index = KSEG0 + (page & (dcache_size - 1)); + blast_dcache32_page_indexed(index); + blast_dcache32_page_indexed(index ^ dcache_waybit); + index = KSEG0 + (page & (scache_size - 1)); + r5k_blast_scache_page(index); + } +out: +} + static void r4k_flush_page_to_ram_s16(struct page *page) { blast_scache16_page((unsigned long)page_address(page)); @@ -1610,6 +1820,19 @@ blast_dcache32_page((unsigned long)page_address(page)); } +static void r5k_flush_page_to_ram_sXXd16(struct page *page) +{ + blast_dcache16_page((unsigned long)page_address(page)); + r5k_blast_scache_page((unsigned long)page_address(page)); +} + +static void r5k_flush_page_to_ram_sXXd32(struct page *page) +{ + blast_dcache32_page((unsigned long)page_address(page)); + r5k_blast_scache_page((unsigned long)page_address(page)); +} + + static void r4k_flush_icache_range(unsigned long start, unsigned long end) { @@ -1691,6 +1914,36 @@ } } +static void r5k_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= (unsigned long)dcache_size) { + flush_cache_l1(); + } else { + a = addr & ~((unsigned long)dc_lsize - 1); + end = (addr + size) & ~((unsigned long)dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + } + + if (size >= (unsigned long)scache_size) { + flush_cache_all(); + } else { + unsigned long sc_psize = sc_lsize << 7; + a = addr & ~((unsigned long) sc_psize - 1); + end = (addr + size) & ~((unsigned long) sc_psize - 1); + while (1) { + flush_scache_page(a); /* Page_Writeback_Inv_S */ + if (a == end) break; + a += sc_psize; + } + } +} + static void r4k_dma_cache_inv_pc(unsigned long addr, unsigned long size) { unsigned long end, a; @@ -1734,6 +1987,37 @@ } } +static void r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + + if (size >= (unsigned long)dcache_size) { + flush_cache_l1(); + } else { + a = addr & ~((unsigned long)dc_lsize - 1); + end = (addr + size) & ~((unsigned long)dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + } + + if (size >= (unsigned long)scache_size) { + flush_cache_all(); + } else { + unsigned long sc_psize = sc_lsize << 7; + a = addr & ~((unsigned long) sc_psize - 1); + end = (addr + size) & ~((unsigned long) sc_psize - 1); + while (1) { + flush_scache_page(a); /* Page_Writeback_Inv_S */ + if (a == end) break; + a += sc_psize; + } + } +} + static void r4k_dma_cache_wback(unsigned long addr, unsigned long size) { panic("r4k_dma_cache called - should not happen."); @@ -2016,23 +2300,21 @@ dcache_size >> 10, dc_lsize); } - /* If you even _breathe_ on this function, look at the gcc output * and make sure it does not pop things on and off the stack for * the cache sizing loop that executes in KSEG1 space or else * you will crash and burn badly. You have been warned. */ + static int __init probe_scache(unsigned long config) { extern unsigned long stext; unsigned long flags, addr, begin, end, pow2; int tmp; - tmp = ((config >> 17) & 1); - if(tmp) + if(config & CONF_SC) return 0; - tmp = ((config >> 22) & 3); - switch(tmp) { + switch((config >> 22) & 3) { case 0: sc_lsize = 16; break; @@ -2047,41 +2329,55 @@ break; } - begin = (unsigned long) &stext; - begin &= ~((4 * 1024 * 1024) - 1); - end = begin + (4 * 1024 * 1024); - - /* This is such a bitch, you'd think they would make it - * easy to do this. Away you daemons of stupidity! - */ - __save_and_cli(flags); - - /* Fill each size-multiple cache line with a valid tag. */ - pow2 = (64 * 1024); - for(addr = begin; addr < end; addr = (begin + pow2)) { - unsigned long *p = (unsigned long *) addr; - __asm__ __volatile__("nop" : : "r" (*p)); /* whee... */ - pow2 <<= 1; - } - - /* Load first line with zero (therefore invalid) tag. */ - set_taglo(0); - set_taghi(0); - __asm__ __volatile__("nop; nop; nop; nop;"); /* avoid the hazard */ - __asm__ __volatile__("\n\t.set noreorder\n\t" - "cache 8, (%0)\n\t" - ".set reorder\n\t" : : "r" (begin)); - __asm__ __volatile__("\n\t.set noreorder\n\t" - "cache 9, (%0)\n\t" - ".set reorder\n\t" : : "r" (begin)); - __asm__ __volatile__("\n\t.set noreorder\n\t" - "cache 11, (%0)\n\t" - ".set reorder\n\t" : : "r" (begin)); - - /* Now search for the wrap around point. */ - pow2 = (128 * 1024); - tmp = 0; - for(addr = (begin + (128 * 1024)); addr < (end); addr = (begin + pow2)) { + switch(mips_cpu.cputype) { + case CPU_R5000: + case CPU_NEVADA: + /* R5000 are nice, they report the secondary cache size */ + scache_size = (512*1024) << ((config >> 20) & 3); + if(!(config & CONF_SE)) { + /* Turn the secondary cache on */ + __save_and_cli(flags); + change_cp0_config(CONF_SE, CONF_SE); + r5k_blast_scache(); + __restore_flags(flags); + } + break; + default: + begin = (unsigned long) &stext; + begin &= ~((4 * 1024 * 1024) - 1); + end = begin + (4 * 1024 * 1024); + + /* This is such a bitch, you'd think they would make it + * easy to do this. Away you daemons of stupidity! + */ + __save_and_cli(flags); + + /* Fill each size-multiple cache line with a valid tag. */ + pow2 = (64 * 1024); + for(addr = begin; addr < end; addr = (begin + pow2)) { + unsigned long *p = (unsigned long *) addr; + __asm__ __volatile__("nop" : : "r" (*p)); /* whee... */ + pow2 <<= 1; + } + + /* Load first line with zero (therefore invalid) tag. */ + set_taglo(0); + set_taghi(0); + __asm__ __volatile__("nop; nop; nop; nop;"); /* avoid the hazard */ + __asm__ __volatile__("\n\t.set noreorder\n\t" + "cache 8, (%0)\n\t" + ".set reorder\n\t" : : "r" (begin)); + __asm__ __volatile__("\n\t.set noreorder\n\t" + "cache 9, (%0)\n\t" + ".set reorder\n\t" : : "r" (begin)); + __asm__ __volatile__("\n\t.set noreorder\n\t" + "cache 11, (%0)\n\t" + ".set reorder\n\t" : : "r" (begin)); + + /* Now search for the wrap around point. */ + pow2 = (128 * 1024); + tmp = 0; + for(addr = (begin + (128 * 1024)); addr < (end); addr = (begin + pow2)) { __asm__ __volatile__("\n\t.set noreorder\n\t" "cache 7, (%0)\n\t" ".set reorder\n\t" : : "r" (addr)); @@ -2089,12 +2385,16 @@ if(!get_taglo()) break; pow2 <<= 1; + } + __restore_flags(flags); + addr -= begin; + scache_size = addr; + break; } - __restore_flags(flags); - addr -= begin; + printk("Secondary cache sized at %dK linesize %d\n", - (int) (addr >> 10), sc_lsize); - scache_size = addr; + (int) (scache_size >> 10), sc_lsize); + return 1; } @@ -2146,7 +2446,7 @@ _dma_cache_inv = r4k_dma_cache_inv_pc; } -static void __init setup_scache_funcs(void) +static void __init r4k_setup_scache_funcs(void) { switch(sc_lsize) { case 16: @@ -2235,6 +2535,43 @@ _dma_cache_inv = r4k_dma_cache_inv_sc; } +static void __init r5k_setup_scache_funcs(void) +{ + switch(dc_lsize) { + case 16: + _clear_page = r4k_clear_page_d16; + _copy_page = r4k_copy_page_d16; + _flush_cache_all = r5k_flush_cache_all_sXXd16i16; + _flush_cache_l1 = r5k_flush_cache_all_sXXd16i16; + _flush_cache_mm = r5k_flush_cache_mm_sXXd16i16; + _flush_cache_range = r5k_flush_cache_range_sXXd16i16; + _flush_cache_page = r5k_flush_cache_page_sXXd16i16; + break; + case 32: + _clear_page = r4k_clear_page_d32; + _copy_page = r4k_copy_page_d32; + _flush_cache_all = r5k_flush_cache_all_sXXd32i32; + _flush_cache_l1 = r5k_flush_cache_all_sXXd32i32; + _flush_cache_mm = r5k_flush_cache_mm_sXXd32i32; + _flush_cache_range = r5k_flush_cache_range_sXXd32i32; + _flush_cache_page = r5k_flush_cache_page_sXXd32i32; + break; + } + + switch(ic_lsize) { + case 16: + _flush_page_to_ram = r5k_flush_page_to_ram_sXXd16; + break; + case 32: + _flush_page_to_ram = r5k_flush_page_to_ram_sXXd32; + break; + } + _flush_icache_page = r4k_flush_icache_page_p; + _dma_cache_wback_inv = r5k_dma_cache_wback_inv_sc; + _dma_cache_wback = r4k_dma_cache_wback; + _dma_cache_inv = r5k_dma_cache_inv_sc; +} + typedef int (*probe_func_t)(unsigned long); static inline void __init setup_scache(unsigned int config) @@ -2247,8 +2584,15 @@ sc_present = probe_scache_kseg1(config); if (sc_present) { - setup_scache_funcs(); + switch(mips_cpu.cputype) { + case CPU_R5000: + case CPU_NEVADA: + r5k_setup_scache_funcs(); + return; + default: + r4k_setup_scache_funcs(); return; + } } setup_noscache_funcs(); diff -Naur linux/include/asm-mips64/r4kcache.h linux.patch/include/asm-mips64/r4kcache.h --- linux/include/asm-mips64/r4kcache.h Sun Dec 9 15:52:27 2001 +++ linux.patch/include/asm-mips64/r4kcache.h Sat Jul 6 23:05:09 2002 @@ -85,6 +85,7 @@ : "r" (addr), "i" (Hit_Invalidate_SD)); } +/* R4XX0 only */ static inline void flush_scache_line(unsigned long addr) { __asm__ __volatile__( @@ -95,6 +96,19 @@ : "r" (addr), "i" (Hit_Writeback_Inv_SD)); } +/* R5000 only : flushes a 'cache page' of 128 lines */ +static inline void flush_scache_page(unsigned long page) +{ + __asm__ __volatile__( + ".set noreorder\n\t" + "cache %1, (%0)\n\t" + ".set reorder" + : + : "r" (page), "i" (Hit_Writeback_Inv_SD)); +} + + + /* * The next two are for badland addresses like signal trampolines. */ @@ -488,6 +502,32 @@ static inline void blast_scache128_page_indexed(unsigned long page) { cache128_unroll32(page,Index_Writeback_Inv_SD); +} + + +static inline void r5k_blast_scache(void) +{ + unsigned long start = KSEG0; + unsigned long end = (start + scache_size); + + set_taglo(0); + while(start < end) { + flush_scache_page(start); + start += PAGE_SIZE; + } +} + +static inline void r5k_blast_scache_page(page) +{ + unsigned long align = (sc_lsize << 7) - 1; + unsigned long start = page & (~align); + unsigned long end = (page + PAGE_SIZE + align) & (~align); + + set_taglo(0); + while(start < end) { + flush_scache_page(page); + start += sc_lsize << 7; + } } #endif /* __ASM_R4KCACHE_H */ diff -Naur linux/include/asm-mips64/r4kcacheops.h linux.patch/include/asm-mips64/r4kcacheops.h --- linux/include/asm-mips64/r4kcacheops.h Sun Dec 9 15:52:27 2001 +++ linux.patch/include/asm-mips64/r4kcacheops.h Sat Jul 6 17:49:34 2002 @@ -17,6 +17,7 @@ #define Index_Writeback_Inv_D 0x01 #define Index_Invalidate_SI 0x02 #define Index_Writeback_Inv_SD 0x03 +#define All_Writeback_Inv_S 0x03 /* R5000 only */ #define Index_Load_Tag_I 0x04 #define Index_Load_Tag_D 0x05 #define Index_Load_Tag_SI 0x06 @@ -35,6 +36,7 @@ #define Hit_Writeback_Inv_D 0x15 /* 0x16 is unused */ #define Hit_Writeback_Inv_SD 0x17 +#define Page_Writeback_Inv_S 0x17 /* R5000 only */ #define Hit_Writeback_I 0x18 #define Hit_Writeback_D 0x19 /* 0x1a is unused */ diff -Naur linux/include/asm-mips64/mipsregs.h linux.patch/include/asm-mips64/mipsregs.h --- linux/include/asm-mips64/mipsregs.h Sun Dec 9 15:52:27 2001 +++ linux.patch/include/asm-mips64/mipsregs.h Fri Dec 21 11:28:06 2001 @@ -367,6 +367,7 @@ #define CONF_CM_CMASK 7 #define CONF_DB (1 << 4) #define CONF_IB (1 << 5) +#define CONF_SE (1 << 12) #define CONF_SC (1 << 17) #define CONF_AC (1 << 23) #define CONF_HALT (1 << 25) From owner-linux-mips@oss.sgi.com Sun Jul 14 14:13:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6ELDaRw015287 for ; Sun, 14 Jul 2002 14:13:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6ELDajk015286 for linux-mips-outgoing; Sun, 14 Jul 2002 14:13:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6ELCvRw015257; Sun, 14 Jul 2002 14:12:58 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6ELHdC12699; Sun, 14 Jul 2002 23:17:39 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6ELHdTF021495; Sun, 14 Jul 2002 23:17:39 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17TqkN-0002hN-00; Sun, 14 Jul 2002 23:17:39 +0200 Date: Sun, 14 Jul 2002 23:17:39 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] R10K DMA cache flushing routines for non-coherent systems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4603 Lines: 195 Hi, This patch adds support for DMA cache flushing for the R10000 processor on non-coherent systems (Indy and O2). Vivien. ================================================================================ --- linux/arch/mips64/mm/andes.c Mon Jul 8 22:26:10 2002 +++ linux.patch/arch/mips64/mm/andes.c Sun Jul 7 14:48:26 2002 @@ -11,13 +11,17 @@ #include #include #include +#include #include #include -#include #include #include -static int scache_lsz64; +/* Secondary cache parameters. */ +static unsigned int scache_size, sc_lsize; /* Again, in bytes */ + +#include + /* * This version has been tuned on an Origin. For other machines the arguments @@ -98,7 +102,7 @@ */ static void andes_flush_cache_l2(void) { - switch (sc_lsize()) { + switch (sc_lsize) { case 64: blast_scache64(); break; @@ -111,13 +115,96 @@ } } +static void +andes_flush_cache_all(void) +{ + andes_flush_cache_l1(); + andes_flush_cache_l2(); +} + void andes_flush_icache_page(unsigned long page) { - if (scache_lsz64) - blast_scache64_page(page); - else - blast_scache128_page(page); + switch (sc_lsize) { + case 64: + blast_scache64_page(page); + break; + case 128: + blast_scache128_page(page); + break; + default: + printk(KERN_EMERG "Unknown L2 line size\n"); + while(1); + } +} + +/* + * Writeback and invalidate the cache before DMA. + */ + +static void andes_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + + if (size >= (unsigned long)dcache_size) { + flush_cache_l1(); + } else { + a = addr & ~((unsigned long)dc_lsize - 1); + end = (addr + size) & ~((unsigned long)dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + } + + if (size >= (unsigned long)scache_size) { + flush_cache_l2(); + } else { + a = addr & ~((unsigned long) sc_lsize - 1); + end = (addr + size) & ~((unsigned long) sc_lsize - 1); + while (1) { + flush_scache_line(a); /* Hit_Writeback_Inv_S */ + if (a == end) break; + a += sc_lsize; + } + } +} + +static void andes_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + + if (size >= (unsigned long)dcache_size) { + flush_cache_l1(); + } else { + a = addr & ~((unsigned long)dc_lsize - 1); + end = (addr + size) & ~((unsigned long)dc_lsize - 1); + while (1) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + if (a == end) break; + a += dc_lsize; + } + } + + if (size >= (unsigned long)scache_size) { + flush_cache_l2(); + } else { + a = addr & ~((unsigned long) sc_lsize - 1); + end = (addr + size) & ~((unsigned long) sc_lsize - 1); + while (1) { + flush_scache_line(a); /* Hit_Writeback_Inv_S */ + if (a == end) break; + a += sc_lsize; + } + } +} + +static void andes_dma_cache_wback(unsigned long addr, unsigned long size) +{ + panic("andes_dma_cache called - should not happen."); } static void @@ -176,11 +263,9 @@ } } -void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start, +void local_flush_tlb_range(struct mm_struct *mm, unsigned long start, unsigned long end) { - struct mm_struct *mm = vma->vm_mm; - if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { unsigned long flags; int size; @@ -305,31 +390,28 @@ void __init ld_mmu_andes(void) { + /* get secondary cache parameters */ + scache_size = scache_size(); + sc_lsize = sc_lsize(); + printk("Primary instruction cache %dkb, linesize %d bytes\n", icache_size >> 10, ic_lsize); printk("Primary data cache %dkb, linesize %d bytes\n", dcache_size >> 10, dc_lsize); printk("Secondary cache sized at %ldK, linesize %ld\n", - scache_size() >> 10, sc_lsize()); + scache_size >> 10, sc_lsize); _clear_page = andes_clear_page; _copy_page = andes_copy_page; + _flush_cache_all = andes_flush_cache_all; _flush_cache_l1 = andes_flush_cache_l1; _flush_cache_l2 = andes_flush_cache_l2; _flush_cache_sigtramp = andes_flush_cache_sigtramp; - switch (sc_lsize()) { - case 64: - scache_lsz64 = 1; - break; - case 128: - scache_lsz64 = 0; - break; - default: - printk(KERN_EMERG "Unknown L2 line size\n"); - while(1); - } + _dma_cache_wback_inv = andes_dma_cache_wback_inv; + _dma_cache_wback = andes_dma_cache_wback; + _dma_cache_inv = andes_dma_cache_inv; update_mmu_cache = andes_update_mmu_cache; From owner-linux-mips@oss.sgi.com Sun Jul 14 17:03:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F03GRw018477 for ; Sun, 14 Jul 2002 17:03:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F03GQW018476 for linux-mips-outgoing; Sun, 14 Jul 2002 17:03:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft17-f167.dialo.tiscali.de [62.246.17.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F03ARw018462 for ; Sun, 14 Jul 2002 17:03:12 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6F06pK03513; Mon, 15 Jul 2002 02:06:51 +0200 Date: Mon, 15 Jul 2002 02:06:51 +0200 From: Ralf Baechle To: Peter De Schrijver Cc: geert@linux-m68k.org, wim@sonycom.com, lionel@sonycom.com, thomasv@sonycom.com, Nico.DeRanter@sonycom.com, tea@sonycom.com, joel@sonycom.com, michiels@CoWare.com, gds@denayer.wenk.be, p2@mind.be, linux-mips@oss.sgi.com Subject: Re: Patch for DDB5074 support Message-ID: <20020715020651.A16146@dea.linux-mips.net> References: <20020710234935.A31932@ace.ulyssis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020710234935.A31932@ace.ulyssis.org>; from p2@ace.ulyssis.org on Wed, Jul 10, 2002 at 11:49:35PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 140 Lines: 8 On Wed, Jul 10, 2002 at 11:49:35PM +0200, Peter De Schrijver wrote: > This patch should be the right one for ddb-5074. Applied, Ralf From owner-linux-mips@oss.sgi.com Mon Jul 15 02:12:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F9CDRw026960 for ; Mon, 15 Jul 2002 02:12:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F9CCUH026959 for linux-mips-outgoing; Mon, 15 Jul 2002 02:12:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F9C0Rw026933 for ; Mon, 15 Jul 2002 02:12:05 -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 NAA27122; Mon, 15 Jul 2002 13:16:31 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA13786; Mon, 15 Jul 2002 13:15:35 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA08712; Mon, 15 Jul 2002 13:11:19 +0400 (MSK) Message-ID: <3D3292E0.40FE937B@niisi.msk.ru> Date: Mon, 15 Jul 2002 13:16:16 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1797 Lines: 35 "Maciej W. Rozycki" wrote: > Well, I certainly understand what you mean, from the beginning, actually, > but I still can't see why this would happen for a real implementation. > When a cache miss happens an instruction word is read directly from the > main memory to the pipeline and a cache fill happens "accidentally". > > What you describe, would require a CPU to query a cache status somehow > during a fill (what if another fill is in progress? -- a cache controller > may perform a fill of additional lines itself as it happens in certain > implementations) and then issue a second read when the fill completes. > That looks weird to me -- why would you design it this way? > A cache is filled in cachline units. There is a possibility to fill only part of cacheline in one cache and to store the rest of data in another cache on the switch. Both caches will set the valid bit on this cacheline, but only part of cacheline is valid. In the worst cache, this operation may load instructions that will be reused later, for example, part of the main loop of the cache invalidation (sic!) routine. Unfortunately, the behaviour depends on whether miss occurs, what instructions are loaded, how they are aligned, and so on. It means, if you get crash on this kernel version, you won't get a crash on another. If you add debug routines, everything is OK. Other black magic tricks are also here. (As you may guess, I explain my real experience here. :-). Analyzer doesn't help, bus transactions look good.) In order to avoid this, CPU shall either perform the check again or freeze everything on the cache swap operation. The latter doesn't look real. Anyway, it's a lot of additional unnatural logic. So, the requirement to run swapping operation uncached looks reasonable. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Jul 15 02:35:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F9ZORw027290 for ; Mon, 15 Jul 2002 02:35:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F9ZOD0027289 for linux-mips-outgoing; Mon, 15 Jul 2002 02:35:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F9ZJRw027280 for ; Mon, 15 Jul 2002 02:35:20 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.9.3) with ESMTP id g6F9e8a24841 for ; Mon, 15 Jul 2002 11:40:08 +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 LAA24361 for ; Mon, 15 Jul 2002 11:40:08 +0200 (MET DST) Message-Id: <200207150940.LAA24361@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: linux-mips@oss.sgi.com Reply-to: vhouten@kpn.com Subject: DECStation: Support for PMAZ-AA TC SCSI card? 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: Mon, 15 Jul 2002 11:40:08 +0200 From: "Houten K.H.C. van (Karel)" X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 643 Lines: 23 Hi all, I'm currently experimenting with software raid support on my decstation, and it looks fine! But I would love to use more than one SCSI chain for my raid disks. My DECStation contains a Turbochannel PMAZ-AA SCSI card, which WAS once supported in the driver, but isn't anymore. :-( Does anyone knows about patches to get this working again? (Harald, David, Florian?) 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 Mon Jul 15 02:38:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6F9c5Rw027388 for ; Mon, 15 Jul 2002 02:38:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6F9c5pc027387 for linux-mips-outgoing; Mon, 15 Jul 2002 02:38:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6F9c0Rw027375 for ; Mon, 15 Jul 2002 02:38:01 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6F9iRE18283; Mon, 15 Jul 2002 10:44:32 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6F9hHR17003; Mon, 15 Jul 2002 10:43:17 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BF7.0035BDDA ; Mon, 15 Jul 2002 10:47:00 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: "Maciej W. Rozycki" , "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Message-ID: <80256BF7.0035BD49.00@notesmta.eur.3com.com> Date: Mon, 15 Jul 2002 10:42:31 +0100 Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 648 Lines: 16 On Fri, 12 Jul 2002, Gleb O. Raiko wrote: > instruction. CPU knows the stalled instruction is in I-cache, but, > unfortunately, caches have been swapped already. The same cacheline in > the D-cache was valid bit set. CPU get data instead of code. I'm glad this cache swapping mess is not necessary for mips32 chips. I imagine that when the caches are swapped the instruction fetch will examine the D-cache so it will not 'know' the instruction is in the I-cache. If the address is present in both caches then the content should be the same. If the cache routines have some self-modifying code then this really is asking for trouble. Jon From owner-linux-mips@oss.sgi.com Mon Jul 15 08:57:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FFvURw003860 for ; Mon, 15 Jul 2002 08:57:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FFvUJx003859 for linux-mips-outgoing; Mon, 15 Jul 2002 08:57:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hermod.qsicorp.com (mail.qsicorp.com [216.190.147.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FFvQRw003849 for ; Mon, 15 Jul 2002 08:57:26 -0700 Received: from qsicorp.com (computer195.qsicorp.com [216.190.147.195]) by hermod.qsicorp.com (Postfix) with ESMTP id C4E5617043 for ; Mon, 15 Jul 2002 10:02:17 -0600 (MDT) Message-ID: <3D3300A3.FD50EDEA@qsicorp.com> Date: Mon, 15 Jul 2002 10:04:35 -0700 From: Ryan Martindale X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31custom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: fpu woes (TX3912) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 728 Lines: 14 I'm using the tx3912 processor for an embedded device and since it doesn't have an fpu, I don't have coprocessor #1. Recently, I remember seeing a fix in process.c for exit_thread and flush_thread, and did apply it - but there still is a problem (at least for me). In traps.c, the save_fp_context and restore_fp_context are set to _save_fp_context (in r2300_fpu.S) which don't check to see if I have a coprocessor available. As I am rather new to the linux/linux-mips development world, I thought I'd give a heads up (it is causing my embedded system to crash). Any direction on fixing it would be welcome, but I'm not sure I'll get to the point where I will submit any patches any time soon. Ryan Martindale QSI Corporation From owner-linux-mips@oss.sgi.com Mon Jul 15 09:19:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGJDRw004607 for ; Mon, 15 Jul 2002 09:19:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGJDTF004606 for linux-mips-outgoing; Mon, 15 Jul 2002 09:19:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGJ6Rw004596 for ; Mon, 15 Jul 2002 09:19:07 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6FGNoXb023388; Mon, 15 Jul 2002 09:23:50 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA06805; Mon, 15 Jul 2002 09:23:50 -0700 (PDT) Message-ID: <01c401c22c1c$1973a170$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ryan Martindale" , References: <3D3300A3.FD50EDEA@qsicorp.com> Subject: Re: fpu woes (TX3912) Date: Mon, 15 Jul 2002 18:24: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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1606 Lines: 32 > I'm using the tx3912 processor for an embedded device and since it > doesn't have an fpu, I don't have coprocessor #1. Recently, I remember > seeing a fix in process.c for exit_thread and flush_thread, and did > apply it - but there still is a problem (at least for me). In traps.c, > the save_fp_context and restore_fp_context are set to _save_fp_context > (in r2300_fpu.S) which don't check to see if I have a coprocessor > available. As I am rather new to the linux/linux-mips development world, > I thought I'd give a heads up (it is causing my embedded system to > crash). Any direction on fixing it would be welcome, but I'm not sure > I'll get to the point where I will submit any patches any time soon. People break things from time to time, but at least at one point in history, R3xxx platforms were correctly supported by the FPU emulator code. Looking at the source code on my system, it looks like traps.c has been "cleaned up" in a somewhat wierd manner, such that the test for whether there is an FPU happens redundantly, once in the specific case of a 4K family CPU (which you would not hit on your TX39), and again just after the switch on the CPU type. Did someone screw up the setting of mips_cpu.options for a TX39xx or something? Is that code missing from the sources that you're using? Are you sure that it isn't something else blowing up on you? There have been mods made locally here and there that might have broken the FPU emulator for R3xxx platforms, but I didn't think that any of them were up on OSS.sgi.com or kernel.org. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jul 15 09:41:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FGfsRw005496 for ; Mon, 15 Jul 2002 09:41:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FGfslC005495 for linux-mips-outgoing; Mon, 15 Jul 2002 09:41:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hermod.qsicorp.com (mail.qsicorp.com [216.190.147.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FGfgRw005485 for ; Mon, 15 Jul 2002 09:41:42 -0700 Received: from qsicorp.com (computer195.qsicorp.com [216.190.147.195]) by hermod.qsicorp.com (Postfix) with ESMTP id 314BF17043; Mon, 15 Jul 2002 10:46:34 -0600 (MDT) Message-ID: <3D330B04.CDE3E332@qsicorp.com> Date: Mon, 15 Jul 2002 10:48:52 -0700 From: Ryan Martindale X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: fpu woes (TX3912) References: <3D3300A3.FD50EDEA@qsicorp.com> <01c401c22c1c$1973a170$10eca8c0@grendel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3199 Lines: 85 "Kevin D. Kissell" wrote: > > > I'm using the tx3912 processor for an embedded device and since it > > doesn't have an fpu, I don't have coprocessor #1. Recently, I remember > > seeing a fix in process.c for exit_thread and flush_thread, and did > > apply it - but there still is a problem (at least for me). In traps.c, > > the save_fp_context and restore_fp_context are set to _save_fp_context > > (in r2300_fpu.S) which don't check to see if I have a coprocessor > > available. As I am rather new to the linux/linux-mips development world, > > I thought I'd give a heads up (it is causing my embedded system to > > crash). Any direction on fixing it would be welcome, but I'm not sure > > I'll get to the point where I will submit any patches any time soon. > > People break things from time to time, but at least at one point > in history, R3xxx platforms were correctly supported by the > FPU emulator code. Looking at the source code on my > system, it looks like traps.c has been "cleaned up" in a > somewhat wierd manner, such that the test for whether > there is an FPU happens redundantly, once in the specific > case of a 4K family CPU (which you would not hit on your > TX39), and again just after the switch on the CPU type. > Did someone screw up the setting of mips_cpu.options > for a TX39xx or something? Is that code missing from > the sources that you're using? Are you sure that it isn't > something else blowing up on you? There have been > mods made locally here and there that might have > broken the FPU emulator for R3xxx platforms, but > I didn't think that any of them were up on OSS.sgi.com > or kernel.org. > > Regards, > > Kevin K. I am actually using the 2.4.18 stable kernel source, although I did check the 2.5.14 source tree I have to see if any modifications had taken place. My problem is the in signal.c function setup_sigcontext has: if (current->used_math) { /* 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; } There is no check to see if I have an FPU. I modified it to: if (current->used_math) { /* fp is active. */ if (mips_cpu.options & MIPS_CPU_FPU) { set_cp0_status(ST0_CU1); err |= save_fp_context(sc); regs->cp0_status &= ~ST0_CU1; } last_task_used_math = NULL; current->used_math = 0; } And now I am not crashing. As far as how it is supposed to be setup, I don't really know - like I said, I'm pretty new at this. I don't see any ifdefs/checks around the code in traps.c case CPU_R2000: case CPU_R3000: case CPU_R3000A: case CPU_R3041: case CPU_R3051: case CPU_R3052: case CPU_R3081: case CPU_R3081E: case CPU_TX3912: case CPU_TX3922: case CPU_TX3927: save_fp_context = _save_fp_context; restore_fp_context = _restore_fp_context; I would think that traps.c would be were you would set up to handle emulation (indeed it appears that there is an emulator option set up for the processors with MIPS_CPU_4KEX && MIPS_CPU_4KTLB options set, but no other locations seem to be concerned about this. Is this where floating point should be dealt with? Ryan From owner-linux-mips@oss.sgi.com Mon Jul 15 11:00:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FI06Rw006794 for ; Mon, 15 Jul 2002 11:00:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FI06pB006793 for linux-mips-outgoing; Mon, 15 Jul 2002 11:00:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from proteus.paralogos.com (aux-209-217-49-36.oklahoma.net [209.217.49.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FHxsRw006774 for ; Mon, 15 Jul 2002 10:59:54 -0700 Received: from grendel ([195.154.177.178]) by proteus.paralogos.com (8.9.3/8.9.3) with SMTP id NAA18279; Mon, 15 Jul 2002 13:07:43 -0500 Message-ID: <01fa01c22c2a$3011d9c0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ryan Martindale" Cc: References: <3D3300A3.FD50EDEA@qsicorp.com> <01c401c22c1c$1973a170$10eca8c0@grendel> <3D330B04.CDE3E332@qsicorp.com> Subject: Re: fpu woes (TX3912) Date: Mon, 15 Jul 2002 20:04:38 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2348 Lines: 75 > I am actually using the 2.4.18 stable kernel source, although I did > check the 2.5.14 source tree I have to see if any modifications had > taken place. My problem is the in signal.c function setup_sigcontext > has: If you mean 2.4.18 from kernel.org, it's missing a lot of MIPS fixes, I'm sorry to say. Most of them went in at 2.4.19-pre2 or so. > if (current->used_math) { /* 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; > } > > There is no check to see if I have an FPU. I modified it to: > > if (current->used_math) { /* fp is active. */ > if (mips_cpu.options & MIPS_CPU_FPU) { > set_cp0_status(ST0_CU1); > err |= save_fp_context(sc); > regs->cp0_status &= ~ST0_CU1; > } > last_task_used_math = NULL; > current->used_math = 0; > } This is a known (and old) problem, with a fix that somehow didn't get distributed widely enough. There are probably related problems in the sources you are using that will likewise cause random core dumps when the FP is used on a loaded system. The 2.4.x branch of the sources at http://oss.sgi.com/mips/ should have the full set of fixes. > And now I am not crashing. As far as how it is supposed to be setup, I > don't really know - like I said, I'm pretty new at this. I don't see any > ifdefs/checks around the code in traps.c > > case CPU_R2000: > case CPU_R3000: > case CPU_R3000A: > case CPU_R3041: > case CPU_R3051: > case CPU_R3052: > case CPU_R3081: > case CPU_R3081E: > case CPU_TX3912: > case CPU_TX3922: > case CPU_TX3927: > save_fp_context = _save_fp_context; > restore_fp_context = _restore_fp_context; The following lines in my copy of the file are: memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80); break; case CPU_UNKNOWN: default: panic("Unknown CPU type"); } if (!(mips_cpu.options & MIPS_CPU_FPU)) { save_fp_context = fpu_emulator_save_context; restore_fp_context = fpu_emulator_restore_context; } This should overwrite the fp_context save/restore pointers with those of the emulator. If that clause doesn't appear in your traps.c file, please try putting it in. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jul 15 14:12:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FLC3Rw013310 for ; Mon, 15 Jul 2002 14:12:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FLC3Ms013309 for linux-mips-outgoing; Mon, 15 Jul 2002 14:12:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f97.dialo.tiscali.de [62.246.18.97]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FLBiS0013285 for ; Mon, 15 Jul 2002 14:11:51 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6FChFq04985; Mon, 15 Jul 2002 14:43:15 +0200 Date: Mon, 15 Jul 2002 14:43:15 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: Brian Murphy , linux-mips@oss.sgi.com Subject: Re: [2.5 patch] R5K SC support Message-ID: <20020715144315.A4837@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Sun, Jul 14, 2002 at 11:12:34PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2964 Lines: 70 On Sun, Jul 14, 2002 at 11:12:34PM +0200, Vivien Chappelier wrote: > > This patch adds support for the secondary cache controller in the > R5000 processors. It's quite similar to Brian Murphy's patch > (thanks BTW) except it's based on the current R4K code. > There is code for variants with 16 bytes cache lines if they > exist.. if they don't just remove :) They don't exist. > +static inline void r5k_flush_cache_all_sXXd16i16(void) > +static void r5k_flush_cache_mm_sXXd16i16(struct mm_struct *mm) Dead code. > +static inline void r5k_flush_cache_all_sXXd32i32(void) > +static void r5k_flush_cache_range_sXXd16i16(struct vm_area_struct *vma, > + unsigned long start, unsigned long end) > +static void r5k_flush_cache_range_sXXd32i32(struct vm_area_struct *vma, > + unsigned long start, unsigned long end) > +static void r5k_flush_cache_mm_sXXd32i32(struct mm_struct *mm) > +static void r5k_flush_cache_page_sXXd16i16(struct vm_area_struct *vma, > + unsigned long page) > +static void r5k_flush_cache_page_sXXd32i32(struct vm_area_struct *vma, > + unsigned long page) > +static void r5k_flush_page_to_ram_sXXd16(struct page *page) > +static void r5k_flush_page_to_ram_sXXd32(struct page *page) Flushing the second level cache not required as it's physically indexed so these are actually indentical to the R4000PC variant flushes. The second level cache only has to be flushed by sysmips(FLUSH_CACHE, ...), flushcache(2) and once on bootup on activation. > +static void r5k_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size) > +static void r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) You can hook the second level cache support into the bcache hook. That's working because unlike the R4000SC the R5000's second level cache does not have the additional constraint of the primary caches always being a subset of the second level caches. Arch/mips/sgi-ip22/ip22-sc.c is an example how this can be done. > /* If you even _breathe_ on this function, look at the gcc output > * and make sure it does not pop things on and off the stack for > * the cache sizing loop that executes in KSEG1 space or else > * you will crash and burn badly. You have been warned. > */ The R4000SC cache sizing code is bad enough as it is; can you keep it a separate function from the code for other CPUs? > +static void __init r5k_setup_scache_funcs(void) With above changes this function will vaporize as well ... An additional comment on the Page_Writeback_Inv_S and operations. They will only work, if the second level caches uses SRAM with the flash clean column feature. If cache SRAMs don't support that feature, things will blowup. That's not an uncommon R4k configuration, unfortunately, so we have to support it and as there is no mechanism for probling provided one simply has to know what type of memory is in used. Not sure about All_Writeback_Inv_S but similar constraints should apply. Ralf From owner-linux-mips@oss.sgi.com Mon Jul 15 14:11:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FLBtRw013303 for ; Mon, 15 Jul 2002 14:11:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FLBtgD013302 for linux-mips-outgoing; Mon, 15 Jul 2002 14:11:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft18-f97.dialo.tiscali.de [62.246.18.97]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FLBiRw013285 for ; Mon, 15 Jul 2002 14:11:45 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6FD61k05025; Mon, 15 Jul 2002 15:06:01 +0200 Date: Mon, 15 Jul 2002 15:06:01 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com Subject: Re: [2.5 PATCH] R10K DMA cache flushing routines for non-coherent systems Message-ID: <20020715150601.B4837@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Sun, Jul 14, 2002 at 11:17:39PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1042 Lines: 46 On Sun, Jul 14, 2002 at 11:17:39PM +0200, Vivien Chappelier wrote: > @@ -111,13 +115,96 @@ > } > } > > +static void > +andes_flush_cache_all(void) > +{ > + andes_flush_cache_l1(); > + andes_flush_cache_l2(); > +} We can optimize that slightly. By leaving it an empty function as it is :-) > void > andes_flush_icache_page(unsigned long page) > { > - if (scache_lsz64) > - blast_scache64_page(page); > - else > - blast_scache128_page(page); > + switch (sc_lsize) { > + case 64: > + blast_scache64_page(page); > + break; > + case 128: > + blast_scache128_page(page); > + break; Eh... So this is replacing a wrong version with another wrong piece of code. There simply is no reason to flush the second level cache at this point. That forcing instructions to be re-fetched from memory and that's slooow. > + _dma_cache_wback_inv = andes_dma_cache_wback_inv; > + _dma_cache_wback = andes_dma_cache_wback; > + _dma_cache_inv = andes_dma_cache_inv; This is breaking cache coherent machines. Encore une fois :-) Ralf From owner-linux-mips@oss.sgi.com Mon Jul 15 15:23:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6FMNqRw014851 for ; Mon, 15 Jul 2002 15:23:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6FMNqsZ014850 for linux-mips-outgoing; Mon, 15 Jul 2002 15:23:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6FMNlRw014840 for ; Mon, 15 Jul 2002 15:23:47 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA26471 for ; Mon, 15 Jul 2002 15:28:35 -0700 Subject: PATCH From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 15 Jul 2002 15:29:10 -0700 Message-Id: <1026772150.15665.145.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-2.5 required=5.0 tests=TO_LOCALPART_EQ_REAL,UNIFIED_PATCH,SUBJ_ALL_CAPS version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 593 Lines: 24 Ralf, __pte is broken when pte_t is a 64bit type. I did this to fix the 36 bit IO support for the Alchemy boards, but it also affects the 64 bit mips port. Apparently it fixed a Xfree problem someone was having. Pete --- include/asm-mips/pgtable.h.old Fri Jul 12 17:25:19 2002 +++ include/asm-mips/pgtable.h Fri Jul 12 17:25:36 2002 @@ -332,7 +332,9 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) { - return __pte(((pte).pte_low & _PAGE_CHG_MASK) | pgprot_val(newprot)); + pte.pte_low &= _PAGE_CHG_MASK; + pte.pte_low |= pgprot_val(newprot); + return pte; } /* From owner-linux-mips@oss.sgi.com Mon Jul 15 17:54:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G0slRw016570 for ; Mon, 15 Jul 2002 17:54:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G0sl5q016569 for linux-mips-outgoing; Mon, 15 Jul 2002 17:54:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from myware.mynet (cpe-24-221-190-179.ca.sprintbbd.net [24.221.190.179]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G0scRw016560 for ; Mon, 15 Jul 2002 17:54:40 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by myware.mynet (8.12.3/8.12.3) with ESMTP id g6G0xOLV005747; Mon, 15 Jul 2002 17:59:25 -0700 Subject: Re: PATCH: Always use ll/sc for mips From: Ulrich Drepper To: "H. J. Lu" Cc: linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20020702114045.A16197@lucon.org> References: <20020702114045.A16197@lucon.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pu3iGaXCetuK+RR7Gii9" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-2) Date: 15 Jul 2002 17:59:24 -0700 Message-Id: <1026781165.3673.11.camel@myware.mynet> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 938 Lines: 31 --=-pu3iGaXCetuK+RR7Gii9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-07-02 at 11:40, H. J. Lu wrote: > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > glibc always use ll/sc. Since I haven't seen any objections I've checked this patch in. --=20 ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ --=-pu3iGaXCetuK+RR7Gii9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9M2/s2ijCOnn/RHQRAmmEAJ9gOVWz631kACuhoQOZwzFjYdEIbwCeJmSb 7Nu/3IYQiH6P6vaRNBK+uIw= =6hDg -----END PGP SIGNATURE----- --=-pu3iGaXCetuK+RR7Gii9-- From owner-linux-mips@oss.sgi.com Mon Jul 15 19:28:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G2S7Rw017574 for ; Mon, 15 Jul 2002 19:28:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G2S7Ym017573 for linux-mips-outgoing; Mon, 15 Jul 2002 19:28:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from web14406.mail.yahoo.com (web14406.mail.yahoo.com [216.136.174.76]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G2RxRw017563 for ; Mon, 15 Jul 2002 19:27:59 -0700 Message-ID: <20020716023252.65583.qmail@web14406.mail.yahoo.com> Received: from [157.165.41.125] by web14406.mail.yahoo.com via HTTP; Mon, 15 Jul 2002 19:32:52 PDT Date: Mon, 15 Jul 2002 19:32:52 -0700 (PDT) From: Long Li Subject: mips32 cross compiler on X86 linux To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1337 Lines: 55 Hi, I am a newbie to the cross compiler. I read some documents online and started to build a gcc cross compiler for MIPS4Kc(32-bit isa) on X86 linux. Here is what I did: 1. I built binutils-2.11.2 with the following configurations: configure --prefix=/home/lli/my-bin --target=mips32-linux --with-cpu=mips32-4kc 2. The binutils was built successfully. Then I built the gcc-3.0.4 with the configurations: --prefix=/home/lli/my-bin --target=mips32-linux --with-cpu=mips32-4kc --with-gnu-as --with-gnu-ld --enable-languages="c c++" I got the error messages: /home/lli/my-bin/mips32-linux/bin/ld: /home/lli/my-bin/mips32-linux/lib/crti.o: Relocations in generic ELF (EM: 3) /home/lli/my-bin/mips32-linux/lib/crti.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/home/lli/objdir/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/home/lli/objdir/gcc' make: *** [all-gcc] Error 2 Is my configuration correct to build a MIPS32-4kc cross compiler on Linux? If not, how should I do? Could you give me some help? Thank you very much. I really appreciate it. Best, Long Li __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From owner-linux-mips@oss.sgi.com Mon Jul 15 20:20:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G3KmRw018389 for ; Mon, 15 Jul 2002 20:20:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G3KmUK018388 for linux-mips-outgoing; Mon, 15 Jul 2002 20:20:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from freemail.com.au (sysofm01.freemail.com.au [210.11.38.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G3KZRw018379 for ; Mon, 15 Jul 2002 20:20:36 -0700 Date: Mon, 15 Jul 2002 20:20:35 -0700 Message-Id: <200207160320.g6G3KZRw018379@oss.sgi.com> Content-type: multipart/mixed; boundary="----------APMIME1" Subject: Re: mips32 cross compiler on X86 linux From: Guo-Rong Koh To: linux-mips@oss.sgi.com X-FreemailID: 14281835 MIME-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1906 Lines: 77 This is a multipart message in MIME format. ------------APMIME1 Content-type: text/plain Try this: http://www.ltc.com/~brad/mips/mips-cross-toolchain/ Guo-Rong At Mon, 15 Jul 2002 19:32:52 -0700 (PDT), Long Li (long21st@yahoo.com) wrote: > Hi, > > I am a newbie to the cross compiler. I read some > documents online and started to build a gcc cross > compiler for MIPS4Kc(32-bit isa) on X86 linux. Here is > what I did: > > 1. I built binutils-2.11.2 with the following > configurations: > > configure --prefix=/home/lli/my-bin > --target=mips32-linux --with-cpu=mips32-4kc > > 2. The binutils was built successfully. Then I built > the gcc-3.0.4 > with the configurations: > > --prefix=/home/lli/my-bin --target=mips32-linux > --with-cpu=mips32-4kc > --with-gnu-as --with-gnu-ld > --enable-languages="c c++" > > I got the error messages: > > /home/lli/my-bin/mips32-linux/bin/ld: > /home/lli/my-bin/mips32-linux/lib/crti.o: Relocations > in generic ELF (EM: 3) > /home/lli/my-bin/mips32-linux/lib/crti.o: could not > read symbols: File in > wrong format > collect2: ld returned 1 exit status > make[2]: *** [libgcc_s.so] Error 1 > make[2]: Leaving directory `/home/lli/objdir/gcc' > make[1]: *** [libgcc.a] Error 2 > make[1]: Leaving directory `/home/lli/objdir/gcc' > make: *** [all-gcc] Error 2 > > > Is my configuration correct to build a MIPS32-4kc > cross compiler on Linux? If not, how should I do? > Could you give me some help? > > Thank you very much. I really appreciate it. > > > Best, > > > Long Li > > __________________________________________________ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com -------------------------------------------------------- Looking for a free email account? Get one now at http://www.freemail.com.au/ -------------------------------------------------------- ------------APMIME1-- From owner-linux-mips@oss.sgi.com Tue Jul 16 01:30:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G8UORw021994 for ; Tue, 16 Jul 2002 01:30:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G8UOgT021993 for linux-mips-outgoing; Tue, 16 Jul 2002 01:30:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G8UERw021983; Tue, 16 Jul 2002 01:30:16 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6G8YxXb026890; Tue, 16 Jul 2002 01:34:59 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA15285; Tue, 16 Jul 2002 01:35:00 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6G8Yxb05588; Tue, 16 Jul 2002 10:34:59 +0200 (MEST) Message-ID: <3D33DAB2.353A4399@mips.com> Date: Tue, 16 Jul 2002 10:34:58 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "H. J. Lu" , linux-mips@oss.sgi.com Subject: Personality Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 890 Lines: 26 The include/linux/personality.h file has changed between the 2.4.3 and the 2.4.18 kernel. Now there is a define of personality (#define personality(pers) (pers & PER_MASK), but that breaks things for the users, if they include this file. The user wishes to call the glibc personality function (which do the syscall), and not use the above definition. So I guess we need a "#ifdef __KERNEL__" around some of the code in include/linux/personality.h (at least around the define of personality), which then has to go into the glibc kernel header files. Any comments ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jul 16 01:55:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6G8tARw022229 for ; Tue, 16 Jul 2002 01:55:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6G8tAss022228 for linux-mips-outgoing; Tue, 16 Jul 2002 01:55:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6G8t2Rw022219 for ; Tue, 16 Jul 2002 01:55:03 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA21915; Tue, 16 Jul 2002 11:00:05 +0200 (MET DST) Date: Tue, 16 Jul 2002 11:00:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D3292E0.40FE937B@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1877 Lines: 38 On Mon, 15 Jul 2002, Gleb O. Raiko wrote: > A cache is filled in cachline units. There is a possibility to fill only > part of cacheline in one cache and to store the rest of data in another > cache on the switch. Both caches will set the valid bit on this > cacheline, but only part of cacheline is valid. In the worst cache, this > operation may load instructions that will be reused later, for example, > part of the main loop of the cache invalidation (sic!) routine. Well, it looks possible for a CPU with cache lines wider than 32-bits (are there any such R3k-class CPUs?), indeed. > Unfortunately, the behaviour depends on whether miss occurs, what > instructions are loaded, how they are aligned, and so on. It means, if > you get crash on this kernel version, you won't get a crash on another. > If you add debug routines, everything is OK. Other black magic tricks > are also here. (As you may guess, I explain my real experience here. > :-). Analyzer doesn't help, bus transactions look good.) How true -- I've seen such nastinesses, too. :-/ Except that I don't have an analyzer. > In order to avoid this, CPU shall either perform the check again or > freeze everything on the cache swap operation. The latter doesn't look > real. Anyway, it's a lot of additional unnatural logic. So, the > requirement to run swapping operation uncached looks reasonable. Well, the simplest effective approach would be a third alternative, i.e. to make swapping happen only when no fill is in progress. Trivial logic with a single D latch on the swap signal should suffice -- I don't think the save on omitting it is worth breaking architecture specs and performance. -- + 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 Jul 16 03:17:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GAH6Rw023129 for ; Tue, 16 Jul 2002 03:17:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GAH65V023128 for linux-mips-outgoing; Tue, 16 Jul 2002 03:17:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GAGpRw023115 for ; Tue, 16 Jul 2002 03:16:54 -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 OAA13009; Tue, 16 Jul 2002 14:21:29 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA19439; Tue, 16 Jul 2002 14:20:40 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA25030; Tue, 16 Jul 2002 14:16:34 +0400 (MSK) Message-ID: <3D33F38A.1866E8BB@niisi.msk.ru> Date: Tue, 16 Jul 2002 14:20:58 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 References: Content-Type: text/plain; charset=koi8-r X-MIME-Autoconverted: from 8bit to quoted-printable by t111.niisi.ras.ru id OAA13009 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6GAGtRw023120 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2595 Lines: 64 "Maciej W. Rozycki" wrote: > Well, it looks possible for a CPU with cache lines wider than 32-bits > (are there any such R3k-class CPUs?), indeed. Yes, IDT R3081 has 16-byte I-cacheline. It also may have 16-byte D-cacheline, it depends on DB Refill set, may be set by wiring and in software too. DB Refill is here to support burst reads modern DRAMs have. > > > Unfortunately, the behaviour depends on whether miss occurs, what > > instructions are loaded, how they are aligned, and so on. It means, if > > you get crash on this kernel version, you won't get a crash on another. > > If you add debug routines, everything is OK. Other black magic tricks > > are also here. (As you may guess, I explain my real experience here. > > :-). Analyzer doesn't help, bus transactions look good.) > > How true -- I've seen such nastinesses, too. :-/ Except that I don't > have an analyzer. Don't care, it doesn't help in such situations. > > > In order to avoid this, CPU shall either perform the check again or > > freeze everything on the cache swap operation. The latter doesn't look > > real. Anyway, it's a lot of additional unnatural logic. So, the > > requirement to run swapping operation uncached looks reasonable. > > Well, the simplest effective approach would be a third alternative, i.e. > to make swapping happen only when no fill is in progress. Trivial logic > with a single D latch on the swap signal should suffice -- I don't think > the save on omitting it is worth breaking architecture specs and > performance. > In two words, it's unclear when there are no fills. Too much situations, additional stall condition (which may break spec anyway). I can't present full explanation, sorry. You have to believe. :-) BTW, I reread my R3081 HW Manual and found two intresting places about cache operation: "These mechanisms [cache sizing, cache flushing] are enabled through the use of the “IsC” (Isolate Cache) and SwC (Swap Cache) bits of the status register, which resides in the on-chip System Control Co-Processor (CP0). Instructions which immediately precede and succeed these operations must not be cacheable, so that the actual swapping/isolation of the cache does not disrupt operation." Note precede instructions. Then, on cache sizeing: "Cache Sizing [Famous algorithm that we implement] Note that this software should operate as uncached. Once this algorithm is done, software should return the caches to their normal state by performing either a complete cache flush or an invalidate of those cache lines modified by the sizing algorithm." Regards, Gleb. From owner-linux-mips@oss.sgi.com Tue Jul 16 03:31:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GAVHRw023339 for ; Tue, 16 Jul 2002 03:31:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GAVH8O023338 for linux-mips-outgoing; Tue, 16 Jul 2002 03:31:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GAV9Rw023328 for ; Tue, 16 Jul 2002 03:31:10 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with ESMTP id MAA23772; Tue, 16 Jul 2002 12:36:25 +0200 (MET DST) Date: Tue, 16 Jul 2002 12:36:24 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@oss.sgi.com Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 In-Reply-To: <3D33F38A.1866E8BB@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 X-MIME-Autoconverted: from 8bit to quoted-printable by delta.ds2.pg.gda.pl id MAA23772 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g6GAVBRw023330 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1444 Lines: 36 On Tue, 16 Jul 2002, Gleb O. Raiko wrote: > In two words, it's unclear when there are no fills. Too much situations, > additional stall condition (which may break spec anyway). I can't The cache logic somehow must know a fill is in progress. Or at least that it starts or finishes. Another latch may store the state. > present full explanation, sorry. You have to believe. :-) You don't have to convince me broken hardware is out there. I am simply trying to emphasize there is still some demand on good hardware, even if marginally more expensive. > BTW, I reread my R3081 HW Manual and found two intresting places about > cache operation: > > "These mechanisms [cache sizing, cache flushing] are enabled through the > use of the “IsC” (Isolate Cache) and SwC (Swap Cache) bits of the status > register, which resides in the on-chip System Control Co-Processor > (CP0). Instructions which immediately precede and succeed these > operations must not be cacheable, so that the actual swapping/isolation > of the cache does not disrupt operation." So someone will need to code a set of cache handling functions with a workaround for this deficiency if we are to support a system with this CPU as it appears Linux-capable. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jul 16 06:35:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GDZtRw030967 for ; Tue, 16 Jul 2002 06:35:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GDZsZm030966 for linux-mips-outgoing; Tue, 16 Jul 2002 06:35:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GDZZRw030954; Tue, 16 Jul 2002 06:35:35 -0700 Received: from dsl254-114-096.nyc1.dsl.speakeasy.net ([216.254.114.96] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17USYp-0006bZ-00; Tue, 16 Jul 2002 08:40:16 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17USYo-00053q-00; Tue, 16 Jul 2002 09:40:14 -0400 Date: Tue, 16 Jul 2002 09:40:14 -0400 From: Daniel Jacobowitz To: Carsten Langgaard Cc: Ralf Baechle , "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: Personality Message-ID: <20020716134014.GA19350@nevyn.them.org> References: <3D33DAB2.353A4399@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D33DAB2.353A4399@mips.com> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1002 Lines: 25 On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote: > The include/linux/personality.h file has changed between the 2.4.3 and > the 2.4.18 kernel. > Now there is a define of personality (#define personality(pers) (pers & > PER_MASK), but that breaks things for the users, if they include this > file. > The user wishes to call the glibc personality function (which do the > syscall), and not use the above definition. > > So I guess we need a "#ifdef __KERNEL__" around some of the code in > include/linux/personality.h (at least around the define of personality), > which then has to go into the glibc kernel header files. > > Any comments ? Why is the user program including in the first place? The right thing to do here is to provide the necessary bits in a glibc header, probably in bits/personality.h or so. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jul 16 06:36:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GDaXRw031029 for ; Tue, 16 Jul 2002 06:36:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GDaX1c031028 for linux-mips-outgoing; Tue, 16 Jul 2002 06:36:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GDaSRw031019 for ; Tue, 16 Jul 2002 06:36:29 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA27241; Tue, 16 Jul 2002 15:41:53 +0200 (MET DST) Date: Tue, 16 Jul 2002 15:41:53 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <200207150940.LAA24361@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 881 Lines: 19 On Mon, 15 Jul 2002, Houten K.H.C. van (Karel) wrote: > I'm currently experimenting with software raid support on my decstation, > and it looks fine! But I would love to use more than one SCSI chain > for my raid disks. My DECStation contains a Turbochannel PMAZ-AA > SCSI card, which WAS once supported in the driver, but isn't anymore. :-( That's basically the same as the /200's onboard SCSI. If that works, why wouldn't an additional card (yup, I know the SCSI driver is a mess...)? [Looking at the sources...] The driver seems to have all necessary bits to support additional HBAs. What do you mean by "not supported anymore?" What does it report for PMAZ-AA cards? -- + 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 Jul 16 06:53:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GDrPRw031327 for ; Tue, 16 Jul 2002 06:53:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GDrPFf031326 for linux-mips-outgoing; Tue, 16 Jul 2002 06:53:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GDrFRw031316; Tue, 16 Jul 2002 06:53:15 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6GDvVXb027628; Tue, 16 Jul 2002 06:57:31 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA26548; Tue, 16 Jul 2002 06:57:31 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6GDvUb05899; Tue, 16 Jul 2002 15:57:31 +0200 (MEST) Message-ID: <3D34264A.7845DFDC@mips.com> Date: Tue, 16 Jul 2002 15:57:30 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Ralf Baechle , "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: Personality References: <3D33DAB2.353A4399@mips.com> <20020716134014.GA19350@nevyn.them.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1477 Lines: 44 Daniel Jacobowitz wrote: > On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote: > > The include/linux/personality.h file has changed between the 2.4.3 and > > the 2.4.18 kernel. > > Now there is a define of personality (#define personality(pers) (pers & > > PER_MASK), but that breaks things for the users, if they include this > > file. > > The user wishes to call the glibc personality function (which do the > > syscall), and not use the above definition. > > > > So I guess we need a "#ifdef __KERNEL__" around some of the code in > > include/linux/personality.h (at least around the define of personality), > > which then has to go into the glibc kernel header files. > > > > Any comments ? > > Why is the user program including in the first > place? > It need some personality type defines. > > The right thing to do here is to provide the necessary bits in a glibc > header, probably in bits/personality.h or so. > Agree, that is probably the right way to do it. > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jul 16 06:58:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GDwQRw031496 for ; Tue, 16 Jul 2002 06:58:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GDwPbS031495 for linux-mips-outgoing; Tue, 16 Jul 2002 06:58:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GDwHRw031480 for ; Tue, 16 Jul 2002 06:58:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA27700; Tue, 16 Jul 2002 16:03:30 +0200 (MET DST) Date: Tue, 16 Jul 2002 16:03:29 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Ryan Martindale , linux-mips@oss.sgi.com Subject: Re: fpu woes (TX3912) In-Reply-To: <01fa01c22c2a$3011d9c0$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1264 Lines: 41 On Mon, 15 Jul 2002, Kevin D. Kissell wrote: > The following lines in my copy of the file are: > memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80); > break; > > case CPU_UNKNOWN: > default: > panic("Unknown CPU type"); > } > if (!(mips_cpu.options & MIPS_CPU_FPU)) { > save_fp_context = fpu_emulator_save_context; > restore_fp_context = fpu_emulator_restore_context; > } > > This should overwrite the fp_context save/restore pointers > with those of the emulator. If that clause doesn't appear > in your traps.c file, please try putting it in. It's worded a bit differently in the CVS: case CPU_UNKNOWN: default: panic("Unknown CPU type"); } flush_icache_range(KSEG0, KSEG0 + 0x400); if (mips_cpu.options & MIPS_CPU_FPU) { save_fp_context = _save_fp_context; restore_fp_context = _restore_fp_context; } else { save_fp_context = fpu_emulator_save_context; restore_fp_context = fpu_emulator_restore_context; } -- + 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 Jul 16 07:13:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GEDERw031816 for ; Tue, 16 Jul 2002 07:13:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GEDEDY031815 for linux-mips-outgoing; Tue, 16 Jul 2002 07:13:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft17-f125.dialo.tiscali.de [62.246.17.125]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GED7Rw031805 for ; Tue, 16 Jul 2002 07:13:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6GAaW317905; Tue, 16 Jul 2002 12:36:32 +0200 Date: Tue, 16 Jul 2002 12:36:32 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: Personality Message-ID: <20020716123632.B17038@dea.linux-mips.net> References: <3D33DAB2.353A4399@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D33DAB2.353A4399@mips.com>; from carstenl@mips.com on Tue, Jul 16, 2002 at 10:34:58AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 800 Lines: 19 On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote: > The include/linux/personality.h file has changed between the 2.4.3 and > the 2.4.18 kernel. > Now there is a define of personality (#define personality(pers) (pers & > PER_MASK), but that breaks things for the users, if they include this > file. > The user wishes to call the glibc personality function (which do the > syscall), and not use the above definition. > > So I guess we need a "#ifdef __KERNEL__" around some of the code in > include/linux/personality.h (at least around the define of personality), > which then has to go into the glibc kernel header files. The general policy about such problems is to not use kernel include files from user applications directly. Hjl - maybe time for ? Ralf From owner-linux-mips@oss.sgi.com Tue Jul 16 08:03:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GF30Rw032273 for ; Tue, 16 Jul 2002 08:03:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GF30Ia032272 for linux-mips-outgoing; Tue, 16 Jul 2002 08:03:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft17-f125.dialo.tiscali.de [62.246.17.125]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GF2rRw032263 for ; Tue, 16 Jul 2002 08:02:55 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6GF7f419786; Tue, 16 Jul 2002 17:07:41 +0200 Date: Tue, 16 Jul 2002 17:07:41 +0200 From: Ralf Baechle To: Pete Popov Cc: linux-mips Subject: Re: PATCH Message-ID: <20020716170741.E31186@dea.linux-mips.net> References: <1026772150.15665.145.camel@zeus.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1026772150.15665.145.camel@zeus.mvista.com>; from ppopov@mvista.com on Mon, Jul 15, 2002 at 03:29:10PM -0700 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 19 On Mon, Jul 15, 2002 at 03:29:10PM -0700, Pete Popov wrote: > --- include/asm-mips/pgtable.h.old Fri Jul 12 17:25:19 2002 > +++ include/asm-mips/pgtable.h Fri Jul 12 17:25:36 2002 > @@ -332,7 +332,9 @@ > > static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) > { > - return __pte(((pte).pte_low & _PAGE_CHG_MASK) | pgprot_val(newprot)); > + pte.pte_low &= _PAGE_CHG_MASK; > + pte.pte_low |= pgprot_val(newprot); > + return pte; > } This patch certainly doesn't apply to oss. Seems somebody did copy all the x86 pte_t and stuff into your tree without too much thinking ... Ralf From owner-linux-mips@oss.sgi.com Tue Jul 16 08:10:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GFAxRw032472 for ; Tue, 16 Jul 2002 08:10:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GFAxvq032471 for linux-mips-outgoing; Tue, 16 Jul 2002 08:10:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GFAqRw032462; Tue, 16 Jul 2002 08:10:52 -0700 Received: from adsl.pacbell.net ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GZC008PNL2C3J@mta7.pltn13.pbi.net>; Tue, 16 Jul 2002 08:15:48 -0700 (PDT) Date: Tue, 16 Jul 2002 08:15:56 -0700 From: Pete Popov Subject: Re: PATCH In-reply-to: <20020716170741.E31186@dea.linux-mips.net> To: Ralf Baechle Cc: linux-mips Message-id: <1026832557.3552.3.camel@adsl.pacbell.net> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7bit References: <1026772150.15665.145.camel@zeus.mvista.com> <20020716170741.E31186@dea.linux-mips.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 764 Lines: 23 On Tue, 2002-07-16 at 08:07, Ralf Baechle wrote: > On Mon, Jul 15, 2002 at 03:29:10PM -0700, Pete Popov wrote: > > > --- include/asm-mips/pgtable.h.old Fri Jul 12 17:25:19 2002 > > +++ include/asm-mips/pgtable.h Fri Jul 12 17:25:36 2002 > > @@ -332,7 +332,9 @@ > > > > static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) > > { > > - return __pte(((pte).pte_low & _PAGE_CHG_MASK) | pgprot_val(newprot)); > > + pte.pte_low &= _PAGE_CHG_MASK; > > + pte.pte_low |= pgprot_val(newprot); > > + return pte; > > } > > This patch certainly doesn't apply to oss. Seems somebody did copy all > the x86 pte_t and stuff into your tree without too much thinking ... That's right, I forgot you don't have the 36 bit code that uses pte_low and pte_high. Pete From owner-linux-mips@oss.sgi.com Tue Jul 16 08:17:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GFHLRw032613 for ; Tue, 16 Jul 2002 08:17:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GFHLt7032612 for linux-mips-outgoing; Tue, 16 Jul 2002 08:17:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GFHFRw032600 for ; Tue, 16 Jul 2002 08:17:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA29152; Tue, 16 Jul 2002 17:22:36 +0200 (MET DST) Date: Tue, 16 Jul 2002 17:22:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ulrich Drepper cc: "H. J. Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips In-Reply-To: <1026781165.3673.11.camel@myware.mynet> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 812 Lines: 22 On 15 Jul 2002, Ulrich Drepper wrote: > > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > > glibc always use ll/sc. > > Since I haven't seen any objections I've checked this patch in. [I must have missed the original mail, sorry.] It sucks performance-wise with no visible gain, so I don't think it is really desireable. Since the no-ll/sc case is handled correctly, I see no reason to remove the code. The kernel interface is awkward, I admit, but it works (and is even handcoded in assembly for performance gain) and we may able to develop a better one eventually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jul 16 08:37:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GFbNRw000424 for ; Tue, 16 Jul 2002 08:37:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GFbNsb000423 for linux-mips-outgoing; Tue, 16 Jul 2002 08:37:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GFbJRw000412 for ; Tue, 16 Jul 2002 08:37:19 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020716154210.TKZF8262.rwcrmhc52.attbi.com@ocean.lucon.org>; Tue, 16 Jul 2002 15:42:10 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id CA693125D8; Tue, 16 Jul 2002 08:42:08 -0700 (PDT) Date: Tue, 16 Jul 2002 08:42:08 -0700 From: "H. J. Lu" To: "Maciej W. Rozycki" Cc: Ulrich Drepper , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020716084208.A21699@lucon.org> References: <1026781165.3673.11.camel@myware.mynet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Tue, Jul 16, 2002 at 05:22:36PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 819 Lines: 24 On Tue, Jul 16, 2002 at 05:22:36PM +0200, Maciej W. Rozycki wrote: > On 15 Jul 2002, Ulrich Drepper wrote: > > > > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes > > > glibc always use ll/sc. > > > > Since I haven't seen any objections I've checked this patch in. > > [I must have missed the original mail, sorry.] > > It sucks performance-wise with no visible gain, so I don't think it is > really desireable. Since the no-ll/sc case is handled correctly, I see no Only is covered by the kernel interface. But it doesn't cover atomicity.h in glibc and libstdc++. > reason to remove the code. The kernel interface is awkward, I admit, but > it works (and is even handcoded in assembly for performance gain) and we > may able to develop a better one eventually. > H.J. From owner-linux-mips@oss.sgi.com Tue Jul 16 08:58:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GFwiRw000721 for ; Tue, 16 Jul 2002 08:58:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GFwiUH000720 for linux-mips-outgoing; Tue, 16 Jul 2002 08:58:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GFwbRw000710 for ; Tue, 16 Jul 2002 08:58:38 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17UUnP-00039n-00 for ; Tue, 16 Jul 2002 18:03:27 +0200 Date: Tue, 16 Jul 2002 18:03:27 +0200 From: Johannes Stezenbach To: linux-mips@oss.sgi.com Subject: PATCH: dma_addr_t 32/64bit mix-up Message-ID: <20020716160327.GA12079@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 608 Lines: 26 Hi, the following patch applies to the linux_2_4 branch. Index: linux/include/asm-mips/types.h =================================================================== RCS file: /cvs/linux/include/asm-mips/types.h,v retrieving revision 1.6.2.4 diff -u -r1.6.2.4 types.h --- linux/include/asm-mips/types.h 2002/06/26 22:36:37 1.6.2.4 +++ linux/include/asm-mips/types.h 2002/07/16 15:48:06 @@ -72,9 +72,9 @@ #define BITS_PER_LONG _MIPS_SZLONG #ifdef CONFIG_64BIT_PHYS_ADDR -typedef u32 dma_addr_t; -#else typedef u64 dma_addr_t; +#else +typedef u32 dma_addr_t; #endif typedef u64 dma64_addr_t; Johannes From owner-linux-mips@oss.sgi.com Tue Jul 16 09:55:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GGtVRw005765 for ; Tue, 16 Jul 2002 09:55:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GGtVMJ005764 for linux-mips-outgoing; Tue, 16 Jul 2002 09:55:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GGt4Rw005700 for ; Tue, 16 Jul 2002 09:55:04 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.11.6) with ESMTP id g6GGxwb05310; Tue, 16 Jul 2002 18:59:58 +0200 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id SAA17040; Tue, 16 Jul 2002 18:59:58 +0200 (MET DST) From: Karel van Houten Message-Id: <200207161659.SAA17040@sparta.research.kpn.com> Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Tue, 16 Jul 2002 18:59:58 +0200 (MET DST) Cc: vhouten@kpn.com ("Houten K.H.C. van (Karel)"), linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Jul 16, 2002 03:41:53 PM X-Url: http://www-lsdm.research.kpn.com/~karel X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9085 Lines: 203 Hi Maciej, You wrote: > > On Mon, 15 Jul 2002, Houten K.H.C. van (Karel) wrote: > > > I'm currently experimenting with software raid support on my decstation, > > and it looks fine! But I would love to use more than one SCSI chain > > for my raid disks. My DECStation contains a Turbochannel PMAZ-AA > > SCSI card, which WAS once supported in the driver, but isn't anymore. :-( > > That's basically the same as the /200's onboard SCSI. If that works, why > wouldn't an additional card (yup, I know the SCSI driver is a mess...)? > > [Looking at the sources...] The driver seems to have all necessary bits > to support additional HBAs. What do you mean by "not supported anymore?" > What does it report for PMAZ-AA cards? Usually I get SCSI bus problems when using the second chain. Even with devices that don't give any problems when connected to the on-board bus. Here is my boot log, with the scsi errors. In this case, I could use the disk on esp1, but I don't know if I can trust this... KN05 V2.1k >>cnfg 3: KN05 DEC V2.1k TCF0 (256 MB) (enet: 08-00-2b-37-63-76) (SCSI = 7) 1: PMAZ-AA DEC V5.3d TCF0 (SCSI = 7) >>cnfg 1 1: PMAZ-AA DEC V5.3d TCF0 (SCSI = 7) --------------------------------------------------- DEV PID VID REV SCSI DEV ===== ================== ========== ====== ======== rz1 C2490A COMPAQ 5193 DIR >>cnfg 3 3: KN05 DEC V2.1k TCF0 (256 MB) (enet: 08-00-2b-37-63-76) (SCSI = 7) --------------------------------------------------- DEV PID VID REV SCSI DEV ===== ================== ========== ====== ======== rz0 DCHS04U IBM 6464 DIR rz1 C2490A COMPAQ 5193 DIR rz2 C2490A COMPAQ 5193 DIR rz3 C2490A COMPAQ 5193 DIR rz4 C2490A COMPAQ 5193 DIR rz5 C2490A COMPAQ 5193 DIR rz6 CD-ROM CDU-55S SONY 1.0t CD-ROM cache: I(16 KB), D(16 KB), S(1024 KB); Scache line (32 bytes) processor revision (4.0) mem( 0): a0000000:a1ffffff ( 32 MB) mem( 1): a2000000:a3ffffff ( 32 MB) mem( 2): a4000000:a5ffffff ( 32 MB) mem( 3): a6000000:a7ffffff ( 32 MB) mem( 4): a8000000:a9ffffff ( 32 MB) mem( 5): aa000000:abffffff ( 32 MB) mem( 6): ac000000:adffffff ( 32 MB) mem( 7): ae000000:afffffff ( 32 MB) >>boot delo V0.7 Copyright 2000 Florian Lohoff Loading /etc/delo.conf .. ok Loading /boot/vmlinux-2.4.18 ....... ok This DECstation is a DS5000/2x0 CPU revision is: 00000440 FPU revision is: 00000500 Primary instruction cache 16kb, linesize 16 bytes. Primary data cache 16kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 32 bytes. Linux version 2.4.18 (root@elrond) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1)) #12 Mon Jul 1 18:07:40 MEST 2002 Determined physical RAM map: memory: 10000000 @ 00000000 (usable) On node 0 totalpages: 65536 zone(0): 65536 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 console=ttyS2 ro Calibrating delay loop... 59.86 BogoMIPS Memory: 255572k/262144k available (1804k kernel code, 6572k reserved, 108k data, 76k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 25.0 MHz (without parity) slot 1: DEC PMAZ-AA V5.3d Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Journalled Block Device driver loaded devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 lk201: DECstation LK keyboard driver v0.05. pty: 256 Unix98 ptys configured DECstation Z8530 serial driver version 0.07 ttyS00 at 0xbf900001 (irq = 14) is a Z85C30 SCC ttyS01 at 0xbf900009 (irq = 14) is a Z85C30 SCC ttyS02 at 0xbf980001 (irq = 15) is a Z85C30 SCC rtc: Digital DECstation epoch (2000) detected Real Time Clock Driver v1.10e block: 128 slots per queue, batch=32 declance.c: v0.009 by Linux MIPS DECstation task force eth0: IOASIC onboard LANCE, addr = 08:00:2b:37:63:76, irq = 16 SCSI subsystem driver Revision: 1.00 SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) ESP: Total of 2 ESP hosts found, 2 actually in use. scsi0 : ESP236 (NCR53C9x) scsi1 : ESP236 (NCR53C9x) esp0: AIEEE wide msg received esp0: hoping for msgout Vendor: IBM Model: DCHS04U Rev: 6464 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SONY Model: CD-ROM CDU-55S Rev: 1.0t Type: CD-ROM ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0 Attached scsi disk sdd at scsi0, channel 0, id 3, lun 0 Attached scsi disk sde at scsi0, channel 0, id 4, lun 0 Attached scsi disk sdf at scsi0, channel 0, id 5, lun 0 Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0 SCSI device sda: 8813870 512-byte hdwr sectors (4513 MB) Partition check: /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 esp0: target 1 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdb: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target1/lun0: p1 esp0: target 2 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdc: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target2/lun0: p1 esp0: target 3 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdd: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target3/lun0: p1 esp0: target 4 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sde: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target4/lun0: p1 esp0: target 5 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdf: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target5/lun0: p1 scsi : aborting command due to timeout : pid 52, scsi1, channel 0, id 1, lun 0 Request Sense 00 00 00 40 00 esp1: Aborting command esp1: dumping state esp1: SW [sreg<00> sstep<04> ireg<20>] esp1: HW reread [sreg<06> sstep ireg<00>] esp1: current command [tgt<01> lun<00> pphase cphase] esp1: disconnected SCSI host 1 abort (pid 52) timed out - resetting SCSI bus is being reset for host 1 channel 0. esp1: Resetting scsi bus esp1: Gross error sreg=40 esp1: SCSI bus reset interrupt esp1: Warning, live target 1 not responding to selection. esp1: Warning, live target 1 not responding to selection. SCSI device sdg: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host1/bus0/target1/lun0: p1 p2 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 esp0: target 6 [period 248ns offset 15 4.03MHz synchronous SCSI] sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.12 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP 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. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused PROM memory: 124k freed Freeing unused kernel memory: 76k freed INIT: version 2.84 booting Thanks for your time... Regards, -- 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 Jul 16 10:38:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GHcpRw008866 for ; Tue, 16 Jul 2002 10:38:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GHcp0r008865 for linux-mips-outgoing; Tue, 16 Jul 2002 10:38:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from clearcore.com (clrsrv@[208.141.182.168]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GHcgRw008855 for ; Tue, 16 Jul 2002 10:38:43 -0700 Received: (qmail 5492 invoked from network); 16 Jul 2002 17:43:33 -0000 Received: from clrsrv.clearcore.com (HELO clearcore.net) (192.168.1.1) by clrsrv.clearcore.com with SMTP; 16 Jul 2002 17:43:33 -0000 Message-ID: <3D345B45.50001@clearcore.net> Date: Tue, 16 Jul 2002 11:43:33 -0600 From: Joe George Organization: ClearCore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete Popov CC: Ralf Baechle , linux-mips Subject: Re: PATCH References: <1026772150.15665.145.camel@zeus.mvista.com> <20020716170741.E31186@dea.linux-mips.net> <1026832557.3552.3.camel@adsl.pacbell.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1406 Lines: 47 I'll disagree with both of you so I may learn from the flames. :-) First it's true the patch wasn't formatted for oss and should have been rejected on that basis. At least my patches would be. :) But Vivien Chappelier said it fixed his X server problem in mips64. CONFIG_64BIT_PHYS_ADDR is applicable to both 36 and 64 bit code, I think. So the crux of my question is, if an unsigned long long pte is and'ed with an unsigned long PAGE_CHG_MASK what happens to the upper 32 bits of pte. On a 64 bit processor is PAGE_CHG_MASK sign extended so everything is fine, or does it zero the upper 32 bits? Joe Pete Popov wrote: > On Tue, 2002-07-16 at 08:07, Ralf Baechle wrote: > >>On Mon, Jul 15, 2002 at 03:29:10PM -0700, Pete Popov wrote: >> >> >>>--- include/asm-mips/pgtable.h.old Fri Jul 12 17:25:19 2002 >>>+++ include/asm-mips/pgtable.h Fri Jul 12 17:25:36 2002 >>>@@ -332,7 +332,9 @@ >>> >>> static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) >>> { >>>- return __pte(((pte).pte_low & _PAGE_CHG_MASK) | pgprot_val(newprot)); >>>+ pte.pte_low &= _PAGE_CHG_MASK; >>>+ pte.pte_low |= pgprot_val(newprot); >>>+ return pte; >>> } >>> >>This patch certainly doesn't apply to oss. Seems somebody did copy all >>the x86 pte_t and stuff into your tree without too much thinking ... >> > > That's right, I forgot you don't have the 36 bit code that uses pte_low > and pte_high. > > Pete > From owner-linux-mips@oss.sgi.com Tue Jul 16 10:54:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GHssRw009073 for ; Tue, 16 Jul 2002 10:54:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GHss58009072 for linux-mips-outgoing; Tue, 16 Jul 2002 10:54:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GHsgRw009060; Tue, 16 Jul 2002 10:54:42 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA18561; Tue, 16 Jul 2002 10:59:32 -0700 Subject: Re: PATCH From: Pete Popov To: Joe George Cc: Ralf Baechle , linux-mips In-Reply-To: <3D345B45.50001@clearcore.net> References: <1026772150.15665.145.camel@zeus.mvista.com> <20020716170741.E31186@dea.linux-mips.net> <1026832557.3552.3.camel@adsl.pacbell.net> <3D345B45.50001@clearcore.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 16 Jul 2002 11:00:16 -0700 Message-Id: <1026842416.15665.199.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1794 Lines: 59 On Tue, 2002-07-16 at 10:43, Joe George wrote: > I'll disagree with both of you so I may learn from the flames. :-) > First it's true the patch wasn't formatted for oss and should have > been rejected on that basis. At least my patches would be. :) Well, my agreement with Ralf was that the patch wasn't formatted for the oss tree, not that it's not applicable. > But Vivien Chappelier said it fixed his X server problem in mips64. > CONFIG_64BIT_PHYS_ADDR is applicable to both 36 and 64 > bit code, I think. > > So the crux of my question is, if an unsigned long long pte is > and'ed with an unsigned long PAGE_CHG_MASK what happens > to the upper 32 bits of pte. On a 64 bit processor is PAGE_CHG_MASK > sign extended so everything is fine, or does it zero the upper > 32 bits? I think the upper 32 bits get zeroed out. The fact that it fixed Vivien's problem confirms this (he was running oss, right?) Pete > Joe > > > Pete Popov wrote: > > On Tue, 2002-07-16 at 08:07, Ralf Baechle wrote: > > > >>On Mon, Jul 15, 2002 at 03:29:10PM -0700, Pete Popov wrote: > >> > >> > >>>--- include/asm-mips/pgtable.h.old Fri Jul 12 17:25:19 2002 > >>>+++ include/asm-mips/pgtable.h Fri Jul 12 17:25:36 2002 > >>>@@ -332,7 +332,9 @@ > >>> > >>> static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) > >>> { > >>>- return __pte(((pte).pte_low & _PAGE_CHG_MASK) | pgprot_val(newprot)); > >>>+ pte.pte_low &= _PAGE_CHG_MASK; > >>>+ pte.pte_low |= pgprot_val(newprot); > >>>+ return pte; > >>> } > >>> > >>This patch certainly doesn't apply to oss. Seems somebody did copy all > >>the x86 pte_t and stuff into your tree without too much thinking ... > >> > > > > That's right, I forgot you don't have the 36 bit code that uses pte_low > > and pte_high. > > > > Pete > > > > From owner-linux-mips@oss.sgi.com Tue Jul 16 12:07:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GJ7MRw009696 for ; Tue, 16 Jul 2002 12:07:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GJ7MUp009695 for linux-mips-outgoing; Tue, 16 Jul 2002 12:07:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GJ79Rw009686; Tue, 16 Jul 2002 12:07:10 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6GJBuXb028970; Tue, 16 Jul 2002 12:11:56 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA11596; Tue, 16 Jul 2002 12:11:57 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6GJBub18183; Tue, 16 Jul 2002 21:11:57 +0200 (MEST) Message-ID: <3D347120.B9CAFF75@mips.com> Date: Tue, 16 Jul 2002 21:16:48 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" CC: Ralf Baechle , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Add sys/personality (Re: Personality) References: <3D33DAB2.353A4399@mips.com> <20020716123632.B17038@dea.linux-mips.net> <20020716090728.A22128@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1443 Lines: 40 Thanks. Now that we are at it, what should personality return in case it's called with a value, which isn't defined in the personality.h file. Should it return -EINVAL ? I don't think, that is the case at the moment, I believe you can set personality to anything. /Carsten "H. J. Lu" wrote: > On Tue, Jul 16, 2002 at 12:36:32PM +0200, Ralf Baechle wrote: > > On Tue, Jul 16, 2002 at 10:34:58AM +0200, Carsten Langgaard wrote: > > > > > The include/linux/personality.h file has changed between the 2.4.3 and > > > the 2.4.18 kernel. > > > Now there is a define of personality (#define personality(pers) (pers & > > > PER_MASK), but that breaks things for the users, if they include this > > > file. > > > The user wishes to call the glibc personality function (which do the > > > syscall), and not use the above definition. > > > > > > So I guess we need a "#ifdef __KERNEL__" around some of the code in > > > include/linux/personality.h (at least around the define of personality), > > > which then has to go into the glibc kernel header files. > > > > The general policy about such problems is to not use kernel include files > > from user applications directly. Hjl - maybe time for ? > > > > Here is a patch. > > H.J. > > ------------------------------------------------------------------------ > > glibc-personality.patchName: glibc-personality.patch > Type: Plain Text (text/plain) From owner-linux-mips@oss.sgi.com Tue Jul 16 14:52:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6GLqlRw015863 for ; Tue, 16 Jul 2002 14:52:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6GLqlOK015862 for linux-mips-outgoing; Tue, 16 Jul 2002 14:52:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from shaun.billgotchy.de (dialer101.kel.de.core.tng.de [213.178.65.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6GLqZRw015843 for ; Tue, 16 Jul 2002 14:52:37 -0700 Received: from shaun.billgotchy.de (shaun [127.0.0.1]) by shaun.billgotchy.de (8.12.4/8.12.4/Debian-4) with ESMTP id g6GLxvOJ008143 for ; Tue, 16 Jul 2002 23:59:57 +0200 Received: (from palic@localhost) by shaun.billgotchy.de (8.12.4/8.12.4/Debian-4) id g6GLxu3s008125 for linux-mips@oss.sgi.com; Tue, 16 Jul 2002 23:59:56 +0200 Date: Tue, 16 Jul 2002 23:59:56 +0200 From: Jan-Hendrik Palic To: linux-mips@oss.sgi.com Subject: Re: New Debian Indy... Message-ID: <20020716215956.GA5482@billgotchy.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020714094331.5207794b.mike@overlord.linux-dude.com> <20020714160806.A31002@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20020714160806.A31002@gandalf.physik.uni-konstanz.de> User-Agent: Mutt/1.3.27i X-Internet: http://www.billgotchy.de X-gpg-key: http://www.linux-debian.de/bin/m.asc X-Fingerprint: D146 9433 E94B DD1E AB41 398B 41C3 45C1 331F FF66 X-Key-ID: 331FFF66 X-OS: Linux Debian Unstable X-Private-Debian-Site: http://www.linux-debian.de X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1310 Lines: 48 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi ..=20 On Sun, Jul 14, 2002 at 04:08:06PM +0200, Guido Guenther wrote: >Hi Mike, >On Sun, Jul 14, 2002 at 09:43:31AM -0400, Mike Martin wrote: >[..snip..]=20 >> Things that don't work: >> X in 24 bit mode (I have the XL-24, 8 bit X works great) >Not supported in the debian packages but flaky support in XFree86 >4.2.0. See > http://honk.physik.uni-konstanz.de/linux-mips/x/x.html >for details. http://people.debian.org/~branden/sid/mips/ <---- there you will find debs for debian-unstable for xfree-4.2 :P Guido, please, can you add this to your side? Regards Jan --=20 .''`. Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- jan.palic@linux-debian.de | ' ` ` --n8g4imXOkfNTN/H1 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 iD8DBQE9NJdbQcNFwTMf/2YRAZHlAJ9NNE+4ujfj3tR5gw5UEGfwI1SEkACfVMK6 o/lVKwwHSabP0uq+UwLm9E0= =KNFX -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-linux-mips@oss.sgi.com Tue Jul 16 17:24:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H0OGRw014168 for ; Tue, 16 Jul 2002 17:24:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H0OG6f014166 for linux-mips-outgoing; Tue, 16 Jul 2002 17:24:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H0OBRw014114 for ; Tue, 16 Jul 2002 17:24:12 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6H0T1v06120; Wed, 17 Jul 2002 02:29:01 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6H0T1TF023401; Wed, 17 Jul 2002 02:29:02 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17Ucgf-0001ra-00; Wed, 17 Jul 2002 02:29:01 +0200 Date: Wed, 17 Jul 2002 02:29:01 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Pete Popov cc: linux-mips@oss.sgi.com Subject: Re: PATCH In-Reply-To: <1026842416.15665.199.camel@zeus.mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 602 Lines: 16 On 16 Jul 2002, Pete Popov wrote: > > But Vivien Chappelier said it fixed his X server problem in mips64. > I think the upper 32 bits get zeroed out. The fact that it fixed Vivien's > problem confirms this (he was running oss, right?) Well.. sorry guys, it seems it works with the old version as well now.. don't know what I messed up.. Anyway, on mips64, pte_t is an unsigned long, which is 64 bit, but PAGE_MASK in PAGE_CHG_MASK is 1UL << something, so it's 64 bit as well. Thus I guess there no problem with the old implementation in fact. (the problem was with me..) Sorry, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Wed Jul 17 00:10:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H7AERw030804 for ; Wed, 17 Jul 2002 00:10:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H7AEkF030802 for linux-mips-outgoing; Wed, 17 Jul 2002 00:10:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-5.us4.outblaze.com (205-158-62-95.outblaze.com [205.158.62.95]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H7AARw030757 for ; Wed, 17 Jul 2002 00:10:10 -0700 Received: (qmail 17399 invoked by uid 1001); 17 Jul 2002 07:15:03 -0000 Message-ID: <20020717071503.17397.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-5.us4.outblaze.com with http for balakris_ananth@email.com; Wed, 17 Jul 2002 02:15:03 -0500 From: "Balakrishnan Ananthanarayanan" To: linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, redhat-list@redhat.com Date: Wed, 17 Jul 2002 02:15:03 -0500 Subject: 2.4.17 - compile error X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-5.us4.outblaze.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 777 Lines: 23 Hello all, I'm compiling 2.4.17 to work for mips. I get the following error: mips_ksyms.c:44: parse error before 'this_object_must_be_defined_as_export_objs_in_the_Makefile' mips_ksyms.c:44: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' mips_ksyms.c:44: warning: data definition has no type or storage class The same errors repeat themselves at certain line numbers till line 140. What shud I do? Please help. Thanks, Balakrishnan -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Wed Jul 17 00:09:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H79nRw030642 for ; Wed, 17 Jul 2002 00:09:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H79npa030641 for linux-mips-outgoing; Wed, 17 Jul 2002 00:09:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H79ZRw030503; Wed, 17 Jul 2002 00:09:35 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6H7EMXb001476; Wed, 17 Jul 2002 00:14:22 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA08642; Wed, 17 Jul 2002 00:14:22 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6H7ELb29725; Wed, 17 Jul 2002 09:14:22 +0200 (MEST) Message-ID: <3D35194D.E880DDDA@mips.com> Date: Wed, 17 Jul 2002 09:14:21 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" CC: Ralf Baechle , GNU C Library , linux-mips@oss.sgi.com, linux kernel Subject: Re: PATCH: Add sys/personality (Re: Personality) References: <3D33DAB2.353A4399@mips.com> <20020716123632.B17038@dea.linux-mips.net> <20020716090728.A22128@lucon.org> <3D347120.B9CAFF75@mips.com> <20020716190814.A31309@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2306 Lines: 61 "H. J. Lu" wrote: > On Tue, Jul 16, 2002 at 09:16:48PM +0200, Carsten Langgaard wrote: > > Thanks. > > Now that we are at it, what should personality return in case it's called with a > > value, which isn't defined in the personality.h file. > > Should it return -EINVAL ? > > I don't think, that is the case at the moment, I believe you can set personality > > to anything. > > > > Like this? > No, I don't think the patch is correct. I don't know how this actually should work, maybe someone who do know can help out here. But it look like the idea is, that we have a default execution domain (linux), which have pers_low = 0 (PER_LINUX) and pers_high = 0. If one want other execution domains, one much call the register_exec_domain to register the execution domain and personality. So if personality is call with a value that isn't register, it then accept the personality and sets the execution domain to the default settings (which is linux). So the question is should personality, return -EINVAL, if it got a personality value which hasn't been registered or should it accept the personality, but set the execution domain to the default setting ? If the later is true, should it also accept values outside the values defined in the personality.h file ? So what should the following user calls return, if not registered in the kernel? personality(PER_BSD): personality(0x47): Could someone with a better understand than I, please comment this. > > H.J. > --- > --- kernel/exec_domain.c.per Mon Jun 10 10:05:27 2002 > +++ kernel/exec_domain.c Tue Jul 16 19:06:13 2002 > @@ -223,7 +223,8 @@ sys_personality(u_long personality) > > if (personality != 0xffffffff) { > set_personality(personality); > - if (current->personality != personality) > + if (personality < current->exec_domain->pers_low > + || personality > current->exec_domain->pers_high) > return -EINVAL; > } > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 17 01:25:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H8PuRw023559 for ; Wed, 17 Jul 2002 01:25:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H8PurC023557 for linux-mips-outgoing; Wed, 17 Jul 2002 01:25:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H8PnRw023525 for ; Wed, 17 Jul 2002 01:25:50 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA14437; Wed, 17 Jul 2002 10:31:13 +0200 (MET DST) Date: Wed, 17 Jul 2002 10:31:13 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H. J. Lu" cc: Ulrich Drepper , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips In-Reply-To: <20020716084208.A21699@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 929 Lines: 20 On Tue, 16 Jul 2002, H. J. Lu wrote: > > It sucks performance-wise with no visible gain, so I don't think it is > > really desireable. Since the no-ll/sc case is handled correctly, I see no > > Only is covered by the kernel interface. But it doesn't > cover atomicity.h in glibc and libstdc++. Even if nobody bothered fixing these, that doesn't mean some other code is useless. If you don't want to implement these with _test_and_set(), then just put equivalent ll/sc code there, which will work thanks to the emulation. Depending on the operation it may even be faster than _test_and_set() as ll/sc provides a generic way to perform atomic operations, while using _test_and_set() might require a spinlock. -- + 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 Jul 17 01:59:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H8xGRw002974 for ; Wed, 17 Jul 2002 01:59:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H8xGDL002973 for linux-mips-outgoing; Wed, 17 Jul 2002 01:59:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H8x6Rw002879; Wed, 17 Jul 2002 01:59:06 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6H93uXb001671; Wed, 17 Jul 2002 02:03:56 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id CAA11755; Wed, 17 Jul 2002 02:03:55 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6H93ub05893; Wed, 17 Jul 2002 11:03:56 +0200 (MEST) Message-ID: <3D3532FB.E227A5AD@mips.com> Date: Wed, 17 Jul 2002 11:03:55 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" , Ralf Baechle , linux-mips@oss.sgi.com Subject: pread and pwrite Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1182 Lines: 43 I'm running some tests from LTP, which tests pread and pwrite. It look like pread/pwrite doesn't do any check, if they are called with 'buf =NULL' or 'offset < 0', and no error is return. If I look in glibc in sysdeps/generic/pread.c it look like this: ssize_t __libc_pread (int fd, void *buf, size_t nbytes, off_t offset) { if (nbytes == 0) return 0; if (fd < 0) { __set_errno (EBADF); return -1; } if (buf == NULL || offset < 0) { __set_errno (EINVAL); return -1; } __set_errno (ENOSYS); return -1; } Here there is some checking for sane values and a proper error value is return. I guess this routine is replaced, if we have the syscall implemented with the sysdeps/unix/sysv/linux/mips/pread.c file. Here there is no check for sane values, is there any reason why ? The same thing goes for pwrite. /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 17 02:00:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6H904Rw003391 for ; Wed, 17 Jul 2002 02:00:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6H903ao003390 for linux-mips-outgoing; Wed, 17 Jul 2002 02:00:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6H8xuRw003288 for ; Wed, 17 Jul 2002 01:59:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA15068; Wed, 17 Jul 2002 11:05:24 +0200 (MET DST) Date: Wed, 17 Jul 2002 11:05:24 +0200 (MET DST) From: "Maciej W. Rozycki" To: Karel van Houten cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <200207161659.SAA17040@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1536 Lines: 36 Hi Karel, > Usually I get SCSI bus problems when using the second chain. > Even with devices that don't give any problems when connected to > the on-board bus. Here is my boot log, with the scsi errors. > In this case, I could use the disk on esp1, but I don't know > if I can trust this... > > KN05 V2.1k > >>cnfg > 3: KN05 DEC V2.1k TCF0 (256 MB) > (enet: 08-00-2b-37-63-76) > (SCSI = 7) > 1: PMAZ-AA DEC V5.3d TCF0 (SCSI = 7) Well, you have a mixed system, so it's quite possible PMAZ-A support does not work reliably anywhere. I don't have such a card, but specs are available and the support code is about one screen long. So it should be fairly trivial to verify -- I'll look at it. Also you have a KN05 system, which doesn't help, unfortunately. The KN05 module implements aggressive posting of uncached (read: iomem) writes (see also /proc/interrupts on your system) and synchronization primitives are non-existent. Since for half a year there is no agreement on how generic synchronization should look like for MIPS, I'm more and more tempted to add a local hack which at least will let DECstations to perform reliably. It's quite possible the lack of synchronization is the lone reason of your problems. 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 Jul 17 05:11:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HCBtRw022497 for ; Wed, 17 Jul 2002 05:11:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HCBt4r022496 for linux-mips-outgoing; Wed, 17 Jul 2002 05:11:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HCBlRw022487 for ; Wed, 17 Jul 2002 05:11:47 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.11.6) with ESMTP id g6HCGjW12579; Wed, 17 Jul 2002 14:16:45 +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 OAA00433; Wed, 17 Jul 2002 14:16:45 +0200 (MET DST) Message-Id: <200207171216.OAA00433@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Maciej W. Rozycki" cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-reply-to: Your message of "Wed, 17 Jul 2002 11:05:24 +0200." 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: Wed, 17 Jul 2002 14:16:45 +0200 From: "Houten K.H.C. van (Karel)" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1594 Lines: 45 Hi Maciej, > > KN05 V2.1k > > >>cnfg > > 3: KN05 DEC V2.1k TCF0 (256 MB) > > (enet: 08-00-2b-37-63-76) > > (SCSI = 7) > > 1: PMAZ-AA DEC V5.3d TCF0 (SCSI = 7) > > Well, you have a mixed system, so it's quite possible PMAZ-A support does > not work reliably anywhere. I don't have such a card, but specs are > available and the support code is about one screen long. So it should be > fairly trivial to verify -- I'll look at it. What do you mean by a mixed system? > Also you have a KN05 system, which doesn't help, unfortunately. The KN05 > module implements aggressive posting of uncached (read: iomem) writes (see > also /proc/interrupts on your system) and synchronization primitives are > non-existent. Since for half a year there is no agreement on how generic > synchronization should look like for MIPS, I'm more and more tempted to > add a local hack which at least will let DECstations to perform reliably. > It's quite possible the lack of synchronization is the lone reason of your > problems. Well, if there is anything I could do to help you by testing things, I'm eager to do so. I also have a 5000/200 system. Would it be interesting to put the PMAZ-AA into that system, and see how it behaves? 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 Wed Jul 17 05:53:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HCrfRw022959 for ; Wed, 17 Jul 2002 05:53:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HCrfWj022958 for linux-mips-outgoing; Wed, 17 Jul 2002 05:53:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HCrYRw022939 for ; Wed, 17 Jul 2002 05:53:36 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA10867; Wed, 17 Jul 2002 14:58:26 +0200 (MET DST) Date: Wed, 17 Jul 2002 14:58:26 +0200 (MEST) From: Geert Uytterhoeven To: Linux/MIPS Development , debian-mips@lists.debian.org Subject: anyone want an Indy? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 720 Lines: 21 ---------- Forwarded message ---------- Date: Tue, 16 Jul 2002 19:58:57 -0700 From: Larry McVoy To: linux-kernel@vger.kernel.org Subject: anyone want an Indy? I have an Indy with a drive, IRIX is installed, and I have no need for it. If there is a Linux kernel person who wants it and will do something useful (like support Linux on it or anything else which is for the general good of the Linux effort) contact me and I'll ship it to you. Cheers, --lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-mips@oss.sgi.com Wed Jul 17 06:29:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HDToRw023551 for ; Wed, 17 Jul 2002 06:29:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HDTo7b023550 for linux-mips-outgoing; Wed, 17 Jul 2002 06:29:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HDTZRw023541 for ; Wed, 17 Jul 2002 06:29:39 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA20711; Wed, 17 Jul 2002 15:35:04 +0200 (MET DST) Date: Wed, 17 Jul 2002 15:35:04 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <200207171216.OAA00433@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2416 Lines: 61 Hi Karel, > What do you mean by a mixed system? Both a PMAZ-A and an I/O ASIC-based controller. They differ. > I also have a 5000/200 system. Would it be interesting to put the > PMAZ-AA into that system, and see how it behaves? Well, the /200's onboard HBA is identical to a PMAZ-A. You don't need to rearrange hardware, although you may, just to be sure -- if the /200 works, then the problem is almost surely related to write posting implemented on the KN05 module which we currently don't handle (it's worked around in the driver in the I/O ASIC-related functions via an ugly hack). Just in case I am right, please check if the following hack helps with your PMAZ-A in your /260. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020717-dec_esp-test-0 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020717.macro/drivers/scsi/dec_esp.c linux-mips-2.4.19-rc1-20020717/drivers/scsi/dec_esp.c --- linux-mips-2.4.19-rc1-20020717.macro/drivers/scsi/dec_esp.c 2002-04-10 02:58:49.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020717/drivers/scsi/dec_esp.c 2002-07-17 13:24:59.000000000 +0000 @@ -486,12 +486,15 @@ static void pmaz_dma_drain(struct NCR_ES static void pmaz_dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length) { volatile int *dmareg = (volatile int *) (esp->slot + DEC_SCSI_DMAREG); + volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; if (length > ESP_TGT_DMA_SIZE) length = ESP_TGT_DMA_SIZE; *dmareg = TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE); + *dummy; + esp_virt_buffer = vaddress; scsi_current_length = length; } @@ -499,6 +502,7 @@ static void pmaz_dma_init_read(struct NC static void pmaz_dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length) { volatile int *dmareg = (volatile int *) ( esp->slot + DEC_SCSI_DMAREG ); + volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; memcpy((void *) (esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE), KSEG0ADDR((void *) vaddress), length); @@ -506,6 +510,7 @@ static void pmaz_dma_init_write(struct N *dmareg = TC_ESP_DMAR_WRITE | TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE); + *dummy; } static void pmaz_dma_ints_off(struct NCR_ESP *esp) From owner-linux-mips@oss.sgi.com Wed Jul 17 06:33:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HDXfRw023871 for ; Wed, 17 Jul 2002 06:33:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HDXfPJ023870 for linux-mips-outgoing; Wed, 17 Jul 2002 06:33:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HDXZRw023860 for ; Wed, 17 Jul 2002 06:33:36 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA14105; Wed, 17 Jul 2002 15:38:30 +0200 (MET DST) Date: Wed, 17 Jul 2002 15:38:30 +0200 (MEST) From: Geert Uytterhoeven To: Linux/MIPS Development , debian-mips@lists.debian.org Subject: Re: anyone want an Indy? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 926 Lines: 26 On Wed, 17 Jul 2002, Geert Uytterhoeven wrote: > ---------- Forwarded message ---------- > Date: Tue, 16 Jul 2002 19:58:57 -0700 > From: Larry McVoy > To: linux-kernel@vger.kernel.org > Subject: anyone want an Indy? > > I have an Indy with a drive, IRIX is installed, and I have no need for it. > If there is a Linux kernel person who wants it and will do something > useful (like support Linux on it or anything else which is for the > general good of the Linux effort) contact me and I'll ship it to you. BTW, I don't know _anything_ about the model and configuration of the Indy. Please ask Larry. 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 Wed Jul 17 06:55:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HDtwRw024270 for ; Wed, 17 Jul 2002 06:55:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HDtwfA024269 for linux-mips-outgoing; Wed, 17 Jul 2002 06:55:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft17-f190.dialo.tiscali.de [62.246.17.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HDtsRw024260 for ; Wed, 17 Jul 2002 06:55:55 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6HE0l526649; Wed, 17 Jul 2002 16:00:47 +0200 Date: Wed, 17 Jul 2002 16:00:47 +0200 From: Ralf Baechle To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com Subject: Re: PATCH: dma_addr_t 32/64bit mix-up Message-ID: <20020717160047.A26625@dea.linux-mips.net> References: <20020716160327.GA12079@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020716160327.GA12079@convergence.de>; from js@convergence.de on Tue, Jul 16, 2002 at 06:03:27PM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 271 Lines: 9 On Tue, Jul 16, 2002 at 06:03:27PM +0200, Johannes Stezenbach wrote: > the following patch applies to the linux_2_4 branch. Thanks for noticing. The fix isn't entirely right, the condition should be defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR). Ralf From owner-linux-mips@oss.sgi.com Wed Jul 17 07:13:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HEDZRw024766 for ; Wed, 17 Jul 2002 07:13:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HEDZ5U024765 for linux-mips-outgoing; Wed, 17 Jul 2002 07:13:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HEDRRw024753; Wed, 17 Jul 2002 07:13:27 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6HEIHXb002497; Wed, 17 Jul 2002 07:18:17 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA22521; Wed, 17 Jul 2002 07:18:18 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6HEIIb22956; Wed, 17 Jul 2002 16:18:18 +0200 (MEST) Message-ID: <3D357CA9.B847EDAC@mips.com> Date: Wed, 17 Jul 2002 16:18:17 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: pread and pwrite References: <3D3532FB.E227A5AD@mips.com> <20020717155930.A25258@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1089 Lines: 32 Ralf Baechle wrote: > On Wed, Jul 17, 2002 at 11:03:55AM +0200, Carsten Langgaard wrote: > > > > > Here there is some checking for sane values and a proper error value is > > return. > > I guess this routine is replaced, if we have the syscall implemented > > with the sysdeps/unix/sysv/linux/mips/pread.c file. > > Here there is no check for sane values, is there any reason why ? > > The same thing goes for pwrite. > > The kernel does it's own error checking. No need to duplicate that in > userspace. The kernel doesn't do this a proper check then. The pread/pwrite parameters is also convert in glibc, the 'offset' is convert from a 'long' to a 'long long', but it isn't sign extended. So when pread is call with offset -1, then kernel won't see it as -1. > > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 17 07:57:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HEv8Rw025391 for ; Wed, 17 Jul 2002 07:57:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HEv7VW025390 for linux-mips-outgoing; Wed, 17 Jul 2002 07:57:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HEv3Rw025380 for ; Wed, 17 Jul 2002 07:57:03 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020717150158.LBHW26053.rwcrmhc53.attbi.com@ocean.lucon.org>; Wed, 17 Jul 2002 15:01:58 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 502C6125D8; Wed, 17 Jul 2002 08:01:57 -0700 (PDT) Date: Wed, 17 Jul 2002 08:01:57 -0700 From: "H. J. Lu" To: "Maciej W. Rozycki" Cc: Ulrich Drepper , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Always use ll/sc for mips Message-ID: <20020717080157.B10247@lucon.org> References: <20020716084208.A21699@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Jul 17, 2002 at 10:31:13AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 23 On Wed, Jul 17, 2002 at 10:31:13AM +0200, Maciej W. Rozycki wrote: > On Tue, 16 Jul 2002, H. J. Lu wrote: > > > > It sucks performance-wise with no visible gain, so I don't think it is > > > really desireable. Since the no-ll/sc case is handled correctly, I see no > > > > Only is covered by the kernel interface. But it doesn't > > cover atomicity.h in glibc and libstdc++. > > Even if nobody bothered fixing these, that doesn't mean some other code > is useless. If you don't want to implement these with _test_and_set(), > then just put equivalent ll/sc code there, which will work thanks to the > emulation. Depending on the operation it may even be faster than > _test_and_set() as ll/sc provides a generic way to perform atomic > operations, while using _test_and_set() might require a spinlock. > I am not against reversing the sysdeps/unix/sysv/linux/mips/sys/tas.h change. But I am not so excited about it to do it myself. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 17 10:31:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HHVHRw027798 for ; Wed, 17 Jul 2002 10:31:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HHVH9H027797 for linux-mips-outgoing; Wed, 17 Jul 2002 10:31:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HHVBRw027788 for ; Wed, 17 Jul 2002 10:31:12 -0700 Received: from excalibur.cologne.de (p50850D8A.dip.t-dialin.net [80.133.13.138]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA11625; Wed, 17 Jul 2002 19:35:48 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17UskJ-00007r-00; Wed, 17 Jul 2002 19:37:51 +0200 Date: Wed, 17 Jul 2002 19:37:51 +0200 From: Karsten Merker To: Balakrishnan Ananthanarayanan , linux-mips@oss.sgi.com Subject: Re: 2.4.17 - compile error Message-ID: <20020717193751.A251@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , Balakrishnan Ananthanarayanan , linux-mips@oss.sgi.com References: <20020717071503.17397.qmail@email.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020717071503.17397.qmail@email.com>; from balakris_ananth@email.com on Wed, Jul 17, 2002 at 02:15:03AM -0500 X-No-Archive: yes X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1077 Lines: 27 On Wed, Jul 17, 2002 at 02:15:03AM -0500, Balakrishnan Ananthanarayanan wrote: > Hello all, > > I'm compiling 2.4.17 to work for mips. I get the following error: > > mips_ksyms.c:44: parse error before 'this_object_must_be_defined_as_export_objs_in_the_Makefile' > > mips_ksyms.c:44: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' > > mips_ksyms.c:44: warning: data definition has no type or storage class > > The same errors repeat themselves at certain line numbers till line 140. What shud I do? Please help. Which kernel tree do you try to compile and which target system do you want to build a kernel for? AFAIK the vanilla 2.4.17 will not build for mips at all, so you have to use a kernel tree with proper support for your target system (e.g. the one at oss.sgi.com). HTH, 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 Wed Jul 17 11:25:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HIPnRw029024 for ; Wed, 17 Jul 2002 11:25:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HIPnbe029023 for linux-mips-outgoing; Wed, 17 Jul 2002 11:25:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HIPTRw029014 for ; Wed, 17 Jul 2002 11:25:30 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.11.6) with ESMTP id g6HIUQW14989; Wed, 17 Jul 2002 20:30:26 +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 UAA04138; Wed, 17 Jul 2002 20:30:25 +0200 (MET DST) Message-Id: <200207171830.UAA04138@sparta.research.kpn.com> To: "Maciej W. Rozycki" cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-reply-to: Your message of "Wed, 17 Jul 2002 15:35:04 +0200." 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 Date: Wed, 17 Jul 2002 20:30:25 +0200 From: "Houten K.H.C. van (Karel)" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5751 Lines: 130 Hi Maciej, "Maciej W. Rozycki" writes: > ... > Just in case I am right, please check if the following hack helps with >your PMAZ-A in your /260. Sorry, same result. See attached log. Regards, Karel. >>boot 3/rz0 1/new delo V0.7 Copyright 2000 Florian Lohoff Loading /etc/delo.conf .. ok Loading /boot/vmlinux-2.4.18-test ....... ok This DECstation is a DS5000/2x0 CPU revision is: 00000440 FPU revision is: 00000500 Primary instruction cache 16kb, linesize 16 bytes. Primary data cache 16kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 32 bytes. Linux version 2.4.18 (root@elrond) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1)) #13 Wed Jul 17 16:58:38 MEST 2002 Determined physical RAM map: memory: 10000000 @ 00000000 (usable) On node 0 totalpages: 65536 zone(0): 65536 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 console=ttyS2 ro Calibrating delay loop... 59.86 BogoMIPS Memory: 255564k/262144k available (1813k kernel code, 6580k reserved, 108k data, 76k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 25.0 MHz (without parity) slot 1: DEC PMAZ-AA V5.3d Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Journalled Block Device driver loaded devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 lk201: DECstation LK keyboard driver v0.05. pty: 256 Unix98 ptys configured DECstation Z8530 serial driver version 0.07 ttyS00 at 0xbf900001 (irq = 14) is a Z85C30 SCC ttyS01 at 0xbf900009 (irq = 14) is a Z85C30 SCC ttyS02 at 0xbf980001 (irq = 15) is a Z85C30 SCC rtc: Digital DECstation epoch (2000) detected Real Time Clock Driver v1.10e block: 128 slots per queue, batch=32 declance.c: v0.009 by Linux MIPS DECstation task force eth0: IOASIC onboard LANCE, addr = 08:00:2b:37:63:76, irq = 16 SCSI subsystem driver Revision: 1.00 SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) ESP: Total of 2 ESP hosts found, 2 actually in use. scsi0 : ESP236 (NCR53C9x) scsi1 : ESP236 (NCR53C9x) esp0: AIEEE wide msg received esp0: hoping for msgout Vendor: IBM Model: DCHS04U Rev: 6464 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SONY Model: CD-ROM CDU-55S Rev: 1.0t Type: CD-ROM ANSI SCSI revision: 02 Vendor: COMPAQ Model: C2490A Rev: 5193 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0 Attached scsi disk sdd at scsi0, channel 0, id 3, lun 0 Attached scsi disk sde at scsi0, channel 0, id 4, lun 0 Attached scsi disk sdf at scsi0, channel 0, id 5, lun 0 Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0 SCSI device sda: 8813870 512-byte hdwr sectors (4513 MB) Partition check: /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 esp0: target 1 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdb: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target1/lun0: p1 esp0: target 2 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdc: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target2/lun0: p1 esp0: target 3 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdd: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target3/lun0: p1 esp0: target 4 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sde: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target4/lun0: p1 esp0: target 5 [period 200ns offset 8 5.00MHz synchronous SCSI] SCSI device sdf: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host0/bus0/target5/lun0: p1 scsi : aborting command due to timeout : pid 52, scsi1, channel 0, id 1, lun 0 Request Sense 00 00 00 40 00 esp1: Aborting command esp1: dumping state esp1: SW [sreg<00> sstep<04> ireg<20>] esp1: HW reread [sreg<06> sstep ireg<00>] esp1: current command [tgt<01> lun<00> pphase cphase] esp1: disconnected SCSI host 1 abort (pid 52) timed out - resetting SCSI bus is being reset for host 1 channel 0. esp1: Resetting scsi bus esp1: Gross error sreg=40 esp1: SCSI bus reset interrupt esp1: Warning, live target 1 not responding to selection. esp1: Warning, live target 1 not responding to selection. SCSI device sdg: 4110000 512-byte hdwr sectors (2104 MB) /dev/scsi/host1/bus0/target1/lun0: p1 p2 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 esp0: target 6 [period 248ns offset 15 4.03MHz synchronous SCSI] sr0: scsi-1 drive From owner-linux-mips@oss.sgi.com Wed Jul 17 12:17:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HJHuRw029967 for ; Wed, 17 Jul 2002 12:17:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HJHupc029965 for linux-mips-outgoing; Wed, 17 Jul 2002 12:17:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HJHoRw029950 for ; Wed, 17 Jul 2002 12:17:51 -0700 Received: from excalibur.cologne.de (p50851E15.dip.t-dialin.net [80.133.30.21]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA08870 for ; Wed, 17 Jul 2002 21:22:45 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17UuQ3-000181-00 for ; Wed, 17 Jul 2002 21:25:03 +0200 Date: Wed, 17 Jul 2002 21:25:03 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Current CVS (2.4.19-rc1) broken on DECstations Message-ID: <20020717212503.A4332@excalibur.cologne.de> 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.2.5i X-No-Archive: yes X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 851 Lines: 24 Hallo everybody, it looks like the current oss.sgi.com 2.4 cvs (currently 2.4.19-rc1) is broken on DECstations. The kernel boots on a DS 5000/150, but using the onboard LANCE does not work. Using ifconfig gives a "SIOCSIFLAGS: Resource temporarily not available and the kernel tells "lance: Can't get DMA IRQ 24". Besides the LANCE problems, everything else seems to work, although I have not yet done extensive testing (fb, keyboard and harddisk seem to work). Can anyone confirm this? Any idea what is broken? I am currently rather short on time, so going back in CVS to find the date of breakage might need some time. Regards, 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 Wed Jul 17 13:05:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HK5FRw030423 for ; Wed, 17 Jul 2002 13:05:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HK5FRp030422 for linux-mips-outgoing; Wed, 17 Jul 2002 13:05:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HK53Rw030401; Wed, 17 Jul 2002 13:05:03 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6HK9sXb003747; Wed, 17 Jul 2002 13:09:54 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA10513; Wed, 17 Jul 2002 13:09:54 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6HK9rb10252; Wed, 17 Jul 2002 22:09:54 +0200 (MEST) Message-ID: <3D35D036.1EE50ADA@mips.com> Date: Wed, 17 Jul 2002 22:14:46 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: pread and pwrite References: <3D3532FB.E227A5AD@mips.com> <20020717155930.A25258@dea.linux-mips.net> <3D357CA9.B847EDAC@mips.com> <20020717120108.A14143@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1314 Lines: 38 "H. J. Lu" wrote: > On Wed, Jul 17, 2002 at 04:18:17PM +0200, Carsten Langgaard wrote: > > Ralf Baechle wrote: > > > > > On Wed, Jul 17, 2002 at 11:03:55AM +0200, Carsten Langgaard wrote: > > > > > > > > > > > Here there is some checking for sane values and a proper error value is > > > > return. > > > > I guess this routine is replaced, if we have the syscall implemented > > > > with the sysdeps/unix/sysv/linux/mips/pread.c file. > > > > Here there is no check for sane values, is there any reason why ? > > > > The same thing goes for pwrite. > > > > > > The kernel does it's own error checking. No need to duplicate that in > > > userspace. > > > > The kernel doesn't do this a proper check then. > > The pread/pwrite parameters is also convert in glibc, the 'offset' is > > convert from a 'long' to a 'long long', but it isn't sign extended. > > So when pread is call with offset -1, then kernel won't see it as -1. > > > > Please check it out: > > http://sources.redhat.com/ml/libc-alpha/2002-07/msg00188.html > > H.J. So the same issue has been raised today on the glibc list, amazing. I guess the problem has existed quite some time. But it look like the patch will fix the problem. Do you know if the patch has been committed and which version of glibc will it then be fixed in ? Thanks, /Carsten From owner-linux-mips@oss.sgi.com Wed Jul 17 15:36:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6HMaYRw008339 for ; Wed, 17 Jul 2002 15:36:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6HMaY92008338 for linux-mips-outgoing; Wed, 17 Jul 2002 15:36:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from wilde.langlois-comp.com (IDENT:root@lsanca1-ar21-4-63-024-153.lsanca1.dsl-verizon.net [4.63.24.153]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6HMaWRw008325 for ; Wed, 17 Jul 2002 15:36:32 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by wilde.langlois-comp.com (8.11.6/8.11.6) id g6HMoI025878 for linux-mips@oss.sgi.com; Wed, 17 Jul 2002 15:50:18 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Mark Langlois Reply-To: mark@langlois-comp.com To: linux-mips@oss.sgi.com Subject: Indy Composite video input Date: Wed, 17 Jul 2002 15:50:18 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02071715501808.03661@wilde.langlois-comp.com> Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 207 Lines: 5 I have been trying to find information on how to use the Indy's composite video and s-video inputs with Linux. Anyone have any information on codecs, video capture etc. with these devices? Mark Langlois From owner-linux-mips@oss.sgi.com Wed Jul 17 20:13:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I3D1Rw013518 for ; Wed, 17 Jul 2002 20:13:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I3D1js013517 for linux-mips-outgoing; Wed, 17 Jul 2002 20:13:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I3CvRw013508 for ; Wed, 17 Jul 2002 20:12:57 -0700 Received: from dea.linux-mips.net (shaft16-f92.dialo.tiscali.de [62.246.16.92]) 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 UAB04075 for ; Wed, 17 Jul 2002 20:13:45 -0700 (PDT) mail_from (ralf@linux-mips.net) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g6HDxUT26639; Wed, 17 Jul 2002 15:59:30 +0200 Date: Wed, 17 Jul 2002 15:59:30 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: pread and pwrite Message-ID: <20020717155930.A25258@dea.linux-mips.net> References: <3D3532FB.E227A5AD@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D3532FB.E227A5AD@mips.com>; from carstenl@mips.com on Wed, Jul 17, 2002 at 11:03:55AM +0200 X-Accept-Language: de,en,fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 474 Lines: 15 On Wed, Jul 17, 2002 at 11:03:55AM +0200, Carsten Langgaard wrote: > > Here there is some checking for sane values and a proper error value is > return. > I guess this routine is replaced, if we have the syscall implemented > with the sysdeps/unix/sysv/linux/mips/pread.c file. > Here there is no check for sane values, is there any reason why ? > The same thing goes for pwrite. The kernel does it's own error checking. No need to duplicate that in userspace. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 18 01:17:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I8HTRw019438 for ; Thu, 18 Jul 2002 01:17:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I8HT9R019437 for linux-mips-outgoing; Thu, 18 Jul 2002 01:17:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I8HORw019428 for ; Thu, 18 Jul 2002 01:17:25 -0700 Received: from pippin.physik.uni-konstanz.de (pippin.physik.uni-konstanz.de [134.34.144.92]) by gandalf.physik.uni-konstanz.de (Postfix) with ESMTP id 5164B8D35 for ; Thu, 18 Jul 2002 10:17:46 +0200 (CEST) Received: from agx by pippin.physik.uni-konstanz.de with local (Exim 3.35 #1 (Debian)) id 17V6Tp-0004AO-00; Thu, 18 Jul 2002 10:17:45 +0200 Date: Thu, 18 Jul 2002 10:17:45 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: Indy Composite video input Message-ID: <20020718081745.GA15938@pippin> Mail-Followup-To: linux-mips@oss.sgi.com References: <02071715501808.03661@wilde.langlois-comp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02071715501808.03661@wilde.langlois-comp.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 463 Lines: 11 Hi, On Wed, Jul 17, 2002 at 03:50:18PM -0700, Mark Langlois wrote: > I have been trying to find information on how to use the Indy's composite > video and s-video inputs with Linux. Anyone have any information on codecs, > video capture etc. with these devices? The driver vor the vino is still under development. Ladislav Michl is working on this. Documentation on the vino can be found at: ftp://oss.sgi.com/pub/linux/mips/doc/indy/vino Regards, -- Guido From owner-linux-mips@oss.sgi.com Thu Jul 18 02:28:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6I9STRw020874 for ; Thu, 18 Jul 2002 02:28:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6I9STWn020873 for linux-mips-outgoing; Thu, 18 Jul 2002 02:28:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6I9SMRw020860 for ; Thu, 18 Jul 2002 02:28:22 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.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 CAA06469 for ; Thu, 18 Jul 2002 02:28: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 LAA10305; Thu, 18 Jul 2002 11:26:00 +0200 (MET DST) Date: Thu, 18 Jul 2002 11:26:00 +0200 (MET DST) From: "Maciej W. Rozycki" To: Karsten Merker cc: linux-mips@oss.sgi.com Subject: Re: Current CVS (2.4.19-rc1) broken on DECstations In-Reply-To: <20020717212503.A4332@excalibur.cologne.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1454 Lines: 30 On Wed, 17 Jul 2002, Karsten Merker wrote: > it looks like the current oss.sgi.com 2.4 cvs (currently 2.4.19-rc1) is > broken on DECstations. The kernel boots on a DS 5000/150, but using > the onboard LANCE does not work. Using ifconfig gives a "SIOCSIFLAGS: > Resource temporarily not available and the kernel tells "lance: Can't get > DMA IRQ 24". Thanks for the report. It's a stupid bug in the KN02BA IRQ routing table. I'm committing the following fix to the CVS. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020717-lance-merr-0 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020717.macro/arch/mips/dec/setup.c linux-mips-2.4.19-rc1-20020717/arch/mips/dec/setup.c --- linux-mips-2.4.19-rc1-20020717.macro/arch/mips/dec/setup.c 2002-06-27 02:57:18.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020717/arch/mips/dec/setup.c 2002-07-18 09:21:42.000000000 +0000 @@ -426,7 +426,7 @@ static int kn02ba_interrupt[DEC_NR_INTS] [DEC_IRQ_TC2] = DEC_CPU_IRQ_NR(KN02BA_CPU_INR_TC2), [DEC_IRQ_TIMER] = -1, [DEC_IRQ_VIDEO] = -1, - [DEC_IRQ_ASC_MERR] = IO_IRQ_NR(IO_INR_LANCE_MERR), + [DEC_IRQ_ASC_MERR] = IO_IRQ_NR(IO_INR_ASC_MERR), [DEC_IRQ_ASC_ERR] = IO_IRQ_NR(IO_INR_ASC_ERR), [DEC_IRQ_ASC_DMA] = IO_IRQ_NR(IO_INR_ASC_DMA), [DEC_IRQ_FLOPPY_ERR] = -1, From owner-linux-mips@oss.sgi.com Thu Jul 18 07:26:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IEQbRw000943 for ; Thu, 18 Jul 2002 07:26:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IEQbCH000942 for linux-mips-outgoing; Thu, 18 Jul 2002 07:26:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IEQVRw000933 for ; Thu, 18 Jul 2002 07:26:32 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA17216; Thu, 18 Jul 2002 16:27:31 +0200 (MET DST) Date: Thu, 18 Jul 2002 16:27:31 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <200207171830.UAA04138@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 986 Lines: 24 Hi Karel, > Sorry, same result. See attached log. Thanks for the report. Apart from missing WB flushing, there is nothing obviously broken in the PMAZ-A code -- I'll look at the problem more deeply later. The driver seems to work to some extent as it was able to retrieve inquiry data, so it's not broken in principle. It would be great if you could check if the driver works for the /200's onboard PMAZ-A. If it worked there, I'd suspect a bug in the NCR53C8x support core. But please don't put a second PMAZ-A into your /200 -- for an unclear reason the driver only supports a single I/O ASIC-based HBA and a single additional PMAZ-A board. All PMAZ-A boards share operational variables with one another, so using more than a single one leads to data corruption. 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 Thu Jul 18 08:19:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IFJ6Rw001949 for ; Thu, 18 Jul 2002 08:19:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IFJ62q001948 for linux-mips-outgoing; Thu, 18 Jul 2002 08:19:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IFJ0Rw001938 for ; Thu, 18 Jul 2002 08:19:01 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.11.6) with ESMTP id g6IFJYt24042; Thu, 18 Jul 2002 17:19:34 +0200 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id RAA18230; Thu, 18 Jul 2002 17:19:34 +0200 (MET DST) From: Karel van Houten Message-Id: <200207181519.RAA18230@sparta.research.kpn.com> Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Thu, 18 Jul 2002 17:19:33 +0200 (MET DST) Cc: vhouten@kpn.com ("Houten K.H.C. van (Karel)"), linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Jul 18, 2002 04:27:31 PM X-Url: http://www-lsdm.research.kpn.com/~karel X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1011 Lines: 25 Hi Maciej, > > It would be great if you could check if the driver works for the /200's > onboard PMAZ-A. If it worked there, I'd suspect a bug in the NCR53C8x > support core. But please don't put a second PMAZ-A into your /200 -- for > an unclear reason the driver only supports a single I/O ASIC-based HBA and > a single additional PMAZ-A board. All PMAZ-A boards share operational > variables with one another, so using more than a single one leads to data > corruption. I have a 5000/200 running fine with the same kernel (the one without your patch). Or did you mean WITH your patch? The only problem is that delo can't handle the different prom in the /200, so that system has to boot over the network, but can use the local disks just fine. Regards, -- 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 Thu Jul 18 09:38:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IGcJRw002962 for ; Thu, 18 Jul 2002 09:38:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IGcJXG002961 for linux-mips-outgoing; Thu, 18 Jul 2002 09:38:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IGc6Rw002952 for ; Thu, 18 Jul 2002 09:38:07 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA19405; Thu, 18 Jul 2002 18:39:10 +0200 (MET DST) Date: Thu, 18 Jul 2002 18:39:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <200207181519.RAA18230@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1889 Lines: 53 Hi Karel, > I have a 5000/200 running fine with the same kernel (the one without > your patch). Or did you mean WITH your patch? The only problem If it works without the patch, it will also do with it. > is that delo can't handle the different prom in the /200, so that > system has to boot over the network, but can use the local disks just fine. OK, more writeback fixes. Please get the following patches: - patch-mips-2.4.18-20020530-mb-wb-8.gz, - patch-mips-2.4.18-20020625-wbflush-7.gz from 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/' and replace the hack I sent you yesterday with the following real fix. After applying the three patches you need to rebuild the kernel from scratch, i.e. do `make oldconfig dep clean boot modules' as the two above patches modify the kernel's configuration. Please report if this works or not. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020717-dec_esp-test-1 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020717.macro/drivers/scsi/dec_esp.c linux-mips-2.4.19-rc1-20020717/drivers/scsi/dec_esp.c --- linux-mips-2.4.19-rc1-20020717.macro/drivers/scsi/dec_esp.c 2002-04-10 02:58:49.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020717/drivers/scsi/dec_esp.c 2002-07-18 16:33:22.000000000 +0000 @@ -492,6 +492,8 @@ static void pmaz_dma_init_read(struct NC *dmareg = TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE); + iob(); + esp_virt_buffer = vaddress; scsi_current_length = length; } @@ -506,6 +508,7 @@ static void pmaz_dma_init_write(struct N *dmareg = TC_ESP_DMAR_WRITE | TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE); + iob(); } static void pmaz_dma_ints_off(struct NCR_ESP *esp) From owner-linux-mips@oss.sgi.com Thu Jul 18 09:42:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IGgXRw003065 for ; Thu, 18 Jul 2002 09:42:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IGgXms003064 for linux-mips-outgoing; Thu, 18 Jul 2002 09:42:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from marvin.ffo.org (dialin-145-254-057-082.arcor-ip.net [145.254.57.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IGgBRw003053 for ; Thu, 18 Jul 2002 09:42:18 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by marvin.ffo.org (8.11.6/8.10.2/SuSE Linux 8.10.0-0.3) id g6I5gcQ01010 for linux-mips@oss.sgi.com; Thu, 18 Jul 2002 07:42:38 +0200 Message-Id: <200207180542.g6I5gcQ01010@marvin.ffo.org> Content-Type: text/plain; charset="iso-8859-1" From: Frank Foerstemann To: "linux-mips" Subject: booting 2.5.3 kernel crashes Date: Thu, 18 Jul 2002 07:42:37 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 466 Lines: 17 Hi. I tried the 2.5.3 Kernel from CVS on my R44K-Indy. Compiling works fine, but when I try to boot the kernel it crashes after the message "Posix conformance testing ..." with the error: "Kernel unaligned instruction access in: unaligned.c::do_ade, line 409 ..." Does anybody know what's wrong ? Unfortunately I do not have a serial console connected to dump the whole message to disk. Is it possible to do that from the newport console ? Regards. Frank From owner-linux-mips@oss.sgi.com Thu Jul 18 10:15:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6IHFtRw003953 for ; Thu, 18 Jul 2002 10:15:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6IHFtlJ003952 for linux-mips-outgoing; Thu, 18 Jul 2002 10:15:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6IHFkRw003943; Thu, 18 Jul 2002 10:15:46 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020717190109.RXRS29588.sccrmhc01.attbi.com@ocean.lucon.org>; Wed, 17 Jul 2002 19:01:09 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id A87BB125D8; Wed, 17 Jul 2002 12:01:08 -0700 (PDT) Date: Wed, 17 Jul 2002 12:01:08 -0700 From: "H. J. Lu" To: Carsten Langgaard Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: pread and pwrite Message-ID: <20020717120108.A14143@lucon.org> References: <3D3532FB.E227A5AD@mips.com> <20020717155930.A25258@dea.linux-mips.net> <3D357CA9.B847EDAC@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D357CA9.B847EDAC@mips.com>; from carstenl@mips.com on Wed, Jul 17, 2002 at 04:18:17PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 965 Lines: 29 On Wed, Jul 17, 2002 at 04:18:17PM +0200, Carsten Langgaard wrote: > Ralf Baechle wrote: > > > On Wed, Jul 17, 2002 at 11:03:55AM +0200, Carsten Langgaard wrote: > > > > > > > > Here there is some checking for sane values and a proper error value is > > > return. > > > I guess this routine is replaced, if we have the syscall implemented > > > with the sysdeps/unix/sysv/linux/mips/pread.c file. > > > Here there is no check for sane values, is there any reason why ? > > > The same thing goes for pwrite. > > > > The kernel does it's own error checking. No need to duplicate that in > > userspace. > > The kernel doesn't do this a proper check then. > The pread/pwrite parameters is also convert in glibc, the 'offset' is > convert from a 'long' to a 'long long', but it isn't sign extended. > So when pread is call with offset -1, then kernel won't see it as -1. > Please check it out: http://sources.redhat.com/ml/libc-alpha/2002-07/msg00188.html H.J. From owner-linux-mips@oss.sgi.com Thu Jul 18 16:42:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6INgpRw010758 for ; Thu, 18 Jul 2002 16:42:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6INgpZJ010757 for linux-mips-outgoing; Thu, 18 Jul 2002 16:42:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6INfURw010722 for ; Thu, 18 Jul 2002 16:41:30 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020718190536.SZJH6023.sccrmhc02.attbi.com@ocean.lucon.org>; Thu, 18 Jul 2002 19:05:36 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id F3A11125D8; Thu, 18 Jul 2002 12:05:26 -0700 (PDT) Date: Thu, 18 Jul 2002 12:05:26 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.15 is released Message-ID: <20020718120526.A3063@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.3 required=5.0 tests=PORN_10,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 17825 Lines: 633 This is the beta release of binutils 2.12.90.0.15 for Linux, which is based on binutils 2002 0717 in CVS on sourecs.redhat.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 Please report any bugs related to binutils 2.12.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.12.90.0.14: 1. Update from binutils 2002 0717. 2. Fix an ia64 assembler bug. 3. Fix a symbol versioning bug. 4. You have to apply the modutils patch enclosed here in order to support System.map generated by the new nm. Changes from binutils 2.12.90.0.12: 1. Update from binutils 2002 0627. 2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel. Changes from binutils 2.12.90.0.11: 1. Update from binutils 2002 0618. 2. Fix a mips assembler bug. Changes from binutils 2.12.90.0.9: 1. Update from binutils 2002 0608. 2. Fix an ELF/mips SHF_MERGE bug. Changes from binutils 2.12.90.0.7: 1. Update from binutils 2002 0526. 2. Support "-z muldefs". Changes from binutils 2.12.90.0.4: 1. Update from binutils 2002 0423. 2. ELF EH frame bug fix. 3. MIPS ELF visibility bug fix. Changes from binutils 2.12.90.0.3: 1. Update from binutils 2002 0408. 2. Bug fixes for ELF/sparc. 3. Bug fixes for ELF/CRIS. Changes from binutils 2.12.90.0.1: 1. Update from binutils 2002 0323. 2. Fix linking a.out relocatable files with ELF. 3. Fix a PPC altivec assembler bug. Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. 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.12.90.0.15.tar.gz. Source code. 2. binutils-2.12.90.0.14-2.12.90.0.15.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.15-1.i386.rpm. IA-32 binary RPM for RedHat 7.3. There is no separate source rpm. You can do # rpm -ta binutils-2.12.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 07/17/2002 ---- > On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote: > > Something you might like to warn about in your next release.. > > > > The 2002-07-05 bfd change exposes a bug in modutils. depmod scans the > > output of nm for a `?' symbol type when looking for certain symbols. > > nm used to return `?' for symbols in sections other than some standard > > sections like .text and .data. Now, nm returns a better guess as to > > the symbol type. > No, but it parses System.map, which is generated by nm. This was in modutils-2.4.16. Fix follows. diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c --- modutils-2.4.16.orig/depmod/depmod.c 2002-04-28 17:23:35.000000000 +0930 +++ modutils-2.4.16/depmod/depmod.c 2002-07-15 16:41:20.000000000 +0930 @@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); /* The second word is either the symbol name or a type */ - if (p && strlen(p) == 1) { /* System.map */ + if (p && p[0] && !p[1]) { /* System.map */ is_mapfile = 1; - if (*p != '?') - p = NULL; - else - p = strtok(NULL, " \t\n"); + p = strtok(NULL, " \t\n"); } else { /* /proc/ksyms copy */ if (p && strtok(NULL, " \t\n")) p = NULL; @@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); if (is_mapfile) { - if (*p != '?') + if (!p || !p[0] || p[1]) continue; p = strtok(NULL, " \t\n"); /* Sparc has symbols like '.div' that need to be -- Alan Modra IBM OzLabs - Linux Technology Centre From owner-linux-mips@oss.sgi.com Thu Jul 18 17:33:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J0XCRw011389 for ; Thu, 18 Jul 2002 17:33:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J0XCCM011388 for linux-mips-outgoing; Thu, 18 Jul 2002 17:33:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J0X1Rw011379 for ; Thu, 18 Jul 2002 17:33:01 -0700 Received: from av.mvista.com (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 RAA04332 for ; Thu, 18 Jul 2002 17:34:06 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA06976; Thu, 18 Jul 2002 17:28:31 -0700 Message-ID: <3D375B4C.9000403@mvista.com> Date: Thu, 18 Jul 2002 17:20:28 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Malta bus error Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3105 Lines: 70 I got the following bus error on Malta. Does anybody know what causes the fault? Is there anyway to disable the error? Or we should install a malta bus_error_handler() to discard this kind of error? Apparently the error has something to do with the code layout as it only happens when I start to modify an unrelated function( do_ri()). I am using the latest linux_2_4 branch from oss.sgi.com CVS tree. Jun ---------------- Loading modules: modprobe: Can't open dependencies file /lib/modules/2.4.19-rc1/modules.dep (No s uch file or directory) Mounting local filesystems... nothing was mounted Cleaning: /etc/network/ifstate. Data bus error, epc == 8021b600, ra == 8013ea80 Oops in traps.c::do_be, line 459: $0 : 00000000 802f601e 802f601e 00000000 83ffffe0 802f6002 0000000c 802f601e $8 : 00006374 00002e63 00000002 6374652f 66690a0a 00000080 80355d48 2d205b20 $16: 0000001e 83ffffde 00000fde 0000001e 802f6000 0001ffde 00000001 80355ee0 $24: 0000000c 00000080 80354000 80355d50 00000000 8013ea80 Hi : fffd000c Lo : 0000fffc epc : 8021b600 Not tainted Status: 1000fc03 Cause : 0080201c Process rcS (pid: 43, stackpage=80354000) Stack: 80355e38 00000000 ffffffff 800028a0 80355ee4 10014408 ffffffff 00000080 802f6000 10014408 10019028 80355f30 00000000 10016da8 00000000 8013eb04 00000001 00000000 80355db8 802f6000 80355e38 8013fae0 8026d974 8026dbb0 000001d2 80005260 622f2123 732f6e69 0a230a68 74732023 2f747261 706f7473 74656e20 6b726f77 20676e69 6d656164 2e736e6f 230a230a 6b686320 666e6f63 203a6769 ... Call Trace: Code: 98a80000 98a90004 24c6fff0 <88a80003> 88a90007 98aa0008 98ab000c 88aa 000b 88ab000f CoreHI interrupt, shouldn't happen, so we die here!!! -------------------------- ffffffff8021b5e0 : ffffffff8021b5e0: 00064102 srl $t0,$a2,0x4 ffffffff8021b5e4: cca00060 lwc3 $0,96($a1) ffffffff8021b5e8: 11000014 beqz $t0,ffffffff8021b63c ffffffff8021b5ec: 30d8000f andi $t8,$a2,0xf ffffffff8021b5f0: cc810060 lwc3 $1,96($a0) ffffffff8021b5f4: 98a80000 lwr $t0,0($a1) ffffffff8021b5f8: 98a90004 lwr $t1,4($a1) ffffffff8021b5fc: 24c6fff0 addiu $a2,$a2,-16 ffffffff8021b600: 88a80003 lwl $t0,3($a1) ffffffff8021b604: 88a90007 lwl $t1,7($a1) ffffffff8021b608: 98aa0008 lwr $t2,8($a1) ffffffff8021b60c: 98ab000c lwr $t3,12($a1) ffffffff8021b610: 88aa000b lwl $t2,11($a1) ffffffff8021b614: 88ab000f lwl $t3,15($a1) ffffffff8021b618: cca00120 lwc3 $0,288($a1) ffffffff8021b61c: 24a50010 addiu $a1,$a1,16 ffffffff8021b620: ac880000 sw $t0,0($a0) ffffffff8021b624: ac890004 sw $t1,4($a0) ffffffff8021b628: ac8a0008 sw $t2,8($a0) ffffffff8021b62c: ac8b000c sw $t3,12($a0) ffffffff8021b630: cc810120 lwc3 $1,288($a0) From owner-linux-mips@oss.sgi.com Thu Jul 18 18:07:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J17aRw011734 for ; Thu, 18 Jul 2002 18:07:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J17asZ011733 for linux-mips-outgoing; Thu, 18 Jul 2002 18:07:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J17WRw011723 for ; Thu, 18 Jul 2002 18:07:32 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020719010803.OIGA24728.rwcrmhc51.attbi.com@ocean.lucon.org>; Fri, 19 Jul 2002 01:08:03 +0000 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id A8B93125D8; Thu, 18 Jul 2002 18:08:00 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 02289EC62; Thu, 18 Jul 2002 18:07:59 -0700 (PDT) Date: Thu, 18 Jul 2002 18:07:59 -0700 From: "H. J. Lu" To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: Malta bus error Message-ID: <20020718180759.A2091@lucon.org> References: <3D375B4C.9000403@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D375B4C.9000403@mvista.com>; from jsun@mvista.com on Thu, Jul 18, 2002 at 05:20:28PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 558 Lines: 16 On Thu, Jul 18, 2002 at 05:20:28PM -0700, Jun Sun wrote: > I got the following bus error on Malta. Does anybody know what causes the > fault? Is there anyway to disable the error? Or we should install a malta > bus_error_handler() to discard this kind of error? > > Apparently the error has something to do with the code layout as it only > happens when I start to modify an unrelated function( do_ri()). > > I am using the latest linux_2_4 branch from oss.sgi.com CVS tree. > I got zero problems with 2.4 kernel on oss as of Jul 11 08:18. H.J. From owner-linux-mips@oss.sgi.com Thu Jul 18 18:13:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J1DWRw011925 for ; Thu, 18 Jul 2002 18:13:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J1DVDf011924 for linux-mips-outgoing; Thu, 18 Jul 2002 18:13:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J1DPRw011913 for ; Thu, 18 Jul 2002 18:13:26 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA07863; Thu, 18 Jul 2002 18:13:57 -0700 Message-ID: <3D3765F1.6050606@mvista.com> Date: Thu, 18 Jul 2002 18:05:53 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "H. J. Lu" CC: linux-mips@oss.sgi.com Subject: Re: Malta bus error References: <3D375B4C.9000403@mvista.com> <20020718180759.A2091@lucon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1152 Lines: 39 H. J. Lu wrote: > On Thu, Jul 18, 2002 at 05:20:28PM -0700, Jun Sun wrote: > >>I got the following bus error on Malta. Does anybody know what causes the >>fault? Is there anyway to disable the error? Or we should install a malta >>bus_error_handler() to discard this kind of error? >> >>Apparently the error has something to do with the code layout as it only >>happens when I start to modify an unrelated function( do_ri()). >> >>I am using the latest linux_2_4 branch from oss.sgi.com CVS tree. >> > > > I got zero problems with 2.4 kernel on oss as of Jul 11 08:18. > Me neither, until I made the following change. I of course use my own config file. Using Malta's own BE handler to ignore bus error seems to fix the problem, although I am not sure if it is the right fix. Jun --- arch/mips/kernel/traps.c.orig Thu Jul 18 15:39:50 2002 +++ arch/mips/kernel/traps.c Thu Jul 18 16:49:32 2002 @@ -614,8 +614,7 @@ */ asmlinkage void do_ri(struct pt_regs *regs) { - if (!user_mode(regs)) - BUG(); + die_if_kernel("no ll/sc emulation for kernel code", regs); #ifndef CONFIG_CPU_HAS_LLSC Jun From owner-linux-mips@oss.sgi.com Thu Jul 18 23:39:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J6dMRw015519 for ; Thu, 18 Jul 2002 23:39:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J6dMXd015518 for linux-mips-outgoing; Thu, 18 Jul 2002 23:39:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J6dCRw015508 for ; Thu, 18 Jul 2002 23:39:12 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6J6dbXb010467; Thu, 18 Jul 2002 23:39:37 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA25042; Thu, 18 Jul 2002 23:39:38 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6J6ddb10587; Fri, 19 Jul 2002 08:39:39 +0200 (MEST) Message-ID: <3D37B42A.8561D3BC@mips.com> Date: Fri, 19 Jul 2002 08:39:38 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: "H. J. Lu" , linux-mips@oss.sgi.com Subject: Re: Malta bus error References: <3D375B4C.9000403@mvista.com> <20020718180759.A2091@lucon.org> <3D3765F1.6050606@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1667 Lines: 56 Jun Sun wrote: > H. J. Lu wrote: > > On Thu, Jul 18, 2002 at 05:20:28PM -0700, Jun Sun wrote: > > > >>I got the following bus error on Malta. Does anybody know what causes the > >>fault? Is there anyway to disable the error? Or we should install a malta > >>bus_error_handler() to discard this kind of error? > >> > >>Apparently the error has something to do with the code layout as it only > >>happens when I start to modify an unrelated function( do_ri()). > >> > >>I am using the latest linux_2_4 branch from oss.sgi.com CVS tree. > >> > > > > > > I got zero problems with 2.4 kernel on oss as of Jul 11 08:18. > > > > Me neither, until I made the following change. I of course use my own config > file. > > Using Malta's own BE handler to ignore bus error seems to fix the problem, > although I am not sure if it is the right fix. > Ignoring bus errors is usually not healthy, it indicates a problem, that I would prefer we find, instead of ignoring it. > > Jun > > --- arch/mips/kernel/traps.c.orig Thu Jul 18 15:39:50 2002 > +++ arch/mips/kernel/traps.c Thu Jul 18 16:49:32 2002 > @@ -614,8 +614,7 @@ > */ > asmlinkage void do_ri(struct pt_regs *regs) > { > - if (!user_mode(regs)) > - BUG(); > + die_if_kernel("no ll/sc emulation for kernel code", regs); > > #ifndef CONFIG_CPU_HAS_LLSC > > Jun -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Fri Jul 19 01:59:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J8xeRw018982 for ; Fri, 19 Jul 2002 01:59:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J8xeCX018981 for linux-mips-outgoing; Fri, 19 Jul 2002 01:59:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J8xaRw018965 for ; Fri, 19 Jul 2002 01:59:36 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6J905Y06111; Fri, 19 Jul 2002 11:00:05 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6J905TF032304; Fri, 19 Jul 2002 11:00:05 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17VTcK-0000C5-00; Fri, 19 Jul 2002 11:00:04 +0200 Date: Fri, 19 Jul 2002 11:00:04 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Frank Foerstemann cc: linux-mips@oss.sgi.com Subject: Re: booting 2.5.3 kernel crashes In-Reply-To: <200207180542.g6I5gcQ01010@marvin.ffo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 564 Lines: 17 > I tried the 2.5.3 Kernel from CVS on my R44K-Indy. Compiling works fine, but > when I try to boot the kernel it crashes after the message "Posix conformance > testing ..." with the error: > > "Kernel unaligned instruction access in: unaligned.c::do_ade, line 409 ..." > > Does anybody know what's wrong ? Yep: context switching. I've a patch for 2.5.4/mips64, I'm sending it again to Ralf and to this mailing list. Anyway, you get what you deserve playing with an unstable kernel :) (you may want to try the linux_2_4 branch) regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Fri Jul 19 02:11:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6J9B5Rw019202 for ; Fri, 19 Jul 2002 02:11:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6J9B5lJ019201 for linux-mips-outgoing; Fri, 19 Jul 2002 02:11:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6J9AdRw019182; Fri, 19 Jul 2002 02:10:40 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6J9BBY07249; Fri, 19 Jul 2002 11:11:11 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g6J9BBTF032698; Fri, 19 Jul 2002 11:11:11 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17VTn5-0000D1-00; Fri, 19 Jul 2002 11:11:11 +0200 Date: Fri, 19 Jul 2002 11:11:11 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] thread_info & stack fixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5384 Lines: 166 Hi, Here are fixes for the 2.5.4 kernel to update code that assumes "current = (task_struct *) $28". In the 2.5.4 kernel, register $28 now holds a thread_info struct rather than a task_struct, shared with the stack, i.e. the layout is $28: thread_info current_thread_info [...] $28+KERNEL_STACK_SIZE-n: top of the stack $28+KERNEL_STACK_SIZE: bottom of the stack See also the thread_union in include/linux/sched.h: union thread_union { struct thread_info thread_info; unsigned long stack[INIT_THREAD_SIZE/sizeof(long)]; }; This patch is for mips64 but I guess the same applies to mips. Vivien. =============================================================================== --- linux/include/asm-mips64/processor.h Tue Jul 9 22:03:12 2002 +++ linux.patch/include/asm-mips64/processor.h Sat Jul 13 18:02:51 2002 @@ -270,7 +270,7 @@ unsigned long get_wchan(struct task_struct *p); #define __PT_REG(reg) ((long)&((struct pt_regs *)0)->reg - sizeof(struct pt_regs)) -#define __KSTK_TOS(tsk) ((unsigned long)(tsk) + KERNEL_STACK_SIZE - 32) +#define __KSTK_TOS(tsk) ((unsigned long)(tsk->thread_info) + KERNEL_STACK_SIZE - 32) #define KSTK_EIP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(cp0_epc))) #define KSTK_ESP(tsk) (*(unsigned long *)(__KSTK_TOS(tsk) + __PT_REG(regs[29]))) --- linux/arch/mips64/kernel/r4k_switch.S Sat Jul 13 20:22:41 2002 +++ linux.patch/arch/mips64/kernel/r4k_switch.S Sat Jul 13 20:28:17 2002 @@ -40,8 +40,8 @@ */ move $28, a2 cpu_restore_nonscratch a1 - - daddiu t1, a1, KERNEL_STACK_SIZE-32 + + daddiu t1, $28, KERNEL_STACK_SIZE-32 set_saved_sp t1 t0 mfc0 t1, CP0_STATUS /* Do we really need this? */ diff -Naur linux/arch/mips64/kernel/process.c linux.patch/arch/mips64/kernel/process.c --- linux/arch/mips64/kernel/process.c Tue Jul 9 22:02:18 2002 +++ linux.patch/arch/mips64/kernel/process.c Sat Jul 13 17:51:18 2002 @@ -74,7 +74,7 @@ struct pt_regs *childregs; long childksp; - childksp = (unsigned long)p + KERNEL_STACK_SIZE - 32; + childksp = (unsigned long)ti + KERNEL_STACK_SIZE - 32; if (IS_FPU_OWNER()) { save_fp(p); @@ -87,7 +87,7 @@ regs->regs[2] = p->pid; if (childregs->cp0_status & ST0_CU0) { - childregs->regs[28] = (unsigned long) p; + childregs->regs[28] = (unsigned long) ti; childregs->regs[29] = childksp; ti->addr_limit = KERNEL_DS; } else { diff -Naur linux/arch/mips64/kernel/ptrace.c linux.patch/arch/mips64/kernel/ptrace.c --- linux/arch/mips64/kernel/ptrace.c Tue Jul 9 22:02:18 2002 +++ linux.patch/arch/mips64/kernel/ptrace.c Sat Jul 13 17:47:07 2002 @@ -102,7 +102,7 @@ struct pt_regs *regs; unsigned int tmp; - regs = (struct pt_regs *) ((unsigned long) child + + regs = (struct pt_regs *) ((unsigned long) child->thread_info + KERNEL_STACK_SIZE - 32 - sizeof(struct pt_regs)); ret = 0; @@ -191,7 +191,7 @@ case PTRACE_POKEUSR: { struct pt_regs *regs; ret = 0; - regs = (struct pt_regs *) ((unsigned long) child + + regs = (struct pt_regs *) ((unsigned long) child->thread_info + KERNEL_STACK_SIZE - 32 - sizeof(struct pt_regs)); switch (addr) { @@ -376,7 +376,7 @@ struct pt_regs *regs; unsigned long tmp; - regs = (struct pt_regs *) ((unsigned long) child + + regs = (struct pt_regs *) ((unsigned long) child->thread_info + KERNEL_STACK_SIZE - 32 - sizeof(struct pt_regs)); ret = 0; @@ -465,7 +465,7 @@ case PTRACE_POKEUSR: { struct pt_regs *regs; ret = 0; - regs = (struct pt_regs *) ((unsigned long) child + + regs = (struct pt_regs *) ((unsigned long) child->thread_info + KERNEL_STACK_SIZE - 32 - sizeof(struct pt_regs)); switch (addr) { diff -Naur linux/arch/mips64/lib/memcpy.S linux.patch/arch/mips64/lib/memcpy.S --- linux/arch/mips64/lib/memcpy.S Sun Dec 9 15:47:12 2001 +++ linux.patch/arch/mips64/lib/memcpy.S Sat Jul 13 12:57:20 2002 @@ -757,7 +757,8 @@ END(__rmemcpy) l_fixup: # clear the rest of the buffer - ld ta0, THREAD_BUADDR($28) + ld a2, TI_TASK($28) + ld ta0, THREAD_BUADDR(a2) nop dsubu a2, AT, ta0 # a2 bytes to go daddu a0, ta0 # compute start address in a1 diff -Naur linux/arch/mips64/lib/memset.S linux.patch/arch/mips64/lib/memset.S --- linux/arch/mips64/lib/memset.S Sun Dec 9 15:47:12 2001 +++ linux.patch/arch/mips64/lib/memset.S Sat Jul 13 13:03:22 2002 @@ -121,14 +121,16 @@ nop fwd_fixup: - ld t0, THREAD_BUADDR($28) + ld t2, TI_TASK($28) + ld t0, THREAD_BUADDR(t2) andi a2, 0x3f daddu a2, t1 jr ra dsubu a2, t0 partial_fixup: - ld t0, THREAD_BUADDR($28) + ld t2, TI_TASK($28) + ld t0, THREAD_BUADDR(t2) andi a2, 7 daddu a2, t1 jr ra diff -Naur linux/arch/mips64/sgi-ip27/ip27-init.c linux.patch/arch/mips64/sgi-ip27/ip27-init.c --- linux/arch/mips64/sgi-ip27/ip27-init.c Mon Jul 8 22:26:10 2002 +++ linux.patch/arch/mips64/sgi-ip27/ip27-init.c Sat Jul 13 17:48:10 2002 @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -492,7 +493,7 @@ */ LAUNCH_SLAVE(cputonasid(num_cpus),cputoslice(num_cpus), (launch_proc_t)MAPPED_KERN_RW_TO_K0(bootstrap), - 0, (void *)((unsigned long)p + + 0, (void *)((unsigned long)p->thread_info + KERNEL_STACK_SIZE - 32), (void *)p); /* From owner-linux-mips@oss.sgi.com Fri Jul 19 03:21:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JAL4Rw020894 for ; Fri, 19 Jul 2002 03:21:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JAL40k020893 for linux-mips-outgoing; Fri, 19 Jul 2002 03:21:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JAKtRw020879 for ; Fri, 19 Jul 2002 03:20:56 -0700 Received: from skynet.ie (orac [136.201.105.3]) by holly.csn.ul.ie (Postfix) with SMTP id 223E12B352; Fri, 19 Jul 2002 11:21:28 +0100 (IST) Received: from 63.84.187.40 (SquirrelMail authenticated user airlied) by www.csn.ul.ie with HTTP; Fri, 19 Jul 2002 11:21:28 +0100 (IST) Message-ID: <62037.63.84.187.40.1027074088.squirrel@www.csn.ul.ie> Date: Fri, 19 Jul 2002 11:21:28 +0100 (IST) Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? From: "Dave Airlie" To: In-Reply-To: References: <200207171830.UAA04138@sparta.research.kpn.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1884 Lines: 49 Hi, about 30 mins coding should be able to hack around the two cards in one system issue :-) (Flo did some work already). only esp_virt_buffer and scsi_current_length globals are used for the PMAZ-A as far as I know, and only in the read path between pmaz_dma_init_read and pmaz_dma_drain, also maybe the pmaz_cmd_buffer when I look at it. if there is nowhere in the esp to place them perhaps a priv void * needs to be added to the NCR core code and used to store this stuff, I meant to do it at the time, but twas 2 years ago and at the moment I'm nearly as far away from my DecStation as physically possible and not getting any closer for the forseeable :-) My reason of course was I didn't really know much about TC and that such a card existed orignally, and the original code only handled one IO-ASIC (which I think is okay)... Dave. in Laos. > Hi Karel, > >> Sorry, same result. See attached log. > > Thanks for the report. Apart from missing WB flushing, there is > nothing > obviously broken in the PMAZ-A code -- I'll look at the problem more > deeply later. The driver seems to work to some extent as it was able to > retrieve inquiry data, so it's not broken in principle. > > It would be great if you could check if the driver works for the /200's > onboard PMAZ-A. If it worked there, I'd suspect a bug in the NCR53C8x > support core. But please don't put a second PMAZ-A into your /200 -- > for an unclear reason the driver only supports a single I/O ASIC-based > HBA and a single additional PMAZ-A board. All PMAZ-A boards share > operational variables with one another, so using more than a single one > leads to data corruption. > > 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 Jul 19 04:40:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JBe2Rw022337 for ; Fri, 19 Jul 2002 04:40:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JBe2rJ022336 for linux-mips-outgoing; Fri, 19 Jul 2002 04:40:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JBdqRw022321 for ; Fri, 19 Jul 2002 04:39:53 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA08021; Fri, 19 Jul 2002 13:40:53 +0200 (MET DST) Date: Fri, 19 Jul 2002 13:40:52 +0200 (MET DST) From: "Maciej W. Rozycki" To: Dave Airlie cc: vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-Reply-To: <62037.63.84.187.40.1027074088.squirrel@www.csn.ul.ie> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1835 Lines: 45 Dave, > about 30 mins coding should be able to hack around the two cards in one > system issue :-) (Flo did some work already). Of course, if you have them, then don't hesitate to do that. I'm going to clean the driver up soon, but it's not a priority for me. > only esp_virt_buffer and scsi_current_length globals are used for the > PMAZ-A as far as I know, and only in the read path between > pmaz_dma_init_read and pmaz_dma_drain, also maybe the pmaz_cmd_buffer when > I look at it. Exactly. > if there is nowhere in the esp to place them perhaps a priv void * needs > to be added to the NCR core code and used to store this stuff, I meant to > do it at the time, but twas 2 years ago and at the moment I'm nearly as > far away from my DecStation as physically possible and not getting any > closer for the forseeable :-) No need to, "struct NCR_ESP" provides esp_id which may be used to index private data. > My reason of course was I didn't really know much about TC and that such a > card existed orignally, and the original code only handled one IO-ASIC > (which I think is okay)... Well, existing hardware permits up to six TC cards to be put into a single system. That's the limit for Alpha systems; for the DECstation, the limit is three (and you have an additional one onboard). Additionally, there exist dual-channel SCSI cards, namely PMAZB-A and PMAZC-A, of which the former uses NCR 53C84 chips and the latter one uses NCR 53C84F ones which are handled by the NCR53C9x.c driver. So theoretically up to 14 HBAs of this type may exist in a single system (2 are onboard on most TC Alphas). ;-) 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 Jul 19 05:39:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JCd2Rw023110 for ; Fri, 19 Jul 2002 05:39:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JCd2sk023109 for linux-mips-outgoing; Fri, 19 Jul 2002 05:39:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JCcARw023100 for ; Fri, 19 Jul 2002 05:38:11 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17VX1h-0001Sb-00; Fri, 19 Jul 2002 14:38:29 +0200 Date: Fri, 19 Jul 2002 14:38:29 +0200 From: Johannes Stezenbach To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?] Message-ID: <20020719123828.GA5521@convergence.de> Mail-Followup-To: Johannes Stezenbach , "Kevin D. Kissell" , linux-mips@oss.sgi.com References: <00ce01c229a4$a7d4ed40$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ce01c229a4$a7d4ed40$10eca8c0@grendel> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10843 Lines: 396 On Fri, Jul 12, 2002 at 03:04:07PM +0200, Kevin D. Kissell wrote: > I'm benchmarking some code that does lots of > semaphores, and with the libc from the "standard" > MIPS/SGI RH 7.1 distribution, those are done using > sysmips, in the interest of universality. I'm working on a platform without LL/SC, an embedded system/SOC with a NEC VR4120A CPU core. To find out the effect of sysmips vs. emulated LL/SC vs. the branch-likely trick posted by Kevin D. Kissell on Tue, 22 Jan 2002 18:16:25 +0100 I created an experimental patch for glibc-2.2.5 which allows run-time switching of the _test_and_set() and __compare_and_swap() implementation based on the presence of two "switch files" in /etc/. Despite its ugliness, I include the patch below for those interested. (Note: I built my glibc with -mips2, so the patch lacks .set mips2 directives.) One thing that caused me some headaches was that the __compare_and_swap() implementation in glibc-2.2.5 is broken (but fixed in glibc CVS and H.J.Lu's patch). For lack of a better benchmark I used some of the examples from glibc-2.2.5/linuxthreads/Examples. The numbers are from the third of three successive runs of 'time exN >/dev/null'. sysmips: ex1 real 0m0.273s user 0m0.040s sys 0m0.230s ex2 real 0m10.911s user 0m2.730s sys 0m8.180s ex3 real 0m3.648s user 0m3.400s sys 0m0.250s ex5 real 0m4.539s user 0m1.830s sys 0m2.710s ll/sc emulation: ex1 real 0m0.272s user 0m0.020s sys 0m0.250s ex2 real 0m4.726s user 0m1.660s sys 0m3.060s ex3 real 0m3.968s user 0m3.750s sys 0m0.220s ex5 real 0m4.069s user 0m1.710s sys 0m2.360s beql-hack: ex1 real 0m0.268s user 0m0.010s sys 0m0.260s ex2 real 0m3.988s user 0m1.620s sys 0m2.360s ex3 real 0m3.965s user 0m3.740s sys 0m0.220s ex5 real 0m2.606s user 0m1.000s sys 0m1.600s I think the poor performance of sysmips is caused by the absence of __compare_and_swap(), which forces libpthread to use less efficient implementations for semaphore and lock functions. Running each of the four tests three times yields around one million LL/SC emulations in /proc/cpuinfo. I think the beql-hack needs a kernel patch to guarantee k1 != MAGIC_COOKIE after each eret, but for a those few tests I was just taking my chance. Next, I'm trying to run the pthread tests from LTP. If someone has a better benchmark code for pthread performance, I'm interested. Regards, Johannes diff -uarN glibc-2.2.5.orig/linuxthreads/sysdeps/mips/pspinlock.c glibc-2.2.5/linuxthreads/sysdeps/mips/pspinlock.c --- glibc-2.2.5.orig/linuxthreads/sysdeps/mips/pspinlock.c Thu Jul 18 14:28:07 2002 +++ glibc-2.2.5/linuxthreads/sysdeps/mips/pspinlock.c Thu Jul 18 18:35:46 2002 @@ -23,7 +23,93 @@ #include #include "internals.h" -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) +#include +#include +#include +#include + +static int +_compare_and_swap_mips2 (long int *p, long int oldval, long int newval) +{ + long int ret; + + __asm__ __volatile__ + ("/* Inline compare & swap */\n\t" + "1:\n\t" + "ll %0,%4\n\t" + ".set push\n" + ".set noreorder\n\t" + "bne %0,%2,2f\n\t" + "move %0,$0\n\t" + "move %0,%3\n\t" + ".set pop\n\t" + "sc %0,%1\n\t" + "beqz %0,1b\n" + "2:\n\t" + "/* End compare & swap */" + : "=&r" (ret), "=m" (*p) + : "r" (oldval), "r" (newval), "m" (*p) + : "memory"); + + return ret; +} + +static int +_compare_and_swap_mips2_nollsc (long int *p, long int oldval, long int newval) +{ + long int r, t; + + __asm__ __volatile__ + (".set push\n\t" + ".set noreorder\n\t" + "li %1,0xffaaffaa\n\t" /* MAGIC_COOKIE */ + "1:\n\t" + "move $27,%1\n\t" /* set k1 */ + "lw %0,%5\n\t" /* r = *p */ + "bne %0,%3,3f\n\t" /* if (r != oldval) return 0 */ + "move %0,$0\n\t" /* r = 0 */ + "move %0,%4\n\t" /* r = newval */ + "beql $27,%1,2f\n\t" /* test k1 for change */ + "sw %0,%2\n\t" /* *p = r; return 1 */ + "b 1b\n\t" /* k1 changed, retry */ + "nop\n\t" + ".set pop\n\t" + "2:\n" + "li %0,1\n\t" /* r = 1 */ + "3:\n" + : "=&r" (r), "=&r" (t), "=m" (*p) + : "r" (oldval), "r" (newval), "m" (*p) + : "memory"); + + return r; +} + +int +compare_and_swap_is_available (void) +{ + int fp; + /* FIXME: write real test */ + if ((fp =open ("/etc/mips2_cpu_without_llsc", O_RDONLY)) != -1) + { + close(fp); + _mips_compare_and_swap = _compare_and_swap_mips2_nollsc; + return 1; + } + if ((fp =open ("/etc/mips2_cpu_with_llsc", O_RDONLY)) != -1) + { + close(fp); + _mips_compare_and_swap = _compare_and_swap_mips2; + return 1; + } + return 0; +} + +int (* _mips_compare_and_swap) (long int *p, long int oldval, long int newval) + = NULL; + + +#if 0 && (_MIPS_ISA >= _MIPS_ISA_MIPS2) + /* don't nother, no one uses this... */ /* This implementation is similar to the one used in the Linux kernel. */ int diff -uarN glibc-2.2.5.orig/linuxthreads/sysdeps/mips/pt-machine.h glibc-2.2.5/linuxthreads/sysdeps/mips/pt-machine.h --- glibc-2.2.5.orig/linuxthreads/sysdeps/mips/pt-machine.h Thu Jul 18 14:28:13 2002 +++ glibc-2.2.5/linuxthreads/sysdeps/mips/pt-machine.h Thu Jul 18 16:27:15 2002 @@ -33,41 +33,11 @@ /* Spinlock implementation; required. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - -PT_EI long int -testandset (int *spinlock) -{ - long int ret, temp; - - __asm__ __volatile__ - ("/* Inline spinlock test & set */\n\t" - "1:\n\t" - "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "bnez %0,2f\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n\t" - "/* End spinlock test & set */" - : "=&r" (ret), "=&r" (temp), "=m" (*spinlock) - : "m" (*spinlock) - : "memory"); - - return ret; -} - -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - PT_EI long int testandset (int *spinlock) { return _test_and_set (spinlock, 1); } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ /* Get some notion of the current stack. Need not be exactly the top @@ -78,32 +48,13 @@ /* Compare-and-swap for semaphores. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - #define HAS_COMPARE_AND_SWAP +#define TEST_FOR_COMPARE_AND_SWAP +extern int (* _mips_compare_and_swap) (long int *p, long int oldval, long int newval); +extern int compare_and_swap_is_available (void); + PT_EI int __compare_and_swap (long int *p, long int oldval, long int newval) { - long int ret; - - __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" - "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" - ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - " move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" - "2:\n\t" - "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) - : "r" (oldval), "r" (newval), "m" (*p) - : "memory"); - - return ret; + return _mips_compare_and_swap (p, oldval, newval); } - -#endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ diff -uarN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.5/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/mips/_test_and_set.c Thu Jul 18 00:21:15 2002 +++ glibc-2.2.5/sysdeps/unix/sysv/linux/mips/_test_and_set.c Thu Jul 18 14:39:01 2002 @@ -21,6 +21,12 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include +#include +#include #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES @@ -28,3 +34,80 @@ #endif #include "sys/tas.h" + + +static int +_test_and_set_mips2_nollsc (int *p, int v) __THROW +{ + int r, t; + + __asm__ __volatile__ + (".set push\n\t" + ".set noreorder\n\t" + "li %1,0xffaaffaa\n\t" /* MAGIC_COOKIE */ + "1:\n\t" + "move $27,%1\n\t" /* set k1 */ + "lw %0,%3\n\t" /* r = *p */ + "beq %0,%4,2f\n\t" /* if (*p == v) return r */ + "beql $27,%1,2f\n\t" /* test k1 for change */ + "sw %4,%2\n\t" /* *p = v; return r */ + "b 1b\n\t" /* retry */ + "nop\n\t" + ".set pop\n\t" + "2:\n" + : "=&r" (r), "=&r" (t), "=m" (*p) + : "m" (*p), "r" (v) + : "memory"); + + return r; +} + +static int +_test_and_set_mips2 (int *p, int v) __THROW +{ + int r, t; + + __asm__ __volatile__ + ("1:\n\t" + "ll %0,%3\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beq %0,%4,2f\n\t" + " move %1,%4\n\t" + ".set pop\n\t" + "sc %1,%2\n\t" + "beqz %1,1b\n" + "2:\n" + : "=&r" (r), "=&r" (t), "=m" (*p) + : "m" (*p), "r" (v) + : "memory"); + + return r; +} + +static int +_test_and_set_mips1 (int *p, int v) __THROW +{ + return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); +} + +static int +_mips_test_and_set_init (int *p, int v) __THROW +{ + int fp; + _mips_test_and_set = _test_and_set_mips1; + /* FIXME: write real test */ + if ((fp =open ("/etc/mips2_cpu_without_llsc", O_RDONLY)) != -1) + { + close(fp); + _mips_test_and_set = _test_and_set_mips2_nollsc; + } + else if ((fp =open ("/etc/mips2_cpu_with_llsc", O_RDONLY)) != -1) + { + close(fp); + _mips_test_and_set = _test_and_set_mips2; + } + return _mips_test_and_set (p, v); +} + +int (* _mips_test_and_set) (int *p, int v) __THROW = _mips_test_and_set_init; diff -uarN glibc-2.2.5.orig/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.5/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.5.orig/sysdeps/unix/sysv/linux/mips/sys/tas.h Thu Jul 18 00:13:21 2002 +++ glibc-2.2.5/sysdeps/unix/sysv/linux/mips/sys/tas.h Thu Jul 18 00:26:54 2002 @@ -27,6 +27,7 @@ __BEGIN_DECLS extern int _test_and_set (int *p, int v) __THROW; +extern int (* _mips_test_and_set) (int *p, int v) __THROW; #ifdef __USE_EXTERN_INLINES @@ -34,40 +35,11 @@ # define _EXTERN_INLINE extern __inline # endif -# if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - -_EXTERN_INLINE int -_test_and_set (int *p, int v) __THROW -{ - int r, t; - - __asm__ __volatile__ - ("1:\n\t" - "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "beq %0,%4,2f\n\t" - " move %1,%4\n\t" - ".set pop\n\t" - "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n" - : "=&r" (r), "=&r" (t), "=m" (*p) - : "m" (*p), "r" (v) - : "memory"); - - 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); + return _mips_test_and_set (p, v); } - -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* __USE_EXTERN_INLINES */ From owner-linux-mips@oss.sgi.com Fri Jul 19 07:30:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JEUIRw032522 for ; Fri, 19 Jul 2002 07:30:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JEUIbN032521 for linux-mips-outgoing; Fri, 19 Jul 2002 07:30:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JEU0Rw032505 for ; Fri, 19 Jul 2002 07:30:01 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17VYmA-0001YM-00 for ; Fri, 19 Jul 2002 16:30:34 +0200 Date: Fri, 19 Jul 2002 16:30:34 +0200 From: Johannes Stezenbach To: linux-mips@oss.sgi.com Subject: LTP testing: msgctl/IPC_STAT Message-ID: <20020719143034.GA5956@convergence.de> Mail-Followup-To: Johannes Stezenbach , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1785 Lines: 54 I was investigating LTP test suite failures of the msgctl01, msgctl02, msgsnd01 and msgsnd02 tests. It seems that they are caused by a mismatch between /usr/include/bits/msq.h and linux/include/asm-mips/msgbuf.h. I suggest the following patch which makes mips' msgbuf.h a copy of the one in include/asm-i386. Johannes Index: linux/include/asm-mips/msgbuf.h =================================================================== RCS file: /cvs/linux/include/asm-mips/msgbuf.h,v retrieving revision 1.1 diff -u -r1.1 msgbuf.h --- linux/include/asm-mips/msgbuf.h 2000/02/16 01:07:48 1.1 +++ linux/include/asm-mips/msgbuf.h 2002/07/19 14:20:29 @@ -2,26 +2,30 @@ #define _ASM_MSGBUF_H /* - * The msqid64_ds structure for alpha architecture. + * The msqid64_ds structure for mips architecture. * Note extra padding because this structure is passed back and forth * between kernel and user space. * * Pad space is left for: - * - 2 miscellaneous 64-bit values + * - 64-bit time_t to solve y2038 problem + * - 2 miscellaneous 32-bit values */ struct msqid64_ds { struct ipc64_perm msg_perm; __kernel_time_t msg_stime; /* last msgsnd time */ + unsigned long __unused1; __kernel_time_t msg_rtime; /* last msgrcv time */ + unsigned long __unused2; __kernel_time_t msg_ctime; /* last change time */ + unsigned long __unused3; unsigned long msg_cbytes; /* current number of bytes on queue */ unsigned long msg_qnum; /* number of messages in queue */ unsigned long msg_qbytes; /* max number of bytes on queue */ __kernel_pid_t msg_lspid; /* pid of last msgsnd */ __kernel_pid_t msg_lrpid; /* last receive pid */ - unsigned long __unused1; - unsigned long __unused2; + unsigned long __unused4; + unsigned long __unused5; }; #endif /* _ASM_MSGBUF_H */ From owner-linux-mips@oss.sgi.com Fri Jul 19 07:59:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JExxRw000301 for ; Fri, 19 Jul 2002 07:59:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JExx54000300 for linux-mips-outgoing; Fri, 19 Jul 2002 07:59:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JExgRw032758 for ; Fri, 19 Jul 2002 07:59:42 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020719150016.JDXX24728.rwcrmhc51.attbi.com@ocean.lucon.org>; Fri, 19 Jul 2002 15:00:16 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1BB90125D8; Fri, 19 Jul 2002 08:00:15 -0700 (PDT) Date: Fri, 19 Jul 2002 08:00:14 -0700 From: "H. J. Lu" To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: LTP testing: msgctl/IPC_STAT Message-ID: <20020719080014.A20377@lucon.org> References: <20020719143034.GA5956@convergence.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020719143034.GA5956@convergence.de>; from js@convergence.de on Fri, Jul 19, 2002 at 04:30:34PM +0200 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3404 Lines: 108 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 19, 2002 at 04:30:34PM +0200, Johannes Stezenbach wrote: > I was investigating LTP test suite failures of the msgctl01, > msgctl02, msgsnd01 and msgsnd02 tests. It seems that they > are caused by a mismatch between /usr/include/bits/msq.h > and linux/include/asm-mips/msgbuf.h. > > I suggest the following patch which makes mips' msgbuf.h > a copy of the one in include/asm-i386. > I prefer we fix glibc. Here is a patch. H.J. --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glibc-mips-msg.patch" 2002-07-19 H.J. Lu * sysdeps/unix/sysv/linux/mips/bits/msq.h: New. --- sysdeps/unix/sysv/linux/mips/bits/msq.h.mips Fri Jul 19 07:57:55 2002 +++ sysdeps/unix/sysv/linux/mips/bits/msq.h Fri Jul 19 07:57:15 2002 @@ -0,0 +1,74 @@ +/* Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. */ + +#ifndef _SYS_MSG_H +# error "Never use directly; include instead." +#endif + +#include + +/* Define options for message queue functions. */ +#define MSG_NOERROR 010000 /* no error if message is too big */ +#ifdef __USE_GNU +# define MSG_EXCEPT 020000 /* recv any msg except of specified type */ +#endif + +/* Types used in the structure definition. */ +typedef unsigned long int msgqnum_t; +typedef unsigned long int msglen_t; + + +/* Structure of record for one message inside the kernel. + The type `struct msg' is opaque. */ +struct msqid_ds +{ + struct ipc_perm msg_perm; /* structure describing operation permission */ + __time_t msg_stime; /* time of last msgsnd command */ + __time_t msg_rtime; /* time of last msgrcv command */ + __time_t msg_ctime; /* time of last change */ + unsigned long int __msg_cbytes; /* current number of bytes on queue */ + msgqnum_t msg_qnum; /* number of messages currently on queue */ + msglen_t msg_qbytes; /* max number of bytes allowed on queue */ + __pid_t msg_lspid; /* pid of last msgsnd() */ + __pid_t msg_lrpid; /* pid of last msgrcv() */ + unsigned long int __unused1; + unsigned long int __unused2; +}; + +#ifdef __USE_MISC + +# define msg_cbytes __msg_cbytes + +/* ipcs ctl commands */ +# define MSG_STAT 11 +# define MSG_INFO 12 + +/* buffer for msgctl calls IPC_INFO, MSG_INFO */ +struct msginfo + { + int msgpool; + int msgmap; + int msgmax; + int msgmnb; + int msgmni; + int msgssz; + int msgtql; + unsigned short int msgseg; + }; + +#endif /* __USE_MISC */ --/04w6evG8XlLl3ft-- From owner-linux-mips@oss.sgi.com Fri Jul 19 08:54:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JFsTRw002003 for ; Fri, 19 Jul 2002 08:54:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JFsTwk002002 for linux-mips-outgoing; Fri, 19 Jul 2002 08:54:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JFsORw001989 for ; Fri, 19 Jul 2002 08:54:25 -0700 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id IAA01973; Fri, 19 Jul 2002 08:54:46 -0700 (PDT) (envelope-from rh@matriplex.com) Date: Fri, 19 Jul 2002 08:54:46 -0700 (PDT) From: Richard Hodges To: Johannes Stezenbach cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?] In-Reply-To: <20020719123828.GA5521@convergence.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 978 Lines: 28 On Fri, 19 Jul 2002, Johannes Stezenbach wrote: > I'm working on a platform without LL/SC, an embedded system/SOC > with a NEC VR4120A CPU core. To find out the effect of sysmips > vs. emulated LL/SC vs. the branch-likely trick posted by > Kevin D. Kissell on Tue, 22 Jan 2002 18:16:25 +0100 > I created an experimental patch for glibc-2.2.5 which allows > run-time switching of the _test_and_set() and __compare_and_swap() > implementation based on the presence of two "switch files" in /etc/. ... > I think the beql-hack needs a kernel patch to guarantee k1 != > MAGIC_COOKIE after each eret, but for a those few tests I was just > taking my chance. Maybe something like this in front of every "eret" instruction? #ifdef CONFIG_CPU_VR41XX move $27,$0 #endif I am also working with an NEC core, and would much prefer to perform atomic operations in user space. (I understand that this trick is probably not SMP safe - I don't really care.) -Richard From owner-linux-mips@oss.sgi.com Fri Jul 19 08:54:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JFsFRw001973 for ; Fri, 19 Jul 2002 08:54:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JFsFco001972 for linux-mips-outgoing; Fri, 19 Jul 2002 08:54:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JFsARw001961 for ; Fri, 19 Jul 2002 08:54:11 -0700 Received: from excalibur.cologne.de (p5085144B.dip.t-dialin.net [80.133.20.75]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA27866 for ; Fri, 19 Jul 2002 17:54:42 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17Va80-0000Lp-00 for ; Fri, 19 Jul 2002 17:57:12 +0200 Date: Fri, 19 Jul 2002 17:57:12 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Current CVS (2.4.19-rc1) broken on DECstations Message-ID: <20020719175712.A651@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20020717212503.A4332@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jul 18, 2002 at 11:26:00AM +0200 X-No-Archive: yes X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 795 Lines: 24 On Thu, Jul 18, 2002 at 11:26:00AM +0200, Maciej W. Rozycki wrote: > Thanks for the report. It's a stupid bug in the KN02BA IRQ routing > table. I'm committing the following fix to the CVS. Thanks, the LANCE works again with your patch, but I have discovered another problem: hwclock does not work (it did wth earlier kernels). "hwclock --show" results in hwclock: ioctl() to /dev/rtc to turn on update interrupts failed unexpectedly, errno=25: Inappropriate ioctl for device. The kernel at least finds the RTC: "rtc: Digital DECstation epoch (2000) detected". Regards, 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 Fri Jul 19 09:21:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JGL2Rw002589 for ; Fri, 19 Jul 2002 09:21:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JGL17f002588 for linux-mips-outgoing; Fri, 19 Jul 2002 09:21:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JGKtRw002578 for ; Fri, 19 Jul 2002 09:20:56 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g6JGN8Dw008191; Fri, 19 Jul 2002 17:23:09 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g6JGM0R14222; Fri, 19 Jul 2002 17:22:00 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256BFB.005A407A ; Fri, 19 Jul 2002 17:25:47 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: linux-mips@oss.sgi.com cc: carstenl@mips.com Message-ID: <80256BFB.005A3F76.00@notesmta.eur.3com.com> Date: Fri, 19 Jul 2002 17:21:09 +0100 Subject: Mips32 icache vs dcache size typo Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 844 Lines: 27 The patch below fixes what looks like a typo on mips32_flush_icache_page() which uses 'dcache_size' instead of 'icache_size'. The patch is part of the one sent by Carsten and the same fix was included in a kernel supplied to us by Broadcom. I haven't had a chance to try the rest of the patch suggested by Carsten yet, but this looks like an important fix for processors where dcache_size != icache_size. Jon Burgess --- arch/mips/mm/c-mips32.c~ Wed May 29 05:03:17 2002 +++ arch/mips/mm/c-mips32.c Thu Jul 11 09:55:08 2002 @@ -303,7 +303,7 @@ if (!(vma->vm_flags & VM_EXEC)) return; - address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (dcache_size - 1)); + address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (icache_size - 1)); blast_icache_page_indexed(address); } From owner-linux-mips@oss.sgi.com Fri Jul 19 10:07:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH7iRw004162 for ; Fri, 19 Jul 2002 10:07:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH7iqx004161 for linux-mips-outgoing; Fri, 19 Jul 2002 10:07:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH7bRw004149 for ; Fri, 19 Jul 2002 10:07:38 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.11.6/8.11.6) with ESMTP id g6JH8Gr02138; Fri, 19 Jul 2002 19:08:16 +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 TAA04858; Fri, 19 Jul 2002 19:08:16 +0200 (MET DST) Message-Id: <200207191708.TAA04858@sparta.research.kpn.com> To: "Maciej W. Rozycki" cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com Subject: Re: DECStation: Support for PMAZ-AA TC SCSI card? In-reply-to: Your message of "Thu, 18 Jul 2002 18:39:09 +0200." 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 Date: Fri, 19 Jul 2002 19:08:16 +0200 From: "Houten K.H.C. van (Karel)" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 974 Lines: 34 Hi Maciej, "Maciej W. Rozycki" writes: > > OK, more writeback fixes. Please get the following patches: > >- patch-mips-2.4.18-20020530-mb-wb-8.gz, > >- patch-mips-2.4.18-20020625-wbflush-7.gz > >from 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/' and replace the hack I >sent you yesterday with the following real fix. After applying the three >patches you need to rebuild the kernel from scratch, i.e. do `make >oldconfig dep clean boot modules' as the two above patches modify the >kernel's configuration. > > Please report if this works or not. Yes! Now I can use the TC PMAZ-AA without problems. I've copied some data around, without any problems. Fsck found no problems on the fs on that drive. Thanks a lot. Will these patches go into the oss CVS (2.4) tree? BTW: Are your patches to the declance driver in a way that we can use one unified driver for the /240 and the /200 systems? I still use the driver modified by Dave for my /200 kernels. Regards, Karel. From owner-linux-mips@oss.sgi.com Fri Jul 19 10:08:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JH84Rw004218 for ; Fri, 19 Jul 2002 10:08:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JH84ph004217 for linux-mips-outgoing; Fri, 19 Jul 2002 10:08:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crisis.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JH6mRw004129; Fri, 19 Jul 2002 10:06:49 -0700 Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by crisis.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VbEJ-0007UC-00; Fri, 19 Jul 2002 19:07:47 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.35 #1 (Debian)) id 17VbCU-0005E3-00; Fri, 19 Jul 2002 19:05:54 +0200 To: linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: [PATCH] EISA bus support on Indigo-2 Organization: Metropolis -- Nowhere X-Attribution: maz X-Baby-1: =?iso-8859-1?q?Lo=EBn?= 12 juin 1996 13:10 X-Baby-2: None X-Love-1: Gone X-Love-2: Crazy-Cat Reply-to: mzyngier@freesurf.fr From: Marc Zyngier Date: 19 Jul 2002 19:05:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 16242 Lines: 66 --=-=-= Hi all, I found some time to update my basic EISA support for the Indigo-2 patch, so here it is (only works in PIO mode). Performance is much better that what it was two months ago, and is stable for my very basic usage (Indigo-2 as a router... yeah right). Here is a sample boot : ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4400 FPU ICACHE DCACHE SCACHE CPU revision is: 00000450 FPU revision is: 00000500 Primary instruction cache 16kb, linesize 16 bytes. Primary data cache 16kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 128 bytes. Linux version 2.4.19-rc1 (maz@lazy) (gcc version 2.95.4 20011002 (Debian prerelease)) #84 Thu Jul 18 20:52:19 CEST 2002 MC: SGI memory controller Revision 3 Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 00001000 @ 00001000 (reserved) memory: 0020d000 @ 08002000 (usable) memory: 0000d000 @ 0820f000 (reserved) memory: 00524000 @ 0821c000 (usable) memory: 000c0000 @ 08740000 (ROM data) memory: 0b800000 @ 08800000 (usable) On node 0 totalpages: 81920 zone(0): 36864 pages. zone(1): 45056 pages. zone(2): 0 pages. Kernel command line: root=/dev/sdb1 EISA: Probing bus... EISA: slot 2 : HWP1940 detected. EISA: slot 3 : TCM5093 detected. EISA: Detected 2 cards. ISA support compiled in. Calibrating system timer... 750000 [150.00 MHz CPU] GIO: Scanning for GIO cards... GIO: Card 0x7f @ 0x1f000000 GIO: Card 0x04 @ 0x1f400000 Console: colour dummy device 80x25 zs0: console input Console: ttyS0 (Zilog8530), 9600 baud Calibrating delay loop... 74.75 BogoMIPS Memory: 190348k/195780k available (1519k kernel code, 5432k reserved, 172k data, 56k init, 0k highmem) The machine currently runs with a 3c579 (EISA counterpart of the 3c509), and a HP100 10/100VG whose driver is not very happy on the Indigo-2... Anyway, the 3Com card is perfectly OK and runs with zero modification to the driver. I still have to try an ISA card in this beast, but at least I can now compile with ISA support (which was crashing the machine before...). Patch is against 2.4.19-rc1 from CVS as of yesterday. I'd really love to hear from someone about this (that is, if anyone cares at all...). M. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ip22-eisa-2.4.19-rc1.patch Content-Description: basic eisa support for Indigo-2 Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.154.2.23 diff -u -r1.154.2.23 config.in --- arch/mips/config.in 2002/07/15 00:24:29 1.154.2.23 +++ arch/mips/config.in 2002/07/19 06:41:26 @@ -313,6 +313,7 @@ define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_SWAP_IO_SPACE y fi if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; then define_bool CONFIG_NEW_IRQ y @@ -467,6 +468,15 @@ if [ "$CONFIG_ARC32" = "y" ]; then bool 'ARC console support' CONFIG_ARC_CONSOLE +fi + +if [ "$CONFIG_SGI_IP22" = "y" ]; then + dep_bool 'Indigo-2 (IP22) EISA bus support' CONFIG_IP22_EISA $CONFIG_EXPERIMENTAL +fi + +if [ "$CONFIG_IP22_EISA" = "y" ]; then + define_bool CONFIG_EISA y + bool ' ISA bus support' CONFIG_ISA fi bool 'Networking support' CONFIG_NET Index: arch/mips/sgi-ip22/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/Makefile,v retrieving revision 1.1.2.4 diff -u -r1.1.2.4 Makefile --- arch/mips/sgi-ip22/Makefile 2002/06/28 10:31:32 1.1.2.4 +++ arch/mips/sgi-ip22/Makefile 2002/07/19 06:41:37 @@ -18,6 +18,7 @@ ip22-gio.o ip22-rtc.o ip22-reset.o ip22-system.o ip22-setup.o obj-$(CONFIG_BOARD_SCACHE) += ip22-sc.o +obj-$(CONFIG_IP22_EISA) += ip22-eisa.o ip22-irq.o: ip22-irq.S Index: arch/mips/sgi-ip22/ip22-int.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-int.c,v retrieving revision 1.2.2.4 diff -u -r1.2.2.4 ip22-int.c --- arch/mips/sgi-ip22/ip22-int.c 2002/07/02 12:02:00 1.2.2.4 +++ arch/mips/sgi-ip22/ip22-int.c 2002/07/19 06:41:38 @@ -40,6 +40,7 @@ extern asmlinkage void indyIRQ(void); extern void do_IRQ(int irq, struct pt_regs *regs); +extern int ip22_eisa_init (void); static void enable_local0_irq(unsigned int irq) { @@ -413,5 +414,9 @@ setup_irq(SGI_MAP_0_IRQ, &map0_cascade); #ifdef I_REALLY_NEED_THIS_IRQ setup_irq(SGI_MAP_1_IRQ, &map1_cascade); +#endif +#ifdef CONFIG_IP22_EISA + if (!sgi_guiness) /* Only Indigo-2 have EISA stuff */ + ip22_eisa_init (); #endif } Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.1.2.12 diff -u -r1.1.2.12 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 2002/07/03 11:51:42 1.1.2.12 +++ arch/mips/sgi-ip22/ip22-setup.c 2002/07/19 06:41:38 @@ -28,6 +28,7 @@ #include #include #include +#include #include #ifdef CONFIG_REMOTE_DEBUG @@ -152,6 +153,9 @@ indy_sc_init(); #endif conswitchp = NULL; + + /* Set the IO space to some sane value */ + set_io_port_base (KSEG1ADDR (0x00080000)); /* ARCS console environment variable is set to "g?" for * graphics console, it is set to "d" for the first serial Index: include/asm-mips/dma.h =================================================================== RCS file: /cvs/linux/include/asm-mips/dma.h,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 dma.h --- include/asm-mips/dma.h 2002/06/30 12:36:35 1.8.2.1 +++ include/asm-mips/dma.h 2002/07/19 06:41:52 @@ -83,7 +83,13 @@ * Deskstations or Acer PICA but not the much more versatile DMA logic used * for the local devices on Acer PICA or Magnums. */ +#ifdef CONFIG_SGI_IP22 +/* Horrible hack to have a correct DMA window on IP22 */ +#include +#define MAX_DMA_ADDRESS (PAGE_OFFSET + SGIMC_SEG0_BADDR + 0x01000000) +#else #define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x01000000) +#endif /* 8237 DMA controllers */ #define IO_DMA1_BASE 0x00 /* 8 bit slave DMA, channels 0..3 */ Index: include/asm-mips/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips/io.h,v retrieving revision 1.29.2.12 diff -u -r1.29.2.12 io.h --- include/asm-mips/io.h 2002/06/26 22:36:37 1.29.2.12 +++ include/asm-mips/io.h 2002/07/19 06:41:53 @@ -30,7 +30,13 @@ #if defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) #define __ioswab8(x) (x) +#ifdef CONFIG_SGI_IP22 +/* IP22 seems braindead enough to swap 16bits values in hardware, but + not 32bits. Go figure... Can't tell without documentation. */ +#define __ioswab16(x) (x) +#else #define __ioswab16(x) swab16(x) +#endif #define __ioswab32(x) swab32(x) #else Index: include/asm-mips/sgi/sgint23.h =================================================================== RCS file: /cvs/linux/include/asm-mips/sgi/sgint23.h,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 sgint23.h --- include/asm-mips/sgi/sgint23.h 2001/12/14 20:49:49 1.5.2.1 +++ include/asm-mips/sgi/sgint23.h 2002/07/19 06:41:58 @@ -21,12 +21,13 @@ * HAL2 driver). This will prevent many complications, trust me ;-) * --ladis */ -#define SGINT_CPU 0 /* MIPS CPU define 8 interrupt sources */ -#define SGINT_LOCAL0 8 /* INDY has 8 local0 irq levels */ -#define SGINT_LOCAL1 16 /* INDY has 8 local1 irq levels */ -#define SGINT_LOCAL2 24 /* INDY has 8 local2 vectored irq levels */ -#define SGINT_LOCAL3 32 /* INDY has 8 local3 vectored irq levels */ -#define SGINT_END 40 /* End of 'spaces' */ +#define SGINT_EISA 0 /* INDIGO-2 has 16 EISA irq levels */ +#define SGINT_CPU 16 /* MIPS CPU define 8 interrupt sources */ +#define SGINT_LOCAL0 24 /* INDY has 8 local0 irq levels */ +#define SGINT_LOCAL1 32 /* INDY has 8 local1 irq levels */ +#define SGINT_LOCAL2 40 /* INDY has 8 local2 vectored irq levels */ +#define SGINT_LOCAL3 48 /* INDY has 8 local3 vectored irq levels */ +#define SGINT_END 56 /* End of 'spaces' */ /* * Individual interrupt definitions for the INDY and Indigo2 --- /dev/null Mon Dec 10 15:21:03 2001 +++ arch/mips/sgi-ip22/ip22-eisa.c Thu May 30 14:33:51 2002 @@ -0,0 +1,303 @@ +/* + * Basic EISA bus support for the SGI Indigo-2. + * + * (C) 2002 Pascal Dameme + * and Marc Zyngier + * + * This code is released under both the GPL version 2 and BSD + * licenses. Either license may be used. + * + * This code offers a very basic support for this EISA bus present in + * the SGI Indigo-2. It currently only supports PIO (forget about DMA + * for the time being). This is enough for a low-end ethernet card, + * but forget about your favorite SCSI card... + * + * TODO : + * - Fix bugs... + * - Add ISA support + * - Add DMA (yeah, right...). + * - Fix more bugs. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +extern int EISA_bus; +extern void do_IRQ(int irq, struct pt_regs *regs); + +#define EISA_MAX_SLOTS 4 +#define EISA_MAX_IRQ 16 + +#define EISA_TO_PHYS(x) (0x00080000 | (x)) +#define EISA_TO_KSEG1(x) ((void *) KSEG1ADDR(EISA_TO_PHYS((x)))) + +#define EIU_MODE_REG 0x0009ffc0 +#define EIU_STAT_REG 0x0009ffc4 +#define EIU_PREMPT_REG 0x0009ffc8 +#define EIU_QUIET_REG 0x0009ffcc +#define EIU_INTRPT_ACK 0x00090004 + +#define EISA_DMA1_STATUS 8 +#define EISA_INT1_CTRL 0x20 +#define EISA_INT1_MASK 0x21 +#define EISA_INT2_CTRL 0xA0 +#define EISA_INT2_MASK 0xA1 +#define EISA_DMA2_STATUS 0xD0 +#define EISA_DMA2_WRITE_SINGLE 0xD4 +#define EISA_EXT_NMI_RESET_CTRL 0x461 +#define EISA_INT1_EDGE_LEVEL 0x4D0 +#define EISA_INT2_EDGE_LEVEL 0x4D1 +#define EISA_VENDOR_ID_OFFSET 0xC80 + +#define EIU_WRITE_32(x,y) { *((u32 *) KSEG1ADDR(x)) = (u32) (y); mb(); } +#define EIU_READ_8(x) *((u8 *) KSEG1ADDR(x)) +#define EISA_WRITE_8(x,y) { *((u8 *) EISA_TO_KSEG1(x)) = (u8) (y); mb(); } +#define EISA_READ_8(x) *((u8 *) EISA_TO_KSEG1(x)) + +static char *decode_eisa_sig (u8 *sig) +{ + static char sig_str[8]; + u16 rev; + + if (sig[0] & 0x80) + return NULL; + + sig_str[0] = ((sig[0] >> 2) & 0x1f) + ('A' - 1); + sig_str[1] = (((sig[0] & 3) << 3) | (sig[1] >> 5)) + ('A' - 1); + sig_str[2] = (sig[1] & 0x1f) + ('A' - 1); + rev = (sig[2] << 8) | sig[3]; + sprintf (sig_str + 3, "%04X", rev); + + return sig_str; +} + +static void ip22_eisa_intr (int irq, void *dev_id, struct pt_regs *regs) +{ + u8 eisa_irq; + u8 dma1, dma2; + + eisa_irq = EIU_READ_8 (EIU_INTRPT_ACK); + dma1 = EISA_READ_8 (EISA_DMA1_STATUS); + dma2 = EISA_READ_8 (EISA_DMA2_STATUS); + + if (eisa_irq >= EISA_MAX_IRQ) + { + /* Oops, Bad Stuff Happened... */ + printk ("eisa_irq %d out of bound\n", eisa_irq); + + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); + } + else + do_IRQ (eisa_irq, regs); +} + +static void enable_eisa1_irq(unsigned int irq) +{ + unsigned long flags; + u8 mask; + + save_and_cli(flags); + + mask = EISA_READ_8 (EISA_INT1_MASK); + mask &= ~((u8) (1 << irq)); + EISA_WRITE_8 (EISA_INT1_MASK, mask); + + restore_flags(flags); +} + +static unsigned int startup_eisa1_irq(unsigned int irq) +{ + u8 edge; + + /* Only use edge interrupts for EISA */ + + edge = EISA_READ_8 (EISA_INT1_EDGE_LEVEL); + edge &= ~((u8) (1 << irq)); + EISA_WRITE_8 (EISA_INT1_EDGE_LEVEL, edge); + + enable_eisa1_irq(irq); + return 0; +} + +static void disable_eisa1_irq(unsigned int irq) +{ + u8 mask; + + mask = EISA_READ_8 (EISA_INT1_MASK); + mask |= ((u8) (1 << irq)); + EISA_WRITE_8 (EISA_INT1_MASK, mask); +} + +#define shutdown_eisa1_irq disable_eisa1_irq + +static void mask_and_ack_eisa1_irq (unsigned int irq) +{ + disable_eisa1_irq (irq); + + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); +} + +static void end_eisa1_irq (unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) + enable_eisa1_irq(irq); +} + +static struct hw_interrupt_type ip22_eisa1_irq_type = +{ + "IP22 EISA", + startup_eisa1_irq, + shutdown_eisa1_irq, + enable_eisa1_irq, + disable_eisa1_irq, + mask_and_ack_eisa1_irq, + end_eisa1_irq, + NULL +}; + +static void enable_eisa2_irq(unsigned int irq) +{ + unsigned long flags; + u8 mask; + + save_and_cli(flags); + + mask = EISA_READ_8 (EISA_INT2_MASK); + mask &= ~((u8) (1 << (irq - 8))); + EISA_WRITE_8 (EISA_INT2_MASK, mask); + + restore_flags(flags); +} + +static unsigned int startup_eisa2_irq(unsigned int irq) +{ + u8 edge; + + /* Only use edge interrupts for EISA */ + + edge = EISA_READ_8 (EISA_INT2_EDGE_LEVEL); + edge &= ~((u8) (1 << (irq - 8))); + EISA_WRITE_8 (EISA_INT2_EDGE_LEVEL, edge); + + enable_eisa2_irq(irq); + return 0; +} + +static void disable_eisa2_irq(unsigned int irq) +{ + u8 mask; + + mask = EISA_READ_8 (EISA_INT2_MASK); + mask |= ((u8) (1 << (irq - 8))); + EISA_WRITE_8 (EISA_INT2_MASK, mask); +} + +#define shutdown_eisa2_irq disable_eisa2_irq + +static void mask_and_ack_eisa2_irq (unsigned int irq) +{ + disable_eisa2_irq (irq); + + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); +} + +static void end_eisa2_irq (unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) + enable_eisa2_irq(irq); +} + +static struct hw_interrupt_type ip22_eisa2_irq_type = +{ + "IP22 EISA", + startup_eisa2_irq, + shutdown_eisa2_irq, + enable_eisa2_irq, + disable_eisa2_irq, + mask_and_ack_eisa2_irq, + end_eisa2_irq, + NULL +}; + +static struct irqaction eisa_action = + { ip22_eisa_intr, 0, 0, "EISA", NULL, NULL }; + +static struct irqaction cascade_action = + { no_action, 0, 0, "EISA cascade", NULL, NULL }; + +int __init ip22_eisa_init (void) +{ + int i, c; + char *str; + u8 *slot_addr; + + printk ("EISA: Probing bus...\n"); + for (c = 0, i = 1; i <= EISA_MAX_SLOTS; i++) + { + slot_addr = (u8 *) EISA_TO_KSEG1 ((0x1000 * i) + EISA_VENDOR_ID_OFFSET); + if ((str = decode_eisa_sig (slot_addr))) + { + printk ("EISA: slot %d : %s detected.\n", i, str); + c++; + } + } + printk ("EISA: Detected %d card%s.\n", c, c < 2 ? "" : "s"); +#ifdef CONFIG_ISA + printk ("ISA support compiled in.\n"); +#endif + + /* Warning : BlackMagicAhead(tm). + Please wave your favorite dead chicken over the busses */ + + /* First say hello to the EIU */ + EIU_WRITE_32 (EIU_PREMPT_REG, 0x0000FFFF); + EIU_WRITE_32 (EIU_QUIET_REG, 1); + EIU_WRITE_32 (EIU_MODE_REG, 0x40f3c07F); + + /* Now be nice to the EISA chipset */ + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 1); + for (i = 0; i < 10000; i++); /* Wait long enough for the dust to settle */ + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 0); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT2_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT1_MASK, 0); + EISA_WRITE_8 (EISA_INT2_MASK, 8); + EISA_WRITE_8 (EISA_INT1_MASK, 4); + EISA_WRITE_8 (EISA_INT2_MASK, 2); + EISA_WRITE_8 (EISA_INT1_MASK, 1); + EISA_WRITE_8 (EISA_INT2_MASK, 1); + EISA_WRITE_8 (EISA_INT1_MASK, 0xfb); + EISA_WRITE_8 (EISA_INT2_MASK, 0xff); + EISA_WRITE_8 (EISA_DMA2_WRITE_SINGLE, 0); + + for (i = SGINT_EISA; i < (SGINT_EISA + EISA_MAX_IRQ); i++) + { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = 0; + irq_desc[i].depth = 1; + if (i < (SGINT_EISA + 8)) + irq_desc[i].handler = &ip22_eisa1_irq_type; + else + irq_desc[i].handler = &ip22_eisa2_irq_type; + } + + /* Cannot use request_irq because of kmalloc not being ready at such + * an early stage. Yes, I've been bitten... */ + setup_irq (SGI_EISA_IRQ, &eisa_action); + setup_irq (SGINT_EISA + 2 , &cascade_action); + + EISA_bus = 1; + return 0; +} --=-=-= -- Places change, faces change. Life is so very strange. --=-=-=-- From owner-linux-mips@oss.sgi.com Fri Jul 19 14:22:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JLMERw029142 for ; Fri, 19 Jul 2002 14:22:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JLME1k029141 for linux-mips-outgoing; Fri, 19 Jul 2002 14:22:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JLM4Rw029132 for ; Fri, 19 Jul 2002 14:22:04 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA01965; Fri, 19 Jul 2002 14:22:39 -0700 Message-ID: <3D388136.2050502@mvista.com> Date: Fri, 19 Jul 2002 14:14:30 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, Ralf Baechle Subject: [PATCH] Let Malta and its friends use common timer interrupt code Content-Type: multipart/mixed; boundary="------------050706020400080501030203" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1964 Lines: 70 This is a multi-part message in MIME format. --------------050706020400080501030203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch let Malta and other MIPS boards use the common timer interrupt code. Not only it reduces maintainance, but also it lets Malta benefit from common improvement (such as Preemptible kernel). Jun --------------050706020400080501030203 Content-Type: text/plain; name="020719.a.mips-boards-use-ll_timer_interrupt.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="020719.a.mips-boards-use-ll_timer_interrupt.patch" diff -Nru linux/arch/mips/mips-boards/generic/time.c.orig linux/arch/mips/mips-boards/generic/time.c --- linux/arch/mips/mips-boards/generic/time.c.orig Tue May 7 20:05:01 2002 +++ linux/arch/mips/mips-boards/generic/time.c Fri Jul 19 13:55:42 2002 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -46,8 +47,6 @@ static unsigned int r4k_offset; /* Amount to increment compare reg each time */ static unsigned int r4k_cur; /* What counter should be at next timer irq */ -extern unsigned int mips_counter_frequency; - #define ALLINTS (IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4 | IE_IRQ5) #if defined(CONFIG_MIPS_ATLAS) @@ -71,13 +70,6 @@ void mips_timer_interrupt(struct pt_regs *regs) { - int cpu = smp_processor_id(); - int irq = MIPS_CPU_TIMER_IRQ; - - irq_enter(cpu, irq); - kstat.irqs[cpu][irq]++; - timer_interrupt(irq, NULL, regs); - if ((timer_tick_count++ % HZ) == 0) { mips_display_message(&display_string[display_count++]); if (display_count == MAX_DISPLAY_COUNT) @@ -85,10 +77,7 @@ } - irq_exit(cpu, irq); - - if (softirq_pending(cpu)) - do_softirq(); + ll_timer_interrupt(MIPS_CPU_TIMER_IRQ, regs); } /* --------------050706020400080501030203-- From owner-linux-mips@oss.sgi.com Fri Jul 19 14:30:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JLUrRw029255 for ; Fri, 19 Jul 2002 14:30:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JLUqMM029254 for linux-mips-outgoing; Fri, 19 Jul 2002 14:30:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JLUjRw029245 for ; Fri, 19 Jul 2002 14:30:45 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by deliverator.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 OAA09343 for ; Fri, 19 Jul 2002 14:31:24 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA02643; Fri, 19 Jul 2002 14:26:18 -0700 Message-ID: <3D388211.1030509@mvista.com> Date: Fri, 19 Jul 2002 14:18:09 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, Ralf Baechle Subject: [PATCH] Let us die more gracefully Content-Type: multipart/mixed; boundary="------------030107050804000506040108" X-Spam-Status: No, hits=-3.7 required=5.0 tests=MAY_BE_FORGED,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1030 Lines: 38 This is a multi-part message in MIME format. --------------030107050804000506040108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch dumps the offending code context rather than dumping the context of do_ri() function call itself. Apply to both branches. (Same is true with the previous patch) Jun --------------030107050804000506040108 Content-Type: text/plain; name="020719.b.graceful-death-in-do_ri.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="020719.b.graceful-death-in-do_ri.patch" diff -Nru linux/arch/mips/kernel/traps.c.orig linux/arch/mips/kernel/traps.c --- linux/arch/mips/kernel/traps.c.orig Thu Jul 18 15:39:50 2002 +++ linux/arch/mips/kernel/traps.c Thu Jul 18 16:49:32 2002 @@ -614,8 +614,7 @@ */ asmlinkage void do_ri(struct pt_regs *regs) { - if (!user_mode(regs)) - BUG(); + die_if_kernel("no ll/sc emulation for kernel code", regs); #ifndef CONFIG_CPU_HAS_LLSC --------------030107050804000506040108-- From owner-linux-mips@oss.sgi.com Fri Jul 19 15:45:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6JMjjRw030767 for ; Fri, 19 Jul 2002 15:45:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6JMjj3s030766 for linux-mips-outgoing; Fri, 19 Jul 2002 15:45:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6JMjdRw030757 for ; Fri, 19 Jul 2002 15:45:39 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA05399; Fri, 19 Jul 2002 15:46:14 -0700 Message-ID: <3D3894CD.5000609@mvista.com> Date: Fri, 19 Jul 2002 15:38:05 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: CoreHI interrupts on Malta Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1588 Lines: 38 After shuffling some lines of printk(), etc, I suddenly get the following panics. Anybody knows what they are? They seems to be recursive, BTW. If the interrupts really shouldn't happen, we probably should just disable IP5. Jun Loading modules: modprobe: Can't open dependencies file /lib/modules/2.4.19-rc1/modules.dep (No ) CoreHI interrupt, shouldn't happen, so we die here!!! epc : 80108a00 Status: 1000fc03 Cause : 00802000 badVaddr : 00000000 GT_INTRCAUSE = 43e00009 GT_CPU_ERR_ADDR = 0204000028 CoreHi interrupt in malta_int.c::corehi_irqdispatch, line 285: $0 : 00000000 7fff62e8 00000000 7fff63e8 7fff6308 83ffff28 00000000 83f3c364 $8 : 00000000 00000000 00000000 00000000 00000000 7fff62c8 00000000 00000000 $16: 7fff63c0 00000018 00000000 10013a88 00000000 ffffffff 00000000 10015188 $24: 00000000 00000018 83ffe000 83ffff30 00000008 801089e8 Hi : 00000000 Lo : 00000020 epc : 80108a00 Not tainted Status: 1000fc03 Cause : 00802000 Process rcS (pid: 32, stackpage=83ffe000) Stack: ffffffff 7fff6498 7fff6518 00000000 00000001 00000000 00000000 802c0000 00001062 00000000 00000018 7fff62c8 7fff62e8 00000000 0000fc00 2ad44404 00000000 00000000 00000000 7fff64a0 00000000 00000000 00000000 00000020 00000000 10013a88 00000000 ffffffff 00000000 10015188 00000000 2acb0870 00000010 00000000 2ae22db0 7fff62b0 00000008 2acaec84 00000020 00000000 2acb0884 ... Call Trace: Code: afa80034 00021023 afa20018 40086000 00000000 35080001 390 CoreHI interrupt, shouldn't happen, so we die here!!! .... From owner-linux-mips@oss.sgi.com Sat Jul 20 11:38:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6KIckRw007743 for ; Sat, 20 Jul 2002 11:38:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6KIckeT007742 for linux-mips-outgoing; Sat, 20 Jul 2002 11:38:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6KIcbRw007733 for ; Sat, 20 Jul 2002 11:38:37 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0AB5B13585; Sat, 20 Jul 2002 20:39:20 +0200 (CEST) Date: Sat, 20 Jul 2002 20:39:19 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: [uHOWTO] Booting a DECstation via MOP Message-ID: <20020720183919.GV8891@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O6iH21V1A1PEFpM6" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1828 Lines: 51 --O6iH21V1A1PEFpM6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've needed several attempts to get my /200 booting. This box mainly has the problem of not being capable of doing tftp, which is kind of a problem (especially if you've not got a bootable hard disk drive handy). So you need a mopd daemon and might attempt to try a 'apt-get install mopd'. Don't do it, it's not worth waiting now bandwidth. Basically, this mopd isn't capable of booting an ELF kernel (like ./linux/vmlinux), but will only accelt a.out images (or proprietary DEC images) which cannot be created in an easy manner (at least, *I* don't know how to do it...). Instead of apt-get'ing a mopd, go to ftp://ftp.ds2.pg.gda.pl/pub/macro/mopd/ and download all of the files in this directory (this will be mopd-2.5.3 at this moment plus several patches. Extract the .tar.gz and apply all patches (you *may* need to fix some .rej's depending on the order you apply these patches). At least on my Alpha, I had to add '-DNOAOUT' to the CFLAGS in =2E/mopd-2.5.3/Makefile to let it compile. For booting a Linux kernel, this is not a problem. Compile it, start it (I started it as './mopd -a'), place your ELF Linux kernel (this is what normally gets generated in ./linux/vmlinux) in /tftpboot/mop/ and be happy. MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --O6iH21V1A1PEFpM6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Oa5XHb1edYOZ4bsRAtqGAKCB3Evw65nTh34+AqNK+WLBOK5GSgCfREo/ TFDljAYeIii9HR9bqXzCcLE= =FNeV -----END PGP SIGNATURE----- --O6iH21V1A1PEFpM6-- From owner-linux-mips@oss.sgi.com Sun Jul 21 23:31:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6M6VARw012196 for ; Sun, 21 Jul 2002 23:31:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6M6VAiT012195 for linux-mips-outgoing; Sun, 21 Jul 2002 23:31:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6M6UuRw012183; Sun, 21 Jul 2002 23:30:56 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6M6V5Xb017151; Sun, 21 Jul 2002 23:31:05 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA28362; Sun, 21 Jul 2002 23:31:05 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6M6V6b22220; Mon, 22 Jul 2002 08:31:06 +0200 (MEST) Message-ID: <3D3BA6A2.DFE3988D@mips.com> Date: Mon, 22 Jul 2002 08:31:06 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Johannes Stezenbach CC: linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: LTP testing: msgctl/IPC_STAT References: <20020719143034.GA5956@convergence.de> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2564 Lines: 71 I also send this patch a week ago. Ralf could you please applied it. If there is any objection against changing this structure in the kernel, then we need a glibc fix instead. /Carsten Johannes Stezenbach wrote: > I was investigating LTP test suite failures of the msgctl01, > msgctl02, msgsnd01 and msgsnd02 tests. It seems that they > are caused by a mismatch between /usr/include/bits/msq.h > and linux/include/asm-mips/msgbuf.h. > > I suggest the following patch which makes mips' msgbuf.h > a copy of the one in include/asm-i386. > > Johannes > > Index: linux/include/asm-mips/msgbuf.h > =================================================================== > RCS file: /cvs/linux/include/asm-mips/msgbuf.h,v > retrieving revision 1.1 > diff -u -r1.1 msgbuf.h > --- linux/include/asm-mips/msgbuf.h 2000/02/16 01:07:48 1.1 > +++ linux/include/asm-mips/msgbuf.h 2002/07/19 14:20:29 > @@ -2,26 +2,30 @@ > #define _ASM_MSGBUF_H > > /* > - * The msqid64_ds structure for alpha architecture. > + * The msqid64_ds structure for mips architecture. > * Note extra padding because this structure is passed back and forth > * between kernel and user space. > * > * Pad space is left for: > - * - 2 miscellaneous 64-bit values > + * - 64-bit time_t to solve y2038 problem > + * - 2 miscellaneous 32-bit values > */ > > struct msqid64_ds { > struct ipc64_perm msg_perm; > __kernel_time_t msg_stime; /* last msgsnd time */ > + unsigned long __unused1; > __kernel_time_t msg_rtime; /* last msgrcv time */ > + unsigned long __unused2; > __kernel_time_t msg_ctime; /* last change time */ > + unsigned long __unused3; > unsigned long msg_cbytes; /* current number of bytes on queue */ > unsigned long msg_qnum; /* number of messages in queue */ > unsigned long msg_qbytes; /* max number of bytes on queue */ > __kernel_pid_t msg_lspid; /* pid of last msgsnd */ > __kernel_pid_t msg_lrpid; /* last receive pid */ > - unsigned long __unused1; > - unsigned long __unused2; > + unsigned long __unused4; > + unsigned long __unused5; > }; > > #endif /* _ASM_MSGBUF_H */ -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Sun Jul 21 23:41:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6M6fbRw012604 for ; Sun, 21 Jul 2002 23:41:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6M6fb7W012603 for linux-mips-outgoing; Sun, 21 Jul 2002 23:41:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6M6fTRw012588; Sun, 21 Jul 2002 23:41:29 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6M6fbXb017168; Sun, 21 Jul 2002 23:41:38 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA28646; Sun, 21 Jul 2002 23:41:39 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g6M6fdb22888; Mon, 22 Jul 2002 08:41:40 +0200 (MEST) Message-ID: <3D3BA918.97AAE461@mips.com> Date: Mon, 22 Jul 2002 08:41:39 +0200 From: Carsten Langgaard