From owner-linux-mips@oss.sgi.com Tue Jan 1 08:38:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01GcD523100 for linux-mips-outgoing; Tue, 1 Jan 2002 08:38:13 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01Gc9g23097 for ; Tue, 1 Jan 2002 08:38:10 -0800 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 g01Fc6O16032 for ; Tue, 1 Jan 2002 16:38:06 +0100 Received: (from karel@localhost) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) id QAA25774; Tue, 1 Jan 2002 16:38:06 +0100 (MET) From: Karel van Houten Message-Id: <200201011538.QAA25774@sparta.research.kpn.com> Subject: DECStation Linux website updated To: linux-mips@oss.sgi.com Date: Tue, 1 Jan 2002 16:38:05 +0100 (MET) Cc: vhouten@sparta.research.kpn.com 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All, A happy new year to to you all! During the last weeks, I've updated my website about Linux on DECStations: http://www.xs4all.nl/~vhouten/mipsel Installation HOWTO is updated to the 'current' RedHat 7.1 level, and recent CVS kernels. I hope to get comments or suggestions from you! 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 Jan 1 12:23:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01KNB126186 for linux-mips-outgoing; Tue, 1 Jan 2002 12:23:11 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01KN6g26183 for ; Tue, 1 Jan 2002 12:23:06 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id LAA14903; Tue, 1 Jan 2002 11:22:23 -0800 Date: Tue, 1 Jan 2002 11:22:23 -0800 From: Jun Sun To: Jim Paris Cc: Alan Cox , Geert Uytterhoeven , "Maciej W. Rozycki" , Linux/MIPS Development Subject: Re: ISA Message-ID: <20020101112223.A14847@mvista.com> References: <20011221134452.A21586@neurosis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011221134452.A21586@neurosis.mit.edu>; from jim@jtan.com on Fri, Dec 21, 2001 at 01:44:52PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Dec 21, 2001 at 01:44:52PM -0500, Jim Paris wrote: > > Interesting - I'd not considered that. Is ISA and non ISA space seperate on > > MIPS or is it all rather ambiguous ? > > On my particular machine, system RAM is at 0x00000000, and ISA I/O > memory is at 0x10000000. The driver I'm currently trying to work with > calls check_mem_region with ISA addresses, which of course breaks when > ISA memory isn't at zero. One suggestion was to patch the driver to > use something like > > check_mem_region(virt_to_phys(ioremap(ISA_address)), ...) > > which might be the best way for now? I agree with Geert and think isa_xxx_mem_region is a better approach. Unfortunately, this requires a change in both dirver and arch-specific part. > I think a more generic way to > abstract away a bus (and support multiple types and numbers of I/O > busses) is really necessary though. Some way to register a bus with > the kernel, and bind particular busses to particular instances of > drivers, or something. > I have talked with somebody before about the address apace idea, which is rather similar to what you are talking : 1. each address space has an id. 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical, 1 for virtual, etc. 3. When drivers discover the devices, they get the address and also the address space id where the address resides. 4. there are a set of macro's that converts/maps an address or an address region from one space to another. This generalized form allows multiple-PCI buses to use substractive decoding. Also removes the 1:1 mapping requirement between PCI memory space and CPU physical address space. However, the detailed implementation can be hairy, which is why it is still an idea. :-) Jun From owner-linux-mips@oss.sgi.com Tue Jan 1 12:34:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01KYYv26332 for linux-mips-outgoing; Tue, 1 Jan 2002 12:34:34 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01KYLg26328 for ; Tue, 1 Jan 2002 12:34:24 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id EFFD5590A9; Tue, 1 Jan 2002 14:30:11 -0500 (EST) Message-ID: <016d01c192fb$518a9dd0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Jun Sun" , "Jim Paris" Cc: "Alan Cox" , "Geert Uytterhoeven" , "Maciej W. Rozycki" , "Linux/MIPS Development" References: <20011221134452.A21586@neurosis.mit.edu> <20020101112223.A14847@mvista.com> Subject: Re: ISA Date: Tue, 1 Jan 2002 14:34:24 -0500 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Jun Sun" To: "Jim Paris" Cc: "Alan Cox" ; "Geert Uytterhoeven" ; "Maciej W. Rozycki" ; "Linux/MIPS Development" Sent: Tuesday, January 01, 2002 2:22 PM Subject: Re: ISA > 1. each address space has an id. > 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical, > 1 for virtual, etc. > 3. When drivers discover the devices, they get the address and also > the address space id where the address resides. > 4. there are a set of macro's that converts/maps an address or an > address region from one space to another. The first thing that jumps out at me is that now every bus access has an added switch in it. Either that or drivers would get back access function pointers, but that eliminates the chance to inline trivial bus accesses. Regards, Brad From owner-linux-mips@oss.sgi.com Tue Jan 1 12:37:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01Kbir26420 for linux-mips-outgoing; Tue, 1 Jan 2002 12:37:44 -0800 Received: from megaela.srvf.org (megaela.fe.dis.titech.ac.jp [131.112.171.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01Kbfg26417 for ; Tue, 1 Jan 2002 12:37:41 -0800 Received: (qmail 14262 invoked from network); 1 Jan 2002 19:37:38 -0000 Received: from unknown (HELO celesta.gotom.jp.fe.dis.titech.ac.jp) (127.0.0.1) by localhost with SMTP; 1 Jan 2002 19:37:38 -0000 Date: Wed, 02 Jan 2002 04:36:12 +0900 Message-ID: From: GOTO Masanori To: linux-mips@oss.sgi.com Subject: sysirix.c returns wrong error ? User-Agent: Wanderlust/2.9.2 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, The following patch is for kernel/sysirix.c kernel vanilla 2.4.17, I think this routine returns wrong error... Is it ok? --- arch/mips/kernel/sysirix.c.vanilla Wed Jan 2 04:29:13 2002 +++ arch/mips/kernel/sysirix.c Wed Jan 2 04:30:19 2002 @@ -1908,7 +1908,7 @@ } if (put_user(0, eob) < 0) { - error = EFAULT; + error = -EFAULT; goto out_putf; } -- gotom From owner-linux-mips@oss.sgi.com Tue Jan 1 13:03:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01L3j826780 for linux-mips-outgoing; Tue, 1 Jan 2002 13:03:45 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01L3gg26776 for ; Tue, 1 Jan 2002 13:03:42 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16LVHh-0001LU-00; Tue, 01 Jan 2002 20:13:17 +0000 Subject: Re: ISA To: jsun@mvista.com (Jun Sun) Date: Tue, 1 Jan 2002 20:13:16 +0000 (GMT) Cc: jim@jtan.com (Jim Paris), alan@lxorguk.ukuu.org.uk (Alan Cox), Geert.Uytterhoeven@sonycom.com (Geert Uytterhoeven), macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-mips@oss.sgi.com (Linux/MIPS Development) In-Reply-To: <20020101112223.A14847@mvista.com> from "Jun Sun" at Jan 01, 2002 11:22:23 AM 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > check_mem_region(virt_to_phys(ioremap(ISA_address)), ...) > > > > which might be the best way for now? > > I agree with Geert and think isa_xxx_mem_region is a better approach. > Unfortunately, this requires a change in both dirver and > arch-specific part. Its something that can be done progressively however as we fixup stuff. It'll just "happen" to work on x86 either way. Alan From owner-linux-mips@oss.sgi.com Tue Jan 1 15:38:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g01NcxC28564 for linux-mips-outgoing; Tue, 1 Jan 2002 15:38:59 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g01Ncug28561 for ; Tue, 1 Jan 2002 15:38:56 -0800 Received: from hypatia.brisbane.redhat.com (lulu.redhat.com.au [202.83.74.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 OAA07115 for ; Tue, 1 Jan 2002 14:38:19 -0800 (PST) mail_from (bje@scooby.brisbane.redhat.com) Received: from scooby.brisbane.redhat.com (scooby.brisbane.redhat.com [172.16.5.228]) by hypatia.brisbane.redhat.com (8.11.6/8.11.0) with ESMTP id g01MJdK02713; Wed, 2 Jan 2002 08:19:41 +1000 Received: by scooby.brisbane.redhat.com (Postfix, from userid 500) id 47C011083B; Wed, 2 Jan 2002 09:19:39 +1100 (EST) From: Ben Elliston MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15410.13819.197485.322115@scooby.brisbane.redhat.com> Date: Wed, 2 Jan 2002 09:19:39 +1100 (EST) To: "H . J . Lu" Cc: Ryan Murray , linux-mips@oss.sgi.com Subject: Re: config.guess changs In-Reply-To: <20011227095306.A16072@lucon.org> References: <20011227020844.U29645@cyberhqz.com> <20011227095306.A16072@lucon.org> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> "H" == H J Lu writes: >> The config.guess rework of 12/12/2001 doesn't work on big endian machines, >> as the preprocessor defines "mips" to be " 1", so the cpp -E output ends >> up being "CPU= 1". H> Try this patch. H> 2001-12-27 H.J. Lu H> * config.guess (mips:Linux:*:*): Undefine CPU, mips and mipsel H> first. Thanks; applied to the FSF master copy. Ben From owner-linux-mips@oss.sgi.com Tue Jan 1 18:04:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0224o530860 for linux-mips-outgoing; Tue, 1 Jan 2002 18:04:50 -0800 Received: from rover.village.org (warner@rover.bsdimp.com [204.144.255.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0224mg30857 for ; Tue, 1 Jan 2002 18:04:48 -0800 Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0214fl40709; Tue, 1 Jan 2002 18:04:42 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0214dF06257; Tue, 1 Jan 2002 18:04:40 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 01 Jan 2002 18:03:43 -0700 (MST) Message-Id: <20020101.180343.38230768.imp@village.org> To: brad@ltc.com Cc: jsun@mvista.com, jim@jtan.com, alan@lxorguk.ukuu.org.uk, Geert.Uytterhoeven@sonycom.com, macro@ds2.pg.gda.pl, linux-mips@oss.sgi.com Subject: Re: ISA From: "M. Warner Losh" In-Reply-To: <016d01c192fb$518a9dd0$5601010a@prefect> References: <20011221134452.A21586@neurosis.mit.edu> <20020101112223.A14847@mvista.com> <016d01c192fb$518a9dd0$5601010a@prefect> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You should look at BSD's bus_space. IT solves this problem without having to put architecturally specific kludged into each driver. Warner From owner-linux-mips@oss.sgi.com Tue Jan 1 20:47:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g024lMQ00742 for linux-mips-outgoing; Tue, 1 Jan 2002 20:47:22 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g024lIg00739 for ; Tue, 1 Jan 2002 20:47:19 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g01Nahh07815; Tue, 1 Jan 2002 21:36:43 -0200 Date: Tue, 1 Jan 2002 21:36:43 -0200 From: Ralf Baechle To: GOTO Masanori Cc: linux-mips@oss.sgi.com Subject: Re: sysirix.c returns wrong error ? Message-ID: <20020101213643.A7105@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gotom@debian.or.jp on Wed, Jan 02, 2002 at 04:36:12AM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jan 02, 2002 at 04:36:12AM +0900, GOTO Masanori wrote: > The following patch is for kernel/sysirix.c kernel vanilla 2.4.17, > I think this routine returns wrong error... Is it ok? Yes, it's ok. I've applied the patch. I should mention though that I have not received ANY user reports about the IRIX 5 compat code since I've put it into the kernel in June 97 so chances the code is actually working are not so bright ;-) Thanks anyway, Ralf From owner-linux-mips@oss.sgi.com Tue Jan 1 21:34:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g025YY801751 for linux-mips-outgoing; Tue, 1 Jan 2002 21:34:34 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g025YUg01748 for ; Tue, 1 Jan 2002 21:34:31 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g024YKw09899; Wed, 2 Jan 2002 02:34:20 -0200 Date: Wed, 2 Jan 2002 02:34:20 -0200 From: Ralf Baechle To: Carsten Langgaard Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: an old FPU context corruption problem when signal happens Message-ID: <20020102023420.A8786@dea.linux-mips.net> References: <3C21390A.FA23978D@mvista.com> <3C219A3B.6DA93A75@mips.com> <20011225044125.A16759@dea.linux-mips.net> <3C2AFD8C.6BAA7F1@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C2AFD8C.6BAA7F1@mips.com>; from carstenl@mips.com on Thu, Dec 27, 2001 at 11:53:00AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Dec 27, 2001 at 11:53:00AM +0100, Carsten Langgaard wrote: > You are welcome to find a better way of handling a non-fpu instruction in the > delay slot of the fpu-branch instruction. > But until someone find a better solution (that works, in all situation), I > think we need this patch. I could live with your solution if we'd be living in uniprocessor-land only. Well, that time is over now ... Ralf From owner-linux-mips@oss.sgi.com Wed Jan 2 02:44:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02AiHd06504 for linux-mips-outgoing; Wed, 2 Jan 2002 02:44:17 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02AiBg06499 for ; Wed, 2 Jan 2002 02:44:11 -0800 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 KAA19298; Wed, 2 Jan 2002 10:41:40 +0100 (MET) Date: Wed, 2 Jan 2002 10:41:39 +0100 (MET) From: Geert Uytterhoeven To: "Bradley D. LaRonde" cc: Jun Sun , Jim Paris , Alan Cox , "Maciej W. Rozycki" , Linux/MIPS Development Subject: Re: ISA In-Reply-To: <016d01c192fb$518a9dd0$5601010a@prefect> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 1 Jan 2002, Bradley D. LaRonde wrote: > ----- Original Message ----- > From: "Jun Sun" > To: "Jim Paris" > Cc: "Alan Cox" ; "Geert Uytterhoeven" > ; "Maciej W. Rozycki" ; > "Linux/MIPS Development" > Sent: Tuesday, January 01, 2002 2:22 PM > Subject: Re: ISA > > > > 1. each address space has an id. > > 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical, > > 1 for virtual, etc. > > 3. When drivers discover the devices, they get the address and also > > the address space id where the address resides. > > 4. there are a set of macro's that converts/maps an address or an > > address region from one space to another. > > The first thing that jumps out at me is that now every bus access has an > added switch in it. > > Either that or drivers would get back access function pointers, but that > eliminates the chance to inline trivial bus accesses. Not completely. ioremap() and friends can handle the address space ID and return an appropriate pointer. That pointer can still be handled by readl() and friends. 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 Jan 2 06:55:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02EtEE12322 for linux-mips-outgoing; Wed, 2 Jan 2002 06:55:14 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02EtCg12319 for ; Wed, 2 Jan 2002 06:55:12 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g02DuSB12103; Wed, 2 Jan 2002 05:56:28 -0800 Date: Wed, 2 Jan 2002 05:56:28 -0800 (PST) From: Venkata Rajesh Bikkina To: linux-mips@oss.sgi.com cc: rajeshbv@intotoinc.com Subject: GDB for 79S334A board Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 149 Lines: 11 Hi All, Anybody is using GDB on 79s334A? Please point me from where i can download the gdb binary working for the above board. Thanks, --Rajesh From owner-linux-mips@oss.sgi.com Wed Jan 2 07:36:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02Fahd13045 for linux-mips-outgoing; Wed, 2 Jan 2002 07:36:43 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02FaVg13041 for ; Wed, 2 Jan 2002 07:36:33 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id D838E590A9; Wed, 2 Jan 2002 09:32:23 -0500 (EST) Message-ID: <004d01c1939a$e6ab7ed0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Geert Uytterhoeven" Cc: "Jun Sun" , "Jim Paris" , "Alan Cox" , "Maciej W. Rozycki" , "Linux/MIPS Development" References: Subject: Re: ISA Date: Wed, 2 Jan 2002 09:36:44 -0500 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1704 Lines: 46 ----- Original Message ----- From: "Geert Uytterhoeven" To: "Bradley D. LaRonde" Cc: "Jun Sun" ; "Jim Paris" ; "Alan Cox" ; "Maciej W. Rozycki" ; "Linux/MIPS Development" Sent: Wednesday, January 02, 2002 4:41 AM Subject: Re: ISA > On Tue, 1 Jan 2002, Bradley D. LaRonde wrote: > > ----- Original Message ----- > > From: "Jun Sun" > > To: "Jim Paris" > > Cc: "Alan Cox" ; "Geert Uytterhoeven" > > ; "Maciej W. Rozycki" ; > > "Linux/MIPS Development" > > Sent: Tuesday, January 01, 2002 2:22 PM > > Subject: Re: ISA > > > > > > > 1. each address space has an id. > > > 2. kernel pre-defines a couple of well-known ones, 0 for CPU physical, > > > 1 for virtual, etc. > > > 3. When drivers discover the devices, they get the address and also > > > the address space id where the address resides. > > > 4. there are a set of macro's that converts/maps an address or an > > > address region from one space to another. > > > > The first thing that jumps out at me is that now every bus access has an > > added switch in it. > > > > Either that or drivers would get back access function pointers, but that > > eliminates the chance to inline trivial bus accesses. > > Not completely. ioremap() and friends can handle the address space ID and > return an appropriate pointer. That pointer can still be handled by readl() and > friends. Yup. I forgot about having to run all bus addresses through ioremap. Regards, Brad From owner-linux-mips@oss.sgi.com Wed Jan 2 10:38:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02IcDq17408 for linux-mips-outgoing; Wed, 2 Jan 2002 10:38:13 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02IcAg17403 for ; Wed, 2 Jan 2002 10:38:10 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 11:37:51 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: general linux question Date: Wed, 2 Jan 2002 11:36:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 903 Lines: 20 This isn't mips-specific, so maybe belongs on another list, but I figured someone here could probably answer just as quickly. I need to track versions of all files in the system (embedded, flash-based, no disk media), but cannot find a structure member where a version number can be stored in a file header. Most linux command line apps generally have a -version command line option, but is not viable for our application. Have I missed something? Is there a standard Linux method/practice for version number tracking and retrieval that is separate from CVS and the -version command switch, or do I have to use something proprietary? Or should I just try to use the file creation timestamp? Keith Siders Software Engineer Toshiba America Consumer Products, Inc. Advanced Television Technology Center 801 Royal Parkway, Suite 100 Nashville, Tennessee 37214 Phone: (615) 257-4050 Fax: (615) 453-7880 From owner-linux-mips@oss.sgi.com Wed Jan 2 10:51:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02Iprx17648 for linux-mips-outgoing; Wed, 2 Jan 2002 10:51:53 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02Ipkg17645 for ; Wed, 2 Jan 2002 10:51:48 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id AE081590A9; Wed, 2 Jan 2002 12:47:40 -0500 (EST) Message-ID: <033501c193b6$2f4163b0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Siders, Keith" , "Linux-Mips (E-mail)" References: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> Subject: Re: general linux question Date: Wed, 2 Jan 2002 12:52:02 -0500 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 336 Lines: 15 ----- Original Message ----- From: "Siders, Keith" To: "Linux-Mips (E-mail)" Sent: Wednesday, January 02, 2002 12:36 PM Subject: general linux question > I need to track versions > of all files in the system (embedded, flash-based, no disk media) Maybe use rcs? Regards, Brad From owner-linux-mips@oss.sgi.com Wed Jan 2 11:22:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02JMvP19031 for linux-mips-outgoing; Wed, 2 Jan 2002 11:22:57 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02JMqg19028 for ; Wed, 2 Jan 2002 11:22:53 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 12:22:36 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B74DB@ATVX> From: "Siders, Keith" To: "'Bradley D. LaRonde'" , "Linux-Mips (E-mail)" Subject: RE: general linux question Date: Wed, 2 Jan 2002 12:21:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1117 Lines: 36 Brad, Thanks for the quick reply... Well, rcs looks like a source control system, which _would_ allow me to create revision history files, but I was hoping that a file carried its version number in a file header, like the superblock structure, for quick access without having to create more files. This is a flash memory system, so storage constraints and access performance reign supreme. Not to mention that I'd have to include rcs as part of the distribution, taking up more memory in the flash file system. Keith -> -----Original Message----- -> From: Bradley D. LaRonde [mailto:brad@ltc.com] -> Sent: Wednesday, January 02, 2002 11:52 AM -> To: Siders, Keith; Linux-Mips (E-mail) -> Subject: Re: general linux question -> -> -> ----- Original Message ----- -> From: "Siders, Keith" -> To: "Linux-Mips (E-mail)" -> Sent: Wednesday, January 02, 2002 12:36 PM -> Subject: general linux question -> -> -> > I need to track versions -> > of all files in the system (embedded, flash-based, no disk media) -> -> Maybe use rcs? -> -> Regards, -> Brad -> From owner-linux-mips@oss.sgi.com Wed Jan 2 13:31:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02LVZU25312 for linux-mips-outgoing; Wed, 2 Jan 2002 13:31:35 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02LVVg25308 for ; Wed, 2 Jan 2002 13:31:31 -0800 Received: from [192.168.1.241] (192.168.1.241 [192.168.1.241]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZA0NHPNL; Wed, 2 Jan 2002 15:31:23 -0500 Subject: Re: general linux question From: Marc Karasek To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> References: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.13.08.57 (Preview Release) Date: 02 Jan 2002 15:30:26 -0500 Message-Id: <1010003431.1088.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1495 Lines: 36 You could embed a header into the file itself that is lart of the linker directive file. These variables would be available from w/i the program. They are kinda like global variables. The version could then be tracked thru this file. You can use things like compile date/time etc. Each time you recompile the variables would change. On Wed, 2002-01-02 at 12:36, Siders, Keith wrote: > This isn't mips-specific, so maybe belongs on another list, but I figured > someone here could probably answer just as quickly. I need to track versions > of all files in the system (embedded, flash-based, no disk media), but > cannot find a structure member where a version number can be stored in a > file header. Most linux command line apps generally have a -version command > line option, but is not viable for our application. Have I missed something? > Is there a standard Linux method/practice for version number tracking and > retrieval that is separate from CVS and the -version command switch, or do I > have to use something proprietary? Or should I just try to use the file > creation timestamp? > > Keith Siders > Software Engineer > Toshiba America Consumer Products, Inc. > Advanced Television Technology Center > 801 Royal Parkway, Suite 100 > Nashville, Tennessee 37214 > Phone: (615) 257-4050 > Fax: (615) 453-7880 -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Wed Jan 2 13:41:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02LfL725502 for linux-mips-outgoing; Wed, 2 Jan 2002 13:41:21 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02LfFg25499 for ; Wed, 2 Jan 2002 13:41:15 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7EDBA85D; Wed, 2 Jan 2002 21:41:01 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id CDFD648B5; Wed, 2 Jan 2002 21:41:10 +0100 (CET) Date: Wed, 2 Jan 2002 21:41:10 +0100 From: Florian Lohoff To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" Subject: Re: general linux question Message-ID: <20020102204110.GA5075@paradigm.rfc822.org> References: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA1B74D9@ATVX> User-Agent: Mutt/1.3.24i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2197 Lines: 58 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2002 at 11:36:27AM -0600, Siders, Keith wrote: > This isn't mips-specific, so maybe belongs on another list, but I figured > someone here could probably answer just as quickly. I need to track versi= ons > of all files in the system (embedded, flash-based, no disk media), but > cannot find a structure member where a version number can be stored in a > file header. Most linux command line apps generally have a -version comma= nd > line option, but is not viable for our application. Have I missed somethi= ng? > Is there a standard Linux method/practice for version number tracking and > retrieval that is separate from CVS and the -version command switch, or d= o I > have to use something proprietary? Or should I just try to use the file > creation timestamp? Usually this is the reason for a distribution which stores some kind of metadata in some flavour of package database: (flo@paradigm)~# dpkg -l gcc binutils Desired=3DUnknown/Install/Remove/Purge/Hold | Status=3DNot/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=3D(none)/Hold/Reinst-required/X=3Dboth-problems (Status,Err: upperc= ase=3Dbad) ||/ Name Version Description +++-=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=3D=3D=3D=3D=3D ii gcc 2.95.4-9 The GNU C compiler. ii binutils 2.11.92.0.12.3 The GNU assembler, linker and binary util= iti Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --gKMricLos+KVdGMg 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 iD8DBQE8M3BmUaz2rXW+gJcRAg7bAKCUytylU681DBPo5jAG8zUb5WavTwCdGa06 Vv+9oAAbL20Gu20Q82TqmcQ= =YmhJ -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-linux-mips@oss.sgi.com Thu Jan 3 11:52:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03JqRf25490 for linux-mips-outgoing; Thu, 3 Jan 2002 11:52:27 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03JqHg25466 for ; Thu, 3 Jan 2002 11:52:18 -0800 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 g03IqEa08237; Thu, 3 Jan 2002 19:52:14 +0100 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 TAA01081; Thu, 3 Jan 2002 19:52:13 +0100 (MET) Message-Id: <200201031852.TAA01081@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: guido.guenther@gmx.net cc: karel@sparta.research.kpn.com, linux-mips@oss.sgi.com Reply-to: vhouten@kpn.com Subject: Newport Xserver 2001-11-21 X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 19:52:13 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3043 Lines: 74 Hi Guido, I'm experimenting with your Xserver for my indy, currently running the 2.4.16 kernel. I've used a local compiled Xserver before, but that was with an older kernel. Now, using 2.4.16 and your Xserver, I get the following errors: XFree86 Version 4.1.99.2 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 12 December 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.16 mips [ELF] Module Loader present (==) Log file: "/var/log/XFree86.0.log", Time: Thu Jan 3 19:50:14 2002 (==) Using config file: "/etc/X11/XF86Config" Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout "simple layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "SGI GDM17e11" (**) | |-->Device "Newport Graphics" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (**) FontPath set to "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/mi sc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:uns caled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/li b/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100d pi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 (II) Loading /usr/X11R6/lib/modules/libbitmap.so (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 1.0.0 (II) Loading /usr/X11R6/lib/modules/libpcidata.so (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 0.1.0 (EE) No OS PCI support available (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.so (II) Module dbe: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 1.0.0 (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.so (II) Module extmod: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 1.0.0 (II) Loading /usr/X11R6/lib/modules/drivers/newport_drv.so (II) Module newport: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 0.1.3 (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.so (II) Module mouse: vendor="The XFree86 Project" compiled for 4.1.99.2, module version = 1.0.0 (II) NEWPORT: driver for Newport Graphics Card: XL (EE) No devices detected. Fatal server error: no screens found Is this a problem with the current kernel? Or have I missed a config option? 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 Jan 3 13:36:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03LaDs28134 for linux-mips-outgoing; Thu, 3 Jan 2002 13:36:13 -0800 Received: from gw-nl5.philips.com (gw-nl5.philips.com [212.153.235.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03La9g28131 for ; Thu, 3 Jan 2002 13:36:09 -0800 Received: from smtpscan-nl4.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id VAA21287 for ; Thu, 3 Jan 2002 21:36:05 +0100 (MET) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-nl4.philips.com(130.139.36.24) by gw-nl5.philips.com via mwrap (4.0a) id xma021285; Thu, 3 Jan 02 21:36:05 +0100 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id VAA26138 for ; Thu, 3 Jan 2002 21:36:04 +0100 (MET) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA21440 for ; Thu, 3 Jan 2002 14:36:03 -0600 (CST) Subject: can't access tty To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 3 Jan 2002 12:36:54 -0800 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 03/01/2002 14:39:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 556 Lines: 28 Hello, I had been trying to get the linux kernel 2.4.3 on our latest mips core which is mips32 ISA complient. Finally I was able to boot the kernel. Also /bin/sh executes but gives the following message and a prompt. Everything freezes thereafter. sh: can't access tty; Job control turned off # I dont know if its a problem with the serial driver or the keyboard driver. I'm using the ttyS0 as the console and I think its working fine. I dont know how to check that the keyboard is working fine. Any tips ?? Thanks in advance. regards, Balaji From owner-linux-mips@oss.sgi.com Thu Jan 3 14:20:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MKHQ29237 for linux-mips-outgoing; Thu, 3 Jan 2002 14:20:17 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MK0g29233; Thu, 3 Jan 2002 14:20:00 -0800 Received: from resel.enst-bretagne.fr (user60364@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03LJob10742; Thu, 3 Jan 2002 22:19:50 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA18754; Thu, 3 Jan 2002 22:19:51 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFHD-0002J6-00; Thu, 03 Jan 2002 22:19:51 +0100 Date: Thu, 3 Jan 2002 22:19:51 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: cache coherency on I/O Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1541166394-1010092791=:6202" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7937 Lines: 141 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-1541166394-1010092791=:6202 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here is a patch to fix cache coherency when doing I/O on the O2. It simply adds writeback and invalidate when unmapping DMA memory. This fixes coherency when reading from a device. It also adds support for mapping/unmapping pages for both the IP27 and the O2. Vivien Chappelier. --279724308-1541166394-1010092791=:6202 Content-Type: TEXT/plain; name="linux-O2-coherent_io.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-coherent_io.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9zZ2ktaXAyNy9pcDI3LXBj aS1kbWEuYyBsaW51eC5wYXRjaC9hcmNoL21pcHM2NC9zZ2ktaXAyNy9pcDI3 LXBjaS1kbWEuYw0KLS0tIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDI3L2lw MjctcGNpLWRtYS5jCVN1biBEZWMgIDkgMTU6NDc6MTUgMjAwMQ0KKysrIGxp bnV4LnBhdGNoL2FyY2gvbWlwczY0L3NnaS1pcDI3L2lwMjctcGNpLWRtYS5j CUZyaSBEZWMgMjEgMTE6MDg6MjIgMjAwMQ0KQEAgLTExMiw3ICsxMTIsMTEg QEANCiANCiAJLyogTWFrZSBzdXJlIHRoYXQgZ2NjIGRvZXNuJ3QgbGVhdmUg dGhlIGVtcHR5IGxvb3AgYm9keS4gICovDQogCWZvciAoaSA9IDA7IGkgPCBu ZW50czsgaSsrLCBzZysrKSB7DQotCQlzZy0+YWRkcmVzcyA9IChjaGFyICop KGJ1c190b19iYWRkcltod2Rldi0+YnVzLT5udW1iZXJdIHwgX19wYShzZy0+ YWRkcmVzcykpOw0KKwkgICAgICAgIGlmKHNnLT5hZGRyZXNzKQ0KKwkJICBh ZGRyZXNzID0gc2ctPmFkZHJlc3M7DQorCQllbHNlDQorCQkgIGFkZHJlc3Mg PSBwYWdlX2FkZHJlc3Moc2ctPnBhZ2UpICsgc2ctPm9mZnNldDsNCisJCXNn LT5kdm1hX2FkZHJlc3MgPSAoY2hhciAqKShidXNfdG9fYmFkZHJbaHdkZXYt PmJ1cy0+bnVtYmVyXSB8IF9fcGEoYWRkcmVzcykpOw0KIAl9DQogDQogCXJl dHVybiBuZW50czsNCmRpZmYgLU5hdXIgbGludXgvYXJjaC9taXBzNjQvc2dp LWlwMzIvaXAzMi1wY2ktZG1hLmMgbGludXgucGF0Y2gvYXJjaC9taXBzNjQv c2dpLWlwMzIvaXAzMi1wY2ktZG1hLmMNCi0tLSBsaW51eC9hcmNoL21pcHM2 NC9zZ2ktaXAzMi9pcDMyLXBjaS1kbWEuYwlTdW4gRGVjICA5IDE1OjQ3OjE1 IDIwMDENCisrKyBsaW51eC5wYXRjaC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9p cDMyLXBjaS1kbWEuYwlGcmkgRGVjIDIxIDExOjA3OjMzIDIwMDENCkBAIC05 OSw3ICs5OSwxMCBAQA0KIAlpZiAoZGlyZWN0aW9uID09IFBDSV9ETUFfTk9O RSkNCiAJCUJVRygpOw0KIAlEUFJJTlRLKCJwY2lfdW5tYXBfc2luZ2xlXG4i KTsNCi0JLyogTm90aGluZyB0byBkbyAqLw0KKwlpZiAoZGlyZWN0aW9uICE9 IFBDSV9ETUFfVE9ERVZJQ0UpIHsNCisJICAgICAgICBtaXBzX3diZmx1c2go KTsNCisJICAgICAgICBkbWFfY2FjaGVfd2JhY2tfaW52KCh1bnNpZ25lZCBs b25nKV9fdmEoZG1hX2FkZHIpLCBzaXplKTsNCisJfQ0KIH0NCiANCiAvKg0K QEAgLTEyMiw2ICsxMjUsNyBAQA0KIAkJCSAgICAgaW50IG5lbnRzLCBpbnQg ZGlyZWN0aW9uKQ0KIHsNCiAJaW50IGk7DQorCXVuc2lnbmVkIGxvbmcgYWRk cmVzczsNCiANCiAJaWYgKGRpcmVjdGlvbiA9PSBQQ0lfRE1BX05PTkUpDQog CQlCVUcoKTsNCkBAIC0xMzEsOSArMTM1LDEzIEBADQogCURQUklOVEsoInBj aV9tYXBfc2dcbiIpOw0KIAkvKiBNYWtlIHN1cmUgdGhhdCBnY2MgZG9lc24n dCBsZWF2ZSB0aGUgZW1wdHkgbG9vcCBib2R5LiAgKi8NCiAJZm9yIChpID0g MDsgaSA8IG5lbnRzOyBpKyssIHNnKyspIHsNCisJICAgICAgICBpZihzZy0+ YWRkcmVzcykNCisJCSAgYWRkcmVzcyA9IHNnLT5hZGRyZXNzOw0KKwkJZWxz ZQ0KKwkJICBhZGRyZXNzID0gcGFnZV9hZGRyZXNzKHNnLT5wYWdlKSArIHNn LT5vZmZzZXQ7DQogCQltaXBzX3diZmx1c2goKTsNCi0JCWRtYV9jYWNoZV93 YmFja19pbnYoKHVuc2lnbmVkIGxvbmcpc2ctPmFkZHJlc3MsIHNnLT5sZW5n dGgpOw0KLQkJc2ctPmFkZHJlc3MgPSAoY2hhciAqKShfX3BhKHNnLT5hZGRy ZXNzKSk7DQorCQlkbWFfY2FjaGVfd2JhY2tfaW52KGFkZHJlc3MsIHNnLT5s ZW5ndGgpOw0KKwkJc2ctPmR2bWFfYWRkcmVzcyA9IF9fcGEoYWRkcmVzcyk7 DQogCX0NCiANCiAJcmV0dXJuIG5lbnRzOw0KQEAgLTE0NywxMCArMTU1LDIy IEBADQogdm9pZCBwY2lfdW5tYXBfc2coc3RydWN0IHBjaV9kZXYgKmh3ZGV2 LCBzdHJ1Y3Qgc2NhdHRlcmxpc3QgKnNnLA0KIAkJCQlpbnQgbmVudHMsIGlu dCBkaXJlY3Rpb24pDQogew0KKwlpbnQgaTsNCisJdW5zaWduZWQgbG9uZyBh ZGRyZXNzOw0KKw0KIAlpZiAoZGlyZWN0aW9uID09IFBDSV9ETUFfTk9ORSkN CiAJCUJVRygpOw0KIAlEUFJJTlRLKCJwY2lfdW5tYXBfc2dcbiIpOw0KLQkv KiBOb3RoaW5nIHRvIGRvICovDQorCWZvciAoaSA9IDA7IGkgPCBuZW50czsg aSsrLCBzZysrKSB7DQorCSAgaWYgKGRpcmVjdGlvbiAhPSBQQ0lfRE1BX1RP REVWSUNFKSB7DQorCSAgICAgICAgaWYoc2ctPmFkZHJlc3MpDQorCQkgIGFk ZHJlc3MgPSBzZy0+YWRkcmVzczsNCisJCWVsc2UNCisJCSAgYWRkcmVzcyA9 IHBhZ2VfYWRkcmVzcyhzZy0+cGFnZSkgKyBzZy0+b2Zmc2V0Ow0KKwkgICAg ICAgIG1pcHNfd2JmbHVzaCgpOw0KKwkgICAgICAgIGRtYV9jYWNoZV93YmFj a19pbnYoYWRkcmVzcywgc2ctPmxlbmd0aCk7DQorCSAgfQ0KKwl9DQogfQ0K IA0KIC8qDQpAQCAtMTg4LDEzICsyMDgsMTkgQEANCiAJCQkJICAgaW50IG5l bGVtcywgaW50IGRpcmVjdGlvbikNCiB7DQogCWludCBpOw0KKwl1bnNpZ25l ZCBsb25nIGFkZHJlc3M7DQorDQogCWlmIChkaXJlY3Rpb24gPT0gUENJX0RN QV9OT05FKQ0KIAkJQlVHKCk7DQogCURQUklOVEsoInBjaV9kbWFfc3luY19z Z1xuIik7DQogCS8qICBNYWtlIHN1cmUgdGhhdCBnY2MgZG9lc24ndCBsZWF2 ZSB0aGUgZW1wdHkgbG9vcCBib2R5LiAgKi8NCiAJZm9yIChpID0gMDsgaSA8 IG5lbGVtczsgaSsrLCBzZysrKXsNCisJICAgICAgICBpZihzZy0+YWRkcmVz cykNCisJCSAgYWRkcmVzcyA9IHNnLT5hZGRyZXNzOw0KKwkJZWxzZQ0KKwkJ ICBhZGRyZXNzID0gcGFnZV9hZGRyZXNzKHNnLT5wYWdlKSArIHNnLT5vZmZz ZXQ7DQogCQltaXBzX3diZmx1c2goKTsNCi0JCWRtYV9jYWNoZV93YmFja19p bnYoKHVuc2lnbmVkIGxvbmcpX192YShzZy0+YWRkcmVzcyksIHNnLT5sZW5n dGgpOw0KKwkJZG1hX2NhY2hlX3diYWNrX2ludihhZGRyZXNzLCBzZy0+bGVu Z3RoKTsNCiAJfQ0KIC8qCWlmKGRpcmVjdGlvbj09UENJX0RNQV9UT0RFVklD RSkNCiAJCW1hY2VfaW52X3JlYWRfYnVmZmVycygpOyovDQpkaWZmIC1OYXVy IGxpbnV4L2luY2x1ZGUvYXNtLW1pcHM2NC9taXBzcmVncy5oIGxpbnV4LnBh dGNoL2luY2x1ZGUvYXNtLW1pcHM2NC9taXBzcmVncy5oDQotLS0gbGludXgv aW5jbHVkZS9hc20tbWlwczY0L21pcHNyZWdzLmgJU3VuIERlYyAgOSAxNTo1 MjoyNyAyMDAxDQorKysgbGludXgucGF0Y2gvaW5jbHVkZS9hc20tbWlwczY0 L21pcHNyZWdzLmgJRnJpIERlYyAyMSAxMToyODowNiAyMDAxDQpAQCAtMzY3 LDYgKzM2Nyw3IEBADQogI2RlZmluZSBDT05GX0NNX0NNQVNLCQkJNw0KICNk ZWZpbmUgQ09ORl9EQgkJCQkoMSA8PCAgNCkNCiAjZGVmaW5lIENPTkZfSUIJ CQkJKDEgPDwgIDUpDQorI2RlZmluZSBDT05GX1NFCQkJCSgxIDw8IDEyKQ0K ICNkZWZpbmUgQ09ORl9TQwkJCQkoMSA8PCAxNykNCiAjZGVmaW5lIENPTkZf QUMgICAgICAgICAgICAgICAgICAgICAgICAgKDEgPDwgMjMpDQogI2RlZmlu ZSBDT05GX0hBTFQgICAgICAgICAgICAgICAgICAgICAgICgxIDw8IDI1KQ0K ZGlmZiAtTmF1ciBsaW51eC9pbmNsdWRlL2FzbS1taXBzNjQvcGNpLmggbGlu dXgucGF0Y2gvaW5jbHVkZS9hc20tbWlwczY0L3BjaS5oDQotLS0gbGludXgv aW5jbHVkZS9hc20tbWlwczY0L3BjaS5oCVRodSBEZWMgMjAgMTg6MzI6MTgg MjAwMQ0KKysrIGxpbnV4LnBhdGNoL2luY2x1ZGUvYXNtLW1pcHM2NC9wY2ku aAlGcmkgRGVjIDIxIDExOjEwOjA4IDIwMDENCkBAIC0zMTksNyArMzE5LDcg QEANCiAgKiByZXR1cm5zLCBvciBhbHRlcm5hdGl2ZWx5IHN0b3Agb24gdGhl IGZpcnN0IHNnX2RtYV9sZW4oc2cpIHdoaWNoDQogICogaXMgMC4NCiAgKi8N Ci0jZGVmaW5lIHNnX2RtYV9hZGRyZXNzKHNnKQkoKHVuc2lnbmVkIGxvbmcp KChzZyktPmFkZHJlc3MpKQ0KKyNkZWZpbmUgc2dfZG1hX2FkZHJlc3Moc2cp CSgoc2cpLT5kdm1hX2FkZHJlc3MpDQogI2RlZmluZSBzZ19kbWFfbGVuKHNn KQkJKChzZyktPmxlbmd0aCkNCiANCiAjZW5kaWYgLyogX19LRVJORUxfXyAq Lw0KZGlmZiAtTmF1ciBsaW51eC9pbmNsdWRlL2FzbS1taXBzNjQvcGd0YWJs ZS5oIGxpbnV4LnBhdGNoL2luY2x1ZGUvYXNtLW1pcHM2NC9wZ3RhYmxlLmgN Ci0tLSBsaW51eC9pbmNsdWRlL2FzbS1taXBzNjQvcGd0YWJsZS5oCVRodSBE ZWMgMjAgMTg6MzI6MTggMjAwMQ0KKysrIGxpbnV4LnBhdGNoL2luY2x1ZGUv YXNtLW1pcHM2NC9wZ3RhYmxlLmgJVGh1IERlYyAyMCAyMDowMzowNyAyMDAx DQpAQCAtMTgwLDExICsxODAsMTEgQEANCiAjaWZkZWYgQ09ORklHX01JUFNf VU5DQUNIRUQNCiAjZGVmaW5lIFBBR0VfQ0FDSEFCTEVfREVGQVVMVCBfQ0FD SEVfVU5DQUNIRUQNCiAjZWxzZSAvKiAhIFVOQ0FDSEVEICovDQotI2lmZGVm IENPTkZJR19TR0lfSVAyMg0KKyNpZiBkZWZpbmVkKENPTkZJR19TR0lfSVAy MikgfHwgZGVmaW5lZChDT05GSUdfU0dJX0lQMzIpDQogI2RlZmluZSBQQUdF X0NBQ0hBQkxFX0RFRkFVTFQgX0NBQ0hFX0NBQ0hBQkxFX05PTkNPSEVSRU5U DQotI2Vsc2UgLyogISBJUDIyICovDQorI2Vsc2UgLyogISAoSVAyMiB8fCBJ UDMyKSovDQogI2RlZmluZSBQQUdFX0NBQ0hBQkxFX0RFRkFVTFQgX0NBQ0hF X0NBQ0hBQkxFX0NPVw0KLSNlbmRpZiAvKiBJUDIyICovDQorI2VuZGlmIC8q IChJUDIyIHx8IElQMzIpICovDQogI2VuZGlmIC8qIFVOQ0FDSEVEICovDQog DQogI2RlZmluZSBQQUdFX05PTkUJX19wZ3Byb3QoX1BBR0VfUFJFU0VOVCB8 IFBBR0VfQ0FDSEFCTEVfREVGQVVMVCkNCmRpZmYgLU5hdXIgbGludXgvaW5j bHVkZS9hc20tbWlwczY0L3NjYXR0ZXJsaXN0LmggbGludXgucGF0Y2gvaW5j bHVkZS9hc20tbWlwczY0L3NjYXR0ZXJsaXN0LmgNCi0tLSBsaW51eC9pbmNs dWRlL2FzbS1taXBzNjQvc2NhdHRlcmxpc3QuaAlUaHUgRGVjIDIwIDE4OjMy OjE4IDIwMDENCisrKyBsaW51eC5wYXRjaC9pbmNsdWRlL2FzbS1taXBzNjQv c2NhdHRlcmxpc3QuaAlGcmkgRGVjIDIxIDExOjA5OjQwIDIwMDENCkBAIC03 LDcgKzcsNyBAQA0KIAl1bnNpZ25lZCBpbnQgb2Zmc2V0Ow0KIAl1bnNpZ25l ZCBpbnQgbGVuZ3RoOw0KIA0KLQlfX3UzMiBkdm1hX2FkZHJlc3M7DQorCWRt YV9hZGRyX3QgZHZtYV9hZGRyZXNzOw0KIH07DQogDQogc3RydWN0IG1tdV9z Z2xpc3Qgew0K --279724308-1541166394-1010092791=:6202-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:27:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MRaq29396 for linux-mips-outgoing; Thu, 3 Jan 2002 14:27:36 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MRTg29393; Thu, 3 Jan 2002 14:27:29 -0800 Received: from resel.enst-bretagne.fr (user33661@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03LRKb10912; Thu, 3 Jan 2002 22:27:20 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA19318; Thu, 3 Jan 2002 22:27:21 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFOT-0002Jl-00; Thu, 03 Jan 2002 22:27:21 +0100 Date: Thu, 3 Jan 2002 22:27:21 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: fixes for R5000 SC Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-290444707-1010093241=:8906" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1996 Lines: 43 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-290444707-1010093241=:8906 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, It seems secondary cache handling for R5000 (at least on the O2) is quite different from the R4xxx. Unfortunately, it's detected by this code and the cache operates in a wrong way. This patch disables detection of a secondary cache for the R5000. Vivien Chappelier. --279724308-290444707-1010093241=:8906 Content-Type: TEXT/plain; name="linux-O2-l1cache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-l1cache.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9tbS9yNHh4MC5jIGxpbnV4 LnBhdGNoL2FyY2gvbWlwczY0L21tL3I0eHgwLmMNCi0tLSBsaW51eC9hcmNo L21pcHM2NC9tbS9yNHh4MC5jCVdlZCBKYW4gIDIgMjI6NTY6NDEgMjAwMg0K KysrIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L21tL3I0eHgwLmMJV2VkIEph biAgMiAyMzoxMDoyNCAyMDAyDQpAQCAtMjM0Niw4ICsyMzQ2LDIxIEBADQog CWludCBzY19wcmVzZW50ID0gMDsNCiANCiAJLyogTWF5YmUgdGhlIGNwdSBr bm93cyBhYm91dCBhIGwyIGNhY2hlPyAqLw0KLQlwcm9iZV9zY2FjaGVfa3Nl ZzEgPSAocHJvYmVfZnVuY190KSAoS1NFRzFBRERSKCZwcm9iZV9zY2FjaGUp KTsNCi0Jc2NfcHJlc2VudCA9IHByb2JlX3NjYWNoZV9rc2VnMShjb25maWcp Ow0KKwlzd2l0Y2gobWlwc19jcHUuY3B1dHlwZSkgew0KKwljYXNlIENQVV9S NDAwMFNDOg0KKwljYXNlIENQVV9SNDAwME1DOg0KKwljYXNlIENQVV9SNDIw MDoNCisJY2FzZSBDUFVfUjQzMDA6DQorCWNhc2UgQ1BVX1I0NDAwU0M6DQor CWNhc2UgQ1BVX1I0NDAwTUM6DQorCWNhc2UgQ1BVX1I0NjAwOg0KKwljYXNl IENQVV9SNDY0MDoNCisJY2FzZSBDUFVfUjQ2NTA6DQorCWNhc2UgQ1BVX1I0 NzAwOg0KKwkgIHByb2JlX3NjYWNoZV9rc2VnMSA9IChwcm9iZV9mdW5jX3Qp IChLU0VHMUFERFIoJnByb2JlX3NjYWNoZSkpOw0KKwkgIHNjX3ByZXNlbnQg PSBwcm9iZV9zY2FjaGVfa3NlZzEoY29uZmlnKTsNCisJICBicmVhazsNCisJ fQ0KIA0KIAlpZiAoc2NfcHJlc2VudCkgew0KIAkJc2V0dXBfc2NhY2hlX2Z1 bmNzKCk7DQo= --279724308-290444707-1010093241=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:35:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MZ7k29618 for linux-mips-outgoing; Thu, 3 Jan 2002 14:35:07 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MZ0g29608; Thu, 3 Jan 2002 14:35:00 -0800 Received: from resel.enst-bretagne.fr (user75578@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03LYpb11383; Thu, 3 Jan 2002 22:34:51 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA19909; Thu, 3 Jan 2002 22:34:52 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFVk-0002KM-00; Thu, 03 Jan 2002 22:34:52 +0100 Date: Thu, 3 Jan 2002 22:34:52 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: aic7xxx (O2 scsi) DMA coherency Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-593455239-1010093692=:8906" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1512 Lines: 35 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-593455239-1010093692=:8906 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, This tells the aic7xxx to use DMA safe memory for I/O. Vivien Chappelier. --279724308-593455239-1010093692=:8906 Content-Type: TEXT/plain; name="linux-aic7xxx.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-aic7xxx.diff" ZGlmZiAtTmF1ciBsaW51eC9kcml2ZXJzL3Njc2kvYWljN3h4eC9haWM3eHh4 X2xpbnV4X2hvc3QuaCBsaW51eC5wYXRjaC9kcml2ZXJzL3Njc2kvYWljN3h4 eC9haWM3eHh4X2xpbnV4X2hvc3QuaA0KLS0tIGxpbnV4L2RyaXZlcnMvc2Nz aS9haWM3eHh4L2FpYzd4eHhfbGludXhfaG9zdC5oCVRodSBEZWMgMjAgMTg6 MzE6MTEgMjAwMQ0KKysrIGxpbnV4LnBhdGNoL2RyaXZlcnMvc2NzaS9haWM3 eHh4L2FpYzd4eHhfbGludXhfaG9zdC5oCVRodSBEZWMgMjAgMjE6NDM6MzEg MjAwMQ0KQEAgLTg3LDcgKzg3LDcgQEANCiAJc2dfdGFibGVzaXplOiAwLAkv KiBtYXggc2NhdHRlci1nYXRoZXIgY21kcyAgICAqL1wNCiAJY21kX3Blcl9s dW46IDIsCQkvKiBjbWRzIHBlciBsdW4JCSAgICAgICovXA0KIAlwcmVzZW50 OiAwLAkJLyogbnVtYmVyIG9mIDd4eHgncyBwcmVzZW50ICAgKi9cDQotCXVu Y2hlY2tlZF9pc2FfZG1hOiAwLAkvKiBubyBtZW1vcnkgRE1BIHJlc3RyaWN0 aW9ucyAqL1wNCisJdW5jaGVja2VkX2lzYV9kbWE6IDEsCQkJCQlcDQogCXVz ZV9jbHVzdGVyaW5nOiBFTkFCTEVfQ0xVU1RFUklORywJCQlcDQogCWhpZ2ht ZW1faW86IDEJCQkJCQlcDQogfQ0K --279724308-593455239-1010093692=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:38:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Mc0729790 for linux-mips-outgoing; Thu, 3 Jan 2002 14:38:00 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Mbqg29786; Thu, 3 Jan 2002 14:37:52 -0800 Received: from resel.enst-bretagne.fr (user66540@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03Lbgb11520; Thu, 3 Jan 2002 22:37:42 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA20227; Thu, 3 Jan 2002 22:37:43 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFYU-0002Kg-00; Thu, 03 Jan 2002 22:37:42 +0100 Date: Thu, 3 Jan 2002 22:37:42 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: missing callbacks on setup (timer) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-280324098-1010093862=:8906" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2407 Lines: 50 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-280324098-1010093862=:8906 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, This fixes missing callbacks for setting up the timer with linux 2.5.1 on the ip27 and ip32. Vivien Chappelier. --279724308-280324098-1010093862=:8906 Content-Type: TEXT/plain; name="linux-mips-timer.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips-timer.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9rZXJuZWwvdGltZS5jIGxp bnV4LnBhdGNoL2FyY2gvbWlwczY0L2tlcm5lbC90aW1lLmMNCi0tLSBsaW51 eC9hcmNoL21pcHM2NC9rZXJuZWwvdGltZS5jCVdlZCBEZWMgMTkgMDE6MDM6 MDMgMjAwMQ0KKysrIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L2tlcm5lbC90 aW1lLmMJVGh1IERlYyAyMCAyMTozNzowMiAyMDAxDQpAQCAtNDU3LDcgKzQ1 Nyw4IEBADQogCSAqIHRvIGJlIE5VTEwgZnVuY3Rpb24gc28gdGhhdCB3ZSBh cmUgc3VyZSB0aGUgaGlnaC1sZXZlbCBjb2RlDQogCSAqIGlzIG5vdCBpbnZv a2VkIGFjY2lkZW50YWxseS4NCiAJICovDQotCWJvYXJkX3RpbWVyX3NldHVw KCZ0aW1lcl9pcnFhY3Rpb24pOw0KKwlpZihib2FyZF90aW1lcl9zZXR1cCkN CisJICBib2FyZF90aW1lcl9zZXR1cCgmdGltZXJfaXJxYWN0aW9uKTsNCiB9 DQogDQogI2RlZmluZSBGRUJSVUFSWQkJMg0KZGlmZiAtTmF1ciBsaW51eC9h cmNoL21pcHM2NC9zZ2ktaXAyNy9pcDI3LXNldHVwLmMgbGludXgucGF0Y2gv YXJjaC9taXBzNjQvc2dpLWlwMjcvaXAyNy1zZXR1cC5jDQotLS0gbGludXgv YXJjaC9taXBzNjQvc2dpLWlwMjcvaXAyNy1zZXR1cC5jCVRodSBEZWMgMjAg MTg6MzA6MjAgMjAwMQ0KKysrIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L3Nn aS1pcDI3L2lwMjctc2V0dXAuYwlUaHUgRGVjIDIwIDIxOjM3OjQ5IDIwMDEN CkBAIC0zMTEsNCArMzExLDUgQEANCiANCiAJbWlwc19pb19wb3J0X2Jhc2Ug PSBJT19CQVNFOw0KIAlib2FyZF90aW1lX2luaXQgPSBpcDI3X3RpbWVfaW5p dDsNCisJYm9hcmRfdGltZXJfc2V0dXAgPSBOVUxMOw0KIH0NCmRpZmYgLU5h dXIgbGludXgvYXJjaC9taXBzNjQvc2dpLWlwMzIvaXAzMi1zZXR1cC5jIGxp bnV4LnBhdGNoL2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzItc2V0dXAuYw0K LS0tIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzItc2V0dXAuYwlU aHUgRGVjIDIwIDE4OjMwOjIwIDIwMDENCisrKyBsaW51eC5wYXRjaC9hcmNo L21pcHM2NC9zZ2ktaXAzMi9pcDMyLXNldHVwLmMJVGh1IERlYyAyMCAyMToz Nzo1OSAyMDAxDQpAQCAtOTEsNiArOTEsNyBAQA0KIA0KIAlydGNfb3BzID0g JmlwMzJfcnRjX29wczsNCiAJYm9hcmRfdGltZV9pbml0ID0gaXAzMl90aW1l X2luaXQ7DQorCWJvYXJkX3RpbWVyX3NldHVwID0gTlVMTDsNCiANCiAJY3Jp bWVfaW5pdCAoKTsNCiB9DQo= --279724308-280324098-1010093862=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:39:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MdPn29868 for linux-mips-outgoing; Thu, 3 Jan 2002 14:39:25 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MdHg29863; Thu, 3 Jan 2002 14:39:18 -0800 Received: from resel.enst-bretagne.fr (user18358@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03Ld8b11590; Thu, 3 Jan 2002 22:39:08 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA20266; Thu, 3 Jan 2002 22:39:09 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFZt-0002L6-00; Thu, 03 Jan 2002 22:39:09 +0100 Date: Thu, 3 Jan 2002 22:39:09 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: missing callbacks on setup (reboot) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1733247112-1010093949=:8906" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2215 Lines: 47 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-1733247112-1010093949=:8906 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This fixes missing callbacks for reboot with linux 2.5.1 on the ip27 and ip32. Vivien Chappelier. --279724308-1733247112-1010093949=:8906 Content-Type: TEXT/plain; name="linux-mips-reboot.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips-reboot.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9zZ2ktaXAyNy9pcDI3LXNl dHVwLmMgbGludXgucGF0Y2gvYXJjaC9taXBzNjQvc2dpLWlwMjcvaXAyNy1z ZXR1cC5jDQotLS0gbGludXgvYXJjaC9taXBzNjQvc2dpLWlwMjcvaXAyNy1z ZXR1cC5jCVdlZCBKYW4gIDIgMjI6NTY6NDEgMjAwMg0KKysrIGxpbnV4LnBh dGNoL2FyY2gvbWlwczY0L3NnaS1pcDI3L2lwMjctc2V0dXAuYwlXZWQgSmFu ICAyIDIzOjE0OjE5IDIwMDINCkBAIC0yNzYsNiArMjc2LDcgQEANCiANCiBl eHRlcm4gdm9pZCBpcDI3X3NldHVwX2NvbnNvbGUodm9pZCk7DQogZXh0ZXJu IHZvaWQgaXAyN190aW1lX2luaXQodm9pZCk7DQorZXh0ZXJuIHZvaWQgaXAy N19yZWJvb3Rfc2V0dXAodm9pZCk7DQogDQogdm9pZCBfX2luaXQgaXAyN19z ZXR1cCh2b2lkKQ0KIHsNCkBAIC0yODMsNiArMjg0LDcgQEANCiAJaHVicmVn X3QgcCwgZTsNCiANCiAJaXAyN19zZXR1cF9jb25zb2xlKCk7DQorCWlwMjdf cmVib290X3NldHVwKCk7DQogDQogCW51bV9icmlkZ2VzID0gMDsNCiAJLyoN CmRpZmYgLU5hdXIgbGludXgvYXJjaC9taXBzNjQvc2dpLWlwMzIvaXAzMi1z ZXR1cC5jIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzIt c2V0dXAuYw0KLS0tIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzIt c2V0dXAuYwlXZWQgSmFuICAyIDIyOjU2OjQxIDIwMDINCisrKyBsaW51eC5w YXRjaC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9pcDMyLXNldHVwLmMJV2VkIEph biAgMiAyMzoxNDoyMSAyMDAyDQpAQCAtNTgsNiArNTgsNyBAQA0KICNlbmRp Zg0KIA0KIGV4dGVybiB2b2lkIGlwMzJfdGltZV9pbml0KHZvaWQpOw0KK2V4 dGVybiB2b2lkIGlwMzJfcmVib290X3NldHVwKHZvaWQpOw0KIA0KIHZvaWQg X19pbml0IGJ1c19lcnJvcl9pbml0KHZvaWQpDQogew0KQEAgLTkyLDYgKzkz LDcgQEANCiAjaWZkZWYgQ09ORklHX1ZUDQogCWNvbnN3aXRjaHAgPSAmZHVt bXlfY29uOw0KICNlbmRpZg0KKwlpcDMyX3JlYm9vdF9zZXR1cCgpOw0KIA0K IAlydGNfb3BzID0gJmlwMzJfcnRjX29wczsNCiAJYm9hcmRfdGltZV9pbml0 ID0gaXAzMl90aW1lX2luaXQ7DQo= --279724308-1733247112-1010093949=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:41:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MfFJ30021 for linux-mips-outgoing; Thu, 3 Jan 2002 14:41:15 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Metg30016; Thu, 3 Jan 2002 14:40:55 -0800 Received: from resel.enst-bretagne.fr (user3695@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03Lejb11675; Thu, 3 Jan 2002 22:40:45 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA20345; Thu, 3 Jan 2002 22:40:46 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFbS-0002LF-00; Thu, 03 Jan 2002 22:40:46 +0100 Date: Thu, 3 Jan 2002 22:40:46 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: l2 cache support for the O2 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-908209083-1010093775=:8906" Content-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9193 Lines: 161 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-908209083-1010093775=:8906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello again, This patch adds support for the secondary cache on the O2. It works basically as the cache support for the ip22 (i.e. using the board_cache interface) Vivien Chappelier. --279724308-908209083-1010093775=:8906 Content-Type: TEXT/PLAIN; NAME="linux-O2-l2cache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="linux-O2-l2cache.diff" ZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9kZWZjb25maWctaXAzMiBs aW51eC5wYXRjaC9hcmNoL21pcHM2NC9kZWZjb25maWctaXAzMg0KLS0tIGxp bnV4L2FyY2gvbWlwczY0L2RlZmNvbmZpZy1pcDMyCVR1ZSBKYW4gIDEgMjE6 NTE6MTEgMjAwMg0KKysrIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0L2RlZmNv bmZpZy1pcDMyCVRodSBKYW4gIDMgMjA6NDM6MTAgMjAwMg0KQEAgLTI3LDYg KzI3LDcgQEANCiBDT05GSUdfTUFQUEVEX1BDSV9JTz15DQogQ09ORklHX05P TkNPSEVSRU5UX0lPPXkNCiBDT05GSUdfQVJDX01FTU9SWT15DQorQ09ORklH X0JPQVJEX1NDQUNIRT15DQogQ09ORklHX0wxX0NBQ0hFX1NISUZUPTUNCiAj IENPTkZJR19JU0EgaXMgbm90IHNldA0KICMgQ09ORklHX0VJU0EgaXMgbm90 IHNldA0KZGlmZiAtTmF1ciBsaW51eC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9N YWtlZmlsZSBsaW51eC5wYXRjaC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9NYWtl ZmlsZQ0KLS0tIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDMyL01ha2VmaWxl CVR1ZSBKYW4gIDEgMjE6NTE6MTIgMjAwMg0KKysrIGxpbnV4LnBhdGNoL2Fy Y2gvbWlwczY0L3NnaS1pcDMyL01ha2VmaWxlCVRodSBKYW4gIDMgMjA6NDI6 MTUgMjAwMg0KQEAgLTE4LDcgKzE4LDcgQEANCiBhbGw6IGlwMzIta2Vybi5h IGlwMzItaXJxLWdsdWUubw0KIA0KIG9iai15CSs9IGlwMzItcnRjLm8gaXAz Mi1zZXR1cC5vIGlwMzItaXJxLm8gaXAzMi1pcnEtZ2x1ZS5vIGlwMzItdGlt ZXIubyBcDQotCSAgIGNyaW1lLm8gaXAzMi1yZXNldC5vDQorCSAgIGNyaW1l Lm8gaXAzMi1yZXNldC5vIGlwMzItc2Mubw0KIA0KIG9iai0kKENPTkZJR19Q Q0kpICAgKz0gaXAzMi1wY2kubyBpcDMyLXBjaS1kbWEubw0KIA0KZGlmZiAt TmF1ciBsaW51eC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9pcDMyLXNjLmMgbGlu dXgucGF0Y2gvYXJjaC9taXBzNjQvc2dpLWlwMzIvaXAzMi1zYy5jDQotLS0g bGludXgvYXJjaC9taXBzNjQvc2dpLWlwMzIvaXAzMi1zYy5jCVRodSBKYW4g IDEgMDE6MDA6MDAgMTk3MA0KKysrIGxpbnV4LnBhdGNoL2FyY2gvbWlwczY0 L3NnaS1pcDMyL2lwMzItc2MuYwlUaHUgSmFuICAzIDIwOjQyOjMwIDIwMDIN CkBAIC0wLDAgKzEsMTU0IEBADQorLyoNCisgKiBpcDMyLXNjLmM6IE8yIGNh Y2hlIG1hbmFnZW1lbnQgZnVuY3Rpb25zLg0KKyAqDQorICogQ29weXJpZ2h0 IChDKSAxOTk3LCAyMDAxIFJhbGYgQmFlY2hsZSAocmFsZkBnbnUub3JnKSwN CisgKiBkZXJpdmVkIGZyb20gcjR4eDAuYyBieSBEYXZpZCBTLiBNaWxsZXIg KGRtQGVuZ3Iuc2dpLmNvbSkuDQorICovDQorI2luY2x1ZGUgPGxpbnV4L2lu aXQuaD4NCisjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQorI2luY2x1ZGUg PGxpbnV4L3NjaGVkLmg+DQorI2luY2x1ZGUgPGxpbnV4L21tLmg+DQorDQor I2luY2x1ZGUgPGFzbS9taXBzcmVncy5oPg0KKyNpbmNsdWRlIDxhc20vYmNh Y2hlLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFz bS9wZ3RhYmxlLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5j bHVkZSA8YXNtL21tdV9jb250ZXh0Lmg+DQorDQorLyogU2Vjb25kYXJ5IGNh Y2hlIHNpemUgaW4gYnl0ZXMsIGlmIHByZXNlbnQuICAqLw0KK3N0YXRpYyB1 bnNpZ25lZCBsb25nIHNjYWNoZV9zaXplOw0KKw0KKyN1bmRlZiBERUJVR19D QUNIRQ0KKw0KKyNkZWZpbmUgU0NfTElORSAzMg0KKw0KKyNkZWZpbmUgQ2xl YXJfU0QgICAgICAgICAgICAgICAgMHgwMw0KKyNkZWZpbmUgSW5kZXhfTG9h ZF9UYWdfU0QJMHgwNw0KKyNkZWZpbmUgSW5kZXhfU3RvcmVfVGFnX1NECTB4 MEINCisjZGVmaW5lIFBhZ2VfV3JpdGViYWNrX0ludl9TRCAgIDB4MTcNCisN CisjaWYgMCAvKiBUaGlzIGlzIHN1cHBvc2VkIHRvIGZsdXNoIHRoZSB3aG9s ZSBjYWNoZSBidXQgZG9lc24ndCBzZWVtIHRvIHdvcmsgKi8NCitzdGF0aWMg aW5saW5lIHZvaWQgZmx1c2hfc2NhY2hlX2FsbCh2b2lkKQ0KK3sgDQorICAg ICAgICB1bnNpZ25lZCBsb25nIGFkZHIgPSBLU0VHMDsNCisNCisJc2V0X3Rh Z2xvKDApOw0KKyAgICAgICAgX19hc21fXyBfX3ZvbGF0aWxlX18oIm5vcDsg bm9wOyBub3A7IG5vcDsiKTsgLyogYXZvaWQgdGhlIGhhemFyZCAqLw0KKwlf X2FzbV9fIF9fdm9sYXRpbGVfXygiXG5cdC5zZXQgbm9yZW9yZGVyXG5cdCIN CisJCQkgICAgICJjYWNoZSAweDAzLCAoJTApXG5cdCINCisJCQkgICAgICIu c2V0IHJlb3JkZXJcblx0IiA6IDogInIiIChhZGRyKSk7DQorfQ0KKyNlbmRp Zg0KKw0KK3N0YXRpYyBpbmxpbmUgdm9pZCBmbHVzaF9zY2FjaGVfcGFnZSh1 bnNpZ25lZCBsb25nIHBhZ2UpDQorew0KKwlfX2FzbV9fIF9fdm9sYXRpbGVf Xygibm9wOyBub3A7IG5vcDsgbm9wOyIpOyAvKiBoYXphcmQuLi4gKi8NCisJ X19hc21fXyBfX3ZvbGF0aWxlX18oIlxuXHQuc2V0IG5vcmVvcmRlclxuXHQi DQorCQkJICAgICAiY2FjaGUgMHgxNywgKCUwKVxuXHQiDQorCQkJICAgICAi LnNldCByZW9yZGVyXG5cdCIgOiA6ICJyIiAocGFnZSkpOw0KK30NCisNCitz dGF0aWMgaW5saW5lIHZvaWQgZmx1c2hfc2NhY2hlX2FsbCh2b2lkKQ0KK3sN CisgICAgICAgIHVuc2lnbmVkIGxvbmcgc3RhcnQgPSBLU0VHMDsgIC8qIHVu bWFwcGVkICovDQorCXVuc2lnbmVkIGxvbmcgZW5kID0gKHN0YXJ0ICsgc2Nh Y2hlX3NpemUpOw0KKw0KKwlzZXRfdGFnbG8oMCk7DQorCXdoaWxlKHN0YXJ0 IDwgZW5kKSB7DQorCSAgICAgICAgZmx1c2hfc2NhY2hlX3BhZ2Uoc3RhcnQp Ow0KKwkJc3RhcnQgKz0gUEFHRV9TSVpFOw0KKwl9DQorfQ0KKw0KK3N0YXRp YyB2b2lkIGlwMzJfc2Nfd2JhY2tfaW52YWxpZGF0ZSh1bnNpZ25lZCBsb25n IGFkZHIsIHVuc2lnbmVkIGxvbmcgc2l6ZSkNCit7DQorCXVuc2lnbmVkIGxv bmcgYmVnaW4sIGVuZDsNCisJdW5zaWduZWQgaW50IGZsYWdzOw0KKw0KKyNp ZmRlZiBERUJVR19DQUNIRQ0KKwlwcmludGsoImlwMzJfc2Nfd2JhY2tfaW52 YWxpZGF0ZVslMDhseCwlMDhseF0iLCBhZGRyLCBzaXplKTsNCisjZW5kaWYN CisNCisJaWYgKCFzaXplKQ0KKwkJcmV0dXJuOw0KKw0KKwkvKiBXaGljaCBw YWdlcyB0byBmbHVzaD8gICovDQorCWJlZ2luID0gKGFkZHIgJiBQQUdFX01B U0spOw0KKwllbmQgPSAoYWRkcitzaXplK1BBR0VfU0laRS0xKSAmIFBBR0Vf TUFTSzsNCisJLyogV2hpY2ggbGluZXMgdG8gZmx1c2g/ICAqLyANCisJYmVn aW4gPSBLU0VHMCArIChiZWdpbiAmIChzY2FjaGVfc2l6ZSAtIFNDX0xJTkUp KTsgLyogdW5tYXBwZWQgKi8NCisJZW5kID0gS1NFRzAgKyAoZW5kICYgKHNj YWNoZV9zaXplIC0gU0NfTElORSkpOw0KKw0KKwlzZXRfdGFnbG8oMCk7IC8q IGludmFsaWRhdGUgZmx1c2hlZCBwYWdlICovDQorCV9fc2F2ZV9hbmRfY2xp KGZsYWdzKTsNCisJaWYoYmVnaW4gPCBlbmQpIHsNCisJICBmb3IoYWRkciA9 IGJlZ2luOyBhZGRyIDwgZW5kOyBhZGRyICs9IFBBR0VfU0laRSkNCisJICAg IGZsdXNoX3NjYWNoZV9wYWdlKGFkZHIpOw0KKwkgIF9fYXNtX18gX192b2xh dGlsZV9fKCJub3A7IG5vcDsgbm9wOyBub3A7Iik7IC8qIGF2b2lkIHRoZSBo YXphcmQgKi8NCisJfSBlbHNlIHsNCisJICBmb3IoYWRkciA9IGJlZ2luOyBh ZGRyIDwgKEtTRUcwK3NjYWNoZV9zaXplKTsgYWRkciArPSBQQUdFX1NJWkUp DQorCSAgICBmbHVzaF9zY2FjaGVfcGFnZShhZGRyKTsNCisJICBfX2FzbV9f IF9fdm9sYXRpbGVfXygibm9wOyBub3A7IG5vcDsgbm9wOyIpOyAvKiBhdm9p ZCB0aGUgaGF6YXJkICovDQorCSAgZm9yKGFkZHIgPSBLU0VHMDsgYWRkciA8 IGVuZDsgYWRkciArPSBQQUdFX1NJWkUpDQorCSAgICBmbHVzaF9zY2FjaGVf cGFnZShhZGRyKTsNCisJICBfX2FzbV9fIF9fdm9sYXRpbGVfXygibm9wOyBu b3A7IG5vcDsgbm9wOyIpOyAvKiBhdm9pZCB0aGUgaGF6YXJkICovDQorCX0N CisJX19yZXN0b3JlX2ZsYWdzKGZsYWdzKTsNCit9DQorDQorc3RhdGljIHZv aWQgaXAzMl9zY19lbmFibGUodm9pZCkNCit7DQorICAgICAgICB1bnNpZ25l ZCBsb25nIGZsYWdzOw0KKw0KKwkvKiBUaGlzIGlzIHJlYWxseSBjb29sLi4u ICovDQorI2lmZGVmIERFQlVHX0NBQ0hFDQorCXByaW50aygiRW5hYmxpbmcg UjUwMDAgU0NBQ0hFXG4iKTsNCisjZW5kaWYNCisJX19zYXZlX2FuZF9jbGko ZmxhZ3MpOw0KKwljaGFuZ2VfY3AwX2NvbmZpZyhDT05GX1NFLCBDT05GX1NF KTsNCisJZmx1c2hfc2NhY2hlX2FsbCgpOw0KKwlfX3Jlc3RvcmVfZmxhZ3Mo ZmxhZ3MpOw0KK30NCisNCitzdGF0aWMgdm9pZCBpcDMyX3NjX2Rpc2FibGUo dm9pZCkNCit7DQorICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyNp ZmRlZiBERUJVR19DQUNIRQ0KKwlwcmludGsoIkRpc2FibGluZyBSNTAwMCBT Q0FDSEVcbiIpOw0KKyNlbmRpZg0KKwlfX3NhdmVfYW5kX2NsaShmbGFncyk7 DQorCWZsdXNoX3NjYWNoZV9hbGwoKTsNCisJY2hhbmdlX2NwMF9jb25maWco Q09ORl9TRSwgMCk7DQorCV9fcmVzdG9yZV9mbGFncyhmbGFncyk7DQorfQ0K Kw0KK3N0YXRpYyBpbmxpbmUgaW50IF9faW5pdCBpcDMyX3NjX3Byb2JlKHZv aWQpDQorew0KKwl1bnNpZ25lZCBsb25nIGNvbmZpZyA9IHJlYWRfMzJiaXRf Y3AwX3JlZ2lzdGVyKENQMF9DT05GSUcpOw0KKw0KKwlpZihjb25maWcgJiBD T05GX1NDKQ0KKwkJcmV0dXJuKDApOw0KKwkgIA0KKwlzY2FjaGVfc2l6ZSA9 ICg1MTIqMTAyNCkgPDwgKChjb25maWcgPj4gMjApJjMpOw0KKw0KKwlwcmlu dGsoIlI1MDAwIFNDQUNIRSBzaXplICVsZEssIGxpbmVzaXplIDMyIGJ5dGVz LlxuIiwNCisJICAgICAgIHNjYWNoZV9zaXplID4+IDEwKTsNCisNCisJcmV0 dXJuIDE7DQorfQ0KKw0KK3N0cnVjdCBiY2FjaGVfb3BzIGlwMzJfc2Nfb3Bz ID0gew0KKwlpcDMyX3NjX2VuYWJsZSwNCisJaXAzMl9zY19kaXNhYmxlLA0K KwlpcDMyX3NjX3diYWNrX2ludmFsaWRhdGUsDQorCWlwMzJfc2Nfd2JhY2tf aW52YWxpZGF0ZQ0KK307DQorDQordm9pZCBfX2luaXQgaXAzMl9zY19pbml0 KHZvaWQpDQorew0KKwlpZiAoaXAzMl9zY19wcm9iZSgpKSB7DQorCQlpcDMy X3NjX2VuYWJsZSgpOw0KKwkJYmNvcHMgPSAmaXAzMl9zY19vcHM7DQorCX0N Cit9DQpkaWZmIC1OYXVyIGxpbnV4L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lw MzItc2V0dXAuYyBsaW51eC5wYXRjaC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9p cDMyLXNldHVwLmMNCi0tLSBsaW51eC9hcmNoL21pcHM2NC9zZ2ktaXAzMi9p cDMyLXNldHVwLmMJV2VkIEphbiAgMiAyMzo0OToxOSAyMDAyDQorKysgbGlu dXgucGF0Y2gvYXJjaC9taXBzNjQvc2dpLWlwMzIvaXAzMi1zZXR1cC5jCVRo dSBKYW4gIDMgMjA6NDI6MDYgMjAwMg0KQEAgLTU5LDYgKzU5LDcgQEANCiAN CiBleHRlcm4gdm9pZCBpcDMyX3RpbWVfaW5pdCh2b2lkKTsNCiBleHRlcm4g dm9pZCBpcDMyX3JlYm9vdF9zZXR1cCh2b2lkKTsNCitleHRlcm4gdm9pZCBp cDMyX3NjX2luaXQodm9pZCk7DQogDQogdm9pZCBfX2luaXQgYnVzX2Vycm9y X2luaXQodm9pZCkNCiB7DQpAQCAtOTQsNiArOTUsNyBAQA0KIAljb25zd2l0 Y2hwID0gJmR1bW15X2NvbjsNCiAjZW5kaWYNCiAJaXAzMl9yZWJvb3Rfc2V0 dXAoKTsNCisJaXAzMl9zY19pbml0KCk7DQogDQogCXJ0Y19vcHMgPSAmaXAz Ml9ydGNfb3BzOw0KIAlib2FyZF90aW1lX2luaXQgPSBpcDMyX3RpbWVfaW5p dDsNCi0tLSBsaW51eC9hcmNoL21pcHM2NC9jb25maWcuaW4JVHVlIEphbiAg MSAyMTo1MToxMCAyMDAyDQorKysgbGludXgucGF0Y2gvYXJjaC9taXBzNjQv Y29uZmlnLmluCVRodSBKYW4gIDMgMjI6MDg6MzMgMjAwMg0KQEAgLTkxLDcg KzkxLDcgQEANCiAgICBkZWZpbmVfYm9vbCBDT05GSUdfQVJDMzIgeQ0KICAg IGRlZmluZV9ib29sIENPTkZJR19QQ19LRVlCIHkNCiAgICBkZWZpbmVfYm9v bCBDT05GSUdfUENJIHkNCi0gICAjZGVmaW5lX2Jvb2wgQ09ORklHX0JPQVJE X1NDQUNIRSB5DQorICAgZGVmaW5lX2Jvb2wgQ09ORklHX0JPQVJEX1NDQUNI RSB5DQogICAgZGVmaW5lX2Jvb2wgQ09ORklHX01BUFBFRF9QQ0lfSU8geQ0K ICAgIGRlZmluZV9ib29sIENPTkZJR19OT05DT0hFUkVOVF9JTyB5DQogICAg ZGVmaW5lX2Jvb2wgQ09ORklHX0FSQ19NRU1PUlkgeQ0K --279724308-908209083-1010093775=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:44:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MimZ30118 for linux-mips-outgoing; Thu, 3 Jan 2002 14:44:48 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Micg30110; Thu, 3 Jan 2002 14:44:39 -0800 Received: from resel.enst-bretagne.fr (user15024@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03LiTb11869; Thu, 3 Jan 2002 22:44:29 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA20667; Thu, 3 Jan 2002 22:44:30 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFf4-0002Lw-00; Thu, 03 Jan 2002 22:44:30 +0100 Date: Thu, 3 Jan 2002 22:44:30 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: binutils bug workaround Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1446538874-1010094270=:8906" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1893 Lines: 50 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-1446538874-1010094270=:8906 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, There is a binutils bug (as) which produces bad addresses when getting the address of a struct member for initializing the same struct, and when there is data or static functions declared before: int test = 0xdeadbeef; struct { int dummy; void *ptr; } bug = { ptr: &bug.ptr }; will produce bad value for bug.ptr. This patch move the declaration of kswapd_wait as a workaround to this compiler bug. This probably affects all mips64 kernels. Vivien Chappelier. --279724308-1446538874-1010094270=:8906 Content-Type: TEXT/plain; name="linux-mips-binutils_bug_workaround.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips-binutils_bug_workaround.diff" ZGlmZiAtTmF1ciBsaW51eC9tbS92bXNjYW4uYyBsaW51eC5wYXRjaC9tbS92 bXNjYW4uYw0KLS0tIGxpbnV4L21tL3Ztc2Nhbi5jCVN1biBEZWMgIDkgMTU6 NTM6MTUgMjAwMQ0KKysrIGxpbnV4LnBhdGNoL21tL3Ztc2Nhbi5jCVdlZCBK YW4gIDIgMjM6MTY6MjIgMjAwMg0KQEAgLTI0LDYgKzI0LDggQEANCiANCiAj aW5jbHVkZSA8YXNtL3BnYWxsb2MuaD4NCiANCitERUNMQVJFX1dBSVRfUVVF VUVfSEVBRChrc3dhcGRfd2FpdCk7DQorDQogLyoNCiAgKiBUaGUgInByaW9y aXR5IiBvZiBWTSBzY2FubmluZyBpcyBob3cgbXVjaCBvZiB0aGUgcXVldWVz IHdlDQogICogd2lsbCBzY2FuIGluIG9uZSBnby4gQSB2YWx1ZSBvZiA2IGZv ciBERUZfUFJJT1JJVFkgaW1wbGllcw0KQEAgLTYwMSw4ICs2MDMsNiBAQA0K IAlvdXRfb2ZfbWVtb3J5KCk7DQogCXJldHVybiAwOw0KIH0NCi0NCi1ERUNM QVJFX1dBSVRfUVVFVUVfSEVBRChrc3dhcGRfd2FpdCk7DQogDQogc3RhdGlj IGludCBjaGVja19jbGFzc3pvbmVfbmVlZF9iYWxhbmNlKHpvbmVfdCAqIGNs YXNzem9uZSkNCiB7DQo= --279724308-1446538874-1010094270=:8906-- From owner-linux-mips@oss.sgi.com Thu Jan 3 14:46:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MkQW30235 for linux-mips-outgoing; Thu, 3 Jan 2002 14:46:26 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MkKg30208; Thu, 3 Jan 2002 14:46:21 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16MFrP-00018Z-00; Thu, 03 Jan 2002 21:57:15 +0000 Subject: Re: aic7xxx (O2 scsi) DMA coherency To: vivien.chappelier@enst-bretagne.fr (Vivien Chappelier) Date: Thu, 3 Jan 2002 21:57:15 +0000 (GMT) Cc: ralf@oss.sgi.com (Ralf Baechle), linux-mips@oss.sgi.com In-Reply-To: from "Vivien Chappelier" at Jan 03, 2002 10:34:52 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 231 Lines: 5 > This tells the aic7xxx to use DMA safe memory for I/O. That seems totally inappropriate. The unchecked dma option is for ancient ISA DMA controllers that didnt do the 16Mb check. If you find you need it debug your pci remapper From owner-linux-mips@oss.sgi.com Thu Jan 3 14:52:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Mq4e30465 for linux-mips-outgoing; Thu, 3 Jan 2002 14:52:04 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Mq0g30462; Thu, 3 Jan 2002 14:52:00 -0800 Received: from resel.enst-bretagne.fr (user51609@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g03Lppb12256; Thu, 3 Jan 2002 22:51:51 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA21133; Thu, 3 Jan 2002 22:51:51 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MFmB-0002Mx-00; Thu, 03 Jan 2002 22:51:51 +0100 Date: Thu, 3 Jan 2002 22:51:51 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Alan Cox cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 597 Lines: 16 On Thu, 3 Jan 2002, Alan Cox wrote: > > This tells the aic7xxx to use DMA safe memory for I/O. > > That seems totally inappropriate. The unchecked dma option is for > ancient ISA DMA controllers that didnt do the 16Mb check. If you > find you need it debug your pci remapper This is used when scaning for devices (drivers/scsi/scsi_scan.c) . When this flag is not set, the code uses memory from the stack (unsigned char scsi_result0[256]; in scan_scsis) instead of kmallocating it DMA safe as it should on non-coherent systems. Maybe this is the thing to change? regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Thu Jan 3 14:53:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Mrg830552 for linux-mips-outgoing; Thu, 3 Jan 2002 14:53:42 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Mrbg30546; Thu, 3 Jan 2002 14:53:37 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 53DF0125C8; Thu, 3 Jan 2002 13:53:34 -0800 (PST) Date: Thu, 3 Jan 2002 13:53:34 -0800 From: "H . J . Lu" To: Vivien Chappelier Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: binutils bug workaround Message-ID: <20020103135334.A3978@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Thu, Jan 03, 2002 at 10:44:30PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 625 Lines: 26 On Thu, Jan 03, 2002 at 10:44:30PM +0100, Vivien Chappelier wrote: > Hi, > > There is a binutils bug (as) which produces bad addresses when > getting the address of a struct member for initializing the same struct, > and when there is data or static functions declared before: > int test = 0xdeadbeef; > > struct { > int dummy; > void *ptr; > } bug = > { > ptr: &bug.ptr > }; > > will produce bad value for bug.ptr. > > This patch move the declaration of kswapd_wait as a workaround to > this compiler bug. This probably affects all mips64 kernels. > Shouldn't you fix the assmbler instead? H.J. From owner-linux-mips@oss.sgi.com Thu Jan 3 14:57:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MvFN30818 for linux-mips-outgoing; Thu, 3 Jan 2002 14:57:15 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g03MvAg30815 for ; Thu, 3 Jan 2002 14:57:11 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g03LuvO04043; Thu, 3 Jan 2002 19:56:57 -0200 Date: Thu, 3 Jan 2002 19:56:57 -0200 From: Ralf Baechle To: "H . J . Lu" Cc: Vivien Chappelier , linux-mips@oss.sgi.com Subject: Re: binutils bug workaround Message-ID: <20020103195657.A12572@dea.linux-mips.net> References: <20020103135334.A3978@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020103135334.A3978@lucon.org>; from hjl@lucon.org on Thu, Jan 03, 2002 at 01:53:34PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 377 Lines: 11 On Thu, Jan 03, 2002 at 01:53:34PM -0800, H . J . Lu wrote: > > This patch move the declaration of kswapd_wait as a workaround to > > this compiler bug. This probably affects all mips64 kernels. > > Shouldn't you fix the assmbler instead? I absolutely agree. The only thing I'd like to add is a some code that makes the kernel panic if built with broken binutils. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 3 15:24:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03NO5M04539 for linux-mips-outgoing; Thu, 3 Jan 2002 15:24:05 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03NO0g04536; Thu, 3 Jan 2002 15:24:00 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16MGRs-0001If-00; Thu, 03 Jan 2002 22:34:56 +0000 Subject: Re: aic7xxx (O2 scsi) DMA coherency To: vivien.chappelier@enst-bretagne.fr (Vivien Chappelier) Date: Thu, 3 Jan 2002 22:34:55 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), ralf@oss.sgi.com (Ralf Baechle), linux-mips@oss.sgi.com In-Reply-To: from "Vivien Chappelier" at Jan 03, 2002 10:51:51 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 272 Lines: 6 > scsi_result0[256]; in scan_scsis) instead of kmallocating it DMA safe as > it should on non-coherent systems. Maybe this is the thing to change? Please fix that - thats a real bug. Actually you may find the PPC64 people (Anton and co) already have a patch you can use From owner-linux-mips@oss.sgi.com Thu Jan 3 16:45:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g040jk407015 for linux-mips-outgoing; Thu, 3 Jan 2002 16:45:46 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g040jig07012 for ; Thu, 3 Jan 2002 16:45:44 -0800 Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 16MHYL-0001Vd-00; Fri, 04 Jan 2002 00:45:41 +0100 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 16MHX7-0000PS-00; Fri, 04 Jan 2002 00:44:25 +0100 Date: Fri, 4 Jan 2002 00:44:25 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: Newport Xserver 2001-11-21 Message-ID: <20020104004425.B1519@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <200201031852.TAA01081@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201031852.TAA01081@sparta.research.kpn.com>; from vhouten@kpn.com on Thu, Jan 03, 2002 at 07:52:13PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 725 Lines: 15 On Thu, Jan 03, 2002 at 07:52:13PM +0100, Houten K.H.C. van (Karel) wrote: > > Hi Guido, > > I'm experimenting with your Xserver for my indy, currently running > the 2.4.16 kernel. I've used a local compiled Xserver before, but that > was with an older kernel. Now, using 2.4.16 and your Xserver, I get the > following errors: Which 2.4.16? The one in the debian archive works. The X-Server parses /proc/cpuinfo to check if it runs on an Indy(yes, thats ugly) since we still have now proper GIO64 bus interface. Ralf recently changed some things in /proc/cpuinfo that broke this parsing. He reverted these changes later, so current oss cvs kernels should provide the necessary information in /proc/cpuinfo again. -- Guido From owner-linux-mips@oss.sgi.com Thu Jan 3 17:06:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0416jC07605 for linux-mips-outgoing; Thu, 3 Jan 2002 17:06:45 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0416gg07602 for ; Thu, 3 Jan 2002 17:06:42 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g03NqFd01594; Thu, 3 Jan 2002 21:52:15 -0200 Date: Thu, 3 Jan 2002 21:52:15 -0200 From: Ralf Baechle To: Vivien Chappelier Cc: Alan Cox , linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency Message-ID: <20020103215215.A1186@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Thu, Jan 03, 2002 at 10:51:51PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 677 Lines: 16 On Thu, Jan 03, 2002 at 10:51:51PM +0100, Vivien Chappelier wrote: > > > This tells the aic7xxx to use DMA safe memory for I/O. > > > > That seems totally inappropriate. The unchecked dma option is for > > ancient ISA DMA controllers that didnt do the 16Mb check. If you > > find you need it debug your pci remapper > > This is used when scaning for devices (drivers/scsi/scsi_scan.c) . When > this flag is not set, the code uses memory from the stack (unsigned char > scsi_result0[256]; in scan_scsis) instead of kmallocating it DMA safe as > it should on non-coherent systems. Maybe this is the thing to change? Indeed, it is. I thought this one died ages ago. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 3 21:12:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g045C5i11728 for linux-mips-outgoing; Thu, 3 Jan 2002 21:12:05 -0800 Received: from hotmail.com (f20.law8.hotmail.com [216.33.241.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g045C2g11720 for ; Thu, 3 Jan 2002 21:12:02 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jan 2002 20:11:55 -0800 Received: from 63.194.140.131 by lw8fd.law8.hotmail.msn.com with HTTP; Fri, 04 Jan 2002 04:11:55 GMT X-Originating-IP: [63.194.140.131] From: "Balaji" To: linux-mips@oss.sgi.com Subject: kernel panic Date: Thu, 03 Jan 2002 20:11:55 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jan 2002 04:11:55.0445 (UTC) FILETIME=[F2239E50:01C194D5] Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 496 Lines: 25 Hi, Does anyone happen to get the following error message? Kernel panic: rs_set_termios called Actually the kernel boots and when the /sbin/init executes, it gives the above message and hangs. This panic is located in the serial drivers but I dont know why they are called. Any help would be greatly appreciated. Best regards, Balaji _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-linux-mips@oss.sgi.com Fri Jan 4 09:35:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04HZ9N12687 for linux-mips-outgoing; Fri, 4 Jan 2002 09:35:09 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04HZ1g12684 for ; Fri, 4 Jan 2002 09:35:01 -0800 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g04GYnt09101; Fri, 4 Jan 2002 16:34:49 GMT Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id QAA19027; Fri, 4 Jan 2002 16:34:49 GMT Date: Fri, 4 Jan 2002 16:34:49 GMT Message-Id: <200201041634.QAA19027@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: linux-mips cc: rick@algor.co.uk, nigel@algor.co.uk, john@algor.co.uk Subject: Designing hardware to join PCI to large local memory X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2118 Lines: 50 Up to now, Algorithmics' MIPS-based single-board computers have offered a maximum of 256Mbytes DRAM. We can (and do) map all of that to PCI at the beginning of time, so any PCI "bus master" device can get to any part of system DRAM. We're now working out how our system controller ("north bridge", more or less) can handle much larger memories - we would like it to go on past 4Gbytes. So now there aren't enough addresses on PCI to map all the memory. We can see two options: 1. Just say it's too bad: PCI devices can only get at memory, say, from 0-256Mbytes. We know that some PCs a while back couldn't DMA above 16Mbytes, and we see that the kernel memory allocator has a "DMA-able" flag... But this seems quite difficult to handle in a robust and efficient way; for example: - The virtual memory paging system presumably uses DMA into user pages; it would need to choose instead to allocate an intermediate buffer and copy data when the user page was not DMA-able. Yuk. Or copy everything - double-yuk. - Any system which is up for a long time with high memory demand will risk deadlock if non-DMA requirements take too much DMAable memory, or waste a lot of memory if they take too little. 2. Add some dynamic kind of translation so PCI devices can get to the memory they need anywhere, and we have enough translation resources to keep all pending-DMA devices happy. But the hardware will be relatively complicated, and may need special software routines to maintain it. We (more specifically Chris) have looked at the kernel sources, and concluded that schemes of both types have been attempted - though the sources don't, of course, pass judgement on how well it worked. Those of you with experience: which would you recommend? And if (2), can you point us to descriptions of good hardware facilities you've met or even imagined? -- Dominic Sweetman Algorithmics Ltd - http://www.algor.co.uk The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 From owner-linux-mips@oss.sgi.com Fri Jan 4 09:40:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04HehX12820 for linux-mips-outgoing; Fri, 4 Jan 2002 09:40:43 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Hecg12817 for ; Fri, 4 Jan 2002 09:40:39 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 16MXZ1-0004da-00; Fri, 04 Jan 2002 16:51:27 +0000 Subject: Re: Designing hardware to join PCI to large local memory To: dom@algor.co.uk (Dominic Sweetman) Date: Fri, 4 Jan 2002 16:51:27 +0000 (GMT) Cc: linux-mips@oss.sgi.com (linux-mips), rick@algor.co.uk, nigel@algor.co.uk, john@algor.co.uk In-Reply-To: <200201041634.QAA19027@mudchute.algor.co.uk> from "Dominic Sweetman" at Jan 04, 2002 04:34:49 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 877 Lines: 21 > or less) can handle much larger memories - we would like it to go on > past 4Gbytes. So now there aren't enough addresses on PCI to map all > the memory. Good PCI devices can support DAC and can access 64bits on a 32bit bus at a tiny penalty. > We (more specifically Chris) have looked at the kernel sources, and > concluded that schemes of both types have been attempted - though the > sources don't, of course, pass judgement on how well it worked. > > Those of you with experience: which would you recommend? And if (2), > can you point us to descriptions of good hardware facilities you've > met or even imagined? On big X86 setups bounce buffers really do hurt I/O performance. The real answer is either DAC aware hardware for performance critical stuff or some kind of mapping hardware, which requires much more complex toys than a random cheap pci bridge. Alan From owner-linux-mips@oss.sgi.com Fri Jan 4 09:50:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04Hot613032 for linux-mips-outgoing; Fri, 4 Jan 2002 09:50:55 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Hopg13029 for ; Fri, 4 Jan 2002 09:50:51 -0800 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 g04Golw19561; Fri, 4 Jan 2002 17:50:47 +0100 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 RAA17203; Fri, 4 Jan 2002 17:50:47 +0100 (MET) Message-Id: <200201041650.RAA17203@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: Newport Xserver 2001-11-21 In-reply-to: Your message of "Fri, 04 Jan 2002 00:44:25 +0100." <20020104004425.B1519@galadriel.physik.uni-konstanz.de> 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: Fri, 04 Jan 2002 17:50:47 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1132 Lines: 32 Hi Guido, You wrote: > On Thu, Jan 03, 2002 at 07:52:13PM +0100, Houten K.H.C. van (Karel) wrote: > > I'm experimenting with your Xserver for my indy, currently running > > the 2.4.16 kernel. I've used a local compiled Xserver before, but that > > was with an older kernel. Now, using 2.4.16 and your Xserver, I get the > > following errors: > Which 2.4.16? The one in the debian archive works. The X-Server > parses /proc/cpuinfo to check if it runs on an Indy(yes, thats ugly) > since we still have now proper GIO64 bus interface. Ralf recently > changed some things in /proc/cpuinfo that broke this parsing. He > reverted these changes later, so current oss cvs kernels should provide > the necessary information in /proc/cpuinfo again. Thanks. I've checked out 2.4.17 from CVS, and it indeed solves the problem (now I only have to reinstall the X fonts :-). 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 Fri Jan 4 10:08:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04I8OL13349 for linux-mips-outgoing; Fri, 4 Jan 2002 10:08:24 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04I8Dg13346; Fri, 4 Jan 2002 10:08:14 -0800 Received: from resel.enst-bretagne.fr (maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04H81b22909; Fri, 4 Jan 2002 18:08:01 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA08775; Fri, 4 Jan 2002 18:08:02 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MTVn-0000K9-00; Fri, 04 Jan 2002 13:31:51 +0100 Date: Fri, 4 Jan 2002 13:30:55 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Alan Cox cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-637116453-1010147455=:639" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2467 Lines: 57 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-637116453-1010147455=:639 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, On Thu, 3 Jan 2002, Alan Cox wrote: > > This tells the aic7xxx to use DMA safe memory for I/O. > > That seems totally inappropriate. The unchecked dma option is for > ancient ISA DMA controllers that didnt do the 16Mb check. > Maybe this is more appropriate then :) It tells the scsi scanner to always use DMA safe memory when doing its INQUIRY commands... On the O2, kernel is running in cacheable, non-coherent memory. kmalloc, with GFP_DMA flag will return a piece of uncacheable memory which is safe for I/O with devices. regards, Vivien Chappelier --279724308-637116453-1010147455=:639 Content-Type: TEXT/plain; name="linux-scsi_scan.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-scsi_scan.diff" LS0tIGxpbnV4L2RyaXZlcnMvc2NzaS9zY3NpX3NjYW4uYwlUaHUgRGVjIDIw IDE4OjMxOjA5IDIwMDENCisrKyBsaW51eC5wYXRjaC9kcml2ZXJzL3Njc2kv c2NzaV9zY2FuLmMJRnJpIEphbiAgNCAxMzoxNzozMSAyMDAyDQpAQCAtMjgz LDcgKzI4Myw2IEBADQogCXVuc2lnbmVkIGludCBsdW47DQogCXVuc2lnbmVk IGludCBtYXhfZGV2X2x1bjsNCiAJdW5zaWduZWQgY2hhciAqc2NzaV9yZXN1 bHQ7DQotCXVuc2lnbmVkIGNoYXIgc2NzaV9yZXN1bHQwWzI1Nl07DQogCVNj c2lfRGV2aWNlICpTRHBudDsNCiAJU2NzaV9EZXZpY2UgKlNEdGFpbDsNCiAJ dW5zaWduZWQgaW50IHNwYXJzZV9sdW47DQpAQCAtMzA1LDggKzMwNCw3IEBA DQogCQlzY3NpX2luaXRpYWxpemVfcXVldWUoU0RwbnQsIHNocG50KTsNCiAJ CVNEcG50LT5yZXF1ZXN0X3F1ZXVlLnF1ZXVlZGF0YSA9ICh2b2lkICopIFNE cG50Ow0KIAkJLyogTWFrZSBzdXJlIHdlIGhhdmUgc29tZXRoaW5nIHRoYXQg aXMgdmFsaWQgZm9yIERNQSBwdXJwb3NlcyAqLw0KLQkJc2NzaV9yZXN1bHQg PSAoKCFzaHBudC0+dW5jaGVja2VkX2lzYV9kbWEpDQotCQkJICAgICAgID8g JnNjc2lfcmVzdWx0MFswXSA6IGttYWxsb2MoNTEyLCBHRlBfRE1BKSk7DQor CQlzY3NpX3Jlc3VsdCA9IGttYWxsb2MoNTEyLCBHRlBfRE1BKTsNCiAJfQ0K IA0KIAlpZiAoc2NzaV9yZXN1bHQgPT0gTlVMTCkgew0KQEAgLTQ2Myw3ICs0 NjEsNyBAQA0KIAl9DQogDQogCS8qIElmIHdlIGFsbG9jYXRlZCBhIGJ1ZmZl ciBzbyB3ZSBjb3VsZCBkbyBETUEsIGZyZWUgaXQgbm93ICovDQotCWlmIChz Y3NpX3Jlc3VsdCAhPSAmc2NzaV9yZXN1bHQwWzBdICYmIHNjc2lfcmVzdWx0 ICE9IE5VTEwpIHsNCisJaWYgKHNjc2lfcmVzdWx0ICE9IE5VTEwpIHsNCiAJ CWtmcmVlKHNjc2lfcmVzdWx0KTsNCiAJfSB7DQogCQlTY3NpX0RldmljZSAq c2RldjsNCg== --279724308-637116453-1010147455=:639-- From owner-linux-mips@oss.sgi.com Fri Jan 4 10:33:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04IXAL13933 for linux-mips-outgoing; Fri, 4 Jan 2002 10:33:10 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04IX1g13930; Fri, 4 Jan 2002 10:33:01 -0800 Received: from resel.enst-bretagne.fr (user92826@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04HWqb30062; Fri, 4 Jan 2002 18:32:52 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA15603; Fri, 4 Jan 2002 18:32:52 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MYD6-0000xh-00; Fri, 04 Jan 2002 18:32:52 +0100 Date: Fri, 4 Jan 2002 18:32:52 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: Alan Cox , linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency In-Reply-To: <20020103215215.A1186@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-311915002-1010165488=:3669" Content-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2857 Lines: 61 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-311915002-1010165488=:3669 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Thu, 3 Jan 2002, Ralf Baechle wrote: > On Thu, Jan 03, 2002 at 10:51:51PM +0100, Vivien Chappelier wrote: > > > > > This tells the aic7xxx to use DMA safe memory for I/O. > > > > > > That seems totally inappropriate. The unchecked dma option is for > > > ancient ISA DMA controllers that didnt do the 16Mb check. If you > > > find you need it debug your pci remapper > > > > This is used when scaning for devices (drivers/scsi/scsi_scan.c) . When > > this flag is not set, the code uses memory from the stack (unsigned char > > scsi_result0[256]; in scan_scsis) instead of kmallocating it DMA safe as > > it should on non-coherent systems. Maybe this is the thing to change? > > Indeed, it is. I thought this one died ages ago. Here is a patch to fix that then. It forces allocation of DMA safe memory in any case. I've not looked at the PPC64 patch however. regards, Vivien Chappelier. --279724308-311915002-1010165488=:3669 Content-Type: TEXT/PLAIN; NAME="linux-scsi_scan.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="linux-scsi_scan.diff" LS0tIGxpbnV4L2RyaXZlcnMvc2NzaS9zY3NpX3NjYW4uYwlUaHUgRGVjIDIw IDE4OjMxOjA5IDIwMDENCisrKyBsaW51eC5wYXRjaC9kcml2ZXJzL3Njc2kv c2NzaV9zY2FuLmMJRnJpIEphbiAgNCAxMzoxNzozMSAyMDAyDQpAQCAtMjgz LDcgKzI4Myw2IEBADQogCXVuc2lnbmVkIGludCBsdW47DQogCXVuc2lnbmVk IGludCBtYXhfZGV2X2x1bjsNCiAJdW5zaWduZWQgY2hhciAqc2NzaV9yZXN1 bHQ7DQotCXVuc2lnbmVkIGNoYXIgc2NzaV9yZXN1bHQwWzI1Nl07DQogCVNj c2lfRGV2aWNlICpTRHBudDsNCiAJU2NzaV9EZXZpY2UgKlNEdGFpbDsNCiAJ dW5zaWduZWQgaW50IHNwYXJzZV9sdW47DQpAQCAtMzA1LDggKzMwNCw3IEBA DQogCQlzY3NpX2luaXRpYWxpemVfcXVldWUoU0RwbnQsIHNocG50KTsNCiAJ CVNEcG50LT5yZXF1ZXN0X3F1ZXVlLnF1ZXVlZGF0YSA9ICh2b2lkICopIFNE cG50Ow0KIAkJLyogTWFrZSBzdXJlIHdlIGhhdmUgc29tZXRoaW5nIHRoYXQg aXMgdmFsaWQgZm9yIERNQSBwdXJwb3NlcyAqLw0KLQkJc2NzaV9yZXN1bHQg PSAoKCFzaHBudC0+dW5jaGVja2VkX2lzYV9kbWEpDQotCQkJICAgICAgID8g JnNjc2lfcmVzdWx0MFswXSA6IGttYWxsb2MoNTEyLCBHRlBfRE1BKSk7DQor CQlzY3NpX3Jlc3VsdCA9IGttYWxsb2MoNTEyLCBHRlBfRE1BKTsNCiAJfQ0K IA0KIAlpZiAoc2NzaV9yZXN1bHQgPT0gTlVMTCkgew0KQEAgLTQ2Myw3ICs0 NjEsNyBAQA0KIAl9DQogDQogCS8qIElmIHdlIGFsbG9jYXRlZCBhIGJ1ZmZl ciBzbyB3ZSBjb3VsZCBkbyBETUEsIGZyZWUgaXQgbm93ICovDQotCWlmIChz Y3NpX3Jlc3VsdCAhPSAmc2NzaV9yZXN1bHQwWzBdICYmIHNjc2lfcmVzdWx0 ICE9IE5VTEwpIHsNCisJaWYgKHNjc2lfcmVzdWx0ICE9IE5VTEwpIHsNCiAJ CWtmcmVlKHNjc2lfcmVzdWx0KTsNCiAJfSB7DQogCQlTY3NpX0RldmljZSAq c2RldjsNCg== --279724308-311915002-1010165488=:3669-- From owner-linux-mips@oss.sgi.com Fri Jan 4 12:46:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04KkK521596 for linux-mips-outgoing; Fri, 4 Jan 2002 12:46:20 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04KkGg21579 for ; Fri, 4 Jan 2002 12:46:17 -0800 Received: from resel.enst-bretagne.fr (user94819@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04Jk7b07726 for ; Fri, 4 Jan 2002 20:46:07 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA26202 for ; Fri, 4 Jan 2002 20:46:07 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MaI3-00014n-00 for ; Fri, 04 Jan 2002 20:46:07 +0100 Date: Fri, 4 Jan 2002 20:46:07 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency (fwd) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 908 Lines: 26 forgot the Cc to the list... BTW sorry for the dual post. ---------- Forwarded message ---------- Date: Fri, 4 Jan 2002 20:33:48 +0100 (CET) From: Vivien Chappelier To: Ilya Volynets Subject: Re: aic7xxx (O2 scsi) DMA coherency > Are you sure GFP_DMA does what you think it does? > I'm not. I thnk using pci_alloc_consistant is more appropriate for > this purpose. Neither am I, I'm just a new kernel hacker :) Anyway, I think what we want is doing I/O using DMA with the scsi controller, so I think we need DMA safe memory for this. Wether the arch needs to ensure coherency for that is not really the concern. On the O2, dma memory is uncacheable memory, but other archs might have other concerns regarding dma memory (below 16Mb for example?), so I think pci_alloc_consistent is not appropriate in this case. regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Fri Jan 4 13:59:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04Lx0e24435 for linux-mips-outgoing; Fri, 4 Jan 2002 13:59:00 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Lwtg24432 for ; Fri, 4 Jan 2002 13:58:56 -0800 Received: from resel.enst-bretagne.fr (user46613@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04Kwjb11653; Fri, 4 Jan 2002 21:58:45 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id VAA31614; Fri, 4 Jan 2002 21:58:46 +0100 X-Authentication-Warning: maisel-gw.enst-bretagne.fr: Host mail@melkor.maisel.enst-bretagne.fr [172.16.20.65] claimed to be melkor Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16MbQM-0001AH-00; Fri, 04 Jan 2002 21:58:46 +0100 Date: Fri, 4 Jan 2002 21:58:45 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ilya Volynets cc: linux-mips@oss.sgi.com Subject: Re: aic7xxx (O2 scsi) DMA coherency In-Reply-To: <20020104194622.29320.qmail@gateway.total-knowledge.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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 799 Lines: 18 On Fri, 4 Jan 2002, Ilya Volynets wrote: > On Friday 04 January 2002 11:33 am, you wrote: > This is true in theory. In practice you have to look at kmalloc implementation > and how it uses GFP_DMA. I don't remember anything arch specific in there, > but I never seriously dug in that part. I believe it doesn't do what we need, > otherwice We'd be using it for pci_alloc_consistent. Well, both pci_alloc_consistent and kmalloc will end up calling __get_free_pages, with the GFP_DMA flag set. On setup, with the MIPS64 arch, DMA memory is set to start in non-cacheable space (don't know how). So both pci_alloc_consistent and kmalloc(GFP_DMA,...) will return DMA safe (i.e. non cacheable) memory. see mm/slab.c (for kmalloc and how it finally calls __get_free_pages). regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Fri Jan 4 14:03:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04M3t024731 for linux-mips-outgoing; Fri, 4 Jan 2002 14:03:55 -0800 Received: from quicklogic.com (quick1.quicklogic.com [206.184.225.224]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04M3mg24728 for ; Fri, 4 Jan 2002 14:03:48 -0800 Received: from qldomain-Message_Server by quicklogic.com with Novell_GroupWise; Fri, 04 Jan 2002 12:57:34 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 04 Jan 2002 12:57:00 -0800 From: "Dan Aizenstros" To: Subject: Oops in do_mounts.c file. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5B065C2E.AACB827B" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2087 Lines: 55 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5B065C2E.AACB827B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, I am getting an oops in the mount_root function if I pass root=3D/dev/nfs to my 2.5.1 kernel. I am also getting an oops in the mount_block_root function if I pass root=3D/dev/hda3 to my 2.5.1 kernel. The problem appears to be related to the following two lines in the init/do_mounts.c file: static char * __initdata root_mount_data; static char * __initdata root_fs_names; The __initdata macro appears to be incorrectly used. In include/linux/init.h the explanation for the macro says the __initdata should appear after the variable name. It also indicates that the variable shoud be initialized. The attached patch fixes the problem. -- Dan A. --=_5B065C2E.AACB827B Content-Type: application/octet-stream; name="do_mounts.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="do_mounts.patch" SW5kZXg6IGRvX21vdW50cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvbGludXgvaW5pdC9k b19tb3VudHMuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xCmRpZmYgLXUgLXIxLjEgZG9fbW91 bnRzLmMKLS0tIGRvX21vdW50cy5jCTIwMDEvMTIvMTkgMDA6MDQ6MDEJMS4xCisrKyBkb19tb3Vu dHMuYwkyMDAyLzAxLzA0IDIyOjAyOjIwCkBAIC0yMzksMTQgKzIzOSwxNCBAQAogCiBfX3NldHVw KCJyb290PSIsIHJvb3RfZGV2X3NldHVwKTsKIAotc3RhdGljIGNoYXIgKiBfX2luaXRkYXRhIHJv b3RfbW91bnRfZGF0YTsKK3N0YXRpYyBjaGFyICogcm9vdF9tb3VudF9kYXRhIF9faW5pdGRhdGEg PSBOVUxMOwogc3RhdGljIGludCBfX2luaXQgcm9vdF9kYXRhX3NldHVwKGNoYXIgKnN0cikKIHsK IAlyb290X21vdW50X2RhdGEgPSBzdHI7CiAJcmV0dXJuIDE7CiB9CiAKLXN0YXRpYyBjaGFyICog X19pbml0ZGF0YSByb290X2ZzX25hbWVzOworc3RhdGljIGNoYXIgKiByb290X2ZzX25hbWVzIF9f aW5pdGRhdGEgPSBOVUxMOwogc3RhdGljIGludCBfX2luaXQgZnNfbmFtZXNfc2V0dXAoY2hhciAq c3RyKQogewogCXJvb3RfZnNfbmFtZXMgPSBzdHI7Cg== --=_5B065C2E.AACB827B-- From owner-linux-mips@oss.sgi.com Fri Jan 4 17:59:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g051xRm28375 for linux-mips-outgoing; Fri, 4 Jan 2002 17:59:27 -0800 Received: from skip1.webley.com (ns1.webley.com [207.25.7.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g051xOg28372 for ; Fri, 4 Jan 2002 17:59:25 -0800 Received: from exchange.webley (exchange.webley [10.50.7.31]) by skip1.webley.com (8.9.3/8.9.3) with ESMTP id SAA00320 for ; Fri, 4 Jan 2002 18:59:22 -0600 Received: from webley.com (eng-df149.webley [10.50.2.199]) by exchange.webley with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y2FGFGR7; Fri, 4 Jan 2002 18:59:22 -0600 Message-ID: <3C364FDE.9080008@webley.com> Date: Fri, 04 Jan 2002 18:59:10 -0600 From: Nicholas Harring User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Question about SMP NEC RISCServer Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 471 Lines: 12 Hi all, I have a question which, while partially addressed in the HOWTO, I wanted to ask here to determine if the HOWTO is 100% up to date. I recently acquired an NEC RISCServer 4200 with four Mips R4400 cpus. Is this machine still completely unsupported, or is there work ongoing into getting it to boot with four cpus? If there is work ongoing, please contact me as I'd love to volunteer my machine and time to help test and so on. Thanks in advance, Nick Harring From owner-linux-mips@oss.sgi.com Sun Jan 6 14:13:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06MD8S19185 for linux-mips-outgoing; Sun, 6 Jan 2002 14:13:08 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g06MD5g19177 for ; Sun, 6 Jan 2002 14:13:05 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g06LCuw02518; Sun, 6 Jan 2002 19:12:56 -0200 Date: Sun, 6 Jan 2002 19:12:56 -0200 From: Ralf Baechle To: Nicholas Harring Cc: linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer Message-ID: <20020106191256.A2418@dea.linux-mips.net> References: <3C364FDE.9080008@webley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C364FDE.9080008@webley.com>; from nharring@webley.com on Fri, Jan 04, 2002 at 06:59:10PM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 710 Lines: 16 On Fri, Jan 04, 2002 at 06:59:10PM -0600, Nicholas Harring wrote: > I have a question which, while partially addressed in the HOWTO, I > wanted to ask here to determine if the HOWTO is 100% up to date. > I recently acquired an NEC RISCServer 4200 with four Mips R4400 cpus. Is > this machine still completely unsupported, or is there work ongoing into > getting it to boot > with four cpus? > If there is work ongoing, please contact me as I'd love to volunteer my > machine and time to help test and so on. We have no information at all about the NEC hardware. As the group that built NEC's systems does no longer exist reverse engineering seems to be the only way to ever support NEC systems. Ralf From owner-linux-mips@oss.sgi.com Sun Jan 6 18:15:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g072Fvs23388 for linux-mips-outgoing; Sun, 6 Jan 2002 18:15:57 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g072Fmg23370 for ; Sun, 6 Jan 2002 18:15:49 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g071FSb05938; Sun, 6 Jan 2002 23:15:28 -0200 Date: Sun, 6 Jan 2002 23:15:28 -0200 From: Ralf Baechle To: Dan Aizenstros Cc: linux-mips@oss.sgi.com Subject: Re: Oops in do_mounts.c file. Message-ID: <20020106231528.A3806@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from daizenstros@quicklogic.com on Fri, Jan 04, 2002 at 12:57:00PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1326 Lines: 37 On Fri, Jan 04, 2002 at 12:57:00PM -0800, Dan Aizenstros wrote: > I am getting an oops in the mount_root function if I > pass root=/dev/nfs to my 2.5.1 kernel. > > I am also getting an oops in the mount_block_root > function if I pass root=/dev/hda3 to my 2.5.1 kernel. > > The problem appears to be related to the following two > lines in the init/do_mounts.c file: > > static char * __initdata root_mount_data; > > static char * __initdata root_fs_names; > > The __initdata macro appears to be incorrectly used. > > In include/linux/init.h the explanation for the macro > says the __initdata should appear after the variable > name. It also indicates that the variable shoud be > initialized. Old gcc was more restrictive about the position of __attribute__() than current gccs. The comment documents older gcc. Old in this context means older than egcs 1.1.2 which is currently the required minmum version to compile the kernel. > The attached patch fixes the problem. And that's highly suspect. No matter with or without your patch root_mount_data and root_fs_names should endup in .data.init. So if your patch indeed has an effect that your compiler seems is suspect. Can you try to look at the generated assembler source and object files and check into which sections gcc places these variables? Ralf From owner-linux-mips@oss.sgi.com Sun Jan 6 20:23:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g074NKS26051 for linux-mips-outgoing; Sun, 6 Jan 2002 20:23:20 -0800 Received: from rover.village.org (warner@rover.bsdimp.com [204.144.255.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g074N2g26046; Sun, 6 Jan 2002 20:23:02 -0800 Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g073Mwl67305; Sun, 6 Jan 2002 20:22:59 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g073Mvx23828; Sun, 6 Jan 2002 20:22:57 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 06 Jan 2002 20:22:42 -0700 (MST) Message-Id: <20020106.202242.102614262.imp@village.org> To: ralf@oss.sgi.com Cc: nharring@webley.com, linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer From: "M. Warner Losh" In-Reply-To: <20020106191256.A2418@dea.linux-mips.net> References: <3C364FDE.9080008@webley.com> <20020106191256.A2418@dea.linux-mips.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 413 Lines: 10 In message: <20020106191256.A2418@dea.linux-mips.net> Ralf Baechle writes: : We have no information at all about the NEC hardware. As the group that : built NEC's systems does no longer exist reverse engineering seems to be : the only way to ever support NEC systems. There are some Japanese engineers that might know, but they are kind of a rough crowd to break into :-) Warner From owner-linux-mips@oss.sgi.com Sun Jan 6 20:28:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g074Sss26219 for linux-mips-outgoing; Sun, 6 Jan 2002 20:28:54 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g074Sqg26216 for ; Sun, 6 Jan 2002 20:28:52 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g073Sbh30496; Mon, 7 Jan 2002 01:28:37 -0200 Date: Mon, 7 Jan 2002 01:28:37 -0200 From: Ralf Baechle To: "M. Warner Losh" Cc: nharring@webley.com, linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer Message-ID: <20020107012837.A30485@dea.linux-mips.net> References: <3C364FDE.9080008@webley.com> <20020106191256.A2418@dea.linux-mips.net> <20020106.202242.102614262.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020106.202242.102614262.imp@village.org>; from imp@village.org on Sun, Jan 06, 2002 at 08:22:42PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 443 Lines: 12 On Sun, Jan 06, 2002 at 08:22:42PM -0700, M. Warner Losh wrote: > : We have no information at all about the NEC hardware. As the group that > : built NEC's systems does no longer exist reverse engineering seems to be > : the only way to ever support NEC systems. > > There are some Japanese engineers that might know, but they are kind > of a rough crowd to break into :-) Maybe you should talk to them over a crate of Saporro :-) Ralf From owner-linux-mips@oss.sgi.com Sun Jan 6 20:44:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g074iX026541 for linux-mips-outgoing; Sun, 6 Jan 2002 20:44:33 -0800 Received: from rover.village.org (warner@rover.bsdimp.com [204.144.255.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g074iUg26538; Sun, 6 Jan 2002 20:44:30 -0800 Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g073iQl67430; Sun, 6 Jan 2002 20:44:27 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g073iQx23977; Sun, 6 Jan 2002 20:44:26 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 06 Jan 2002 20:44:11 -0700 (MST) Message-Id: <20020106.204411.115981034.imp@village.org> To: ralf@oss.sgi.com Cc: nharring@webley.com, linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer From: "M. Warner Losh" In-Reply-To: <20020107012837.A30485@dea.linux-mips.net> References: <20020106191256.A2418@dea.linux-mips.net> <20020106.202242.102614262.imp@village.org> <20020107012837.A30485@dea.linux-mips.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 498 Lines: 11 In message: <20020107012837.A30485@dea.linux-mips.net> Ralf Baechle writes: : Maybe you should talk to them over a crate of Saporro :-) Next time I go to Japan, I may have to try to do just that :-) Except, they'd likely want some kind of good saki. I know that they are doing NetBSD/arc right now with those machines. I saw one NEC machine for sale at a junk shop in Akihabara last time I was there. Too bad it weighed too much for me to ship it home :-) Warner From owner-linux-mips@oss.sgi.com Sun Jan 6 20:46:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g074kYb26637 for linux-mips-outgoing; Sun, 6 Jan 2002 20:46:34 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g074kVg26634 for ; Sun, 6 Jan 2002 20:46:31 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g073kMX30658; Mon, 7 Jan 2002 01:46:22 -0200 Date: Mon, 7 Jan 2002 01:46:22 -0200 From: Ralf Baechle To: "M. Warner Losh" Cc: nharring@webley.com, linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer Message-ID: <20020107014622.A30647@dea.linux-mips.net> References: <20020106191256.A2418@dea.linux-mips.net> <20020106.202242.102614262.imp@village.org> <20020107012837.A30485@dea.linux-mips.net> <20020106.204411.115981034.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020106.204411.115981034.imp@village.org>; from imp@village.org on Sun, Jan 06, 2002 at 08:44:11PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 469 Lines: 11 On Sun, Jan 06, 2002 at 08:44:11PM -0700, M. Warner Losh wrote: > Next time I go to Japan, I may have to try to do just that :-) > Except, they'd likely want some kind of good saki. I know that they > are doing NetBSD/arc right now with those machines. I saw one NEC > machine for sale at a junk shop in Akihabara last time I was there. > Too bad it weighed too much for me to ship it home :-) I thought shipping sports equipment is free when traveling ;-) Ralf From owner-linux-mips@oss.sgi.com Sun Jan 6 20:49:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g074n3m26738 for linux-mips-outgoing; Sun, 6 Jan 2002 20:49:03 -0800 Received: from rover.village.org (warner@rover.bsdimp.com [204.144.255.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g074n0g26734; Sun, 6 Jan 2002 20:49:00 -0800 Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g073mvl67480; Sun, 6 Jan 2002 20:48:57 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g073mux24046; Sun, 6 Jan 2002 20:48:56 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 06 Jan 2002 20:48:41 -0700 (MST) Message-Id: <20020106.204841.97841971.imp@village.org> To: ralf@oss.sgi.com Cc: nharring@webley.com, linux-mips@oss.sgi.com Subject: Re: Question about SMP NEC RISCServer From: "M. Warner Losh" In-Reply-To: <20020107014622.A30647@dea.linux-mips.net> References: <20020107012837.A30485@dea.linux-mips.net> <20020106.204411.115981034.imp@village.org> <20020107014622.A30647@dea.linux-mips.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 313 Lines: 8 In message: <20020107014622.A30647@dea.linux-mips.net> Ralf Baechle writes: : I thought shipping sports equipment is free when traveling ;-) Well, all the other stuff put me too close to my weight limit. I also couldn't imagine taking it on the subway back to my hotel... Warner From owner-linux-mips@oss.sgi.com Mon Jan 7 02:19:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07AJca31109 for linux-mips-outgoing; Mon, 7 Jan 2002 02:19:38 -0800 Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07AJZg31103 for ; Mon, 7 Jan 2002 02:19:35 -0800 Message-Id: <200201071019.g07AJZg31103@oss.sgi.com> Received: from unknown (HELO tp240) (61.187.62.132) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jan 2002 09:19:32 -0000 Date: Mon, 7 Jan 2002 17:20:25 +0800 From: Wu Qingbo To: "linux-mips@oss.sgi.com" Subject: where can I get cross compiler and glibc for mipsel linux X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 292 Lines: 13 Hi, all, I want to install cross compiler on my X86 linux system for mipsel linux. Where can I get them? And how to install them? Thanks in advance! Qingbo _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Mon Jan 7 09:56:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Hu3m19802 for linux-mips-outgoing; Mon, 7 Jan 2002 09:56:03 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Htvg19798 for ; Mon, 7 Jan 2002 09:55:57 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id EBC47125CB; Mon, 7 Jan 2002 08:55:54 -0800 (PST) Date: Mon, 7 Jan 2002 08:55:54 -0800 From: "H . J . Lu" To: Wu Qingbo Cc: "linux-mips@oss.sgi.com" Subject: Re: where can I get cross compiler and glibc for mipsel linux Message-ID: <20020107085554.B2284@lucon.org> References: <200201071019.g07AJZg31103@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: <200201071019.g07AJZg31103@oss.sgi.com>; from wu_qingbo2000@yahoo.com.cn on Mon, Jan 07, 2002 at 05:20:25PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1293 Lines: 45 On Mon, Jan 07, 2002 at 05:20:25PM +0800, Wu Qingbo wrote: > Hi, all, > > I want to install cross compiler on my X86 linux system for mipsel linux. > Where can I get them? And how to install them? > Thanks in advance! > You can try my RedHat 7.1. H.J. ---- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You may need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 7 11:54:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07JsAx22676 for linux-mips-outgoing; Mon, 7 Jan 2002 11:54:10 -0800 Received: from river-bank.demon.co.uk (river-bank.demon.co.uk [193.237.18.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Js5g22643 for ; Mon, 7 Jan 2002 11:54:06 -0800 Received: from river-bank.demon.co.uk(ratty.river-bank.demon.co.uk[192.168.0.4]) (1654 bytes) by river-bank.demon.co.uk via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 7 Jan 2002 18:54:42 +0000 (GMT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-12) Message-ID: <3C39EE20.57513318@river-bank.demon.co.uk> Date: Mon, 07 Jan 2002 18:51:12 +0000 From: Phil Thompson Organization: At Home X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: How to Handle PCI Bridge Buffers? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1072 Lines: 24 I am working with some hardware that has a "feature" that I'd like some advice on how to handle. The PCI bridge has a read-ahead buffer between the PCI bus and system memory - used by PCI bus masters. The buffer can only be invalidated from software. An example of the problem it causes is an ethernet device is kicked off to go through its ring buffers. The first one has a flag saying there is no data, so it stops. The kernel then puts data in the buffer, toggles the flag, and kicks off the ethernet device again. The old value of the flag is still in the read-ahead buffer so the device stops again. The fix is obviously to invalidate the read-ahead buffer before kicking off the device. The question is, how to do this in a generic way? I don't want to modify the driver for every PCI device that might be used. The only other way seems to be to add the buffer invalidation code to outb() etc. (and hope that no driver wants to use memory mapped registers). Is this "feature" common? Is there existing code I can look at? Suggestions very welcome. Thanks, Phil From owner-linux-mips@oss.sgi.com Mon Jan 7 12:16:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07KGg923488 for linux-mips-outgoing; Mon, 7 Jan 2002 12:16:42 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07KGdg23484 for ; Mon, 7 Jan 2002 12:16:39 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g07JFPB09092; Mon, 7 Jan 2002 11:15:25 -0800 Message-ID: <3C39F401.9B961EA3@mvista.com> Date: Mon, 07 Jan 2002 11:16:17 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Wu Qingbo CC: "linux-mips@oss.sgi.com" Subject: Re: where can I get cross compiler and glibc for mipsel linux References: <200201071019.g07AJZg31103@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 253 Lines: 14 Wu Qingbo wrote: > > Hi, all, > > I want to install cross compiler on my X86 linux system for mipsel linux. > Where can I get them? And how to install them? > Thanks in advance! > See my porting howto at http://linux.junsun.net/porting-howto Jun From owner-linux-mips@oss.sgi.com Mon Jan 7 14:16:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07MGEs27500 for linux-mips-outgoing; Mon, 7 Jan 2002 14:16:14 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07MG7g27491 for ; Mon, 7 Jan 2002 14:16:07 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9AE9F125CB; Mon, 7 Jan 2002 13:16:04 -0800 (PST) Date: Mon, 7 Jan 2002 13:16:04 -0800 From: "H . J . Lu" To: Jakub Jelinek Cc: GNU libc hacker , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: Prelink for mips (Re: MIPS broken in 2.3) Message-ID: <20020107131604.A6383@lucon.org> References: <20011213093958.A6057@lucon.org> <20011217123631.G542@sunsite.ms.mff.cuni.cz> <20011217091032.A29014@lucon.org> <20011217185215.K542@sunsite.ms.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011217185215.K542@sunsite.ms.mff.cuni.cz>; from jakub@redhat.com on Mon, Dec 17, 2001 at 06:52:15PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2560 Lines: 52 On Mon, Dec 17, 2001 at 06:52:15PM +0100, Jakub Jelinek wrote: > On Mon, Dec 17, 2001 at 09:10:32AM -0800, H . J . Lu wrote: > > On Mon, Dec 17, 2001 at 12:36:31PM +0100, Jakub Jelinek wrote: > > > > > instead (well, best would be if somebody ported prelink to mips; > > > I'll try to answer any questions and help). > > > > Do you have some documentations how prelink works? > > So far not too much. Some info is in prelink(8) man page, some info > was posted to binutils mailing list. I have prelink-20011010.tar.bz2. Is that current? > > > > I skipped mips because it is way too different from how any other ELF > > > architecture works (e.g. using a single dynamic reloc type for everything > > > with various meanings, etc.) and I have no access to it. > > > > That is what I am afraid of. The MIPS ABI supports "quickstart". > > I know, but from what I understood, quickstart e.g. just assumes there won't > be conflicts and if there are, their handling is very costly (their > conflicts are just symbol indices which need to be checked out). > prelink conflicts are ElfW(Rela) relocs against r_symndx 0. > > To port prelink to a new architecture, you need basically: > 1) determine what you need to do with relocations and special CPU sections > when relocating a shared library from one address to another one > (e.g. you can link a shared libs once at VMA 0, once at VMA 0xdeadb000 > and see what changed) - these are *_adjust_* functions > 2) write routines which apply relocs (*_prelink_rel*) > 3) write routines which create conflict relocs > 4) as MIPS is rel, it needs to be figured out when it is needed to convert > from Rel to Rela (in i386/arm case in most cases it can be avoided, > the only relocs which require it are (on i386): R_386_32 with nonzero > addend (otherwise R_386_GLOB_DAT does exactly the same thing) and > R_386_PC32). This is needed, because otherwise the information about the > original addend is lost when the final relocated value is stored at > r_offset address. Original addend is needed, if prelink cannot be used, > during dynamic linking. If MIPS has some place where it stashes this > for Quickstart, then it could be reused, otherwise I'm afraid REL->RELA will > happen more often on MIPS than on IA-32/ARM. > 5) write routines which apply relocs to a buffer or apply a conflict > to a buffer (these are used when doing comparisons on relocated content) > As I unsterstand, MIPS only has R_MIPS_REL32 for GOT in DSO and EXE. Do you have any suggestions? H.J. From owner-linux-mips@oss.sgi.com Mon Jan 7 15:16:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07NGvx28868 for linux-mips-outgoing; Mon, 7 Jan 2002 15:16:57 -0800 Received: from spinics.net (IDENT:root@vzn1-22.ce.ftel.net [206.24.95.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07NGsg28863 for ; Mon, 7 Jan 2002 15:16:54 -0800 Received: (from ellis@localhost) by spinics.net (8.11.6/8.11.6) id g07MHrY20022 for linux-mips@oss.sgi.com; Mon, 7 Jan 2002 14:17:53 -0800 From: ellis@spinics.net Message-Id: <200201072217.g07MHrY20022@spinics.net> Subject: Galileo 64240 To: linux-mips@oss.sgi.com Date: Mon, 7 Jan 2002 14:17:53 -0800 (PST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 98 Lines: 3 Is there any support code around for the Galileo 64240? A serial driver would be really nice ;) From owner-linux-mips@oss.sgi.com Mon Jan 7 15:50:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07NoGM04009 for linux-mips-outgoing; Mon, 7 Jan 2002 15:50:16 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07NoCg04002 for ; Mon, 7 Jan 2002 15:50:12 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g07MnxX04725; Mon, 7 Jan 2002 14:49:59 -0800 From: "Matthew Dharm" To: , Subject: RE: Galileo 64240 Date: Mon, 7 Jan 2002 14:49:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200201072217.g07MHrY20022@spinics.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 970 Lines: 28 We've got a 64240-based board that we're going to be porting Linux to... tho we're not using the on-board MPSC ports. I doubt anyone is building a board using the MPSC ports -- it's just too difficult to drive them, and 16550-like parts are too cheap. If you're trying to bring up a 64240-based board under linux, perhaps sharing work would be good? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of ellis@spinics.net > Sent: Monday, January 07, 2002 2:18 PM > To: linux-mips@oss.sgi.com > Subject: Galileo 64240 > > > Is there any support code around for the Galileo 64240? A serial > driver would be really nice ;) > From owner-linux-mips@oss.sgi.com Mon Jan 7 19:30:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g083U1Y18852 for linux-mips-outgoing; Mon, 7 Jan 2002 19:30:01 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g083Tvg18844 for ; Mon, 7 Jan 2002 19:29:57 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4F090125CB; Mon, 7 Jan 2002 18:29:55 -0800 (PST) Date: Mon, 7 Jan 2002 18:29:55 -0800 From: "H . J . Lu" To: Jakub Jelinek Cc: GNU libc hacker , binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com Subject: Re: Prelink for mips (Re: MIPS broken in 2.3) Message-ID: <20020107182955.A11352@lucon.org> References: <20011213093958.A6057@lucon.org> <20011217123631.G542@sunsite.ms.mff.cuni.cz> <20011217091032.A29014@lucon.org> <20011217185215.K542@sunsite.ms.mff.cuni.cz> <20020107131604.A6383@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020107131604.A6383@lucon.org>; from hjl@lucon.org on Mon, Jan 07, 2002 at 01:16:04PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2084 Lines: 37 On Mon, Jan 07, 2002 at 01:16:04PM -0800, H . J . Lu wrote: > > I know, but from what I understood, quickstart e.g. just assumes there won't > > be conflicts and if there are, their handling is very costly (their > > conflicts are just symbol indices which need to be checked out). > > prelink conflicts are ElfW(Rela) relocs against r_symndx 0. > > > > To port prelink to a new architecture, you need basically: > > 1) determine what you need to do with relocations and special CPU sections > > when relocating a shared library from one address to another one > > (e.g. you can link a shared libs once at VMA 0, once at VMA 0xdeadb000 > > and see what changed) - these are *_adjust_* functions > > 2) write routines which apply relocs (*_prelink_rel*) > > 3) write routines which create conflict relocs > > 4) as MIPS is rel, it needs to be figured out when it is needed to convert > > from Rel to Rela (in i386/arm case in most cases it can be avoided, > > the only relocs which require it are (on i386): R_386_32 with nonzero > > addend (otherwise R_386_GLOB_DAT does exactly the same thing) and > > R_386_PC32). This is needed, because otherwise the information about the > > original addend is lost when the final relocated value is stored at > > r_offset address. Original addend is needed, if prelink cannot be used, > > during dynamic linking. If MIPS has some place where it stashes this > > for Quickstart, then it could be reused, otherwise I'm afraid REL->RELA will > > happen more often on MIPS than on IA-32/ARM. > > 5) write routines which apply relocs to a buffer or apply a conflict > > to a buffer (these are used when doing comparisons on relocated content) > > > > As I unsterstand, MIPS only has R_MIPS_REL32 for GOT in DSO and EXE. Do you > have any suggestions? The ld.so relocates R_MIPS_REL32 using GOT which is relocated first by a special rule. There is no relocation information for GOT. Also there is no symbol lookup for relocating R_MIPS_REL32. I am not sure how it will work with the current prelink. H.J. From owner-linux-mips@oss.sgi.com Tue Jan 8 04:13:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08CDGc01671 for linux-mips-outgoing; Tue, 8 Jan 2002 04:13:16 -0800 Received: from oval.algor.co.uk (oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08CCpg01663 for ; Tue, 8 Jan 2002 04:13:00 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g08BCJt09706; Tue, 8 Jan 2002 11:12:19 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id g08BC8a01332; Tue, 8 Jan 2002 11:12:08 GMT From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.54280.707286.147408@gladsmuir.algor.co.uk> Date: Tue, 8 Jan 2002 11:12:08 +0000 (GMT) To: Phil Thompson Cc: linux-mips@oss.sgi.com Subject: Re: How to Handle PCI Bridge Buffers? In-Reply-To: <3C39EE20.57513318@river-bank.demon.co.uk> References: <3C39EE20.57513318@river-bank.demon.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2524 Lines: 54 Phil, > I am working with some hardware that has a "feature" that I'd like some > advice on how to handle. The PCI bridge has a read-ahead buffer between > the PCI bus and system memory - used by PCI bus masters. The buffer can > only be invalidated from software. So it also acts as a cache. Interesting. > An example of the problem it causes is an ethernet device is kicked off > to go through its ring buffers. The first one has a flag saying there is > no data, so it stops. The kernel then puts data in the buffer, toggles > the flag, and kicks off the ethernet device again. The old value of the > flag is still in the read-ahead buffer so the device stops again. The > fix is obviously to invalidate the read-ahead buffer before kicking off > the device. The question is, how to do this in a generic way? This is analogous to the problem you get when accessing device buffers through the MIPS cache; so we know there's no easy fix. You'll have to locate every write made to a shared memory structure, and then invalidate the cache in the bridge. If you're mapping the shared memory cached, that would be just after doing a forced write-back of the CPU cache... but the shared memory is more likely accessed uncached. But as a result of the MIPS cache experience there are a collection of cache-safety buffer functions (rely on a proper Linux expert to tell you about them, sorry). So you can update your driver to call them, then change your local implementation of the functions to invalidate the bridge's cache too. You still have to change all the non-compliant drivers, of course, but at least you have the warm feeling that you're *improving* them. [Just a note: I suppose you've checked you're not accidentally working through a "writeback" CPU cache, which would cause the identical symptom? This feature would cause such routine trouble in a bridge that I'm surprised it isn't at least easy to disable...] > I don't want to modify the driver for every PCI device that might be > used. The only other way seems to be to add the buffer invalidation code > to outb() etc. (and hope that no driver wants to use memory mapped > registers). But lots of drivers use memory mapped registers. x86 I/O space (inb/outb etc) maps to PCI I/O space, the use of which is deprecated except for legacy software. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Jan 8 05:20:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DKBD04553 for linux-mips-outgoing; Tue, 8 Jan 2002 05:20:11 -0800 Received: from emma.patton.com (emma.patton.com [209.49.110.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08DK7g04550 for ; Tue, 8 Jan 2002 05:20:07 -0800 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id HAA15566; Tue, 8 Jan 2002 07:20:09 -0500 (EST) Message-ID: <3C3AE3EE.761CB1CD@patton.com> Date: Tue, 08 Jan 2002 07:19:58 -0500 From: Paul Kasper Reply-To: paul@patton.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: ellis@spinics.net CC: linux-mips@oss.sgi.com Subject: Re: Galileo 64240 References: <200201072217.g07MHrY20022@spinics.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 866 Lines: 22 ellis@spinics.net wrote: > > Is there any support code around for the Galileo 64240? A serial > driver would be really nice ;) I started an MPSC/Uart driver for the 64240/64240A chips. Didn't get much of it working when we got fed up with all of the Galileo errata about which registers could or could not be read at which times and their confusion as to whether or not they were planning to ever fix the errata. We broke down and added a 162550 UART to the board. The driver code was abandoned in the midst of early debugging stages and is in a horrific state. You're welcome to a copy if you really can't find something better. -- /"\ . . . . . . . . . . . . . . . /"\ \ / ASCII Ribbon Campaign \ / Paul R. Kasper X - NO HTML/RTF in e-mail X Patton Electronics Co. / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 From owner-linux-mips@oss.sgi.com Tue Jan 8 05:45:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DjxN05377 for linux-mips-outgoing; Tue, 8 Jan 2002 05:45:59 -0800 Received: from emma.patton.com (emma.patton.com [209.49.110.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Djug05374 for ; Tue, 8 Jan 2002 05:45:56 -0800 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id HAA15849; Tue, 8 Jan 2002 07:46:02 -0500 (EST) Message-ID: <3C3AE9FC.F34C9794@patton.com> Date: Tue, 08 Jan 2002 07:45:48 -0500 From: Paul Kasper Reply-To: paul@patton.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: ellis@spinics.net CC: linux-mips@oss.sgi.com Subject: Re: Galileo 64240 References: <200201072217.g07MHrY20022@spinics.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 583 Lines: 15 ellis@spinics.net wrote: > > Is there any support code around for the Galileo 64240? A serial > driver would be really nice ;) I also have a hacked-up port of MontaVista's HHLinux gt96100eth code that is functional on 64240 and 64240A in little-endian mode and untested in BE. It still lacks support for any "advanced" features of the Galileo chips. -- /"\ . . . . . . . . . . . . . . . /"\ \ / ASCII Ribbon Campaign \ / Paul R. Kasper X - NO HTML/RTF in e-mail X Patton Electronics Co. / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 From owner-linux-mips@oss.sgi.com Tue Jan 8 12:08:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08K86t25885 for linux-mips-outgoing; Tue, 8 Jan 2002 12:08:06 -0800 Received: from ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08K82g25877 for ; Tue, 8 Jan 2002 12:08:03 -0800 Received: from [192.168.1.5] (IDENT:root@localhost.localdomain [127.0.0.1]) by ayrnetworks.com (8.11.6/8.11.2) with ESMTP id g08J5Ne12745 for ; Tue, 8 Jan 2002 11:05:23 -0800 Mime-Version: 1.0 X-Sender: kph@127.0.0.1 Message-Id: Date: Tue, 8 Jan 2002 11:07:53 -0800 To: linux-mips@oss.sgi.com From: Kevin Paul Herbert Subject: Support for physical memory above 0x20000000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 887 Lines: 20 I'm working with a somewhat dated kernel (2.4.2+patches) and have discovered that there are problems with physical memory that does not map into KSEG0/KSEG1. I looked over the list archives (manually, I couldn't find a search interface) and it appears that this is still the case for current kernels (at least as of a note from last summer, the last time the issue seems to have come up.) Obviously, phys_to_virt() is going to be a problem but besides this I'm wondering what anybody may have done to support physical memory that is not always mapped into the virtual address space, so that I don't have to reinvent the wheel. When I tell the kernel about the memory above 0x20000000, userland fails to start; the kernel gets as far as execve()'ing init, but nothing happens (interrupts are enabled; I get echo on the console, but nothing from userland). Thanks, Kevin -- From owner-linux-mips@oss.sgi.com Tue Jan 8 12:50:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08KohT26805 for linux-mips-outgoing; Tue, 8 Jan 2002 12:50:43 -0800 Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Koeg26802 for ; Tue, 8 Jan 2002 12:50:40 -0800 Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id UAA17869 for ; Tue, 8 Jan 2002 20:49:54 +0100 (CET) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl4.philips.com via mwrap (4.0a) id xma017867; Tue, 8 Jan 02 20:49:55 +0100 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id UAA16912 for ; Tue, 8 Jan 2002 20:50:35 +0100 (MET) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA18788 for ; Tue, 8 Jan 2002 13:50:33 -0600 (CST) Subject: keyboard config with serial console To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 8 Jan 2002 11:51:24 -0800 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 08/01/2002 13:54:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 661 Lines: 24 Hello, I'm trying to boot linux 2.4.3 on mips core. I'm using a ttyS0 device (uart com 1) as my serial console. I get a shell prompt but not able to do anything after that because of my keyboard drivers not configured. Itseems that in order to configure keyboard drivers one should define CONSOLE_VT. I just have a serial uart and I dont know if I can use a CONFIG_SERIAL and CONFIG_SERIAL_CONSOLE and still configure my keyboard. I think many keyboard function calls are linked with the virtual terminal related files. Is it possible to configure the keyboard drivers with a serial console? Have anyone tried this before? Please advice regards, Balaji From owner-linux-mips@oss.sgi.com Tue Jan 8 12:52:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Kq3a26870 for linux-mips-outgoing; Tue, 8 Jan 2002 12:52:03 -0800 Received: from river-bank.demon.co.uk (river-bank.demon.co.uk [193.237.18.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Kppg26840 for ; Tue, 8 Jan 2002 12:51:51 -0800 Received: from river-bank.demon.co.uk(ratty.river-bank.demon.co.uk[192.168.0.4]) (3242 bytes) by river-bank.demon.co.uk via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 8 Jan 2002 19:52:22 +0000 (GMT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-12) Message-ID: <3C3B4D1E.2E0C1DDD@river-bank.demon.co.uk> Date: Tue, 08 Jan 2002 19:48:46 +0000 From: Phil Thompson Organization: At Home X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Sweetman CC: linux-mips@oss.sgi.com Subject: Re: How to Handle PCI Bridge Buffers? References: <3C39EE20.57513318@river-bank.demon.co.uk> <15418.54280.707286.147408@gladsmuir.algor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2493 Lines: 54 Dominic Sweetman wrote: > > Phil, > > > I am working with some hardware that has a "feature" that I'd like some > > advice on how to handle. The PCI bridge has a read-ahead buffer between > > the PCI bus and system memory - used by PCI bus masters. The buffer can > > only be invalidated from software. > > So it also acts as a cache. Interesting. > > > An example of the problem it causes is an ethernet device is kicked off > > to go through its ring buffers. The first one has a flag saying there is > > no data, so it stops. The kernel then puts data in the buffer, toggles > > the flag, and kicks off the ethernet device again. The old value of the > > flag is still in the read-ahead buffer so the device stops again. The > > fix is obviously to invalidate the read-ahead buffer before kicking off > > the device. The question is, how to do this in a generic way? > > This is analogous to the problem you get when accessing device buffers > through the MIPS cache; so we know there's no easy fix. You'll have > to locate every write made to a shared memory structure, and then > invalidate the cache in the bridge. If you're mapping the shared > memory cached, that would be just after doing a forced write-back of > the CPU cache... but the shared memory is more likely accessed > uncached. > > But as a result of the MIPS cache experience there are a collection of > cache-safety buffer functions (rely on a proper Linux expert to tell > you about them, sorry). So you can update your driver to call them, > then change your local implementation of the functions to invalidate > the bridge's cache too. You still have to change all the > non-compliant drivers, of course, but at least you have the warm > feeling that you're *improving* them. > > [Just a note: I suppose you've checked you're not accidentally working > through a "writeback" CPU cache, which would cause the identical > symptom? This feature would cause such routine trouble > in a bridge that I'm surprised it isn't at least easy to disable...] It's definately in the bridge. > > I don't want to modify the driver for every PCI device that might be > > used. The only other way seems to be to add the buffer invalidation code > > to outb() etc. (and hope that no driver wants to use memory mapped > > registers). > > But lots of drivers use memory mapped registers. x86 I/O space > (inb/outb etc) maps to PCI I/O space, the use of which is deprecated > except for legacy software. Oh dear! Phil From owner-linux-mips@oss.sgi.com Tue Jan 8 12:56:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08KuB227035 for linux-mips-outgoing; Tue, 8 Jan 2002 12:56:11 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Ku8g27032 for ; Tue, 8 Jan 2002 12:56:08 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g08Jtxn4027134; Tue, 8 Jan 2002 11:56:00 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g08Jtv4A027125; Tue, 8 Jan 2002 11:55:58 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 8 Jan 2002 11:55:55 -0800 (PST) From: James Simmons To: balaji.ramalingam@philips.com cc: linux-mips@oss.sgi.com Subject: Re: keyboard config with serial console In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 792 Lines: 27 > Itseems that in order to configure keyboard drivers one should define > CONSOLE_VT. Correct. With the standard tree you need CONSOLE_VT. > I just have a serial uart and I dont know if I can use a > CONFIG_SERIAL and CONFIG_SERIAL_CONSOLE and still > configure my keyboard. You can use serial tty/console along side a VT console. > I think many keyboard function calls are linked with the virtual terminal > related files. Is it possible to configure the keyboard drivers with a > serial console? I know it is possible to use a keyboard without a VT via the input layer. I reworked the console system for 2.5.X so you can use a keybaord without a VT. I'm slowly intergrating this now into the dave jones tree. > Have anyone tried this before? Yes. http://linuxconsole.sf.net From owner-linux-mips@oss.sgi.com Tue Jan 8 14:28:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08MSrQ02118 for linux-mips-outgoing; Tue, 8 Jan 2002 14:28:53 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08MSmg02115 for ; Tue, 8 Jan 2002 14:28:48 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g08LSdX09496; Tue, 8 Jan 2002 13:28:40 -0800 From: "Matthew Dharm" To: , Cc: Subject: RE: Galileo 64240 Date: Tue, 8 Jan 2002 13:28:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C3AE9FC.F34C9794@patton.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1232 Lines: 38 I would love a copy of that, personally. Could you send it to me (or the list)? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Paul Kasper > Sent: Tuesday, January 08, 2002 4:46 AM > To: ellis@spinics.net > Cc: linux-mips@oss.sgi.com > Subject: Re: Galileo 64240 > > > ellis@spinics.net wrote: > > > > Is there any support code around for the Galileo 64240? A serial > > driver would be really nice ;) > > I also have a hacked-up port of MontaVista's HHLinux gt96100eth code > that is functional on 64240 and 64240A in little-endian mode and > untested in BE. It still lacks support for any "advanced" > features of > the Galileo chips. > > -- > /"\ . . . . . . . . . . . . . . . /"\ > \ / ASCII Ribbon Campaign \ / Paul R. Kasper > X - NO HTML/RTF in e-mail X Patton Electronics Co. > / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 > From owner-linux-mips@oss.sgi.com Tue Jan 8 15:21:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08NLok04648 for linux-mips-outgoing; Tue, 8 Jan 2002 15:21:50 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g08NLkg04645 for ; Tue, 8 Jan 2002 15:21:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g08MLJ722305; Tue, 8 Jan 2002 20:21:19 -0200 Date: Tue, 8 Jan 2002 20:21:19 -0200 From: Ralf Baechle To: Kevin Paul Herbert Cc: linux-mips@oss.sgi.com Subject: Re: Support for physical memory above 0x20000000 Message-ID: <20020108202119.B21992@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kph@ayrnetworks.com on Tue, Jan 08, 2002 at 11:07:53AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1260 Lines: 25 On Tue, Jan 08, 2002 at 11:07:53AM -0800, Kevin Paul Herbert wrote: > I'm working with a somewhat dated kernel (2.4.2+patches) and have > discovered that there are problems with physical memory that does not > map into KSEG0/KSEG1. I looked over the list archives (manually, I > couldn't find a search interface) and it appears that this is still > the case for current kernels (at least as of a note from last summer, > the last time the issue seems to have come up.) > > Obviously, phys_to_virt() is going to be a problem but besides this > I'm wondering what anybody may have done to support physical memory > that is not always mapped into the virtual address space, so that I > don't have to reinvent the wheel. > > When I tell the kernel about the memory above 0x20000000, userland > fails to start; the kernel gets as far as execve()'ing init, but > nothing happens (interrupts are enabled; I get echo on the console, > but nothing from userland). Correct. There are two ways to solve this problem. For the 32-bit kernel I've got a highmem patch and the 64-bit kernel memory limits are the hardware's memory limits. I'll post the highmem patch soon. I was planning to have it ready by now but a flu sent me to bed instead ... Ralf From owner-linux-mips@oss.sgi.com Tue Jan 8 16:03:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0903kA05706 for linux-mips-outgoing; Tue, 8 Jan 2002 16:03:46 -0800 Received: from spinics.net (IDENT:root@vzn1-22.ce.ftel.net [206.24.95.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0903gg05702 for ; Tue, 8 Jan 2002 16:03:42 -0800 Received: (from ellis@localhost) by spinics.net (8.11.6/8.11.6) id g08N4eA29568 for linux-mips@oss.sgi.com; Tue, 8 Jan 2002 15:04:40 -0800 From: ellis@spinics.net Message-Id: <200201082304.g08N4eA29568@spinics.net> Subject: Re: Galileo 64240 To: linux-mips@oss.sgi.com Date: Tue, 8 Jan 2002 15:04:40 -0800 (PST) In-Reply-To: from "Paul Kasper" at Jan 08, 2002 07:19:58 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 856 Lines: 23 >>Is there any support code around for the Galileo 64240? A >>serial driver would be really nice ;) >I started an MPSC/Uart driver for the 64240/64240A chips. Didn't >get much of it working when we got fed up with all of the >Galileo errata about which registers could or could not be read >at which times and their confusion as to whether or not they >were planning to ever fix the errata. >We broke down and added a 162550 UART to the board. I really wish that option was available. ;) >The driver code was abandoned in the midst of early debugging >stages and is in a horrific state. You're welcome to a copy if >you really can't find something better. It looks like we have something that works for our in-house (non-linux) OS. I guess I'll use that code as an example and see if I can get a real driver working. -- http://www.spinics.net/linux/ From owner-linux-mips@oss.sgi.com Tue Jan 8 18:48:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g092m0W12444 for linux-mips-outgoing; Tue, 8 Jan 2002 18:48:00 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g092lug12441; Tue, 8 Jan 2002 18:47:56 -0800 Received: from h11752a ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GPNE8I00.B3V; Wed, 9 Jan 2002 09:45:54 +0800 Message-ID: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> From: "machael thailer" To: Cc: "Ralf Baechle" Subject: limited Memory question... Date: Wed, 9 Jan 2002 09:43:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g092lvg12442 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 230 Lines: 6 Hello, all: I have a question to need you help. Our MIPS-based custom board has only 8M memory.When I want to insmod a 24M module, it often panics and says "out of memory...". How can I solve this? Thank you. machael thailer From owner-linux-mips@oss.sgi.com Tue Jan 8 18:55:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g092t1m12575 for linux-mips-outgoing; Tue, 8 Jan 2002 18:55:01 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g092svg12566; Tue, 8 Jan 2002 18:54:57 -0800 Received: from brinquedo.distro.conectiva (3-115.ctame701-2.telepar.net.br [200.181.171.115]) by netbank.com.br (Postfix) with ESMTP id 190354680E; Tue, 8 Jan 2002 23:51:04 -0200 (BRDT) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id 59BD3C487; Tue, 8 Jan 2002 23:51:29 -0200 (BRST) Date: Tue, 8 Jan 2002 23:51:29 -0200 From: Arnaldo Carvalho de Melo To: "machael thailer" Cc: , "Ralf Baechle" Subject: Re: limited Memory question... Message-ID: <20020109015128.GB23506@conectiva.com.br> References: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> User-Agent: Mutt/1.3.25i X-Url: http://advogato.org/person/acme Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 390 Lines: 10 Em Wed, Jan 09, 2002 at 09:43:59AM +0800, machael thailer escreveu: > I have a question to need you help. Our MIPS-based custom board has only > 8M memory.When I want to insmod a 24M module, it often panics and says > "out of memory...". a kernel module? 24MiB? ouch, if that is the case, the only way is to get more memory for your board, as kernel memory is not swappable... - Arnaldo From owner-linux-mips@oss.sgi.com Tue Jan 8 19:43:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093hG913500 for linux-mips-outgoing; Tue, 8 Jan 2002 19:43:16 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093hEg13497 for ; Tue, 8 Jan 2002 19:43:14 -0800 Received: from h11752a ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GPNGSO00.44Y; Wed, 9 Jan 2002 10:41:12 +0800 Message-ID: <000f01c198b6$d627ffe0$9b6e0b0a@huawei.com> From: "machael thailer" To: "Arnaldo Carvalho de Melo" Cc: References: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> <20020109015128.GB23506@conectiva.com.br> Subject: Re: limited Memory question... Date: Wed, 9 Jan 2002 10:39:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g093hFg13498 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 454 Lines: 11 > > I have a question to need you help. Our MIPS-based custom board has only > > 8M memory.When I want to insmod a 24M module, it often panics and says > > "out of memory...". > > a kernel module? 24MiB? ouch, if that is the case, the only way is to get > more memory for your board, as kernel memory is not swappable... Yes, it is a kernel module. But unfortunately, the memory is fixed on our board and we cannot add more memory. Any other ideas? From owner-linux-mips@oss.sgi.com Tue Jan 8 19:48:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093mEf14769 for linux-mips-outgoing; Tue, 8 Jan 2002 19:48:14 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093m9g14766 for ; Tue, 8 Jan 2002 19:48:09 -0800 Received: from brinquedo.distro.conectiva (3-115.ctame701-2.telepar.net.br [200.181.171.115]) by netbank.com.br (Postfix) with ESMTP id 52E2746821; Wed, 9 Jan 2002 00:44:16 -0200 (BRDT) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id 062D4C487; Wed, 9 Jan 2002 00:44:43 -0200 (BRST) Date: Wed, 9 Jan 2002 00:44:43 -0200 From: Arnaldo Carvalho de Melo To: "machael thailer" Cc: Subject: Re: limited Memory question... Message-ID: <20020109024443.GD23506@conectiva.com.br> References: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> <20020109015128.GB23506@conectiva.com.br> <000f01c198b6$d627ffe0$9b6e0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c198b6$d627ffe0$9b6e0b0a@huawei.com> User-Agent: Mutt/1.3.25i X-Url: http://advogato.org/person/acme Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1015 Lines: 21 Em Wed, Jan 09, 2002 at 10:39:18AM +0800, machael thailer escreveu: > > > I have a question to need you help. Our MIPS-based custom board has only > > > 8M memory.When I want to insmod a 24M module, it often panics and says > > > "out of memory...". > > > > a kernel module? 24MiB? ouch, if that is the case, the only way is to get > > more memory for your board, as kernel memory is not swappable... > > Yes, it is a kernel module. > But unfortunately, the memory is fixed on our board and we cannot add more memory. > Any other ideas? What does this module does that takes so much memory? One possible idea akpm talked about was to reduce NR_CPUS to the number of CPUs in your eval board if that is something relevant to the reason why your module takes so much memory, does it have a firmware linked? If so, don't link it and load it from userspace, block by block, if this is possible, etc, other than these suggestions one could only give more ideas if the source code is available for review. - Arnaldo From owner-linux-mips@oss.sgi.com Tue Jan 8 20:02:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0942I215941 for linux-mips-outgoing; Tue, 8 Jan 2002 20:02:18 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0942Dg15919; Tue, 8 Jan 2002 20:02:13 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16O9BM-0008W9-00; Wed, 09 Jan 2002 03:13:40 +0000 Subject: Re: limited Memory question... To: dony.he@huawei.com (machael thailer) Date: Wed, 9 Jan 2002 03:13:40 +0000 (GMT) Cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com (Ralf Baechle) In-Reply-To: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> from "machael thailer" at Jan 09, 2002 09:43:59 AM 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 250 Lines: 6 > I have a question to need you help. Our MIPS-based custom board has only > 8M memory.When I want to insmod a 24M module, it often panics and says "out > of memory...". > How can I solve this? Stop the module using 24Mb of unpageable memory ? From owner-linux-mips@oss.sgi.com Tue Jan 8 20:06:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0946On16190 for linux-mips-outgoing; Tue, 8 Jan 2002 20:06:24 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0946Jg16187 for ; Tue, 8 Jan 2002 20:06:19 -0800 Received: from h11752a ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GPNHV500.15P; Wed, 9 Jan 2002 11:04:17 +0800 Message-ID: <001b01c198ba$0fc82b00$9b6e0b0a@huawei.com> From: "machael thailer" To: "Arnaldo Carvalho de Melo" Cc: References: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> <20020109015128.GB23506@conectiva.com.br> <000f01c198b6$d627ffe0$9b6e0b0a@huawei.com> <20020109024443.GD23506@conectiva.com.br> Subject: Re: limited Memory question... Date: Wed, 9 Jan 2002 11:02:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0946Kg16188 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1117 Lines: 26 > Em Wed, Jan 09, 2002 at 10:39:18AM +0800, machael thailer escreveu: > > > > I have a question to need you help. Our MIPS-based custom board has only > > > > 8M memory.When I want to insmod a 24M module, it often panics and says > > > > "out of memory...". > > > > > > a kernel module? 24MiB? ouch, if that is the case, the only way is to get > > > more memory for your board, as kernel memory is not swappable... > > > > Yes, it is a kernel module. > > But unfortunately, the memory is fixed on our board and we cannot add more memory. > > Any other ideas? > > What does this module does that takes so much memory? One possible idea > akpm talked about was to reduce NR_CPUS to the number of CPUs in your eval > board if that is something relevant to the reason why your module takes so > much memory, does it have a firmware linked? If so, don't link it and load > it from userspace, block by block, if this is possible, etc, other than > these suggestions one could only give more ideas if the source code is > available for review. 24M is the size of the module, not the memory that it takes. machael. From owner-linux-mips@oss.sgi.com Tue Jan 8 20:09:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09497n16283 for linux-mips-outgoing; Tue, 8 Jan 2002 20:09:07 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0948vg16279 for ; Tue, 8 Jan 2002 20:08:58 -0800 Received: from brinquedo.distro.conectiva (3-115.ctame701-2.telepar.net.br [200.181.171.115]) by netbank.com.br (Postfix) with ESMTP id CA05446827; Wed, 9 Jan 2002 01:05:04 -0200 (BRDT) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id A5233C487; Wed, 9 Jan 2002 01:05:31 -0200 (BRST) Date: Wed, 9 Jan 2002 01:05:30 -0200 From: Arnaldo Carvalho de Melo To: "machael thailer" Cc: Subject: Re: limited Memory question... Message-ID: <20020109030530.GE23506@conectiva.com.br> References: <003301c198af$1c0d0a80$9b6e0b0a@huawei.com> <20020109015128.GB23506@conectiva.com.br> <000f01c198b6$d627ffe0$9b6e0b0a@huawei.com> <20020109024443.GD23506@conectiva.com.br> <001b01c198ba$0fc82b00$9b6e0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01c198ba$0fc82b00$9b6e0b0a@huawei.com> User-Agent: Mutt/1.3.25i X-Url: http://advogato.org/person/acme Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1275 Lines: 31 Em Wed, Jan 09, 2002 at 11:02:23AM +0800, machael thailer escreveu: > > > Em Wed, Jan 09, 2002 at 10:39:18AM +0800, machael thailer escreveu: > > > > > I have a question to need you help. Our MIPS-based custom board has only > > > > > 8M memory.When I want to insmod a 24M module, it often panics and says > > > > > "out of memory...". > > > > > > > > a kernel module? 24MiB? ouch, if that is the case, the only way is to get > > > > more memory for your board, as kernel memory is not swappable... > > > > > > Yes, it is a kernel module. > > > But unfortunately, the memory is fixed on our board and we cannot add more memory. > > > Any other ideas? > > > > What does this module does that takes so much memory? One possible idea > > akpm talked about was to reduce NR_CPUS to the number of CPUs in your eval > > board if that is something relevant to the reason why your module takes so > > much memory, does it have a firmware linked? If so, don't link it and load > > it from userspace, block by block, if this is possible, etc, other than > > these suggestions one could only give more ideas if the source code is > > available for review. > > 24M is the size of the module, not the memory that it takes. what is the output of: size your_module.o ? - Arnaldo From owner-linux-mips@oss.sgi.com Tue Jan 8 20:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g094HLM16600 for linux-mips-outgoing; Tue, 8 Jan 2002 20:17:21 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g094HIg16596 for ; Tue, 8 Jan 2002 20:17:18 -0800 Received: from h11752a ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GPNIDG00.O7K; Wed, 9 Jan 2002 11:15:16 +0800 Message-ID: <004101c198bb$988a6ec0$9b6e0b0a@huawei.com> From: "machael thailer" To: "Alan Cox" Cc: , "Arnaldo Carvalho de Melo" References: Subject: Re: limited Memory question... Date: Wed, 9 Jan 2002 11:13:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g094HJg16597 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 495 Lines: 16 > > I have a question to need you help. Our MIPS-based custom board has only > > 8M memory.When I want to insmod a 24M module, it often panics and says "out > > of memory...". > > How can I solve this? > > Stop the module using 24Mb of unpageable memory ? Sorry , I think I didn't describe my questions clearly before. "24M" contains some debugging information. I compile it using "-g". code+data sections is only about 7.4M. Can you describe your solutions in more details? machael. From owner-linux-mips@oss.sgi.com Tue Jan 8 21:42:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g095gEj17779 for linux-mips-outgoing; Tue, 8 Jan 2002 21:42:14 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g095gAg17776 for ; Tue, 8 Jan 2002 21:42:10 -0800 Received: (qmail 19625 invoked from network); 9 Jan 2002 04:42:07 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 9 Jan 2002 04:42:07 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16OAYr-0002eH-00; Tue, 08 Jan 2002 21:42:02 -0700 Date: Tue, 8 Jan 2002 21:42:01 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: Phil Thompson cc: linux-mips@oss.sgi.com Subject: Re: How to Handle PCI Bridge Buffers? In-Reply-To: <3C39EE20.57513318@river-bank.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 878 Lines: 25 On Mon, 7 Jan 2002, Phil Thompson wrote: > I am working with some hardware that has a "feature" that I'd like some > advice on how to handle. The PCI bridge has a read-ahead buffer between > the PCI bus and system memory - used by PCI bus masters. The buffer can > only be invalidated from software. Geeze best put 'pci bridge' in quotes too, that's totally not allowed by the PCI bridge spec. Delayed transactions and any data that the bridge may prefetch have very specific lifetimes. Hardware that does what you describe is very much non conforming.. Are you sure of what you are seeing? > Is this "feature" common? Is there existing code I can look at? No - it's a bug not a feature :> The best you can do is have any write to a PCI io/memory space from the CPU clear the prefetch buffer, and hope you don't hit any of the other anomolies that can show up. Jason From owner-linux-mips@oss.sgi.com Tue Jan 8 23:24:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g097ORv19528 for linux-mips-outgoing; Tue, 8 Jan 2002 23:24:27 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g097OPg19525 for ; Tue, 8 Jan 2002 23:24:25 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g096P5c17933 for ; Tue, 8 Jan 2002 22:25:05 -0800 Date: Tue, 8 Jan 2002 22:25:05 -0800 (PST) From: Venkata Rajesh Bikkina To: linux-mips@oss.sgi.com Subject: GDB for MIPS 79S334A Board Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 248 Lines: 10 Hi All, Anybody is using GDB on MIPS 79S334A boards. Please give me some hook from where i can get pre-compiled GDB binaries. I don't have "rpm" binary on my MIPS target to install any rpm file Where can i get this? Thanks in advance, --Rajesh From owner-linux-mips@oss.sgi.com Wed Jan 9 00:08:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0988tv20664 for linux-mips-outgoing; Wed, 9 Jan 2002 00:08:55 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0988pg20661 for ; Wed, 9 Jan 2002 00:08:51 -0800 Received: (qmail 16931 invoked from network); 9 Jan 2002 07:08:48 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 9 Jan 2002 07:08:48 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16OCqt-0003qe-00 for ; Wed, 09 Jan 2002 00:08:47 -0700 Date: Wed, 9 Jan 2002 00:08:47 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: linux-mips@oss.sgi.com Subject: Q about ST0_UX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 984 Lines: 32 Hi All, I just noticed that in setup.c there is this little bit: s = read_32bit_cp0_register(CP0_STATUS); s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_KX|ST0_SX|ST0_FR); s |= ST0_CU0; write_32bit_cp0_register(CP0_STATUS, s); And it doesn't mask off ST0_UX - is this an oversight? With my RM7K the kernel is called with ST0_UX set, and since it doesn't clear it the XTLB handler is called - which faults things.. So, would this patch be appropriate in general: --- setup.c 2001/12/02 11:34:38 1.96 +++ setup.c 2002/01/09 08:05:43 @@ -558,7 +558,7 @@ /* Disable coprocessors and set FPU for 16 FPRs */ s = read_32bit_cp0_register(CP0_STATUS); - s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_KX|ST0_SX|ST0_FR); + s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_UX|ST0_KX|ST0_SX|ST0_FR); s |= ST0_CU0; write_32bit_cp0_register(CP0_STATUS, s); or is it better to make the xtlb handler work in the 32 bit case? Thanks, Jason From owner-linux-mips@oss.sgi.com Wed Jan 9 04:16:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09CGip02299 for linux-mips-outgoing; Wed, 9 Jan 2002 04:16:44 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09CGgg02295 for ; Wed, 9 Jan 2002 04:16:42 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g09BHLk21033 for ; Wed, 9 Jan 2002 03:17:21 -0800 Date: Wed, 9 Jan 2002 03:17:21 -0800 (PST) From: Venkata Rajesh Bikkina To: linux-mips@oss.sgi.com Subject: Unresolved symbols while inserting a module Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 275 Lines: 12 Hi All, when i am trying to insert my kernel module or any sample test module on MIPS 334A board with kernel 2.4.3, insmod is saying _gp_disp unresolved. Can anybody point out what i am missing. /sbin/insmod igateway.o insmod: unresolved symbol _gp_disp Thanks, --Rajesh From owner-linux-mips@oss.sgi.com Wed Jan 9 04:31:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09CVEm03681 for linux-mips-outgoing; Wed, 9 Jan 2002 04:31:14 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g09CV7g03678 for ; Wed, 9 Jan 2002 04:31:08 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g09BUeX01772; Wed, 9 Jan 2002 09:30:40 -0200 Date: Wed, 9 Jan 2002 09:30:40 -0200 From: Ralf Baechle To: Jason Gunthorpe Cc: linux-mips@oss.sgi.com Subject: Re: Q about ST0_UX Message-ID: <20020109093039.A1468@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgg@debian.org on Wed, Jan 09, 2002 at 12:08:47AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1350 Lines: 35 On Wed, Jan 09, 2002 at 12:08:47AM -0700, Jason Gunthorpe wrote: > I just noticed that in setup.c there is this little bit: > > s = read_32bit_cp0_register(CP0_STATUS); > s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_KX|ST0_SX|ST0_FR); > s |= ST0_CU0; > write_32bit_cp0_register(CP0_STATUS, s); > > And it doesn't mask off ST0_UX - is this an oversight? With my RM7K the > kernel is called with ST0_UX set, and since it doesn't clear it the XTLB > handler is called - which faults things.. On all firmware I've made the 32-bit kernel run on it is invoked with UX cleared so I just didn't bother to clear it myself. > So, would this patch be appropriate in general: > > --- setup.c 2001/12/02 11:34:38 1.96 > +++ setup.c 2002/01/09 08:05:43 > @@ -558,7 +558,7 @@ > > /* Disable coprocessors and set FPU for 16 FPRs */ > s = read_32bit_cp0_register(CP0_STATUS); > - s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_KX|ST0_SX|ST0_FR); > + s &= ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_UX|ST0_KX|ST0_SX|ST0_FR); > s |= ST0_CU0; > write_32bit_cp0_register(CP0_STATUS, s); > > or is it better to make the xtlb handler work in the 32 bit case? No, your patch is the right thing. Enabeling UX would also permit the use of 64-bit instructions and that wouldn't work on the 32-bit kernel. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 9 04:35:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09CZnB03779 for linux-mips-outgoing; Wed, 9 Jan 2002 04:35:49 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g09CZig03775 for ; Wed, 9 Jan 2002 04:35:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g09BZKR01813; Wed, 9 Jan 2002 09:35:20 -0200 Date: Wed, 9 Jan 2002 09:35:20 -0200 From: Ralf Baechle To: machael thailer Cc: Alan Cox , linux-mips@oss.sgi.com, Arnaldo Carvalho de Melo Subject: Re: limited Memory question... Message-ID: <20020109093519.B1468@dea.linux-mips.net> References: <004101c198bb$988a6ec0$9b6e0b0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004101c198bb$988a6ec0$9b6e0b0a@huawei.com>; from dony.he@huawei.com on Wed, Jan 09, 2002 at 11:13:22AM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 546 Lines: 16 On Wed, Jan 09, 2002 at 11:13:22AM +0800, machael thailer wrote: > "24M" contains some debugging information. I compile it using "-g". > code+data sections is only about 7.4M. > > Can you describe your solutions in more details? No way to load such a module into such little memory. The only possible solution is to drastically rewrite your module and move everything possible into a userspace process. For userspace processes swapping is possible ... Ralf -- "Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill. From owner-linux-mips@oss.sgi.com Wed Jan 9 10:54:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09Is6w11725 for linux-mips-outgoing; Wed, 9 Jan 2002 10:54:06 -0800 Received: from emma.patton.com (emma.patton.com [209.49.110.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09Irxg11722 for ; Wed, 9 Jan 2002 10:54:00 -0800 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id MAA09071; Wed, 9 Jan 2002 12:54:00 -0500 (EST) Message-ID: <3C3C8370.2B1F1C54@patton.com> Date: Wed, 09 Jan 2002 12:52:48 -0500 From: Paul Kasper Reply-To: paul@patton.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dharm CC: ellis@spinics.net, linux-mips@oss.sgi.com Subject: Re: Galileo 64240 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2164 Lines: 56 Matthew Dharm wrote: > > I would love a copy of that, personally. Could you send it to me (or > the list)? > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > > I also have a hacked-up port of MontaVista's HHLinux gt96100eth code > > that is functional on 64240 and 64240A in little-endian mode and > > untested in BE. It still lacks support for any "advanced" > > features of > > the Galileo chips. > > > > -- > > /"\ . . . . . . . . . . . . . . . /"\ > > \ / ASCII Ribbon Campaign \ / Paul R. Kasper > > X - NO HTML/RTF in e-mail X Patton Electronics Co. > > / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 > > Matt: I'll zip up a copy of the gt64240eth driver as soon as I can track down the relvant include files, and send it to you. I should mention that I'm still running it on a 2.4.0-test9 kernel. Maybe after you verify that it is complete, we can post it to the list. Our board configuration is a QED RM5261A with GT64240A, Intel Flash, STK1744 RTC/NVRAM, 16C2550 DUART, and a bunch of Conexant HDLC I/O -- not all of which is coded yet. I do have the basic arch/mips/patton/{generic,dsl3224} board support trees which were based on mips/atlas and ev96100 ports but, unfortunately, I still reference some Galileo/VxWorks sample code in the interrupt handler. This needs to be cleaned up. I originally used their code only because I did not have a working 64240 board to test with and the Galileo datasheets are so ambiguous that I thought that their sample code programmers might have had some hidden insight into the chips. I since have learned that the opposite is true and need to clean all of that stuff out. -- Paul K. -- /"\ . . . . . . . . . . . . . . . /"\ \ / ASCII Ribbon Campaign \ / Paul R. Kasper X - NO HTML/RTF in e-mail X Patton Electronics Co. / \ - NO MSWord docs in e-mail / \ 301-975-1000 x173 From owner-linux-mips@oss.sgi.com Wed Jan 9 11:03:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09J3CQ12013 for linux-mips-outgoing; Wed, 9 Jan 2002 11:03:12 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g09J31g11998 for ; Wed, 9 Jan 2002 11:03:03 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g09I2a821833; Wed, 9 Jan 2002 16:02:36 -0200 Date: Wed, 9 Jan 2002 16:02:36 -0200 From: Ralf Baechle To: Venkata Rajesh Bikkina Cc: linux-mips@oss.sgi.com Subject: Re: Unresolved symbols while inserting a module Message-ID: <20020109160236.A21705@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rajeshbv@intotoinc.com on Wed, Jan 09, 2002 at 03:17:21AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 386 Lines: 12 On Wed, Jan 09, 2002 at 03:17:21AM -0800, Venkata Rajesh Bikkina wrote: > when i am trying to insert my kernel module or any sample test module on > MIPS 334A board with kernel 2.4.3, insmod is saying _gp_disp unresolved. > Can anybody point out what i am missing. > > /sbin/insmod igateway.o > insmod: unresolved symbol _gp_disp See http://oss.sgi.com/mips/mips-howto.html. Ralf From owner-linux-mips@oss.sgi.com Wed Jan 9 18:16:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A2G9q24713 for linux-mips-outgoing; Wed, 9 Jan 2002 18:16:09 -0800 Received: from gw-nl5.philips.com (gw-nl5.philips.com [212.153.235.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A2G5g24710 for ; Wed, 9 Jan 2002 18:16:06 -0800 Received: from smtpscan-nl2.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id CAA17555 for ; Thu, 10 Jan 2002 02:16:01 +0100 (MET) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-nl2.philips.com(130.139.36.22) by gw-nl5.philips.com via mwrap (4.0a) id xma017553; Thu, 10 Jan 02 02:16:01 +0100 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id CAA05105 for ; Thu, 10 Jan 2002 02:16:00 +0100 (MET) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA01583 for ; Wed, 9 Jan 2002 19:15:58 -0600 (CST) Subject: linux on keyboardless system To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 9 Jan 2002 17:16:52 -0800 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 09/01/2002 19:19:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 471 Lines: 16 Hello, I'm tried booting linux 2.4.3 on my prototype system which does not have a keyboard and a monitor. I used the uart as my serial device and passed on the console=ttyS0(com1 in my pc) to the kernel. I can see the shell prompt after the kernel bootup but not able to enter anything after that. So how can I use my pc keyboard to send characters to my uart? I think I'm missing something here. Can anyone give me some hint? Thankyou in advance... regards, Balaji From owner-linux-mips@oss.sgi.com Wed Jan 9 21:19:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A5JHg28921 for linux-mips-outgoing; Wed, 9 Jan 2002 21:19:17 -0800 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A5JGg28918 for ; Wed, 9 Jan 2002 21:19:16 -0800 Received: from [10.2.2.67] ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPP00LGZG00R0@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Wed, 09 Jan 2002 20:19:14 -0800 (PST) Date: Wed, 09 Jan 2002 20:16:52 -0800 From: Pete Popov Subject: Re: Galileo 64240 In-reply-to: <3C3C8370.2B1F1C54@patton.com> To: paul@patton.com Cc: Matthew Dharm , ellis@spinics.net, linux-mips Message-id: <1010636216.1221.0.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution/1.0 (Preview Release) Content-type: text/plain Content-transfer-encoding: 7bit References: <3C3C8370.2B1F1C54@patton.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 444 Lines: 10 The GT64260 is the PPC equivalent of the mips 64240. I'm pretty sure our PPC guys did some work with the 64260 and they might have one of the serial ports working as a simple uart. Check the community PPC tree. If you don't find anything there, post to the ppc mailing list to see what people have done with the 64260. Pretty much everything should be portable to the 64240 and you might get feedback on hardware bugs and workarounds. Pete From owner-linux-mips@oss.sgi.com Thu Jan 10 00:16:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A8Gvs00931 for linux-mips-outgoing; Thu, 10 Jan 2002 00:16:57 -0800 Received: from cast-ext.ab.videon.ca (cast-ext.ab.videon.ca [206.75.216.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A8Grg00928 for ; Thu, 10 Jan 2002 00:16:53 -0800 Received: (qmail 21762 invoked from network); 10 Jan 2002 07:16:50 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by cast-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 07:16:50 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16OZSE-0004Xz-00 for ; Thu, 10 Jan 2002 00:16:50 -0700 Date: Thu, 10 Jan 2002 00:16:50 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: linux-mips Subject: initrd breaks with exactly 512M of ram Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1046 Lines: 34 I realize this is a very unique situation, but the initrd code breaks with exactly 512M of RAM mapped from 0 to 512M: Determined physical RAM map: memory: 20000000 @ 00000000 (usable) Initial ramdisk at: 0x8023a000 (629389 bytes) initrd extends beyond end of memory (0x802d3a8d > 0x80000000) Here is a little patch - instead of converting the PFN to a physical address it converts the initrd_end to a PFN. Thanks, Jason Index: setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96 diff -u -r1.96 setup.c --- setup.c 2001/12/02 11:34:38 1.96 +++ setup.c 2002/01/10 08:01:18 @@ -921,7 +928,7 @@ printk("Initial ramdisk at: 0x%p (%lu bytes)\n", (void *)initrd_start, initrd_size); - if ((void *)initrd_end > phys_to_virt(PFN_PHYS(max_low_pfn))) { + if (PFN_UP(__pa(initrd_end)) >= max_low_pfn) { printk("initrd extends beyond end of memory " "(0x%lx > 0x%p)\ndisabling initrd\n", initrd_end, From owner-linux-mips@oss.sgi.com Thu Jan 10 05:24:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ADO1X09323 for linux-mips-outgoing; Thu, 10 Jan 2002 05:24:01 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ADNvg09318 for ; Thu, 10 Jan 2002 05:23:58 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA10185; Thu, 10 Jan 2002 13:23:51 +0100 (MET) Date: Thu, 10 Jan 2002 13:23:50 +0100 (MET) From: "Maciej W. Rozycki" To: balaji.ramalingam@philips.com cc: linux-mips@oss.sgi.com Subject: Re: linux on keyboardless system In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 702 Lines: 15 On Wed, 9 Jan 2002 balaji.ramalingam@philips.com wrote: > I'm tried booting linux 2.4.3 on my prototype system which does not have > a keyboard and a monitor. I used the uart as my serial device and passed on > the console=ttyS0(com1 in my pc) to the kernel. I can see the shell prompt after the kernel > bootup but not able to enter anything after that. Assuming that you have handshaking and modem control set up correctly, do you have the CREAD tty flag set for your console device after boot? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 10 06:30:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AEUSR11238 for linux-mips-outgoing; Thu, 10 Jan 2002 06:30:28 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AEUMg11235 for ; Thu, 10 Jan 2002 06:30:22 -0800 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 08:30:13 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2195B0E@ATLOPS> From: Marc Karasek To: "'balaji.ramalingam@philips.com'" , linux-mips@oss.sgi.com Subject: RE: linux on keyboardless system Date: Thu, 10 Jan 2002 08:30:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 858 Lines: 28 What are you using for init? Is it busybox by chance. If so there was a bug in a past version that would cause this. It had to do with not setting CREAD properly I believe. -----Original Message----- From: balaji.ramalingam@philips.com [mailto:balaji.ramalingam@philips.com] Sent: Wednesday, January 09, 2002 8:17 PM To: linux-mips@oss.sgi.com Subject: linux on keyboardless system Hello, I'm tried booting linux 2.4.3 on my prototype system which does not have a keyboard and a monitor. I used the uart as my serial device and passed on the console=ttyS0(com1 in my pc) to the kernel. I can see the shell prompt after the kernel bootup but not able to enter anything after that. So how can I use my pc keyboard to send characters to my uart? I think I'm missing something here. Can anyone give me some hint? Thankyou in advance... regards, Balaji From owner-linux-mips@oss.sgi.com Thu Jan 10 10:41:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AIfmR18703 for linux-mips-outgoing; Thu, 10 Jan 2002 10:41:48 -0800 Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AIfbg18697 for ; Thu, 10 Jan 2002 10:41:37 -0800 Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0AHfWk10368; Thu, 10 Jan 2002 18:41:32 +0100 (MET) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0AHfV210364; Thu, 10 Jan 2002 18:41:32 +0100 (MET) Received: from esk.fhg.de (host4-40 [192.168.4.40]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id SAA06303; Thu, 10 Jan 2002 18:41:30 +0100 (MET) Message-ID: <3C3DD208.45B5BC29@esk.fhg.de> Date: Thu, 10 Jan 2002 18:40:24 +0100 From: Wolfgang Heidrich Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: ppopov@pacbell.net Subject: usb-problems with Au1000 References: <3B7DA3A3.8010000@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2796 Lines: 77 Hello, I have following configuration: - mips-Au1000-processor (PB1000-board from Alchemy-Semiconductor) - _no_ USB-devices connected - linux from the Montavista-Tree (downloaded in December from www.alchemysemi.com)(Kernel "2.4.2_hhl20") - prebuilt crosscompiler from Montavista (downloaded in December from www.alchemysemi.com) During booting the kernel initalizes the usb-device-driver and a little later prints "USB device not accepting new address...": >>>> usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26 usb-ohci.c: usb-builtin, non-PCI OHCI usb.c: new USB bus registered, assigned bus number 1 Product: USB OHCI Root Hub SerialNumber: b0100000 hub.c: USB hub found hub.c: 2 ports detected usb-ohci.c: v5.2 Roman Weissgaerber , David Brownell usb-ohci.c: USB OHCI Host Controller Driver usb.c: registered new driver hid mice: PS/2 mouse device common for all mice 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 192.168.65.17, my address is 192.168.65.240 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Serial driver version 1.01 (2001-02-08) with no serial options enabled ttyS00 at 0xb1100000 (irq = 0) is a 16550 ttyS01 at 0xb1200000 (irq = 1) is a 16550 ttyS02 at 0xb1300000 (irq = 2) is a 16550 ttyS03 at 0xb1400000 (irq = 3) is a 16550 Looking up port of RPC 100003/2 on 192.168.65.17 Looking up port of RPC 100005/2 on 192.168.65.17 hub.c: USB new device connect on bus1/1, assigned device number 2 usb.c: USB device not accepting new address=2 (error=-145) <---------???? VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 64k freed Algorithmics/MIPS FPU Emulator v1.5a hub.c: USB new device connect on bus1/1, assigned device number 3 usb.c: USB device not accepting new address=3 (error=-145) <---------???? <<<< I wonder what I could have done wrong. The switches on the board are set accordingly the Montavista-faq.txt. I could verify these settings with the schematics of the board. After booting, when I plug in an USB-device, the same error messages are repeated. As far as I know USB should work with this kernel. So maybe this is a hardware failure ? I reduced the CPU-frequency from 396MHz to 120MHz, but this didn't help, too. The same messages appear, when I plug the device in the other USB-connector on the board. It's no problem with the power, because I could verify that there are 5Volt on the USB-connector. Probably someone already knows the solution, because this is not a special configuration. Thanks in advance -- Wolfgang From owner-linux-mips@oss.sgi.com Thu Jan 10 10:46:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AIkkI18825 for linux-mips-outgoing; Thu, 10 Jan 2002 10:46:46 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AIkag18821 for ; Thu, 10 Jan 2002 10:46:36 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0AHjSB28708; Thu, 10 Jan 2002 09:45:28 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Wolfgang Heidrich Cc: linux-mips In-Reply-To: <3C3DD208.45B5BC29@esk.fhg.de> References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 09:49:06 -0800 Message-Id: <1010684946.29315.82.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3293 Lines: 93 On Thu, 2002-01-10 at 09:40, Wolfgang Heidrich wrote: > Hello, > > I have following configuration: > > - mips-Au1000-processor (PB1000-board from Alchemy-Semiconductor) > - _no_ USB-devices connected > - linux from the Montavista-Tree (downloaded in December from > www.alchemysemi.com)(Kernel "2.4.2_hhl20") > - prebuilt crosscompiler from Montavista (downloaded in December from > www.alchemysemi.com) > > During booting the kernel initalizes the usb-device-driver and > a little later prints "USB device not accepting new address...": Which LSP version do you have? Do an "rpm -qa | grep hhl- | grep lsp". There was a hardware errata in the usb controller, but a software fix is already in the kernel (assuming you have a late enough kernel). Also, the usb switches, S4, should be set to: 1-4 off 5-6 on 7-8 off Pete > >>>> > usb.c: registered new driver usbdevfs > usb.c: registered new driver hub > usb-ohci.c: USB OHCI at membase 0xb0100000, IRQ 26 > usb-ohci.c: usb-builtin, non-PCI OHCI > usb.c: new USB bus registered, assigned bus number 1 > Product: USB OHCI Root Hub > SerialNumber: b0100000 > hub.c: USB hub found > hub.c: 2 ports detected > usb-ohci.c: v5.2 Roman Weissgaerber , David Brownell > usb-ohci.c: USB OHCI Host Controller Driver > usb.c: registered new driver hid > mice: PS/2 mouse device common for all mice > 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 192.168.65.17, my address is > 192.168.65.240 > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Serial driver version 1.01 (2001-02-08) with no serial options enabled > ttyS00 at 0xb1100000 (irq = 0) is a 16550 > ttyS01 at 0xb1200000 (irq = 1) is a 16550 > ttyS02 at 0xb1300000 (irq = 2) is a 16550 > ttyS03 at 0xb1400000 (irq = 3) is a 16550 > Looking up port of RPC 100003/2 on 192.168.65.17 > Looking up port of RPC 100005/2 on 192.168.65.17 > hub.c: USB new device connect on bus1/1, assigned device number 2 > usb.c: USB device not accepting new address=2 (error=-145) > <---------???? > VFS: Mounted root (nfs filesystem) readonly. > Freeing unused kernel memory: 64k freed > Algorithmics/MIPS FPU Emulator v1.5a > hub.c: USB new device connect on bus1/1, assigned device number 3 > usb.c: USB device not accepting new address=3 (error=-145) > <---------???? > <<<< > > I wonder what I could have done wrong. The switches on the board > are set accordingly the Montavista-faq.txt. I could verify these > settings > with the schematics of the board. > After booting, when I plug in an USB-device, the same error messages > are repeated. > > As far as I know USB should work with this kernel. So maybe this > is a hardware failure ? I reduced the CPU-frequency from 396MHz to > 120MHz, > but this didn't help, too. The same messages appear, when I plug the > device > in the other USB-connector on the board. It's no problem with the power, > because I could verify that there are 5Volt on the USB-connector. > > Probably someone already knows the solution, because this is not a > special > configuration. > > Thanks in advance > > -- > Wolfgang From owner-linux-mips@oss.sgi.com Thu Jan 10 11:03:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJ3Eq19219 for linux-mips-outgoing; Thu, 10 Jan 2002 11:03:14 -0800 Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJ38g19206 for ; Thu, 10 Jan 2002 11:03:08 -0800 Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA28227; Thu, 10 Jan 2002 12:02:31 -0600 (CST) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma028224; Thu, 10 Jan 02 12:02:31 -0600 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA09913; Thu, 10 Jan 2002 12:02:30 -0600 (CST) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA00661; Thu, 10 Jan 2002 12:02:29 -0600 (CST) Subject: Re: linux on keyboardless system To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 10 Jan 2002 10:03:22 -0800 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 10/01/2002 12:06:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1914 Lines: 38 Thanks for the reply. Yes I have the CREAD flag set in my uart drivers. (in the function rs_init() in serial.c). "Maciej W. Rozycki" To: Balaji Ramalingam/SVL/SC/PHILIPS@AMEC Subject: Re: linux on keyboardless system 01/10/02 Classification: 04:23 AM On Wed, 9 Jan 2002 balaji.ramalingam@philips.com wrote: > I'm tried booting linux 2.4.3 on my prototype system which does not have > a keyboard and a monitor. I used the uart as my serial device and passed on > the console=ttyS0(com1 in my pc) to the kernel. I can see the shell prompt after the kernel > bootup but not able to enter anything after that. Assuming that you have handshaking and modem control set up correctly, do you have the CREAD tty flag set for your console device after boot? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 10 11:05:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJ5rT19291 for linux-mips-outgoing; Thu, 10 Jan 2002 11:05:53 -0800 Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJ5kg19288 for ; Thu, 10 Jan 2002 11:05:46 -0800 Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA29387; Thu, 10 Jan 2002 12:05:33 -0600 (CST) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma029385; Thu, 10 Jan 02 12:05:34 -0600 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA11005; Thu, 10 Jan 2002 12:05:33 -0600 (CST) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA01456; Thu, 10 Jan 2002 12:05:32 -0600 (CST) Subject: RE: linux on keyboardless system To: Marc Karasek Cc: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 10 Jan 2002 10:06:25 -0800 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 10/01/2002 12:09:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2248 Lines: 60 Thanks for you reply Marc I 'm not using busybox I tried both init (with /etc/inittab , /etc/fstab ...) and also replacing init with /bin/sh. In both the cases I was able to get the shell prompt. But not able to enter anything after that. regards, Balaji Marc Karasek linux-mips@oss.sgi.com cc: 01/10/02 05:30 Subject: RE: linux on keyboardless system AM Classification: What are you using for init? Is it busybox by chance. If so there was a bug in a past version that would cause this. It had to do with not setting CREAD properly I believe. -----Original Message----- From: balaji.ramalingam@philips.com [mailto:balaji.ramalingam@philips.com] Sent: Wednesday, January 09, 2002 8:17 PM To: linux-mips@oss.sgi.com Subject: linux on keyboardless system Hello, I'm tried booting linux 2.4.3 on my prototype system which does not have a keyboard and a monitor. I used the uart as my serial device and passed on the console=ttyS0(com1 in my pc) to the kernel. I can see the shell prompt after the kernel bootup but not able to enter anything after that. So how can I use my pc keyboard to send characters to my uart? I think I'm missing something here. Can anyone give me some hint? Thankyou in advance... regards, Balaji From owner-linux-mips@oss.sgi.com Thu Jan 10 11:49:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJnWE21593 for linux-mips-outgoing; Thu, 10 Jan 2002 11:49:32 -0800 Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJnRg21590 for ; Thu, 10 Jan 2002 11:49:28 -0800 Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0AInOb16893; Thu, 10 Jan 2002 19:49:24 +0100 (MET) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0AInN216886; Thu, 10 Jan 2002 19:49:23 +0100 (MET) Received: from esk.fhg.de (host4-40 [192.168.4.40]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id TAA07175; Thu, 10 Jan 2002 19:49:21 +0100 (MET) Message-ID: <3C3DE1F0.F45307FB@esk.fhg.de> Date: Thu, 10 Jan 2002 19:48:16 +0100 From: Wolfgang Heidrich Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: linux-mips CC: Pete Popov Subject: Re: usb-problems with Au1000 References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1010684946.29315.82.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 793 Lines: 31 Hello Pete, Pete Popov wrote: > > On Thu, 2002-01-10 at 09:40, Wolfgang Heidrich wrote: > > Hello, > > > > During booting the kernel initalizes the usb-device-driver and > > a little later prints "USB device not accepting new address...": > > Which LSP version do you have? Do an "rpm -qa | grep hhl- | grep lsp". hhl-cross-mips_fp_le-lsp-mips-malta-2.4.2_hhl20-hhl2.0.2 hhl-cross-mips_fp_le-lsp-alchemy-pb1000-2.4.2_hhl20-hhl2.0.2 > > There was a hardware errata in the usb controller, but a software fix is > already in the kernel (assuming you have a late enough kernel). Also, > the usb switches, S4, should be set to: > > 1-4 off > 5-6 on > 7-8 off I used these settings. But as far as I know these settings are only relevant for the second USB. Thanks in advance -- Wolfgang From owner-linux-mips@oss.sgi.com Thu Jan 10 11:58:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJwR821824 for linux-mips-outgoing; Thu, 10 Jan 2002 11:58:27 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJwNg21821 for ; Thu, 10 Jan 2002 11:58:23 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0AIvAB00713; Thu, 10 Jan 2002 10:57:10 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Wolfgang Heidrich Cc: linux-mips In-Reply-To: <3C3DE1F0.F45307FB@esk.fhg.de> References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1010684946.29315.82.camel@zeus> <3C3DE1F0.F45307FB@esk.fhg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 11:00:48 -0800 Message-Id: <1010689248.12706.109.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1065 Lines: 39 On Thu, 2002-01-10 at 10:48, Wolfgang Heidrich wrote: > Hello Pete, > > Pete Popov wrote: > > > > On Thu, 2002-01-10 at 09:40, Wolfgang Heidrich wrote: > > > Hello, > > > > > > > During booting the kernel initalizes the usb-device-driver and > > > a little later prints "USB device not accepting new address...": > > > > Which LSP version do you have? Do an "rpm -qa | grep hhl- | grep lsp". > > hhl-cross-mips_fp_le-lsp-mips-malta-2.4.2_hhl20-hhl2.0.2 > hhl-cross-mips_fp_le-lsp-alchemy-pb1000-2.4.2_hhl20-hhl2.0.2 That LSP is old. Get the _hhl20_hhl2.0.3 release. Alchemy should have it on their ftp site by now. Let me know if you still have problems with 2.0.3. Pete > > There was a hardware errata in the usb controller, but a software fix is > > already in the kernel (assuming you have a late enough kernel). Also, > > the usb switches, S4, should be set to: > > > > 1-4 off > > 5-6 on > > 7-8 off > > I used these settings. But as far as I know these settings are only > relevant for the second USB. > > Thanks in advance > -- > Wolfgang From owner-linux-mips@oss.sgi.com Thu Jan 10 12:59:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AKx5723105 for linux-mips-outgoing; Thu, 10 Jan 2002 12:59:05 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AKx2g23102 for ; Thu, 10 Jan 2002 12:59:02 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA23409; Thu, 10 Jan 2002 20:59:09 +0100 (MET) Date: Thu, 10 Jan 2002 20:59:08 +0100 (MET) From: "Maciej W. Rozycki" To: balaji.ramalingam@philips.com cc: linux-mips@oss.sgi.com Subject: Re: linux on keyboardless system In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 477 Lines: 13 On Thu, 10 Jan 2002 balaji.ramalingam@philips.com wrote: > Yes I have the CREAD flag set in my uart drivers. (in the function > rs_init() in serial.c). Check handshaking and modem lines then -- if CLOCAL and CRTSCTS of your terminal system reflect your connection setup. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 10 16:49:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B0nFm03081 for linux-mips-outgoing; Thu, 10 Jan 2002 16:49:15 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B0n9g03046 for ; Thu, 10 Jan 2002 16:49:09 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 4E7AE842; Fri, 11 Jan 2002 00:48:56 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 4474E3F3F; Fri, 11 Jan 2002 00:49:03 +0100 (CET) Date: Fri, 11 Jan 2002 00:49:03 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: LTP tests / Crash :) Message-ID: <20020110234903.GA10021@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1281 Lines: 51 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i am just trying to run the LTP (Linux Test Project -> ltp.sf.net)=20 on a 2.4.16 SGI/Indy and it seems to crash reproducable :) <<>> tag=3Dgetpeername01 stime=3D1010706641 cmdline=3D"getpeername01" contacts=3D"" analysis=3Dexit initiation_status=3D"ok" <<>> On 2 different machines - Running both 2.4.16 Debian/Sid and Debian/Woody - I will try to gather the oops - But it seems we should take the LTP for regular regression tests :) Crashes are: Kernel unaligned instruction access in unaligned.c:do_ade, line 397 and Unhandled kernel unaligned access in unaligned.c:emulate_load_store_isns, l= ine 342 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --X1bOJ3K7DJ5YkBrT 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 iD8DBQE8PihvUaz2rXW+gJcRAtn5AJ9l7VzQ9wi3rHXgbRLnp6TGxkkW3gCeIgTF Cqf0yQfwWbm4CWjWo1TKpJs= =wSCI -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-linux-mips@oss.sgi.com Thu Jan 10 17:16:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B1GkZ03767 for linux-mips-outgoing; Thu, 10 Jan 2002 17:16:46 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B1Gfg03764 for ; Thu, 10 Jan 2002 17:16:41 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id ACC07842; Fri, 11 Jan 2002 01:16:28 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5328B3F3F; Fri, 11 Jan 2002 01:16:28 +0100 (CET) Date: Fri, 11 Jan 2002 01:16:28 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Re: LTP tests / Crash :) Message-ID: <20020111001628.GD10021@paradigm.rfc822.org> References: <20020110234903.GA10021@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EY/WZ/HvNxOox07X" Content-Disposition: inline In-Reply-To: <20020110234903.GA10021@paradigm.rfc822.org> User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1185 Lines: 42 --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 11, 2002 at 12:49:03AM +0100, Florian Lohoff wrote: > On 2 different machines - Running both 2.4.16 Debian/Sid and > Debian/Woody - I will try to gather the oops - But it seems we should > take the LTP for regular regression tests :) >=20 > Crashes are: >=20 > Kernel unaligned instruction access in unaligned.c:do_ade, line 397 >=20 > and >=20 > Unhandled kernel unaligned access in unaligned.c:emulate_load_store_isns,= line 342 It seems those are fixed in the current 2.4 cvs with the unaligned.c fixes which went in lately ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --EY/WZ/HvNxOox07X 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 iD8DBQE8Pi7cUaz2rXW+gJcRAizeAKC0x9hwzuGYSBAA1CgUp1yHNUJ6IgCff0HH DQwygpp8SsuN4VLjQfwwgxE= =dImj -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From owner-linux-mips@oss.sgi.com Thu Jan 10 18:01:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B21eB04782 for linux-mips-outgoing; Thu, 10 Jan 2002 18:01:40 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B21Wg04779 for ; Thu, 10 Jan 2002 18:01:32 -0800 Message-Id: <200201110201.g0B21Wg04779@oss.sgi.com> Received: (qmail 16542 invoked from network); 11 Jan 2002 00:57:44 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 11 Jan 2002 00:57:44 -0000 Date: Fri, 11 Jan 2002 8:58:15 +0800 From: Zhang Fuxin To: Florian Lohoff CC: "linux-mips@oss.sgi.com" Subject: Re: LTP tests / Crash :) X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0B21Yg04780 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1415 Lines: 51 hi,Florian Lohoff£¬ i have noticed that a while ago and send ralf and fix,he make his own fix in current cvs. My ltp runs turns out a number of failures,the one worry me most are the filesystem corrupts(mmap write?),but i had no time to follow them currently. ÔÚ 2002-01-11 00:49:00 you wrote£º >Hi, >i am just trying to run the LTP (Linux Test Project -> ltp.sf.net) >on a 2.4.16 SGI/Indy and it seems to crash reproducable :) > ><<>> >tag=getpeername01 stime=1010706641 >cmdline="getpeername01" >contacts="" >analysis=exit >initiation_status="ok" ><<>> > >On 2 different machines - Running both 2.4.16 Debian/Sid and >Debian/Woody - I will try to gather the oops - But it seems we should >take the LTP for regular regression tests :) > >Crashes are: > >Kernel unaligned instruction access in unaligned.c:do_ade, line 397 > >and > >Unhandled kernel unaligned access in unaligned.c:emulate_load_store_isns, line 342 > >Flo >-- >Florian Lohoff flo@rfc822.org +49-5201-669912 >Nine nineth on september the 9th Welcome to the new billenium >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: For info see http://www.gnupg.org > >iD8DBQE8PihvUaz2rXW+gJcRAtn5AJ9l7VzQ9wi3rHXgbRLnp6TGxkkW3gCeIgTF >Cqf0yQfwWbm4CWjWo1TKpJs= >=wSCI >-----END PGP SIGNATURE----- Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Thu Jan 10 18:53:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B2rPD05670 for linux-mips-outgoing; Thu, 10 Jan 2002 18:53:25 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B2rLg05667; Thu, 10 Jan 2002 18:53:21 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0B1qEB22905; Thu, 10 Jan 2002 17:52:14 -0800 Message-ID: <3C3E458A.B2AEC3CA@mvista.com> Date: Thu, 10 Jan 2002 17:53:14 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: [PATCH] disable interrupt for non-LLSC atomic set Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 429 Lines: 11 The current MIPS_ATOMIC set code for no-LLSC case does a load and store with interrupt open. This is potentially dangerous as an interrupt could happen in-between and cause the value changed inside the interrupt handler. Therefore the load/store is not atomic anymore. Does the following patch look good to fix that? http://linux.junsun.net/patches/oss.sgi.com/submitted/020110.disable-intr-for-nollsc-atomic-set.patch Jun From owner-linux-mips@oss.sgi.com Thu Jan 10 18:56:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B2uFm05818 for linux-mips-outgoing; Thu, 10 Jan 2002 18:56:15 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B2u8g05811 for ; Thu, 10 Jan 2002 18:56:08 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id DC48B7FB; Fri, 11 Jan 2002 02:55:55 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 61F633F3F; Fri, 11 Jan 2002 02:55:55 +0100 (CET) Date: Fri, 11 Jan 2002 02:55:55 +0100 From: Florian Lohoff To: Zhang Fuxin Cc: "linux-mips @ oss. sgi. com" Subject: Re: LTP tests / Crash :) Message-ID: <20020111015555.GB18469@paradigm.rfc822.org> References: <20020111010058.EB5C47FB@noose.gt.owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20020111010058.EB5C47FB@noose.gt.owl.de> User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2003 Lines: 62 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 11, 2002 at 08:58:15AM +0800, Zhang Fuxin wrote: > hi,Florian Lohoff?? Flo shortform :) > i have noticed that a while ago and send ralf and fix,he > make his own fix in current cvs. The current cvs is stable for me :) > My ltp runs turns out a number of failures,the one worry me > most are the filesystem corrupts(mmap write?),but i had no time > to follow them currently. Havent seen those yet - This sounds like cache issues or probably disk controller stuff - I am not running plain cvs - I am running with some r4k cache wback/inv modifications i tried in connection with my sgiwd93.c cleanup/fix. Most annoying i guess is the still not perfect fpu emulation which also causes the "sleep" bug where sleeps sometime return after 22 years (strace output) as there are fpu problems within librt=20 And at least i know of one real-world app which had problems with=20 message passing/shared memory - The Xfree server garbles xbitmaps within the server in shared segments - The happens with Gnome on XFree 4 on the Indy. shmat01 2 FAIL : shared memory address is not correct shmdt02 1 FAIL : call succeeded unexpectedly These are also interesting: fcntl05 1 BROK : Unexpected signal 15 received. pipe05 1 BROK : Unexpected signal 11 received. sched_getscheduler01 1 BROK : Unexpected signal 11 received. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --aM3YZ0Iwxop3KEKx 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 iD8DBQE8PkYrUaz2rXW+gJcRAjdVAJ9myTkOJVMs2NVXvo8KXpw1AG4d+gCgyX99 bLVzfbYc0/Yp+0zwsgMQ29A= =ODWy -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-linux-mips@oss.sgi.com Thu Jan 10 19:14:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B3EbR06192 for linux-mips-outgoing; Thu, 10 Jan 2002 19:14:37 -0800 Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B3EZg06188 for ; Thu, 10 Jan 2002 19:14:35 -0800 Received: (qmail 14423 invoked by uid 104); 11 Jan 2002 02:14:27 -0000 Received: from Manoj_Ekbote@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4180. . Clean. Processed in 0.448729 secs); 11 Jan 2002 02:14:27 -0000 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 11 Jan 2002 02:14:27 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g0B2EQm22411 for ; Thu, 10 Jan 2002 18:14:26 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 18:14:26 -0800 Message-ID: From: Manoj Ekbote To: "'linux-mips@oss.sgi.com'" Subject: sdram remapped to non-zero address Date: Thu, 10 Jan 2002 18:13:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 561 Lines: 13 Hi, I got the latest kernel off the cvs tree and am running it on a board(CPU- RM5710) whose physical address has been remapped to 0x8000000, the virtual address being 0xa8000000. The kernel fails while trying to allocate memory for the initbootmem map table. In the setup_arch() routine of arch/mips/kernel/setup.c, the "start_pfn" variable gets a greater value than "max_pfn" before the call to init_bootmem(). I have done relevant changes to the call to add_memory_region() routine in arch/mips/alpine/setup.c. CONFIG_BLK_DEV_INITRD is not set. Manoj From owner-linux-mips@oss.sgi.com Fri Jan 11 03:54:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BBswL17040 for linux-mips-outgoing; Fri, 11 Jan 2002 03:54:58 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BBskg17036; Fri, 11 Jan 2002 03:54:46 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA12487; Fri, 11 Jan 2002 11:54:26 +0100 (MET) Date: Fri, 11 Jan 2002 11:54:24 +0100 (MET) From: "Maciej W. Rozycki" To: Jun Sun cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] disable interrupt for non-LLSC atomic set In-Reply-To: <3C3E458A.B2AEC3CA@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 553 Lines: 14 On Thu, 10 Jan 2002, Jun Sun wrote: > The current MIPS_ATOMIC set code for no-LLSC case does a load and store with > interrupt open. This is potentially dangerous as an interrupt could happen > in-between and cause the value changed inside the interrupt handler. No need to -- no sane interrupt handler will ever access a user's atomic variable. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 11 10:24:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BIOhX28557 for linux-mips-outgoing; Fri, 11 Jan 2002 10:24:43 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BIObg28554; Fri, 11 Jan 2002 10:24:37 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id JAA10178; Fri, 11 Jan 2002 09:23:46 -0800 Date: Fri, 11 Jan 2002 09:23:46 -0800 From: Jun Sun To: "Maciej W. Rozycki" Cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] disable interrupt for non-LLSC atomic set Message-ID: <20020111092346.C32345@mvista.com> References: <3C3E458A.B2AEC3CA@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Jan 11, 2002 at 11:54:24AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 623 Lines: 16 On Fri, Jan 11, 2002 at 11:54:24AM +0100, Maciej W. Rozycki wrote: > On Thu, 10 Jan 2002, Jun Sun wrote: > > > The current MIPS_ATOMIC set code for no-LLSC case does a load and store with > > interrupt open. This is potentially dangerous as an interrupt could happen > > in-between and cause the value changed inside the interrupt handler. > > No need to -- no sane interrupt handler will ever access a user's atomic > variable. > OK, I have to reveal the secret desire :-). I have a patch that makes MIPS kernel preemptible, and that unprotected operation becomes very volunerable with the preemptible patch. Jun From owner-linux-mips@oss.sgi.com Fri Jan 11 10:41:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BIf4F28755 for linux-mips-outgoing; Fri, 11 Jan 2002 10:41:04 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BIerg28749; Fri, 11 Jan 2002 10:40:57 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA23341; Fri, 11 Jan 2002 18:40:07 +0100 (MET) Date: Fri, 11 Jan 2002 18:40:07 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] disable interrupt for non-LLSC atomic set In-Reply-To: <20020111092346.C32345@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 686 Lines: 18 On Fri, 11 Jan 2002, Jun Sun wrote: > > No need to -- no sane interrupt handler will ever access a user's atomic > > variable. > > OK, I have to reveal the secret desire :-). I have a patch > that makes MIPS kernel preemptible, and that unprotected operation > becomes very volunerable with the preemptible patch. I see. But why not to keep the MIPS_ATOMIC update together with the patch then? It doesn't look like such a patch is going into the official kernel anytime soon. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 11 12:52:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BKqLs31186 for linux-mips-outgoing; Fri, 11 Jan 2002 12:52:21 -0800 Received: from mailhost.taec.toshiba.com (mailhost.taec.com [209.243.128.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BKqEg31181 for ; Fri, 11 Jan 2002 12:52:14 -0800 Received: from hdqmta.taec.com (hdqmta [209.243.180.59]) by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id LAA03237 for ; Fri, 11 Jan 2002 11:52:05 -0800 (PST) Subject: libtool warning on redhat 7.1 native mipsel compile To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Adrian.Hulse@taec.toshiba.com Date: Fri, 11 Jan 2002 11:53:42 -0800 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.8 |June 18, 2001) at 01/11/2002 11:51:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2027 Lines: 56 I have come across many libtool warnings when native compiling redhat 7.1 packages on my mips board. An example warning is : *** Warning: This library needs some functionality provided by -lc *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. So I ran file on libc-2.2.4.so, and it gave me the following output : /lib/libc-2.2.4.so: ELF 32-bit LSB mips-1 shared object, MIPS R3000_LE [bfd bug], version 1 (SYSV), not stripped Which I believe is telling me the library is shared. A search on the web revealed some passed problems with file and libtool, but going by my libtool's version number I should be OK. To cut a long story short I traced the problem to a number of script files which define a string to be : ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib) When this is used as a match against libc-2.2.4.so's output the "mips-1" part causes a mismatch and libtool complains the library is not a shared library file. Note, as far as I have checked most of the library files in the redhat 7.1 distribution include this "mips-1". As dirty fix I hand hacked all occurences of ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib) and changed them to ELF [0-9][0-9]*-bit [LM]SB mips-1 (shared object | dynamic lib) and sure enough all but one of the libtool warnings went away. The only one reamining was directed towards linking against libgcc, which is an archive so I'll let that one go. Not understanding the workings of everything, my simple analysis of this problem is that : "if file did not output "mips-1" the problem would not exist". Does anyone know why mips-1 is there ? Should it be there because it has the potential to break a lot of scripts out there. Does anyone know how to fix either the libraries or the program "file" so that "mips-1" is not output. Any help on this will be greatly appreciated TIA From owner-linux-mips@oss.sgi.com Fri Jan 11 12:56:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BKumL31347 for linux-mips-outgoing; Fri, 11 Jan 2002 12:56:48 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BKukg31344 for ; Fri, 11 Jan 2002 12:56:46 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 92349125CB; Fri, 11 Jan 2002 11:56:43 -0800 (PST) Date: Fri, 11 Jan 2002 11:56:43 -0800 From: "H . J . Lu" To: Adrian.Hulse@taec.toshiba.com Cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020111115643.A28700@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Adrian.Hulse@taec.toshiba.com on Fri, Jan 11, 2002 at 11:53:42AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 544 Lines: 17 On Fri, Jan 11, 2002 at 11:53:42AM -0800, Adrian.Hulse@taec.toshiba.com wrote: > > I have come across many libtool warnings when native compiling redhat 7.1 > packages on my mips board. > > An example warning is : > > *** Warning: This library needs some functionality provided by -lc > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > Does that cause any problems? H.J. From owner-linux-mips@oss.sgi.com Fri Jan 11 13:06:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BL6tq31726 for linux-mips-outgoing; Fri, 11 Jan 2002 13:06:55 -0800 Received: from mailhost.taec.toshiba.com (mailhost.taec.com [209.243.128.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BL6ng31723 for ; Fri, 11 Jan 2002 13:06:49 -0800 Received: from hdqmta.taec.com (hdqmta [209.243.180.59]) by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id MAA03945; Fri, 11 Jan 2002 12:06:39 -0800 (PST) Subject: Re: libtool warning on redhat 7.1 native mipsel compile To: "H . J . Lu" Cc: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Adrian.Hulse@taec.toshiba.com Date: Fri, 11 Jan 2002 12:08:12 -0800 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.8 |June 18, 2001) at 01/11/2002 12:05:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1813 Lines: 46 I don't know for sure just yet, the package takes a long time to compile. The last time I compiled the package it failed to build - whether it is due to the warnings or not I don't really know - maybe not. But as a result of trying to get the package to compile I came across the "mips-1" problem and thought I'd post my findings to the list, as it seems to have the potential to affect a lot of builds. "H . J . Lu" cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 01/11/02 11:56 native mipsel compile AM On Fri, Jan 11, 2002 at 11:53:42AM -0800, Adrian.Hulse@taec.toshiba.com wrote: > > I have come across many libtool warnings when native compiling redhat 7.1 > packages on my mips board. > > An example warning is : > > *** Warning: This library needs some functionality provided by -lc > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > Does that cause any problems? H.J. From owner-linux-mips@oss.sgi.com Fri Jan 11 13:08:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BL8A431805 for linux-mips-outgoing; Fri, 11 Jan 2002 13:08:10 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BL88g31802 for ; Fri, 11 Jan 2002 13:08:08 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 919C3125CB; Fri, 11 Jan 2002 12:08:06 -0800 (PST) Date: Fri, 11 Jan 2002 12:08:06 -0800 From: "H . J . Lu" To: Adrian.Hulse@taec.toshiba.com Cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020111120806.A28902@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Adrian.Hulse@taec.toshiba.com on Fri, Jan 11, 2002 at 12:08:12PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 381 Lines: 12 On Fri, Jan 11, 2002 at 12:08:12PM -0800, Adrian.Hulse@taec.toshiba.com wrote: > > I don't know for sure just yet, the package takes a long time to compile. > The last time I compiled the package it failed to build - whether it is due > to the warnings or not I don't really know - maybe not. > libtool is very fragile. If it doesn't cause the failure, I won't touch it. H.J. From owner-linux-mips@oss.sgi.com Fri Jan 11 13:12:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BLChe31948 for linux-mips-outgoing; Fri, 11 Jan 2002 13:12:43 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BLCVg31943 for ; Fri, 11 Jan 2002 13:12:31 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA29999; Fri, 11 Jan 2002 21:12:32 +0100 (MET) Date: Fri, 11 Jan 2002 21:12:32 +0100 (MET) From: "Maciej W. Rozycki" To: Adrian.Hulse@taec.toshiba.com cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4652 Lines: 101 On Fri, 11 Jan 2002 Adrian.Hulse@taec.toshiba.com wrote: > To cut a long story short I traced the problem to a number of script files > which define a string to be : > > ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib) > > When this is used as a match against libc-2.2.4.so's output the "mips-1" > part causes a mismatch and libtool complains the library is not a shared > library file. Note, as far as I have checked most of the library files in > the redhat 7.1 distribution include this "mips-1". Libtool is broken. It doesn't use `file' for most ELF Linux platforms but it does for MIPS. Here is a patch for libtool. After building and installing updated libtool you need to run `libtoolize -f' to update an obsolete script for every libtool-dependent program to be built. Depending on a program's configuration and the version of libtool used by it, there might be additional steps needed, such as running `aclocal' or `autoconf'. Sometimes a manual update of "aclocal.m4" is needed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + libtool-1.4.1-mips-deplibs.patch diff -up --recursive --new-file libtool-1.4.1.macro/acinclude.m4 libtool-1.4.1/acinclude.m4 --- libtool-1.4.1.macro/acinclude.m4 Sun Sep 2 23:32:02 2001 +++ libtool-1.4.1/acinclude.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM diff -up --recursive --new-file libtool-1.4.1.macro/cdemo/acinclude.m4 libtool-1.4.1/cdemo/acinclude.m4 --- libtool-1.4.1.macro/cdemo/acinclude.m4 Mon Sep 3 01:45:03 2001 +++ libtool-1.4.1/cdemo/acinclude.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM diff -up --recursive --new-file libtool-1.4.1.macro/demo/acinclude.m4 libtool-1.4.1/demo/acinclude.m4 --- libtool-1.4.1.macro/demo/acinclude.m4 Mon Sep 3 01:44:59 2001 +++ libtool-1.4.1/demo/acinclude.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM diff -up --recursive --new-file libtool-1.4.1.macro/depdemo/acinclude.m4 libtool-1.4.1/depdemo/acinclude.m4 --- libtool-1.4.1.macro/depdemo/acinclude.m4 Mon Sep 3 01:45:00 2001 +++ libtool-1.4.1/depdemo/acinclude.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM diff -up --recursive --new-file libtool-1.4.1.macro/libtool.m4 libtool-1.4.1/libtool.m4 --- libtool-1.4.1.macro/libtool.m4 Sun Sep 2 23:32:02 2001 +++ libtool-1.4.1/libtool.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM diff -up --recursive --new-file libtool-1.4.1.macro/mdemo/acinclude.m4 libtool-1.4.1/mdemo/acinclude.m4 --- libtool-1.4.1.macro/mdemo/acinclude.m4 Mon Sep 3 01:45:02 2001 +++ libtool-1.4.1/mdemo/acinclude.m4 Sat Sep 8 23:30:44 2001 @@ -3323,7 +3323,7 @@ irix5* | irix6*) # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM From owner-linux-mips@oss.sgi.com Fri Jan 11 22:26:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C6QQR10756 for linux-mips-outgoing; Fri, 11 Jan 2002 22:26:26 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0C6QNg10752 for ; Fri, 11 Jan 2002 22:26:23 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0C5QKn04944; Fri, 11 Jan 2002 21:26:20 -0800 Date: Fri, 11 Jan 2002 21:26:20 -0800 From: Ralf Baechle To: "H . J . Lu" Cc: Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020111212620.A4809@dea.linux-mips.net> References: <20020111120806.A28902@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020111120806.A28902@lucon.org>; from hjl@lucon.org on Fri, Jan 11, 2002 at 12:08:06PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 673 Lines: 18 On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote: > > I don't know for sure just yet, the package takes a long time to compile. > > The last time I compiled the package it failed to build - whether it is due > > to the warnings or not I don't really know - maybe not. > > > > libtool is very fragile. If it doesn't cause the failure, I won't touch > it. This bug may result in libraries not getting linked against certain other libraries thus DT_NEEDED entries missing. Frequently that's harmless but it breaks a few packages. I remember fixing this in a large number of RH 7.0 packages. Bug are rarely harmless just their consequences are subtle. Ralf From owner-linux-mips@oss.sgi.com Fri Jan 11 22:42:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C6gi711016 for linux-mips-outgoing; Fri, 11 Jan 2002 22:42:44 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C6gbg11013; Fri, 11 Jan 2002 22:42:37 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4A591125CB; Fri, 11 Jan 2002 21:42:35 -0800 (PST) Date: Fri, 11 Jan 2002 21:42:34 -0800 From: "H . J . Lu" To: Ralf Baechle Cc: Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020111214234.A5294@lucon.org> References: <20020111120806.A28902@lucon.org> <20020111212620.A4809@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020111212620.A4809@dea.linux-mips.net>; from ralf@oss.sgi.com on Fri, Jan 11, 2002 at 09:26:20PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1075 Lines: 39 On Fri, Jan 11, 2002 at 09:26:20PM -0800, Ralf Baechle wrote: > On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote: > > > > I don't know for sure just yet, the package takes a long time to compile. > > > The last time I compiled the package it failed to build - whether it is due > > > to the warnings or not I don't really know - maybe not. > > > > > > > libtool is very fragile. If it doesn't cause the failure, I won't touch > > it. > > This bug may result in libraries not getting linked against certain other > libraries thus DT_NEEDED entries missing. Frequently that's harmless but > it breaks a few packages. I remember fixing this in a large number of > RH 7.0 packages. > > Bug are rarely harmless just their consequences are subtle. Ok. Please try ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm You have to rebuild it on your Linux/mips system with # su # rpm --rebuild libtool-1.3.5-8.3.src.rpm Let me know if it works for you. H.J. to ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib) H.J. H.J. From owner-linux-mips@oss.sgi.com Fri Jan 11 22:48:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C6maW11229 for linux-mips-outgoing; Fri, 11 Jan 2002 22:48:36 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0C6mXg11223 for ; Fri, 11 Jan 2002 22:48:33 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0C5mV105092; Fri, 11 Jan 2002 21:48:31 -0800 Date: Fri, 11 Jan 2002 21:48:31 -0800 From: Ralf Baechle To: "H . J . Lu" Cc: Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020111214831.A5081@dea.linux-mips.net> References: <20020111120806.A28902@lucon.org> <20020111212620.A4809@dea.linux-mips.net> <20020111214234.A5294@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020111214234.A5294@lucon.org>; from hjl@lucon.org on Fri, Jan 11, 2002 at 09:42:34PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 726 Lines: 24 On Fri, Jan 11, 2002 at 09:42:34PM -0800, H . J . Lu wrote: > > This bug may result in libraries not getting linked against certain other > > libraries thus DT_NEEDED entries missing. Frequently that's harmless but > > it breaks a few packages. I remember fixing this in a large number of > > RH 7.0 packages. > > > > Bug are rarely harmless just their consequences are subtle. > > Ok. Please try > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm > > You have to rebuild it on your Linux/mips system with > > # su > # rpm --rebuild libtool-1.3.5-8.3.src.rpm > > Let me know if it works for you. I'll not be able to test this for several more days as I'm currently in Sunnyvale. Ralf From owner-linux-mips@oss.sgi.com Sat Jan 12 01:05:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C95e813387 for linux-mips-outgoing; Sat, 12 Jan 2002 01:05:40 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C95Zg13384 for ; Sat, 12 Jan 2002 01:05:36 -0800 Received: (qmail 10633 invoked from network); 12 Jan 2002 08:05:31 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 12 Jan 2002 08:05:31 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16PJAQ-0003fE-00 for ; Sat, 12 Jan 2002 01:05:30 -0700 Date: Sat, 12 Jan 2002 01:05:30 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: linux-mips@oss.sgi.com Subject: Quick Q about caches Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1675 Lines: 40 Hi All, I've been working on some cache code for a new processor and I just quickly wanted to ensure I'm reading the existing stuff right, I hope that someone who knows a bit more about this codes history could just confirm some of my guesses :> So here is what I'm thinking: (read virtually indexed == cache aliasing problems) The stuff in c-mips32 is for a processor with virtually indexed primary and secondary caches, seperate i/d caches and no io-coherancy The stuff in c-rm7k describes a processor with physically indexed caches, but seperate non-snooping i and d caches. The IO coherancy stuff does too much flushing, notably DMA should never be done to regions that are executing, and the flush_scache also does the flush_dcache as in c-mips32 (presumably this is what the XXX comment is talking about) The SB1 reference tells me that it has a virtually indexed icache that also tags ASID's, the CONFIG_VTAG_ICACHE option invokes the special code to manage this ASID caching. The rest of the caches are physically indexed and IO coherant (woop!). The comment for sb1_flush_page_to_ram does not jive with the stuff in Documentation/cachetlb.txt - I think the latter is right and the function should be a nop on a physically tagged dcache.. The one thing I don't quite get yet is why flush_dcache_page is a NOP for everyone? That must mean the dcache is always physically indexed if Documentation/cachetlb.txt is correct.. Anyhow, the chip I've got is largely sane, the only annoyance is that the SR7100 has physically tagged but virtually indexed i/d-caches that can alias if the page size is less than 8K, the rest seems straightforward.. Thanks, Jason From owner-linux-mips@oss.sgi.com Sat Jan 12 06:36:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0CEaWu17659 for linux-mips-outgoing; Sat, 12 Jan 2002 06:36:32 -0800 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0CEaQg17656 for ; Sat, 12 Jan 2002 06:36:26 -0800 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id NAA22217 for linux-mips@oss.sgi.com; Sat, 12 Jan 2002 13:36:21 GMT From: Robin Humble Message-Id: <200201121336.NAA22217@groucho.maths.monash.edu.au> Subject: Re: libtool warning on redhat 7.1 native mipsel compile To: linux-mips@oss.sgi.com Date: Sun, 13 Jan 2002 00:36:21 +1100 (EDT) In-Reply-To: <20020111214234.A5294@lucon.org> from "H . J . Lu" at Jan 11, 2002 09:42:34 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1717 Lines: 41 H . J . Lu writes: >On Fri, Jan 11, 2002 at 09:26:20PM -0800, Ralf Baechle wrote: >> On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote: >> > > I don't know for sure just yet, the package takes a long time to compile. >> > > The last time I compiled the package it failed to build - whether it is d ue >> > > to the warnings or not I don't really know - maybe not. >> > libtool is very fragile. If it doesn't cause the failure, I won't touch >> > it. >> This bug may result in libraries not getting linked against certain other >> libraries thus DT_NEEDED entries missing. Frequently that's harmless but >> it breaks a few packages. I remember fixing this in a large number of >> RH 7.0 packages. >> >> Bug are rarely harmless just their consequences are subtle. yeah, the libtool thing is a pain, but realistically it's only been a problem for me on 2 or 3 out of many rpm builds. Still it'd be way cool if it was sorted out... >Ok. Please try >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm unfortunately this doesn't work. Same output as the orig 7.1 rpm or a stock newer libtool :-/ Does the latest kernel export endianess in /proc/cpuinfo? If so, then the latest rawhide rpm can be trivially modified to add mips* along with s390* support in the s390 patch and it seems to work for me. If your kernel doesn't export endianess, then you can specify it with (eg. for big endian) ./configure --host=mips-unknown-linux-gnu ... and libtool then works ok. Grab a patched for mips libtool srpm (+ big endian binary rpms (Indy)) from http://www.cita.utoronto.ca/~rjh/mips/libtool/ Maybe someone can --rebuild the srpm on mipsel and see if it works too? cheers, robin From owner-linux-mips@oss.sgi.com Sat Jan 12 10:22:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0CIMLS20535 for linux-mips-outgoing; Sat, 12 Jan 2002 10:22:21 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0CIMKg20532 for ; Sat, 12 Jan 2002 10:22:20 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8CC10125CB; Sat, 12 Jan 2002 09:22:17 -0800 (PST) Date: Sat, 12 Jan 2002 09:22:17 -0800 From: "H . J . Lu" To: Robin Humble Cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020112092217.A15384@lucon.org> References: <20020111214234.A5294@lucon.org> <200201121336.NAA22217@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201121336.NAA22217@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Sun, Jan 13, 2002 at 12:36:21AM +1100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 307 Lines: 12 On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote: > > >Ok. Please try > >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm > > unfortunately this doesn't work. Same output as the orig 7.1 rpm or a > stock newer libtool :-/ Please tell me how to reproduce it. H.J. From owner-linux-mips@oss.sgi.com Sat Jan 12 17:21:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0D1LCu26173 for linux-mips-outgoing; Sat, 12 Jan 2002 17:21:12 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0D1L8g26169 for ; Sat, 12 Jan 2002 17:21:08 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0CNp2q05396; Sat, 12 Jan 2002 15:51:02 -0800 Date: Sat, 12 Jan 2002 15:51:02 -0800 From: Ralf Baechle To: Jason Gunthorpe Cc: linux-mips@oss.sgi.com Subject: Re: Quick Q about caches Message-ID: <20020112155102.A1569@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgg@debian.org on Sat, Jan 12, 2002 at 01:05:30AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1613 Lines: 36 On Sat, Jan 12, 2002 at 01:05:30AM -0700, Jason Gunthorpe wrote: > So here is what I'm thinking: (read virtually indexed == cache aliasing > problems) Right. > The stuff in c-mips32 is for a processor with virtually indexed primary > and secondary caches, seperate i/d caches and no io-coherancy > > The stuff in c-rm7k describes a processor with physically indexed > caches, but seperate non-snooping i and d caches. The IO coherancy stuff > does too much flushing, notably DMA should never be done to regions that > are executing, and the flush_scache also does the flush_dcache as in > c-mips32 (presumably this is what the XXX comment is talking about) > > The SB1 reference tells me that it has a virtually indexed icache that > also tags ASID's, the CONFIG_VTAG_ICACHE option invokes the special code > to manage this ASID caching. The rest of the caches are physically indexed > and IO coherant (woop!). The comment for sb1_flush_page_to_ram does > not jive with the stuff in Documentation/cachetlb.txt - I think the > latter is right and the function should be a nop on a physically tagged > dcache.. > > The one thing I don't quite get yet is why flush_dcache_page is a NOP for > everyone? That must mean the dcache is always physically indexed if > Documentation/cachetlb.txt is correct.. You either need to implement flush_page_to_ram or flush_dcache_page. > Anyhow, the chip I've got is largely sane, the only annoyance is that > the SR7100 has physically tagged but virtually indexed i/d-caches that > can alias if the page size is less than 8K, the rest seems > straightforward.. Ralf From owner-linux-mips@oss.sgi.com Sat Jan 12 21:04:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0D54j428891 for linux-mips-outgoing; Sat, 12 Jan 2002 21:04:45 -0800 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0D54dg28883 for ; Sat, 12 Jan 2002 21:04:39 -0800 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id EAA27646 for linux-mips@oss.sgi.com; Sun, 13 Jan 2002 04:04:35 GMT From: Robin Humble Message-Id: <200201130404.EAA27646@groucho.maths.monash.edu.au> Subject: Re: libtool warning on redhat 7.1 native mipsel compile To: linux-mips@oss.sgi.com Date: Sun, 13 Jan 2002 15:04:35 +1100 (EDT) In-Reply-To: <20020112092217.A15384@lucon.org> from "H . J . Lu" at Jan 12, 2002 09:22:17 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1771 Lines: 45 H.J. writes: >On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote: >> >Ok. Please try >> >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm >> unfortunately this doesn't work. Same output as the orig 7.1 rpm or a >> stock newer libtool :-/ >Please tell me how to reproduce it. try --rebuild on these for example: imlib, gconf, gnome-python, mozilla. the libtool problem means that they refuse to build shared libs and only make the .a's. this leads to problems down the track when other apps expect the .so's to be present. Output from configure/libtool varies, but for example it typically looks like this: ... *** Warning: This library needs some functionality provided by -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -ldb1. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. ... Although in this case (control-center) it still built the .so's just gave lots of warnings like this. I guess the s390 arch had the same problems, hence the patch that's in recent libtool srpms. I just added mips* as well - AFAICT this avoids libtool trying to use 'file' at all, and hence avoid any issues with 'file' output changing. Hope that's of some help. cheers, robin From owner-linux-mips@oss.sgi.com Sat Jan 12 23:27:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0D7RSX30900 for linux-mips-outgoing; Sat, 12 Jan 2002 23:27:28 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0D7RQg30897 for ; Sat, 12 Jan 2002 23:27:26 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 51F4E125CB; Sat, 12 Jan 2002 22:27:21 -0800 (PST) Date: Sat, 12 Jan 2002 22:27:21 -0800 From: "H . J . Lu" To: Robin Humble Cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020112222721.B26661@lucon.org> References: <20020112092217.A15384@lucon.org> <200201130404.EAA27646@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201130404.EAA27646@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Sun, Jan 13, 2002 at 03:04:35PM +1100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 576 Lines: 17 On Sun, Jan 13, 2002 at 03:04:35PM +1100, Robin Humble wrote: > > H.J. writes: > >On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote: > >> >Ok. Please try > >> >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm > >> unfortunately this doesn't work. Same output as the orig 7.1 rpm or a > >> stock newer libtool :-/ > >Please tell me how to reproduce it. > > try --rebuild on these for example: imlib, gconf, gnome-python, mozilla. Do you have something which doesn't use X? I don't have X on my machine. I need a simple testcase. H.J. From owner-linux-mips@oss.sgi.com Sun Jan 13 19:06:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E36UN21632 for linux-mips-outgoing; Sun, 13 Jan 2002 19:06:30 -0800 Received: from 213.160.207.130 ([213.160.207.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E36Qg21629 for ; Sun, 13 Jan 2002 19:06:27 -0800 Received: (qmail 1506 invoked from network); 13 Jan 2002 20:57:58 -0000 Received: from 213-97-238-169.uc.nombres.ttd.es (HELO none) (213.97.238.169) by dtu.co.uk with SMTP; 13 Jan 2002 20:57:58 -0000 Message-ID: <476165711879$44007527$95404726@helmut> From: "schneckchen@brisant-mail.com" To: "linux-mips@oss.sgi.com" Subject: Ich bin's Date: Sun, 13 Jan 2002 21:03:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 767 Lines: 22 Hallo, ....danke für Dein Mail. Ist schon `ne Weile her. Nun ja, bist Du immer noch allein? Einsam? Ich auch. Obwohl Freunde von mir sagen, dass ich recht gut aussehe, fehlt mir doch noch ein netter Partner zum Reden, Lieben und Kuscheln. Vielleicht bist Du es. Dein Alter und Dein Aussehen ist für mich nicht so wichtig. Im Moment spanne ich einige Tage aus, lasse die Seele baumeln-, versuche nach Enttäuschungen mein Leben neu zu ordnen. Ich habe mich bei www.fairway-contacts.com eingetragen. Du findest ein Foto und meine Wohnungsanschrift mit normaler Telefonnummer unter der Rubrik "Sie sucht Ihn". Wenn ich Dir gefallen sollte, rufe mich doch einfach einmal an. Ich freue mich auf ein Gespräch mit Dir. Bis bald Dein Schneckchen From owner-linux-mips@oss.sgi.com Sun Jan 13 22:13:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E6Djq24312 for linux-mips-outgoing; Sun, 13 Jan 2002 22:13:45 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E6DVg24301 for ; Sun, 13 Jan 2002 22:13:37 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g0E5DNc07128 for linux-mips@oss.sgi.com; Sun, 13 Jan 2002 21:13:23 -0800 Date: Sun, 13 Jan 2002 21:13:23 -0800 From: Matthew Dharm To: linux-mips@oss.sgi.com Subject: MIPS64 status? Message-ID: <20020113211323.A7115@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 23 So, lots of people are asking me about 64-bit support for MIPS Linux. And this is something I think I know, but I'm not sure. And before I go spreading any more bad data, I thought I'd ask the experts. :) As I understand it, 64-bit support is really two different things: 64-bit data path (i.e. unsigned long long) and 64-bit addressing (for more than 4G of RAM). My understanding is that "MIPS64" generally refers to a kernel which supports a 64-bit data path, but we're still limited to 32-bit addressing. Is that correct? I suspect that this is very much a toolchain issue, as I don't think gcc will generate 64-bit addressing code. Comments? Corrections? Smack-downs? :) Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Mon Jan 14 01:13:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E9D8W27651 for linux-mips-outgoing; Mon, 14 Jan 2002 01:13:08 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E9D5g27647 for ; Mon, 14 Jan 2002 01:13:05 -0800 Received: (qmail 9050 invoked from network); 14 Jan 2002 08:13:02 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 08:13:02 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16Q2En-0005fE-00; Mon, 14 Jan 2002 01:13:01 -0700 Date: Mon, 14 Jan 2002 01:13:01 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Matthew Dharm cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <20020113211323.A7115@momenco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 794 Lines: 23 On Sun, 13 Jan 2002, Matthew Dharm wrote: > As I understand it, 64-bit support is really two different things: 64-bit > data path (i.e. unsigned long long) and 64-bit addressing (for more than 4G > of RAM). I suppose you could say that. I think I saw someone post to this list that they were working on a patch to enable 64 bit registers with a 32 bit kernel. > My understanding is that "MIPS64" generally refers to a kernel which > supports a 64-bit data path, but we're still limited to 32-bit addressing. > Is that correct? The mips64 tree in CVS is one that is a 64 bit addressing capable kernel. AFAIK the linx convention is that 64 refers to addressing (which probably impiles register width too :>) I'm not sure what the current state of the ELF64 MIPS toolchain is. Jason From owner-linux-mips@oss.sgi.com Mon Jan 14 04:17:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ECHV202199 for linux-mips-outgoing; Mon, 14 Jan 2002 04:17:31 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ECHMg02193 for ; Mon, 14 Jan 2002 04:17:23 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0EBHCt19254; Mon, 14 Jan 2002 11:17:12 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id g0EBH8a01395; Mon, 14 Jan 2002 11:17:08 GMT From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15426.48692.795968.819750@gladsmuir.algor.co.uk> Date: Mon, 14 Jan 2002 11:17:08 +0000 (GMT) To: Matthew Dharm Cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <20020113211323.A7115@momenco.com> References: <20020113211323.A7115@momenco.com> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2427 Lines: 61 Matthew, > As I understand it, 64-bit support is really two different things: > 64-bit data path (i.e. unsigned long long) and 64-bit addressing > (for more than 4G of RAM). Yes: the MIPS architecture is designed so there are lots of different things which can be "64-bit", and you don't have to go for them all at once. This kind of choice can be as much curse as blessing, of course. Ralf etc have worked (with some sponsorship from SGI) on a full-blown system where you get: o A very large physical address space o Very large virtual address spaces, using 64-bit pointer types. o C "long" (and perhaps even "int") becomes 64-bit. In such a 64-bit Linux system, though, you might still want to be able to run 32-bit applications with 32-bit pointers, int and long - either for compatibility or economy (32-bit data types make for a smaller program). SGI do this in Irix: I don't know whether the 64-bit Linux/MIPS systems got around to it. There are other potentially useful combinations: o A Linux where all machine-supported integer data types are 32-bit, but capable of addressing physical memory outside of a 4Gbyte map. (In practice, you need to use this kind of system to get outside of a 512Mbyte map - so it's urgent). Ralf says he has done this: it could be done without using any 64-bit operations, but it might be easier with them. o A system using 32-bit pointers and 'long' throughout, but with support for 'long long' 64-bit integer data types in registers. o A system using 64-bit addressing within the kernel, but not for applications. However, it's unlikely to make sense to do all of them! > I suspect that this is very much a toolchain issue, as I don't think > gcc will generate 64-bit addressing code. I suspect that the generic GNU toolchains are pretty buggy when you switch on 64-bit MIPS operation; but it's bug-fixes which are needed, not wholesale new features. Politics: MIPS Technologies' advocacy for their "MIPS32" instruction set dialect in embedded systems means there are now some quite capable MIPS CPUs (eg Alchemy's 500Mhz integrated CPUs) which don't have 64-bit datapaths or arithmetic. So casual dependence on 64-bit operations should probably be avoided. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Mon Jan 14 04:36:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ECagM02635 for linux-mips-outgoing; Mon, 14 Jan 2002 04:36:42 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ECaQg02628; Mon, 14 Jan 2002 04:36:26 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA13993; Mon, 14 Jan 2002 12:35:57 +0100 (MET) Date: Mon, 14 Jan 2002 12:35:57 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Ralf Baechle , Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile In-Reply-To: <20020111214234.A5294@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 484 Lines: 13 On Fri, 11 Jan 2002, H . J . Lu wrote: > ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib) Why not simply "lt_cv_deplibs_check_method=pass_all" like for other sane Linux platforms? I'm running libtool in such a configuration since May with no negative side effects. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 14 04:48:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ECm9I03459 for linux-mips-outgoing; Mon, 14 Jan 2002 04:48:09 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ECm5g03455 for ; Mon, 14 Jan 2002 04:48:05 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA14356; Mon, 14 Jan 2002 12:44:29 +0100 (MET) Date: Mon, 14 Jan 2002 12:44:29 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Robin Humble , linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile In-Reply-To: <20020112222721.B26661@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 679 Lines: 17 On Sat, 12 Jan 2002, H . J . Lu wrote: > > try --rebuild on these for example: imlib, gconf, gnome-python, mozilla. > > Do you have something which doesn't use X? I don't have X on my machine. > I need a simple testcase. FYI, I've put mipsel-linux-XFree86-3.3.6-2.src.rpm and mipsel-linux-XFree86*-3.3.6-2.i386.rpm cross-compilation packages at my site recently. Standard development libraries take only 6MB of disk space with extra 4MB needed for additional static ones. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 14 05:54:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EDsI108306 for linux-mips-outgoing; Mon, 14 Jan 2002 05:54:18 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EDsEg08303 for ; Mon, 14 Jan 2002 05:54:14 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA02524; Mon, 14 Jan 2002 04:54:04 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA14019; Mon, 14 Jan 2002 04:54:03 -0800 (PST) Message-ID: <00ee01c19cfa$ab8d3640$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Dominic Sweetman" , "Matthew Dharm" Cc: References: <20020113211323.A7115@momenco.com> <15426.48692.795968.819750@gladsmuir.algor.co.uk> Subject: Re: MIPS64 status? Date: Mon, 14 Jan 2002 13:54:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1264 Lines: 29 > > As I understand it, 64-bit support is really two different things: > > 64-bit data path (i.e. unsigned long long) and 64-bit addressing > > (for more than 4G of RAM). > > Yes: the MIPS architecture is designed so there are lots of different > things which can be "64-bit", and you don't have to go for them all at > once. This kind of choice can be as much curse as blessing, of course. Careful, Dom. As far as user-mode programs are concerned, older 64-bit MIPS designs (R4xxxx/R5xxxx/R7xxxx), one cannot enable 64-bit arithmetic without enabling 64-bit addressing, both of these functions being enabled by the Status.UX bit. SGI's IRIX OS allowed an execution model that provided 64-bit registers and math, while *simulating* a 32-bit address space, based on sign-extending 32-bit addresses to 64-bits. The user was spared doubling the footprint of all his pointers, but the OS still had to manage the larger page tables. The official MIPS64[tm] architecture spec from MIPS Technologies also provides a bit (Status.PX) which enables the 64-bit data path without affecting address generation and translation, which removes this quirk. Only the very most recent 64-bit cores and CPUs implement it, however. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 14 06:38:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EEcWf09969 for linux-mips-outgoing; Mon, 14 Jan 2002 06:38:32 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EEcJg09965 for ; Mon, 14 Jan 2002 06:38:21 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA18448; Mon, 14 Jan 2002 14:37:22 +0100 (MET) Date: Mon, 14 Jan 2002 14:37:22 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Dominic Sweetman , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <00ee01c19cfa$ab8d3640$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1180 Lines: 25 On Mon, 14 Jan 2002, Kevin D. Kissell wrote: > Careful, Dom. As far as user-mode programs are concerned, > older 64-bit MIPS designs (R4xxxx/R5xxxx/R7xxxx), one cannot > enable 64-bit arithmetic without enabling 64-bit addressing, > both of these functions being enabled by the Status.UX bit. > SGI's IRIX OS allowed an execution model that provided > 64-bit registers and math, while *simulating* a 32-bit address > space, based on sign-extending 32-bit addresses to 64-bits. > The user was spared doubling the footprint of all his pointers, > but the OS still had to manage the larger page tables. Note that there is usually no point in using a 64D/32A mode unless you have weird toolchain problems. You may get a 64D/32A user program by mapping its segments appropriately in the 31-bit address space. Since the MIPS user segment always starts at zero such a program won't see a difference between a 64D/32A and a 64D/64A mode. Why would an OS need larger page tables? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 14 10:50:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EIoZw17344 for linux-mips-outgoing; Mon, 14 Jan 2002 10:50:35 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EIoWg17339 for ; Mon, 14 Jan 2002 10:50:32 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 2461B125C1; Mon, 14 Jan 2002 09:50:28 -0800 (PST) Date: Mon, 14 Jan 2002 09:50:28 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Robin Humble , linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020114095028.C30946@lucon.org> References: <20020112222721.B26661@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 14, 2002 at 12:44:29PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 960 Lines: 22 On Mon, Jan 14, 2002 at 12:44:29PM +0100, Maciej W. Rozycki wrote: > On Sat, 12 Jan 2002, H . J . Lu wrote: > > > > try --rebuild on these for example: imlib, gconf, gnome-python, mozilla. > > > > Do you have something which doesn't use X? I don't have X on my machine. > > I need a simple testcase. > > FYI, I've put mipsel-linux-XFree86-3.3.6-2.src.rpm and > mipsel-linux-XFree86*-3.3.6-2.i386.rpm cross-compilation packages at my > site recently. Standard development libraries take only 6MB of disk space > with extra 4MB needed for additional static ones. I should have made myself clearer. I do have X rpms. In fact, my RedHat 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine. I simply can't afford to put X on it. My mips box is used to track gcc 3.1, which breaks on Linux/mips almost every week, if not everyday. It takes 2 days for me bootstrap/check gcc 3.1 on that box. I need something simple to reproduce it. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 14 10:56:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EIuDo17571 for linux-mips-outgoing; Mon, 14 Jan 2002 10:56:13 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EIu8g17568; Mon, 14 Jan 2002 10:56:09 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1F9C5125C1; Mon, 14 Jan 2002 09:56:05 -0800 (PST) Date: Mon, 14 Jan 2002 09:56:05 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Ralf Baechle , Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020114095605.D30946@lucon.org> References: <20020111214234.A5294@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 14, 2002 at 12:35:57PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 510 Lines: 17 On Mon, Jan 14, 2002 at 12:35:57PM +0100, Maciej W. Rozycki wrote: > On Fri, 11 Jan 2002, H . J . Lu wrote: > > > ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib) > > Why not simply "lt_cv_deplibs_check_method=pass_all" like for other sane > Linux platforms? I'm running libtool in such a configuration since May > with no negative side effects. > Please follow http://sources.redhat.com/ml/binutils/2001-10/msg00358.html http://sources.redhat.com/ml/binutils/2001-10/msg00406.html H.J. From owner-linux-mips@oss.sgi.com Mon Jan 14 13:00:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EL0cN21419 for linux-mips-outgoing; Mon, 14 Jan 2002 13:00:38 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EL0Vg21415 for ; Mon, 14 Jan 2002 13:00:31 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0EK01X10310; Mon, 14 Jan 2002 12:00:02 -0800 From: "Matthew Dharm" To: "Jason Gunthorpe" Cc: Subject: RE: MIPS64 status? Date: Mon, 14 Jan 2002 12:00:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1695 Lines: 57 See, it's answers like this that make me skeptical and confused... So MIPS64 denotes 64-bit data _and_ address? Great. But, what is the current state of the toolchain? I mean, what point is having the code if the tools won't compile it properly? I guess what I'm looking for is what I should tell someone who wants to run MIPS Linux 64-bit with 8 gigs of RAM. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@debian.org] > Sent: Monday, January 14, 2002 12:13 AM > To: Matthew Dharm > Cc: linux-mips@oss.sgi.com > Subject: Re: MIPS64 status? > > > > On Sun, 13 Jan 2002, Matthew Dharm wrote: > > > As I understand it, 64-bit support is really two > different things: 64-bit > > data path (i.e. unsigned long long) and 64-bit addressing > (for more than 4G > > of RAM). > > I suppose you could say that. I think I saw someone post to > this list > that they were working on a patch to enable 64 bit > registers with a 32 bit > kernel. > > > My understanding is that "MIPS64" generally refers to a > kernel which > > supports a 64-bit data path, but we're still limited to > 32-bit addressing. > > Is that correct? > > The mips64 tree in CVS is one that is a 64 bit addressing > capable kernel. > AFAIK the linx convention is that 64 refers to > addressing (which > probably impiles register width too :>) > > I'm not sure what the current state of the ELF64 MIPS toolchain is. > > Jason > From owner-linux-mips@oss.sgi.com Mon Jan 14 13:42:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ELgRs22593 for linux-mips-outgoing; Mon, 14 Jan 2002 13:42:27 -0800 Received: from cast-ext.ab.videon.ca (cast-ext.ab.videon.ca [206.75.216.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ELgPg22590 for ; Mon, 14 Jan 2002 13:42:25 -0800 Received: (qmail 17107 invoked from network); 14 Jan 2002 20:42:22 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by cast-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 20:42:22 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16QDvy-0006lG-00; Mon, 14 Jan 2002 13:42:22 -0700 Date: Mon, 14 Jan 2002 13:42:22 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Matthew Dharm cc: linux-mips@oss.sgi.com Subject: RE: MIPS64 status? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 687 Lines: 19 On Mon, 14 Jan 2002, Matthew Dharm wrote: > So MIPS64 denotes 64-bit data _and_ address? Great. But, what is the > current state of the toolchain? I mean, what point is having the code > if the tools won't compile it properly? Well, working on the kernel is a good way to get the tools working. That is how several of the Linux archs have worked in the past. > I guess what I'm looking for is what I should tell someone who wants > to run MIPS Linux 64-bit with 8 gigs of RAM. I have such hardware myself. IMHO the best option is the mips64 kernel and I hope to try it someday. But in practice I'd guess that Ralf's highmem patch is more likely to be usuable first (?). Jason From owner-linux-mips@oss.sgi.com Mon Jan 14 14:17:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EMHcs23195 for linux-mips-outgoing; Mon, 14 Jan 2002 14:17:38 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EMHXg23190 for ; Mon, 14 Jan 2002 14:17:34 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0ELHFt05877; Mon, 14 Jan 2002 21:17:16 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id g0ELHCi02540; Mon, 14 Jan 2002 21:17:12 GMT From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15427.19160.15187.23375@gladsmuir.algor.co.uk> Date: Mon, 14 Jan 2002 21:17:12 +0000 (GMT) To: "Matthew Dharm" Cc: "Jason Gunthorpe" , Subject: RE: MIPS64 status? In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 606 Lines: 19 Matthew Dharm (mdharm@momenco.com) writes: > I guess what I'm looking for is what I should tell someone who wants > to run MIPS Linux 64-bit with 8 gigs of RAM. "Ask Ralf". (at least, that's the best advice for the kernel, which he worked on at SGI). For a compiler, you should ask Algorithmics. We haven't tried the 64-bit configuration yet, but we've done lots of GCC variants and it's only a program... -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Mon Jan 14 15:59:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ENxxH26588 for linux-mips-outgoing; Mon, 14 Jan 2002 15:59:59 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0ENxug26585 for ; Mon, 14 Jan 2002 15:59:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0EMxrj29257 for linux-mips@oss.sgi.com; Mon, 14 Jan 2002 14:59:53 -0800 Received: from portablue.intern.mind.be (open.your.mind.be [195.162.205.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EEpfg10168 for ; Mon, 14 Jan 2002 06:51:42 -0800 Received: by portablue.intern.mind.be (Postfix, from userid 505) id 415DF7B50; Mon, 14 Jan 2002 14:51:26 +0100 (CET) Date: Mon, 14 Jan 2002 14:51:25 +0100 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, linux-mips@oss.sgi.com Subject: [PATCH] DDB-5074 support Message-ID: <20020114135125.GA1254@mind.be> Mail-Followup-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 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Answer: 42 X-Operating-system: Debian GNU/Linux X-message-flag: Get yourself a real email client. http://www.mutt.org/ From: p2@mind.be (Peter De Schrijver) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 44059 Lines: 1620 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The attached patch against the linux/mips CVS tree is a first attempt to get the NEC DDB-5074 support back to work. The board boots now, but there are still some things to be done : - Support for the onboard Tulip ethernet controller - Support for ps/2 mouse & keyboard - Getting the matrox fb device to work on a Millenium I/II without running the BIOS - ... Happy hacking, Peter. --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=ddb-patch-1 diff -uN -r --exclude=CVS linux-cvs/arch/mips/Makefile linux-ddb/arch/mips/Makefile --- linux-cvs/arch/mips/Makefile Tue Nov 27 16:57:11 2001 +++ linux-ddb/arch/mips/Makefile Mon Dec 24 01:10:35 2001 @@ -189,8 +189,8 @@ # NEC DDB Vrc-5074 # ifdef CONFIG_DDB5074 -SUBDIRS += arch/mips/ddb5074 -LIBS += arch/mips/ddb5074/ddb5074.a +SUBDIRS += arch/mips/ddb5xxx/common arch/mips/ddb5xxx/ddb5074 +LIBS += arch/mips/ddb5xxx/common/ddb5xxx.o arch/mips/ddb5xxx/ddb5074/ddb5074.o LOADADDR += 0x80080000 endif diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/Makefile linux-ddb/arch/mips/ddb5xxx/ddb5074/Makefile --- linux-cvs/arch/mips/ddb5xxx/ddb5074/Makefile Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/Makefile Sun Dec 30 19:08:18 2001 @@ -0,0 +1,21 @@ +# +# Makefile for the NEC DDB Vrc-5074 specific kernel interface routines +# under Linux. +# +# Note! Dependencies are done automagically by 'make dep', which also +# removes any old dependencies. DON'T put your own dependencies here +# unless it's something special (ie not a .c file). +# +# Note 2! The CFLAGS definitions are now in the main makefile... +# + +.S.s: + $(CPP) $(CFLAGS) $< -o $*.s +.S.o: + $(CC) $(CFLAGS) -c $< -o $*.o + +O_TARGET = ddb5074.o + +obj-y += setup.o irq.o int-handler.o pci.o pci_ops.o nile4_pic.o + +include $(TOPDIR)/Rules.make diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/int-handler.S linux-ddb/arch/mips/ddb5xxx/ddb5074/int-handler.S --- linux-cvs/arch/mips/ddb5xxx/ddb5074/int-handler.S Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/int-handler.S Sun Dec 23 23:51:35 2001 @@ -0,0 +1,120 @@ +/* + * arch/mips/ddb5074/int-handler.S -- NEC DDB Vrc-5074 interrupt handler + * + * Based on arch/mips/sgi/kernel/indyIRQ.S + * + * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include + +/* A lot of complication here is taken away because: + * + * 1) We handle one interrupt and return, sitting in a loop and moving across + * all the pending IRQ bits in the cause register is _NOT_ the answer, the + * common case is one pending IRQ so optimize in that direction. + * + * 2) We need not check against bits in the status register IRQ mask, that + * would make this routine slow as hell. + * + * 3) Linux only thinks in terms of all IRQs on or all IRQs off, nothing in + * between like BSD spl() brain-damage. + * + * Furthermore, the IRQs on the INDY look basically (barring software IRQs + * which we don't use at all) like: + * + * MIPS IRQ Source + * -------- ------ + * 0 Software (ignored) + * 1 Software (ignored) + * 2 Local IRQ level zero + * 3 Local IRQ level one + * 4 8254 Timer zero + * 5 8254 Timer one + * 6 Bus Error + * 7 R4k timer (what we use) + * + * We handle the IRQ according to _our_ priority which is: + * + * Highest ---- R4k Timer + * Local IRQ zero + * Local IRQ one + * Bus Error + * 8254 Timer zero + * Lowest ---- 8254 Timer one + * + * then we just return, if multiple IRQs are pending then we will just take + * another exception, big deal. + */ + + .text + .set noreorder + .set noat + .align 5 + NESTED(ddbIRQ, PT_SIZE, sp) + SAVE_ALL + CLI + .set at + mfc0 s0, CP0_CAUSE # get irq mask + +#if 1 + mfc0 t2,CP0_STATUS # get enabled interrupts + and s0,t2 # isolate allowed ones +#endif + /* First we check for r4k counter/timer IRQ. */ + andi a0, s0, CAUSEF_IP2 # delay slot, check local level zero + beq a0, zero, 1f + andi a0, s0, CAUSEF_IP3 # delay slot, check local level one + + /* Wheee, local level zero interrupt. */ + jal ddb_local0_irqdispatch + move a0, sp # delay slot + + j ret_from_irq + nop # delay slot + +1: + beq a0, zero, 1f + andi a0, s0, CAUSEF_IP6 # delay slot, check bus error + + /* Wheee, local level one interrupt. */ + move a0, sp + jal ddb_local1_irqdispatch + nop + + j ret_from_irq + nop + +1: + beq a0, zero, 1f + nop + + /* Wheee, an asynchronous bus error... */ + move a0, sp + jal ddb_buserror_irq + nop + + j ret_from_irq + nop + +1: + /* Here by mistake? This is possible, what can happen + * is that by the time we take the exception the IRQ + * pin goes low, so just leave if this is the case. + */ + andi a0, s0, (CAUSEF_IP4 | CAUSEF_IP5) + beq a0, zero, 1f + + /* Must be one of the 8254 timers... */ + move a0, sp + jal ddb_8254timer_irq + nop +1: + j ret_from_irq + nop + END(ddbIRQ) diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/irq.c linux-ddb/arch/mips/ddb5xxx/ddb5074/irq.c --- linux-cvs/arch/mips/ddb5xxx/ddb5074/irq.c Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/irq.c Mon Dec 31 17:25:36 2001 @@ -0,0 +1,175 @@ +/* + * arch/mips/ddb5074/irq.c -- NEC DDB Vrc-5074 interrupt routines + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + + +extern void __init i8259_init(void); +extern void i8259_disable_irq(unsigned int irq_nr); +extern void i8259_enable_irq(unsigned int irq_nr); + +extern asmlinkage void ddbIRQ(void); +extern asmlinkage void i8259_do_irq(int irq, struct pt_regs *regs); +extern asmlinkage void do_IRQ(int irq, struct pt_regs *regs); + +static struct irqaction irq_cascade = { no_action, 0, 0, "cascade", NULL, NULL }; + +#define M1543_PNP_CONFIG 0x03f0 /* PnP Config Port */ +#define M1543_PNP_INDEX 0x03f0 /* PnP Index Port */ +#define M1543_PNP_DATA 0x03f1 /* PnP Data Port */ + +#define M1543_PNP_ALT_CONFIG 0x0370 /* Alternative PnP Config Port */ +#define M1543_PNP_ALT_INDEX 0x0370 /* Alternative PnP Index Port */ +#define M1543_PNP_ALT_DATA 0x0371 /* Alternative PnP Data Port */ + +#define M1543_INT1_MASTER_CTRL 0x0020 /* INT_1 (master) Control Register */ +#define M1543_INT1_MASTER_MASK 0x0021 /* INT_1 (master) Mask Register */ + +#define M1543_INT1_SLAVE_CTRL 0x00a0 /* INT_1 (slave) Control Register */ +#define M1543_INT1_SLAVE_MASK 0x00a1 /* INT_1 (slave) Mask Register */ + +#define M1543_INT1_MASTER_ELCR 0x04d0 /* INT_1 (master) Edge/Level Control */ +#define M1543_INT1_SLAVE_ELCR 0x04d1 /* INT_1 (slave) Edge/Level Control */ + + +static void m1543_irq_setup(void) +{ + /* + * The ALI M1543 has 13 interrupt inputs, IRQ1..IRQ13. Not all + * the possible IO sources in the M1543 are in use by us. We will + * use the following mapping: + * + * IRQ1 - keyboard (default set by M1543) + * IRQ3 - reserved for UART B (default set by M1543) (note that + * the schematics for the DDB Vrc-5074 board seem to + * indicate that IRQ3 is connected to the DS1386 + * watchdog timer interrupt output so we might have + * a conflict) + * IRQ4 - reserved for UART A (default set by M1543) + * IRQ5 - parallel (default set by M1543) + * IRQ8 - DS1386 time of day (RTC) interrupt + * IRQ12 - mouse + */ + + /* + * Assing mouse interrupt to IRQ12 + */ + + /* Enter configuration mode */ + outb(0x51, M1543_PNP_CONFIG); + outb(0x23, M1543_PNP_CONFIG); + + /* Select logical device 7 (Keyboard) */ + outb(0x07, M1543_PNP_INDEX); + outb(0x07, M1543_PNP_DATA); + + /* Select IRQ12 */ + outb(0x72, M1543_PNP_INDEX); + outb(0x0c, M1543_PNP_DATA); + + /* Leave configration mode */ + outb(0xbb, M1543_PNP_CONFIG); + +#if 0 + /* Initialize the 8259 PIC in the M1543 */ + i8259_init(); + + /* Enable the interrupt cascade */ + nile4_enable_irq(NILE4_INT_INTE); + + request_region(M1543_PNP_CONFIG, 2, "M1543 config"); + request_region(M1543_INT1_MASTER_ELCR, 2, "pic ELCR"); +#endif + +} + +void ddb_local0_irqdispatch(struct pt_regs *regs) +{ + u32 mask; + int nile4_irq; +#if 1 + volatile static int nesting = 0; + if (nesting++ == 0) + ddb5074_led_d3(1); + ddb5074_led_hex(nesting < 16 ? nesting : 15); +#endif + + mask = nile4_get_irq_stat(0); + nile4_clear_irq_mask(mask); + + /* Handle the timer interrupt first */ + if (mask & (1 << NILE4_INT_GPT)) { + nile4_disable_irq(NILE4_INT_GPT); + do_IRQ(nile4_to_irq(NILE4_INT_GPT), regs); + nile4_enable_irq(NILE4_INT_GPT); + mask &= ~(1 << NILE4_INT_GPT); + } + for (nile4_irq = 0; mask; nile4_irq++, mask >>= 1) + if (mask & 1) { + nile4_disable_irq(nile4_irq); + if (nile4_irq == NILE4_INT_INTE) { + int i8259_irq = nile4_i8259_iack(); + i8259_do_irq(i8259_irq, regs); + } else + do_IRQ(nile4_to_irq(nile4_irq), regs); + nile4_enable_irq(nile4_irq); + } +#if 1 + if (--nesting == 0) + ddb5074_led_d3(0); + ddb5074_led_hex(nesting < 16 ? nesting : 15); +#endif +} + +void ddb_local1_irqdispatch(void) +{ + printk("ddb_local1_irqdispatch called\n"); +} + +void ddb_buserror_irq(void) +{ + printk("ddb_buserror_irq called\n"); +} + +void ddb_8254timer_irq(void) +{ + printk("ddb_8254timer_irq called\n"); +} + +void __init ddb_irq_setup(void) +{ +#ifdef CONFIG_REMOTE_DEBUG + if (remote_debug) + set_debug_traps(); + breakpoint(); /* you may move this line to whereever you want :-) */ +#endif + + /* setup cascade interrupts */ + setup_irq(NILE4_IRQ_BASE + NILE4_INT_INTE, &irq_cascade); + setup_irq(CPU_IRQ_BASE + CPU_NILE4_CASCADE, &irq_cascade); + + set_except_vector(0, ddbIRQ); + + nile4_irq_setup(NILE4_IRQ_BASE); + m1543_irq_setup(); + init_i8259_irqs(); + + mips_cpu_irq_init(CPU_IRQ_BASE); + +} diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/nile4_pic.c linux-ddb/arch/mips/ddb5xxx/ddb5074/nile4_pic.c --- linux-cvs/arch/mips/ddb5xxx/ddb5074/nile4_pic.c Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/nile4_pic.c Mon Dec 31 17:40:59 2001 @@ -0,0 +1,274 @@ +/* + * arch/mips/ddb5476/nile4.c -- + * low-level PIC code for NEC Vrc-5476 (Nile 4) + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + * + * Copyright 2001 MontaVista Software Inc. + * Author: jsun@mvista.com or jsun@junsun.net + * + */ +#include +#include +#include +#include + +#include + +#include + +static int irq_base; + +/* + * Interrupt Programming + */ +void nile4_map_irq(int nile4_irq, int cpu_irq) +{ + u32 offset, t; + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + t = ddb_in32(offset); + t &= ~(7 << (nile4_irq * 4)); + t |= cpu_irq << (nile4_irq * 4); + ddb_out32(offset, t); +} + +void nile4_map_irq_all(int cpu_irq) +{ + u32 all, t; + + all = cpu_irq; + all |= all << 4; + all |= all << 8; + all |= all << 16; + t = ddb_in32(DDB_INTCTRL); + t &= 0x88888888; + t |= all; + ddb_out32(DDB_INTCTRL, t); + t = ddb_in32(DDB_INTCTRL + 4); + t &= 0x88888888; + t |= all; + ddb_out32(DDB_INTCTRL + 4, t); +} + +void nile4_enable_irq(int nile4_irq) +{ + u32 offset, t; + + nile4_irq-=irq_base; + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + t = ddb_in32(offset); + t |= 8 << (nile4_irq * 4); + ddb_out32(offset, t); +} + +void nile4_disable_irq(int nile4_irq) +{ + u32 offset, t; + + nile4_irq-=irq_base; + + offset = DDB_INTCTRL; + if (nile4_irq >= 8) { + offset += 4; + nile4_irq -= 8; + } + t = ddb_in32(offset); + t &= ~(8 << (nile4_irq * 4)); + ddb_out32(offset, t); +} + +void nile4_disable_irq_all(void) +{ + ddb_out32(DDB_INTCTRL, 0); + ddb_out32(DDB_INTCTRL + 4, 0); +} + +u16 nile4_get_irq_stat(int cpu_irq) +{ + return ddb_in16(DDB_INTSTAT0 + cpu_irq * 2); +} + +void nile4_enable_irq_output(int cpu_irq) +{ + u32 t; + + t = ddb_in32(DDB_INTSTAT1 + 4); + t |= 1 << (16 + cpu_irq); + ddb_out32(DDB_INTSTAT1, t); +} + +void nile4_disable_irq_output(int cpu_irq) +{ + u32 t; + + t = ddb_in32(DDB_INTSTAT1 + 4); + t &= ~(1 << (16 + cpu_irq)); + ddb_out32(DDB_INTSTAT1, t); +} + +void nile4_set_pci_irq_polarity(int pci_irq, int high) +{ + u32 t; + + t = ddb_in32(DDB_INTPPES); + if (high) + t &= ~(1 << (pci_irq * 2)); + else + t |= 1 << (pci_irq * 2); + ddb_out32(DDB_INTPPES, t); +} + +void nile4_set_pci_irq_level_or_edge(int pci_irq, int level) +{ + u32 t; + + t = ddb_in32(DDB_INTPPES); + if (level) + t |= 2 << (pci_irq * 2); + else + t &= ~(2 << (pci_irq * 2)); + ddb_out32(DDB_INTPPES, t); +} + +void nile4_clear_irq(int nile4_irq) +{ + nile4_irq-=irq_base; + ddb_out32(DDB_INTCLR, 1 << nile4_irq); +} + +void nile4_clear_irq_mask(u32 mask) +{ + ddb_out32(DDB_INTCLR, mask); +} + +u8 nile4_i8259_iack(void) +{ + u8 irq; + u32 reg; + + /* Set window 0 for interrupt acknowledge */ + reg = ddb_in32(DDB_PCIINIT0); + + ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IACK, 0, DDB_PCI_ACCESS_32); + irq = *(volatile u8 *) KSEG1ADDR(DDB_PCI_IACK_BASE); + /* restore window 0 for PCI I/O space */ + // ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IO, 0, DDB_PCI_ACCESS_32); + ddb_out32(DDB_PCIINIT0, reg); + + /* i8269.c set the base vector to be 0x20, as it does for i386 */ + return irq - 0x20; +} + +static int nile4_irq_startup(int irq) { + + nile4_enable_irq(irq); + return 0; + +} + +static void nile4_ack_irq(int irq) { + + nile4_clear_irq(irq); + nile4_disable_irq(irq); + +} + +static void nile4_irq_end(int irq) { + + if(!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + nile4_enable_irq(irq); + +} + +#define nile4_irq_shutdown nile4_disable_irq + +static hw_irq_controller nile4_irq_controller = { + "nile4", + nile4_irq_startup, + nile4_irq_shutdown, + nile4_enable_irq, + nile4_disable_irq, + nile4_ack_irq, + nile4_irq_end, + NULL +}; + +void nile4_irq_setup(u32 base) { + + int i; + extern irq_desc_t irq_desc[]; + + irq_base=base; + + /* Map all interrupts to CPU int #0 */ + nile4_map_irq_all(0); + + /* PCI INTA#-E# must be level triggered */ + nile4_set_pci_irq_level_or_edge(0, 1); + nile4_set_pci_irq_level_or_edge(1, 1); + nile4_set_pci_irq_level_or_edge(2, 1); + nile4_set_pci_irq_level_or_edge(3, 1); + nile4_set_pci_irq_level_or_edge(4, 1); + + /* PCI INTA#-D# must be active low, INTE# must be active high */ + nile4_set_pci_irq_polarity(0, 0); + nile4_set_pci_irq_polarity(1, 0); + nile4_set_pci_irq_polarity(2, 0); + nile4_set_pci_irq_polarity(3, 0); + nile4_set_pci_irq_polarity(4, 1); + + for (i = 0; i < 16; i++) + nile4_clear_irq(i); + + /* Enable CPU int #0 */ + nile4_enable_irq_output(0); + + for (i= base; i< base + NUM_NILE4_INTERRUPTS; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 1; + irq_desc[i].handler = &nile4_irq_controller; + } + +#if 0 + request_mem_region(NILE4_BASE, NILE4_SIZE, "Nile 4"); +#endif +} + +#if defined(CONFIG_LL_DEBUG) +void nile4_dump_irq_status(void) +{ + printk(KERN_DEBUG " + CPUSTAT = %p:%p\n", (void *) ddb_in32(DDB_CPUSTAT + 4), + (void *) ddb_in32(DDB_CPUSTAT)); + printk(KERN_DEBUG " + INTCTRL = %p:%p\n", (void *) ddb_in32(DDB_INTCTRL + 4), + (void *) ddb_in32(DDB_INTCTRL)); + printk(KERN_DEBUG + "INTSTAT0 = %p:%p\n", + (void *) ddb_in32(DDB_INTSTAT0 + 4), + (void *) ddb_in32(DDB_INTSTAT0)); + printk(KERN_DEBUG + "INTSTAT1 = %p:%p\n", + (void *) ddb_in32(DDB_INTSTAT1 + 4), + (void *) ddb_in32(DDB_INTSTAT1)); + printk(KERN_DEBUG + "INTCLR = %p:%p\n", (void *) ddb_in32(DDB_INTCLR + 4), + (void *) ddb_in32(DDB_INTCLR)); + printk(KERN_DEBUG + "INTPPES = %p:%p\n", (void *) ddb_in32(DDB_INTPPES + 4), + (void *) ddb_in32(DDB_INTPPES)); +} + +#endif diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/pci.c linux-ddb/arch/mips/ddb5xxx/ddb5074/pci.c --- linux-cvs/arch/mips/ddb5xxx/ddb5074/pci.c Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/pci.c Sun Dec 30 20:39:32 2001 @@ -0,0 +1,128 @@ +#include +#include +#include +#include + +#include +#include + +#include + +static struct resource extpci_io_resource = { + "pci IO space", + 0x1000, /* leave some room for ISA bus */ + DDB_PCI_IO_SIZE -1, + IORESOURCE_IO}; + +static struct resource extpci_mem_resource = { + "pci memory space", + DDB_PCI_MEM_BASE + 0x00100000, /* leave 1 MB for RTC */ + DDB_PCI_MEM_BASE + DDB_PCI_MEM_SIZE -1, + IORESOURCE_MEM}; + +extern struct pci_ops ddb5476_ext_pci_ops; + +struct pci_channel mips_pci_channels[] = { + { &ddb5476_ext_pci_ops, &extpci_io_resource, &extpci_mem_resource }, + { NULL, NULL, NULL} +}; + +#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 MAX_SLOT_NUM 14 + +static unsigned char irq_map[MAX_SLOT_NUM] = { + /* SLOT: 0 */ nile4_to_irq(PCI_EXT_INTE), + /* SLOT: 1 */ nile4_to_irq(PCI_EXT_INTA), + /* SLOT: 2 */ nile4_to_irq(PCI_EXT_INTA), + /* SLOT: 3 */ nile4_to_irq(PCI_EXT_INTB), + /* SLOT: 4 */ nile4_to_irq(PCI_EXT_INTC), + /* SLOT: 5 */ nile4_to_irq(NILE4_INT_UART), + /* SLOT: 6 */ 0xff, + /* SLOT: 7 */ 0xff, + /* SLOT: 8 */ 0xff, + /* SLOT: 9 */ 0xff, + /* SLOT: 10 */ 0xff, + /* SLOT: 11 */ 0xff, + /* SLOT: 12 */ 0xff, + /* SLOT: 13 */ nile4_to_irq(PCI_EXT_INTE), +}; + +void __init pcibios_fixup_irqs(void) { + + struct pci_dev *dev; + int slot_num; + + pci_for_each_dev(dev) { + slot_num = PCI_SLOT(dev->devfn); + db_assert(slot_num < MAX_SLOT_NUM); + db_assert(irq_map[slot_num] != 0xff); + + pci_write_config_byte(dev, + PCI_INTERRUPT_LINE, + irq_map[slot_num]); + + dev->irq = irq_map[slot_num]; + } +} + +void __init ddb_pci_reset_bus(void) +{ + u32 temp; + + /* + * I am not sure about the "official" procedure, the following + * steps work as far as I know: + * We first set PCI cold reset bit (bit 31) in PCICTRL-H. + * Then we clear the PCI warm reset bit (bit 30) to 0 in PCICTRL-H. + * The same is true for both PCI channels. + */ + temp = ddb_in32(DDB_PCICTRL+4); + temp |= 0x80000000; + ddb_out32(DDB_PCICTRL+4, temp); + temp &= ~0xc0000000; + ddb_out32(DDB_PCICTRL+4, temp); + +} + +unsigned __init int pcibios_assign_all_busses(void) +{ + /* we hope pci_auto has assigned the bus numbers to all buses */ + return 1; +} + +void __init pcibios_fixup_resources(struct pci_dev *dev) +{ +} + +void __init pcibios_fixup(void) +{ + struct pci_dev *dev; + + pci_for_each_dev(dev) { + if (dev->vendor == PCI_VENDOR_ID_AL && + dev->device == PCI_DEVICE_ID_AL_M7101) { + /* + * It's nice to have the LEDs on the GPIO pins + * available for debugging + */ + extern struct pci_dev *pci_pmu; + u8 t8; + + pci_pmu = dev; /* for LEDs D2 and D3 */ + /* Program the lines for LEDs D2 and D3 to output */ + pci_read_config_byte(dev, 0x7d, &t8); + t8 |= 0xc0; + pci_write_config_byte(dev, 0x7d, t8); + /* Turn LEDs D2 and D3 off */ + pci_read_config_byte(dev, 0x7e, &t8); + t8 |= 0xc0; + pci_write_config_byte(dev, 0x7e, t8); + } + } +} + diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/pci_ops.c linux-ddb/arch/mips/ddb5xxx/ddb5074/pci_ops.c --- linux-cvs/arch/mips/ddb5xxx/ddb5074/pci_ops.c Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/pci_ops.c Fri Jan 11 21:42:46 2002 @@ -0,0 +1,345 @@ +/* + * Copyright 2001 MontaVista Software Inc. + * Author: Jun Sun, jsun@mvista.com or jsun@junsun.net + * + * arch/mips/ddb5xxx/ddb5476/pci_ops.c + * Define the pci_ops for DB5477. + * + * Much of the code is derived from the original DDB5074 port by + * Geert Uytterhoeven + * + * 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 + +/* + * config_swap structure records what set of pdar/pmr are used + * to access pci config space. It also provides a place hold the + * original values for future restoring. + */ +struct pci_config_swap { + u32 pdar; + u32 pmr; + u32 config_base; + u32 config_size; + u32 pdar_backup; + u32 pmr_backup; +}; + +/* + * On DDB5476, we have one set of swap registers + */ +struct pci_config_swap ext_pci_swap = { + DDB_PCIW0, + DDB_PCIINIT0, + DDB_PCI_CONFIG_BASE, + DDB_PCI_CONFIG_SIZE +}; + +static int pci_config_workaround=1; + +/* + * access config space + */ +static inline u32 ddb_access_config_base(struct pci_config_swap *swap, + u32 bus,/* 0 means top level bus */ + u32 slot_num) +{ + u32 pci_addr = 0; + u32 pciinit_offset = 0; + u32 virt_addr = swap->config_base; + u32 option; + + if (pci_config_workaround) { + /* [jsun] work around Vrc5476 controller itself */ + if (slot_num == 12) slot_num = 0; + + /* BUG : skip P2P bridge for now */ + if (slot_num == 5) slot_num = 0; + } else { + if (slot_num == 12) return DDB_BASE + DDB_PCI_BASE; + } + + /* minimum pdar (window) size is 2MB */ + db_assert(swap->config_size >= (2 << 20)); + + db_assert(slot_num < (1 << 5)); + db_assert(bus < (1 << 8)); + + /* backup registers */ + swap->pdar_backup = ddb_in32(swap->pdar); + swap->pmr_backup = ddb_in32(swap->pmr); + + /* set the pdar (pci window) register */ + ddb_set_pdar(swap->pdar, + swap->config_base, + swap->config_size, + 32, /* 32 bit wide */ + 0, /* not on local memory bus */ + 0); /* not visible from PCI bus (N/A) */ + + /* + * calcuate the absolute pci config addr; + * according to the spec, we start scanning from adr:11 (0x800) + */ + if (bus == 0) { + /* type 0 config */ + pci_addr = 0x00040000 << slot_num; + } else { + /* type 1 config */ + pci_addr = 0x00040000 << slot_num; + panic("ddb_access_config_base: we don't support type 1 config Yet"); + } + + /* + * if pci_addr is less than pci config window size, we set + * pciinit_offset to 0 and adjust the virt_address. + * Otherwise we will try to adjust pciinit_offset. + */ + if (pci_addr < swap->config_size) { + virt_addr = KSEG1ADDR(swap->config_base + pci_addr); + pciinit_offset = 0; + } else { + db_assert( (pci_addr & (swap->config_size - 1)) == 0); + virt_addr = KSEG1ADDR(swap->config_base); + pciinit_offset = pci_addr; + } + + /* set the pmr register */ + option = DDB_PCI_ACCESS_32; + if (bus != 0) option |= DDB_PCI_CFGTYPE1; + ddb_set_pmr(swap->pmr, DDB_PCICMD_CFG, pciinit_offset, option); + + return virt_addr; +} + +static inline void ddb_close_config_base(struct pci_config_swap *swap) +{ + ddb_out32(swap->pdar, swap->pdar_backup); + ddb_out32(swap->pmr, swap->pmr_backup); +} + +static int read_config_dword(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u32 *val) +{ + u32 bus, slot_num, func_num; + u32 base; + + db_assert((where & 3) == 0); + db_assert(where < (1 << 8)); + + /* check if the bus is top-level */ + if (dev->bus->parent != NULL) { + bus = dev->bus->number; + db_assert(bus != 0); + } else { + bus = 0; + } + + slot_num = PCI_SLOT(dev->devfn); + func_num = PCI_FUNC(dev->devfn); + base = ddb_access_config_base(swap, bus, slot_num); + *val = *(volatile u32*) (base + (func_num << 8) + where); + ddb_close_config_base(swap); + return PCIBIOS_SUCCESSFUL; +} + +static int read_config_word(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u16 *val) +{ + int status; + u32 result; + + db_assert((where & 1) == 0); + + status = read_config_dword(swap, dev, where & ~3, &result); + if (where & 2) result >>= 16; + *val = result & 0xffff; + return status; +} + +static int read_config_byte(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u8 *val) +{ + int status; + u32 result; + + status = read_config_dword(swap, dev, where & ~3, &result); + if (where & 1) result >>= 8; + if (where & 2) result >>= 16; + *val = result & 0xff; + return status; +} + +static int write_config_dword(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u32 val) +{ + u32 bus, slot_num, func_num; + u32 base; + + db_assert((where & 3) == 0); + db_assert(where < (1 << 8)); + + /* check if the bus is top-level */ + if (dev->bus->parent != NULL) { + bus = dev->bus->number; + db_assert(bus != 0); + } else { + bus = 0; + } + + slot_num = PCI_SLOT(dev->devfn); + func_num = PCI_FUNC(dev->devfn); + base = ddb_access_config_base(swap, bus, slot_num); + *(volatile u32*) (base + (func_num << 8) + where) = val; + ddb_close_config_base(swap); + return PCIBIOS_SUCCESSFUL; +} + +static int write_config_word(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u16 val) +{ + int status, shift=0; + u32 result; + + db_assert((where & 1) == 0); + + status = read_config_dword(swap, dev, where & ~3, &result); + if (status != PCIBIOS_SUCCESSFUL) return status; + + if (where & 2) + shift += 16; + result &= ~(0xffff << shift); + result |= val << shift; + return write_config_dword(swap, dev, where & ~3, result); +} + +static int write_config_byte(struct pci_config_swap *swap, + struct pci_dev *dev, + u32 where, + u8 val) +{ + int status, shift=0; + u32 result; + + status = read_config_dword(swap, dev, where & ~3, &result); + if (status != PCIBIOS_SUCCESSFUL) return status; + + if (where & 2) + shift += 16; + if (where & 1) + shift += 8; + result &= ~(0xff << shift); + result |= val << shift; + return write_config_dword(swap, dev, where & ~3, result); +} + +#define MAKE_PCI_OPS(prefix, rw, unitname, unittype, pciswap) \ +static int prefix##_##rw##_config_##unitname(struct pci_dev *dev, int where, unittype val) \ +{ \ + return rw##_config_##unitname(pciswap, \ + dev, \ + where, \ + val); \ +} + +MAKE_PCI_OPS(extpci, read, byte, u8 *, &ext_pci_swap) +MAKE_PCI_OPS(extpci, read, word, u16 *, &ext_pci_swap) +MAKE_PCI_OPS(extpci, read, dword, u32 *, &ext_pci_swap) + +MAKE_PCI_OPS(extpci, write, byte, u8, &ext_pci_swap) +MAKE_PCI_OPS(extpci, write, word, u16, &ext_pci_swap) +MAKE_PCI_OPS(extpci, write, dword, u32, &ext_pci_swap) + +struct pci_ops ddb5476_ext_pci_ops ={ + extpci_read_config_byte, + extpci_read_config_word, + extpci_read_config_dword, + extpci_write_config_byte, + extpci_write_config_word, + extpci_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; + + pci_config_workaround = 0; + + 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< 1; j++) { + printk(KERN_INFO "scan ddb5476 external PCI bus:\n"); + bus.ops = &ddb5476_ext_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(KERN_INFO "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++) { + if ((i%4) == 0) + printk(KERN_INFO); + db_verify(pci_read_config_dword(&dev, i*4, &temp), + == PCIBIOS_SUCCESSFUL); + printk("\t%08X", temp); + if ((i%4) == 3) + printk("\n"); + } + } + } + + pci_config_workaround = 1; +} +#endif diff -uN -r --exclude=CVS linux-cvs/arch/mips/ddb5xxx/ddb5074/setup.c linux-ddb/arch/mips/ddb5xxx/ddb5074/setup.c --- linux-cvs/arch/mips/ddb5xxx/ddb5074/setup.c Thu Jan 1 01:00:00 1970 +++ linux-ddb/arch/mips/ddb5xxx/ddb5074/setup.c Sat Jan 12 21:31:05 2002 @@ -0,0 +1,246 @@ +/* + * arch/mips/ddb5074/setup.c -- NEC DDB Vrc-5074 setup routines + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifdef CONFIG_REMOTE_DEBUG +extern void rs_kgdb_hook(int); +extern void breakpoint(void); +#endif + +#if defined(CONFIG_SERIAL_CONSOLE) +extern void console_setup(char *); +#endif + +extern struct ide_ops std_ide_ops; + +static void (*back_to_prom) (void) = (void (*)(void)) 0xbfc00000; + +static void ddb_machine_restart(char *command) +{ + u32 t; + + /* PCI cold reset */ + t = nile4_in32(NILE4_PCICTRL + 4); + t |= 0x40000000; + nile4_out32(NILE4_PCICTRL + 4, t); + /* CPU cold reset */ + t = nile4_in32(NILE4_CPUSTAT); + t |= 1; + nile4_out32(NILE4_CPUSTAT, t); + /* Call the PROM */ + back_to_prom(); +} + +static void ddb_machine_halt(void) +{ + printk("DDB Vrc-5074 halted.\n"); + do { + } while (1); +} + +static void ddb_machine_power_off(void) +{ + printk("DDB Vrc-5074 halted. Please turn off the power.\n"); + do { + } while (1); +} + +extern void ddb_irq_setup(void); + +extern void (*board_timer_setup) (struct irqaction * irq); + +void __init bus_error_init(void) +{ +} + +static void __init ddb_time_init(struct irqaction *irq) +{ + /* set the clock to 1 Hz */ + nile4_out32(NILE4_T2CTRL, 1000000); + /* enable the General-Purpose Timer */ + nile4_out32(NILE4_T2CTRL + 4, 0x00000001); + /* reset timer */ + nile4_out32(NILE4_T2CNTR, 0); + /* enable interrupt */ + nile4_enable_irq(NILE4_INT_GPT); + setup_irq(nile4_to_irq(NILE4_INT_GPT), irq); + change_cp0_status(ST0_IM, + IE_IRQ0 | IE_IRQ1 | IE_IRQ2 | IE_IRQ3 | IE_IRQ4); +} + +void __init ddb_setup(void) +{ + extern int panic_timeout; + + irq_setup = ddb_irq_setup; + set_io_port_base(NILE4_PCI_IO_BASE); + isa_slot_offset = NILE4_PCI_MEM_BASE; + board_timer_setup = ddb_time_init; + + _machine_restart = ddb_machine_restart; + _machine_halt = ddb_machine_halt; + _machine_power_off = ddb_machine_power_off; + +#ifdef CONFIG_BLK_DEV_IDE + ide_ops = &std_ide_ops; +#endif + +printk("PDAR0: %08x, PDAR1: %08x\n",ddb_in32(DDB_SDRAM0),ddb_in32(DDB_SDRAM1)); + + /* Reboot on panic */ + panic_timeout = 180; +} + + +#define USE_NILE4_SERIAL 0 + +#if USE_NILE4_SERIAL +#define ns16550_in(reg) nile4_in8((reg)*8) +#define ns16550_out(reg, val) nile4_out8((reg)*8, (val)) +#else +#define NS16550_BASE (NILE4_PCI_IO_BASE+0x03f8) +static inline u8 ns16550_in(u32 reg) +{ + return *(volatile u8 *) (NS16550_BASE + reg); +} + +static inline void ns16550_out(u32 reg, u8 val) +{ + *(volatile u8 *) (NS16550_BASE + reg) = val; +} +#endif + +#define NS16550_RBR 0 +#define NS16550_THR 0 +#define NS16550_DLL 0 +#define NS16550_IER 1 +#define NS16550_DLM 1 +#define NS16550_FCR 2 +#define NS16550_IIR 2 +#define NS16550_LCR 3 +#define NS16550_MCR 4 +#define NS16550_LSR 5 +#define NS16550_MSR 6 +#define NS16550_SCR 7 + +#define NS16550_LSR_DR 0x01 /* Data ready */ +#define NS16550_LSR_OE 0x02 /* Overrun */ +#define NS16550_LSR_PE 0x04 /* Parity error */ +#define NS16550_LSR_FE 0x08 /* Framing error */ +#define NS16550_LSR_BI 0x10 /* Break */ +#define NS16550_LSR_THRE 0x20 /* Xmit holding register empty */ +#define NS16550_LSR_TEMT 0x40 /* Xmitter empty */ +#define NS16550_LSR_ERR 0x80 /* Error */ + + +void _serinit(void) +{ +#if USE_NILE4_SERIAL + ns16550_out(NS16550_LCR, 0x80); + ns16550_out(NS16550_DLM, 0x00); + ns16550_out(NS16550_DLL, 0x36); /* 9600 baud */ + ns16550_out(NS16550_LCR, 0x00); + ns16550_out(NS16550_LCR, 0x03); + ns16550_out(NS16550_FCR, 0x47); +#else + /* done by PMON */ +#endif +} + +void _putc(char c) +{ + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_THRE)); + ns16550_out(NS16550_THR, c); + if (c == '\n') { + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_THRE)); + ns16550_out(NS16550_THR, '\r'); + } +} + +void _puts(const char *s) +{ + char c; + while ((c = *s++)) + _putc(c); +} + +char _getc(void) +{ + while (!(ns16550_in(NS16550_LSR) & NS16550_LSR_DR)); + return ns16550_in(NS16550_RBR); +} + +int _testc(void) +{ + return (ns16550_in(NS16550_LSR) & NS16550_LSR_DR) != 0; +} + + +/* + * Hexadecimal 7-segment LED + */ +void ddb5074_led_hex(int hex) +{ + outb(hex, 0x80); +} + + +/* + * LEDs D2 and D3, connected to the GPIO pins of the PMU in the ALi M1543 + */ +struct pci_dev *pci_pmu = NULL; + +void ddb5074_led_d2(int on) +{ + u8 t; + + if (pci_pmu) { + pci_read_config_byte(pci_pmu, 0x7e, &t); + if (on) + t &= 0x7f; + else + t |= 0x80; + pci_write_config_byte(pci_pmu, 0x7e, t); + } +} + +void ddb5074_led_d3(int on) +{ + u8 t; + + if (pci_pmu) { + pci_read_config_byte(pci_pmu, 0x7e, &t); + if (on) + t &= 0xbf; + else + t |= 0x40; + pci_write_config_byte(pci_pmu, 0x7e, t); + } +} diff -uN -r --exclude=CVS linux-cvs/drivers/net/tulip/interrupt.c linux-ddb/drivers/net/tulip/interrupt.c --- linux-cvs/drivers/net/tulip/interrupt.c Sun Dec 2 12:34:45 2001 +++ linux-ddb/drivers/net/tulip/interrupt.c Sat Jan 12 20:41:44 2002 @@ -186,6 +186,9 @@ tp->rx_buffers[entry].skb->tail, pkt_len); #endif +#if defined(__mips__) + dma_cache_inv((unsigned long)bus_to_virt(tp->rx_ring[entry].buffer1),pkt_len); +#endif } else { /* Pass up the skb already on the Rx ring. */ char *temp = skb_put(skb = tp->rx_buffers[entry].skb, pkt_len); diff -uN -r --exclude=CVS linux-cvs/drivers/net/tulip/tulip.h linux-ddb/drivers/net/tulip/tulip.h --- linux-cvs/drivers/net/tulip/tulip.h Sun Dec 2 12:34:45 2001 +++ linux-ddb/drivers/net/tulip/tulip.h Sat Jan 12 22:31:36 2002 @@ -29,7 +29,7 @@ /* undefine, or define to various debugging levels (>4 == obscene levels) */ -#define TULIP_DEBUG 1 +#define TULIP_DEBUG 5 /* undefine USE_IO_OPS for MMIO, define for PIO */ #ifdef CONFIG_TULIP_MMIO diff -uN -r --exclude=CVS linux-cvs/drivers/net/tulip/tulip_core.c linux-ddb/drivers/net/tulip/tulip_core.c --- linux-cvs/drivers/net/tulip/tulip_core.c Wed Dec 19 01:03:24 2001 +++ linux-ddb/drivers/net/tulip/tulip_core.c Sat Jan 12 22:25:08 2002 @@ -93,6 +93,8 @@ static int csr0 = 0x01A00000 | 0x9000; #elif defined(__arm__) || defined(__sh__) static int csr0 = 0x01A00000 | 0x4800; +#elif defined(__mips__) +static int csr0 = 0x00200000 | 0x4000; #else #warning Processor architecture undefined! static int csr0 = 0x00A00000 | 0x4800; @@ -315,6 +317,11 @@ tp->tx_buffers[tp->cur_tx].skb = NULL; tp->tx_buffers[tp->cur_tx].mapping = mapping; +#if defined(__mips__) + dma_cache_wback_inv((unsigned long)tp->setup_frame, + sizeof(tp->setup_frame)); +#endif + /* Put the setup frame on the Tx list. */ tp->tx_ring[tp->cur_tx].length = cpu_to_le32(0x08000000 | 192); tp->tx_ring[tp->cur_tx].buffer1 = cpu_to_le32(mapping); @@ -618,6 +625,10 @@ PKT_BUF_SZ, PCI_DMA_FROMDEVICE); tp->rx_buffers[i].mapping = mapping; skb->dev = dev; /* Mark as being used by this device. */ +#if defined(__mips__) + /* Kick out any matching lines in the cache. */ + dma_cache_inv((unsigned long)skb->tail, PKT_BUF_SZ); +#endif tp->rx_ring[i].status = cpu_to_le32(DescOwned); /* Owned by Tulip chip */ tp->rx_ring[i].buffer1 = cpu_to_le32(mapping); } @@ -670,6 +681,11 @@ /* if we were using Transmit Automatic Polling, we would need a * wmb() here. */ tp->tx_ring[entry].status = cpu_to_le32(DescOwned); + printk("tp->tx_ring[entry].status: %08x, tp->tx_ring[entry].length: %d", + tp->tx_ring[entry].status,tp->tx_ring[entry].length & ~flag); +#if defined(__mips__) + dma_cache_wback_inv((unsigned long)skb->data, skb->len); +#endif wmb(); tp->cur_tx++; @@ -1384,6 +1400,7 @@ ioaddr = pci_resource_start (pdev, 0); irq = pdev->irq; + /* alloc_etherdev ensures aligned and zeroed private structures */ dev = alloc_etherdev (sizeof (*tp)); if (!dev) { @@ -1428,6 +1445,8 @@ tp->tx_ring = (struct tulip_tx_desc *)(tp->rx_ring + RX_RING_SIZE); tp->tx_ring_dma = tp->rx_ring_dma + sizeof(struct tulip_rx_desc) * RX_RING_SIZE; + printk("tp->tx_ring: %p\n",tp->tx_ring); + tp->chip_id = chip_idx; tp->flags = tulip_tbl[chip_idx].flags; tp->pdev = pdev; @@ -1515,6 +1534,16 @@ /* No media table either */ tp->flags &= ~HAS_MEDIA_TABLE; } +#endif +#ifdef CONFIG_DDB5074 +printk("PCI_SLOT(pdev->devfn): %d\n",PCI_SLOT(pdev->devfn)); + if ((pdev->bus->number == 0) && (PCI_SLOT(pdev->devfn) == 1)) { + /* DDB5477 MAC address in first EEPROM locations. */ + sa_offset = 0; + /* No media table either */ + tp->flags &= ~HAS_MEDIA_TABLE; + } + #endif for (i = 0; i < 6; i ++) { dev->dev_addr[i] = ee_data[i + sa_offset]; diff -uN -r --exclude=CVS linux-cvs/drivers/video/matrox/matroxfb_Ti3026.c linux-ddb/drivers/video/matrox/matroxfb_Ti3026.c --- linux-cvs/drivers/video/matrox/matroxfb_Ti3026.c Mon Nov 5 21:16:16 2001 +++ linux-ddb/drivers/video/matrox/matroxfb_Ti3026.c Sat Jan 12 21:51:17 2002 @@ -667,7 +667,7 @@ udelay(10); } if (!tmout) - printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs\n"); + printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs, %02x\n",inTi3026(PMINFO TVP3026_XPIXPLLDATA)); } static void ti3026_ramdac_init(WPMINFO struct matrox_hw_state* hw){ @@ -754,7 +754,7 @@ CRITEND if (!tmout) - printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs\n"); + printk(KERN_ERR "matroxfb: Pixel PLL not locked after 5 secs,%02x\n",inTi3026(PMINFO TVP3026_XPIXPLLDATA)); else dprintk(KERN_INFO "PixelPLL: %d\n", 500000-tmout); CRITBEGIN diff -uN -r --exclude=CVS linux-cvs/drivers/video/matrox/matroxfb_misc.c linux-ddb/drivers/video/matrox/matroxfb_misc.c --- linux-cvs/drivers/video/matrox/matroxfb_misc.c Sun Dec 2 12:34:52 2001 +++ linux-ddb/drivers/video/matrox/matroxfb_misc.c Sat Jan 12 22:30:54 2002 @@ -127,12 +127,15 @@ void matroxfb_DAC_out(CPMINFO int reg, int val) { DBG_REG("outDAC"); mga_outb(M_RAMDAC_BASE+M_X_INDEX, reg); + wmb(); mga_outb(M_RAMDAC_BASE+M_X_DATAREG, val); + wmb(); } int matroxfb_DAC_in(CPMINFO int reg) { DBG_REG("inDAC"); mga_outb(M_RAMDAC_BASE+M_X_INDEX, reg); + wmb(); return mga_inb(M_RAMDAC_BASE+M_X_DATAREG); } diff -uN -r --exclude=CVS linux-cvs/include/asm-mips/ddb5xxx/ddb5074.h linux-ddb/include/asm-mips/ddb5xxx/ddb5074.h --- linux-cvs/include/asm-mips/ddb5xxx/ddb5074.h Thu Jan 1 01:00:00 1970 +++ linux-ddb/include/asm-mips/ddb5xxx/ddb5074.h Sun Dec 30 19:30:43 2001 @@ -0,0 +1,38 @@ +/* + * include/asm-mips/ddb5074.h -- NEC DDB Vrc-5074 definitions + * + * Copyright (C) 2000 Geert Uytterhoeven + * Sony Software Development Center Europe (SDCE), Brussels + */ + +#ifndef _ASM_DDB5XXX_DDB5074_H +#define _ASM_DDB5XXX_DDB5074_H + +#include + +#define DDB_SDRAM_SIZE 0x04000000 /* 64MB */ + +#define DDB_PCI_IO_BASE 0x06000000 +#define DDB_PCI_IO_SIZE 0x02000000 /* 32 MB */ + +#define DDB_PCI_MEM_BASE 0x08000000 +#define DDB_PCI_MEM_SIZE 0x08000000 /* 128 MB */ + +#define DDB_PCI_CONFIG_BASE DDB_PCI_MEM_BASE +#define DDB_PCI_CONFIG_SIZE DDB_PCI_MEM_SIZE + +#define NILE4_PCI_IO_BASE 0xa6000000 +#define NILE4_PCI_MEM_BASE 0xa8000000 +#define NILE4_PCI_CFG_BASE NILE4_PCI_MEM_BASE +#define DDB_PCI_IACK_BASE NILE4_PCI_IO_BASE + +#define NILE4_IRQ_BASE NUM_I8259_INTERRUPTS +#define CPU_IRQ_BASE NUM_NILE4_INTERRUPTS +#define CPU_NILE4_CASCADE 2 + +extern void ddb5074_led_hex(int hex); +extern void ddb5074_led_d2(int on); +extern void ddb5074_led_d3(int on); + +extern void nile4_irq_setup(u32 base); +#endif diff -uN -r --exclude=CVS linux-cvs/include/asm-mips/nile4.h linux-ddb/include/asm-mips/nile4.h --- linux-cvs/include/asm-mips/nile4.h Thu Sep 6 15:12:02 2001 +++ linux-ddb/include/asm-mips/nile4.h Wed Dec 26 17:32:24 2001 @@ -9,6 +9,9 @@ * NEC Vrc 5074 System Controller Data Sheet, June 1998 */ +#ifndef _ASM_NILE4_H +#define _ASM_NILE4_H + #define NILE4_BASE 0xbfa00000 #define NILE4_SIZE 0x00200000 /* 2 MB */ @@ -303,3 +306,4 @@ extern u8 nile4_i8259_iack(void); extern void nile4_dump_irq_status(void); /* Debug */ +#endif diff -uN -r --exclude=CVS linux-cvs/init/main.c linux-ddb/init/main.c --- linux-cvs/init/main.c Wed Dec 19 01:04:01 2001 +++ linux-ddb/init/main.c Fri Jan 11 16:36:17 2002 @@ -77,9 +77,11 @@ * To avoid associated bogus bug reports, we flatly refuse to compile * with a gcc that is known to be too old from the very beginning. */ +#if 0 #if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 91) #error Sorry, your GCC is too old. It builds incorrect kernels. #endif +#endif extern char _stext, _etext; extern char *linux_banner; diff -u linux-cvs/arch/mips/config.in linux-ddb/arch/mips/config.in --- linux-cvs/arch/mips/config.in Wed Jan 2 18:10:36 2002 +++ linux-ddb/arch/mips/config.in Sun Dec 30 19:49:32 2001 @@ -183,9 +176,12 @@ define_bool CONFIG_I8259 y define_bool CONFIG_ISA y define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_IRQ_CPU y define_bool CONFIG_PCI y + define_bool CONFIG_NEW_PCI y + define_bool CONFIG_PCI_AUTO y define_bool CONFIG_PC_KEYB y - define_bool CONFIG_OLD_TIME_C y + define_bool CONFIG_NEW_TIME_C y fi if [ "$CONFIG_DDB5476" = "y" ]; then define_bool CONFIG_ISA y --u3/rZRmxL6MmkK24-- From owner-linux-mips@oss.sgi.com Mon Jan 14 16:06:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F060U26798 for linux-mips-outgoing; Mon, 14 Jan 2002 16:06:00 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F05vg26795 for ; Mon, 14 Jan 2002 16:05:57 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0EN5sX29314; Mon, 14 Jan 2002 15:05:54 -0800 Date: Mon, 14 Jan 2002 15:05:54 -0800 From: Ralf Baechle To: Matthew Dharm Cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114150554.A29242@dea.linux-mips.net> References: <20020113211323.A7115@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020113211323.A7115@momenco.com>; from mdharm@momenco.com on Sun, Jan 13, 2002 at 09:13:23PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1168 Lines: 28 On Sun, Jan 13, 2002 at 09:13:23PM -0800, Matthew Dharm wrote: > As I understand it, 64-bit support is really two different things: 64-bit > data path (i.e. unsigned long long) and 64-bit addressing (for more than 4G > of RAM). Right but due to the CPU architecture of pre-MIPS64 CPUs they always come together unless the software does funny attempts at truncating OS support to just 32-bit. So the 32-bit kernel gives you none of the two, the mips64 kernel both. > My understanding is that "MIPS64" generally refers to a kernel which > supports a 64-bit data path, but we're still limited to 32-bit addressing. > Is that correct? MIPS64 is MIPS's MIPS64 processor architecture, mips64 is the 64-bit kernel. That may sound like nitpicking but it's important to understand that both are not the same. > I suspect that this is very much a toolchain issue, as I don't think gcc > will generate 64-bit addressing code. Gcc is fine; the problem are binutils, that is as and ld. As a result of the gcc problems we don't have a 64-bit userspace either so all software running on 64-bit kernels is currently old 32-bit software running in compatibility mode. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:07:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F07un26881 for linux-mips-outgoing; Mon, 14 Jan 2002 16:07:56 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F07rg26877 for ; Mon, 14 Jan 2002 16:07:53 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0EN7p329325; Mon, 14 Jan 2002 15:07:51 -0800 Date: Mon, 14 Jan 2002 15:07:51 -0800 From: Ralf Baechle To: Jason Gunthorpe Cc: Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114150751.B29242@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgg@debian.org on Mon, Jan 14, 2002 at 01:42:22PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 540 Lines: 12 On Mon, Jan 14, 2002 at 01:42:22PM -0700, Jason Gunthorpe wrote: > I have such hardware myself. IMHO the best option is the mips64 kernel and > I hope to try it someday. But in practice I'd guess that Ralf's highmem > patch is more likely to be usuable first (?). Depends if you can live with the problems of the current mips64 kernel. If you can then it's highmem-free memory managment is certainly the way to go. It's also not limited to peanuts numbers of gigabytes but can support as much memory as your can tack on a MIPS. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:09:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F09GV26979 for linux-mips-outgoing; Mon, 14 Jan 2002 16:09:16 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F09Eg26976 for ; Mon, 14 Jan 2002 16:09:14 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0EN9Bq29346; Mon, 14 Jan 2002 15:09:11 -0800 Date: Mon, 14 Jan 2002 15:09:11 -0800 From: Ralf Baechle To: Dominic Sweetman Cc: Matthew Dharm , Jason Gunthorpe , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114150911.C29242@dea.linux-mips.net> References: <15427.19160.15187.23375@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15427.19160.15187.23375@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Jan 14, 2002 at 09:17:12PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 560 Lines: 17 On Mon, Jan 14, 2002 at 09:17:12PM +0000, Dominic Sweetman wrote: > > I guess what I'm looking for is what I should tell someone who wants > > to run MIPS Linux 64-bit with 8 gigs of RAM. > > "Ask Ralf". (at least, that's the best advice for the kernel, which > he worked on at SGI). Tested with upto 128gb :-) > For a compiler, you should ask Algorithmics. We haven't tried the > 64-bit configuration yet, but we've done lots of GCC variants and it's > only a program... May I have full support for N32 and N64 tomorrow after lunch, please ;-) Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:23:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0N6U27237 for linux-mips-outgoing; Mon, 14 Jan 2002 16:23:06 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F0Mxg27234 for ; Mon, 14 Jan 2002 16:22:59 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0ENMu229444; Mon, 14 Jan 2002 15:22:56 -0800 Date: Mon, 14 Jan 2002 15:22:56 -0800 From: Ralf Baechle To: Dominic Sweetman Cc: Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114152256.D29242@dea.linux-mips.net> References: <20020113211323.A7115@momenco.com> <15426.48692.795968.819750@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15426.48692.795968.819750@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Jan 14, 2002 at 11:17:08AM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2999 Lines: 73 On Mon, Jan 14, 2002 at 11:17:08AM +0000, Dominic Sweetman wrote: > o Very large virtual address spaces, using 64-bit pointer types. Actually I only implemented support for something like 0.5TB. As for supercomputing that's peanuts (Like five years ago a customer requested SGI to increase the per process size of the address space from 1TB, the limit of the R4000 to 16TB, the limit of R10000 class processors.) > o C "long" (and perhaps even "int") becomes 64-bit. We follow the MIPS ABI which uses 32-bit ints and 64-bit longs. > In such a 64-bit Linux system, though, you might still want to be able > to run 32-bit applications with 32-bit pointers, int and long - either > for compatibility or economy (32-bit data types make for a smaller > program). SGI do this in Irix: I don't know whether the 64-bit > Linux/MIPS systems got around to it. Yes. The environment provided however is slightly different. 32-bit software on the mips64 kernel is running with UX=1 thus 64-bit instructions are allowed. > There are other potentially useful combinations: > > o A Linux where all machine-supported integer data types are 32-bit, I don't want to support 32-bit char and short, sorry :-) > but capable of addressing physical memory outside of a 4Gbyte map. > (In practice, you need to use this kind of system to get outside of > a 512Mbyte map - so it's urgent). I'd be working on this right now if you'd not be bothering me with email ;-) > Ralf says he has done this: it could be done without using any > 64-bit operations, but it might be easier with them. There are still MIPS32 systems which don't support 64-bit operations just may have an address space of upto 36 bits. > o A system using 32-bit pointers and 'long' throughout, but with > support for 'long long' 64-bit integer data types in registers. > > o A system using 64-bit addressing within the kernel, but not for > applications. > > However, it's unlikely to make sense to do all of them! Correct. We may add support for the one or other code of these models over time. > > I suspect that this is very much a toolchain issue, as I don't think > > gcc will generate 64-bit addressing code. > > I suspect that the generic GNU toolchains are pretty buggy when you > switch on 64-bit MIPS operation; but it's bug-fixes which are needed, > not wholesale new features. Actually in the past somebody was doing paid work to get the combo g++ + SGI as + GNU ld to work for N32. Due to the similarity of N32 and N64 that already brought us quite a bit closer to N64 support. That still leaves alot of work including plenty of gas work. > Politics: MIPS Technologies' advocacy for their "MIPS32" instruction > set dialect in embedded systems means there are now some quite capable > MIPS CPUs (eg Alchemy's 500Mhz integrated CPUs) which don't have > 64-bit datapaths or arithmetic. So casual dependence on 64-bit > operations should probably be avoided. I'm doing the best to avoid that. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:23:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0NxR27318 for linux-mips-outgoing; Mon, 14 Jan 2002 16:23:59 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F0Nwg27315 for ; Mon, 14 Jan 2002 16:23:58 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0ENNtm29454; Mon, 14 Jan 2002 15:23:55 -0800 Date: Mon, 14 Jan 2002 15:23:55 -0800 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Dominic Sweetman , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114152355.E29242@dea.linux-mips.net> References: <20020113211323.A7115@momenco.com> <15426.48692.795968.819750@gladsmuir.algor.co.uk> <00ee01c19cfa$ab8d3640$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00ee01c19cfa$ab8d3640$0deca8c0@Ulysses>; from kevink@mips.com on Mon, Jan 14, 2002 at 01:54:42PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 404 Lines: 11 On Mon, Jan 14, 2002 at 01:54:42PM +0100, Kevin D. Kissell wrote: > The official MIPS64[tm] architecture spec from MIPS > Technologies also provides a bit (Status.PX) which enables > the 64-bit data path without affecting address generation > and translation, which removes this quirk. Only the very > most recent 64-bit cores and CPUs implement it, however. And Linux doesn't use PX at all. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:25:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0PxL27404 for linux-mips-outgoing; Mon, 14 Jan 2002 16:25:59 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F0Pmg27397; Mon, 14 Jan 2002 16:25:48 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0ENPiX11538; Mon, 14 Jan 2002 15:25:44 -0800 From: "Matthew Dharm" To: "Ralf Baechle" Cc: Subject: RE: MIPS64 status? Date: Mon, 14 Jan 2002 15:25:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020114150554.A29242@dea.linux-mips.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2363 Lines: 77 Ralf -- Thanks for the info. Too bad "MIPS64" and "mips64" sound exactly the same on the telephone. But, I need to be pedantic, just to be clear on a couple of questions... So, the "mips64" kernel can use 64-bits of address, for RAM >4G? But, the apps running are always 32-bit? Does this mean that any individual application can only use 4G of memory, tho you could have several applications in physical memory doing this? (i.e. multiple applications using 1G of RAM each, but not swapping to disk?) Does this mean we could map PCI memory/IO addresses above 4G and have it work? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle > Sent: Monday, January 14, 2002 3:06 PM > To: Matthew Dharm > Cc: linux-mips@oss.sgi.com > Subject: Re: MIPS64 status? > > > On Sun, Jan 13, 2002 at 09:13:23PM -0800, Matthew Dharm wrote: > > > As I understand it, 64-bit support is really two > different things: 64-bit > > data path (i.e. unsigned long long) and 64-bit addressing > (for more than 4G > > of RAM). > > Right but due to the CPU architecture of pre-MIPS64 CPUs > they always come > together unless the software does funny attempts at > truncating OS support > to just 32-bit. So the 32-bit kernel gives you none of the > two, the mips64 > kernel both. > > > My understanding is that "MIPS64" generally refers to a > kernel which > > supports a 64-bit data path, but we're still limited to > 32-bit addressing. > > Is that correct? > > MIPS64 is MIPS's MIPS64 processor architecture, mips64 is > the 64-bit kernel. > That may sound like nitpicking but it's important to > understand that both > are not the same. > > > I suspect that this is very much a toolchain issue, as I > don't think gcc > > will generate 64-bit addressing code. > > Gcc is fine; the problem are binutils, that is as and ld. > As a result of > the gcc problems we don't have a 64-bit userspace either so > all software > running on 64-bit kernels is currently old 32-bit software > running in > compatibility mode. > > Ralf > From owner-linux-mips@oss.sgi.com Mon Jan 14 16:45:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0jmQ27841 for linux-mips-outgoing; Mon, 14 Jan 2002 16:45:48 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0F0jig27837 for ; Mon, 14 Jan 2002 16:45:44 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0ENjgu30346; Mon, 14 Jan 2002 15:45:42 -0800 Date: Mon, 14 Jan 2002 15:45:42 -0800 From: Ralf Baechle To: Matthew Dharm Cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020114154542.A29462@dea.linux-mips.net> References: <20020114150554.A29242@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Mon, Jan 14, 2002 at 03:25:44PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1185 Lines: 31 On Mon, Jan 14, 2002 at 03:25:44PM -0800, Matthew Dharm wrote: > Thanks for the info. Too bad "MIPS64" and "mips64" sound exactly the > same on the telephone. > > But, I need to be pedantic, just to be clear on a couple of > questions... > > So, the "mips64" kernel can use 64-bits of address, for RAM >4G? > But, the apps running are always 32-bit? In theory the kernel has the capability to run 64-bit applications. In practice that doesn't work due to the lack of 64-bit apps and stuff. > Does this mean that any individual application can only use 4G of > memory, tho you could have several applications in physical memory > doing this? (i.e. multiple applications using 1G of RAM each, but not > swapping to disk?) In theory we don't limit the address space of 32-bit applications in 64-bit mode so they could go and use all memory and syscalls on the 64-bit address space also. In practice that's just too ugly to be usable so consider 32-bit apps on the 64-bit kernel as limited to 2gb as they are currently. You can however run an arbitrary number of these processes. > Does this mean we could map PCI memory/IO addresses above 4G and have > it work? Sure. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 14 16:59:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0xof28455 for linux-mips-outgoing; Mon, 14 Jan 2002 16:59:50 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F0xmg28446 for ; Mon, 14 Jan 2002 16:59:48 -0800 Received: (qmail 9564 invoked from network); 14 Jan 2002 23:59:45 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 23:59:45 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16QH0y-0007OI-00; Mon, 14 Jan 2002 16:59:45 -0700 Date: Mon, 14 Jan 2002 16:59:44 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Matthew Dharm cc: linux-mips@oss.sgi.com Subject: RE: MIPS64 status? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 19 On Mon, 14 Jan 2002, Matthew Dharm wrote: > Does this mean we could map PCI memory/IO addresses above 4G and have > it work? Ooh, don't go there :> We looked at that and actually did it then backed it out. The PCI spec (particuarly PCI-X) tries to make it possible, but in a general system with PCI sockets/etc it is just is not feasible. PCI bridges need to be located below 4G, as do the majority of devices made. There is also a performance hit for having device registers > 4G. You'd definately need the mips64 kernel to do that, or use ugly wired TLB entries with normal mips. Jason From owner-linux-mips@oss.sgi.com Mon Jan 14 17:08:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F18Up28710 for linux-mips-outgoing; Mon, 14 Jan 2002 17:08:30 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F18Rg28706 for ; Mon, 14 Jan 2002 17:08:27 -0800 Received: (qmail 18348 invoked from network); 15 Jan 2002 00:08:24 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.82.81.190]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 15 Jan 2002 00:08:24 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16QH9M-0007Oo-00 for ; Mon, 14 Jan 2002 17:08:24 -0700 Date: Mon, 14 Jan 2002 17:08:24 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <20020114150751.B29242@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1048 Lines: 27 On Mon, 14 Jan 2002, Ralf Baechle wrote: > On Mon, Jan 14, 2002 at 01:42:22PM -0700, Jason Gunthorpe wrote: > > > I have such hardware myself. IMHO the best option is the mips64 kernel and > > I hope to try it someday. But in practice I'd guess that Ralf's highmem > > patch is more likely to be usuable first (?). > > Depends if you can live with the problems of the current mips64 kernel. > If you can then it's highmem-free memory managment is certainly the way > to go. It's also not limited to peanuts numbers of gigabytes but can > support as much memory as your can tack on a MIPS. Yep, totally. I thought about starting with mips64 but it was simpler to go with the pre-existing processor support in the mips32 kernel. I'd like to patch mips64 up to support the CPU's I have here, but not this month :> Could someone quickly comment on how it is running? Can it boot normal 32 bit user space OK? I know with sparc64 there were (are?) a number of problems with missing 32 bit syscall translations for some obscure things.. Jason From owner-linux-mips@oss.sgi.com Mon Jan 14 17:27:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F1RAI28966 for linux-mips-outgoing; Mon, 14 Jan 2002 17:27:10 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F1R5g28960 for ; Mon, 14 Jan 2002 17:27:05 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0F0R2X11844; Mon, 14 Jan 2002 16:27:02 -0800 From: "Matthew Dharm" To: "Jason Gunthorpe" Cc: Subject: RE: MIPS64 status? Date: Mon, 14 Jan 2002 16:27:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1473 Lines: 51 Hrm... Were you actually using 64-bit addresses on the PCI bus? My guess is that with some creative address mappings, this could be done. The PCI bus itself would use only 32-bit address, but the CPU would use a base address offset into the >4G range. Yeah, I could see how that could get ugly... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Jason Gunthorpe > Sent: Monday, January 14, 2002 4:00 PM > To: Matthew Dharm > Cc: linux-mips@oss.sgi.com > Subject: RE: MIPS64 status? > > > > On Mon, 14 Jan 2002, Matthew Dharm wrote: > > > Does this mean we could map PCI memory/IO addresses above > 4G and have > > it work? > > Ooh, don't go there :> We looked at that and actually did > it then backed > it out. > > The PCI spec (particuarly PCI-X) tries to make it possible, but in a > general system with PCI sockets/etc it is just is not feasible. PCI > bridges need to be located below 4G, as do the majority of > devices made. > There is also a performance hit for having device registers > 4G. > > You'd definately need the mips64 kernel to do that, or use > ugly wired TLB > entries with normal mips. > > Jason > From owner-linux-mips@oss.sgi.com Tue Jan 15 02:05:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FA5BV10951 for linux-mips-outgoing; Tue, 15 Jan 2002 02:05:11 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FA58P10947 for ; Tue, 15 Jan 2002 02:05:08 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id D7FBB9F36; Tue, 15 Jan 2002 10:05:03 +0100 (CET) Date: Tue, 15 Jan 2002 10:05:03 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: [OT] NFS locking with NFS-Root Message-ID: <20020115100503.K15285@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 544 Lines: 17 Hi! I've got an Indy now, and I want to make it install (with the current debian dbootstrap) on a NFS root. So I first go to mount the NFS server to /target and then proceed with the installation. All .deb's get downloaded, but they cannot be extracted because dpkg can't lock /var/lib/dpkg/lock . Dumb question: How do I make file locking (via fcntl(F_SETLK)) functional? MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ From owner-linux-mips@oss.sgi.com Tue Jan 15 03:20:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FBKmd13051 for linux-mips-outgoing; Tue, 15 Jan 2002 03:20:48 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FBKjP13048 for ; Tue, 15 Jan 2002 03:20:45 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16QQhb-0005u0-00; Tue, 15 Jan 2002 11:20:23 +0100 Date: Tue, 15 Jan 2002 11:20:22 +0100 (CET) From: Ladislav Michl To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: [OT] NFS locking with NFS-Root In-Reply-To: <20020115100503.K15285@lug-owl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 483 Lines: 15 On Tue, 15 Jan 2002, Jan-Benedict Glaw wrote: > I've got an Indy now, and I want to make it install (with the current > debian dbootstrap) on a NFS root. So I first go to mount the NFS server > to /target and then proceed with the installation. All .deb's get > downloaded, but they cannot be extracted because dpkg can't lock > /var/lib/dpkg/lock . > > Dumb question: How do I make file locking (via fcntl(F_SETLK)) > functional? place your lock files into the ramdisk. ladis From owner-linux-mips@oss.sgi.com Tue Jan 15 06:07:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FE7at19543 for linux-mips-outgoing; Tue, 15 Jan 2002 06:07:36 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FE7RP19540; Tue, 15 Jan 2002 06:07:27 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA27438; Tue, 15 Jan 2002 14:07:16 +0100 (MET) Date: Tue, 15 Jan 2002 14:07:16 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Kevin D. Kissell" , Dominic Sweetman , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <20020114152355.E29242@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 953 Lines: 22 On Mon, 14 Jan 2002, Ralf Baechle wrote: > > The official MIPS64[tm] architecture spec from MIPS > > Technologies also provides a bit (Status.PX) which enables > > the 64-bit data path without affecting address generation > > and translation, which removes this quirk. Only the very > > most recent 64-bit cores and CPUs implement it, however. > > And Linux doesn't use PX at all. Especially as there is no real need for the bit for the standard MIPS64 TLB organization. The functionality of the PX bit can be replaced by the UX bit together with an appropriate mapping of segments to the 31-bit address space. Of course the kernel needs to handle the XTLB exception for UX as opposed to the TLB one for PX, but for programs it doesn't matter. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jan 15 06:10:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FEAQK20089 for linux-mips-outgoing; Tue, 15 Jan 2002 06:10:26 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FEANP20086 for ; Tue, 15 Jan 2002 06:10:23 -0800 Received: from spider.cphdev.eicon.com (firewall.i-data.com [195.24.22.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA07382 for ; Tue, 15 Jan 2002 05:05:58 -0800 (PST) mail_from (brian.murphy@eicon.com) Received: from (null) ([127.0.0.1] helo=eicon.com) by spider.cphdev.eicon.com with esmtp (Exim 3.22 #1 (Debian)) id 16QT9F-0004gi-00 for ; Tue, 15 Jan 2002 13:57:05 +0100 Message-ID: <3C442721.76843A70@eicon.com> Date: Tue, 15 Jan 2002 13:57:05 +0100 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile References: <20020112222721.B26661@lucon.org> <20020114095028.C30946@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 768 Lines: 22 "H . J . Lu" wrote: > I should have made myself clearer. I do have X rpms. In fact, my RedHat > 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine. > I simply can't afford to put X on it. My mips box is used to track gcc > 3.1, which breaks on Linux/mips almost every week, if not everyday. It > takes 2 days for me bootstrap/check gcc 3.1 on that box. I need > something simple to reproduce it. > > H.J. Is it possible for us to help? We have some machines here (Lasat Masquerade Pro) which have NEC VR5000 CPU's running at 266 MHz fitted with harddisk and running a 2.4.17 kernel. We currently have the debian mips distribution installed on them. Perhaps the scripts you use to build/test gcc could be run on one of these machines? /Brian From owner-linux-mips@oss.sgi.com Tue Jan 15 08:46:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FGkxP24580 for linux-mips-outgoing; Tue, 15 Jan 2002 08:46:59 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FGktP24577 for ; Tue, 15 Jan 2002 08:46:55 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6D647125C1; Tue, 15 Jan 2002 07:46:52 -0800 (PST) Date: Tue, 15 Jan 2002 07:46:52 -0800 From: "H . J . Lu" To: Brian Murphy Cc: linux-mips@oss.sgi.com Subject: Re: libtool warning on redhat 7.1 native mipsel compile Message-ID: <20020115074652.A18875@lucon.org> References: <20020112222721.B26661@lucon.org> <20020114095028.C30946@lucon.org> <3C442721.76843A70@eicon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C442721.76843A70@eicon.com>; from brian.murphy@eicon.com on Tue, Jan 15, 2002 at 01:57:05PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1276 Lines: 38 On Tue, Jan 15, 2002 at 01:57:05PM +0100, Brian Murphy wrote: > "H . J . Lu" wrote: > > > I should have made myself clearer. I do have X rpms. In fact, my RedHat > > 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine. > > I simply can't afford to put X on it. My mips box is used to track gcc > > 3.1, which breaks on Linux/mips almost every week, if not everyday. It > > takes 2 days for me bootstrap/check gcc 3.1 on that box. I need > > something simple to reproduce it. > > > > H.J. > > Is it possible for us to help? We have some machines here (Lasat > Masquerade Pro) > which have NEC VR5000 CPU's running at 266 MHz fitted with harddisk and > running > a 2.4.17 kernel. We currently have the debian mips distribution > installed on > them. Perhaps the scripts you use to build/test gcc could be run on one > of > these machines? If you have some spare mips machines and want to help, you can check out the gcc main trunk from CVS: http://gcc.gnu.org/ You can build/check it and send in the test result. It has to be done continuously since any checkin can break gcc on Linux/mips. You can also check out glibc from CVS: http://sources.redhat.com and build/check it. The failed glibc tests should be sent to the glibc mailing list. H.J. From owner-linux-mips@oss.sgi.com Tue Jan 15 10:48:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FImln28939 for linux-mips-outgoing; Tue, 15 Jan 2002 10:48:47 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FImhP28936 for ; Tue, 15 Jan 2002 10:48:44 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id B6DC3A092; Tue, 15 Jan 2002 18:48:39 +0100 (CET) Date: Tue, 15 Jan 2002 18:48:39 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: -ELOOP: Problem during package installation Message-ID: <20020115184839.M15285@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 571 Lines: 17 Hi! I'm running the standard debian kernel that comes with a plain installation on a R4k6 Indy. When installing packages (dpkg --install ....) I sometimes get error messages that there have been too many links in file name chain (-ELOOP). This only happens sometimes, and is not reproduceable. So, if a package failed to install, I can try it again, any may have success... Oh, this is on nfsroot... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ From owner-linux-mips@oss.sgi.com Tue Jan 15 11:05:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FJ5Kv29384 for linux-mips-outgoing; Tue, 15 Jan 2002 11:05:20 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FJ5HP29380 for ; Tue, 15 Jan 2002 11:05:17 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 87872A092; Tue, 15 Jan 2002 19:05:14 +0100 (CET) Date: Tue, 15 Jan 2002 19:05:14 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Perl on R4k6 (_not_ the segfault problem) Message-ID: <20020115190514.N15285@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 566 Lines: 18 Hi! I'm facing another problem with Perl. (Again, this is on nfsroot.) Some perl scripts ( notably update-info) stall, they do not(!) segfault). I strace'd it a time, last operation was a munmap(). The problem appears independend of the settings for LD_BIND_NOW, so it's different from the problem described on Debian's Ports pages. Is anybody working on this, or is anything known about this? MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ From owner-linux-mips@oss.sgi.com Tue Jan 15 12:11:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FKBb330823 for linux-mips-outgoing; Tue, 15 Jan 2002 12:11:37 -0800 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FKBVP30820 for ; Tue, 15 Jan 2002 12:11:32 -0800 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (SGI-8.9.3/8.9.3) with ESMTP id UAA76178 for ; Tue, 15 Jan 2002 20:11:22 +0100 (MET) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.33 #1 (Debian)) id 16QYzS-0007UV-00 for ; Tue, 15 Jan 2002 20:11:22 +0100 Date: Tue, 15 Jan 2002 20:11:22 +0100 To: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020115191122.GA28175@rembrandt.csv.ica.uni-stuttgart.de> References: <20020113211323.A7115@momenco.com> <15426.48692.795968.819750@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15426.48692.795968.819750@gladsmuir.algor.co.uk> User-Agent: Mutt/1.3.25i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 574 Lines: 17 Dominic Sweetman wrote: [snip] > > I suspect that this is very much a toolchain issue, as I don't think > > gcc will generate 64-bit addressing code. gcc does 64bit adressing, but binutils (ld/gas) do only partially yet. > I suspect that the generic GNU toolchains are pretty buggy when you > switch on 64-bit MIPS operation; but it's bug-fixes which are needed, > not wholesale new features. It needs definitely more than bug fixing. I commited some support for n64 non-PIC to binutils CVS some time ago, but support for n64 PIC and n32 still needs to be done. Thiemo From owner-linux-mips@oss.sgi.com Tue Jan 15 12:47:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FKloE31514 for linux-mips-outgoing; Tue, 15 Jan 2002 12:47:50 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FKlkP31511 for ; Tue, 15 Jan 2002 12:47:46 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 2C1229F36; Tue, 15 Jan 2002 20:47:42 +0100 (CET) Date: Tue, 15 Jan 2002 20:47:42 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: -ELOOP: Problem during package installation Message-ID: <20020115204742.Q15285@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020115184839.M15285@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115184839.M15285@lug-owl.de> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 24 On Tue, 2002-01-15 18:48:39 +0100, Jan-Benedict Glaw wrote in message <20020115184839.M15285@lug-owl.de>: > I'm running the standard debian kernel that comes with a plain > installation on a R4k6 Indy. When installing packages (dpkg --install > ....) I sometimes get error messages that there have been too > many links in file name chain (-ELOOP). This only happens sometimes, > and is not reproduceable. So, if a package failed to install, I > can try it again, any may have success... > > Oh, this is on nfsroot... Well, I've just seen this in dmesg's output: kernel: nfs_refresh_inode: inode 424854012 mode changed, 0120777 to 0100000 I brute-force installed some packages, and magically, whenever I see the -ELOOP bug, I get (at least) one of the above messages:-) MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ From owner-linux-mips@oss.sgi.com Tue Jan 15 12:50:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FKo7f31610 for linux-mips-outgoing; Tue, 15 Jan 2002 12:50:07 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FKo4P31607 for ; Tue, 15 Jan 2002 12:50:04 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 03BCA9F36; Tue, 15 Jan 2002 20:50:00 +0100 (CET) Date: Tue, 15 Jan 2002 20:50:00 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Perl on R4k6 (_not_ the segfault problem) Message-ID: <20020115205000.R15285@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020115190514.N15285@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115190514.N15285@lug-owl.de> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 19 On Tue, 2002-01-15 19:05:14 +0100, Jan-Benedict Glaw wrote in message <20020115190514.N15285@lug-owl.de>: > Hi! > > I'm facing another problem with Perl. (Again, this is on nfsroot.) > Some perl scripts ( notably update-info) stall, they do not(!) s/update-info/install-info/ install-info is provided by dpkg, so I can't simply uninstall the package. I've "fixed" this bug for now by setting the shell bang to /bin/true... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ From owner-linux-mips@oss.sgi.com Tue Jan 15 13:08:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FL8IY32244 for linux-mips-outgoing; Tue, 15 Jan 2002 13:08:18 -0800 Received: from scsoftware.sc-software.com (mipsdev@[206.40.202.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FL82P32235; Tue, 15 Jan 2002 13:08:02 -0800 Received: from localhost (mipsdev@localhost) by scsoftware.sc-software.com (8.8.3/8.8.3) with SMTP id MAA11508; Tue, 15 Jan 2002 12:00:13 -0800 Date: Tue, 15 Jan 2002 12:00:12 -0800 (PST) From: John Heil To: Ralf Baechle cc: Jason Gunthorpe , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: <20020114150751.B29242@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 935 Lines: 28 On Mon, 14 Jan 2002, Ralf Baechle wrote: > Date: Mon, 14 Jan 2002 15:07:51 -0800 > From: Ralf Baechle > To: Jason Gunthorpe > Cc: Matthew Dharm , linux-mips@oss.sgi.com > Subject: Re: MIPS64 status? > > On Mon, Jan 14, 2002 at 01:42:22PM -0700, Jason Gunthorpe wrote: > > > I have such hardware myself. IMHO the best option is the mips64 kernel and > > I hope to try it someday. But in practice I'd guess that Ralf's highmem > > patch is more likely to be usuable first (?). > > Depends if you can live with the problems of the current mips64 kernel. > If you can then it's highmem-free memory managment is certainly the way > to go. It's also not limited to peanuts numbers of gigabytes but can > support as much memory as your can tack on a MIPS. > > Ralf > Who, if anyone, has a MIPS64 reference design board available ? ...With >4G memory capacity ? Thanx Johnh From owner-linux-mips@oss.sgi.com Tue Jan 15 13:55:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLtGg03806 for linux-mips-outgoing; Tue, 15 Jan 2002 13:55:16 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0FLtEP03802 for ; Tue, 15 Jan 2002 13:55:14 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0FKtBO01964; Tue, 15 Jan 2002 12:55:11 -0800 Date: Tue, 15 Jan 2002 12:55:11 -0800 From: Ralf Baechle To: John Heil Cc: Jason Gunthorpe , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020115125511.A1832@dea.linux-mips.net> References: <20020114150751.B29242@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mipsdev@scsoftware.sc-software.com on Tue, Jan 15, 2002 at 12:00:12PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 292 Lines: 9 On Tue, Jan 15, 2002 at 12:00:12PM -0800, John Heil wrote: > Who, if anyone, has a MIPS64 reference design board available ? > ...With >4G memory capacity ? I think such boards are currently quite rare. 2gb using latest memory modules seems to be as much as you can get right now. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 15 13:59:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLxLG04901 for linux-mips-outgoing; Tue, 15 Jan 2002 13:59:21 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0FLxJP04898 for ; Tue, 15 Jan 2002 13:59:19 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0FKxHD01997; Tue, 15 Jan 2002 12:59:17 -0800 Date: Tue, 15 Jan 2002 12:59:17 -0800 From: Ralf Baechle To: Jason Gunthorpe Cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 status? Message-ID: <20020115125917.B1832@dea.linux-mips.net> References: <20020114150751.B29242@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgg@debian.org on Mon, Jan 14, 2002 at 05:08:24PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 330 Lines: 10 On Mon, Jan 14, 2002 at 05:08:24PM -0700, Jason Gunthorpe wrote: > Could someone quickly comment on how it is running? Can it boot normal 32 > bit user space OK? I know with sparc64 there were (are?) a number of > problems with missing 32 bit syscall translations for some obscure > things.. Same situation for mips64. Ralf From owner-linux-mips@oss.sgi.com Tue Jan 15 14:32:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FMWfP06449 for linux-mips-outgoing; Tue, 15 Jan 2002 14:32:41 -0800 Received: from loewe.inprot.at (loewe.inprot.at [195.58.183.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FMWdP06439; Tue, 15 Jan 2002 14:32:39 -0800 Received: from Miltie (ocnsd1-blk2-hfc-0251-d1db1785.rdc1.sdca.coxatwork.com [209.219.23.133]) by loewe.inprot.at (8.9.3/8.9.1) with ESMTP id SAA26068 for ; Tue, 15 Jan 2002 18:34:50 +0100 Received: from [172.16.1.38] by Miltie (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 15 Jan 2002 09:39:56 -0800 From: "Daryl Woods" To: Subject: Testing Date: Tue, 15 Jan 2002 09:30:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9 Lines: 2 testing From owner-linux-mips@oss.sgi.com Tue Jan 15 14:43:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FMhLo06712 for linux-mips-outgoing; Tue, 15 Jan 2002 14:43:21 -0800 Received: from loewe.inprot.at (loewe.inprot.at [195.58.183.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FMhHP06703; Tue, 15 Jan 2002 14:43:17 -0800 Received: from tron.admin.cto.netsol.com (h240.s231.netsol.com [216.168.231.240]) by loewe.inprot.at (8.9.3/8.9.1) with ESMTP id RAA25124; Tue, 15 Jan 2002 17:28:20 +0100 Received: (from raldi@localhost) by tron.admin.cto.netsol.com (8.11.6/8.11.6) id g0FGRhR02776; Tue, 15 Jan 2002 11:27:43 -0500 Date: Tue, 15 Jan 2002 11:27:43 -0500 From: Mike Schiraldi Cc: Winecellarconstruction / Weinkellerbau Gruber , mail1@winecellar.at Subject: Re: Remove Message-ID: <20020115162743.GG18641@columbia.edu> References: <00ab01dec343$f628fcc0$e9362fd5@chello.at> <004a01c19daa$6b1abc80$6950fd3e@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004a01c19daa$6b1abc80$6950fd3e@oemcomputer> User-Agent: Mutt/1.3.24i X-Last-Reboot: January 9, 2002 (5 days ago) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 251 Lines: 4 You guys can stop sending remove notices to this list -- they just get forwarded to the entire gigantic list, creating more spam for all of us. I think it's pretty clear that whoever is spamming us is not going to take our names off his mailing list. From owner-linux-mips@oss.sgi.com Tue Jan 15 19:52:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G3qNc13477 for linux-mips-outgoing; Tue, 15 Jan 2002 19:52:23 -0800 Received: from loewe.inprot.at (loewe.inprot.at [195.58.183.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G3qIP13468; Tue, 15 Jan 2002 19:52:18 -0800 Received: from nuclear.biodome.org (IDENT:qmailr@cpu1727.adsl.bellglobal.com [206.47.27.208]) by loewe.inprot.at (8.9.3/8.9.1) with SMTP id XAA30908 for ; Tue, 15 Jan 2002 23:18:26 +0100 Received: (qmail 5339 invoked from network); 15 Jan 2002 22:18:23 -0000 Received: from unknown (HELO localhost) (qg@127.0.0.1) by 127.0.0.1 with SMTP; 15 Jan 2002 22:18:23 -0000 Date: Tue, 15 Jan 2002 17:18:23 -0500 (EST) From: QuantumG To: Mike Schiraldi cc: Winecellarconstruction / Weinkellerbau Gruber , Subject: Re: Remove In-Reply-To: <20020115162743.GG18641@columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-MIME-Autoconverted: from 8bit to quoted-printable by loewe.inprot.at id XAA30908 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0G3qJP13469 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 956 Lines: 23 Then I would like to take this opportunity to introduce myself. My name is Trent Waddington, I'm a compiler tester in the United Kingdom and I have no idea what this list is. The web page at the address of which this list appears to be hosted has contact details as such: WEINKELLERBAU FRIEDRICH GRUBER Ges.m.b.H. A- 2770 Gutenstein, Ferdinand Raimund - Straße 171 Tel.: +43 / 26 34 / 74 65, FAX +43 / 26 34 / 85 85 Would any members of this list who are in Germany (and I'm sure there are a few) please call this number and threaten the life of whoever answers. I am now adding a deny rule to my mail browser. Thanks for playing. On Tue, 15 Jan 2002, Mike Schiraldi wrote: > You guys can stop sending remove notices to this list -- they just get > forwarded to the entire gigantic list, creating more spam for all of us. I > think it's pretty clear that whoever is spamming us is not going to take our > names off his mailing list. > > From owner-linux-mips@oss.sgi.com Tue Jan 15 20:14:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G4Exh13956 for linux-mips-outgoing; Tue, 15 Jan 2002 20:14:59 -0800 Received: from loewe.inprot.at (loewe.inprot.at [195.58.183.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G4EtP13948; Tue, 15 Jan 2002 20:14:55 -0800 Received: from shell.iceball.net (IDENT:matth@pawilk-apx1-122-100.du.uplink.net [209.173.122.101]) by loewe.inprot.at (8.9.3/8.9.1) with ESMTP id AAA32073; Wed, 16 Jan 2002 00:10:23 +0100 Received: from localhost (matth@localhost) by shell.iceball.net (8.9.3/8.8.7) with ESMTP id SAA17725; Tue, 15 Jan 2002 18:10:19 -0500 Date: Tue, 15 Jan 2002 18:10:18 -0500 (EST) From: Matt X-Sender: matth@shell.iceball.net To: Mike Schiraldi cc: Winecellarconstruction / Weinkellerbau Gruber , mail1@winecellar.at Subject: Re: Remove In-Reply-To: <20020115162743.GG18641@columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 18 A side note.. I used special e-mail address for things.. apaprently they "web crawled" slashdot.org and took e-mail address from there (and maybe elsewhere?) because they sent mail (this one) to the address I ONLY use for slashdot! ----------------------------------------------------------------- I like angles, but only to a degree. The most important part of a microbiologist's job is not letting the little things get to him. On Tue, 15 Jan 2002, Mike Schiraldi wrote: > You guys can stop sending remove notices to this list -- they just get > forwarded to the entire gigantic list, creating more spam for all of us. I > think it's pretty clear that whoever is spamming us is not going to take our > names off his mailing list. > From owner-linux-mips@oss.sgi.com Wed Jan 16 00:01:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G81dL17737 for linux-mips-outgoing; Wed, 16 Jan 2002 00:01:39 -0800 Received: from loewe.inprot.at (loewe.inprot.at [195.58.183.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G81bP17729; Wed, 16 Jan 2002 00:01:37 -0800 Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by loewe.inprot.at (8.9.3/8.9.1) with ESMTP id EAA04356 for ; Wed, 16 Jan 2002 04:13:20 +0100 Received: from [12.88.114.14] by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020116031248.PPXK5540.mtiwmhc21.worldnet.att.net@[12.88.114.14]>; Wed, 16 Jan 2002 03:12:48 +0000 Message-ID: <3C44F0AD.4F62@att.net> Date: Tue, 15 Jan 2002 22:17:01 -0500 From: "Peter T. Daniels" X-Mailer: Mozilla 3.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: jeff hansen CC: mail1@winecellar.at Subject: Re: worng email address!! References: <20020115220637.8160.qmail@web12301.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 166 Lines: 5 You'd think all of you have never received spam before!!! Stop sending "Remove" notices!!!!!!!!!!!!!!!! -- Peter T. Daniels grammatim@att.net From owner-linux-mips@oss.sgi.com Wed Jan 16 02:52:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GAqos22306 for linux-mips-outgoing; Wed, 16 Jan 2002 02:52:50 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GAqgP22303 for ; Wed, 16 Jan 2002 02:52:42 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA06048 for ; Wed, 16 Jan 2002 01:52:35 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA00016 for ; Wed, 16 Jan 2002 01:52:32 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0G9qEA25493 for ; Wed, 16 Jan 2002 10:52:15 +0100 (MET) Message-ID: <3C454D61.ACF98623@mips.com> Date: Wed, 16 Jan 2002 10:52:33 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: fsck fails on latest 2.4 kernel Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1920 Lines: 61 I have checked out the latest 2.4 kernel sources and tried to run it on my Malta board with an IDE disk, but fsck fails. EPC points at __wake_up, which is called from __alloc_pages. Has anyone encountered a similar problem ? Checking root filesystem /dev/hda1 was not cleanly unmounted, check forced. Oops in fault.c:do_page_fault, line 204: $0 : 00000000 9000fc00 00000000 00000000 0000001a 802b5d0c 83b72000 811e94e0 $8 : 00001000 00000001 801374c4 00000003 00000000 83b73ed0 00068db8 7fff7688 $16: 00000000 9000fc00 00000001 9000fc01 802c0078 802bc628 00000001 83ce23c0 $24: 00000000 0046a040 83b72000 83b73df0 83b73df0 8011239c Hi : 00000000 Lo : 00000000 epc : 801123ec Not tainted Status: 9000fc02 Cause : 80800008 Process fsck.ext2 (pid: 50, stackpage=83b72000) Stack: 83ce23c0 0000001f 00001000 83ce23c0 802c0a38 00000001 00000000 8115c320 802c08dc 802c0a2c 000001d0 8115c260 80131278 810140e4 000889c5 00000000 00001000 8115c260 80127928 00000002 81121b58 00000000 00000000 8115c320 00088a3d 00000000 00001000 80130e70 81121978 810140c0 00000000 8115c320 801285a0 8012847c 8025c1e0 00000001 802bf000 00000000 00000000 81163060 ffffffea ... Call Trace: [<80131278>] [<80127928>] [<80130e70>] [<801285a0>] [<8012847c>] [<8 025c1e0>] [<80128a7c>] [<80128974>] [<80118c5c>] [<8013759c>] [<80137398>] [<8010d368>] Code: 12400004 00000000 8e100000 <5614ffcc> 8e05fffc 40016000 32730001 3421 0001 38210001 [/sbin/fsck.ext2 -- /] fsck.ext2 -a /dev/hda1 Warning... fsck.ext2 for device /dev/hda1 exited with signal 11. [FAILED] /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 Jan 16 07:52:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GFq5x29966 for linux-mips-outgoing; Wed, 16 Jan 2002 07:52:05 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GFpuP29963 for ; Wed, 16 Jan 2002 07:51:57 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA08649 for ; Wed, 16 Jan 2002 06:51:48 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA08227 for ; Wed, 16 Jan 2002 06:51:47 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0GEpTA14980 for ; Wed, 16 Jan 2002 15:51:29 +0100 (MET) Message-ID: <3C459383.5C8A6C8B@mips.com> Date: Wed, 16 Jan 2002 15:51:47 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel References: <3C454D61.ACF98623@mips.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2736 Lines: 80 The problem turned out to be a compiler/binutils bug. I'm using ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/binutils-mipsel-linux-2.9.5-3.i386.rpm and ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/egcs-mipsel-linux-1.1.2-4.i386.rpm , which seems to be the latest on the SGI FTP server. What are the recommended toolchain ? /Carsten Carsten Langgaard wrote: > I have checked out the latest 2.4 kernel sources and tried to run it on > my Malta board with an IDE disk, but fsck fails. > EPC points at __wake_up, which is called from __alloc_pages. > > Has anyone encountered a similar problem ? > > Checking root filesystem > /dev/hda1 was not cleanly unmounted, check forced. > Oops in fault.c:do_page_fault, line 204: > $0 : 00000000 9000fc00 00000000 00000000 0000001a 802b5d0c 83b72000 > 811e94e0 > $8 : 00001000 00000001 801374c4 00000003 00000000 83b73ed0 00068db8 > 7fff7688 > $16: 00000000 9000fc00 00000001 9000fc01 802c0078 802bc628 00000001 > 83ce23c0 > $24: 00000000 0046a040 83b72000 83b73df0 83b73df0 > 8011239c > Hi : 00000000 > Lo : 00000000 > epc : 801123ec Not tainted > Status: 9000fc02 > Cause : 80800008 > Process fsck.ext2 (pid: 50, stackpage=83b72000) > Stack: 83ce23c0 0000001f 00001000 83ce23c0 802c0a38 00000001 00000000 > 8115c320 > 802c08dc 802c0a2c 000001d0 8115c260 80131278 810140e4 000889c5 > 00000000 > 00001000 8115c260 80127928 00000002 81121b58 00000000 00000000 > 8115c320 > 00088a3d 00000000 00001000 80130e70 81121978 810140c0 00000000 > 8115c320 > 801285a0 8012847c 8025c1e0 00000001 802bf000 00000000 00000000 > 81163060 > ffffffea ... > Call Trace: [<80131278>] [<80127928>] [<80130e70>] [<801285a0>] > [<8012847c>] [<8 > 025c1e0>] > [<80128a7c>] [<80128974>] [<80118c5c>] [<8013759c>] [<80137398>] > [<8010d368>] > > Code: 12400004 00000000 8e100000 <5614ffcc> 8e05fffc 40016000 > 32730001 3421 > 0001 38210001 > [/sbin/fsck.ext2 -- /] fsck.ext2 -a /dev/hda1 > Warning... fsck.ext2 for device /dev/hda1 exited with signal 11. > [FAILED] > > /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 -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jan 16 10:43:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GIh6G03945 for linux-mips-outgoing; Wed, 16 Jan 2002 10:43:06 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GIgxP03938 for ; Wed, 16 Jan 2002 10:43:01 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id DC364125C1; Wed, 16 Jan 2002 09:42:55 -0800 (PST) Date: Wed, 16 Jan 2002 09:42:55 -0800 From: "H . J . Lu" To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel Message-ID: <20020116094255.A10704@lucon.org> References: <3C454D61.ACF98623@mips.com> <3C459383.5C8A6C8B@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C459383.5C8A6C8B@mips.com>; from carstenl@mips.com on Wed, Jan 16, 2002 at 03:51:47PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 589 Lines: 18 On Wed, Jan 16, 2002 at 03:51:47PM +0100, Carsten Langgaard wrote: > The problem turned out to be a compiler/binutils bug. > > I'm using > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/binutils-mipsel-linux-2.9.5-3.i386.rpm > and > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/egcs-mipsel-linux-1.1.2-4.i386.rpm > , which seems to be the latest on the SGI FTP server. I won't use them myself. They are known to be broken. > > What are the recommended toolchain ? The toolchain from my RedHat 7.1 mips port is in reasonably good shape. H.J. From owner-linux-mips@oss.sgi.com Wed Jan 16 12:05:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GK5cw15934 for linux-mips-outgoing; Wed, 16 Jan 2002 12:05:38 -0800 Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GK5WP15926 for ; Wed, 16 Jan 2002 12:05:33 -0800 Received: from galileo.co.il (linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id VAA22281 for ; Wed, 16 Jan 2002 21:04:34 +0200 (GMT-2) Message-ID: <3C45CE3B.6080507@galileo.co.il> Date: Wed, 16 Jan 2002 21:02:19 +0200 From: Rabeeh Khoury User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Compilers question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 958 Lines: 28 Hi All, This is not MIPS Linux issue, but I couldn't find out a better place to post it :) I have an application I'v compiled with certain toolchain (for MIPS and other targets), and I want to distribute the application in binary (no loadable modules or dynamic linked libraries, just plain C files with headers files that gives out certain API - sort of a low level driver for hardware access only). What I need to know, is how I can make sure that when another person gets my binaries he can link them with his application and work well ? The factors that I can identify till now are two - 1.. Distribute the binary in ELF format (are there any compilers that don't support ELF ? ) 2.. Compile the binary that it is ABI compliant Please add more factors that should be checked, or even suggest another approach to overcome this problem (other than I get the other person tool chain and compile the sources myself). Thank you a lot, Rabeeh From owner-linux-mips@oss.sgi.com Wed Jan 16 12:14:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GKELk16241 for linux-mips-outgoing; Wed, 16 Jan 2002 12:14:21 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GKEFP16238; Wed, 16 Jan 2002 12:14:15 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0GJEAt22356; Wed, 16 Jan 2002 19:14:10 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id g0GItrJ08836; Wed, 16 Jan 2002 18:55:53 GMT From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15429.52408.364878.539323@gladsmuir.algor.co.uk> Date: Wed, 16 Jan 2002 18:55:52 +0000 (GMT) To: John Heil Cc: Ralf Baechle , Jason Gunthorpe , Matthew Dharm , linux-mips@oss.sgi.com Subject: Re: MIPS64 status? In-Reply-To: References: <20020114150751.B29242@dea.linux-mips.net> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 16 > Who, if anyone, has a MIPS64 reference design board available ? Algorithmics P-6064 (http://www.algor.co.uk/algor/info/p6064.html) > ...With >4G memory capacity ? A mere 2Gbytes today - we've got two DIMM slots and 1Gbyte SDRAM DIMMs are readily available. The 1Gbyte boards have 32 x 256Mbit chips, but I think there may even now be boards with more chips "stacked" in pairs. We've got no significant addressing restrictions on the memory controller and the existing DIMM modules still have address lines remaining... We can support even larger memories when and if the DIMMs show up. From owner-linux-mips@oss.sgi.com Wed Jan 16 12:53:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GKrx922153 for linux-mips-outgoing; Wed, 16 Jan 2002 12:53:59 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GKrsP22150 for ; Wed, 16 Jan 2002 12:53:55 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0GJroX21311 for ; Wed, 16 Jan 2002 11:53:50 -0800 From: "Matthew Dharm" To: "Linux-MIPS" Subject: IDE/Toolchains for MIPS? Date: Wed, 16 Jan 2002 11:53:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 441 Lines: 13 Does anyone know of a good IDE for MIPS/Linux? Some people I know are asking, because they're very used to the graphical design environments on other platforms. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Wed Jan 16 15:26:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GNQXj26404 for linux-mips-outgoing; Wed, 16 Jan 2002 15:26:33 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0GNQVP26401 for ; Wed, 16 Jan 2002 15:26:31 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0GMQS023775; Wed, 16 Jan 2002 14:26:28 -0800 Date: Wed, 16 Jan 2002 14:26:28 -0800 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel Message-ID: <20020116142628.D20408@dea.linux-mips.net> References: <3C454D61.ACF98623@mips.com> <3C459383.5C8A6C8B@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C459383.5C8A6C8B@mips.com>; from carstenl@mips.com on Wed, Jan 16, 2002 at 03:51:47PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 437 Lines: 12 On Wed, Jan 16, 2002 at 03:51:47PM +0100, Carsten Langgaard wrote: > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/binutils-mipsel-linux-2.9.5-3.i386.rpm > and > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/egcs-mipsel-linux-1.1.2-4.i386.rpm > , which seems to be the latest on the SGI FTP server. > > What are the recommended toolchain ? Don't use these for building userspace apps. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 17 00:26:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H8QAf03624 for linux-mips-outgoing; Thu, 17 Jan 2002 00:26:10 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H8Q6P03612; Thu, 17 Jan 2002 00:26:06 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA21946; Wed, 16 Jan 2002 23:25:55 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA18673; Wed, 16 Jan 2002 23:25:54 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0H7PbA14998; Thu, 17 Jan 2002 08:25:37 +0100 (MET) Message-ID: <3C467C84.AB9FFDB5@mips.com> Date: Thu, 17 Jan 2002 08:25:56 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel References: <3C454D61.ACF98623@mips.com> <3C459383.5C8A6C8B@mips.com> <20020116142628.D20408@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 879 Lines: 28 Ralf Baechle wrote: > On Wed, Jan 16, 2002 at 03:51:47PM +0100, Carsten Langgaard wrote: > > > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/binutils-mipsel-linux-2.9.5-3.i386.rpm > > and > > ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/egcs-mipsel-linux-1.1.2-4.i386.rpm > > , which seems to be the latest on the SGI FTP server. > > > > What are the recommended toolchain ? > > Don't use these for building userspace apps. I'm only building the kernel with these. What are you using for building the kernel ? > > 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 Jan 17 00:52:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H8qbm04292 for linux-mips-outgoing; Thu, 17 Jan 2002 00:52:37 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0H8qZP04288 for ; Thu, 17 Jan 2002 00:52:35 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0H7qXB04691; Wed, 16 Jan 2002 23:52:33 -0800 Date: Wed, 16 Jan 2002 23:52:33 -0800 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel Message-ID: <20020116235232.A2760@dea.linux-mips.net> References: <3C454D61.ACF98623@mips.com> <3C459383.5C8A6C8B@mips.com> <20020116142628.D20408@dea.linux-mips.net> <3C467C84.AB9FFDB5@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C467C84.AB9FFDB5@mips.com>; from carstenl@mips.com on Thu, Jan 17, 2002 at 08:25:56AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 401 Lines: 12 On Thu, Jan 17, 2002 at 08:25:56AM +0100, Carsten Langgaard wrote: > > Don't use these for building userspace apps. > > I'm only building the kernel with these. > What are you using for building the kernel ? Exactly the binaries which I put on oss. I know that in the meantime various problems with them have shown up so I'm waiting for the next official binutils release to replace them. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 17 02:37:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HAbdh06122 for linux-mips-outgoing; Thu, 17 Jan 2002 02:37:39 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HAbYP06119 for ; Thu, 17 Jan 2002 02:37:34 -0800 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 g0H9bUW10978; Thu, 17 Jan 2002 10:37:30 +0100 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 KAA28900; Thu, 17 Jan 2002 10:37:30 +0100 (MET) Message-Id: <200201170937.KAA28900@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: karsten@excalibur.cologne.de cc: vhouten@kpn.com, linux-mips@oss.sgi.com Reply-to: vhouten@kpn.com Subject: DECStation debian CD's X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jan 2002 10:37:30 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1124 Lines: 31 Hi Karsten, I've installed a 5000/240 using your debian-mipsel images. The install procedure needs some fixes, but I was able to create a bootable system. You can have a look at the system and the bootlog at http://www.xs4all.nl/~vhouten/mipsel/dior.html After installing the toolchain, I was able to compile the 2.4.17 kernel, and boot it. I tried to connect the disk to a 5000/200 (R3k too), but this failed: - delo doesn't work in combination with th 5000/200 PROM ??? (the systems just resets) - when booting a kernel by tftp, the output stops at: INIT: version 2.84 booting - I've a;so tried the tftp install image on the 5000/200, and it turns out that busybox can't find any disk: when trying this from a shell, I found out that fdisk dumps core. This might be a toolchain issue, because the fdisk from H.J.Lu's RH7.1 port works ok on the /200. 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 Jan 17 03:36:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HBabP09646 for linux-mips-outgoing; Thu, 17 Jan 2002 03:36:37 -0800 Received: from nm.laser5.co.jp (nm.laser5.co.jp [202.221.8.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HBaSP09641 for ; Thu, 17 Jan 2002 03:36:29 -0800 Received: from l5ac152.l5.laser5.co.jp (l5web.laser5.co.jp [202.221.8.76] (may be forged)) by nm.laser5.co.jp (8.10.0/3.7WVER2000041120) with ESMTP id g0HB37L18637 for ; Thu, 17 Jan 2002 20:03:07 +0900 Date: Thu, 17 Jan 2002 19:36:24 +0900 Message-ID: From: Kunihiko IMAI To: linux-mips@oss.sgi.com Subject: Re: usb-problems with Au1000 In-Reply-To: <3C3DD208.45B5BC29@esk.fhg.de> References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) Emacs/20.7 (i386-laser5-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1621 Lines: 69 Hi, I'm trying SGI version of kernel-2.2.17. And I get same message, At Thu, 10 Jan 2002 18:40:24 +0100, Wolfgang Heidrich wrote: > hub.c: USB new device connect on bus1/1, assigned device number 3 > usb.c: USB device not accepting new address=3 (error=-145) when connect some device. I checked in some cases: - Some devices are recognized, some are not. A joystick device (sanwa supply) works fine. A mouse device (century corp.) works too. But another mouse (Logitech Mini Wheel Mouse) doesn't work and I got message like above. - When connected via USB hub device, Logitech mouse works fine. I think USB root HUB doesn't work properly. By the way: today, I got a errata document from the chip dealer. This document reports some USB errata. I read the report and source code, then I found a bug in arch/mips/au1000/pb1000/setup.c. The errata report says workaround method: - set the CPU clock is 384MHz - set the source of USB host controller is CPU clcck. And the code: /* * Setup 48MHz FREQ2 from CPUPLL for USB Host */ /* FRDIV2=3 -> div by 8 of 384MHz -> 48MHz */ sys_freqctrl |= ((3<<22) | (1<<21) | (0<<20)); outl(sys_freqctrl, FQ_CNTRL_1); Comment says "Setup FREQ2" but the code set FREQ5. outl(sys_freqctrl, FQ_CNTRL_1); should be outl(sys_freqctrl, FQ_CNTRL_0); Also formar line: sys_freqctrl = inl(FQ_CNTRL_1); should be sys_freqctrl = inl(FQ_CNTRL_0); Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Thu Jan 17 04:12:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HCCI710890 for linux-mips-outgoing; Thu, 17 Jan 2002 04:12:18 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HCBhP10880; Thu, 17 Jan 2002 04:11:43 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA24066; Thu, 17 Jan 2002 03:11:33 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA29695; Thu, 17 Jan 2002 03:11:31 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0HBBDA08373; Thu, 17 Jan 2002 12:11:14 +0100 (MET) Message-ID: <3C46B151.7A15C5F4@mips.com> Date: Thu, 17 Jan 2002 12:11:13 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@oss.sgi.com Subject: IDE driver broken in bigendian 2.4.17 kernel Content-Type: multipart/mixed; boundary="------------0FA5C1CF8BAED1C4D153EBA3" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8384 Lines: 293 This is a multi-part message in MIME format. --------------0FA5C1CF8BAED1C4D153EBA3 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Due to changes in the string port macros/functions (insl, outsl, insw, ...) the bigendian IDE driver doesn't work anymore. I think we need to have local versions of these functions in include/asm-mips/ide.h, therefore these functions should be macros (#define) and not static functions in include/asm-mips/io.h (in order to redefine them). I have attached a patch that solves this problem. I have also attached a patch for the Malta board. /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 --------------0FA5C1CF8BAED1C4D153EBA3 Content-Type: text/plain; charset=iso-8859-15; name="ide.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ide.patch" Index: include/asm-mips/ide.h =================================================================== RCS file: /cvs/linux/include/asm-mips/ide.h,v retrieving revision 1.11 diff -u -r1.11 ide.h --- include/asm-mips/ide.h 2001/08/17 12:17:58 1.11 +++ include/asm-mips/ide.h 2002/01/17 12:01:03 @@ -125,6 +125,57 @@ #if defined(__MIPSEB__) +/* get rid of defs from io.h - ide has its private and conflicting versions */ +#ifdef insw +#undef insw +#endif +#ifdef outsw +#undef outsw +#endif +#ifdef insl +#undef insl +#endif +#ifdef outsl +#undef outsl +#endif + +#define insw(port, addr, count) ide_insw(port, addr, count) +#define insl(port, addr, count) ide_insl(port, addr, count) +#define outsw(port, addr, count) ide_outsw(port, addr, count) +#define outsl(port, addr, count) ide_outsl(port, addr, count) + +static inline void ide_insw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port); + addr += 2; + } +} + +static inline void ide_outsw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(volatile u16 *)(mips_io_port_base + (port)) = *(u16 *)addr; + addr += 2; + } +} + +static inline void ide_insl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port); + addr += 4; + } +} + +static inline void ide_outsl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(volatile u32 *)(mips_io_port_base + (port)) = *(u32 *)addr; + addr += 4; + } +} + #define T_CHAR (0x0000) /* char: don't touch */ #define T_SHORT (0x4000) /* short: 12 -> 21 */ #define T_INT (0x8000) /* int: 1234 -> 4321 */ Index: include/asm-mips/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips/io.h,v retrieving revision 1.29.2.4 diff -u -r1.29.2.4 io.h --- include/asm-mips/io.h 2001/12/26 23:41:26 1.29.2.4 +++ include/asm-mips/io.h 2002/01/17 12:01:03 @@ -249,22 +249,29 @@ SLOW_DOWN_IO; \ } while(0) -static inline unsigned char inb(unsigned long port) +#define inb(port) __inb(port) +#define inw(port) __inw(port) +#define inl(port) __inl(port) +#define inb_p(port) __inb_p(port) +#define inw_p(port) __inw_p(port) +#define inl_p(port) __inl_p(port) + +static inline unsigned char __inb(unsigned long port) { return __ioswab8(*(volatile u8 *)(mips_io_port_base + port)); } -static inline unsigned short inw(unsigned long port) +static inline unsigned short __inw(unsigned long port) { return __ioswab16(*(volatile u16 *)(mips_io_port_base + port)); } -static inline unsigned int inl(unsigned long port) +static inline unsigned int __inl(unsigned long port) { return __ioswab32(*(volatile u32 *)(mips_io_port_base + port)); } -static inline unsigned char inb_p(unsigned long port) +static inline unsigned char __inb_p(unsigned long port) { u8 __val; @@ -274,7 +281,7 @@ return __ioswab8(__val); } -static inline unsigned short inw_p(unsigned long port) +static inline unsigned short __inw_p(unsigned long port) { u16 __val; @@ -284,7 +291,7 @@ return __ioswab16(__val); } -static inline unsigned int inl_p(unsigned long port) +static inline unsigned int __inl_p(unsigned long port) { u32 __val; @@ -292,8 +299,15 @@ SLOW_DOWN_IO; return __ioswab32(__val); } + +#define outsb(port, addr, count) __outsb(port, addr, count) +#define insb(port, addr, count) __insb(port, addr, count) +#define outsw(port, addr, count) __outsw(port, addr, count) +#define insw(port, addr, count) __insw(port, addr, count) +#define outsl(port, addr, count) __outsl(port, addr, count) +#define insl(port, addr, count) __insl(port, addr, count) -static inline void outsb(unsigned long port, void *addr, unsigned int count) +static inline void __outsb(unsigned long port, void *addr, unsigned int count) { while (count--) { outb(*(u8 *)addr, port); @@ -301,7 +315,7 @@ } } -static inline void insb(unsigned long port, void *addr, unsigned int count) +static inline void __insb(unsigned long port, void *addr, unsigned int count) { while (count--) { *(u8 *)addr = inb(port); @@ -309,7 +323,7 @@ } } -static inline void outsw(unsigned long port, void *addr, unsigned int count) +static inline void __outsw(unsigned long port, void *addr, unsigned int count) { while (count--) { outw(*(u16 *)addr, port); @@ -317,7 +331,7 @@ } } -static inline void insw(unsigned long port, void *addr, unsigned int count) +static inline void __insw(unsigned long port, void *addr, unsigned int count) { while (count--) { *(u16 *)addr = inw(port); @@ -325,7 +339,7 @@ } } -static inline void outsl(unsigned long port, void *addr, unsigned int count) +static inline void __outsl(unsigned long port, void *addr, unsigned int count) { while (count--) { outl(*(u32 *)addr, port); @@ -333,7 +347,7 @@ } } -static inline void insl(unsigned long port, void *addr, unsigned int count) +static inline void __insl(unsigned long port, void *addr, unsigned int count) { while (count--) { *(u32 *)addr = inl(port); --------------0FA5C1CF8BAED1C4D153EBA3 Content-Type: text/plain; charset=iso-8859-15; name="malta.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="malta.patch" Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.154.2.9 diff -u -r1.154.2.9 config.in --- arch/mips/config.in 2002/01/07 03:33:54 1.154.2.9 +++ arch/mips/config.in 2002/01/17 12:00:53 @@ -149,6 +149,7 @@ define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_SWAP_IO_SPACE y + define_bool CONFIG_PC_KEYB y fi if [ "$CONFIG_MOMENCO_OCELOT" = "y" ]; then define_bool CONFIG_PCI y Index: arch/mips/mips-boards/malta/malta_setup.c =================================================================== RCS file: /cvs/linux/arch/mips/mips-boards/malta/malta_setup.c,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 malta_setup.c --- arch/mips/mips-boards/malta/malta_setup.c 2001/12/12 13:45:58 1.7.2.1 +++ arch/mips/mips-boards/malta/malta_setup.c 2002/01/17 12:00:54 @@ -36,6 +36,12 @@ #include #endif #include +#ifdef CONFIG_PC_KEYB +#include +#endif +#ifdef CONFIG_VT +#include +#endif #if defined(CONFIG_SERIAL_CONSOLE) || defined(CONFIG_PROM_CONSOLE) extern void console_setup(char *, int *); @@ -136,6 +142,26 @@ #endif #ifdef CONFIG_PC_KEYB kbd_ops = &std_kbd_ops; +#endif + +#ifdef CONFIG_VT +#if defined(CONFIG_VGA_CONSOLE) + conswitchp = &vga_con; + + screen_info = (struct screen_info) { + 0, 25, /* orig-x, orig-y */ + 0, /* unused */ + 0, /* orig-video-page */ + 0, /* orig-video-mode */ + 80, /* orig-video-cols */ + 0,0,0, /* ega_ax, ega_bx, ega_cx */ + 25, /* orig-video-lines */ + 1, /* orig-video-isVGA */ + 16 /* orig-video-points */ + }; +#elif defined(CONFIG_DUMMY_CONSOLE) + conswitchp = &dummy_con; +#endif #endif mips_reboot_setup(); } --------------0FA5C1CF8BAED1C4D153EBA3-- From owner-linux-mips@oss.sgi.com Thu Jan 17 05:02:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HD2Ut11580 for linux-mips-outgoing; Thu, 17 Jan 2002 05:02:30 -0800 Received: from gate.hhi.de (gate.HHI.DE [193.174.67.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HD2QP11577 for ; Thu, 17 Jan 2002 05:02:26 -0800 Received: from mails.hhi.de by gate.hhi.de via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 17 Jan 2002 12:02:24 UT Received: from hhi.de (bs-hpp.HHI.DE) by mails.HHI.DE (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GQ300M9N03Y1B@mails.HHI.DE> for linux-mips@oss.sgi.com; Thu, 17 Jan 2002 13:02:22 +0100 (MET) Date: Thu, 17 Jan 2002 13:02:22 +0100 From: Torsten Weber Subject: profiling in glibc for Linux/MIPS To: Linux MIPS Message-id: <3C46BD4D.DCF1F188@hhi.de> Organization: HHI MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/782) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 679 Lines: 23 We use RedHat 7.1 (available at ftp.mips.com) for the MALTA board, but programs compiled usign gcc -pg (and using a lib call inside) generate a segmentation fault and core dump. I applied the "patch" described in the mailing list (http://oss.sgi.com/mips/archive/linux-mips.0107, Subject: [patch] fix profiling in glibc for Linux/MIPS), but the core dumps are still generated. Does anybody know a solution? Thanks --------------------------------------------------------------- Torsten Weber Heinrich-Hertz-Institut fuer E-Mail: t.weber@hhi.de Nachrichtentechnik Berlin GmbH --------------------------------------------------------------- From owner-linux-mips@oss.sgi.com Thu Jan 17 05:26:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HDQ6B12068 for linux-mips-outgoing; Thu, 17 Jan 2002 05:26:06 -0800 Received: from gate.hhi.de (gate.HHI.DE [193.174.67.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HDQ2P12064 for ; Thu, 17 Jan 2002 05:26:02 -0800 Received: from mails.hhi.de by gate.hhi.de via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 17 Jan 2002 12:26:00 UT Received: from hhi.de (bs-hpp.HHI.DE) by mails.HHI.DE (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GQ300MFT1791B@mails.HHI.DE> for linux-mips@oss.sgi.com; Thu, 17 Jan 2002 13:25:58 +0100 (MET) Date: Thu, 17 Jan 2002 13:25:57 +0100 From: Torsten Weber Subject: -O2 in gcc 2.96 buggy? To: Linux MIPS Message-id: <3C46C2D5.F191DC26@hhi.de> Organization: HHI MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/782) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 720 Lines: 21 On a RedHat 7.1 installation I compiled gawk (3.1.0), but gawk crashed (gawk couldn't run glibc-2.2.4/scripts/firstversions.awk, it resulted in: > (FILENAME=- FNR=1) fatal error: internal error > Aborted (core dumped) ) The gawk problem disappeares if I compile without optimizing with -O2 (i.e. optimizing with -O works). gcc version is 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) Is this problem already known, or where is my mistake? Thanks. --------------------------------------------------------------- Torsten Weber Heinrich-Hertz-Institut fuer E-Mail: t.weber@hhi.de Nachrichtentechnik Berlin GmbH --------------------------------------------------------------- From owner-linux-mips@oss.sgi.com Thu Jan 17 06:12:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HECaF12932 for linux-mips-outgoing; Thu, 17 Jan 2002 06:12:36 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HECBP12929; Thu, 17 Jan 2002 06:12:14 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA13169; Thu, 17 Jan 2002 14:04:50 +0100 (MET) Date: Thu, 17 Jan 2002 14:04:49 +0100 (MET) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IDE driver broken in bigendian 2.4.17 kernel In-Reply-To: <3C46B151.7A15C5F4@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 956 Lines: 22 On Thu, 17 Jan 2002, Carsten Langgaard wrote: > Due to changes in the string port macros/functions (insl, outsl, insw, > ...) the bigendian IDE driver doesn't work anymore. > I think we need to have local versions of these functions in > include/asm-mips/ide.h, therefore these functions should be macros > (#define) and not static functions in include/asm-mips/io.h (in order to > redefine them). I believe the inline functions should be left as they are and the IDE driver should use own ones that call the formers and perform byteswapping on results as needed. You should avoid the name clash. Also if that's a chipset-specific issue and not an IDE host adapter's one, this should be resolved globally as other devices/drivers may be affected. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 17 06:29:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HETUs13248 for linux-mips-outgoing; Thu, 17 Jan 2002 06:29:30 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HETQP13245 for ; Thu, 17 Jan 2002 06:29:26 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16RCnA-0003KU-00; Thu, 17 Jan 2002 13:41:20 +0000 Subject: Re: Compilers question To: rabeeh@galileo.co.il (Rabeeh Khoury) Date: Thu, 17 Jan 2002 13:41:20 +0000 (GMT) Cc: linux-mips@oss.sgi.com In-Reply-To: <3C45CE3B.6080507@galileo.co.il> from "Rabeeh Khoury" at Jan 16, 2002 09:02:19 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 628 Lines: 17 > The factors that I can identify till now are two - > 1.. Distribute the binary in ELF format (are there any compilers that > don't support ELF ? ) > 2.. Compile the binary that it is ABI compliant > > Please add more factors that should be checked, or even suggest another > approach to overcome this problem (other than I get the other person > tool chain and compile the sources myself). Assuming you plan to ship just the binary 3. Ensure you also either ship .o files or you avoid using libc, ld.so and any other LGPL components (license requirements). 4. Check you use no GPL libraries (normally not likely) Alan From owner-linux-mips@oss.sgi.com Thu Jan 17 06:33:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HEXNg13372 for linux-mips-outgoing; Thu, 17 Jan 2002 06:33:23 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HEXGP13368; Thu, 17 Jan 2002 06:33:16 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA25292; Thu, 17 Jan 2002 05:31:52 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA06415; Thu, 17 Jan 2002 05:31:51 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0HDVXA16794; Thu, 17 Jan 2002 14:31:33 +0100 (MET) Message-ID: <3C46D248.931FB659@mips.com> Date: Thu, 17 Jan 2002 14:31:52 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IDE driver broken in bigendian 2.4.17 kernel References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1569 Lines: 39 "Maciej W. Rozycki" wrote: > On Thu, 17 Jan 2002, Carsten Langgaard wrote: > > > Due to changes in the string port macros/functions (insl, outsl, insw, > > ...) the bigendian IDE driver doesn't work anymore. > > I think we need to have local versions of these functions in > > include/asm-mips/ide.h, therefore these functions should be macros > > (#define) and not static functions in include/asm-mips/io.h (in order to > > redefine them). > > I believe the inline functions should be left as they are and the IDE > driver should use own ones that call the formers and perform byteswapping > on results as needed. You should avoid the name clash. > > Also if that's a chipset-specific issue and not an IDE host adapter's > one, this should be resolved globally as other devices/drivers may be > affected. One could argue that the IDE driver should use it's own special functions (like ide_insl, etc ...) and not use the generic functions (insl, etc ...). But all other architectures does it this way, so I'm just trying to follow the trend. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + -- _ _ ____ ___ 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 Jan 17 06:33:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HEXj113386 for linux-mips-outgoing; Thu, 17 Jan 2002 06:33:45 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HEXgP13383 for ; Thu, 17 Jan 2002 06:33:43 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16RCrB-0003LI-00; Thu, 17 Jan 2002 13:45:29 +0000 Subject: Re: IDE/Toolchains for MIPS? To: mdharm@momenco.com (Matthew Dharm) Date: Thu, 17 Jan 2002 13:45:29 +0000 (GMT) Cc: linux-mips@oss.sgi.com (Linux-MIPS) In-Reply-To: from "Matthew Dharm" at Jan 16, 2002 11:53:50 AM 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 287 Lines: 7 > Does anyone know of a good IDE for MIPS/Linux? > > Some people I know are asking, because they're very used to the > graphical design environments on other platforms. kdevelop should build and run fine on mips, as should anjuta. I'm not a KDE fan but kdevelop is a very nice package From owner-linux-mips@oss.sgi.com Thu Jan 17 06:34:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HEYsG13518 for linux-mips-outgoing; Thu, 17 Jan 2002 06:34:54 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HEYkP13510 for ; Thu, 17 Jan 2002 06:34:46 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA25323 for ; Thu, 17 Jan 2002 05:34:36 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA06543 for ; Thu, 17 Jan 2002 05:34:36 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0HDYIA16993 for ; Thu, 17 Jan 2002 14:34:18 +0100 (MET) Message-ID: <3C46D2ED.9BCA458A@mips.com> Date: Thu, 17 Jan 2002 14:34:37 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Bug in the _save_fp_context. Content-Type: multipart/mixed; boundary="------------13498F6F204C7733F9CE6B14" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2057 Lines: 71 This is a multi-part message in MIME format. --------------13498F6F204C7733F9CE6B14 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit I posted the following problem on the list almost a year ago, but it still hasn't made into the SGI CVS. I think there is a bug in the _save_fp_context function in arch/mips/kernel/r4k_fpu.S The problem is the following piece of code: jr ra .set nomacro EX(sw t0,SC_FPC_EIR(a0)) .set macro We do not handle entries in the __ex_table which is located in a branch delay. So we need to handle the situation where we take a page fault on an instruction which is located in a brach delay slot, or we don't put the "potential" faulting instruction in a delay slot. This situation probably doesn't generally hit people since it hasn't been fix yet, but if you try run something nasty like Crashme, you will get hit by this problem. I suggest the following patch. /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 --------------13498F6F204C7733F9CE6B14 Content-Type: text/plain; charset=iso-8859-15; name="r4k_fpu.S.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r4k_fpu.S.patch" Index: arch/mips/kernel/r4k_fpu.S =================================================================== RCS file: /cvs/linux/arch/mips/kernel/r4k_fpu.S,v retrieving revision 1.12 diff -u -r1.12 r4k_fpu.S --- arch/mips/kernel/r4k_fpu.S 2001/04/11 05:19:46 1.12 +++ arch/mips/kernel/r4k_fpu.S 2002/01/17 14:21:09 @@ -50,11 +50,10 @@ EX(sdc1 $f30,(SC_FPREGS+240)(a0)) EX(sw t1,SC_FPC_CSR(a0)) cfc1 t0,$0 # implementation/version + EX(sw t0,SC_FPC_EIR(a0)) jr ra - .set nomacro - EX(sw t0,SC_FPC_EIR(a0)) - .set macro + nop END(_save_fp_context) /* --------------13498F6F204C7733F9CE6B14-- From owner-linux-mips@oss.sgi.com Thu Jan 17 07:19:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HFJFv14505 for linux-mips-outgoing; Thu, 17 Jan 2002 07:19:15 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HFJ5P14502 for ; Thu, 17 Jan 2002 07:19:05 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA25783 for ; Thu, 17 Jan 2002 06:18:56 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA08691 for ; Thu, 17 Jan 2002 06:18:55 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0HEIaA19758 for ; Thu, 17 Jan 2002 15:18:37 +0100 (MET) Message-ID: <3C46DD4F.225E134E@mips.com> Date: Thu, 17 Jan 2002 15:18:55 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: EJTAG patch Content-Type: multipart/mixed; boundary="------------3876C11FE88E3C3D432B94EB" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2872 Lines: 85 This is a multi-part message in MIME format. --------------3876C11FE88E3C3D432B94EB Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit I have attached a patch for EJTAG exception support on MIPS32 CPUs. I send these patches to everyone and not just Ralf, because I've got questions from various people about MIPS32 CPUs and Malta board support in the 2.4.17 kernel. Sorry to disturb the rest of you. /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 --------------3876C11FE88E3C3D432B94EB Content-Type: text/plain; charset=iso-8859-15; name="ejtag.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ejtag.patch" Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96.2.4 diff -u -r1.96.2.4 setup.c --- arch/mips/kernel/setup.c 2002/01/07 03:33:54 1.96.2.4 +++ arch/mips/kernel/setup.c 2002/01/17 15:11:23 @@ -150,6 +150,10 @@ case CPU_NEVADA: case CPU_RM7000: case CPU_TX49XX: + case CPU_4KC: + case CPU_4KEC: + case CPU_4KSC: + case CPU_5KC: cpu_wait = r4k_wait; printk(" available.\n"); break; @@ -435,7 +439,7 @@ mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC | MIPS_CPU_WATCH | - MIPS_CPU_MCHECK; + MIPS_CPU_MCHECK | MIPS_CPU_EJTAG; config1 = read_mips32_cp0_config1(); if (config1 & (1 << 3)) mips_cpu.options |= MIPS_CPU_WATCH; @@ -452,7 +456,7 @@ mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC | MIPS_CPU_WATCH | - MIPS_CPU_MCHECK; + MIPS_CPU_MCHECK | MIPS_CPU_EJTAG; config1 = read_mips32_cp0_config1(); if (config1 & (1 << 3)) mips_cpu.options |= MIPS_CPU_WATCH; Index: arch/mips/kernel/traps.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/traps.c,v retrieving revision 1.99.2.3 diff -u -r1.99.2.3 traps.c --- arch/mips/kernel/traps.c 2001/12/29 05:37:49 1.99.2.3 +++ arch/mips/kernel/traps.c 2002/01/17 15:11:23 @@ -853,7 +853,7 @@ * destination. */ if (mips_cpu.options & MIPS_CPU_EJTAG) - memcpy((void *)(KSEG0 + 0x200), &except_vec_ejtag_debug, 0x80); + memcpy((void *)(KSEG0 + 0x300), &except_vec_ejtag_debug, 0x80); /* * Only some CPUs have the watch exceptions or a dedicated --------------3876C11FE88E3C3D432B94EB-- From owner-linux-mips@oss.sgi.com Thu Jan 17 07:52:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HFqdn17752 for linux-mips-outgoing; Thu, 17 Jan 2002 07:52:39 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HFqZP17748 for ; Thu, 17 Jan 2002 07:52:35 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16RDtt-0007wn-00; Thu, 17 Jan 2002 09:52:21 -0500 Date: Thu, 17 Jan 2002 09:52:21 -0500 From: Daniel Jacobowitz To: Torsten Weber Cc: Linux MIPS Subject: Re: profiling in glibc for Linux/MIPS Message-ID: <20020117095221.A30388@nevyn.them.org> References: <3C46BD4D.DCF1F188@hhi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C46BD4D.DCF1F188@hhi.de> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 771 Lines: 22 On Thu, Jan 17, 2002 at 01:02:22PM +0100, Torsten Weber wrote: > We use RedHat 7.1 (available at ftp.mips.com) for the MALTA board, > > but programs compiled usign gcc -pg (and using a lib call inside) > > generate a segmentation fault and core dump. I applied the "patch" > > described in the mailing list > > (http://oss.sgi.com/mips/archive/linux-mips.0107, > > Subject: [patch] fix profiling in glibc for Linux/MIPS), but > > the core dumps are still generated. Does anybody know a solution? You also need a GCC patch. I posted: http://gcc.gnu.org/ml/gcc-patches/2001-10/msg00598.html which was just approved. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Jan 17 08:32:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HGWCX20929 for linux-mips-outgoing; Thu, 17 Jan 2002 08:32:12 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HGVuP20926; Thu, 17 Jan 2002 08:31:57 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA17873; Thu, 17 Jan 2002 16:31:03 +0100 (MET) Date: Thu, 17 Jan 2002 16:31:02 +0100 (MET) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IDE driver broken in bigendian 2.4.17 kernel In-Reply-To: <3C46D248.931FB659@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1053 Lines: 25 On Thu, 17 Jan 2002, Carsten Langgaard wrote: > One could argue that the IDE driver should use it's own special functions > (like ide_insl, etc ...) and not use the generic functions (insl, etc ...). If it's due to a problem with an IDE host adapter then it should be fixed within the IDE driver (or not at all and kept privately as needed). In no case the order of header inclusions may determine function or macro definitions. > But all other architectures does it this way, so I'm just trying to follow > the trend. It does not mean other architectures are right here. Possibly they have not hit the problem so far. If the problem is generic to a chipset, then you indeed need to redefine I/O macros, but then in . If that's PCI-specific, for example, then you should probably make the redefinition conditional on CONFIG_PCI. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 17 10:02:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HI26025094 for linux-mips-outgoing; Thu, 17 Jan 2002 10:02:06 -0800 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HI1wP25090 for ; Thu, 17 Jan 2002 10:01:59 -0800 Received: from GS256.SP.CS.CMU.EDU by ux3.sp.cs.cmu.edu id aa15824; 17 Jan 2002 12:01 EST Subject: Re: -O2 in gcc 2.96 buggy? From: Justin Carlson To: Torsten Weber Cc: Linux MIPS In-Reply-To: <3C46C2D5.F191DC26@hhi.de> References: <3C46C2D5.F191DC26@hhi.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7TIf4RcVnk6Fp0HnN+IP" X-Mailer: Evolution/0.99.2 (Preview Release) Date: 17 Jan 2002 12:01:29 -0500 Message-Id: <1011286893.315.28.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1463 Lines: 59 --=-7TIf4RcVnk6Fp0HnN+IP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-01-17 at 07:25, Torsten Weber wrote: > On a RedHat 7.1 installation I compiled gawk (3.1.0), but gawk crashed > (gawk couldn't run glibc-2.2.4/scripts/firstversions.awk, it resulted > in: > > (FILENAME=3D- FNR=3D1) fatal error: internal error > > Aborted (core dumped) > ) > The gawk problem disappeares if I compile without optimizing with -O2 > (i.e. optimizing with -O works). >=20 > gcc version is 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) >=20 > Is this problem already known, or where is my mistake? >=20 Often compiling with -O2 reveals actual bugs in the code of the program, not the compiler. For example, uninitialized variables can come out differently depending on optimization level: #include #include int main() { int foo; printf("Foo is %i\n", foo); return 0; } [justinca@gs256 ~]$ gcc -O0 foo.c -o foo [justinca@gs256 ~]$ ./foo Foo is -1073743180 [justinca@gs256 ~]$ gcc -O2 foo.c -o foo [justinca@gs256 ~]$ ./foo Foo is 1075157696 -Justin --=-7TIf4RcVnk6Fp0HnN+IP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8RwNp47Lg4cGgb74RAuHEAJ9Q5WzYjMwo2BmPExcaw6rEeK1WYQCfVHkN kbbjboFxKyhEvSIjoYfK7Gs= =DbhC -----END PGP SIGNATURE----- --=-7TIf4RcVnk6Fp0HnN+IP-- From owner-linux-mips@oss.sgi.com Thu Jan 17 10:34:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HIYgI26169 for linux-mips-outgoing; Thu, 17 Jan 2002 10:34:42 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HIYbP26166 for ; Thu, 17 Jan 2002 10:34:37 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 20776125C1; Thu, 17 Jan 2002 09:34:33 -0800 (PST) Date: Thu, 17 Jan 2002 09:34:32 -0800 From: "H . J . Lu" To: Torsten Weber Cc: Linux MIPS Subject: Re: -O2 in gcc 2.96 buggy? Message-ID: <20020117093432.A995@lucon.org> References: <3C46C2D5.F191DC26@hhi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C46C2D5.F191DC26@hhi.de>; from t.weber@hhi.de on Thu, Jan 17, 2002 at 01:25:57PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 591 Lines: 19 On Thu, Jan 17, 2002 at 01:25:57PM +0100, Torsten Weber wrote: > On a RedHat 7.1 installation I compiled gawk (3.1.0), but gawk crashed > (gawk couldn't run glibc-2.2.4/scripts/firstversions.awk, it resulted > in: > > (FILENAME=- FNR=1) fatal error: internal error > > Aborted (core dumped) > ) > The gawk problem disappeares if I compile without optimizing with -O2 > (i.e. optimizing with -O works). > > gcc version is 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) > > Is this problem already known, or where is my mistake? I know a kernel bug caused this problem. H.J. From owner-linux-mips@oss.sgi.com Thu Jan 17 11:39:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HJdgg27905 for linux-mips-outgoing; Thu, 17 Jan 2002 11:39:42 -0800 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HJddP27902 for ; Thu, 17 Jan 2002 11:39:39 -0800 Received: from excalibur.cologne.de (p5085141E.dip.t-dialin.net [80.133.20.30]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA29392; Thu, 17 Jan 2002 19:39:34 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16RH3q-00008x-00; Thu, 17 Jan 2002 19:14:50 +0100 Date: Thu, 17 Jan 2002 19:14:50 +0100 From: Karsten Merker To: "Houten K.H.C. van (Karel)" Cc: linux-mips@oss.sgi.com Subject: Re: DECStation debian CD's Message-ID: <20020117191450.A253@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com References: <200201170937.KAA28900@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201170937.KAA28900@sparta.research.kpn.com>; from vhouten@kpn.com on Thu, Jan 17, 2002 at 10:37:30AM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 652 Lines: 17 On Thu, Jan 17, 2002 at 10:37:30AM +0100, Houten K.H.C. van (Karel) wrote: > I've installed a 5000/240 using your debian-mipsel images. The install > procedure needs some fixes, but I was able to create a bootable system. > You can have a look at the system and the bootlog at > http://www.xs4all.nl/~vhouten/mipsel/dior.html Thanks for testing the installer. Do you have a list of the particular problems you had with it? Greetings, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Thu Jan 17 12:07:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HK7xA28852 for linux-mips-outgoing; Thu, 17 Jan 2002 12:07:59 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HK7pP28849 for ; Thu, 17 Jan 2002 12:07:51 -0800 Received: from hermes.mvista.com ([12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA28675 for ; Thu, 17 Jan 2002 11:03:22 -0800 (PST) mail_from (ppopov@pacbell.net) Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0HIxvB07463; Thu, 17 Jan 2002 10:59:57 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Kunihiko IMAI Cc: linux-mips In-Reply-To: References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 17 Jan 2002 11:02:03 -0800 Message-Id: <1011294123.4550.58.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2227 Lines: 68 On Thu, 2002-01-17 at 02:36, Kunihiko IMAI wrote: > Hi, > > I'm trying SGI version of kernel-2.2.17. > And I get same message, > > At Thu, 10 Jan 2002 18:40:24 +0100, > Wolfgang Heidrich wrote: > > > hub.c: USB new device connect on bus1/1, assigned device number 3 > > usb.c: USB device not accepting new address=3 (error=-145) I'm surprised the sgi kernel works with usb at all. We did a patch for non-pci usb devices which was not accepted by the usb project at that time because they were working on a different solution. > when connect some device. > > > I checked in some cases: > > - Some devices are recognized, some are not. > A joystick device (sanwa supply) works fine. > A mouse device (century corp.) works too. > But another mouse (Logitech Mini Wheel Mouse) doesn't work and > I got message like above. > > - When connected via USB hub device, Logitech mouse works fine. > > I think USB root HUB doesn't work properly. > By the way: > > today, I got a errata document from the chip dealer. This document > reports some USB errata. > I read the report and source code, then I found a bug in > arch/mips/au1000/pb1000/setup.c. > > > The errata report says workaround method: > - set the CPU clock is 384MHz > - set the source of USB host controller is CPU clcck. > > And the code: > > /* > * Setup 48MHz FREQ2 from CPUPLL for USB Host > */ > /* FRDIV2=3 -> div by 8 of 384MHz -> 48MHz */ > sys_freqctrl |= ((3<<22) | (1<<21) | (0<<20)); > outl(sys_freqctrl, FQ_CNTRL_1); > > Comment says "Setup FREQ2" but the code set FREQ5. It's the comment that's wrong, not the code. The code works and has been tested. Alchemy makes available the Linux Support Package (LSP) which we did. That kernel has been tested with all peripherals so I would recommend that you get that from them. Also,make sure your jumpers are setup correctly (S4). I do have a better USB workaround which checks the CPU silicon rev, but I haven't had time to send Ralf an updated patch. The current setup.c should work though. Get the latest LSP from Alchemy, check the S4 jumpers (1-4 off, 5-6 on, 7-8 off), and let me know if it still doesn't work for you. Pete From owner-linux-mips@oss.sgi.com Thu Jan 17 12:53:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HKrfb30438 for linux-mips-outgoing; Thu, 17 Jan 2002 12:53:41 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HKraP30435 for ; Thu, 17 Jan 2002 12:53:36 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id CB3F8838; Thu, 17 Jan 2002 20:53:21 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 09E834395; Thu, 17 Jan 2002 20:49:14 +0100 (CET) Date: Thu, 17 Jan 2002 20:49:13 +0100 From: Florian Lohoff To: "Houten K.H.C. van (Karel)" Cc: karsten@excalibur.cologne.de, linux-mips@oss.sgi.com Subject: Re: DECStation debian CD's Message-ID: <20020117194913.GB26395@paradigm.rfc822.org> References: <200201170937.KAA28900@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <200201170937.KAA28900@sparta.research.kpn.com> User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1340 Lines: 44 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2002 at 10:37:30AM +0100, Houten K.H.C. van (Karel) wrote: > - delo doesn't work in combination with th 5000/200 PROM ??? > (the systems just resets) Thats correct - The /200 should ne a REX (non-REX?) prom which is basically not supported yet - I havent got a running /200=20 loader/main.c 30 /* FIXME We only check for REX but dont handle it right now */ 31 if (magic =3D=3D DEC_REX_MAGIC) { 32 /* Store Call Vector */ 33 callv=3Dcv; 34 rex_prom=3D1; 35 } Somebody would need to actually tune a bit for the prom calls for read/write of disks and the command line parameters. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --vGgW1X5XWziG23Ko 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 iD8DBQE8Ryq5Uaz2rXW+gJcRAgISAKDVzm6l4fRzHzzLhbhEbuf+Oa8tNgCgsgNq GFmE8TbF/xdX6ua7PsKfXxI= =eV/x -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-linux-mips@oss.sgi.com Thu Jan 17 13:09:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HL9U631676 for linux-mips-outgoing; Thu, 17 Jan 2002 13:09:30 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HL9NP31673; Thu, 17 Jan 2002 13:09:23 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA01192; Thu, 17 Jan 2002 12:08:13 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA02320; Thu, 17 Jan 2002 12:08:13 -0800 (PST) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g0HK7tA10490; Thu, 17 Jan 2002 21:07:55 +0100 (MET) Message-ID: <3C472F60.E5B62F0C@mips.com> Date: Thu, 17 Jan 2002 21:09:04 +0100 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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IDE driver broken in bigendian 2.4.17 kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1696 Lines: 40 "Maciej W. Rozycki" wrote: > On Thu, 17 Jan 2002, Carsten Langgaard wrote: > > > One could argue that the IDE driver should use it's own special functions > > (like ide_insl, etc ...) and not use the generic functions (insl, etc ...). > > If it's due to a problem with an IDE host adapter then it should be fixed > within the IDE driver (or not at all and kept privately as needed). In no > case the order of header inclusions may determine function or macro > definitions. The order of header inclusions doesn't matter, because the ide.h file include the io.h file, and that way io.h always get include first. The '#ifndef' in all header file makes sure it only get included once. > > > But all other architectures does it this way, so I'm just trying to follow > > the trend. > > It does not mean other architectures are right here. Possibly they have > not hit the problem so far. > > If the problem is generic to a chipset, then you indeed need to redefine > I/O macros, but then in . If that's PCI-specific, for example, > then you should probably make the redefinition conditional on CONFIG_PCI. I'm not in a position, where I can fix and not at least test the changes, that it needed in both the IDE driver as well as in all the other bigendian architectures ide.h files. I think my fix is the only one that doesn't break things for anyone else, you may argue that it isn't the right one and I kind of agree, but at this point I think it's the best solution. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jan 17 14:55:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HMtPv01361 for linux-mips-outgoing; Thu, 17 Jan 2002 14:55:25 -0800 Received: from hermes.mvista.com ([12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HMtNP01355 for ; Thu, 17 Jan 2002 14:55:23 -0800 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0HLrxB18791 for ; Thu, 17 Jan 2002 13:53:59 -0800 Message-ID: <3C474909.4DF82E72@mvista.com> Date: Thu, 17 Jan 2002 13:58:33 -0800 From: Alice Hennessy X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: malta 4kc and tlb-r4k.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 386 Lines: 22 I needed to add a BARRIER between : set_entryhi(KSEG0+idx*0x2000); and tlb_write_indexed(); in local_flush_tlb_range() (tlb-r4k.c), otherwise I get a bootup failure: Kernel panic: Caught Machine Check exception - probably caused by multiple matching entries in the TLB. Malta 5kc didn't have this problem. Also, the call set_entryhi(KSEG0); doesn't seem necessary. Alice From owner-linux-mips@oss.sgi.com Thu Jan 17 22:26:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I6QH811931 for linux-mips-outgoing; Thu, 17 Jan 2002 22:26:17 -0800 Received: from nm.laser5.co.jp (nm.laser5.co.jp [202.221.8.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I6Q6P11925 for ; Thu, 17 Jan 2002 22:26:06 -0800 Received: from l5ac152.l5.laser5.co.jp (l5web.laser5.co.jp [202.221.8.76] (may be forged)) by nm.laser5.co.jp (8.10.0/3.7WVER2000041120) with ESMTP id g0I5qoL26919 for ; Fri, 18 Jan 2002 14:52:51 +0900 Date: Fri, 18 Jan 2002 14:26:02 +0900 Message-ID: From: Kunihiko IMAI To: linux-mips Subject: Re: usb-problems with Au1000 In-Reply-To: <1011294123.4550.58.camel@zeus> References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) Emacs/20.7 (i386-laser5-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2936 Lines: 85 Hi, At 17 Jan 2002 11:02:03 -0800, Pete Popov wrote: > > On Thu, 2002-01-17 at 02:36, Kunihiko IMAI wrote: > > Hi, > > > > I'm trying SGI version of kernel-2.2.17. > > And I get same message, > > > > At Thu, 10 Jan 2002 18:40:24 +0100, > > Wolfgang Heidrich wrote: > > > > > hub.c: USB new device connect on bus1/1, assigned device number 3 > > > usb.c: USB device not accepting new address=3 (error=-145) > > I'm surprised the sgi kernel works with usb at all. We did a patch for > non-pci usb devices which was not accepted by the usb project at that > time because they were working on a different solution. Of course, I patched usb-ohci code with memory mapped I/O support. It is very ugly code, so Linux USB stuff will not accept, I think. About two years ago, I ported USB OHCI to StrongARM SA1111 CPU and SA1111 companion chip. At that time, I suggested to the author of usb-ohci.c that it should be better to support of memory mapped I/O device, but it was not accepted. On StrongARM, it has DMA memory coherency problem, too. (Au1000 has bus snoop function, so this is not a problem.) > > The errata report says workaround method: > > - set the CPU clock is 384MHz > > - set the source of USB host controller is CPU clcck. > > > > And the code: > > > > /* > > * Setup 48MHz FREQ2 from CPUPLL for USB Host > > */ > > /* FRDIV2=3 -> div by 8 of 384MHz -> 48MHz */ > > sys_freqctrl |= ((3<<22) | (1<<21) | (0<<20)); > > outl(sys_freqctrl, FQ_CNTRL_1); > > > > Comment says "Setup FREQ2" but the code set FREQ5. > > It's the comment that's wrong, not the code. The code works and has been > tested. Alchemy makes available the Linux Support Package (LSP) which > we did. That kernel has been tested with all peripherals so I would > recommend that you get that from them. Also,make sure your jumpers are > setup correctly (S4). In the source code: sys_clksrc |= ((4<<12) | (0<<11) | (0<<10)); (snip...) outl(sys_clksrc, CLOCK_SOURCE_CNTRL); This code sets the clock source of USB host controller is FREQ2. So FREQ5 clock source doesn't affect to USB host controller. And I found HHL version of kernel source code in Pb1000 CD-ROM. I'll read it. > I do have a better USB workaround which checks the CPU silicon rev, but > I haven't had time to send Ralf an updated patch. The current setup.c > should work though. Get the latest LSP from Alchemy, check the S4 > jumpers (1-4 off, 5-6 on, 7-8 off), and let me know if it still doesn't > work for you. OK. I checked S4 DIP SW, it was setted same config. # Pb1000 documentation doesn't clearly explain at this configration. # So I looked schematics of Pb1000. This switch affects only J24 connector setting. J2 connector is not affected by S4. Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Thu Jan 17 22:38:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I6csp12163 for linux-mips-outgoing; Thu, 17 Jan 2002 22:38:54 -0800 Received: from thunder.adam.com.au (thunder.adam.com.au [203.2.124.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I6cnP12160 for ; Thu, 17 Jan 2002 22:38:49 -0800 Received: (qmail 45127 invoked by uid 65534); 18 Jan 2002 05:39:00 -0000 To: linux-mips@oss.sgi.com Subject: IndyCam software Message-ID: <1011332340.3c47b4f4a4416@thunder.adam.com.au> Date: Fri, 18 Jan 2002 16:09:00 +1030 (CST) From: James Mclean MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 827 Lines: 26 All, Howdy, I have an SGI Indy currently running Irix 6.5.?, with an IndyCam. There is currently some corrupt software, which is causing the camera not to work. I have been hunting for a copy of Irix, but was unable to find one as of yet. I have been suggested NetBSD, but did not know what IndyCam support was like and decided to stick with Irix for now. Now that I hear that SGI is supporting a port of Linux to the mips, is there any chance that there is support for the IndyCam, or software to view the video input? I am interested in dual booting with Irix also, but first would like to establish if there is any preliminary support for the IndyCam before installing linux-mips. TIA. Regards, James Mclean "Windows didn't get as bad as it is overnight -- it took over ten years of careful development." From owner-linux-mips@oss.sgi.com Thu Jan 17 23:09:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I799p12627 for linux-mips-outgoing; Thu, 17 Jan 2002 23:09:09 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I795P12624 for ; Thu, 17 Jan 2002 23:09:05 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 16RSCN-0002Qj-00; Fri, 18 Jan 2002 07:08:23 +0100 Date: Fri, 18 Jan 2002 07:08:23 +0100 (CET) From: Ladislav Michl To: James Mclean cc: linux-mips@oss.sgi.com Subject: Re: IndyCam software In-Reply-To: <1011332340.3c47b4f4a4416@thunder.adam.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 700 Lines: 22 On Fri, 18 Jan 2002, James Mclean wrote: > I am interested in dual booting with Irix also, but first would like to > establish if there is any preliminary support for the IndyCam before installing > linux-mips. hi James, you should follow these steps: * install linux anyway :) * get linux kernel from cvs * download stuff from ftp.psi.cz/pub/ladis/vino/ and see README * happy hacking ;) note for those who are waiting for vino support: yes, i'll start to work on driver again. i wrote audio driver meanwhile and learned many usefull things (many thanks to dwmw2 for patience), now i know that vino driver have to be rewritten and i'll do so when audio driver appears in cvs. regards, ladis From owner-linux-mips@oss.sgi.com Thu Jan 17 23:44:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I7ivR13063 for linux-mips-outgoing; Thu, 17 Jan 2002 23:44:57 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I7irP13057 for ; Thu, 17 Jan 2002 23:44:53 -0800 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 g0I6io518621; Fri, 18 Jan 2002 07:44:50 +0100 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 HAA14358; Fri, 18 Jan 2002 07:44:49 +0100 (MET) Message-Id: <200201180644.HAA14358@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Karsten Merker cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: DECStation debian CD's In-reply-to: Your message of "Thu, 17 Jan 2002 19:14:50 +0100." <20020117191450.A253@excalibur.cologne.de> 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: Fri, 18 Jan 2002 07:44:49 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 475 Lines: 20 Hi Karsten, > > Thanks for testing the installer. Do you have a list of the particular > problems you had with it? I'll see if I can find some time this weekend to redo the installation, and make some more notes. 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 Jan 17 23:46:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I7k0T13135 for linux-mips-outgoing; Thu, 17 Jan 2002 23:46:00 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I7jtP13131 for ; Thu, 17 Jan 2002 23:45:55 -0800 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 g0I6jq518635; Fri, 18 Jan 2002 07:45:52 +0100 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 HAA14403; Fri, 18 Jan 2002 07:45:52 +0100 (MET) Message-Id: <200201180645.HAA14403@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Florian Lohoff cc: "Houten K.H.C. van (Karel)" , karsten@excalibur.cologne.de, linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: DECStation debian CD's In-reply-to: Your message of "Thu, 17 Jan 2002 20:49:13 +0100." <20020117194913.GB26395@paradigm.rfc822.org> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 07:45:52 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1052 Lines: 34 Hi Flo, > On Thu, Jan 17, 2002 at 10:37:30AM +0100, Houten K.H.C. van (Karel) wrote: > > - delo doesn't work in combination with th 5000/200 PROM ??? > > (the systems just resets) > > Thats correct - The /200 should ne a REX (non-REX?) prom which is > basically not supported yet - I havent got a running /200 > > loader/main.c > 30 /* FIXME We only check for REX but dont handle it right > now */ > 31 if (magic == DEC_REX_MAGIC) { > 32 /* Store Call Vector */ > 33 callv=cv; > 34 rex_prom=1; > 35 } > > Somebody would need to actually tune a bit for the prom calls for > read/write of disks and the command line parameters. Is there any documentation about those PROM's available? 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 Fri Jan 18 00:55:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I8tuF14271 for linux-mips-outgoing; Fri, 18 Jan 2002 00:55:56 -0800 Received: from thing.com (IDENT:AC6BaasNYPoS3U7cDSjqiURBq7V/+sBf@thing.com [216.39.145.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I8tsP14266 for ; Fri, 18 Jan 2002 00:55:54 -0800 Received: from localhost (herber@localhost) by thing.com (8.11.6/8.9.3) with ESMTP id g0I7tpH04351 for ; Thu, 17 Jan 2002 23:55:51 -0800 Date: Thu, 17 Jan 2002 23:55:50 -0800 (PST) From: Steve Herber To: Subject: Spare hardware in the Seattle area In-Reply-To: <200201180645.HAA14403@sparta.research.kpn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 305 Lines: 11 I have some SGI Indigo and DECstation workstations that I would like to give to anyone in the Seattle area that could put them to good use, especially working on Linux MIPS support. Thanks, -- Steve Herber herber@thing.com work: 206-732-6111 IT Manager, Rosen Building, SoM, UoW home: 425-454-2399 From owner-linux-mips@oss.sgi.com Fri Jan 18 03:40:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IBe3Z18845 for linux-mips-outgoing; Fri, 18 Jan 2002 03:40:03 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IBdoP18840; Fri, 18 Jan 2002 03:39:52 -0800 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 LAA16756; Fri, 18 Jan 2002 11:38:48 +0100 (MET) Date: Fri, 18 Jan 2002 11:38:48 +0100 (MET) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Carsten Langgaard , Ralf Baechle , Linux/MIPS Development Subject: Re: IDE driver broken in bigendian 2.4.17 kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.sonytel.be id LAA16756 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0IBdsP18841 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 841 Lines: 25 On Thu, 17 Jan 2002, Maciej W. Rozycki wrote: > On Thu, 17 Jan 2002, Carsten Langgaard wrote: > > But all other architectures does it this way, so I'm just trying to follow > > the trend. > > It does not mean other architectures are right here. Possibly they have > not hit the problem so far. Yes we have. On m68k we had to redefine insw() and friends as well. But I agree it's an ugly hack that's been waiting for a clean up since many years. We had IDE on m68k in 1994... But IIRC André is working on that (among other things). 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 Jan 18 04:16:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ICGfg19739 for linux-mips-outgoing; Fri, 18 Jan 2002 04:16:41 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ICGSP19736; Fri, 18 Jan 2002 04:16:29 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA16818; Fri, 18 Jan 2002 12:16:16 +0100 (MET) Date: Fri, 18 Jan 2002 12:16:14 +0100 (MET) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IDE driver broken in bigendian 2.4.17 kernel In-Reply-To: <3C472F60.E5B62F0C@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1941 Lines: 40 On Thu, 17 Jan 2002, Carsten Langgaard wrote: > The order of header inclusions doesn't matter, because the ide.h file include the > io.h file, and that way io.h always get include first. > The '#ifndef' in all header file makes sure it only get included once. Then it's partially safe -- the definition used still depends on whether some code includes ide.h or not. > > If the problem is generic to a chipset, then you indeed need to redefine > > I/O macros, but then in . If that's PCI-specific, for example, > > then you should probably make the redefinition conditional on CONFIG_PCI. > > I'm not in a position, where I can fix and not at least test the changes, that it > needed in both the IDE driver as well as in all the other bigendian architectures > ide.h files. Nobody expects you to test changes on every possible system in existence. Just try to handle whatever you anticipate and let people test the changes. You can read the code and see what others expect from it -- most likely that will be accurate or you hit a comment on why something is not obvious. > I think my fix is the only one that doesn't break things for anyone else, you may > argue that it isn't the right one and I kind of agree, but at this point I think > it's the best solution. I'm afraid it is the kind of a defensive attitude that makes the arch/mips, include/asm-mips code so ugly and hackish in certain places. The discussion lists (linux-mips, linux-kernel and others, depending on the subsystem) exist for the purpose to send patches and let people test them. You need not be afraid something gets broken -- it happens all the time -- if anyone uses the code affected, someone will fix it, otherwise why to care at all? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 18 05:13:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDDQs22856 for linux-mips-outgoing; Fri, 18 Jan 2002 05:13:26 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDDNP22853 for ; Fri, 18 Jan 2002 05:13:23 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g0IDLLl10612; Fri, 18 Jan 2002 05:21:21 -0800 Date: Fri, 18 Jan 2002 05:21:21 -0800 (PST) From: Venkata Rajesh Bikkina To: flo@rfc822.org cc: linux-mips@oss.sgi.com, rajeshbv@intotoinc.com Subject: Illegal instruction error on MIPS 79s334A with kernel version 2.4.3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 587 Lines: 19 Hi all, I am facing a strange error in an user mode application. I am running this application as daemon in background process. The error i am getting is [iked:41] Illegal instruction 00000000 at 8036b364 ra=8036bb78 Got ri at 8036b624. [iked:41] Illegal instruction 00000004 at 8036b624 ra=8036b5ec Got ri at 8036b650. It is continiously displaying this error upto several seconds and then stopping. The daemon is also getting killed. I have aplied fast-sysmips patch by florian to my kernel. Still could not get rid of it. Can anybody through some light on this. Thanks, --Rajesh From owner-linux-mips@oss.sgi.com Fri Jan 18 05:31:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDVAP23141 for linux-mips-outgoing; Fri, 18 Jan 2002 05:31:10 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDV5P23138 for ; Fri, 18 Jan 2002 05:31:05 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id D168E84F; Fri, 18 Jan 2002 13:30:50 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id CE79F4395; Fri, 18 Jan 2002 13:31:07 +0100 (CET) Date: Fri, 18 Jan 2002 13:31:07 +0100 From: Florian Lohoff To: "Houten K.H.C. van (Karel)" Cc: karsten@excalibur.cologne.de, linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: DECStation debian CD's Message-ID: <20020118123107.GB32641@paradigm.rfc822.org> References: <20020117194913.GB26395@paradigm.rfc822.org> <200201180645.HAA14403@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <200201180645.HAA14403@sparta.research.kpn.com> User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 991 Lines: 36 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2002 at 07:45:52AM +0100, Houten K.H.C. van (Karel) wrote: > > Somebody would need to actually tune a bit for the prom calls for > > read/write of disks and the command line parameters. >=20 > Is there any documentation about those PROM's available? Yep Have a look at decstation.unix-ag.org Documentation/Turbochannel Firmware blah Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --vGgW1X5XWziG23Ko 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 iD8DBQE8SBWLUaz2rXW+gJcRAsxDAJ0ZaQFnkafYcELg4u/iGdUEqXq3SwCfThky dxYILlUdC3+/pDtu+ExcaiI= =8lHK -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-linux-mips@oss.sgi.com Fri Jan 18 05:40:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDeC323467 for linux-mips-outgoing; Fri, 18 Jan 2002 05:40:12 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDe6P23463 for ; Fri, 18 Jan 2002 05:40:06 -0800 Message-Id: <200201181340.g0IDe6P23463@oss.sgi.com> Received: (qmail 26869 invoked from network); 18 Jan 2002 12:34:49 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Jan 2002 12:34:49 -0000 Date: Fri, 18 Jan 2002 20:37:7 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: Fw: behavior of accessing undefined io ports X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1439 Lines: 46 hi,all We have trouble debugging a little fpga cpu. It seems that accesses to non-existing ports differ from what IDT cpu shows. Is there any standards that specifys the behavior? We have below code segment to demonstrate this problem: /* this results in 60 for idtRC64474,0 for our cpu */ prom_printf("before write *1ee=%x\n",inb(0x1ee)); outb(0xa0,0x1ee); /* this print 0 for idt,a0 for our cpu */ prom_printf("immediately after write:*1ee=%x\n",inb(0x1ee)); prom_printf("\nLINUX starting...\n"); prom_init_cmdline(); prom_meminit(); /* both print 0xa */ prom_printf("long after first write:*1ee=%x\n",inb(0x1ee)); outb(0xb0,0x1ee); /* idt print 0,ours b0 */ prom_printf("imme. after second write:*1ee=%x\n",inb(0x1ee)); inb(0x21); prom_printf("init done.\n"); /* both a */ prom_printf("long after second write:*1ee=%x\n",inb(0x1ee)); This hit us when linux probing ide drives: it writes to 0x1ee etc ports that doesn't exist there. Our cpu read back the exact value it writes to the port so it think the drive is there and makes unnecessary probing. And some other weird problems too. I haven't notice a clear statement for behaviors under such condition. Would you please help me out? Thank you in advance. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Fri Jan 18 10:59:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IIxhh05276 for linux-mips-outgoing; Fri, 18 Jan 2002 10:59:43 -0800 Received: from hermes.mvista.com ([12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IIxYP05273 for ; Fri, 18 Jan 2002 10:59:34 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0IHvTB07255; Fri, 18 Jan 2002 09:57:34 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Kunihiko IMAI Cc: linux-mips In-Reply-To: References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 18 Jan 2002 09:59:50 -0800 Message-Id: <1011376794.13904.37.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2777 Lines: 76 > Of course, I patched usb-ohci code with memory mapped I/O support. > It is very ugly code, so Linux USB stuff will not accept, I think. I think the work we did was clean, but it wasn't accepted anyway. Although, Steve L.'s initial work on mips usb did get accepted and that gave us usb on the it8172 system controller. > About two years ago, I ported USB OHCI to StrongARM SA1111 CPU and > SA1111 companion chip. At that time, I suggested to the author of > usb-ohci.c that it should be better to support of memory mapped I/O > device, but it was not accepted. On StrongARM, it has DMA memory > coherency problem, too. (Au1000 has bus snoop function, so this is not > a problem.) > > > > The errata report says workaround method: > > > - set the CPU clock is 384MHz > > > - set the source of USB host controller is CPU clcck. > > > > > > And the code: > > > > > > /* > > > * Setup 48MHz FREQ2 from CPUPLL for USB Host > > > */ > > > /* FRDIV2=3 -> div by 8 of 384MHz -> 48MHz */ > > > sys_freqctrl |= ((3<<22) | (1<<21) | (0<<20)); > > > outl(sys_freqctrl, FQ_CNTRL_1); > > > > > > Comment says "Setup FREQ2" but the code set FREQ5. > > > > It's the comment that's wrong, not the code. The code works and has been > > tested. Alchemy makes available the Linux Support Package (LSP) which > > we did. That kernel has been tested with all peripherals so I would > > recommend that you get that from them. Also,make sure your jumpers are > > setup correctly (S4). > > In the source code: > > sys_clksrc |= ((4<<12) | (0<<11) | (0<<10)); > > (snip...) > > outl(sys_clksrc, CLOCK_SOURCE_CNTRL); > > This code sets the clock source of USB host controller is FREQ2. So > FREQ5 clock source doesn't affect to USB host controller. I'll take a look at it, thanks. > And I found HHL version of kernel source code in Pb1000 CD-ROM. I'll > read it. I don't think you have the latest CDROM. That one you have probably has an older version of the LSP. > > > I do have a better USB workaround which checks the CPU silicon rev, but > > I haven't had time to send Ralf an updated patch. The current setup.c > > should work though. Get the latest LSP from Alchemy, check the S4 > > jumpers (1-4 off, 5-6 on, 7-8 off), and let me know if it still doesn't > > work for you. > > OK. I checked S4 DIP SW, it was setted same config. > # Pb1000 documentation doesn't clearly explain at this configration. > # So I looked schematics of Pb1000. > > This switch affects only J24 connector setting. J2 connector is not > affected by S4. The CDROM you have is most definitely old and might not have the latest usb code. Try the latest LSP from Alchemy. The rpms should have "hhl2.0.3" or later in the string. Pete From owner-linux-mips@oss.sgi.com Fri Jan 18 11:19:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IJJJ005681 for linux-mips-outgoing; Fri, 18 Jan 2002 11:19:19 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IJJBP05674 for ; Fri, 18 Jan 2002 11:19:12 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 04274125C1; Fri, 18 Jan 2002 10:19:09 -0800 (PST) Date: Fri, 18 Jan 2002 10:19:08 -0800 From: "H . J . Lu" To: Ulrich Drepper Cc: GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020118101908.C23887@lucon.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drepper@redhat.com on Thu, Jan 17, 2002 at 04:07:23PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2198 Lines: 61 On Thu, Jan 17, 2002 at 04:07:23PM -0800, Ulrich Drepper wrote: > The time is near when we (well, I) well start a drastic move toward > generally using thread registers. Even in non-threaded code. > > This means that unless all architectures get thread registers (or > equivalent things like Alpha's special code) we'll have a two class > society of platforms where all code written for the platforms without > thread register can be run on the other systems, but not vice versa. > > >From what I see today we have thread registers only on Alpha, x86, > IA-64, SH, and x86_64. SPARC shouldn't be too much of a problem. Sun > is using %g6 or %g7 (forgot which one) and since they define the ABI > no big complications are expected. > > Now, what is about the rest? I assume cris isn't much of a problem > since it's a purely embedded machine. > > > Arm: don't know whether this should fall in the same category. > Philip? > > > m68k: Well, maybe it's time to retire these machines. But on the > other hand, there are those useless address registers. Andreas, Jes? > > > PPC (32-bit) is known to be a problem. I've seen several proposals as > to what register to use but haven't seen a final decision. Problems > with the different PPC implementations are probably hindering this. > Geoff, could you please make a decision? I hope the PPC64 ABI already > allocated a thread register. > > > S390: I have no idea. Martin, please comment and make a decision. > > > MIPS: Who feels responsible? Andreas, HJ? > I don't see there are any registers we can use without breaking ABI. On the other hand, can we change the mips kernel to save k0 or k1 for user space? > > PA: no idea. HP has no 32-bit ELF so. But they have 64-bit ELF and > it definitely has a thread register. > > > > Please consider this a high priority task now. I've been warning > about this for a long time. Jakub is working on some code and once > this is ready for me to use I'll make lots of changes to ld.so and the > locale handling and from that point on we have the two classes of > architectures. > > Oh, this now also concerns Hurd. So, Roland, how far is using LDTs on > Hurd/x86? > H.J. From owner-linux-mips@oss.sgi.com Fri Jan 18 11:31:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IJVi105919 for linux-mips-outgoing; Fri, 18 Jan 2002 11:31:44 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IJVgP05916 for ; Fri, 18 Jan 2002 11:31:42 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA18072; Fri, 18 Jan 2002 10:31:23 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0IIVIc00695; Fri, 18 Jan 2002 10:31:18 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 10:31:17 -0800 In-Reply-To: <20020118101908.C23887@lucon.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 667 Lines: 15 "H . J . Lu" writes: > I don't see there are any registers we can use without breaking ABI. > On the other hand, can we change the mips kernel to save k0 or k1 for > user space? Are these registers which are readable by normal users but writable only in ring 0? If yes, this is definitely worthwhile (similar to how x86 works). The only problem will be the MIPS variants which don't have this register. I bet there are some. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 12:08:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IK8oA07183 for linux-mips-outgoing; Fri, 18 Jan 2002 12:08:50 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IK8lP07174 for ; Fri, 18 Jan 2002 12:08:47 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 19686125C1; Fri, 18 Jan 2002 11:08:44 -0800 (PST) Date: Fri, 18 Jan 2002 11:08:44 -0800 From: "H . J . Lu" To: Ulrich Drepper Cc: GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020118110844.A25165@lucon.org> References: <20020118101908.C23887@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drepper@redhat.com on Fri, Jan 18, 2002 at 10:31:17AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 704 Lines: 20 On Fri, Jan 18, 2002 at 10:31:17AM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > I don't see there are any registers we can use without breaking ABI. > > On the other hand, can we change the mips kernel to save k0 or k1 for > > user space? > > Are these registers which are readable by normal users but writable > only in ring 0? If yes, this is definitely worthwhile (similar to how I can write to k0/k1. But the value is not perserved by kernel. > x86 works). The only problem will be the MIPS variants which don't > have this register. I bet there are some. I don't think so. k0/k1 is reserved for OS. I don't know if OS can restore it for use space or not. H.J. From owner-linux-mips@oss.sgi.com Fri Jan 18 12:20:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IKKZb07574 for linux-mips-outgoing; Fri, 18 Jan 2002 12:20:35 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IKKVP07570 for ; Fri, 18 Jan 2002 12:20:32 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA22159; Fri, 18 Jan 2002 11:20:19 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0IJKHe00822; Fri, 18 Jan 2002 11:20:17 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> <20020118110844.A25165@lucon.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 11:20:17 -0800 In-Reply-To: <20020118110844.A25165@lucon.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 720 Lines: 18 "H . J . Lu" writes: > I can write to k0/k1. But the value is not perserved by kernel. Strange. This means the registers cannot have been used so far and if the kernel can be changed it is free. > I don't think so. k0/k1 is reserved for OS. I don't know if OS can > restore it for use space or not. There are so many different MIPS implementations that I wouldn't bet on it. One would have to look at the minimum architecture definition. Also, what do the new MIPS32 cores do? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 12:48:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IKmpa08801 for linux-mips-outgoing; Fri, 18 Jan 2002 12:48:51 -0800 Received: from hermes.mvista.com ([12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IKmkP08797 for ; Fri, 18 Jan 2002 12:48:47 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0IJklB14075; Fri, 18 Jan 2002 11:46:47 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Kunihiko IMAI Cc: linux-mips In-Reply-To: References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 18 Jan 2002 11:49:09 -0800 Message-Id: <1011383349.18177.6.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1271 Lines: 37 > > It's the comment that's wrong, not the code. The code works and has been > > tested. Alchemy makes available the Linux Support Package (LSP) which > > we did. That kernel has been tested with all peripherals so I would > > recommend that you get that from them. Also,make sure your jumpers are > > setup correctly (S4). > > In the source code: > > sys_clksrc |= ((4<<12) | (0<<11) | (0<<10)); > > (snip...) > > outl(sys_clksrc, CLOCK_SOURCE_CNTRL); > > This code sets the clock source of USB host controller is FREQ2. So > FREQ5 clock source doesn't affect to USB host controller. After looking into it, both the comment and code are correct. From include/asm-mips/au1000.h: #define FQ_CNTRL_1 0xB1900020 #define FQ_CNTRL_2 0xB1900024 So FQ_CNTRL_1 corresponds to what is now sys_freqctrl0. In other words, the update to the databook has not been incorporated into the Au1000 files. The names of the registers were updated after I had done all the core work. I need to update the code so the names of the registers correspond to the latest Au1000 manual. Since the boards we have do work with USB and there were some usb hardware glitches, please check with Alchemy on what the problem might be with your board. Pete From owner-linux-mips@oss.sgi.com Fri Jan 18 13:13:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILD0X09516 for linux-mips-outgoing; Fri, 18 Jan 2002 13:13:00 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILCsP09510 for ; Fri, 18 Jan 2002 13:12:54 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00406 for ; Fri, 18 Jan 2002 12:08:24 -0800 (PST) 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 VAA00311; Fri, 18 Jan 2002 21:03:38 +0100 (MET) Date: Fri, 18 Jan 2002 21:03:38 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "H . J . Lu" cc: Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <20020118101908.C23887@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1805 Lines: 41 On Fri, 18 Jan 2002, H . J . Lu wrote: > > This means that unless all architectures get thread registers (or > > equivalent things like Alpha's special code) we'll have a two class > > society of platforms where all code written for the platforms without > > thread register can be run on the other systems, but not vice versa. [...] > On the other hand, can we change the mips kernel to save k0 or k1 for > user space? No way. MIPS doesn't predefine any stack-switching hardware and it doesn't save any registers on exceptions (except from copying pc to cp0's epc or errorepc). The k0, k1 registers are defined as reserved for the kernel use to switch to a kernel stack and save current values of other registers upon a kernel entry due to an exception. The general exception handler (used for almost everything, including interrupts for most systems) uses the registers this way to "bootstrap" itself. The dedicated TLB exception handler, which needs to be very fast for any reasonable performance to achieve, uses these two registers solely, without even touching anything else. As a result, anything written to k0 or k1 is lost immediately after the first exception to happen afterwards. Of course, this use of k0, k1 is purely conventional -- they are ordinary 32-bit general-purpose registers from the hardware point of view. Only zero and, to some extent, ra registers are different on MIPS. The usage of all 32 registers is fixed in the ABI for MIPS. But what about that Alpha's special code? It could possibly be reused given the large Alpha's similarity to MIPS. 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 Jan 18 13:21:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILL9209977 for linux-mips-outgoing; Fri, 18 Jan 2002 13:21:09 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILL6P09974 for ; Fri, 18 Jan 2002 13:21:07 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA27511; Fri, 18 Jan 2002 12:20:53 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0IKKpP00956; Fri, 18 Jan 2002 12:20:51 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "Maciej W. Rozycki" Cc: "H . J . Lu" , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 12:20:51 -0800 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 688 Lines: 15 "Maciej W. Rozycki" writes: > But what about that Alpha's special code? It could possibly be > reused given the large Alpha's similarity to MIPS. No. Alpha has certain builtin code which looks similar to calls or software interrupts but are executed in the CPU. This allows access to some memory in the CPU which is almost as fast as a normal register access. MIPS doesn't have such hardware. If you cannot find a register you're doomed. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 13:50:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILoDa11145 for linux-mips-outgoing; Fri, 18 Jan 2002 13:50:13 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILo9P11141 for ; Fri, 18 Jan 2002 13:50:10 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA01283; Fri, 18 Jan 2002 21:50:08 +0100 (MET) Date: Fri, 18 Jan 2002 21:50:08 +0100 (MET) From: "Maciej W. Rozycki" To: Ulrich Drepper cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 931 Lines: 23 On 18 Jan 2002, Ulrich Drepper wrote: > > But what about that Alpha's special code? It could possibly be > > reused given the large Alpha's similarity to MIPS. > > No. Alpha has certain builtin code which looks similar to calls or > software interrupts but are executed in the CPU. This allows access Yep, PALcode is possibly the most significant difference. > to some memory in the CPU which is almost as fast as a normal register > access. MIPS doesn't have such hardware. If you cannot find a > register you're doomed. Hmm, why would an ABI reserve spare registers for a possible future use that might never happen? We can probably define a new ABI specifically for Linux, though, if the gain surpasses the loss. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 18 14:03:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IM37t11497 for linux-mips-outgoing; Fri, 18 Jan 2002 14:03:07 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IM33P11494 for ; Fri, 18 Jan 2002 14:03:03 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA01214; Fri, 18 Jan 2002 13:02:53 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0IL2nO01100; Fri, 18 Jan 2002 13:02:49 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 13:02:48 -0800 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 999 Lines: 19 "Maciej W. Rozycki" writes: > Hmm, why would an ABI reserve spare registers for a possible future > use that might never happen? We can probably define a new ABI > specifically for Linux, though, if the gain surpasses the loss. I don't really care what is done for MIPS and there is no reason to find excuses for not having the foresight. I just present the facts: if there is no thread register or something equally fast MIPS will be one of the platforms which will have only a subset of the functionality of the other Linux architectures and not all applications will be able to be compiled for MIPS. That's all. If this is fine (e.g., for MIPS on embedded platforms) then all is good. If somebody wants to use threads and MIPS there is a problem. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 14:23:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMNY511919 for linux-mips-outgoing; Fri, 18 Jan 2002 14:23:34 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMNVP11915 for ; Fri, 18 Jan 2002 14:23:31 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16RgTt-00057P-00; Fri, 18 Jan 2002 16:23:25 -0500 Date: Fri, 18 Jan 2002 16:23:25 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020118162325.A19122@nevyn.them.org> References: <20020118101908.C23887@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020118101908.C23887@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 780 Lines: 19 On Fri, Jan 18, 2002 at 10:19:08AM -0800, H . J . Lu wrote: > > MIPS: Who feels responsible? Andreas, HJ? > > > > I don't see there are any registers we can use without breaking ABI. > On the other hand, can we change the mips kernel to save k0 or k1 for > user space? No, there are no free registers and $k0/$k1 are needed by the kernel for exceptions. The only way I can see to do this would be to change the ABI. There are none available; the least used that I see is $v1, but $v1 is used to return half of a double precision return value. We would have to steal one of the existing call-saved or call-clobbered registers. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Jan 18 14:25:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMP2m11996 for linux-mips-outgoing; Fri, 18 Jan 2002 14:25:02 -0800 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMOuP11992 for ; Fri, 18 Jan 2002 14:24:56 -0800 Received: from GS256.SP.CS.CMU.EDU by ux3.sp.cs.cmu.edu id aa04181; 18 Jan 2002 16:24 EST Subject: Re: thread-ready ABIs From: Justin Carlson To: drepper@redhat.com Cc: linux-mips@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2fAJiySWyIN6gBSOSi2M" X-Mailer: Evolution/0.99.2 (Preview Release) Date: 18 Jan 2002 16:24:45 -0500 Message-Id: <1011389085.7765.69.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1605 Lines: 45 --=-2fAJiySWyIN6gBSOSi2M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable For those of us who are slightly behind, could you give some brief summary of what this thread register hullabaloo is about? I hadn't been following this thread, but a search of the archives makes it look like it hasn't really been explained yet. _Why_ do we need a general register which is read-only to userland? Are you trying to store thread-context information in a fast way? Why does this need to happen? Depending on what the exact requirements are, I could see several ways to free up a register: We could, theoretically, free up k1 or k0 (but not both) at the expense of some time in the stackframe setup at the userland/kernel boundary and some time in the fast TLB handler. This wouldn't be read-only from userland, though, but is that really a hard requirement? =20 There is precedent for hijacking some CP0 registers for purposes other than originally intended, e.g., the WATCH registers for holding the kernel stack pointer. I don't have a mips spec in front of me, though, so I don't know if any CP0 registers are readable from userland: I seem to remember that all mfc0 ops are priveleged at the instruction level, not the register level, though. -Justin --=-2fAJiySWyIN6gBSOSi2M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8SJKd47Lg4cGgb74RAvf6AKDAd7EKEAQIHYuguF68sEcX/0j4cwCgyRwh HNEZEcjWNgS4q9VIZKgRQJc= =3T0G -----END PGP SIGNATURE----- --=-2fAJiySWyIN6gBSOSi2M-- From owner-linux-mips@oss.sgi.com Fri Jan 18 14:32:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMWBA12189 for linux-mips-outgoing; Fri, 18 Jan 2002 14:32:11 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMW8P12186 for ; Fri, 18 Jan 2002 14:32:09 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA03905; Fri, 18 Jan 2002 13:32:01 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0ILVxE13939; Fri, 18 Jan 2002 13:31:59 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <1011389085.7765.69.camel@gs256.sp.cs.cmu.edu> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 13:31:59 -0800 In-Reply-To: <1011389085.7765.69.camel@gs256.sp.cs.cmu.edu> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 606 Lines: 14 Justin Carlson writes: > _Why_ do we need a general register which is read-only to userland? Are > you trying to store thread-context information in a fast way? Why does > this need to happen? Read-only is no requirement. It is possible to live with this arrangement is all I said. If it's a normal register, fine, this is how it works on most platforms. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 14:35:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMZww12308 for linux-mips-outgoing; Fri, 18 Jan 2002 14:35:58 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMZqP12305 for ; Fri, 18 Jan 2002 14:35:53 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA02307; Fri, 18 Jan 2002 22:35:49 +0100 (MET) Date: Fri, 18 Jan 2002 22:35:49 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ulrich Drepper cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1631 Lines: 38 On 18 Jan 2002, Ulrich Drepper wrote: > I don't really care what is done for MIPS and there is no reason to > find excuses for not having the foresight. I just present the facts: Tell that to the SysV committee. ;-) BTW, the i386 ABI supplement defines no spare registers, either -- all are already assigned. Where did you get extraneous registers for the i386 from (especially given the usual register shortage there)? Maybe we could use the same approach for MIPS. Where to look for the code in glibc in a current snapshot? One possible approach is to reserve GOT entries for thread registers. While not as fast as CPU's registers, if frequently accessed they would stick in the cache. Since the ABI mandates the code to keep a pointer to the GOT in the gp register, accesses to got entries need only a single instruction. I haven't thought on it much -- someone might have a better idea. > if there is no thread register or something equally fast MIPS will be > one of the platforms which will have only a subset of the > functionality of the other Linux architectures and not all > applications will be able to be compiled for MIPS. That's all. If > this is fine (e.g., for MIPS on embedded platforms) then all is good. > If somebody wants to use threads and MIPS there is a problem. I have only workstation/server MIPS systems and I do care. Maciej PS. Too bad libc-hacker rejects my submissions... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 18 14:43:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMhin12485 for linux-mips-outgoing; Fri, 18 Jan 2002 14:43:44 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMhcP12481 for ; Fri, 18 Jan 2002 14:43:38 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA02492; Fri, 18 Jan 2002 22:42:15 +0100 (MET) Date: Fri, 18 Jan 2002 22:42:15 +0100 (MET) From: "Maciej W. Rozycki" To: Justin Carlson cc: drepper@redhat.com, linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <1011389085.7765.69.camel@gs256.sp.cs.cmu.edu> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1238 Lines: 28 On 18 Jan 2002, Justin Carlson wrote: > We could, theoretically, free up k1 or k0 (but not both) at the expense > of some time in the stackframe setup at the userland/kernel boundary and > some time in the fast TLB handler. This wouldn't be read-only from > userland, though, but is that really a hard requirement? Much, *much* time, especially in the case of TLB exceptions. > There is precedent for hijacking some CP0 registers for purposes other > than originally intended, e.g., the WATCH registers for holding the > kernel stack pointer. I don't have a mips spec in front of me, though, That's not used exactly a stack pointer, but as a safeguard. I'm still thinking on a better use of this register, i.e. as a watchpoint for gdb. > so I don't know if any CP0 registers are readable from userland: I seem > to remember that all mfc0 ops are priveleged at the instruction level, > not the register level, though. Technically you can make cp0 registers r/w accessible from the userland, but that's unacceptable for us. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jan 18 14:44:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IMiuu12567 for linux-mips-outgoing; Fri, 18 Jan 2002 14:44:56 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IMipP12557 for ; Fri, 18 Jan 2002 14:44:52 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA05057; Fri, 18 Jan 2002 13:44:45 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0ILiib13822; Fri, 18 Jan 2002 13:44:44 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "Maciej W. Rozycki" Cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Jan 2002 13:44:44 -0800 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1125 Lines: 30 "Maciej W. Rozycki" writes: > Where did you get extraneous registers for the i386 > from (especially given the usual register shortage there)? %gs > Maybe we could use the same approach for MIPS. I doubt it. > Where to look for the code in glibc in a current snapshot? %gs is used for a long time linuxthreads/sysdeps/386/useldt.h > One possible approach is to reserve GOT entries for thread registers. > While not as fast as CPU's registers, if frequently accessed they would > stick in the cache. Since the ABI mandates the code to keep a pointer to > the GOT in the gp register, accesses to got entries need only a single > instruction. I haven't thought on it much -- someone might have a better > idea. How would you have different values for different threads? It would mean having multiple GOTs which is a resource waste and a nightmare in resource management. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jan 18 15:17:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0INHP613308 for linux-mips-outgoing; Fri, 18 Jan 2002 15:17:25 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0INHIP13302 for ; Fri, 18 Jan 2002 15:17:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA03355; Fri, 18 Jan 2002 23:17:15 +0100 (MET) Date: Fri, 18 Jan 2002 23:17:14 +0100 (MET) From: "Maciej W. Rozycki" To: Ulrich Drepper cc: "H . J . Lu" , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1540 Lines: 45 On 18 Jan 2002, Ulrich Drepper wrote: > > Where did you get extraneous registers for the i386 > > from (especially given the usual register shortage there)? > > %gs Ah well, then you just have it by an accident and not because it was specifically designed to be spare... > > Maybe we could use the same approach for MIPS. > > I doubt it. Indeed. > > Where to look for the code in glibc in a current snapshot? > > %gs is used for a long time linuxthreads/sysdeps/386/useldt.h Thanks. > > One possible approach is to reserve GOT entries for thread registers. > > While not as fast as CPU's registers, if frequently accessed they would > > stick in the cache. Since the ABI mandates the code to keep a pointer to > > the GOT in the gp register, accesses to got entries need only a single > > instruction. I haven't thought on it much -- someone might have a better > > idea. > > How would you have different values for different threads? It would > mean having multiple GOTs which is a resource waste and a nightmare in > resource management. OK, now I understand you need some kind of a tid, that needs not be writeable. A read-only register can be moderately easily provided by either k0 or k1 if exit paths of exceptions reload the given one. The trail code of exceptions only needs one of them at most. 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 Jan 18 17:35:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J1ZDk16320 for linux-mips-outgoing; Fri, 18 Jan 2002 17:35:13 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J1Z9P16316 for ; Fri, 18 Jan 2002 17:35:09 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA22468; Fri, 18 Jan 2002 16:34:58 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA08107; Fri, 18 Jan 2002 16:34:55 -0800 (PST) Message-ID: <01b801c1a081$3f6518e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "H . J . Lu" , "Ulrich Drepper" Cc: "GNU libc hacker" , References: <20020118101908.C23887@lucon.org> Subject: Re: thread-ready ABIs Date: Sat, 19 Jan 2002 01:35:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1328 Lines: 34 > On Thu, Jan 17, 2002 at 04:07:23PM -0800, Ulrich Drepper wrote: > > The time is near when we (well, I) well start a drastic move toward > > generally using thread registers. Even in non-threaded code. > > > > This means that unless all architectures get thread registers (or > > equivalent things like Alpha's special code) we'll have a two class > > society of platforms where all code written for the platforms without > > thread register can be run on the other systems, but not vice versa. [snip] > > MIPS: Who feels responsible? Andreas, HJ? > > I don't see there are any registers we can use without breaking ABI. > On the other hand, can we change the mips kernel to save k0 or k1 for > user space? Thank you for posting this to linux-mips, since I'm not sure that anyone at MIPS is on the GNU_libc_hacker list. It would, in principle, be possible to save/restore k0 or k1 (but not both) if no other clever solution can be found. There are other VM OSes that manage to do so for MIPS, for other outside-the-old-ABI reasons. It does, of course, add some instructions and some memory traffic to the low-level exception handling , and we would have to look at whether we would want to make such a feature standard or specific to a "thread-ready" kernel build. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Fri Jan 18 21:11:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J5BjQ20429 for linux-mips-outgoing; Fri, 18 Jan 2002 21:11:45 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J5BgP20422 for ; Fri, 18 Jan 2002 21:11:43 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9D373125C1; Fri, 18 Jan 2002 20:11:39 -0800 (PST) Date: Fri, 18 Jan 2002 20:11:39 -0800 From: "H . J . Lu" To: "Kevin D. Kissell" Cc: Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020118201139.A847@lucon.org> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01b801c1a081$3f6518e0$0deca8c0@Ulysses>; from kevink@mips.com on Sat, Jan 19, 2002 at 01:35:38AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 749 Lines: 17 On Sat, Jan 19, 2002 at 01:35:38AM +0100, Kevin D. Kissell wrote: > > It would, in principle, be possible to save/restore k0 > or k1 (but not both) if no other clever solution can be found. > There are other VM OSes that manage to do so for MIPS, > for other outside-the-old-ABI reasons. It does, of course, > add some instructions and some memory traffic to the > low-level exception handling , and we would have to look > at whether we would want to make such a feature standard > or specific to a "thread-ready" kernel build. I like the read-only k0 idea. We just need to make a system call to tell kernel what value to put in k0 before returning to the user space. It shouldn't be too hard to implement. I will try it next week. H.J. From owner-linux-mips@oss.sgi.com Sat Jan 19 00:19:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J8JWZ24597 for linux-mips-outgoing; Sat, 19 Jan 2002 00:19:32 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J8I1P24577 for ; Sat, 19 Jan 2002 00:18:01 -0800 Received: (qmail 14966 invoked from network); 19 Jan 2002 07:17:56 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 19 Jan 2002 07:17:55 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16RplD-0003Ql-00 for ; Sat, 19 Jan 2002 00:17:55 -0700 Date: Sat, 19 Jan 2002 00:17:54 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: linux-mips@oss.sgi.com Subject: [PATCH] SR7100 support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 27251 Lines: 880 Hello, Here is a patch to add support for the new SandCraft SR7100 processor. The SR7100 is a faster pin compatible replacement for the RM7000 family of chips but implements MIPS64 and has a different cache configuration. This patch includes a fix for 1 errata in current chips, the wait instruction doesn't work quite right. It is possible to omit this (ugly!) fix but the CPU runs a little hot.. :> The patch is against the linux_2_4 branch of CVS, I have not yet tried HEAD.. Jason diff --exclude CVS -bBrNu ./arch/mips/Makefile ../linux_2_4_branch/arch/mips/Makefile --- ./arch/mips/Makefile Fri Jan 18 23:35:38 2002 +++ ../linux_2_4_branch/arch/mips/Makefile Fri Jan 18 23:38:57 2002 @@ -93,6 +93,9 @@ MODFLAGS += -msb1-pass1-workarounds endif endif +ifdef CONFIG_CPU_SR7100 +GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap +endif GCCFLAGS += -pipe diff --exclude CVS -bBrNu ./arch/mips/config.in ../linux_2_4_branch/arch/mips/config.in --- ./arch/mips/config.in Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/config.in Fri Jan 18 23:39:09 2002 @@ -331,6 +331,7 @@ R5000 CONFIG_CPU_R5000 \ R5432 CONFIG_CPU_R5432 \ RM7000 CONFIG_CPU_RM7000 \ + SR7100 CONFIG_CPU_SR7100 \ R52xx CONFIG_CPU_NEVADA \ R10000 CONFIG_CPU_R10000 \ SB1 CONFIG_CPU_SB1 \ diff --exclude CVS -bBrNu ./arch/mips/kernel/Makefile ../linux_2_4_branch/arch/mips/kernel/Makefile --- ./arch/mips/kernel/Makefile Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/kernel/Makefile Sat Jan 12 15:54:45 2002 @@ -39,6 +39,7 @@ obj-$(CONFIG_CPU_SB1) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_MIPS32) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_MIPS64) += r4k_fpu.o r4k_switch.o +obj-$(CONFIG_CPU_SR7100) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R6000) += r6000_fpu.o r4k_switch.o obj-$(CONFIG_SMP) += smp.o diff --exclude CVS -bBrNu ./arch/mips/kernel/entry.S ../linux_2_4_branch/arch/mips/kernel/entry.S --- ./arch/mips/kernel/entry.S Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/kernel/entry.S Sun Jan 13 00:57:24 2002 @@ -50,7 +50,29 @@ lw t0, PT_STATUS(sp) # returning to kernel mode? andi t0, t0, KU_USER bnez t0, ret_from_sys_call +EXPORT(ret_from_irq_sr7100) j restore_all + +/* SR7100 Errata: The wait instruction that does not advance EPC. The solution + is to check if epc is pointing at a wait instruction and if so, skip it. + This must be after ret_from_irq. The setup code will nop out the jump above + so we fall through. wait instructions are only fixed if they are in the + kernel */ +#ifdef CONFIG_CPU_SR7100 + // Fetch EPC + lw t0,PT_EPC(sp) + + // Is the instruction a wait? + li t2,0x42000000 + lw t1,0(t0) + ori t2,t2,0x20 + bne t1,t2,restore_all + + // Yep, go to the next instruction + addu t1,t0,4 + sw t1,PT_EPC(sp) + j restore_all +#endif reschedule: jal schedule diff --exclude CVS -bBrNu ./arch/mips/kernel/setup.c ../linux_2_4_branch/arch/mips/kernel/setup.c --- ./arch/mips/kernel/setup.c Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/kernel/setup.c Fri Jan 18 23:40:56 2002 @@ -46,6 +46,7 @@ #ifndef CONFIG_SMP struct cpuinfo_mips cpu_data[1]; #endif +#include /* * Not all of the MIPS CPUs have the "wait" instruction available. Moreover, @@ -121,10 +122,12 @@ extern void SetUpBootInfo(void); extern void loadmmu(void); extern asmlinkage void start_kernel(void); +extern asmlinkage void ret_from_irq_sr7100(void); extern void prom_init(int, char **, char **, int *); static struct resource code_resource = { "Kernel code" }; static struct resource data_resource = { "Kernel data" }; +static void sr7100_wait(void); static inline void check_wait(void) { @@ -153,6 +156,11 @@ cpu_wait = r4k_wait; printk(" available.\n"); break; + + case CPU_SR7100: + cpu_wait = sr7100_wait; + printk(" errata work around.\n"); + break; default: printk(" unavailable.\n"); break; @@ -519,6 +527,21 @@ break; } break; + + case PRID_COMP_SANDCRAFT: + mips_cpu.cputype = CPU_UNKNOWN; + switch (mips_cpu.processor_id & 0xff00) { + case PRID_IMP_SR7100: + mips_cpu.cputype = CPU_SR7100; + mips_cpu.isa_level = MIPS_CPU_ISA_M64; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | + MIPS_CPU_4KTLB | MIPS_CPU_FPU | + MIPS_CPU_COUNTER | MIPS_CPU_DIVEC | + MIPS_CPU_MCHECK; + mips_cpu.scache.ways = 8; + break; + } + break; default: mips_cpu.cputype = CPU_UNKNOWN; } @@ -802,6 +825,7 @@ hp_setup(); break; #endif + default: panic("Unsupported architecture"); } @@ -986,6 +1010,39 @@ __asm__(".set\tmips3\n\t" "wait\n\t" ".set\tmips0"); +} + +/* Fix the sr7100 wait errata. We have a special ret_from_irq that is executed + when a jump is converted to a nop. Before we wait we do that conversion. + This engages the code that detects the errata. This way we don't loose any + speed in the normal case. Though it does make the timing race with wait + longer.. */ +static void sr7100_wait(void) +{ + u32 *jump = ((u32 *)&ret_from_irq_sr7100); + __asm__ __volatile__ + ( + ".set push\n\t" + ".set noat\n\t" + ".set noreorder\n\t" + ".set mips3\n\t" + "lw $1,0(%0)\n\t" + "sw $0,0(%0)\n\t" + + // No snoopy i/d cache.. + "cache %1,0(%0)\n\t" + "cache %2,0(%0)\n\t" + + "wait\n\t" + "sw $1,0(%0)\n\t" + + "cache %1,0(%0)\n\t" + "cache %2,0(%0)\n\t" + + ".set pop\n\t" + : + : "r" (jump), "i"(Hit_Writeback_D), "i"(Hit_Invalidate_I) + : "$1"); } int __init fpu_disable(char *s) diff --exclude CVS -bBrNu ./arch/mips/mm/Makefile ../linux_2_4_branch/arch/mips/mm/Makefile --- ./arch/mips/mm/Makefile Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/mm/Makefile Sat Jan 12 15:59:04 2002 @@ -30,6 +30,7 @@ obj-$(CONFIG_CPU_R10000) += pg-andes.o c-andes.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_MIPS32) += pg-mips32.o c-mips32.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_MIPS64) += pg-mips32.o c-mips32.o tlb-r4k.o tlbex-r4k.o +obj-$(CONFIG_CPU_SR7100) += pg-mips32.o c-sr7100.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_SB1) += pg-sb1.o c-sb1.o tlb-sb1.o tlbex-r4k.o obj-$(CONFIG_SGI_IP22) += umap.o diff --exclude CVS -bBrNu ./arch/mips/mm/c-sr7100.c ../linux_2_4_branch/arch/mips/mm/c-sr7100.c --- ./arch/mips/mm/c-sr7100.c Wed Dec 31 17:00:00 1969 +++ ../linux_2_4_branch/arch/mips/mm/c-sr7100.c Fri Jan 18 23:43:40 2002 @@ -0,0 +1,584 @@ +/* + Jason Gunthorpe + Copyright (C) 2002 YottaYotta. Inc. + + Based on c-mips32: + Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com + Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + + 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. + + Sandcraft SR7100 cache routines. + The SR7100 is a MIPS64 compatible CPU with 4 caches: + * 4 way 32K primary ICache - virtually indexed/physically tagged + * 4 way 32K primary DCache - virtually indexed/physically tagged + * 8 way 512K secondary cache - physically indexed/taged + * 8 way up to 16M tertiary cache - physically indexed/taged (and off chip) + + ICache and DCache do not have any sort of snooping. Unlike the RM7k, + the virtual index is 13 bits, and we use a 4k page size. This means you + can have cache aliasing effects, so they have to be treated as virtually + tagged. (unless that can be solved elsewhere, should investigate) + + Note that on this chip all the _SD type cache ops (ie Hit_Writeback_Inv_SD) + are really just _S. This is in line with what the MIPS64 spec permits. + Also, the line size of the tertiary cache is really the block size. The + line size is always 32 bytes. The chip can tag partial blocks and the cache + op instructions work on those partial blocks too. + + See ./Documentation/cachetlb.txt + */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +// Should move to mipsregs.h +#define read_32bit_cp0_registerx(source,sel) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tpush\n\t" \ + ".set\treorder\n\t" \ + ".set\tmips64\n\t" \ + "mfc0\t%0,"STR(source)","STR(sel)"\n\t" \ + ".set\tmips0\n\t" \ + ".set\tpop" \ + : "=r" (__res)); \ + __res;}) +#define write_32bit_cp0_registerx(register,sel,value) \ + __asm__ __volatile__( \ + ".set\tmips64\n\t" \ + "mtc0\t%0,"STR(register)","STR(sel)"\n\t" \ + ".set\tmips0\n\t" \ + "nop" \ + : : "r" (value)); + +#undef DEBUG_CACHE + +/* Primary cache parameters. */ +int icache_size, dcache_size; /* Size in bytes */ +int ic_lsize, dc_lsize; /* LineSize in bytes */ + +/* Secondary cache parameters. */ +unsigned int scache_size, sc_lsize; /* Again, in bytes */ + +/* tertiary cache (if present) parameters. */ +unsigned int tcache_size, tc_lsize; /* Again, in bytes */ + +#include +#include + +// Unique the SR7100 +#define Index_Invalidate_T 0x2 +#define Hit_Invalidate_T 0x16 +static inline void blast_tcache(void) +{ + unsigned long start = KSEG0; + unsigned long end = KSEG0 + tcache_size; + + // Could use flash invalidate perhaps.. + while(start < end) + { + cache_unroll(start,Index_Invalidate_T); + start += tc_lsize; + } +} + +static inline void flush_tcache_line(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_Invalidate_T)); +} + +/* + * Dummy cache handling routines for machines without boardcaches + */ +static void no_sc_noop(void) {} + +static struct bcache_ops no_sc_ops = { + (void *)no_sc_noop, (void *)no_sc_noop, + (void *)no_sc_noop, (void *)no_sc_noop +}; +struct bcache_ops *bcops = &no_sc_ops; + +// Clean all virtually indexed caches +static inline void sr7100_flush_cache_all_pc(void) +{ + unsigned long flags; + + __save_and_cli(flags); + blast_dcache(); blast_icache(); + __restore_flags(flags); +} + +// This clears all caches. It is only used from a syscall.. +static inline void sr7100_nuke_caches(void) +{ + unsigned long flags; + + __save_and_cli(flags); + blast_dcache(); blast_icache(); blast_scache(); + if (tcache_size != 0) + blast_tcache(); + __restore_flags(flags); +} + +/* This is called to clean out a virtual mapping. We only need to flush the + I and D caches since the other two are physically tagged */ +static void sr7100_flush_cache_range_pc(struct mm_struct *mm, + unsigned long start, + unsigned long end) +{ + if(mm->context != 0) { + unsigned long flags; + +#ifdef DEBUG_CACHE + printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); +#endif + __save_and_cli(flags); + blast_dcache(); blast_icache(); + __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. + * Again, only clean the virtually tagged cache. + */ +static void sr7100_flush_cache_mm_pc(struct mm_struct *mm) +{ + if(mm->context != 0) { +#ifdef DEBUG_CACHE + printk("cmm[%d]", (int)mm->context); +#endif + sr7100_flush_cache_all_pc(); + } +} + +static void sr7100_flush_cache_page_pc(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; + + /* + * 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_VALID)) + goto out; + + /* + * Doing flushes for another ASID than the current one is + * too difficult since Mips32 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) { + blast_dcache_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_dcache_page_indexed(page); + } +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 sr7100_flush_page_to_ram_pc(struct page *page) +{ + blast_dcache_page((unsigned long)page_address(page)); +} + +/* I-Cache and D-Cache are seperate and virtually tagged, these need to + flush them */ +static void sr7100_flush_icache_range(unsigned long start, unsigned long end) +{ + flush_cache_all(); // only does i and d, probably excessive +} + +static void sr7100_flush_icache_page(struct vm_area_struct *vma, + struct page *page) +{ + int address; + + if (!(vma->vm_flags & VM_EXEC)) + return; + + address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (dcache_size - 1)); + blast_icache_page_indexed(address); +} + +/* Writeback and invalidate the primary cache dcache before DMA. + See asm-mips/io.h + */ +static void sr7100_dma_cache_wback_inv_sc(unsigned long addr, + unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + sr7100_nuke_caches(); + return; + } + + a = addr & ~(sc_lsize - 1); + end = (addr + size) & ~(sc_lsize - 1); + while (1) { + flush_dcache_line(a); + flush_scache_line(a); // Hit_Writeback_Inv_SD + if (a == end) break; + a += sc_lsize; + } +} + +static void sr7100_dma_cache_wback_inv_tc(unsigned long addr, + unsigned long size) +{ + unsigned long end, a; + + a = addr & ~(sc_lsize - 1); + end = (addr + size) & ~(sc_lsize - 1); + while (1) { + flush_dcache_line(a); + flush_scache_line(a); // Hit_Writeback_Inv_SD + flush_tcache_line(a); // Hit_Invalidate_T + if (a == end) break; + a += sc_lsize; + } +} + +/* It is kind of silly to writeback for the inv case.. Oh well */ +static void sr7100_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + sr7100_nuke_caches(); + return; + } + + a = addr & ~(sc_lsize - 1); + end = (addr + size) & ~(sc_lsize - 1); + while (1) { + flush_dcache_line(a); + flush_scache_line(a); // Hit_Writeback_Inv_SD + if (a == end) break; + a += sc_lsize; + } +} + +static void sr7100_dma_cache_inv_tc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + a = addr & ~(sc_lsize - 1); + end = (addr + size) & ~(sc_lsize - 1); + while (1) { + flush_dcache_line(a); + flush_scache_line(a); // Hit_Writeback_Inv_SD + flush_tcache_line(a); // Hit_Invalidate_T + if (a == end) break; + a += sc_lsize; + } +} + +static void sr7100_dma_cache_wback(unsigned long addr, unsigned long size) +{ + panic("sr7100_dma_cache_wback called - should not happen."); +} + +/* + * 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 sr7100_flush_cache_sigtramp(unsigned long addr) +{ + protected_writeback_dcache_line(addr & ~(dc_lsize - 1)); + protected_flush_icache_line(addr & ~(ic_lsize - 1)); +} + +/* Detect and size the various caches. */ +static void __init probe_icache(unsigned long config,unsigned long config1) +{ + unsigned int lsize; + + config1 = read_mips32_cp0_config1(); + + if ((lsize = ((config1 >> 19) & 7))) + mips_cpu.icache.linesz = 2 << lsize; + else + mips_cpu.icache.linesz = lsize; + mips_cpu.icache.sets = 64 << ((config1 >> 22) & 7); + mips_cpu.icache.ways = 1 + ((config1 >> 16) & 7); + + ic_lsize = mips_cpu.icache.linesz; + icache_size = mips_cpu.icache.sets * mips_cpu.icache.ways * + ic_lsize; + printk("Primary instruction cache %dkb, linesize %d bytes (%d ways)\n", + icache_size >> 10, ic_lsize, mips_cpu.icache.ways); +} + +static void __init probe_dcache(unsigned long config,unsigned long config1) +{ + unsigned int lsize; + + if ((lsize = ((config1 >> 10) & 7))) + mips_cpu.dcache.linesz = 2 << lsize; + else + mips_cpu.dcache.linesz = lsize; + mips_cpu.dcache.sets = 64 << ((config1 >> 13) & 7); + mips_cpu.dcache.ways = 1 + ((config1 >> 7) & 7); + + dc_lsize = mips_cpu.dcache.linesz; + dcache_size = + mips_cpu.dcache.sets * mips_cpu.dcache.ways + * dc_lsize; + printk("Primary data cache %dkb, linesize %d bytes (%d ways)\n", + dcache_size >> 10, dc_lsize, mips_cpu.dcache.ways); +} + +static void __init probe_scache(unsigned long config,unsigned long config2) +{ + unsigned int lsize; + + if ((lsize = ((config2 >> 4) & 7))) + mips_cpu.scache.linesz = 2 << lsize; + else + mips_cpu.scache.linesz = lsize; + + mips_cpu.scache.sets = 64 << ((config2 >> 8) & 7); + mips_cpu.scache.ways = 1 + ((config2 >> 0) & 7); + + sc_lsize = mips_cpu.scache.linesz; + scache_size = mips_cpu.scache.sets * mips_cpu.scache.ways * sc_lsize; + + printk("Secondary cache %dK, linesize %d bytes (%d ways)\n", + scache_size >> 10, sc_lsize, mips_cpu.scache.ways); +} + +static void __init probe_tcache(unsigned long config,unsigned long config2) +{ + unsigned int lsize; + + /* Firmware or prom_init is required to configure the size of the + tertiary cache in config2 and set the TE bit in config2 to signal + the external SRAM chips are present. */ + if ((config2 & (1<<28)) == 0) + return; + + if ((lsize = ((config2 >> 20) & 7))) + mips_cpu.tcache.linesz = 2 << lsize; + else + mips_cpu.tcache.linesz = lsize; + + mips_cpu.tcache.sets = 64 << ((config2 >> 24) & 7); + mips_cpu.tcache.ways = 1 + ((config2 >> 16) & 7); + + tc_lsize = mips_cpu.tcache.linesz; + tcache_size = mips_cpu.tcache.sets * mips_cpu.tcache.ways * tc_lsize; + + printk("Tertiary cache %dK, linesize %d bytes, blocksize %d " + "bytes (%d ways)\n", + tcache_size >> 10, sc_lsize, tc_lsize, mips_cpu.tcache.ways); +} + +static void __init setup_scache_funcs(void) +{ + _flush_cache_all = sr7100_flush_cache_all_pc; + ___flush_cache_all = sr7100_nuke_caches; + _flush_cache_mm = sr7100_flush_cache_mm_pc; + _flush_cache_range = sr7100_flush_cache_range_pc; + _flush_cache_page = sr7100_flush_cache_page_pc; + _flush_page_to_ram = sr7100_flush_page_to_ram_pc; + _clear_page = (void *)mips32_clear_page_sc; + _copy_page = (void *)mips32_copy_page_sc; + + _flush_icache_page = sr7100_flush_icache_page; + + if (tcache_size == 0) + { + _dma_cache_wback_inv = sr7100_dma_cache_wback_inv_sc; + _dma_cache_inv = sr7100_dma_cache_inv_sc; + } + else + { + _dma_cache_wback_inv = sr7100_dma_cache_wback_inv_tc; + _dma_cache_inv = sr7100_dma_cache_inv_tc; + } + + _dma_cache_wback = sr7100_dma_cache_wback; +} + +/* This implements the cache intialization stuff from the SR7100 guide. After + this all the caches will be empty and ready to run. It must be run from + uncached space. */ +static void __init clear_enable_caches(unsigned long config) +{ + config = (config & (~CONF_CM_CMASK)) | CONF_CM_CACHABLE_NONCOHERENT; + + /* Primary cache init (7.1.1) + SR71000 Primary Cache initialization of 4-way, 32 Kbyte line I/D + caches. */ + __asm__ __volatile__ + ( + ".set push\n" + ".set noreorder\n" + ".set noat\n" + ".set mips64\n" + + // Enable KSEG0 caching + " mtc0 %0, $16\n" + + /* It is recommended that parity be disabled during cache + initialization. */ + " mfc0 $1, $12\n" // Read CP0 Status Register. + " li $2, 0x00010000\n" // DE Bit. + " or $2, $1, $2\n" + " mtc0 $2, $12\n" // Disable Parity. + + " ori $3, %1, 0x1FE0\n" // 256 sets. + " mtc0 $0, $28\n" // Set CP0 Tag_Lo Register + "1:\n" + " cache 8, 0x0000($3)\n" // Index_Store_Tag_I + " cache 8, 0x2000($3)\n" // Index_Store_Tag_I + " cache 8, 0x4000($3)\n" // Index_Store_Tag_I + " cache 8, 0x6000($3)\n" // Index_Store_Tag_I + " cache 9, 0x0000($3)\n" // Index_Store_Tag_D + " cache 9, 0x2000($3)\n" // Index_Store_Tag_D + " cache 9, 0x4000($3)\n" // Index_Store_Tag_D + " cache 9, 0x6000($3)\n" // Index_Store_Tag_D + " bne $3, %1, 1b\n" + " addiu $3, $3, -0x0020\n" // 32 byte cache line + " mtc0 $1, $12\n" // Put original back in Status Register. + ".set pop\n" + : + : "r"(config), "r"(KSEG0) + : "$1","$2","$3"); + // Fixme: use settings from config register not hardwired + + /* Secondary and tertiary flash invalidate (7.5.18) + This code fragment, invalidates (also disables), and + restores (re-enables) the secondary and tertiary caches. + Ensure system is operating in uncached space. */ + __asm__ __volatile__ + ( + ".set push\n" + ".set noreorder\n" + ".set noat\n" + ".set mips64\n" + " sync\n" // flush core pipeline + " lw $2, 0(%0)\n" // flush pending accesses + " bne $2, $2, 1f\n" // prevent I-fetches + " nop\n" + "1: mfc0 $1, $16, 2\n" // save current Config2 + " li $2, 0x20002000\n" // set flash invalidation bits + " or $2, $1, $2\n" + " mtc0 $2, $16, 2\n" // invalidate & disable caches + " mtc0 $1, $16, 2\n" // restore Config2 + ".set pop\n" + : + : "r"(KSEG1) + : "$1","$2"); +} + +void __init ld_mmu_sr7100(void) +{ + unsigned long config = read_32bit_cp0_registerx(CP0_CONFIG,0); + unsigned long config1 = read_32bit_cp0_registerx(CP0_CONFIG,1); + unsigned long config2 = read_32bit_cp0_registerx(CP0_CONFIG,2); + void (*kseg1_cec)(unsigned long config) = (void *)KSEG1ADDR(&clear_enable_caches); + + // Should never happen + if (!(config & (1 << 31)) || !(config1 & (1 << 31))) + panic("sr7100 does not have necessary config registers"); + + /* We should be uncached for this.. If the firmware has enabled + the cache it may have dirty data and we really need to flush + it before doing a mass invalidate, on the other hand if the + cache has not been inited flushing it could corrupt ram.. */ + if ((config & CONF_CM_CMASK) != CONF_CM_UNCACHED) + { + printk("Turning off cache.\n"); + change_cp0_config(CONF_CM_CMASK,CONF_CM_UNCACHED); + + // flush core pipeline + __asm__ __volatile__ (" sync\n"); + + sr7100_flush_cache_all_pc(); + + // Was the secondary cached turned on? + if ((config2 & (1<<12)) != 0) + blast_scache(); + + // Tertiary is write through so it is safe + } + + probe_icache(config,config1); + probe_dcache(config,config1); + probe_scache(config,config2); + probe_tcache(config,config2); + setup_scache_funcs(); + + // Make sure the the secondary cache is turned on (always present) + write_32bit_cp0_registerx(CP0_CONFIG,2,config2 | (1<<12)); + +#ifndef CONFIG_MIPS_UNCACHED + kseg1_cec(config); +#endif + + _flush_cache_sigtramp = sr7100_flush_cache_sigtramp; + _flush_icache_range = sr7100_flush_icache_range; +} diff --exclude CVS -bBrNu ./arch/mips/mm/loadmmu.c ../linux_2_4_branch/arch/mips/mm/loadmmu.c --- ./arch/mips/mm/loadmmu.c Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/mm/loadmmu.c Sat Jan 12 15:56:36 2002 @@ -61,6 +61,7 @@ extern void ld_mmu_andes(void); extern void ld_mmu_sb1(void); extern void ld_mmu_mips32(void); +extern void ld_mmu_sr7100(void); extern void r3k_tlb_init(void); extern void r4k_tlb_init(void); extern void sb1_tlb_init(void); @@ -89,6 +90,10 @@ #if defined(CONFIG_CPU_MIPS32) || defined(CONFIG_CPU_MIPS64) ld_mmu_mips32(); + r4k_tlb_init(); +#endif +#if defined(CONFIG_CPU_SR7100) + ld_mmu_sr7100(); r4k_tlb_init(); #endif } else switch(mips_cpu.cputype) { diff --exclude CVS -bBrNu ./arch/mips/mm/tlb-r4k.c ../linux_2_4_branch/arch/mips/mm/tlb-r4k.c --- ./arch/mips/mm/tlb-r4k.c Fri Jan 18 23:35:39 2002 +++ ../linux_2_4_branch/arch/mips/mm/tlb-r4k.c Sat Jan 12 16:09:30 2002 @@ -351,8 +351,6 @@ panic("No MMU present"); else mips_cpu.tlbsize = ((config1 >> 25) & 0x3f) + 1; - - printk("Number of TLB entries %d.\n", mips_cpu.tlbsize); } void __init r4k_tlb_init(void) diff --exclude CVS -bBrNu ./include/asm-mips/bootinfo.h ../linux_2_4_branch/include/asm-mips/bootinfo.h --- ./include/asm-mips/bootinfo.h Fri Jan 18 23:35:38 2002 +++ ../linux_2_4_branch/include/asm-mips/bootinfo.h Fri Jan 18 23:45:25 2002 @@ -37,7 +37,7 @@ #define GROUP_NAMES { "unknown", "Jazz", "Digital", "ARC", "SNI", "ACN", \ "SGI", "Cobalt", "NEC DDB", "Baget", "Cosine", "Galileo", "Momentum", \ "ITE", "Philips", "Globepspan", "SiByte", "Toshiba", "Alchemy", \ - "NEC Vr41xx", "HP LaserJet" } + "NEC Vr41xx", "HP LaserJet"} /* * Valid machtype values for group unknown (low order halfword of mips_machtype) @@ -253,7 +253,8 @@ #define CPU_R5500 41 #define CPU_TX49XX 42 #define CPU_TX39XX 43 -#define CPU_LAST 43 +#define CPU_SR7100 44 +#define CPU_LAST 44 #define CPU_NAMES { "unknown", "R2000", "R3000", "R3000A", "R3041", "R3051", \ "R3052", "R3081", "R3081E", "R4000PC", "R4000SC", "R4000MC", \ @@ -262,7 +263,7 @@ "R5000A", "R4640", "Nevada", "RM7000", "R5432", "MIPS 4Kc", \ "MIPS 5Kc", "R4310", "SiByte SB1", "TX3912", "TX3922", "TX3927", \ "Au1000", "MIPS 4KEc", "MIPS 4KSc", "NEC Vr41xx", "R5500", "TX49xx", \ - "TX39xx" } + "TX39xx", "SR7100" } #define COMMAND_LINE_SIZE 256 diff --exclude CVS -bBrNu ./include/asm-mips/cpu.h ../linux_2_4_branch/include/asm-mips/cpu.h --- ./include/asm-mips/cpu.h Fri Jan 18 23:35:38 2002 +++ ../linux_2_4_branch/include/asm-mips/cpu.h Thu Jan 10 20:21:53 2002 @@ -29,6 +29,7 @@ #define PRID_COMP_BROADCOM 0x020000 #define PRID_COMP_ALCHEMY 0x030000 #define PRID_COMP_SIBYTE 0x040000 +#define PRID_COMP_SANDCRAFT 0x050000 /* * Assigned values for the product ID register. In order to detect a @@ -73,6 +74,12 @@ */ #define PRID_IMP_SB1 0x0100 + +/* + * These are the PRID's for when 23:16 == PRID_COMP_SANDCRAFT + */ + +#define PRID_IMP_SR7100 0x0400 /* * Definitions for 7:0 on legacy processors From owner-linux-mips@oss.sgi.com Sat Jan 19 03:25:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JBPT429528 for linux-mips-outgoing; Sat, 19 Jan 2002 03:25:29 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JBPQP29524 for ; Sat, 19 Jan 2002 03:25:26 -0800 Received: from r19223c ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GQ6FUY00.1BA for ; Sat, 19 Jan 2002 16:35:22 +0800 Message-ID: <025901c1a0c4$30ec20e0$3d6e0b0a@huawei.com> From: "renc stone" To: Subject: use float in no-fpu mips kernel modules? Date: Sat, 19 Jan 2002 16:34:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 318 Lines: 17 hi, Any one know how to use float point in mips kernel? We use some 2.4.5 kernel, on idt mips 32334, which has no fpu, I think. we want to use the float numbers like this: float a = 87; a * = 1.04; Any kernel functions to do this? or how to compile it use soft fpu support? Thanks in advance. From owner-linux-mips@oss.sgi.com Sat Jan 19 11:00:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JJ0CT07944 for linux-mips-outgoing; Sat, 19 Jan 2002 11:00:12 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JJ07P07937 for ; Sat, 19 Jan 2002 11:00:08 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0JHxtt28113; Sat, 19 Jan 2002 17:59:55 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.2/8.11.2) id g0JCE1p01203; Sat, 19 Jan 2002 12:14:01 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15433.25352.345698.244662@gladsmuir.algor.co.uk> Date: Sat, 19 Jan 2002 12:14:00 +0000 To: drepper@redhat.com (Ulrich Drepper) Cc: "H . J . Lu" , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: References: <20020118101908.C23887@lucon.org> <20020118110844.A25165@lucon.org> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1224 Lines: 30 Well, just about k0/k1: So far as the hardware and instruction set is concerned, k0/k1 are just two of the 32 general purpose registers. There's nothing special about them and a program in user mode can read/write them. By a mere software convention, they're reserved. But this is an important software convention, because MIPS hardware does so little to help out on an exception or interrupt. Couple that to the lack of any absolute addressing mode, and any exception handler pretty much has to have a GP register it can write without saving, in order to be able to point to the register-save area. [You could, maybe, do something tricky with a negative offset from the (constant zero) $0 register and special mapping] OK, so that's one of them. The second is used to reduce the length and run-time of the tiny exception handler which is used to refill the TLB when a page translation is not loaded. The OS doesn't rely on user programs not corrupting these registers, of course: it typically uses them only in non-interruptible code sequences. But since the OS changes them under the feet of user programs, the convention that you don't use them is pretty strongly enforced. Dominic Sweetman Algorithmics Ltd From owner-linux-mips@oss.sgi.com Sat Jan 19 11:00:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JJ0Dq07949 for linux-mips-outgoing; Sat, 19 Jan 2002 11:00:13 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JJ08P07939 for ; Sat, 19 Jan 2002 11:00:08 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0JHxst28110; Sat, 19 Jan 2002 17:59:54 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.2/8.11.2) id g0JCRqv01223; Sat, 19 Jan 2002 12:27:52 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15433.26184.411289.161787@gladsmuir.algor.co.uk> Date: Sat, 19 Jan 2002 12:27:52 +0000 To: "H . J . Lu" Cc: "Kevin D. Kissell" , Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <20020118201139.A847@lucon.org> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020118201139.A847@lucon.org> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1253 Lines: 28 H . J . Lu (hjl@lucon.org) writes: > > It would, in principle, be possible to save/restore k0 > > or k1 (but not both) if no other clever solution can be found. > > There are other VM OSes that manage to do so for MIPS, > > for other outside-the-old-ABI reasons. It does, of course, > > add some instructions and some memory traffic to the > > low-level exception handling , and we would have to look > > at whether we would want to make such a feature standard > > or specific to a "thread-ready" kernel build. > > I like the read-only k0 idea. We just need to make a system call to > tell kernel what value to put in k0 before returning to the user space. > It shouldn't be too hard to implement. I will try it next week. You could, I guess, wire a TLB entry to map the thread register into the highest virtual memory region of the machine (the top of 'kseg2'), which is accessible in a single instruction as a negative offset from $0. The kernel can write it through kseg0 or 64-bit equivalent, if you're a bit careful about cache aliases. Reading something out of the cache is pretty cheap: would that be close enough to a 'register' to do the job? There's no change to critical routines, that way. Dominic Sweetman Algorithmics Ltd. From owner-linux-mips@oss.sgi.com Sat Jan 19 12:42:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JKgFm09284 for linux-mips-outgoing; Sat, 19 Jan 2002 12:42:15 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JKg7P09273 for ; Sat, 19 Jan 2002 12:42:08 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id B1608125C1; Sat, 19 Jan 2002 11:42:04 -0800 (PST) Date: Sat, 19 Jan 2002 11:42:04 -0800 From: "H . J . Lu" To: Dominic Sweetman Cc: "Kevin D. Kissell" , Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020119114204.A13939@lucon.org> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020118201139.A847@lucon.org> <15433.26184.411289.161787@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15433.26184.411289.161787@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Sat, Jan 19, 2002 at 12:27:52PM +0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2398 Lines: 62 On Sat, Jan 19, 2002 at 12:27:52PM +0000, Dominic Sweetman wrote: > > H . J . Lu (hjl@lucon.org) writes: > > > > It would, in principle, be possible to save/restore k0 > > > or k1 (but not both) if no other clever solution can be found. > > > There are other VM OSes that manage to do so for MIPS, > > > for other outside-the-old-ABI reasons. It does, of course, > > > add some instructions and some memory traffic to the > > > low-level exception handling , and we would have to look > > > at whether we would want to make such a feature standard > > > or specific to a "thread-ready" kernel build. > > > > I like the read-only k0 idea. We just need to make a system call to > > tell kernel what value to put in k0 before returning to the user space. > > It shouldn't be too hard to implement. I will try it next week. > > You could, I guess, wire a TLB entry to map the thread register into > the highest virtual memory region of the machine (the top of 'kseg2'), > which is accessible in a single instruction as a negative offset from > $0. The kernel can write it through kseg0 or 64-bit equivalent, if > you're a bit careful about cache aliases. But it has to be a per thread value. > > Reading something out of the cache is pretty cheap: would that be > close enough to a 'register' to do the job? There's no change to > critical routines, that way. > This is a patch against 2.4.16. Will this restore k1 to a known per thread value? H.J. --- include/asm-mips/stackframe.h.thread Wed Dec 12 12:34:53 2001 +++ include/asm-mips/stackframe.h Sat Jan 19 11:36:38 2002 @@ -191,6 +191,7 @@ __asm__ ( lw $2, PT_R2(sp) #define RESTORE_SP_AND_RET \ + lw $27, PT_R27(sp); \ .set push; \ .set noreorder; \ lw k0, PT_EPC(sp); \ @@ -229,6 +230,7 @@ __asm__ ( lw $2, PT_R2(sp) #define RESTORE_SP_AND_RET \ + lw $27, PT_R27(sp); \ lw sp, PT_R29(sp); \ .set mips3; \ eret; \ @@ -237,6 +239,7 @@ __asm__ ( #endif #define RESTORE_SP \ + lw $27, PT_R27(sp); \ lw sp, PT_R29(sp); \ #define RESTORE_ALL \ From owner-linux-mips@oss.sgi.com Sat Jan 19 15:20:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JNKl412173 for linux-mips-outgoing; Sat, 19 Jan 2002 15:20:47 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JNKiP12169 for ; Sat, 19 Jan 2002 15:20:44 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA00950; Sat, 19 Jan 2002 14:20:33 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA11521; Sat, 19 Jan 2002 14:20:28 -0800 (PST) Message-ID: <002a01c1a137$a35340a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Dominic Sweetman" , "H . J . Lu" Cc: "Ulrich Drepper" , "GNU libc hacker" , References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020118201139.A847@lucon.org> <15433.26184.411289.161787@gladsmuir.algor.co.uk> Subject: Re: thread-ready ABIs Date: Sat, 19 Jan 2002 23:21:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1281 Lines: 26 > > > It would, in principle, be possible to save/restore k0 > > > or k1 (but not both) if no other clever solution can be found. > > > There are other VM OSes that manage to do so for MIPS, > > > for other outside-the-old-ABI reasons. It does, of course, > > > add some instructions and some memory traffic to the > > > low-level exception handling , and we would have to look > > > at whether we would want to make such a feature standard > > > or specific to a "thread-ready" kernel build. > > > > I like the read-only k0 idea. We just need to make a system call to > > tell kernel what value to put in k0 before returning to the user space. > > It shouldn't be too hard to implement. I will try it next week. > > You could, I guess, wire a TLB entry to map the thread register into > the highest virtual memory region of the machine (the top of 'kseg2'), > which is accessible in a single instruction as a negative offset from > $0. Funny you should mention this. I was thinking about it yesterday in this context as something else that I've seen done in some non-Linux MIPS OSes, and something that I think would be a better solution for CPU-specific fast storage in SMP configurations than some of the hacks that I've seen proposed for SMP MIPS/Linux so far. From owner-linux-mips@oss.sgi.com Sat Jan 19 15:27:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JNR6b12291 for linux-mips-outgoing; Sat, 19 Jan 2002 15:27:06 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JNR4P12287 for ; Sat, 19 Jan 2002 15:27:04 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA00999; Sat, 19 Jan 2002 14:26:55 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA11693; Sat, 19 Jan 2002 14:26:53 -0800 (PST) Message-ID: <003601c1a138$868fdc20$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "renc stone" , References: <025901c1a0c4$30ec20e0$3d6e0b0a@huawei.com> Subject: Re: use float in no-fpu mips kernel modules? Date: Sat, 19 Jan 2002 23:27:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 17 > Any one know how to use float point in mips kernel? > We use some 2.4.5 kernel, on idt mips 32334, which has no fpu, I think. > we want to use the float numbers like this: > float a = 87; > a * = 1.04; > Any kernel functions to do this? or how to compile it use soft fpu > support? The way I integrated the Algorithmics FPU emulaton code into the kernel *used* to work for kernel FP. Maybe someone has broken it since, and there may well be situations where it was unsafe, but have you tried simply confuguring FPU emulation and running your code with it? Kevin K. From owner-linux-mips@oss.sgi.com Sat Jan 19 20:18:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0K4IUo15369 for linux-mips-outgoing; Sat, 19 Jan 2002 20:18:30 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0K4IKP15365 for ; Sat, 19 Jan 2002 20:18:20 -0800 Received: from r19223c ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GQ7VR500.E12; Sun, 20 Jan 2002 11:16:17 +0800 Message-ID: <001301c1a160$d2fe5460$3d6e0b0a@huawei.com> From: "renc stone" To: "Kevin D. Kissell" , References: <025901c1a0c4$30ec20e0$3d6e0b0a@huawei.com> <003601c1a138$868fdc20$0deca8c0@Ulysses> Subject: Re: use float in no-fpu mips kernel modules? Date: Sun, 20 Jan 2002 11:16:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1938 Lines: 85 > > Any one know how to use float point in mips kernel? > > We use some 2.4.5 kernel, on idt mips 32334, which has no fpu, I think. > > we want to use the float numbers like this: > > float a = 87; > > a * = 1.04; > > Any kernel functions to do this? or how to compile it use soft fpu > > support? > > The way I integrated the Algorithmics FPU emulaton > code into the kernel *used* to work for kernel FP. > Maybe someone has broken it since, and there may > well be situations where it was unsafe, but have you > tried simply confuguring FPU emulation and running > your code with it? > I have checked it, the FPU support is in the kernel. My kernel can't boot without the FPU emulation support. that's the module code: ################# float a = 1.03; double b = 1.05; int init_module (void) { a = 39 * a; b /= 34*(1.01 + a); printk("\nthe result is : %f", b); return 0; } void cleanup_module (void) { return; } ###################### insmod this module to the kernel, kernel will report [insmod:25] Illegal instruction 81700000 at 8170007c ra=80017fac ... I look into the module's code, and that's inst(objdump): 40: d4240008 0xd4240008 ... 1c: d4240128 0xd4240128 ... 74: f4240008 0xf4240008 ... these are in .text section. The other mfc1, swc1 inst in code are ok. Then I try to use soft float . compile like this: mipsel-linux-gdb ..... -msoft-float ... -o fp_tmp.o -c fp.c mipsel-linux-ld -r -EL -static -L/opt/Embdeix/tools/mipsel-linux/lib -lm -o fp.o fp_tmp.o (I use lineo's Embedix SDK2.0) and when insmod fp1.o , U comes: fp.o: unresolved symbol dpadd fp.o: unresolved symbol fpmul fp.o: unresolved symbol fptodp fp.o: unresolved symbol dpmul fp.o: unresolved symbol dpdiv the gcc's maual says in mips when use -msoftfloat , should get some special-compiled lib routines. Is that dpadd, fpmul ,etc? How to get that special-compiled lib? From owner-linux-mips@oss.sgi.com Sun Jan 20 03:38:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KBcwo18558 for linux-mips-outgoing; Sun, 20 Jan 2002 03:38:58 -0800 Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [146.215.0.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KBcqP18555 for ; Sun, 20 Jan 2002 03:38:52 -0800 Received: from mail2.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns4.sony.co.jp (R8/Sony) with ESMTP id g0KAckY75219; Sun, 20 Jan 2002 19:38:46 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g0KAcjH03835; Sun, 20 Jan 2002 19:38:45 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g0KAcjA03831; Sun, 20 Jan 2002 19:38:45 +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 TAA14007; Sun, 20 Jan 2002 19:43:32 +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 TAA19168; Sun, 20 Jan 2002 19:38:44 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0KAciJ00710; Sun, 20 Jan 2002 19:38:44 +0900 (JST) To: hjl@lucon.org Cc: kevink@mips.com, drepper@redhat.com, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <20020118201139.A847@lucon.org> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020118201139.A847@lucon.org> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020120193843M.machida@sm.sony.co.jp> Date: Sun, 20 Jan 2002 19:38:43 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1361 Lines: 36 From: "H . J . Lu" Subject: Re: thread-ready ABIs Date: Fri, 18 Jan 2002 20:11:39 -0800 > I like the read-only k0 idea. We just need to make a system call to > tell kernel what value to put in k0 before returning to the user space. > It shouldn't be too hard to implement. I will try it next week. > > > H.J. Please don't use k1, we already use k1 to implement fast test-and-set method for MIPS1 machine. We plan to mereg the method into main glibc and kernel tree. You can use test-and-set without systemcall on MIPS1 machines using this method. You can find the paper described about it in http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf (sorry in japanese only) The abstract of the paper attached below; The Implementation of user level test-and-set on PS2 Linux In the multi-thread environment like Linux, a fast user-level mutual exclusion mechanism is strongly required. But MIPS chips designed for embedded and single processor, like the Emotion Engine, have no atomic test-and-set instruction. We implemented the fast user-level mutual exclusion without invoking system-call and its costs, on the PS2 Linux. This method utilizes the memory protection facility of Operating System, to detect preemption and nullify the operation. In this paper, we present the method and its evaluation. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Sun Jan 20 04:57:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KCvRJ24534 for linux-mips-outgoing; Sun, 20 Jan 2002 04:57:27 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KCvMP24531 for ; Sun, 20 Jan 2002 04:57:22 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA05875; Sun, 20 Jan 2002 03:57:14 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA05906; Sun, 20 Jan 2002 03:57:10 -0800 (PST) Message-ID: <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Machida Hiroyuki" Cc: , , References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020118201139.A847@lucon.org> <20020120193843M.machida@sm.sony.co.jp> Subject: Re: thread-ready ABIs Date: Sun, 20 Jan 2002 12:58:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1780 Lines: 43 > > I like the read-only k0 idea. We just need to make a system call to > > tell kernel what value to put in k0 before returning to the user space. > > It shouldn't be too hard to implement. I will try it next week. > > > > H.J. > > Please don't use k1, we already use k1 to implement fast > test-and-set method for MIPS1 machine. We plan to mereg > the method into main glibc and kernel tree. I don't read Japanese, but I've worked on similar methods for semaphores using k1, so I can guess roughly what you've done. We'll have to be very careful if we want to have both a thread-register extended ABI *and* this approach to semaphores. The TLB miss handler must inevitably destroy one or the other of k0/k1, though it can avoid destroying both. Thus the merge of thread-register+semaphore must not require that both be preserved on an arbitrary memory reference. That may or may not be possible, so it would be good if you guys at Sony could post your code ASAP so we can see what can and cannot be merged. This situation also behooves us to verify that k0/k1 are really and truly the only candidates for a thread register in MIPS. I haven't been involved in any of the earlier discussions, and am not on the libc-hacker mailing list (and thus cannot post to it, by the way), but was it considered to simply use one of the static registers (say, s7/$23) in the existing ABI? Assuming it was set up correctly at process startup, it would be preserved by pre-thread library and .o modules, and could be exploited by newly generated code. Losing a static register would be a hit on code generation efficiency and performance, at least in principle. Was this the reason why the idea was rejected, or is there a more fundamental technical problem? Kevin K. From owner-linux-mips@oss.sgi.com Sun Jan 20 06:16:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KEGJp25267 for linux-mips-outgoing; Sun, 20 Jan 2002 06:16:19 -0800 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KEGDP25264 for ; Sun, 20 Jan 2002 06:16:14 -0800 Received: from mail2.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g0KDG8L00886; Sun, 20 Jan 2002 22:16:08 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g0KDG8H22182; Sun, 20 Jan 2002 22:16:08 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g0KDG7A22178; Sun, 20 Jan 2002 22:16:08 +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 WAA14993; Sun, 20 Jan 2002 22:20:55 +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 WAA20801; Sun, 20 Jan 2002 22:16:07 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0KDG7J00815; Sun, 20 Jan 2002 22:16:07 +0900 (JST) To: kevink@mips.com Cc: hjl@lucon.org, drepper@redhat.com, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> References: <20020118201139.A847@lucon.org> <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020120221607T.machida@sm.sony.co.jp> Date: Sun, 20 Jan 2002 22:16:07 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1622 Lines: 43 From: "Kevin D. Kissell" Subject: Re: thread-ready ABIs Date: Sun, 20 Jan 2002 12:58:00 +0100 > I don't read Japanese, but I've worked on similar > methods for semaphores using k1, so I can guess > roughly what you've done. We'll have to be very > careful if we want to have both a thread-register > extended ABI *and* this approach to semaphores. > The TLB miss handler must inevitably destroy one > or the other of k0/k1, though it can avoid destroying > both. Thus the merge of thread-register+semaphore > must not require that both be preserved on an > arbitrary memory reference. That may or may not > be possible, so it would be good if you guys at > Sony could post your code ASAP so we can see > what can and cannot be merged. We released source codes to the public with PS2 Linux (beta version) DISC. But I think you can't get the DISC in outside of japan. Patches included in those SRPMs are not separeted by function. That meanes single big patche includes r5900 porting codes, r5900 specific devices drivers and other enhancements. I can put kernel and glibc SRPMs in that DISC to you ftp site, if you really want to get SRPMs with such a dirty patch. Please send me your ftp site and how to put, if you want to SRPMs. I'll write short descriptions about what our test-and-set does, and try to make a separate patch for the method, anyway. > This situation also behooves us to verify that > k0/k1 are really and truly the only candidates > for a thread register in MIPS. I haven't been Sorry, I don't read libc-hackers's archives yet... --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Sun Jan 20 12:19:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KKJNu29157 for linux-mips-outgoing; Sun, 20 Jan 2002 12:19:23 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KKJFP29147 for ; Sun, 20 Jan 2002 12:19:16 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id D46F2125C0; Sun, 20 Jan 2002 11:19:12 -0800 (PST) Date: Sun, 20 Jan 2002 11:19:12 -0800 From: "H . J . Lu" To: "Kevin D. Kissell" Cc: Machida Hiroyuki , drepper@redhat.com, GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020120111912.A6918@lucon.org> References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020118201139.A847@lucon.org> <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses>; from kevink@mips.com on Sun, Jan 20, 2002 at 12:58:00PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2565 Lines: 60 On Sun, Jan 20, 2002 at 12:58:00PM +0100, Kevin D. Kissell wrote: > > > I like the read-only k0 idea. We just need to make a system call to > > > tell kernel what value to put in k0 before returning to the user space. > > > It shouldn't be too hard to implement. I will try it next week. > > > > > > H.J. > > > > Please don't use k1, we already use k1 to implement fast > > test-and-set method for MIPS1 machine. We plan to mereg > > the method into main glibc and kernel tree. > > I don't read Japanese, but I've worked on similar > methods for semaphores using k1, so I can guess > roughly what you've done. We'll have to be very > careful if we want to have both a thread-register > extended ABI *and* this approach to semaphores. > The TLB miss handler must inevitably destroy one > or the other of k0/k1, though it can avoid destroying > both. Thus the merge of thread-register+semaphore > must not require that both be preserved on an > arbitrary memory reference. That may or may not > be possible, so it would be good if you guys at > Sony could post your code ASAP so we can see > what can and cannot be merged. As I understand, we don't need k1 based semaphore for MIPS II or above. So many processors can still benefit from the thread register. We can use a system call to implement loading a thread register. So it is a trade off between system-call/k1 for thread-register/semaphore. We can make it a configure time option. Since PS2 is already using k1 for semaphore, I'd like to see it get merged in ASAP so that anything we do won't break PS2. > > This situation also behooves us to verify that > k0/k1 are really and truly the only candidates > for a thread register in MIPS. I haven't been > involved in any of the earlier discussions, > and am not on the libc-hacker mailing list > (and thus cannot post to it, by the way), but You haven't missed anything. I changed it to the glibc alpha list. > was it considered to simply use one of the > static registers (say, s7/$23) in the existing > ABI? Assuming it was set up correctly at > process startup, it would be preserved by > pre-thread library and .o modules, and could > be exploited by newly generated code. Losing > a static register would be a hit on code generation > efficiency and performance, at least in principle. > Was this the reason why the idea was rejected, > or is there a more fundamental technical problem? We never considered it since it is an invasive ABI change. Besides the performance issue, it may break exist codes. I prefer k1 if all possible. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 02:39:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LAd0p18785 for linux-mips-outgoing; Mon, 21 Jan 2002 02:39:00 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LAcqP18774 for ; Mon, 21 Jan 2002 02:38:52 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA14260; Mon, 21 Jan 2002 01:38:42 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA19610; Mon, 21 Jan 2002 01:38:31 -0800 (PST) Message-ID: <003701c1a25f$8abfc120$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "H . J . Lu" Cc: "Machida Hiroyuki" , , "GNU C Library" , References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020118201139.A847@lucon.org> <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> <20020120111912.A6918@lucon.org> Subject: Re: thread-ready ABIs Date: Mon, 21 Jan 2002 10:39:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2501 Lines: 62 > > > > I like the read-only k0 idea. We just need to make a system call to > > > > tell kernel what value to put in k0 before returning to the user space. > > > > It shouldn't be too hard to implement. I will try it next week. > > > > > > > > H.J. > > > > > > Please don't use k1, we already use k1 to implement fast > > > test-and-set method for MIPS1 machine. We plan to merge > > > the method into main glibc and kernel tree. [snip] > > > > This situation... behooves us to verify that > > k0/k1 are really and truly the only candidates > > for a thread register in MIPS. I haven't been > > involved in any of the earlier discussions, > > and am not on the libc-hacker mailing list > > (and thus cannot post to it, by the way), but > > was it considered to simply use one of the > > static registers (say, s7/$23) in the existing > > ABI? Assuming it was set up correctly at > > process startup, it would be preserved by > > pre-thread library and .o modules, and could > > be exploited by newly generated code. Losing > > a static register would be a hit on code generation > > efficiency and performance, at least in principle. > > Was this the reason why the idea was rejected, > > or is there a more fundamental technical problem? > > We never considered it since it is an invasive ABI change. Besides > the performance issue, it may break exist codes. I prefer k1 if all > possible. If anything, assuming that k0 or k1 are sane in compiler-generated code is more of a violation of the ABI than imposing an optional use of s7. Sony's use in libraries is somewhat less intrusive. Please explain how the use of a static register as described above would break existing codes. It's a common technique to bind a static register to a global variable. Linking to libraries with no knowledge of this variable breaks nothing, since by the ABI, all use of "s" registers requires that they be preserved and returned intact to the caller. It seems to me to be quite straightforward to apply this technique to the thread register. The *only* issue I see is that of performance, and it is by no means clear how severe this would be. In the compiled code that I have examined for compiler efficiency in the past, it's pretty rare that *all* static registers are actually used. I consider this to be a fairly serious issue, and will take it up with the people who own the ABI within MIPS. I hope to be able to make an "official" recommendation shortly. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 21 06:29:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LETMN27407 for linux-mips-outgoing; Mon, 21 Jan 2002 06:29:22 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LETFP27404 for ; Mon, 21 Jan 2002 06:29:15 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA23804; Mon, 21 Jan 2002 14:27:22 +0100 (MET) Date: Mon, 21 Jan 2002 14:27:21 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Dominic Sweetman , "Kevin D. Kissell" , Ulrich Drepper , GNU libc alpha , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <20020119114204.A13939@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 605 Lines: 18 On Sat, 19 Jan 2002, H . J . Lu wrote: > But it has to be a per thread value. But threads run under different contexts in Linux, AFAIK. > This is a patch against 2.4.16. Will this restore k1 to a known per > thread value? It wouldn't -- k1 isn't saved. And there are TLB exception handlers (the most important performance issue here) that don't use framing at all -- see arch/mips/mm/tlbex-r?k.S. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 21 06:44:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LEisu27988 for linux-mips-outgoing; Mon, 21 Jan 2002 06:44:54 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LEioP27984 for ; Mon, 21 Jan 2002 06:44:51 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA24201; Mon, 21 Jan 2002 14:43:51 +0100 (MET) Date: Mon, 21 Jan 2002 14:43:51 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "H . J . Lu" cc: "Kevin D. Kissell" , Machida Hiroyuki , drepper@redhat.com, GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <20020120111912.A6918@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 929 Lines: 21 On Sun, 20 Jan 2002, H . J . Lu wrote: > As I understand, we don't need k1 based semaphore for MIPS II or above. > So many processors can still benefit from the thread register. We can > use a system call to implement loading a thread register. So it is > a trade off between system-call/k1 for thread-register/semaphore. We > can make it a configure time option. Since PS2 is already using k1 for > semaphore, I'd like to see it get merged in ASAP so that anything we > do won't break PS2. I believe we need not trade anything off if we split k1 into two parts. We could use e.g. the 31 MSBs for the thread register and the LSB for the ll/sc equivalent. Other splits are possible if the ll/sc emulation needs more bits. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 21 06:57:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LEvUM28239 for linux-mips-outgoing; Mon, 21 Jan 2002 06:57:30 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LEvMP28235 for ; Mon, 21 Jan 2002 06:57:22 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA24506; Mon, 21 Jan 2002 14:56:22 +0100 (MET) Date: Mon, 21 Jan 2002 14:56:21 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: "H . J . Lu" , Machida Hiroyuki , drepper@redhat.com, GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs In-Reply-To: <003701c1a25f$8abfc120$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1555 Lines: 37 On Mon, 21 Jan 2002, Kevin D. Kissell wrote: > If anything, assuming that k0 or k1 are sane in > compiler-generated code is more of a violation > of the ABI than imposing an optional use of s7. > Sony's use in libraries is somewhat less intrusive. Hmm, it's a glibc/kernel internal implementation detail. I don't think this is an ABI violation, as from a program's point of view k0/k1 are still "undefined -- do not use". > It's a common technique to bind a static register > to a global variable. Linking to libraries with no > knowledge of this variable breaks nothing, since > by the ABI, all use of "s" registers requires that > they be preserved and returned intact to the caller. > It seems to me to be quite straightforward to apply > this technique to the thread register. The *only* > issue I see is that of performance, and it is by > no means clear how severe this would be. The k0/k1 approach is a performance hit as well. Possibly a worse one, as you lose a few cycles unconditionally every exception, while having one static register less in the code can be dealt with by a compiler in a more flexible way. > In the compiled code that I have examined > for compiler efficiency in the past, it's pretty > rare that *all* static registers are actually used. Even with one register less there are still eight remaining, indeed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jan 21 07:42:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LFgW731700 for linux-mips-outgoing; Mon, 21 Jan 2002 07:42:32 -0800 Received: from sadclown.net (IDENT:postfix@syr-66-67-109-186.twcny.rr.com [66.67.109.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LFgUP31697 for ; Mon, 21 Jan 2002 07:42:30 -0800 Received: from funk.sadclown.net (unknown [192.168.0.2]) by sadclown.net (Postfix) with ESMTP id 7B33A1F6EB for ; Mon, 21 Jan 2002 09:42:29 -0500 (EST) Subject: linux on o2 From: Jeff Utter To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 21 Jan 2002 09:43:33 -0500 Message-Id: <1011624213.2259.0.camel@funk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 97 Lines: 3 Hey, i was just wondering the status of linux being ported to the 02? is there any success yet? From owner-linux-mips@oss.sgi.com Mon Jan 21 11:25:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJP3104133 for linux-mips-outgoing; Mon, 21 Jan 2002 11:25:03 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJOwP04129 for ; Mon, 21 Jan 2002 11:24:58 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id ED129125C0; Mon, 21 Jan 2002 10:24:55 -0800 (PST) Date: Mon, 21 Jan 2002 10:24:55 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , Machida Hiroyuki , drepper@redhat.com, GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121102455.A27606@lucon.org> References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jan 21, 2002 at 02:56:21PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1364 Lines: 32 On Mon, Jan 21, 2002 at 02:56:21PM +0100, Maciej W. Rozycki wrote: > > > It's a common technique to bind a static register > > to a global variable. Linking to libraries with no > > knowledge of this variable breaks nothing, since > > by the ABI, all use of "s" registers requires that > > they be preserved and returned intact to the caller. > > It seems to me to be quite straightforward to apply > > this technique to the thread register. The *only* > > issue I see is that of performance, and it is by > > no means clear how severe this would be. > > The k0/k1 approach is a performance hit as well. Possibly a worse one, > as you lose a few cycles unconditionally every exception, while having one > static register less in the code can be dealt with by a compiler in a more > flexible way. > > > In the compiled code that I have examined > > for compiler efficiency in the past, it's pretty > > rare that *all* static registers are actually used. > > Even with one register less there are still eight remaining, indeed. If people believe it won't be a big problem, we can tell gcc not to use $23, at least when compiling glibc. The question is, should $23 be fixed outside of glibc? Ulrich, should applciations have access to thread register directly? If not, we may add a switch to tell gcc that $23 is fixed and compile glibc with it. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 11:37:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJbmS04649 for linux-mips-outgoing; Mon, 21 Jan 2002 11:37:48 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJbjP04619 for ; Mon, 21 Jan 2002 11:37:45 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA18162; Mon, 21 Jan 2002 10:36:27 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0LIaQP24084; Mon, 21 Jan 2002 10:36:26 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 10:36:26 -0800 In-Reply-To: <20020121102455.A27606@lucon.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 573 Lines: 13 "H . J . Lu" writes: > Ulrich, should applciations have access to thread register directly? It doesn't matter. The value isn't changed in the lifetime of a thread. So the overhead of a syscall wouldn't be too much. And protection against programs overwriting the register isn't necessary. It's the program's fault if that happens. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jan 21 11:52:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJqxc09909 for linux-mips-outgoing; Mon, 21 Jan 2002 11:52:59 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJquP09903 for ; Mon, 21 Jan 2002 11:52:56 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6A812125C0; Mon, 21 Jan 2002 10:52:53 -0800 (PST) Date: Mon, 21 Jan 2002 10:52:53 -0800 From: "H . J . Lu" To: Ulrich Drepper Cc: "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121105253.B28087@lucon.org> References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drepper@redhat.com on Mon, Jan 21, 2002 at 10:36:26AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 847 Lines: 19 On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Ulrich, should applciations have access to thread register directly? > > It doesn't matter. The value isn't changed in the lifetime of a > thread. So the overhead of a syscall wouldn't be too much. And > protection against programs overwriting the register isn't necessary. > It's the program's fault if that happens. Thq question is if we should reserve $23 outside of glibc. $23 is a saved register in the MIPS ABI. It doesn't change across function calls. If applications outside of glibc don't need to access the thread register directly, that means $23 can be used as a saved register. We don't have to change anything when compiling applications. We only need to compile glibc with $23 reserved as the thread register. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 11:58:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJwvs10055 for linux-mips-outgoing; Mon, 21 Jan 2002 11:58:57 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJwsP10048 for ; Mon, 21 Jan 2002 11:58:54 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 06BDE125C0; Mon, 21 Jan 2002 10:58:50 -0800 (PST) Date: Mon, 21 Jan 2002 10:58:50 -0800 From: "H . J . Lu" To: Ulrich Drepper Cc: "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121105850.A28350@lucon.org> References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121105253.B28087@lucon.org>; from hjl@lucon.org on Mon, Jan 21, 2002 at 10:52:53AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1062 Lines: 24 On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote: > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > Ulrich, should applciations have access to thread register directly? > > > > It doesn't matter. The value isn't changed in the lifetime of a > > thread. So the overhead of a syscall wouldn't be too much. And > > protection against programs overwriting the register isn't necessary. > > It's the program's fault if that happens. > > Thq question is if we should reserve $23 outside of glibc. $23 is > a saved register in the MIPS ABI. It doesn't change across function > calls. If applications outside of glibc don't need to access the > thread register directly, that means $23 can be used as a saved > register. We don't have to change anything when compiling applications. > We only need to compile glibc with $23 reserved as the thread register. In another word, is a thread register purely a convention within glibc as long as it doesn't change when entering glibc? H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 12:01:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LK12Y10216 for linux-mips-outgoing; Mon, 21 Jan 2002 12:01:02 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LK0wP10202 for ; Mon, 21 Jan 2002 12:00:59 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16Sjew-0006z3-00; Mon, 21 Jan 2002 13:59:10 -0500 Date: Mon, 21 Jan 2002 13:59:10 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121135910.A26790@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020121105253.B28087@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1365 Lines: 28 On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote: > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > Ulrich, should applciations have access to thread register directly? > > > > It doesn't matter. The value isn't changed in the lifetime of a > > thread. So the overhead of a syscall wouldn't be too much. And > > protection against programs overwriting the register isn't necessary. > > It's the program's fault if that happens. > > Thq question is if we should reserve $23 outside of glibc. $23 is > a saved register in the MIPS ABI. It doesn't change across function > calls. If applications outside of glibc don't need to access the > thread register directly, that means $23 can be used as a saved > register. We don't have to change anything when compiling applications. > We only need to compile glibc with $23 reserved as the thread register. That's not right. If it is call-saved in the application, that means the application can use it. Main may have to restore it before it returns to __libc_start_main, but that doesn't do you any good. It doesn't change across function calls, but it does change inside function calls. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Jan 21 12:05:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LK5fU10354 for linux-mips-outgoing; Mon, 21 Jan 2002 12:05:41 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LK5bP10350 for ; Mon, 21 Jan 2002 12:05:37 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1858C125C0; Mon, 21 Jan 2002 11:05:34 -0800 (PST) Date: Mon, 21 Jan 2002 11:05:33 -0800 From: "H . J . Lu" To: Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121110533.B28350@lucon.org> References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> <20020121135910.A26790@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121135910.A26790@nevyn.them.org>; from dan@debian.org on Mon, Jan 21, 2002 at 01:59:10PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1573 Lines: 33 On Mon, Jan 21, 2002 at 01:59:10PM -0500, Daniel Jacobowitz wrote: > On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote: > > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > > "H . J . Lu" writes: > > > > > > > Ulrich, should applciations have access to thread register directly? > > > > > > It doesn't matter. The value isn't changed in the lifetime of a > > > thread. So the overhead of a syscall wouldn't be too much. And > > > protection against programs overwriting the register isn't necessary. > > > It's the program's fault if that happens. > > > > Thq question is if we should reserve $23 outside of glibc. $23 is > > a saved register in the MIPS ABI. It doesn't change across function > > calls. If applications outside of glibc don't need to access the > > thread register directly, that means $23 can be used as a saved > > register. We don't have to change anything when compiling applications. > > We only need to compile glibc with $23 reserved as the thread register. > > That's not right. If it is call-saved in the application, that means > the application can use it. Main may have to restore it before it > returns to __libc_start_main, but that doesn't do you any good. > > It doesn't change across function calls, but it does change inside > function calls. What is wrong about using a thread register as long as it contains the right value when it is accessed as a thread pointer? If applications don't have access to the thread pointer, I don't see the problem using the thread register. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 12:11:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LKB6110546 for linux-mips-outgoing; Mon, 21 Jan 2002 12:11:06 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LKB1P10543 for ; Mon, 21 Jan 2002 12:11:01 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16Sjoy-000772-00; Mon, 21 Jan 2002 14:09:32 -0500 Date: Mon, 21 Jan 2002 14:09:32 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121140932.A27328@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> <20020121135910.A26790@nevyn.them.org> <20020121110533.B28350@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020121110533.B28350@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2040 Lines: 40 On Mon, Jan 21, 2002 at 11:05:33AM -0800, H . J . Lu wrote: > On Mon, Jan 21, 2002 at 01:59:10PM -0500, Daniel Jacobowitz wrote: > > On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote: > > > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > > > "H . J . Lu" writes: > > > > > > > > > Ulrich, should applciations have access to thread register directly? > > > > > > > > It doesn't matter. The value isn't changed in the lifetime of a > > > > thread. So the overhead of a syscall wouldn't be too much. And > > > > protection against programs overwriting the register isn't necessary. > > > > It's the program's fault if that happens. > > > > > > Thq question is if we should reserve $23 outside of glibc. $23 is > > > a saved register in the MIPS ABI. It doesn't change across function > > > calls. If applications outside of glibc don't need to access the > > > thread register directly, that means $23 can be used as a saved > > > register. We don't have to change anything when compiling applications. > > > We only need to compile glibc with $23 reserved as the thread register. > > > > That's not right. If it is call-saved in the application, that means > > the application can use it. Main may have to restore it before it > > returns to __libc_start_main, but that doesn't do you any good. > > > > It doesn't change across function calls, but it does change inside > > function calls. > > What is wrong about using a thread register as long as it contains > the right value when it is accessed as a thread pointer? If > applications don't have access to the thread pointer, I don't see the > problem using the thread register. When is the thread pointer accessed? My understanding was that it would be needed for the lifetime of the application, in functions called from the application. In that case its value can not be trusted. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Jan 21 12:18:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LKIDK11002 for linux-mips-outgoing; Mon, 21 Jan 2002 12:18:13 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LKIBP10999 for ; Mon, 21 Jan 2002 12:18:11 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6F7A8125C0; Mon, 21 Jan 2002 11:18:08 -0800 (PST) Date: Mon, 21 Jan 2002 11:18:08 -0800 From: "H . J . Lu" To: Daniel Jacobowitz Cc: Ulrich Drepper , "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121111808.A28676@lucon.org> References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> <20020121135910.A26790@nevyn.them.org> <20020121110533.B28350@lucon.org> <20020121140932.A27328@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121140932.A27328@nevyn.them.org>; from dan@debian.org on Mon, Jan 21, 2002 at 02:09:32PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 411 Lines: 12 On Mon, Jan 21, 2002 at 02:09:32PM -0500, Daniel Jacobowitz wrote: > > When is the thread pointer accessed? My understanding was that it > would be needed for the lifetime of the application, in functions > called from the application. In that case its value can not be > trusted. You are right. If we use $23 as the thread pointer, we have to change the ABI. Any assembler codes have to be checked. H.J. From owner-linux-mips@oss.sgi.com Mon Jan 21 12:30:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LKUgg11142 for linux-mips-outgoing; Mon, 21 Jan 2002 12:30:42 -0800 Received: from desire.geoffk.org (12-234-190-114.client.attbi.com [12.234.190.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LKUcP11139 for ; Mon, 21 Jan 2002 12:30:38 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g0LJUUe00748; Mon, 21 Jan 2002 11:30:30 -0800 Date: Mon, 21 Jan 2002 11:30:30 -0800 From: Geoff Keating Message-Id: <200201211930.g0LJUUe00748@desire.geoffk.org> To: hjl@lucon.org CC: drepper@redhat.com, macro@ds2.pg.gda.pl, kevink@mips.com, machida@sm.sony.co.jp, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com In-reply-to: <20020121105253.B28087@lucon.org> (hjl@lucon.org) Subject: Re: thread-ready ABIs Reply-to: Geoff Keating References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1479 Lines: 31 > Date: Mon, 21 Jan 2002 10:52:53 -0800 > From: "H . J . Lu" > Cc: "Maciej W. Rozycki" , > "Kevin D. Kissell" , > Machida Hiroyuki , > GNU C Library , linux-mips@oss.sgi.com > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > Ulrich, should applciations have access to thread register directly? > > > > It doesn't matter. The value isn't changed in the lifetime of a > > thread. So the overhead of a syscall wouldn't be too much. And > > protection against programs overwriting the register isn't necessary. > > It's the program's fault if that happens. > > Thq question is if we should reserve $23 outside of glibc. $23 is > a saved register in the MIPS ABI. It doesn't change across function > calls. If applications outside of glibc don't need to access the > thread register directly, that means $23 can be used as a saved > register. We don't have to change anything when compiling applications. > We only need to compile glibc with $23 reserved as the thread register. This won't work, will it? We need a register that application code is not allowed to change ever, not one that is saved and restored. Even if the user knows that no glibc routines are called between the save and the restore, a signal could happen. -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Mon Jan 21 14:04:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LM4RC15657 for linux-mips-outgoing; Mon, 21 Jan 2002 14:04:27 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LM4KP15653 for ; Mon, 21 Jan 2002 14:04:20 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA21249; Mon, 21 Jan 2002 13:04:09 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA12621; Mon, 21 Jan 2002 13:04:06 -0800 (PST) Message-ID: <012501c1a2bf$4c832180$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "H . J . Lu" Cc: "Ulrich Drepper" , "Maciej W. Rozycki" , "Machida Hiroyuki" , "GNU C Library" , References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> <20020121135910.A26790@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Mon, 21 Jan 2002 22:04:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2578 Lines: 56 From: "Daniel Jacobowitz" > On Mon, Jan 21, 2002 at 10:52:53AM -0800, H . J . Lu wrote: > > On Mon, Jan 21, 2002 at 10:36:26AM -0800, Ulrich Drepper wrote: > > > "H . J . Lu" writes: > > > > > > > Ulrich, should applciations have access to thread register directly? > > > > > > It doesn't matter. The value isn't changed in the lifetime of a > > > thread. So the overhead of a syscall wouldn't be too much. And > > > protection against programs overwriting the register isn't necessary. > > > It's the program's fault if that happens. > > > > Thq question is if we should reserve $23 outside of glibc. $23 is > > a saved register in the MIPS ABI. It doesn't change across function > > calls. If applications outside of glibc don't need to access the > > thread register directly, that means $23 can be used as a saved > > register. We don't have to change anything when compiling applications. > > We only need to compile glibc with $23 reserved as the thread register. > > That's not right. If it is call-saved in the application, that means > the application can use it. Main may have to restore it before it > returns to __libc_start_main, but that doesn't do you any good. > > It doesn't change across function calls, but it does change inside > function calls. You are quite correct, and you have stated the problem very succinctly. We cannot, as I had hoped, simply superimpose a thread pointer on a static register and keep it otherwise invisible to the code generator. So it's not the "easy way out". That does not necessarily mean that it's the wrong solution. As Maciej has pointed out, from the standpoint of performance, making the kernel do gymnastics to preserve or set up a "k" register on each trap may well be worse for overall performance than having one fewer "s" register. Stealing the "s" register would involve a change to the ABI and the compiler, but would make it invisible to the kernel. Using (or abusing) a "k" register would techncially also require a change to the ABI (though one that would be more perfectly backward compatible), a smaller perturbation of the compiler (thread pointer stuff gets added, but the s-register compliment is unchanged), and a kernel hack that may or may not conflict with other people's work (e.g. Sony). I've been kicking this around with my colleagues at MIPS, and as I say, I hope to be back with a semi-official recommendation shortly. Meanwhile, I'm very interested in other's views of the pros, cons, and alternatives. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 21 14:08:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LM8BX15734 for linux-mips-outgoing; Mon, 21 Jan 2002 14:08:11 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LM87P15728 for ; Mon, 21 Jan 2002 14:08:07 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA03560; Mon, 21 Jan 2002 13:07:14 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0LL7DI24457; Mon, 21 Jan 2002 13:07:13 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: "Maciej W. Rozycki" , "Kevin D. Kissell" , Machida Hiroyuki , GNU C Library , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <20020121102455.A27606@lucon.org> <20020121105253.B28087@lucon.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 13:07:13 -0800 In-Reply-To: <20020121105253.B28087@lucon.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 674 Lines: 15 "H . J . Lu" writes: > Thq question is if we should reserve $23 outside of glibc. $23 is > a saved register in the MIPS ABI. It doesn't change across function > calls. If applications outside of glibc don't need to access the > thread register directly, that means $23 can be used as a saved > register. It depends on the final decisions os the thrad ABI but it is best to assume that compiler-generated code will access the register. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jan 21 14:17:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LMHI615977 for linux-mips-outgoing; Mon, 21 Jan 2002 14:17:18 -0800 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LMHFP15965 for ; Mon, 21 Jan 2002 14:17:15 -0800 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA12734; Mon, 21 Jan 2002 16:17:06 -0500 Date: Mon, 21 Jan 2002 16:17:06 -0500 (EST) From: X-Sender: nick@ns To: Jeff Utter cc: linux-mips@oss.sgi.com Subject: Re: linux on o2 In-Reply-To: <1011624213.2259.0.camel@funk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 283 Lines: 10 It's starting to shape up. I'm hopeing to put out an install CD image by the 29th of this month, but that may be hopelessly optimistic. Nick On 21 Jan 2002, Jeff Utter wrote: > Hey, i was just wondering the status of linux being ported to the 02? is > there any success yet? > From owner-linux-mips@oss.sgi.com Mon Jan 21 14:53:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LMrJd16656 for linux-mips-outgoing; Mon, 21 Jan 2002 14:53:19 -0800 Received: from sadclown.net (IDENT:postfix@syr-66-67-109-186.twcny.rr.com [66.67.109.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LMrGP16653 for ; Mon, 21 Jan 2002 14:53:16 -0800 Received: from funk.sadclown.net (unknown [192.168.0.2]) by sadclown.net (Postfix) with ESMTP id EE0E71F6EB; Mon, 21 Jan 2002 16:53:15 -0500 (EST) Subject: Re: linux on o2 From: Jeff Utter To: nick@snowman.net Cc: linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 21 Jan 2002 16:54:17 -0500 Message-Id: <1011650057.2261.7.camel@funk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 438 Lines: 15 Wow, nifty. i hope your able to get that working... Also, i know that it's not completed yet but what's the status on X for the o2? > It's starting to shape up. I'm hopeing to put out an install CD image by > the 29th of this month, but that may be hopelessly optimistic. > Nick > > On 21 Jan 2002, Jeff Utter wrote: > > > Hey, i was just wondering the status of linux being ported to the 02? is > > there any success yet? > > > From owner-linux-mips@oss.sgi.com Mon Jan 21 15:00:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LN09D16859 for linux-mips-outgoing; Mon, 21 Jan 2002 15:00:09 -0800 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LN05P16856 for ; Mon, 21 Jan 2002 15:00:05 -0800 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA13962; Mon, 21 Jan 2002 16:59:56 -0500 Date: Mon, 21 Jan 2002 16:59:56 -0500 (EST) From: X-Sender: nick@ns To: Jeff Utter cc: linux-mips@oss.sgi.com Subject: Re: linux on o2 In-Reply-To: <1011650057.2261.7.camel@funk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 759 Lines: 24 I need a DRI guy. Badly. FB should be compleate or at least sorta working by the 29th, MACE ethernet is working, sound and AV support has yet to be started. The pci slot is questionable, and right now the scsi support seems to have some issues. Nick On 21 Jan 2002, Jeff Utter wrote: > Wow, nifty. i hope your able to get that working... Also, i know that > it's not completed yet but what's the status on X for the o2? > > > It's starting to shape up. I'm hopeing to put out an install CD image by > > the 29th of this month, but that may be hopelessly optimistic. > > Nick > > > > On 21 Jan 2002, Jeff Utter wrote: > > > > > Hey, i was just wondering the status of linux being ported to the 02? is > > > there any success yet? > > > > > > > From owner-linux-mips@oss.sgi.com Mon Jan 21 15:02:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LN2MU17001 for linux-mips-outgoing; Mon, 21 Jan 2002 15:02:22 -0800 Received: from banff.ayrnetworks.com (64-166-72-137.ayrnetworks.com [64.166.72.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LN2IP16998 for ; Mon, 21 Jan 2002 15:02:18 -0800 Received: from ayrnetworks.com (IDENT:chua@localhost.localdomain [127.0.0.1]) by banff.ayrnetworks.com (8.11.2/8.11.2) with ESMTP id g0LM2B221276 for ; Mon, 21 Jan 2002 14:02:11 -0800 Message-ID: <3C4C8FE2.9090800@ayrnetworks.com> Date: Mon, 21 Jan 2002 14:02:10 -0800 From: Bryan Chua User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: arch/mips/setup.c Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1143 Lines: 41 I recall a bunch of disussion about changing arch/mips/setup.c to simplify adding vendor-specific platform code in setup_arch, but to date nothing has come of it. So while this is a dramatic oversimplification of the various proposals, how about this for now -- just a vendor-defined function "platform_setup (void)" and it is up to the vendor to figure out what to do from there. -- bryan Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96.2.3 diff -u -r1.96.2.3 setup.c --- arch/mips/kernel/setup.c 2001/12/26 23:27:02 1.96.2.3 +++ arch/mips/kernel/setup.c 2002/01/21 22:55:35 @@ -666,6 +666,7 @@ void it8172_setup(void); void swarm_setup(void); void hp_setup(void); + void platform_setup (void); unsigned long bootmap_size; unsigned long start_pfn, max_pfn, first_usable_pfn; @@ -793,7 +794,8 @@ break; #endif default: - panic("Unsupported architecture"); + platform_setup (); + break; } strncpy(command_line, arcs_cmdline, sizeof command_line); From owner-linux-mips@oss.sgi.com Mon Jan 21 15:21:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LNL5a17707 for linux-mips-outgoing; Mon, 21 Jan 2002 15:21:05 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0LNL2P17683 for ; Mon, 21 Jan 2002 15:21:02 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0K0OF317384; Sat, 19 Jan 2002 16:24:15 -0800 Date: Sat, 19 Jan 2002 16:24:15 -0800 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "H . J . Lu" , Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020119162415.B31028@dea.linux-mips.net> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01b801c1a081$3f6518e0$0deca8c0@Ulysses>; from kevink@mips.com on Sat, Jan 19, 2002 at 01:35:38AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 875 Lines: 19 On Sat, Jan 19, 2002 at 01:35:38AM +0100, Kevin D. Kissell wrote: > Thank you for posting this to linux-mips, since I'm not sure > that anyone at MIPS is on the GNU_libc_hacker list. > > It would, in principle, be possible to save/restore k0 > or k1 (but not both) if no other clever solution can be found. > There are other VM OSes that manage to do so for MIPS, > for other outside-the-old-ABI reasons. It does, of course, > add some instructions and some memory traffic to the > low-level exception handling , and we would have to look > at whether we would want to make such a feature standard > or specific to a "thread-ready" kernel build. Changing the kernel for the small number of threaded applications that exists and taking a performance impact for the kernel itself and anything that's using threads is an exquisite example for a bad tradeoff. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 21 15:21:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LNL6E17719 for linux-mips-outgoing; Mon, 21 Jan 2002 15:21:06 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0LNL3P17700 for ; Mon, 21 Jan 2002 15:21:03 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0K0E5r15490; Sat, 19 Jan 2002 16:14:05 -0800 Date: Sat, 19 Jan 2002 16:14:05 -0800 From: Ralf Baechle To: Ulrich Drepper Cc: "H . J . Lu" , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020119161405.A31028@dea.linux-mips.net> References: <20020118101908.C23887@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drepper@redhat.com on Fri, Jan 18, 2002 at 10:31:17AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 667 Lines: 18 On Fri, Jan 18, 2002 at 10:31:17AM -0800, Ulrich Drepper wrote: > > I don't see there are any registers we can use without breaking ABI. > > On the other hand, can we change the mips kernel to save k0 or k1 for > > user space? These are reserved for kernel use. Saving them is not a good idea as it would impact performance of TLB exception handlers which are extremly performance sensitive. > Are these registers which are readable by normal users but writable > only in ring 0? If yes, this is definitely worthwhile (similar to how > x86 works). The only problem will be the MIPS variants which don't > have this register. I bet there are some. No. Ralf From owner-linux-mips@oss.sgi.com Mon Jan 21 16:31:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M0V4b19013 for linux-mips-outgoing; Mon, 21 Jan 2002 16:31:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M0UxP19010; Mon, 21 Jan 2002 16:30:59 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) 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 SMTP id PAA04615; Mon, 21 Jan 2002 15:29:44 -0800 (PST) mail_from (drepper@redhat.com) Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA16882; Mon, 21 Jan 2002 15:22:31 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0LNMUQ24648; Mon, 21 Jan 2002 15:22:30 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Ralf Baechle Cc: "Kevin D. Kissell" , "H . J . Lu" , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 15:22:29 -0800 In-Reply-To: <20020119162415.B31028@dea.linux-mips.net> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 687 Lines: 14 Ralf Baechle writes: > Changing the kernel for the small number of threaded applications that > exists and taking a performance impact for the kernel itself and anything > that's using threads is an exquisite example for a bad tradeoff. Well, it seems you haven't read what I wrote. It's not about a small number of threaded applications anymore. The thread register will be part of the ABI and all applications, threaded or not, will use it. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jan 21 16:44:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M0iDP19213 for linux-mips-outgoing; Mon, 21 Jan 2002 16:44:13 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M0iBP19210 for ; Mon, 21 Jan 2002 16:44:11 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Jan 2002 23:47:13 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g0LNg9W13674 for ; Mon, 21 Jan 2002 15:42:09 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id PAA07631; Mon, 21 Jan 2002 15:43:29 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id RAA15559; Mon, 21 Jan 2002 17:37:32 -0600 Message-ID: <3C4CA8C8.5010801@esstech.com> Date: Mon, 21 Jan 2002 17:48:24 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ide dma in latest cvs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 760 Lines: 21 Does the latest CVS version work with an IDE controller in DMA mode? I have an NEC VR5432 based system working with the IDE controller, but it crashes when used in dma mode. I've tracked it down to the following code called from ide_build_sglist(): - blk_rq_map_sg() is called to build a list of blocks to be transferred. It sets address = NULL for every entry (other fields like "page" are set to valid values). - dma_cache_wback_inv(addr, size) is called for each block entry. This routine crashes because the address parameter is always set to zero when the routine is called. I see that this is part of the new bio code recently added. Should I expect this code to work, or is it not yet working for the mips platform? Thanks. Gerald From owner-linux-mips@oss.sgi.com Mon Jan 21 16:57:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M0vBk19615 for linux-mips-outgoing; Mon, 21 Jan 2002 16:57:11 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M0v5P19612; Mon, 21 Jan 2002 16:57:05 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA23132; Mon, 21 Jan 2002 15:56:54 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA19075; Mon, 21 Jan 2002 15:56:52 -0800 (PST) Message-ID: <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Ulrich Drepper" Cc: "Mike Uhler" , , "GNU libc hacker" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 00:57:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 990 Lines: 25 Ulrich Drepper" writes: > > Ralf Baechle writes: > > > Changing the kernel for the small number of threaded applications that > > exists and taking a performance impact for the kernel itself and anything > > that's using threads is an exquisite example for a bad tradeoff. > > Well, it seems you haven't read what I wrote. It's not about a small > number of threaded applications anymore. The thread register will be > part of the ABI and all applications, threaded or not, will use it. As MIPS "owns" the ABI, whether or not the thread register becomes a part of it is not something that anyone outside of MIPS can simply decree. I'd very much appreciate it if someone would explain to me just what this register is used for, and why a register needs to be permantly allocated for this purpose. There may still be other ways to solve the problem without doing violence to the kernel or to the ABI. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 21 17:16:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M1GSA19941 for linux-mips-outgoing; Mon, 21 Jan 2002 17:16:28 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M1GKP19936; Mon, 21 Jan 2002 17:16:21 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA21566; Mon, 21 Jan 2002 16:16:10 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0M0G9H24788; Mon, 21 Jan 2002 16:16:09 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "Kevin D. Kissell" Cc: "Ralf Baechle" , "Mike Uhler" , , "H . J . Lu" Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 16:16:09 -0800 In-Reply-To: <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 842 Lines: 20 "Kevin D. Kissell" writes: > As MIPS "owns" the ABI, whether or not the thread register > becomes a part of it is not something that anyone outside > of MIPS can simply decree. Well, MIPS might define the "official" ABI but nobody is forced to use it and if nobody uses it it's nor worth anything. > I'd very much appreciate it if someone would explain to me just what > this register is used for, and why a register needs to be permantly > allocated for this purpose. Simply look at the ABIs for some less-backward processors. Read the thread-local storage section in the IA-64 ABI specification. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jan 21 18:39:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M2dIA21583 for linux-mips-outgoing; Mon, 21 Jan 2002 18:39:18 -0800 Received: from are.twiddle.net (are.twiddle.net [64.81.246.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M2dGP21580 for ; Mon, 21 Jan 2002 18:39:16 -0800 Received: (from rth@localhost) by are.twiddle.net (8.11.6/8.11.6) id g0M1dBG14522; Mon, 21 Jan 2002 17:39:11 -0800 Date: Mon, 21 Jan 2002 17:39:11 -0800 From: Richard Henderson To: "H . J . Lu" Cc: Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com Subject: Re: thread-ready ABIs Message-ID: <20020121173911.A14483@are.twiddle.net> Mail-Followup-To: "H . J . Lu" , Ulrich Drepper , GNU libc hacker , linux-mips@oss.sgi.com References: <20020118101908.C23887@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: <20020118101908.C23887@lucon.org>; from hjl@lucon.org on Fri, Jan 18, 2002 at 10:19:08AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 221 Lines: 8 On Fri, Jan 18, 2002 at 10:19:08AM -0800, H . J . Lu wrote: > On the other hand, can we change the mips kernel to save k0 or k1 for > user space? I doubt it. Traditionally these are clobbered by the TLB fill trap. r~ From owner-linux-mips@oss.sgi.com Mon Jan 21 19:00:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M30pu22024 for linux-mips-outgoing; Mon, 21 Jan 2002 19:00:51 -0800 Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M30iP22019 for ; Mon, 21 Jan 2002 19:00:44 -0800 Received: (qmail 17488 invoked by uid 104); 22 Jan 2002 02:00:36 -0000 Received: from Manoj_Ekbote@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4181. . Clean. Processed in 0.734354 secs); 22 Jan 2002 02:00:36 -0000 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 22 Jan 2002 02:00:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g0M20Zm17564 for ; Mon, 21 Jan 2002 18:00:35 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 18:00:36 -0800 Message-ID: From: Manoj Ekbote To: "'linux-mips@oss.sgi.com'" Subject: changing the PAGE_OFFSET variable Date: Mon, 21 Jan 2002 18:00:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 491 Lines: 11 Hi, I am trying to load a kernel on a board whose SDRAM is mapped to 0x8000000.So, the LOADADDR reads 0xa8000000. In order to generate the correct virtual and physical addresses (for __pa and __va macros), I would have to change the PAGE_OFFSET to 0xa0000000.I guess I would also have to change some routines in include/asm/io.h that translate the virtual addresses to physical addresses and vice versa. I am not having any PCI access. Do I need to make any other changes? Thanks, Manoj From owner-linux-mips@oss.sgi.com Mon Jan 21 23:30:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M7U9525955 for linux-mips-outgoing; Mon, 21 Jan 2002 23:30:09 -0800 Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [146.215.0.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M7RtP25890 for ; Mon, 21 Jan 2002 23:27:56 -0800 Received: from mail5.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns4.sony.co.jp (R8/Sony) with ESMTP id g0M6RmY53227; Tue, 22 Jan 2002 15:27:48 +0900 (JST) Received: from mail5.sony.co.jp (localhost [127.0.0.1]) by mail5.sony.co.jp (R8/Sony) with ESMTP id g0M6Rmh07153; Tue, 22 Jan 2002 15:27:48 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail5.sony.co.jp (R8/Sony) with ESMTP id g0M6RlF07136; Tue, 22 Jan 2002 15:27:47 +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 PAA22509; Tue, 22 Jan 2002 15:32:31 +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 PAA29771; Tue, 22 Jan 2002 15:27:44 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0M6RiJ04934; Tue, 22 Jan 2002 15:27:44 +0900 (JST) To: kevink@mips.com, hjl@lucon.org, drepper@redhat.com, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: patches for test-and-set without ll/sc (Re: thread-ready ABIs) In-Reply-To: <20020120221607T.machida@sm.sony.co.jp> References: <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> <20020120221607T.machida@sm.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jan_22_15:27:43_2002_135)--" Content-Transfer-Encoding: 7bit Message-Id: <20020122152744C.machida@sm.sony.co.jp> Date: Tue, 22 Jan 2002 15:27:44 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 33857 Lines: 1312 ----Next_Part(Tue_Jan_22_15:27:43_2002_135)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all. As I said at 1/20, I'll post the short descriptions about our test-and-set implementation and patches for linux-2.4.17 and glibc-2.2.3. ===================================================================== We implemented the fast and safe user level test and set function for single MIPS CPUs. You don't need to use LL/SC and sysmips() with this method. (excatly say, sysmips() is needed for initializing, but once initialized, we don't use it any more). NOTE: We assume the single processor to use this method, You can not use our method for SMP. WHAT'S CHANGED: * kernel side change #1 Set specific constant (we call this value "_TST_ACCESS_MAGIC") to K1 on every transition from kernel mode to user mode. This means you can use k1 in any exception handler as same as before our method introduced, except that you have to do "li k1, _TST_ACCESS_MAGIC" at the very previous of "eret" or "j k0; "rfe" . We choose the value of _TST_ACCESS_MAGIC, to cause SEGV fault when you use this value as address. * kernel side change #2 On memory fault hander, kernel check write-access to _TST_ACCESS_MAGIC from fixed address range of user process. (EPC is in _TST_START_MAGIC to _TST_START_MAGIC+PAGE_SIZE) If the condtion is met, kernel restart user process from _TST_START_MAGIC. * kernel side change #3 We add pseudo device driver "/dev/tst" to provide test_and_set procedure at the same virtual address (_TST_START_MAGIC) to any user process. _TST_START_MAGIC: .set noreorder 0: move k1, a0 lw v0, 0(a0) nop bnez v0, 1f nop bne k1, a0, 0b nop .... sw a1, 0(k1) 1: jr ra nop * glibc change: We implement test_and_set(addr, val) as follows, Do mmap /dev/tst to _TST_START_MAGIC, if not yet mapped. call _TST_START_MAGIC(addr, val) If we can't open /dev/tst then, use sysmips() as final resort. HOW TO WORK: If no context-switch is occured in _TST_START_MAGIC() procedure, nobody changes the mutex var. It's no problem. So you can do _TST_START_MAGIC() porcedure as you see. But, if some context-swtich is occured in _TST_START_MAGIC() somebody chages the mutex var. It's a problem. We must not store to the mutex var, if context-swtich is occured at . In our method, kernel sets k1 as _TST_ACCESS_MAGIC on transition to user mode. "sw a1, 0(k1)" causes SEGV-fault if context-swtich is occured at . The SEGV-fault hander catch this situation, restart user process from top of _TST_START_MAGIC(). PATCHES: I attached three patches; 1. patch for linux kernel 2.4.17 (SourceForge tree) 2. patch for glibc 2.2.3 (of HHL 2.0) 3. patch for linuxthread 2.2.3 (of HHL 2.0) To test those patches; you must turn on CONFIG_MIPS_TST_DEV on config kernel, have working version of sysmips(MIPS_ATOMIC_SET), update kernel headers before building glibc and make /dev/tst device ("mknod c /dev/tst 123 0", 123 is a tempoary major number for this device) I'v tested at ITE board. On testing, I'v made lettle changes into "drivers/char/Config.in" and "arch/mips/kernel/sysmip.c" to enable CONFIG_MIPS_TST_DEV and to work sysmips() at ITE board. Those chages are not included in the patch set. =================================================================== You can find the paper about it in http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf (sorry in japanese only) The abstract of the paper is following; The Implementation of user level test-and-set on PS2 Linux In the multi-thread environment like Linux, a fast user-level mutual exclusion mechanism is strongly required. But MIPS chips designed for embedded and single processor, like the Emotion Engine, have no atomic test-and-set instruction. We implemented the fast user-level mutual exclusion without invoking system-call and its costs, on the PS2 Linux. This method utilizes the memory protection facility of Operating System, to detect preemption and nullify the operation. In this paper, we present the method and its evaluation. --- Hiroyuki Machida Sony Corp. ----Next_Part(Tue_Jan_22_15:27:43_2002_135)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.4-mips-tas.patch" Index: arch/mips/kernel/entry.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/kernel/entry.S,v retrieving revision 1.14 diff -u -p -r1.14 entry.S --- arch/mips/kernel/entry.S 2001/12/10 17:46:47 1.14 +++ arch/mips/kernel/entry.S 2002/01/22 05:13:37 @@ -161,6 +161,7 @@ handle_vced: addiu k1, 1 sw k1, %lo(vced_count)(k0) #endif + TST_DEV_EPILOGUE eret handle_vcei: @@ -172,6 +173,7 @@ handle_vcei: addiu k1, 1 sw k1, %lo(vcei_count)(k0) #endif + TST_DEV_EPILOGUE eret .set pop END(except_vec3_r4000) Index: arch/mips/kernel/gdb-low.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/kernel/gdb-low.S,v retrieving revision 1.4 diff -u -p -r1.4 gdb-low.S --- arch/mips/kernel/gdb-low.S 2002/01/02 17:06:08 1.4 +++ arch/mips/kernel/gdb-low.S 2002/01/22 05:13:38 @@ -304,6 +304,7 @@ lw v1,GDB_FR_REG3(sp) lw v0,GDB_FR_REG2(sp) lw $1,GDB_FR_REG1(sp) + TST_DEV_EPILOGUE #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) lw k0, GDB_FR_EPC(sp) lw sp, GDB_FR_REG29(sp) /* Deallocate stack */ Index: arch/mips/kernel/r2300_misc.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/kernel/r2300_misc.S,v retrieving revision 1.2 diff -u -p -r1.2 r2300_misc.S --- arch/mips/kernel/r2300_misc.S 2001/10/09 21:37:55 1.2 +++ arch/mips/kernel/r2300_misc.S 2002/01/22 05:13:38 @@ -130,9 +130,10 @@ 1: tlbwr; \ 2: -#define RET(reg) \ +#define RET(reg) /* don't pass k1 to REG */ \ mfc0 reg, CP0_EPC; \ nop; \ + TST_DEV_EPILOGUE /* this may use k1 */ \ jr reg; \ rfe Index: arch/mips/kernel/r4k_misc.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/kernel/r4k_misc.S,v retrieving revision 1.5 diff -u -p -r1.5 r4k_misc.S --- arch/mips/kernel/r4k_misc.S 2001/10/09 21:37:55 1.5 +++ arch/mips/kernel/r4k_misc.S 2002/01/22 05:13:38 @@ -167,6 +167,7 @@ invalid_tlbl: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 @@ -191,6 +192,7 @@ nopage_tlbl: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 @@ -225,6 +227,7 @@ nopage_tlbs: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 Index: arch/mips/mm/fault.c =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/mm/fault.c,v retrieving revision 1.8 diff -u -p -r1.8 fault.c --- arch/mips/mm/fault.c 2001/12/07 19:28:37 1.8 +++ arch/mips/mm/fault.c 2002/01/22 05:14:37 @@ -26,6 +26,10 @@ #include #include +#if defined (CONFIG_MIPS_TST_DEV) || defined (CONFIG_MIPS_TST_DEV_MODULE) +#include +#endif + #define development_version (LINUX_VERSION_CODE & 0x100) /* @@ -160,6 +164,28 @@ bad_area: bad_area_nosemaphore: /* User mode accesses just cause a SIGSEGV */ if (user_mode(regs)) { +#if defined (CONFIG_MIPS_TST_DEV) || defined (CONFIG_MIPS_TST_DEV_MODULE) + /* TEST AND SET magic code */ + /* Restart user program from _TST_START_MAGIC, + when all of following conditions are matched; + + 1. User program tried to wirte into _TST_ACCESS_MAGIC address. + 2. That write access was done at the page including + _TST_START_MAGIC. + */ + + if (address == _TST_ACCESS_MAGIC && write ) { + + unsigned long pc; + pc = (unsigned long)regs->cp0_epc; + if ( _TST_START_MAGIC <= pc + && pc < (_TST_START_MAGIC + PAGE_SIZE)){ + + regs->cp0_epc = (unsigned long)_TST_START_MAGIC; + return; + } + } +#endif /* defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE) */ tsk->thread.cp0_badvaddr = address; tsk->thread.error_code = write; #if 0 Index: arch/mips/mm/tlbex-r3k.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/mm/tlbex-r3k.S,v retrieving revision 1.3 diff -u -p -r1.3 tlbex-r3k.S --- arch/mips/mm/tlbex-r3k.S 2002/01/04 18:04:53 1.3 +++ arch/mips/mm/tlbex-r3k.S 2002/01/22 05:14:37 @@ -48,9 +48,10 @@ lw k0, (k1) nop mtc0 k0, CP0_ENTRYLO0 - mfc0 k1, CP0_EPC + mfc0 k0, CP0_EPC tlbwr - jr k1 + TST_DEV_EPILOGUE + jr k0 rfe END(except_vec0_r2300) @@ -155,9 +156,11 @@ 1: tlbwr; \ 2: -#define RET(reg) \ + +#define RET(reg) /* don't pass k1 to REG */ \ mfc0 reg, CP0_EPC; \ nop; \ + TST_DEV_EPILOGUE /* this may use k1 */ \ jr reg; \ rfe Index: arch/mips/mm/tlbex-r4k.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/mm/tlbex-r4k.S,v retrieving revision 1.4 diff -u -p -r1.4 tlbex-r4k.S --- arch/mips/mm/tlbex-r4k.S 2002/01/04 18:04:53 1.4 +++ arch/mips/mm/tlbex-r4k.S 2002/01/22 05:14:37 @@ -90,6 +90,7 @@ tlbwr # write random tlb entry 1: nop + TST_DEV_EPILOGUE eret # return from trap END(except_vec0_r4000) @@ -117,6 +118,7 @@ nop tlbwr nop + TST_DEV_EPILOGUE eret END(except_vec0_r4600) @@ -156,6 +158,7 @@ nop tlbwr # write random tlb entry nop # traditional nop + TST_DEV_EPILOGUE eret # return from trap END(except_vec0_nevada) @@ -187,6 +190,7 @@ tlbwr 1: nop + TST_DEV_EPILOGUE eret END(except_vec0_r45k_bvahwbug) @@ -219,6 +223,7 @@ tlbwr 1: nop + TST_DEV_EPILOGUE eret END(except_vec0_r4k_mphwbug) #endif @@ -250,6 +255,7 @@ tlbwr 1: nop + TST_DEV_EPILOGUE eret END(except_vec0_r4k_250MHZhwbug) @@ -284,6 +290,7 @@ tlbwr 1: nop + TST_DEV_EPILOGUE eret END(except_vec0_r4k_MP250MHZhwbug) #endif @@ -454,6 +461,7 @@ invalid_tlbl: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 @@ -478,6 +486,7 @@ nopage_tlbl: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 @@ -508,6 +517,7 @@ nopage_tlbs: tlbwi 1: nop + TST_DEV_EPILOGUE .set mips3 eret .set mips0 @@ -638,6 +648,7 @@ END(get_real_pte) lui k0, %hi(__saved_at) lw $at, %lo(__saved_at)(k0) # restore at lw ra, %lo(__saved_ra)(k0) # restore ra + TST_DEV_EPILOGUE eret # return from trap END(translate_pte) Index: drivers/char/Config.in =================================================================== RCS file: /cvsroot/linux-mips/linux/drivers/char/Config.in,v retrieving revision 1.29 diff -u -p -r1.29 Config.in --- drivers/char/Config.in 2001/12/02 19:05:31 1.29 +++ drivers/char/Config.in 2002/01/22 05:33:21 @@ -269,3 +269,10 @@ if [ "$CONFIG_MIPS_ITE8172" = "y" ]; the tristate ' ITE GPIO' CONFIG_ITE_GPIO fi endmenu + +if [ "$CONFIG_MIPS" = "y" -a "$CONFIG_CPU_HAS_LLSC" = "n" ]; then + mainmenu_option next_comment + comment 'MIPS specific pseudo device driver' + tristate ' MIPS1 fast test and set support' CONFIG_MIPS_TST_DEV + endmenu +fi Index: drivers/char/Makefile =================================================================== RCS file: /cvsroot/linux-mips/linux/drivers/char/Makefile,v retrieving revision 1.24 diff -u -p -r1.24 Makefile --- drivers/char/Makefile 2001/12/05 19:49:28 1.24 +++ drivers/char/Makefile 2002/01/22 05:33:21 @@ -24,7 +24,7 @@ obj-y += mem.o tty_io.o n_tty.o tty_ioc export-objs := busmouse.o console.o keyboard.o sysrq.o \ misc.o pty.o random.o selection.o serial.o \ sonypi.o tty_io.o tty_ioctl.o generic_serial.o \ - au1000_gpio.o lcd.o + au1000_gpio.o lcd.o tst_dev.o mod-subdirs := joystick ftape drm pcmcia @@ -247,6 +247,8 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o obj-$(CONFIG_VR41XX_WDT) += vr41xxwdt.o + +obj-$(CONFIG_MIPS_TST_DEV) += tst_dev.o subdir-$(CONFIG_MWAVE) += mwave ifeq ($(CONFIG_MWAVE),y) Index: include/asm-mips/stackframe.h =================================================================== RCS file: /cvsroot/linux-mips/linux/include/asm-mips/stackframe.h,v retrieving revision 1.3 diff -u -p -r1.3 stackframe.h --- include/asm-mips/stackframe.h 2001/10/24 23:32:54 1.3 +++ include/asm-mips/stackframe.h 2002/01/22 05:33:22 @@ -16,6 +16,15 @@ #include #include +#if defined (CONFIG_MIPS_TST_DEV) || defined (CONFIG_MIPS_TST_DEV_MODULE) +#include +#define TST_DEV_EPILOGUE \ + li k1, _TST_ACCESS_MAGIC; +#else +#define TST_DEV_EPILOGUE +#endif + + #define SAVE_AT \ .set push; \ .set noat; \ @@ -195,6 +204,7 @@ __asm__ ( .set noreorder; \ lw k0, PT_EPC(sp); \ lw sp, PT_R29(sp); \ + TST_DEV_EPILOGUE \ jr k0; \ rfe; \ .set pop @@ -230,6 +240,7 @@ __asm__ ( #define RESTORE_SP_AND_RET \ lw sp, PT_R29(sp); \ + TST_DEV_EPILOGUE \ .set mips3; \ eret; \ .set mips0 Index: include/linux/tst_dev.h =================================================================== --- /dev/null Wed May 6 05:32:27 1998 +++ include/linux/tst_dev.h Mon Jan 21 14:29:50 2002 @@ -0,0 +1,37 @@ +/* + * tst_dev.h - MIPS1 TEST and SET pseudo device interface + */ + + +#ifndef _TST_DEV_H +#define _TST_DEV_H + +#define TST_DEVICE_NAME "tst" + +#ifndef _LANGUAGE_ASSEMBLY + +#include + +struct _tst_area_info { + __u32 magic; + __u32 pad1; + void *map_addr; +#if _MIPS_SZPTR==32 + __u32 pad2; +#endif + }; + +#endif /*_LANGUAGE_ASSEMBLY*/ + +#define _TST_INFO_MAGIC 0x20000304 /* obsolete */ +#define _TST_INFO_MAGIC_2ARGS 0x20000305 + +#ifdef __KERNEL__ +#define _TST_ACCESS_MAGIC 0x00200000 +#define _TST_START_MAGIC 0x00300000 +#endif /* __KERNEL_ */ + +#endif /*_TST_DEV_H */ + + + Index: drivers/char/tst_dev.c =================================================================== --- /dev/null Wed May 6 05:32:27 1998 +++ drivers/char/tst_dev.c Tue Jan 22 12:01:16 2002 @@ -0,0 +1,404 @@ +/* + * tst_dev.c - Test and Set device for mips which has not LL/SC. + * + * Copyright (C) 2000, 2001, 2002 Sony Computer Entertainment Inc. + * Copyright 2001, 2002 Sony Corp. + * + * This file is subject to the terms and conditions of the GNU General + * Public License Version 2. See the file "COPYING" in the main + * directory of this archive for more details. + * + */ + +#include + +#ifndef CONFIG_MIPS +#error "Sorry, this device is for MIPS only." +#endif +#if !defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) +#error "Not on this device" +#endif + +/* + * Setup/Clean up Driver Module + */ + +#ifdef MODULE + +#ifndef EXPORT_SYMTAB +#define EXPORT_SYMTAB +#endif + +#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS) +#define MODVERSIONS +#endif + +#ifdef MODVERSIONS +#include +#endif + +#endif /* MODULE */ + +#include + +#include /* error codes */ +#include /* printk() */ +#include /* file op. */ +#include /* proc fs file op. */ +#include +#include +#include +#include /* copy to/from user space */ +#include /* page size */ +#include /* PAGE_READONLY */ + +#include + +#include + +#include + +#ifndef TSTDEV_MAJOR +#define TSTDEV_MAJOR 123 +#endif + +static int tst_major=TSTDEV_MAJOR; + +EXPORT_SYMBOL(tst_major); /* export symbole */ +MODULE_PARM(tst_major,"i"); /* as parameter on loaing */ + + +/* + * File Operations table + * please refer for other methods. + */ + +static struct file_operations tst_fops; + + +#ifndef TST_DEVICE_NAME +#define TST_DEVICE_NAME "tst" +#endif + + +static spinlock_t lock; +static struct page * tst_code_buffer = 0 ; +static const __u32 tst_code[] = { +/* 0:*/ 0x0080d821, //move $k1,$a0 +/* 4:*/ 0x8c820000, //lw $v0,0($a0) +/* 8:*/ 0x00000000, //nop +/* c:*/ 0x14400004, //bnez $v0,0x20 +/* 10:*/ 0x00000000, //nop +/* 14:*/ 0x1764fffa, //bne $k1,$a0,0x0 +/* 18:*/ 0x00000000, //nop +/* 1c:*/ 0xaf650000, //sw $a1,0($k1) +/* 20:*/ 0x03e00008, //jr $ra +/* 24:*/ 0x00000000, //nop + 0}; + + +EXPORT_SYMBOL(tst_code_buffer); /* export symbole */ + +/******************** + +#include + + .set noreorder +0: + move k1 ,a0 + lw v0, 0(a0) + nop + bnez v0, 1f + nop + bne k1, a0, 0b + nop + sw a1, 0(k1) +1: + jr ra + nop + +*********************/ + + + + +static +int try_init_code_buffer(void) +{ + + spin_lock(&lock); + if (!tst_code_buffer) { + tst_code_buffer = alloc_pages(GFP_KERNEL, 0); + spin_unlock(&lock); + + if (!tst_code_buffer) + return -EBUSY; + + clear_page(page_address(tst_code_buffer)); + + memcpy (page_address(tst_code_buffer), (void *)tst_code, + sizeof (tst_code) * sizeof (tst_code[0])); + + } else { + spin_unlock(&lock); + } + return 0; +} + +#ifdef MODULE +static +void try_free_code_buffer(void) +{ + + spin_lock(&lock); + if (tst_code_buffer) { + page_t *pg = tst_code_buffer; + tst_code_buffer=0; + spin_unlock(&lock); + put_page (pg); + } else { + spin_unlock(&lock); + } +} +#endif + +static get_info_t get_tst_info; + + +/* + * Caller of (*get_info)() is proc_file_read() in fs/proc/generic.c + */ +static +int get_tst_info (char *buf, /* allocated area for info */ + char **start, /* return youown area if you allocate */ + off_t pos, /* pos arg of vfs read */ + int count) /* readable bytes */ +{ + +/* SPRINTF does not exist in the kernel */ +#define MY_BUFSIZE 256 +#define MARGIN 16 + char mybuf[MY_BUFSIZE+MARGIN]; + + int len; + + len = sprintf(mybuf, + "_TST_INFO_MAGIC:\t0x%8.8x\n" + "_TST_START_MAGIC:\t0x%8.8x\n" + "_TST_ACCESS_MAGIC:\t0x%8.8x\n", + _TST_INFO_MAGIC_2ARGS, + _TST_START_MAGIC, + _TST_ACCESS_MAGIC + ); + if (len >= MY_BUFSIZE) mybuf[MY_BUFSIZE] = '\0'; + + if ( pos+count >= len ) { + count = len-pos; + } + memcpy (buf, mybuf+pos, count); + return count; +} + +#ifdef MODULE + +#define tst_dev_init init_module + +void +cleanup_module (void) +{ + /* free code buffer */ + try_free_code_buffer(); + + /* unregister /proc entry */ + + (void) remove_proc_entry(TST_DEVICE_NAME, NULL); + + /* unregister chrdev */ + unregister_chrdev(tst_major, TST_DEVICE_NAME); +} + + +#endif /* MODULE */ + + +int __init tst_dev_init(void) +{ + + int result; + + spin_lock_init(&lock); + + result = register_chrdev(tst_major, TST_DEVICE_NAME , &tst_fops); + if (result < 0) { + printk(KERN_WARNING + TST_DEVICE_NAME ": can't get major %d\n",tst_major); + return result; + } + if (tst_major == 0) tst_major = result; /* dynamic */ + + /* + * register /proc entry, if you want. + */ + + + if (!create_proc_info_entry(TST_DEVICE_NAME, 0, NULL, &get_tst_info)) { + printk(KERN_WARNING + TST_DEVICE_NAME ": can't get proc entry\n"); + unregister_chrdev(tst_major, TST_DEVICE_NAME); + return result; + } + + (void) try_init_code_buffer(); + + return 0; +} + +#ifndef MODULE +__initcall(tst_dev_init); +#endif + + +//======================================================================== + +/* + * VMA Opreations + */ + +static void tst_vma_open(struct vm_area_struct *vma) +{ + MOD_INC_USE_COUNT; +} + +static void tst_vma_close(struct vm_area_struct *vma) +{ + MOD_DEC_USE_COUNT; +} + +struct page * +tst_vma_nopage (struct vm_area_struct * area, + unsigned long address, int write_access) +{ + if ( address != _TST_START_MAGIC + || area->vm_start != _TST_START_MAGIC + || area->vm_pgoff != 0 ) + return 0; + + get_page(tst_code_buffer); + flush_page_to_ram(tst_code_buffer); + return tst_code_buffer; +} + + +static struct vm_operations_struct tst_vm_ops = { + open:tst_vma_open, + close:tst_vma_close, + nopage:tst_vma_nopage, +}; + +//======================================================================== + +/* + * Device File Operations + */ + + +/* + * Open and Close + */ + +static int tst_open (struct inode *p_inode, struct file *p_file) +{ + + int ret_code; + if ( p_file->f_mode & FMODE_WRITE ) { + return -EPERM; + } + + ret_code = try_init_code_buffer (); + if (ret_code) { + return ret_code; + } + + /* + * if you want store something for later processing, do it on + * p_file->private_data . + */ + MOD_INC_USE_COUNT; + return 0; /* success */ +} + +static int tst_release (struct inode *p_inode, struct file *p_file) +{ + MOD_DEC_USE_COUNT; + return 0; +} + + +/* + * Mmap + */ +static int tst_mmap(struct file *file, struct vm_area_struct *vma) +{ + unsigned long size; + + if (vma->vm_start != _TST_START_MAGIC) + return -ENXIO; + + if (vma->vm_pgoff != 0) + return -ENXIO; + + size = vma->vm_end - vma->vm_start; + if (size != PAGE_SIZE) + return -EINVAL; + + vma->vm_ops = &tst_vm_ops; + + tst_vma_open(vma); + + return 0; +} + + +/* + * Read + */ +static ssize_t tst_read(struct file *p_file, char * p_buff, size_t count, + loff_t * p_pos) +{ + + struct _tst_area_info info; + int data; + struct inode * p_inode; + int info_size = sizeof(info); + + p_inode = p_file->f_dentry->d_inode; + data = MAJOR(p_inode->i_rdev); + + info.magic = _TST_INFO_MAGIC_2ARGS; + info.pad1 = 0; + info.map_addr = (void *)_TST_START_MAGIC; +#if _MIPS_SZPTR==32 + info.pad2 = 0; +#endif + + if (*p_pos + count >= info_size){ + count = info_size - *p_pos; + } + if(copy_to_user(p_buff,((char *)&info)+*p_pos, count)) { + return -EFAULT; + } + *p_pos += count; + return count; +} + +static +struct file_operations tst_fops = { + /* ssize_t (*read) (struct file *, char *, size_t, loff_t *); */ + read:tst_read, + /* int (*open) (struct inode *, struct file *); */ + open:tst_open, + /* int (*release) (struct inode *, struct file *);*/ + release:tst_release, + /* int (*mmap) (struct file *, struct vm_area_struct *); */ + mmap:tst_mmap, +}; Index: arch/mips/kernel/head.S =================================================================== RCS file: /cvsroot/linux-mips/linux/arch/mips/kernel/head.S,v retrieving revision 1.12 diff -u -p -r1.12 head.S --- arch/mips/kernel/head.S 2002/01/04 18:04:53 1.12 +++ arch/mips/kernel/head.S 2002/01/22 05:48:36 @@ -101,6 +101,7 @@ addiu k1, k1, 4 1: mtc0 k1, $24 RESTORE_ALL + TST_DEV_EPILOGUE .word 0x4200001f # deret, return EJTAG debug exception. nop .set at ----Next_Part(Tue_Jan_22_15:27:43_2002_135)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="glibc-2.2.3-mips-tas.patch" Index: sysdeps/unix/sysv/linux/mips/Makefile =================================================================== RCS file: /export/cvsroot/CoPE/cmplrs/glibc-2.2/sysdeps/unix/sysv/linux/mips/Makefile,v retrieving revision 1.1.3.1 diff -u -p -r1.1.3.1 Makefile --- sysdeps/unix/sysv/linux/mips/Makefile 13 Dec 2001 05:28:00 -0000 1.1.3.1 +++ sysdeps/unix/sysv/linux/mips/Makefile 22 Jan 2002 05:22:35 -0000 @@ -5,7 +5,7 @@ sysdep_routines += rt_sigsuspend rt_sigp endif ifeq ($(subdir),misc) -sysdep_routines += cachectl cacheflush sysmips _test_and_set +sysdep_routines += cachectl cacheflush sysmips _test_and_set mips1_tst sysdep_headers += sys/cachectl.h sys/sysmips.h sys/tas.h endif Index: sysdeps/unix/sysv/linux/mips/Versions =================================================================== RCS file: /export/cvsroot/CoPE/cmplrs/glibc-2.2/sysdeps/unix/sysv/linux/mips/Versions,v retrieving revision 1.1.3.1 diff -u -p -r1.1.3.1 Versions --- sysdeps/unix/sysv/linux/mips/Versions 13 Dec 2001 05:28:00 -0000 1.1.3.1 +++ sysdeps/unix/sysv/linux/mips/Versions 22 Jan 2002 05:22:35 -0000 @@ -17,5 +17,8 @@ libc { GLIBC_2.2 { # _* _test_and_set; + # mips1 test and set + __mips1_tst_func; + __mips1_tst_func_2args; } } Index: sysdeps/unix/sysv/linux/mips/sys/tas.h =================================================================== RCS file: /export/cvsroot/CoPE/cmplrs/glibc-2.2/sysdeps/unix/sysv/linux/mips/sys/tas.h,v retrieving revision 1.1.3.1 diff -u -p -r1.1.3.1 tas.h --- sysdeps/unix/sysv/linux/mips/sys/tas.h 13 Dec 2001 05:28:00 -0000 1.1.3.1 +++ sysdeps/unix/sysv/linux/mips/sys/tas.h 22 Jan 2002 05:22:35 -0000 @@ -23,6 +23,7 @@ #include #include #include +#include __BEGIN_DECLS @@ -34,7 +35,8 @@ extern int _test_and_set (int *p, int v) # define _EXTERN_INLINE extern __inline # endif -# if (_MIPS_ISA >= _MIPS_ISA_MIPS2) +# if (_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)) _EXTERN_INLINE int _test_and_set (int *p, int v) __THROW @@ -59,15 +61,19 @@ _test_and_set (int *p, int v) __THROW return r; } -# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# else /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ + +extern int (*__mips1_tst_func_2args)(volatile int *, int); _EXTERN_INLINE int _test_and_set (int *p, int v) __THROW { - return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); + return (*__mips1_tst_func_2args)((volatile int *)p, v); } -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# endif /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ #endif /* __USE_EXTERN_INLINES */ Index: sysdeps/unix/sysv/linux/mips/mips1_tst.c =================================================================== --- /dev/null Wed May 6 05:32:27 1998 +++ sysdeps/unix/sysv/linux/mips//mips1_tst.c Mon Jan 21 19:35:38 2002 @@ -0,0 +1,155 @@ +/* +- mips1_tst.c: fast test and set using /dev/tst. + + Copyright (C) 2000 Sony Computer Entertainment Inc. + Copyright 2002 Sony Corp. + +This file is subject to the terms and conditions of the GNU Library +General Public License Version 2 or later. See the file "COPYING.LIB" +in the main directory of this archive for more details. +*/ + +#include +#include +#include +#include +#include +#include + +#include +#include + + +static int init_tst_func(volatile int *spinlock); +static int init_tst_func_2args(volatile int *spinlock, int val); + +static volatile short lock_setup=0; + +/* + * __mips1_tst_func: + * This interface was originally designed for glibc-2.0.[67] and + * used on PS2 linux with glibc-2.2.2. This interface can NOT accept + * 2nd arg of _test_and_set() in glibc-2.2. + * We maintain this old interface to keep binary compatibility. + * + * __mips1_tst_func_2args: + * New interface which can accept 2nd arg of _test_and_set() + * in glibc-2.2. + * + */ +int (*__mips1_tst_func)(volatile int *) = (void *)init_tst_func; +int (*__mips1_tst_func_2args)(volatile int *, int) = + (void *)init_tst_func_2args; + +static int sysmips_tst_1arg(volatile int *spinlock) +{ + return sysmips((const int)MIPS_ATOMIC_SET, + (const int)spinlock, + (const int)1, + (const int)NULL); +} + +static int sysmips_tst_2args(volatile int *spinlock, int val) +{ + return sysmips((const int)MIPS_ATOMIC_SET, + (const int)spinlock, + (const int)val, + (const int)NULL); +} + +static int tst_1arg(volatile int *spinlock) +{ + return (*__mips1_tst_func_2args)(spinlock, 1) ; +} + +static int tst_2args(volatile int *spinlock, int val) +{ + static volatile int lock; + int retval; + + while ((*__mips1_tst_func)(&lock)!=0); + retval = *spinlock; + if (retval==0) { + *spinlock = val; + } + lock = 0; + return retval; +} + +static void setup_tst_func(void) +{ + struct _tst_area_info info; + int fd; + void *addr; + int res; + size_t size = getpagesize(); + int device_accept_2args = 0; + + while (sysmips((const int)MIPS_ATOMIC_SET, + (const int)&lock_setup, + (const int)1, + (const int)NULL)) ; + + if ( __mips1_tst_func != init_tst_func ){ + lock_setup=0; + return; + } + + fd = open( "/dev/" TST_DEVICE_NAME , O_RDONLY); + if (fd < 0) goto fail; + + res = read ( fd, &info, sizeof(info)); + switch (info.magic) { + case _TST_INFO_MAGIC: + break; + case _TST_INFO_MAGIC_2ARGS: + device_accept_2args = 1; + break; + default: + close(fd); + goto fail; + } + + addr=(void *)mmap(info.map_addr, size, + PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FIXED, + fd, 0); + close(fd); + + if (addr != info.map_addr ) { + if (addr != (void *)0 && addr !=(void *) -1) + munmap(addr,size); + goto fail; + } + + if (device_accept_2args) { + /* Use new device interface */ + __mips1_tst_func_2args = addr; + __mips1_tst_func = tst_1arg; + } else { + /* Use old device interface */ + __mips1_tst_func_2args = tst_2args; + __mips1_tst_func = addr; + + } + lock_setup=0; + return; + fail: + /* last resort */ + __mips1_tst_func = sysmips_tst_1arg; + __mips1_tst_func_2args = sysmips_tst_2args; + lock_setup=0; + return; +} + +static int init_tst_func(volatile int *spinlock) +{ + setup_tst_func(); + return (*__mips1_tst_func)(spinlock) ; +} + +static int init_tst_func_2args(volatile int *spinlock, int val) +{ + setup_tst_func(); + return (*__mips1_tst_func_2args)(spinlock, val) ; +} + ----Next_Part(Tue_Jan_22_15:27:43_2002_135)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linuxthread-2.2.3-mips-tas.patch" Index: linuxthreads/sysdeps/mips/pspinlock.c =================================================================== RCS file: /export/cvsroot/CoPE/cmplrs/glibc-2.2/linuxthreads/sysdeps/mips/pspinlock.c,v retrieving revision 1.1.3.1 diff -u -p -r1.1.3.1 pspinlock.c --- linuxthreads/sysdeps/mips/pspinlock.c 13 Dec 2001 05:28:33 -0000 1.1.3.1 +++ linuxthreads/sysdeps/mips/pspinlock.c 22 Jan 2002 05:25:59 -0000 @@ -23,7 +23,9 @@ #include #include "internals.h" -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) + +#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)) /* This implementation is similar to the one used in the Linux kernel. */ int @@ -49,7 +51,8 @@ __pthread_spin_lock (pthread_spinlock_t return 0; } -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +#else /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ int __pthread_spin_lock (pthread_spinlock_t *lock) @@ -58,7 +61,8 @@ __pthread_spin_lock (pthread_spinlock_t return 0; } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +#endif /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ weak_alias (__pthread_spin_lock, pthread_spin_lock) @@ -66,8 +70,7 @@ weak_alias (__pthread_spin_lock, pthread int __pthread_spin_trylock (pthread_spinlock_t *lock) { - /* To be done. */ - return 0; + return (_test_and_set (lock, 1) ? EBUSY : 0); } weak_alias (__pthread_spin_trylock, pthread_spin_trylock) Index: linuxthreads/sysdeps/mips/pt-machine.h =================================================================== RCS file: /export/cvsroot/CoPE/cmplrs/glibc-2.2/linuxthreads/sysdeps/mips/pt-machine.h,v retrieving revision 1.1.3.1 diff -u -p -r1.1.3.1 pt-machine.h --- linuxthreads/sysdeps/mips/pt-machine.h 13 Dec 2001 05:28:33 -0000 1.1.3.1 +++ linuxthreads/sysdeps/mips/pt-machine.h 22 Jan 2002 05:25:59 -0000 @@ -33,7 +33,8 @@ /* Spinlock implementation; required. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) +#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)) PT_EI long int testandset (int *spinlock) @@ -60,14 +61,16 @@ testandset (int *spinlock) return ret; } -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +#else /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ PT_EI long int testandset (int *spinlock) { return _test_and_set (spinlock, 1); } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +#endif /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ /* Get some notion of the current stack. Need not be exactly the top @@ -78,7 +81,8 @@ register char * stack_pointer __asm__ (" /* Compare-and-swap for semaphores. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) +#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)) #define HAS_COMPARE_AND_SWAP PT_EI int @@ -106,4 +110,5 @@ __compare_and_swap (long int *p, long in return ret; } -#endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +#endif /* !((_MIPS_ISA >= _MIPS_ISA_MIPS2) && \ + !(defined(CONFIG_MIPS_TST_DEV) || defined(CONFIG_MIPS_TST_DEV_MODULE)))*/ ----Next_Part(Tue_Jan_22_15:27:43_2002_135)---- From owner-linux-mips@oss.sgi.com Mon Jan 21 23:37:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M7bVC26071 for linux-mips-outgoing; Mon, 21 Jan 2002 23:37:31 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M7bRP26067 for ; Mon, 21 Jan 2002 23:37:27 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id WAA11785; Mon, 21 Jan 2002 22:37:04 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0M6b2q26556; Mon, 21 Jan 2002 22:37:02 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Machida Hiroyuki Cc: kevink@mips.com, hjl@lucon.org, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) References: <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> <20020120221607T.machida@sm.sony.co.jp> <20020122152744C.machida@sm.sony.co.jp> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 22:37:02 -0800 In-Reply-To: <20020122152744C.machida@sm.sony.co.jp> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1228 Lines: 31 Machida Hiroyuki writes: > * glibc change: > > We implement test_and_set(addr, val) as follows, > > Do mmap /dev/tst to _TST_START_MAGIC, if not yet mapped. > call _TST_START_MAGIC(addr, val) > > If we can't open /dev/tst then, use sysmips() as final resort. First, the patch as it is unacceptable. A file with copyright Sony? All the code must be copyrighted by the FSF. Sony will have to assign the copyright for the code to the FSF. Also, no such change can be accepted until the necessary kernel changes are in the official kernel sources. I cannot make any exceptions since otherwise all kinds of people want to see support for their local hack added. Furthermore, the symbols were not available in version 2.2. Therefore they cannot be exported with this version. It'll either be 2.2.6 (if their ever will be such a release) or 2.3. And finally, the patch should be sent to the glibc MIPS maintainer for review. The question is who feels responsible... -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jan 21 23:55:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M7tCT26333 for linux-mips-outgoing; Mon, 21 Jan 2002 23:55:12 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M7tAP26330 for ; Mon, 21 Jan 2002 23:55:10 -0800 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) 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 WAA01895 for ; Mon, 21 Jan 2002 22:55:05 -0800 (PST) mail_from (machida@sm.sony.co.jp) Received: from mail1.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g0M6kVL56762; Tue, 22 Jan 2002 15:46:31 +0900 (JST) Received: from mail1.sony.co.jp (localhost [127.0.0.1]) by mail1.sony.co.jp (R8) with ESMTP id g0M6kUl26955; Tue, 22 Jan 2002 15:46:31 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail1.sony.co.jp (R8) with ESMTP id g0M6kUg26937; Tue, 22 Jan 2002 15:46:30 +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 PAA23504; Tue, 22 Jan 2002 15:51: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 PAA00618; Tue, 22 Jan 2002 15:46:29 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0M6kTJ05008; Tue, 22 Jan 2002 15:46:29 +0900 (JST) To: drepper@redhat.com Cc: kevink@mips.com, hjl@lucon.org, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) In-Reply-To: References: <20020120221607T.machida@sm.sony.co.jp> <20020122152744C.machida@sm.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020122154629F.machida@sm.sony.co.jp> Date: Tue, 22 Jan 2002 15:46:29 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 492 Lines: 15 From: Ulrich Drepper Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: 21 Jan 2002 22:37:02 -0800 > First, the patch as it is unacceptable. A file with copyright Sony? > All the code must be copyrighted by the FSF. Sony will have to assign > the copyright for the code to the FSF. Please let us why. Acctually, glibc includes codes copyrighted by SUN and gcc includes codes copryrighed by HP and SGI. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Mon Jan 21 23:56:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M7uV426420 for linux-mips-outgoing; Mon, 21 Jan 2002 23:56:31 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M7uTP26407 for ; Mon, 21 Jan 2002 23:56:29 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id WAA12544; Mon, 21 Jan 2002 22:56:18 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0M6uH326612; Mon, 21 Jan 2002 22:56:17 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Machida Hiroyuki Cc: kevink@mips.com, hjl@lucon.org, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) References: <20020120221607T.machida@sm.sony.co.jp> <20020122152744C.machida@sm.sony.co.jp> <20020122154629F.machida@sm.sony.co.jp> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 21 Jan 2002 22:56:17 -0800 In-Reply-To: <20020122154629F.machida@sm.sony.co.jp> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 756 Lines: 17 Machida Hiroyuki writes: > Please let us why. Acctually, glibc includes codes copyrighted by > SUN and gcc includes codes copryrighed by HP and SGI. It contains public domain code and the rest of the code is assigned. If there is a header saying that somebody from a company wrote the code this is mentioned but the person also has a document signed. If you cannot live with this the code cannot be accepted. Any further discussion you have to have with the legal people at the FSF. I've no time for this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Tue Jan 22 02:17:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MAHwS28835 for linux-mips-outgoing; Tue, 22 Jan 2002 02:17:58 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MAHiP28831 for ; Tue, 22 Jan 2002 02:17:45 -0800 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 KAA27584; Tue, 22 Jan 2002 10:17:20 +0100 (MET) Date: Tue, 22 Jan 2002 10:17:20 +0100 (MET) From: Geert Uytterhoeven To: Bryan Chua cc: Linux/MIPS Development Subject: Re: arch/mips/setup.c In-Reply-To: <3C4C8FE2.9090800@ayrnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1597 Lines: 52 On Mon, 21 Jan 2002, Bryan Chua wrote: > I recall a bunch of disussion about changing arch/mips/setup.c to > simplify adding vendor-specific platform code in setup_arch, but to date > nothing has come of it. So while this is a dramatic oversimplification > of the various proposals, how about this for now -- > > just a vendor-defined function "platform_setup (void)" and it is up to > the vendor to figure out what to do from there. > > -- bryan > > > Index: arch/mips/kernel/setup.c > =================================================================== > RCS file: /cvs/linux/arch/mips/kernel/setup.c,v > retrieving revision 1.96.2.3 > diff -u -r1.96.2.3 setup.c > --- arch/mips/kernel/setup.c 2001/12/26 23:27:02 1.96.2.3 > +++ arch/mips/kernel/setup.c 2002/01/21 22:55:35 > @@ -666,6 +666,7 @@ > void it8172_setup(void); > void swarm_setup(void); > void hp_setup(void); > + > void platform_setup (void); > > unsigned long bootmap_size; > unsigned long start_pfn, max_pfn, first_usable_pfn; > @@ -793,7 +794,8 @@ > break; > #endif > default: > - > panic("Unsupported architecture"); > + > platform_setup (); > + At first I thought: he's adding code after a call to panic(), but it turns out your mailer screwed your patch... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Jan 22 02:39:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MAdIN30114 for linux-mips-outgoing; Tue, 22 Jan 2002 02:39:18 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MAdAP30110; Tue, 22 Jan 2002 02:39:11 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0M9bft07359; Tue, 22 Jan 2002 09:37:42 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.2/8.11.2) id g0M9bfn01173; Tue, 22 Jan 2002 09:37:41 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15437.13028.496595.150427@gladsmuir.algor.co.uk> Date: Tue, 22 Jan 2002 09:37:40 +0000 To: drepper@redhat.com (Ulrich Drepper) Cc: "Kevin D. Kissell" , "Ralf Baechle" , "Mike Uhler" , , "H . J . Lu" Subject: Re: thread-ready ABIs In-Reply-To: References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 801 Lines: 25 Kevin asked: > > I'd very much appreciate it if someone would explain to me just > > what this register is used for, and why a register needs to be > > permantly allocated for this purpose. Ulrich Drepper (drepper@redhat.com) writes: > Simply look at the ABIs for some less-backward processors. Read the > thread-local storage section in the IA-64 ABI specification. Sometimes when you're busy it's understandable to respond with "RTFM". But to fail to provide a URL is not very respectful: other people reading this list are quite smart, they're just smart about different things from you. URL please. Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Jan 22 02:47:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MAll530301 for linux-mips-outgoing; Tue, 22 Jan 2002 02:47:47 -0800 Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MAlgP30298 for ; Tue, 22 Jan 2002 02:47:42 -0800 Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0M9lHk07065; Tue, 22 Jan 2002 10:47:17 +0100 (MET) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id g0M9lF607051; Tue, 22 Jan 2002 10:47:16 +0100 (MET) Received: from esk.fhg.de (host4-40 [192.168.4.40]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id KAA25158; Tue, 22 Jan 2002 10:47:14 +0100 (MET) Message-ID: <3C4D34D6.8D2166C0@esk.fhg.de> Date: Tue, 22 Jan 2002 10:45:58 +0100 From: Wolfgang Heidrich Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Bob McGhee , linux-mips@oss.sgi.com Subject: Re: Au1000/Linux-LSP References: <3.0.5.32.20020117153910.0364fda0@mailhost.alchemysemi.com> <3.0.5.32.20020121123823.035a4a30@mailhost.alchemysemi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1215 Lines: 39 Hi Bob, >Hi Wolfgang, >Have you been successful in getting the latest files? >Thanks, >Bob Yes, thank you very much, now I really have Beta6 and Beta5. But USB still doesn't work, I still get the message "usb.c: USB device not accepting new address=3 (error=-145)" everytime I plug in a USB device in J2. The same happens with J24. Only one thing changed (look my Email in the newsgroup from January 10): With Beta4-Version I always was getting the message >>> hub.c: USB new device connect on bus1/1, assigned device number 3 usb.c: USB device not accepting new address=3 (error=-145) <<< already during booting of the kernel, although there were no USB devices connected. But with Beta6-Version I just get it when plugging in a device after booting: >>> usb.c: USB device not accepting new address=2 (error=-145) usb.c: USB device not accepting new address=3 (error=-145) <<< The version of the LSP is now hhl-cross-mips_fp_le-lsp-alchemy-pb1000-2.4.2_hhl20-mb011105.2 The Pb1000 Board Serial Number is 5070. Maybe you can tell me that the reason is just a buggy Au1000, and perhaps USB is going to work, when we get our own Au1000-boards with newer versions of the Au1000. Thanks in advance -- Wolfgang From owner-linux-mips@oss.sgi.com Tue Jan 22 02:56:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MAuhX30495 for linux-mips-outgoing; Tue, 22 Jan 2002 02:56:43 -0800 Received: from nm.laser5.co.jp (nm.laser5.co.jp [202.221.8.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MAubP30491 for ; Tue, 22 Jan 2002 02:56:37 -0800 Received: from l5ac152.l5.laser5.co.jp (l5web.laser5.co.jp [202.221.8.76] (may be forged)) by nm.laser5.co.jp (8.10.0/3.7WVER2000041120) with ESMTP id g0MANnL05817; Tue, 22 Jan 2002 19:23:50 +0900 Date: Tue, 22 Jan 2002 18:56:33 +0900 Message-ID: From: Kunihiko IMAI To: Pete Popov Cc: Kunihiko IMAI , linux-mips Subject: Re: usb-problems with Au1000 In-Reply-To: <1011383349.18177.6.camel@zeus> References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> <1011383349.18177.6.camel@zeus> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) Emacs/20.7 (i386-laser5-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1629 Lines: 51 Hi, At 18 Jan 2002 11:49:09 -0800, Pete Popov wrote: > > > > > It's the comment that's wrong, not the code. The code works and has been > > > tested. Alchemy makes available the Linux Support Package (LSP) which > > > we did. That kernel has been tested with all peripherals so I would > > > recommend that you get that from them. Also,make sure your jumpers are > > > setup correctly (S4). > > > > In the source code: > > > > sys_clksrc |= ((4<<12) | (0<<11) | (0<<10)); > > > > (snip...) > > > > outl(sys_clksrc, CLOCK_SOURCE_CNTRL); > > > > This code sets the clock source of USB host controller is FREQ2. So > > FREQ5 clock source doesn't affect to USB host controller. > > After looking into it, both the comment and code are correct. From > include/asm-mips/au1000.h: > > #define FQ_CNTRL_1 0xB1900020 > #define FQ_CNTRL_2 0xB1900024 > > So FQ_CNTRL_1 corresponds to what is now sys_freqctrl0. In other words, > the update to the databook has not been incorporated into the Au1000 > files. The names of the registers were updated after I had done all the > core work. I need to update the code so the names of the registers > correspond to the latest Au1000 manual. Oh, I see. I'm sorry for my misunderstanding. Now the relations are like this: Au1000 manual Linux Header ----------------------------------- sys_freqctl0 FQ_CNTRL_1 sys_freqctl1 FQ_CNTRL_2 ----------------------------------- Then it's correct setup. Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Tue Jan 22 03:01:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MB1UP30749 for linux-mips-outgoing; Tue, 22 Jan 2002 03:01:30 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MB1JP30729; Tue, 22 Jan 2002 03:01:20 -0800 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0M9xst08507; Tue, 22 Jan 2002 09:59:54 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.2/8.11.2) id g0M9xrq01215; Tue, 22 Jan 2002 09:59:53 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15437.14361.918255.115877@gladsmuir.algor.co.uk> Date: Tue, 22 Jan 2002 09:59:53 +0000 To: "Kevin D. Kissell" Cc: "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , , "GNU libc hacker" , "H . J . Lu" Subject: Re: thread-ready ABIs In-Reply-To: <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1807 Lines: 42 Kevin, Since nobody seems to be prepared to essay a brief definition of a thread register, I'll make one up from first principles and maybe the experts will beat it into shape. Multiple threads in a Linux process share the same address space: code and data. A thread has its own unique stack, but since (by definition) it shares all its data with every other thread it has no identity - there is no thread-unique static data. That means it has no handle to acquire and manage any thread-specific variables. [Some threads purists would probably maintain that's a Good Thing: threads to them are like electrons to quantum physicists, indistinguishable by definition]. Linux is not noted for computer science purity; so an OS-maintained "thread identity" variable which is cheap to read in user space sounds a useful thing to have. A patient Linux expert (if any such are reading this list) might like to say what value is typically held (a pointer? an index?) and how it's used (my money's on "wrapped in an impenetrable macro"). In a more baroque (synonym for "less backward"?) architecture there are usually registers hanging about which no compiler or OS author has previously figured out any use for, which can be bent to this purpose. Unfortunately, MIPS original architects committed the grave error of making all the registers useful. I quite like the idea of putting the thread value at a known offset in low virtual memory, but I expect the kernel keeps virtual page 0 invalid to catch null pointers and that instructions start at the first boundary which doesn't create cache alias problems... -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Jan 22 04:48:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MCmmx00929 for linux-mips-outgoing; Tue, 22 Jan 2002 04:48:48 -0800 Received: from web15004.mail.bjs.yahoo.com (web15004.mail.bjs.yahoo.com [61.135.128.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MCmjP00926 for ; Tue, 22 Jan 2002 04:48:45 -0800 Message-ID: <20020122114834.41223.qmail@web15004.mail.bjs.yahoo.com> Received: from [218.76.10.233] by web15004.mail.bjs.yahoo.com via HTTP; Tue, 22 Jan 2002 19:48:34 CST Date: Tue, 22 Jan 2002 19:48:34 +0800 (CST) From: =?gb2312?q?Qingbo=20Wu?= Subject: what's the latest linux mips kernel version? To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 373 Lines: 15 Hi, all, What's the latest linux mips kernel version? Can it support 2.4.17? If someone knows, please help me. TIA Qingbo _________________________________________________________ Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡¡ª¡ª ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html From owner-linux-mips@oss.sgi.com Tue Jan 22 05:17:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MDHbZ01349 for linux-mips-outgoing; Tue, 22 Jan 2002 05:17:37 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MDHRP01345; Tue, 22 Jan 2002 05:17:27 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA00009; Tue, 22 Jan 2002 04:17:11 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA10358; Tue, 22 Jan 2002 04:17:09 -0800 (PST) Message-ID: <002001c1a33e$d9936560$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Dominic Sweetman" Cc: "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "GNU libc hacker" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 13:18:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3373 Lines: 74 > Since nobody seems to be prepared to essay a brief definition of a > thread register, I'll make one up from first principles and maybe the > experts will beat it into shape. Thank you, Dom, for trying to inject some civility into this debate. > Multiple threads in a Linux process share the same address space: code > and data. A thread has its own unique stack, but since (by > definition) it shares all its data with every other thread it has no > identity - there is no thread-unique static data. That means it has > no handle to acquire and manage any thread-specific variables. > > [Some threads purists would probably maintain that's a Good Thing: > threads to them are like electrons to quantum physicists, > indistinguishable by definition]. > > Linux is not noted for computer science purity; so an OS-maintained > "thread identity" variable which is cheap to read in user space sounds > a useful thing to have. > > A patient Linux expert (if any such are reading this list) might like > to say what value is typically held (a pointer? an index?) and how > it's used (my money's on "wrapped in an impenetrable macro"). > > In a more baroque (synonym for "less backward"?) architecture there > are usually registers hanging about which no compiler or OS author has > previously figured out any use for, which can be bent to this purpose. > Unfortunately, MIPS original architects committed the grave error of > making all the registers useful. > > I quite like the idea of putting the thread value at a known offset in > low virtual memory, but I expect the kernel keeps virtual page 0 > invalid to catch null pointers and that instructions start at the > first boundary which doesn't create cache alias problems... I think that the problem is complicated by the fact that there may be a many->many mapping of kernel threads (and CPUs) to user-land threads. In that case, no single low-memory address can be correct for all kernel threads. However, since every kernel thread should have its own stack segment, it would appear to me that having a variable "under" the stack would satisfy the need for per-kernel-thread storage at a knowable location. I suspect that there is a second-order problem in that the base stack address may differ for instances of the same binary launched under different circumstances. But I don't think that renders the problem impossible. One could have a global pointer, resolvable at link time, which could be set to SP+delta by whatever we call crt0 these days, and which should provide the required semantics. Each user thread startup or context switch could follow the global pointer to the kernel-thread-specific memory location which could be used as the pointer to the user-thread specific data area. Even with the double indirection, that strikes me as far more efficient than performing a system call on every thread startup to set up a magic value to be returned in a k-register (as some have suggested) and considerably less messy, technically and commercially, than pulling a register out of the ABI and rendering it useless for programs which happen not to be executing the threads library (as others have proposed). I await news as to why this is impossible and/or unacceptable, and I shall endeavor to modify or withdraw the suggestion accordingly. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 05:24:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MDOOU01501 for linux-mips-outgoing; Tue, 22 Jan 2002 05:24:24 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MDOKP01498 for ; Tue, 22 Jan 2002 05:24:20 -0800 Received: from resel.enst-bretagne.fr (root@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0MCO3506737; Tue, 22 Jan 2002 13:24:04 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.1/8.12.1/Debian -5) with ESMTP id g0MBXh0R011235; Tue, 22 Jan 2002 12:33:44 +0100 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.33 #1 (Debian)) id 16SzBP-0000WI-00; Tue, 22 Jan 2002 12:33:43 +0100 Date: Tue, 22 Jan 2002 12:33:43 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Gerald Champagne cc: linux-mips@oss.sgi.com Subject: Re: ide dma in latest cvs In-Reply-To: <3C4CA8C8.5010801@esstech.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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 944 Lines: 30 On Mon, 21 Jan 2002, Gerald Champagne wrote: > - blk_rq_map_sg() is called to build a list of blocks to be transferred. > It sets address = NULL for every entry (other fields like "page" are > set to valid values). > > - dma_cache_wback_inv(addr, size) is called for each block entry. This > routine crashes because the address parameter is always set to zero > when the routine is called. > > I see that this is part of the new bio code recently added. Should I expect > this code to work, or is it not yet working for the mips platform? I've encountered a similar problem on O2. You can probably fix it by adding the code for handling pages in pci_map_sg/pci_unmap_sg/pci_sync_sg. This is what I've done for ip32 and ip27: unsigned long address; if(sg->address) address = sg->address; else address = page_address(sg->page) + sg->offset; dma_cache_wback_inv(address, sg->length); regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Tue Jan 22 05:50:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MDoGn01852 for linux-mips-outgoing; Tue, 22 Jan 2002 05:50:16 -0800 Received: from scan2.fhg.de (scan2.fhg.de [153.96.1.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MDoAP01846 for ; Tue, 22 Jan 2002 05:50:10 -0800 Received: from scan2.fhg.de (localhost [127.0.0.1]) by scan2.fhg.de (8.11.1/8.11.1) with ESMTP id g0MArDT27611; Tue, 22 Jan 2002 11:53:13 +0100 (MET) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan2.fhg.de (8.11.1/8.11.1) with ESMTP id g0MArCC27602; Tue, 22 Jan 2002 11:53:12 +0100 (MET) Received: from esk.fhg.de (host4-40 [192.168.4.40]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id LAA27341; Tue, 22 Jan 2002 11:53:10 +0100 (MET) Message-ID: <3C4D444A.CB30AC60@esk.fhg.de> Date: Tue, 22 Jan 2002 11:51:54 +0100 From: Wolfgang Heidrich Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: linux-mips CC: bobm@alchemysemi.com Subject: Re: usb-problems with Au1000 References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> <1011383349.18177.6.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1271 Lines: 41 (I just repeat my last message with corrected subject) Hi Bob, >Hi Wolfgang, >Have you been successful in getting the latest files? >Thanks, >Bob Yes, thank you very much, now I really have Beta6 and Beta5. But USB still doesn't work, I still get the message "usb.c: USB device not accepting new address=3 (error=-145)" everytime I plug in a USB device in J2. The same happens with J24. Only one thing changed (look my Email in the newsgroup from January 10): With Beta4-Version I always was getting the message >>> hub.c: USB new device connect on bus1/1, assigned device number 3 usb.c: USB device not accepting new address=3 (error=-145) <<< already during booting of the kernel, although there were no USB devices connected. But with Beta6-Version I just get it when plugging in a device after booting: >>> usb.c: USB device not accepting new address=2 (error=-145) usb.c: USB device not accepting new address=3 (error=-145) <<< The version of the LSP is now hhl-cross-mips_fp_le-lsp-alchemy-pb1000-2.4.2_hhl20-mb011105.2 The Pb1000 Board Serial Number is 5070. Maybe you can tell me that the reason is just a buggy Au1000, and perhaps USB is going to work, when we get our own Au1000-boards with newer versions of the Au1000. Thanks in advance -- Wolfgang From owner-linux-mips@oss.sgi.com Tue Jan 22 07:25:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MFPvD10423 for linux-mips-outgoing; Tue, 22 Jan 2002 07:25:57 -0800 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MFPZP10418; Tue, 22 Jan 2002 07:25:36 -0800 Received: from mail2.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g0MEPVL05788; Tue, 22 Jan 2002 23:25:31 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g0MEPVH01056; Tue, 22 Jan 2002 23:25:31 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g0MEPUA01039; Tue, 22 Jan 2002 23:25:30 +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 XAA10476; Tue, 22 Jan 2002 23:30: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 XAA16961; Tue, 22 Jan 2002 23:25:29 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0MEPTJ05605; Tue, 22 Jan 2002 23:25:29 +0900 (JST) To: aj@suse.de, hjl@lucon.org, ralf@oss.sgi.com, kevink@mips.com Cc: linux-mips@oss.sgi.com Subject: patches for test-and-set without ll/sc (Re: thread-ready ABIs) X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020122232529V.machida@sm.sony.co.jp> Date: Tue, 22 Jan 2002 23:25:29 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4758 Lines: 154 Hi, all. Please review an attached patch set and if it is ok, please megre into the cvs trees. Kevin, please let us know about "k1 semaphore" you said. I want to know we can merge those functions or not. Technical discussions are welcome. ------------ From: Machida Hiroyuki To: kevink@mips.com, hjl@lucon.org, drepper@redhat.com, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Date: Tue, 22 Jan 2002 15:27:44 +0900 X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Hi, all. As I said at 1/20, I'll post the short descriptions about our test-and-set implementation and patches for linux-2.4.17 and glibc-2.2.3. ===================================================================== We implemented the fast and safe user level test and set function for single MIPS CPUs. You don't need to use LL/SC and sysmips() with this method. (excatly say, sysmips() is needed for initializing, but once initialized, we don't use it any more). NOTE: We assume the single processor to use this method, You can not use our method for SMP. WHAT'S CHANGED: * kernel side change #1 Set specific constant (we call this value "_TST_ACCESS_MAGIC") to K1 on every transition from kernel mode to user mode. This means you can use k1 in any exception handler as same as before our method introduced, except that you have to do "li k1, _TST_ACCESS_MAGIC" at the very previous of "eret" or "j k0; "rfe" . We choose the value of _TST_ACCESS_MAGIC, to cause SEGV fault when you use this value as address. * kernel side change #2 On memory fault hander, kernel check write-access to _TST_ACCESS_MAGIC from fixed address range of user process. (EPC is in _TST_START_MAGIC to _TST_START_MAGIC+PAGE_SIZE) If the condtion is met, kernel restart user process from _TST_START_MAGIC. * kernel side change #3 We add pseudo device driver "/dev/tst" to provide test_and_set procedure at the same virtual address (_TST_START_MAGIC) to any user process. _TST_START_MAGIC: .set noreorder 0: move k1, a0 lw v0, 0(a0) nop bnez v0, 1f nop bne k1, a0, 0b nop .... sw a1, 0(k1) 1: jr ra nop * glibc change: We implement test_and_set(addr, val) as follows, Do mmap /dev/tst to _TST_START_MAGIC, if not yet mapped. call _TST_START_MAGIC(addr, val) If we can't open /dev/tst then, use sysmips() as final resort. HOW TO WORK: If no context-switch is occured in _TST_START_MAGIC() procedure, nobody changes the mutex var. It's no problem. So you can do _TST_START_MAGIC() porcedure as you see. But, if some context-swtich is occured in _TST_START_MAGIC() somebody chages the mutex var. It's a problem. We must not store to the mutex var, if context-swtich is occured at . In our method, kernel sets k1 as _TST_ACCESS_MAGIC on transition to user mode. "sw a1, 0(k1)" causes SEGV-fault if context-swtich is occured at . The SEGV-fault hander catch this situation, restart user process from top of _TST_START_MAGIC(). PATCHES: I attached three patches; 1. patch for linux kernel 2.4.17 (SourceForge tree) 2. patch for glibc 2.2.3 (of HHL 2.0) 3. patch for linuxthread 2.2.3 (of HHL 2.0) To test those patches; you must turn on CONFIG_MIPS_TST_DEV on config kernel, have working version of sysmips(MIPS_ATOMIC_SET), update kernel headers before building glibc and make /dev/tst device ("mknod c /dev/tst 123 0", 123 is a tempoary major number for this device) I'v tested at ITE board. On testing, I'v made lettle changes into "drivers/char/Config.in" and "arch/mips/kernel/sysmip.c" to enable CONFIG_MIPS_TST_DEV and to work sysmips() at ITE board. Those chages are not included in the patch set. =================================================================== You can find the paper about it in http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf (sorry in japanese only) The abstract of the paper is following; The Implementation of user level test-and-set on PS2 Linux In the multi-thread environment like Linux, a fast user-level mutual exclusion mechanism is strongly required. But MIPS chips designed for embedded and single processor, like the Emotion Engine, have no atomic test-and-set instruction. We implemented the fast user-level mutual exclusion without invoking system-call and its costs, on the PS2 Linux. This method utilizes the memory protection facility of Operating System, to detect preemption and nullify the operation. In this paper, we present the method and its evaluation. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Tue Jan 22 08:22:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MGM7k12875 for linux-mips-outgoing; Tue, 22 Jan 2002 08:22:07 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MGLpP12872; Tue, 22 Jan 2002 08:21:52 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16T2jo-00032O-00; Tue, 22 Jan 2002 10:21:28 -0500 Date: Tue, 22 Jan 2002 10:21:28 -0500 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , GNU libc hacker , "H . J . Lu" Subject: Re: thread-ready ABIs Message-ID: <20020122102128.A11455@nevyn.them.org> References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002001c1a33e$d9936560$0deca8c0@Ulysses> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1461 Lines: 29 On Tue, Jan 22, 2002 at 01:18:03PM +0100, Kevin D. Kissell wrote: > I think that the problem is complicated by the fact that > there may be a many->many mapping of kernel threads > (and CPUs) to user-land threads. In that case, no single > low-memory address can be correct for all kernel threads. > However, since every kernel thread should have its own > stack segment, it would appear to me that having a > variable "under" the stack would satisfy the need for > per-kernel-thread storage at a knowable location. > I suspect that there is a second-order problem in that > the base stack address may differ for instances of > the same binary launched under different circumstances. > But I don't think that renders the problem impossible. > One could have a global pointer, resolvable at link > time, which could be set to SP+delta by whatever > we call crt0 these days, and which should provide the > required semantics. Each user thread startup or Resolvable at link time and set by crt0 seem to be mutually exclusive... but perhaps I'm misunderstanding you. In any case, that's not the real problem. Linux user threads do not have true separate stacks. They share their _entire_ address space; the stacks are all bounded (default is 2MB) and grouped together at the top of the available memory region. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jan 22 08:46:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MGkI913450 for linux-mips-outgoing; Tue, 22 Jan 2002 08:46:18 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MGjKP13423; Tue, 22 Jan 2002 08:45:20 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g0MFiva23526; Tue, 22 Jan 2002 15:44:58 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15437.35062.770932.705864@gladsmuir.algor.co.uk> Date: Tue, 22 Jan 2002 15:44:54 +0000 To: Daniel Jacobowitz Cc: "Kevin D. Kissell" , Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs In-Reply-To: <20020122102128.A11455@nevyn.them.org> References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1213 Lines: 30 > In any case, that's not the real problem. Linux user threads do not > have true separate stacks. They share their _entire_ address space; > the stacks are all bounded (default is 2MB) and grouped together at > the top of the available memory region. Quite. A comment by Kevin reminded me of the real constraint (which the experts probably take for granted): this system is supposed to work on shared-memory multiprocessors and multithreaded CPUs. In both cases two or more threads within an address space can be active simultaneously. On a multithreaded CPU (in particular) there's only one TLB, so memory (including any memory specially handled by the kernel) is all held in common. The *only* thing available to a user privilege program which distinguishes the threads is the CPU register set. (Well, and the stack, which is a difference inherited from the value in the stack pointer register. But the stack pointer is not really going to help much to return a thread-characteristic pointer or ID.) So MIPS really do need to figure out which register can be freed up. Well, at least I know why now. Hope the rest of you aren't too bored! Dominic Sweetman Algorithmics Ltd http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Jan 22 09:05:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MH5WO14122 for linux-mips-outgoing; Tue, 22 Jan 2002 09:05:32 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MH5MP14113; Tue, 22 Jan 2002 09:05:22 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA02431; Tue, 22 Jan 2002 08:05:12 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id IAA17777; Tue, 22 Jan 2002 08:05:10 -0800 (PST) Message-ID: <007601c1a35e$b3e3f940$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "GNU libc hacker" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 17:05:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2798 Lines: 60 Tue, Jan 22, 2002 at 01:18:03PM +0100, Kevin D. Kissell wrote: > > I think that the problem is complicated by the fact that > > there may be a many->many mapping of kernel threads > > (and CPUs) to user-land threads. In that case, no single > > low-memory address can be correct for all kernel threads. > > However, since every kernel thread should have its own > > stack segment, it would appear to me that having a > > variable "under" the stack would satisfy the need for > > per-kernel-thread storage at a knowable location. > > I suspect that there is a second-order problem in that > > the base stack address may differ for instances of > > the same binary launched under different circumstances. > > But I don't think that renders the problem impossible. > > One could have a global pointer, resolvable at link > > time, which could be set to SP+delta by whatever > > we call crt0 these days, and which should provide the > > required semantics. Each user thread startup or > > Resolvable at link time and set by crt0 seem to be mutually > exclusive... but perhaps I'm misunderstanding you. You are. The *address* of the pointer to the pointer can be resolved at link time. The *value* of the pointer to the pointer is set by crt0 (if stack origins are not intrinsically fixed at link time - if they are, the indirection is not necessary). > In any case, that's not the real problem. Linux user threads do not > have true separate stacks. They share their _entire_ address space; > the stacks are all bounded (default is 2MB) and grouped together at the > top of the available memory region. Exactly. But if all we all we are worried about is thread specific data for user threads multiplexed on exactly one kernel thread, we could probably get by with a simple global variable for the thread pointer for the current user thread running in the process. It's the case of multiple user threads running within multiple *kernel* threads (e.g. created by fork()) that complicates things, and makes people want to use a register or other storage resource associated with exactly one kernel thread (and CPU). A permanently assigned register, as we have seen, creates various complications, so I'm looking for another kernel-thread-specific resource, of which I believe the stack region is the best candidate. Each process/task/program would have a single global variable, which points to a common address in the stack region of each kernel thread, which is used to store the address of the user-thread-specific data of the user thread executing on that kernel thread. Of course, I still haven't seen an informed description of the actual problem that Ulrich and H.J. are trying to solve, so it may in fact be simpler (or more complex). Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 09:34:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MHYR014829 for linux-mips-outgoing; Tue, 22 Jan 2002 09:34:27 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MHYFP14826; Tue, 22 Jan 2002 09:34:15 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16T3sK-0003jo-00; Tue, 22 Jan 2002 11:34:20 -0500 Date: Tue, 22 Jan 2002 11:34:20 -0500 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs Message-ID: <20020122113420.A14284@nevyn.them.org> References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007601c1a35e$b3e3f940$0deca8c0@Ulysses> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1857 Lines: 35 On Tue, Jan 22, 2002 at 05:05:45PM +0100, Kevin D. Kissell wrote: > > In any case, that's not the real problem. Linux user threads do not > > have true separate stacks. They share their _entire_ address space; > > the stacks are all bounded (default is 2MB) and grouped together at the > > top of the available memory region. > > Exactly. But if all we all we are worried about is thread > specific data for user threads multiplexed on exactly > one kernel thread, we could probably get by with a > simple global variable for the thread pointer for the > current user thread running in the process. It's the > case of multiple user threads running within multiple > *kernel* threads (e.g. created by fork()) that complicates > things, and makes people want to use a register > or other storage resource associated with exactly one > kernel thread (and CPU). A permanently assigned > register, as we have seen, creates various complications, > so I'm looking for another kernel-thread-specific resource, > of which I believe the stack region is the best candidate. > Each process/task/program would have a single global > variable, which points to a common address in the > stack region of each kernel thread, which is used > to store the address of the user-thread-specific > data of the user thread executing on that kernel thread. Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping of kernel threads to user threads. All the kernel threads, and thus all the user threads, share the same memory region - including the stack region. Their stacks are differentiated solely by different values in the stack pointer register. Thus I don't think what you're suggesting is possible. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jan 22 10:07:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MI7pY19505 for linux-mips-outgoing; Tue, 22 Jan 2002 10:07:51 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MI7hP19501; Tue, 22 Jan 2002 10:07:43 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA03284; Tue, 22 Jan 2002 09:07:33 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA21263; Tue, 22 Jan 2002 09:07:31 -0800 (PST) Message-ID: <00c001c1a367$69c10160$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 18:08:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1690 Lines: 37 > Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping > of kernel threads to user threads. All the kernel threads, and thus > all the user threads, share the same memory region - including the > stack region. Their stacks are differentiated solely by different > values in the stack pointer register. Thus I don't think what you're > suggesting is possible. I don't see how fork() semantics can be preserved unless the stack regions are replicated (copy-on-write) on a fork(). Under ATT and BSD Unix (which is where I did most of my kernel hacking in the old days) that was the *only* way to get a new kernel thread, so it was "obvious" that my proposed hack would work. Linux does have the clone() function as well, and if LinuxThreads are implemented in terms of clone(foo, stakptr, CLONE_VM, arg), you are correct, the proposed scheme would not work without modification. One such modification would be to have each newly cloned thread explicitly allocate and map a 1-page VM region that is private to the kernel thread, and bound to a known virtual address that is common to all threads within the task. That known virtual address would take the place of the below-the-stack storage location I described earlier. The same algorithm would apply - one has a globally known address that maps to different storage per-thread, which can be used to store the address of the (globally visible) per-thread information. The set-up is slightly more complicated and heavyweight than the fork()-based model I suggested, but one could in principle eliminate one level of indirection at on the lookups at run-time. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 10:13:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIDfW19786 for linux-mips-outgoing; Tue, 22 Jan 2002 10:13:41 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIDUP19779; Tue, 22 Jan 2002 10:13:30 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA03467; Tue, 22 Jan 2002 09:13:20 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA21556; Tue, 22 Jan 2002 09:13:18 -0800 (PST) Message-ID: <005301c1a368$87d27ed0$10eca8c0@grendel> From: "Kevin D. Kissell" To: , , , "Machida Hiroyuki" Cc: References: <20020122232529V.machida@sm.sony.co.jp> Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Tue, 22 Jan 2002 18:16:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2693 Lines: 77 > Kevin, please let us know about "k1 semaphore" you said. > I want to know we can merge those functions or not. My proposal is for a very simple emulation of ll/sc for CPUs that implement the MIPS II "branch likely" instructions but which do not have a functioning LL/SC. That means that it is *not* a solution for R3000 processor such as those found in old DEC and SGI platforms. LL/SC is also part of MIPS II, but several manufacturers seem to have done MIPS II/III processors where LL/SC is not fully functional. This hack could thus be workable both for the TX59 family and the Vr4100 family. The idea leverages off the fact that a branch likely instruction performs a kind of conditional execution. The instruction in the delay slot is executed only if the branch is taken. This can be used to synthesize a conditional store. The user level code for a simple atomic increment, for example, would look something like this: _atomic_inc_nollsc: .set noreorder li t0,MAGIC_COOKIE Retry: mov k1,t0 lw t1,0(a0) addiu t1,t1,1 BEQL k1,t0,done sw t1,0(a0) b Retry nop done jr ra nop If - and this is an important consideration - IF the value of MAGIC_COOKIE can be determined such that it can *never* be the residue value left in k1 by a kernel exception handler, *no* kernel modifications are required for this to work identically to LL/SC! If, for example, k1 always ends up containing either a Status, EPC, or EntryLo value after an ERET, something like 0xffdadaff could be used as a MAGIC_COOKIE value, as it is not a sane value for any of the above. You will get some number of needless retries in this scheme to the extent that there are TLB misses on the load and on the instructions themselves if the routine crosses a page boundary. You would get those same retries using LL/SC. You could eliminate those retries by preserving the appropriate k-register in the TLB refill handler, but I really doubt that it would be worthwhile. If there is any doubt about the possibility of the MAGIC_COOKIE value being left in k1 (or k0, which could also be used as the "LL flop" if its behavior is more easily constrained), an explicit operation at the end of the fault handlers could be used to clear the register. That would still be far less complex and intrusive than the mods that you suggest below. I have not implemented this scheme under Linux, but we have tried it with success under other OSes. It should in principle be SMP safe. > Technical discussions are welcome. Well, there you have one! Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 10:13:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIDer19785 for linux-mips-outgoing; Tue, 22 Jan 2002 10:13:40 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIDTP19777; Tue, 22 Jan 2002 10:13:29 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16T4UE-0004C5-00; Tue, 22 Jan 2002 12:13:30 -0500 Date: Tue, 22 Jan 2002 12:13:30 -0500 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs Message-ID: <20020122121330.A16110@nevyn.them.org> References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c001c1a367$69c10160$0deca8c0@Ulysses> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1292 Lines: 26 On Tue, Jan 22, 2002 at 06:08:12PM +0100, Kevin D. Kissell wrote: > > Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping > > of kernel threads to user threads. All the kernel threads, and thus > > all the user threads, share the same memory region - including the > > stack region. Their stacks are differentiated solely by different > > values in the stack pointer register. Thus I don't think what you're > > suggesting is possible. > > I don't see how fork() semantics can be preserved unless > the stack regions are replicated (copy-on-write) on a fork(). > Under ATT and BSD Unix (which is where I did most of > my kernel hacking in the old days) that was the *only* > way to get a new kernel thread, so it was "obvious" > that my proposed hack would work. Linux does have > the clone() function as well, and if LinuxThreads are > implemented in terms of clone(foo, stakptr, CLONE_VM, arg), > you are correct, the proposed scheme would not work > without modification. Which it is. Fork shares no memory regions; vfork/clone share all memory regions. AFAIK there is no share-heap-but-not-stack option in Linux. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jan 22 10:32:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIWEs20474 for linux-mips-outgoing; Tue, 22 Jan 2002 10:32:14 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIW8P20470 for ; Tue, 22 Jan 2002 10:32:08 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0MHUAB24458; Tue, 22 Jan 2002 09:30:10 -0800 Subject: Re: usb-problems with Au1000 From: Pete Popov To: Kunihiko IMAI Cc: linux-mips In-Reply-To: References: <3B7DA3A3.8010000@pacbell.net> <3C3DD208.45B5BC29@esk.fhg.de> <1011294123.4550.58.camel@zeus> <1011383349.18177.6.camel@zeus> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 09:33:29 -0800 Message-Id: <1011720809.28944.149.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1694 Lines: 52 On Tue, 2002-01-22 at 01:56, Kunihiko IMAI wrote: > Hi, > > At 18 Jan 2002 11:49:09 -0800, > Pete Popov wrote: > > > > > > > > It's the comment that's wrong, not the code. The code works and has been > > > > tested. Alchemy makes available the Linux Support Package (LSP) which > > > > we did. That kernel has been tested with all peripherals so I would > > > > recommend that you get that from them. Also,make sure your jumpers are > > > > setup correctly (S4). > > > > > > In the source code: > > > > > > sys_clksrc |= ((4<<12) | (0<<11) | (0<<10)); > > > > > > (snip...) > > > > > > outl(sys_clksrc, CLOCK_SOURCE_CNTRL); > > > > > > This code sets the clock source of USB host controller is FREQ2. So > > > FREQ5 clock source doesn't affect to USB host controller. > > > > After looking into it, both the comment and code are correct. From > > include/asm-mips/au1000.h: > > > > #define FQ_CNTRL_1 0xB1900020 > > #define FQ_CNTRL_2 0xB1900024 > > > > So FQ_CNTRL_1 corresponds to what is now sys_freqctrl0. In other words, > > the update to the databook has not been incorporated into the Au1000 > > files. The names of the registers were updated after I had done all the > > core work. I need to update the code so the names of the registers > > correspond to the latest Au1000 manual. > > Oh, I see. I'm sorry for my misunderstanding. It's OK, one of these days I'll have time to rename all the registers to match the last data book. Pete > Now the relations are like this: > > Au1000 manual Linux Header > ----------------------------------- > sys_freqctl0 FQ_CNTRL_1 > sys_freqctl1 FQ_CNTRL_2 > ----------------------------------- From owner-linux-mips@oss.sgi.com Tue Jan 22 10:34:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIY7M22067 for linux-mips-outgoing; Tue, 22 Jan 2002 10:34:07 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIY0P22064; Tue, 22 Jan 2002 10:34:00 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA03943; Tue, 22 Jan 2002 09:33:51 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA22491; Tue, 22 Jan 2002 09:33:48 -0800 (PST) Message-ID: <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> <20020122121330.A16110@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 18:34:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1575 Lines: 40 > > > Perhaps I'm mangling terminology. LinuxThreads is a one-to-one mapping > > > of kernel threads to user threads. All the kernel threads, and thus > > > all the user threads, share the same memory region - including the > > > stack region. Their stacks are differentiated solely by different > > > values in the stack pointer register. Thus I don't think what you're > > > suggesting is possible. > > > > I don't see how fork() semantics can be preserved unless > > the stack regions are replicated (copy-on-write) on a fork(). > > Under ATT and BSD Unix (which is where I did most of > > my kernel hacking in the old days) that was the *only* > > way to get a new kernel thread, so it was "obvious" > > that my proposed hack would work. Linux does have > > the clone() function as well, and if LinuxThreads are > > implemented in terms of clone(foo, stakptr, CLONE_VM, arg), > > you are correct, the proposed scheme would not work > > without modification. > > Which it is. Fork shares no memory regions; Oh, come on. If it doesn't share text regions, it's completely brain dead! > vfork/clone share all memory regions. AFAIK there is no > share-heap-but-not-stack option in Linux. Yeah. Not that it matters, but I had misremebered there being finer grained control than that on clone(). Probably confused it with something that someone overlaid on Mach once upon a time... Anyway, do you see a hole or a serious performance problem with my modified proposal (explicit mmap() to create the necessary storage)? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 10:41:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIfYM24021 for linux-mips-outgoing; Tue, 22 Jan 2002 10:41:34 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIfSP24018; Tue, 22 Jan 2002 10:41:28 -0800 Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA20568; Tue, 22 Jan 2002 09:41:14 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g0MHfDc28062; Tue, 22 Jan 2002 09:41:13 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Dominic Sweetman Cc: "Kevin D. Kissell" , "Ralf Baechle" , "Mike Uhler" , , "H . J . Lu" Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.13028.496595.150427@gladsmuir.algor.co.uk> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 22 Jan 2002 09:41:12 -0800 In-Reply-To: <15437.13028.496595.150427@gladsmuir.algor.co.uk> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 646 Lines: 17 Dominic Sweetman writes: > Sometimes when you're busy it's understandable to respond with "RTFM". > But to fail to provide a URL is not very respectful: other people > reading this list are quite smart, they're just smart about different > things from you. A simple Google search would have turned up http://developer.intel.com/design/itanium/downloads/24537003.pdf as the first choice. Section 7.5. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Tue Jan 22 10:47:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIlNn26857 for linux-mips-outgoing; Tue, 22 Jan 2002 10:47:23 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIlFP26852; Tue, 22 Jan 2002 10:47:15 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA04274; Tue, 22 Jan 2002 09:47:05 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA23027; Tue, 22 Jan 2002 09:47:02 -0800 (PST) Message-ID: <00d801c1a36c$ef0719e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> <20020122121330.A16110@nevyn.them.org> <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> <20020122123743.A17232@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 18:47:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by mx.mips.com id JAA04274 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0MIlFP26853 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1934 Lines: 47 > > Anyway, do you see a hole or a serious performance > > problem with my modified proposal (explicit mmap() > > to create the necessary storage)? > > Same problem as with clone. I recommend the clone manpage; it says: > > CLONE_VM > If CLONE_VM is set, the calling process and the child processes run in the same > memory space. In particular, memory writes performed by the calling process or > by the child process are also visible in the other process. Moreover, any mem­ > ory mapping or unmapping performed with mmap(2) or munmap(2) by the child or > calling process also affects the other process. > > If CLONE_VM is not set, the child process runs in a separate copy of the memory > space of the calling process at the time of clone. Memory writes or file map­ > pings/unmappings performed by one of the processes do not affect the other, as > with fork(2). > > That is, if any memory OR MAPPING is shared, they all are. Daniel, you didn't read my message. The per-thread memory would be allocated *after* the clone() in pthread_create(). More specifically, pthread_create() would set it up so that the function passed to clone for invocation was in fact a wrapper that sets up the memory and thread data before invoking the application function passed to pthread_create(). Now, if the idea is that the clone() system call is supposed to cause the thread to be born, like Athena, full-grown from the head of Zeus, with the analog to the thread register already set up when it leaves the kernel, then I would be inclined to concede that we need to change the ABI, the kernel, and compilers, and I would ask just what we get for our trouble. But if we are permitted the pthreads abstraction, there's a lot that can be done transparently. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 10:48:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIm3M26929 for linux-mips-outgoing; Tue, 22 Jan 2002 10:48:03 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIltP26923; Tue, 22 Jan 2002 10:47:55 -0800 Received: from nevyn.them.org (NEVYN.RES.CMU.EDU [128.2.145.6]) 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 JAA05263; Tue, 22 Jan 2002 09:46:38 -0800 (PST) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16T4rf-0004UZ-00; Tue, 22 Jan 2002 12:37:43 -0500 Date: Tue, 22 Jan 2002 12:37:43 -0500 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs Message-ID: <20020122123743.A17232@nevyn.them.org> References: <20020118101908.C23887@lucon.org><01b801c1a081$3f6518e0$0deca8c0@Ulysses><20020119162415.B31028@dea.linux-mips.net><01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> <20020122121330.A16110@nevyn.them.org> <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> User-Agent: Mutt/1.3.23i X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id JAA05263 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0MIltP26924 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2931 Lines: 60 On Tue, Jan 22, 2002 at 06:34:42PM +0100, Kevin D. Kissell wrote: > > > > Perhaps I'm mangling terminology. LinuxThreads is a one-to-one > mapping > > > > of kernel threads to user threads. All the kernel threads, and thus > > > > all the user threads, share the same memory region - including the > > > > stack region. Their stacks are differentiated solely by different > > > > values in the stack pointer register. Thus I don't think what you're > > > > suggesting is possible. > > > > > > I don't see how fork() semantics can be preserved unless > > > the stack regions are replicated (copy-on-write) on a fork(). > > > Under ATT and BSD Unix (which is where I did most of > > > my kernel hacking in the old days) that was the *only* > > > way to get a new kernel thread, so it was "obvious" > > > that my proposed hack would work. Linux does have > > > the clone() function as well, and if LinuxThreads are > > > implemented in terms of clone(foo, stakptr, CLONE_VM, arg), > > > you are correct, the proposed scheme would not work > > > without modification. > > > > Which it is. Fork shares no memory regions; > > Oh, come on. If it doesn't share text regions, it's completely > brain dead! They aren't shared, they're duplicated. They use the same physical memory, and the same virtual addresses, but the page table entries are separate. That's what I meant. No copy of the page table is common on fork(), AFAIK. > > vfork/clone share all memory regions. AFAIK there is no > > share-heap-but-not-stack option in Linux. > > Yeah. Not that it matters, but I had misremebered there being > finer grained control than that on clone(). Probably confused > it with something that someone overlaid on Mach once upon a time... > > Anyway, do you see a hole or a serious performance > problem with my modified proposal (explicit mmap() > to create the necessary storage)? Same problem as with clone. I recommend the clone manpage; it says: CLONE_VM If CLONE_VM is set, the calling process and the child processes run in the same memory space. In particular, memory writes performed by the calling process or by the child process are also visible in the other process. Moreover, any mem­ ory mapping or unmapping performed with mmap(2) or munmap(2) by the child or calling process also affects the other process. If CLONE_VM is not set, the child process runs in a separate copy of the memory space of the calling process at the time of clone. Memory writes or file map­ pings/unmappings performed by one of the processes do not affect the other, as with fork(2). That is, if any memory OR MAPPING is shared, they all are. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jan 22 10:57:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIvwC27200 for linux-mips-outgoing; Tue, 22 Jan 2002 10:57:58 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIvnP27197; Tue, 22 Jan 2002 10:57:49 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16T5B5-0004j3-00; Tue, 22 Jan 2002 12:57:47 -0500 Date: Tue, 22 Jan 2002 12:57:47 -0500 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: Dominic Sweetman , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs Message-ID: <20020122125747.A18040@nevyn.them.org> References: <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> <20020122121330.A16110@nevyn.them.org> <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> <20020122123743.A17232@nevyn.them.org> <00d801c1a36c$ef0719e0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00d801c1a36c$ef0719e0$0deca8c0@Ulysses> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2795 Lines: 59 On Tue, Jan 22, 2002 at 06:47:55PM +0100, Kevin D. Kissell wrote: > > > Anyway, do you see a hole or a serious performance > > > problem with my modified proposal (explicit mmap() > > > to create the necessary storage)? > > > > Same problem as with clone. I recommend the clone manpage; it says: > > > > CLONE_VM > > If CLONE_VM is set, the calling process and the child > processes run in the same > > memory space. In particular, memory writes performed by the > calling process or > > by the child process are also visible in the other process. > Moreover, any mem­ > > ory mapping or unmapping performed with mmap(2) or munmap(2) > by the child or > > calling process also affects the other process. > > > > If CLONE_VM is not set, the child process runs in a separate > copy of the memory > > space of the calling process at the time of clone. Memory > writes or file map­ > > pings/unmappings performed by one of the processes do not > affect the other, as > > with fork(2). > > > > That is, if any memory OR MAPPING is shared, they all are. > > Daniel, you didn't read my message. The per-thread memory > would be allocated *after* the clone() in pthread_create(). > More specifically, pthread_create() would set it up so that > the function passed to clone for invocation was in fact a > wrapper that sets up the memory and thread data before > invoking the application function passed to pthread_create(). > > Now, if the idea is that the clone() system call is supposed > to cause the thread to be born, like Athena, full-grown from > the head of Zeus, with the analog to the thread register > already set up when it leaves the kernel, then I would be inclined > to concede that we need to change the ABI, the kernel, and > compilers, and I would ask just what we get for our trouble. > But if we are permitted the pthreads abstraction, there's a > lot that can be done transparently. No, you didn't read my manpage quote, Kevin. Or we're just talking past each other. The problem is not that existing mappings are shared, but that "any memory mapping or unmapping performed with mmap(2) or munmap(2) by the child or calling process also affects the other process". That is, if the child maps some private storage, the parent will see it too. Thus we can not use the private storage as a thread-local storage unless we already have some thread-local way to say where it is for this particular thread, and we're back where we started. Does that make sense, or am I missing your objection? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jan 22 11:08:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MJ8MS27516 for linux-mips-outgoing; Tue, 22 Jan 2002 11:08:22 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MJ8JP27512 for ; Tue, 22 Jan 2002 11:08:19 -0800 Received: (qmail 18247 invoked from network); 22 Jan 2002 18:08:16 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 22 Jan 2002 18:08:16 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16T5LD-0005OL-00; Tue, 22 Jan 2002 11:08:15 -0700 Date: Tue, 22 Jan 2002 11:08:15 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: "Kevin D. Kissell" cc: linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) In-Reply-To: <005301c1a368$87d27ed0$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 559 Lines: 17 On Tue, 22 Jan 2002, Kevin D. Kissell wrote: > The idea leverages off the fact that a branch likely > instruction performs a kind of conditional execution. > The instruction in the delay slot is executed only if > the branch is taken. This can be used to synthesize > a conditional store. The user level code for a simple > atomic increment, for example, would look something > like this: Hmm, could you use this to take the race out of the kernel wait loop too? Ie use current->need_resched as the test and 'wait' as the conditional operation. Jason From owner-linux-mips@oss.sgi.com Tue Jan 22 11:17:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MJHe027749 for linux-mips-outgoing; Tue, 22 Jan 2002 11:17:40 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MJHVP27746; Tue, 22 Jan 2002 11:17:31 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA04922; Tue, 22 Jan 2002 10:17:20 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA24186; Tue, 22 Jan 2002 10:17:17 -0800 (PST) Message-ID: <00e401c1a371$28a023a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <007601c1a35e$b3e3f940$0deca8c0@Ulysses> <20020122113420.A14284@nevyn.them.org> <00c001c1a367$69c10160$0deca8c0@Ulysses> <20020122121330.A16110@nevyn.them.org> <00cc01c1a36b$15cbf200$0deca8c0@Ulysses> <20020122123743.A17232@nevyn.them.org> <00d801c1a36c$ef0719e0$0deca8c0@Ulysses> <20020122125747.A18040@nevyn.them.org> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 19:18:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1583 Lines: 35 > No, you didn't read my manpage quote, Kevin. Or we're just talking > past each other. The problem is not that existing mappings are shared, > but that "any memory mapping or unmapping performed with mmap(2) > or munmap(2) by the child or calling process also affects the other > process". That is, if the child maps some private storage, the parent > will see it too. Thus we can not use the private storage as a > thread-local storage unless we already have some thread-local way to > say where it is for this particular thread, and we're back where we > started. > > Does that make sense, or am I missing your objection? It doen't necessarily make *sense*, in that it seems to be a pretty crippled memory model ;-) but I do see your objection. Sorry to have seemed dense, I'm doing several things at once on a couple of screens this evening and reading too quickly. I had misread that as underscoring that the effects of mmaps() *prior* to the clone() were inherited. Feh. Well, we aren't likely to have the luxury of fixing the underlying design of pthreads for Linux to use a fork()-based model with explicit sharing (which has its own problems, of course), so we may well be looking at ABI abuse. I was really, really, hoping to avoid that, in that gcc/Linux is far from the only user (and commercially speaking, far from being the most important user) of the ABI, and any change that breaks backward compatibility and cross-platform compatibility would be a Very Bad Thing. More on this later, and thanks for your (civil) comments, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 11:19:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MJJEw27813 for linux-mips-outgoing; Tue, 22 Jan 2002 11:19:14 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MJJBP27810 for ; Tue, 22 Jan 2002 11:19:11 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA04959; Tue, 22 Jan 2002 10:19:01 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA24246; Tue, 22 Jan 2002 10:19:01 -0800 (PST) Message-ID: <00e801c1a371$65c92ec0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jason Gunthorpe" Cc: References: Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Tue, 22 Jan 2002 19:19:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 705 Lines: 19 > On Tue, 22 Jan 2002, Kevin D. Kissell wrote: > > > The idea leverages off the fact that a branch likely > > instruction performs a kind of conditional execution. > > The instruction in the delay slot is executed only if > > the branch is taken. This can be used to synthesize > > a conditional store. The user level code for a simple > > atomic increment, for example, would look something > > like this: > > Hmm, could you use this to take the race out of the kernel wait loop > too? Ie use current->need_resched as the test and 'wait' as the > conditional operation. It's quite possible. But remember that it won't work on an R3000. R39xx yes, but not an R3K "classic". Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 12:00:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MK0uc28460 for linux-mips-outgoing; Tue, 22 Jan 2002 12:00:56 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MK0pP28457 for ; Tue, 22 Jan 2002 12:00:52 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0MIxEB30419; Tue, 22 Jan 2002 10:59:14 -0800 Message-ID: <3C4DB6DA.7F3E7386@mvista.com> Date: Tue, 22 Jan 2002 11:00:42 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gerald Champagne CC: linux-mips@oss.sgi.com Subject: Re: ide dma in latest cvs References: <3C4CA8C8.5010801@esstech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 751 Lines: 21 Gerald Champagne wrote: > > Does the latest CVS version work with an IDE controller in DMA mode? > > I have an NEC VR5432 based system working with the IDE controller, but it > crashes when used in dma mode. I've tracked it down to the following code > called from ide_build_sglist(): > > - blk_rq_map_sg() is called to build a list of blocks to be transferred. > It sets address = NULL for every entry (other fields like "page" are > set to valid values). > > - dma_cache_wback_inv(addr, size) is called for each block entry. This > routine crashes because the address parameter is always set to zero > when the routine is called. > Did you check what the address is and why it is zero? It seems to me this might be key ... Jun From owner-linux-mips@oss.sgi.com Tue Jan 22 12:52:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKqZp30049 for linux-mips-outgoing; Tue, 22 Jan 2002 12:52:35 -0800 Received: from banff.ayrnetworks.com (64-166-72-137.ayrnetworks.com [64.166.72.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKqOP30041 for ; Tue, 22 Jan 2002 12:52:24 -0800 Received: from ayrnetworks.com (IDENT:chua@localhost.localdomain [127.0.0.1]) by banff.ayrnetworks.com (8.11.2/8.11.2) with ESMTP id g0MJqF208870; Tue, 22 Jan 2002 11:52:15 -0800 Message-ID: <3C4DC2EE.9060702@ayrnetworks.com> Date: Tue, 22 Jan 2002 11:52:14 -0800 From: Bryan Chua User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Geert Uytterhoeven CC: Linux/MIPS Development Subject: Re: arch/mips/setup.c References: Content-Type: multipart/mixed; boundary="------------050203000506020609010103" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2814 Lines: 104 This is a multi-part message in MIME format. --------------050203000506020609010103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry , it is attached. -- bryan Geert Uytterhoeven wrote: > On Mon, 21 Jan 2002, Bryan Chua wrote: > >>I recall a bunch of disussion about changing arch/mips/setup.c to >>simplify adding vendor-specific platform code in setup_arch, but to date >>nothing has come of it. So while this is a dramatic oversimplification >>of the various proposals, how about this for now -- >> >>just a vendor-defined function "platform_setup (void)" and it is up to >>the vendor to figure out what to do from there. >> >>-- bryan >> >> >>Index: arch/mips/kernel/setup.c >>=================================================================== >>RCS file: /cvs/linux/arch/mips/kernel/setup.c,v >>retrieving revision 1.96.2.3 >>diff -u -r1.96.2.3 setup.c >>--- arch/mips/kernel/setup.c 2001/12/26 23:27:02 1.96.2.3 >>+++ arch/mips/kernel/setup.c 2002/01/21 22:55:35 >>@@ -666,6 +666,7 @@ >> void it8172_setup(void); >> void swarm_setup(void); >> void hp_setup(void); >>+ >>void platform_setup (void); >> >> unsigned long bootmap_size; >> unsigned long start_pfn, max_pfn, first_usable_pfn; >>@@ -793,7 +794,8 @@ >> break; >> #endif >> default: >>- >> panic("Unsupported architecture"); >>+ >> platform_setup (); >>+ >> > > At first I thought: he's adding code after a call to panic(), but it turns out > your mailer screwed your patch... > > 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 > > --------------050203000506020609010103 Content-Type: text/plain; name="setup.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="setup.c" Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96.2.3 diff -u -r1.96.2.3 setup.c --- arch/mips/kernel/setup.c 2001/12/26 23:27:02 1.96.2.3 +++ arch/mips/kernel/setup.c 2002/01/22 20:52:05 @@ -666,6 +666,7 @@ void it8172_setup(void); void swarm_setup(void); void hp_setup(void); + void platform_setup (void); unsigned long bootmap_size; unsigned long start_pfn, max_pfn, first_usable_pfn; @@ -793,7 +794,8 @@ break; #endif default: - panic("Unsupported architecture"); + platform_setup (); + break; } strncpy(command_line, arcs_cmdline, sizeof command_line); --------------050203000506020609010103-- From owner-linux-mips@oss.sgi.com Tue Jan 22 12:59:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKxbp30198 for linux-mips-outgoing; Tue, 22 Jan 2002 12:59:37 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKxZP30195 for ; Tue, 22 Jan 2002 12:59:35 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 22 Jan 2002 20:02:38 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g0MJvVW23530; Tue, 22 Jan 2002 11:57:31 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id LAA17118; Tue, 22 Jan 2002 11:58:53 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id NAA23910; Tue, 22 Jan 2002 13:52:53 -0600 Message-ID: <3C4DC5A1.3080105@esstech.com> Date: Tue, 22 Jan 2002 14:03:45 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Jun Sun , linux-mips@oss.sgi.com Subject: Re: ide dma in latest cvs References: <3C4CA8C8.5010801@esstech.com> <3C4DB6DA.7F3E7386@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 628 Lines: 20 > Did you check what the address is and why it is zero? It seems to me this > might be key ... I see what the address is and why it's set to zero. The address is the address of a block of data to be transferred using dma, and it's set to zero because the new interface in blk_rq_map_sg() passes parameters in a page field instead an address field. It looks like this is part of the bio changes for 2.5 that work for x86 but haven't been updated for Mips. I figured that someone else must have run into this and it sounds like someone did. I'll try what Vivien Chappelier recommended in his response. Thanks. Gerald From owner-linux-mips@oss.sgi.com Tue Jan 22 14:43:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMhMH00475 for linux-mips-outgoing; Tue, 22 Jan 2002 14:43:22 -0800 Received: from firewall.i-data.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMhFP00470 for ; Tue, 22 Jan 2002 14:43:16 -0800 Received: (qmail 15099 invoked from network); 22 Jan 2002 21:43:12 -0000 Received: from idahub2000.i-data.com (HELO idanshub.i-data.com) (172.16.1.8) by firewall.i-data.com with SMTP; 22 Jan 2002 21:43:12 -0000 Received: from eicon.com ([172.16.2.227]) by idanshub.i-data.com (Lotus Domino Release 5.0.8) with ESMTP id 2002012222431045:20862 ; Tue, 22 Jan 2002 22:43:10 +0100 Message-ID: <3C4DDD24.4A0F24DE@eicon.com> Date: Tue, 22 Jan 2002 22:44:04 +0100 From: "Tommy S. Christensen" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Sweetman CC: Daniel Jacobowitz , "Kevin D. Kissell" , Ralf Baechle , Ulrich Drepper , Mike Uhler , "MIPS/Linux List (SGI)" , "H . J . Lu" Subject: Re: thread-ready ABIs References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <15437.35062.770932.705864@gladsmuir.algor.co.uk> X-MIMETrack: Itemize by SMTP Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 22-01-2002 22:43:11, Serialize by Router on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 22-01-2002 22:43:12, Serialize complete at 22-01-2002 22:43:12 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1551 Lines: 36 Dominic Sweetman wrote: > > > In any case, that's not the real problem. Linux user threads do not > > have true separate stacks. They share their _entire_ address space; > > the stacks are all bounded (default is 2MB) and grouped together at > > the top of the available memory region. > > Quite. > > A comment by Kevin reminded me of the real constraint (which the > experts probably take for granted): this system is supposed to work on > shared-memory multiprocessors and multithreaded CPUs. > > In both cases two or more threads within an address space can be > active simultaneously. On a multithreaded CPU (in particular) there's > only one TLB, so memory (including any memory specially handled by the > kernel) is all held in common. The *only* thing available to a user > privilege program which distinguishes the threads is the CPU register > set. > > (Well, and the stack, which is a difference inherited from the value > in the stack pointer register. But the stack pointer is not really > going to help much to return a thread-characteristic pointer or ID.) Well, why not use the stack? I am not quite familiar with the requirements on this "thread register", but couldn't something like this be made to work: #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET) It assumes a fixed maximum stack size (and alignment), which it should be possible to meet (virtual memory is cheap). The STACK_SIZE could probably even be a (process global!) variable if it is not desirable to limit this at compile time. -Tommy From owner-linux-mips@oss.sgi.com Tue Jan 22 14:53:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMr5Y00797 for linux-mips-outgoing; Tue, 22 Jan 2002 14:53:05 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMqvP00790; Tue, 22 Jan 2002 14:52:57 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA08470; Tue, 22 Jan 2002 13:52:47 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA03753; Tue, 22 Jan 2002 13:52:44 -0800 (PST) Message-ID: <013a01c1a38f$41f96a00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Tommy S. Christensen" , "Dominic Sweetman" Cc: "Daniel Jacobowitz" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <15437.35062.770932.705864@gladsmuir.algor.co.uk> <3C4DDD24.4A0F24DE@eicon.com> Subject: Re: thread-ready ABIs Date: Tue, 22 Jan 2002 22:53:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1874 Lines: 46 "Tommy S. Christensen" wrote: > > Dominic Sweetman wrote: > > > > > In any case, that's not the real problem. Linux user threads do not > > > have true separate stacks. They share their _entire_ address space; > > > the stacks are all bounded (default is 2MB) and grouped together at > > > the top of the available memory region. > > > > Quite. > > > > A comment by Kevin reminded me of the real constraint (which the > > experts probably take for granted): this system is supposed to work on > > shared-memory multiprocessors and multithreaded CPUs. > > > > In both cases two or more threads within an address space can be > > active simultaneously. On a multithreaded CPU (in particular) there's > > only one TLB, so memory (including any memory specially handled by the > > kernel) is all held in common. The *only* thing available to a user > > privilege program which distinguishes the threads is the CPU register > > set. > > > > (Well, and the stack, which is a difference inherited from the value > > in the stack pointer register. But the stack pointer is not really > > going to help much to return a thread-characteristic pointer or ID.) > > Well, why not use the stack? > > I am not quite familiar with the requirements on this "thread register", > but couldn't something like this be made to work: > #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET) > > It assumes a fixed maximum stack size (and alignment), which it should > be possible to meet (virtual memory is cheap). The STACK_SIZE could > probably even be a (process global!) variable if it is not desirable > to limit this at compile time. Thanks for writing this up. I had the same thought over dinner, but I'm throughly discredited today, and it's better that it came from someone else. ;-) Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 16:13:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N0DPO02793 for linux-mips-outgoing; Tue, 22 Jan 2002 16:13:25 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N0DJP02790; Tue, 22 Jan 2002 16:13:19 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA09873; Tue, 22 Jan 2002 15:13:09 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA07612; Tue, 22 Jan 2002 15:13:04 -0800 (PST) Message-ID: <016801c1a39a$7b2ca8e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , "Tommy S. Christensen" , "Dominic Sweetman" Cc: "Daniel Jacobowitz" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "MIPS/Linux List \(SGI\)" , "H . J . Lu" References: <20020118101908.C23887@lucon.org> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <20020119162415.B31028@dea.linux-mips.net> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <15437.14361.918255.115877@gladsmuir.algor.co.uk> <002001c1a33e$d9936560$0deca8c0@Ulysses> <20020122102128.A11455@nevyn.them.org> <15437.35062.770932.705864@gladsmuir.algor.co.uk> <3C4DDD24.4A0F24DE@eicon.com> <013a01c1a38f$41f96a00$0deca8c0@Ulysses> Subject: Re: thread-ready ABIs Date: Wed, 23 Jan 2002 00:13:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 879 Lines: 24 > > Well, why not use the stack? > > > > I am not quite familiar with the requirements on this "thread register", > > but couldn't something like this be made to work: > > #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET) > > > > It assumes a fixed maximum stack size (and alignment), which it should > > be possible to meet (virtual memory is cheap). The STACK_SIZE could > > probably even be a (process global!) variable if it is not desirable > > to limit this at compile time. > > Thanks for writing this up. I had the same thought over dinner, > but I'm throughly discredited today, and it's better that it came > from someone else. ;-) That having been said, I don't think this scheme will really work. Programs do build themselves temporary stacks in the heap from time to time. Signal stacks come to mind. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jan 22 17:23:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N1NTN03741 for linux-mips-outgoing; Tue, 22 Jan 2002 17:23:29 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N1NQP03738 for ; Tue, 22 Jan 2002 17:23:26 -0800 Message-Id: <200201230123.g0N1NQP03738@oss.sgi.com> Received: from unknown (HELO tp240) (218.76.10.22) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jan 2002 00:23:22 -0000 Date: Wed, 23 Jan 2002 8:24:32 +0800 From: Wu Qingbo To: "linux-mips@oss.sgi.com" Subject: Can mips linux support ext3 file sytem? X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 286 Lines: 15 Hi, all, Can linux mips support ext3 file system? If someone knows, please help me. TIA Wu Qingbo wu_qingbo2000@yahoo.com.cn _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Tue Jan 22 17:30:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N1U5v03909 for linux-mips-outgoing; Tue, 22 Jan 2002 17:30:05 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N1U3P03897 for ; Tue, 22 Jan 2002 17:30:03 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 3CBC0125C0; Tue, 22 Jan 2002 16:30:00 -0800 (PST) Date: Tue, 22 Jan 2002 16:29:59 -0800 From: "H . J . Lu" To: Wu Qingbo Cc: "linux-mips@oss.sgi.com" Subject: Re: Can mips linux support ext3 file sytem? Message-ID: <20020122162959.A23795@lucon.org> References: <200201230123.g0N1NQP03738@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: <200201230123.g0N1NQP03738@oss.sgi.com>; from wu_qingbo2000@yahoo.com.cn on Wed, Jan 23, 2002 at 08:24:32AM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 192 Lines: 11 On Wed, Jan 23, 2002 at 08:24:32AM +0800, Wu Qingbo wrote: > Hi, all, > > Can linux mips support ext3 file system? > If someone knows, please help me. > I am using ext3 with 2.4.16. H.J. From owner-linux-mips@oss.sgi.com Tue Jan 22 18:12:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2CIo08780 for linux-mips-outgoing; Tue, 22 Jan 2002 18:12:18 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2CDP08774 for ; Tue, 22 Jan 2002 18:12:13 -0800 Received: (qmail 1279 invoked from network); 23 Jan 2002 01:12:10 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 23 Jan 2002 01:12:10 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16TBxR-0005ac-00; Tue, 22 Jan 2002 18:12:10 -0700 Date: Tue, 22 Jan 2002 18:12:09 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: "Tommy S. Christensen" , Ulrich Drepper cc: "MIPS/Linux List (SGI)" Subject: Re: thread-ready ABIs In-Reply-To: <3C4DDD24.4A0F24DE@eicon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1523 Lines: 37 On Tue, 22 Jan 2002, Tommy S. Christensen wrote: > Well, why not use the stack? > > I am not quite familiar with the requirements on this "thread register", > but couldn't something like this be made to work: > #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET) Last time I looked at how pthreads worked it did use the stack pointer to decide what the TID is. It got rather ugly because the stack on thread 0 was not under program control, so it had all sorts of unknown properties. But that could be fixed with kernel support I think. The only reason I can think of to have a *fast* thread-local variable is to implement thread-local storage. This is a good thing for glibc and multi-threaded programs - the ultimate implemenation would probably be to have gcc know about it (if ia64 has dedicated hardware, it is not unimaginable, and other compilers do implement this) extern int errno __attribute__((thread_local)); On i386 this has often been done using fs/gs to point to a block of ram. However, I expect you could probably also base the thread-local ram on the top/bottom of the stack which means each procedure can compute the (constant!) base in a couple of instructions. The runtime can know how much to set aside before it begins executing the new thread. Aligning SP can be done in a kernel independent way for tid 0. I don't know if this is worse than making the TLB handler slower to free up k0/k1, it entirely depends how many functions will be using thread local stuff.. Jason From owner-linux-mips@oss.sgi.com Tue Jan 22 18:15:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2FsG08894 for linux-mips-outgoing; Tue, 22 Jan 2002 18:15:54 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2FpP08891 for ; Tue, 22 Jan 2002 18:15:51 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 6B567E00141 for ; Tue, 22 Jan 2002 20:15:44 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 568A9400135 for ; Tue, 22 Jan 2002 20:15:44 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 20:15:44 -0500 Message-ID: From: "TWEDE,ROGER (HP-Boise,ex1)" To: linux-mips@oss.sgi.com Subject: Mips IRQ support Date: Tue, 22 Jan 2002 20:15:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 529 Lines: 19 Are there any plans to provide full MIPS irq support in the general mips irq code? The only machine that appears to attempt to fully support the MIPS interrupt set currently is the gt64120/momenco_ocelot machine. It uses the define CP0_S1_INTCONTROL ($20) to get at the upper interrupt lines ( > 8 ). Anyone else find that support for this MIPS hardware would be best placed in the standard irq code rather than each machine variant having to re-implement it itself (as the irq code was in the past). Thanks, Roger Twede From owner-linux-mips@oss.sgi.com Tue Jan 22 18:24:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2OcR09004 for linux-mips-outgoing; Tue, 22 Jan 2002 18:24:38 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2OXP09001 for ; Tue, 22 Jan 2002 18:24:33 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0N1MtB22274; Tue, 22 Jan 2002 17:22:55 -0800 Subject: Re: Mips IRQ support From: Pete Popov To: "TWEDE,ROGER ""(HP-Boise,ex1)" Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 17:26:19 -0800 Message-Id: <1011749179.28944.262.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 812 Lines: 25 On Tue, 2002-01-22 at 17:15, TWEDE,ROGER (HP-Boise,ex1) wrote: > > Are there any plans to provide full MIPS irq support in the general mips irq > code? > > The only machine that appears to attempt to fully support the MIPS interrupt > set currently is the gt64120/momenco_ocelot machine. > It uses the define CP0_S1_INTCONTROL ($20) to get at the upper interrupt > lines ( > 8 ). That's really a QED rm7k cpu feature, not a mips generic one. > Anyone else find that support for this MIPS hardware would be best placed in > the standard irq code rather than each machine variant having to > re-implement it itself (as the irq code was in the past). Might be a good feature for arch/mips/kernel/irq_cpu.c and it wouldn't be difficult to add. I don't think arch/mips/kernel/irq.c needs to change. Pete From owner-linux-mips@oss.sgi.com Tue Jan 22 18:28:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2S4H09078 for linux-mips-outgoing; Tue, 22 Jan 2002 18:28:04 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2RwP09075 for ; Tue, 22 Jan 2002 18:27:59 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0N1QLB22454; Tue, 22 Jan 2002 17:26:21 -0800 Message-ID: <3C4E1195.9996C16@mvista.com> Date: Tue, 22 Jan 2002 17:27:49 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "TWEDE,ROGER (HP-Boise,ex1)" CC: linux-mips@oss.sgi.com Subject: Re: Mips IRQ support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 23 "TWEDE,ROGER (HP-Boise,ex1)" wrote: > > Are there any plans to provide full MIPS irq support in the general mips irq > code? > > The only machine that appears to attempt to fully support the MIPS interrupt > set currently is the gt64120/momenco_ocelot machine. > > It uses the define CP0_S1_INTCONTROL ($20) to get at the upper interrupt > lines ( > 8 ). > > Anyone else find that support for this MIPS hardware would be best placed in > the standard irq code rather than each machine variant having to > re-implement it itself (as the irq code was in the past). > Yes. The best way is to provide hw_irq_controller structure for the extended CPU IRQ feature. See arch/mips/kernel/irq_cpu.c file and its related config option. Jun From owner-linux-mips@oss.sgi.com Tue Jan 22 18:40:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2eQa09454 for linux-mips-outgoing; Tue, 22 Jan 2002 18:40:26 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2eCP09450 for ; Tue, 22 Jan 2002 18:40:12 -0800 Received: (qmail 14560 invoked from network); 23 Jan 2002 01:40:09 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 23 Jan 2002 01:40:09 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16TCOX-0005ha-00; Tue, 22 Jan 2002 18:40:09 -0700 Date: Tue, 22 Jan 2002 18:40:09 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Jun Sun cc: "TWEDE,ROGER (HP-Boise,ex1)" , linux-mips@oss.sgi.com Subject: Re: Mips IRQ support In-Reply-To: <3C4E1195.9996C16@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4417 Lines: 139 On Tue, 22 Jan 2002, Jun Sun wrote: > The best way is to provide hw_irq_controller structure for the extended CPU > IRQ feature. See arch/mips/kernel/irq_cpu.c file and its related config > option. Attached is such a file. Jason /* Copyright 2002 Jason Gunthorpe Modified from arch/mips/kernel/irq_cpu.S: Copyright 2001 MontaVista Software Inc. Author: Jun Sun, jsun@mvista.com or jsun@junsun.net 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. This is an addendum to irq_cpu to support the additional RM7000 interrupt sources. irq_cpu handles the lower 8 interrupts, this does the remaining 6. */ #include #include #include #include /* Move me to asm-mips/mipsregs.h */ #define __BUILD_SET_CP0_SET1(name,register) \ extern __inline__ unsigned int \ set_cp0_##name(unsigned int set) \ { \ unsigned int res; \ \ res = read_32bit_cp0_set1_register(register); \ res |= set; \ write_32bit_cp0_set1_register(register, res); \ \ return res; \ } \ \ extern __inline__ unsigned int \ clear_cp0_##name(unsigned int clear) \ { \ unsigned int res; \ \ res = read_32bit_cp0_set1_register(register); \ res &= ~clear; \ write_32bit_cp0_set1_register(register, res); \ \ return res; \ } \ \ extern __inline__ unsigned int \ change_cp0_##name(unsigned int change, unsigned int new) \ { \ unsigned int res; \ \ res = read_32bit_cp0_set1_register(register); \ res &= ~change; \ res |= (new & change); \ if(change) \ write_32bit_cp0_set1_register(register, res); \ \ return res; \ } __BUILD_SET_CP0_SET1(s1_intcontrol,CP0_S1_INTCONTROL) static int mips_rm7kcpu_irq_base; static void mips_rm7kcpu_irq_enable(unsigned int irq) { set_cp0_s1_intcontrol(1 << (irq - mips_rm7kcpu_irq_base + 8)); } static void mips_rm7kcpu_irq_disable(unsigned int irq) { clear_cp0_s1_intcontrol(1 << (irq - mips_rm7kcpu_irq_base + 8)); } static unsigned int mips_rm7kcpu_irq_startup(unsigned int irq) { mips_rm7kcpu_irq_enable(irq); return 0; } #define mips_rm7kcpu_irq_shutdown mips_rm7kcpu_irq_disable static void mips_rm7kcpu_irq_ack(unsigned int irq) { /* disable this interrupt - so that we safe proceed to the handler */ mips_rm7kcpu_irq_disable(irq); } static void mips_rm7kcpu_irq_end(unsigned int irq) { mips_rm7kcpu_irq_enable(irq); } static hw_irq_controller mips_rm7kcpu_irq_controller = { "RM7KCPU_irq", mips_rm7kcpu_irq_startup, mips_rm7kcpu_irq_shutdown, mips_rm7kcpu_irq_enable, mips_rm7kcpu_irq_disable, mips_rm7kcpu_irq_ack, mips_rm7kcpu_irq_end, NULL /* no affinity stuff for UP */ }; void mips_rm7kcpu_irq_init(u32 irq_base) { extern irq_desc_t irq_desc[]; u32 i; for (i= irq_base; i< irq_base+6; i++) { irq_desc[i].status = IRQ_DISABLED; irq_desc[i].action = NULL; irq_desc[i].depth = 1; irq_desc[i].handler = &mips_rm7kcpu_irq_controller; } mips_rm7kcpu_irq_base = irq_base; // Enable TE, the dedicated timer IRQ. It shows up as irq_base + 4 set_cp0_s1_intcontrol(1 << 7); } From owner-linux-mips@oss.sgi.com Tue Jan 22 22:56:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N6usZ12272 for linux-mips-outgoing; Tue, 22 Jan 2002 22:56:54 -0800 Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [146.215.0.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N6ugP12269; Tue, 22 Jan 2002 22:56:43 -0800 Received: from mail1.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns4.sony.co.jp (R8/Sony) with ESMTP id g0N5ucY75386; Wed, 23 Jan 2002 14:56:38 +0900 (JST) Received: from mail1.sony.co.jp (localhost [127.0.0.1]) by mail1.sony.co.jp (R8) with ESMTP id g0N5ubl22735; Wed, 23 Jan 2002 14:56:37 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail1.sony.co.jp (R8) with ESMTP id g0N5uZg22681; Wed, 23 Jan 2002 14:56:36 +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 PAA04915; Wed, 23 Jan 2002 15:01:21 +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 OAA16906; Wed, 23 Jan 2002 14:56:34 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0N5uYJ08126; Wed, 23 Jan 2002 14:56:34 +0900 (JST) To: kevink@mips.com Cc: aj@suse.de, hjl@lucon.org, ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) In-Reply-To: <005301c1a368$87d27ed0$10eca8c0@grendel> References: <20020122232529V.machida@sm.sony.co.jp> <005301c1a368$87d27ed0$10eca8c0@grendel> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020123145634M.machida@sm.sony.co.jp> Date: Wed, 23 Jan 2002 14:56:34 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1868 Lines: 66 Hi Kevin, As you said, following codes can run fine if CPU has brach-likely. From: "Kevin D. Kissell" Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Tue, 22 Jan 2002 18:16:25 +0100 > _atomic_inc_nollsc: > .set noreorder > li t0,MAGIC_COOKIE > Retry: > mov k1,t0 > lw t1,0(a0) > addiu t1,t1,1 > BEQL k1,t0,done > sw t1,0(a0) > b Retry > nop > done > jr ra > nop > > If there is any doubt about the possibility of the > MAGIC_COOKIE value being left in k1 (or > k0, which could also be used as the "LL flop" > if its behavior is more easily constrained), an > explicit operation at the end of the fault handlers > could be used to clear the register. That would > still be far less complex and intrusive than the mods > that you suggest below. I think we should always "clear" k1 at the end of exception handler. (Above "clear" means "set !MAGIC_COOKIE"). It's conaervative way, but robust aginst future changes in exception handler. > It should in principle be SMP safe. I don't think so. Suppose that THREAD A is bound to CPU A and THREAD B is bound to CPU B. THREAD A and THREAD B are running on_atomic_inc_nollsc(). Two threads are really running at the same time, without context-switch. In this case nobody clear k1. Anyway, I will merge your brach-likely method and make some changes. This change will provide signle interface of user level test-and-set(), without LL/SC instruction emulation nor system-call. So everyone will be able to run single user program binary to on following three types of CPUs; CPU has LL/SC, CPU has no LL/SC, but has branch-likely and CPU has neither LL/SC nor branch-likely. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Wed Jan 23 01:38:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N9cQN25250 for linux-mips-outgoing; Wed, 23 Jan 2002 01:38:26 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N9cLP25221; Wed, 23 Jan 2002 01:38:21 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA15915; Wed, 23 Jan 2002 00:38:10 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA22805; Wed, 23 Jan 2002 00:38:02 -0800 (PST) Message-ID: <000c01c1a3e9$6a8086c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Machida Hiroyuki" Cc: , , , References: <20020122232529V.machida@sm.sony.co.jp><005301c1a368$87d27ed0$10eca8c0@grendel> <20020123145634M.machida@sm.sony.co.jp> Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Wed, 23 Jan 2002 09:38:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 460 Lines: 17 > > It should in principle be SMP safe. > > I don't think so. You are quite right. It was an offhand remark that should have been better qualified. The basic mechanism requires no global memory resource and will detect discontinuitues in scheduling on several CPUs at once, but but it is certainly not SMP safe in the sense of the code sample providing atomic increment on a classical SMP hardware platform. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Jan 23 08:52:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGqeM15483 for linux-mips-outgoing; Wed, 23 Jan 2002 08:52:40 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGqcP15468 for ; Wed, 23 Jan 2002 08:52:38 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16TPhJ-0000t8-00; Wed, 23 Jan 2002 09:52:25 -0600 Message-ID: <3C4EDC2D.199E54D8@cotw.com> Date: Wed, 23 Jan 2002 09:52:13 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Wu Qingbo CC: "linux-mips@oss.sgi.com" Subject: Re: Can mips linux support ext3 file sytem? References: <200201230123.g0N1NQP03738@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 184 Lines: 11 Wu Qingbo wrote: > > Can linux mips support ext3 file system? > If someone knows, please help me. > Yup, and XFS works great too. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Jan 24 02:50:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OAoq723081 for linux-mips-outgoing; Thu, 24 Jan 2002 02:50:52 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OAooP23074 for ; Thu, 24 Jan 2002 02:50:50 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g0O9og129966 for linux-mips@oss.sgi.com; Thu, 24 Jan 2002 01:50:42 -0800 Date: Thu, 24 Jan 2002 01:50:42 -0800 From: Matthew Dharm To: linux-mips@oss.sgi.com Subject: Does anyone know how HHL boots? Message-ID: <20020124015042.B29933@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 589 Lines: 17 I'm somewhat curious... MontaVista has HHL support for several MIPS boards... including one that my company makes. We've never actually seen their HHL distribution for our board, tho... and we're wondering, how does it boot? I mean, our boards have an elementary boot loader that can load a kernel from the network, and disk-booting is something we're trying to figure out. But how does HHL accomplish this? And is it a general solution for multiple platforms? Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Thu Jan 24 03:00:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OB0qj26030 for linux-mips-outgoing; Thu, 24 Jan 2002 03:00:52 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OB0hP25987 for ; Thu, 24 Jan 2002 03:00:44 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9E62B1E46A; Thu, 24 Jan 2002 10:57:02 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: drepper@redhat.com (Ulrich Drepper) Cc: Machida Hiroyuki , kevink@mips.com, hjl@lucon.org, libc-hacker@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) References: <20020120193843M.machida@sm.sony.co.jp> <002c01c1a1a9$b9f0de40$0deca8c0@Ulysses> <20020120221607T.machida@sm.sony.co.jp> <20020122152744C.machida@sm.sony.co.jp> From: Andreas Jaeger Date: Thu, 24 Jan 2002 10:56:57 +0100 In-Reply-To: (Ulrich Drepper's message of "21 Jan 2002 22:37:02 -0800") Message-ID: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1630 Lines: 46 Ulrich Drepper writes: > Machida Hiroyuki writes: > >> * glibc change: >> >> We implement test_and_set(addr, val) as follows, >> >> Do mmap /dev/tst to _TST_START_MAGIC, if not yet mapped. >> call _TST_START_MAGIC(addr, val) >> >> If we can't open /dev/tst then, use sysmips() as final resort. > > First, the patch as it is unacceptable. A file with copyright Sony? > All the code must be copyrighted by the FSF. Sony will have to assign > the copyright for the code to the FSF. > > Also, no such change can be accepted until the necessary kernel > changes are in the official kernel sources. I cannot make any > exceptions since otherwise all kinds of people want to see support for > their local hack added. > > Furthermore, the symbols were not available in version 2.2. Therefore > they cannot be exported with this version. It'll either be 2.2.6 (if > their ever will be such a release) or 2.3. > > And finally, the patch should be sent to the glibc MIPS maintainer for > review. The question is who feels responsible... I'll look into it later in more detail. But for now, let me just tell that I agree with Ulrich's comments. Additionally I'd like to wait with adding this patch until: - a solution for the thread register is found for MIPS (and those solution should not conflict with this patch) - the kernel side patches have been adopted. Therefore please discuss this with the kernel and ABI folks, and then let's look again at the issues. 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 Thu Jan 24 06:58:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OEwsM04328 for linux-mips-outgoing; Thu, 24 Jan 2002 06:58:54 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OEwjP04308 for ; Thu, 24 Jan 2002 06:58:45 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16TkOj-0001pC-00 for ; Thu, 24 Jan 2002 07:58:37 -0600 Message-ID: <3C502108.B4024075@cotw.com> Date: Thu, 24 Jan 2002 08:58:16 -0600 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "MIPS/Linux List (SGI)" Subject: gdb, pthreads and MIPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3024 Lines: 90 I am targeting a NEC VR5432 I am able to debug/set break points on executables that are not linked with -lpthreads. However, whenever I try an executable that was linked with pthreads gdb can never find the stack (PC). Once a SIGTRAP occurs gdb has lost track of the stack. Up until that point it seems to be keeping track of the PC. I have tried gdb from the SGI site (H J Lu) I also have built 5.1.0.1 native. Both fail. Are other people having trouble debugging pthreads? Are there any patches available? Can anyone even help me classify this problem? (gcc, glibc, gdb all three) -------------------------------------------------- The programs I am running are cross compiled with: $ mipsel-linux-gcc -v Reading specs from /opt/toolchains/mips/lib/gcc-lib/mipsel-linux/3.0.3/specs Configured with: ../gcc-3.0.3/configure --prefix=/opt/toolchains/mips --target=mipsel-linux i686-pc-linux-gnu --includedir=/opt/toolchains/mips/mipsel-linux/include --with-gxx-include-dir=/opt/toolchains/mips/mipsel-linux/include --mandir=/opt/toolchains/mips/man --infodir=/opt/toolchains/mips/info --enable-languages=c,c++ --enable-threads Thread model: posix gcc version 3.0.3 -------------------------------------------------------- The native compiler on the MIS box is: bash-2.04# gcc -v Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) [New Thread 1024 (LWP 175)] Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 1024 (LWP 175)] warning: Warning: GDB can't find the start of the function at 0xffffffff. GDB is unable to find the start of the function at 0xffffffff and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0xffffffff for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. 0xffffffff in ?? () (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 2ab04e60 00000001 2aab9920 00000000 2ab052b8 00000000 0000004d t0 t1 t2 t3 t4 t5 t6 t7 R8 0000f000 00000053 00000000 00000001 00000001 8022eef3 7fff7904 7fff7700 s0 s1 s2 s3 s4 s5 s6 s7 R16 2ab05860 00400d40 10012c10 00000000 7fff7b18 7fff7af4 00000008 2ab052c8 t8 t9 k0 k1 gp sp s8 ra R24 00000000 2aab9920 7fff76b8 00000000 2ab0c9e0 7fff7a98 2ab052b0 2aab9288 sr lo hi bad cause pc ffffffff ffffffff 00000000 2abfd290 00000024 ffffffff fsr fir fp 00000000 00000000 00000000 -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Thu Jan 24 09:37:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OHbpx19369 for linux-mips-outgoing; Thu, 24 Jan 2002 09:37:51 -0800 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OHbkP19363 for ; Thu, 24 Jan 2002 09:37:47 -0800 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id IAA62727; Thu, 24 Jan 2002 08:37:23 -0800 (PST) Date: Thu, 24 Jan 2002 08:37:23 -0800 From: Geoffrey Espin To: Matthew Dharm Cc: linux-mips@oss.sgi.com Subject: Re: Does anyone know how HHL boots? Message-ID: <20020124083723.A47711@idiom.com> References: <20020124015042.B29933@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020124015042.B29933@momenco.com>; from Matthew Dharm on Thu, Jan 24, 2002 at 01:50:42AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1754 Lines: 41 Matt, > MontaVista has HHL support for several MIPS boards... including one that my >... > I mean, our boards have an elementary boot loader that can load a kernel > from the network, and disk-booting is something we're trying to figure out. > But how does HHL accomplish this? And is it a general solution for > multiple platforms? I went thru the same pain and confusion myself 9 months ago. My understanding is MontaVista uses whatever the manufacturer supplies with the hardware. And/or they have an internal version of PMON. There are probably a dozen differernt MIPS loaders... some of which you might be able to find source for, but probably won't be even close to working on your board without weeks+ of effort. If you have some assembly startup code that turns off interrupts, sets up the memory controller then you maybe able to use my "LinuxMon" solution which only works on the Korva(Markham) NEC Vr41xx chip but is very generic. Sheese, every monitor says it's generic. After turning off interrupts and setting up the memory controller it copies (optionally gunzips) the remainder of flash then jumps to your linux kernel. A 1-stage boot. It can then be used to load a second linux kernel if it has been linked elsewhere. I wasn't successful in getting it submitted/accepted unfortunately. You can get a copy of my 2.4.16 release containing it, at: http://www.idiom.com/~espin/nec The important files are arch/mips/korva/{Boot.make,vrboot.S,misc.c} If you have an already working linux kernel then these few files should turn it into a boot monitor. These were posted to linux-mips-kernel@lists.sourceforge.net so you can find them in the mail archive in Nov/Dec. Or I can post. Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Thu Jan 24 09:54:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OHsmS20554 for linux-mips-outgoing; Thu, 24 Jan 2002 09:54:48 -0800 Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OHshP20546 for ; Thu, 24 Jan 2002 09:54:43 -0800 Received: from [10.2.2.69] ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQG00J2JCB05U@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Thu, 24 Jan 2002 08:54:36 -0800 (PST) Date: Thu, 24 Jan 2002 08:51:37 -0800 From: Pete Popov Subject: Re: Does anyone know how HHL boots? In-reply-to: <20020124015042.B29933@momenco.com> To: Matthew Dharm Cc: linux-mips Message-id: <1011891098.1390.15.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution/1.0.1 Content-type: text/plain Content-transfer-encoding: 7bit References: <20020124015042.B29933@momenco.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2324 Lines: 44 On Thu, 2002-01-24 at 01:50, Matthew Dharm wrote: > I'm somewhat curious... > > MontaVista has HHL support for several MIPS boards... including one that my > company makes. We've never actually seen their HHL distribution for our > board, tho... and we're wondering, how does it boot? > > I mean, our boards have an elementary boot loader that can load a kernel > from the network, and disk-booting is something we're trying to figure out. > But how does HHL accomplish this? And is it a general solution for > multiple platforms? HHL, or now MontaVista Linux, MVL, is a cross dev environment. The tools and all apps are installed on the host system. The target boots over the net, which requires that the boot code support net booting, and then mounts the root fs over nfs. You can then proceed to develop your apps on the host system, install it in the target directory, test it, etc. When you're ready for deployment, you can use the Target Configurator Tool to build a custom file system. How you deploy the system varies. I'll give you an example of a board I'm working on right now. The Pb1500 from Alchemy has yamon as the boot code. I've added boot from flash support so you can compile a zImage kernel. The image is then turned to srecords, which yamon can download directly to flash (if the srecords' addresses are those of the flash). You can then set a "start" variable in yamon which is a string that yamon parses, such as: "go bfd00000 root=/dev/mtdblock0". Assuming that you have the zImage at 0xbfd00000, yamon will just jump there and the kernel loader that's part of the zImage will do the rest. The root file system, in this case, is in flash. This means that you need mtd and jffs or jffs2 support. Another option for this board is to put the root fs on a pcmcia card or on a hard disk, since the board has the HPT370A IDE controller. I've tested both. I guess the short answer is that MVL boots over the network and mounts the root fs over nfs. For deployment, it depends on what you need or what your customers need. It also depends on the features of your boot code and the level of support for your board in the kernel tree (mtd, jffs, etc). It might be very easy to deploy the board, or you might have to either pay someone PS or add the additional features you need yourself. Pete From owner-linux-mips@oss.sgi.com Thu Jan 24 10:15:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OIFcf25060 for linux-mips-outgoing; Thu, 24 Jan 2002 10:15:38 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OIFYP25038 for ; Thu, 24 Jan 2002 10:15:34 -0800 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16TnTU-00078e-00; Thu, 24 Jan 2002 12:15:44 -0500 Date: Thu, 24 Jan 2002 12:15:44 -0500 From: Daniel Jacobowitz To: Scott A McConnell Cc: "MIPS/Linux List (SGI)" Subject: Re: gdb, pthreads and MIPS Message-ID: <20020124121544.A26522@nevyn.them.org> References: <3C502108.B4024075@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C502108.B4024075@cotw.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1125 Lines: 28 On Thu, Jan 24, 2002 at 08:58:16AM -0600, Scott A McConnell wrote: > I am targeting a NEC VR5432 > > I am able to debug/set break points on executables that are not linked > with -lpthreads. However, whenever I try an executable that was linked > with pthreads gdb can never find the stack (PC). > > Once a SIGTRAP occurs gdb has lost track of the stack. Up until that > point it seems to be keeping track of the PC. > > I have tried gdb from the SGI site (H J Lu) I also have built 5.1.0.1 > native. Both fail. > > Are other people having trouble debugging pthreads? > Are there any patches available? > Can anyone even help me classify this problem? (gcc, glibc, gdb all > three) Primarily glibc. I've spent a long long time trying to get this fixed and Ulrich categorically refused the patch. The size of prgregset in the headers is wrong. Edit /usr/include/sys/procfs.h, change the typedef of pr*regset from *regset_t to elf_*regset_t, rebuild GDB, see if it works. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Jan 24 10:57:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OIvdL08044 for linux-mips-outgoing; Thu, 24 Jan 2002 10:57:39 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OIvbP08029 for ; Thu, 24 Jan 2002 10:57:37 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16To7u-000226-00 for ; Thu, 24 Jan 2002 11:57:30 -0600 Message-ID: <3C505900.9685DDE3@cotw.com> Date: Thu, 24 Jan 2002 12:57:04 -0600 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "MIPS/Linux List (SGI)" Subject: ABI for MIPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 403 Lines: 12 I found these MIPS ABI documents. Ralph mentions on his web page to look at the System V MIPS ABI book which is out of print are these equivalent? If I want to understand the ABI for GCC/Linux/MIPS are these a good place to start? http://ftp.stenstad.net/pub/mipslinux/docs/ABI/mipsabi.pdf http://ftp.stenstad.net/pub/mipslinux/docs/ABI/psABI_mips3.0.pdf -- Scott A. McConnell Phone: (319) 364-0100 From owner-linux-mips@oss.sgi.com Thu Jan 24 11:00:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OJ0XQ09522 for linux-mips-outgoing; Thu, 24 Jan 2002 11:00:33 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OJ0SP09497 for ; Thu, 24 Jan 2002 11:00:28 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0OHwgB31678; Thu, 24 Jan 2002 09:58:42 -0800 Subject: Re: Does anyone know how HHL boots? From: Pete Popov To: Matthew Dharm Cc: linux-mips In-Reply-To: <20020124083723.A47711@idiom.com> References: <20020124015042.B29933@momenco.com> <20020124083723.A47711@idiom.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 10:02:30 -0800 Message-Id: <1011895350.26391.11.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1695 Lines: 36 On Thu, 2002-01-24 at 08:37, Geoffrey Espin wrote: > Matt, > > > MontaVista has HHL support for several MIPS boards... including one that my > >... > > I mean, our boards have an elementary boot loader that can load a kernel > > from the network, and disk-booting is something we're trying to figure out. > > But how does HHL accomplish this? And is it a general solution for > > multiple platforms? > > I went thru the same pain and confusion myself 9 months ago. My > understanding is MontaVista uses whatever the manufacturer supplies > with the hardware. And/or they have an internal version of PMON. > There are probably a dozen differernt MIPS loaders... some of > which you might be able to find source for, but probably won't > be even close to working on your board without weeks+ of effort. There is pmon2000 which was ported to mips and runs on the ev96100 (rm7k). Porting it to the Ocelot should be straight forward. The CPU is the same. The system controller is different, but the gt96100 is a superset of the gt64120, so that part should be easy too. I believe the low level code that initializes the memory controller will be the same. I did find a bug in the mem init code that reports the wrong memory size and sets up the sub decoder incorrectly, but ... it still worked and I didn't have time to fix it. Pmon2000 is rather large because it's openbsd based. What's nice though is that porting drivers to it is much easier since you can just grab it from openbsd and get rid of some of the memory/bus code. Another option I like a lot is yamon from MIPS T. I don't know how long it would take to port it to the rm7k and the gt64120, but it can't be that bad. Pete From owner-linux-mips@oss.sgi.com Thu Jan 24 11:14:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OJEUw12716 for linux-mips-outgoing; Thu, 24 Jan 2002 11:14:30 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OJEQP12695 for ; Thu, 24 Jan 2002 11:14:26 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0OICfB00317; Thu, 24 Jan 2002 10:12:41 -0800 Message-ID: <3C504EF6.D41EB019@mvista.com> Date: Thu, 24 Jan 2002 10:14:14 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dharm CC: linux-mips@oss.sgi.com Subject: Re: Does anyone know how HHL boots? References: <20020124015042.B29933@momenco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 548 Lines: 21 Matthew Dharm wrote: > > I'm somewhat curious... > > MontaVista has HHL support for several MIPS boards... including one that my > company makes. I suppose you are referring to Ocelot. It is supported in HHL2.0. > We've never actually seen their HHL distribution for our > board, tho... Strange. You should get one set of CD's. I am not sure about the business arrangment. Please contact support@mvista.com. > and we're wondering, how does it boot? Kernel is booted through netboot. Root fs is NFS. It is documented in the CD's. Jun From owner-linux-mips@oss.sgi.com Thu Jan 24 11:35:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OJZrA18802 for linux-mips-outgoing; Thu, 24 Jan 2002 11:35:53 -0800 Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OJZmP18779 for ; Thu, 24 Jan 2002 11:35:49 -0800 Received: from host213-122-62-182.btinternet.com ([213.122.62.182] helo=rodson.com) by carbon.btinternet.com with smtp (Exim 3.22 #8) id 16Toft-0006LH-00; Thu, 24 Jan 2002 18:32:38 +0000 From: "Rodson Universal" To: Subject: Port and Stevedoring Equipment For Sale and Wanted Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 24 Jan 2002 20:32:16 +0200 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1246 Lines: 40 Attn : Stevedoring , crane and engineering dept. We buy and sell crawler and telescopic cranes 50-1000 tons Stevedoring equipment Port cranes equipment ,Shipyard equipment Container cranes and equipment Floating grab cranes , heavy lift cranes , dry docks and barges PLEASE CHECK OUR WEBSITE www.rodson.com We are always looking to buy port cranes and ship unloading systems , bagging plants , pneumatic grain unloaders , dry cargo unloaders , screw type unloaders , dry cargo unloading systems , dry powdered cement unloaders , rail mounted and rubber tyred ship-to-shore cranes , container cranes , grab cranes , coal discharging systems , Port pedastal whirley cranes ,container-handling forklifts and reachstackers , terminal tractors and trailers, electro-hydrauylic grabs 10-14 cu meter Please keep us informed of any equipment you have for sale and let us know your port equipment and stevedoring requirements thanks and regards connie sullivan Please reply to: sales@rodson.com RODSON UNIVERSAL INC www.rodson.com Tel +44 1444 412728 Fax +44 1444 415929 If you feel that you have received this e-mail in error or wish to unsubscribe to future mailings, please reply to this e-mail with "remove" in the subject header. From owner-linux-mips@oss.sgi.com Thu Jan 24 12:42:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKgXt01843 for linux-mips-outgoing; Thu, 24 Jan 2002 12:42:33 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKgUP01812 for ; Thu, 24 Jan 2002 12:42:30 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16TplO-00029S-00 for ; Thu, 24 Jan 2002 13:42:23 -0600 Message-ID: <3C507199.CBCF56EF@cotw.com> Date: Thu, 24 Jan 2002 14:42:01 -0600 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "MIPS/Linux List (SGI)" Subject: Re: gdb, pthreads and MIPS References: <3C502108.B4024075@cotw.com> <20020124121544.A26522@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 650 Lines: 26 Daniel Jacobowitz wrote: --snip-- > > Primarily glibc. I've spent a long long time trying to get this fixed > and Ulrich categorically refused the patch. The size of prgregset in > the headers is wrong. > > Edit /usr/include/sys/procfs.h, change the typedef of pr*regset from > *regset_t to elf_*regset_t, rebuild GDB, see if it works. You sure made my day! This fix worked. Wow, I sure can believe it took you "a long long time to get this fixed". Thanks, Scott > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Thu Jan 24 16:56:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P0upE31404 for linux-mips-outgoing; Thu, 24 Jan 2002 16:56:51 -0800 Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P0ujP31359 for ; Thu, 24 Jan 2002 16:56:45 -0800 Received: from e146222.ppp.asahi-net.or.jp (HELO nazneen) (211.13.146.222) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Jan 2002 23:56:41 -0000 Message-ID: <003901c1a532$d01576e0$de920dd3@gol.com> From: "Girish Gulawani" To: "MIPS/Linux List \(SGI\)" References: <3C505900.9685DDE3@cotw.com> Subject: MIPS/Linux NonSGI Date: Fri, 25 Jan 2002 08:41:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1178 Lines: 30 hello all. i'm trying to bringup linux 2.4.[2|9] on our board based on LSI mips r4k core. right now the kernel compiled with gcc-3.0, boots up & can only work with statically linked commands. hence the root file system mounted from ramdisk,nfs, & de-dream ide-disk can show some-prompt only if ash.static is invoked. this is seen with 2.4.3 & ditto with 2.4.9. the kernel is in un-cached mode,since we have page-size problem with our core in cached, write through/back both, modes. so question is WHY THE COMMANDS WITH SHARED LIBRARY DONOT WORK. FAILS TO LOAD SHARED LIBRARIES. the problem no.2 is root on ide-disk. the disk is paritioned & formatted using a linux pentium-pc. using a master disk the above said statically linked commands are downloaded to slave disk. the board boots up. however the bdflush/update process corrupts file-system. the UPDATE PROCESS CORRUPTS SUPERBLOCK AND INODES WHILE FLUSHING THE DIRTY BUFERS. PLEASE! PLEASE!! HELP ME ON THIS. THIS NEWSGROUP IS MY LAST HOPE. many thanks in advance with regards, girish. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Thu Jan 24 17:49:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P1nhv10408 for linux-mips-outgoing; Thu, 24 Jan 2002 17:49:43 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0P1neP10402 for ; Thu, 24 Jan 2002 17:49:40 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0OIxPc02626; Thu, 24 Jan 2002 10:59:25 -0800 Date: Thu, 24 Jan 2002 10:59:15 -0800 From: Ralf Baechle To: Machida Hiroyuki Cc: kevink@mips.com, aj@suse.de, hjl@lucon.org, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Message-ID: <20020124105915.A838@dea.linux-mips.net> References: <20020122232529V.machida@sm.sony.co.jp> <005301c1a368$87d27ed0$10eca8c0@grendel> <20020123145634M.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020123145634M.machida@sm.sony.co.jp>; from machida@sm.sony.co.jp on Wed, Jan 23, 2002 at 02:56:34PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 18 On Wed, Jan 23, 2002 at 02:56:34PM +0900, Machida Hiroyuki wrote: > > It should in principle be SMP safe. > > I don't think so. > > Suppose that > THREAD A is bound to CPU A and THREAD B is bound to CPU B. > THREAD A and THREAD B are running on_atomic_inc_nollsc(). > Two threads are really running at the same time, without > context-switch. In this case nobody clear k1. There is a method for mutual exclusion called Dekker's Algorithem (sp?) which only requires just atomic stores and can be implemented in plain C. Downside is it's weak performance that renders it pretty much a CS only thing. Ralf From owner-linux-mips@oss.sgi.com Thu Jan 24 18:45:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P2jSr21861 for linux-mips-outgoing; Thu, 24 Jan 2002 18:45:28 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0P2jOP21852 for ; Thu, 24 Jan 2002 18:45:24 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0P1jLX15571; Thu, 24 Jan 2002 17:45:21 -0800 Date: Thu, 24 Jan 2002 17:45:21 -0800 From: Ralf Baechle To: Girish Gulawani Cc: "MIPS/Linux List (SGI)" Subject: Re: MIPS/Linux NonSGI Message-ID: <20020124174521.B8860@dea.linux-mips.net> References: <3C505900.9685DDE3@cotw.com> <003901c1a532$d01576e0$de920dd3@gol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003901c1a532$d01576e0$de920dd3@gol.com>; from girishvg@yahoo.com on Fri, Jan 25, 2002 at 08:41:10AM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1444 Lines: 33 On Fri, Jan 25, 2002 at 08:41:10AM +0900, Girish Gulawani wrote: > i'm trying to bringup linux 2.4.[2|9] on our board based on LSI mips r4k > core. > right now the kernel compiled with gcc-3.0, boots up & can only work with There are known bugs in older kernels that will crash them when compiled with gcc 3.0. Even with current 2.4 kernels it's still playing with the fire. > statically linked commands. hence the root file system mounted from > ramdisk,nfs, & de-dream ide-disk can show some-prompt only if ash.static is > invoked. > this is seen with 2.4.3 & ditto with 2.4.9. the kernel is in un-cached > mode,since we have page-size problem with our core in cached, write > through/back > both, modes. so question is WHY THE COMMANDS WITH SHARED LIBRARY DONOT WORK. > FAILS TO LOAD SHARED LIBRARIES. > > the problem no.2 is root on ide-disk. the disk is paritioned & formatted > using a linux pentium-pc. using a master disk the above said statically > linked commands are downloaded to slave disk. the board boots up. however > the bdflush/update process corrupts file-system. the UPDATE PROCESS CORRUPTS > SUPERBLOCK AND INODES WHILE FLUSHING THE DIRTY BUFERS. > > PLEASE! PLEASE!! HELP ME ON THIS. THIS NEWSGROUP IS MY LAST HOPE. Seems pretty obvious that cacheflushing for your system is broken. Verify that arch/mips/mm/c-r4k.c knows how to handle your system. Ralf PS: Seems your caps lock key occasionally gets stuck ;-) From owner-linux-mips@oss.sgi.com Thu Jan 24 21:39:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P5dcG24747 for linux-mips-outgoing; Thu, 24 Jan 2002 21:39:38 -0800 Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [146.215.0.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P5dVP24711; Thu, 24 Jan 2002 21:39:31 -0800 Received: from mail1.sony.co.jp (GateKeeper11.Sony.CO.JP [146.215.0.74]) by ns4.sony.co.jp (R8/Sony) with ESMTP id g0P4dKY54130; Fri, 25 Jan 2002 13:39:20 +0900 (JST) Received: from mail1.sony.co.jp (localhost [127.0.0.1]) by mail1.sony.co.jp (R8) with ESMTP id g0P4dJl07412; Fri, 25 Jan 2002 13:39:19 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail1.sony.co.jp (R8) with ESMTP id g0P4dIg07377; Fri, 25 Jan 2002 13:39:18 +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 NAA01226; Fri, 25 Jan 2002 13:44:02 +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 NAA09285; Fri, 25 Jan 2002 13:39:17 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g0P4dHJ13115; Fri, 25 Jan 2002 13:39:17 +0900 (JST) To: ralf@oss.sgi.com Cc: kevink@mips.com, aj@suse.de, hjl@lucon.org, linux-mips@oss.sgi.com Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) In-Reply-To: <20020124105915.A838@dea.linux-mips.net> References: <005301c1a368$87d27ed0$10eca8c0@grendel> <20020123145634M.machida@sm.sony.co.jp> <20020124105915.A838@dea.linux-mips.net> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020125133916X.machida@sm.sony.co.jp> Date: Fri, 25 Jan 2002 13:39:16 +0900 From: Machida Hiroyuki X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 616 Lines: 21 From: Ralf Baechle Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Thu, 24 Jan 2002 10:59:15 -0800 > There is a method for mutual exclusion called Dekker's Algorithem (sp?) > which only requires just atomic stores and can be implemented in plain > C. Downside is it's weak performance that renders it pretty much a CS > only thing. Dekker's Algorithem and Lamport's Algorithm are not match for test_and_set() interface in glibc. In test_and_set(), mutex var is INT, but those algorimths need to share addtional variables. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Fri Jan 25 00:22:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P8MbH26489 for linux-mips-outgoing; Fri, 25 Jan 2002 00:22:37 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P8MUP26438; Fri, 25 Jan 2002 00:22:30 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA19242; Thu, 24 Jan 2002 23:22:19 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA05143; Thu, 24 Jan 2002 23:22:16 -0800 (PST) Message-ID: <001001c1a571$7a7a08b0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Machida Hiroyuki" Cc: , , References: <20020122232529V.machida@sm.sony.co.jp> <005301c1a368$87d27ed0$10eca8c0@grendel> <20020123145634M.machida@sm.sony.co.jp> <20020124105915.A838@dea.linux-mips.net> Subject: Re: patches for test-and-set without ll/sc (Re: thread-ready ABIs) Date: Fri, 25 Jan 2002 08:25:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 981 Lines: 24 > > > It should in principle be SMP safe. > > > > I don't think so. > > > > Suppose that > > THREAD A is bound to CPU A and THREAD B is bound to CPU B. > > THREAD A and THREAD B are running on_atomic_inc_nollsc(). > > Two threads are really running at the same time, without > > context-switch. In this case nobody clear k1. > > There is a method for mutual exclusion called Dekker's Algorithem (sp?) > which only requires just atomic stores and can be implemented in plain > C. Downside is it's weak performance that renders it pretty much a CS > only thing. Having actually ised Dekker's algorithm once in an industrial application (2 Z80's with a shared buffer) some 20-odd years ago, I can say that it does work, but caution that, while in theory one can scale it to arbitrary number of CPUs, the time of the operation expands by something like the square of the number of CPUs involved. It's minimally acceptable for 2 CPUs. More than that... Kevin K. From owner-linux-mips@oss.sgi.com Fri Jan 25 09:14:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PHEKX08403 for linux-mips-outgoing; Fri, 25 Jan 2002 09:14:20 -0800 Received: from river-bank.demon.co.uk (river-bank.demon.co.uk [193.237.18.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PHEHP08391 for ; Fri, 25 Jan 2002 09:14:17 -0800 Received: from river-bank.demon.co.uk(ratty.river-bank.demon.co.uk[192.168.0.4]) (1024 bytes) by river-bank.demon.co.uk via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 25 Jan 2002 16:14:13 +0000 (GMT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-12) Message-ID: <3C51838A.174F8712@river-bank.demon.co.uk> Date: Fri, 25 Jan 2002 16:10:50 +0000 From: Phil Thompson Organization: At Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Generic DISCONTIGMEM Support on 32bit MIPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 432 Lines: 13 I'm working on a port of 32bit MIPS to a board with several large holes in the memory map. So I need to re-implement paging_init() and mem_init(). The first question is: has anybody already done this? Particularly as, once you've identified where the holes are, the code isn't board specific. If not then I'll try to work out what needed from the corresponding mips64 and ip27 code, but I'd appreciate any pointers. Thanks, Phil From owner-linux-mips@oss.sgi.com Fri Jan 25 10:12:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PICwJ19306 for linux-mips-outgoing; Fri, 25 Jan 2002 10:12:58 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PICpP19285; Fri, 25 Jan 2002 10:12:51 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA24804; Fri, 25 Jan 2002 09:12:41 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA02330; Fri, 25 Jan 2002 09:12:30 -0800 (PST) Message-ID: <002b01c1a5c3$f1b71d80$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Girish Gulawani" Cc: "MIPS/Linux List \(SGI\)" References: <3C505900.9685DDE3@cotw.com> <003901c1a532$d01576e0$de920dd3@gol.com> <20020124174521.B8860@dea.linux-mips.net> Subject: Re: MIPS/Linux NonSGI Date: Fri, 25 Jan 2002 18:15:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 864 Lines: 29 > On Fri, Jan 25, 2002 at 08:41:10AM +0900, Girish Gulawani wrote: > > > i'm trying to bringup linux 2.4.[2|9] on our board based on LSI mips r4k > > core. [snip] > Seems pretty obvious that cacheflushing for your system is broken. Sure sounds like it. > Verify that arch/mips/mm/c-r4k.c knows how to handle your system. > > Ralf LSI has done a number of R3K and R4K-like designs under their MIPS architecture license which have features that differ from the main stream of MIPS CPUs where the OS is concerned. Cache manipulation is a case in point. If it's not obvious to you from the cache management code, compare the relevant sections of your CPU manual with the MIPS32 spec (which I think is on the web somewhere at www.mips.com) or a copy of the R4000 manual if you can find one kicking around somewhere. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Fri Jan 25 13:44:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PLiZt28123 for linux-mips-outgoing; Fri, 25 Jan 2002 13:44:35 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0PLiXP28117 for ; Fri, 25 Jan 2002 13:44:33 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0PKiT201623; Fri, 25 Jan 2002 12:44:29 -0800 Date: Fri, 25 Jan 2002 12:44:29 -0800 From: Ralf Baechle To: Phil Thompson Cc: linux-mips@oss.sgi.com Subject: Re: Generic DISCONTIGMEM Support on 32bit MIPS Message-ID: <20020125124429.A961@dea.linux-mips.net> References: <3C51838A.174F8712@river-bank.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C51838A.174F8712@river-bank.demon.co.uk>; from phil@river-bank.demon.co.uk on Fri, Jan 25, 2002 at 04:10:50PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 687 Lines: 18 On Fri, Jan 25, 2002 at 04:10:50PM +0000, Phil Thompson wrote: > I'm working on a port of 32bit MIPS to a board with several large holes > in the memory map. So I need to re-implement paging_init() and > mem_init(). > > The first question is: has anybody already done this? Particularly as, > once you've identified where the holes are, the code isn't board > specific. > > If not then I'll try to work out what needed from the corresponding > mips64 and ip27 code, but I'd appreciate any pointers. Great, I was already planning to do this next. Discontiguous memory is a common problem on MIPS systems; it's almost standard for systems that have more than 256mb of memory. Ralf From owner-linux-mips@oss.sgi.com Fri Jan 25 13:46:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PLkp428640 for linux-mips-outgoing; Fri, 25 Jan 2002 13:46:51 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PLklP28619 for ; Fri, 25 Jan 2002 13:46:47 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16UDF6-0003SW-00; Fri, 25 Jan 2002 14:46:36 -0600 Message-ID: <3C51C427.392B40E4@cotw.com> Date: Fri, 25 Jan 2002 14:46:31 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: New MIPS cross toolchain using glibc-2.2.5pre1.... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 945 Lines: 27 Greetings. First I want to thank HJ Lu for his patience as I traded quite a few emails with him trying to get this up and working. I was successful with building a new MIPS toolchain using the following: binutils-cvs-LATEST gcc-cvs-LATEST (gcc-3.1) glibc-2.2.5pre1 It compiles kernels and user apps with no problems. I have made everything available here: ftp://ftp.cotw.com/Linux/MIPS/toolchain/experimental Most important is the patch required to glibc-2.2.5pre1 in order for a MIPS toolchain to even build. The other important item is that it is absolutely necessary to specify the '--enable-kernel=2.4.X' option when configuring glibc, or you will have problems with undefined versioned symbols related to GLIBC_2.1. There is also a shell script in the 'sources' directory that shows the exact steps that I used. Hopefully this will be of some use to someone. Cheers. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Fri Jan 25 14:20:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PMKeW03294 for linux-mips-outgoing; Fri, 25 Jan 2002 14:20:40 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PMKbP03279 for ; Fri, 25 Jan 2002 14:20:37 -0800 Received: (qmail 18384 invoked from network); 25 Jan 2002 21:20:34 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 25 Jan 2002 21:20:34 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16UDlx-0001TS-00; Fri, 25 Jan 2002 14:20:33 -0700 Date: Fri, 25 Jan 2002 14:20:33 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Phil Thompson cc: linux-mips@oss.sgi.com Subject: Re: Generic DISCONTIGMEM Support on 32bit MIPS In-Reply-To: <3C51838A.174F8712@river-bank.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 548 Lines: 22 On Fri, 25 Jan 2002, Phil Thompson wrote: > The first question is: has anybody already done this? Particularly as, > once you've identified where the holes are, the code isn't board > specific. Is this of any help? http://kt.zork.net/kernel-traffic/kt20011112_141.html#6 William Irwin [*] announced: A number of people have expressed a wish to replace the bitmap-based bootmem allocator with one that tracks ranges explicitly. I have written such a replacement in order to deal with some of the situations I have encountered. [...] Jason From owner-linux-mips@oss.sgi.com Fri Jan 25 14:51:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PMpNi09859 for linux-mips-outgoing; Fri, 25 Jan 2002 14:51:23 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PMpIP09837 for ; Fri, 25 Jan 2002 14:51:18 -0800 Received: from wli by holomorphy with local (Exim 3.33 #1 (Debian)) id 16UEGP-0008SQ-00; Fri, 25 Jan 2002 13:52:01 -0800 Date: Fri, 25 Jan 2002 13:52:01 -0800 From: William Lee Irwin III To: Jason Gunthorpe Cc: Phil Thompson , linux-mips@oss.sgi.com Subject: Re: Generic DISCONTIGMEM Support on 32bit MIPS Message-ID: <20020125135201.I872@holomorphy.com> References: <3C51838A.174F8712@river-bank.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from jgg@debian.org on Fri, Jan 25, 2002 at 02:20:33PM -0700 Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1526 Lines: 38 On Fri, 25 Jan 2002, Phil Thompson wrote: >> The first question is: has anybody already done this? Particularly as, >> once you've identified where the holes are, the code isn't board >> specific. On Fri, Jan 25, 2002 at 02:20:33PM -0700, Jason Gunthorpe wrote: > Is this of any help? > http://kt.zork.net/kernel-traffic/kt20011112_141.html#6 > William Irwin [*] announced: > A number of people have expressed a wish to replace the bitmap-based > bootmem allocator with one that tracks ranges explicitly. I have written > such a replacement in order to deal with some of the situations I have > encountered. > [...] I ran into some code acceptance issues in three places: (1) I used trees (2) I didn't go about changing the arch-specific code to actually simplify the calling sequence as it appeared in arch-specific code. (3) it is a whole-hog rewrite of bootmem.c, which perhaps attracted flak from the original author The last bits of this I released are in: ftp://ftp.kernel.org/pub/linux/kernel/people/wli/bootmem/ I'm not sure it addresses all the issues that arise here -- largely it just avoids some code complexity in laying out the bootmem bitmaps. DISCONTIGMEM as I understand it just minimally adjusts the core bootmem so it can handle things at all, and then focuses on the actual hard parts needed for things to work well on larger systems. (Of course, that's an extremely vague description of the difference, but I won't go about reciting featuresets aside from this high-level stuff.) Cheers, Bill From owner-linux-mips@oss.sgi.com Sat Jan 26 00:46:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q8k2416580 for linux-mips-outgoing; Sat, 26 Jan 2002 00:46:02 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q8jkP16533 for ; Sat, 26 Jan 2002 00:45:46 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 437FC125C0; Fri, 25 Jan 2002 23:45:43 -0800 (PST) Date: Fri, 25 Jan 2002 23:45:42 -0800 From: "H . J . Lu" To: GNU C Library , linux-mips@oss.sgi.com Subject: A linuxthreads bug on mips? Message-ID: <20020125234542.A31028@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3392 Lines: 151 Here is a modified ex2.c which only uses one conditional variable. It works fine on x86. But it leads to dead lock on mips where both producer and consumer are suspended. Is this testcase correct? H.J. ---- /* The classic producer-consumer example. Illustrates mutexes and conditions. All integers between 0 and 9999 should be printed exactly twice, once to the right of the arrow and once to the left. */ #include #include "pthread.h" #define BUFFER_SIZE 16 #define thread_cycles 10 #define thread_pairs 10 #define iters 10000 /* Circular buffer of integers. */ struct prodcons { int buffer[BUFFER_SIZE]; /* the actual data */ pthread_mutex_t lock; /* mutex ensuring exclusive access to buffer */ int readpos, writepos; /* positions for reading and writing */ pthread_cond_t cond; /* signaled when buffer is not empty nor full */ }; /* Initialize a buffer */ static void init (struct prodcons *b) { pthread_mutex_init (&b->lock, NULL); pthread_cond_init (&b->cond, NULL); b->readpos = 0; b->writepos = 0; } /* Store an integer in the buffer */ static void put (struct prodcons *b, int data) { pthread_mutex_lock (&b->lock); /* Wait until buffer is not full */ while ((b->writepos + 1) % BUFFER_SIZE == b->readpos) { pthread_cond_wait (&b->cond, &b->lock); /* pthread_cond_wait reacquired b->lock before returning */ } /* Write the data and advance write pointer */ b->buffer[b->writepos] = data; b->writepos++; if (b->writepos >= BUFFER_SIZE) b->writepos = 0; /* Signal that the buffer is now not empty */ pthread_cond_signal (&b->cond); pthread_mutex_unlock (&b->lock); } /* Read and remove an integer from the buffer */ static int get (struct prodcons *b) { int data; pthread_mutex_lock (&b->lock); /* Wait until buffer is not empty */ while (b->writepos == b->readpos) { pthread_cond_wait (&b->cond, &b->lock); } /* Read the data and advance read pointer */ data = b->buffer[b->readpos]; b->readpos++; if (b->readpos >= BUFFER_SIZE) b->readpos = 0; /* Signal that the buffer is now not full */ pthread_cond_signal (&b->cond); pthread_mutex_unlock (&b->lock); return data; } /* A test program: one thread inserts integers from 1 to 10000, the other reads them and prints them. */ #define OVER (-1) static void * producer (void *data) { struct prodcons *buffer = (struct prodcons *) data; int n; for (n = 0; n < 10000; n++) { #if 0 printf ("%d --->\n", n); #endif put (buffer, n); } put (buffer, OVER); return NULL; } static void * consumer (void *data) { struct prodcons *buffer = (struct prodcons *) data; int d; while (1) { d = get (buffer); if (d == OVER) break; #if 0 printf ("---> %d\n", d); #endif } return NULL; } struct prodcons buffer [thread_pairs]; int main (void) { pthread_t prod[thread_pairs]; pthread_t cons[thread_pairs]; int i, j; for (i = 0; i < thread_pairs; i++) init (&buffer [i]); for (j = 0; j < thread_cycles; j++) { for (i = 0; i < thread_pairs; i++) { pthread_create (&prod[i], NULL, producer, (void *) &(buffer [i])); pthread_create (&cons[i], NULL, consumer, (void *) &(buffer [i])); } for (i = 0; i < thread_pairs; i++) { pthread_join (prod[i], NULL); pthread_join (cons[i], NULL); } } return 0; } From owner-linux-mips@oss.sgi.com Sat Jan 26 00:54:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q8sfu17921 for linux-mips-outgoing; Sat, 26 Jan 2002 00:54:41 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q8sbP17910 for ; Sat, 26 Jan 2002 00:54:37 -0800 Received: from e147195.ppp.asahi-net.or.jp (HELO nazneen) (211.13.147.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jan 2002 07:54:34 -0000 Message-ID: <009b01c1a63e$bf045580$c3930dd3@gol.com> From: "Girish Gulawani" To: "Kevin D. Kissell" , "Ralf Baechle" Cc: "MIPS/Linux List \(SGI\)" References: <3C505900.9685DDE3@cotw.com> <003901c1a532$d01576e0$de920dd3@gol.com> <20020124174521.B8860@dea.linux-mips.net> <002b01c1a5c3$f1b71d80$10eca8c0@grendel> Subject: Re: MIPS/Linux NonSGI Date: Sat, 26 Jan 2002 16:54:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1438 Lines: 31 hi, again. thanks a lot for quick reply. re-compiled the kernels, using egcc-2.91, but no luck. is there still older version i should be using? & i guess you were referring to file arch/mips/mm/r4xx.c. the board support is detected & load_mmu_r4k() is called. so this looks okay. yes, LSI CPUs differ from the main stream, right in the cache opcodes. but this problem apart, as i have been using kernel in un-cached mode & anyway i have build almost all the commands by static linking. hence shared library issue i shall deal with later. ***right now my main concern is file system getting corrupted. the bdflush/update processes flushes the inode buffers & corrupts the fs. to be precise the "update" process wakes up & writes some buffers to the disk from the function sync_old_buffers() in fs/buffer.c. the pci-ide bus mastering controller is non standard & that the driver is also self written. however since reads from the disk are working as i can see all the commands getting loaded & executed, the writes also should be working properly, as they differ only in a command to the controller. so where could be the problem? please help me. many thanks & best regards, girish. ps. ralf, liked your comment abt my caps lock getting stuck;-) it just shows how desperate i'm in solving this problem. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Sat Jan 26 03:41:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QBfH110746 for linux-mips-outgoing; Sat, 26 Jan 2002 03:41:17 -0800 Received: from river-bank.demon.co.uk (river-bank.demon.co.uk [193.237.18.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QBf5P10722; Sat, 26 Jan 2002 03:41:06 -0800 Received: from river-bank.demon.co.uk(ratty.river-bank.demon.co.uk[192.168.0.4]) (1574 bytes) by river-bank.demon.co.uk via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sat, 26 Jan 2002 10:41:04 +0000 (GMT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-12) Message-ID: <3C5286ED.497B2E82@river-bank.demon.co.uk> Date: Sat, 26 Jan 2002 10:37:34 +0000 From: Phil Thompson Organization: At Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: Generic DISCONTIGMEM Support on 32bit MIPS References: <3C51838A.174F8712@river-bank.demon.co.uk> <20020125124429.A961@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 826 Lines: 23 Ralf Baechle wrote: > > On Fri, Jan 25, 2002 at 04:10:50PM +0000, Phil Thompson wrote: > > > I'm working on a port of 32bit MIPS to a board with several large holes > > in the memory map. So I need to re-implement paging_init() and > > mem_init(). > > > > The first question is: has anybody already done this? Particularly as, > > once you've identified where the holes are, the code isn't board > > specific. > > > > If not then I'll try to work out what needed from the corresponding > > mips64 and ip27 code, but I'd appreciate any pointers. > > Great, I was already planning to do this next. Discontiguous memory is a > common problem on MIPS systems; it's almost standard for systems that > have more than 256mb of memory. You may still be quicker as I'm starting from a position of almost complete ignorance. Phil From owner-linux-mips@oss.sgi.com Sat Jan 26 09:14:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QHEk228770 for linux-mips-outgoing; Sat, 26 Jan 2002 09:14:46 -0800 Received: from xyzzy.stargate.net ([198.144.45.122]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QHEhP28764 for ; Sat, 26 Jan 2002 09:14:43 -0800 Received: (from justin@localhost) by xyzzy.stargate.net (8.11.6/8.11.6) id g0QGFdJ01998; Sat, 26 Jan 2002 11:15:39 -0500 X-Authentication-Warning: xyzzy.stargate.net: justin set sender to justinca@ri.cmu.edu using -f Subject: Re: A linuxthreads bug on mips? From: Justin Carlson To: hjl@lucon.org Cc: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 26 Jan 2002 11:15:38 -0500 Message-Id: <1012061738.1322.22.camel@xyzzy.stargate.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 428 Lines: 12 On Sat, 2002-01-26 at 02:45, H . J . Lu wrote: > Here is a modified ex2.c which only uses one conditional variable. It > works fine on x86. But it leads to dead lock on mips where both > producer and consumer are suspended. Is this testcase correct? > I stared at it for a while and see nothing wrong with it. Well, ok, iters is #define'd but never used. But somehow I doubt that's the root of your problems. ;) -Justin From owner-linux-mips@oss.sgi.com Sun Jan 27 01:23:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R9NZj31769 for linux-mips-outgoing; Sun, 27 Jan 2002 01:23:35 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R9MjP31655 for ; Sun, 27 Jan 2002 01:22:45 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g0R8Mgu11460 for linux-mips@oss.sgi.com; Sun, 27 Jan 2002 00:22:42 -0800 Date: Sun, 27 Jan 2002 00:22:42 -0800 From: Matthew Dharm To: linux-mips@oss.sgi.com Subject: Help with OOPSes, anyone? Message-ID: <20020127002242.A11373@momenco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 21508 Lines: 466 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline So, I'm back to trying to get Linux running on our boards, and I'm having a problem I'd like some help with... (See http://www.momenco.com/products/ocelot if you're interested.) At one point, we had 2.4.5 working on this board. That was the result of joint work between myself, RedHat, and MontaVista. Seemed to work pretty well, given that we had basically no userspace to work with. So, while it seemed functional, it's not much of a datapoint. So, I did a cvs update, and tried to build 2.4.17. Lo and behold, it still compiles. And it even runs. And the RedHat 7.1 userspace from oss.sgi.com even seems to work, mostly. But, under certain conditions, the kernel OOPSes. Attached to this message are a few of those OOPSes (serial console is wonderful!) along with the ksymoops output. I think the read_lsmod() warning is bogus, because there are, actually, no modules loaded. My instincts are telling me that these are all being caused by the same problem, but I'll be damned if I can figure out what that is. Caching is a good suspect, but that's just because it's always a good suspect. What does work is a ping -f to the board... so I think the interrupt code is rock-solid. It's pretty simple anyway, so I'm not suprised that's a problem. While we did have some problem supporting our boards that have 512MB on them, the board I'm testing with only has 128MB. Dealing with the 512MB problems (which, I understand, are caused by the cache-flush routines trying to flush too much), is on the TODO list, but I don't think those problems are affecting me right now. Load does seem to be a factor. Big compiles, lots of NFS traffic, that sort of thing seems to be the triggering factor. It's easy to duplicate, given a few minutes. Oddly enough, lite loads or idle doesn't trigger this -- I FTPed the SRPM for wget and built it without any problems. Heck, it even works! But when I try to build something bigger (say, ncftp or glibc), it dies an ugly death. Heck, I could FTP, build, and use ksymoops natively on the board without any problems. Lots of things work fine, but sometimes.... I know Ralf has one of our boards, but I don't know if he's in the same country as that board... Ralf? In these OOPSes, one is caused by some code in unaligned.c -- I've seen several (many) like this, tho I only captured and decoded one. The code in question seems to be one of those "you can never get here" situations, which makes me really worry. The other two look like some form of NULL-pointer dereference. I've tried several different configurations, stripping down drivers as I go. I'm going to continue that tomorrow/monday, but I don't have high hopes that will fix the problem. I'm thinking about trying CONFIG_MIPS_UNCACHED, but I don't know if that works on an RM7000 processor -- the L1 and L2 are built-in to the processor, and I don't think the L1 can be deactivated. Then again, I don't know how CONFIG_MIPS_UNCACHED works, so if someone would like to clue me in on the subject, I'd really appreciate it. Another thing I'm going to try is an ELF image from that Redhat/Montavista work, to see if it shows the same problems. That datapoint will be useful also. If anyone has any clues as to what's going on, I'd really appreciate it. Anyone? Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops.in" Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 345: $0 : 00000000 90045400 813fb004 021dc71d 813fb000 00000003 00000001 85a19020 $8 : 00000028 80242788 00000000 0065002c 3c520292 00000000 3c520292 00000000 $16: 021dc71d 813fa3fc 00000001 90045401 813fb004 802c3aa8 00000003 00008001 $24: 8129ea64 85750cc0 813f6000 813f7e90 813f7e90 802396d8 Hi : 00000000 Lo : 0000000e epc : 8010a3fc Not tainted Status: 90045402 Cause : 00008010 Process rpciod (pid: 8, stackpage=813f6000) Stack: 00000002 8023a360 85747274 90045401 813fa000 813fa3fc 85750bc0 802c64c8 802c64c8 8029541c 813ff410 00000000 802396d8 802396bc 85750bc0 813fe8e0 85e2c140 85a19620 813fa000 8023904c 813fa314 85747700 85750bc0 813fe8e0 85750bc0 85750c14 00000005 8023b1a4 85750c14 85750bc0 00000005 802c64c8 00000000 85750bc0 8023a92c 00008400 acd8a3f8 85461000 3c520291 00000000 00000000 ... Call Trace: [<8023a360>] [<802396d8>] [<802396bc>] [<8023904c>] [<8023b1a4>] [<8023a92c>] [<8023ab9c>] [<8023aa54>] [<8023b7b8>] [<8023b620>] [<8023b620>] [<80100da0>] [<8023bb8c>] [<8023c1a0>] [<80100d90>] Code: 00c09021 3c15802c 26b53aa8 <8e05fffc> 8ca20000 00561024 1040002f 00001821 40116000 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops.out" ksymoops 2.4.0 on mips 2.4.17. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17/ (default) -m /boot/System.map-2.4.17 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? $0 : 00000000 90045400 813fb004 021dc71d 813fb000 00000003 00000001 85a19020 $8 : 00000028 80242788 00000000 0065002c 3c520292 00000000 3c520292 00000000 $16: 021dc71d 813fa3fc 00000001 90045401 813fb004 802c3aa8 00000003 00008001 $24: 8129ea64 85750cc0 813f6000 813f7e90 813f7e90 802396d8 epc : 8010a3fc Not tainted Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: 90045402 Cause : 00008010 Process rpciod (pid: 8, stackpage=813f6000) Stack: 00000002 8023a360 85747274 90045401 813fa000 813fa3fc 85750bc0 802c64c8 802c64c8 8029541c 813ff410 00000000 802396d8 802396bc 85750bc0 813fe8e0 85e2c140 85a19620 813fa000 8023904c 813fa314 85747700 85750bc0 813fe8e0 85750bc0 85750c14 00000005 8023b1a4 85750c14 85750bc0 00000005 802c64c8 00000000 85750bc0 8023a92c 00008400 acd8a3f8 85461000 3c520291 00000000 00000000 ... Call Trace: [<8023a360>] [<802396d8>] [<802396bc>] [<8023904c>] [<8023b1a4>] [<8023a92c>] [<8023ab9c>] [<8023aa54>] [<8023b7b8>] [<8023b620>] [<8023b620>] [<80100da0>] [<8023bb8c>] [<8023c1a0>] [<80100d90>] Code: 00c09021 3c15802c 26b53aa8 <8e05fffc> 8ca20000 00561024 1040002f 00001821 40116000 >>PC; 8010a3fc <__wake_up+6c/198> <===== Trace; 8023a360 Trace; 802396d8 Trace; 802396bc Trace; 8023904c Trace; 8023b1a4 Trace; 8023a92c <__rpc_execute+378/3a0> Trace; 8023ab9c <__rpc_schedule+1a0/20c> Trace; 8023aa54 <__rpc_schedule+58/20c> Trace; 8023b7b8 Trace; 8023b620 Trace; 8023b620 Trace; 80100da0 Trace; 8023bb8c Trace; 8023c1a0 Trace; 80100d90 Code; 8010a3f0 <__wake_up+60/198> 00000000 <_PC>: Code; 8010a3f0 <__wake_up+60/198> 0: 00c09021 move s2,a2 Code; 8010a3f4 <__wake_up+64/198> 4: 3c15802c lui s5,0x802c Code; 8010a3f8 <__wake_up+68/198> 8: 26b53aa8 addiu s5,s5,15016 Code; 8010a3fc <__wake_up+6c/198> <===== c: 8e05fffc lw a1,-4(s0) <===== Code; 8010a400 <__wake_up+70/198> 10: 8ca20000 lw v0,0(a1) Code; 8010a404 <__wake_up+74/198> 14: 00561024 and v0,v0,s6 Code; 8010a408 <__wake_up+78/198> 18: 1040002f beqz v0,d8 <_PC+0xd8> 8010a4c8 <__wake_up+138/198> Code; 8010a40c <__wake_up+7c/198> 1c: 00001821 move v1,zero Code; 8010a410 <__wake_up+80/198> 20: 40116000 mfc0 s1,$12 Kernel panic: Aiee, killing interrupt handler! 2 warnings issued. Results may not be reliable. --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops2.in" Unable to handle kernel paging request at virtual address 00000020, epc == 8010a19c, ra <1>Unable to handle kernel paging request at virtual address 00000062, epc == 80206ce4, ra == 80217c2c Oops in fault.c:do_page_fault, line 204: $0 : 00000000 00000001 812efecc 812efe60 00000000 802e0020 0000ab22 812efecc $8 : c0a80112 00000000 00000000 00000002 00000000 00000000 802e3626 00000000 $16: 812efecc 00001d3c 812ee8a0 813fc620 87156b20 812ee8a0 00000000 812ee8cc $24: 00000000 85919c47 85918000 85919a50 87156bf8 80217c2c Hi : 00000000 Lo : 00000e00 epc : 80206ce4 Not tainted Status: b0045403 Cause : 00008008 Process cc1 (pid: 3366, stackpage=85918000) Stack: 87156bf8 8021636c c0a80101 00000000 00000000 801f3ee0 812efc80 81296140 81296140 87156b20 87156bf8 81296140 813fc620 00000000 87156bf8 00001d3c 812efee0 00000000 87156b20 00000020 812ee8a0 812ee8cc 80217c2c 80217b38 812ee8a0 802f6c94 801ef2b0 812fb590 87156bf8 87156b20 87156bf8 802c64c0 802b68a0 802b68c0 00800000 00000060 00000010 8021aa50 00000056 812ea140 00000001 ... Call Trace: [<8021636c>] [<801f3ee0>] [<80217c2c>] [<80217b38>] [<801ef2b0>] [<8021aa50>] [<8021b62c>] [<80203978>] [<80236c68>] [<8011773c>] [<8011354c>] [<801f421c>] [<801133dc>] [<8011782c>] [<80112e8c>] [<8010631c>] [<80106630>] [<801065ec>] [<8019609c>] [<8012b808>] [<8023b1e4>] [<80117448>] [<801a7aec>] [<801a7aec>] [<8010dd00>] [<8010dd8c>] [<8010debc>] [<8010e2b8>] [<8010e184>] [<80247686>] [<80108c3c>] [<8012b808>] [<80247628>] [<8010a19c>] [<801033f0>] [<8012b460>] [<8011ed48>] [<8011ede8>] [<8011ee00>] [<80109938>] [<8011efd0>] ... Code: 8ea20080 8ea3007c 8e64000c <94850062> 00431023 0045102a 1040002c 8eb1000c 8c8200fc Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops2.out" ksymoops 2.4.0 on mips 2.4.17. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17/ (default) -m /boot/System.map-2.4.17 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel paging request at virtual address 00000020, epc == 8010a19c, ra <1>Unable to handle kernel paging request at virtual address 00000062, epc == 80206ce4, ra == 80217c2c $0 : 00000000 00000001 812efecc 812efe60 00000000 802e0020 0000ab22 812efecc $8 : c0a80112 00000000 00000000 00000002 00000000 00000000 802e3626 00000000 $16: 812efecc 00001d3c 812ee8a0 813fc620 87156b20 812ee8a0 00000000 812ee8cc $24: 00000000 85919c47 85918000 85919a50 87156bf8 80217c2c epc : 80206ce4 Not tainted Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: b0045403 Cause : 00008008 Process cc1 (pid: 3366, stackpage=85918000) Stack: 87156bf8 8021636c c0a80101 00000000 00000000 801f3ee0 812efc80 81296140 81296140 87156b20 87156bf8 81296140 813fc620 00000000 87156bf8 00001d3c 812efee0 00000000 87156b20 00000020 812ee8a0 812ee8cc 80217c2c 80217b38 812ee8a0 802f6c94 801ef2b0 812fb590 87156bf8 87156b20 87156bf8 802c64c0 802b68a0 802b68c0 00800000 00000060 00000010 8021aa50 00000056 812ea140 00000001 ... Call Trace: [<8021636c>] [<801f3ee0>] [<80217c2c>] [<80217b38>] [<801ef2b0>] [<8021aa50>] [<8021b62c>] [<80203978>] [<80236c68>] [<8011773c>] [<8011354c>] [<801f421c>] [<801133dc>] [<8011782c>] [<80112e8c>] [<8010631c>] [<80106630>] [<801065ec>] [<8019609c>] [<8012b808>] [<8023b1e4>] [<80117448>] [<801a7aec>] [<801a7aec>] [<8010dd00>] [<8010dd8c>] [<8010debc>] [<8010e2b8>] [<8010e184>] [<80247686>] [<80108c3c>] [<8012b808>] [<80247628>] [<8010a19c>] [<801033f0>] [<8012b460>] [<8011ed48>] [<8011ede8>] [<8011ee00>] [<80109938>] [<8011efd0>] ... Warning (Oops_trace_line): garbage '...' at end of trace line ignored Code: 8ea20080 8ea3007c 8e64000c <94850062> 00431023 0045102a 1040002c 8eb1000c 8c8200fc >>RA; 80217c2c >>PC; 80206ce4 <===== Trace; 8021636c Trace; 801f3ee0 Trace; 80217c2c Trace; 80217b38 Trace; 801ef2b0 Trace; 8021aa50 Trace; 8021b62c Trace; 80203978 Trace; 80236c68 Trace; 8011773c Trace; 8011354c Trace; 801f421c Trace; 801133dc Trace; 8011782c Trace; 80112e8c Trace; 8010631c Trace; 80106630 Trace; 801065ec Trace; 8019609c Trace; 8012b808 <__alloc_pages+70/21c> Trace; 8023b1e4 Trace; 80117448 Trace; 801a7aec Trace; 801a7aec Trace; 8010dd00 <__call_console_drivers+68/94> Trace; 8010dd8c <_call_console_drivers+60/70> Trace; 8010debc Trace; 8010e2b8 Trace; 8010e184 Trace; 80247686 Trace; 80108c3c Trace; 8012b808 <__alloc_pages+70/21c> Trace; 80247628 Trace; 8010a19c Trace; 801033f0 Trace; 8012b460 <_alloc_pages+20/2c> Trace; 8011ed48 Trace; 8011ede8 Trace; 8011ee00 Trace; 80109938 Trace; 8011efd0 Code; 80206cd8 00000000 <_PC>: Code; 80206cd8 0: 8ea20080 lw v0,128(s5) Code; 80206cdc 4: 8ea3007c lw v1,124(s5) Code; 80206ce0 8: 8e64000c lw a0,12(s3) Code; 80206ce4 <===== c: 94850062 lhu a1,98(a0) <===== Code; 80206ce8 10: 00431023 subu v0,v0,v1 Code; 80206cec 14: 0045102a slt v0,v0,a1 Code; 80206cf0 18: 1040002c beqz v0,cc <_PC+0xcc> 80206da4 Code; 80206cf4 1c: 8eb1000c lw s1,12(s5) Code; 80206cf8 20: 8c8200fc lw v0,252(a0) Kernel panic: Aiee, killing interrupt handler! 3 warnings issued. Results may not be reliable. --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops3.in" Unable to handle kernel paging request at virtual address 00000004, epc == 801289b8, ra == 8016b820 Oops in fault.c:do_page_fault, line 204: $0 : 00000000 b0045400 00000000 00000000 81207600 81207608 000004c2 00000000 $8 : 813ff000 b0045401 00000000 00000000 00000000 00000000 00000065 87dcfd12 $16: 81207600 000000f0 00000001 812914e8 871ab960 8114f580 00000010 879278e0 $24: 00000000 2af984e0 8719a000 8719bd38 00000000 8016b820 Hi : 00000000 Lo : 00000780 epc : 801289b8 Not tainted Status: b0045402 Cause : 0000800c Process rpmq (pid: 666, stackpage=8719a000) Stack: 8719bd60 00000000 00000000 8017065c 00000000 81205b20 8016b820 8016df98 00000001 81205be0 8719bd60 8719bd60 00000000 879278e0 879278e0 8114f580 871ab960 0000001f 00001000 871ab960 879278e0 8016d870 000001d2 871ab960 00000004 8012b808 00001000 879278e0 00000000 879278e0 8114f580 871ab960 8016e338 879279a0 8114f580 00000000 80121cc8 0000001f 00000006 8012b460 8114f580 ... Call Trace: [<8017065c>] [<8016b820>] [<8016df98>] [<8016d870>] [<8012b808>] [<8016e338>] [<80121cc8>] [<8012b460>] [<80121dcc>] [<80121dd8>] [<801226cc>] [<80122a0c>] [<801fb26c>] [<801fb088>] [<801136e4>] [<80123060>] [<80122f58>] [<8016716c>] [<80112e8c>] [<8010631c>] [<80131bec>] [<801319e8>] [<80106630>] [<801065ec>] [<801057e8>] [<8019604c>] Code: 00000000 8d020004 8d030000 ac430000 8e040008 ac880004 ad040000 ad050004 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops3.out" ksymoops 2.4.0 on mips 2.4.17. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17/ (default) -m /boot/System.map-2.4.17 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel paging request at virtual address 00000004, epc == 801289b8, ra == 8016b820 $0 : 00000000 b0045400 00000000 00000000 81207600 81207608 000004c2 00000000 $8 : 813ff000 b0045401 00000000 00000000 00000000 00000000 00000065 87dcfd12 $16: 81207600 000000f0 00000001 812914e8 871ab960 8114f580 00000010 879278e0 $24: 00000000 2af984e0 8719a000 8719bd38 00000000 8016b820 epc : 801289b8 Not tainted Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: b0045402 Cause : 0000800c Process rpmq (pid: 666, stackpage=8719a000) Stack: 8719bd60 00000000 00000000 8017065c 00000000 81205b20 8016b820 8016df98 00000001 81205be0 8719bd60 8719bd60 00000000 879278e0 879278e0 8114f580 871ab960 0000001f 00001000 871ab960 879278e0 8016d870 000001d2 871ab960 00000004 8012b808 00001000 879278e0 00000000 879278e0 8114f580 871ab960 8016e338 879279a0 8114f580 00000000 80121cc8 0000001f 00000006 8012b460 8114f580 ... Call Trace: [<8017065c>] [<8016b820>] [<8016df98>] [<8016d870>] [<8012b808>] [<8016e338>] [<80121cc8>] [<8012b460>] [<80121dcc>] [<80121dd8>] [<801226cc>] [<80122a0c>] [<801fb26c>] [<801fb088>] [<801136e4>] [<80123060>] [<80122f58>] [<8016716c>] [<80112e8c>] [<8010631c>] [<80131bec>] [<801319e8>] [<80106630>] [<801065ec>] [<801057e8>] [<8019604c>] Code: 00000000 8d020004 8d030000 ac430000 8e040008 ac880004 ad040000 ad050004 >>RA; 8016b820 >>PC; 801289b8 <===== Trace; 8017065c Trace; 8016b820 Trace; 8016df98 Trace; 8016d870 Trace; 8012b808 <__alloc_pages+70/21c> Trace; 8016e338 Trace; 80121cc8 Trace; 8012b460 <_alloc_pages+20/2c> Trace; 80121dcc Trace; 80121dd8 Trace; 801226cc Trace; 80122a0c Trace; 801fb26c Trace; 801fb088 Trace; 801136e4 <__run_task_queue+c8/e4> Trace; 80123060 Trace; 80122f58 Trace; 8016716c Trace; 80112e8c Trace; 8010631c Trace; 80131bec Trace; 801319e8 Trace; 80106630 Trace; 801065ec Trace; 801057e8 Trace; 8019604c Code; 801289ac 00000000 <_PC>: Code; 801289ac 0: 00000000 nop Code; 801289b0 4: 8d020004 lw v0,4(t0) Code; 801289b4 8: 8d030000 lw v1,0(t0) Code; 801289b8 <===== c: ac620004 sw v0,4(v1) <===== Code; 801289bc 10: ac430000 sw v1,0(v0) Code; 801289c0 14: 8e040008 lw a0,8(s0) Code; 801289c4 18: ac880004 sw t0,4(a0) Code; 801289c8 1c: ad040000 sw a0,0(t0) Code; 801289cc 20: ad050004 sw a1,4(t0) 2 warnings issued. Results may not be reliable. --KsGdsel6WgEHnImy-- From owner-linux-mips@oss.sgi.com Sun Jan 27 03:53:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RBrkr20766 for linux-mips-outgoing; Sun, 27 Jan 2002 03:53:46 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RBrcP20736 for ; Sun, 27 Jan 2002 03:53:38 -0800 Received: (qmail 24881 invoked from network); 27 Jan 2002 10:53:34 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 27 Jan 2002 10:53:34 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16UmwI-0002AP-00; Sun, 27 Jan 2002 03:53:34 -0700 Date: Sun, 27 Jan 2002 03:53:34 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: Matthew Dharm cc: linux-mips@oss.sgi.com Subject: Re: Help with OOPSes, anyone? In-Reply-To: <20020127002242.A11373@momenco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2975 Lines: 71 On Sun, 27 Jan 2002, Matthew Dharm wrote: > My instincts are telling me that these are all being caused by the same > problem, but I'll be damned if I can figure out what that is. Caching is a > good suspect, but that's just because it's always a good suspect. I can tell you that I have managed to get 2.4.17 (patched up from the 2.4.15 in the linux_2_4 branch of SGI CVS) running very solidly on a RM7000 platform. I have carefully inspected the cache code, and I think that what is in the CVS tree is correct, though a little over-zealous :> I had to make some tweaks to the cache init on the RM7k, the existing code is wrong - but this is only important if your PROM does not do it for you. I can send you this code if you like. I'm using the Debian user land, 8M of L3 and a custom system controller. The machine works will enough to build complicated programs, run X stuff, etc. My board also has 512M of ram, (mapped from 0-512M, so no problems with highmem..). The box is nfs root'd and I've currently got a 8139 ethernet chip on it. > In these OOPSes, one is caused by some code in unaligned.c -- I've seen > several (many) like this, tho I only captured and decoded one. The code in Many of the oops's I've seen (while gettings this working) come from unaligned.c - haven't investigated why yet - they might actually be kernel unaligned memory references. While working on the SR7100, I noticed that various sorts of problems that result in a subtly broken system bus caused random faults in unaligned.c > -- I FTPed the SRPM for wget and built it without any problems. Heck, it > even works! But when I try to build something bigger (say, ncftp or > glibc), it dies an ugly death. Heck, I could FTP, build, and use ksymoops Just tried for you: mips:/tmp/ram# apt-get source -b ncftp [..] dpkg-deb: building package `ncftp' in `../ncftp_3.1.1-3_mipsel.deb'. mips:/tmp/ram# uname -a Linux mips 2.4.15-greased-turkey #407 Thu Jan 17 19:20:18 MST 2002 mips unknown mips:/tmp/ram# cat /proc/cpuinfo processor : 0 cpu model : RM7000 V3.2 FPU V2.0 BogoMIPS : 346.20 [..] mips:/tmp/ram# free total used free shared buffers cached Mem: 514100 124996 389104 0 16 98604 > hopes that will fix the problem. I'm thinking about trying > CONFIG_MIPS_UNCACHED, but I don't know if that works on an RM7000 processor It does. > -- the L1 and L2 are built-in to the processor, and I don't think the L1 > can be deactivated. Then again, I don't know how CONFIG_MIPS_UNCACHED They can.. It is worth trying without the L3 cache at the very least. I see your boards have the GT system controllers. You may want to validate they are configured correctly, you can get all sorts of really screwy results if they are not - there are lots of errata for those chips, and some models have a very intolerant (electricaly) sdram controller. Jason From owner-linux-mips@oss.sgi.com Sun Jan 27 05:11:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RDBf908038 for linux-mips-outgoing; Sun, 27 Jan 2002 05:11:41 -0800 Received: from fenris.scrooge.dk (213.237.12.36.adsl.ynoe.worldonline.dk [213.237.12.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RDBcP08027 for ; Sun, 27 Jan 2002 05:11:38 -0800 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.12.1/8.8.7) with ESMTP id g0RCBbJK026088 for ; Sun, 27 Jan 2002 13:11:37 +0100 From: "Soeren Laursen" To: linux-mips@oss.sgi.com Date: Sun, 27 Jan 2002 13:10:21 +0100 MIME-Version: 1.0 Subject: SMP support challenge L Reply-to: soeren.laursen@scrooge.dk Message-ID: <3C53FC3D.10933.55876D@localhost> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=ISO-8859-1 Content-description: Mail message body Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id g0RDBdP08028 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 439 Lines: 15 Hi, Just wondering if the SMP support is working at all. Sometimes there are patches that affect the SMP support. Got a challenge L with two R4xxx cpu's. Could start working on it via a nft root and give some feed back, fixes etc. Just one question. The terminal is broken and a guy at SGI Denmark told me how to create a null modem that worked on the challenge L but I have lost the paper. Any one got a clue? Best regards, Søren From owner-linux-mips@oss.sgi.com Sun Jan 27 10:36:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIaBc30412 for linux-mips-outgoing; Sun, 27 Jan 2002 10:36:11 -0800 Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIa8P30399 for ; Sun, 27 Jan 2002 10:36:08 -0800 Received: from [10.2.2.61] ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQL00H94Y864C@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Sun, 27 Jan 2002 09:36:06 -0800 (PST) Date: Sun, 27 Jan 2002 09:33:02 -0800 From: Pete Popov Subject: Re: Help with OOPSes, anyone? In-reply-to: <20020127002242.A11373@momenco.com> To: Matthew Dharm Cc: linux-mips Message-id: <1012152783.2026.7.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution/1.0.1 Content-type: text/plain Content-transfer-encoding: 7bit References: <20020127002242.A11373@momenco.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1076 Lines: 24 > But, under certain conditions, the kernel OOPSes. Attached to this message > are a few of those OOPSes (serial console is wonderful!) along with the > ksymoops output. I think the read_lsmod() warning is bogus, because there > are, actually, no modules loaded. > > My instincts are telling me that these are all being caused by the same > problem, but I'll be damned if I can figure out what that is. Caching is a > good suspect, but that's just because it's always a good suspect. Native compiles have indeed proven a great way to shake out hardware and software bugs. One suggestion. The rm7k, at least some of the silicon versions, have hardware erratas with the 'wait' instruction, used in the cpu_idle() loop. The CPU I have on one of the EV96100 boards, in combination with the gt96100, will hang hard every time if I don't disable the use of 'wait'. So while this bug might not have anything to do with what you're observing, I would ifdef-out the 'wait' instruction in check_wait(), just to be sure that that's not the cause or one of the problems. Pete From owner-linux-mips@oss.sgi.com Sun Jan 27 13:12:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RLCub18361 for linux-mips-outgoing; Sun, 27 Jan 2002 13:12:56 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RLCoP18358; Sun, 27 Jan 2002 13:12:51 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16Uvqu-0002X7-00; Sun, 27 Jan 2002 20:24:36 +0000 Subject: Re: thread-ready ABIs To: dan@debian.org (Daniel Jacobowitz) Date: Sun, 27 Jan 2002 20:24:36 +0000 (GMT) Cc: kevink@mips.com (Kevin D. Kissell), dom@algor.co.uk (Dominic Sweetman), ralf@oss.sgi.com (Ralf Baechle), drepper@redhat.com (Ulrich Drepper), uhler@mips.com (Mike Uhler), linux-mips@oss.sgi.com ("MIPS/Linux List (SGI)"), hjl@lucon.org (H . J . Lu) In-Reply-To: <20020122121330.A16110@nevyn.them.org> from "Daniel Jacobowitz" at Jan 22, 2002 12:13:30 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 422 Lines: 9 > Which it is. Fork shares no memory regions; vfork/clone share all > memory regions. AFAIK there is no share-heap-but-not-stack option in > Linux. Thats a design decision. At the point you don't have identical mappings for both threads you need two sets of page tables and you take all the performance hits that go with changing current tables on a schedule. Its a lot cheaper to use a different %esp for each thread From owner-linux-mips@oss.sgi.com Sun Jan 27 14:34:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RMYNf27390 for linux-mips-outgoing; Sun, 27 Jan 2002 14:34:23 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0RMYMP27383 for ; Sun, 27 Jan 2002 14:34:23 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0RLYJP16271 for linux-mips@oss.sgi.com; Sun, 27 Jan 2002 13:34:19 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RJtlP09785 for ; Sun, 27 Jan 2002 11:55:49 -0800 Received: from delllaptop ([208.187.134.69]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g0RItlx08858 for ; Sun, 27 Jan 2002 10:55:47 -0800 From: "Robert Rusek" To: Subject: Newbie Question Date: Sun, 27 Jan 2002 10:59:42 -0800 Message-ID: <001e01c1a764$c8753fe0$6401a8c0@delllaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C1A721.BA51FFE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1415 Lines: 44 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1A721.BA51FFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have been out of the loop for quite a while. Is there a functional or completed port of any of the RedHat flavors? If so how would I go about getting them? Thanks, -- Robert Rusek ------=_NextPart_000_001F_01C1A721.BA51FFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have = been out of=20 the loop for quite a while.  Is there a functional or completed = port of any=20 of the RedHat flavors?  If so how would I go about getting=20 them?
 
Thanks,
--
Robert Rusek
 
------=_NextPart_000_001F_01C1A721.BA51FFE0-- From owner-linux-mips@oss.sgi.com Sun Jan 27 14:40:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RMeXr28154 for linux-mips-outgoing; Sun, 27 Jan 2002 14:40:33 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id g0RMeUP28151 for ; Sun, 27 Jan 2002 14:40:30 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id g0RLeRu16334; Sun, 27 Jan 2002 13:40:27 -0800 Date: Sun, 27 Jan 2002 13:40:27 -0800 From: Ralf Baechle To: Soeren Laursen Cc: linux-mips@oss.sgi.com Subject: Re: SMP support challenge L Message-ID: <20020127134027.A2129@dea.linux-mips.net> References: <3C53FC3D.10933.55876D@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C53FC3D.10933.55876D@localhost>; from soeren.laursen@scrooge.dk on Sun, Jan 27, 2002 at 01:10:21PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 771 Lines: 18 On Sun, Jan 27, 2002 at 01:10:21PM +0100, Soeren Laursen wrote: > Just wondering if the SMP support is working at all. Sometimes > there are patches that affect the SMP support. > > Got a challenge L with two R4xxx cpu's. Could start working on it > via a nft root and give some feed back, fixes etc. > > Just one question. The terminal is broken and a guy at SGI Denmark > told me how to create a null modem that worked on the challenge L but > I have lost the paper. Any one got a clue? Null modems are described in a FAQ about the serial interface written by Christian Blum and others. Just google for it. The pinout as used on various SGI systems is described in IRIX's serial man page which if not on your system you can also find somewhere online. Ralf From owner-linux-mips@oss.sgi.com Sun Jan 27 15:24:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RNOCi00884 for linux-mips-outgoing; Sun, 27 Jan 2002 15:24:12 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RNO7P00871 for ; Sun, 27 Jan 2002 15:24:07 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g0RMO4Y18080; Sun, 27 Jan 2002 14:24:04 -0800 Date: Sun, 27 Jan 2002 14:24:04 -0800 From: Matthew Dharm To: Pete Popov Cc: linux-mips Subject: Re: Help with OOPSes, anyone? Message-ID: <20020127142404.B18041@momenco.com> References: <20020127002242.A11373@momenco.com> <1012152783.2026.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1012152783.2026.7.camel@localhost.localdomain>; from ppopov@mvista.com on Sun, Jan 27, 2002 at 09:33:02AM -0800 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1602 Lines: 38 Well, we're using very late RM7000 silicon, so I doubt that's the problem. But it's a good thing to look at, anyway. Tho it kinda conflicts with the datapoint that we actually had a stable kernel on this hardware before. Tho, like I said, that's not much of a datapoint -- more testing coming! Matt On Sun, Jan 27, 2002 at 09:33:02AM -0800, Pete Popov wrote: > > > But, under certain conditions, the kernel OOPSes. Attached to this message > > are a few of those OOPSes (serial console is wonderful!) along with the > > ksymoops output. I think the read_lsmod() warning is bogus, because there > > are, actually, no modules loaded. > > > > My instincts are telling me that these are all being caused by the same > > problem, but I'll be damned if I can figure out what that is. Caching is a > > good suspect, but that's just because it's always a good suspect. > > Native compiles have indeed proven a great way to shake out hardware and > software bugs. > > One suggestion. The rm7k, at least some of the silicon versions, have > hardware erratas with the 'wait' instruction, used in the cpu_idle() > loop. The CPU I have on one of the EV96100 boards, in combination with > the gt96100, will hang hard every time if I don't disable the use of > 'wait'. So while this bug might not have anything to do with what > you're observing, I would ifdef-out the 'wait' instruction in > check_wait(), just to be sure that that's not the cause or one of the > problems. > > Pete -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Sun Jan 27 15:27:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RNR9r01271 for linux-mips-outgoing; Sun, 27 Jan 2002 15:27:09 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RNR0P01253 for ; Sun, 27 Jan 2002 15:27:00 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g0RMQvG18102; Sun, 27 Jan 2002 14:26:57 -0800 Date: Sun, 27 Jan 2002 14:26:57 -0800 From: Matthew Dharm To: Jason Gunthorpe Cc: linux-mips@oss.sgi.com Subject: Re: Help with OOPSes, anyone? Message-ID: <20020127142657.C18041@momenco.com> References: <20020127002242.A11373@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgg@debian.org on Sun, Jan 27, 2002 at 03:53:34AM -0700 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3725 Lines: 90 Interesting... did you try the 2.4.17 that's in the SGI CVS? That's what I'm using.... Our PROM does configure the cache for us, but I'd like to see the code anyway. Might be insightful. We're pretty sure our GT-64120 is setup properly, as we use the same parameters under vxWorks and OpenBSD without problem. The particular board I'm using has no L3 on it. But I will try the NONCACHED option to see what happens. Matt On Sun, Jan 27, 2002 at 03:53:34AM -0700, Jason Gunthorpe wrote: > > On Sun, 27 Jan 2002, Matthew Dharm wrote: > > > My instincts are telling me that these are all being caused by the same > > problem, but I'll be damned if I can figure out what that is. Caching is a > > good suspect, but that's just because it's always a good suspect. > > I can tell you that I have managed to get 2.4.17 (patched up from the > 2.4.15 in the linux_2_4 branch of SGI CVS) running very solidly on a > RM7000 platform. I have carefully inspected the cache code, and I > think that what is in the CVS tree is correct, though a little > over-zealous :> I had to make some tweaks to the cache init on the RM7k, > the existing code is wrong - but this is only important if your PROM does > not do it for you. I can send you this code if you like. > > I'm using the Debian user land, 8M of L3 and a custom system controller. > The machine works will enough to build complicated programs, run X stuff, > etc. My board also has 512M of ram, (mapped from 0-512M, so no problems > with highmem..). The box is nfs root'd and I've currently got a 8139 > ethernet chip on it. > > > In these OOPSes, one is caused by some code in unaligned.c -- I've seen > > several (many) like this, tho I only captured and decoded one. The code in > > Many of the oops's I've seen (while gettings this working) come from > unaligned.c - haven't investigated why yet - they might actually be kernel > unaligned memory references. > > While working on the SR7100, I noticed that various sorts of problems that > result in a subtly broken system bus caused random faults in unaligned.c > > > -- I FTPed the SRPM for wget and built it without any problems. Heck, it > > even works! But when I try to build something bigger (say, ncftp or > > glibc), it dies an ugly death. Heck, I could FTP, build, and use ksymoops > > Just tried for you: > > mips:/tmp/ram# apt-get source -b ncftp > [..] > dpkg-deb: building package `ncftp' in `../ncftp_3.1.1-3_mipsel.deb'. > mips:/tmp/ram# uname -a > Linux mips 2.4.15-greased-turkey #407 Thu Jan 17 19:20:18 MST 2002 mips unknown > mips:/tmp/ram# cat /proc/cpuinfo > processor : 0 > cpu model : RM7000 V3.2 FPU V2.0 > BogoMIPS : 346.20 > [..] > mips:/tmp/ram# free > total used free shared buffers cached > Mem: 514100 124996 389104 0 16 98604 > > > hopes that will fix the problem. I'm thinking about trying > > CONFIG_MIPS_UNCACHED, but I don't know if that works on an RM7000 processor > > It does. > > > -- the L1 and L2 are built-in to the processor, and I don't think the L1 > > can be deactivated. Then again, I don't know how CONFIG_MIPS_UNCACHED > > They can.. It is worth trying without the L3 cache at the very least. > > I see your boards have the GT system controllers. You may want to validate > they are configured correctly, you can get all sorts of really screwy > results if they are not - there are lots of errata for those chips, and > some models have a very intolerant (electricaly) sdram controller. > > Jason > > > -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Sun Jan 27 19:39:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S3dMK30640 for linux-mips-outgoing; Sun, 27 Jan 2002 19:39:22 -0800 Received: from cast-ext.ab.videon.ca (cast-ext.ab.videon.ca [206.75.216.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S3dKP30637 for ; Sun, 27 Jan 2002 19:39:20 -0800 Received: (qmail 7234 invoked from network); 28 Jan 2002 02:39:19 -0000 Received: from unknown (HELO wakko.deltatee.com) ([24.86.210.128]) (envelope-sender ) by cast-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 28 Jan 2002 02:39:19 -0000 Received: from localhost ([127.0.0.1] helo=wakko.deltatee.com ident=jgg) by wakko.deltatee.com with smtp (Exim 3.16 #1 (Debian)) id 16V1hV-0006rN-00; Sun, 27 Jan 2002 19:39:17 -0700 Date: Sun, 27 Jan 2002 19:39:17 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com Reply-To: Jason Gunthorpe To: Matthew Dharm cc: linux-mips@oss.sgi.com Subject: Re: Help with OOPSes, anyone? In-Reply-To: <20020127142657.C18041@momenco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 333 Lines: 16 On Sun, 27 Jan 2002, Matthew Dharm wrote: > Interesting... did you try the 2.4.17 that's in the SGI CVS? That's what > I'm using.... Hmm. Woops. Wrong CVS tag. Right, 2.4.17 out of CVS w/ my patch set is working OK, at least it compiles ncftp, and runs my usual gamut of things. I'll send you my modified cache code.. Jason From owner-linux-mips@oss.sgi.com Mon Jan 28 01:47:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S9lsK04171 for linux-mips-outgoing; Mon, 28 Jan 2002 01:47:54 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S9lkP04151; Mon, 28 Jan 2002 01:47:46 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA26530; Mon, 28 Jan 2002 00:47:33 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA02439; Mon, 28 Jan 2002 00:47:29 -0800 (PST) Message-ID: <002f01c1a7d8$e49bb9f0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Alan Cox" Cc: "Dominic Sweetman" , "Ralf Baechle" , "Ulrich Drepper" , "Mike Uhler" , "\"MIPS/Linux List \(SGI\)\"" , "H . J . Lu" References: Subject: Re: thread-ready ABIs Date: Mon, 28 Jan 2002 09:50:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2211 Lines: 48 > > Which it is. Fork shares no memory regions; vfork/clone share all > > memory regions. AFAIK there is no share-heap-but-not-stack option in > > Linux. > > Thats a design decision. At the point you don't have identical mappings for > both threads you need two sets of page tables and you take all the > performance hits that go with changing current tables on a schedule. > > Its a lot cheaper to use a different %esp for each thread That's a point of view that reflects the PC-centric origins of Linux. Large-scale parallel systems, such as the current high-end server offerings from Sun, IBM/Sequent, and SGI, have a non-uniform memory access (NUMA) model on which insisting on maintining identical page tables for all threads of a parallel program can result in an intollerable level of remote memory accesses. The usual technique employed on such systems is a dynamic replication of frequently accessed pages. This of course implies greater OS overhead for all operations on virtual memory maps, and additional overhead to synchronize the copies, but that can be more than compensated for by reducing the average memory latency seen by the CPUs. An even more extrememe case, though one that is perhaps less relevant to mainstream parallel servers, is that of the emulation of shared memory ("virtual shared memory" or VSM as we used to call it) on message based highly-parallel machines, which likewise depends on having distinctly set-up and managed page tables for different threads/processes within a parallel program. There's nothing wrong with having an OS design that allows common page tables to be used across the threads of a parallel program running on a simple, small-scale SMP platform like a dual or quad CPU PC. But making that the *only* way that thread parallelism is supported is, in my opinion, a design error that will have to be fixed one of these days. And the longer the existing model is enhanced and maintained, the harder it will be to fix. All that having been said, please note that this issue is orthogonal to the question of whether one should have a single "process image" across all threads of a parallel program. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon Jan 28 04:28:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SCSTW23140 for linux-mips-outgoing; Mon, 28 Jan 2002 04:28:29 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SCSMP23127 for ; Mon, 28 Jan 2002 04:28:22 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g0SBRUu03495; Mon, 28 Jan 2002 03:27:30 -0800 Date: Mon, 28 Jan 2002 03:27:30 -0800 (PST) From: Venkata Rajesh Bikkina To: linux-mips@oss.sgi.com cc: rajeshbv@intotoinc.com Subject: INSMOD failing on MIPS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1698 Lines: 64 Hi All, I encountered a strange problem when i tried to insert a module on MIPS 79S334A board with linux kernel version 2.4.3 When a single test file "temp.c" is compiled as mipsel-linux-gcc -I /home/idt/linux/include/asm/gcc -D__KERNEL__ -I/home/idt/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe -DMODULE -mlong-calls -o temp.o -c temp.c and i try to insmod the output 'temp.o' file, insmod is working fine. But when i link two '.o' files with ld as "mipsel-linux-ld -r -o temp.o temp.o temp1.o" and insert the output 'temp.o' it is crashing. While debugging i came to know that the Global Variable is allocated memory at an address 0x4 which is an invalid memory in MIPS. The error displayed on console is >Unable to handle kernel paging request at virtual address 00000004, epc == c00000b4, ra == 80216e54 >Oops in fault.c:do_page_fault, line 172 If i declare the variable as "static" the memory allocation is in proper memory map as it will go into DATA section. This means some problem is coming for the relocatable symbols while linking. Please suggest any more options to be added/deleted while compiling/linking the module or any other missing thing. The C file content is : #include #ifdef MODULE #include #else # include #endif int MyGlobalVar; int init_module (void) { printk("<1>My Test Module Inserted\n"); printk("<1>MyGlobalVar Address : %x\n", &MyGlobalVar); MyGlobalVar = NULL; return 0; } void cleanup_module() { printk("<1>My Test Module Removed\n"); } Thanks and Regards, --Rajesh From owner-linux-mips@oss.sgi.com Mon Jan 28 05:28:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SDStb00442 for linux-mips-outgoing; Mon, 28 Jan 2002 05:28:55 -0800 Received: from columba.eur.3com.com (columba.EUR.3Com.COM [161.71.169.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SDSoP00433 for ; Mon, 28 Jan 2002 05:28:50 -0800 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.eur.3com.com with ESMTP id g0SCUU709096; Mon, 28 Jan 2002 12:30:30 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g0SCSNQ08252; Mon, 28 Jan 2002 12:28:23 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256B4F.004578DE ; Mon, 28 Jan 2002 12:38:49 +0000 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: Venkata Rajesh Bikkina cc: linux-mips@oss.sgi.com, rajeshbv@intotoinc.com Message-ID: <80256B4F.00416BF5.00@notesmta.eur.3com.com> Date: Mon, 28 Jan 2002 11:39:56 +0000 Subject: Re: INSMOD failing on MIPS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 471 Lines: 19 >But when i link two '.o' files with ld as >"mipsel-linux-ld -r -o temp.o temp.o temp1.o" >and insert the output 'temp.o' it is crashing. I've seen this before, I think the solution is to use: mipsel-linux-ld -G 0 -r -o temp.o temp.o temp1.o Without the '-G0' the linker places small common variables into a '.scommon' section which insmod fails to relocate. 'insmod' should complain in this situation or try to relocate these symbols properly. Jon Burgess From owner-linux-mips@oss.sgi.com Mon Jan 28 06:40:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SEeRF08630 for linux-mips-outgoing; Mon, 28 Jan 2002 06:40:27 -0800 Received: from river-bank.demon.co.uk (river-bank.demon.co.uk [193.237.18.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SEeEP08600 for ; Mon, 28 Jan 2002 06:40:14 -0800 Received: from river-bank.demon.co.uk(ratty.river-bank.demon.co.uk[192.168.0.4]) (4473 bytes) by river-bank.demon.co.uk via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 28 Jan 2002 13:40:23 +0000 (GMT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-12) Message-ID: <3C5553E7.7DFDBB55@river-bank.demon.co.uk> Date: Mon, 28 Jan 2002 13:36:39 +0000 From: Phil Thompson Organization: At Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: pgd_init() Patch Content-Type: multipart/mixed; boundary="------------CBB8CDD6DA28F78586CD521A" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3902 Lines: 108 This is a multi-part message in MIME format. --------------CBB8CDD6DA28F78586CD521A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While trying to understand the changes needed for discontiguous memory I came across this... In paging_init() there are two calls to pgd_init()... /* Initialize the entire pgd. */ pgd_init((unsigned long)swapper_pg_dir); pgd_init((unsigned long)swapper_pg_dir + PAGE_SIZE / 2); ...where the assumption seems to be that the PGD is one page and each call initialises half of it. Most of the CPU implementations of pgd_init() nearly do this because they initialise USER_PTRS_PER_PGD entries. The problems with this are... - pg-r3k.c and pg-r4k.S don't use USER_PTRS_PER_PGD and initialise a page's worth each time. This means the second call to pgd_init() initialises half a page's worth of memory after the end of swapper_pg_dir. - USER_PTRS_PER_PGD is defined as TASK_SIZE/PGDIR_SIZE. However, because, TASK_SIZE is actually defined as one less that the maximum task size there is a rounding error that means that USER_PTRS_PER_PGD works out at 511 rather than 512. This means that entries 511 and 1023 of swapper_pg_dir don't get initialised. The corresponding mips64 code has only the first call to pgd_init() and each implementation of pgd_init() initialises PTRS_PER_PGD entries, where PTRS_PER_PGD is simple defined as 1024. The attached patch applies the mips64 approach to the mips code. Should USER_PTRS_PER_PGD be defined as (TASK_SIZE/PGDIR_SIZE) + 1? Phil --------------CBB8CDD6DA28F78586CD521A Content-Type: text/plain; charset=us-ascii; name="mm.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mm.patch" diff -ruN mm.orig/c-sb1.c mm/c-sb1.c --- mm.orig/c-sb1.c Wed Dec 12 16:25:01 2001 +++ mm/c-sb1.c Mon Jan 28 12:37:20 2002 @@ -44,7 +44,7 @@ unsigned long *p = (unsigned long *) page; int i; - for (i = 0; i < USER_PTRS_PER_PGD; i+=8) { + for (i = 0; i < PTRS_PER_PGD; i+=8) { p[i + 0] = (unsigned long) invalid_pte_table; p[i + 1] = (unsigned long) invalid_pte_table; p[i + 2] = (unsigned long) invalid_pte_table; diff -ruN mm.orig/init.c mm/init.c --- mm.orig/init.c Fri Jan 25 14:17:12 2002 +++ mm/init.c Mon Jan 28 12:37:36 2002 @@ -152,7 +152,6 @@ /* Initialize the entire pgd. */ pgd_init((unsigned long)swapper_pg_dir); - pgd_init((unsigned long)swapper_pg_dir + PAGE_SIZE / 2); max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT; low = max_low_pfn; diff -ruN mm.orig/pg-mips32.c mm/pg-mips32.c --- mm.orig/pg-mips32.c Tue Oct 23 02:02:46 2001 +++ mm/pg-mips32.c Mon Jan 28 12:37:56 2002 @@ -127,7 +127,7 @@ unsigned long *p = (unsigned long *) page; int i; - for(i = 0; i < USER_PTRS_PER_PGD; i+=8) { + for(i = 0; i < PTRS_PER_PGD; i+=8) { p[i + 0] = (unsigned long) invalid_pte_table; p[i + 1] = (unsigned long) invalid_pte_table; p[i + 2] = (unsigned long) invalid_pte_table; diff -ruN mm.orig/pg-r5432.c mm/pg-r5432.c --- mm.orig/pg-r5432.c Tue Oct 23 02:02:46 2001 +++ mm/pg-r5432.c Mon Jan 28 12:38:30 2002 @@ -104,7 +104,7 @@ unsigned long *p = (unsigned long *) page; int i; - for(i = 0; i < USER_PTRS_PER_PGD; i+=8) { + for(i = 0; i < PTRS_PER_PGD; i+=8) { p[i + 0] = (unsigned long) invalid_pte_table; p[i + 1] = (unsigned long) invalid_pte_table; p[i + 2] = (unsigned long) invalid_pte_table; diff -ruN mm.orig/pg-rm7k.c mm/pg-rm7k.c --- mm.orig/pg-rm7k.c Tue Oct 23 02:02:46 2001 +++ mm/pg-rm7k.c Mon Jan 28 12:38:38 2002 @@ -107,7 +107,7 @@ unsigned long *p = (unsigned long *) page; int i; - for (i = 0; i < USER_PTRS_PER_PGD; i+=8) { + for (i = 0; i < PTRS_PER_PGD; i+=8) { p[i + 0] = (unsigned long) invalid_pte_table; p[i + 1] = (unsigned long) invalid_pte_table; p[i + 2] = (unsigned long) invalid_pte_table; --------------CBB8CDD6DA28F78586CD521A-- From owner-linux-mips@oss.sgi.com Mon Jan 28 07:23:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SFN6p13396 for linux-mips-outgoing; Mon, 28 Jan 2002 07:23:06 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SFN3P13390 for ; Mon, 28 Jan 2002 07:23:03 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16VCgM-0006nP-00; Mon, 28 Jan 2002 08:22:50 -0600 Message-ID: <3C556CC2.FD6EB35@cotw.com> Date: Mon, 28 Jan 2002 09:22:42 -0600 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: GNU C Library , linux-mips@oss.sgi.com Subject: Re: A linuxthreads bug on mips? References: <20020125234542.A31028@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 703 Lines: 21 "H . J . Lu" wrote: > > Here is a modified ex2.c which only uses one conditional variable. It > works fine on x86. But it leads to dead lock on mips where both > producer and consumer are suspended. Is this testcase correct? H. J., I ran the program on the PC and a MIPS le NEC vr5432. It worked fine on both machines. I do not run the pthread library on the SGI site because it dead locks. I rebuilt the pthread lib natively on my MIPS box and use that lib in place of the lib provided in the RPM on the SGI site. (I suspect it is a cross compilation problem rather than a problem in the pthread lib.) I believe others have also posted about deadlocks with the pthread lib on the SGI site. Scott From owner-linux-mips@oss.sgi.com Mon Jan 28 08:36:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SGaao23023 for linux-mips-outgoing; Mon, 28 Jan 2002 08:36:36 -0800 Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SGaWP23012 for ; Mon, 28 Jan 2002 08:36:32 -0800 Received: from localhost (rajeshbv@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g0SFZZp06635; Mon, 28 Jan 2002 07:35:35 -0800 Date: Mon, 28 Jan 2002 07:35:35 -0800 (PST) From: Venkata Rajesh Bikkina To: Jon Burgess cc: linux-mips@oss.sgi.com Subject: Re: INSMOD failing on MIPS In-Reply-To: <80256B4F.00416BF5.00@notesmta.eur.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 692 Lines: 32 Hi Jon, Thankyou very much for your quick reply. And it worked with your suggestion of adding "-G 0" for linking also. Thanks, --Rajesh On Mon, 28 Jan 2002, Jon Burgess wrote: > > > >But when i link two '.o' files with ld as > >"mipsel-linux-ld -r -o temp.o temp.o temp1.o" > >and insert the output 'temp.o' it is crashing. > > I've seen this before, I think the solution is to use: > > mipsel-linux-ld -G 0 -r -o temp.o temp.o temp1.o > > Without the '-G0' the linker places small common variables into a '.scommon' > section which insmod fails to relocate. > > 'insmod' should complain in this situation or try to relocate these symbols > properly. > > Jon Burgess > > From owner-linux-mips@oss.sgi.com Mon Jan 28 12:53:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SKrZw02789 for linux-mips-outgoing; Mon, 28 Jan 2002 12:53:35 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SKrSP02785 for ; Mon, 28 Jan 2002 12:53:29 -0800 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 UAA21184; Mon, 28 Jan 2002 20:53:14 +0100 (MET) Date: Mon, 28 Jan 2002 20:53:15 +0100 (MET) From: Geert Uytterhoeven To: Phil Thompson cc: Linux/MIPS Development Subject: Re: pgd_init() Patch In-Reply-To: <3C5553E7.7DFDBB55@river-bank.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1130 Lines: 31 On Mon, 28 Jan 2002, Phil Thompson wrote: > - USER_PTRS_PER_PGD is defined as TASK_SIZE/PGDIR_SIZE. However, > because, TASK_SIZE is actually defined as one less that the maximum task ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > size there is a rounding error that means that USER_PTRS_PER_PGD works ^^^^ > out at 511 rather than 512. This means that entries 511 and 1023 of > swapper_pg_dir don't get initialised. > > The corresponding mips64 code has only the first call to pgd_init() and > each implementation of pgd_init() initialises PTRS_PER_PGD entries, > where PTRS_PER_PGD is simple defined as 1024. > > The attached patch applies the mips64 approach to the mips code. > > Should USER_PTRS_PER_PGD be defined as (TASK_SIZE/PGDIR_SIZE) + 1? You mean ((TASK_SIZE)+1)/PGDIR_SIZE? 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 Jan 28 13:03:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SL35L03953 for linux-mips-outgoing; Mon, 28 Jan 2002 13:03:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SL2tP03938 for ; Mon, 28 Jan 2002 13:02:56 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0SK0xB02947; Mon, 28 Jan 2002 12:00:59 -0800 Subject: Re: pgd_init() Patch From: Pete Popov To: Geert Uytterhoeven Cc: Phil Thompson , Linux/MIPS Development In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-YecztOMllCdru85KXkmr" X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 12:03:19 -0800 Message-Id: <1012248199.19952.111.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1995 Lines: 74 --=-YecztOMllCdru85KXkmr Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2002-01-28 at 11:53, Geert Uytterhoeven wrote: > On Mon, 28 Jan 2002, Phil Thompson wrote: > > - USER_PTRS_PER_PGD is defined as TASK_SIZE/PGDIR_SIZE. However, > > because, TASK_SIZE is actually defined as one less that the maximum task > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > size there is a rounding error that means that USER_PTRS_PER_PGD works > ^^^^ > > out at 511 rather than 512. This means that entries 511 and 1023 of > > swapper_pg_dir don't get initialised. > > > > The corresponding mips64 code has only the first call to pgd_init() and > > each implementation of pgd_init() initialises PTRS_PER_PGD entries, > > where PTRS_PER_PGD is simple defined as 1024. > > > > The attached patch applies the mips64 approach to the mips code. > > > > Should USER_PTRS_PER_PGD be defined as (TASK_SIZE/PGDIR_SIZE) + 1? > > You mean ((TASK_SIZE)+1)/PGDIR_SIZE? Or how about: #define USER_PTRS_PER_PGD ((TASK_SIZE-1)/PGDIR_SIZE + 1) The above patch fixes a rather serious memory leak. When a parent process forks a large number of children and then it exits before the children exit, we lose one page per child. I was able to narrow down the problem and reproduce it with the attached program. Ralf has the fix, but was examining related issues before applying the patch. Pete --=-YecztOMllCdru85KXkmr Content-Disposition: attachment; filename=mleak.c Content-Transfer-Encoding: quoted-printable Content-Type: text/x-c; charset=ISO-8859-1 =20 #include #define NUM_TSK 200 int main() { int i, lastp; int pids[NUM_TSK]; printf("mypid %d\n", getpid()); for (i=3D0; i; Mon, 28 Jan 2002 13:05:11 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0SK3GB03140; Mon, 28 Jan 2002 12:03:16 -0800 Message-ID: <3C55AEEA.EC76C0D4@mvista.com> Date: Mon, 28 Jan 2002 12:04:58 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Phil Thompson , Linux/MIPS Development Subject: Re: pgd_init() Patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1330 Lines: 39 Geert Uytterhoeven wrote: > > On Mon, 28 Jan 2002, Phil Thompson wrote: > > - USER_PTRS_PER_PGD is defined as TASK_SIZE/PGDIR_SIZE. However, > > because, TASK_SIZE is actually defined as one less that the maximum task > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > size there is a rounding error that means that USER_PTRS_PER_PGD works > ^^^^ > > out at 511 rather than 512. This means that entries 511 and 1023 of > > swapper_pg_dir don't get initialised. > > > > The corresponding mips64 code has only the first call to pgd_init() and > > each implementation of pgd_init() initialises PTRS_PER_PGD entries, > > where PTRS_PER_PGD is simple defined as 1024. > > > > The attached patch applies the mips64 approach to the mips code. > > > > Should USER_PTRS_PER_PGD be defined as (TASK_SIZE/PGDIR_SIZE) + 1? > > You mean ((TASK_SIZE)+1)/PGDIR_SIZE? > No. It should be +#define USER_PTRS_PER_PGD ((TASK_SIZE-1)/PGDIR_SIZE + 1) Mathmatically, USER_PTRS_PER_PGD=ceil(TASK_SIZE/PGDIR_SIZE) I submitted this patch to Ralf on Jan 03. Ralf, any reason for not applying this? This formula ensures PTRS_PER_PGD is always correct irrespect of the values of TAKS_SIZE and PGDIR_SIZE. See this patch and other pending patches at http://linux.junsun.net/patches/oss.sgi.com/submitted Jun From owner-linux-mips@oss.sgi.com Mon Jan 28 13:26:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SLQir06747 for linux-mips-outgoing; Mon, 28 Jan 2002 13:26:44 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SLQeP06737 for ; Mon, 28 Jan 2002 13:26:40 -0800 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 VAA22777; Mon, 28 Jan 2002 21:26:23 +0100 (MET) Date: Mon, 28 Jan 2002 21:26:24 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: Phil Thompson , Linux/MIPS Development Subject: Re: pgd_init() Patch In-Reply-To: <3C55AEEA.EC76C0D4@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 761 Lines: 29 On Mon, 28 Jan 2002, Jun Sun wrote: > Geert Uytterhoeven wrote: > > On Mon, 28 Jan 2002, Phil Thompson wrote: > > > Should USER_PTRS_PER_PGD be defined as (TASK_SIZE/PGDIR_SIZE) + 1? > > > > You mean ((TASK_SIZE)+1)/PGDIR_SIZE? > > > > No. It should be > > +#define USER_PTRS_PER_PGD ((TASK_SIZE-1)/PGDIR_SIZE + 1) > > Mathmatically, > > USER_PTRS_PER_PGD=ceil(TASK_SIZE/PGDIR_SIZE) OK, ((TASK_SIZE+PGDIR_SIZE-1)/PGDIR_SIZE) in that case :-) 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 Jan 28 16:31:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T0VuI28351 for linux-mips-outgoing; Mon, 28 Jan 2002 16:31:56 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T0VqP28337 for ; Mon, 28 Jan 2002 16:31:52 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0SNVnX23399 for ; Mon, 28 Jan 2002 15:31:49 -0800 From: "Matthew Dharm" To: Subject: RE: Help with OOPSes, anyone? Date: Mon, 28 Jan 2002 15:31:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1307 Lines: 32 Well, here's the latest test results... The 2.4.0 kernel from MontaVista seems to work just fine. Of course, it doesn't have support for the full range of interrupts, but that's a separate matter. But it doesn't crash under big compiles. 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes longer, but that may just be a function of it running so much slower. The BogoMIPS drops by a factor of 100. Ouch. So it doesn't look like a cache problem after all. And it does suggest that something introduced between 2.4.0 and .17 is what broke things. But what that is, I have no idea. I'm going to try Jason's modified cache code just in case, but I doubt that will change anything. We'll have to see, tho. Does anyone have any other suggestions to try? I'm starting to wonder if perhaps the PROM isn't setting up the SDRAM properly, but that conflicts with the working 2.4.0 kernel -- the PROM is the same in both cases, so I would expect a PROM error to affect both versions. I'm running out of ideas here... anyone? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Mon Jan 28 16:51:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T0p7130422 for linux-mips-outgoing; Mon, 28 Jan 2002 16:51:07 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T0p0P30406 for ; Mon, 28 Jan 2002 16:51:00 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0SNowX23517 for ; Mon, 28 Jan 2002 15:50:58 -0800 From: "Matthew Dharm" To: Subject: RE: Help with OOPSes, anyone? Date: Mon, 28 Jan 2002 15:50:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2093 Lines: 62 Well, Jason's modified cache code doesn't help either. I'm still open to suggestions.... Ralf, are you in the same location as your board? I'm curious to hear your opinion of this? Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Matthew Dharm > Sent: Monday, January 28, 2002 3:32 PM > To: linux-mips@oss.sgi.com > Subject: RE: Help with OOPSes, anyone? > > > Well, here's the latest test results... > > The 2.4.0 kernel from MontaVista seems to work just fine. > Of course, > it doesn't have support for the full range of interrupts, > but that's a > separate matter. But it doesn't crash under big compiles. > > 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes longer, but that > may just be a function of it running so much slower. The BogoMIPS > drops by a factor of 100. Ouch. > > So it doesn't look like a cache problem after all. And it does > suggest that something introduced between 2.4.0 and .17 is > what broke > things. But what that is, I have no idea. > > I'm going to try Jason's modified cache code just in case, > but I doubt > that will change anything. We'll have to see, tho. > > Does anyone have any other suggestions to try? I'm > starting to wonder > if perhaps the PROM isn't setting up the SDRAM properly, but that > conflicts with the working 2.4.0 kernel -- the PROM is the same in > both cases, so I would expect a PROM error to affect both versions. > > I'm running out of ideas here... anyone? > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. > Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > From owner-linux-mips@oss.sgi.com Mon Jan 28 16:54:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T0sOK30832 for linux-mips-outgoing; Mon, 28 Jan 2002 16:54:24 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T0sKP30820 for ; Mon, 28 Jan 2002 16:54:20 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0SNqOB16747; Mon, 28 Jan 2002 15:52:24 -0800 Subject: RE: Help with OOPSes, anyone? From: Pete Popov To: Matthew Dharm Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 15:54:47 -0800 Message-Id: <1012262087.8518.174.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1436 Lines: 35 On Mon, 2002-01-28 at 15:31, Matthew Dharm wrote: > Well, here's the latest test results... > > The 2.4.0 kernel from MontaVista seems to work just fine. Of course, > it doesn't have support for the full range of interrupts, but that's a > separate matter. But it doesn't crash under big compiles. 2.4.0 from MontaVista? Do you mean the very first release, which was 2.4.0-test9? > 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes longer, but that > may just be a function of it running so much slower. The BogoMIPS > drops by a factor of 100. Ouch. > > So it doesn't look like a cache problem after all. And it does > suggest that something introduced between 2.4.0 and .17 is what broke > things. But what that is, I have no idea. > > I'm going to try Jason's modified cache code just in case, but I doubt > that will change anything. We'll have to see, tho. > > Does anyone have any other suggestions to try? I'm starting to wonder > if perhaps the PROM isn't setting up the SDRAM properly, but that > conflicts with the working 2.4.0 kernel -- the PROM is the same in > both cases, so I would expect a PROM error to affect both versions. > > I'm running out of ideas here... anyone? If you're absolutely sure 2.4.0-test9 doesn't crash (you ran the test "enough" times), perhaps you can start testing kernels between 2.4.0 and 2.4.17. And, you did get rid of the 'wait' instruction in 2.4.17, right ;-)? Pete From owner-linux-mips@oss.sgi.com Mon Jan 28 17:10:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T1A9F32492 for linux-mips-outgoing; Mon, 28 Jan 2002 17:10:09 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T1A1P32467 for ; Mon, 28 Jan 2002 17:10:01 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0T09oX23620; Mon, 28 Jan 2002 16:09:50 -0800 From: "Matthew Dharm" To: "Pete Popov" Cc: "linux-mips" Subject: RE: Help with OOPSes, anyone? Date: Mon, 28 Jan 2002 16:09:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1012262087.8518.174.camel@zeus> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2396 Lines: 70 Frankly, I'm not entirely certain which version the Montavista kernel is. We were supposed to be doing the software validation for PMC-Sierra (who contracted to Montavista for the work), so this is one of the later kernels from that process. But I really don't know exactly which one... As for the 'wait' thing... forgot to try that one. How does one go about disabling the wait instruction, anyway? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Pete Popov [mailto:ppopov@pacbell.net] > Sent: Monday, January 28, 2002 3:55 PM > To: Matthew Dharm > Cc: linux-mips > Subject: RE: Help with OOPSes, anyone? > > > On Mon, 2002-01-28 at 15:31, Matthew Dharm wrote: > > Well, here's the latest test results... > > > > The 2.4.0 kernel from MontaVista seems to work just fine. > Of course, > > it doesn't have support for the full range of interrupts, > but that's a > > separate matter. But it doesn't crash under big compiles. > > 2.4.0 from MontaVista? Do you mean the very first release, which was > 2.4.0-test9? > > > 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes > longer, but that > > may just be a function of it running so much slower. The BogoMIPS > > drops by a factor of 100. Ouch. > > > > So it doesn't look like a cache problem after all. And it does > > suggest that something introduced between 2.4.0 and .17 > is what broke > > things. But what that is, I have no idea. > > > > I'm going to try Jason's modified cache code just in > case, but I doubt > > that will change anything. We'll have to see, tho. > > > > Does anyone have any other suggestions to try? I'm > starting to wonder > > if perhaps the PROM isn't setting up the SDRAM properly, but that > > conflicts with the working 2.4.0 kernel -- the PROM is the same in > > both cases, so I would expect a PROM error to affect both > versions. > > > > I'm running out of ideas here... anyone? > > If you're absolutely sure 2.4.0-test9 doesn't crash (you > ran the test > "enough" times), perhaps you can start testing kernels > between 2.4.0 and > 2.4.17. And, you did get rid of the 'wait' instruction in 2.4.17, > right ;-)? > > Pete > From owner-linux-mips@oss.sgi.com Mon Jan 28 17:22:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T1MKq01312 for linux-mips-outgoing; Mon, 28 Jan 2002 17:22:20 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T1MAP01293 for ; Mon, 28 Jan 2002 17:22:10 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0T0KDB18375; Mon, 28 Jan 2002 16:20:13 -0800 Subject: RE: Help with OOPSes, anyone? From: Pete Popov To: Matthew Dharm Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 16:22:36 -0800 Message-Id: <1012263756.8522.181.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2802 Lines: 82 On Mon, 2002-01-28 at 16:09, Matthew Dharm wrote: > Frankly, I'm not entirely certain which version the Montavista kernel > is. We were supposed to be doing the software validation for > PMC-Sierra (who contracted to Montavista for the work), so this is one > of the later kernels from that process. But I really don't know > exactly which one... It's probably 2.4.2 based, but it could be 2.4.0-test9. On the target, type "uname --all" > As for the 'wait' thing... forgot to try that one. How does one go > about disabling the wait instruction, anyway? arch/mips/kernel/setup.c, in the function check_wait(), ifdef-out the RM7000 case so that 'wait' is not available. Pete > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > > -----Original Message----- > > From: Pete Popov [mailto:ppopov@pacbell.net] > > Sent: Monday, January 28, 2002 3:55 PM > > To: Matthew Dharm > > Cc: linux-mips > > Subject: RE: Help with OOPSes, anyone? > > > > > > On Mon, 2002-01-28 at 15:31, Matthew Dharm wrote: > > > Well, here's the latest test results... > > > > > > The 2.4.0 kernel from MontaVista seems to work just fine. > > Of course, > > > it doesn't have support for the full range of interrupts, > > but that's a > > > separate matter. But it doesn't crash under big compiles. > > > > 2.4.0 from MontaVista? Do you mean the very first release, which was > > 2.4.0-test9? > > > > > 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes > > longer, but that > > > may just be a function of it running so much slower. The BogoMIPS > > > drops by a factor of 100. Ouch. > > > > > > So it doesn't look like a cache problem after all. And it does > > > suggest that something introduced between 2.4.0 and .17 > > is what broke > > > things. But what that is, I have no idea. > > > > > > I'm going to try Jason's modified cache code just in > > case, but I doubt > > > that will change anything. We'll have to see, tho. > > > > > > Does anyone have any other suggestions to try? I'm > > starting to wonder > > > if perhaps the PROM isn't setting up the SDRAM properly, but that > > > conflicts with the working 2.4.0 kernel -- the PROM is the same in > > > both cases, so I would expect a PROM error to affect both > > versions. > > > > > > I'm running out of ideas here... anyone? > > > > If you're absolutely sure 2.4.0-test9 doesn't crash (you > > ran the test > > "enough" times), perhaps you can start testing kernels > > between 2.4.0 and > > 2.4.17. And, you did get rid of the 'wait' instruction in 2.4.17, > > right ;-)? > > > > Pete > > > From owner-linux-mips@oss.sgi.com Mon Jan 28 19:04:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T342811314 for linux-mips-outgoing; Mon, 28 Jan 2002 19:04:02 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T33hP11278 for ; Mon, 28 Jan 2002 19:03:44 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g0T23eX24073; Mon, 28 Jan 2002 18:03:40 -0800 From: "Matthew Dharm" To: "Pete Popov" Cc: "linux-mips" Subject: RE: Help with OOPSes, anyone? Date: Mon, 28 Jan 2002 18:03:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1012262087.8518.174.camel@zeus> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5856 Lines: 166 Well, more data. 2.4.0 won't boot. What I get on the serial console is: PMON> boot 192.168.1.1:/tftpboot/mdharm/vmlinux-2.4.0 Loading file: 192.168.1.1:/tftpboot/mdharm/vmlinux-2.4.0 (elf) 0x80100000/1490576 + 0x8026be90/127504(z) + 4094 syms\ Entry address is 801005a8 PMON> g Linux version 2.4.0 (mdharm@GoldenGate) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Mon Jan 28 16:37:45 PST 2002 Determined physical RAM map: memory: 08000000 @ 00000000 (usable) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: and then it just stops. Go figure. 2.4.5 crashes, but in a different way. Now I get a stream of: Got ibe at 2ab60b3c. Instruction bus error, epc == 2ab60b3c, ra == 2ab5fcac Over and over again. I should say the system didn't actually crash, but every command I run at the shell gives a Segmentation Fault. And, even when I'm not trying to run applications, the above message is streaming out the serial port. 2.4.10 also does something bad. Rebuilding ncftp causes a bus error during the compilation process. As with 2.4.5, no applications will now run, but this time they all give "Illegal Instruction (core dumped)". Nothing appeared on the serial console. 2.4.14 crashes with the following OOPS (decoded for your enjoyment): ksymoops 2.4.0 on mips 2.4.14. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.14/ (default) -m System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address 00000020, epc == 80128228, ra == 80123c28 $0 : 00000000 1000ee88 00000177 81209a20 8129fa80 00000067 2ab06000 00000000 $8 : 90045401 1000001f 00000000 802635a8 00000000 8025b840 87407e90 81205b64 $16: 00000000 00000067 86f54e40 00000000 86dbc520 86f54e40 2ab6d000 00000177 $24: 00000001 006b6c30 86d20000 86d21dd8 7fd73d98 80123c28 epc : 80128228 Not tainted Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 Status: 90045403 Cause : 00008008 Process cc1 (pid: 3465, stackpage=86d20000) Stack: 80123b70 7fd75db8 7fd74dc8 7fd74db8 00000000 2ab6d000 86f54e40 86318140 00000000 86181db4 2ab6d000 8631815c 7fd73d98 80123c28 86d21e78 7fd74db8 0070c248 86d21f30 7fd71ca8 00000000 00000000 2ab6d000 86318140 00000000 86f54e40 86d21f30 00000000 80123df0 86f54720 86d20000 8631815c 00000045 86181db4 ffffffff 86f54e40 86d20000 8631815c 2ab6d000 86318140 8010fcb4 0000000b ... Call Trace: [<80123b70>] [<80123c28>] [<80123df0>] [<8010fcb4>] [<8011db50>] [<8011dc90>] [<8011e0e0>] [<8010d76c>] [<80110b98>] [<8010a760>] Warning (Oops_read): Code line not seen, dumping what data is available >>RA; 80123c28 >>PC; 80128228 <===== Trace; 80123b70 Trace; 80123c28 Trace; 80123df0 Trace; 8010fcb4 Trace; 8011db50 Trace; 8011dc90 Trace; 8011e0e0 Trace; 8010d76c Trace; 80110b98 Trace; 8010a760 And 2.4.17 with the wait instruction turned off still crashes. The Montavista kernel (which claims to be 2.4.0 #5 build by jsun) seems to work... I've done several recompiles on it, and lots of I/O traffic with no problems. Unfortunatly, I don't have the source code to this particular kernel... tho I believe that Montavista is required to release their source cod by the GPL. Tho here's a question: What is the best compiler to build a kernel with? I've built all mine with egcs-2.91.66 which I downloaded from oss.sgi.com a while ago. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Pete Popov [mailto:ppopov@pacbell.net] > Sent: Monday, January 28, 2002 3:55 PM > To: Matthew Dharm > Cc: linux-mips > Subject: RE: Help with OOPSes, anyone? > > > On Mon, 2002-01-28 at 15:31, Matthew Dharm wrote: > > Well, here's the latest test results... > > > > The 2.4.0 kernel from MontaVista seems to work just fine. > Of course, > > it doesn't have support for the full range of interrupts, > but that's a > > separate matter. But it doesn't crash under big compiles. > > 2.4.0 from MontaVista? Do you mean the very first release, which was > 2.4.0-test9? > > > 2.4.17 with CONFIG_MIPS_UNCACHED crashes. It takes > longer, but that > > may just be a function of it running so much slower. The BogoMIPS > > drops by a factor of 100. Ouch. > > > > So it doesn't look like a cache problem after all. And it does > > suggest that something introduced between 2.4.0 and .17 > is what broke > > things. But what that is, I have no idea. > > > > I'm going to try Jason's modified cache code just in > case, but I doubt > > that will change anything. We'll have to see, tho. > > > > Does anyone have any other suggestions to try? I'm > starting to wonder > > if perhaps the PROM isn't setting up the SDRAM properly, but that > > conflicts with the working 2.4.0 kernel -- the PROM is the same in > > both cases, so I would expect a PROM error to affect both > versions. > > > > I'm running out of ideas here... anyone? > > If you're absolutely sure 2.4.0-test9 doesn't crash (you > ran the test > "enough" times), perhaps you can start testing kernels > between 2.4.0 and > 2.4.17. And, you did get rid of the 'wait' instruction in 2.4.17, > right ;-)? > > Pete > From owner-linux-mips@oss.sgi.com Mon Jan 28 19:34:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T3Y0l14199 for linux-mips-outgoing; Mon, 28 Jan 2002 19:34:00 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T3XtP14185 for ; Mon, 28 Jan 2002 19:33:55 -0800 Received: from hermes.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 SAA04393 for ; Mon, 28 Jan 2002 18:32:29 -0800 (PST) mail_from (ppopov@pacbell.net) Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g0T2QwB24696; Mon, 28 Jan 2002 18:26:58 -0800 Subject: RE: Help with OOPSes, anyone? From: Pete Popov To: Matthew Dharm Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 18:29:22 -0800 Message-Id: <1012271362.8518.219.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1217 Lines: 33 > And 2.4.17 with the wait instruction turned off still crashes. > The Montavista kernel (which claims to be 2.4.0 #5 build by jsun) > seems to work... Strange, that must have been some interim build Jun did. > I've done several recompiles on it, and lots of I/O > traffic with no problems. Unfortunatly, I don't have the source code > to this particular kernel... tho I believe that Montavista is required > to release their source cod by the GPL. All of the open source work we do we push out to the community tree immediately. That's a rule we live by and there's no exceptions. The Ocelot code was pushed out back then. Since then I've seen lots of additions to that directory and obviously something got broke. QED did receive an Alliance CD with the Ocelot LSP on it, so they should be able to provide you with a copy of the cdimage, including the source. But the kernel will be 2.4.2 based though -- I don't know where the 2.4.0 came from. > Tho here's a question: What is the best compiler to build a kernel > with? I've built all mine with egcs-2.91.66 which I downloaded from > oss.sgi.com a while ago. MontaVista's, but I'm biased ;-) The toolchain will be on the CD as well. Pete From owner-linux-mips@oss.sgi.com Mon Jan 28 22:42:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T6gqb32588 for linux-mips-outgoing; Mon, 28 Jan 2002 22:42:52 -0800 Received: from gda-server ([202.88.152.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0T6gkP32585 for ; Mon, 28 Jan 2002 22:42:49 -0800 Received: from [192.168.0.186] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Tue, 29 Jan 2002 11:16:39 Message-ID: <3C56DF16.DD3687F1@gdatech.co.in> Date: Tue, 29 Jan 2002 23:12:46 +0530 From: santhosh <ps.santhosh@gdatech.co.in> Organization: gdatech X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: SB1250 boot loader Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 156 Lines: 8 Hai MIPSian I am working on a MIPS64 based board ....SB1250. Shall i get its boot loader or MIPS64 boot loader?? plz send away to get these... From owner-linux-mips@oss.sgi.com Mon Jan 28 23:18:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0T7Ieb00788 for linux-mips-outgoing; M