From owner-linux-mips@oss.sgi.com Wed Aug 1 04:27:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71BRCO01173 for linux-mips-outgoing; Wed, 1 Aug 2001 04:27:12 -0700 Received: from fe070.worldonline.dk (fe070.worldonline.dk [212.54.64.208]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71BRBV01170 for ; Wed, 1 Aug 2001 04:27:11 -0700 Received: (qmail 30967 invoked by uid 0); 1 Aug 2001 11:22:36 -0000 Received: from unknown (HELO tuxedo.skovlyporten.dk) (213.237.49.98) by fe070.worldonline.dk with SMTP; 1 Aug 2001 11:22:36 -0000 Received: by tuxedo.skovlyporten.dk (Postfix, from userid 501) id 51A09C438; Wed, 1 Aug 2001 13:22:33 +0200 (CEST) Date: Wed, 1 Aug 2001 13:22:33 +0200 From: Lars Munch Christensen To: linux-mips@oss.sgi.com Subject: Remote debug Malta Message-ID: <20010801132233.A12343@tuxedo.skovlyporten.dk> 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 Hi all As I have mentioned previously on this list, I'm writing a small mips64 microkernel for the malta board. The malta has a remote gdb interface in YAMON, but I have not succeeded in remote debugging my kernel yet. Is there a recommended gdb version that I should use to debug mips64 code? I have got it as far as downloading the kernel and jumping to the kernel entry, but from there I'm only able to execute the program, but not single step or anything else. Thanks -- Lars Munch From owner-linux-mips@oss.sgi.com Wed Aug 1 05:25:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71CPQw01947 for linux-mips-outgoing; Wed, 1 Aug 2001 05:25:26 -0700 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 f71CPPV01944 for ; Wed, 1 Aug 2001 05:25:25 -0700 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id IAA28096; Wed, 1 Aug 2001 08:25:30 -0400 (EDT) Message-ID: <3B67F510.A0CFB4E7@patton.com> Date: Wed, 01 Aug 2001 08:24:48 -0400 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: James Simmons CC: Jun Sun , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: sys_mips problems References: Content-Type: multipart/mixed; boundary="------------111494A63E67E90551881BCC" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------111494A63E67E90551881BCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Simmons wrote: > > > > Since I was having problems with everything sefaulting due to the sys_mips > > > bug I tried the patch floating around. It fixed the segfault problem but > > > instead I get this error. Anyone knows why? > > > > > > : error while loading shared libraries: libc.so.6: cannot stat shared > > > object: Error 14 > > > > Which patch did you use? > > The fast_sysmips one. > > > Does your CPU have ll/sc instructions? > > I have a cobalt cube which has a MIPS Nevada chip which is a R52xx chip. I > don't know if it does. By default I have ll/sc and lld/scd instructions > enabled. I don't know which R52xx chip you have, but my QED RM5261 has ll/sc but no mention of lld/scd instructions. -- /"\ . . . . . . . . . . . . . . . /"\ \ / 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 --------------111494A63E67E90551881BCC Content-Type: text/x-vcard; charset=us-ascii; name="paul.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Paul Kasper Content-Disposition: attachment; filename="paul.vcf" begin:vcard n:Kasper;Paul tel;fax:301-869-9293 tel;work:301-975-1000 x173 x-mozilla-html:FALSE url:www.patton.com org:Patton Electronics Co.;Central Office Products adr:;;7622 Rickenbacker Drive;Gaithersburg;MD;20879;USA version:2.1 email;internet:paul@patton.com x-mozilla-cpt:;10912 fn:Paul Kasper end:vcard --------------111494A63E67E90551881BCC-- From owner-linux-mips@oss.sgi.com Wed Aug 1 06:33:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71DXPu03115 for linux-mips-outgoing; Wed, 1 Aug 2001 06:33:25 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71DXOV03112 for ; Wed, 1 Aug 2001 06:33:24 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA03444; Wed, 1 Aug 2001 06:33:11 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA20898; Wed, 1 Aug 2001 06:33:08 -0700 (PDT) Message-ID: <019701c11a8f$2561daa0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "James Simmons" Cc: "Jun Sun" , , References: <3B67F510.A0CFB4E7@patton.com> Subject: Re: sys_mips problems Date: Wed, 1 Aug 2001 15:37:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > > Since I was having problems with everything sefaulting due to the sys_mips > > > > bug I tried the patch floating around. It fixed the segfault problem but > > > > instead I get this error. Anyone knows why? > > > > > > > > : error while loading shared libraries: libc.so.6: cannot stat shared > > > > object: Error 14 > > > > > > Which patch did you use? > > > > The fast_sysmips one. > > > > > Does your CPU have ll/sc instructions? > > > > I have a cobalt cube which has a MIPS Nevada chip which is a R52xx chip. I > > don't know if it does. By default I have ll/sc and lld/scd instructions > > enabled. > > I don't know which R52xx chip you have, but my QED RM5261 has ll/sc but > no mention of lld/scd instructions. The RM52xx families are MIPS IV ISA devices, and lld/scd are MIPS III (and therefore MIPS IV) instructions. You've got 'em. But you won't be able to use them in User mode unless the UX bit of the CP0.Status register is set, which also turns on 64-bit addressing, for which I rather doubt that your kernel is prepared. User mode code should use only the 32-bit ll/sc's. Not that it sounds like that has anything to do with the problem reported here, mind you... Kevin K. From owner-linux-mips@oss.sgi.com Wed Aug 1 08:51:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Fphm06151 for linux-mips-outgoing; Wed, 1 Aug 2001 08:51:43 -0700 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 f71FpgV06148 for ; Wed, 1 Aug 2001 08:51:42 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15RyHb-0007Ew-00; Wed, 01 Aug 2001 17:51:39 +0200 Date: Wed, 1 Aug 2001 17:51:39 +0200 From: Guido Guenther To: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Horrible X and kernel crashes under mipsel RH7.1... Message-ID: <20010801175138.A10809@gandalf.physik.uni-konstanz.de> Mail-Followup-To: debian-mips@lists.debian.org, linux-mips@oss.sgi.com References: <3B66B5F3.79D6AAB8@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B66B5F3.79D6AAB8@cotw.com>; from sjhill@cotw.com on Tue, Jul 31, 2001 at 08:43:15AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 31, 2001 at 08:43:15AM -0500, Steven J. Hill wrote: [..snip..] > CVS crashes and takes the kernel with it. I have not tested anything under > the Debian distros yet. If you want to, there's a full build of 4.1.0-0pre1v7 at http://honk.physik.uni-konstanz.de/linux-mips/x/mipsel-debs/ -- Guido From owner-linux-mips@oss.sgi.com Wed Aug 1 09:36:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71GaNJ07316 for linux-mips-outgoing; Wed, 1 Aug 2001 09:36:23 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71GaKV07312 for ; Wed, 1 Aug 2001 09:36:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA26736; Wed, 1 Aug 2001 18:35:27 +0200 (MET DST) Date: Wed, 1 Aug 2001 18:35:27 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , "Steven J. Hill" cc: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Horrible X and kernel crashes under mipsel RH7.1... In-Reply-To: <3B66B5F3.79D6AAB8@cotw.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 31 Jul 2001, Steven J. Hill wrote: > root@localhost:/home/sjhill$ /usr/X11R6/bin/Xfbdev > __alloc_pages: 5-order allocation failed. > __alloc_pages: 5-order allocation failed. > Unable to handle kernel paging request at virtual address 00000000, epc == 00000 > 000, ra == 80167750 > Oops in fault.c:do_page_fault, line 172: > $0 : 00000000 801f0000 b30003f0 000000bb > $4 : 0000000c 0000006b 809d3bc0 00006b18 > $8 : 00000020 801658f0 801cbc98 801c5000 > $12: 00000001 00000040 00000003 81f6eea0 > $16: 801dbf18 801cbe60 00000001 801d60cc > $20: 801d0a3c 809d3bc0 00000000 806e3620 > $24: 00000001 2ac99d90 > $28: 813f2000 813f3de0 00000000 80167750 > epc : 00000000 > Status: b001f003 > Cause : 00000008 > Process Xfbdev (pid: 596, stackpage=813f2000) > > *************** > > The next one I printed out the memory usage as well as the attempt to run > startx and xinit first. The page alloc messages aren't printed, but the > kernel still dies a horrible death. The kernel actually commits suicide. I don't know why it does, but it looks like a temporary debugging hack. With the following patch the system might survive. Next you might want to find why the null pointer dereference happens. The __alloc_pages errors suggest some code does not check for a null pointer being returned. A kernel code inspection around address 0x80167750 might reveal guilty code. Ralf, could you please apply the patch? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010730-die-0 diff -up --recursive --new-file linux.macro/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c --- linux.macro/arch/mips/kernel/traps.c Tue Jul 24 04:26:34 2001 +++ linux/arch/mips/kernel/traps.c Wed Aug 1 16:12:42 2001 @@ -204,7 +204,6 @@ extern void __die(const char * str, stru show_trace((unsigned int *) regs->regs[29]); show_code((unsigned int *) regs->cp0_epc); printk("\n"); -while(1); spin_unlock_irq(&die_lock); do_exit(SIGSEGV); } From owner-linux-mips@oss.sgi.com Wed Aug 1 10:09:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71H9kb08437 for linux-mips-outgoing; Wed, 1 Aug 2001 10:09:46 -0700 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 f71H9iV08434 for ; Wed, 1 Aug 2001 10:09:44 -0700 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id NAA06030; Wed, 1 Aug 2001 13:09:54 -0400 (EDT) Message-ID: <3B683788.B48252A8@patton.com> Date: Wed, 01 Aug 2001 13:08:24 -0400 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: James Simmons CC: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: Mips Cobalt cube distro References: Content-Type: multipart/mixed; boundary="------------FA9C495AE12F1A482AACFE19" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------FA9C495AE12F1A482AACFE19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Simmons wrote: > > Oops. A small problem with the web server. Sorry aboput that. Now when you > go to that web page it will be appended so you can read it via the web. > > > Ummm, what README? > > All I see is this. > > > > base-contents.txt 31-Jul-2001 13:40 5k > > base.tar.bz2 31-Jul-2001 13:40 19.0M > > vmlinux.gz 31-Jul-2001 13:40 824k Are the kernel sources and .config for that vmlinuz available somewhere? If so, where? -- 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 --------------FA9C495AE12F1A482AACFE19 Content-Type: text/x-vcard; charset=us-ascii; name="paul.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Paul Kasper Content-Disposition: attachment; filename="paul.vcf" begin:vcard n:Kasper;Paul tel;fax:301-869-9293 tel;work:301-975-1000 x173 x-mozilla-html:FALSE url:www.patton.com org:Patton Electronics Co.;Central Office Products adr:;;7622 Rickenbacker Drive;Gaithersburg;MD;20879;USA version:2.1 email;internet:paul@patton.com x-mozilla-cpt:;10912 fn:Paul Kasper end:vcard --------------FA9C495AE12F1A482AACFE19-- From owner-linux-mips@oss.sgi.com Wed Aug 1 10:23:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71HNq108678 for linux-mips-outgoing; Wed, 1 Aug 2001 10:23:52 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71HNpV08675 for ; Wed, 1 Aug 2001 10:23:51 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f71HNeLh003017; Wed, 1 Aug 2001 10:23:40 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f71HNexq003013; Wed, 1 Aug 2001 10:23:40 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 1 Aug 2001 10:23:40 -0700 (PDT) From: James Simmons To: Paul Kasper cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: Mips Cobalt cube distro In-Reply-To: <3B683788.B48252A8@patton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > base-contents.txt 31-Jul-2001 13:40 5k > > > base.tar.bz2 31-Jul-2001 13:40 19.0M > > > vmlinux.gz 31-Jul-2001 13:40 824k > > Are the kernel sources and .config for that vmlinuz available > somewhere? If so, where? http://www.sf.net/projects/linux-mips Just go the CVS section. arch/mips/configs/defconfig-cobalt is the configuration I used. From owner-linux-mips@oss.sgi.com Wed Aug 1 10:34:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71HYC708818 for linux-mips-outgoing; Wed, 1 Aug 2001 10:34:12 -0700 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 f71HYCV08815 for ; Wed, 1 Aug 2001 10:34:12 -0700 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 15Rzsj-0003XY-00; Wed, 01 Aug 2001 12:34:05 -0500 Message-ID: <3B683BC8.74F72492@cotw.com> Date: Wed, 01 Aug 2001 12:26:32 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: debian-mips@lists.debian.org Subject: Re: Horrible X and kernel crashes under mipsel RH7.1... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > The patch helps when the X server dies. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Aug 2 05:46:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72CkK915243 for linux-mips-outgoing; Thu, 2 Aug 2001 05:46:20 -0700 Received: from dea.waldorf-gmbh.de (u-206-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72CkHV15215 for ; Thu, 2 Aug 2001 05:46:17 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f72C5cN24785; Thu, 2 Aug 2001 14:05:38 +0200 Date: Thu, 2 Aug 2001 14:05:38 +0200 From: Ralf Baechle To: "Steven J. Hill" Cc: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Horrible X and kernel crashes under mipsel RH7.1... Message-ID: <20010802140538.G24305@bacchus.dhis.org> References: <3B66B5F3.79D6AAB8@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B66B5F3.79D6AAB8@cotw.com>; from sjhill@cotw.com on Tue, Jul 31, 2001 at 08:43:15AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 31, 2001 at 08:43:15AM -0500, Steven J. Hill wrote: > root@localhost:/home/sjhill$ /usr/X11R6/bin/Xfbdev > __alloc_pages: 5-order allocation failed. > __alloc_pages: 5-order allocation failed. Order 5 allocations are pretty unreliable and put high stress on the memory managment. They may fail though you may still have plenty of memory available in smaller chunks. So if possible at all try to avoid the allocation of high order pages or at least have a fallback strategy available. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 2 05:47:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72ClgK15524 for linux-mips-outgoing; Thu, 2 Aug 2001 05:47:42 -0700 Received: from dea.waldorf-gmbh.de (u-206-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72ClcV15513 for ; Thu, 2 Aug 2001 05:47:38 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f72BsuT24679; Thu, 2 Aug 2001 13:54:56 +0200 Date: Thu, 2 Aug 2001 13:54:56 +0200 From: Ralf Baechle To: "John D. Davis" Cc: Carsten Langgaard , SGI MIPS list Subject: Re: r4600 flag Message-ID: <20010802135456.F24305@bacchus.dhis.org> References: <3B66B4E6.70B80D21@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@Stanford.EDU on Tue, Jul 31, 2001 at 08:29:12AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Jul 31, 2001 at 08:29:12AM -0700, John D. Davis wrote: > Looking at the system map from the generic build of 2.4.3, it looks like > the code is 64 bit. The upper 32 bits are "f" instead of 0. No. Sign extended, that is bit 31 is copied into bits 32 to 63. > I built it > using the R4600 flag. This differs from the system map for > 2.4.0-test9 where the upper 32 bits are 0. No. Different binutils. Older binutils did zero extend 32-bit addresses to 64-bit addresses in the objdump output which is wrong. > For the indy, do I specify mips2 to generate 32 bit code? -mips2 :-) For the kernel we use a few 64-bit instructions on the Indy though. These are carefully chosen such that nothing go wrong like exceptions corrupting the upper 32-bit of a register. > objdump says it is ELF32, but it doesn't look like that. I would like to > generate 32bit. ELF is an object format. Nothing prevents you from putting 64-bit code into a 32-bit ELF file and vice versa. You just need to be careful. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 2 05:47:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Clne15565 for linux-mips-outgoing; Thu, 2 Aug 2001 05:47:49 -0700 Received: from dea.waldorf-gmbh.de (u-206-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72ClkV15554 for ; Thu, 2 Aug 2001 05:47:47 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f72Bffs24638; Thu, 2 Aug 2001 13:41:41 +0200 Date: Thu, 2 Aug 2001 13:41:41 +0200 From: Ralf Baechle To: Lars Munch Christensen Cc: linux-mips@oss.sgi.com Subject: Re: Remote debug Malta Message-ID: <20010802134141.D24305@bacchus.dhis.org> References: <20010801132233.A12343@tuxedo.skovlyporten.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010801132233.A12343@tuxedo.skovlyporten.dk>; from c948114@student.dtu.dk on Wed, Aug 01, 2001 at 01:22:33PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 01, 2001 at 01:22:33PM +0200, Lars Munch Christensen wrote: > As I have mentioned previously on this list, I'm writing > a small mips64 microkernel for the malta board. The malta > has a remote gdb interface in YAMON, but I have not succeeded > in remote debugging my kernel yet. Is there a recommended > gdb version that I should use to debug mips64 code? > > I have got it as far as downloading the kernel and jumping to the > kernel entry, but from there I'm only able to execute the > program, but not single step or anything else. Checkout arch/mips/kernel/gdb-* in the Linux kerne; it's all you need in your OS. Assuming your code is also GPL transplanting should be doable very quickly. Ralf PS: I assume you're microkernel is Linux otherwise we'd be off-topic here :-) From owner-linux-mips@oss.sgi.com Thu Aug 2 06:47:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72Dlf524367 for linux-mips-outgoing; Thu, 2 Aug 2001 06:47:41 -0700 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72DldV24360 for ; Thu, 2 Aug 2001 06:47:39 -0700 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 2979C2B6FE; Thu, 2 Aug 2001 14:45:47 +0100 (IST) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 884C1A8A5; Thu, 2 Aug 2001 14:45:46 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 8477EA8A4; Thu, 2 Aug 2001 14:45:46 +0100 (IST) Date: Thu, 2 Aug 2001 14:45:46 +0100 (IST) From: Dave Airlie X-X-Sender: To: Jan-Benedict Glaw Cc: "Maciej W. Rozycki" , SGI MIPS list , Debian MIPS list , Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010731002421.A19713@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 > I really *hate* to see so many different implementations. That counts > to about 21..25 pieces of code, always written for the same thing. > Well, I'll start off in merging in those two declance drivers. But > this will come no earlier that in two weeks or so. I'll first do > the serial keyboard with dz.c. I sent this earlier but attached some large files.. so in case people on the list didn't get it .. http://www.skynet.ie/~airlied/mips/dz.c and dec_dz_keyb.c are my initial attempts at dz keyboard support for DS5000/200, they required the access.bus keyboard supprt (or at least lk201 stuff).... just in case the are usefull.. they worked for lowercase, but the shift state stuff is all wrong... I lost my monitor soon afterwards which stopped my development.. I think someone else is working on this maybe Karsten Merker... Dave. > > MfG, JBG > PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to > *BSD :-) Who will ever attempt to clean up? > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Thu Aug 2 10:45:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72HjKN13125 for linux-mips-outgoing; Thu, 2 Aug 2001 10:45:20 -0700 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 f72Hj1V13115 for ; Thu, 2 Aug 2001 10:45:15 -0700 Received: from ayrnetworks.com (IDENT:chua@localhost.localdomain [127.0.0.1]) by banff.ayrnetworks.com (8.11.0/8.11.0) with ESMTP id f72Hh2H14822 for ; Thu, 2 Aug 2001 10:43:02 -0700 Message-ID: <3B699126.E1B5F5E0@ayrnetworks.com> Date: Thu, 02 Aug 2001 10:43:02 -0700 From: Bryan Chua X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: xtime declaration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone else come across a compile error: mips-linux-gcc -I /local/chua/public/linux-mips-latest/include/asm/gcc -D__KERNEL__ -I/local/chua/public/linux-mips-latest/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -c -o timer.o timer.c timer.c:35: conflicting types for `xtime' /local/chua/public/linux-mips-latest/include/linux/sched.h:540: previous declaration of `xtime' in include/linux/sched.h: extern struct timeval xtime; int timer.c: volatile struct timeval xtime __attribute__ ((aligned (16))); I am using gcc 3.0 and binutils 2.11.2, both of the released versions. I do not know if my kernel actually runs yet with this toolchain... -- bryan From owner-linux-mips@oss.sgi.com Thu Aug 2 13:25:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72KP3g06094 for linux-mips-outgoing; Thu, 2 Aug 2001 13:25:03 -0700 Received: from bagpuss.swansea.linux.org.uk (pc1-cwbl2-0-cust80.cdf.cable.ntl.com [62.252.63.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72KP1V06085 for ; Thu, 2 Aug 2001 13:25:02 -0700 Received: (from alan@localhost) by bagpuss.swansea.linux.org.uk (8.11.2/8.11.2) id f6TLQ7m01578; Sun, 29 Jul 2001 17:26:07 -0400 From: Alan Cox Message-Id: <200107292126.f6TLQ7m01578@bagpuss.swansea.linux.org.uk> Subject: Re: [long] Lance on DS5k/200 To: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Sun, 29 Jul 2001 17:26:06 -0400 (EDT) Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), airlied@csn.ul.ie (Dave Airlie), linux-mips@oss.sgi.com (SGI MIPS list), debian-mips@lists.debian.org (Debian MIPS list), engel@unix-ag.org In-Reply-To: <20010731004556.C19713@lug-owl.de> from "Jan-Benedict Glaw" at Jul 31, 2001 12:45:56 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Z8530 is on my to-do list. Our driver really sucks: neither DMA (the I/O > > ASIC again) nor sychronous mode, just basic asynchronous support. I'm > > going to look at LANCE one day, too, but it's lower on the list. > > You you facing towards all those Z8530 implementation or only to > "ours"? All the 8530 sync support is in my Z85230 driver. Its written so someone can add async support to it. From owner-linux-mips@oss.sgi.com Thu Aug 2 17:46:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f730kLe19601 for linux-mips-outgoing; Thu, 2 Aug 2001 17:46:21 -0700 Received: from dea.waldorf-gmbh.de (u-227-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f730kIV19595 for ; Thu, 2 Aug 2001 17:46:19 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f730j1q28023; Fri, 3 Aug 2001 02:45:01 +0200 Date: Fri, 3 Aug 2001 02:45:01 +0200 From: Ralf Baechle To: Bryan Chua Cc: linux-mips@oss.sgi.com Subject: Re: xtime declaration Message-ID: <20010803024501.A27708@bacchus.dhis.org> References: <3B699126.E1B5F5E0@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B699126.E1B5F5E0@ayrnetworks.com>; from chua@ayrnetworks.com on Thu, Aug 02, 2001 at 10:43:02AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 02, 2001 at 10:43:02AM -0700, Bryan Chua wrote: > Has anyone else come across a compile error: > > mips-linux-gcc -I /local/chua/public/linux-mips-latest/include/asm/gcc > -D__KERNEL__ -I/local/chua/public/linux-mips-latest/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 > -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -c -o > timer.o timer.c > timer.c:35: conflicting types for `xtime' > /local/chua/public/linux-mips-latest/include/linux/sched.h:540: previous > declaration of `xtime' > > in include/linux/sched.h: > extern struct timeval xtime; > > int timer.c: > volatile struct timeval xtime __attribute__ ((aligned (16))); > > I am using gcc 3.0 and binutils 2.11.2, both of the released versions. > I do not know if my kernel actually runs yet with this toolchain... That's a bug which got fixed in the latest kernels by removing the volatile from the sched.h declaration. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 2 22:45:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f735ja224056 for linux-mips-outgoing; Thu, 2 Aug 2001 22:45:36 -0700 Received: from firsmail.shanshan.com.cn ([202.96.104.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f735jUV24037; Thu, 2 Aug 2001 22:45:31 -0700 Date: Thu, 2 Aug 2001 22:45:31 -0700 Message-Id: <200108030545.f735jUV24037@oss.sgi.com> Received: from all-life.com by firsmail.shanshan.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id QBNWVQ9Y; Fri, 3 Aug 2001 12:36:46 +0800 From: "toddra@4news.com" To: "4813@another.com" <4813@another.com> Subject: Get the word out about your business. Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Triple Your Business in 60 Days or Less !! Generate traffic to your website by the thousands!!! Have complete control on who receives your ad. Get thousands of Targeted visitors!!! Why it Works. Because you can deliver your message to millions of people for a fraction of the cost of conventional advertising. That's right it's less than a classified ad that would only reach a fraction of the audience. What we offer you. A complete turn-key operation for you. * Total Control- We can expose your product to hundreds of millions of people of your choosing. * Full Marketing Team - Our marketing team will help you create an effective marketing piece for your campaign . * FREE use of software - we will provide you with state of the art software specifcally designed to contact all the prospects you need. * 100% customer service and tech support - Your success is our success !! EASY As 1...2...3... It's easy to get started simply reply today and we will set you up with this fantastic system, specifically designed for "Your success on The Net" Call 702-252-4626 To Unsubscribe to this email list, please go to delete@eurosport.com and type "ELIMINATE" in the subject line. Thank you. From owner-linux-mips@oss.sgi.com Thu Aug 2 23:11:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f736BaJ27981 for linux-mips-outgoing; Thu, 2 Aug 2001 23:11:36 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f736BaV27978 for ; Thu, 2 Aug 2001 23:11:36 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id XAA03764 for ; Thu, 2 Aug 2001 23:09:24 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14871; Fri, 3 Aug 2001 16:10:06 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips In-reply-to: Your message of "Thu, 28 Jun 2001 16:32:51 +0200." <20010628163250.D28583@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Aug 2001 16:10:06 +1000 Message-ID: <17478.996819006@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Resend, no response. On Thu, 28 Jun 2001 16:32:51 +0200, Thiemo Seufer wrote: >Keith Owens wrote: >[snip] >> >The best option is for a mips64 kernel to indicate that it is 64 bit >> >and its endianess. Instead of printing > >The appended patch introduces the new format in mips64. Maybe this speeds >up agreement about it. :-) I am updating ksymoops now and need some information. Could somebody tell me what this produces on mips? # objdump -x ksymoops | head -8 # objdump -x mips64-lsb-vmlinux | head -8 # objdump -x mips64-msb-vmlinux | head -8 where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB and MSB. From owner-linux-mips@oss.sgi.com Fri Aug 3 02:59:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f739xem04393 for linux-mips-outgoing; Fri, 3 Aug 2001 02:59:40 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f739xcV04389 for ; Fri, 3 Aug 2001 02:59:38 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id LAA133555 for ; Fri, 3 Aug 2001 11:59:36 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Sbjz-0000m0-00 for ; Fri, 03 Aug 2001 11:59:35 +0200 Date: Fri, 3 Aug 2001 11:59:35 +0200 To: linux-mips@oss.sgi.com Subject: Re: xtime declaration Message-ID: <20010803115935.B26278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010803024501.A27708@bacchus.dhis.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: [snip] > > timer.c:35: conflicting types for `xtime' > > /local/chua/public/linux-mips-latest/include/linux/sched.h:540: previous > > declaration of `xtime' > > > > in include/linux/sched.h: > > extern struct timeval xtime; > > > > int timer.c: > > volatile struct timeval xtime __attribute__ ((aligned (16))); > > > > I am using gcc 3.0 and binutils 2.11.2, both of the released versions. > > I do not know if my kernel actually runs yet with this toolchain... > > That's a bug which got fixed in the latest kernels by removing the > volatile from the sched.h declaration. And since timer.c kept the volatile definition, it does not compile now. The volatile should either be removed in timer.c or added in sched.h, I don't know what is right. Thiemo From owner-linux-mips@oss.sgi.com Fri Aug 3 03:07:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73A7Rj04932 for linux-mips-outgoing; Fri, 3 Aug 2001 03:07:27 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73A7OV04929 for ; Fri, 3 Aug 2001 03:07:24 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id MAA133599 for ; Fri, 3 Aug 2001 12:07:23 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15SbrW-0000nb-00 for ; Fri, 03 Aug 2001 12:07:22 +0200 Date: Fri, 3 Aug 2001 12:07:22 +0200 To: linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips Message-ID: <20010803120722.C26278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17478.996819006@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Keith Owens wrote: > Resend, no response. I tried to send you something via PM, but your email address gave errors. ----- Transcript of session follows ----- 451 ... reply: read error from mail.ocs.com.au. ... Deferred: Connection reset by mail.ocs.com.au. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old [snip] > >I am updating ksymoops now and need some information. Could somebody > >tell me what this produces on mips? > > > ># objdump -h ksymoops | head -8 > ># objdump -h mips64-lsb-vmlinux | head -8 > ># objdump -h mips64-msb-vmlinux | head -8 > > > >where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB > >and MSB. > > Sorry, that should have been objdump -x, not objdump -h, I need the > architecture type as well as the file format. What I have is not the "official" CVS kernel but a patched version, along with a patched toolchain. It already uses elf64-tradbigmips instead of elf64-bigmips and has a different start address as it is loaded in 64bit address space. I haven't cared about little endian yet (no such hardware). So it's just for reference for now, possibly it helps. Thiemo ----------------------------------------------------------------------- mips64-msb-vmlinux: file format elf64-tradbigmips mips64-msb-vmlinux architecture: mips:8000, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0xa8000000201b4000 Program Header: From owner-linux-mips@oss.sgi.com Fri Aug 3 08:39:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73Fdos13791 for linux-mips-outgoing; Fri, 3 Aug 2001 08:39:50 -0700 Received: from dea.waldorf-gmbh.de (u-54-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73FdjV13767 for ; Fri, 3 Aug 2001 08:39:47 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f73DU4x30746; Fri, 3 Aug 2001 15:30:04 +0200 Date: Fri, 3 Aug 2001 15:30:04 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: xtime declaration Message-ID: <20010803153004.B30319@bacchus.dhis.org> References: <20010803024501.A27708@bacchus.dhis.org> <20010803115935.B26278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010803115935.B26278@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, Aug 03, 2001 at 11:59:35AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 03, 2001 at 11:59:35AM +0200, Thiemo Seufer wrote: > > That's a bug which got fixed in the latest kernels by removing the > > volatile from the sched.h declaration. > > And since timer.c kept the volatile definition, it does not compile > now. The volatile should either be removed in timer.c or added in > sched.h, I don't know what is right. Remove the volatile from timer.c; that's what's in 2.4.7. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 3 09:49:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73GnvT15718 for linux-mips-outgoing; Fri, 3 Aug 2001 09:49:57 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73GnoV15712 for ; Fri, 3 Aug 2001 09:49:51 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR1VGF>; Fri, 3 Aug 2001 11:49:23 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BE0@ATVX> From: "Siders, Keith" To: "'linux-mips@oss.sgi.com'" Subject: Re: Linux 2.4.6 Date: Fri, 3 Aug 2001 11:48:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Still getting the following for make config/oldconfig/vmlinux. What works (or seem to): make clean/mrproper/depend. What am I missing? I also get this on the MIPS Linux 2.4.3 from the MIPS site. > bash-2.04$ make config > rm -f include/asm > ( cd include ; ln -sf asm-mips asm) > /bin/sh scripts/Configure arch/mips/config.in > : command not found > 'cripts/Configure: line 68: syntax error near unexpected token `{ > 'cripts/Configure: line 68: `function mainmenu_option () { > make: *** [config] Error 2 > bash-2.04$ > > > 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 Fri Aug 3 14:16:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73LGCc26977 for linux-mips-outgoing; Fri, 3 Aug 2001 14:16:12 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73LGCV26974 for ; Fri, 3 Aug 2001 14:16:12 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f73LFsG02037; Fri, 3 Aug 2001 14:15:54 -0700 (PDT) Date: Fri, 3 Aug 2001 14:15:54 -0700 (PDT) From: "John D. Davis" To: SGI MIPS list , Debian MIPS list Subject: printk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does anyone know off hand, the earlies point that I can use printk? I added some printk statements to driver/char/console.c and the resulting kernel hangs with only the logo showing and no text. Is prom_printf something that I should use instead. I put some printk statements in tty_io.c and kernel/printk.c and those compiled kernels work. thanks, john davis From owner-linux-mips@oss.sgi.com Fri Aug 3 14:21:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73LLAj27461 for linux-mips-outgoing; Fri, 3 Aug 2001 14:21:10 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73LL4V27451 for ; Fri, 3 Aug 2001 14:21:09 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f73LQGA30060; Fri, 3 Aug 2001 14:26:16 -0700 Message-ID: <3B6B160C.6000609@pacbell.net> Date: Fri, 03 Aug 2001 14:22:20 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "John D. Davis" CC: SGI MIPS list , Debian MIPS list Subject: Re: printk References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk John D. Davis wrote: > Does anyone know off hand, the earlies point that I can use printk? Well, you can use them from the very beginning, but you won't see the output until after serial console init (if you're using a serial console). > I added some printk statements to driver/char/console.c and the resulting > kernel hangs with only the logo showing and no text. Is prom_printf > something that I should use instead. I put some printk statements in > tty_io.c and kernel/printk.c and those compiled kernels work. I like using simple puts and put32 routines that print a string and a 32 bit number. These routines bang directly on the uart so you see the prints immediately, before printk works. Take a look at arch/mips/au1000/common/puts.c. Pete From owner-linux-mips@oss.sgi.com Fri Aug 3 14:36:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73LaVB28922 for linux-mips-outgoing; Fri, 3 Aug 2001 14:36:31 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73LaUV28915 for ; Fri, 3 Aug 2001 14:36:30 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f73LaHE1027609; Fri, 3 Aug 2001 14:36:17 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f73LaGOX027602; Fri, 3 Aug 2001 14:36:16 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 3 Aug 2001 14:36:16 -0700 (PDT) From: James Simmons To: "John D. Davis" cc: SGI MIPS list , Debian MIPS list Subject: Re: printk 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 > Does anyone know off hand, the earlies point that I can use printk? Very early. Right after IRQs are setup and started. If no hardware is present that can print the messages out the messages are queued in the log buffer and once a device registers itself as a console it will flush that buffer, thus printing everything. How soon can a register a device as a console. Well that depends on when linux initializes the hardware. > I added some printk statements to driver/char/console.c and the > resulting kernel hangs with only the logo showing and no text. Printk calls the functons in console.c which in turn calls printk which in turn and so on. So you get this recursive loop that goes on forever. So be careful. Also never call printk in interrupt handler. Printk turns off IRQs when printing. This will be fixed in 2.5.X. From owner-linux-mips@oss.sgi.com Fri Aug 3 14:46:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f73LklH29898 for linux-mips-outgoing; Fri, 3 Aug 2001 14:46:47 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f73LkhV29891 for ; Fri, 3 Aug 2001 14:46:43 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id OAA08494; Fri, 3 Aug 2001 14:41:43 -0700 Date: Fri, 3 Aug 2001 14:41:43 -0700 From: Jun Sun To: "John D. Davis" Cc: linux-mips@oss.sgi.com Subject: Re: printk Message-ID: <20010803144143.B3894@mvista.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johnd@stanford.edu on Fri, Aug 03, 2001 at 02:15:54PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 03, 2001 at 02:15:54PM -0700, John D. Davis wrote: > Does anyone know off hand, the earlies point that I can use printk? I > added some printk statements to driver/char/console.c and the resulting > kernel hangs with only the logo showing and no text. Is prom_printf > something that I should use instead. I put some printk statements in > tty_io.c and kernel/printk.c and those compiled kernels work. > > thanks, > john davis > Like other folks from this list have pointed out, you can use it as early as the first C line. The output is stored in a memory buffer and later displayed on your screen when your serial console is registered. When porting to a new machine, I often use dev-only patch (i.e., not meant to be checked in) to enable seeing printk immediately, *if* it is a standard UART port. See the attache patch below. I don't recommand use or implement prom_printf. Jun --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="early-printk.patch" diff -Nru linux/kernel/printk.c.orig linux/kernel/printk.c --- linux/kernel/printk.c.orig Fri Mar 9 12:34:58 2001 +++ linux/kernel/printk.c Thu Mar 15 14:24:19 2001 @@ -251,6 +251,7 @@ return do_syslog(type, buf, len); } +extern void debug_out(char * msg, int len); asmlinkage int printk(const char *fmt, ...) { va_list args; @@ -296,6 +297,11 @@ break; } } + + /* jsun */ + debug_out(msg, p - msg + line_feed); + + /* if (msg_level < console_loglevel && console_drivers) { struct console *c = console_drivers; while(c) { @@ -304,6 +310,7 @@ c = c->next; } } + */ if (line_feed) msg_level = -1; } @@ -494,4 +501,132 @@ if (tty && tty->driver.write) tty->driver.write(tty, 0, msg, strlen(msg)); return; +} + + +/* --- CONFIG --- */ + +/* we need uint32 uint8 */ +/* #include "types.h" */ +typedef unsigned char uint8; +typedef unsigned int uint32; + +/* --- END OF CONFIG --- */ + +#define UART16550_BAUD_2400 2400 +#define UART16550_BAUD_4800 4800 +#define UART16550_BAUD_9600 9600 +#define UART16550_BAUD_19200 19200 +#define UART16550_BAUD_38400 38400 +#define UART16550_BAUD_57600 57600 +#define UART16550_BAUD_115200 115200 + +#define UART16550_PARITY_NONE 0 +#define UART16550_PARITY_ODD 0x08 +#define UART16550_PARITY_EVEN 0x18 +#define UART16550_PARITY_MARK 0x28 +#define UART16550_PARITY_SPACE 0x38 + +#define UART16550_DATA_5BIT 0x0 +#define UART16550_DATA_6BIT 0x1 +#define UART16550_DATA_7BIT 0x2 +#define UART16550_DATA_8BIT 0x3 + +#define UART16550_STOP_1BIT 0x0 +#define UART16550_STOP_2BIT 0x4 + +void Uart16550Init(uint32 baud, uint8 data, uint8 parity, uint8 stop); + +/* blocking call */ +uint8 Uart16550GetPoll(void); + +void Uart16550Put(uint8 byte); + +/* ----------------------------------------------------- */ + +/* === CONFIG === */ + +#define BASE 0xbfa04200 +#define MAX_BAUD 115200 +#define REG_OFFSET 8 + +/* === END OF CONFIG === */ + +/* register offset */ +#define OFS_RCV_BUFFER (0*REG_OFFSET) +#define OFS_TRANS_HOLD (0*REG_OFFSET) +#define OFS_SEND_BUFFER (0*REG_OFFSET) +#define OFS_INTR_ENABLE (1*REG_OFFSET) +#define OFS_INTR_ID (2*REG_OFFSET) +#define OFS_DATA_FORMAT (3*REG_OFFSET) +#define OFS_LINE_CONTROL (3*REG_OFFSET) +#define OFS_MODEM_CONTROL (4*REG_OFFSET) +#define OFS_RS232_OUTPUT (4*REG_OFFSET) +#define OFS_LINE_STATUS (5*REG_OFFSET) +#define OFS_MODEM_STATUS (6*REG_OFFSET) +#define OFS_RS232_INPUT (6*REG_OFFSET) +#define OFS_SCRATCH_PAD (7*REG_OFFSET) + +#define OFS_DIVISOR_LSB (0*REG_OFFSET) +#define OFS_DIVISOR_MSB (1*REG_OFFSET) + + +/* memory-mapped read/write of the port */ +#define UART16550_READ(y) (*((volatile uint8*)(BASE + y))) +#define UART16550_WRITE(y, z) ((*((volatile uint8*)(BASE + y))) = z) + +#define DEBUG_LED (*(unsigned short*)0xb7ffffc0) +#define OutputLED(x) (DEBUG_LED = x) + +void Uart16550Init(uint32 baud, uint8 data, uint8 parity, uint8 stop) +{ + /* disable interrupts */ + UART16550_WRITE(OFS_INTR_ENABLE, 0); + + /* set up buad rate */ + { + uint32 divisor; + + /* set DIAB bit */ + UART16550_WRITE(OFS_LINE_CONTROL, 0x80); + + /* set divisor */ + divisor = MAX_BAUD / baud; + UART16550_WRITE(OFS_DIVISOR_LSB, divisor & 0xff); + UART16550_WRITE(OFS_DIVISOR_MSB, (divisor & 0xff00)>>8); + + /* clear DIAB bit */ + UART16550_WRITE(OFS_LINE_CONTROL, 0x0); + } + + /* set data format */ + UART16550_WRITE(OFS_DATA_FORMAT, data | parity | stop); +} + +uint8 Uart16550GetPoll(void) +{ + while((UART16550_READ(OFS_LINE_STATUS) & 0x1) == 0); + return UART16550_READ(OFS_RCV_BUFFER); +} + + +void Uart16550Put(uint8 byte) +{ + while ((UART16550_READ(OFS_LINE_STATUS) &0x20) == 0); + UART16550_WRITE(OFS_SEND_BUFFER, byte); +} + +/* ---------------------------------------------------------- */ + +void debug_out(char * msg, int len) +{ + int i; + for (i=0; i< len; i++) { + if (msg[i] == '\n') { + Uart16550Put('\r'); + Uart16550Put('\n'); + } else { + Uart16550Put(msg[i]); + } + } } --G4iJoqBmSsgzjUCe-- From owner-linux-mips@oss.sgi.com Fri Aug 3 19:15:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f742FZL23938 for linux-mips-outgoing; Fri, 3 Aug 2001 19:15:35 -0700 Received: from smtp.huawei.com (nszx104.121.szptt.net.cn [202.104.121.208] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f742FXV23931 for ; Fri, 3 Aug 2001 19:15:33 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GHITZ201.I0M for ; Sat, 4 Aug 2001 10:09:02 +0800 Message-ID: <000701c11c8b$77e039e0$8021690a@huawei.com> From: "machael thailer" To: Subject: Where is the first entry point for linux-mips boot? Date: Sat, 4 Aug 2001 10:16:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello,all: Now I plan to port linux on our mips-based board. Since it is the first time for me to work on linux-mips, I have several questions to ask: There are many many subdirectories in arch/mips, I don't know where is the FIRST entry point for embedded linux-mips boot process? I find that there is "kernel_entry" in arch/mips/kernel/head.S. I know this is the entry point for linux kernel ,but it is not the FIRST entry point for embedded linux-mips boot process. So my questions is : After the board initializations finish, it should load linux kernel into RAM and jump there . Just before it runs the linux kernel, who calls "kernel_entry"? I don't know whether I have expressed my meaning apparently. Hope you can understand me. Thank you very much. machael thailer From owner-linux-mips@oss.sgi.com Fri Aug 3 22:11:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f745B2e14382 for linux-mips-outgoing; Fri, 3 Aug 2001 22:11:02 -0700 Received: from dea.waldorf-gmbh.de (u-146-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f745AxV14378 for ; Fri, 3 Aug 2001 22:10:59 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f745AGD02372; Sat, 4 Aug 2001 07:10:16 +0200 Date: Sat, 4 Aug 2001 07:10:16 +0200 From: Ralf Baechle To: machael thailer Cc: linux-mips@oss.sgi.com Subject: Re: Where is the first entry point for linux-mips boot? Message-ID: <20010804071016.A1275@bacchus.dhis.org> References: <000701c11c8b$77e039e0$8021690a@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: <000701c11c8b$77e039e0$8021690a@huawei.com>; from dony.he@huawei.com on Sat, Aug 04, 2001 at 10:16:27AM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Aug 04, 2001 at 10:16:27AM +0800, machael thailer wrote: > There are many many subdirectories in arch/mips, I don't know where is > the FIRST entry point for embedded linux-mips boot process? I find that > there is "kernel_entry" in arch/mips/kernel/head.S. I know this is the entry > point for linux kernel ,but it is not the FIRST entry point for embedded > linux-mips boot process. So my questions is : > After the board initializations finish, it should load linux kernel into > RAM and jump there . Just before it runs the linux kernel, who calls > "kernel_entry"? The firmware or bootloader. Ralf From owner-linux-mips@oss.sgi.com Sat Aug 4 07:02:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f74E2bh16878 for linux-mips-outgoing; Sat, 4 Aug 2001 07:02:37 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f74E2XV16866; Sat, 4 Aug 2001 07:02:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA05642; Sat, 4 Aug 2001 07:02:21 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA28502; Sat, 4 Aug 2001 07:02:17 -0700 (PDT) Message-ID: <006b01c11cee$b54cfbc0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Carsten Langgaard" , , "Ralf Baechle" Cc: "MIPS/Linux List \(SGI\)" References: <3B53679A.4020809@mvista.com> <3B53D22D.D8913C09@mips.com> <3B53D4DB.2090809@mvista.com> <3B53D895.30D92792@mips.com> <3B53DB71.8040501@mvista.com> <3B53DCDA.ECAB628E@mips.com> <3B53E00F.4070904@mvista.com> <3B53E654.325D030@mips.com> <3B53E79F.80409@mvista.com> <3B53ECA3.2BD2104E@mips.com> <3B53EF8B.8010003@mvista.com> <3B53F42C.6F409B70@mips.com> <3B53F5A7.8020705@mvista.com> <3B53F6E2.FE19F0CA@mips.com> Subject: FPU Emulation and Signals - An Alternative Fix Date: Sat, 4 Aug 2001 16:06:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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 To recap, Pete found a hole in the FPU emulator code, wherein a signal delivered between the setup and the execution of the trampoline code for an instruction in the delay slot of an emulated floating point branch would trash the trampoline code and cause Bad Things to happen. Adding a more space between the user stack pointer and the trampoline code solves the problem in a particular case, but is provably still at risk, since signal handlers can allocate arbitrary amounts of stack storage. Carsten and I both developed patches to inhibit the delivery of signals during the trampoline. This had the defect of causing processes to block indefinitely in cases where the instruction being executed by the trampoline itself causes an exception, as Carsten was able to demonstrate using "crashme". My patch used relatively heavyweight high-level mechanisms, which have the virtue of being easily configurable to allow certain signals from which the signal handler is unable or unlikely to return (such as SIGILL, SIGSEGV, and SIGBUS) to be delivered. That seems to be OK for both crashme and Pete's program, but I believe it is still broken for things like trap instructions in the branch delay slot, and for ptrace() single-stepping. So I've got another idea that I think is much better, and I'm kicking myself for not having thought of it earlier. The idea is to simply ensure that signal stack frames always leave a space between the current user SP and the stack frame itself. If no signals fire, fine. If a signal is delivered and caught, its frame will be beyond the FP emulator trampoline. This is a trivial hack to get_sigframe() that should be completely harmless (aside from increased memory consumption), since it's aleady set up to accept signal frames that aren't on the stack as per Posix signal stacks. There are, however, a flies in the ointment, as always. Once we commit that original sin of allowing signals to "play through" during the trampoline sequence, we open the door to a signal handler containing FP branches itself, which would need to be emulated. Yes, we could create another trampoline further up the stack, but the problem is that the thread-specific data to allow recovery from the first trampoline will be overwritten by the second. Furthermore, the trampoline mechanism is terminated by catching the next unaligned access fault for the thread. A signal handler could also generate an unaligned access fault. The former problem could probably be worked around acceptably by simply having the FP trap handler notice that it is already in a delay-slot-emulation sequence, and nail the process with SIGFPE or SIGILL if it happens to do another one. Not nice, but at least consistent, and the case is highly unlikely to arise. But we've still got the unaligned access case to consider. So I submit the following for your consideration. In the FP emulator, when we set up the trampoline, we set up the following above the user stack: Instruction-to-be-executed AdELOAD (unaligned load of r0 off of r0) Magic-cookie-that-is-an-unimplemented-instruction EPC-to-use-on-completion Rather than use thread.desmul_epc as a flag to indicate to the unaligned access handler that there is emulation going on, the unaligned access handler would test to see if the unaligned access instruction itself was the AdELOAD, and that it is followed by the magic cookie, and if so, treat that as an indication to stuff the value following the sequence (as indicated by EPC, modulo branch delays) into the EPC and return. This way, one could nest an arbitrary number of emulation/signal/emulation sequences, and they should unroll correctly. The further magic cookie is needed since, even though it's a completely useless instruction, the AdELOAD could be encountered for other reasons, as a misguided attempt at cache prefetch, or by executing crashme. It's a useless instruction to emulate, having r0 as the destination, but the normal Linux semantics as I understand them would be to turn it into a very expensive no-op and continue in what might otherwise be safe and sane execution. With the addtional code word after the AdELOAD (and before the EPC) on the dsemul stack that would be (more-or-less) guaranteed to really be an illegal instruction, the only risk we would be taking would be to have a program really containing the unaligned nonsense load followed by the illegal instruction blow up, not on the illegal instruction, but by picking up a bogus EPC. Not perfect. But maybe the lesser of several evils. I'm working on a prototype, but do you think that this scheme is viable? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sun Aug 5 03:52:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75Aqk017868 for linux-mips-outgoing; Sun, 5 Aug 2001 03:52:46 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75AqfV17857; Sun, 5 Aug 2001 03:52:41 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA09072; Sun, 5 Aug 2001 03:52:26 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA06212; Sun, 5 Aug 2001 03:52:25 -0700 (PDT) Message-ID: <004f01c11d9d$595ca7c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , , "Carsten Langgaard" Cc: "MIPS/Linux List \(SGI\)" References: <3B53679A.4020809@mvista.com> <3B53D22D.D8913C09@mips.com> <3B53D4DB.2090809@mvista.com> <3B53D895.30D92792@mips.com> <3B53DB71.8040501@mvista.com> <3B53DCDA.ECAB628E@mips.com> <3B53E00F.4070904@mvista.com> <3B53E654.325D030@mips.com> <3B53E79F.80409@mvista.com> <3B53ECA3.2BD2104E@mips.com> <3B53EF8B.8010003@mvista.com> <3B53F42C.6F409B70@mips.com> <3B53F5A7.8020705@mvista.com> <3B53F6E2.FE19F0CA@mips.com> <006b01c11cee$b54cfbc0$0deca8c0@Ulysses> Subject: Re: FPU Emulation and Signals - An Alternative Fix Date: Sun, 5 Aug 2001 12:56:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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 > So I submit the following for your consideration. > In the FP emulator, when we set up the trampoline, we set > up the following above the user stack: > > Instruction-to-be-executed > AdELOAD (unaligned load of r0 off of r0) > Magic-cookie-that-is-an-unimplemented-instruction > EPC-to-use-on-completion > > Rather than use thread.desmul_epc as a flag to indicate > to the unaligned access handler that there is emulation > going on, the unaligned access handler would test to see > if the unaligned access instruction itself was the AdELOAD, > and that it is followed by the magic cookie, and if so, treat > that as an indication to stuff the value following the sequence > (as indicated by EPC, modulo branch delays) into the EPC > and return. This way, one could nest an arbitrary number of > emulation/signal/emulation sequences, and they should unroll > correctly. The further magic cookie is needed since, even though > it's a completely useless instruction, the AdELOAD could be > encountered for other reasons, as a misguided attempt > at cache prefetch, or by executing crashme. It's a useless instruction > to emulate, having r0 as the destination, but the normal Linux semantics > as I understand them would be to turn it into a very expensive > no-op and continue in what might otherwise be safe and sane > execution. With the addtional code word after the AdELOAD > (and before the EPC) on the dsemul stack that would be (more-or-less) > guaranteed to really be an illegal instruction, the only risk we would > be taking would be to have a program really containing the > unaligned nonsense load followed by the illegal instruction > blow up, not on the illegal instruction, but by picking up a bogus > EPC. Not perfect. But maybe the lesser of several evils. One further embellishment and one further alternative to consider: The thread data field currently used to store the post-trampoline EPC value can be renamed and used instead as a counter of the "depth" of FP branch delay slot emulation. If the count is zero, the unaligned access trap does not look for the magic sequence described above, and just emulates the AdELOAD instruction. Unfortunately, a signal handler that invokes a longjmp will not return to the trampoline, not invoke the associated trap, and thus not decrement the counter, so a non-zero count cannot be taken as absolute proof that a branch emulation is pending. The hack would further reduce the probability of a "naturally occurring" AdELOAD/MagicCookie sequence being mishandled, not eliminate the possibility. The scheme proposed above allows arbitrary recursion (a Good Thing) but also misdiagnosis of a wildly improbable but conceptually possible error condition (a Bad Thing). An alternative - still in conjunction with the proposed gap-between-user-stack-and-signal-stack technique - would be to replace the single EPC storage location in the thread data with, say, three storage locations and an additional variable that serves as a sort of "stack pointer" for the EPCs. In this model, the EPCs are kept off the user stack and no magic cookies are needed. If nesting of FP branch emulation exceeds three, the process gets nailed with a fatal error. This would not allow arbitrary recursion and would increase the static size of the thread data structure (Bad Things), but would, within the constraints of the allowed depth of recursion, create no ambiguous situations (a Good Thing). Any comments or declarations of preference? I guess it boils down to the question of what is more probable, a naturally occurring sequence of AdELOAD/MagicCookie or a 4-way nesting of signals delivered in the branch emulation delay trampoline window. Both strike me as unlikely, but I feel more confident about my estimate of the former than of the later. Sorry to bore 95% of you to tears with this stuff, but it really does matter to some of us, and I don't presume to know exactly who on the list could have valuable input. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sun Aug 5 09:48:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75Gm9I16535 for linux-mips-outgoing; Sun, 5 Aug 2001 09:48:09 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75Gm8V16532 for ; Sun, 5 Aug 2001 09:48:08 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 56D8B125C3; Sun, 5 Aug 2001 09:48:07 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id DB524EFB6; Sun, 5 Aug 2001 09:48:06 -0700 (PDT) Date: Sun, 5 Aug 2001 09:48:06 -0700 From: "H . J . Lu" To: Eric Christopher Cc: gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010805094806.A3146@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am working with Eric to clean up the Linux/mips configuration in gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They are the same on Linux/mips. There won't be any run-time problems. I am wondering if there are any compatibility problems at the compile time at the source and binary level. For one thing, __WCHAR_TYPE__ will be changed from "long int" to "int". The only thing I can think of is the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one I am working on will be the first gcc 3.x for Linux/mips. So there shouldn't be any problems. Am I right? H.J. From owner-linux-mips@oss.sgi.com Sun Aug 5 10:06:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75H6QH17048 for linux-mips-outgoing; Sun, 5 Aug 2001 10:06:26 -0700 Received: from ariane.ens-cachan.fr (root@ariane.ens-cachan.fr [138.231.176.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75H6OV17045 for ; Sun, 5 Aug 2001 10:06:25 -0700 Received: from mayo.cmla.ens-cachan.fr (mayo.cmla.ens-cachan.fr [138.231.64.2]) by ariane.ens-cachan.fr (8.12.0.Beta7/jtpda-5.3.3) with ESMTP id f75H6Hiw002547 ; Sun, 5 Aug 2001 19:06:17 +0200 Received: from jambon.cmla.ens-cachan.fr (jambon.cmla.ens-cachan.fr [138.231.64.60]) by mayo.cmla.ens-cachan.fr (8.9.1a/jtpda-5.3.2) with ESMTP id TAA03977 ; Sun, 5 Aug 2001 19:06:12 +0200 (MET DST) Received: from (dosreis@localhost) by jambon.cmla.ens-cachan.fr (8.9.3+Sun/jtpda-5.3.1/CL) id TAA05800 ; Sun, 5 Aug 2001 19:06:14 +0200 (MET DST) To: "H . J . Lu" Cc: Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? References: <20010805094806.A3146@lucon.org> From: Gabriel Dos Reis In-Reply-To: "H . J . Lu"'s message of "Sun, 5 Aug 2001 09:48:06 -0700" Organization: CodeSourcery, LLC Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: 05 Aug 2001 19:06:14 +0200 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" writes: | changed from "long int" to "int". The only thing I can think of is | the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one | I am working on will be the first gcc 3.x for Linux/mips. So there | shouldn't be any problems. Am I right? Normally, wchar_t is a keyword in C++ (as opposed to typedef in C). So at first sight, I would think there should be no problem with changing WCHAR_TYPE. But then, I may be missing some subtile ABI point. -- Gaby From owner-linux-mips@oss.sgi.com Sun Aug 5 12:59:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75JxWa20440 for linux-mips-outgoing; Sun, 5 Aug 2001 12:59:32 -0700 Received: from scsoftware.sc-software.com (mipsdev@[206.40.202.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75JxUV20435 for ; Sun, 5 Aug 2001 12:59:31 -0700 Received: from localhost (mipsdev@localhost) by scsoftware.sc-software.com (8.8.3/8.8.3) with SMTP id MAA15023; Sun, 5 Aug 2001 12:53:01 GMT Date: Sun, 5 Aug 2001 12:53:01 +0000 ( ) From: John Heil Reply-To: John Heil To: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, linux-mips@oss.sgi.com Subject: Qube2 gcc 2.7.2 compiler error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On the Qube2, gcc 2.7.2, option -s, to generate MIPS assembler corresponding to the input C code, generates invalid assembler by virtue of generating duplicate labels. The resultant assembler will not assemble, of course, due to the duplicate labels. The code (linux kernel's printk.c) compiles cleanly from C to object code. Q: How do I get valid assembler from gcc on Qube2 ? (My ultimate goal here is to be able to get listings out of gas.) Thanks much John H From owner-linux-mips@oss.sgi.com Sun Aug 5 13:05:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f75K5h821043 for linux-mips-outgoing; Sun, 5 Aug 2001 13:05:43 -0700 Received: from scsoftware.sc-software.com (mipsdev@[206.40.202.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f75K5fV21040 for ; Sun, 5 Aug 2001 13:05:42 -0700 Received: from localhost (mipsdev@localhost) by scsoftware.sc-software.com (8.8.3/8.8.3) with SMTP id MAA15054; Sun, 5 Aug 2001 12:59:23 GMT Date: Sun, 5 Aug 2001 12:59:23 +0000 ( ) From: John Heil To: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, linux-mips@oss.sgi.com Subject: Qube2 gcc 2.7.2 compiler error (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On the Qube2, gcc 2.7.2, option -s, to generate MIPS assembler corresponding to the input C code, generates invalid assembler by virtue of generating duplicate labels. The resultant assembler will not assemble, of course, due to the duplicate labels. The code (linux kernel's printk.c) compiles cleanly from C to object code. Q: How do I get valid assembler from gcc on Qube2 ? (My ultimate goal here is to be able to get listings out of gas.) Thanks much John H Oops, Sorry -> typo. I meant gcc -S Thanks From owner-linux-mips@oss.sgi.com Sun Aug 5 23:54:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f766som27993 for linux-mips-outgoing; Sun, 5 Aug 2001 23:54:50 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f766sZV27989; Sun, 5 Aug 2001 23:54:35 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 6 Aug 2001 06:54:35 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id PAA76785; Mon, 6 Aug 2001 15:54:33 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA46103; Mon, 6 Aug 2001 15:54:33 +0900 (JST) To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: Re: shm ipc broken From: Atsushi Nemoto In-Reply-To: <20010430004457.A1227@bacchus.dhis.org> References: <20010429210601.A16687@bilbo.physik.uni-konstanz.de> <20010430004457.A1227@bacchus.dhis.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug__6_15:58:43_2001_179)--" Content-Transfer-Encoding: 7bit Message-Id: <20010806155901I.nemoto@toshiba-tops.co.jp> Date: Mon, 06 Aug 2001 15:59:01 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 65 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----Next_Part(Mon_Aug__6_15:58:43_2001_179)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Mon, 30 Apr 2001 00:44:57 -0300, Ralf Baechle said: >> The attached patch fixes a problem with shm ipc. The structs >> ipc_perm in /u/i/bits/ipc.h and ipc64_perm in include/asm/ipcbuf.h >> had different sizes and so caused the copy_shminfo_to_user in >> ipc/shm.c to corrupt user space(the kernel structure was 8 bytes >> larger). >> ... ralf> Thanks for the report. Now, the kernel interface is what it is ralf> supposed to be so you patch was unacceptable. Instead I've sent ralf> below patch to to the libc maintainers for inclusion. Also for ralf> semaphores we also had a structure missmatch. There is still a structure mismatch between msqid_ds (in libc's bits/msq.h) and msqid64_ds (in kernel's asm-mips/msgbuf.h). Here is a patch to fix kernel's header, but I can not tell which one should be fixed. --- Atsushi Nemoto ----Next_Part(Mon_Aug__6_15:58:43_2001_179)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="msgbuf.h.patch" --- linux/include/asm-mips/msgbuf.h:1.1.1.1 Fri Jul 6 11:22:16 2001 +++ linux/include/asm-mips/msgbuf.h Thu Jul 26 12:13:43 2001 @@ -2,7 +2,7 @@ #define _ASM_MSGBUF_H /* - * The msqid64_ds structure for alpha architecture. + * The msqid64_ds structure for MIPS architecture. * Note extra padding because this structure is passed back and forth * between kernel and user space. * @@ -13,15 +13,18 @@ struct msqid64_ds { struct ipc64_perm msg_perm; __kernel_time_t msg_stime; /* last msgsnd time */ + unsigned long int __unused1; __kernel_time_t msg_rtime; /* last msgrcv time */ + unsigned long int __unused2; __kernel_time_t msg_ctime; /* last change time */ + unsigned long int __unused3; unsigned long msg_cbytes; /* current number of bytes on queue */ unsigned long msg_qnum; /* number of messages in queue */ unsigned long msg_qbytes; /* max number of bytes on queue */ __kernel_pid_t msg_lspid; /* pid of last msgsnd */ __kernel_pid_t msg_lrpid; /* last receive pid */ - unsigned long __unused1; - unsigned long __unused2; + unsigned long __unused4; + unsigned long __unused5; }; #endif /* _ASM_MSGBUF_H */ ----Next_Part(Mon_Aug__6_15:58:43_2001_179)---- From owner-linux-mips@oss.sgi.com Mon Aug 6 00:33:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f767Xvf29060 for linux-mips-outgoing; Mon, 6 Aug 2001 00:33:57 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f767XtV29057 for ; Mon, 6 Aug 2001 00:33:56 -0700 Message-Id: <200108060733.f767XtV29057@oss.sgi.com> Received: (qmail 18376 invoked from network); 6 Aug 2001 07:28:20 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 6 Aug 2001 07:28:20 -0000 Date: Mon, 6 Aug 2001 15:36:29 +0800 From: Fuxin Zhang To: "linux-mips@oss.sgi.com" Subject: XFree86 generic.c problem 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 hello,linux-mips When trying to crossing compile XFree86 server for my linux on mipsel machine(idt64474,p6032) i find some problems: 1. In: xc/programs/Xserver/hw/xfree86/int10/generic write_w & write_l They use #if X_BYTE_ORDER == X_LITTLE_ENDIAN if (OFF(addr + 3) > 2) { V_ADDR_WL(addr, val); } #endif V_ADDR_WB(addr, val); V_ADDR_WB(addr + 1, val >> 8); V_ADDR_WB(addr + 2, val >> 16); V_ADDR_WB(addr + 3, val >> 24); I think there should be a #else to prevent executing of the WB statement in little endian machines,am i missing something? 2.in xc/programs/Xserver/hw/xfree86/common/comiler.h These statements seems wrong: #define stq_u(v,p) stl_u(v,p) #define stl_u(v,p) (*(unsigned char *)(p)) = (v); \ (*(unsigned char *)(p)+1) = ((v) >> 8); \ ^^^^^ Should it be (*((unsigned char*)(p) + 1))? (*(unsigned char *)(p)+2) = ((v) >> 16); \ (*(unsigned char *)(p)+3) = ((v) >> 24) #define stw_u(v,p) (*(unsigned char *)(p)) = (v); \ (*(unsigned char *)(p)+1) = ((v) >> 8) Mr. Guido Guenther has posted a patch to work around it.But could it be right somewhere?Just curious:) Thank you in advance. Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Aug 6 00:40:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f767etY29272 for linux-mips-outgoing; Mon, 6 Aug 2001 00:40:55 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f767eoV29269 for ; Mon, 6 Aug 2001 00:40:51 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 6 Aug 2001 07:40:50 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id QAA77377; Mon, 6 Aug 2001 16:40:22 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id QAA46216; Mon, 6 Aug 2001 16:40:22 +0900 (JST) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Subject: SysV IPC shared memory and virtual alising From: Atsushi Nemoto To: linux-mips@oss.sgi.com, linux-mips@fnet.fr X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug__6_16:44:05_2001_756)--" Content-Transfer-Encoding: 7bit Message-Id: <20010806164452D.nemoto@toshiba-tops.co.jp> Date: Mon, 06 Aug 2001 16:44:52 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 94 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----Next_Part(Mon_Aug__6_16:44:05_2001_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is an patch to fix virtual aliasing problem with SysV IPC shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. If D-cache is smaller than PAGE_SIZE this patch is not needed at all, but I think it is not so bad unconditionally forcing alignment to SHMLBA. --- Atsushi Nemoto ----Next_Part(Mon_Aug__6_16:44:05_2001_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="unmapped_area.patch" diff -ur linux.sgi/arch/mips/kernel/syscall.c linux/arch/mips/kernel/syscall.c --- linux.sgi/arch/mips/kernel/syscall.c Thu Apr 5 13:56:09 2001 +++ linux/arch/mips/kernel/syscall.c Mon Aug 6 16:16:36 2001 @@ -30,6 +30,7 @@ #include #include #include +#include extern asmlinkage void syscall_trace(void); typedef asmlinkage int (*syscall_t)(void *a0,...); @@ -91,6 +92,47 @@ { return do_mmap2(addr, len, prot, flags, fd, pgoff); } + +#ifdef HAVE_ARCH_UNMAPPED_AREA +/* solve cache aliasing problem (see Documentation/cache.txt and + arch/sparc64/kernel/sys_sparc.c */ +#define COLOUR_ALIGN(addr) (((addr)+SHMLBA-1)&~(SHMLBA-1)) + +unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) +{ + struct vm_area_struct * vmm; + + if (flags & MAP_FIXED) { + /* We do not accept a shared mapping if it would violate + * cache aliasing constraints. + */ + if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1))) + return -EINVAL; + return addr; + } + + if (len > TASK_SIZE) + return -ENOMEM; + if (!addr) + addr = TASK_UNMAPPED_BASE; + + if (flags & MAP_SHARED) + addr = COLOUR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + + for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { + /* At this point: (!vmm || addr < vmm->vm_end). */ + if (TASK_SIZE - len < addr) + return -ENOMEM; + if (!vmm || addr + len <= vmm->vm_start) + return addr; + addr = vmm->vm_end; + if (flags & MAP_SHARED) + addr = COLOUR_ALIGN(addr); + } +} +#endif /* HAVE_ARCH_UNMAPPED_AREA */ save_static_function(sys_fork); static_unused int _sys_fork(struct pt_regs regs) diff -ur linux.sgi/include/asm-mips/pgtable.h linux/include/asm-mips/pgtable.h --- linux.sgi/include/asm-mips/pgtable.h Sun Aug 5 23:41:28 2001 +++ linux/include/asm-mips/pgtable.h Mon Aug 6 16:17:11 2001 @@ -740,6 +740,9 @@ #include +/* We provide our own get_unmapped_area to cope with VA holes for userland */ +#define HAVE_ARCH_UNMAPPED_AREA + #endif /* !defined (_LANGUAGE_ASSEMBLY) */ #define io_remap_page_range remap_page_range ----Next_Part(Mon_Aug__6_16:44:05_2001_756)---- From owner-linux-mips@oss.sgi.com Mon Aug 6 01:50:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f768ofR31654 for linux-mips-outgoing; Mon, 6 Aug 2001 01:50:41 -0700 Received: from kenton.algor.co.uk (smtp.algor.co.uk [62.254.210.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f768oYV31651 for ; Mon, 6 Aug 2001 01:50:37 -0700 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id JAA16147; Mon, 6 Aug 2001 09:50:15 +0100 (GMT/BST) Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id f768oEX01106; Mon, 6 Aug 2001 09:50:14 +0100 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.23110.345236.934305@gladsmuir.algor.co.uk> Date: Mon, 6 Aug 2001 09:50:14 +0100 (BST) To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising In-Reply-To: <20010806164452D.nemoto@toshiba-tops.co.jp> References: <20010806164452D.nemoto@toshiba-tops.co.jp> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Atsushi Nemoto (nemoto@toshiba-tops.co.jp) writes: > Here is an patch to fix virtual aliasing problem with SysV IPC > shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > If D-cache is smaller than PAGE_SIZE this patch is not needed at > all... More precisely, if the size of a D-cache "set" is smaller than PAGE_SIZE. So a CPU with a 16Kbyte 4-way set-associative cache and 4Kbyte PAGE_SIZE is safe. Dominic Sweetman Algorithmics Ltd From owner-linux-mips@oss.sgi.com Mon Aug 6 03:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76ABhq01359 for linux-mips-outgoing; Mon, 6 Aug 2001 03:11:43 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76ABMV01336; Mon, 6 Aug 2001 03:11:22 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 421571E532; Mon, 6 Aug 2001 12:11:16 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: Ralf Baechle Cc: "H . J . Lu" , Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> From: Andreas Jaeger Date: Mon, 06 Aug 2001 12:10:59 +0200 In-Reply-To: <20010806115913.B17179@bacchus.dhis.org> (Ralf Baechle's message of "Mon, 6 Aug 2001 11:59:13 +0200") Message-ID: Lines: 27 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-=-= Content-Transfer-Encoding: quoted-printable Ralf Baechle writes: > On Sun, Aug 05, 2001 at 09:48:06AM -0700, H . J . Lu wrote: > >> I am working with Eric to clean up the Linux/mips configuration in >> gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They >> are the same on Linux/mips. There won't be any run-time problems. I am >> wondering if there are any compatibility problems at the compile time >> at the source and binary level. For one thing, __WCHAR_TYPE__ will be >> changed from "long int" to "int". The only thing I can think of is >> the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one >> I am working on will be the first gcc 3.x for Linux/mips. So there >> shouldn't be any problems. Am I right? > > The MIPS ABI defines wchar_t to long. So please go ahead and make the > change. I'm confused. The ABI defines it to be long - and he should change it nevertheless? Andreas =2D-=20 Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7bm0zOJpWPMJyoSYRArSgAJ9Ct50CFo0gDljzP3M9kE0sdN+70QCeN6n9 WlALwFwEUpNW6OVo6ZPpa6k= =uKbi -----END PGP SIGNATURE----- --=-=-=-- From owner-linux-mips@oss.sgi.com Mon Aug 6 03:39:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76Adhm02721 for linux-mips-outgoing; Mon, 6 Aug 2001 03:39:43 -0700 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 f76AdeV02715 for ; Mon, 6 Aug 2001 03:39:40 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15ThnE-0001l3-00; Mon, 06 Aug 2001 12:39:28 +0200 Date: Mon, 6 Aug 2001 12:39:28 +0200 From: Guido Guenther To: Fuxin Zhang Cc: linux-mips@oss.sgi.com Subject: Re: XFree86 generic.c problem Message-ID: <20010806123928.G5525@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Fuxin Zhang , linux-mips@oss.sgi.com References: <200108060733.f767XtV29057@oss.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108060733.f767XtV29057@oss.sgi.com>; from fxzhang@ict.ac.cn on Mon, Aug 06, 2001 at 03:36:29PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 06, 2001 at 03:36:29PM +0800, Fuxin Zhang wrote: > hello,linux-mips > > When trying to crossing compile XFree86 server for my linux on mipsel > Mr. Guido Guenther has posted a patch to work around it.But could > it be right somewhere?Just curious:) > Thank you in advance. I have fixed this(and some other problems) in the debian XFree86 Packages but not submitted upstream yet. I've attched the patch. -- Guido --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="350_mips_compiler_h.diff" --- xc/programs/Xserver/hw/xfree86/common/compiler.h.orig Tue Jul 24 22:33:42 2001 +++ xc/programs/Xserver/hw/xfree86/common/compiler.h Tue Jul 24 22:37:37 2001 @@ -862,6 +862,67 @@ return r1; } +#ifdef linux /* don't mess with other OSs */ + +/* + * EGCS 1.1 knows about arbitrary unaligned loads (and we don't support older + * versions anyway. Define some packed structures to talk about such things + * with. + */ + +struct __una_u32 { unsigned int x __attribute__((packed)); }; +struct __una_u16 { unsigned short x __attribute__((packed)); }; + +static __inline__ void stw_u(unsigned long val, unsigned short *p) +{ + struct __una_u16 *ptr = (struct __una_u16 *) p; + ptr->x = val; +} + +static __inline__ void stl_u(unsigned long val, unsigned int *p) +{ + struct __una_u32 *ptr = (struct __una_u32 *) p; + ptr->x = val; +} + +#if X_BYTE_ORDER == X_BIG_ENDIAN +static __inline__ unsigned int +xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset) +{ + unsigned long addr = ((unsigned long)base) + offset; + unsigned int ret; + + __asm__ __volatile__("lw %0, 0(%1)" + : "=r" (ret) + : "r" (addr)); + return ret; +} + +static __inline__ void +xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset, + const unsigned int val) +{ + unsigned long addr = ((unsigned long)base) + offset; + + __asm__ __volatile__("sw %0, 0(%1)" + : /* No outputs */ + : "r" (val), "r" (addr)); +} +#endif + +#define mem_barrier() \ +__asm__ __volatile__( \ + "# prevent instructions being moved around\n\t" \ + ".set\tnoreorder\n\t" \ + "# 8 nops to fool the R4400 pipeline\n\t" \ + "nop;nop;nop;nop;nop;nop;nop;nop\n\t" \ + ".set\treorder" \ + : /* no output */ \ + : /* no input */ \ + : "memory") +#define write_mem_barrier() mem_barrier() + +#else /* !linux */ #define stq_u(v,p) stl_u(v,p) #define stl_u(v,p) (*(unsigned char *)(p)) = (v); \ (*(unsigned char *)(p)+1) = ((v) >> 8); \ @@ -872,6 +934,7 @@ (*(unsigned char *)(p)+1) = ((v) >> 8) #define mem_barrier() /* NOP */ +#endif /* !linux */ #endif /* __mips__ */ #if defined(__arm32__) --lEGEL1/lMxI0MVQ2-- From owner-linux-mips@oss.sgi.com Mon Aug 6 07:14:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76EEJD01652 for linux-mips-outgoing; Mon, 6 Aug 2001 07:14:19 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76EEIV01649 for ; Mon, 6 Aug 2001 07:14:18 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA15634; Mon, 6 Aug 2001 07:14:15 -0700 (PDT) Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? From: Eric Christopher To: "H . J . Lu" Cc: gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20010805094806.A3146@lucon.org> References: <20010805094806.A3146@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 15:12:56 +0100 Message-Id: <997107178.1253.7.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I am working on will be the first gcc 3.x for Linux/mips. So there > shouldn't be any problems. Am I right? I _think_ you are ok doing this. I just noticed from your patch that you set the size to 32-bits. Please set it to BITS_PER_WORD. -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Mon Aug 6 07:21:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76ELRn02842 for linux-mips-outgoing; Mon, 6 Aug 2001 07:21:27 -0700 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 f76ELQV02833 for ; Mon, 6 Aug 2001 07:21:26 -0700 Received: from [192.168.1.168] (192.168.1.168 [192.168.1.168]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNBAW; Mon, 6 Aug 2001 10:21:20 -0400 Subject: Re: Where is the first entry point for linux-mips boot? From: Marc Karasek To: machael thailer Cc: linux-mips@oss.sgi.com In-Reply-To: <000701c11c8b$77e039e0$8021690a@huawei.com> References: <000701c11c8b$77e039e0$8021690a@huawei.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12.99 (Preview Release) Date: 06 Aug 2001 10:21:23 -0400 Message-Id: <997107690.1342.5.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The firmware or bootloader. For some examples of this look at redboot from RedHat or yamon (yet another monitor) from MIPS (I think). Keep in mind these will prob require a seperate cross-compiler. I have yet to test compiling a boot monitor with linux gcc cross compiler. You can get one from either MIPS or Algorythmics (www.algor.co.uk). I have used both of these to build both of the above monitors. Any other questions, email me.. /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ On 04 Aug 2001 10:16:27 +0800, machael thailer wrote: > Hello,all: > > Now I plan to port linux on our mips-based board. Since it is the first > time for me to work on linux-mips, I have several questions to ask: > > There are many many subdirectories in arch/mips, I don't know where is > the FIRST entry point for embedded linux-mips boot process? I find that > there is "kernel_entry" in arch/mips/kernel/head.S. I know this is the entry > point for linux kernel ,but it is not the FIRST entry point for embedded > linux-mips boot process. So my questions is : > After the board initializations finish, it should load linux kernel into > RAM and jump there . Just before it runs the linux kernel, who calls > "kernel_entry"? > I don't know whether I have expressed my meaning apparently. Hope you > can understand me. > > Thank you very much. > > machael thailer > > -- /************************* 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 Mon Aug 6 07:29:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76ETGj04053 for linux-mips-outgoing; Mon, 6 Aug 2001 07:29:16 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76ETDV04043; Mon, 6 Aug 2001 07:29:13 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA16787; Mon, 6 Aug 2001 07:29:09 -0700 (PDT) Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? From: Eric Christopher To: Andreas Jaeger Cc: Ralf Baechle , "H . J . Lu" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library In-Reply-To: References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 15:27:49 +0100 Message-Id: <997108072.1773.10.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > The MIPS ABI defines wchar_t to long. So please go ahead and make the > > change. > > I'm confused. The ABI defines it to be long - and he should change it > nevertheless? > Also depends on which MIPS ABI :) I think it is ok to change though. -- Look out behind you! From owner-linux-mips@oss.sgi.com Mon Aug 6 07:40:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76EeIr05778 for linux-mips-outgoing; Mon, 6 Aug 2001 07:40:18 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76EeGV05767 for ; Mon, 6 Aug 2001 07:40:16 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id QAA166552; Mon, 6 Aug 2001 16:40:00 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15TlY0-0003ro-00; Mon, 06 Aug 2001 16:40:00 +0200 Date: Mon, 6 Aug 2001 16:40:00 +0200 To: Eric Christopher Cc: "H . J . Lu" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <997107178.1253.7.camel@ghostwheel.cygnus.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Eric Christopher wrote: > > > I am working on will be the first gcc 3.x for Linux/mips. So there > > shouldn't be any problems. Am I right? > > I _think_ you are ok doing this. > > I just noticed from your patch that you set the size to 32-bits. Please > set it to BITS_PER_WORD. I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64, this might be wrong for wchar_t. At least the code for irix6 defines WCHAR_TYPE_SIZE == 32. Thiemo From owner-linux-mips@oss.sgi.com Mon Aug 6 07:42:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76Egxn06183 for linux-mips-outgoing; Mon, 6 Aug 2001 07:42:59 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76EgxV06180 for ; Mon, 6 Aug 2001 07:42:59 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA17617; Mon, 6 Aug 2001 07:42:47 -0700 (PDT) Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? From: Eric Christopher To: Thiemo Seufer Cc: "H . J . Lu" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 15:41:28 +0100 Message-Id: <997108890.1773.22.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64, > this might be wrong for wchar_t. At least the code for irix6 defines > WCHAR_TYPE_SIZE == 32. > Hrm. You might be right. I was thinking that would be correct though. AFAICT from reading the c++ standard, it doesn't care about the size of wchar_t as long as it is large enough to hold the values from the supported locales. Perhaps some c++ expert could help with this a bit? Benjamin is there a problem if wchar_t becomes 64-bits? -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Mon Aug 6 08:22:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76FMN011195 for linux-mips-outgoing; Mon, 6 Aug 2001 08:22:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76FMMV11192 for ; Mon, 6 Aug 2001 08:22:22 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B7A70125C3; Mon, 6 Aug 2001 08:22:19 -0700 (PDT) Date: Mon, 6 Aug 2001 08:22:19 -0700 From: "H . J . Lu" To: Eric Christopher Cc: gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806082219.A15666@lucon.org> References: <20010805094806.A3146@lucon.org> <997107178.1253.7.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997107178.1253.7.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Aug 06, 2001 at 03:12:56PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 03:12:56PM +0100, Eric Christopher wrote: > > > I am working on will be the first gcc 3.x for Linux/mips. So there > > shouldn't be any problems. Am I right? > > I _think_ you are ok doing this. > > I just noticed from your patch that you set the size to 32-bits. Please > set it to BITS_PER_WORD. > BITS_PER_WORD is not right. That is what prompted me to make the change. There are a few things about the MIPS ABI: 1. We do follow the ABI part. 2. We care much less about the API part. That is in the section 6 where wchar_t is defined. 3. On mips, sizeof (int) == sizeof (long int). But BITS_PER_WORD can be 32 or 64, depending on TARGET_LONG64. As for WCHAR_TYPE, it should be `int' regardless of TARGET_LONG64. For most of the 64bit Linux targets, sizeof (int) should be 32bit. That means WCHAR_TYPE_SIZE should be 32 for mips. H.J. From owner-linux-mips@oss.sgi.com Mon Aug 6 08:29:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76FT6g12094 for linux-mips-outgoing; Mon, 6 Aug 2001 08:29:06 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76FT5V12088 for ; Mon, 6 Aug 2001 08:29:05 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id BCF2D125C3; Mon, 6 Aug 2001 08:29:04 -0700 (PDT) Date: Mon, 6 Aug 2001 08:29:04 -0700 From: "H . J . Lu" To: Eric Christopher Cc: Thiemo Seufer , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806082904.C15666@lucon.org> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997108890.1773.22.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Aug 06, 2001 at 03:41:28PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 03:41:28PM +0100, Eric Christopher wrote: > > > I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64, > > this might be wrong for wchar_t. At least the code for irix6 defines > > WCHAR_TYPE_SIZE == 32. > > > > Hrm. You might be right. I was thinking that would be correct though. > AFAICT from reading the c++ standard, it doesn't care about the size of > wchar_t as long as it is large enough to hold the values from the > supported locales. > > Perhaps some c++ expert could help with this a bit? Benjamin is there a > problem if wchar_t becomes 64-bits? Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips' BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t on most of the 64bit Linux targets. Why do we want to use 64 for mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all 64bit Linux targets. H.J. From owner-linux-mips@oss.sgi.com Mon Aug 6 08:35:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76FZNQ12970 for linux-mips-outgoing; Mon, 6 Aug 2001 08:35:23 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76FZMV12967 for ; Mon, 6 Aug 2001 08:35:22 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA21293; Mon, 6 Aug 2001 08:35:12 -0700 (PDT) Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? From: Eric Christopher To: "H . J . Lu" Cc: Thiemo Seufer , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20010806082904.C15666@lucon.org> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> <20010806082904.C15666@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 16:33:54 +0100 Message-Id: <997112036.2480.14.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which > is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips' > BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t > on most of the 64bit Linux targets. Why do we want to use 64 for > mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all > 64bit Linux targets. > Right. alpha doesn't define WCHAR_TYPE_SIZE, ia64 seems to do what you want... -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Mon Aug 6 08:39:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76Fdjw13527 for linux-mips-outgoing; Mon, 6 Aug 2001 08:39:45 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76FdiV13522 for ; Mon, 6 Aug 2001 08:39:44 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4A20A125C3; Mon, 6 Aug 2001 08:39:43 -0700 (PDT) Date: Mon, 6 Aug 2001 08:39:42 -0700 From: "H . J . Lu" To: Eric Christopher Cc: Thiemo Seufer , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806083942.A16047@lucon.org> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> <20010806082904.C15666@lucon.org> <997112036.2480.14.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997112036.2480.14.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Aug 06, 2001 at 04:33:54PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 04:33:54PM +0100, Eric Christopher wrote: > > > Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which > > is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips' > > BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t > > on most of the 64bit Linux targets. Why do we want to use 64 for > > mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all > > 64bit Linux targets. > > > > Right. alpha doesn't define WCHAR_TYPE_SIZE, ia64 seems to do what you > want... alpha does: # grep WCHAR_TYPE defaults.h config/alpha/linux.h defaults.h:#ifndef WCHAR_TYPE_SIZE defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE config/alpha/linux.h:#undef WCHAR_TYPE config/alpha/linux.h:#define WCHAR_TYPE "int" # grep INT_TYPE_SIZE config/alpha/*.h config/alpha/alpha.h:#define INT_TYPE_SIZE 32 So WCHAR_TYPE_SIZE is 32 for Linux/alpha. H.J. From owner-linux-mips@oss.sgi.com Mon Aug 6 09:22:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GM2h16781 for linux-mips-outgoing; Mon, 6 Aug 2001 09:22:02 -0700 Received: from dea.waldorf-gmbh.de (u-243-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GLxV16778 for ; Mon, 6 Aug 2001 09:22:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76GKoH21156; Mon, 6 Aug 2001 18:20:50 +0200 Date: Mon, 6 Aug 2001 18:20:50 +0200 From: Ralf Baechle To: Andreas Jaeger Cc: "H . J . Lu" , Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806182050.A21142@bacchus.dhis.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aj@suse.de on Mon, Aug 06, 2001 at 12:10:59PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 12:10:59PM +0200, Andreas Jaeger wrote: > >> I am working with Eric to clean up the Linux/mips configuration in > >> gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They > >> are the same on Linux/mips. There won't be any run-time problems. I am > >> wondering if there are any compatibility problems at the compile time > >> at the source and binary level. For one thing, __WCHAR_TYPE__ will be > >> changed from "long int" to "int". The only thing I can think of is > >> the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one > >> I am working on will be the first gcc 3.x for Linux/mips. So there > >> shouldn't be any problems. Am I right? > > > > The MIPS ABI defines wchar_t to long. So please go ahead and make the > > change. > > I'm confused. The ABI defines it to be long - and he should change it > nevertheless? It's defined as a "long", not "long int" so we're obviously off by a tiny bit. H.J. - why did you want to change this type anyway? "long int" and "int" both have the same size and signedness so there isn't any incompatibility anyway? Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 09:24:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GO3N16912 for linux-mips-outgoing; Mon, 6 Aug 2001 09:24:03 -0700 Received: from dea.waldorf-gmbh.de (u-243-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GO0V16909 for ; Mon, 6 Aug 2001 09:24:00 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f769xDl19762; Mon, 6 Aug 2001 11:59:13 +0200 Date: Mon, 6 Aug 2001 11:59:13 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806115913.B17179@bacchus.dhis.org> References: <20010805094806.A3146@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: <20010805094806.A3146@lucon.org>; from hjl@lucon.org on Sun, Aug 05, 2001 at 09:48:06AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Aug 05, 2001 at 09:48:06AM -0700, H . J . Lu wrote: > I am working with Eric to clean up the Linux/mips configuration in > gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They > are the same on Linux/mips. There won't be any run-time problems. I am > wondering if there are any compatibility problems at the compile time > at the source and binary level. For one thing, __WCHAR_TYPE__ will be > changed from "long int" to "int". The only thing I can think of is > the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one > I am working on will be the first gcc 3.x for Linux/mips. So there > shouldn't be any problems. Am I right? The MIPS ABI defines wchar_t to long. So please go ahead and make the change. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 09:24:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GObU16986 for linux-mips-outgoing; Mon, 6 Aug 2001 09:24:37 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GOaV16983 for ; Mon, 6 Aug 2001 09:24:36 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA25190; Mon, 6 Aug 2001 09:24:30 -0700 (PDT) Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? From: Eric Christopher To: "H . J . Lu" Cc: Thiemo Seufer , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library In-Reply-To: <20010806083942.A16047@lucon.org> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> <20010806082904.C15666@lucon.org> <997112036.2480.14.camel@ghostwheel.cygnus.com> <20010806083942.A16047@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 06 Aug 2001 17:23:11 +0100 Message-Id: <997114994.12490.0.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > alpha does: > > # grep WCHAR_TYPE defaults.h config/alpha/linux.h > defaults.h:#ifndef WCHAR_TYPE_SIZE > defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE > config/alpha/linux.h:#undef WCHAR_TYPE > config/alpha/linux.h:#define WCHAR_TYPE "int" > # grep INT_TYPE_SIZE config/alpha/*.h > config/alpha/alpha.h:#define INT_TYPE_SIZE 32 > > So WCHAR_TYPE_SIZE is 32 for Linux/alpha. > Ah ha. I'd not looked into defaults.h. Ok. Nevermind then. -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Mon Aug 6 09:24:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GOoH17039 for linux-mips-outgoing; Mon, 6 Aug 2001 09:24:50 -0700 Received: from dea.waldorf-gmbh.de (u-243-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GOlV17035 for ; Mon, 6 Aug 2001 09:24:47 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f769ju119673; Mon, 6 Aug 2001 11:45:56 +0200 Date: Mon, 6 Aug 2001 11:45:56 +0200 From: Ralf Baechle To: John Heil Cc: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, linux-mips@oss.sgi.com Subject: Re: Qube2 gcc 2.7.2 compiler error (fwd) Message-ID: <20010806114556.A17179@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mipsdev@scsoftware.sc-software.com on Sun, Aug 05, 2001 at 12:59:23PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Aug 05, 2001 at 12:59:23PM +0000, John Heil wrote: > Date: Sun, 5 Aug 2001 12:59:23 +0000 ( ) > From: John Heil > To: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, > linux-mips@oss.sgi.com > Subject: Qube2 gcc 2.7.2 compiler error (fwd) > > > On the Qube2, gcc 2.7.2, option -s, to generate MIPS assembler > corresponding to the input C code, generates invalid assembler > by virtue of generating duplicate labels. The resultant > assembler will not assemble, of course, due to the duplicate > labels. The code (linux kernel's printk.c) compiles cleanly > from C to object code. > > Q: How do I get valid assembler from gcc on Qube2 ? > (My ultimate goal here is to be able to get listings out > of gas.) gcc 2.7.2 creates a duplicate label for each function label. That is no problem as both always have the same value. But I assume you're talking about a different type of label? Can you send a piece of small piece of source code and the assembler code generated from it to demonstrate the problem? Anyway, these days gcc 2.7.2 is so old these days it's not even funny. You really should upgrade. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 09:29:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GTi817281 for linux-mips-outgoing; Mon, 6 Aug 2001 09:29:44 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GTgV17277; Mon, 6 Aug 2001 09:29:42 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 54FA7125C3; Mon, 6 Aug 2001 09:29:41 -0700 (PDT) Date: Mon, 6 Aug 2001 09:29:41 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Andreas Jaeger , Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806092941.A16954@lucon.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <20010806182050.A21142@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010806182050.A21142@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, Aug 06, 2001 at 06:20:50PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 06:20:50PM +0200, Ralf Baechle wrote: > > H.J. - why did you want to change this type anyway? "long int" and "int" > both have the same size and signedness so there isn't any incompatibility > anyway? > All Linux targets should use a 32bit type, `int', for wchar_t. `long' is 64bit for mips64. Like I said, we don't use the mips API, only the ABI. H.J. From owner-linux-mips@oss.sgi.com Mon Aug 6 09:29:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76GTll17321 for linux-mips-outgoing; Mon, 6 Aug 2001 09:29:47 -0700 Received: from dea.waldorf-gmbh.de (u-243-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76GTiV17286 for ; Mon, 6 Aug 2001 09:29:45 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76GShK21186; Mon, 6 Aug 2001 18:28:43 +0200 Date: Mon, 6 Aug 2001 18:28:43 +0200 From: Ralf Baechle To: Eric Christopher Cc: Andreas Jaeger , "H . J . Lu" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806182843.B21142@bacchus.dhis.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <997108072.1773.10.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997108072.1773.10.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Aug 06, 2001 at 03:27:49PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 03:27:49PM +0100, Eric Christopher wrote: > > > The MIPS ABI defines wchar_t to long. So please go ahead and make the > > > change. > > > > I'm confused. The ABI defines it to be long - and he should change it > > nevertheless? > > > > Also depends on which MIPS ABI :) I think it is ok to change though. MIPS psABI 3.0. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 10:06:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76H65X17930 for linux-mips-outgoing; Mon, 6 Aug 2001 10:06:05 -0700 Received: from perceval.inria.fr (IDENT:root@perceval.inria.fr [138.96.116.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76H61V17926; Mon, 6 Aug 2001 10:06:01 -0700 Received: by perceval.inria.fr (8.11.1/8.10.0) id f76H4aC17454; Mon, 6 Aug 2001 19:04:36 +0200 From: Gabriel Dos_Reis MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Aug 2001 19:04:36 +0200 (MEST) To: Ralf Baechle Cc: Andreas Jaeger , "H . J . Lu" , Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? In-Reply-To: <20010806182050.A21142@bacchus.dhis.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <20010806182050.A21142@bacchus.dhis.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15214.52694.346958.536105@perceval.inria.fr> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk | > I'm confused. The ABI defines it to be long - and he should change it | > nevertheless? | | It's defined as a "long", not "long int" so we're obviously off by a tiny | bit. As far as far C++ is concerned, there is no pedantic difference between "long" and "long int" and "signed long int". -- Gaby From owner-linux-mips@oss.sgi.com Mon Aug 6 10:27:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76HR9I18284 for linux-mips-outgoing; Mon, 6 Aug 2001 10:27:09 -0700 Received: from dea.waldorf-gmbh.de (u-145-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76HR7V18278 for ; Mon, 6 Aug 2001 10:27:07 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76HPvu21492; Mon, 6 Aug 2001 19:25:57 +0200 Date: Mon, 6 Aug 2001 19:25:57 +0200 From: Ralf Baechle To: Gabriel Dos_Reis Cc: Andreas Jaeger , "H . J . Lu" , Eric Christopher , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010806192557.A21485@bacchus.dhis.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <20010806182050.A21142@bacchus.dhis.org> <15214.52694.346958.536105@perceval.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15214.52694.346958.536105@perceval.inria.fr>; from gdosreis@sophia.inria.fr on Mon, Aug 06, 2001 at 07:04:36PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 07:04:36PM +0200, Gabriel Dos_Reis wrote: > | > I'm confused. The ABI defines it to be long - and he should change it > | > nevertheless? > | > | It's defined as a "long", not "long int" so we're obviously off by a tiny > | bit. > > As far as far C++ is concerned, there is no pedantic difference > between "long" and "long int" and "signed long int". Guess why I said a tiny bit :-) Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 11:06:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76I6bN19586 for linux-mips-outgoing; Mon, 6 Aug 2001 11:06:37 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76I6ZV19582 for ; Mon, 6 Aug 2001 11:06:36 -0700 content-class: urn:content-classes:message Subject: set_bit() function. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 6 Aug 2001 11:04:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A21EB@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: set_bit() function. Thread-Index: AcEeokFaRAkLCp4hQ8eLxQFGPnYOJw== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f76I6aV19583 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, ALL: I have a question regarding the function set_bit() in linux/include/asm-mips/bitops.h for MIPS 1(R3000). extern __inline__ void set_bit(int nr, void * addr) { int mask; int *a = addr; __bi_flags; a += nr >> 5; // <---- why shits right 5 bits? mask = 1 << (nr & 0x1f); __bi_save_flags(flags); __bi_cli(); *a |= mask; __bi_restore_flags(flags); } In extern __inline__ int test_bit(int nr, const void *addr) { return ((1UL << (nr & 31)) & (((const unsigned int *) addr)[nr >> 5])) != 0; } addr is always passed in as a pointer to an integer. Why does it use array [nr >>5]? Any help is greatly appreciated. Thanks. Steven Liu From owner-linux-mips@oss.sgi.com Mon Aug 6 12:19:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76JJxm24442 for linux-mips-outgoing; Mon, 6 Aug 2001 12:19:59 -0700 Received: from scsoftware.sc-software.com (mipsdev@[206.40.202.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76JJsV24436; Mon, 6 Aug 2001 12:19:54 -0700 Received: from localhost (mipsdev@localhost) by scsoftware.sc-software.com (8.8.3/8.8.3) with SMTP id MAA17908; Mon, 6 Aug 2001 12:13:29 GMT Date: Mon, 6 Aug 2001 12:13:29 +0000 ( ) From: John Heil To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: Qube2 gcc 2.7.2 compiler error (fwd) In-Reply-To: <20010806114556.A17179@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 6 Aug 2001, Ralf Baechle wrote: > Date: Mon, 6 Aug 2001 11:45:56 +0200 > From: Ralf Baechle > To: John Heil > Cc: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, > linux-mips@oss.sgi.com > Subject: Re: Qube2 gcc 2.7.2 compiler error (fwd) > > On Sun, Aug 05, 2001 at 12:59:23PM +0000, John Heil wrote: > > Date: Sun, 5 Aug 2001 12:59:23 +0000 ( ) > > From: John Heil > > To: cobalt-22@devel.alal.com, cobalt-developers@list.cobalt.com, > > linux-mips@oss.sgi.com > > Subject: Qube2 gcc 2.7.2 compiler error (fwd) > > > > > > On the Qube2, gcc 2.7.2, option -s, to generate MIPS assembler > > corresponding to the input C code, generates invalid assembler > > by virtue of generating duplicate labels. The resultant > > assembler will not assemble, of course, due to the duplicate > > labels. The code (linux kernel's printk.c) compiles cleanly > > from C to object code. > > > > Q: How do I get valid assembler from gcc on Qube2 ? > > (My ultimate goal here is to be able to get listings out > > of gas.) > > gcc 2.7.2 creates a duplicate label for each function label. That is no > problem as both always have the same value. But I assume you're talking This is exactly the problem. The fact that the values are the same is causing the assembler interface to GCC to fail. When gcc -S outputs a .s assembler file, the GNU as assembler errors out on 'duplicate label'. Further, using the gcc -Wa,... without using -S, causes the compile to fail when the assembler is invoked and gives the same errors. > about a different type of label? Can you send a piece of small piece of > source code and the assembler code generated from it to demonstrate the > problem? > > Anyway, these days gcc 2.7.2 is so old these days it's not even funny. You > really should upgrade. > > Ralf > I'm happy to upgrade... What is the recommended level for kernel compiles and where can I find it. I am required to work on 2.0.34C53_SK using Qube2 for my build platform so I need compatibility. If I could cross compile on x86 that would be cool too. Thanx much John From owner-linux-mips@oss.sgi.com Mon Aug 6 12:33:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76JXmU25666 for linux-mips-outgoing; Mon, 6 Aug 2001 12:33:48 -0700 Received: from dea.waldorf-gmbh.de (u-145-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76JXhV25659 for ; Mon, 6 Aug 2001 12:33:44 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76JWnt22002; Mon, 6 Aug 2001 21:32:49 +0200 Date: Mon, 6 Aug 2001 21:32:49 +0200 From: Ralf Baechle To: John Heil Cc: linux-mips@oss.sgi.com Subject: Re: Qube2 gcc 2.7.2 compiler error (fwd) Message-ID: <20010806213249.A21984@bacchus.dhis.org> References: <20010806114556.A17179@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mipsdev@scsoftware.sc-software.com on Mon, Aug 06, 2001 at 12:13:29PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 12:13:29PM +0000, John Heil wrote: > > gcc 2.7.2 creates a duplicate label for each function label. That is no > > problem as both always have the same value. But I assume you're talking > > This is exactly the problem. The fact that the values are the same is > causing the assembler interface to GCC to fail. When gcc -S outputs a > .s assembler file, the GNU as assembler errors out on 'duplicate label'. Since when that? Gas used to accept that for just more than half a decade. You seem to be using some non-standard gas version? > I'm happy to upgrade... > > What is the recommended level for kernel compiles and where can I find it. > I am required to work on 2.0.34C53_SK using Qube2 for my build platform > so I need compatibility. If I could cross compile on x86 that would be > cool too. You may want to try H.J. Lu's latest tools from oss. I should mention that nobody is testing on such old systems any more and I suspect some minor changes may be required to get these tools to work in such an environment. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 16:37:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76NbHf27965 for linux-mips-outgoing; Mon, 6 Aug 2001 16:37:17 -0700 Received: from dea.waldorf-gmbh.de (u-157-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76NbEV27954 for ; Mon, 6 Aug 2001 16:37:14 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76NaLq22997; Tue, 7 Aug 2001 01:36:21 +0200 Date: Tue, 7 Aug 2001 01:36:21 +0200 From: Ralf Baechle To: Steven Liu Cc: linux-mips@oss.sgi.com Subject: Re: set_bit() function. Message-ID: <20010807013621.A22966@bacchus.dhis.org> References: <84CE342693F11946B9F54B18C1AB837B0A21EB@ex2k.pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84CE342693F11946B9F54B18C1AB837B0A21EB@ex2k.pcs.psdc.com>; from stevenliu@psdc.com on Mon, Aug 06, 2001 at 11:04:38AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 11:04:38AM -0700, Steven Liu wrote: > extern __inline__ void set_bit(int nr, void * addr) > { > int mask; > int *a = addr; > __bi_flags; > > a += nr >> 5; // <---- why shits right 5 > bits? > mask = 1 << (nr & 0x1f); > __bi_save_flags(flags); > __bi_cli(); > *a |= mask; > __bi_restore_flags(flags); > } > > In > > extern __inline__ int test_bit(int nr, const void *addr) > { > return ((1UL << (nr & 31)) & (((const unsigned int *) addr)[nr > >> 5])) != 0; > } > > addr is always passed in as a pointer to an integer. Why does it use > array [nr >>5]? Linux bitfields can have an arbitrary size, more than a single machine word. Bitfields consist of a arrays of unsigned longs - note that this makes a difference for 32-bit and 64-bit kernels!. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 16:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76NoNf29884 for linux-mips-outgoing; Mon, 6 Aug 2001 16:50:23 -0700 Received: from dea.waldorf-gmbh.de (u-157-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76NoJV29878 for ; Mon, 6 Aug 2001 16:50:20 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f76NnA123038; Tue, 7 Aug 2001 01:49:10 +0200 Date: Tue, 7 Aug 2001 01:49:10 +0200 From: Ralf Baechle To: Eric Christopher Cc: Thiemo Seufer , "H . J . Lu" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, GNU C Library Subject: Re: Changing WCHAR_TYPE from "long int" to "int"? Message-ID: <20010807014910.B22966@bacchus.dhis.org> References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997108890.1773.22.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Mon, Aug 06, 2001 at 03:41:28PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 03:41:28PM +0100, Eric Christopher wrote: > Hrm. You might be right. I was thinking that would be correct though. > AFAICT from reading the c++ standard, it doesn't care about the size of > wchar_t as long as it is large enough to hold the values from the > supported locales. > > Perhaps some c++ expert could help with this a bit? Benjamin is there a > problem if wchar_t becomes 64-bits? On 64-bit MIPS ABI compliant machines I see wchar_t defined to __int32_t which again is int. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 6 19:32:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f772Wlf14896 for linux-mips-outgoing; Mon, 6 Aug 2001 19:32:47 -0700 Received: from viditec-netmedia.com.tw (61-220-240-70.HINET-IP.hinet.net [61.220.240.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f772WiV14893 for ; Mon, 6 Aug 2001 19:32:45 -0700 Received: from VSB200 ([61.170.150.156]) by viditec-netmedia.com.tw (8.10.0/8.10.0) with SMTP id f774inG24453 for ; Tue, 7 Aug 2001 12:44:49 +0800 Message-ID: <018601bf54c9$e28219c0$416baac0@viditec> From: "kjlin" To: Subject: null TTY error Date: Sun, 2 Jan 2000 10:34:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0183_01BF550C.EF3D3E40" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0183_01BF550C.EF3D3E40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpQb3J0aW5nIHRoZSBrZXJuZWwgMi40LjEgdG8gbXkgTUlQUyBlbWJlZGRlZCBi b2FyZCwNCmkgZW5jb3VudGVyZWQgYSBUVFkgcHJvYmxlbS4NCldoZW4gdGhlIHByaW50ZiBpcyBw dXR0ZWQgaW4gYSBsYXJnZSBsb29wLCBzdWNoIGFzIGEgMTAwIHRpbWVzIGxvb3AsIA0KdGhlIGtl cm5lbCBlcnJvciBtZXNzYWdlICJXYXJuaW5nOiBudWxsIFRUWSBmb3IgKGZmOmZmKSBpbiB0dHlf d3JpdGUiIGFwcGVhcnMuDQpIb3dldmVyLCBpZiBqdXN0IG9uZSBvciB0d28gcHJpbnRmIGFyZSB1 c2VkLCBldmVyeXRoaW5nIGlzIGZpbmUuDQpEb2VzIHRoaXMgcHJvYmxlbSBjb25jZXJuIHdpdGgg bXkgc2VyaWFsIGRyaXZlcj8NCkkgd3JvdGUgbXkgc2VyaWFsIGRyaXZlciBiYXNlZCBvbiBkcml2 ZXIvY2hhci9zZXJpYWwuYy4NCkNhbiBzb21lb25lIGdpdmUgbWUgYSBoaW50IHRoYXQgd2hlcmUg c2hvdWxkIGJlIGNoZWNrZWQgb3Zlcj8NCg0KVGhhbmtzLg0KDQoNCg== ------=_NextPart_000_0183_01BF550C.EF3D3E40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSA8Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPmFsbCw8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+UG9ydGluZyB0aGUg a2VybmVsIDIuNC4xIHRvIG15IE1JUFMgDQplbWJlZGRlZCBib2FyZCw8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPmkgZW5jb3VudGVyZWQgYSBU VFkgDQpwcm9ibGVtLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPTI+V2hlbiB0aGUgcHJpbnRmJm5ic3A7aXMgcHV0dGVkIGluIGEgDQpsYXJnZSBs b29wLCBzdWNoIGFzIGEgMTAwIHRpbWVzIGxvb3AsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+dGhlIGtlcm5lbCBlcnJvciBtZXNzYWdlICJX YXJuaW5nOiBudWxsIA0KVFRZIGZvciAoZmY6ZmYpIGluIHR0eV93cml0ZSIgYXBwZWFycy48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPkhvd2V2 ZXIsIGlmIGp1c3Qgb25lIG9yIHR3byBwcmludGYgYXJlIA0KdXNlZCwgZXZlcnl0aGluZyBpcyBm aW5lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PTI+RG9lcyZuYnNwO3RoaXMgcHJvYmxlbSBjb25jZXJuIHdpdGggbXkgDQpzZXJpYWwgZHJpdmVy PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+ SSB3cm90ZSBteSBzZXJpYWwgZHJpdmVyIGJhc2VkIG9uIA0KZHJpdmVyL2NoYXIvc2VyaWFsLmMu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj5D YW4gc29tZW9uZSBnaXZlIG1lIGEgaGludCB0aGF0IHdoZXJlIA0Kc2hvdWxkIGJlIGNoZWNrZWQg b3Zlcj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mj5UaGFua3MuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0183_01BF550C.EF3D3E40-- From owner-linux-mips@oss.sgi.com Mon Aug 6 20:40:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f773elE21979 for linux-mips-outgoing; Mon, 6 Aug 2001 20:40:47 -0700 Received: from sioux.meginc.com (Sioux.meginc.com [207.246.76.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f773ekV21974 for ; Mon, 6 Aug 2001 20:40:46 -0700 Received: from linux (brandon@[207.246.76.93]) by sioux.meginc.com (8.9.3/8.9.1) with SMTP id XAA47882 for ; Mon, 6 Aug 2001 23:40:17 -0400 (EDT) (envelope-from bebarker@meginc.com) Content-Type: text/plain; charset="iso-8859-1" From: Brandon Barker To: "linux-mips@oss.sgi.com" Date: Mon, 6 Aug 2001 23:47:36 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01080623471400.01828@linux> Content-Transfer-Encoding: 8bit Subject: Indy 64 or 32 bit? Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was curious if these are 64 bit systems or 32 bit systems (for that matter, are all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think IRIX has been 64 for quite some time, but was curious. I use Linux on x86 but will probably use IRIX for a few weeks on the Indy's until I become familiar enough with the machines to try installing Linux. BTW, does gcc work on IRIX? Thanks for the info, Brandon Barker From owner-linux-mips@oss.sgi.com Mon Aug 6 20:54:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f773ssP22882 for linux-mips-outgoing; Mon, 6 Aug 2001 20:54:54 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f773soV22877 for ; Mon, 6 Aug 2001 20:54:51 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id D24A6590AC for ; Mon, 6 Aug 2001 23:52:19 -0400 (EDT) Message-ID: <074001c11ef4$fdbd7530$3501010a@ltc.com> From: "Bradley D. LaRonde" To: References: <20010806164000.E400@rembrandt.csv.ica.uni-stuttgart.de> <997108890.1773.22.camel@ghostwheel.cygnus.com> <20010806082904.C15666@lucon.org> <997112036.2480.14.camel@ghostwheel.cygnus.com> <20010806083942.A16047@lucon.org> Subject: cross-mipsel-linux-ld --prefix library path Date: Mon, 6 Aug 2001 23:56:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk When I build and install cross-binutils (on Debian 2.2) like this: tar -xzf binutils-2.11.2.tar.gz mkdir mipsel-binutils cd mipsel-binutils ../binutils-2.11.2/configure --target=mipsel-linux \ --prefix=/usr/mipsel-linux make make install it seems the resulting mipsel-linux-ld wants to look in: /usr/mipsel-linux/mipsel-linux/lib for crt1.o, crti.o, libc.*, etc. However, a cross-built glibc like: tar -xzf glibc-2.2.3 cd glibc-2.2.3 patch -p1 -i../elf32-tradlittlemips.diff tar -xzf ../glibc-linuxthreads-2.2.3.tar.gz cd .. mkdir mipsel-glibc cd mipsel-glibc ../glibc-2.2.3/configure --build=i686-linux \ --host=mipsel-linux --prefix=/usr/mipsel-linux \ --with-headers=/usr/mipsel-linux/include --enable-add-ons make make install puts it's stuff in: /usr/mipsel-linux/lib/ not: /usr/mipsel-linux/mipsel-linux/lib/ My first suspicion is that --prefix=/usr/mipsel-linux for binutils is naive, but --prefix=/usr looks like a disaster (would overwrite native stuff like libbfd.la for example, whatever that is). Another odd thing is that binutils installs: /usr/mipsel-linux/bin/mipsel-linux-ld and an identical copy at: /usr/mipsel-linux/mipsel-linux/bin/ld This seems like a Clue. If fact, the whole /usr/mipsel-linux/mipsel-linux thing seems off to me. Only, being only an RTN (Reluctant Toolchain Neophyte), that's about as far as I've gotten with it. Analysis (of the software, not me)? :-) Regards, Brad From owner-linux-mips@oss.sgi.com Mon Aug 6 20:56:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f773u4f23031 for linux-mips-outgoing; Mon, 6 Aug 2001 20:56:04 -0700 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f773u3V23028 for ; Mon, 6 Aug 2001 20:56:03 -0700 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id A62CCFB5; Mon, 6 Aug 2001 23:56:01 -0400 (EDT) Date: Mon, 6 Aug 2001 23:56:00 -0400 (EDT) From: George Gensure To: Brandon Barker Cc: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? In-Reply-To: <01080623471400.01828@linux> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The R5000 Indies are, in my experience 32 bit systems. Feel free to smack me down if anyone has contrary information, however. George Gensure On Mon, 6 Aug 2001, Brandon Barker wrote: > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was > curious if these are 64 bit systems or 32 bit systems (for that matter, are > all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think > IRIX has been 64 for quite some time, but was curious. I use Linux on x86 > but will probably use IRIX for a few weeks on the Indy's until I become > familiar enough with the machines to try installing Linux. BTW, does gcc > work on IRIX? > > Thanks for the info, > Brandon Barker > From owner-linux-mips@oss.sgi.com Mon Aug 6 21:04:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7744D323422 for linux-mips-outgoing; Mon, 6 Aug 2001 21:04:13 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7744CV23418 for ; Mon, 6 Aug 2001 21:04:12 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id AAA24177; Tue, 7 Aug 2001 00:03:33 -0400 Date: Tue, 7 Aug 2001 00:03:33 -0400 (EDT) From: X-Sender: nick@ns To: George Gensure cc: Brandon Barker , "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? 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 IRIX runs indys 32bit. I would assume it runs the challange s 32bit as well, though I'm not sure. All SGIs newer than the indigo (so the indy, i2, etc) support 64bit mode, though some early indy/i2 proms may not be able to deal with 64bit code. Nick On Mon, 6 Aug 2001, George Gensure wrote: > The R5000 Indies are, in my experience 32 bit systems. Feel free to smack me > down if anyone has contrary information, however. > > George Gensure > > On Mon, 6 Aug 2001, Brandon Barker wrote: > > > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was > > curious if these are 64 bit systems or 32 bit systems (for that matter, are > > all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think > > IRIX has been 64 for quite some time, but was curious. I use Linux on x86 > > but will probably use IRIX for a few weeks on the Indy's until I become > > familiar enough with the machines to try installing Linux. BTW, does gcc > > work on IRIX? > > > > Thanks for the info, > > Brandon Barker > > > From owner-linux-mips@oss.sgi.com Mon Aug 6 21:12:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f774Cw624809 for linux-mips-outgoing; Mon, 6 Aug 2001 21:12:58 -0700 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 f774CuV24806 for ; Mon, 6 Aug 2001 21:12:57 -0700 Received: from pinckneya.peachtree.sgi.com (pinckneya.peachtree.sgi.com [169.238.221.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA17431 for ; Mon, 6 Aug 2001 21:12:42 -0700 (PDT) mail_from (andya@sgi.com) Received: from PCANDYA by pinckneya.peachtree.sgi.com via SMTP (950413.SGI.8.6.12/930416.SGI) id AAA23703; Tue, 7 Aug 2001 00:11:12 -0400 Message-ID: <002201c11ef7$0d18d090$0adeeea9@peachtree.sgi.com> From: "Nils C. Anderson" To: , "George Gensure" Cc: "Brandon Barker" , References: Subject: Re: Indy 64 or 32 bit? Date: Tue, 7 Aug 2001 00:11:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Indy and Challenge S under Irix are 32 bits. to verify just run `uname` if it returns "IRIX" == 32 bit if "IRIX64" == 64 bit. Andy ----- Original Message ----- From: To: "George Gensure" Cc: "Brandon Barker" ; Sent: Tuesday, August 07, 2001 12:03 AM Subject: Re: Indy 64 or 32 bit? > IRIX runs indys 32bit. I would assume it runs the challange s 32bit as > well, though I'm not sure. All SGIs newer than the indigo (so the indy, > i2, etc) support 64bit mode, though some early indy/i2 proms may not be > able to deal with 64bit code. > Nick > > On Mon, 6 Aug 2001, George Gensure wrote: > > > The R5000 Indies are, in my experience 32 bit systems. Feel free to smack me > > down if anyone has contrary information, however. > > > > George Gensure > > > > On Mon, 6 Aug 2001, Brandon Barker wrote: > > > > > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was > > > curious if these are 64 bit systems or 32 bit systems (for that matter, are > > > all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think > > > IRIX has been 64 for quite some time, but was curious. I use Linux on x86 > > > but will probably use IRIX for a few weeks on the Indy's until I become > > > familiar enough with the machines to try installing Linux. BTW, does gcc > > > work on IRIX? > > > > > > Thanks for the info, > > > Brandon Barker > > > > > > > From owner-linux-mips@oss.sgi.com Tue Aug 7 00:40:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f777emj13376 for linux-mips-outgoing; Tue, 7 Aug 2001 00:40:48 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f777ekV13365 for ; Tue, 7 Aug 2001 00:40:46 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA05638; Tue, 7 Aug 2001 09:40:19 +0200 (MET DST) Date: Tue, 7 Aug 2001 09:40:18 +0200 (MEST) From: Geert Uytterhoeven To: "Bradley D. LaRonde" cc: linux-mips@oss.sgi.com Subject: Re: cross-mipsel-linux-ld --prefix library path In-Reply-To: <074001c11ef4$fdbd7530$3501010a@ltc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 6 Aug 2001, Bradley D. LaRonde wrote: > Another odd thing is that binutils installs: > > /usr/mipsel-linux/bin/mipsel-linux-ld > > and an identical copy at: > > /usr/mipsel-linux/mipsel-linux/bin/ld > > This seems like a Clue. If fact, the whole That's normal, I have | tux$ ls -li /usr/local/bin/*ld /usr/local/*/bin/ld | 62976 -rwxr-xr-x 2 root staff 946678 Jun 11 15:47 /usr/local/bin/m68k-amigaos-ld* | 63675 -rwxr-xr-x 2 root staff 1356730 Mar 12 11:17 /usr/local/bin/m68k-linux-ld* | 63660 -rwxr-xr-x 2 root staff 1545874 Mar 12 11:16 /usr/local/bin/powerpc-linux-ld* | 62976 -rwxr-xr-x 2 root staff 946678 Jun 11 15:47 /usr/local/m68k-amigaos/bin/ld* | 63675 -rwxr-xr-x 2 root staff 1356730 Mar 12 11:17 /usr/local/m68k-linux/bin/ld* | 63660 -rwxr-xr-x 2 root staff 1545874 Mar 12 11:16 /usr/local/powerpc-linux/bin/ld* | tux$ The `duplicates' are just hard links (compare the inode numbers), so they don't waste real space (except for the directory entries :-). BTW, I used --prefix=/usr/local. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Aug 7 00:42:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f777gqR13680 for linux-mips-outgoing; Tue, 7 Aug 2001 00:42:52 -0700 Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f777glV13668 for ; Tue, 7 Aug 2001 00:42:47 -0700 Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA05353; Tue, 7 Aug 2001 17:42:40 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdftwVJ_; Tue Aug 7 17:42:38 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA13798; Tue, 7 Aug 2001 17:42:37 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0S9.t1; Tue Aug 7 17:42:16 2001 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA02658; Tue, 7 Aug 2001 17:42:16 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 17:38:17 +1000 Message-ID: From: "Salisbury, Roger" To: "'linux-mips@oss.sgi.com'" Cc: "'Keith Wesolows'" Subject: MIPS-INDIGO2-KERNEL BUG Date: Tue, 7 Aug 2001 17:38:15 +1000 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 Sirs BELOW is the ERROR 1. make vmlinux ................................. ................................. ................................. ld: drivers/media/media.o: uses different e_flags (0x0) fields than previous modules (0x100) Bad value: failed to merge target specific data of file drivers/media/media.o make: *** [vmlinux] Error 1 2. Error compiling a new kernel. 3. ld (linker) 4. bash-2.04# cat /proc/version Linux version 2.2.14 (wesolows@fallout) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #2 Thu May 18 16:27:14 PDT 2000 bash-2.04# 5.N/A 6 N/A 7. bash-2.04# set BASH=/usr/bin/bash BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release" [5]="mips-unknown-linux- gnu") BASH_VERSION='2.04.0(1)-release' COLUMNS=80 DIRSTACK=() EUID=0 GROUPS=() HISTFILE=//.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/ HOSTNAME=Roland HOSTTYPE=mips IFS=' ' LINES=24 LOGNAME=root MACHTYPE=mips-unknown-linux-gnu MAIL=/var/spool/mail/root MAILCHECK=60 OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/sbin:/bin:/usr/sbin:/usr/bin PIPESTATUS=([0]="0") PPID=1 PS1='\s-\v\$ ' PS2='> ' PS4='+ ' PWD=/ SHELL=/usr/bin/bash SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comment s:emacs SHLVL=1 TERM=vt100 UID=0 _=/proc/version bash-2.04# 7.1 > VERSIONS::::::::::::::::::::::::::::::: > ################################################################# > bash-2.04# /linux/scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux Roland 2.2.14 #2 Thu May 18 16:27:14 PDT 2000 mips unknown > > Gnu C egcs-2.91.66 > Gnu make 3.79 > binutils 000425 > util-linux 2.10m > mount 2.10m > modutils 2.3.11 > e2fsprogs 1.18 > Linux C Library 2.0.6 > Dynamic linker (ldd) 2.0.6 > Linux C++ Library 2.9.0 > Procps 2.0.6 > Net-tools 1.55 > Kbd command > Sh-utils 2.0i > cat: /proc/modules: No such file or directory > Modules Loaded > bash-2.04# > 7.2 bash-2.04# cat /proc/cpuinfo cpu : MIPS cpu model : R4000SC V3.0 system type : SGI Indy BogoMIPS : 49.97 byteorder : big endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : no hardware watchpoint : yes VCED exceptions : 670 VCEI exceptions : 169 bash-2.04# 7.3 No modules 7.4 bash-2.04# ls -l /proc/ioports -r--r--r-- 1 root sys 0 Aug 8 07:33 /proc/ioports bash-2.04# ls -l /proc/iomem ls: /proc/iomem: No such file or directory bash-2.04# 7.5 No PCI 7.6 bash-2.04# ls -lt /proc/scsi total 0 dr-xr-xr-x 2 root sys 0 Aug 8 07:35 SGIWD -rw-r--r-- 1 root sys 0 Aug 8 07:35 scsi bash-2.04# bash-2.04# ls -lt /proc/scsi total 0 dr-xr-xr-x 2 root sys 0 Aug 8 07:35 SGIWD -rw-r--r-- 1 root sys 0 Aug 8 07:35 scsi bash-2.04# 7.7 AND here are some details ARCH: indigo 2 IP22 SYSTEM : Simple Linux built as per http://foobazco.org/~wesolows/Install-HOWTO.html KERNEL: [Simple Linux/MIPS 0.1 (kernel 2.2.14)] or [Simple Linux/MIPS 0.1 (kernel 2.4.3)] >> hinv System: IP22 Processor: 100 Mhz R4000, with FPU Primary I-cache size: 8 Kbytes Primary D-cache size: 8 Kbytes Secondary cache size: 1024 Kbytes Memory size: 64 Mbytes Graphics: XL SCSI Disk: scsi(0)disk(1) SCSI CDROM: scsi(0)cdrom(3) >> BOTH "CONFIG_CROSS_COMPILE" has been turned on or off without any change. Error again: > mips-linux-ld: drivers/media/media.o: uses different e_flags (0x0) fields than previous modules (0x100) > Bad value: failed to merge target specific data of file drivers/media/media.o > make: [vmlinux] Error 1 (ignored) > mips-linux-nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map > ################################################################# > From owner-linux-mips@oss.sgi.com Tue Aug 7 04:52:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77BqTh10500 for linux-mips-outgoing; Tue, 7 Aug 2001 04:52:29 -0700 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 f77BqOV10479; Tue, 7 Aug 2001 04:52:24 -0700 Received: from patton.com (decpc.patton.com [209.49.110.83]) by emma.patton.com (8.9.0/8.9.0) with ESMTP id HAA07874; Tue, 7 Aug 2001 07:52:34 -0400 (EDT) Message-ID: <3B6FD676.CA20DF04@patton.com> Date: Tue, 07 Aug 2001 07:52:22 -0400 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: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?) References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <997108072.1773.10.camel@ghostwheel.cygnus.com> <20010806182843.B21142@bacchus.dhis.org> Content-Type: multipart/mixed; boundary="------------BD792DC6653E688B3DC63EDE" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------BD792DC6653E688B3DC63EDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > > On Mon, Aug 06, 2001 at 03:27:49PM +0100, Eric Christopher wrote: > > > > > The MIPS ABI defines wchar_t to long. So please go ahead and make the > > > > change. > > > > > > I'm confused. The ABI defines it to be long - and he should change it > > > nevertheless? > > > > > > > Also depends on which MIPS ABI :) I think it is ok to change though. > > MIPS psABI 3.0. > > Ralf Where can I find the MIPS ABI? -- 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 --------------BD792DC6653E688B3DC63EDE Content-Type: text/x-vcard; charset=us-ascii; name="paul.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Paul Kasper Content-Disposition: attachment; filename="paul.vcf" begin:vcard n:Kasper;Paul tel;fax:301-869-9293 tel;work:301-975-1000 x173 x-mozilla-html:FALSE url:www.patton.com org:Patton Electronics Co.;Central Office Products adr:;;7622 Rickenbacker Drive;Gaithersburg;MD;20879;USA version:2.1 email;internet:paul@patton.com x-mozilla-cpt:;10912 fn:Paul Kasper end:vcard --------------BD792DC6653E688B3DC63EDE-- From owner-linux-mips@oss.sgi.com Tue Aug 7 05:32:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77CWGi13312 for linux-mips-outgoing; Tue, 7 Aug 2001 05:32:16 -0700 Received: from dea.waldorf-gmbh.de (u-111-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77CWCV13308 for ; Tue, 7 Aug 2001 05:32:13 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f77CVJd26050; Tue, 7 Aug 2001 14:31:19 +0200 Date: Tue, 7 Aug 2001 14:31:19 +0200 From: Ralf Baechle To: Paul Kasper Cc: linux-mips@oss.sgi.com Subject: Re: MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?) Message-ID: <20010807143119.A26044@bacchus.dhis.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <997108072.1773.10.camel@ghostwheel.cygnus.com> <20010806182843.B21142@bacchus.dhis.org> <3B6FD676.CA20DF04@patton.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6FD676.CA20DF04@patton.com>; from paul@patton.com on Tue, Aug 07, 2001 at 07:52:22AM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Aug 07, 2001 at 07:52:22AM -0400, Paul Kasper wrote: > Where can I find the MIPS ABI? www.eagercon.com is one of the places where it's online. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 7 07:08:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77E8jb19458 for linux-mips-outgoing; Tue, 7 Aug 2001 07:08:45 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77E8gV19449 for ; Tue, 7 Aug 2001 07:08:42 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 886AE590AC; Tue, 7 Aug 2001 10:06:13 -0400 (EDT) Message-ID: <088d01c11f4a$c2a5eee0$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Geert Uytterhoeven" Cc: References: Subject: Re: cross-mipsel-linux-ld --prefix library path Date: Tue, 7 Aug 2001 10:10:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Cool. So, what is the purpose of having both $prefix/bin/mipsel-linux-ld and $prefix/mipsel-linux/bin/ld? Also, why is glibc installing libraries into $prefix/lib when mipsel-linux-ld is looking in $prefix/mipsel-linux/lib? Regards, Brad ----- Original Message ----- From: "Geert Uytterhoeven" To: "Bradley D. LaRonde" Cc: Sent: Tuesday, August 07, 2001 3:40 AM Subject: Re: cross-mipsel-linux-ld --prefix library path > On Mon, 6 Aug 2001, Bradley D. LaRonde wrote: > > Another odd thing is that binutils installs: > > > > /usr/mipsel-linux/bin/mipsel-linux-ld > > > > and an identical copy at: > > > > /usr/mipsel-linux/mipsel-linux/bin/ld > > > > This seems like a Clue. If fact, the whole > > That's normal, I have > > | tux$ ls -li /usr/local/bin/*ld /usr/local/*/bin/ld > | 62976 -rwxr-xr-x 2 root staff 946678 Jun 11 15:47 /usr/local/bin/m68k-amigaos-ld* > | 63675 -rwxr-xr-x 2 root staff 1356730 Mar 12 11:17 /usr/local/bin/m68k-linux-ld* > | 63660 -rwxr-xr-x 2 root staff 1545874 Mar 12 11:16 /usr/local/bin/powerpc-linux-ld* > | 62976 -rwxr-xr-x 2 root staff 946678 Jun 11 15:47 /usr/local/m68k-amigaos/bin/ld* > | 63675 -rwxr-xr-x 2 root staff 1356730 Mar 12 11:17 /usr/local/m68k-linux/bin/ld* > | 63660 -rwxr-xr-x 2 root staff 1545874 Mar 12 11:16 /usr/local/powerpc-linux/bin/ld* > | tux$ > > The `duplicates' are just hard links (compare the inode numbers), so they don't waste real space (except for the directory entries :-). > > BTW, I used --prefix=/usr/local. > > Gr{oetje,eeting}s, > > Geert From owner-linux-mips@oss.sgi.com Tue Aug 7 07:08:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77E8LC19390 for linux-mips-outgoing; Tue, 7 Aug 2001 07:08:21 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77E8HV19387 for ; Tue, 7 Aug 2001 07:08:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08059; Tue, 7 Aug 2001 16:10:11 +0200 (MET DST) Date: Tue, 7 Aug 2001 16:10:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" cc: linux-mips@oss.sgi.com Subject: Re: cross-mipsel-linux-ld --prefix library path In-Reply-To: <074001c11ef4$fdbd7530$3501010a@ltc.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 6 Aug 2001, Bradley D. LaRonde wrote: > When I build and install cross-binutils (on Debian 2.2) like this: > > tar -xzf binutils-2.11.2.tar.gz > mkdir mipsel-binutils > cd mipsel-binutils > ../binutils-2.11.2/configure --target=mipsel-linux \ > --prefix=/usr/mipsel-linux > make > make install > > it seems the resulting mipsel-linux-ld wants to look in: > > /usr/mipsel-linux/mipsel-linux/lib > > for crt1.o, crti.o, libc.*, etc. You don't need to specify "--prefix=/usr/mipsel-linux" for building cross-binutils. The scripts will add the target alias automatically for files that need it -- if you look at the scripts, "${prefix}/${target_alias}" is the so called "tooldir". -- + 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 Aug 7 07:12:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77ECN419855 for linux-mips-outgoing; Tue, 7 Aug 2001 07:12:23 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77ECKV19839 for ; Tue, 7 Aug 2001 07:12:20 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 8C5BC590AC; Tue, 7 Aug 2001 10:09:51 -0400 (EDT) Message-ID: <089d01c11f4b$449b4800$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Maciej W. Rozycki" Cc: References: Subject: Re: cross-mipsel-linux-ld --prefix library path Date: Tue, 7 Aug 2001 10:14:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" Cc: Sent: Tuesday, August 07, 2001 10:10 AM Subject: Re: cross-mipsel-linux-ld --prefix library path > You don't need to specify "--prefix=/usr/mipsel-linux" for building > cross-binutils. The scripts will add the target alias automatically for > files that need it -- if you look at the scripts, > "${prefix}/${target_alias}" is the so called "tooldir". Oh... The mysteries of cross-toolchain building. Thanks. So if I leave out --prefix alogether, will "make install" overwrite any x86 stuff, like that libbfd.la file I mentioned? Regards, Brad From owner-linux-mips@oss.sgi.com Tue Aug 7 07:32:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77EWLp21255 for linux-mips-outgoing; Tue, 7 Aug 2001 07:32:21 -0700 Received: from epic8.Stanford.EDU (epic8.Stanford.EDU [171.64.15.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EWHV21248 for ; Tue, 7 Aug 2001 07:32:17 -0700 Received: (from johnd@localhost) by epic8.Stanford.EDU (8.11.1/8.11.1) id f77EVio27607; Tue, 7 Aug 2001 07:31:44 -0700 (PDT) Date: Tue, 7 Aug 2001 07:31:44 -0700 (PDT) From: "John D. Davis" To: "Salisbury, Roger" cc: "'linux-mips@oss.sgi.com'" , "'Keith Wesolows'" Subject: Re: MIPS-INDIGO2-KERNEL BUG 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 Roger- When I did a native compile for an indy, I had the same problem. I commented out the media.o line in the top level Makefile. I looked at the media.o file and there was not much there. Try compiling with the Makefile change. I don't think media.o is necessary for mips, at least it is not used for the indy box that I have. I hope that helps. I may need a kernel patch as well, if you have not already gotten one. john On Tue, 7 Aug 2001, Salisbury, Roger wrote: > Sirs > > BELOW is the ERROR > > 1. > make vmlinux > ................................. > ................................. > ................................. > ld: drivers/media/media.o: uses different e_flags (0x0) fields than previous > modules (0x100) > Bad value: failed to merge target specific data of file > drivers/media/media.o > make: *** [vmlinux] Error 1 > > > 2. > Error compiling a new kernel. > > 3. > ld (linker) > > 4. > bash-2.04# cat /proc/version > Linux version 2.2.14 (wesolows@fallout) (gcc version egcs-2.91.66 19990314 > (egcs-1.1.2 > release)) #2 Thu May 18 16:27:14 PDT 2000 > bash-2.04# > > 5.N/A > > 6 N/A > > 7. > bash-2.04# set > BASH=/usr/bin/bash > BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release" > [5]="mips-unknown-linux- > gnu") > BASH_VERSION='2.04.0(1)-release' > COLUMNS=80 > DIRSTACK=() > EUID=0 > GROUPS=() > HISTFILE=//.bash_history > HISTFILESIZE=500 > HISTSIZE=500 > HOME=/ > HOSTNAME=Roland > HOSTTYPE=mips > IFS=' > ' > LINES=24 > LOGNAME=root > MACHTYPE=mips-unknown-linux-gnu > MAIL=/var/spool/mail/root > MAILCHECK=60 > OPTERR=1 > OPTIND=1 > OSTYPE=linux-gnu > PATH=/sbin:/bin:/usr/sbin:/usr/bin > PIPESTATUS=([0]="0") > PPID=1 > PS1='\s-\v\$ ' > PS2='> ' > PS4='+ ' > PWD=/ > SHELL=/usr/bin/bash > SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comment > s:emacs > SHLVL=1 > TERM=vt100 > UID=0 > _=/proc/version > bash-2.04# > > 7.1 > > VERSIONS::::::::::::::::::::::::::::::: > > ################################################################# > > bash-2.04# /linux/scripts/ver_linux > > If some fields are empty or look unusual you may have an old version. > > Compare to the current minimal requirements in Documentation/Changes. > > > > Linux Roland 2.2.14 #2 Thu May 18 16:27:14 PDT 2000 mips unknown > > > > Gnu C egcs-2.91.66 > > Gnu make 3.79 > > binutils 000425 > > util-linux 2.10m > > mount 2.10m > > modutils 2.3.11 > > e2fsprogs 1.18 > > Linux C Library 2.0.6 > > Dynamic linker (ldd) 2.0.6 > > Linux C++ Library 2.9.0 > > Procps 2.0.6 > > Net-tools 1.55 > > Kbd command > > Sh-utils 2.0i > > cat: /proc/modules: No such file or directory > > Modules Loaded > > bash-2.04# > > > 7.2 > bash-2.04# cat /proc/cpuinfo > cpu : MIPS > cpu model : R4000SC V3.0 > system type : SGI Indy > BogoMIPS : 49.97 > byteorder : big endian > unaligned accesses : 0 > wait instruction : no > microsecond timers : no > extra interrupt vector : no > hardware watchpoint : yes > VCED exceptions : 670 > VCEI exceptions : 169 > bash-2.04# > > 7.3 > No modules > > 7.4 > bash-2.04# ls -l /proc/ioports > -r--r--r-- 1 root sys 0 Aug 8 07:33 /proc/ioports > bash-2.04# ls -l /proc/iomem > ls: /proc/iomem: No such file or directory > bash-2.04# > > 7.5 > No PCI > > 7.6 > bash-2.04# ls -lt /proc/scsi > total 0 > dr-xr-xr-x 2 root sys 0 Aug 8 07:35 SGIWD > -rw-r--r-- 1 root sys 0 Aug 8 07:35 scsi > bash-2.04# > bash-2.04# ls -lt /proc/scsi > total 0 > dr-xr-xr-x 2 root sys 0 Aug 8 07:35 SGIWD > -rw-r--r-- 1 root sys 0 Aug 8 07:35 scsi > bash-2.04# > > > 7.7 > > AND here are some details > > > ARCH: indigo 2 IP22 > SYSTEM : Simple Linux built as per > http://foobazco.org/~wesolows/Install-HOWTO.html > KERNEL: [Simple Linux/MIPS 0.1 (kernel 2.2.14)] > or [Simple Linux/MIPS 0.1 (kernel 2.4.3)] > >> hinv > System: IP22 > Processor: 100 Mhz R4000, with FPU > Primary I-cache size: 8 Kbytes > Primary D-cache size: 8 Kbytes > Secondary cache size: 1024 Kbytes > Memory size: 64 Mbytes > Graphics: XL > SCSI Disk: scsi(0)disk(1) > SCSI CDROM: scsi(0)cdrom(3) > >> > > BOTH "CONFIG_CROSS_COMPILE" has been turned on or off without any change. > > Error again: > > > mips-linux-ld: drivers/media/media.o: uses different e_flags (0x0) fields > than previous modules (0x100) > > Bad value: failed to merge target specific data of file > drivers/media/media.o > > make: [vmlinux] Error 1 (ignored) > > mips-linux-nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] > \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map > > > > > ################################################################# > > > From owner-linux-mips@oss.sgi.com Tue Aug 7 07:34:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77EYZQ21447 for linux-mips-outgoing; Tue, 7 Aug 2001 07:34:35 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EYVV21429 for ; Tue, 7 Aug 2001 07:34:32 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08486; Tue, 7 Aug 2001 16:36:35 +0200 (MET DST) Date: Tue, 7 Aug 2001 16:36:34 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" cc: linux-mips@oss.sgi.com Subject: Re: cross-mipsel-linux-ld --prefix library path In-Reply-To: <089d01c11f4b$449b4800$3501010a@ltc.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 7 Aug 2001, Bradley D. LaRonde wrote: > So if I leave out --prefix alogether, will "make install" overwrite any x86 > stuff, like that libbfd.la file I mentioned? Well, libbfd and libopcodes do conflict indeed. In theory they can support multiple targets at once, but I'm unsure if that's stable enough. I use "--enable-shared --disable-static --libdir='${exec_prefix}'/mipsel-linux/i386-linux/lib" in the configure's command line for i386-linux-hosted cross-binutils. As a result the libraries get installed out of the way but they are still used by cross-binutils thanks to the RPATH tag being set appropriately in ELF headers by libtool. -- + 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 Aug 7 07:42:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77EgSo22173 for linux-mips-outgoing; Tue, 7 Aug 2001 07:42:28 -0700 Received: from tennyson.netexpress.net (IDENT:root@tennyson.netexpress.net [64.22.192.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EgRV22170 for ; Tue, 7 Aug 2001 07:42:27 -0700 Received: from localhost (vorlon@localhost) by tennyson.netexpress.net (8.9.3/8.9.3) with ESMTP id JAA32724; Tue, 7 Aug 2001 09:42:15 -0500 X-Authentication-Warning: tennyson.netexpress.net: vorlon owned process doing -bs Date: Tue, 7 Aug 2001 09:42:14 -0500 (CDT) From: Steve Langasek To: "Bradley D. LaRonde" cc: Subject: Re: cross-mipsel-linux-ld --prefix library path In-Reply-To: <074001c11ef4$fdbd7530$3501010a@ltc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 6 Aug 2001, Bradley D. LaRonde wrote: > Another odd thing is that binutils installs: > /usr/mipsel-linux/bin/mipsel-linux-ld > and an identical copy at: > /usr/mipsel-linux/mipsel-linux/bin/ld The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and /usr/bin/mipsel-linux-ld. The reason for having two copies is that when you're calling these tools directly (or from a make script), you want them to be in your path, so you want them to have a unique name (/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer /not/ to have to mess with the name mangling used there, so instead they look for a tool with the normal name (ld) in an architecture-specific directory (/usr/mipsel-linux/bin). Steve Langasek postmodern programmer From owner-linux-mips@oss.sgi.com Tue Aug 7 07:43:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77EhpY22389 for linux-mips-outgoing; Tue, 7 Aug 2001 07:43:51 -0700 Received: from dea.waldorf-gmbh.de (u-87-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EhlV22376 for ; Tue, 7 Aug 2001 07:43:47 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f77EgnO26635; Tue, 7 Aug 2001 16:42:49 +0200 Date: Tue, 7 Aug 2001 16:42:49 +0200 From: Ralf Baechle To: Brandon Barker Cc: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010807164249.B26419@bacchus.dhis.org> References: <01080623471400.01828@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01080623471400.01828@linux>; from bebarker@meginc.com on Mon, Aug 06, 2001 at 11:47:36PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 06, 2001 at 11:47:36PM -0400, Brandon Barker wrote: > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was > curious if these are 64 bit systems or 32 bit systems (for that matter, are > all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think > IRIX has been 64 for quite some time, but was curious. I use Linux on x86 > but will probably use IRIX for a few weeks on the Indy's until I become > familiar enough with the machines to try installing Linux. BTW, does gcc > work on IRIX? By hardwareware it's a 64-bit system - like all SGI systems we support. The kernel is just a 32-bit one though which is a reasonable compromise for these systems. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 7 07:44:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Eikc22584 for linux-mips-outgoing; Tue, 7 Aug 2001 07:44:46 -0700 Received: from dea.waldorf-gmbh.de (u-87-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77EigV22569 for ; Tue, 7 Aug 2001 07:44:42 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f77EhSj26642; Tue, 7 Aug 2001 16:43:28 +0200 Date: Tue, 7 Aug 2001 16:43:28 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: "'linux-mips@oss.sgi.com'" , "'Keith Wesolows'" Subject: Re: MIPS-INDIGO2-KERNEL BUG Message-ID: <20010807164328.C26419@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Tue, Aug 07, 2001 at 05:38:15PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Aug 07, 2001 at 05:38:15PM +1000, Salisbury, Roger wrote: > 1. > make vmlinux > ................................. > ................................. > ................................. > ld: drivers/media/media.o: uses different e_flags (0x0) fields than previous > modules (0x100) > Bad value: failed to merge target specific data of file > drivers/media/media.o > make: *** [vmlinux] Error 1 Upgrade your binutils. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 7 08:23:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FNSP27620 for linux-mips-outgoing; Tue, 7 Aug 2001 08:23:28 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FNOV27614 for ; Tue, 7 Aug 2001 08:23:25 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 277C5590AC; Tue, 7 Aug 2001 11:20:54 -0400 (EDT) Message-ID: <094d01c11f55$31969d40$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Steve Langasek" Cc: References: Subject: Re: cross-mipsel-linux-ld --prefix library path Date: Tue, 7 Aug 2001 11:25:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk OK, so say I leave off --prefix entirely, and the binutils get installed in /usr/bin and /usr/mipsel-linux/bin. Now, I suppose that mipsel-linux-ld will look for libs in /usr/mipsel-linux/lib, which is cool. But, how to I convince the cross-built glibc that's where his libraries belong? Just --prefix=/usr/mipsel-linux to glibc's configure? Regards, Brad ----- Original Message ----- From: "Steve Langasek" To: "Bradley D. LaRonde" Cc: Sent: Tuesday, August 07, 2001 10:42 AM Subject: Re: cross-mipsel-linux-ld --prefix library path > On Mon, 6 Aug 2001, Bradley D. LaRonde wrote: > > > Another odd thing is that binutils installs: > > > /usr/mipsel-linux/bin/mipsel-linux-ld > > > and an identical copy at: > > > /usr/mipsel-linux/mipsel-linux/bin/ld > > The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and > /usr/bin/mipsel-linux-ld. The reason for having two copies is that when > you're calling these tools directly (or from a make script), you want them to > be in your path, so you want them to have a unique name > (/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer /not/ > to have to mess with the name mangling used there, so instead they look for a > tool with the normal name (ld) in an architecture-specific directory > (/usr/mipsel-linux/bin). > > Steve Langasek > postmodern programmer > > From owner-linux-mips@oss.sgi.com Tue Aug 7 08:42:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77FgoN30569 for linux-mips-outgoing; Tue, 7 Aug 2001 08:42:50 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77FgbV30557 for ; Tue, 7 Aug 2001 08:42:37 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 95267125C3; Tue, 7 Aug 2001 08:42:36 -0700 (PDT) Date: Tue, 7 Aug 2001 08:42:36 -0700 From: "H . J . Lu" To: Eric Christopher Cc: gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com Subject: PATCH: Clean up Linux/mips. Message-ID: <20010807084236.A5550@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 Here is a patch to clean up Linux/mips. It also fixes a bug in UNIQUE_SECTION in config/mips/elf.h, which uses `decl' instead of `DECL'. Tested on Linux/mipsel. H.J. ---- 2001-08-06 H.J. Lu * config/mips/mips.c (mips_unique_section): New. Copied from config/mips/elf.h. * config/mips/mips-protos.h (mips_unique_section): New prototype. * config/mips/elf.h (UNIQUE_SECTION): Use mips_unique_section. * config/mips/little.h: New. Generic little endian mips targets. * config/mips/linux.h: Include "gofast.h" and "mips/mips.h". (WCHAR_TYPE): Defined (WCHAR_TYPE_SIZE): Likewise. (INIT_SUBTARGET_OPTABS): Likewise. (BSS_SECTION_ASM_OP): Likewise. (SBSS_SECTION_ASM_OP): Likewise. (ASM_OUTPUT_ALIGNED_BSS): Likewise. (ASM_DECLARE_OBJECT_NAME): Likewise. (UNIQUE_SECTION): Likewise. (EXTRA_SECTIONS): Likewise. (ASM_OUTPUT_CONSTRUCTOR): Likewise. (ASM_OUTPUT_DESTRUCTOR): Likewise. (ASM_OUTPUT_DEF): Likewise. (HANDLE_SYSV_PRAGMA): Removed. (NO_IMPLICIT_EXTERN_C): Likewise. (TARGET_MEM_FUNCTIONS): Likewise. (STARTFILE_SPEC): Likewise. (ENDFILE_SPEC): Likewise. (LIB_SPEC): Likewise. (INVOKE__main): Likewise. (CTOR_LIST_BEGIN): Likewise. (CTOR_LIST_END): Likewise. (DTOR_LIST_BEGIN): Likewise. (DTOR_LIST_END): Likewise. (SET_ASM_OP): Likewise. (ASM_OUTPUT_SOURCE_LINE): Likewise. (ASM_OUTPUT_DEF): Likewise. (ASM_OUTPUT_IDENT): Likewise. * config/mips/mips.h (ASM_SPEC): Undefine before define. (CPLUSPLUS_CPP_SPEC): Likewise. (ASM_APP_ON) Redefine only if not defined. (ASM_APP_OFF): Likewise. (ASM_OUTPUT_SOURCE_LINE): Likewise. (ASM_OUTPUT_IDENT): Likewise. * config.gcc: Update tm_file for Linux/mips. --- gcc/config.gcc.linux Wed Aug 1 16:00:23 2001 +++ gcc/config.gcc Sun Aug 5 08:56:33 2001 @@ -2200,9 +2200,9 @@ mipsel-*-netbsd* | mips-dec-netbsd*) ;; mips*-*-linux*) # Linux MIPS, either endian. xmake_file=x-linux + tm_file="linux.h mips/linux.h" case $machine in - mips*el-*) tm_file="elfos.h mips/elfl.h mips/linux.h" ;; - *) tm_file="elfos.h mips/elf.h mips/linux.h" ;; + mips*el-*) tm_file="mips/little.h $tm_file" ;; esac tmake_file="t-slibgcc-elf-ver t-linux mips/t-linux" extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o" --- gcc/config/mips/elf.h.linux Mon Jul 2 21:03:24 2001 +++ gcc/config/mips/elf.h Mon Aug 6 11:35:44 2001 @@ -214,70 +214,8 @@ do { \ #undef UNIQUE_SECTION_P #define UNIQUE_SECTION_P(DECL) (DECL_ONE_ONLY (DECL)) #undef UNIQUE_SECTION -#define UNIQUE_SECTION(DECL,RELOC) \ -do { \ - int len, size, sec; \ - char *name, *string, *prefix; \ - static char *prefixes[4][2] = { \ - { ".text.", ".gnu.linkonce.t." }, \ - { ".rodata.", ".gnu.linkonce.r." }, \ - { ".data.", ".gnu.linkonce.d." }, \ - { ".sdata.", ".gnu.linkonce.s." } \ - }; \ - \ - name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (DECL)); \ - size = int_size_in_bytes (TREE_TYPE (decl)); \ - \ - /* Determine the base section we are interested in: \ - 0=text, 1=rodata, 2=data, 3=sdata, [4=bss]. */ \ - if (TREE_CODE (DECL) == FUNCTION_DECL) \ - sec = 0; \ - else if (DECL_INITIAL (DECL) == 0 \ - || DECL_INITIAL (DECL) == error_mark_node) \ - sec = 2; \ - else if ((TARGET_EMBEDDED_PIC || TARGET_MIPS16) \ - && TREE_CODE (decl) == STRING_CST \ - && !flag_writable_strings) \ - { \ - /* For embedded position independent code, put constant strings \ - in the text section, because the data section is limited to \ - 64K in size. For mips16 code, put strings in the text \ - section so that a PC relative load instruction can be used to \ - get their address. */ \ - sec = 0; \ - } \ - else if (TARGET_EMBEDDED_DATA) \ - { \ - /* For embedded applications, always put an object in read-only data \ - if possible, in order to reduce RAM usage. */ \ - \ - if (DECL_READONLY_SECTION (DECL, RELOC)) \ - sec = 1; \ - else if (size > 0 && size <= mips_section_threshold) \ - sec = 3; \ - else \ - sec = 2; \ - } \ - else \ - { \ - /* For hosted applications, always put an object in small data if \ - possible, as this gives the best performance. */ \ - \ - if (size > 0 && size <= mips_section_threshold) \ - sec = 3; \ - else if (DECL_READONLY_SECTION (DECL, RELOC)) \ - sec = 1; \ - else \ - sec = 2; \ - } \ - \ - prefix = prefixes[sec][DECL_ONE_ONLY (DECL)]; \ - len = strlen (name) + strlen (prefix); \ - string = alloca (len + 1); \ - sprintf (string, "%s%s", prefix, name); \ - \ - DECL_SECTION_NAME (DECL) = build_string (len, string); \ -} while (0) +#define UNIQUE_SECTION(DECL,RELOC) \ + mips_unique_section ((DECL), (RELOC)) /* Support the ctors/dtors and other sections. */ --- gcc/config/mips/linux.h.linux Wed Aug 1 10:24:54 2001 +++ gcc/config/mips/linux.h Mon Aug 6 11:30:33 2001 @@ -18,6 +18,128 @@ along with GNU CC; see the file COPYING. the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include "gofast.h" + +/* US Software GOFAST library support. */ +#define INIT_SUBTARGET_OPTABS INIT_GOFAST_OPTABS + +#include "mips/mips.h" + +#undef WCHAR_TYPE +#define WCHAR_TYPE "int" + +#undef WCHAR_TYPE_SIZE +#define WCHAR_TYPE_SIZE 32 + +/* If defined, a C expression whose value is a string containing the + assembler operation to identify the following data as + uninitialized global data. If not defined, and neither + `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined, + uninitialized global data will be output in the data section if + `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be + used. */ +#define BSS_SECTION_ASM_OP "\t.section\t.bss" + +#define SBSS_SECTION_ASM_OP "\t.section .sbss" + +/* Like `ASM_OUTPUT_BSS' except takes the required alignment as a + separate, explicit argument. If you define this macro, it is used + in place of `ASM_OUTPUT_BSS', and gives you more flexibility in + handling the required alignment of the variable. The alignment is + specified as the number of bits. + + Try to use function `asm_output_aligned_bss' defined in file + `varasm.c' when defining this macro. */ +#define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \ +do { \ + ASM_GLOBALIZE_LABEL (FILE, NAME); \ + if (SIZE > 0 && SIZE <= mips_section_threshold) \ + sbss_section (); \ + else \ + bss_section (); \ + ASM_OUTPUT_ALIGN (FILE, floor_log2 (ALIGN / BITS_PER_UNIT)); \ + last_assemble_variable_decl = DECL; \ + ASM_DECLARE_OBJECT_NAME (FILE, NAME, DECL); \ + ASM_OUTPUT_SKIP (FILE, SIZE ? SIZE : 1); \ +} while (0) + +/* These macros generate the special .type and .size directives which + are used to set the corresponding fields of the linker symbol table + entries in an ELF object file under SVR4. These macros also output + the starting labels for the relevant functions/objects. */ + +/* Write the extra assembler code needed to declare an object properly. */ + +#undef ASM_DECLARE_OBJECT_NAME +#define ASM_DECLARE_OBJECT_NAME(FILE, NAME, DECL) \ + do { \ + fprintf (FILE, "%s", TYPE_ASM_OP); \ + assemble_name (FILE, NAME); \ + putc (',', FILE); \ + fprintf (FILE, TYPE_OPERAND_FMT, "object"); \ + putc ('\n', FILE); \ + size_directive_output = 0; \ + if (!flag_inhibit_size_directive && DECL_SIZE (DECL)) \ + { \ + size_directive_output = 1; \ + fprintf (FILE, "%s", SIZE_ASM_OP); \ + assemble_name (FILE, NAME); \ + fprintf (FILE, ",%d\n", \ + int_size_in_bytes (TREE_TYPE (DECL))); \ + } \ + mips_declare_object (FILE, NAME, "", ":\n", 0); \ + } while (0) + +#undef UNIQUE_SECTION +#define UNIQUE_SECTION(DECL,RELOC) \ + mips_unique_section ((DECL), (RELOC)) + +/* A list of other sections which the compiler might be "in" at any + given time. */ +#undef EXTRA_SECTIONS +#define EXTRA_SECTIONS in_sdata, in_sbss, in_rdata, in_ctors, in_dtors + +#undef EXTRA_SECTION_FUNCTIONS +#define EXTRA_SECTION_FUNCTIONS \ + SECTION_FUNCTION_TEMPLATE(sdata_section, in_sdata, SDATA_SECTION_ASM_OP) \ + SECTION_FUNCTION_TEMPLATE(sbss_section, in_sbss, SBSS_SECTION_ASM_OP) \ + SECTION_FUNCTION_TEMPLATE(rdata_section, in_rdata, RDATA_SECTION_ASM_OP) \ + SECTION_FUNCTION_TEMPLATE(ctors_section, in_ctors, CTORS_SECTION_ASM_OP) \ + SECTION_FUNCTION_TEMPLATE(dtors_section, in_dtors, DTORS_SECTION_ASM_OP) + +#define SECTION_FUNCTION_TEMPLATE(FN, ENUM, OP) \ +void FN () \ +{ \ + if (in_section != ENUM) \ + { \ + fprintf (asm_out_file, "%s\n", OP); \ + in_section = ENUM; \ + } \ +} + +/* A C statement (sans semicolon) to output an element in the table of + global constructors. */ +#undef ASM_OUTPUT_CONSTRUCTOR +#define ASM_OUTPUT_CONSTRUCTOR(FILE,NAME) \ + do { \ + ctors_section (); \ + fprintf (FILE, "\t%s\t", TARGET_LONG64 ? ".dword" : ".word"); \ + assemble_name (FILE, NAME); \ + fprintf (FILE, "\n"); \ + } while (0) + + +/* A C statement (sans semicolon) to output an element in the table of + global destructors. */ +#undef ASM_OUTPUT_DESTRUCTOR +#define ASM_OUTPUT_DESTRUCTOR(FILE,NAME) \ + do { \ + dtors_section (); \ + fprintf (FILE, "\t%s\t", TARGET_LONG64 ? ".dword" : ".word"); \ + assemble_name (FILE, NAME); \ + fprintf (FILE, "\n"); \ + } while (0) + #undef TARGET_VERSION #if TARGET_ENDIAN_DEFAULT == 0 #define TARGET_VERSION fprintf (stderr, " (MIPSel GNU/Linux with ELF)"); @@ -35,17 +157,6 @@ Boston, MA 02111-1307, USA. */ #undef TARGET_DEFAULT #define TARGET_DEFAULT (MASK_ABICALLS|MASK_GAS) - -/* Handle #pragma weak and #pragma pack. */ -#undef HANDLE_SYSV_PRAGMA -#define HANDLE_SYSV_PRAGMA 1 - -/* Don't assume anything about the header files. */ -#define NO_IMPLICIT_EXTERN_C - -/* Generate calls to memcpy, etc., not bcopy, etc. */ -#define TARGET_MEM_FUNCTIONS - /* Specify predefined symbols in preprocessor. */ #undef CPP_PREDEFINES #if TARGET_ENDIAN_DEFAULT == 0 @@ -112,40 +223,12 @@ Boston, MA 02111-1307, USA. */ -D_GNU_SOURCE %(cpp) \ " -/* Provide a STARTFILE_SPEC appropriate for GNU/Linux. Here we add - the GNU/Linux magical crtbegin.o file (see crtstuff.c) which - provides part of the support for getting C++ file-scope static - object constructed before entering `main'. */ - -#undef STARTFILE_SPEC -#define STARTFILE_SPEC \ - "%{!shared: \ - %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:crt1.o%s}}}\ - crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}" - -/* Provide a ENDFILE_SPEC appropriate for GNU/Linux. Here we tack on - the GNU/Linux magical crtend.o file (see crtstuff.c) which - provides part of the support for getting C++ file-scope static - object constructed before entering `main', followed by a normal - GNU/Linux "finalizer" file, `crtn.o'. */ - -#undef ENDFILE_SPEC -#define ENDFILE_SPEC \ - "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s" - /* From iris5.h */ /* -G is incompatible with -KPIC which is the default, so only allow objects in the small data section if the user explicitly asks for it. */ #undef MIPS_DEFAULT_GVALUE #define MIPS_DEFAULT_GVALUE 0 -#undef LIB_SPEC -/* Taken from sparc/linux.h. */ -#define LIB_SPEC \ - "%{shared: -lc} \ - %{!shared: %{mieee-fp:-lieee} %{pthread:-lpthread} \ - %{profile:-lc_p} %{!profile: -lc}}" - /* Borrowed from sparc/linux.h */ #undef LINK_SPEC #define LINK_SPEC \ @@ -165,44 +248,19 @@ Boston, MA 02111-1307, USA. */ %{!fno-PIC:%{!fno-pic:-KPIC}} \ %{fno-PIC:-non_shared} %{fno-pic:-non_shared}" -/* We don't need those nonsenses. */ -#undef INVOKE__main -#undef CTOR_LIST_BEGIN -#undef CTOR_LIST_END -#undef DTOR_LIST_BEGIN -#undef DTOR_LIST_END - /* The MIPS assembler has different syntax for .set. We set it to .dummy to trap any errors. */ #undef SET_ASM_OP #define SET_ASM_OP "\t.dummy\t" -#undef ASM_OUTPUT_SOURCE_LINE -#define ASM_OUTPUT_SOURCE_LINE(FILE, LINE) \ -do \ - { \ - static int sym_lineno = 1; \ - fprintf (FILE, "%sLM%d:\n\t%s 68,0,%d,%sLM%d", \ - LOCAL_LABEL_PREFIX, sym_lineno, ASM_STABN_OP, \ - LINE, LOCAL_LABEL_PREFIX, sym_lineno); \ - putc ('-', FILE); \ - assemble_name (FILE, \ - XSTR (XEXP (DECL_RTL (current_function_decl), 0), 0));\ - putc ('\n', FILE); \ - sym_lineno++; \ - } \ -while (0) - -/* This is how we tell the assembler that two symbols have the - same value. */ #undef ASM_OUTPUT_DEF #define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2) \ - do { \ - fprintf ((FILE), "\t"); \ + do { \ + fputc ( '\t', FILE); \ assemble_name (FILE, LABEL1); \ - fprintf (FILE, "="); \ + fputs ( " = ", FILE); \ assemble_name (FILE, LABEL2); \ - fprintf (FILE, "\n"); \ + fputc ( '\n', FILE); \ } while (0) #undef ASM_OUTPUT_DEFINE_LABEL_DIFFERENCE_SYMBOL @@ -248,8 +306,3 @@ while (0) /* Tell function_prologue in mips.c that we have already output the .ent/.end pseudo-ops. */ #define FUNCTION_NAME_ALREADY_DECLARED - -/* Output #ident as a .ident. */ -#undef ASM_OUTPUT_IDENT -#define ASM_OUTPUT_IDENT(FILE, NAME) \ - fprintf (FILE, "\t%s\t\"%s\"\n", IDENT_ASM_OP, NAME); --- gcc/config/mips/little.h.linux Wed Aug 1 14:04:44 2001 +++ gcc/config/mips/little.h Wed Aug 1 16:09:31 2001 @@ -0,0 +1,22 @@ +/* Definition of little endian mips machine for GNU compiler. + + Copyright (C) 2001 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC 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, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +#define TARGET_ENDIAN_DEFAULT 0 --- gcc/config/mips/mips-protos.h.linux Sun Jul 15 18:30:29 2001 +++ gcc/config/mips/mips-protos.h Mon Aug 6 11:38:33 2001 @@ -60,6 +60,7 @@ extern void mips_va_start PARAMS ((int, #endif /* RTX_CODE */ extern struct rtx_def *mips_va_arg PARAMS ((tree, tree)); extern void mips_select_section PARAMS ((tree, int)); +extern void mips_unique_section PARAMS ((tree, int)); #endif /* TREE_CODE */ #ifdef RTX_CODE --- gcc/config/mips/mips.c.linux Thu Jul 26 10:13:51 2001 +++ gcc/config/mips/mips.c Mon Aug 6 11:40:23 2001 @@ -9800,3 +9800,75 @@ mips_parse_cpu (cpu_string) return cpu; } + +/* Cover function for UNIQUE_SECTION. */ + +void +mips_unique_section (decl, reloc) + tree decl; + int reloc; +{ + int len, size, sec; + char *name, *string, *prefix; + static char *prefixes[4][2] = { + { ".text.", ".gnu.linkonce.t." }, + { ".rodata.", ".gnu.linkonce.r." }, + { ".data.", ".gnu.linkonce.d." }, + { ".sdata.", ".gnu.linkonce.s." } + }; + + name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)); + size = int_size_in_bytes (TREE_TYPE (decl)); + + /* Determine the base section we are interested in: + 0=text, 1=rodata, 2=data, 3=sdata, [4=bss]. */ + if (TREE_CODE (decl) == FUNCTION_DECL) + sec = 0; + else if (DECL_INITIAL (decl) == 0 + || DECL_INITIAL (decl) == error_mark_node) + sec = 2; + else if ((TARGET_EMBEDDED_PIC || TARGET_MIPS16) + && TREE_CODE (decl) == STRING_CST + && !flag_writable_strings) + { + /* For embedded position independent code, put constant + strings in the text section, because the data section + is limited to 64K in size. For mips16 code, put + strings in the text section so that a PC relative load + instruction can be used to get their address. */ + sec = 0; + } + else if (TARGET_EMBEDDED_DATA) + { + /* For embedded applications, always put an object in + read-only data if possible, in order to reduce RAM + usage. */ + + if (DECL_READONLY_SECTION (decl, reloc)) + sec = 1; + else if (size > 0 && size <= mips_section_threshold) + sec = 3; + else + sec = 2; + } + else + { + /* For hosted applications, always put an object in + small data if possible, as this gives the best + performance. */ + + if (size > 0 && size <= mips_section_threshold) + sec = 3; + else if (DECL_READONLY_SECTION (decl, reloc)) + sec = 1; + else + sec = 2; + } + + prefix = prefixes[sec][DECL_ONE_ONLY (decl)]; + len = strlen (name) + strlen (prefix); + string = alloca (len + 1); + sprintf (string, "%s%s", prefix, name); + + DECL_SECTION_NAME (decl) = build_string (len, string); +} --- gcc/config/mips/mips.h.linux Wed Aug 1 15:37:14 2001 +++ gcc/config/mips/mips.h Mon Aug 6 11:27:03 2001 @@ -862,6 +862,7 @@ while (0) /* ASM_SPEC is the set of arguments to pass to the assembler. */ +#undef ASM_SPEC #define ASM_SPEC "\ %{!membedded-pic:%{G*}} %(endian_spec) %{mips1} %{mips2} %{mips3} %{mips4} \ %{mips16:%{!mno-mips16:-mips16}} %{mno-mips16:-no-mips16} \ @@ -991,6 +992,7 @@ while (0) /* For C++ we need to ensure that _LANGUAGE_C_PLUS_PLUS is defined independent of the source file extension. */ +#undef CPLUSPLUS_CPP_SPEC #define CPLUSPLUS_CPP_SPEC "\ -D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS \ %(cpp) \ @@ -3822,12 +3824,16 @@ while (0) /* Output to assembler file text saying following lines may contain character constants, extra white space, comments, etc. */ +#ifndef ASM_APP_ON #define ASM_APP_ON " #APP\n" +#endif /* Output to assembler file text saying following lines no longer contain unusual constructs. */ +#ifndef ASM_APP_OFF #define ASM_APP_OFF " #NO_APP\n" +#endif /* How to refer to registers in assembler output. This sequence is indexed by compiler's hard-register-number (see above). @@ -4119,9 +4125,10 @@ while (0) #define LABEL_AFTER_LOC(STREAM) #endif -#undef ASM_OUTPUT_SOURCE_LINE +#ifndef ASM_OUTPUT_SOURCE_LINE #define ASM_OUTPUT_SOURCE_LINE(STREAM, LINE) \ mips_output_lineno (STREAM, LINE) +#endif /* The MIPS implementation uses some labels for its own purpose. The following lists what labels are created, and are all formed by the @@ -4410,8 +4417,8 @@ do { \ /* Handle certain cpp directives used in header files on sysV. */ #define SCCS_DIRECTIVE +#ifndef ASM_OUTPUT_IDENT /* Output #ident as a in the read-only data section. */ -#undef ASM_OUTPUT_IDENT #define ASM_OUTPUT_IDENT(FILE, STRING) \ { \ const char *p = STRING; \ @@ -4419,6 +4426,7 @@ do { \ rdata_section (); \ assemble_string (p, size); \ } +#endif /* Default to -G 8 */ #ifndef MIPS_DEFAULT_GVALUE From owner-linux-mips@oss.sgi.com Tue Aug 7 09:07:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77G7Nn01559 for linux-mips-outgoing; Tue, 7 Aug 2001 09:07:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77G7JV01553; Tue, 7 Aug 2001 09:07:19 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id C908E125C3; Tue, 7 Aug 2001 09:07:18 -0700 (PDT) Date: Tue, 7 Aug 2001 09:07:18 -0700 From: "H . J . Lu" To: Paul Kasper Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?) Message-ID: <20010807090718.B5936@lucon.org> References: <20010805094806.A3146@lucon.org> <20010806115913.B17179@bacchus.dhis.org> <997108072.1773.10.camel@ghostwheel.cygnus.com> <20010806182843.B21142@bacchus.dhis.org> <3B6FD676.CA20DF04@patton.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6FD676.CA20DF04@patton.com>; from paul@patton.com on Tue, Aug 07, 2001 at 07:52:22AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Aug 07, 2001 at 07:52:22AM -0400, Paul Kasper wrote: > > > > MIPS psABI 3.0. > > > > Ralf > > Where can I find the MIPS ABI? > ftp://oss.sgi.com/pub/linux/mips/doc/ABI/ H.J. From owner-linux-mips@oss.sgi.com Tue Aug 7 10:41:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77Hf7s05109 for linux-mips-outgoing; Tue, 7 Aug 2001 10:41:07 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77Hf6V05106 for ; Tue, 7 Aug 2001 10:41:06 -0700 content-class: urn:content-classes:message Subject: Could not find the source code for "/sbin/init". MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 7 Aug 2001 10:39:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A2257@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Could not find the source code for "/sbin/init". Thread-Index: AcEfZ9sR8pfBso9zTOeZBYlOZk+QMQ== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f77Hf6V05107 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi ALL: As we know, the function init( ) in main.c is static int init(void * unused) { lock_kernel(); do_basic_setup(); free_initmem(); unlock_kernel(); if (open("/dev/console", O_RDWR, 0) < 0) printk("Warning: unable to open an initial console.\n"); (void) dup(0); (void) dup(0); if (execute_command) execve(execute_command,argv_init,envp_init); execve("/sbin/init",argv_init,envp_init); //<--- problem execve("/etc/init",argv_init,envp_init); execve("/bin/init",argv_init,envp_init); execve("/bin/sh",argv_init,envp_init); panic("No init found. Try passing init= option to kernel."); } The system call execve("/sbin/init",argv_init,envp_init) will start a background process. In my case, it could not start the process, that is, system hangs there and execve("/etc/init",argv_init,envp_init) could not be executed. Could you tell me where could I find the source code for the executable /sbin/init? Thank you very much for your help. Regards, Steven Liu From owner-linux-mips@oss.sgi.com Tue Aug 7 10:47:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77HlVI05346 for linux-mips-outgoing; Tue, 7 Aug 2001 10:47:31 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77HlTV05343 for ; Tue, 7 Aug 2001 10:47:29 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f77HqRA26776; Tue, 7 Aug 2001 10:52:33 -0700 Message-ID: <3B702A28.5020002@pacbell.net> Date: Tue, 07 Aug 2001 10:49:28 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Steven Liu CC: linux-mips@oss.sgi.com Subject: Re: Could not find the source code for "/sbin/init". References: <84CE342693F11946B9F54B18C1AB837B0A2257@ex2k.pcs.psdc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Steven Liu wrote: > Hi ALL: > > As we know, the function init( ) in main.c is > > static int init(void * unused) > { > lock_kernel(); > do_basic_setup(); > free_initmem(); > unlock_kernel(); > > if (open("/dev/console", O_RDWR, 0) < 0) > printk("Warning: unable to open an initial console.\n"); > > (void) dup(0); > (void) dup(0); > > > if (execute_command) > execve(execute_command,argv_init,envp_init); > > execve("/sbin/init",argv_init,envp_init); //<--- problem > > execve("/etc/init",argv_init,envp_init); > execve("/bin/init",argv_init,envp_init); > execve("/bin/sh",argv_init,envp_init); > panic("No init found. Try passing init= option to kernel."); > } > > The system call execve("/sbin/init",argv_init,envp_init) will start a > background process. > In my case, it could not start the process, that is, system hangs there > and > execve("/etc/init",argv_init,envp_init) could not be executed. > > > Could you tell me where could I find the source code for the executable > /sbin/init? > > Thank you very much for your help. /sbin/init is part of the SysVInit package. Your problem is most likely NOT with /sbin/init itself. I would start by loading sash first; if that works, try a static bash; if that works, try a dynamically linked bash. Pete From owner-linux-mips@oss.sgi.com Tue Aug 7 12:27:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77JRpi09901 for linux-mips-outgoing; Tue, 7 Aug 2001 12:27:51 -0700 Received: from tennyson.netexpress.net (IDENT:root@tennyson.netexpress.net [64.22.192.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77JRoV09893 for ; Tue, 7 Aug 2001 12:27:50 -0700 Received: from localhost (vorlon@localhost) by tennyson.netexpress.net (8.9.3/8.9.3) with ESMTP id OAA00981; Tue, 7 Aug 2001 14:27:44 -0500 X-Authentication-Warning: tennyson.netexpress.net: vorlon owned process doing -bs Date: Tue, 7 Aug 2001 14:27:44 -0500 (CDT) From: Steve Langasek To: "Bradley D. LaRonde" cc: Subject: Re: cross-mipsel-linux-ld --prefix library path In-Reply-To: <094d01c11f55$31969d40$3501010a@ltc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 7 Aug 2001, Bradley D. LaRonde wrote: > OK, so say I leave off --prefix entirely, and the binutils get installed in > /usr/bin and /usr/mipsel-linux/bin. Now, I suppose that mipsel-linux-ld > will look for libs in /usr/mipsel-linux/lib, which is cool. But, how to I > convince the cross-built glibc that's where his libraries belong? > Just --prefix=/usr/mipsel-linux to glibc's configure? That should be enough to force glibc to use /usr/mipsel-linux, but I don't think it's correct to use that as a /configure/ option. Effectively, libraries used for cross-building should be identical to the native libraries in every way[1], only installed in a different place on the system. You would never /run/ glibc-based applications against /usr/mipsel-linux on a native system. On Debian, I find that dpkg-cross is a very useful utility. You can pass it the filename of a package from another architecture, as well as the architecture it belongs to, and it will reconstruct an Architecture: all package that places the libraries under /usr/-linux. This seems a bit easier than trying to worry about install directories for glibc at compile time. HTH, Steve Langasek postmodern programmer [1] ok, with the exception of /usr/lib/libc.so, which is not a library at all, but rather a GNU linker script. dpkg-cross also takes care of rewriting this script, which I found rather impressive the first time I saw it happen. From owner-linux-mips@oss.sgi.com Tue Aug 7 13:53:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77KrHg22224 for linux-mips-outgoing; Tue, 7 Aug 2001 13:53:17 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77KrGV22217 for ; Tue, 7 Aug 2001 13:53:16 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.0.Beta17/8.12.0.Beta17) with ESMTP id f77KrFFd025779 for ; Tue, 7 Aug 2001 16:53:16 -0400 (EDT) Date: Tue, 7 Aug 2001 16:53:15 -0400 (EDT) From: Ian To: Subject: HELP can't boot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk OK I'm having some problems here. I recently received an SGI Indy (complete with all hardware except disk) and I installed a blank 1-GB scsi disk (no disk errors reported on bootup) but without sash I cannot netboot linux. My question is this: How can I netboot linux (using bootp, tftp, and nfs, all confirmed working)? I the kernel and the hardhat kit, but I can't get the Indy to load the kernel. I have no IRIX kits available, nor a CD-writer (although I have access to a CD-writer if needed). PLEASE help! Thanks in advance! -- Ian Cooper ian@wpi.edu From owner-linux-mips@oss.sgi.com Tue Aug 7 17:38:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f780cj022286 for linux-mips-outgoing; Tue, 7 Aug 2001 17:38:45 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f780ciV22283 for ; Tue, 7 Aug 2001 17:38:44 -0700 content-class: urn:content-classes:message Subject: execve("sbin/init",argv_init,envp-init) in init() of main.c and sbin/init. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 7 Aug 2001 17:36:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A2294@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: execve("sbin/init",argv_init,envp-init) in init() of main.c and sbin/init. Thread-Index: AcEfojJqpJJKjWoETbGX1CrUnpmVpQ== From: "Steven Liu" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f780ciV22284 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, ALL: I posted a message in this board regarding execve("sbin/init",argv_init,envp-init) in init() of main.c this morning. Pete gave some very good suggessions.Thank you very much, Pete. I tried them but the problem has not been solved yet. My CPU is not standard R3000 mips CPU with some registers added in and modified. For example, ASID field in EntryHi register is of 8 bits instead of 6 bits. This may creat some problems. I want to investigate the "sbin/init" program but I do not know where I can find the source code of this program. If you know any hint and let me know, I would be very pleased. Thank you for your help. Regards, Steven Liu From owner-linux-mips@oss.sgi.com Tue Aug 7 17:45:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f780jnj23384 for linux-mips-outgoing; Tue, 7 Aug 2001 17:45:49 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f780jlV23381 for ; Tue, 7 Aug 2001 17:45:47 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA20847; Tue, 7 Aug 2001 20:45:17 -0400 Date: Tue, 7 Aug 2001 20:45:17 -0400 From: "J. Scott Kasten" To: Brandon Barker cc: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? In-Reply-To: <01080623471400.01828@linux> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Well, it's kind of both. The R4000 and up are 64 bit CPU's capable of running either 32 or 64 bit code. The MIPS address space is a little wierd such that you can kinda munge 32 and 64 bit code togeather under the right circumstances. Some of the old hands here could tell you better how Irix behaves on those boxes. I know you can compile code with 64 bit int and pointers and it will run on those boxes under Irix, but there is a little more to it than that. Yes, gcc works under Irix. I think most of Reputable's Indy's have Irix 6.2 loaded on them, which is probably the minimum you would want to run gcc under. You will have to download the IDF and IDL from SGI (about 500MB worth of stuff) to make gcc work. It relies on having the official Irix /usr/include, compiler libraries, and the navtive Irix assembler/linker. I've used the gcc-2.95.2 found on SGI's freeware site. It seems quite solid. The only caveat to using gcc with Irix is that gcc and the native compiler differ in how they pass data structures as arguments to functions, or as return values. I'm not talking about pointers to structs, but actual structs as the targets. Code that does that will break. Thankfully, that's rare, but there are a few stdlib cases such as semiphore operations. I've used both linux and Irix on the Indy. Quite frankly, I would consider getting a second HD if cheep enough so that you could keep both around. (Note: don't put 2 high RPM drives in the Indy, or we are talking melt down of your pretty blue toy...) I've found much to like in Irix in addition to the flexibility of Linux. On Mon, 6 Aug 2001, Brandon Barker wrote: > I will be purchasing 2 SGI Indy R5000 models from reputable.com, and was > curious if these are 64 bit systems or 32 bit systems (for that matter, are > all/any Indys 32 or 64 bit systems). My guess is 64 because I wiould think > IRIX has been 64 for quite some time, but was curious. I use Linux on x86 > but will probably use IRIX for a few weeks on the Indy's until I become > familiar enough with the machines to try installing Linux. BTW, does gcc > work on IRIX? > > Thanks for the info, > Brandon Barker > From owner-linux-mips@oss.sgi.com Tue Aug 7 20:59:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f783xcC16316 for linux-mips-outgoing; Tue, 7 Aug 2001 20:59:38 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f783xZV16312 for ; Tue, 7 Aug 2001 20:59:36 -0700 Received: (qmail 17737 invoked by uid 502); 8 Aug 2001 03:59:34 -0000 Content-Type: text/plain; charset="koi8-r" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: "Steven Liu" , Subject: Re: execve("sbin/init",argv_init,envp-init) in init() of main.c and sbin/init. Date: Tue, 7 Aug 2001 20:59:31 -0700 X-Mailer: KMail [version 1.2] Cc: References: <84CE342693F11946B9F54B18C1AB837B0A2294@ex2k.pcs.psdc.com> In-Reply-To: <84CE342693F11946B9F54B18C1AB837B0A2294@ex2k.pcs.psdc.com> MIME-Version: 1.0 Message-Id: <01080720593103.03147@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Look for SystemVinit at sunsite.unc.edu, or any other major free software archive. Or just search alte vista... On Tuesday 07 August 2001 17:36, Steven Liu wrote: > Hi, ALL: > > I posted a message in this board regarding > execve("sbin/init",argv_init,envp-init) in init() of main.c this > morning. Pete gave some very good suggessions.Thank you very much, Pete. > I tried them but the problem has not been solved yet. My CPU is not > standard R3000 mips CPU with some registers added in and modified. For > example, ASID field in EntryHi register is of 8 bits instead of 6 bits. > This may creat some problems. > > I want to investigate the "sbin/init" program but I do not know where I > can find the source code of this program. If you know any hint and let > me know, I would be very pleased. > > Thank you for your help. > > Regards, > > Steven Liu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtwuSYACgkQtKh84cA8u2nn7gCeNd3zrFk3mPAzKubwGfW3EVEC Cq4AoIyMVLJ0LSbc/1Iot28eCBSmaVaf =UyqM -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Tue Aug 7 21:40:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f784e4p21766 for linux-mips-outgoing; Tue, 7 Aug 2001 21:40:04 -0700 Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f784e3V21763 for ; Tue, 7 Aug 2001 21:40:03 -0700 Received: from pacbell.net ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHQ005EBFMNQ3@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Tue, 07 Aug 2001 21:40:00 -0700 (PDT) Date: Tue, 07 Aug 2001 21:39:56 -0700 From: Pete Popov Subject: Re: execve("sbin/init",argv_init,envp-init) in init() of main.c and sbin/init. To: Steven Liu Cc: linux-mips@oss.sgi.com, dankamura@mvista.com Reply-to: ppopov@pacbell.net Message-id: <3B70C29C.8080803@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <84CE342693F11946B9F54B18C1AB837B0A2294@ex2k.pcs.psdc.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Steven Liu wrote: > Hi, ALL: > > I posted a message in this board regarding > execve("sbin/init",argv_init,envp-init) in init() of main.c this > morning. Pete gave some very good suggessions.Thank you very much, Pete. > I tried them but the problem has not been solved yet. My CPU is not > standard R3000 mips CPU with some registers added in and modified. For > example, ASID field in EntryHi register is of 8 bits instead of 6 bits. > This may creat some problems. > > I want to investigate the "sbin/init" program but I do not know where I > can find the source code of this program. If you know any hint and let > me know, I would be very pleased. > > Thank you for your help. If you tried sash and you couldn't run it, I strongly suggest not messing with /sbin/init. Work on your kernel until you can run a simple userland shell like sash. Pete From owner-linux-mips@oss.sgi.com Wed Aug 8 01:25:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f788PJp21994 for linux-mips-outgoing; Wed, 8 Aug 2001 01:25:19 -0700 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 f788PHV21979 for ; Wed, 8 Aug 2001 01:25:17 -0700 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.9.3/8.8.7) with ESMTP id KAA06296; Wed, 8 Aug 2001 10:25:33 +0200 From: "Soeren Laursen" To: , Ian Date: Wed, 8 Aug 2001 10:25:44 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: HELP can't boot Reply-to: soeren.laursen@scrooge.dk Message-ID: <3B7113A8.1719.52C999@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id f788PIV21984 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You need (as I know) to use irix to prepare the disk. But read the following links: http://black.hole.org/indy-boot.html http://foobazco.org/~wesolows/Install-HOWTO.html http://www.stafwag.f2s.com/indy/index.php?lang=eng Søren, > OK I'm having some problems here. > > I recently received an SGI Indy (complete with all hardware except disk) > and I installed a blank 1-GB scsi disk (no disk errors reported on bootup) > but without sash I cannot netboot linux. > > My question is this: How can I netboot linux (using bootp, tftp, and nfs, > all confirmed working)? I the kernel and the hardhat kit, but I can't get > the Indy to load the kernel. > > I have no IRIX kits available, nor a CD-writer (although I have > access to a CD-writer if needed). PLEASE help! > > Thanks in advance! > > -- > Ian Cooper > ian@wpi.edu From owner-linux-mips@oss.sgi.com Wed Aug 8 01:45:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f788jeJ24581 for linux-mips-outgoing; Wed, 8 Aug 2001 01:45:40 -0700 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 f788jdV24578 for ; Wed, 8 Aug 2001 01:45:39 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15UOy8-0005ng-00; Wed, 08 Aug 2001 10:45:36 +0200 Date: Wed, 8 Aug 2001 10:45:36 +0200 From: Guido Guenther To: Soeren Laursen Cc: linux-mips@oss.sgi.com, Ian Subject: Re: HELP can't boot Message-ID: <20010808104536.A21775@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Soeren Laursen , linux-mips@oss.sgi.com, Ian References: <3B7113A8.1719.52C999@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7113A8.1719.52C999@localhost>; from soeren.laursen@scrooge.dk on Wed, Aug 08, 2001 at 10:25:44AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 10:25:44AM +0200, Soeren Laursen wrote: > You need (as I know) to use irix to prepare the disk. No need for Irix. Linux fdisk can handle sgi disklkabels since quiet some time now. -- Guido From owner-linux-mips@oss.sgi.com Wed Aug 8 03:19:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78AJEX03930 for linux-mips-outgoing; Wed, 8 Aug 2001 03:19:14 -0700 Received: from dea.waldorf-gmbh.de (u-180-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78AJ7V03921 for ; Wed, 8 Aug 2001 03:19:07 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f78AH6902453; Wed, 8 Aug 2001 12:17:06 +0200 Date: Wed, 8 Aug 2001 12:17:06 +0200 From: Ralf Baechle To: "J. Scott Kasten" Cc: Brandon Barker , "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010808121706.A602@bacchus.dhis.org> References: <01080623471400.01828@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsk@tetracon-eng.net on Tue, Aug 07, 2001 at 08:45:17PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Aug 07, 2001 at 08:45:17PM -0400, J. Scott Kasten wrote: > Well, it's kind of both. The R4000 and up are 64 bit CPU's capable of > running either 32 or 64 bit code. The MIPS address space is a little > wierd such that you can kinda munge 32 and 64 bit code togeather under the > right circumstances. Right circumstances = almost always. Actually Linux makes sure that it's indeed always. > Some of the old hands here could tell you better how Irix behaves on those > boxes. I know you can compile code with 64 bit int and pointers and it > will run on those boxes under Irix, but there is a little more to it than > that. That's not supported on all systems. An Indy for example is limited to 128mb RAM as shipped by SGI (256 with aftermarket parts). There is no point in supporting 64-bit address space on such a system and so SGI doesn't support only N32. > I've used both linux and Irix on the Indy. Quite frankly, I would > consider getting a second HD if cheep enough so that you could keep both > around. (Note: don't put 2 high RPM drives in the Indy, or we are talking > melt down of your pretty blue toy...) External drives work just fine and can be hidden where their sound isn't so annoying. > I've found much to like in Irix in addition to the flexibility of Linux. Yep and they co-exist nicely. Ralf From owner-linux-mips@oss.sgi.com Wed Aug 8 03:25:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78AP0T04407 for linux-mips-outgoing; Wed, 8 Aug 2001 03:25:00 -0700 Received: from animal.pace.co.uk (gateway.pace.co.uk [195.44.197.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78AOwV04401 for ; Wed, 8 Aug 2001 03:24:59 -0700 Received: from exchange1.cam.pace.co.uk (exchange1.cam.pace.co.uk [136.170.131.80]) by animal.pace.co.uk (8.10.2/8.10.2) with ESMTP id f78AOqQ23131 for ; Wed, 8 Aug 2001 11:24:52 +0100 Received: by exchange1.cam.pace.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Aug 2001 11:24:52 +0100 Message-ID: <54045BFDAD47D5118A850002A5095CC30AC56D@exchange1.cam.pace.co.uk> From: Phil Thompson To: "'linux-mips@oss.sgi.com'" Subject: Patch for i8259.c Date: Wed, 8 Aug 2001 11:24:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11FF4.5BD8F130" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11FF4.5BD8F130 Content-Type: text/plain; charset="iso-8859-1" Attached is a patch for i8259.c which fixes a problem where irq2 is setup before the irq_desc array is initialised. Phil ------_=_NextPart_000_01C11FF4.5BD8F130 Content-Type: application/octet-stream; name="i8259.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i8259.c.patch" --- i8259.c.orig Wed Aug 8 10:52:48 2001=0A= +++ i8259.c Wed Aug 8 10:53:04 2001=0A= @@ -295,7 +295,6 @@=0A= =0A= request_resource(&ioport_resource, &pic1_io_resource);=0A= request_resource(&ioport_resource, &pic2_io_resource);=0A= - setup_irq(2, &irq2);=0A= =0A= init_8259A(0);=0A= =0A= @@ -305,4 +304,6 @@=0A= irq_desc[i].depth =3D 1;=0A= irq_desc[i].handler =3D &i8259A_irq_type;=0A= }=0A= +=0A= + setup_irq(2, &irq2);=0A= }=0A= ------_=_NextPart_000_01C11FF4.5BD8F130-- From owner-linux-mips@oss.sgi.com Wed Aug 8 05:59:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78CxJ925563 for linux-mips-outgoing; Wed, 8 Aug 2001 05:59:19 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78CxIV25559 for ; Wed, 8 Aug 2001 05:59:18 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.0.Beta17/8.12.0.Beta17) with ESMTP id f78CxFFd001878; Wed, 8 Aug 2001 08:59:15 -0400 (EDT) Date: Wed, 8 Aug 2001 08:59:15 -0400 (EDT) From: Ian To: Guido Guenther cc: Soeren Laursen , Subject: Re: HELP can't boot In-Reply-To: <20010808104536.A21775@gandalf.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I was in the middle of a HardHat install, and fdisk was able to partition the disks. The problem is that I deleted all of the partitions on the original disk, including sda9 and sda11, which store the SGI sash bootloader and associated files. Without the bootloader, the system is inoperable. I did not realize that those partitions contained it at that time. On Wed, 8 Aug 2001, Guido Guenther wrote: > On Wed, Aug 08, 2001 at 10:25:44AM +0200, Soeren Laursen wrote: > > You need (as I know) to use irix to prepare the disk. > No need for Irix. Linux fdisk can handle sgi disklkabels since quiet > some time now. > -- Guido > -- Ian Cooper ian@wpi.edu From owner-linux-mips@oss.sgi.com Wed Aug 8 06:25:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78DPRP30005 for linux-mips-outgoing; Wed, 8 Aug 2001 06:25:27 -0700 Received: from dea.waldorf-gmbh.de (u-168-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.168]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78DP9V29964 for ; Wed, 8 Aug 2001 06:25:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f78DN9d03359; Wed, 8 Aug 2001 15:23:09 +0200 Date: Wed, 8 Aug 2001 15:23:09 +0200 From: Ralf Baechle To: Phil Thompson Cc: "'linux-mips@oss.sgi.com'" Subject: Re: Patch for i8259.c Message-ID: <20010808152309.A3264@bacchus.dhis.org> References: <54045BFDAD47D5118A850002A5095CC30AC56D@exchange1.cam.pace.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: <54045BFDAD47D5118A850002A5095CC30AC56D@exchange1.cam.pace.co.uk>; from Phil.Thompson@pace.co.uk on Wed, Aug 08, 2001 at 11:24:51AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 11:24:51AM +0100, Phil Thompson wrote: > Attached is a patch for i8259.c which fixes a problem where irq2 is setup > before the irq_desc array is initialised. Thanks, applied! Ralf From owner-linux-mips@oss.sgi.com Wed Aug 8 06:42:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78DgpM32376 for linux-mips-outgoing; Wed, 8 Aug 2001 06:42:51 -0700 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 f78DgnV32369 for ; Wed, 8 Aug 2001 06:42:49 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15UTbi-0006a6-00; Wed, 08 Aug 2001 15:42:46 +0200 Date: Wed, 8 Aug 2001 15:42:46 +0200 From: Guido Guenther To: Ian Cc: Soeren Laursen , linux-mips Subject: Re: HELP can't boot Message-ID: <20010808154246.A25205@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Ian , Soeren Laursen , linux-mips References: <20010808104536.A21775@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 08:59:15AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 08:59:15AM -0400, Ian wrote: > I was in the middle of a HardHat install, and fdisk was able to partition > the disks. The problem is that I deleted all of the partitions on the > original disk, including sda9 and sda11, which store the SGI sash > bootloader and associated files. Without the bootloader, the system is > inoperable. I did not realize that those partitions contained it at that > time. You simply need to recreate a sgi partition table which is no problem with a current fdisk. That's all you need to make linux bootable from harddisk. This is kind of off-topic but I'd recommend switching to s.th. more recent than hardhat like debian or the rpms by H.J Lu on oss. Hardhat is way out of date. -- Guido From owner-linux-mips@oss.sgi.com Wed Aug 8 06:55:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78DttC02020 for linux-mips-outgoing; Wed, 8 Aug 2001 06:55:55 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78DtsV02014 for ; Wed, 8 Aug 2001 06:55:54 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id GAA18627; Wed, 8 Aug 2001 06:53:06 -0700 (PDT) Subject: Re: PATCH: Clean up Linux/mips. From: Eric Christopher To: "H . J . Lu" Cc: gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com In-Reply-To: <20010807084236.A5550@lucon.org> References: <20010807084236.A5550@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 08 Aug 2001 14:51:45 +0100 Message-Id: <997278707.1290.41.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ok, with one question: > * config/mips/little.h: New. Generic little endian mips > targets. Did you convert the other *el ports to use this? It doesn't look like it. -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Wed Aug 8 07:17:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EHIg04956 for linux-mips-outgoing; Wed, 8 Aug 2001 07:17:18 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EHHV04951 for ; Wed, 8 Aug 2001 07:17:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id A0A05125C3; Wed, 8 Aug 2001 07:17:16 -0700 (PDT) Date: Wed, 8 Aug 2001 07:17:16 -0700 From: "H . J . Lu" To: Eric Christopher Cc: gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808071716.A26704@lucon.org> References: <20010807084236.A5550@lucon.org> <997278707.1290.41.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997278707.1290.41.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Wed, Aug 08, 2001 at 02:51:45PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 02:51:45PM +0100, Eric Christopher wrote: > Ok, with one question: > > > * config/mips/little.h: New. Generic little endian mips > > targets. > > Did you convert the other *el ports to use this? It doesn't look like > it. No. I will let their maintainers decide what to do. Personally, I think they should use it :-(. But it may require additional changes. H.J. From owner-linux-mips@oss.sgi.com Wed Aug 8 07:20:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EKr005501 for linux-mips-outgoing; Wed, 8 Aug 2001 07:20:53 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EKqV05497 for ; Wed, 8 Aug 2001 07:20:52 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA20661; Wed, 8 Aug 2001 07:20:48 -0700 (PDT) Subject: Re: PATCH: Clean up Linux/mips. From: Eric Christopher To: "H . J . Lu" Cc: gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com In-Reply-To: <20010808071716.A26704@lucon.org> References: <20010807084236.A5550@lucon.org> <997278707.1290.41.camel@ghostwheel.cygnus.com> <20010808071716.A26704@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 08 Aug 2001 15:19:28 +0100 Message-Id: <997280370.1290.43.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > No. I will let their maintainers decide what to do. Personally, I think they > should use it :-(. But it may require additional changes. > *sigh* That'd be me then. Ok. Make sure your changelog entry states that mipsel*-linux-* is the only one using it then. Thanks. -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Wed Aug 8 07:35:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EZCM07073 for linux-mips-outgoing; Wed, 8 Aug 2001 07:35:12 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EZBV07056 for ; Wed, 8 Aug 2001 07:35:11 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D07D0125C3; Wed, 8 Aug 2001 07:35:09 -0700 (PDT) Date: Wed, 8 Aug 2001 07:35:09 -0700 From: "H . J . Lu" To: Eric Christopher , mark@codesourcery.com Cc: gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808073509.A26983@lucon.org> References: <20010807084236.A5550@lucon.org> <997278707.1290.41.camel@ghostwheel.cygnus.com> <20010808071716.A26704@lucon.org> <997280370.1290.43.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997280370.1290.43.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Wed, Aug 08, 2001 at 03:19:28PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 03:19:28PM +0100, Eric Christopher wrote: > > > > > No. I will let their maintainers decide what to do. Personally, I think they > > should use it :-(. But it may require additional changes. > > > > *sigh* That'd be me then. Ok. Make sure your changelog entry states > that mipsel*-linux-* is the only one using it then. > I changed it to * config/mips/little.h: New. Generic little endian mips targets. Only mips*-*-linux* is converted to use it so far. BTW, let me know if it is ok to check in. Also, I'd like to check it into gcc 3.0.1 if it is approved for the trunk. Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Aug 8 07:39:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Edab07735 for linux-mips-outgoing; Wed, 8 Aug 2001 07:39:36 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EdZV07730 for ; Wed, 8 Aug 2001 07:39:35 -0700 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA22514; Wed, 8 Aug 2001 07:39:28 -0700 (PDT) Subject: Re: PATCH: Clean up Linux/mips. From: Eric Christopher To: "H . J . Lu" Cc: mark@codesourcery.com, gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com In-Reply-To: <20010808073509.A26983@lucon.org> References: <20010807084236.A5550@lucon.org> <997278707.1290.41.camel@ghostwheel.cygnus.com> <20010808071716.A26704@lucon.org> <997280370.1290.43.camel@ghostwheel.cygnus.com> <20010808073509.A26983@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.12 (Preview Release) Date: 08 Aug 2001 15:38:08 +0100 Message-Id: <997281490.1290.49.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > BTW, let me know if it is ok to check in. Also, I'd like to check it > into gcc 3.0.1 if it is approved for the trunk. > Quick question: You said you tested, but I wanted to verify that you were able to bootstrap with no regressions? If so, then it is approved for the trunk. Mark will need to approve for the branch. -eric -- Look out behind you! From owner-linux-mips@oss.sgi.com Wed Aug 8 07:46:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EkTu08747 for linux-mips-outgoing; Wed, 8 Aug 2001 07:46:29 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EkRV08742 for ; Wed, 8 Aug 2001 07:46:27 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.0.Beta17/8.12.0.Beta17) with ESMTP id f78EkOFd005564; Wed, 8 Aug 2001 10:46:24 -0400 (EDT) Date: Wed, 8 Aug 2001 10:46:24 -0400 (EDT) From: Ian To: Guido Guenther cc: Soeren Laursen , linux-mips Subject: Re: HELP can't boot In-Reply-To: <20010808154246.A25205@gandalf.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > You simply need to recreate a sgi partition table which is no problem > with a current fdisk. That's all you need to make linux bootable from > harddisk. Right. But how to I get to that point? There is NO bootloader? I have no Irix 6.x media available to restore those partitions. > This is kind of off-topic but I'd recommend switching to s.th. more > recent than hardhat like debian or the rpms by H.J Lu on oss. Hardhat is > way out of date. I was planning to use HardHat as a basis to build a custom LFS (http://www.linuxfromscrtach.org) system from. It would be sufficient. -- Ian Cooper ian@wpi.edu From owner-linux-mips@oss.sgi.com Wed Aug 8 07:47:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Elke08990 for linux-mips-outgoing; Wed, 8 Aug 2001 07:47:46 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78EleV08972 for ; Wed, 8 Aug 2001 07:47:40 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id A64D4125C3; Wed, 8 Aug 2001 07:47:38 -0700 (PDT) Date: Wed, 8 Aug 2001 07:47:38 -0700 From: "H . J . Lu" To: Eric Christopher Cc: mark@codesourcery.com, gcc-patches@gcc.gnu.org, linux-mips@oss.sgi.com Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808074738.B26983@lucon.org> References: <20010807084236.A5550@lucon.org> <997278707.1290.41.camel@ghostwheel.cygnus.com> <20010808071716.A26704@lucon.org> <997280370.1290.43.camel@ghostwheel.cygnus.com> <20010808073509.A26983@lucon.org> <997281490.1290.49.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <997281490.1290.49.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Wed, Aug 08, 2001 at 03:38:08PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 03:38:08PM +0100, Eric Christopher wrote: > > > > > BTW, let me know if it is ok to check in. Also, I'd like to check it > > into gcc 3.0.1 if it is approved for the trunk. > > > > Quick question: You said you tested, but I wanted to verify that you > were able to bootstrap with no regressions? If so, then it is approved Well, it is my first try of gcc 3.0/3.1 on Linux/mips. I also have to disable libgcj since it is not supported. I couldn't find any previous gcc 3.0/3.1 testsuite results for Linux/mips. In any case, I am enclosing mine here. It has more failures than it should have since my hardware/kernel is flaky. > for the trunk. Mark will need to approve for the branch. > H.J. ----- FAIL: 21_strings/append.cc execution test FAIL: 21_strings/ctor_copy_dtor.cc execution test FAIL: 21_strings/element_access.cc execution test FAIL: 21_strings/insert.cc execution test FAIL: 21_strings/substr.cc execution test FAIL: 22_locale/ctor_copy_dtor.cc execution test FAIL: 23_containers/bitset_members.cc execution test FAIL: 23_containers/vector_element_access.cc execution test FAIL: 27_io/filebuf.cc execution test FAIL: 27_io/filebuf_members.cc execution test FAIL: 27_io/ifstream_members.cc execution test FAIL: 27_io/ios_members.cc execution test FAIL: 27_io/istream_extractor_other.cc execution test FAIL: 27_io/istream_seeks.cc execution test FAIL: 27_io/istream_unformatted.cc execution test FAIL: 27_io/ostream_inserter_other.cc execution test FAIL: gcc.c-torture/compile/20001226-1.c, -O0 FAIL: gcc.c-torture/compile/20001226-1.c, -O2 FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -g FAIL: gcc.c-torture/compile/20001226-1.c, -Os FAIL: gcc.c-torture/compile/920501-12.c, -O1 FAIL: gcc.c-torture/compile/920501-12.c, -O2 FAIL: gcc.c-torture/compile/920501-12.c, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/compile/920501-12.c, -O3 -g FAIL: gcc.c-torture/compile/920501-12.c, -Os FAIL: gcc.c-torture/execute/20010122-1.c execution, -O0 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O1 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O2 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/20010122-1.c execution, -Os FAIL: gcc.c-torture/execute/921208-2.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/921208-2.c compilation, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/921208-2.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/921208-2.c compilation, -O3 -g FAIL: gcc.c-torture/execute/930106-1.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/930106-1.c compilation, -O3 -g FAIL: gcc.dg/cpp/assert_trad1.c (test for excess errors) FAIL: gcc.dg/cpp/assert_trad2.c (test for excess errors) FAIL: gcc.dg/cpp/assert_trad3.c (test for excess errors) FAIL: gcc.dg/cpp/defined_trad.c (test for excess errors) FAIL: gcc.dg/cpp/hash2.c (test for excess errors) FAIL: gcc.dg/cpp/tr-define.c (test for excess errors) FAIL: gcc.dg/cpp/tr-direct.c (test for excess errors) FAIL: gcc.dg/cpp/tr-paste.c (test for excess errors) FAIL: gcc.dg/cpp/tr-str.c (test for excess errors) FAIL: gcc.dg/cpp/ucs.c (test for warnings, line 24) FAIL: gcc.dg/cpp/ucs.c (test for excess errors) FAIL: gcc.dg/asm-fs-1.c scan-assembler-not \*_bar FAIL: gcc.dg/asm-fs-1.c scan-assembler-not \*_baz FAIL: gcc.dg/ext-glob.c (test for excess errors) FAIL: gcc.dg/special/gcsec-1.c (test for excess errors) FAIL: g++.abi/cxa_vec.C Execution test FAIL: g++.abi/vbase1.C (test for excess errors) FAIL: g++.eh/fntry1.C Execution test FAIL: g++.eh/new2.C Execution test FAIL: g++.eh/spec2.C Execution test FAIL: g++.eh/spec3.C Execution test FAIL: g++.jason/groff1.C (test for excess errors) FAIL: g++.jason/ref12.C (test for excess errors) FAIL: g++.mike/dyncast2.C Execution test FAIL: g++.mike/eh10.C (test for excess errors) FAIL: g++.mike/eh16.C Execution test FAIL: g++.mike/eh17.C Execution test FAIL: g++.mike/eh23.C Execution test FAIL: g++.mike/eh33.C Execution test FAIL: g++.mike/eh39.C Execution test FAIL: g++.mike/eh40.C Execution test FAIL: g++.mike/eh41.C Execution test FAIL: g++.mike/eh50.C Execution test FAIL: g++.mike/eh51.C Execution test FAIL: g++.mike/thunk3.C (test for excess errors) FAIL: g++.ns/template4.C (test for excess errors) FAIL: g++.other/crash18.C caused compiler crash FAIL: g++.other/enum5.C (test for excess errors) FAIL: g++.other/incomplete.C incomplete (test for errors, line 14) FAIL: g++.other/incomplete.C incomplete (test for errors, line 15) FAIL: g++.other/incomplete.C incomplete (test for errors, line 16) FAIL: g++.robertl/eh990323-1.C Execution test FAIL: g++.robertl/eh990323-5.C Execution test FAIL: g77.f-torture/compile/19990826-3.f, -O0 FAIL: g77.f-torture/execute/20010430.f execution, -O2 FAIL: g77.f-torture/execute/20010430.f execution, -O3 -fomit-frame-pointer FAIL: g77.f-torture/execute/20010430.f execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: g77.f-torture/execute/20010430.f execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: g77.f-torture/execute/20010430.f execution, -O3 -g FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -O0 FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -O1 FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -O2 FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -O3 -fomit-frame-pointer FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -O3 -g FAIL: g77.f-torture/execute/intrinsic-vax-cd.f compilation, -Os FAIL: g77.f-torture/execute/intrinsic77.f compilation, -O0 FAIL: g77.f-torture/execute/intrinsic77.f compilation, -O1 FAIL: g77.f-torture/execute/intrinsic77.f compilation, -O2 FAIL: g77.f-torture/execute/intrinsic77.f compilation, -O3 -fomit-frame-pointer FAIL: g77.f-torture/execute/intrinsic77.f compilation, -O3 -g FAIL: g77.f-torture/execute/intrinsic77.f compilation, -Os FAIL: objc/execute/IMP.m compilation, -O FAIL: objc/execute/_cmd.m compilation, -O FAIL: objc/execute/accessing_ivars.m compilation, -O FAIL: objc/execute/bf-1.m compilation, -O FAIL: objc/execute/bf-10.m compilation, -O FAIL: objc/execute/bf-11.m compilation, -O FAIL: objc/execute/bf-12.m compilation, -O FAIL: objc/execute/bf-13.m compilation, -O FAIL: objc/execute/bf-14.m compilation, -O FAIL: objc/execute/bf-15.m compilation, -O FAIL: objc/execute/bf-16.m compilation, -O FAIL: objc/execute/bf-17.m compilation, -O FAIL: objc/execute/bf-18.m compilation, -O FAIL: objc/execute/bf-19.m compilation, -O FAIL: objc/execute/bf-2.m compilation, -O FAIL: objc/execute/bf-20.m compilation, -O FAIL: objc/execute/bf-3.m compilation, -O FAIL: objc/execute/bf-4.m compilation, -O FAIL: objc/execute/bf-5.m compilation, -O FAIL: objc/execute/bf-6.m compilation, -O FAIL: objc/execute/bf-7.m compilation, -O FAIL: objc/execute/bf-8.m compilation, -O FAIL: objc/execute/bf-9.m compilation, -O FAIL: objc/execute/bycopy-1.m compilation, -O FAIL: objc/execute/bycopy-2.m compilation, -O FAIL: objc/execute/bycopy-3.m compilation, -O FAIL: objc/execute/class-1.m compilation, -O FAIL: objc/execute/class-10.m compilation, -O FAIL: objc/execute/class-11.m compilation, -O FAIL: objc/execute/class-12.m compilation, -O FAIL: objc/execute/class-13.m compilation, -O FAIL: objc/execute/class-14.m compilation, -O FAIL: objc/execute/class-2.m compilation, -O FAIL: objc/execute/class-3.m compilation, -O FAIL: objc/execute/class-4.m compilation, -O FAIL: objc/execute/class-5.m compilation, -O FAIL: objc/execute/class-6.m compilation, -O FAIL: objc/execute/class-7.m compilation, -O FAIL: objc/execute/class-8.m compilation, -O FAIL: objc/execute/class-9.m compilation, -O FAIL: objc/execute/compatibility_alias.m compilation, -O FAIL: objc/execute/encode-1.m compilation, -O FAIL: objc/execute/fdecl.m compilation, -O FAIL: objc/execute/formal_protocol-1.m compilation, -O FAIL: objc/execute/formal_protocol-2.m compilation, -O FAIL: objc/execute/formal_protocol-3.m compilation, -O FAIL: objc/execute/formal_protocol-4.m compilation, -O FAIL: objc/execute/formal_protocol-5.m compilation, -O FAIL: objc/execute/formal_protocol-6.m compilation, -O FAIL: objc/execute/formal_protocol-7.m compilation, -O FAIL: objc/execute/initialize.m compilation, -O FAIL: objc/execute/load-2.m compilation, -O FAIL: objc/execute/load-3.m compilation, -O FAIL: objc/execute/load.m compilation, -O FAIL: objc/execute/many_args_method.m compilation, -O FAIL: objc/execute/nested-2.m compilation, -O FAIL: objc/execute/nested-3.m compilation, -O FAIL: objc/execute/no_clash.m compilation, -O FAIL: objc/execute/np-1.m compilation, -O FAIL: objc/execute/np-2.m compilation, -O FAIL: objc/execute/object_is_class.m compilation, -O FAIL: objc/execute/object_is_meta_class.m compilation, -O FAIL: objc/execute/paste.m compilation, -O FAIL: objc/execute/private.m compilation, -O FAIL: objc/execute/protocol.m compilation, -O FAIL: objc/execute/redefining_self.m compilation, -O FAIL: objc/execute/root_methods.m compilation, -O FAIL: objc/execute/selector-1.m compilation, -O FAIL: objc/execute/static-1.m compilation, -O FAIL: objc/execute/static-2.m compilation, -O FAIL: objc/execute/string1.m compilation, -O FAIL: objc/execute/string2.m compilation, -O FAIL: objc/execute/string3.m compilation, -O FAIL: objc/execute/string4.m compilation, -O FAIL: objc/execute/va_method.m compilation, -O FAIL: objc.dg/class-1.m (test for excess errors) FAIL: objc.dg/class-2.m (test for excess errors) FAIL: objc.dg/const-str-1.m (test for excess errors) FAIL: objc.dg/local-decl-1.m (test for excess errors) FAIL: objc.dg/method-1.m (test for excess errors) FAIL: objc.dg/proto-hier-1.m (test for excess errors) From owner-linux-mips@oss.sgi.com Wed Aug 8 07:58:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78EwSH10704 for linux-mips-outgoing; Wed, 8 Aug 2001 07:58:28 -0700 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 f78EwQV10693 for ; Wed, 8 Aug 2001 07:58:26 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15UUmv-0003jj-00; Wed, 08 Aug 2001 16:58:25 +0200 Date: Wed, 8 Aug 2001 16:58:25 +0200 From: Guido Guenther To: linux-mips Subject: Re: HELP can't boot Message-ID: <20010808165825.B25627@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips References: <20010808154246.A25205@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 10:46:24AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 10:46:24AM -0400, Ian wrote: > > You simply need to recreate a sgi partition table which is no problem > > with a current fdisk. That's all you need to make linux bootable from > > harddisk. > > Right. But how to I get to that point? There is NO bootloader? I have > no Irix 6.x media available to restore those partitions. E.g. use the base system at: ftp://ftp.uni-mainz.de/pub/Linux/debian-local/mips/ with a kernel from: ftp://ftp.rfc822.org/pub/local/debian-mips/kernel or the debian "bootdisks" consisting of a small nfs-root and kernel at: http://honk.physik.uni-konstanz.de/linux-mips/debian/bootdisks/ these contain fdisk & dvhtool, so hopefully everything to get your disk "back into shape". -- Guido From owner-linux-mips@oss.sgi.com Wed Aug 8 08:02:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78F2lf11410 for linux-mips-outgoing; Wed, 8 Aug 2001 08:02:47 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78F2gV11392; Wed, 8 Aug 2001 08:02:42 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23865; Wed, 8 Aug 2001 11:02:44 -0400 Date: Wed, 8 Aug 2001 11:02:44 -0400 From: "J. Scott Kasten" To: Ralf Baechle cc: Brandon Barker , "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? In-Reply-To: <20010808121706.A602@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 8 Aug 2001, Ralf Baechle wrote: > On Tue, Aug 07, 2001 at 08:45:17PM -0400, J. Scott Kasten wrote: > Right circumstances = almost always. Actually Linux makes sure that it's > indeed always. As long as our data doesn't make sparse use of the VM address space, yes... I always have to think of the worst case. ;-) > > Some of the old hands here could tell you better how Irix behaves on those > > boxes. I know you can compile code with 64 bit int and pointers and it > > will run on those boxes under Irix, but there is a little more to it than > > that. > > That's not supported on all systems. An Indy for example is limited to > 128mb RAM as shipped by SGI (256 with aftermarket parts). There is no > point in supporting 64-bit address space on such a system and so SGI doesn't > support only N32. Well, that actually brings to mind a nagging question I've had in regards to just what N32 is. Here's an example app and creative use of gcc: /* Note: stdio.h deliberately left out to bypass some syntax issues. */ int main(int argc, char *agv[]) { int i, *j; printf( "sizeof(int) = %1d, sizeof(*) = %1d\n", sizeof(i), sizeof(j) ); j = &i; *j = 10; i++; printf( "Result: %1d\n", (int) *j ); return (0); } Compile: gcc -mips3 -mint64 test.c -o test The file command says: test: ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1 Run: sizeof(int) = 8, sizeof(*) = 8 Result: 11 If we look at the assembly, we see a sign extended 64 bit load, and a 64 bit add. So we are indeed generating 64 bit instructions, at least in some cases. dli $3,0xa # 10 daddu $3,$2,1 Does N32 legitimately allow 64 bit instructions, or is this an example of code that I've truely "munged" togeather? It clearly works, at least in this trivial case. I'm just trying to solidify my understanding of what Irix is supposed to do. From owner-linux-mips@oss.sgi.com Wed Aug 8 08:04:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78F4ng11712 for linux-mips-outgoing; Wed, 8 Aug 2001 08:04:49 -0700 Received: from gandalf.codesourcery.com (227.dsl6660148.rstatic.surewest.net [66.60.148.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78F4mV11705 for ; Wed, 8 Aug 2001 08:04:48 -0700 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.9.3/8.9.3) with ESMTP id IAA01008; Wed, 8 Aug 2001 08:04:42 -0700 Date: Wed, 08 Aug 2001 08:04:41 -0700 From: Mark Mitchell To: Eric Christopher , "H . J . Lu" cc: "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <11900000.997283081@gandalf.codesourcery.com> In-Reply-To: <997281490.1290.49.camel@ghostwheel.cygnus.com> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --On Wednesday, August 08, 2001 03:38:08 PM +0100 Eric Christopher wrote: > Quick question: You said you tested, but I wanted to verify that you > were able to bootstrap with no regressions? If so, then it is approved > for the trunk. Mark will need to approve for the branch. What incredibly critical problem does this solve? Recall that 3.0.1 is currently frozen, waiting only for some breakage in V3-land to get fixed, before we produce a release candidate. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From owner-linux-mips@oss.sgi.com Wed Aug 8 08:09:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78F91k12357 for linux-mips-outgoing; Wed, 8 Aug 2001 08:09:01 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78F90V12349 for ; Wed, 8 Aug 2001 08:09:00 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id C209A125C3; Wed, 8 Aug 2001 08:08:59 -0700 (PDT) Date: Wed, 8 Aug 2001 08:08:59 -0700 From: "H . J . Lu" To: Mark Mitchell Cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808080859.D26983@lucon.org> References: <997281490.1290.49.camel@ghostwheel.cygnus.com> <11900000.997283081@gandalf.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <11900000.997283081@gandalf.codesourcery.com>; from mark@codesourcery.com on Wed, Aug 08, 2001 at 08:04:41AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 08:04:41AM -0700, Mark Mitchell wrote: > > > --On Wednesday, August 08, 2001 03:38:08 PM +0100 Eric Christopher > wrote: > > > Quick question: You said you tested, but I wanted to verify that you > > were able to bootstrap with no regressions? If so, then it is approved > > for the trunk. Mark will need to approve for the branch. > > What incredibly critical problem does this solve? Recall that 3.0.1 > is currently frozen, waiting only for some breakage in V3-land to get > fixed, before we produce a release candidate. Have you seen reports on any Linux/mips targets at http://gcc.gnu.org/ml/gcc-testresults/ My goal is to make it appear one day. I'd like to see gcc 3.0.1 is at least partially supported on Linux/mips. H.J. From owner-linux-mips@oss.sgi.com Wed Aug 8 08:09:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78F9Kn12457 for linux-mips-outgoing; Wed, 8 Aug 2001 08:09:20 -0700 Received: from newsmtp2.atmel.com (newsmtp2.atmel.com [12.146.133.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78F9JV12454 for ; Wed, 8 Aug 2001 08:09:19 -0700 Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105]) by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA26923 for ; Wed, 8 Aug 2001 08:02:28 -0700 (PDT) Received: from mmc.atmel.com (mail [10.127.240.34]) by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA02634 for ; Wed, 8 Aug 2001 08:02:45 -0700 (PDT) Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163]) by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id LAA04986 for ; Wed, 8 Aug 2001 11:09:26 -0400 (EDT) Message-ID: <3B71649E.95BEEFCD@mmc.atmel.com> Date: Wed, 08 Aug 2001 11:11:10 -0500 From: Shuanglin Wang Reply-To: swang@mmc.atmel.com Organization: ATMEL MMC X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: How to build a kernel for the malta board? Content-Type: multipart/alternative; boundary="------------AA719F7834B49A898A20BAFF" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --------------AA719F7834B49A898A20BAFF Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi everyone, I want to compile Linux Kernel (2.4.3) for a Malta board. I downloaded both MIPS Linux distribution and cross-compiler tools. Now, the problem is how to configure the Linux kernel for malta boards. Thanks in advance. -- Shuanglin Wang Atmel Multimedia & Communications 3800 Gateway Centre, Suite 311 Morrisville, NC 27560 --------------AA719F7834B49A898A20BAFF Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit Hi everyone,

I want to compile Linux Kernel (2.4.3) for a Malta board.  I downloaded both MIPS Linux distribution and cross-compiler tools. Now, the problem is how to configure the Linux kernel  for malta boards.

Thanks in advance. 

-- 
Shuanglin Wang
Atmel Multimedia & Communications
3800 Gateway Centre, Suite 311
Morrisville, NC 27560
  --------------AA719F7834B49A898A20BAFF-- From owner-linux-mips@oss.sgi.com Wed Aug 8 08:19:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78FJIP13585 for linux-mips-outgoing; Wed, 8 Aug 2001 08:19:18 -0700 Received: from dea.waldorf-gmbh.de (u-121-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FJCV13571 for ; Wed, 8 Aug 2001 08:19:13 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f78FI6J04205; Wed, 8 Aug 2001 17:18:06 +0200 Date: Wed, 8 Aug 2001 17:18:06 +0200 From: Ralf Baechle To: "J. Scott Kasten" Cc: Brandon Barker , "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010808171806.A4105@bacchus.dhis.org> References: <20010808121706.A602@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsk@tetracon-eng.net on Wed, Aug 08, 2001 at 11:02:44AM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote: > gcc -mips3 -mint64 test.c -o test > > The file command says: > > test: ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1 > > Run: > > sizeof(int) = 8, sizeof(*) = 8 > Result: 11 > > If we look at the assembly, we see a sign extended 64 bit load, and a 64 > bit add. So we are indeed generating 64 bit instructions, at least in > some cases. > > dli $3,0xa # 10 > > daddu $3,$2,1 > > Does N32 legitimately allow 64 bit instructions, Yes. Hey, that's the 80% of the purpose of N32! > or is this an example of code that I've truely "munged" togeather? Doubleplusyesyesyes :-) -mint64 is not valid for any MIPS code model. Gas is royally b0rken for N32. If you really want to read about N32 get the respective docs from techpubs.sgi.com. Ralf From owner-linux-mips@oss.sgi.com Wed Aug 8 08:32:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78FWCL15489 for linux-mips-outgoing; Wed, 8 Aug 2001 08:32:12 -0700 Received: from fe170.worldonline.dk (fe170.worldonline.dk [212.54.64.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FWBV15486 for ; Wed, 8 Aug 2001 08:32:11 -0700 Received: (qmail 12894 invoked by uid 0); 8 Aug 2001 15:31:18 -0000 Received: from 213.237.49.98.skovlyporten.dk (HELO tuxedo.skovlyporten.dk) (213.237.49.98) by fe170.worldonline.dk with SMTP; 8 Aug 2001 15:31:18 -0000 Received: by tuxedo.skovlyporten.dk (Postfix, from userid 501) id 218933D9B; Wed, 8 Aug 2001 17:31:58 +0200 (CEST) Date: Wed, 8 Aug 2001 17:31:58 +0200 From: Lars Munch Christensen To: Shuanglin Wang Cc: linux-mips@oss.sgi.com Subject: Re: How to build a kernel for the malta board? Message-ID: <20010808173157.B868@tuxedo.skovlyporten.dk> References: <3B71649E.95BEEFCD@mmc.atmel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B71649E.95BEEFCD@mmc.atmel.com>; from swang@mmc.atmel.com on Wed, Aug 08, 2001 at 11:11:10AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 11:11:10AM -0500, Shuanglin Wang wrote: > I want to compile Linux Kernel (2.4.3) for a Malta board. I downloaded > both MIPS Linux distribution and cross-compiler tools. Now, the problem > is how to configure the Linux kernel for malta boards. If you got the kernel from the MIPS ftp site, you will see a file called .config.malta in the root of the source tree. This is a good starting point for configuring the kernel for the Malta board. Regards -- Lars Munch From owner-linux-mips@oss.sgi.com Wed Aug 8 08:38:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Fcg016536 for linux-mips-outgoing; Wed, 8 Aug 2001 08:38:42 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FcdV16522 for ; Wed, 8 Aug 2001 08:38:40 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f78Fcc403143 for ; Wed, 8 Aug 2001 16:38:38 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id QAA05242 for ; Wed, 8 Aug 2001 16:38:37 +0100 (BST) Message-ID: <00bd01c12020$31041d00$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: Subject: Re: How to build a kernel for the malta board? Date: Wed, 8 Aug 2001 16:38: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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Shuanglin, This is what I did. Download the Linux kernel source from the MIPS ftp site and extract it on the development host: % tar -xzf linux-2.4.3.mips-src-01.00.tar.gz % cd linux-2.4.3 I patched this kernel to make the FPU emulator more reliable using patches from this list's archive. Setup the configuration file: % cp .config.malta .config % chmod +w .config For little endian mode, edit this file changing the line: # CONFIG_CPU_LITTLE_ENDIAN is not set to: CONFIG_CPU_LITTLE_ENDIAN=y Setup the make file: % chmod +w Makefile Edit this file changing the line: CROSS_COMPILE = to: CROSS_COMPILE = mipsel-linux- Build and install the kernel: % make oldconfig % make dep % make To use TFTP to boot the kernel: % mipsel-linux-objcopy -O srec vmlinux vmlinux.srec % cp vmlinux.srec /tftpboot/mipsel-2.4.3 Andrew Thornton From owner-linux-mips@oss.sgi.com Wed Aug 8 08:40:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Fe6L16826 for linux-mips-outgoing; Wed, 8 Aug 2001 08:40:06 -0700 Received: from gandalf.codesourcery.com (227.dsl6660148.rstatic.surewest.net [66.60.148.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78Fe5V16814 for ; Wed, 8 Aug 2001 08:40:06 -0700 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.9.3/8.9.3) with ESMTP id IAA01149; Wed, 8 Aug 2001 08:40:00 -0700 Date: Wed, 08 Aug 2001 08:39:59 -0700 From: Mark Mitchell To: "H . J . Lu" cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <17100000.997285199@gandalf.codesourcery.com> In-Reply-To: <20010808080859.D26983@lucon.org> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Have you seen reports on any Linux/mips targets at Sorry, that didn't answer my question. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From owner-linux-mips@oss.sgi.com Wed Aug 8 08:41:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78FfkC17147 for linux-mips-outgoing; Wed, 8 Aug 2001 08:41:46 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FfiV17138 for ; Wed, 8 Aug 2001 08:41:44 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id RAA189603 for ; Wed, 8 Aug 2001 17:41:42 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15UVSo-0001R1-00 for ; Wed, 08 Aug 2001 17:41:42 +0200 Date: Wed, 8 Aug 2001 17:41:42 +0200 To: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010808174142.F4452@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010808171806.A4105@bacchus.dhis.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote: > > > gcc -mips3 -mint64 test.c -o test > > > > The file command says: > > > > test: ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1 ^^^ I don't know how file detects this, but at least current CVS gas does not set the appropriate flag in the object file header. > > > > Run: > > > > sizeof(int) = 8, sizeof(*) = 8 ^ ^ This should be both 4, I assume this happened due to -mint64. > > Result: 11 > > > > If we look at the assembly, we see a sign extended 64 bit load, and a 64 > > bit add. So we are indeed generating 64 bit instructions, at least in > > some cases. > > > > dli $3,0xa # 10 To what does this dli get expanded? I'm interested in the output of objdump -d. [snip] > > or is this an example of code that I've truely "munged" togeather? > > Doubleplusyesyesyes :-) -mint64 is not valid for any MIPS code model. Gas > is royally b0rken for N32. WRT what? Thiemo From owner-linux-mips@oss.sgi.com Wed Aug 8 08:45:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Fjkp17983 for linux-mips-outgoing; Wed, 8 Aug 2001 08:45:46 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78FjjV17976 for ; Wed, 8 Aug 2001 08:45:45 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 46EE3125C3; Wed, 8 Aug 2001 08:45:44 -0700 (PDT) Date: Wed, 8 Aug 2001 08:45:44 -0700 From: "H . J . Lu" To: Mark Mitchell Cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808084544.A28287@lucon.org> References: <20010808080859.D26983@lucon.org> <17100000.997285199@gandalf.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <17100000.997285199@gandalf.codesourcery.com>; from mark@codesourcery.com on Wed, Aug 08, 2001 at 08:39:59AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 08:39:59AM -0700, Mark Mitchell wrote: > > Have you seen reports on any Linux/mips targets at > > Sorry, that didn't answer my question. I am trying to get gcc 3.x to work correctly on Linux/mips. I believe very very few people have done # ./configure # make bootstrap # make check successfully on linux/mips. In fact, I may be the only one. H.J. From owner-linux-mips@oss.sgi.com Wed Aug 8 08:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Fr9619219 for linux-mips-outgoing; Wed, 8 Aug 2001 08:53:09 -0700 Received: from gandalf.codesourcery.com (227.dsl6660148.rstatic.surewest.net [66.60.148.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78Fr7V19208 for ; Wed, 8 Aug 2001 08:53:08 -0700 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.9.3/8.9.3) with ESMTP id IAA01183; Wed, 8 Aug 2001 08:52:58 -0700 Date: Wed, 08 Aug 2001 08:52:58 -0700 From: Mark Mitchell To: "H . J . Lu" cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <35250000.997285978@gandalf.codesourcery.com> In-Reply-To: <20010808084544.A28287@lucon.org> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I am trying to get gcc 3.x to work correctly on Linux/mips. Sorry, that didn't answer my question either. You need to explain what problem your patch solves, in detail, and how it solves it, so that even I, not as smart as you, can understand it. I had an excellent professor in college who gave a lecture on the first day of every class to introduce his perspective. He said that many students think that their job is to learn as much as possible, but that's not it at all. Instead, he pointed out, the job of a student is to make it as easy as possible for the grader to give them an `A'. That means don't write in red pencil on both sides of a piece of paper torn from a spiral bound notebook -- LaTeX it. Don't just write code that works; include comments that make it obvious it works. Don't skip 10 obvious steps in the proof; the grader may not be as smart as you. I cannot match the flair with which the original lecture was delivered, but that was the idea. Here, I am the grader. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From owner-linux-mips@oss.sgi.com Wed Aug 8 09:09:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78G9PA21090 for linux-mips-outgoing; Wed, 8 Aug 2001 09:09:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78G9OV21087 for ; Wed, 8 Aug 2001 09:09:25 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D2C9C125C3; Wed, 8 Aug 2001 09:09:23 -0700 (PDT) Date: Wed, 8 Aug 2001 09:09:23 -0700 From: "H . J . Lu" To: Mark Mitchell Cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <20010808090923.A28678@lucon.org> References: <20010808084544.A28287@lucon.org> <35250000.997285978@gandalf.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35250000.997285978@gandalf.codesourcery.com>; from mark@codesourcery.com on Wed, Aug 08, 2001 at 08:52:58AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 08:52:58AM -0700, Mark Mitchell wrote: > > I am trying to get gcc 3.x to work correctly on Linux/mips. > > Sorry, that didn't answer my question either. > > You need to explain what problem your patch solves, in detail, and how > it solves it, so that even I, not as smart as you, can understand it. > Well, the mips config is a mess and Eric suggested me to clean it up at least for Linux/mips since I have been working on fixing the gcc 3.x for Linux/mips. I'd love to see Linux/mips be supported in gcc 3.0.1. But I am afraid I don't have the time to do more than what I have done so far. H.J. From owner-linux-mips@oss.sgi.com Wed Aug 8 09:12:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78GCkj21272 for linux-mips-outgoing; Wed, 8 Aug 2001 09:12:46 -0700 Received: from gandalf.codesourcery.com (227.dsl6660148.rstatic.surewest.net [66.60.148.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78GCjV21269 for ; Wed, 8 Aug 2001 09:12:45 -0700 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.9.3/8.9.3) with ESMTP id JAA01274; Wed, 8 Aug 2001 09:12:37 -0700 Date: Wed, 08 Aug 2001 09:12:36 -0700 From: Mark Mitchell To: "H . J . Lu" cc: Eric Christopher , "gcc-patches@gcc.gnu.org" , "linux-mips@oss.sgi.com" Subject: Re: PATCH: Clean up Linux/mips. Message-ID: <42150000.997287156@gandalf.codesourcery.com> In-Reply-To: <20010808090923.A28678@lucon.org> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Well, the mips config is a mess and Eric suggested me to clean it up > at least for Linux/mips since I have been working on fixing the gcc > 3.x for Linux/mips. I'd love to see Linux/mips be supported in gcc > 3.0.1. But I am afraid I don't have the time to do more than what I > have done so far. OK. It's not going to be in 3.0.1, then. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From owner-linux-mips@oss.sgi.com Wed Aug 8 09:13:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78GDmm21375 for linux-mips-outgoing; Wed, 8 Aug 2001 09:13:48 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78GDiV21371 for ; Wed, 8 Aug 2001 09:13:44 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 6091810CF; Wed, 8 Aug 2001 18:13:42 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5E1D53F24; Wed, 8 Aug 2001 17:43:51 +0200 (CEST) Date: Wed, 8 Aug 2001 17:43:51 +0200 From: Florian Lohoff To: Ian Cc: Guido Guenther , Soeren Laursen , linux-mips Subject: Re: HELP can't boot Message-ID: <20010808174351.C17694@paradigm.rfc822.org> References: <20010808154246.A25205@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 10:46:24AM -0400 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 10:46:24AM -0400, Ian wrote: > > > You simply need to recreate a sgi partition table which is no problem > > with a current fdisk. That's all you need to make linux bootable from > > harddisk. > > Right. But how to I get to that point? There is NO bootloader? I have > no Irix 6.x media available to restore those partitions. > tftp/nfs-root boot ? The prom is enough. > I was planning to use HardHat as a basis to build a custom LFS > (http://www.linuxfromscrtach.org) system from. It would be sufficient. Hardhat is VERY old and you will get really in trouble to get any current software integrated into the distribution. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Wed Aug 8 12:35:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78JZPj02675 for linux-mips-outgoing; Wed, 8 Aug 2001 12:35:25 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78JZOV02670 for ; Wed, 8 Aug 2001 12:35:24 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.0.Beta17/8.12.0.Beta17) with ESMTP id f78JZNFd003073; Wed, 8 Aug 2001 15:35:23 -0400 (EDT) Date: Wed, 8 Aug 2001 15:35:22 -0400 (EDT) From: Ian To: Florian Lohoff cc: Guido Guenther , Soeren Laursen , linux-mips Subject: Re: HELP can't boot In-Reply-To: <20010808174351.C17694@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > tftp/nfs-root boot ? The prom is enough. When I type "boot bootp():/tftpboot/kernel-hardhat" at the PROM command monitor, I get an error that it can't find Sash (the Irix [6.2] bootloader). Sash appears to be necessary to do a netboot. > Hardhat is VERY old and you will get really in trouble to get any > current software integrated into the distribution. HardHat will a sufficient base to build a new system on (i.e. LFS) from scratch. LFS is a program where you simply build a complete Linux system from source (current sources, including libraries and *everything*). However you need some kind of basic system to start with, and HardHat will do the trick (if I can get it to boot). -- Ian Cooper ian@wpi.edu From owner-linux-mips@oss.sgi.com Wed Aug 8 12:50:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Joet04261 for linux-mips-outgoing; Wed, 8 Aug 2001 12:50:40 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78JocV04257 for ; Wed, 8 Aug 2001 12:50:38 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id VAA189493 for ; Wed, 8 Aug 2001 21:50:37 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15UZLh-0004Hd-00 for ; Wed, 08 Aug 2001 21:50:37 +0200 Date: Wed, 8 Aug 2001 21:50:37 +0200 To: linux-mips Subject: Re: HELP can't boot Message-ID: <20010808215037.G4452@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ian wrote: > > tftp/nfs-root boot ? The prom is enough. > > When I type "boot bootp():/tftpboot/kernel-hardhat" at the PROM command ^ boot -f bootp():... Thiemo From owner-linux-mips@oss.sgi.com Wed Aug 8 13:13:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78KDGJ07410 for linux-mips-outgoing; Wed, 8 Aug 2001 13:13:16 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78KDDV07397 for ; Wed, 8 Aug 2001 13:13:13 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24834; Wed, 8 Aug 2001 16:12:39 -0400 Date: Wed, 8 Aug 2001 16:12:39 -0400 From: "J. Scott Kasten" To: Thiemo Seufer cc: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? In-Reply-To: <20010808174142.F4452@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 8 Aug 2001, Thiemo Seufer wrote: > Ralf Baechle wrote: > > On Wed, Aug 08, 2001 at 11:02:44AM -0400, J. Scott Kasten wrote: > > > > > gcc -mips3 -mint64 test.c -o test > > > > > > The file command says: > > > > > > test: ELF N32 MSB mips-3 dynamic executable (not stripped) MIPS - version 1 > ^^^ > I don't know how file detects this, but at least current CVS gas > does not set the appropriate flag in the object file header. Gas does not apply here. We're talking about gcc running under Irix with the native as and ld tools. I'm using gcc-2.91.66 (egcs-1.1.2), gcc-2.95.2, MipsPro 7.30 as and ld. > > > > > > Run: > > > > > > sizeof(int) = 8, sizeof(*) = 8 > ^ ^ > This should be both 4, I assume this happened due to -mint64. Not totally. -mips3 generates values of 4 and 8. The -mint64 takes it to 8 and 8. If I just invoke gcc with no -m flags, it does produce 4 and 4. > > > If we look at the assembly, we see a sign extended 64 bit load, and a 64 > > > bit add. So we are indeed generating 64 bit instructions, at least in > > > some cases. > > > > > > dli $3,0xa # 10 > > To what does this dli get expanded? I'm interested in the output of > objdump -d. test.S sd $2,40($fp) ld $2,40($fp) dli $3,0xa # 10 sd $3,0($2) ld $2,32($fp) daddu $3,$2,1 sd $3,32($fp) ld $2,40($fp) objdump -d 100012b0: ffc20028 sd $v0,40($s8) 100012b4: dfc20028 ld $v0,40($s8) 100012b8: 2403000a li $v1,10 100012bc: fc430000 sd $v1,0($v0) 100012c0: dfc20020 ld $v0,32($s8) 100012c4: 64430001 daddiu $v1,$v0,1 100012c8: ffc30020 sd $v1,32($s8) 100012cc: dfc20028 ld $v0,40($s8) Just for kicks, instead of *j = 10, which is trivial, I picked a true 64 bit constant: sd $2,40($fp) ld $2,40($fp) dli $3,0x807060504030201 sd $3,0($2) ld $2,32($fp) daddu $3,$2,1 sd $3,32($fp) ld $2,40($fp) 100012b0: ffc20028 sd $v0,40($s8) 100012b4: dfc20028 ld $v0,40($s8) 100012b8: 3c030807 lui $v1,0x807 100012bc: 34630605 ori $v1,$v1,0x605 100012c0: 00031c38 dsll $v1,$v1,0x10 100012c4: 34630403 ori $v1,$v1,0x403 100012c8: 00031c38 dsll $v1,$v1,0x10 100012cc: 34630201 ori $v1,$v1,0x201 100012d0: fc430000 sd $v1,0($v0) 100012d4: dfc20020 ld $v0,32($s8) 100012d8: 64430001 daddiu $v1,$v0,1 100012dc: ffc30020 sd $v1,32($s8) 100012e0: dfc20028 ld $v0,40($s8) Ouch that's a painfull load. It's interesting that in both cases, it effectively makes the constant load a 16 bit operation, does the math 64 bit, and stores 64 bit. From owner-linux-mips@oss.sgi.com Wed Aug 8 13:39:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78KdhR11811 for linux-mips-outgoing; Wed, 8 Aug 2001 13:39:43 -0700 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 f78KdgV11803 for ; Wed, 8 Aug 2001 13:39:42 -0700 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 15Ua7A-0004AX-00; Wed, 08 Aug 2001 22:39:40 +0200 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15Ua7A-0003Gl-00; Wed, 08 Aug 2001 22:39:40 +0200 Date: Wed, 8 Aug 2001 22:39:40 +0200 From: Guido Guenther To: Ian Cc: linux-mips Subject: Re: HELP can't boot Message-ID: <20010808223940.B12550@galadriel.physik.uni-konstanz.de> Mail-Followup-To: Ian , linux-mips References: <20010808174351.C17694@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 03:35:22PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 03:35:22PM -0400, Ian wrote: > > tftp/nfs-root boot ? The prom is enough. > > When I type "boot bootp():/tftpboot/kernel-hardhat" at the PROM command > monitor, I get an error that it can't find Sash (the Irix [6.2] > bootloader). Sash appears to be necessary to do a netboot. Try just "bootp():". The prom is clever enough to figure out the rest. > > HardHat will a sufficient base to build a new system on (i.e. LFS) from > scratch. LFS is a program where you simply build a complete Linux system I doubt that. You can't compile a recent glibc with that outdated toolchain. -- Guido From owner-linux-mips@oss.sgi.com Wed Aug 8 14:16:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78LGQV17660 for linux-mips-outgoing; Wed, 8 Aug 2001 14:16:26 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78LGNV17652 for ; Wed, 8 Aug 2001 14:16:24 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id XAA190663 for ; Wed, 8 Aug 2001 23:16:22 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Uagg-00036c-00 for ; Wed, 08 Aug 2001 23:16:22 +0200 Date: Wed, 8 Aug 2001 23:16:22 +0200 To: "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010808231622.H4452@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk J. Scott Kasten wrote: [snip] > > I don't know how file detects this, but at least current CVS gas > > does not set the appropriate flag in the object file header. > > Gas does not apply here. We're talking about gcc running under Irix with > the native as and ld tools. I'm using gcc-2.91.66 (egcs-1.1.2), > gcc-2.95.2, MipsPro 7.30 as and ld. Sorry, I have missed this. > > > > > > > > Run: > > > > > > > > sizeof(int) = 8, sizeof(*) = 8 > > ^ ^ > > This should be both 4, I assume this happened due to -mint64. > > Not totally. -mips3 generates values of 4 and 8. The -mint64 takes it to > 8 and 8. If I just invoke gcc with no -m flags, it does produce 4 and 4. n32 ABI uses sizeof(void *) == 4, so something went wrong here. [snip] > Just for kicks, instead of *j = 10, which is trivial, I picked a true 64 > bit constant: Are you a telepathic? :-) > sd $2,40($fp) > ld $2,40($fp) > dli $3,0x807060504030201 > sd $3,0($2) > ld $2,32($fp) > daddu $3,$2,1 > sd $3,32($fp) > ld $2,40($fp) > > > 100012b0: ffc20028 sd $v0,40($s8) > 100012b4: dfc20028 ld $v0,40($s8) > 100012b8: 3c030807 lui $v1,0x807 > 100012bc: 34630605 ori $v1,$v1,0x605 > 100012c0: 00031c38 dsll $v1,$v1,0x10 > 100012c4: 34630403 ori $v1,$v1,0x403 > 100012c8: 00031c38 dsll $v1,$v1,0x10 > 100012cc: 34630201 ori $v1,$v1,0x201 > 100012d0: fc430000 sd $v1,0($v0) > 100012d4: dfc20020 ld $v0,32($s8) > 100012d8: 64430001 daddiu $v1,$v0,1 > 100012dc: ffc30020 sd $v1,32($s8) > 100012e0: dfc20028 ld $v0,40($s8) > > Ouch that's a painfull load. It's interesting that in both cases, it > effectively makes the constant load a 16 bit operation, does the math 64 > bit, and stores 64 bit. Loading constants via 16bit immediates is normal and the fastest way on MIPS. The really interesting part is that the load avoids clobbering $at. For superscalar processors it's faster to do e.g. lui $v1,0x807 lui $at,$at,0x403 ori $v1,$v1,0x605 ori $at,$at,0x201 dsll32 $v1,$v1,0x0 or $v1,$v1,$at with a critical path length of 4 instead of 6. Thiemo From owner-linux-mips@oss.sgi.com Wed Aug 8 16:23:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78NNZ704086 for linux-mips-outgoing; Wed, 8 Aug 2001 16:23:35 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78NNXV04077 for ; Wed, 8 Aug 2001 16:23:33 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 5F8661184; Thu, 9 Aug 2001 01:23:32 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8A5403F1C; Thu, 9 Aug 2001 01:23:18 +0200 (CEST) Date: Thu, 9 Aug 2001 01:23:18 +0200 From: Florian Lohoff To: Ian Cc: Guido Guenther , Soeren Laursen , linux-mips Subject: Re: HELP can't boot Message-ID: <20010809012318.A23123@paradigm.rfc822.org> References: <20010808174351.C17694@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 03:35:22PM -0400 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 03:35:22PM -0400, Ian wrote: > > tftp/nfs-root boot ? The prom is enough. > > When I type "boot bootp():/tftpboot/kernel-hardhat" at the PROM command > monitor, I get an error that it can't find Sash (the Irix [6.2] > bootloader). Sash appears to be necessary to do a netboot. Try to delete the "boot" at the beginning - That means to start the sash bootloader which will do the bootp request which the prom is able to do itself. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Wed Aug 8 16:40:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78NeWO06518 for linux-mips-outgoing; Wed, 8 Aug 2001 16:40:32 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78NeTV06509 for ; Wed, 8 Aug 2001 16:40:29 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 2C0F1590AC for ; Wed, 8 Aug 2001 19:37:47 -0400 (EDT) Message-ID: <02a401c12063$cde1e830$3501010a@ltc.com> From: "Bradley D. LaRonde" To: Subject: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Wed, 8 Aug 2001 19:42:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have spent quite a bit of time trying to get a gcc 3.0 / glibc 2.2.3 cross-toolchain working. I am not a Toolchain Builder, but I really wanted to try this combo and I don't see any way around building it myself. I've had some success. Everything seems to build fine. However, when I try to run a simple "hello world" dynamically linked with glibc, I get this: : error while loading shared libraries: failed to map segment from shared object: cannot load shared object file: Invalid argument I think it is trying to load libc.so.6, which is in my root in /lib/, symlinked to libc-2.2.3.so, and so is ld.so.1, symlinked to ld-2.2.3.so. I feel like I am pretty close, but I am starting to get discouraged and could really use some help. I really am clueless about what should/shouldn't work. I'm trying to do this based on bits and pieces of information that I've collected from countless sources. I have heard that gcc 3.0 isn't really "working", but I still want to try. Here is what I've used: * binutils-2.11.90.0.25.tar.gz (extracted from H. J. Lu's srpm on oss.sgi.com; I've tried others also) * gcc-3.0.tar.gz (released version - no patches) * glibc-linuxthreads-2.2.3.tar.gz (released version - no patches; glibc didn't want to configure without this) * glibc-2.2.3.tar.gz (released version) plus a tiny patch to glibc that looks like: --- libc-04052001/sysdeps/mips/mipsel/rtld-parms Sat Jul 12 18:26:15 1997 +++ libc-04052001-patched/sysdeps/mips/mipsel/rtld-parms Fri Apr 6 09:23:27 2001 @@ -1,3 +1,3 @@ ifndef rtld-oformat -rtld-oformat = elf32-littlemips +rtld-oformat = elf32-tradlittlemips endif I built everything on my i386 Debian 2.2 box as follows: Build the mipsel cross-binutils tar -xzf binutils-2.11.90.0.25.tar.gz mkdir mipsel-binutils cd mipsel-binutils ../binutils-2.11.2/configure --target=mipsel-linux \ --libdir='${exec_prefix}'/mipsel-linux/i386-linux/lib make make install cd .. Build the mipsel cross-gcc: tar -xzf gcc-3.0.tar.gz mkdir mipsel-gcc cd mipsel-gcc ../gcc-3.0/configure --target=mipsel-linux \ --enable-languages=c --disable-shared make make install cd .. Install the kernel headers mkdir /usr/local/mipsel-linux/include cp -r $LINUX_SRC/include/linux /usr/local/mipsel-linux/include cp -r $LINUX_SRC/include/asm-mips /usr/local/mipsel-linux/include/asm Build glibc: tar -xzf glibc-2.2.3 cd glibc-2.2.3 patch -p1 -i../elf32-tradlittlemips.diff tar -xzf ../glibc-linuxthreads-2.2.3.tar.gz cd .. mkdir mipsel-glibc cd mipsel-glibc ../glibc-2.2.3/configure --build=i686-linux --host=mipsel-linux \ --enable-add-ons --prefix=/usr/local/mipsel-linux make make install cd .. Thanks. Regards, Brad From owner-linux-mips@oss.sgi.com Wed Aug 8 16:54:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78NseL08493 for linux-mips-outgoing; Wed, 8 Aug 2001 16:54:40 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78NsdV08482 for ; Wed, 8 Aug 2001 16:54:39 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01271 for ; Wed, 8 Aug 2001 16:53:44 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15Ud0Y-0001q5-00; Wed, 08 Aug 2001 16:45:02 -0700 Date: Wed, 8 Aug 2001 16:45:02 -0700 From: Daniel Jacobowitz To: "Bradley D. LaRonde" Cc: linux-mips@oss.sgi.com Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Message-ID: <20010808164502.A6966@nevyn.them.org> References: <02a401c12063$cde1e830$3501010a@ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <02a401c12063$cde1e830$3501010a@ltc.com>; from brad@ltc.com on Wed, Aug 08, 2001 at 07:42:17PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 07:42:17PM -0400, Bradley D. LaRonde wrote: > I have spent quite a bit of time trying to get a gcc 3.0 / glibc 2.2.3 > cross-toolchain working. I am not a Toolchain Builder, but I really wanted > to try this combo and I don't see any way around building it myself. > > I've had some success. Everything seems to build fine. However, when I try > to run a simple "hello world" dynamically linked with glibc, I get this: > > : error while loading shared libraries: failed to map > segment from shared object: cannot load shared object file: Invalid > argument > > I think it is trying to load libc.so.6, which is in my root in /lib/, > symlinked to libc-2.2.3.so, and so is ld.so.1, symlinked to ld-2.2.3.so. > > I feel like I am pretty close, but I am starting to get discouraged and > could really use some help. I really am clueless about what > should/shouldn't work. I'm trying to do this based on bits and pieces of > information that I've collected from countless sources. I have heard that > gcc 3.0 isn't really "working", but I still want to try. > > Here is what I've used: > > * binutils-2.11.90.0.25.tar.gz (extracted from H. J. Lu's > srpm on oss.sgi.com; I've tried others also) > * gcc-3.0.tar.gz (released version - no patches) > * glibc-linuxthreads-2.2.3.tar.gz (released version - no > patches; glibc didn't want to configure without this) > * glibc-2.2.3.tar.gz (released version) You're missing the patch to change MAP_BASE_ADDR. You need that. Something as simple as changing it to 0 will work for you, since you're building everything yourself. If you want debugging info, of course, it's much more complicated :) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Aug 8 16:56:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f78Nuk408862 for linux-mips-outgoing; Wed, 8 Aug 2001 16:56:46 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f78NuhV08847 for ; Wed, 8 Aug 2001 16:56:43 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 9EE03590AB; Wed, 8 Aug 2001 19:54:08 -0400 (EDT) Message-ID: <02ca01c12066$164e5570$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Daniel Jacobowitz" Cc: References: <02a401c12063$cde1e830$3501010a@ltc.com> <20010808164502.A6966@nevyn.them.org> Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Wed, 8 Aug 2001 19:58:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Daniel Jacobowitz" To: "Bradley D. LaRonde" Cc: Sent: Wednesday, August 08, 2001 7:45 PM Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > On Wed, Aug 08, 2001 at 07:42:17PM -0400, Bradley D. LaRonde wrote: > > I have spent quite a bit of time trying to get a gcc 3.0 / glibc 2.2.3 > > cross-toolchain working. I am not a Toolchain Builder, but I really wanted > > to try this combo and I don't see any way around building it myself. > > > > I've had some success. Everything seems to build fine. However, when I try > > to run a simple "hello world" dynamically linked with glibc, I get this: > > > > : error while loading shared libraries: failed to map > > segment from shared object: cannot load shared object file: Invalid > > argument > > > > I think it is trying to load libc.so.6, which is in my root in /lib/, > > symlinked to libc-2.2.3.so, and so is ld.so.1, symlinked to ld-2.2.3.so. > > > > I feel like I am pretty close, but I am starting to get discouraged and > > could really use some help. I really am clueless about what > > should/shouldn't work. I'm trying to do this based on bits and pieces of > > information that I've collected from countless sources. I have heard that > > gcc 3.0 isn't really "working", but I still want to try. > > > > Here is what I've used: > > > > * binutils-2.11.90.0.25.tar.gz (extracted from H. J. Lu's > > srpm on oss.sgi.com; I've tried others also) > > * gcc-3.0.tar.gz (released version - no patches) > > * glibc-linuxthreads-2.2.3.tar.gz (released version - no > > patches; glibc didn't want to configure without this) > > * glibc-2.2.3.tar.gz (released version) > > You're missing the patch to change MAP_BASE_ADDR. You need that. > Something as simple as changing it to 0 will work for you, since you're > building everything yourself. I tried applying the patch that H. J. Lu posted on linux-mips that contains that fix, but then glibc would compile. I'll try it again - maybe I messed something up. If that doesn't work, I'll try the simple fix. Thanks. Regards, Brad From owner-linux-mips@oss.sgi.com Wed Aug 8 18:27:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f791RLP19613 for linux-mips-outgoing; Wed, 8 Aug 2001 18:27:21 -0700 Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f791RKV19610 for ; Wed, 8 Aug 2001 18:27:20 -0700 Received: from grover.wpi.edu (ian@grover.WPI.EDU [130.215.25.67]) by smtp.WPI.EDU (8.12.0.Beta17/8.12.0.Beta17) with ESMTP id f791RHFd023746; Wed, 8 Aug 2001 21:27:17 -0400 (EDT) Date: Wed, 8 Aug 2001 21:27:17 -0400 (EDT) From: Ian To: Guido Guenther cc: linux-mips Subject: Re: HELP can't boot In-Reply-To: <20010808223940.B12550@galadriel.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Try just "bootp():". The prom is clever enough to figure out the rest. Doesn't work. It complains that Sash is missing. > I doubt that. You can't compile a recent glibc with that outdated toolchain. You can. You just build glibc and gcc with the old gcc (2.7.8?), and then you chroot into the newly-built environment and rebuild it again with the new gcc. -- Ian Cooper ian@wpi.edu From owner-linux-mips@oss.sgi.com Wed Aug 8 19:32:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f792WB023286 for linux-mips-outgoing; Wed, 8 Aug 2001 19:32:11 -0700 Received: from dea.waldorf-gmbh.de (u-68-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f792W8V23283 for ; Wed, 8 Aug 2001 19:32:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f792V8Q19240; Thu, 9 Aug 2001 04:31:08 +0200 Date: Thu, 9 Aug 2001 04:31:08 +0200 From: Ralf Baechle To: Ian Cc: Guido Guenther , linux-mips Subject: Re: HELP can't boot Message-ID: <20010809043108.A19210@bacchus.dhis.org> References: <20010808223940.B12550@galadriel.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ian@WPI.EDU on Wed, Aug 08, 2001 at 09:27:17PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 09:27:17PM -0400, Ian wrote: > > Try just "bootp():". The prom is clever enough to figure out the rest. > > Doesn't work. It complains that Sash is missing. > > > I doubt that. You can't compile a recent glibc with that outdated toolchain. > > You can. You just build glibc and gcc with the old gcc (2.7.8?), and then > you chroot into the newly-built environment and rebuild it again with the > new gcc. Since Hardhat there have been various places in the kernel, libc and tools where for the sake of sanity and bugfixes we had to break the binary compatibility. Add the rest of bugs and you'll find probably have an interesting even impossible job to upgrade. Certain packages such as rpm can only sanely be upgraded by upgrading from a binary package as any attempt to rebuild would automatically inherit the broken settings of the installed package. Oh and a rebuild of a current distribution should need about 3 days of CPU or so ... Ralf From owner-linux-mips@oss.sgi.com Wed Aug 8 19:44:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f792iCh23849 for linux-mips-outgoing; Wed, 8 Aug 2001 19:44:12 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f792i9V23845 for ; Wed, 8 Aug 2001 19:44:09 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 0E7B6590AB; Wed, 8 Aug 2001 22:41:31 -0400 (EDT) Message-ID: <040c01c1207d$78b62b90$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Bradley D. LaRonde" , "Daniel Jacobowitz" Cc: References: <02a401c12063$cde1e830$3501010a@ltc.com> <20010808164502.A6966@nevyn.them.org> <02ca01c12066$164e5570$3501010a@ltc.com> Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Wed, 8 Aug 2001 22:44:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Woohoo! It works! Thanks! I was using H. J. Lu's first patch and that was broken. I found the second patch and it worked, except it left the first line in rtld-ldscript.in, when it really should have removed the file entirely. Looks like it's right in the glibc CVS though. Regards, Brad ----- Original Message ----- From: "Bradley D. LaRonde" To: "Daniel Jacobowitz" Cc: Sent: Wednesday, August 08, 2001 7:58 PM Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > ----- Original Message ----- > From: "Daniel Jacobowitz" > To: "Bradley D. LaRonde" > Cc: > Sent: Wednesday, August 08, 2001 7:45 PM > Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > > > > On Wed, Aug 08, 2001 at 07:42:17PM -0400, Bradley D. LaRonde wrote: > > > I have spent quite a bit of time trying to get a gcc 3.0 / glibc 2.2.3 > > > cross-toolchain working. I am not a Toolchain Builder, but I really > wanted > > > to try this combo and I don't see any way around building it myself. > > > > > > I've had some success. Everything seems to build fine. However, when I > try > > > to run a simple "hello world" dynamically linked with glibc, I get this: > > > > > > : error while loading shared libraries: failed to map > > > segment from shared object: cannot load shared object file: Invalid > > > argument > > > > > > I think it is trying to load libc.so.6, which is in my root in /lib/, > > > symlinked to libc-2.2.3.so, and so is ld.so.1, symlinked to ld-2.2.3.so. > > > > > > I feel like I am pretty close, but I am starting to get discouraged and > > > could really use some help. I really am clueless about what > > > should/shouldn't work. I'm trying to do this based on bits and pieces > of > > > information that I've collected from countless sources. I have heard > that > > > gcc 3.0 isn't really "working", but I still want to try. > > > > > > Here is what I've used: > > > > > > * binutils-2.11.90.0.25.tar.gz (extracted from H. J. Lu's > > > srpm on oss.sgi.com; I've tried others also) > > > * gcc-3.0.tar.gz (released version - no patches) > > > * glibc-linuxthreads-2.2.3.tar.gz (released version - no > > > patches; glibc didn't want to configure without this) > > > * glibc-2.2.3.tar.gz (released version) > > > > You're missing the patch to change MAP_BASE_ADDR. You need that. > > Something as simple as changing it to 0 will work for you, since you're > > building everything yourself. > > I tried applying the patch that H. J. Lu posted on linux-mips that contains > that fix, but then glibc would compile. I'll try it again - maybe I messed > something up. If that doesn't work, I'll try the simple fix. Thanks. > > Regards, > Brad From owner-linux-mips@oss.sgi.com Wed Aug 8 20:47:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f793lK728963 for linux-mips-outgoing; Wed, 8 Aug 2001 20:47:20 -0700 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f793lGV28957 for ; Wed, 8 Aug 2001 20:47:16 -0700 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 77C76590AB for ; Wed, 8 Aug 2001 23:44:40 -0400 (EDT) Message-ID: <046001c12086$4ba02ee0$3501010a@ltc.com> From: "Bradley D. LaRonde" To: References: <02a401c12063$cde1e830$3501010a@ltc.com> <20010808164502.A6966@nevyn.them.org> <02ca01c12066$164e5570$3501010a@ltc.com> <040c01c1207d$78b62b90$3501010a@ltc.com> Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Wed, 8 Aug 2001 23:49:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've chronicled my cross-toolchain mips-adventures at: http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt I included a copy of the glibc patch that has the MAP_BASE_ADDR fix in it in the same directory, namely: http://www.ltc.com/~brad/mips/ Regards, Brad ----- Original Message ----- From: "Bradley D. LaRonde" To: "Bradley D. LaRonde" ; "Daniel Jacobowitz" Cc: Sent: Wednesday, August 08, 2001 10:44 PM Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > Woohoo! It works! Thanks! I was using H. J. Lu's first patch and that was > broken. I found the second patch and it worked, except it left the first > line in rtld-ldscript.in, when it really should have removed the file > entirely. Looks like it's right in the glibc CVS though. > > Regards, > Brad > > ----- Original Message ----- > From: "Bradley D. LaRonde" > To: "Daniel Jacobowitz" > Cc: > Sent: Wednesday, August 08, 2001 7:58 PM > Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > > > > ----- Original Message ----- > > From: "Daniel Jacobowitz" > > To: "Bradley D. LaRonde" > > Cc: > > Sent: Wednesday, August 08, 2001 7:45 PM > > Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain > > > > > > > On Wed, Aug 08, 2001 at 07:42:17PM -0400, Bradley D. LaRonde wrote: > > > > I have spent quite a bit of time trying to get a gcc 3.0 / glibc 2.2.3 > > > > cross-toolchain working. I am not a Toolchain Builder, but I really > > wanted > > > > to try this combo and I don't see any way around building it myself. > > > > > > > > I've had some success. Everything seems to build fine. However, when > I > > try > > > > to run a simple "hello world" dynamically linked with glibc, I get > this: > > > > > > > > : error while loading shared libraries: failed to map > > > > segment from shared object: cannot load shared object file: > Invalid > > > > argument > > > > > > > > I think it is trying to load libc.so.6, which is in my root in /lib/, > > > > symlinked to libc-2.2.3.so, and so is ld.so.1, symlinked to > ld-2.2.3.so. > > > > > > > > I feel like I am pretty close, but I am starting to get discouraged > and > > > > could really use some help. I really am clueless about what > > > > should/shouldn't work. I'm trying to do this based on bits and pieces > > of > > > > information that I've collected from countless sources. I have heard > > that > > > > gcc 3.0 isn't really "working", but I still want to try. > > > > > > > > Here is what I've used: > > > > > > > > * binutils-2.11.90.0.25.tar.gz (extracted from H. J. Lu's > > > > srpm on oss.sgi.com; I've tried others also) > > > > * gcc-3.0.tar.gz (released version - no patches) > > > > * glibc-linuxthreads-2.2.3.tar.gz (released version - no > > > > patches; glibc didn't want to configure without this) > > > > * glibc-2.2.3.tar.gz (released version) > > > > > > You're missing the patch to change MAP_BASE_ADDR. You need that. > > > Something as simple as changing it to 0 will work for you, since you're > > > building everything yourself. > > > > I tried applying the patch that H. J. Lu posted on linux-mips that > contains > > that fix, but then glibc would compile. I'll try it again - maybe I > messed > > something up. If that doesn't work, I'll try the simple fix. Thanks. > > > > Regards, > > Brad From owner-linux-mips@oss.sgi.com Wed Aug 8 23:54:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f796sq812978 for linux-mips-outgoing; Wed, 8 Aug 2001 23:54:52 -0700 Received: from anfora-central.anfora (AToulouse-201-2-1-26.abo.wanadoo.fr [193.251.11.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f796soV12974 for ; Wed, 8 Aug 2001 23:54:51 -0700 Received: from arnaud (arnaud.anfora [192.168.0.132]) by anfora-central.anfora (8.9.3/8.8.7) with SMTP id IAA04147 for ; Thu, 9 Aug 2001 08:57:32 +0200 X-Authentication-Warning: anfora-central.anfora: Host arnaud.anfora [192.168.0.132] claimed to be arnaud Content-Type: text/plain; charset="iso-8859-1" From: Arnaud Rolly Organization: Anfora To: linux-mips@oss.sgi.com Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Thu, 9 Aug 2001 09:03:03 -0400 X-Mailer: KMail [version 1.2] References: <02a401c12063$cde1e830$3501010a@ltc.com> <040c01c1207d$78b62b90$3501010a@ltc.com> <046001c12086$4ba02ee0$3501010a@ltc.com> In-Reply-To: <046001c12086$4ba02ee0$3501010a@ltc.com> MIME-Version: 1.0 Message-Id: <01080909030303.06909@arnaud> X-MIME-Autoconverted: from 8bit to quoted-printable by anfora-central.anfora id IAA04147 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f796sqV12975 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Le Mercredi 8 Août 2001 23:49, vous avez écrit : > I've chronicled my cross-toolchain mips-adventures at: > > http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt > > I included a copy of the glibc patch that has the MAP_BASE_ADDR fix in it > in the same directory, namely: > > http://www.ltc.com/~brad/mips/ > > Regards, > Brad It would be great to have a patch repository, for example just a directory on the FTP of oss.sgi.com From owner-linux-mips@oss.sgi.com Thu Aug 9 00:11:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f797BND14330 for linux-mips-outgoing; Thu, 9 Aug 2001 00:11:23 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f797BMV14326 for ; Thu, 9 Aug 2001 00:11:22 -0700 Received: (qmail 30386 invoked by uid 502); 9 Aug 2001 07:11:21 -0000 Content-Type: text/plain; charset="koi8-r" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Arnaud Rolly , linux-mips@oss.sgi.com Subject: Re: gcc 3.0 / glibc 2.2.3 cross-toolchain Date: Thu, 9 Aug 2001 00:11:17 -0700 X-Mailer: KMail [version 1.2] References: <02a401c12063$cde1e830$3501010a@ltc.com> <046001c12086$4ba02ee0$3501010a@ltc.com> <01080909030303.06909@arnaud> In-Reply-To: <01080909030303.06909@arnaud> MIME-Version: 1.0 Message-Id: <01080900111701.28762@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I offered something along these lines a while ago. I even started a little site. Unfortunately I don't have enough time to keep up with current toolchain patches, etc. myself, but if people send me patches, along with comments, I'll post them at my site. On Thursday 09 August 2001 06:03, Arnaud Rolly wrote: > Le Mercredi 8 Août 2001 23:49, vous avez écrit : > > I've chronicled my cross-toolchain mips-adventures at: > > > > http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt > > > > I included a copy of the glibc patch that has the MAP_BASE_ADDR fix in it > > in the same directory, namely: > > > > http://www.ltc.com/~brad/mips/ > > > > Regards, > > Brad > > It would be great to have a patch repository, for example just a directory > on the FTP of oss.sgi.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtyN5kACgkQtKh84cA8u2lORwCcDr0csXgikuVFizIgBXJgncPv zpQAoIGtXsSE7WMiBP0XODyWhEMhj9zb =VJLD -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Thu Aug 9 05:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79CdnE18985 for linux-mips-outgoing; Thu, 9 Aug 2001 05:39:49 -0700 Received: from animal.pace.co.uk (gateway.pace.co.uk [195.44.197.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79CdlV18970 for ; Thu, 9 Aug 2001 05:39:48 -0700 Received: from exchange1.cam.pace.co.uk (exchange1.cam.pace.co.uk [136.170.131.80]) by animal.pace.co.uk (8.10.2/8.10.2) with ESMTP id f79CdcQ10419 for ; Thu, 9 Aug 2001 13:39:38 +0100 Received: by exchange1.cam.pace.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Aug 2001 13:39:37 +0100 Message-ID: <54045BFDAD47D5118A850002A5095CC30AC570@exchange1.cam.pace.co.uk> From: Phil Thompson To: "'linux-mips@oss.sgi.com'" Subject: RM5231A Cause Register Values Date: Thu, 9 Aug 2001 13:39:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk In my low level assembler interrupt handler I'm detecting a Cause register value of 0x00800000. According to "See MIPS Run", the bit that is set should be zero - but I haven't been able to find any RM5231A documentation that defines this bit as anything else. Any ideas? BTW, the exception is raised under fairly heavy network traffic and in either disable_irq_nosync() or ei_start_xmit(). The latter is in the network card driver and itself contains a call to disable_irq_nosync(). I don't believe (although I may be wrong) that this was happening under the old style interrupt code. Thanks, Phil From owner-linux-mips@oss.sgi.com Thu Aug 9 05:50:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Co1V20501 for linux-mips-outgoing; Thu, 9 Aug 2001 05:50:01 -0700 Received: from dea.waldorf-gmbh.de (u-217-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.217]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79Cm0V20195 for ; Thu, 9 Aug 2001 05:48:15 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f79C80620997; Thu, 9 Aug 2001 14:08:00 +0200 Date: Thu, 9 Aug 2001 14:08:00 +0200 From: Ralf Baechle To: "J. Scott Kasten" Cc: Thiemo Seufer , "linux-mips@oss.sgi.com" Subject: Re: Indy 64 or 32 bit? Message-ID: <20010809140800.A20579@bacchus.dhis.org> References: <20010808174142.F4452@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsk@tetracon-eng.net on Wed, Aug 08, 2001 at 04:12:39PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Aug 08, 2001 at 04:12:39PM -0400, J. Scott Kasten wrote: > 100012b0: ffc20028 sd $v0,40($s8) > 100012b4: dfc20028 ld $v0,40($s8) > 100012b8: 3c030807 lui $v1,0x807 > 100012bc: 34630605 ori $v1,$v1,0x605 > 100012c0: 00031c38 dsll $v1,$v1,0x10 > 100012c4: 34630403 ori $v1,$v1,0x403 > 100012c8: 00031c38 dsll $v1,$v1,0x10 > 100012cc: 34630201 ori $v1,$v1,0x201 > 100012d0: fc430000 sd $v1,0($v0) > 100012d4: dfc20020 ld $v0,32($s8) > 100012d8: 64430001 daddiu $v1,$v0,1 > 100012dc: ffc30020 sd $v1,32($s8) > 100012e0: dfc20028 ld $v0,40($s8) > > Ouch that's a painfull load. It's interesting that in both cases, it > effectively makes the constant load a 16 bit operation, does the math 64 > bit, and stores 64 bit. With GP optimization something like the following would have been created: dla $gp, _gp + $8000 ld $reg1, %gprel(var)($gp) daddiu $reg1, $reg1, 1 sd $reg1, %gprel(var)($gp) _gp: var: .word 0 Gas is lame. MIPS/ELF gas is more. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 9 06:02:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79D2Jo22198 for linux-mips-outgoing; Thu, 9 Aug 2001 06:02:19 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79D2IV22194 for ; Thu, 9 Aug 2001 06:02:18 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA24651; Thu, 9 Aug 2001 06:02:11 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA10832; Thu, 9 Aug 2001 06:02:10 -0700 (PDT) Message-ID: <007001c120d4$22a24520$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Phil Thompson" , References: <54045BFDAD47D5118A850002A5095CC30AC570@exchange1.cam.pace.co.uk> Subject: Re: RM5231A Cause Register Values Date: Thu, 9 Aug 2001 15:06:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk That bit should be the "IV" bit on the R52xx, which is actually a control bit, not a status indication. The set value implies that interrupt exceptions are being vectored to offet 0x200 instead of 0x180. It should not be changing on its own! Kevin K. ----- Original Message ----- From: "Phil Thompson" To: Sent: Thursday, August 09, 2001 2:39 PM Subject: RM5231A Cause Register Values > In my low level assembler interrupt handler I'm detecting a Cause register > value of 0x00800000. According to "See MIPS Run", the bit that is set should > be zero - but I haven't been able to find any RM5231A documentation that > defines this bit as anything else. Any ideas? > > BTW, the exception is raised under fairly heavy network traffic and in > either disable_irq_nosync() or ei_start_xmit(). The latter is in the network > card driver and itself contains a call to disable_irq_nosync(). I don't > believe (although I may be wrong) that this was happening under the old > style interrupt code. > > Thanks, > Phil From owner-linux-mips@oss.sgi.com Thu Aug 9 06:21:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79DL5624771 for linux-mips-outgoing; Thu, 9 Aug 2001 06:21:05 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79DL3V24765 for ; Thu, 9 Aug 2001 06:21:03 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA24804; Thu, 9 Aug 2001 06:20:57 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA11008; Thu, 9 Aug 2001 06:20:54 -0700 (PDT) Message-ID: <007901c120d6$c0f29ca0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , "Phil Thompson" , References: <54045BFDAD47D5118A850002A5095CC30AC570@exchange1.cam.pace.co.uk> <007001c120d4$22a24520$0deca8c0@Ulysses> Subject: Re: RM5231A Cause Register Values Date: Thu, 9 Aug 2001 15:25:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Oh, yeah, and the fact that you're seeing no other bits set in the Cause register is indicative of it being a "spurious" interrupt, which was presumably raised while you were doing another interrupt service which coincidentally cleared the cause. That's consistent with your report of seeing it under heavy interrupt load. You should be able to just return from interrupt. Kevin K. ----- Original Message ----- From: "Kevin D. Kissell" To: "Phil Thompson" ; Sent: Thursday, August 09, 2001 3:06 PM Subject: Re: RM5231A Cause Register Values > That bit should be the "IV" bit on the R52xx, which is actually > a control bit, not a status indication. The set value implies > that interrupt exceptions are being vectored to offet 0x200 > instead of 0x180. It should not be changing on its own! > > Kevin K. > > ----- Original Message ----- > From: "Phil Thompson" > To: > Sent: Thursday, August 09, 2001 2:39 PM > Subject: RM5231A Cause Register Values > > > > In my low level assembler interrupt handler I'm detecting a Cause register > > value of 0x00800000. According to "See MIPS Run", the bit that is set > should > > be zero - but I haven't been able to find any RM5231A documentation that > > defines this bit as anything else. Any ideas? > > > > BTW, the exception is raised under fairly heavy network traffic and in > > either disable_irq_nosync() or ei_start_xmit(). The latter is in the > network > > card driver and itself contains a call to disable_irq_nosync(). I don't > > believe (although I may be wrong) that this was happening under the old > > style interrupt code. > > > > Thanks, > > Phil > From owner-linux-mips@oss.sgi.com Thu Aug 9 08:36:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79Fa6n10684 for linux-mips-outgoing; Thu, 9 Aug 2001 08:36:06 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79Fa4V10680 for ; Thu, 9 Aug 2001 08:36:04 -0700 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15Urqr-0006F6-00 for linux-mips@oss.sgi.com; Thu, 9 Aug 2001 17:36:01 +0200 Received: from p3e9ea738.dip.t-dialin.net ([62.158.167.56] helo=shodan) by mrvdom04.kundenserver.de with smtp (Exim 2.12 #2) id 15Urqr-0004bu-00 for linux-mips@oss.sgi.com; Thu, 9 Aug 2001 17:36:01 +0200 Message-ID: <007501c120e8$fe293720$737e9fc1@shodan> From: "Armin F. Gnosa" To: Subject: Problem with PMAD-AA / DECStation 5000/200 Date: Thu, 9 Aug 2001 17:35:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm owning a DECStation mentioned in the subject. It has only one flaw: The Firmware-EPROM of the on-board PMAD-AA Ethernet adapter has become amnesic. So is there anyone who can read out his EPROM and send me an image so that I can finally boot Linux from the net? The version was 5.3a Many Thanks in advance Armin From owner-linux-mips@oss.sgi.com Thu Aug 9 08:51:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79FpMg12442 for linux-mips-outgoing; Thu, 9 Aug 2001 08:51:22 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79FpKV12432 for ; Thu, 9 Aug 2001 08:51:20 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 0AB81138A; Thu, 9 Aug 2001 17:51:17 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 31D374501; Thu, 9 Aug 2001 17:51:31 +0200 (CEST) Date: Thu, 9 Aug 2001 17:51:31 +0200 From: Florian Lohoff To: "Armin F. Gnosa" Cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010809175131.D30160@paradigm.rfc822.org> References: <007501c120e8$fe293720$737e9fc1@shodan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <007501c120e8$fe293720$737e9fc1@shodan>; from armin@gnosa.com on Thu, Aug 09, 2001 at 05:35:42PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 05:35:42PM +0200, Armin F. Gnosa wrote: > I'm owning a DECStation mentioned in the subject. It has > only one flaw: The Firmware-EPROM of the on-board PMAD-AA > Ethernet adapter has become amnesic. So is there anyone who > can read out his EPROM and send me an image so that I can > finally boot Linux from the net? The version was 5.3a If anyone can read out different proms i would happy to put them somewhere on the net. I guess the Dec/Compaq whoever guys who might own the copyright dont bother after at least 10-15 years. There are proms who are not able to boot from the net which could be solved just by burning a new eprom. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Thu Aug 9 09:20:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GKpu14752 for linux-mips-outgoing; Thu, 9 Aug 2001 09:20:51 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79GKnV14743 for ; Thu, 9 Aug 2001 09:20:50 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 577D1C4FE; Thu, 9 Aug 2001 18:20:47 +0200 (CEST) Date: Thu, 9 Aug 2001 18:20:47 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010809182047.A25724@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010809175131.D30160@paradigm.rfc822.org>; from flo@rfc822.org on Thu, Aug 09, 2001 at 05:51:31PM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2001-08-09 17:51:31 +0200, Florian Lohoff wrote in message <20010809175131.D30160@paradigm.rfc822.org>: > On Thu, Aug 09, 2001 at 05:35:42PM +0200, Armin F. Gnosa wrote: > > I'm owning a DECStation mentioned in the subject. It has > > only one flaw: The Firmware-EPROM of the on-board PMAD-AA > > Ethernet adapter has become amnesic. So is there anyone who > > can read out his EPROM and send me an image so that I can > > finally boot Linux from the net? The version was 5.3a > > If anyone can read out different proms i would happy to put them > somewhere on the net. I guess the Dec/Compaq whoever guys who might > own the copyright dont bother after at least 10-15 years. There are > proms who are not able to boot from the net which could be solved just > by burning a new eprom. I volunteer to provide all PROMs I can find @home. However, someone has to read them as I don't have an EPROM burner:-( Btw... Is it possible to make some machines tftp boot (instead of crappy/nonfunctional MOP booting?) MfG, JBG From owner-linux-mips@oss.sgi.com Thu Aug 9 09:23:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GNCv14889 for linux-mips-outgoing; Thu, 9 Aug 2001 09:23:12 -0700 Received: from kuolema.infodrom.north.de (postfix@kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79GN9V14884 for ; Thu, 9 Aug 2001 09:23:10 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id 555CC4D741; Thu, 9 Aug 2001 18:23:02 +0200 (CEST) Received: by finlandia.infodrom.north.de (Postfix, from userid 501) id 4240911730; Thu, 9 Aug 2001 18:22:58 +0200 (CEST) Date: Thu, 9 Aug 2001 18:22:58 +0200 From: Martin Schulze To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010809182258.W27458@finlandia.infodrom.north.de> Reply-To: Martin Schulze References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <20010809182047.A25724@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010809182047.A25724@lug-owl.de>; from jbglaw@lug-owl.de on Thu, Aug 09, 2001 at 06:20:47PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jan-Benedict Glaw wrote: > I volunteer to provide all PROMs I can find @home. However, someone > has to read them as I don't have an EPROM burner:-( > > Btw... Is it possible to make some machines tftp boot (instead of > crappy/nonfunctional MOP booting?) After "updating" their prom's, that should be possible, I guess. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book From owner-linux-mips@oss.sgi.com Thu Aug 9 09:35:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79GZum15051 for linux-mips-outgoing; Thu, 9 Aug 2001 09:35:56 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79GZsV15048 for ; Thu, 9 Aug 2001 09:35:54 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 1B1C7C4FE; Thu, 9 Aug 2001 18:35:53 +0200 (CEST) Date: Thu, 9 Aug 2001 18:35:53 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010809183552.B25724@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <20010809182047.A25724@lug-owl.de> <20010809182258.W27458@finlandia.infodrom.north.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010809182258.W27458@finlandia.infodrom.north.de>; from joey@finlandia.infodrom.north.de on Thu, Aug 09, 2001 at 06:22:58PM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2001-08-09 18:22:58 +0200, Martin Schulze wrote in message <20010809182258.W27458@finlandia.infodrom.north.de>: > Jan-Benedict Glaw wrote: > > I volunteer to provide all PROMs I can find @home. However, someone > > has to read them as I don't have an EPROM burner:-( > > > > Btw... Is it possible to make some machines tftp boot (instead of > > crappy/nonfunctional MOP booting?) > > After "updating" their prom's, that should be possible, I guess. I'm not that sure. Does there always exist a "clean" PROM? For example, I'm searching for a tftp/bootp enabled PROM for a DEC 5000/240 (or was it /200?). Does anybody have sth like this? MfG, JBG From owner-linux-mips@oss.sgi.com Thu Aug 9 13:00:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79K0qq25667 for linux-mips-outgoing; Thu, 9 Aug 2001 13:00:52 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79K0pV25660 for ; Thu, 9 Aug 2001 13:00:51 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f79K0Tp17836; Thu, 9 Aug 2001 13:00:29 -0700 (PDT) Date: Thu, 9 Aug 2001 13:00:29 -0700 (PDT) From: "John D. Davis" To: SGI MIPS list , Debian MIPS list Subject: Java VM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Is there a java vm available for mips linux? I would like to do some java stuff, webserver, and database stuff and I am wondering if that is available, ported, for this platform. thanks, john From owner-linux-mips@oss.sgi.com Thu Aug 9 13:12:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f79KC0q26584 for linux-mips-outgoing; Thu, 9 Aug 2001 13:12:00 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f79KBxV26579 for ; Thu, 9 Aug 2001 13:11:59 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f79KBqTc005529; Thu, 9 Aug 2001 13:11:52 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f79KBqNV005525; Thu, 9 Aug 2001 13:11:52 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 9 Aug 2001 13:11:51 -0700 (PDT) From: James Simmons To: "John D. Davis" cc: SGI MIPS list , Debian MIPS list Subject: Re: Java VM 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 > Is there a java vm available for mips linux? I would like to do some java > stuff, webserver, and database stuff and I am wondering if that is > available, ported, for this platform. I work on kaffe and I have ported it to mips. From owner-linux-mips@oss.sgi.com Thu Aug 9 17:18:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A0IQ322994 for linux-mips-outgoing; Thu, 9 Aug 2001 17:18:26 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A0IQV22987 for ; Thu, 9 Aug 2001 17:18:26 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id RAA29996 for ; Thu, 9 Aug 2001 17:18:25 -0700 Message-Id: <200108100018.RAA29996@saturn.mikemac.com> To: linux-mips@oss.sgi.com Subject: R10K I2 Solid Impact Date: Thu, 09 Aug 2001 17:18:25 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I just got a R10K I2 Solid Impact that I'm going to attempt to play with linux on. But first I need to find some more basic info. Does anyone know where the connectors are documented? In particular, the video connectors on the Solid Impact. The SGI search engine just tells be they don't refurbish Indigos anymore. The serial port pinouts would be useful too. (Wasn't it 'man serial' once I get it running?) It's been a while since I've played with an SGI, so any helpful information will be greatly appreciated. Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Thu Aug 9 17:29:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A0Tdq24126 for linux-mips-outgoing; Thu, 9 Aug 2001 17:29:39 -0700 Received: from web11902.mail.yahoo.com (web11902.mail.yahoo.com [216.136.172.186]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A0TbV24123 for ; Thu, 9 Aug 2001 17:29:37 -0700 Message-ID: <20010810002937.56073.qmail@web11902.mail.yahoo.com> Received: from [209.243.184.191] by web11902.mail.yahoo.com; Thu, 09 Aug 2001 17:29:37 PDT Date: Thu, 9 Aug 2001 17:29:37 -0700 (PDT) From: Wayne Gowcher Subject: Problems mounting RedHat 7.0 or 7.1 from oss.sgi site To: linux-mips@oss.sgi.com In-Reply-To: <20010809175131.D30160@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have tried unsuccessfully to use the root filesystems mipselroot-rh7-20010606.tar.bz2 and H.J.Lu's RedHat 7.1 install from the sgi ftp site. Both give me warnings immeadiately about the files they are trying to access : INIT: version 2.78 booting /etc/rc.sysinit: .: /etc/sysconfig/network: not a regular file /etc/rc.sysinit: .: /etc/init.d/functions: not a regular file Welcome to Red Hat Linux Press 'I' to enter interactive startup. If I then boot either with init=/bin/bash rw and use 'ls' without any parameters 'ls' warns : bash-2.04# ls ls: .: Invalid argument Using ls * will give a file listing if the directory contains any files. But the file info is totally hosed eg from /etc: ?--------x 0 0 root 17 Jul 23 2000 host.conf ?--------x 0 0 root 161 Jan 12 2000 hosts.allow ?--------x 0 0 root 347 Jan 12 2000 hosts.deny ?--------x 0 0 root 754 Feb 24 11:57 info-dir ? I am using a 2.4.2 kernel that boots successfully when using the RedHat 5.1 distribution also found on the SGI site. My tools are : egcs-mipsel-linux-1.1.2-4.i386.rpm binutils-mipsel-linux-2.8.1-2.i386.rpm Any ideas as to what I am doing wrong would be appreciated Compiler ? Glibc ? ??? Wayne __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Thu Aug 9 17:46:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A0k8v25677 for linux-mips-outgoing; Thu, 9 Aug 2001 17:46:08 -0700 Received: from sioux.meginc.com (Sioux.meginc.com [207.246.76.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A0k7V25672 for ; Thu, 9 Aug 2001 17:46:07 -0700 Received: from linux (brandon@[207.246.76.46]) by sioux.meginc.com (8.9.3/8.9.1) with SMTP id UAA65917 for ; Thu, 9 Aug 2001 20:47:21 -0400 (EDT) (envelope-from bebarker@meginc.com) Content-Type: text/plain; charset="iso-8859-1" From: Brandon Barker To: linux-mips@oss.sgi.com Subject: XFS installer Date: Thu, 9 Aug 2001 20:53:11 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01080920531200.02315@linux> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk My intel workstation uses SGI's XFS Installer to create partitions with XFS for Redhat 7.1 before it is installed, along with installing a modified kernel and utilitiies. I was wondering if there is anything like this for Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition for use with linux. Thanks, Brandon From owner-linux-mips@oss.sgi.com Thu Aug 9 17:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A0mbw25752 for linux-mips-outgoing; Thu, 9 Aug 2001 17:48:37 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A0mZV25749 for ; Thu, 9 Aug 2001 17:48:35 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id CAA203706 for ; Fri, 10 Aug 2001 02:48:34 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15V0TZ-00035d-00 for ; Fri, 10 Aug 2001 02:48:33 +0200 Date: Fri, 10 Aug 2001 02:48:33 +0200 To: linux-mips@oss.sgi.com Subject: Re: R10K I2 Solid Impact Message-ID: <20010810024833.A385@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108100018.RAA29996@saturn.mikemac.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Mike McDonald wrote: > > I just got a R10K I2 Solid Impact that I'm going to attempt to play > with linux on. At least my I2 R10K's Firmware doesn't boot anything else than ELF64 Kernels loaded at 0x8000000020002000. I'm currently developing a mips64-linux in 64bit address space due to this. I'd like to know how your machine behaves WRT this. > But first I need to find some more basic info. Does > anyone know where the connectors are documented? In particular, the > video connectors on the Solid Impact. What I've figured out via google is this pinout: 13W3-SGI | DB15-VGA | 13W3-SUN ------------------------------ A1 --- 1 --- A1 A1-GND --- 6 --- A1-GND A2 --- 2 --- A2 A2-GND --- 7 --- A2-GND A3 --- 3 --- A3 A3-GND --- 8 --- A3-GND 3-CSYNC --- --- 5 4-HSYNC --- 13 --- 5-VSYNC --- 14 --- --- 10 --- 10 The Impact normally uses HSYNC/VSYNC but can be set to CSYNC mode. > The SGI search engine just tells > be they don't refurbish Indigos anymore. The serial port pinouts would > be useful too. (Wasn't it 'man serial' once I get it running?) The pinout for a cross cable can be found in the I2 Howto. Thiemo From owner-linux-mips@oss.sgi.com Thu Aug 9 18:14:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1E5c32694 for linux-mips-outgoing; Thu, 9 Aug 2001 18:14:05 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1E3V32691 for ; Thu, 9 Aug 2001 18:14:04 -0700 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA13734; Fri, 10 Aug 2001 11:13:55 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd.1zSz_; Fri Aug 10 11:13:09 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA13943; Fri, 10 Aug 2001 11:13:08 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdykjf4_; Fri Aug 10 11:12:32 2001 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA00940; Fri, 10 Aug 2001 11:12:32 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 11:08:33 +1000 Message-ID: From: "Salisbury, Roger" To: "''" Cc: "'Keith Wesolows'" , "'Ralf Baechle'" Subject: indigo2 kernel build failures Date: Fri, 10 Aug 2001 11:08:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Keith / Ralf / All I just wondering if the UNKNOW aspect "mips-unknown-linux-gnu" of building packages has some detrimental affect on the success of building a kernel. IE The machine status isn't detected properly. If so what do i do to fix? Thanks ######################################## bash-2.04# pwd /binutils-2.9.5.0.37 bash-2.04# ./configure Configuring for a mips-unknown-linux-gnu host. *** This configuration is not supported in the following subdirectories: gprof (Any other directories should still work fine.) ############################################### From owner-linux-mips@oss.sgi.com Thu Aug 9 18:26:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1QU400456 for linux-mips-outgoing; Thu, 9 Aug 2001 18:26:30 -0700 Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1QSV00453 for ; Thu, 9 Aug 2001 18:26:29 -0700 Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA23361 for ; Fri, 10 Aug 2001 11:26:22 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdgHaNG_; Fri Aug 10 11:26:04 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA23328 for ; Fri, 10 Aug 2001 11:26:03 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdZaGbZ_; Fri Aug 10 11:25:55 2001 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA18942 for ; Fri, 10 Aug 2001 11:25:55 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 11:21:55 +1000 Message-ID: From: "Salisbury, Roger" To: "'linux-mips@oss.sgi.com'" Subject: FW: indigo2 kernel build failures Date: Fri, 10 Aug 2001 11:21:52 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Keith / Ralf / All > > I just wondering if the UNKNOW aspect "mips-unknown-linux-gnu" of > building packages has some detrimental affect > on the success of building a kernel. > IE > The machine status isn't detected properly. > > > If so what do i do to fix? > > Thanks > EG when updating binutils I get: > ######################################## > bash-2.04# pwd > /binutils-2.9.5.0.37 > bash-2.04# ./configure > Configuring for a mips-unknown-linux-gnu host. > *** This configuration is not supported in the following subdirectories: > gprof > (Any other directories should still work fine.) > ############################################### > From owner-linux-mips@oss.sgi.com Thu Aug 9 18:37:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1b8B00592 for linux-mips-outgoing; Thu, 9 Aug 2001 18:37:08 -0700 Received: from tennyson.netexpress.net (IDENT:root@tennyson.netexpress.net [64.22.192.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1b6V00575 for ; Thu, 9 Aug 2001 18:37:06 -0700 Received: from localhost (vorlon@localhost) by tennyson.netexpress.net (8.9.3/8.9.3) with ESMTP id UAA06201; Thu, 9 Aug 2001 20:36:31 -0500 X-Authentication-Warning: tennyson.netexpress.net: vorlon owned process doing -bs Date: Thu, 9 Aug 2001 20:36:31 -0500 (CDT) From: Steve Langasek To: "Salisbury, Roger" cc: "''" Subject: Re: indigo2 kernel build failures 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 On Fri, 10 Aug 2001, Salisbury, Roger wrote: > Keith / Ralf / All > I just wondering if the UNKNOW aspect "mips-unknown-linux-gnu" of > building packages has some detrimental affect > on the success of building a kernel. > IE > The machine status isn't detected properly. Er, 'mips-unknown-linux-gnu' /is/ the proper machine type. $ uname -a Linux quetzcoatl 2.4.1 #1 Sat Feb 10 23:24:40 CST 2001 alpha unknown $ /usr/share/misc/config.guess alphapca56-unknown-linux-gnu $ Results are similar on all other Linux platforms except for x86 machines, IIRC, where 'unknown' is replaced with 'pc'. Steve Langasek postmodern programmer From owner-linux-mips@oss.sgi.com Thu Aug 9 18:37:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1b6d00574 for linux-mips-outgoing; Thu, 9 Aug 2001 18:37:06 -0700 Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1b5V00570 for ; Thu, 9 Aug 2001 18:37:05 -0700 Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA27191 for ; Fri, 10 Aug 2001 11:36:59 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdAf9QI_; Fri Aug 10 11:36:43 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA00278 for ; Fri, 10 Aug 2001 11:36:42 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdl8wZx_; Fri Aug 10 11:36:06 2001 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA03258 for ; Fri, 10 Aug 2001 11:36:06 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 11:32:07 +1000 Message-ID: From: "Salisbury, Roger" To: "'linux-mips@oss.sgi.com'" Subject: FW: indigo2 kernel build failures Date: Fri, 10 Aug 2001 11:31:58 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Keith / Ralf / All > > I just wondering if the UNKNOW aspect "mips-unknown-linux-gnu" of > building packages has some detrimental affect > on the success of building a kernel. > IE > The machine status isn't detected properly. > > > If so what do i do to fix? > > Thanks > > EG when updating binutils I get: > ######################################## > bash-2.04# pwd > /binutils-2.9.5.0.37 > bash-2.04# ./configure > Configuring for a mips-unknown-linux-gnu host. > *** This configuration is not supported in the following subdirectories: > gprof > (Any other directories should still work fine.) > ############################################### > From owner-linux-mips@oss.sgi.com Thu Aug 9 18:52:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1qDw00818 for linux-mips-outgoing; Thu, 9 Aug 2001 18:52:13 -0700 Received: from dea.waldorf-gmbh.de (u-219-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1qAV00815 for ; Thu, 9 Aug 2001 18:52:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7A1p7K23568; Fri, 10 Aug 2001 03:51:07 +0200 Date: Fri, 10 Aug 2001 03:51:07 +0200 From: Ralf Baechle To: Brandon Barker Cc: linux-mips@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810035106.A23548@bacchus.dhis.org> References: <01080920531200.02315@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01080920531200.02315@linux>; from bebarker@meginc.com on Thu, Aug 09, 2001 at 08:53:11PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 08:53:11PM -0400, Brandon Barker wrote: > My intel workstation uses SGI's XFS Installer to create partitions with XFS > for Redhat 7.1 before it is installed, along with installing a modified > kernel and utilitiies. I was wondering if there is anything like this for > Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition > for use with linux. Don't take my answer as authoritative for XFS stuff - the directory format of XFS on disk has somewhen been changed; the Linux version only supports v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both flavours are incompatible. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 9 18:53:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1rkQ00897 for linux-mips-outgoing; Thu, 9 Aug 2001 18:53:46 -0700 Received: from dea.waldorf-gmbh.de (u-219-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1rhV00894 for ; Thu, 9 Aug 2001 18:53:44 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7A1qRU23575; Fri, 10 Aug 2001 03:52:27 +0200 Date: Fri, 10 Aug 2001 03:52:27 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: FW: indigo2 kernel build failures Message-ID: <20010810035227.B23548@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Fri, Aug 10, 2001 at 11:21:52AM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 11:21:52AM +1000, Salisbury, Roger wrote: > > If so what do i do to fix? > EG when updating binutils I get: > > ######################################## > > bash-2.04# pwd > > /binutils-2.9.5.0.37 > > bash-2.04# ./configure > > Configuring for a mips-unknown-linux-gnu host. > > *** This configuration is not supported in the following subdirectories: > > gprof > > (Any other directories should still work fine.) As it says - gprof. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 9 18:59:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A1xAI00999 for linux-mips-outgoing; Thu, 9 Aug 2001 18:59:10 -0700 Received: from thor ([207.246.91.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A1x8V00996 for ; Thu, 9 Aug 2001 18:59:08 -0700 Received: from localhost (localhost [127.0.0.1]) by thor (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA29136; Thu, 9 Aug 2001 21:58:30 -0400 Date: Thu, 9 Aug 2001 21:58:30 -0400 From: "J. Scott Kasten" To: Mike McDonald cc: Subject: Re: R10K I2 Solid Impact In-Reply-To: <200108100018.RAA29996@saturn.mikemac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The site www.reputable.com is for a used equipment dealer (no affiliation, but I bought my I2 from them), they have lots of really good links. In particular there is a multi-page SGI FAQ that will answer 70% of your questions. If I'm not mistaken the serial is RS-422 like on the older Macs. I'm not sure if the pinout is identical or not, but you can get a matching connector in the Mac section of CompUSA and re-wire the other end if you have too. The audio connectors are like a standard PC. The keyboard and mouse appear to be standard PS/2 variety. Amazingly, I even had a QueCat and hacked Linux driver for it working under Irix when I played with that durring its ten minutes of fame. Mine is an extreeme, but I suspect your Impact uses the same identical 13W3 connector, DB25 shell with 3 mini coax inserted with a dozen or so regular pins. The video will be sync on green. There's some comments on the reputable site on what it takes to get some monitors to use that. There's a small flat connector near the audio that has lots of really tiny pins in it. That is the external SCSI. This should get you started. If you have any other general questions, email me off list and I'll point you in the right direction. -- J. Scott Kasten Email: jsk AT tetracon-eng DOT net "Nearly all men can stand adversity, but if you want to test a man's charater, give him power. - A Lincoln" On Thu, 9 Aug 2001, Mike McDonald wrote: > > I just got a R10K I2 Solid Impact that I'm going to attempt to play > with linux on. But first I need to find some more basic info. Does > anyone know where the connectors are documented? In particular, the > video connectors on the Solid Impact. The SGI search engine just tells > be they don't refurbish Indigos anymore. The serial port pinouts would > be useful too. (Wasn't it 'man serial' once I get it running?) > > It's been a while since I've played with an SGI, so any helpful > information will be greatly appreciated. > > Mike McDonald > mikemac@mikemac.com > From owner-linux-mips@oss.sgi.com Thu Aug 9 21:55:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A4tPY02281 for linux-mips-outgoing; Thu, 9 Aug 2001 21:55:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A4tOV02278 for ; Thu, 9 Aug 2001 21:55:24 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 87CAC125C3; Thu, 9 Aug 2001 21:55:23 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id EFCF2EFB6; Thu, 9 Aug 2001 21:55:22 -0700 (PDT) Date: Thu, 9 Aug 2001 21:55:22 -0700 From: "H . J . Lu" To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Problems mounting RedHat 7.0 or 7.1 from oss.sgi site Message-ID: <20010809215522.A1958@lucon.org> References: <20010809175131.D30160@paradigm.rfc822.org> <20010810002937.56073.qmail@web11902.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010810002937.56073.qmail@web11902.mail.yahoo.com>; from wgowcher@yahoo.com on Thu, Aug 09, 2001 at 05:29:37PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 05:29:37PM -0700, Wayne Gowcher wrote: > I have tried unsuccessfully to use the root > filesystems > mipselroot-rh7-20010606.tar.bz2 > and H.J.Lu's RedHat 7.1 install from the sgi ftp site. > > Both give me warnings immeadiately about the files > they are trying to access : > Your kernel is very old. You have to have kernel 2.4.3 or above to use mine stuff. H.J. From owner-linux-mips@oss.sgi.com Thu Aug 9 22:38:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A5cMm02690 for linux-mips-outgoing; Thu, 9 Aug 2001 22:38:22 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A5cHV02687; Thu, 9 Aug 2001 22:38:17 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA13815; Fri, 10 Aug 2001 07:38:15 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA24389; Fri, 10 Aug 2001 07:38:15 +0200 (CEST) Date: Fri, 10 Aug 2001 07:38:15 +0200 (CEST) From: Seth Mos To: Ralf Baechle cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: <20010810035106.A23548@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Ralf Baechle wrote: > On Thu, Aug 09, 2001 at 08:53:11PM -0400, Brandon Barker wrote: > > > My intel workstation uses SGI's XFS Installer to create partitions with XFS > > for Redhat 7.1 before it is installed, along with installing a modified > > kernel and utilitiies. I was wondering if there is anything like this for > > Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition > > for use with linux. > > Don't take my answer as authoritative for XFS stuff - the directory format > of XFS on disk has somewhen been changed; the Linux version only supports > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > flavours are incompatible. True, linux suports only v2. I don't know if Irix 6.2 supports the v2 mode. Another thing to watch out for is that the blocksize must equal pagesize to be able to als mount it under linux. This has different size on different architectures. Most are 4k but ia64 is variable from 2 - 16k or so. This exlpained a bit in the FAQ http://oss.sgi.com/projects/xfs/faq.html I will cc the linux-xfs list for an answer on which Irix versions can support the v2 format. > Ralf > Cheers Seth From owner-linux-mips@oss.sgi.com Thu Aug 9 23:09:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A69iA03150 for linux-mips-outgoing; Thu, 9 Aug 2001 23:09:44 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A69eV03129; Thu, 9 Aug 2001 23:09:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) 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 XAA05920; Thu, 9 Aug 2001 23:08:32 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23914; Fri, 10 Aug 2001 16:08:20 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA17338; Fri, 10 Aug 2001 16:08:20 +1000 (AEST) Date: Fri, 10 Aug 2001 16:08:19 +1000 From: Nathan Scott To: Seth Mos Cc: Ralf Baechle , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810160819.D279562@wobbly.melbourne.sgi.com> References: <20010810035106.A23548@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knuffie@xs4all.nl on Fri, Aug 10, 2001 at 07:38:15AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > On Fri, 10 Aug 2001, Ralf Baechle wrote: > > > On Thu, Aug 09, 2001 at 08:53:11PM -0400, Brandon Barker wrote: > > > > > My intel workstation uses SGI's XFS Installer to create partitions with XFS > > > for Redhat 7.1 before it is installed, along with installing a modified > > > kernel and utilitiies. I was wondering if there is anything like this for > > > Linux Mips (on Indys), or if IRIX 6.2 can create a compatible XFS partition > > > for use with linux. > > > > Don't take my answer as authoritative for XFS stuff - the directory format > > of XFS on disk has somewhen been changed; the Linux version only supports > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > flavours are incompatible. > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > mode. Another thing to watch out for is that the blocksize must equal > pagesize to be able to als mount it under linux. > > This has different size on different architectures. Most are 4k but ia64 > is variable from 2 - 16k or so. > > This exlpained a bit in the FAQ http://oss.sgi.com/projects/xfs/faq.html > > I will cc the linux-xfs list for an answer on which Irix versions can > support the v2 format. V2 directories were first introduced in 6.5.5 and, AFAICT, there was no IRIX 6.2 patch. The default XFS blocksize on an Indy is 4K, you shouldn't have any trouble there. You could upgrade your Indy to a recent IRIX (6.5 has been around for 3+ years now...) or figure out what's wrong with the v1 directory support on Linux - can't remember what the issues were there, but the code is all still in the tree, might be just a "simple matter of programming". I thought RedHat dropped MIPS as a platform awhile back, so you may be out of luck on the installer front (I'll toss you back to the mips list on that one, I really don't know). cheers. -- Nathan From owner-linux-mips@oss.sgi.com Fri Aug 10 01:55:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A8tps06032 for linux-mips-outgoing; Fri, 10 Aug 2001 01:55:51 -0700 Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A8tnV06029 for ; Fri, 10 Aug 2001 01:55:50 -0700 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by mout02.kundenserver.de with esmtp (Exim 2.12 #2) id 15V856-00020F-00; Fri, 10 Aug 2001 10:55:48 +0200 Received: from pd9007d27.dip.t-dialin.net ([217.0.125.39] helo=shodan) by mrvdom03.schlund.de with smtp (Exim 2.12 #2) id 15V855-0000wN-00; Fri, 10 Aug 2001 10:55:48 +0200 Message-ID: <001701c1217a$3f206960$277d00d9@shodan> From: "Armin F. Gnosa" To: "Florian Lohoff" Cc: References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Date: Fri, 10 Aug 2001 10:54:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > If anyone can read out different proms i would happy to put them > somewhere on the net. I guess the Dec/Compaq whoever guys who might > own the copyright dont bother after at least 10-15 years. There are > proms who are not able to boot from the net which could be solved just > by burning a new eprom. That would certainly be an interesting institution to which I would contribute, but for the sake if the webmaster those copyright matters have to be cleared before. :-) From owner-linux-mips@oss.sgi.com Fri Aug 10 01:58:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A8wUT06121 for linux-mips-outgoing; Fri, 10 Aug 2001 01:58:30 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A8wQV06118 for ; Fri, 10 Aug 2001 01:58:27 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA03733; Fri, 10 Aug 2001 11:00:41 +0200 (MET DST) Date: Fri, 10 Aug 2001 11:00:40 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 In-Reply-To: <20010809183552.B25724@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote: > I'm not that sure. Does there always exist a "clean" PROM? For > example, I'm searching for a tftp/bootp enabled PROM for a > DEC 5000/240 (or was it /200?). Does anybody have sth like this? Look at 'http://www.netbsd.org/Ports/pmax/board-list.html'. They list MB ROMs only, though. Note that certain options (FDDI controllers) have a Flash ROM that is soldered to the PCB, so they can only be updated via appropriate software. -- + 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 Aug 10 02:09:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A99mj06392 for linux-mips-outgoing; Fri, 10 Aug 2001 02:09:48 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A99fV06388 for ; Fri, 10 Aug 2001 02:09:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA03906; Fri, 10 Aug 2001 11:11:58 +0200 (MET DST) Date: Fri, 10 Aug 2001 11:11:58 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 In-Reply-To: <20010809182047.A25724@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote: > I volunteer to provide all PROMs I can find @home. However, someone > has to read them as I don't have an EPROM burner:-( I'm not sure how exactly the ROMs are wired (they're usually 8-bit); hopefully in a "natural" way. You can read most of ROMs under Linux via mmap()ping /dev/mem -- parts of ROMs may not be directly available to the host CPU if they contain option's CPU firmware. The MB ROM is remapped (byte-merged) by the chipset so that it can be read in 32-bit quantities as parts of it get executed directly (the I/O ASIC permits switching the byte merging off). Option ROMs are not remapped as they always get copied to the system RAM before execution. Their organization can be read from their headers as specified by the TURBOchannel firmware specification. -- + 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 Aug 10 02:10:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A9AaA06464 for linux-mips-outgoing; Fri, 10 Aug 2001 02:10:36 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A9AZV06460 for ; Fri, 10 Aug 2001 02:10:35 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 3441DC4FE; Fri, 10 Aug 2001 11:10:33 +0200 (CEST) Date: Fri, 10 Aug 2001 11:10:33 +0200 From: Jan-Benedict Glaw To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010810111033.B760@lug-owl.de> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20010809183552.B25724@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Aug 10, 2001 at 11:00:40AM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2001-08-10 11:00:40 +0200, Maciej W. Rozycki wrote in message : > On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote: > > > I'm not that sure. Does there always exist a "clean" PROM? For > > example, I'm searching for a tftp/bootp enabled PROM for a > > DEC 5000/240 (or was it /200?). Does anybody have sth like this? > > Look at 'http://www.netbsd.org/Ports/pmax/board-list.html'. They list MB > ROMs only, though. Note that certain options (FDDI controllers) have a > Flash ROM that is soldered to the PCB, so they can only be updated via > appropriate software. Or via a soldering iron:-) I don't fear using it, but currently I don't own an EPROM burner:-( MfG, JBG From owner-linux-mips@oss.sgi.com Fri Aug 10 02:13:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7A9Dul06606 for linux-mips-outgoing; Fri, 10 Aug 2001 02:13:56 -0700 Received: from secure.webhotel.net (secure.webhotel.net [195.41.202.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7A9DsV06603 for ; Fri, 10 Aug 2001 02:13:54 -0700 Received: (qmail 128217484 invoked from network); 10 Aug 2001 09:14:01 -0000 Received: from mail-gateway.webhotel.net (195.41.202.215) by mail.webhotel.net with SMTP; 10 Aug 2001 09:14:01 -0000 X-Authenticated-Timestamp: 11:14:01(CEST) on August 10, 2001 Message-ID: <3B73A5D0.1050202@nellemann.nu> Date: Fri, 10 Aug 2001 11:13:52 +0200 From: Mark Nellemann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips mail list Subject: Is it possible to boot linux on an O2 r5k ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm confused. I was told on irc a month ago, that someone had gotten an O2 to boot. Yesterday I tried to fire up my O2. The whole bootp, tftp setup was working fine, but when I boot'ed the kernel (linux-2.4.3-ip22) the kernel said "Yee, could not determine architecture type ". Is this because i'm using a wrong kernel or isn't it possible to boot the O2 yet ? /Mark From owner-linux-mips@oss.sgi.com Fri Aug 10 04:21:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABLG009148 for linux-mips-outgoing; Fri, 10 Aug 2001 04:21:16 -0700 Received: from dea.waldorf-gmbh.de (u-187-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABLCV09126; Fri, 10 Aug 2001 04:21:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABJsg24044; Fri, 10 Aug 2001 13:19:54 +0200 Date: Fri, 10 Aug 2001 13:19:54 +0200 From: Ralf Baechle To: Seth Mos Cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810131954.C23866@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knuffie@xs4all.nl on Fri, Aug 10, 2001 at 07:38:15AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > of XFS on disk has somewhen been changed; the Linux version only supports > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > flavours are incompatible. > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > mode. Another thing to watch out for is that the blocksize must equal > pagesize to be able to als mount it under linux. Urg. MIPS also supports various page sizes and so this will limit the use of XFS for file exchange. Is this planned to be fixed? Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 04:21:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABLMk09222 for linux-mips-outgoing; Fri, 10 Aug 2001 04:21:22 -0700 Received: from dea.waldorf-gmbh.de (u-187-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABLGV09147; Fri, 10 Aug 2001 04:21:16 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABHgV24035; Fri, 10 Aug 2001 13:17:42 +0200 Date: Fri, 10 Aug 2001 13:17:42 +0200 From: Ralf Baechle To: Nathan Scott Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810131742.B23866@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> <20010810160819.D279562@wobbly.melbourne.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: <20010810160819.D279562@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 10, 2001 at 04:08:19PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Nathan, On Fri, Aug 10, 2001 at 04:08:19PM +1000, Nathan Scott wrote: > I thought RedHat dropped MIPS as a platform awhile back, so you may > be out of luck on the installer front (I'll toss you back to the mips > list on that one, I really don't know). Redhat supports MIPS as an embedded target; the only port of their standard distro they ever publshed was Hardhat Linux aka Rough Cuts which was a four CD collection of ports of Redhat to various architectures. (The name Hardhat has been recycled later on by Montavista for their embedded product which is totally unrelated.) Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 04:22:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABMIR09399 for linux-mips-outgoing; Fri, 10 Aug 2001 04:22:18 -0700 Received: from dea.waldorf-gmbh.de (u-187-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABMCV09375 for ; Fri, 10 Aug 2001 04:22:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABKul24055; Fri, 10 Aug 2001 13:20:56 +0200 Date: Fri, 10 Aug 2001 13:20:56 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010810132056.D23866@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Fri, Aug 10, 2001 at 01:59:59PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 01:59:59PM +1000, Salisbury, Roger wrote: > how would I update /usr/bin/file ?? > ./configure spits this out > > *** Warning: the command libtool uses to detect shared libraries, > *** /usr/bin/file, produces output that libtool cannot recognize. > *** The result is that libtool may fail to recognize shared libraries > *** as such. This will affect the creation of libtool libraries that > *** depend on shared libraries, but programs linked with such libtool > *** libraries will work regardless of this problem. Nevertheless, you > *** may want to report the problem to your system manager and/or to > *** bug-libtool@gnu.org That's a libtool bug. My RH 7.0 port has the fix. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 04:31:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABVaq09702 for linux-mips-outgoing; Fri, 10 Aug 2001 04:31:36 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABVZV09699 for ; Fri, 10 Aug 2001 04:31:35 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 227F11604; Fri, 10 Aug 2001 13:31:33 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 057A74501; Fri, 10 Aug 2001 12:33:58 +0200 (CEST) Date: Fri, 10 Aug 2001 12:33:58 +0200 From: Florian Lohoff To: "Armin F. Gnosa" Cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010810123358.D12247@paradigm.rfc822.org> References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <001701c1217a$3f206960$277d00d9@shodan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <001701c1217a$3f206960$277d00d9@shodan>; from armin@gnosa.com on Fri, Aug 10, 2001 at 10:54:46AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 10:54:46AM +0200, Armin F. Gnosa wrote: > > That would certainly be an interesting institution to which I would > contribute, but for the sake if the webmaster those copyright matters > have to be cleared before. :-) > As i said - I dont think anyone cares - I dont think anyone is able to tell who is the current copyright holder for the Decstation stuff so - sue me ... Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Fri Aug 10 04:43:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ABhYh10186 for linux-mips-outgoing; Fri, 10 Aug 2001 04:43:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ABhUV10165; Fri, 10 Aug 2001 04:43:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) 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 EAA05053; Fri, 10 Aug 2001 04:42:21 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA25379; Fri, 10 Aug 2001 21:42:12 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA90837; Fri, 10 Aug 2001 21:42:11 +1000 (EST) Date: Fri, 10 Aug 2001 21:42:11 +1000 From: Nathan Scott To: Ralf Baechle Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810214211.B282097@wobbly.melbourne.sgi.com> References: <20010810035106.A23548@bacchus.dhis.org> <20010810131954.C23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010810131954.C23866@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, Aug 10, 2001 at 01:19:54PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, On Fri, Aug 10, 2001 at 01:19:54PM +0200, Ralf Baechle wrote: > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > > > of XFS on disk has somewhen been changed; the Linux version only supports > > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > > flavours are incompatible. > > > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > > mode. Another thing to watch out for is that the blocksize must equal > > pagesize to be able to als mount it under linux. > > Urg. MIPS also supports various page sizes and so this will limit the > use of XFS for file exchange. Is this planned to be fixed? > Yes, for the filesystem blocksize < pagesize case anyway - slated for Linux/XFS 1.1. On IRIX mkfs defaults to a 4K blocksize, which is fortunate I guess. IRIX/XFS supports 512byte through to 64K blocksizes, so having variable page sizes on Linux/MIPS actually makes sharing easier on MIPS than on many other architectures. cheers. -- Nathan From owner-linux-mips@oss.sgi.com Fri Aug 10 06:32:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ADWQd12302 for linux-mips-outgoing; Fri, 10 Aug 2001 06:32:26 -0700 Received: from mout04.kundenserver.de (mout04.kundenserver.de [195.20.224.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ADWPV12299 for ; Fri, 10 Aug 2001 06:32:25 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by mout04.kundenserver.de with esmtp (Exim 2.12 #2) id 15VCOe-00043V-00; Fri, 10 Aug 2001 15:32:16 +0200 Received: from pd9007d28.dip.t-dialin.net ([217.0.125.40] helo=shodan) by mrvdom00.schlund.de with smtp (Exim 2.12 #2) id 15VCOd-0007s8-00; Fri, 10 Aug 2001 15:32:15 +0200 Message-ID: <002601c121a0$de4f2fa0$237900d9@shodan> From: "Armin F. Gnosa" To: "Maciej W. Rozycki" Cc: References: Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Date: Fri, 10 Aug 2001 15:32:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I'm not sure how exactly the ROMs are wired (they're usually 8-bit); > hopefully in a "natural" way. You can read most of ROMs under Linux via > mmap()ping /dev/mem -- parts of ROMs may not be directly available to the > host CPU if they contain option's CPU firmware. The MB ROM is remapped > (byte-merged) by the chipset so that it can be read in 32-bit quantities > as parts of it get executed directly (the I/O ASIC permits switching the > byte merging off). Option ROMs are not remapped as they always get copied > to the system RAM before execution. Their organization can be read from > their headers as specified by the TURBOchannel firmware specification. That sounds like an interesting alternative to pulling the PROM out of its socket. Then, a program running on a DECStation 5000/200 should be reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte Merging: Does it mean that I don't have to read bytewise but instead DWORD-wise? Regards, Armin From owner-linux-mips@oss.sgi.com Fri Aug 10 06:36:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ADaR312399 for linux-mips-outgoing; Fri, 10 Aug 2001 06:36:27 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ADaOV12396 for ; Fri, 10 Aug 2001 06:36:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07315; Fri, 10 Aug 2001 15:37:58 +0200 (MET DST) Date: Fri, 10 Aug 2001 15:37:58 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010810132056.D23866@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Ralf Baechle wrote: > That's a libtool bug. My RH 7.0 port has the fix. Libtool doesn't really need the file program for decent shared library systems. Linux/ELF is one of them and the current CVS version of libtool shouldn't depend on file for MIPS/Linux anymore. -- + 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 Aug 10 06:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ADmbF12607 for linux-mips-outgoing; Fri, 10 Aug 2001 06:48:37 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ADmWV12604; Fri, 10 Aug 2001 06:48:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA974927; Fri, 10 Aug 2001 15:47:21 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2681294; Fri, 10 Aug 2001 08:47:12 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA03690; Fri, 10 Aug 2001 08:47:12 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7ADkQ307720; Fri, 10 Aug 2001 08:46:26 -0500 Message-Id: <200108101346.f7ADkQ307720@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ralf Baechle cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: Message from Ralf Baechle of "Fri, 10 Aug 2001 13:19:54 +0200." <20010810131954.C23866@bacchus.dhis.org> Date: Fri, 10 Aug 2001 08:46:26 -0500 From: Steve Lord Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > > > > of XFS on disk has somewhen been changed; the Linux version only supports > > > v2 while IRIX 6.2 is rather old so I think only supports v1. Thus both > > > flavours are incompatible. > > > > True, linux suports only v2. I don't know if Irix 6.2 supports the v2 > > mode. Another thing to watch out for is that the blocksize must equal > > pagesize to be able to als mount it under linux. > > Urg. MIPS also supports various page sizes and so this will limit the > use of XFS for file exchange. Is this planned to be fixed? The page size == block size will get fixed, we need to do that, but it may take a while. Block size less than pagesize will come first, blocksize greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to be on the cards for 2.5. V1 directories mostly work in Linux, but there are glibc getdents issues with them. The glibc code which lseeks backwards in a directory is the issue, if you have control over your glibc it can be fixed by using the 64 bit version of lseek in this code. This is all because the directory offset in V1 is a 64 bit hash value, not a 32 bit signed number. Steve > > Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 07:18:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEIw313488 for linux-mips-outgoing; Fri, 10 Aug 2001 07:18:58 -0700 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEIqV13467; Fri, 10 Aug 2001 07:18:52 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA19646; Fri, 10 Aug 2001 16:18:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20010810161107.032d5ee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 16:18:07 +0200 To: Steve Lord , Ralf Baechle From: Seth Mos Subject: Re: XFS installer Cc: Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <200108101346.f7ADkQ307720@jen.americas.sgi.com> References: <20010810131954.C23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk At 08:46 10-8-2001 -0500, Steve Lord wrote: > > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: >V1 directories mostly work in Linux, but there are glibc getdents issues >with them. The glibc code which lseeks backwards in a directory is the issue, >if you have control over your glibc it can be fixed by using the 64 bit >version of lseek in this code. This is all because the directory offset in >V1 is a 64 bit hash value, not a 32 bit signed number. Would this have adverse effects on existing code if this would be changed? Is it something that can be done without pulling out everything from beneath us? Does userspace need to be recompiled? Would something like this be needed for other architectures as well? If this can become standard in glibc we can tell people that it is supported from glibc 2.2.? systems and higher. Would a workaround in the kernel code even be a possibility. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-mips@oss.sgi.com Fri Aug 10 07:35:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEZFN13957 for linux-mips-outgoing; Fri, 10 Aug 2001 07:35:15 -0700 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEZCV13951; Fri, 10 Aug 2001 07:35:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7AEejW14760; Fri, 10 Aug 2001 07:40:45 -0700 Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2680720; Fri, 10 Aug 2001 09:33:50 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA01468; Fri, 10 Aug 2001 09:33:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7AEX4P07846; Fri, 10 Aug 2001 09:33:04 -0500 Message-Id: <200108101433.f7AEX4P07846@jen.americas.sgi.com> To: Seth Mos cc: Steve Lord , Ralf Baechle , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer References: <20010810131954.C23866@bacchus.dhis.org> <4.3.2.7.2.20010810161107.032d5ee8@pop.xs4all.nl> Comments: In-reply-to Seth Mos message dated "Fri, 10 Aug 2001 16:18:07 +0200." Date: Fri, 10 Aug 2001 09:33:04 -0500 From: Steve Lord Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > At 08:46 10-8-2001 -0500, Steve Lord wrote: > > > On Fri, Aug 10, 2001 at 07:38:15AM +0200, Seth Mos wrote: > >V1 directories mostly work in Linux, but there are glibc getdents issues > >with them. The glibc code which lseeks backwards in a directory is the issue > , > >if you have control over your glibc it can be fixed by using the 64 bit > >version of lseek in this code. This is all because the directory offset in > >V1 is a 64 bit hash value, not a 32 bit signed number. > > Would this have adverse effects on existing code if this would be changed? > Is it something that can be done without pulling out everything from > beneath us? Does userspace need to be recompiled? Would something like this > be needed for other architectures as well? This is only needed if reasonable V1 directory support is required on Linux, without it you can get files missing in directories etc. In fact even with it this can still happen. This was the whole reason we made V2 the default on Linux (we finally won the battle to make it the default on Irix too). > > If this can become standard in glibc we can tell people that it is > supported from glibc 2.2.? systems and higher. All attempts to get glibc to budge on this have failed. > > Would a workaround in the kernel code even be a possibility. I am not sure, no time to think about it right now... Steve > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-mips@oss.sgi.com Fri Aug 10 07:45:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEjOd14297 for linux-mips-outgoing; Fri, 10 Aug 2001 07:45:24 -0700 Received: from dea.waldorf-gmbh.de (u-65-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEj7V14276; Fri, 10 Aug 2001 07:45:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ACcDS24442; Fri, 10 Aug 2001 14:38:13 +0200 Date: Fri, 10 Aug 2001 14:38:13 +0200 From: Ralf Baechle To: Nathan Scott Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810143813.A24347@bacchus.dhis.org> References: <20010810035106.A23548@bacchus.dhis.org> <20010810131954.C23866@bacchus.dhis.org> <20010810214211.B282097@wobbly.melbourne.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: <20010810214211.B282097@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Aug 10, 2001 at 09:42:11PM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 09:42:11PM +1000, Nathan Scott wrote: > > Urg. MIPS also supports various page sizes and so this will limit the > > use of XFS for file exchange. Is this planned to be fixed? > > Yes, for the filesystem blocksize < pagesize case anyway - slated > for Linux/XFS 1.1. On IRIX mkfs defaults to a 4K blocksize, which > is fortunate I guess. > > IRIX/XFS supports 512byte through to 64K blocksizes, so having > variable page sizes on Linux/MIPS actually makes sharing easier > on MIPS than on many other architectures. Some chips now support page sizes of 1kb an higher, so the case of filesystems of large blocksize than pagesize is also going to be of some interest. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 07:49:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEnkO14645 for linux-mips-outgoing; Fri, 10 Aug 2001 07:49:46 -0700 Received: from dea.waldorf-gmbh.de (u-65-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEnbV14624; Fri, 10 Aug 2001 07:49:38 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7AEm7e24931; Fri, 10 Aug 2001 16:48:07 +0200 Date: Fri, 10 Aug 2001 16:48:07 +0200 From: Ralf Baechle To: Steve Lord Cc: Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer Message-ID: <20010810164807.A24889@bacchus.dhis.org> References: <200108101346.f7ADkQ307720@jen.americas.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: <200108101346.f7ADkQ307720@jen.americas.sgi.com>; from lord@sgi.com on Fri, Aug 10, 2001 at 08:46:26AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 08:46:26AM -0500, Steve Lord wrote: > The page size == block size will get fixed, we need to do that, but it > may take a while. Block size less than pagesize will come first, blocksize > greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to > be on the cards for 2.5. > > V1 directories mostly work in Linux, but there are glibc getdents issues > with them. The glibc code which lseeks backwards in a directory is the issue, > if you have control over your glibc it can be fixed by using the 64 bit > version of lseek in this code. This is all because the directory offset in > V1 is a 64 bit hash value, not a 32 bit signed number. So in other words that means using kernel 2.4 / glibc 2.2 and for 32-bit systems building applications with the large file API. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 07:51:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEpqS14855 for linux-mips-outgoing; Fri, 10 Aug 2001 07:51:52 -0700 Received: from dea.waldorf-gmbh.de (u-65-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEpmV14850 for ; Fri, 10 Aug 2001 07:51:48 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7AEnjo24938; Fri, 10 Aug 2001 16:49:45 +0200 Date: Fri, 10 Aug 2001 16:49:45 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010810164945.B24889@bacchus.dhis.org> References: <20010810132056.D23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Aug 10, 2001 at 03:37:58PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 03:37:58PM +0200, Maciej W. Rozycki wrote: > Libtool doesn't really need the file program for decent shared library > systems. Linux/ELF is one of them and the current CVS version of libtool > shouldn't depend on file for MIPS/Linux anymore. We're talking about old code here. The fact that each package based on libtool is carrying it's own copy of libtool around doesn't exactly help to eleminate old libtool copies quickly either. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 07:58:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEwT715124 for linux-mips-outgoing; Fri, 10 Aug 2001 07:58:29 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEwPV15121; Fri, 10 Aug 2001 07:58:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA00509; Fri, 10 Aug 2001 07:56:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2678389; Fri, 10 Aug 2001 09:57:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA20365; Fri, 10 Aug 2001 09:57:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f7AEuMi07997; Fri, 10 Aug 2001 09:56:22 -0500 Message-Id: <200108101456.f7AEuMi07997@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ralf Baechle cc: Steve Lord , Seth Mos , Brandon Barker , linux-mips@oss.sgi.com, linux-xfs@oss.sgi.com Subject: Re: XFS installer In-Reply-To: Message from Ralf Baechle of "Fri, 10 Aug 2001 16:48:07 +0200." <20010810164807.A24889@bacchus.dhis.org> Date: Fri, 10 Aug 2001 09:56:22 -0500 From: Steve Lord Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Fri, Aug 10, 2001 at 08:46:26AM -0500, Steve Lord wrote: > > > The page size == block size will get fixed, we need to do that, but it > > may take a while. Block size less than pagesize will come first, blocksize > > greater than pagesize needs PAGE_CACHE_SIZE to be bumped, which appears to > > be on the cards for 2.5. > > > > V1 directories mostly work in Linux, but there are glibc getdents issues > > with them. The glibc code which lseeks backwards in a directory is the issu > e, > > if you have control over your glibc it can be fixed by using the 64 bit > > version of lseek in this code. This is all because the directory offset in > > V1 is a 64 bit hash value, not a 32 bit signed number. > > So in other words that means using kernel 2.4 / glibc 2.2 and for 32-bit > systems building applications with the large file API. No, it all depends on which version of the glibc getdents code you have, there have been several, I cannot remember what it looks like now. here is an old patch: --- glibc-2.1.3/sysdeps/unix/sysv/linux/getdents.c.orig Fri May 7 09:41:08 1999 +++ glibc-2.1.3/sysdeps/unix/sysv/linux/getdents.c Thu Mar 23 11:49:11 2000 @@ -53,6 +53,9 @@ #ifdef GETDENTS64 # define __getdents __getdents64 # define dirent dirent64 +# undef off_t +# define off_t off64_t +# define __lseek __lseek64 #endif /* The problem here is that we cannot simply read the next NBYTES @@ -107,6 +110,33 @@ } last_offset = kdp->d_off; + +#ifdef GETDENTS64 + if (sizeof(__kernel_off_t) < sizeof(off64_t)) { + /* + * The kernel returns d_off as a 'cookie' that can be used + * in an lseek() to re-position the directory stream. + * "d_off" is signed by current definition of "__kernel_off_t", + * which is consistent with lseek() "off_t" semantics. + * Some file systems, most commonly NFS, may return "d_off" + * 'cookies' that use all 32 bits, or more specifically the + * sign bit. + * This means we need to be careful how we save "last_offset" + * in the case where "last_offset" is defined to be a larger + * container than "__kernel_off_t", we want to prevent the sign + * extension; it's only the lower 32 bits that we want to be + * able to pass back in via lseek64(). + */ + switch(sizeof(__kernel_off_t)) { + case 4: + { + last_offset = (u_int32_t)kdp->d_off; + + break; + } + } + } +#endif dp->d_ino = kdp->d_ino; dp->d_off = kdp->d_off; dp->d_reclen = new_reclen; I am pretty sure this patch is useless with a 2.2 glibc. The issue is not so much the application interface as the fact that glibc has the nasty habit of lseeking back in the directory because its dirent and the kernels are not the same size. Steve From owner-linux-mips@oss.sgi.com Fri Aug 10 08:39:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AFdk516130 for linux-mips-outgoing; Fri, 10 Aug 2001 08:39:46 -0700 Received: from web13906.mail.yahoo.com (web13906.mail.yahoo.com [216.136.175.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AFdjV16127 for ; Fri, 10 Aug 2001 08:39:45 -0700 Message-ID: <20010810153944.89482.qmail@web13906.mail.yahoo.com> Received: from [61.133.135.82] by web13906.mail.yahoo.com; Fri, 10 Aug 2001 08:39:44 PDT Date: Fri, 10 Aug 2001 08:39:44 -0700 (PDT) From: Barry Wu Subject: about mips IDE DMA disk problem To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, all, We port linux-2.2.12 to our mipsel evaluation board. We use Ali 1535D south bridge. Now our disk can work under PIO, I want to work using DMA. I do not know how many places I have to initialize. If someone knows, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Fri Aug 10 08:57:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AFv7r16554 for linux-mips-outgoing; Fri, 10 Aug 2001 08:57:07 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AFv5V16550 for ; Fri, 10 Aug 2001 08:57:06 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15VEgt-0001Di-00; Fri, 10 Aug 2001 16:59:15 +0100 Subject: Re: about mips IDE DMA disk problem To: wqb123@yahoo.com (Barry Wu) Date: Fri, 10 Aug 2001 16:59:15 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: from "Barry Wu" at Aug 10, 2001 08:39:44 AM X-Mailer: ELM [version 2.5 PL5] 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 > We port linux-2.2.12 to our mipsel evaluation board. 2.2.12 is ancient including remotely exploitable security holes. If you update to a vaguely recent 2.2 kernel you'll also find there are ali1535 drivers although I dont think anyone has verified them on mips From owner-linux-mips@oss.sgi.com Fri Aug 10 09:06:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AG6Tl16904 for linux-mips-outgoing; Fri, 10 Aug 2001 09:06:29 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AG6SV16901 for ; Fri, 10 Aug 2001 09:06:28 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3525D1694; Fri, 10 Aug 2001 17:40:37 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 080264503; Fri, 10 Aug 2001 17:37:37 +0200 (CEST) Date: Fri, 10 Aug 2001 17:37:36 +0200 From: Florian Lohoff To: "J. Scott Kasten" Cc: Mike McDonald , linux-mips@oss.sgi.com Subject: Re: R10K I2 Solid Impact Message-ID: <20010810173736.A19516@paradigm.rfc822.org> References: <200108100018.RAA29996@saturn.mikemac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from jsk@tetracon-eng.net on Thu, Aug 09, 2001 at 09:58:30PM -0400 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 09, 2001 at 09:58:30PM -0400, J. Scott Kasten wrote: > particular there is a multi-page SGI FAQ that will answer 70% of your > questions. If I'm not mistaken the serial is RS-422 like on the older > Macs. I'm not sure if the pinout is identical or not, but you can get a It is - I am using a normal RS422 -> DB25 cable bought with a "Mac Modem"... Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Fri Aug 10 09:10:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AGAvo17041 for linux-mips-outgoing; Fri, 10 Aug 2001 09:10:57 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AGAuV17038 for ; Fri, 10 Aug 2001 09:10:56 -0700 Received: (qmail 11549 invoked by uid 502); 10 Aug 2001 16:10:55 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Mark Nellemann , linux-mips mail list Subject: Re: Is it possible to boot linux on an O2 r5k ? Date: Fri, 10 Aug 2001 09:10:52 -0700 X-Mailer: KMail [version 1.2] References: <3B73A5D0.1050202@nellemann.nu> In-Reply-To: <3B73A5D0.1050202@nellemann.nu> MIME-Version: 1.0 Message-Id: <01081009105200.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 10 August 2001 02:13, Mark Nellemann wrote: > I'm confused. > > I was told on irc a month ago, that someone had gotten an O2 to boot. > > Yesterday I tried to fire up my O2. The whole bootp, tftp setup was working > fine, but when I boot'ed the kernel (linux-2.4.3-ip22) the kernel said > "Yee, could not determine architecture type ". Is this because > i'm using a wrong kernel or isn't it possible to boot the O2 yet ? Both. The kernel sources for O2 live in cvs.foobazco.org. Also, there are LOTS of problems. You will need some extra ethernet adapter, for example, since MACE ethernet is not suported. (I am working on it at the moment, but don't hold your breath). NICs that are knownw to work: some tulip-based. NICs that are known not to work: 3c905B-TX... Also, things only work uncached. As you now understand, O2+Linux is kernel-hacker only toy at the moment. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt0B48ACgkQtKh84cA8u2k/AwCeKNmJjvGQesQl8EE2jqwcIXzA VeUAnAwLKa/hCSL/oIyZ8bRc2crbE+rN =1v99 -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Fri Aug 10 11:05:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AI5lE18951 for linux-mips-outgoing; Fri, 10 Aug 2001 11:05:47 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AI5kV18946 for ; Fri, 10 Aug 2001 11:05:46 -0700 Received: (qmail 13247 invoked by uid 502); 10 Aug 2001 18:05:45 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Alan Cox , wqb123@yahoo.com (Barry Wu) Subject: Re: about mips IDE DMA disk problem Date: Fri, 10 Aug 2001 11:05:39 -0700 X-Mailer: KMail [version 1.2] Cc: linux-mips@oss.sgi.com, boards@mips.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01081011053902.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 10 August 2001 08:59, Alan Cox wrote: > > We port linux-2.2.12 to our mipsel evaluation board. > > 2.2.12 is ancient including remotely exploitable security holes. If you > update to a vaguely recent 2.2 kernel you'll also find there are ali1535 > drivers although I dont think anyone has verified them on mips Perhaps somebody should tell MIPS, Inc. people that 2.2.12 on their site is little bit out of date. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt0InkACgkQtKh84cA8u2lxcwCdEM8mRkj63kpxnfaRU2tS9D86 QS8AnjVTo67VGpbgcgnn+nkuHVJW/DQN =4ngI -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Fri Aug 10 11:24:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIObC19309 for linux-mips-outgoing; Fri, 10 Aug 2001 11:24:37 -0700 Received: from dea.waldorf-gmbh.de (u-118-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.118]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIOZV19306 for ; Fri, 10 Aug 2001 11:24:35 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7AINGU25772; Fri, 10 Aug 2001 20:23:16 +0200 Date: Fri, 10 Aug 2001 20:23:16 +0200 From: Ralf Baechle To: Ilya Volynets Cc: Alan Cox , Barry Wu , linux-mips@oss.sgi.com, boards@mips.com Subject: Re: about mips IDE DMA disk problem Message-ID: <20010810202316.A25714@bacchus.dhis.org> References: <01081011053902.07543@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01081011053902.07543@gateway>; from ilya@theIlya.com on Fri, Aug 10, 2001 at 11:05:39AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 11:05:39AM -0700, Ilya Volynets wrote: > > 2.2.12 is ancient including remotely exploitable security holes. If you > > update to a vaguely recent 2.2 kernel you'll also find there are ali1535 > > drivers although I dont think anyone has verified them on mips > Perhaps somebody should tell MIPS, Inc. people that 2.2.12 on their > site is little bit out of date. They're well aware of that - and working on 2.4 Ralf From owner-linux-mips@oss.sgi.com Fri Aug 10 11:27:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIR1g19384 for linux-mips-outgoing; Fri, 10 Aug 2001 11:27:01 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIR0V19380 for ; Fri, 10 Aug 2001 11:27:00 -0700 Received: (qmail 13457 invoked by uid 502); 10 Aug 2001 18:27:00 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Ralf Baechle Subject: Re: about mips IDE DMA disk problem Date: Fri, 10 Aug 2001 11:26:54 -0700 X-Mailer: KMail [version 1.2] Cc: Barry Wu , linux-mips@oss.sgi.com, boards@mips.com References: <01081011053902.07543@gateway> <20010810202316.A25714@bacchus.dhis.org> In-Reply-To: <20010810202316.A25714@bacchus.dhis.org> MIME-Version: 1.0 Message-Id: <01081011265403.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 10 August 2001 11:23, Ralf Baechle wrote: > On Fri, Aug 10, 2001 at 11:05:39AM -0700, Ilya Volynets wrote: > > > 2.2.12 is ancient including remotely exploitable security holes. If you > > > update to a vaguely recent 2.2 kernel you'll also find there are > > > ali1535 drivers although I dont think anyone has verified them on mips > > > > Perhaps somebody should tell MIPS, Inc. people that 2.2.12 on their > > site is little bit out of date. > > They're well aware of that - and working on 2.4 Great! 'cause questions related to 2.2.12 kernel are becoming FAQ. > Ralf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt0J3QACgkQtKh84cA8u2nQHQCfUBdRLJKhnulO0AWli04hxNjU ozYAoKXOiffJtqb5EHVKRVNTbSKa+++k =DiXG -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Fri Aug 10 11:43:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AIhIn19862 for linux-mips-outgoing; Fri, 10 Aug 2001 11:43:18 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AIhGV19859 for ; Fri, 10 Aug 2001 11:43:16 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA09961; Fri, 10 Aug 2001 11:43:09 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA17161; Fri, 10 Aug 2001 11:43:06 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7AIfma13792; Fri, 10 Aug 2001 20:41:48 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id UAA01339; Fri, 10 Aug 2001 20:41:47 +0200 (MET DST) Message-Id: <200108101841.UAA01339@copsun17.mips.com> Subject: Re: about mips IDE DMA disk problem To: ilya@theilya.com, linux-mips@oss.sgi.com Date: Fri, 10 Aug 2001 20:41:47 +0200 (MET DST) In-Reply-To: <01081011265403.07543@gateway> from "Ilya Volynets" at Aug 10, 2001 11:26:54 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 Hi, Ilya Volynets writes: > > They're well aware of that - and working on 2.4 > Great! 'cause questions related to 2.2.12 kernel are becoming FAQ. You can already find 2.4 kernels on ftp.mips.com: ftp> pwd 257 "/pub/linux/mips/kernel/2.4" is current directory. ftp> ls -R 227 Entering Passive Mode (206,31,31,227,157,126) 150 Opening ASCII mode data connection for /bin/ls. total 4 -rw-r--r-- 1 9618 40 1613 Jul 6 04:41 README drwxr-xr-x 2 9618 40 512 Jul 6 05:26 images drwxr-xr-x 2 9618 40 512 Jul 6 05:27 src images: total 8720 -rw-r--r-- 1 9618 40 1103571 Mar 30 05:23 vmlinux-2.4.1.atlas.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 1129920 Mar 30 05:23 vmlinux-2.4.1.atlas.el-01.00.srec.gz -rw-r--r-- 1 9618 40 1061736 Mar 30 05:23 vmlinux-2.4.1.malta.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 1093062 Mar 30 05:23 vmlinux-2.4.1.malta.el-01.00.srec.gz -rw-r--r-- 1 9618 40 1116378 Jul 6 04:35 vmlinux-2.4.3.atlas.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 1144798 Jul 6 04:35 vmlinux-2.4.3.atlas.el-01.00.srec.gz -rw-r--r-- 1 9618 40 1075193 Jul 6 04:35 vmlinux-2.4.3.malta.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 1107586 Jul 6 04:35 vmlinux-2.4.3.malta.el-01.00.srec.gz src: total 50200 -rw-r--r-- 1 9618 40 25100716 Mar 30 05:24 linux-2.4.1.mips-src-01.00.tar.gz -rw-r--r-- 1 9618 40 26239788 Jul 6 04:35 linux-2.4.3.mips-src-01.00.tar.gz 226 Transfer complete. ftp> /Hartvig -- _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com |\ /| | |____)(____ Direct: +45 4486 5503 | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 From owner-linux-mips@oss.sgi.com Fri Aug 10 12:58:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AJwXf23885 for linux-mips-outgoing; Fri, 10 Aug 2001 12:58:33 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AJwVV23879 for ; Fri, 10 Aug 2001 12:58:31 -0700 Received: (qmail 14200 invoked by uid 502); 10 Aug 2001 19:58:30 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Hartvig Ekner , ilya@theIlya.com, linux-mips@oss.sgi.com Subject: Re: about mips IDE DMA disk problem Date: Fri, 10 Aug 2001 12:58:27 -0700 X-Mailer: KMail [version 1.2] References: <200108101841.UAA01339@copsun17.mips.com> In-Reply-To: <200108101841.UAA01339@copsun17.mips.com> MIME-Version: 1.0 Message-Id: <01081012582704.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MIPS web site still lists 2.2.12 kernel as official one coming from MIPS (http://www.mips.com/devTools/catalog_2001/Linux.html) which is probably the reason everyone else is trying to port that one. That's all I was saying. Probably this should have been sent to web master. On Friday 10 August 2001 11:41, Hartvig Ekner wrote: > Hi, > > Ilya Volynets writes: > > > They're well aware of that - and working on 2.4 > > > > Great! 'cause questions related to 2.2.12 kernel are becoming FAQ. > > You can already find 2.4 kernels on ftp.mips.com: > > ftp> pwd > 257 "/pub/linux/mips/kernel/2.4" is current directory. > ftp> ls -R > 227 Entering Passive Mode (206,31,31,227,157,126) > 150 Opening ASCII mode data connection for /bin/ls. > total 4 > -rw-r--r-- 1 9618 40 1613 Jul 6 04:41 README > drwxr-xr-x 2 9618 40 512 Jul 6 05:26 images > drwxr-xr-x 2 9618 40 512 Jul 6 05:27 src > > images: > total 8720 > -rw-r--r-- 1 9618 40 1103571 Mar 30 05:23 > vmlinux-2.4.1.atlas.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 > 1129920 Mar 30 05:23 vmlinux-2.4.1.atlas.el-01.00.srec.gz -rw-r--r-- 1 > 9618 40 1061736 Mar 30 05:23 > vmlinux-2.4.1.malta.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 > 1093062 Mar 30 05:23 vmlinux-2.4.1.malta.el-01.00.srec.gz -rw-r--r-- 1 > 9618 40 1116378 Jul 6 04:35 > vmlinux-2.4.3.atlas.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 > 1144798 Jul 6 04:35 vmlinux-2.4.3.atlas.el-01.00.srec.gz -rw-r--r-- 1 > 9618 40 1075193 Jul 6 04:35 > vmlinux-2.4.3.malta.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 > 1107586 Jul 6 04:35 vmlinux-2.4.3.malta.el-01.00.srec.gz > > src: > total 50200 > -rw-r--r-- 1 9618 40 25100716 Mar 30 05:24 > linux-2.4.1.mips-src-01.00.tar.gz -rw-r--r-- 1 9618 40 26239788 > Jul 6 04:35 linux-2.4.3.mips-src-01.00.tar.gz 226 Transfer complete. > ftp> > > /Hartvig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt0POYACgkQtKh84cA8u2mXdACfV5qmuHKMuToSz5AwH+nAt8a2 CyUAnjdm1jtPtDaSNy13tXRNytvBpDMH =gazA -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Sun Aug 12 06:50:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CDo3s19068 for linux-mips-outgoing; Sun, 12 Aug 2001 06:50:03 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CDo2j19065 for ; Sun, 12 Aug 2001 06:50:02 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA19256 for ; Sun, 12 Aug 2001 06:49:55 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA13095 for ; Sun, 12 Aug 2001 06:49:53 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7CDmZa05366 for ; Sun, 12 Aug 2001 15:48:36 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id PAA02757 for linux-mips@oss.sgi.com; Sun, 12 Aug 2001 15:48:35 +0200 (MET DST) Message-Id: <200108121348.PAA02757@copsun17.mips.com> Subject: Malta kernel config file To: linux-mips@oss.sgi.com Date: Sun, 12 Aug 2001 15:48:35 +0200 (MET DST) 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 I think I saw somebody ask last week how to configure the kernel for the MIPS Malta board. In the tar archives on ftp.mips.com, e.g. linux-2.4.3.mips-src-01.00.tar.gz There are several .config files: /home/hartvige/tmp/linux-2.4.3> ll .config* -r--r----- 1 hartvige mips 11361 May 25 10:59 .config.atlas -r--r----- 1 hartvige mips 11436 May 17 09:59 .config.malta -r--r----- 1 hartvige mips 10681 May 17 10:49 .config.malta.64 Copy or link the right one (in this case .config.malta) to .config, and you're ready to go! /Hartvig From owner-linux-mips@oss.sgi.com Sun Aug 12 13:30:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CKUii23623 for linux-mips-outgoing; Sun, 12 Aug 2001 13:30:44 -0700 Received: from dea.waldorf-gmbh.de (u-132-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CKUfj23620 for ; Sun, 12 Aug 2001 13:30:42 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7CKTKM21341; Sun, 12 Aug 2001 22:29:20 +0200 Date: Sun, 12 Aug 2001 22:29:20 +0200 From: Ralf Baechle To: Hartvig Ekner Cc: linux-mips@oss.sgi.com Subject: Re: Malta kernel config file Message-ID: <20010812222920.A21308@bacchus.dhis.org> References: <200108121348.PAA02757@copsun17.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: <200108121348.PAA02757@copsun17.mips.com>; from hartvige@mips.com on Sun, Aug 12, 2001 at 03:48:35PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Aug 12, 2001 at 03:48:35PM +0200, Hartvig Ekner wrote: > I think I saw somebody ask last week how to configure the kernel > for the MIPS Malta board. > > In the tar archives on ftp.mips.com, e.g. > > linux-2.4.3.mips-src-01.00.tar.gz > > There are several .config files: > > /home/hartvige/tmp/linux-2.4.3> ll .config* > -r--r----- 1 hartvige mips 11361 May 25 10:59 .config.atlas > -r--r----- 1 hartvige mips 11436 May 17 09:59 .config.malta > -r--r----- 1 hartvige mips 10681 May 17 10:49 .config.malta.64 Keeping the sample config files in the root directory of the tree is not a good idea as ``make distclean'' will wipe them away. Ralf From owner-linux-mips@oss.sgi.com Sun Aug 12 13:33:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CKXos23730 for linux-mips-outgoing; Sun, 12 Aug 2001 13:33:50 -0700 Received: from dea.waldorf-gmbh.de (u-132-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CKXlj23725 for ; Sun, 12 Aug 2001 13:33:48 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7CKWJB21356; Sun, 12 Aug 2001 22:32:19 +0200 Date: Sun, 12 Aug 2001 22:32:19 +0200 From: Ralf Baechle To: Florian Lohoff Cc: "Armin F. Gnosa" , linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010812223219.B21308@bacchus.dhis.org> References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <001701c1217a$3f206960$277d00d9@shodan> <20010810123358.D12247@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010810123358.D12247@paradigm.rfc822.org>; from flo@rfc822.org on Fri, Aug 10, 2001 at 12:33:58PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 12:33:58PM +0200, Florian Lohoff wrote: > > That would certainly be an interesting institution to which I would > > contribute, but for the sake if the webmaster those copyright matters > > have to be cleared before. :-) > > > > As i said - I dont think anyone cares - I dont think anyone is able > to tell who is the current copyright holder for the Decstation stuff so > - sue me ... No problem. There is a company who bought all right of DEC is now making some money by supporting those systems. Ralf From owner-linux-mips@oss.sgi.com Sun Aug 12 13:40:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CKeGp23884 for linux-mips-outgoing; Sun, 12 Aug 2001 13:40:16 -0700 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CKeCj23881; Sun, 12 Aug 2001 13:40:12 -0700 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15W21q-0004G3-00; Sun, 12 Aug 2001 22:40:10 +0200 Received: from pc19f1991.dip.t-dialin.net ([193.159.25.145] helo=shodan) by mrvdom04.kundenserver.de with smtp (Exim 2.12 #2) id 15W21p-00019d-00; Sun, 12 Aug 2001 22:40:10 +0200 Message-ID: <003001c1236e$fa730060$91199fc1@shodan> From: "Armin F. Gnosa" To: "Ralf Baechle" , "Florian Lohoff" Cc: References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <001701c1217a$3f206960$277d00d9@shodan> <20010810123358.D12247@paradigm.rfc822.org> <20010812223219.B21308@bacchus.dhis.org> Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Date: Sun, 12 Aug 2001 22:40:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > As i said - I dont think anyone cares - I dont think anyone is able > > to tell who is the current copyright holder for the Decstation stuff so > > - sue me ... > > No problem. There is a company who bought all right of DEC is now making > some money by supporting those systems. So, at least for the worst case, I can still buy a new EPROM there... Regards, Armin From owner-linux-mips@oss.sgi.com Sun Aug 12 13:42:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7CKg4V23972 for linux-mips-outgoing; Sun, 12 Aug 2001 13:42:04 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7CKg2j23969 for ; Sun, 12 Aug 2001 13:42:02 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E54BCC4FE; Sun, 12 Aug 2001 22:41:59 +0200 (CEST) Date: Sun, 12 Aug 2001 22:41:59 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010812224159.H918@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <001701c1217a$3f206960$277d00d9@shodan> <20010810123358.D12247@paradigm.rfc822.org> <20010812223219.B21308@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010812223219.B21308@bacchus.dhis.org>; from ralf@oss.sgi.com on Sun, Aug 12, 2001 at 10:32:19PM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, 2001-08-12 22:32:19 +0200, Ralf Baechle wrote in message <20010812223219.B21308@bacchus.dhis.org>: > On Fri, Aug 10, 2001 at 12:33:58PM +0200, Florian Lohoff wrote: > > > That would certainly be an interesting institution to which I would > > > contribute, but for the sake if the webmaster those copyright matters > > > have to be cleared before. :-) > > As i said - I dont think anyone cares - I dont think anyone is able > > to tell who is the current copyright holder for the Decstation stuff so > > - sue me ... > No problem. There is a company who bought all right of DEC is now making > some money by supporting those systems. "No problem - let's sue Flo" -or- "No problem - noone will sue anybody" If you've heared of that company (which will support those old machines), maybe they're willung to work with us? They've maybe got all legal rights to software/documentation/thousands of kilometers of tape archives, but we're (partially) really working with these machines. So maybe we've got some know-how in practical terms which they maybe do not have... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 From owner-linux-mips@oss.sgi.com Sun Aug 12 18:53:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D1rON27262 for linux-mips-outgoing; Sun, 12 Aug 2001 18:53:24 -0700 Received: from www.ctaragon.com.mx (IDENT:qmailr@integramex4.psi.net.mx [200.39.119.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D1rMj27259 for ; Sun, 12 Aug 2001 18:53:22 -0700 Message-Id: <200108130153.f7D1rMj27259@oss.sgi.com> Received: (qmail 16541 invoked from network); 12 Aug 2001 19:03:33 -0000 Received: from 0-1pool218-71.nas1.madison1.wi.us.da.qwest.net (HELO 63.233.218.71) (63.233.218.71) by portalmaestro.119.39.200.in-addr.arpa with SMTP; 12 Aug 2001 19:03:33 -0000 To: From: f9cclr9l6vjeru9s3uezs9@hotmail.com Subject: Save 50% on Premium Brand Cigarettes! Date: Wed, 15 Aug 2001 02:34:27 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Buy premium cigarett= es for up to 50% off.
Carton Niagra $10.50   Carton Marboro Duty Free $22.00
Click Here to= See the Savings!


Did you know that buying cigarettes on line from America's Discount Ci= garettes you can save you up to 50%. We ship from the Seneca Indian Reserv= ation which saves you having to pay most of those high State and Federal t= axes on each pack. Here's an example of the saving you can expect...  = ;Marboro Box Duty Free $22.00 a carton ..that's only $2.20 per pack!  = ;Salem's $23.00 per carton ..that's only $2.30 per pack. Stop throwing mon= ey away.

Visit our site to= day and start saving today!



This email was sent to you because your email is part of a targeted opt-in= list.  If you do not wish to receive further mailings, please click below and enter your email at the bottom of the page.  You may then rest-assured that= you will never receive another email from us again.  
UNSUBSCRIBE ME PLEASE or visnqmer@yahoo.com
= From owner-linux-mips@oss.sgi.com Sun Aug 12 20:38:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D3cYL28522 for linux-mips-outgoing; Sun, 12 Aug 2001 20:38:34 -0700 Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D3cVj28519 for ; Sun, 12 Aug 2001 20:38:32 -0700 Received: from oz.agile.tv (IDENT:simong@pacific.oz.agile.tv [192.168.16.16]) by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f7D3cUj02355 for ; Mon, 13 Aug 2001 13:38:30 +1000 Message-ID: <3B774FA9.A96C838B@oz.agile.tv> Date: Mon, 13 Aug 2001 13:55:21 +1000 From: Simon Gee Organization: AgileTV Corporation Australia X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: PATCH: missing call-graph data and profiling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk When attempting to use profiling under mips-linux the produced gmon.out file was reported as "missing call -raph data". The problem lay in the fact that the following from machine-gmon.h: "move $5,$31;" \ "jal __mcount;" \ "move $4,$1;" \ was assembled as: 0x432458 <_mcount+40>: move $a1,$ra 0x43245c <_mcount+44>: lw $t9,-32724($gp) 0x432460 <_mcount+48>: nop 0x432464 <_mcount+52>: addiu $t9,$t9,8816 0x432468 <_mcount+56>: jalr $t9 0x43246c <_mcount+60>: nop 0x432470 <_mcount+64>: lw $gp,0($s8) 0x432474 <_mcount+68>: move $a0,$at by gas. Basically, the fact that "jal __mcount" was being expanded forced "move $4,$1;" out of the delay slot which resulted in the first argument to __mcount to be incorrect. The following patch against glibc corrects this problem. *** sysdeps/mips/machine-gmon.h.orig Mon Aug 13 12:17:39 2001 --- sysdeps/mips/machine-gmon.h Mon Aug 13 12:18:00 2001 *************** *** 43,50 **** "sw $1,16($29);" \ "sw $31,20($29);" \ "move $5,$31;" \ - "jal __mcount;" \ "move $4,$1;" \ "lw $4,24($29);" \ "lw $5,28($29);" \ "lw $6,32($29);" \ --- 43,51 ---- "sw $1,16($29);" \ "sw $31,20($29);" \ "move $5,$31;" \ "move $4,$1;" \ + "jal __mcount;" \ + "nop;" \ "lw $4,24($29);" \ "lw $5,28($29);" \ "lw $6,32($29);" \ Simon From owner-linux-mips@oss.sgi.com Sun Aug 12 21:51:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D4ppi29143 for linux-mips-outgoing; Sun, 12 Aug 2001 21:51:51 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D4poj29140 for ; Sun, 12 Aug 2001 21:51:50 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 3AF673E90; Sun, 12 Aug 2001 21:39:43 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id F24E713FD0; Sun, 12 Aug 2001 21:46:15 -0700 (PDT) Date: Sun, 12 Aug 2001 21:46:15 -0700 From: Keith M Wesolowski To: Mark Nellemann Cc: linux-mips mail list Subject: Re: Is it possible to boot linux on an O2 r5k ? Message-ID: <20010812214615.B24560@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B73A5D0.1050202@nellemann.nu> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 11:13:52AM +0200, Mark Nellemann wrote: > I was told on irc a month ago, that someone had gotten an O2 to boot. You were not lied to. http://foobazco.org/~wesolows/o2.txt > Yesterday I tried to fire up my O2. The whole bootp, tftp setup was working > fine, but when I boot'ed the kernel (linux-2.4.3-ip22) the kernel said "Yee, > could not determine architecture type ". Is this because i'm using a > wrong kernel or isn't it possible to boot the O2 yet ? Certainly not with that kernel. You need a modified kernel that understands O2 (and a 64-bit kernel toolchain to build it). -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Sun Aug 12 22:00:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D50GS29299 for linux-mips-outgoing; Sun, 12 Aug 2001 22:00:16 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D50Fj29295 for ; Sun, 12 Aug 2001 22:00:15 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 226513E90; Sun, 12 Aug 2001 21:48:05 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 1877513FD0; Sun, 12 Aug 2001 21:54:43 -0700 (PDT) Date: Sun, 12 Aug 2001 21:54:42 -0700 From: Keith M Wesolowski To: Ilya Volynets Cc: Mark Nellemann , linux-mips mail list Subject: Re: Is it possible to boot linux on an O2 r5k ? Message-ID: <20010812215442.C24560@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01081009105200.07543@gateway> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 09:10:52AM -0700, Ilya Volynets wrote: > Both. The kernel sources for O2 live in cvs.foobazco.org. Also, > there are LOTS of problems. You will need some extra ethernet > adapter, for example, since MACE ethernet is not suported. (I am > working on it at the moment, but don't hold your breath). NICs that > are knownw to work: some tulip-based. NICs that are known not to > work: 3c905B-TX... Also eepro100 has worked for me in the past. Someone should investigate why the 3c doesn't work; probably the driver is doing something forbidden. While we're at it, someone should sync that tree with oss again. It doesn't appear likely that I'll be working on it for some time, if ever. > Also, things only work uncached. Well, even then I can't really claim that it "works" for any standard meaning of the word. Frankly, I'd rather people start running cached so that those problems can get fixed, especially since running cached isn't really *that* much worse anyway. > As you now understand, O2+Linux is kernel-hacker only toy at the moment. Isn't that the rule? Completeness of Linux support is directly proportional to the degree of obsolescence of the hardware. You want full support, just run Irix... it's not like it's windows or anything. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Sun Aug 12 22:07:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D57eF29414 for linux-mips-outgoing; Sun, 12 Aug 2001 22:07:40 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D57dj29411 for ; Sun, 12 Aug 2001 22:07:39 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 58C573E90; Sun, 12 Aug 2001 21:55:32 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 81DDC13FD0; Sun, 12 Aug 2001 22:02:10 -0700 (PDT) Date: Sun, 12 Aug 2001 22:02:10 -0700 From: Keith M Wesolowski To: "Salisbury, Roger" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: FW: indigo2 kernel build failures Message-ID: <20010812220210.D24560@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 10, 2001 at 11:31:58AM +1000, Salisbury, Roger wrote: > > I just wondering if the UNKNOW aspect "mips-unknown-linux-gnu" of > > building packages has some detrimental affect > > on the success of building a kernel. > > IE > > The machine status isn't detected properly. Nope. Even if it did the kernel wouldn't care. Build gcc on a peecee sometime and you'll see "i386-unknown-linux-gnu" and it will work as well as gcc ever does. Have some fun with it - maybe "mips-fuckmeinthegoatass-linux-gnu" (STR) for your amusement or "mips-notintel-linux-gnu" to make a statement. It won't affect anything. Leave off the -gnu, though, and configure will kindly add it back on, reminding you that it is, in fact, GNU/Linux, dammit. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Sun Aug 12 22:13:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D5Dwc29520 for linux-mips-outgoing; Sun, 12 Aug 2001 22:13:58 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D5Dvj29517 for ; Sun, 12 Aug 2001 22:13:57 -0700 Received: (qmail 12221 invoked by uid 502); 13 Aug 2001 05:13:56 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Keith M Wesolowski Subject: Re: Is it possible to boot linux on an O2 r5k ? Date: Sun, 12 Aug 2001 22:13:53 -0700 X-Mailer: KMail [version 1.2] Cc: Mark Nellemann , linux-mips mail list References: <20010812215442.C24560@foobazco.org> In-Reply-To: <20010812215442.C24560@foobazco.org> MIME-Version: 1.0 Message-Id: <0108122213530C.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 12 August 2001 21:54, Keith M Wesolowski wrote: > Also eepro100 has worked for me in the past. Someone should > investigate why the 3c doesn't work; probably the driver is doing > something forbidden. While we're at it, someone should sync that tree > with oss again. It doesn't appear likely that I'll be working on it > for some time, if ever. I think Nick wanted to take over this. At least he said he'd try. > > Also, things only work uncached. > > Well, even then I can't really claim that it "works" for any standard > meaning of the word. Frankly, I'd rather people start running cached > so that those problems can get fixed, especially since running cached > isn't really *that* much worse anyway. I'll get on it as soon as I get MACE Ethernet driver working. > > As you now understand, O2+Linux is kernel-hacker only toy at the moment. > > Isn't that the rule? Completeness of Linux support is directly > proportional to the degree of obsolescence of the hardware. You want > full support, just run Irix... it's not like it's windows or anything. I don't know if this discussion should be started again, but I can't stop myself from saing that having Linux supporting SGI MIPS machines as well as it does SPARC64 machines would be very pleasant thing to have. Everyone knows that Slowlaris is rock-solid OS, but I am yet to see a person that doesn't like Linux on SUN machines. I want to be able to say same thing about O2, Octane, and Onyx[2] systems some time soon (wish wish wish....). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt3YhQACgkQtKh84cA8u2kbjACaA2O/hf9+FhPOIe/yQU+IlMxU 6EsAn0cdQihzuUIws9AH7394ITRPa2Mx =hJez -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Mon Aug 13 01:44:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7D8i8Z00822 for linux-mips-outgoing; Mon, 13 Aug 2001 01:44:08 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7D8i7j00819 for ; Mon, 13 Aug 2001 01:44:07 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 57E281E66A; Mon, 13 Aug 2001 10:43:52 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: Simon Gee Cc: linux-mips@oss.sgi.com Subject: Re: PATCH: missing call-graph data and profiling References: <3B774FA9.A96C838B@oz.agile.tv> From: Andreas Jaeger Date: Mon, 13 Aug 2001 10:43:47 +0200 In-Reply-To: <3B774FA9.A96C838B@oz.agile.tv> (Simon Gee's message of "Mon, 13 Aug 2001 13:55:21 +1000") Message-ID: Lines: 10 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks, I've committed this to the CVS archive. Please send glibc patches next time to the glibc mailing list, 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 Mon Aug 13 04:28:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DBSjR04863 for linux-mips-outgoing; Mon, 13 Aug 2001 04:28:45 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DBScj04858 for ; Mon, 13 Aug 2001 04:28:38 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19659; Mon, 13 Aug 2001 13:30:30 +0200 (MET DST) Date: Mon, 13 Aug 2001 13:30:30 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Armin F. Gnosa" cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 In-Reply-To: <002601c121a0$de4f2fa0$237900d9@shodan> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Armin F. Gnosa wrote: > That sounds like an interesting alternative to pulling the PROM out of > its socket. Then, a program running on a DECStation 5000/200 should be > reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte > Merging: Does it mean that I don't have to read bytewise but instead > DWORD-wise? The system ROM is mapped from 0x1f800000 up to 0x1f83fffff (and repeated at 0x1fc00000) and is 256kB in size on my /240. Although I cannot verify it, docs state that the /200 contains the following ROMs: - the system ROM from 0x1fc00000 up to 0x1fc7ffff (repeated at 0x1ff80000), 256kB in size, - the PMAD-A ROM from 0x1f9c0000 up to 0x1f9fffff, 32kB in size, - the PMAZ-A ROM from 0x1f4c0000 up to 0x1f4fffff, 32kB in size. The system ROMs are presented on the whole data bus, while the option ROMs are only presented on 8 least significant bits. The merging can be switched off for I/O ASIC systems (I haven't tested the exact behaviour of this configuration) but it seems to be hardwired for the /200. -- + 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 Aug 13 04:30:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DBUOC04972 for linux-mips-outgoing; Mon, 13 Aug 2001 04:30:24 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DBTxj04944; Mon, 13 Aug 2001 04:30:11 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19681; Mon, 13 Aug 2001 13:32:19 +0200 (MET DST) Date: Mon, 13 Aug 2001 13:32:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010810164945.B24889@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 10 Aug 2001, Ralf Baechle wrote: > The fact that each package based on libtool is carrying it's own copy of > libtool around doesn't exactly help to eleminate old libtool copies > quickly either. It's worth to run `libtoolize -c -f' before building any libtool-based software. -- + 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 Aug 13 06:07:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DD7WY07337 for linux-mips-outgoing; Mon, 13 Aug 2001 06:07:32 -0700 Received: from web13908.mail.yahoo.com (web13908.mail.yahoo.com [216.136.175.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DD7Tj07334 for ; Mon, 13 Aug 2001 06:07:29 -0700 Message-ID: <20010813130729.37581.qmail@web13908.mail.yahoo.com> Received: from [61.133.138.154] by web13908.mail.yahoo.com; Mon, 13 Aug 2001 06:07:29 PDT Date: Mon, 13 Aug 2001 06:07:29 -0700 (PDT) From: Barry Wu Subject: mips ide disk dma problem To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, all, I meet problems about mips ide disk. I find dma mode is different from other platform. We have to use dma_cache_wback_inv and vtonocache functions to work under DMA mode, I read pcnet32 ethernet driver, it works like that. I do not know if I have to support ide disk dma, what I have to do? I use Acerlab 1535D southbridge and M5229 IDE controller. I patch 1535D driver to linux 2.2.12 kernel. Hard disk can work well using PIO mode. But it is very slow on our mips evaluation board. Therefore, if someone knows how and where to add dma_cache_wback_inv, vtonocahce, something like these. Please help me. Thanks in advance! Barry __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Aug 13 06:22:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DDMa107704 for linux-mips-outgoing; Mon, 13 Aug 2001 06:22:36 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DDMUj07701 for ; Mon, 13 Aug 2001 06:22:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21183; Mon, 13 Aug 2001 15:24:25 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:24:25 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Additional DEC memory configuration macros Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, The following patch adds a few macros for memory configuration for DECstation 5000/2x0 systems. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-dec_memory-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn02.h linux-mips-2.4.5-20010704/include/asm-mips/dec/kn02.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn02.h Wed Jun 27 22:35:33 2001 +++ linux-mips-2.4.5-20010704/include/asm-mips/dec/kn02.h Sun Aug 12 01:26:09 2001 @@ -28,6 +28,8 @@ #define KN02_RTC_BASE KSEG1ADDR(0x1fe80000) #define KN02_DZ11_BASE KSEG1ADDR(0x1fe00000) +#define KN02_CSR_BNK32M (1<<10) /* 32M stride */ + /* * Interrupt enable Bits */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn03.h linux-mips-2.4.5-20010704/include/asm-mips/dec/kn03.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn03.h Wed Jun 27 22:35:33 2001 +++ linux-mips-2.4.5-20010704/include/asm-mips/dec/kn03.h Sun Aug 12 01:23:20 2001 @@ -24,6 +24,10 @@ */ #define KN03_IOASIC_BASE KSEG1ADDR(0x1f840000) /* I/O ASIC */ #define KN03_RTC_BASE KSEG1ADDR(0x1fa00000) /* RTC */ +#define KN03_MCR_BASE KSEG1ADDR(0x1fac0000) /* MCR */ + +#define KN03_MCR_BNK32M (1<<10) /* 32M stride */ +#define KN03_MCR_ECCEN (1<<13) /* ECC enabled */ #define KN03_IOASIC_REG(r) (KN03_IOASIC_BASE+(r)) From owner-linux-mips@oss.sgi.com Mon Aug 13 06:24:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DDOBU07797 for linux-mips-outgoing; Mon, 13 Aug 2001 06:24:11 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DDO8j07792 for ; Mon, 13 Aug 2001 06:24:08 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21203; Mon, 13 Aug 2001 15:26:24 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:26:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Export mips_machtype Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, The following patch exports mips_machtype to modules. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-machtype-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c Thu Jun 14 04:26:19 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c Sat Aug 11 21:02:38 2001 @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -40,6 +41,7 @@ extern long __strlen_user_asm(const char extern long __strnlen_user_nocheck_asm(const char *s); extern long __strnlen_user_asm(const char *s); +EXPORT_SYMBOL(mips_machtype); EXPORT_SYMBOL(EISA_bus); /* From owner-linux-mips@oss.sgi.com Mon Aug 13 06:42:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DDgMU08193 for linux-mips-outgoing; Mon, 13 Aug 2001 06:42:22 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DDgGj08186 for ; Mon, 13 Aug 2001 06:42:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21444; Mon, 13 Aug 2001 15:43:56 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:43:56 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Keith Owens , Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] modutils 2.4.6: Make __dbe_table available to modules Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, The following patch is needed for modutils to initialize __dbe_table table pointers appropriately for modules that want to handle bus error exceptions on MIPS. A separate patch is needed for the kernel. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + modutils-2.4.6-mips-dbe.patch diff -up --recursive --new-file modutils-2.4.6.macro/include/module.h modutils-2.4.6/include/module.h --- modutils-2.4.6.macro/include/module.h Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/include/module.h Sun Aug 12 13:16:13 2001 @@ -153,6 +153,10 @@ struct module unsigned tgt_long cleanup; unsigned tgt_long ex_table_start; unsigned tgt_long ex_table_end; +#ifdef __mips__ + unsigned tgt_long dbe_table_start; + unsigned tgt_long dbe_table_end; +#endif #ifdef __alpha__ unsigned tgt_long gp; #endif diff -up --recursive --new-file modutils-2.4.6.macro/man/init_module.2 modutils-2.4.6/man/init_module.2 --- modutils-2.4.6.macro/man/init_module.2 Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/man/init_module.2 Sun Aug 12 13:17:14 2001 @@ -39,6 +39,10 @@ struct module void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; +#ifdef __mips__ + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +#endif #ifdef __alpha__ unsigned long gp; #endif diff -up --recursive --new-file modutils-2.4.6.macro/obj/obj_mips.c modutils-2.4.6/obj/obj_mips.c --- modutils-2.4.6.macro/obj/obj_mips.c Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/obj/obj_mips.c Sun Aug 12 16:16:26 2001 @@ -217,6 +217,15 @@ arch_create_got (struct obj_file *f) int arch_init_module (struct obj_file *f, struct module *mod) { + struct obj_section *sec; + + sec = obj_find_section(f, "__dbe_table"); + if (sec) + { + mod->dbe_table_start = sec->header.sh_addr; + mod->dbe_table_end = sec->header.sh_addr + sec->header.sh_size; + } + return 1; } From owner-linux-mips@oss.sgi.com Mon Aug 13 06:46:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DDkQ208384 for linux-mips-outgoing; Mon, 13 Aug 2001 06:46:26 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DDkMj08377 for ; Mon, 13 Aug 2001 06:46:22 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA08565 for ; Mon, 13 Aug 2001 06:44:49 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21352; Mon, 13 Aug 2001 15:38:36 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:38:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen , Keith Owens cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Make __dbe_table available to modules Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Unlike most architectures which only handle memory faults/privilege violations via __ex_table, the MIPS port allows to handle bus error exceptions via __dbe_table. Unfortunately, the latter table is not exported to modules, so if a modularized driver needs to probe the address space for a device it's out of luck. The following patch implements the kernel part of __dbe_table support. A separate patch is needed for modutils. A side effect of the patch is a fix to unhandled bus error exceptions which happen in the kernel mode. Currently they cause the faulting code to be reexecuted which results in a hang in an infinite loop. With the patch applied, the kernel's response is an "Oops" similar to the one printed when a memory fault happens. I hope it's fine to apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-dbe-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c Fri Jun 15 04:27:07 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c Sun Aug 12 17:34:55 2001 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -254,23 +255,59 @@ search_one_table(const struct exception_ return (first == last && first->insn == value) ? first->nextinsn : 0; } -#define search_dbe_table(addr) \ - search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr)) +extern spinlock_t modlist_lock; + +static unsigned long +search_dbe_table(unsigned long addr) +{ + unsigned long ret = 0; + +#ifndef CONFIG_MODULES + /* There is only the kernel to search. */ + ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (mp->dbe_table_start == NULL || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING))) + continue; + ret = search_one_table(mp->dbe_table_start, + mp->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif +} static void default_be_board_handler(struct pt_regs *regs) { unsigned long new_epc; - unsigned long fixup = search_dbe_table(regs->cp0_epc); + unsigned long fixup; - if (fixup) { - new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); - regs->cp0_epc = new_epc; - return; + if (!user_mode(regs)) { + fixup = search_dbe_table(regs->cp0_epc); + if (fixup) { + new_epc = fixup_exception(dpf_reg, fixup, + regs->cp0_epc); + regs->cp0_epc = new_epc; + return; + } } /* * Assume it would be too dangerous to continue ... */ + printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n", + (regs->cp0_cause & 4) ? "Data" : "Instruction", + regs->cp0_epc, regs->regs[31]); + die_if_kernel("Oops", regs); force_sig(SIGBUS, current); } diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/linux/module.h linux-mips-2.4.5-20010704/include/linux/module.h --- linux-mips-2.4.5-20010704.macro/include/linux/module.h Mon Jul 16 02:13:58 2001 +++ linux-mips-2.4.5-20010704/include/linux/module.h Sun Aug 12 11:22:09 2001 @@ -75,6 +75,10 @@ struct module void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; +#ifdef __mips__ + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +#endif #ifdef __alpha__ unsigned long gp; #endif diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/kernel/module.c linux-mips-2.4.5-20010704/kernel/module.c --- linux-mips-2.4.5-20010704.macro/kernel/module.c Thu Jun 14 04:28:48 2001 +++ linux-mips-2.4.5-20010704/kernel/module.c Sun Aug 12 11:24:53 2001 @@ -36,6 +36,11 @@ extern struct module_symbol __stop___ksy extern const struct exception_table_entry __start___ex_table[]; extern const struct exception_table_entry __stop___ex_table[]; +#ifdef __mips__ +extern const struct exception_table_entry __start___dbe_table[]; +extern const struct exception_table_entry __stop___dbe_table[]; +#endif + extern const char __start___kallsyms[] __attribute__ ((weak)); extern const char __stop___kallsyms[] __attribute__ ((weak)); @@ -48,6 +53,10 @@ static struct module kernel_module = syms: __start___ksymtab, ex_table_start: __start___ex_table, ex_table_end: __stop___ex_table, +#ifdef __mips__ + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, +#endif kallsyms_start: __start___kallsyms, kallsyms_end: __stop___kallsyms, }; @@ -436,6 +445,19 @@ sys_init_module(const char *name_user, s printk(KERN_ERR "init_module: mod->ex_table_* invalid.\n"); goto err2; } +#ifdef __mips__ + if (mod->dbe_table_start > mod->dbe_table_end + || (mod->dbe_table_start && + !((unsigned long)mod->dbe_table_start >= ((unsigned long)mod + mod->size_of_struct) + && ((unsigned long)mod->dbe_table_end + < (unsigned long)mod + mod->size))) + || (((unsigned long)mod->dbe_table_start + - (unsigned long)mod->dbe_table_end) + % sizeof(struct exception_table_entry))) { + printk(KERN_ERR "init_module: mod->dbe_table_* invalid.\n"); + goto err2; + } +#endif if (mod->flags & ~MOD_AUTOCLEAN) { printk(KERN_ERR "init_module: mod->flags invalid.\n"); goto err2; From owner-linux-mips@oss.sgi.com Mon Aug 13 07:19:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DEJS909340 for linux-mips-outgoing; Mon, 13 Aug 2001 07:19:28 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DEJNj09334 for ; Mon, 13 Aug 2001 07:19:23 -0700 Received: (qmail 23285 invoked from network); 13 Aug 2001 14:19:18 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Aug 2001 14:19:18 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-reply-to: Your message of "Mon, 13 Aug 2001 15:43:56 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 00:19:17 +1000 Message-ID: <15497.997712357@ocs3.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001 15:43:56 +0200 (MET DST), "Maciej W. Rozycki" wrote: > The following patch is needed for modutils to initialize __dbe_table >table pointers appropriately for modules that want to handle bus error >exceptions on MIPS. A separate patch is needed for the kernel. > >modutils-2.4.6-mips-dbe.patch >diff -up --recursive --new-file modutils-2.4.6.macro/include/module.h modutils-2.4.6/include/module.h >--- modutils-2.4.6.macro/include/module.h Fri Jan 5 01:45:19 2001 >+++ modutils-2.4.6/include/module.h Sun Aug 12 13:16:13 2001 >@@ -153,6 +153,10 @@ struct module > unsigned tgt_long cleanup; > unsigned tgt_long ex_table_start; > unsigned tgt_long ex_table_end; >+#ifdef __mips__ >+ unsigned tgt_long dbe_table_start; >+ unsigned tgt_long dbe_table_end; >+#endif > #ifdef __alpha__ > unsigned tgt_long gp; > #endif Checking dbe table is fine but where you placed the table in struct modules is wrong. You must not insert fields in the middle of struct module, it introduces version skew between kernel and user space. At the very least you have moved the can_unload which will break IPv6 plus a few other modules. I understand why you placed it before gp, it looks like the place for arch dependent code. The alpha specific data is a hangover that should never have been there. modutils 2.3.16 added the archdata_start and archdata_end fields specifically so each architecture did not have to keep adding fields and causing size mismatch between kernel and modutils. IA64 uses those fields for its unwind data, MIPS can use archdata for whatever it needs in a module. In modutils, there is an arch_archdata routine for each architecture. Most just return but obj/obj_ia64.c::arch_archdata actually does something. Copy that routine and create a structure containing two fields, the start and end of the dbe table. insmod then sets archdata_start and archdata_end to point to the structure that points to the dbe table. Do not put the dbe table directly in archdata_{start,end} in case you want to add more mips data later. In the kernel, module.c verifies that archdata_{start,end} are valid, if present. It later calls module_arch_init to handle archdata. include/asm-$(ARCH)/module.h defines macros module_map, module_unmap and module_arch_init. MIPS needs to define the last two. module_arch_init is passed the struct module so it can find the arch specific data, decode it and do what it likes with the contents. module_unmap does any arch specific cleanup, such as removing extra tables. For dbe tables, define a mips module_arch_init that validates the format of the arch specific data. Probably all you need to do is check that dbe start and end are inside the module. Unless you copy the dbe data elsewhere, module_unmap can be left as vfree. When you want to verify the dbe table, you run the module list. If archdata_end >= archdata_start+2*sizeof(struct exception_table_entry *) then archdata contains the dbe data. If dbe_table_end > dbe_table_start then run the table. Checking > ignores NULL pointers. The only other change you have to make is to init_modules(). For mips you create pointers to the kernel dbe tables and fill in archdata start and end in kernel_module. Since init_module is called before kmalloc is ready, make the kernel dbe table a static variable. From owner-linux-mips@oss.sgi.com Mon Aug 13 07:18:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DEIP209295 for linux-mips-outgoing; Mon, 13 Aug 2001 07:18:25 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DEI9j09282 for ; Mon, 13 Aug 2001 07:18:10 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA22347; Mon, 13 Aug 2001 16:20:12 +0200 (MET DST) Date: Mon, 13 Aug 2001 16:20:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: CFT: A DECstation 5000/2x0 NVRAM module driver Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, This is a call for testers for a DECstation 5000/2x0 NVRAM module driver. The module is a special memory board, electrically and mechanically compatible with the MS02-AA 8MB and MS02-CA 32MB DRAM memory modules as used in DECstation 5000/2x0 and DECsystem 5900 systems. It contains 1MB of SRAM backed by a lithium battery. The board used to be manufactured and sold by DEC as an NFS accelerator. Following is a patch that implements an MTD driver for the module. The driver supports any number of NVRAM boards, which means up to 14 in practice (as you need to place some real memory into the first slot). Unfortunately the firmware only initializes a single module in the last (15th) slot. Since the current version of the driver depends on the firmware to detect NVRAM boards, modules placed in other slots might get improperly detected. I'm thinking on getting rid of the dependency but as the board is completely undocumented I need to dig deeper into the firmware to find out how the boards get detected. The basic functionality is pretty much complete -- the driver registers as a MTD properly and provides functions for reading and writing. This is sufficient for upper layer drivers -- I tested the driver with the character and the block MTD drivers. I've been able to create and mount a filesystem using the latter (a patch is needed for mtdblock.c, though). The driver missess mapping support, but adding it is trivial and I'll do it in a few days. What's more important, it misses battery status and control. The generic MTD layer does not support such operations, so I need to think a bit how to implement them. The driver depends on other patches -- I've sent them to the list today. I've made all the patches available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/ms02-nv/'. The patch should be fine to apply. Comments, suggestions are welcomed. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-ms02-nv-67 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/Documentation/Configure.help linux-mips-2.4.5-20010704/Documentation/Configure.help --- linux-mips-2.4.5-20010704.macro/Documentation/Configure.help Thu Jun 14 04:25:51 2001 +++ linux-mips-2.4.5-20010704/Documentation/Configure.help Sun Aug 12 22:18:32 2001 @@ -10262,6 +10262,19 @@ CONFIG_MTD_PMC551_DEBUG only really useful if you are developing on this driver or suspect a possible hardware or driver bug. If unsure say N. +DEC MS02-NV NVRAM module support +CONFIG_MTD_MS02NV + This is a MTD driver for the DEC's MS02-type battery backed-up NVRAM + module. The module was originally meant as an NFS accelerator. Say Y + here if you have a DECstation 5000/2x0 equipped with such a module. + The driver should support the DECsystem 5900's onboard NVRAM module as + well. + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. The module will be + called ms02-nv.o. + Debugging RAM test driver CONFIG_MTD_MTDRAM This enables a test MTD device driver which uses vmalloc() to diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/Config.in linux-mips-2.4.5-20010704/drivers/mtd/Config.in --- linux-mips-2.4.5-20010704.macro/drivers/mtd/Config.in Wed Jan 10 14:06:27 2001 +++ linux-mips-2.4.5-20010704/drivers/mtd/Config.in Sat Aug 11 18:22:23 2001 @@ -38,6 +38,7 @@ comment 'RAM/ROM Device Drivers' bool ' PMC551 256M DRAM Bugfix' CONFIG_MTD_PMC551_BUGFIX bool ' PMC551 Debugging' CONFIG_MTD_PMC551_DEBUG fi + dep_tristate ' DEC MS02-NV NVRAM module support' CONFIG_MTD_MS02NV $CONFIG_MTD $CONFIG_DECSTATION dep_tristate ' Debugging RAM test driver' CONFIG_MTD_MTDRAM $CONFIG_MTD if [ "$CONFIG_MTD_MTDRAM" != "n" ]; then int 'Device size in kB' CONFIG_MTDRAM_TOTAL_SIZE 4096 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/Makefile linux-mips-2.4.5-20010704/drivers/mtd/Makefile --- linux-mips-2.4.5-20010704.macro/drivers/mtd/Makefile Thu Jan 11 05:26:08 2001 +++ linux-mips-2.4.5-20010704/drivers/mtd/Makefile Sat Aug 11 18:23:46 2001 @@ -33,6 +33,7 @@ obj-$(CONFIG_MTD_DOC2001) += doc2001.o obj-$(CONFIG_MTD_DOCPROBE) += docprobe.o docecc.o obj-$(CONFIG_MTD_SLRAM) += slram.o obj-$(CONFIG_MTD_PMC551) += pmc551.o +obj-$(CONFIG_MTD_MS02NV) += ms02-nv.o obj-$(CONFIG_MTD_MTDRAM) += mtdram.o # Chip drivers diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.c linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.c --- linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.c Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.c Mon Aug 13 07:04:49 2001 @@ -0,0 +1,322 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "ms02-nv.h" + + +static char version[] __initdata = + "ms02-nv.c: v.1.0.0 13 Aug 2001 Maciej W. Rozycki.\n"; + +MODULE_AUTHOR("Maciej W. Rozycki "); +MODULE_DESCRIPTION("DEC MS02-NV NVRAM module driver"); + + +/* + * Addresses we probe for an MS02-NV at. Modules may be located + * at any 8MB boundary within a 0MB up to 112MB range or at any 32MB + * boundary within a 0MB up to 448MB range. We don't support a module + * at 0MB, though. + */ +static ulong ms02nv_addrs[] __initdata = { + 0x07000000, 0x06800000, 0x06000000, 0x05800000, 0x05000000, + 0x04800000, 0x04000000, 0x03800000, 0x03000000, 0x02800000, + 0x02000000, 0x01800000, 0x01000000, 0x00800000 +}; + +static const char ms02nv_name[] = "DEC MS02-NV NVRAM"; +static const char ms02nv_res_diag_ram[] = "Diagnostic RAM"; +static const char ms02nv_res_user_ram[] = "General-purpose RAM"; +static const char ms02nv_res_csr[] = "Control and status register"; + +static struct mtd_info *root_ms02nv_mtd; + + +static int ms02nv_read(struct mtd_info *mtd, loff_t from, + size_t len, size_t *retlen, u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (from + len > mtd->size) + return -EINVAL; + + memcpy(buf, mp->uaddr + from, len); + *retlen = len; + + return 0; +} + +static int ms02nv_write(struct mtd_info *mtd, loff_t to, + size_t len, size_t *retlen, const u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (to + len > mtd->size) + return -EINVAL; + + memcpy(mp->uaddr + to, buf, len); + *retlen = len; + + return 0; +} + + +static inline uint ms02nv_probe_one(ulong addr) +{ + ms02nv_uint *ms02nv_diagp; + ms02nv_uint *ms02nv_magicp; + uint ms02nv_diag; + uint ms02nv_magic; + size_t size; + + int err; + + /* + * The firmware writes MS02NV_ID at MS02NV_MAGIC and also + * a diagnostic status at MS02NV_DIAG. + */ + ms02nv_diagp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_DIAG)); + ms02nv_magicp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_MAGIC)); + err = get_dbe(ms02nv_magic, ms02nv_magicp); + if (err) + return 0; + if (ms02nv_magic != MS02NV_ID) + return 0; + + ms02nv_diag = *ms02nv_diagp; + size = (ms02nv_diag & MS02NV_DIAG_SIZE_MASK) << MS02NV_DIAG_SIZE_SHIFT; + if (size > MS02NV_CSR) + size = MS02NV_CSR; + + return size; +} + +static int __init ms02nv_init_one(ulong addr) +{ + struct mtd_info *mtd; + struct ms02nv_private *mp; + struct resource *mod_res; + struct resource *diag_res; + struct resource *user_res; + struct resource *csr_res; + ulong fixaddr; + size_t size, fixsize; + + static int version_printed; + + int ret = -ENODEV; + + /* The module decodes 8MB of address space. */ + mod_res = kmalloc(sizeof(*mod_res), GFP_KERNEL); + if (!mod_res) + return -ENOMEM; + + memset(mod_res, 0, sizeof(*mod_res)); + mod_res->name = ms02nv_name; + mod_res->start = addr; + mod_res->end = addr + MS02NV_SLOT_SIZE - 1; + mod_res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + if (request_resource(&iomem_resource, mod_res) < 0) + goto err_out_mod_res; + + size = ms02nv_probe_one(addr); + if (!size) + goto err_out_mod_res_rel; + + if (!version_printed) { + printk(KERN_INFO "%s", version); + version_printed = 1; + } + + ret = -ENOMEM; + mtd = kmalloc(sizeof(*mtd), GFP_KERNEL); + if (!mtd) + goto err_out_mod_res_rel; + memset(mtd, 0, sizeof(*mtd)); + mp = kmalloc(sizeof(*mp), GFP_KERNEL); + if (!mp) + goto err_out_mtd; + memset(mp, 0, sizeof(*mp)); + + mtd->priv = mp; + mp->resource.module = mod_res; + + /* Firmware's diagnostic NVRAM area. */ + diag_res = kmalloc(sizeof(*diag_res), GFP_KERNEL); + if (!diag_res) + goto err_out_mp; + + memset(diag_res, 0, sizeof(*diag_res)); + diag_res->name = ms02nv_res_diag_ram; + diag_res->start = addr; + diag_res->end = addr + MS02NV_RAM - 1; + diag_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, diag_res); + + mp->resource.diag_ram = diag_res; + + /* User-available general-purpose NVRAM area. */ + user_res = kmalloc(sizeof(*user_res), GFP_KERNEL); + if (!user_res) + goto err_out_diag_res; + + memset(user_res, 0, sizeof(*user_res)); + user_res->name = ms02nv_res_user_ram; + user_res->start = addr + MS02NV_RAM; + user_res->end = addr + size - 1; + user_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, user_res); + + mp->resource.user_ram = user_res; + + /* Control and status register. */ + csr_res = kmalloc(sizeof(*csr_res), GFP_KERNEL); + if (!csr_res) + goto err_out_user_res; + + memset(csr_res, 0, sizeof(*csr_res)); + csr_res->name = ms02nv_res_csr; + csr_res->start = addr + MS02NV_CSR; + csr_res->end = addr + MS02NV_CSR + 3; + csr_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, csr_res); + + mp->resource.csr = csr_res; + + mp->addr = phys_to_virt(addr); + mp->size = size; + + /* + * Hide the firmware's diagnostic area. It may get destroyed + * upon a reboot. Take paging into account for mapping support. + */ + fixaddr = (addr + MS02NV_RAM + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1); + fixsize = (size - (fixaddr - addr)) & ~(PAGE_SIZE - 1); + mp->uaddr = phys_to_virt(fixaddr); + + mtd->type = MTD_RAM; + mtd->flags = MTD_CAP_RAM | MTD_XIP; + mtd->size = fixsize; + mtd->name = (char *)ms02nv_name; + mtd->module = THIS_MODULE; + mtd->read = ms02nv_read; + mtd->write = ms02nv_write; + + ret = -EIO; + if (add_mtd_device(mtd)) { + printk(KERN_ERR + "ms02-nv: Unable to register MTD device, aborting!\n"); + goto err_out_csr_res; + } + + printk(KERN_INFO "mtd%d: %s at 0x%08lx, size %uMB.\n", + mtd->index, ms02nv_name, addr, size >> 20); + + mp->next = root_ms02nv_mtd; + root_ms02nv_mtd = mtd; + + return 0; + + +err_out_csr_res: + release_resource(csr_res); + kfree(csr_res); +err_out_user_res: + release_resource(user_res); + kfree(user_res); +err_out_diag_res: + release_resource(diag_res); + kfree(diag_res); +err_out_mp: + kfree(mp); +err_out_mtd: + kfree(mtd); +err_out_mod_res_rel: + release_resource(mod_res); +err_out_mod_res: + kfree(mod_res); + return ret; +} + +static void __exit ms02nv_remove_one(void) +{ + struct mtd_info *mtd = root_ms02nv_mtd; + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + root_ms02nv_mtd = mp->next; + + del_mtd_device(mtd); + + release_resource(mp->resource.csr); + kfree(mp->resource.csr); + release_resource(mp->resource.user_ram); + kfree(mp->resource.user_ram); + release_resource(mp->resource.diag_ram); + kfree(mp->resource.diag_ram); + release_resource(mp->resource.module); + kfree(mp->resource.module); + kfree(mp); + kfree(mtd); +} + + +static int __init ms02nv_init(void) +{ + volatile u32 *csr; + uint stride = 0; + int count = 0; + int i; + + switch (mips_machtype) { + case MACH_DS5000_200: + csr = (volatile u32 *)KN02_CSR_ADDR; + if (*csr & KN02_CSR_BNK32M) + stride = 2; + break; + case MACH_DS5000_2X0: + csr = (volatile u32 *)KN03_MCR_BASE; + if (*csr & KN03_MCR_BNK32M) + stride = 2; + break; + default: + return -ENODEV; + break; + } + + for (i = 0; i < (sizeof(ms02nv_addrs) / sizeof(*ms02nv_addrs)); i++) + if (!ms02nv_init_one(ms02nv_addrs[i] << stride)) + count++; + + return (count > 0) ? 0 : -ENODEV; +} + +static void __exit ms02nv_cleanup(void) +{ + while (root_ms02nv_mtd) + ms02nv_remove_one(); +} + + +module_init(ms02nv_init); +module_exit(ms02nv_cleanup); diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.h linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.h --- linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.h Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.h Sun Aug 12 20:10:10 2001 @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * 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 + +/* MS02-NV iomem register offsets. */ +#define MS02NV_CSR 0x400000 /* control & status register */ + +/* MS02-NV memory offsets. */ +#define MS02NV_DIAG 0x0003f8 /* diagnostic status */ +#define MS02NV_MAGIC 0x0003fc /* MS02-NV magic ID */ +#define MS02NV_RAM 0x000400 /* general-purpose RAM start */ + +/* MS02-NV diagnostic status constants. */ +#define MS02NV_DIAG_SIZE_MASK 0xf0 /* RAM size mask */ +#define MS02NV_DIAG_SIZE_SHIFT 0x10 /* RAM size shift (left) */ + +/* MS02-NV general constants. */ +#define MS02NV_ID 0x03021966 /* MS02-NV magic ID value */ +#define MS02NV_SLOT_SIZE 0x800000 /* size of the address space + decoded by the module */ + +typedef volatile u32 ms02nv_uint; + +struct ms02nv_private { + struct mtd_info *next; + struct { + struct resource *module; + struct resource *diag_ram; + struct resource *user_ram; + struct resource *csr; + } resource; + u_char *addr; + size_t size; + u_char *uaddr; +}; From owner-linux-mips@oss.sgi.com Mon Aug 13 07:47:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DElTs09983 for linux-mips-outgoing; Mon, 13 Aug 2001 07:47:29 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DElMj09979 for ; Mon, 13 Aug 2001 07:47:22 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23031; Mon, 13 Aug 2001 16:49:22 +0200 (MET DST) Date: Mon, 13 Aug 2001 16:49:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-Reply-To: <15497.997712357@ocs3.ocs-net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 14 Aug 2001, Keith Owens wrote: > Checking dbe table is fine but where you placed the table in struct > modules is wrong. You must not insert fields in the middle of struct > module, it introduces version skew between kernel and user space. At > the very least you have moved the can_unload which will break IPv6 plus > a few other modules. [...] Thanks a lot for the detailed explanation. I'll cook an improvement soon. > The only other change you have to make is to init_modules(). For mips > you create pointers to the kernel dbe tables and fill in archdata start > and end in kernel_module. Since init_module is called before kmalloc > is ready, make the kernel dbe table a static variable. __dbe_table is initialized exactly like __ex_table, i.e. it's a separate ELF section with pointers to the start and the end computed in a linker script. Thus it is fine. The table has actually been present in the kernel for quite some time already. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Aug 13 08:14:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DFEA910594 for linux-mips-outgoing; Mon, 13 Aug 2001 08:14:10 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DFE6j10590 for ; Mon, 13 Aug 2001 08:14:06 -0700 Received: (qmail 23825 invoked from network); 13 Aug 2001 15:14:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Aug 2001 15:14:03 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-reply-to: Your message of "Mon, 13 Aug 2001 16:49:22 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 01:14:02 +1000 Message-ID: <16145.997715642@ocs3.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001 16:49:22 +0200 (MET DST), "Maciej W. Rozycki" wrote: >On Tue, 14 Aug 2001, Keith Owens wrote: >> The only other change you have to make is to init_modules(). For mips >> you create pointers to the kernel dbe tables and fill in archdata start >> and end in kernel_module. Since init_module is called before kmalloc >> is ready, make the kernel dbe table a static variable. > > __dbe_table is initialized exactly like __ex_table, i.e. it's a separate >ELF section with pointers to the start and the end computed in a linker >script. Thus it is fine. The table has actually been present in the >kernel for quite some time already. You still need this: struct archdata { const struct exception_table_entry *dbe_table_start; const struct exception_table_entry *dbe_table_end; }; In init_module: #ifdef __mips__ { extern const struct exception_table_entry __start___dbe_table[]; extern const struct exception_table_entry __stop___dbe_table[]; static struct archdata archdata_mips = { __start___dbe_table, __end___dbe_table }; kernel_module.archdata_start = (char *)&archdata_mips; kernel_module.archdata_end = kernel_module.archdata_start + sizeof(archdata_mips); } #endif I really need to add an arch specific init_module routine as well, instead of conditional code in init_module, but that means changing all architectures. Not today. From owner-linux-mips@oss.sgi.com Mon Aug 13 08:45:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DFjQP11482 for linux-mips-outgoing; Mon, 13 Aug 2001 08:45:26 -0700 Received: from dea.waldorf-gmbh.de (u-86-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DFjOj11479 for ; Mon, 13 Aug 2001 08:45:24 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7D9wu624073; Mon, 13 Aug 2001 11:58:56 +0200 Date: Mon, 13 Aug 2001 11:58:56 +0200 From: Ralf Baechle To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com Subject: Re: Problem with PMAD-AA / DECStation 5000/200 Message-ID: <20010813115856.D23431@bacchus.dhis.org> References: <007501c120e8$fe293720$737e9fc1@shodan> <20010809175131.D30160@paradigm.rfc822.org> <001701c1217a$3f206960$277d00d9@shodan> <20010810123358.D12247@paradigm.rfc822.org> <20010812223219.B21308@bacchus.dhis.org> <20010812224159.H918@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010812224159.H918@lug-owl.de>; from jbglaw@lug-owl.de on Sun, Aug 12, 2001 at 10:41:59PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Aug 12, 2001 at 10:41:59PM +0200, Jan-Benedict Glaw wrote: > If you've heared of that company (which will support those old > machines), maybe they're willung to work with us? They've maybe > got all legal rights to software/documentation/thousands of > kilometers of tape archives, but we're (partially) really > working with these machines. So maybe we've got some know-how > in practical terms which they maybe do not have... It's not exactly the name of a company I'd consider important enough to dedicate the surface of a a slip of paper to it's name, so sorry, I don't have it's name at hand. Ask Compaq. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 08:53:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DFrEk11910 for linux-mips-outgoing; Mon, 13 Aug 2001 08:53:14 -0700 Received: from dea.waldorf-gmbh.de (u-86-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DFrBj11907 for ; Mon, 13 Aug 2001 08:53:11 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFogR02275; Mon, 13 Aug 2001 17:50:42 +0200 Date: Mon, 13 Aug 2001 17:50:42 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules Message-ID: <20010813175042.C2228@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 03:38:36PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 03:38:36PM +0200, Maciej W. Rozycki wrote: > Unlike most architectures which only handle memory faults/privilege > violations via __ex_table, the MIPS port allows to handle bus error > exceptions via __dbe_table. Unfortunately, the latter table is not > exported to modules, so if a modularized driver needs to probe the address > space for a device it's out of luck. > > The following patch implements the kernel part of __dbe_table support. A > separate patch is needed for modutils. > > A side effect of the patch is a fix to unhandled bus error exceptions > which happen in the kernel mode. Currently they cause the faulting code > to be reexecuted which results in a hang in an infinite loop. With the > patch applied, the kernel's response is an "Oops" similar to the one > printed when a memory fault happens. > > I hope it's fine to apply. Looks fine at the first view. I'll apply it but duplicate it for mips64 also. The whole mechanism has it's problems though. On the Origin certain accesses like an attempt to write to a non-existant serial interface take down the machine though. I don't have an explanation nor did Kanoj seem to. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 08:54:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DFsPa11989 for linux-mips-outgoing; Mon, 13 Aug 2001 08:54:25 -0700 Received: from dea.waldorf-gmbh.de (u-86-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DFsNj11986 for ; Mon, 13 Aug 2001 08:54:23 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFqQW02284; Mon, 13 Aug 2001 17:52:26 +0200 Date: Mon, 13 Aug 2001 17:52:26 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010813175226.D2228@bacchus.dhis.org> References: <20010810164945.B24889@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 01:32:19PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 01:32:19PM +0200, Maciej W. Rozycki wrote: > > The fact that each package based on libtool is carrying it's own copy of > > libtool around doesn't exactly help to eleminate old libtool copies > > quickly either. > > It's worth to run `libtoolize -c -f' before building any libtool-based > software. That results in build failures for a few rpms. Many packages already do that but unfortunately not all. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 08:55:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DFtcV12013 for linux-mips-outgoing; Mon, 13 Aug 2001 08:55:38 -0700 Received: from dea.waldorf-gmbh.de (u-86-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DFtaj12010 for ; Mon, 13 Aug 2001 08:55:36 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFrvD02291; Mon, 13 Aug 2001 17:53:57 +0200 Date: Mon, 13 Aug 2001 17:53:57 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype Message-ID: <20010813175357.E2228@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 03:26:23PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote: > The following patch exports mips_machtype to modules. Please apply. Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To messy and requires a central authority to allocate machine types. What do you think? Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 09:22:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DGM3k12852 for linux-mips-outgoing; Mon, 13 Aug 2001 09:22:03 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DGLtj12843; Mon, 13 Aug 2001 09:21:55 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24704; Mon, 13 Aug 2001 18:24:20 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:24:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules In-Reply-To: <20010813175042.C2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001, Ralf Baechle wrote: > Looks fine at the first view. I'll apply it but duplicate it for mips64 > also. Please wait for a while, until I resolve modutils interoperability as pointed out by Keith. > The whole mechanism has it's problems though. On the Origin certain > accesses like an attempt to write to a non-existant serial interface > take down the machine though. I don't have an explanation nor did Kanoj > seem to. The MIPS architecture defines the bus error exception event for data reads and instruction fetches only. Writes are asynchronous so errors on them cannot be reported exactly -- some MIPS documentation recommends using a general-purpose interrupt line for such events. Both bus error exceptions and error interrupts are system-specific and might not work unless designed to. The Origin might be an example. Does it crash for reads/fetches from the affected address space, either? -- + 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 Aug 13 09:25:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DGPcT12996 for linux-mips-outgoing; Mon, 13 Aug 2001 09:25:38 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DGPVj12986; Mon, 13 Aug 2001 09:25:31 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24793; Mon, 13 Aug 2001 18:27:37 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:27:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010813175226.D2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001, Ralf Baechle wrote: > > It's worth to run `libtoolize -c -f' before building any libtool-based > > software. > > That results in build failures for a few rpms. Many packages already do > that but unfortunately not all. Well, libtool is pretty self-contained, but you may try to regenerate scripts as well. If that fails, too, the software needs to be fixed sooner or later. Look at my packages for a number of updates in this area. -- + 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 Aug 13 09:34:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DGYHl13277 for linux-mips-outgoing; Mon, 13 Aug 2001 09:34:17 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DGY8j13274; Mon, 13 Aug 2001 09:34:09 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24957; Mon, 13 Aug 2001 18:36:35 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:36:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <20010813175357.E2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 13 Aug 2001, Ralf Baechle wrote: > > The following patch exports mips_machtype to modules. Please apply. > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > messy and requires a central authority to allocate machine types. What > do you think? No idea at the moment. For DECs things are pretty easy. The firmware returns a unique system ID for each different kind of hardware. It can be used instead (actually mips_machtype is initialized bazed on what firmware reports). The ID is mostly useful for system-specific stuff, e.g. onboard devices that cannot be identified or probed in another way. Note that for PCI-based systems, there is usually no problem -- PCI IDs can be used instead in most cases. -- + 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 Aug 13 10:34:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHYnB14299 for linux-mips-outgoing; Mon, 13 Aug 2001 10:34:49 -0700 Received: from web11901.mail.yahoo.com (web11901.mail.yahoo.com [216.136.172.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHYkj14296 for ; Mon, 13 Aug 2001 10:34:47 -0700 Message-ID: <20010813173446.61234.qmail@web11901.mail.yahoo.com> Received: from [209.243.184.191] by web11901.mail.yahoo.com; Mon, 13 Aug 2001 10:34:46 PDT Date: Mon, 13 Aug 2001 10:34:46 -0700 (PDT) From: Wayne Gowcher Subject: Benchmark performance To: linux-mips@oss.sgi.com In-Reply-To: <20010809215522.A1958@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have been running the nbench-byte-2.1 benchmark on a mips r4k processor with various combinations of kernel and distribution packages. I initially started with a 2.4.2 kernel using the redhat 5.1 distribution found on the SGI mips site. I compiled nbench native on the target with redhat mounted via nfs. I used this as my base. I then ran a 2.4.6 kernel on the same mips 4k processor, but this time with the redhat 7.0 distribution. I compiled native using the distributions compiler. This resulted in : a 3 % reduction in the Memory Index benchmark a 2 % increase in the Integer Index benchmark a 23 % reduction in the Floating Point Index benchmark Using the same 2.4.6 kernel on the same mips 4k processor, with the redhat 7.1 distribution (compiling native with the distribution's compiler ) I got : a 5.7 % reduction in the Memory Index benchmark a 1.5 % reduction in the Integer Index benchmark a 27 % reduction in the Floating point Index benchmark Also as a test I ran the redhat 5.1 native compiled nbench executable on the 2.4.6 / redhat 7.0 setup and again saw reduced performance : a 4.8 % reduction in the Memory Index benchmark a 1.5 % increase in the Integer Index benchmark a 26 % reduction in the floating point benchmark Although I tried various compiler switches to acheive the highest index I could on a per kernel / per distribution basis ( they weren't always the same ). My basic CFLAGS settings were : CFLAGS = -s -static -Wall -O2 -fomit-frame-pointer -funroll-all-loops -mips2 -finline-functions. >From the above tests it seems that newer does not in fact mean faster. I can only speculate as to why, and so I would appreciate hearing from anyone who : a, has suggestions on how to optimize compiler performance. b, may know why performance seems to degrade with a newer kernel and with a newer distribution ? newer compiler ? c, any other tips for improving kernel / application performance. Wayne __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Aug 13 11:13:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DID6f15910 for linux-mips-outgoing; Mon, 13 Aug 2001 11:13:06 -0700 Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DID1j15907; Mon, 13 Aug 2001 11:13:02 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA05475; Mon, 13 Aug 2001 22:12:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA01383; Mon, 13 Aug 2001 21:55:58 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA08024; Mon, 13 Aug 2001 22:08:59 +0400 (MSD) Message-ID: <3B781837.33B9E438@niisi.msk.ru> Date: Mon, 13 Aug 2001 22:11:03 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > The MIPS architecture defines the bus error exception event for data > reads and instruction fetches only. Writes are asynchronous so errors on > them cannot be reported exactly -- some MIPS documentation recommends > using a general-purpose interrupt line for such events. > DBE is treated as ACK* on write. Some HW design manuals advise to use this fact even. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Aug 13 11:33:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DIXDm16491 for linux-mips-outgoing; Mon, 13 Aug 2001 11:33:13 -0700 Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DIX1j16486; Mon, 13 Aug 2001 11:33:01 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA05730; Mon, 13 Aug 2001 22:32:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id WAA01452; Mon, 13 Aug 2001 22:13:38 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA08135; Mon, 13 Aug 2001 22:24:56 +0400 (MSD) Message-ID: <3B781BF5.9FF57CF8@niisi.msk.ru> Date: Mon, 13 Aug 2001 22:27:01 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Mon, 13 Aug 2001, Ralf Baechle wrote: > > > > The following patch exports mips_machtype to modules. Please apply. > > > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > > messy and requires a central authority to allocate machine types. What > > do you think? > > No idea at the moment. For DECs things are pretty easy. The firmware > returns a unique system ID for each different kind of hardware. It can be > used instead (actually mips_machtype is initialized bazed on what firmware > reports). The ID is mostly useful for system-specific stuff, e.g. onboard > devices that cannot be identified or probed in another way. > > Note that for PCI-based systems, there is usually no problem -- PCI IDs > can be used instead in most cases. > How? In fact, I've got two different boards with the same Ethernet chip. Moreover, mach type shall be known as early as possible, early than pci init for sure. Just imagine, I need a way to identify PCI controller by mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I miss something in your proposal? BTW, in my Baget case, I just need a number for mach type. I can ask to change my prom in worst case. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Aug 13 12:35:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJZYU17736 for linux-mips-outgoing; Mon, 13 Aug 2001 12:35:34 -0700 Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [212.227.116.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DJZUj17733; Mon, 13 Aug 2001 12:35:30 -0700 Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by mailgate3.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id f7DJZS608675; Mon, 13 Aug 2001 21:35:29 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.2 #11) id m15WNUm-007oYqC; Mon, 13 Aug 2001 21:35 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: Ralf Baechle , "Maciej W. Rozycki" Subject: Re: [patch] linux 2.4.5: Export mips_machtype Date: Mon, 13 Aug 2001 21:39:11 +0200 X-Mailer: KMail [version 1.2] Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com References: <20010813175357.E2228@bacchus.dhis.org> In-Reply-To: <20010813175357.E2228@bacchus.dhis.org> MIME-Version: 1.0 Message-Id: <01081321391100.09809@intel> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Monday 13 August 2001 17:53, Ralf Baechle wrote: > On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote: > > The following patch exports mips_machtype to modules. Please apply. > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > messy and requires a central authority to allocate machine types. What > do you think? Well, it doesn't neccessarily have to be called mips_machtype, but, yes, we would need something similar at least for DECstations. Harald From owner-linux-mips@oss.sgi.com Mon Aug 13 12:37:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DJbFA17826 for linux-mips-outgoing; Mon, 13 Aug 2001 12:37:15 -0700 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 f7DJbCj17823 for ; Mon, 13 Aug 2001 12:37:12 -0700 Received: (qmail 11216 invoked from network); 13 Aug 2001 19:37:10 -0000 Received: from idahub2000.i-data.com (HELO idanshub) (172.16.1.8) by firewall.i-data.com with SMTP; 13 Aug 2001 19:37:10 -0000 Received: from eicon.com ([172.16.2.227]) by idanshub (Lotus Domino Release 5.0.8) with ESMTP id 2001081321393657:4124 ; Mon, 13 Aug 2001 21:39:36 +0200 Message-ID: <3B782CB0.AA24C7C8@eicon.com> Date: Mon, 13 Aug 2001 21:38:24 +0200 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: Barry Wu CC: linux-mips@oss.sgi.com Subject: Re: mips ide disk dma problem References: <20010813130729.37581.qmail@web13908.mail.yahoo.com> X-MIMETrack: Itemize by SMTP Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 13-08-2001 21:39:37, Serialize by Router on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 13-08-2001 21:39:38, Serialize complete at 13-08-2001 21:39:38 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Barry Wu wrote: > I meet problems about mips ide disk. I find dma mode > is different from other platform. We have to use > dma_cache_wback_inv and vtonocache functions to work > under DMA mode, I read pcnet32 ethernet driver, > it works like that. I do not know if I have to support > ide disk dma, what I have to do? Some MIPS'ification is needed to handle the caches. You can try the patch below to drivers/block/ide-dma.c. I don't know about your IDE controller (our board have a CMD PCI-648), but it may need some special handling also. -Tommy --- ide-dma.c.old Tue Aug 31 09:46:14 1999 +++ ide-dma.c Mon Aug 13 20:51:57 2001 @@ -176,6 +176,13 @@ #endif unsigned int count = 0; +#if defined(__mips__) + /* MIPS: We access the dmatable through uncached addresses, so that it + * will be read correctly by the controller. The alternative is to flush + * the appropriate range at the end of this procedure. + */ + table = (unsigned int *)vtonocache(table); +#endif do { /* * Determine addr and size of next buffer area. We assume that @@ -197,6 +204,10 @@ size += bh->b_size; } } +#if defined(__mips__) + /* MIPS: We need to flush the cache */ + dma_cache_wback_inv(bus_to_virt(addr), size); +#endif /* * Fill in the dma table, without crossing any 64kB boundaries. * Most hardware requires 16-bit alignment of all blocks, @@ -401,6 +412,10 @@ dmatable += (PRD_ENTRIES * PRD_BYTES); leftover -= (PRD_ENTRIES * PRD_BYTES); hwif->dmaproc = &ide_dmaproc; +#if defined(__mips__) + /* Make sure no part of the dmatable is in the cache */ + dma_cache_wback_inv(hwif->dmatable, PRD_ENTRIES * PRD_BYTES); +#endif if (hwif->chipset != ide_trm290) { byte dma_stat = inb(dma_base+2); @@ -430,6 +445,9 @@ } } if (dma_base) { +#if defined(__mips__) + dma_base = KSEG1ADDR(dma_base); +#endif if (extra) /* PDC20246 & HPT343 */ request_region(dma_base+16, extra, name); dma_base += hwif->channel ? 8 : 0; From owner-linux-mips@oss.sgi.com Mon Aug 13 16:10:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DNAgi23113 for linux-mips-outgoing; Mon, 13 Aug 2001 16:10:42 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DNAfj23110 for ; Mon, 13 Aug 2001 16:10:41 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f7DNAZC24949; Mon, 13 Aug 2001 16:10:35 -0700 (PDT) Date: Mon, 13 Aug 2001 16:10:35 -0700 (PDT) From: "John D. Davis" To: Debian MIPS list , SGI MIPS list Subject: Tracing the Console Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am currently trying to trace the console on and R4400 Indy. It seems that everything goes through console.c using either con_write or con_put_char. It would be great if I could communicate with someone that has a thorough understanding of this code and its interaction with newport_con.c. I have put some prtink statements in and it seems that newport_putcs is called several more times than it should. Is there some interrupt handler that can jump right to it? I have manually traced the calls from console.c con_write or con_put_char -> do_con_write -> newport_putcs. I am trying to pin down the console low-level read/write functions, so that I can grab the characters at that level and redirect them in a similar console driver. This is what a normal call trace looks like so far: Aug 6 20:14:57 agamemnon kernel: IN: console.c:con_write():line 2244: int 0: string Entering runlevel: 2\210^KA4 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: IN: console.c:do_con_write():line 1839 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: OUT: console.c:do_con_write():line 2013 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Aug 6 20:14:57 agamemnon kernel: OUT: console.c:con_write():line 2251 Aug 6 20:14:57 agamemnon kernel: IN: newport_con.c:newport_putcs():line 393 Aug 6 20:14:57 agamemnon kernel: OUT: newport_con.c:newport_putcs():line 423 Even after exiting con_write(), there is another newport_putcs() call. Any assistance/explanation would be greatly appreciated. thanks, john From owner-linux-mips@oss.sgi.com Mon Aug 13 16:18:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DNInq23299 for linux-mips-outgoing; Mon, 13 Aug 2001 16:18:49 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DNImj23296 for ; Mon, 13 Aug 2001 16:18:48 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7DNIbTc026617; Mon, 13 Aug 2001 16:18:37 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7DNIbeZ026613; Mon, 13 Aug 2001 16:18:37 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 13 Aug 2001 16:18:36 -0700 (PDT) From: James Simmons To: "John D. Davis" cc: Debian MIPS list , SGI MIPS list Subject: Re: Tracing the 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 > I am currently trying to trace the console on and R4400 Indy. It seems > that everything goes through console.c using either con_write or > con_put_char. It would be great if I could communicate with someone that > has a thorough understanding of this code and its interaction with > newport_con.c. Okay. I could explain this code if you want. > I have put some prtink statements in and it seems that > newport_putcs is called several more times than it should. Don't do that. Printk calls newport_putcs so if you have printk in newport_putcs it will going into a endless loop. You could redirect the console to a different tty device, say a serial console. From owner-linux-mips@oss.sgi.com Mon Aug 13 21:33:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E4XbS29534 for linux-mips-outgoing; Mon, 13 Aug 2001 21:33:37 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E4XVj29531; Mon, 13 Aug 2001 21:33:31 -0700 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA11277; Tue, 14 Aug 2001 14:32:47 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdABNES_; Tue Aug 14 14:31:43 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA21873; Tue, 14 Aug 2001 14:31:42 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdBQQGR_; Tue Aug 14 14:30:25 2001 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA09918; Tue, 14 Aug 2001 14:30:25 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 14:26:25 +1000 Message-ID: From: "Salisbury, Roger" To: "'Maciej W. Rozycki'" , Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: RE: /usr/bin/file Date: Tue, 14 Aug 2001 11:40:48 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk where do I get "libtoolize" Still trying to update everything. binutils-2.9.5.0.37 seems ok. although runtest not found.( needs testsuite, which needs DejaGnu from ftp ://gcc.gnu.org/pub/gcc/infrastructure BUT the site is currently down. glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... egcs-2.91.66, bad ...*** Some critical program is missing or too old ) gcc-3.0 needs rectification in [libgcc_s.so] & [libgcc.a] it seems (see make error below!) Any idea Anyone please. ############################################################### bash-2.04# pwd /gcc-3.0 bash-2.04#make ... ... /usr/local/mips-unknown-linux-gnu/bin/ld: bfd assertion fail elf32-mips.c:8348 /usr/local/mips-unknown-linux-gnu/bin/ld: bfd assertion fail elf32-mips.c:8348 /usr/local/mips-unknown-linux-gnu/bin/ld: bfd assertion fail elf32-mips.c:8348 /usr/local/mips-unknown-linux-gnu/bin/ld: bfd assertion fail elf32-mips.c:8348 collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/gcc-3.0/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/gcc-3.0/gcc' make: *** [all-gcc] Error 2 bash-2.04# ############################################################### Any idea Anyone please. Thanks Roger > -----Original Message----- > From: Maciej W. Rozycki [SMTP:macro@ds2.pg.gda.pl] > Sent: Tuesday, 14 August 2001 2:28 am > To: Ralf Baechle > Cc: Salisbury, Roger; linux-mips@oss.sgi.com; linux-mips@fnet.fr > Subject: Re: /usr/bin/file > > On Mon, 13 Aug 2001, Ralf Baechle wrote: > > > > It's worth to run `libtoolize -c -f' before building any > libtool-based > > > software. > > > > That results in build failures for a few rpms. Many packages already do > > that but unfortunately not all. > > Well, libtool is pretty self-contained, but you may try to regenerate > scripts as well. If that fails, too, the software needs to be fixed > sooner or later. Look at my packages for a number of updates in this > area. > > -- > + 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 Aug 13 22:19:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E5JCO30459 for linux-mips-outgoing; Mon, 13 Aug 2001 22:19:12 -0700 Received: from dea.waldorf-gmbh.de (u-197-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.197]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E5J9j30456 for ; Mon, 13 Aug 2001 22:19:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E5HJC05632; Tue, 14 Aug 2001 07:17:19 +0200 Date: Tue, 14 Aug 2001 07:17:19 +0200 From: Ralf Baechle To: "Tommy S. Christensen" Cc: Barry Wu , linux-mips@oss.sgi.com Subject: Re: mips ide disk dma problem Message-ID: <20010814071718.A5552@bacchus.dhis.org> References: <20010813130729.37581.qmail@web13908.mail.yahoo.com> <3B782CB0.AA24C7C8@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: <3B782CB0.AA24C7C8@eicon.com>; from tommy.christensen@eicon.com on Mon, Aug 13, 2001 at 09:38:24PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Aug 13, 2001 at 09:38:24PM +0200, Tommy S. Christensen wrote: > Barry Wu wrote: > > I meet problems about mips ide disk. I find dma mode > > is different from other platform. We have to use > > dma_cache_wback_inv and vtonocache functions to work > > under DMA mode, I read pcnet32 ethernet driver, > > it works like that. I do not know if I have to support > > ide disk dma, what I have to do? > > Some MIPS'ification is needed to handle the caches. > You can try the patch below to drivers/block/ide-dma.c. > > I don't know about your IDE controller (our board have > a CMD PCI-648), but it may need some special handling also. You're referencing a function that doesn't exist in the whole kernel. Aside it's a crude hack anyway. If you have problems with caches use the API defined in Documentation/DMA-mapping.txt. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 22:27:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E5RwD30680 for linux-mips-outgoing; Mon, 13 Aug 2001 22:27:58 -0700 Received: from dea.waldorf-gmbh.de (u-197-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.197]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E5Rsj30646 for ; Mon, 13 Aug 2001 22:27:54 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E5Q2l05681; Tue, 14 Aug 2001 07:26:02 +0200 Date: Tue, 14 Aug 2001 07:26:02 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: "'Maciej W. Rozycki'" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010814072602.A5665@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Tue, Aug 14, 2001 at 11:40:48AM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Aug 14, 2001 at 11:40:48AM +1000, Salisbury, Roger wrote: > where do I get "libtoolize" GNU libtools. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) > gcc-3.0 needs rectification in [libgcc_s.so] & [libgcc.a] it seems (see > make error below!) linker problem. If you still run gcc 1.2 then your ld is probably to antique anyway. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 13 23:03:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E63KS31493 for linux-mips-outgoing; Mon, 13 Aug 2001 23:03:20 -0700 Received: from gateway.sonysard.co.in ([202.54.38.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E63Fj31490 for ; Mon, 13 Aug 2001 23:03:17 -0700 Received: from gateway.sony.co.in [202.54.38.194] (HELO localhost) by gateway.sonysard.co.in (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_0168_3b78_c199_2b72; Tue, 14 Aug 2001 11:43:45 +0530 Received: from sonysard.co.in (satish.sony.co.in [192.168.1.22]) by mailserv.sonysard.co.in (8.9.3/8.9.3) with ESMTP id LAA10061 for ; Tue, 14 Aug 2001 11:25:14 +0530 Message-ID: <3B78BD32.8BB29B6D@sonysard.co.in> Date: Tue, 14 Aug 2001 11:24:59 +0530 From: Sathish Vasudevaiah Organization: SARD/SISC X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: help References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From owner-linux-mips@oss.sgi.com Tue Aug 14 00:16:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E7GxB00918 for linux-mips-outgoing; Tue, 14 Aug 2001 00:16:59 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E7Gsj00906; Tue, 14 Aug 2001 00:16:54 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 353AF1E225; Tue, 14 Aug 2001 09:16:48 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: "Salisbury, Roger" Cc: "'Maciej W. Rozycki'" , Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file References: From: Andreas Jaeger Date: Tue, 14 Aug 2001 09:16:36 +0200 In-Reply-To: ("Salisbury, Roger"'s message of "Tue, 14 Aug 2001 11:40:48 +1000") Message-ID: Lines: 26 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Salisbury, Roger" writes: > where do I get "libtoolize" > > Still trying to update everything. > > binutils-2.9.5.0.37 seems ok. although runtest not found.( needs testsuite, > which needs DejaGnu from ftp ://gcc.gnu.org/pub/gcc/infrastructure BUT the > site is currently down. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) > > gcc-3.0 needs rectification in [libgcc_s.so] & [libgcc.a] it seems (see > make error below!) GCC 3.0 will not compile a correct glibc at all, wait for GCC 3.0.1 and glibc 2.2.5 and read the glibc announcements, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Tue Aug 14 01:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E8Bhg02100 for linux-mips-outgoing; Tue, 14 Aug 2001 01:11:43 -0700 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 f7E8Bej02078 for ; Tue, 14 Aug 2001 01:11:41 -0700 Received: (qmail 13342 invoked from network); 14 Aug 2001 08:11:39 -0000 Received: from idahub2000.i-data.com (HELO idanshub) (172.16.1.8) by firewall.i-data.com with SMTP; 14 Aug 2001 08:11:39 -0000 Received: from eicon.com ([172.17.159.1]) by idanshub (Lotus Domino Release 5.0.8) with ESMTP id 2001081410140571:4761 ; Tue, 14 Aug 2001 10:14:05 +0200 Message-ID: <3B78DD81.39D4A69B@eicon.com> Date: Tue, 14 Aug 2001 10:12:49 +0200 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: Ralf Baechle CC: Barry Wu , linux-mips@oss.sgi.com Subject: Re: mips ide disk dma problem References: <20010813130729.37581.qmail@web13908.mail.yahoo.com> <3B782CB0.AA24C7C8@eicon.com> <20010814071718.A5552@bacchus.dhis.org> X-MIMETrack: Itemize by SMTP Server on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 14-08-2001 10:14:05, Serialize by Router on idaHUB2000/INT(Release 5.0.8 |June 18, 2001) at 14-08-2001 10:14:06, Serialize complete at 14-08-2001 10:14:06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Mon, Aug 13, 2001 at 09:38:24PM +0200, Tommy S. Christensen wrote: > > > Barry Wu wrote: > > > I meet problems about mips ide disk. I find dma mode > > > is different from other platform. We have to use > > > dma_cache_wback_inv and vtonocache functions to work > > > under DMA mode, I read pcnet32 ethernet driver, > > > it works like that. I do not know if I have to support > > > ide disk dma, what I have to do? > > > > Some MIPS'ification is needed to handle the caches. > > You can try the patch below to drivers/block/ide-dma.c. > > > > I don't know about your IDE controller (our board have > > a CMD PCI-648), but it may need some special handling also. > > You're referencing a function that doesn't exist in the whole kernel. vtonocache(p) is defined as KSEG1ADDR(virt_to_phys(p)). This is for linux-2.2.12 from MIPS, remember. > Aside it's a crude hack anyway. If you have problems with caches use > the API defined in Documentation/DMA-mapping.txt. I don't see why this is a hack. Sure, the Dynamic DMA interface is a lot cleaner, but it ends up with more or less the same. -Tommy From owner-linux-mips@oss.sgi.com Tue Aug 14 01:58:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E8wE703251 for linux-mips-outgoing; Tue, 14 Aug 2001 01:58:14 -0700 Received: from dea.waldorf-gmbh.de (u-198-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E8w5j03238 for ; Tue, 14 Aug 2001 01:58:06 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E8nfU06453; Tue, 14 Aug 2001 10:49:41 +0200 Date: Tue, 14 Aug 2001 10:49:41 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising Message-ID: <20010814104941.F5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.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: <20010806164452D.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Aug 06, 2001 at 04:44:52PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1204 Lines: 27 On Mon, Aug 06, 2001 at 04:44:52PM +0900, Atsushi Nemoto wrote: > Here is an patch to fix virtual aliasing problem with SysV IPC shared > memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > If D-cache is smaller than PAGE_SIZE this patch is not needed at all, > but I think it is not so bad unconditionally forcing alignment to > SHMLBA. It's wasting huge amounts of address space. That can be prohibitive if you want to run something such as electric fence. Technically the worst case of any CPU that's required is 32kb on R4000 / R4400 SC and MC versions, so I don't want to go beyond that. What does this patch have to do with SysV shared mem? Shmat(2) does proper alignment checking and aligning and doesn't call arch_get_unmapped_area. We do have an alignment problem with mmap(2); somebody already has a correct patch for this already pending to be merged by Alan and Linus as it affects all architectures. I assume your patch was actually intended to fix this problem; it' doesn't correctly properly deal with anonymous mappings which have no extra alignment constraints nor correctly factor in the file offset so with just two mmap calls I can still create aliases. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 01:58:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E8wxU03336 for linux-mips-outgoing; Tue, 14 Aug 2001 01:58:59 -0700 Received: from dea.waldorf-gmbh.de (u-198-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E8wpj03331 for ; Tue, 14 Aug 2001 01:58:52 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E7xVF06195; Tue, 14 Aug 2001 09:59:31 +0200 Date: Tue, 14 Aug 2001 09:59:31 +0200 From: Ralf Baechle To: Keith M Wesolowski Cc: "Salisbury, Roger" , "'linux-mips@oss.sgi.com'" Subject: Re: FW: indigo2 kernel build failures Message-ID: <20010814095931.C5928@bacchus.dhis.org> References: <20010812220210.D24560@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010812220210.D24560@foobazco.org>; from wesolows@foobazco.org on Sun, Aug 12, 2001 at 10:02:10PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 928 Lines: 18 On Sun, Aug 12, 2001 at 10:02:10PM -0700, Keith M Wesolowski wrote: > Nope. Even if it did the kernel wouldn't care. Build gcc on a peecee > sometime and you'll see "i386-unknown-linux-gnu" and it will work as > well as gcc ever does. Have some fun with it - maybe > "mips-fuckmeinthegoatass-linux-gnu" (STR) for your amusement or > "mips-notintel-linux-gnu" to make a statement. It won't affect > anything. Leave off the -gnu, though, and configure will kindly add > it back on, reminding you that it is, in fact, GNU/Linux, dammit. Since the manufacturer part of the name quadruple is a entirely useless just like the -gnu suffix on Linux I usually strip it off. That's why the kernel by default uses mips-linux, mipsel-linux, mips64-linux or mips64el-linux by default and I'd like others to do the same to avoid the unnecessary pleasure of editing makefiles that know about crosscompiler configuration names. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 01:59:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E8x8w03412 for linux-mips-outgoing; Tue, 14 Aug 2001 01:59:08 -0700 Received: from dea.waldorf-gmbh.de (u-198-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E8wxj03344 for ; Tue, 14 Aug 2001 01:58:59 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E7pqw06166; Tue, 14 Aug 2001 09:51:52 +0200 Date: Tue, 14 Aug 2001 09:51:52 +0200 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: Benchmark performance Message-ID: <20010814095152.A5928@bacchus.dhis.org> References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813173446.61234.qmail@web11901.mail.yahoo.com>; from wgowcher@yahoo.com on Mon, Aug 13, 2001 at 10:34:46AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1874 Lines: 49 On Mon, Aug 13, 2001 at 10:34:46AM -0700, Wayne Gowcher wrote: > I have been running the nbench-byte-2.1 benchmark on a > mips r4k processor with various combinations of kernel > and distribution packages. I initially started with a > 2.4.2 kernel using the redhat 5.1 distribution found > on the SGI mips site. I compiled nbench native on the > target with redhat mounted via nfs. I used this as my > base. > > I then ran a 2.4.6 kernel on the same mips 4k > processor, but this time with the redhat 7.0 > distribution. I compiled native using the > distributions compiler. This resulted in : > > a 3 % reduction in the Memory Index benchmark > a 2 % increase in the Integer Index benchmark > a 23 % reduction in the Floating Point Index benchmark Small fluctuations in the range of 2 or 3 percent are usually explained by a changing usage pattern of the caches. Therefore rerunning a the benchmarks is a good idea. Especially microbenchmarks a la lmbench on caches of low associativity like the direct mapped R4k caches are extremly easily affected by cache usage patterns. Did you get any kernel messages during the Floating Point Index benchmark on the older kernel? > a, has suggestions on how to optimize compiler > performance. > > b, may know why performance seems to degrade with a > newer kernel and with a newer distribution ? newer > compiler ? Gcc 3.0 has been reported to produce slightly slower code than it's predecessor by many people on various architecture. I'm sad to find that MIPS is also one of them. As for the kernel - I don't really know; your analysis isn't fine grained enough. I don't run kernel benchmarks religiously on every version but what I can say my number have in part risen dramatically. > c, any other tips for improving kernel / application > performance. Successful tuning requires a detailed analysis first. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 02:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7E90n303567 for linux-mips-outgoing; Tue, 14 Aug 2001 02:00:49 -0700 Received: from dea.waldorf-gmbh.de (u-198-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7E90fj03560 for ; Tue, 14 Aug 2001 02:00:42 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E8Orm06319; Tue, 14 Aug 2001 10:24:53 +0200 Date: Tue, 14 Aug 2001 10:24:52 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising Message-ID: <20010814102452.E5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.co.jp> <15214.23110.345236.934305@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: <15214.23110.345236.934305@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Aug 06, 2001 at 09:50:14AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 616 Lines: 17 On Mon, Aug 06, 2001 at 09:50:14AM +0100, Dominic Sweetman wrote: > > Here is an patch to fix virtual aliasing problem with SysV IPC > > shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > > > If D-cache is smaller than PAGE_SIZE this patch is not needed at > > all... > > More precisely, if the size of a D-cache "set" is smaller than > PAGE_SIZE. So a CPU with a 16Kbyte 4-way set-associative cache and > 4Kbyte PAGE_SIZE is safe. Or is physically indexed and physically tagged or magically deals with aliasing such as R4000 / R4400 SC and MC versions or R10000, R12000 or R14000. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 05:42:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ECgiE08025 for linux-mips-outgoing; Tue, 14 Aug 2001 05:42:44 -0700 Received: from dea.waldorf-gmbh.de (u-244-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ECgfj08022 for ; Tue, 14 Aug 2001 05:42:42 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E93oK06622; Tue, 14 Aug 2001 11:03:50 +0200 Date: Tue, 14 Aug 2001 11:03:50 +0200 From: Ralf Baechle To: "Tommy S. Christensen" Cc: Barry Wu , linux-mips@oss.sgi.com Subject: Re: mips ide disk dma problem Message-ID: <20010814110350.A6592@bacchus.dhis.org> References: <20010813130729.37581.qmail@web13908.mail.yahoo.com> <3B782CB0.AA24C7C8@eicon.com> <20010814071718.A5552@bacchus.dhis.org> <3B78DD81.39D4A69B@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: <3B78DD81.39D4A69B@eicon.com>; from tommy.christensen@eicon.com on Tue, Aug 14, 2001 at 10:12:49AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 652 Lines: 17 On Tue, Aug 14, 2001 at 10:12:49AM +0200, Tommy S. Christensen wrote: > vtonocache(p) is defined as KSEG1ADDR(virt_to_phys(p)). > This is for linux-2.2.12 from MIPS, remember. > > > Aside it's a crude hack anyway. If you have problems with caches use > > the API defined in Documentation/DMA-mapping.txt. > > I don't see why this is a hack. Sure, the Dynamic DMA > interface is a lot cleaner, but it ends up with more or > less the same. Less. It's a non-portable construct which for example will fail on any machine that uses some sort of DMA address translation. And would you expect the maintainers to accept such a bunch of #ifdefs? Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 05:45:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ECjB608195 for linux-mips-outgoing; Tue, 14 Aug 2001 05:45:11 -0700 Received: from dea.waldorf-gmbh.de (u-244-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ECj9j08192 for ; Tue, 14 Aug 2001 05:45:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E88C106241; Tue, 14 Aug 2001 10:08:12 +0200 Date: Tue, 14 Aug 2001 10:08:12 +0200 From: Ralf Baechle To: Ilya Volynets Cc: Keith M Wesolowski , Mark Nellemann , linux-mips mail list Subject: Re: Is it possible to boot linux on an O2 r5k ? Message-ID: <20010814100812.D5928@bacchus.dhis.org> References: <20010812215442.C24560@foobazco.org> <0108122213530C.07543@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0108122213530C.07543@gateway>; from ilya@theIlya.com on Sun, Aug 12, 2001 at 10:13:53PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 556 Lines: 12 On Sun, Aug 12, 2001 at 10:13:53PM -0700, Ilya Volynets wrote: > I don't know if this discussion should be started again, but I can't > stop myself from saing that having Linux supporting SGI MIPS > machines as well as it does SPARC64 machines would be very pleasant > thing to have. Everyone knows that Slowlaris is rock-solid OS, but I am > yet to see a person that doesn't like Linux on SUN machines. Talk to sun4c users. The performance suck rocks and in general at time the maintenance of the 32-bit Sparc kernel left alot of desires open. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 14 08:29:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EFTac12128 for linux-mips-outgoing; Tue, 14 Aug 2001 08:29:36 -0700 Received: from web11904.mail.yahoo.com (web11904.mail.yahoo.com [216.136.172.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EFTXj12123 for ; Tue, 14 Aug 2001 08:29:33 -0700 Message-ID: <20010814152933.67337.qmail@web11904.mail.yahoo.com> Received: from [209.243.184.191] by web11904.mail.yahoo.com; Tue, 14 Aug 2001 08:29:33 PDT Date: Tue, 14 Aug 2001 08:29:33 -0700 (PDT) From: Wayne Gowcher Subject: Re: Benchmark performance To: Ralf Baechle Cc: linux-mips@oss.sgi.com In-Reply-To: <20010814095152.A5928@bacchus.dhis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2278 Lines: 78 Ralf, Thanks for the input. > > a 3 % reduction in the Memory Index benchmark > > a 2 % increase in the Integer Index benchmark > > a 23 % reduction in the Floating Point Index > benchmark > > Small fluctuations in the range of 2 or 3 percent > are usually explained > by a changing usage pattern of the caches. > Therefore rerunning a the > benchmarks is a good idea. Especially > microbenchmarks a la lmbench on > caches of low associativity like the direct mapped > R4k caches are extremly > easily affected by cache usage patterns. I messed up the figures for the redhat 7.1 case They should have been : Memory Index 6.7 % decrease Integer Index 2 % decrease Floating Point 27 % decrease And it was the progressive reduction in performance of the Memory Index that was raising a red flag to me. Especially the big hit in floating point performance. > Did you get any kernel messages during the Floating > Point Index benchmark > on the older kernel? No, everything ran fine. > > newer kernel and with a newer distribution ? newer > > compiler ? > > Gcc 3.0 has been reported to produce slightly slower > code than it's > predecessor by many people on various architecture. > I'm sad to find that > MIPS is also one of them. OK. That's one to remember. > As for the kernel - I don't really know; your > analysis isn't fine grained > enough. I didn't do any performance tweaking with the kernel itself as I wouldn't really know how to go about it. I was more trying to use a base kernel and then see how I could improve the benchmark performance by using compile options on the benchmark program only. Admittedly improving kernel performance is a far more efficient way of improving the benchmark scores. > Successful tuning requires a detailed analysis > first. I read an article recently in Linux Journal on tweaking an Alpha kernel. I suppose the same general principles can be applied to MIPS. Alternatively, do you ( or anyone else ) know of a howto or even a general article on how to do this ? I downloaded the benchmark from : http://www.tux.org/~mayer/linux/bmark.html Wayne __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Tue Aug 14 10:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EHXNh15067 for linux-mips-outgoing; Tue, 14 Aug 2001 10:33:23 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EHX9j15062; Tue, 14 Aug 2001 10:33:10 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA05576; Tue, 14 Aug 2001 19:34:45 +0200 (MET DST) Date: Tue, 14 Aug 2001 19:34:44 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules In-Reply-To: <3B781837.33B9E438@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 660 Lines: 18 On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > DBE is treated as ACK* on write. Some HW design manuals advise to use > this fact even. And what is the use of ACK*? Note that that the state of the CPU at the moment of a write is completely unrelated to the action that triggered the write. Therefore any reporting of a write failure is hardly useful -- possibly as a kind of an MCE only, i.e. report the event and kill the current process or panic if none. -- + 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 Aug 14 10:41:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EHfQx15266 for linux-mips-outgoing; Tue, 14 Aug 2001 10:41:26 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EHfJj15260; Tue, 14 Aug 2001 10:41:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA05695; Tue, 14 Aug 2001 19:43:23 +0200 (MET DST) Date: Tue, 14 Aug 2001 19:43:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B781BF5.9FF57CF8@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1321 Lines: 29 On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > > Note that for PCI-based systems, there is usually no problem -- PCI IDs > > can be used instead in most cases. > > How? In fact, I've got two different boards with the same Ethernet chip. > Moreover, mach type shall be known as early as possible, early than pci > init for sure. Just imagine, I need a way to identify PCI controller by > mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I > miss something in your proposal? The PCI ID of a host bridge is usually sufficient to differentiate most systems for onboard devices that are not reported on PCI. If it is not for your one, you just fall outside of the scope of "most cases" and you need a different way to identify a system. Note I do not promote mips_machtype removal. > BTW, in my Baget case, I just need a number for mach type. I can ask to > change my prom in worst case. How do you set up mips_machtype on your system in the first place? At kernel_entry the code does not know what machine it's running on anyway, so it has to set mips_machtype based on a detection algorithm. -- + 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 Aug 14 11:23:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EINOe16399 for linux-mips-outgoing; Tue, 14 Aug 2001 11:23:24 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EINHj16391 for ; Tue, 14 Aug 2001 11:23:18 -0700 content-class: urn:content-classes:message Subject: RE: Could not find the source code for "/sbin/init". MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 14 Aug 2001 11:21:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A2431@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Could not find the source code for "/sbin/init". Thread-Index: AcEfcZ4IsRIyq7ZrSqeBkRbieS/W7AFejhow From: "Steven Liu" To: "Pete Popov" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7EINIj16393 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4390 Lines: 202 Hi, Pete: Thank you very much for your help. After several tries, I realized that you are right. My MMU may have problem. Because my mips CPU is not the standard one and I do not have a R3000 application program such as "date", "arch", or "init", I built an application as following. liu.c is: void main(void) { } Makefile is: ARCH = mips .EXPORT_ALL_VARIABLES: CROSS_COMPILE =mips-linux- AS =$(CROSS_COMPILE)as LD =$(CROSS_COMPILE)ld CC =$(CROSS_COMPILE)gcc -D__mips__ CPP =$(CC) -E AR =$(CROSS_COMPILE)ar NM =$(CROSS_COMPILE)nm STRIP =$(CROSS_COMPILE)strip OBJCOPY =$(CROSS_COMPILE)objcopy OBJDUMP =$(CROSS_COMPILE)objdump MAKE =make GENKSYMS=/sbin/genksyms CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mips1 -mcpu=r3000 -mmemcpy CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) # egcs-1.0.2 compiler for MIPS has a problem for which this is a work-around CFLAGS += $(shell if $(CC) -mno-split-addresses -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-mno-split-addresses"; fi) .S.s: $(CC) -D__ASSEMBLY__ -traditional -E -o $*.s $< .S.o: $(CC) -D__ASSEMBLY__ -traditional -c -o $*.o $< liu: $(CONFIGURATION) liu.o $(LD) $(LINKFLAGS) $(HEAD) liu.o \ -o liu $(NM) liu | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map liu.o: liu.c $(CC) $(CFLAGS) $(PROFILING) -c -o $*.o $< When I ran the program, it crushed. Could you build this application and run it on your R3000 system? If it works, send me your executable so that I can test my system. Regards, Steven Liu -----Original Message----- From: Pete Popov [mailto:ppopov@pacbell.net] Sent: Tuesday, August 07, 2001 11:53 AM To: Steven Liu Subject: Re: Could not find the source code for "/sbin/init". Steven Liu wrote: > Hi, Pete: > > Thank you for your help. > > Could you tell me what are sash,static bash, and dynamically > linked bash? > > Sorry for the trival question because I am new in Linux kernel. sash is a "stand alone shell". It's very small and is completely statically linked. The commands are bit different -- for example, "ls" is "-ls" -- ie, the commands start with a "-". If you can load sash instead of /sbin/init, it gives you some confidence that your kernel is actually able to switch to userland. Static and dynamic bash refers to how the libraries that bash is using a linked. With a statically linked bash, all of the libraries are linked as part of the bash binary. That way there is no dynamic library loading when you start bash. Dynamically linked bash means that when you start bash, different libraries that bash is using will be loaded dynamically. Pete > > Regards, > > Steven Liu > > -----Original Message----- > From: Pete Popov [mailto:ppopov@pacbell.net] > Sent: Tuesday, August 07, 2001 10:49 AM > To: Steven Liu > Cc: linux-mips@oss.sgi.com > Subject: Re: Could not find the source code for "/sbin/init". > > > Steven Liu wrote: > >>Hi ALL: >> >>As we know, the function init( ) in main.c is >> >>static int init(void * unused) >>{ >> lock_kernel(); >> do_basic_setup(); >> free_initmem(); >> unlock_kernel(); >> >> if (open("/dev/console", O_RDWR, 0) < 0) >> printk("Warning: unable to open an initial console.\n"); >> >> (void) dup(0); >> (void) dup(0); >> >> >> if (execute_command) >> execve(execute_command,argv_init,envp_init); >> >> execve("/sbin/init",argv_init,envp_init); //<--- problem >> >> execve("/etc/init",argv_init,envp_init); >> execve("/bin/init",argv_init,envp_init); >> execve("/bin/sh",argv_init,envp_init); >> panic("No init found. Try passing init= option to kernel."); >>} >> >>The system call execve("/sbin/init",argv_init,envp_init) will start a >>background process. >>In my case, it could not start the process, that is, system hangs >> > there > >>and >>execve("/etc/init",argv_init,envp_init) could not be executed. >> >> >>Could you tell me where could I find the source code for the >> > executable > >>/sbin/init? >> >>Thank you very much for your help. >> > > /sbin/init is part of the SysVInit package. > > Your problem is most likely NOT with /sbin/init itself. I would start by > loading > sash first; if that works, try a static bash; if that works, try a > dynamically > linked bash. > > Pete > > > > From owner-linux-mips@oss.sgi.com Tue Aug 14 11:34:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EIYaP16765 for linux-mips-outgoing; Tue, 14 Aug 2001 11:34:36 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EIYOj16762 for ; Tue, 14 Aug 2001 11:34:33 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7EIdCA03105; Tue, 14 Aug 2001 11:39:12 -0700 Message-ID: <3B797004.4030503@pacbell.net> Date: Tue, 14 Aug 2001 11:37:56 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Steven Liu CC: linux-mips@oss.sgi.com Subject: Re: Could not find the source code for "/sbin/init". References: <84CE342693F11946B9F54B18C1AB837B0A2431@ex2k.pcs.psdc.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: 2296 Lines: 89 Steven Liu wrote: > Hi, Pete: > > Thank you very much for your help. > > After several tries, I realized that you are right. My MMU may have > problem. > > Because my mips CPU is not the standard one and I do not have a R3000 > application > program such as "date", "arch", or "init", I built an application as > following. > > liu.c is: > > void main(void) > { > > } > > Makefile is: > > ARCH = mips > > .EXPORT_ALL_VARIABLES: > > > CROSS_COMPILE =mips-linux- > > AS =$(CROSS_COMPILE)as > LD =$(CROSS_COMPILE)ld > CC =$(CROSS_COMPILE)gcc -D__mips__ > CPP =$(CC) -E > AR =$(CROSS_COMPILE)ar > NM =$(CROSS_COMPILE)nm > STRIP =$(CROSS_COMPILE)strip > OBJCOPY =$(CROSS_COMPILE)objcopy > OBJDUMP =$(CROSS_COMPILE)objdump > MAKE =make > GENKSYMS=/sbin/genksyms > > > CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mips1 > -mcpu=r3000 -mmemcpy > > CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc > /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) > > # egcs-1.0.2 compiler for MIPS has a problem for which this is a > work-around > CFLAGS += $(shell if $(CC) -mno-split-addresses -S -o /dev/null -xc > /dev/null >/dev/null 2>&1; then echo "-mno-split-addresses"; fi) > > > > .S.s: > $(CC) -D__ASSEMBLY__ -traditional -E -o $*.s $< > .S.o: > $(CC) -D__ASSEMBLY__ -traditional -c -o $*.o $< > > > > liu: $(CONFIGURATION) liu.o > $(LD) $(LINKFLAGS) $(HEAD) liu.o \ > -o liu > $(NM) liu | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU] > \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map > > > liu.o: liu.c > $(CC) $(CFLAGS) $(PROFILING) -c -o $*.o $< > > > When I ran the program, it crushed. > > Could you build this application and run it on your R3000 system? If it > works, send me your executable so that I can test my system. How do you run the program? Do you use it instead of /sbin/init? If so, what should happen is that the program should "run" and then just return. If you put printks before and after your program is run, you should see the program being executed and then returning. If it's crashing, it sounds like your kernel can't run *any* userland app, probably because the mmu is not setup correctly. Unfortunately I don't have any R3000 based boards so I can't test anything. Pete From owner-linux-mips@oss.sgi.com Tue Aug 14 15:18:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7EMIsd23000 for linux-mips-outgoing; Tue, 14 Aug 2001 15:18:54 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7EMInj22994 for ; Tue, 14 Aug 2001 15:18:49 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09500 for ; Tue, 14 Aug 2001 15:18:35 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15WmNI-0005AK-00; Tue, 14 Aug 2001 15:09:24 -0700 Date: Tue, 14 Aug 2001 15:09:24 -0700 From: Daniel Jacobowitz To: linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org Cc: Simon Gee Subject: MIPS, profiling, and not working Message-ID: <20010814150924.A19477@nevyn.them.org> Mail-Followup-To: linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org, Simon Gee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1586 Lines: 40 I'm having some interesting problems with getting _mcount() to work on mips*-*-linux. Most of them are easily correctable within _mcount itself, but one deals with how it's called. The sequence looks like this: .set noreorder .set noat move $1,$31 # save current return address jal _mcount subu $sp,$sp,8 # _mcount pops 2 words from stack .set reorder .set at Suppose we have a function with no frame pointer, though - one which would otherwise be a leaf. We have a small problem based on the fact that GCC considers it to be a leaf despite calling _mcount. If it uses $sp for its frame register, then when the jal expands: 0x404550 <__libc_start_main+16>: sw $gp,16($sp) ... 0x404574 <__libc_start_main+52>: move $at,$ra 0x404578 <__libc_start_main+56>: lw $t9,-32584($gp) 0x40457c <__libc_start_main+60>: nop 0x404580 <__libc_start_main+64>: jalr $t9 0x404584 <__libc_start_main+68>: nop 0x404588 <__libc_start_main+72>: lw $gp,16($sp) 0x40458c <__libc_start_main+76>: addiu $sp,$sp,-8 Note that we saved $gp at 16($sp), then tried to restore it before we fixed $sp up again. Does anyone have a good idea? The best I can think of is to emit the jalr from GCC directly, so that we can restore the GP after restoring the stack pointer properly. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 14 16:36:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ENaSr25619 for linux-mips-outgoing; Tue, 14 Aug 2001 16:36:28 -0700 Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ENaQj25616 for ; Tue, 14 Aug 2001 16:36:26 -0700 Received: from oz.agile.tv (IDENT:simong@pacific.oz.agile.tv [192.168.16.16]) by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f7ENaCj29675; Wed, 15 Aug 2001 09:36:12 +1000 Message-ID: <3B79B9F0.7350BE7F@oz.agile.tv> Date: Wed, 15 Aug 2001 09:53:20 +1000 From: Simon Gee Organization: AgileTV Corporation Australia X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org Subject: Re: MIPS, profiling, and not working References: <20010814150924.A19477@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: 1975 Lines: 43 > > .set noreorder > .set noat > move $1,$31 # save current return address > jal _mcount > subu $sp,$sp,8 # _mcount pops 2 words from stack > .set reorder > .set at > Given this assembler sequence, which is produced by: /* Output assembler code to FILE to increment profiler label # LABELNO for profiling a function entry. */ #define FUNCTION_PROFILER(FILE, LABELNO) \ { \ if (TARGET_MIPS16) \ sorry ("mips16 function profiling"); \ fprintf (FILE, "\t.set\tnoreorder\n"); \ fprintf (FILE, "\t.set\tnoat\n"); \ fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n", \ reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]); \ fprintf (FILE, "\tjal\t_mcount\n"); \ fprintf (FILE, \ "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from stack\n", \ TARGET_64BIT ? "dsubu" : "subu", \ reg_names[STACK_POINTER_REGNUM], \ reg_names[STACK_POINTER_REGNUM], \ Pmode == DImode ? 16 : 8); \ fprintf (FILE, "\t.set\treorder\n"); \ fprintf (FILE, "\t.set\tat\n"); \ } in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was intended to be within "jal"'s delay slot (the expansion of jal is really annoying!) ? This being the case, the stack adjustment may have had to have been made before the call to _mcount is made. Simon From owner-linux-mips@oss.sgi.com Tue Aug 14 16:43:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7ENhtK25945 for linux-mips-outgoing; Tue, 14 Aug 2001 16:43:55 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7ENhrj25938 for ; Tue, 14 Aug 2001 16:43:53 -0700 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15WnrS-0005wu-00; Tue, 14 Aug 2001 16:44:38 -0700 Date: Tue, 14 Aug 2001 16:44:38 -0700 From: Daniel Jacobowitz To: Simon Gee Cc: linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org Subject: Re: MIPS, profiling, and not working Message-ID: <20010814164438.A22825@nevyn.them.org> Mail-Followup-To: Simon Gee , linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org References: <20010814150924.A19477@nevyn.them.org> <3B79B9F0.7350BE7F@oz.agile.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <3B79B9F0.7350BE7F@oz.agile.tv>; from simong@oz.agile.tv on Wed, Aug 15, 2001 at 09:53:20AM +1000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2473 Lines: 50 On Wed, Aug 15, 2001 at 09:53:20AM +1000, Simon Gee wrote: > > > > .set noreorder > > .set noat > > move $1,$31 # save current return address > > jal _mcount > > subu $sp,$sp,8 # _mcount pops 2 words from stack > > .set reorder > > .set at > > > > Given this assembler sequence, which is produced by: > > /* Output assembler code to FILE to increment profiler label # LABELNO > for profiling a function entry. */ > > #define FUNCTION_PROFILER(FILE, LABELNO) \ > { \ > if (TARGET_MIPS16) \ > sorry ("mips16 function profiling"); \ > fprintf (FILE, "\t.set\tnoreorder\n"); \ > fprintf (FILE, "\t.set\tnoat\n"); \ > fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n", \ > reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]); \ > fprintf (FILE, "\tjal\t_mcount\n"); \ > fprintf (FILE, \ > "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from stack\n", \ > TARGET_64BIT ? "dsubu" : "subu", \ > reg_names[STACK_POINTER_REGNUM], \ > reg_names[STACK_POINTER_REGNUM], \ > Pmode == DImode ? 16 : 8); \ > fprintf (FILE, "\t.set\treorder\n"); \ > fprintf (FILE, "\t.set\tat\n"); \ > } > > in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was > intended to be within "jal"'s delay slot (the expansion of jal is really > annoying!) ? This being the case, the stack adjustment may have had to have > been made before the call to _mcount is made. *sigh* Yes, I think the adjustment was meant to be made before the call. Perhaps binutils should warn about things in the "delay slot" of a macro? Doing the adjustment before the call would fix the problem that I'm seeing. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 14 17:17:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F0H4w26742 for linux-mips-outgoing; Tue, 14 Aug 2001 17:17:04 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F0H3j26739 for ; Tue, 14 Aug 2001 17:17:03 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7F0LbA19388; Tue, 14 Aug 2001 17:21:39 -0700 Message-ID: <3B79BE22.F679A3D@mvista.com> Date: Tue, 14 Aug 2001 17:11:14 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Simon Gee , linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org Subject: Re: MIPS, profiling, and not working References: <20010814150924.A19477@nevyn.them.org> <3B79B9F0.7350BE7F@oz.agile.tv> <20010814164438.A22825@nevyn.them.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2518 Lines: 51 Daniel Jacobowitz wrote: > > On Wed, Aug 15, 2001 at 09:53:20AM +1000, Simon Gee wrote: > > > > > > .set noreorder > > > .set noat > > > move $1,$31 # save current return address > > > jal _mcount > > > subu $sp,$sp,8 # _mcount pops 2 words from stack > > > .set reorder > > > .set at > > > > > > > Given this assembler sequence, which is produced by: > > > > /* Output assembler code to FILE to increment profiler label # LABELNO > > for profiling a function entry. */ > > > > #define FUNCTION_PROFILER(FILE, LABELNO) \ > > { \ > > if (TARGET_MIPS16) \ > > sorry ("mips16 function profiling"); \ > > fprintf (FILE, "\t.set\tnoreorder\n"); \ > > fprintf (FILE, "\t.set\tnoat\n"); \ > > fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n", \ > > reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]); \ > > fprintf (FILE, "\tjal\t_mcount\n"); \ > > fprintf (FILE, \ > > "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from stack\n", \ > > TARGET_64BIT ? "dsubu" : "subu", \ > > reg_names[STACK_POINTER_REGNUM], \ > > reg_names[STACK_POINTER_REGNUM], \ > > Pmode == DImode ? 16 : 8); \ > > fprintf (FILE, "\t.set\treorder\n"); \ > > fprintf (FILE, "\t.set\tat\n"); \ > > } > > > > in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was > > intended to be within "jal"'s delay slot (the expansion of jal is really > > annoying!) ? This being the case, the stack adjustment may have had to have > > been made before the call to _mcount is made. > > *sigh* Yes, I think the adjustment was meant to be made before the > call. Perhaps binutils should warn about things in the "delay slot" of a > macro? > It is a reasonable warning if we are in "noreorder" state. Programmers tend to make assumptions about the delay slot after they do "set .noreorder". Jun From owner-linux-mips@oss.sgi.com Tue Aug 14 18:29:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7F1Tbo28920 for linux-mips-outgoing; Tue, 14 Aug 2001 18:29:37 -0700 Received: from smtp.huawei.com (nszx104.121.szptt.net.cn [202.104.121.208] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7F1Taj28917 for ; Tue, 14 Aug 2001 18:29:36 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GI356602.A0U for ; Wed, 15 Aug 2001 09:22:54 +0800 Message-ID: <000701c12529$e1640580$8021690a@huawei.com> From: "machael thailer" To: Subject: Virtual address to physical address mapping... Date: Wed, 15 Aug 2001 09:30:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 267 Lines: 13 Hello, I am a newbie on linux-mips. I read the linux-mips sources codes and cannot find where it builds the page tables (from Virtual address to physical address mapping). Can you point it out to me where I can find it? Thank you very much. machael thailer From owner-linux-mips@oss.sgi.com Wed Aug 15 03:48:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FAmbS10286 for linux-mips-outgoing; Wed, 15 Aug 2001 03:48:37 -0700 Received: from dea.waldorf-gmbh.de (u-233-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FAmAj10133 for ; Wed, 15 Aug 2001 03:48:21 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7F8XET11987; Wed, 15 Aug 2001 10:33:14 +0200 Date: Wed, 15 Aug 2001 10:33:14 +0200 From: Ralf Baechle To: machael thailer Cc: linux-mips@oss.sgi.com Subject: Re: Virtual address to physical address mapping... Message-ID: <20010815103314.A11966@bacchus.dhis.org> References: <000701c12529$e1640580$8021690a@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: <000701c12529$e1640580$8021690a@huawei.com>; from dony.he@huawei.com on Wed, Aug 15, 2001 at 09:30:34AM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 498 Lines: 14 On Wed, Aug 15, 2001 at 09:30:34AM +0800, machael thailer wrote: > I am a newbie on linux-mips. I read the linux-mips sources codes and > cannot find where it builds the page tables (from Virtual address to > physical address mapping). > Can you point it out to me where I can find it? It only comes in the commercial edition ;-) Checkout the mm/ directory which contains most of the generic code. include/asm-mips/pgtable.h and arch/mips/mm/ contain most of the MIPS specific code. Ralf From owner-linux-mips@oss.sgi.com Wed Aug 15 05:54:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FCsph12479 for linux-mips-outgoing; Wed, 15 Aug 2001 05:54:51 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FCsej12451 for ; Wed, 15 Aug 2001 05:54:40 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA19040 for ; Wed, 15 Aug 2001 05:54:33 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA22700 for ; Wed, 15 Aug 2001 05:54:33 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7FCrCa23780 for ; Wed, 15 Aug 2001 14:53:12 +0200 (MEST) Message-ID: <3B7A70B8.ED92FE4@mips.com> Date: Wed, 15 Aug 2001 14:53:12 +0200 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: FP emulator patch Content-Type: multipart/mixed; boundary="------------B681E670EA042CA2391804E1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13284 Lines: 406 This is a multi-part message in MIME format. --------------B681E670EA042CA2391804E1 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit There has been some reports regarding FP emulator failures, which the attached patch should solve. The patch include a fix for emulation of instructions in a COP1 delay-slot, a fix for FP context switching and some additional stuff , which was needed to pass our torture test. Ralf could you please apply this 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 --------------B681E670EA042CA2391804E1 Content-Type: text/plain; charset=iso-8859-15; name="fp_emulator.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fp_emulator.patch" Index: linux/arch/mips/kernel/signal.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/signal.c,v retrieving revision 1.36 diff -u -r1.36 signal.c --- linux/arch/mips/kernel/signal.c 2001/06/18 22:43:35 1.36 +++ linux/arch/mips/kernel/signal.c 2001/08/15 12:33:38 @@ -220,6 +220,8 @@ err |= __get_user(owned_fp, &sc->sc_ownedfp); if (owned_fp) { + if (last_task_used_math && (last_task_used_math != current)) + last_task_used_math->thread.cp0_status &= ~ST0_CU1; err |= restore_fp_context(sc); last_task_used_math = current; } @@ -353,12 +355,11 @@ owned_fp = (current == last_task_used_math); err |= __put_user(owned_fp, &sc->sc_ownedfp); - if (current->used_math) { /* fp is active. */ + if (owned_fp) { /* fp is active. */ set_cp0_status(ST0_CU1); err |= save_fp_context(sc); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; - current->used_math = 0; } return err; @@ -375,6 +376,13 @@ /* Default to using normal stack */ sp = regs->regs[29]; + /* + * FPU emulator may have it's own trampoline active just + * above the user stack, 16-bytes before the next lowest + * 16 byte boundary. Try to avoid trashing it. + */ + sp -= 32; + /* This is the X/Open sanctioned signal stack switching. */ if ((ka->sa.sa_flags & SA_ONSTACK) && ! on_sig_stack(sp)) sp = current->sas_ss_sp + current->sas_ss_size; @@ -435,7 +443,7 @@ #if DEBUG_SIG printk("SIG deliver (%s:%d): sp=0x%p pc=0x%p ra=0x%p\n", - current->comm, current->pid, frame, regs->cp0_epc, frame->code); + current->comm, current->pid, frame, regs->cp0_epc, frame->sf_code); #endif return; Index: linux/arch/mips/kernel/unaligned.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/unaligned.c,v retrieving revision 1.12 diff -u -r1.12 unaligned.c --- linux/arch/mips/kernel/unaligned.c 2001/07/11 22:05:11 1.12 +++ linux/arch/mips/kernel/unaligned.c 2001/08/15 12:33:38 @@ -365,15 +365,12 @@ return; } - die_if_kernel ("Unhandled kernel unaligned access", regs); send_sig(SIGSEGV, current, 1); return; sigbus: - die_if_kernel ("Unhandled kernel unaligned access", regs); send_sig(SIGBUS, current, 1); return; sigill: - die_if_kernel ("Unhandled kernel unaligned access or invalid instruction", regs); send_sig(SIGILL, current, 1); return; } @@ -391,11 +388,10 @@ * of the CPU after executing the instruction * in the delay slot of an emulated branch. */ + /* Terminate if exception was recognized as a delay slot return */ + if(do_dsemulret(regs)) return; - if ((unsigned long)regs->cp0_epc == current->thread.dsemul_aerpc) { - do_dsemulret(regs); - return; - } + /* Otherwise handle as normal */ /* * Did we catch a fault trying to load an instruction? @@ -417,7 +413,6 @@ return; sigbus: - die_if_kernel ("Kernel unaligned instruction access", regs); force_sig(SIGBUS, current); return; Index: linux/arch/mips/math-emu/cp1emu.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/cp1emu.c,v retrieving revision 1.7 diff -u -r1.7 cp1emu.c --- linux/arch/mips/math-emu/cp1emu.c 2001/08/02 21:55:26 1.7 +++ linux/arch/mips/math-emu/cp1emu.c 2001/08/15 12:33:38 @@ -6,7 +6,7 @@ * http://www.algor.co.uk * * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com - * Copyright (C) 2000 MIPS Technologies, Inc. + * Copyright (C) 2000-2001 MIPS Technologies, Inc. * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as @@ -273,7 +273,10 @@ fpuemuprivate.stats.errors++; return SIGBUS; } + /* __computer_return_epc() will have updated cp0_epc */ contpc = REG_TO_VA xcp->cp0_epc; + /* In order not to confuse ptrace() et al, tweak context */ + xcp->cp0_epc = VA_TO_REG emulpc - 4; } else { emulpc = REG_TO_VA xcp->cp0_epc; contpc = REG_TO_VA xcp->cp0_epc + 4; @@ -753,29 +756,73 @@ * execution of delay-slot instruction execution. */ +* Instruction inserted following delay slot instruction to force trap */ + +#define AdELOAD 0x8c000001 /* lw $0,1($0) */ + +/* Instruction inserted following the AdELOAD to further tag the sequence */ + +#define BD_COOKIE 0x0000bd36 /* tne $0,$0 with baggage */ + int do_dsemulret(struct pt_regs *xcp) { + unsigned long *pinst; + unsigned long stackitem; + int err = 0; + + /* See if this trap was deliberate. First check the instruction */ + + pinst = (unsigned long *) REG_TO_VA(xcp->cp0_epc); + + /* + * If we can't even access the area, something is very + * wrong, but we'll leave that to the default handling + */ + if (verify_area(VERIFY_READ, pinst, sizeof(unsigned long) * 3)) + return 0; + + /* Is the instruction pointed to by the EPC an AdELOAD? */ + stackitem = mips_get_word(xcp, pinst, &err); + if (err || (stackitem != AdELOAD)) return 0; + /* Is the following memory word the BD_COOKIE? */ + stackitem = mips_get_word(xcp, pinst+1, &err); + if (err || (stackitem != BD_COOKIE)) return 0; + + /* + * At this point, we are satisfied that it's a BD emulation + * trap. Yes, a user might have deliberately put two + * malformed and useless instructions in a row in his program, + * in which case he's in for a nasty surprise - the + * next instruction will be treated as a continuation + * address! Alas, this seems to be the only way that + * we can handle signals, recursion, and longjmps() + * in the context of emulating the branch delay instruction. + */ + #ifdef DSEMUL_TRACE printk("desemulret\n"); #endif + + /* Fetch the Saved EPC to Resume */ + + stackitem = mips_get_word(xcp, pinst+2, &err); + if (err) { + /* This is not a good situation to be in */ + fpuemuprivate.stats.errors++; + force_sig(SIGBUS, current); + return(1); + } + /* Set EPC to return to post-branch instruction */ - xcp->cp0_epc = current->thread.dsemul_epc; - /* - * Clear the state that got us here. - */ - current->thread.dsemul_aerpc = (unsigned long) 0; + xcp->cp0_epc = stackitem; - return 0; + return 1; } - -#define AdELOAD 0x8c000001 /* lw $0,1($0) */ - static int mips_dsemul(struct pt_regs *xcp, mips_instruction ir, vaddr_t cpc) { mips_instruction *dsemul_insns; - mips_instruction forcetrap; extern asmlinkage void handle_dsemulret(void); if (ir == 0) { /* a nop is easy */ @@ -791,13 +838,22 @@ * and put a trap after it which we can catch and jump to * the required address any alternative apart from full * instruction emulation!!. + * + * Algorithmics used a system call instruction, and + * borrowed that vector. MIPS/Linux version is a bit + * more heavyweight in the interests of portability and + * multiprocessor support. We flag the thread for special + * handling in the unaligned access handler and force an + * address error excpetion. */ - dsemul_insns = (mips_instruction *) (xcp->regs[29] & ~3); - dsemul_insns -= 3; /* Two instructions, plus one for luck ;-) */ + + /* Ensure that the two instructions are in the same cache line */ + dsemul_insns = (mips_instruction *) (xcp->regs[29] & ~0xf); + dsemul_insns -= 4; /* Retain 16-byte alignment */ /* Verify that the stack pointer is not competely insane */ if (verify_area(VERIFY_WRITE, dsemul_insns, - sizeof(mips_instruction) * 2)) + sizeof(mips_instruction) * 4)) return SIGBUS; if (mips_put_word(xcp, &dsemul_insns[0], ir)) { @@ -805,29 +861,22 @@ return SIGBUS; } - /* - * Algorithmics used a system call instruction, and - * borrowed that vector. MIPS/Linux version is a bit - * more heavyweight in the interests of portability and - * multiprocessor support. We flag the thread for special - * handling in the unaligned access handler and force an - * address error excpetion. - */ + if (mips_put_word(xcp, &dsemul_insns[1], (mips_instruction)AdELOAD)) { + fpuemuprivate.stats.errors++; + return (SIGBUS); + } - /* If one is *really* paranoid, one tests for a bad stack pointer */ - if ((xcp->regs[29] & 0x3) == 0x3) - forcetrap = AdELOAD - 1; - else - forcetrap = AdELOAD; + if (mips_put_word(xcp, &dsemul_insns[2], + (mips_instruction)BD_COOKIE)) { + fpuemuprivate.stats.errors++; + return (SIGBUS); + } - if (mips_put_word(xcp, &dsemul_insns[1], forcetrap)) { + if (mips_put_word(xcp, &dsemul_insns[3], (mips_instruction)cpc)) { fpuemuprivate.stats.errors++; return (SIGBUS); } - /* Set thread state to catch and handle the exception */ - current->thread.dsemul_epc = (unsigned long) cpc; - current->thread.dsemul_aerpc = (unsigned long) &dsemul_insns[1]; xcp->cp0_epc = VA_TO_REG & dsemul_insns[0]; flush_cache_sigtramp((unsigned long) dsemul_insns); Index: linux/arch/mips/math-emu/kernel_linkage.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/kernel_linkage.c,v retrieving revision 1.3 diff -u -r1.3 kernel_linkage.c --- linux/arch/mips/math-emu/kernel_linkage.c 2001/01/13 18:17:58 1.3 +++ linux/arch/mips/math-emu/kernel_linkage.c 2001/08/15 12:33:38 @@ -3,7 +3,7 @@ * arch/mips/math_emu/kernel_linkage.c * * Kevin D. Kissell, kevink@mips and Carsten Langgaard, carstenl@mips.com - * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + * Copyright (C) 2000-2001 MIPS Technologies, Inc. All rights reserved. * * ######################################################################## * @@ -45,7 +45,7 @@ if (first) { first = 0; - printk("Algorithmics/MIPS FPU Emulator v1.4\n"); + printk("Algorithmics/MIPS FPU Emulator v1.5\n"); } current->thread.fpu.soft.sr = 0; Index: linux/arch/mips/tools/offset.c =================================================================== RCS file: /cvs/linux/arch/mips/tools/offset.c,v retrieving revision 1.16 diff -u -r1.16 offset.c --- linux/arch/mips/tools/offset.c 2000/12/10 07:56:02 1.16 +++ linux/arch/mips/tools/offset.c 2001/08/15 12:33:39 @@ -121,10 +121,6 @@ thread.irix_trampoline); offset("#define THREAD_OLDCTX ", struct task_struct, \ thread.irix_oldctx); - offset("#define THREAD_DSEEPC ", struct task_struct, \ - thread.dsemul_epc); - offset("#define THREAD_DSEAERPC ", struct task_struct, \ - thread.dsemul_aerpc); linefeed; } Index: linux/include/asm-mips/processor.h =================================================================== RCS file: /cvs/linux/include/asm-mips/processor.h,v retrieving revision 1.37 diff -u -r1.37 processor.h --- linux/include/asm-mips/processor.h 2001/07/23 00:17:39 1.37 +++ linux/include/asm-mips/processor.h 2001/08/15 12:33:42 @@ -151,21 +151,6 @@ mm_segment_t current_ds; unsigned long irix_trampoline; /* Wheee... */ unsigned long irix_oldctx; - - /* - * These are really only needed if the full FPU emulator is configured. - * Would be made conditional on MIPS_FPU_EMULATOR if it weren't for the - * fact that having offset.h rebuilt differently for different config - * options would be asking for trouble. - * - * Saved EPC during delay-slot emulation (see math-emu/cp1emu.c) - */ - unsigned long dsemul_epc; - - /* - * Pointer to instruction used to induce address error - */ - unsigned long dsemul_aerpc; }; #endif /* !defined (_LANGUAGE_ASSEMBLY) */ @@ -195,11 +180,6 @@ * For now the default is to fix address errors \ */ \ MF_FIXADE, { 0 }, 0, 0, \ - /* \ - * dsemul_epc and dsemul_aerpc should never be used uninitialized, \ - * but... \ - */ \ - 0 ,0 \ } #ifdef __KERNEL__ @@ -235,8 +215,8 @@ * Do necessary setup to start up a newly executed thread. */ #define start_thread(regs, new_pc, new_sp) do { \ - /* New thread looses kernel privileges. */ \ - regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU)) | KU_USER;\ + /* New thread loses kernel and FPU privileges. */ \ + regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\ regs->cp0_epc = new_pc; \ regs->regs[29] = new_sp; \ current->thread.current_ds = USER_DS; \ --------------B681E670EA042CA2391804E1-- From owner-linux-mips@oss.sgi.com Wed Aug 15 10:57:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FHvGP20700 for linux-mips-outgoing; Wed, 15 Aug 2001 10:57:16 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FHv6j20659; Wed, 15 Aug 2001 10:57:06 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id DFAD23E90; Wed, 15 Aug 2001 10:44:35 -0700 (PDT) Date: Wed, 15 Aug 2001 10:44:35 -0700 From: Keith M Wesolowski To: "Maciej W. Rozycki" Cc: "Gleb O. Raiko" , Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype Message-ID: <20010815104435.A8370@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 821 Lines: 17 On Tue, Aug 14, 2001 at 07:43:23PM +0200, Maciej W. Rozycki wrote: > How do you set up mips_machtype on your system in the first place? At > kernel_entry the code does not know what machine it's running on anyway, > so it has to set mips_machtype based on a detection algorithm. Of course. I published a patch and some documentation a long time ago for doing just this. I don't think anyone ever even read any of it; I received no comments. In any case it's currently used in my tree for O2 and although I know it could be better it seems to work rather well. -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Wed Aug 15 11:04:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FI4g522331 for linux-mips-outgoing; Wed, 15 Aug 2001 11:04:42 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FI4fj22325 for ; Wed, 15 Aug 2001 11:04:41 -0700 Received: (qmail 8241 invoked by uid 502); 15 Aug 2001 18:04:40 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Keith M Wesolowski , "Maciej W. Rozycki" Subject: Re: [patch] linux 2.4.5: Export mips_machtype Date: Wed, 15 Aug 2001 11:04:37 -0700 X-Mailer: KMail [version 1.2] Cc: "Gleb O. Raiko" , Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com References: <20010815104435.A8370@foobazco.org> In-Reply-To: <20010815104435.A8370@foobazco.org> MIME-Version: 1.0 Message-Id: <0108151104370T.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1038 Lines: 24 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 15 August 2001 10:44, Keith M Wesolowski wrote: > On Tue, Aug 14, 2001 at 07:43:23PM +0200, Maciej W. Rozycki wrote: > > How do you set up mips_machtype on your system in the first place? At > > kernel_entry the code does not know what machine it's running on anyway, > > so it has to set mips_machtype based on a detection algorithm. > > Of course. I published a patch and some documentation a long time ago > for doing just this. I don't think anyone ever even read any of it; I > received no comments. In any case it's currently used in my tree for > O2 and although I know it could be better it seems to work rather > well. Not true. I read it, and thought it's good enough to leave as is :-) No comments seemed to be nessesary. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt6ubgACgkQtKh84cA8u2nZhgCg2eg3Z48ZjXca9x3Rctt48Jj9 oisAoKEF2LQz3tnIc+I+j6nfSnOdFKgG =+aUM -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed Aug 15 11:05:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FI5x122674 for linux-mips-outgoing; Wed, 15 Aug 2001 11:05:59 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FI5vj22662 for ; Wed, 15 Aug 2001 11:05:57 -0700 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15X53q-0007UB-00; Wed, 15 Aug 2001 11:06:34 -0700 Date: Wed, 15 Aug 2001 11:06:34 -0700 From: Daniel Jacobowitz To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: FP emulator patch Message-ID: <20010815110634.A19305@nevyn.them.org> References: <3B7A70B8.ED92FE4@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <3B7A70B8.ED92FE4@mips.com>; from carstenl@mips.com on Wed, Aug 15, 2001 at 02:53:12PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2078 Lines: 57 On Wed, Aug 15, 2001 at 02:53:12PM +0200, Carsten Langgaard wrote: > There has been some reports regarding FP emulator failures, which the > attached patch should solve. > The patch include a fix for emulation of instructions in a COP1 > delay-slot, a fix for FP context switching and some additional stuff , > which was needed to pass our torture test. > > Ralf could you please apply this patch. Two comments, especially since parts of this seem to be the patch I posted here over a month ago. > Index: linux/arch/mips/kernel/signal.c > @@ -353,12 +355,11 @@ > owned_fp = (current == last_task_used_math); > err |= __put_user(owned_fp, &sc->sc_ownedfp); > > - if (current->used_math) { /* fp is active. */ > + if (owned_fp) { /* fp is active. */ > set_cp0_status(ST0_CU1); > err |= save_fp_context(sc); > last_task_used_math = NULL; > regs->cp0_status &= ~ST0_CU1; > - current->used_math = 0; > } > > return err; This is absolutely not right. It's righter than the status quo. If we don't own the FP, you don't save the FP. Then we can use FP in the signal handler, corrupting the process's original floating point context. > Index: linux/include/asm-mips/processor.h > @@ -235,8 +215,8 @@ > * Do necessary setup to start up a newly executed thread. > */ > #define start_thread(regs, new_pc, new_sp) do { \ > - /* New thread looses kernel privileges. */ \ > - regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU)) | KU_USER;\ > + /* New thread loses kernel and FPU privileges. */ \ > + regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\ > regs->cp0_epc = new_pc; \ > regs->regs[29] = new_sp; \ > current->thread.current_ds = USER_DS; \ I could be misremembering, but I believe that Ralf said this should be unnecessary and the problem was somewhere else. On the other hand, I still think it's a good idea. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Aug 15 13:48:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKmDd30397 for linux-mips-outgoing; Wed, 15 Aug 2001 13:48:13 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKm9j30376 for ; Wed, 15 Aug 2001 13:48:10 -0700 content-class: urn:content-classes:message Subject: glibc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 15 Aug 2001 13:45:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A248C@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: glibc Thread-Index: AcEly0IruLuJW3b4Sfe10Uu0rmR0iQ== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7FKmCj30392 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 404 Lines: 17 Hi, ALL: I am porting Linux version 2.2.12 to Mips R3000 and need to build glibc but I could not find the following files: glibc-2.0.6.tar.gz glibc-crypt-2.0.6.tar.gz glibc-localedata-2.0.6.tar.gz glibc-linuxthreads-2.0.6.tar.gz glibc-2.0.6-mips.patch If anyone know the place I caould get the files and let me know, I would be greatly appreciated. Thank you. Steven Liu From owner-linux-mips@oss.sgi.com Wed Aug 15 13:56:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FKuRX32198 for linux-mips-outgoing; Wed, 15 Aug 2001 13:56:27 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FKuQj32190 for ; Wed, 15 Aug 2001 13:56:26 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15X7kU-000416-00; Wed, 15 Aug 2001 21:58:46 +0100 Subject: Re: glibc To: stevenliu@psdc.com (Steven Liu) Date: Wed, 15 Aug 2001 21:58:46 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: from "Steven Liu" at Aug 15, 2001 01:45:47 PM X-Mailer: ELM [version 2.5 PL5] 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: 298 Lines: 11 > I am porting Linux version 2.2.12 to Mips R3000 and need to build glibc > but I could not find the following files: Oh no not again. 2.2.12 is historical value only. It has remote vulnerabilities and shouldnt be used for anything. > glibc-2.0.6.tar.gz glibc 2.0 is also obsolete, heavily so From owner-linux-mips@oss.sgi.com Wed Aug 15 14:02:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FL2LT01113 for linux-mips-outgoing; Wed, 15 Aug 2001 14:02:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FL25j01060 for ; Wed, 15 Aug 2001 14:02:19 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7FL63A29810; Wed, 15 Aug 2001 14:06:43 -0700 Message-ID: <3B7AE3FE.1070103@pacbell.net> Date: Wed, 15 Aug 2001 14:05:02 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Steven Liu CC: linux-mips@oss.sgi.com Subject: Re: glibc References: <84CE342693F11946B9F54B18C1AB837B0A248C@ex2k.pcs.psdc.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: 871 Lines: 25 Steven Liu wrote: > Hi, ALL: > > I am porting Linux version 2.2.12 to Mips R3000 and need to build glibc > but I could not find the following files: > > glibc-2.0.6.tar.gz > glibc-crypt-2.0.6.tar.gz > glibc-localedata-2.0.6.tar.gz > glibc-linuxthreads-2.0.6.tar.gz > glibc-2.0.6-mips.patch > > If anyone know the place I caould get the files and let me know, I would > be greatly appreciated. Why are you porting 2.2.12? 2.4 is much more easy to port and there's already pretty good support for a number of different boards. The tools and glibc (2.2.3) are ready and available from a few places. And, you are much more likely to get help from someone with the 2.4 kernel, since that's what everyone seems to be using. As soon as your 2.2.12 port is done, it will be dead. Who are you going to submit it to? Just my 2c anyway. Pete From owner-linux-mips@oss.sgi.com Wed Aug 15 14:33:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLXWR08894 for linux-mips-outgoing; Wed, 15 Aug 2001 14:33:32 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLXVj08882 for ; Wed, 15 Aug 2001 14:33:31 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR15BZ>; Wed, 15 Aug 2001 16:33:14 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BF3@ATVX> From: "Siders, Keith" To: "'Steven Liu'" , linux-mips@oss.sgi.com Subject: RE: glibc Date: Wed, 15 Aug 2001 16:31:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 708 Lines: 29 Go to http://www.mips.com/ and look for the developer tools. -> -----Original Message----- -> From: Steven Liu [mailto:stevenliu@psdc.com] -> Sent: Wednesday, August 15, 2001 3:46 PM -> To: linux-mips@oss.sgi.com -> Subject: glibc -> -> -> Hi, ALL: -> -> I am porting Linux version 2.2.12 to Mips R3000 and need to -> build glibc -> but I could not find the following files: -> -> glibc-2.0.6.tar.gz -> glibc-crypt-2.0.6.tar.gz -> glibc-localedata-2.0.6.tar.gz -> glibc-linuxthreads-2.0.6.tar.gz -> glibc-2.0.6-mips.patch -> -> If anyone know the place I caould get the files and let me -> know, I would -> be greatly appreciated. -> -> Thank you. -> -> Steven Liu -> From owner-linux-mips@oss.sgi.com Wed Aug 15 14:38:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLcB609917 for linux-mips-outgoing; Wed, 15 Aug 2001 14:38:11 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLcAj09907 for ; Wed, 15 Aug 2001 14:38:10 -0700 Received: (qmail 10052 invoked by uid 502); 15 Aug 2001 21:38:09 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: "Siders, Keith" , "'Steven Liu'" , linux-mips@oss.sgi.com Subject: Re: glibc Date: Wed, 15 Aug 2001 14:38:06 -0700 X-Mailer: KMail [version 1.2] References: <7DF7BFDC95ECD411B4010090278A44CA0A3BF3@ATVX> In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA0A3BF3@ATVX> MIME-Version: 1.0 Message-Id: <0108151438060U.07543@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1229 Lines: 45 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do NOT go there. Do NOT look for development tools. Port 2.4.x I wonder when MIPS will remove that 2.2.12 kit from their site..... On Wednesday 15 August 2001 14:31, Siders, Keith wrote: > Go to http://www.mips.com/ and look for the developer tools. > > -> -----Original Message----- > -> From: Steven Liu [mailto:stevenliu@psdc.com] > -> Sent: Wednesday, August 15, 2001 3:46 PM > -> To: linux-mips@oss.sgi.com > -> Subject: glibc > -> > -> > -> Hi, ALL: > -> > -> I am porting Linux version 2.2.12 to Mips R3000 and need to > -> build glibc > -> but I could not find the following files: > -> > -> glibc-2.0.6.tar.gz > -> glibc-crypt-2.0.6.tar.gz > -> glibc-localedata-2.0.6.tar.gz > -> glibc-linuxthreads-2.0.6.tar.gz > -> glibc-2.0.6-mips.patch > -> > -> If anyone know the place I caould get the files and let me > -> know, I would > -> be greatly appreciated. > -> > -> Thank you. > -> > -> Steven Liu > -> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjt668EACgkQtKh84cA8u2kCxwCff1UwiYf1UZO11dmtgOEPBB9t 7l8AoKQ5XVajZ8Dy/Sc5Hw3exowaMLcg =IQWT -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed Aug 15 14:39:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLdSV10175 for linux-mips-outgoing; Wed, 15 Aug 2001 14:39:28 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLdPj10166 for ; Wed, 15 Aug 2001 14:39:25 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR15B9>; Wed, 15 Aug 2001 16:39:04 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BF4@ATVX> From: "Siders, Keith" To: "'ilya@theIlya.com'" , "'Steven Liu'" , linux-mips@oss.sgi.com Subject: RE: glibc Date: Wed, 15 Aug 2001 16:37:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1609 Lines: 55 2.4.3 is available there... -> -----Original Message----- -> From: Ilya Volynets [mailto:ilya@theIlya.com] -> Sent: Wednesday, August 15, 2001 4:38 PM -> To: Siders, Keith; 'Steven Liu'; linux-mips@oss.sgi.com -> Subject: Re: glibc -> -> -> -----BEGIN PGP SIGNED MESSAGE----- -> Hash: SHA1 -> -> Do NOT go there. Do NOT look for development tools. -> Port 2.4.x -> I wonder when MIPS will remove that 2.2.12 kit from their site..... -> -> On Wednesday 15 August 2001 14:31, Siders, Keith wrote: -> > Go to http://www.mips.com/ and look for the developer tools. -> > -> > -> -----Original Message----- -> > -> From: Steven Liu [mailto:stevenliu@psdc.com] -> > -> Sent: Wednesday, August 15, 2001 3:46 PM -> > -> To: linux-mips@oss.sgi.com -> > -> Subject: glibc -> > -> -> > -> -> > -> Hi, ALL: -> > -> -> > -> I am porting Linux version 2.2.12 to Mips R3000 and need to -> > -> build glibc -> > -> but I could not find the following files: -> > -> -> > -> glibc-2.0.6.tar.gz -> > -> glibc-crypt-2.0.6.tar.gz -> > -> glibc-localedata-2.0.6.tar.gz -> > -> glibc-linuxthreads-2.0.6.tar.gz -> > -> glibc-2.0.6-mips.patch -> > -> -> > -> If anyone know the place I caould get the files and let me -> > -> know, I would -> > -> be greatly appreciated. -> > -> -> > -> Thank you. -> > -> -> > -> Steven Liu -> > -> -> -----BEGIN PGP SIGNATURE----- -> Version: GnuPG v1.0.4 (GNU/Linux) -> Comment: For info see http://www.gnupg.org -> -> iEYEARECAAYFAjt668EACgkQtKh84cA8u2kCxwCff1UwiYf1UZO11dmtgOEPBB9t -> 7l8AoKQ5XVajZ8Dy/Sc5Hw3exowaMLcg -> =IQWT -> -----END PGP SIGNATURE----- -> From owner-linux-mips@oss.sgi.com Wed Aug 15 14:51:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLpWj12283 for linux-mips-outgoing; Wed, 15 Aug 2001 14:51:32 -0700 Received: from newsmtp2.atmel.com (newsmtp2.atmel.org [12.146.133.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLpVj12277 for ; Wed, 15 Aug 2001 14:51:31 -0700 Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105]) by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA18941 for ; Wed, 15 Aug 2001 14:44:26 -0700 (PDT) Received: from mmc.atmel.com (mail [10.127.240.34]) by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA25112 for ; Wed, 15 Aug 2001 14:44:44 -0700 (PDT) Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163]) by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id RAA23512 for ; Wed, 15 Aug 2001 17:51:34 -0400 (EDT) Message-ID: <3B7AFD6B.C0891B97@mmc.atmel.com> Date: Wed, 15 Aug 2001 17:53:31 -0500 From: Shuanglin Wang Reply-To: swang@mmc.atmel.com Organization: ATMEL MMC X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: About booting malta board. References: <20010810153944.89482.qmail@web13906.mail.yahoo.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 345 Lines: 13 I try to install the Linux on the Malta board. In the big-endian mode, it works fine. But in the little-endian mode, the kernel just displayed "LINUX started..." and then deadlock. Does anybody can help me solve the problem ? I guess the system maybe failed to create an initial console for displaying messages to me? Thanks, --Shuanglin From owner-linux-mips@oss.sgi.com Wed Aug 15 14:59:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FLxAc13847 for linux-mips-outgoing; Wed, 15 Aug 2001 14:59:10 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FLx9j13840 for ; Wed, 15 Aug 2001 14:59:09 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA24667; Wed, 15 Aug 2001 14:59:02 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id OAA05223; Wed, 15 Aug 2001 14:59:01 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7FLvfa17185; Wed, 15 Aug 2001 23:57:41 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id XAA29536; Wed, 15 Aug 2001 23:57:41 +0200 (MET DST) Message-Id: <200108152157.XAA29536@copsun17.mips.com> Subject: Re: About booting malta board. To: swang@mmc.atmel.com Date: Wed, 15 Aug 2001 23:57:41 +0200 (MET DST) Cc: linux-mips@oss.sgi.com In-Reply-To: <3B7AFD6B.C0891B97@mmc.atmel.com> from "Shuanglin Wang" at Aug 15, 2001 05:53:31 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: 881 Lines: 24 You would need to be a little more specific if you want help - e.g. what kernel did you boot, did you get the binary from the MIPS Malta CDROM or website, did you compile yourself, what "go" command parameters did you use to launch the kernel, what CPU are you running on, etc. Only idea I can come up with unless you are more specific is that you accidentally booted the wrong kernel, e.g. Atlas board kernel instead of Malta - this kernel will startup and then hang quickly. /Hartvig Shuanglin Wang writes: > > I try to install the Linux on the Malta board. In the big-endian mode, it > works fine. But in the little-endian mode, the kernel just displayed > "LINUX started..." and then deadlock. Does anybody can help me solve the > problem ? > > I guess the system maybe failed to create an initial console for displaying > messages to me? > > Thanks, > > --Shuanglin From owner-linux-mips@oss.sgi.com Wed Aug 15 15:05:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FM5G315072 for linux-mips-outgoing; Wed, 15 Aug 2001 15:05:16 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FM5Cj15057 for ; Wed, 15 Aug 2001 15:05:12 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR15CS>; Wed, 15 Aug 2001 17:04:54 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BF7@ATVX> From: "Siders, Keith" To: "'linux-mips@oss.sgi.com'" Subject: Re: glibc Date: Wed, 15 Aug 2001 17:03:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2980 Lines: 88 http://www.mips.com/devTools/devArea/Linux.html states "The MIPS Linux kernel is available based on both 2.2.12 and 2.4 releases, and is provided as a reference for developers using Linux in a system based on a MIPS Technologies core. It supports MIPS32 and MIPS64 CPUs..." Why are people grabbing 2.2.12? Don't know, but 2.4 is available at ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/. Additional info is available up a couple levels at ftp://ftp.mips.com/pub/linux/mips/. Enjoy... -> -----Original Message----- -> From: Ilya Volynets [mailto:ilya@theIlya.com] -> Sent: Wednesday, August 15, 2001 4:42 PM -> To: Siders, Keith -> Subject: Re: glibc -> -> -> -----BEGIN PGP SIGNED MESSAGE----- -> Hash: SHA1 -> -> Why are people trying to port 2.2.12 all the time, then? -> -> On Wednesday 15 August 2001 14:37, you wrote: -> > 2.4.3 is available there... -> > -> > -> -----Original Message----- -> > -> From: Ilya Volynets [mailto:ilya@theIlya.com] -> > -> Sent: Wednesday, August 15, 2001 4:38 PM -> > -> To: Siders, Keith; 'Steven Liu'; linux-mips@oss.sgi.com -> > -> Subject: Re: glibc -> > -> -> > -> -> > -> -----BEGIN PGP SIGNED MESSAGE----- -> > -> Hash: SHA1 -> > -> -> > -> Do NOT go there. Do NOT look for development tools. -> > -> Port 2.4.x -> > -> I wonder when MIPS will remove that 2.2.12 kit from -> their site..... -> > -> -> > -> On Wednesday 15 August 2001 14:31, Siders, Keith wrote: -> > -> > Go to http://www.mips.com/ and look for the developer tools. -> > -> > -> > -> > -> -----Original Message----- -> > -> > -> From: Steven Liu [mailto:stevenliu@psdc.com] -> > -> > -> Sent: Wednesday, August 15, 2001 3:46 PM -> > -> > -> To: linux-mips@oss.sgi.com -> > -> > -> Subject: glibc -> > -> > -> -> > -> > -> -> > -> > -> Hi, ALL: -> > -> > -> -> > -> > -> I am porting Linux version 2.2.12 to Mips R3000 and need to -> > -> > -> build glibc -> > -> > -> but I could not find the following files: -> > -> > -> -> > -> > -> glibc-2.0.6.tar.gz -> > -> > -> glibc-crypt-2.0.6.tar.gz -> > -> > -> glibc-localedata-2.0.6.tar.gz -> > -> > -> glibc-linuxthreads-2.0.6.tar.gz -> > -> > -> glibc-2.0.6-mips.patch -> > -> > -> -> > -> > -> If anyone know the place I caould get the files and let me -> > -> > -> know, I would -> > -> > -> be greatly appreciated. -> > -> > -> -> > -> > -> Thank you. -> > -> > -> -> > -> > -> Steven Liu -> > -> > -> -> > -> -----BEGIN PGP SIGNATURE----- -> > -> Version: GnuPG v1.0.4 (GNU/Linux) -> > -> Comment: For info see http://www.gnupg.org -> > -> -> > -> iEYEARECAAYFAjt668EACgkQtKh84cA8u2kCxwCff1UwiYf1UZO11dmtgOEPBB9t -> > -> 7l8AoKQ5XVajZ8Dy/Sc5Hw3exowaMLcg -> > -> =IQWT -> > -> -----END PGP SIGNATURE----- -> > -> -> -----BEGIN PGP SIGNATURE----- -> Version: GnuPG v1.0.4 (GNU/Linux) -> Comment: For info see http://www.gnupg.org -> -> iEUEARECAAYFAjt67MwACgkQtKh84cA8u2nm6wCbBwx8sTgrDVM0OAhc5nJ2yQj8 -> Jp4AlRa1sIz35E2ulVdZ0HqiOjCjCVs= -> =qs+y -> -----END PGP SIGNATURE----- -> From owner-linux-mips@oss.sgi.com Wed Aug 15 15:08:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FM8FU15801 for linux-mips-outgoing; Wed, 15 Aug 2001 15:08:15 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FM8Ej15795 for ; Wed, 15 Aug 2001 15:08:14 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7FMCvA01074; Wed, 15 Aug 2001 15:12:57 -0700 Message-ID: <3B7AF3A2.4010404@pacbell.net> Date: Wed, 15 Aug 2001 15:11:46 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: swang@mmc.atmel.com CC: linux-mips@oss.sgi.com Subject: Re: About booting malta board. References: <20010810153944.89482.qmail@web13906.mail.yahoo.com> <3B7AFD6B.C0891B97@mmc.atmel.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 549 Lines: 15 Shuanglin Wang wrote: > I try to install the Linux on the Malta board. In the big-endian mode, it > works fine. But in the little-endian mode, the kernel just displayed > "LINUX started..." and then deadlock. Does anybody can help me solve the > problem ? > > I guess the system maybe failed to create an initial console for displaying > messages to me? What kernel and where did you get it from? MontaVista has a Linux Support Package (LSP) for the Malta and it's available on the Journeyman Mips CD. I'm pretty sure it's little endian. Pete From owner-linux-mips@oss.sgi.com Wed Aug 15 15:51:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FMpJq23345 for linux-mips-outgoing; Wed, 15 Aug 2001 15:51:19 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FMp0j23265 for ; Wed, 15 Aug 2001 15:51:00 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 27526125C4; Wed, 15 Aug 2001 15:50:52 -0700 (PDT) Date: Wed, 15 Aug 2001 15:50:52 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , GNU C Library , gcc@gcc.gnu.org Subject: The Linux binutils 2.11.90.0.27 is released. Message-ID: <20010815155052.A30688@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: 13356 Lines: 480 This release only works when ELF is in BFD. All Linux targets should include ELF. This bug will be fixed in the next release. H.J. ---- This is the beta release of binutils 2.11.90.0.27 for Linux, which is based on binutils 2001 0726 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.27 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.27.tar.gz. Source code. 2. binutils-2.11.90.0.25-2.11.90.0.27.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.27-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.27.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 08/15/2001 From owner-linux-mips@oss.sgi.com Wed Aug 15 17:01:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G01aT04629 for linux-mips-outgoing; Wed, 15 Aug 2001 17:01:36 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G01Xj04612 for ; Wed, 15 Aug 2001 17:01:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id RAA26098; Wed, 15 Aug 2001 17:01:20 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id RAA08229; Wed, 15 Aug 2001 17:01:18 -0700 (PDT) Message-ID: <010001c125e7$35ca2d80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Carsten Langgaard" Cc: References: <3B7A70B8.ED92FE4@mips.com> <20010815110634.A19305@nevyn.them.org> Subject: Re: FP emulator patch Date: Thu, 16 Aug 2001 02:05:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2997 Lines: 83 > Two comments, especially since parts of this seem to be the patch I > posted here over a month ago. > > > Index: linux/arch/mips/kernel/signal.c > > > @@ -353,12 +355,11 @@ > > owned_fp = (current == last_task_used_math); > > err |= __put_user(owned_fp, &sc->sc_ownedfp); > > > > - if (current->used_math) { /* fp is active. */ > > + if (owned_fp) { /* fp is active. */ > > set_cp0_status(ST0_CU1); > > err |= save_fp_context(sc); > > last_task_used_math = NULL; > > regs->cp0_status &= ~ST0_CU1; > > - current->used_math = 0; > > } > > > > return err; > > This is absolutely not right. It's righter than the status quo. If we > don't own the FP, you don't save the FP. Then we can use FP in the > signal handler, corrupting the process's original floating point > context. I only worked on the FP branch emulation fix, and hadn't looked at the stack signal context problem until now. If the current thread has any FPU state, it needs to be saved ahead of signal delivery for the reasons you suggest above. I assume that's the reason for the previous "if (current->used_math)" condition. If there's been a problem with FP register corruption in the face of signals and context switches, it's presumably because, while we're saving the state in the sigcontext so that it will be restored on the signal return, we're also clearing last_task_used_math and curren->used_math. The former means that if we invoke the signal handler, it returns, and we will restore the FP context to the register file. But if the signal handler *doesn't* do any FP, we've got a "dirty" FPU and no owner for the state, and Bad Things happen. And the way the current code is written, if the signal handler does happen to acquire the FPU, the thread inherits the enable, the register contents, and an obligation to save the FPU state uselessly on the next context switch. I don't understand why there is any manipulation of the FPU ownership status going on in setup_sigcontext(), nor any persistent modification of the Cp0.Status state. Shouldn't the code in setup_sigcontext() look more like: if(owned_fp) { /* Not clear to me how we could have owned_fp true with CU1 off. Double check this... */ someaccursednewtemp = regs->cp0_status; set_cp0_status(ST0_CU1); err |= save_fp_context(sc); regs->cp0_status = someaccursednewtemp; } Then, in the symmetric code fragment in restore_sigcontext() if(owned_fp) { err |= restore_fp_context(sc); } else { if (current == last_task_used_math) { /* signal handler acquired FPU - give it back */ last_task_used_math = NULL; current->used_math = 0; clear_cp0_status(ST0_CU1); } } Disclaimer: The above was typed into Outlook Express and may contain typos, but I think it expresses the idea well enough for someone to tell me if I'm completely off base. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Aug 15 19:05:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G25Sq28740 for linux-mips-outgoing; Wed, 15 Aug 2001 19:05:28 -0700 Received: from sioux.meginc.com (Sioux.meginc.com [207.246.76.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G25Rj28735 for ; Wed, 15 Aug 2001 19:05:27 -0700 Received: from dell.meginc.com ([207.246.76.106]) by sioux.meginc.com (8.9.3/8.9.1) with SMTP id WAA30473; Wed, 15 Aug 2001 22:04:19 -0400 (EDT) (envelope-from bebarker@meginc.com) Content-Type: text/plain; charset="gb2312" From: Brandon Barker To: swang@mmc.atmel.com Subject: Re: About booting malta board. Date: Wed, 15 Aug 2001 22:09:34 -0400 X-Mailer: KMail [version 1.2] References: <20010810153944.89482.qmail@web13906.mail.yahoo.com> <3B7AFD6B.C0891B97@mmc.atmel.com> In-Reply-To: <3B7AFD6B.C0891B97@mmc.atmel.com> Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Message-Id: <01081522093400.14676@dell.meginc.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 598 Lines: 16 On a slightly related note, is it possible to have more than 64MB of memory on a Malta board? If so, I may get a Malta - it would be a little more exciting to work with than my Indy. On Wednesday 15 August 2001 06:53 pm, you wrote: > I try to install the Linux on the Malta board. In the big-endian mode, it > works fine. But in the little-endian mode, the kernel just displayed > "LINUX started..." and then deadlock. Does anybody can help me solve the > problem ? > > I guess the system maybe failed to create an initial console for displaying > messages to me? > > Thanks, > > --Shuanglin From owner-linux-mips@oss.sgi.com Wed Aug 15 19:59:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G2xZj05113 for linux-mips-outgoing; Wed, 15 Aug 2001 19:59:35 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G2xUj05106; Wed, 15 Aug 2001 19:59:30 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 16 Aug 2001 02:59:30 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 25ACD54C0E; Thu, 16 Aug 2001 11:59:28 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA69534; Thu, 16 Aug 2001 11:59:27 +0900 (JST) To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising From: Atsushi Nemoto In-Reply-To: <20010814104941.F5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.co.jp> <20010814104941.F5928@bacchus.dhis.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010816120401V.nemoto@toshiba-tops.co.jp> Date: Thu, 16 Aug 2001 12:04:01 +0900 X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1111 Lines: 27 >>>>> On Tue, 14 Aug 2001 10:49:41 +0200, Ralf Baechle said: ralf> It's wasting huge amounts of address space. That can be ralf> prohibitive if you want to run something such as electric fence. ralf> Technically the worst case of any CPU that's required is 32kb on ralf> R4000 / R4400 SC and MC versions, so I don't want to go beyond ralf> that. Yes. My patch is wasting address space. I did not know reasonable size for alignment, so I used SHMLBA value. It may be better to calculate proper alignment size on run-time or compile-time. ralf> What does this patch have to do with SysV shared mem? Shmat(2) ralf> does proper alignment checking and aligning and doesn't call ralf> arch_get_unmapped_area. I tried with this code (Xshm extention in Xserver use shm like this) : shmid = shmget(IPC_PRIVATE, 0x1000, IPC_CREAT | 0777); data = shmat(shmid, 0, 0); data2 = shmat(shmid, 0, 0); In this case, get_unmapped_area() is called with a file structure does not have 'get_unmapped_area' operation ('shmem_file_operations') so arch_get_unmapped_area() is called. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Aug 15 20:52:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G3qP210295 for linux-mips-outgoing; Wed, 15 Aug 2001 20:52:25 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G3qLj10292 for ; Wed, 15 Aug 2001 20:52:22 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 16 Aug 2001 03:52:21 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id CC24954C0E; Thu, 16 Aug 2001 12:52:19 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA69632; Thu, 16 Aug 2001 12:52:19 +0900 (JST) To: wgowcher@yahoo.com Cc: linux-mips@oss.sgi.com Subject: Re: Benchmark performance From: Atsushi Nemoto In-Reply-To: <20010813173446.61234.qmail@web11901.mail.yahoo.com> References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_16_12:56:02_2001_518)--" Content-Transfer-Encoding: 7bit Message-Id: <20010816125652N.nemoto@toshiba-tops.co.jp> Date: Thu, 16 Aug 2001 12:56:52 +0900 X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2772 Lines: 78 ----Next_Part(Thu_Aug_16_12:56:02_2001_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher said: wgowcher> a 23 % reduction in the Floating Point Index benchmark Current CVS kernel uses FPU emulator unconditionally. If one floating point intruction causes a 'Unimplemented' exception (denormalized result, etc.) following floating point instructions are also handle by FPU emulator (not only the instruction which raise the exception). I do not know this is really desired behavior, but here is a patch to change this. If Unimplemented exception had been occured during the benchmark, aplying this patch may result better performance. --- Atsushi Nemoto ----Next_Part(Thu_Aug_16_12:56:02_2001_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fpu_emu.patch" diff -ur linux.sgi/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c --- linux.sgi/arch/mips/kernel/traps.c Sun Aug 5 23:39:20 2001 +++ linux/arch/mips/kernel/traps.c Thu Aug 16 12:20:23 2001 @@ -60,7 +60,7 @@ extern asmlinkage void handle_mcheck(void); extern asmlinkage void handle_reserved(void); -extern int fpu_emulator_cop1Handler(struct pt_regs *); +extern int fpu_emulator_cop1Handler(struct pt_regs *, int); char watch_available = 0; @@ -306,7 +306,8 @@ save_fp(current); /* Run the emulator */ - sig = fpu_emulator_cop1Handler(regs); + /* Emulate only one insn if we have FPU. */ + sig = fpu_emulator_cop1Handler(regs, 1); /* * We can't allow the emulated instruction to leave the @@ -605,7 +606,7 @@ current->used_math = 1; } } - sig = fpu_emulator_cop1Handler(regs); + sig = fpu_emulator_cop1Handler(regs, 0); last_task_used_math = current; if (sig) force_sig(sig, current); diff -ur linux.sgi/arch/mips/math-emu/cp1emu.c linux/arch/mips/math-emu/cp1emu.c --- linux.sgi/arch/mips/math-emu/cp1emu.c Sun Aug 5 23:39:27 2001 +++ linux/arch/mips/math-emu/cp1emu.c Thu Aug 16 12:21:07 2001 @@ -1662,7 +1662,7 @@ * hit a non-fp instruction, or a backward branch. This cuts down dramatically * on the per instruction exception overhead. */ -int fpu_emulator_cop1Handler(struct pt_regs *xcp) +int fpu_emulator_cop1Handler(struct pt_regs *xcp, int maxcount) { struct mips_fpu_soft_struct *ctx = ¤t->thread.fpu.soft; unsigned long oldepc, prevepc; @@ -1682,6 +1682,8 @@ sig = cop1Emulate(xcp, ctx); else xcp->cp0_epc += 4; /* skip nops */ + if (maxcount && --maxcount <= 0) + break; } while (xcp->cp0_epc > prevepc && sig == 0); /* SIGILL indicates a non-fpu instruction */ ----Next_Part(Thu_Aug_16_12:56:02_2001_518)---- From owner-linux-mips@oss.sgi.com Wed Aug 15 21:16:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G4GDm11112 for linux-mips-outgoing; Wed, 15 Aug 2001 21:16:13 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G4GAj11109 for ; Wed, 15 Aug 2001 21:16:10 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 16 Aug 2001 04:16:10 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id F341954C11; Thu, 16 Aug 2001 13:16:08 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id NAA69673; Thu, 16 Aug 2001 13:16:08 +0900 (JST) To: dan@debian.org Cc: carstenl@mips.com, linux-mips@oss.sgi.com Subject: Re: FP emulator patch From: Atsushi Nemoto In-Reply-To: <20010815110634.A19305@nevyn.them.org> References: <3B7A70B8.ED92FE4@mips.com> <20010815110634.A19305@nevyn.them.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_16_13:19:40_2001_179)--" Content-Transfer-Encoding: 7bit Message-Id: <20010816132042T.nemoto@toshiba-tops.co.jp> Date: Thu, 16 Aug 2001 13:20:42 +0900 X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2235 Lines: 65 ----Next_Part(Thu_Aug_16_13:19:40_2001_179)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Wed, 15 Aug 2001 11:06:34 -0700, Daniel Jacobowitz said: >> Index: linux/arch/mips/kernel/signal.c > >> @@ -353,12 +355,11 @@ >> owned_fp = (current == last_task_used_math); >> err |= __put_user(owned_fp, &sc->sc_ownedfp); >> >> - if (current->used_math) { /* fp is active. */ >> + if (owned_fp) { /* fp is active. */ >> set_cp0_status(ST0_CU1); >> err |= save_fp_context(sc); >> last_task_used_math = NULL; >> regs->cp0_status &= ~ST0_CU1; >> - current->used_math = 0; >> } >> >> return err; dan> This is absolutely not right. It's righter than the status quo. dan> If we don't own the FP, you don't save the FP. Then we can use dan> FP in the signal handler, corrupting the process's original dan> floating point context. I also am trying to fix this problem. How about my patch? restore_sigcontext() can be more optimized, but I think this is a smallest patch to fix the problem. --- Atsushi Nemoto ----Next_Part(Thu_Aug_16_13:19:40_2001_179)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signal.c.patch" diff -ur linux.sgi/arch/mips/kernel/signal.c linux/arch/mips/kernel/signal.c --- linux.sgi/arch/mips/kernel/signal.c Mon Jun 25 22:56:56 2001 +++ linux/arch/mips/kernel/signal.c Thu Aug 16 13:09:28 2001 @@ -350,11 +350,18 @@ err |= __put_user(regs->cp0_cause, &sc->sc_cause); err |= __put_user(regs->cp0_badvaddr, &sc->sc_badvaddr); - owned_fp = (current == last_task_used_math); + /* restore_sigcontext must restore the fp context even if this + process was not last_task_used_math. */ + owned_fp = current->used_math; err |= __put_user(owned_fp, &sc->sc_ownedfp); if (current->used_math) { /* fp is active. */ +#if 0 + /* Do not set CU1 here. If this process does not + owned fp, save_fp_context causes lazy_fpu_switch + (and fp-owner's context will saved). */ set_cp0_status(ST0_CU1); +#endif err |= save_fp_context(sc); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; ----Next_Part(Thu_Aug_16_13:19:40_2001_179)---- From owner-linux-mips@oss.sgi.com Wed Aug 15 21:30:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G4UWw11620 for linux-mips-outgoing; Wed, 15 Aug 2001 21:30:32 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G4UTj11617 for ; Wed, 15 Aug 2001 21:30:29 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 16 Aug 2001 04:30:29 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 3D2F554C10; Thu, 16 Aug 2001 13:30:28 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id NAA69714; Thu, 16 Aug 2001 13:30:28 +0900 (JST) To: carstenl@mips.com Cc: linux-mips@oss.sgi.com Subject: Re: FP emulator patch From: Atsushi Nemoto In-Reply-To: <3B7A70B8.ED92FE4@mips.com> References: <3B7A70B8.ED92FE4@mips.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_16_13:34:48_2001_982)--" Content-Transfer-Encoding: 7bit Message-Id: <20010816133501S.nemoto@toshiba-tops.co.jp> Date: Thu, 16 Aug 2001 13:35:01 +0900 X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1556 Lines: 42 ----Next_Part(Thu_Aug_16_13:34:48_2001_982)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Wed, 15 Aug 2001 14:53:12 +0200, Carsten Langgaard said: carstenl> There has been some reports regarding FP emulator failures, carstenl> which the attached patch should solve. The patch include a carstenl> fix for emulation of instructions in a COP1 delay-slot, a carstenl> fix for FP context switching and some additional stuff , carstenl> which was needed to pass our torture test. There is another bug in FPU emulator. An instruction in delay slot of bc1tl/bc1fl executed(or emulated) even if the branch not taken. Here is a patch to fix this. Since current kernel calls FPU emulator on FP exception and FPU emulator handles continuous FP instructions in one call, this bug affects CPUs with FPU (not only CPUs without FPU). --- Atsushi Nemoto ----Next_Part(Thu_Aug_16_13:34:48_2001_982)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cp1emu.c.patch" diff -ur linux.sgi/arch/mips/math-emu/cp1emu.c linux/arch/mips/math-emu/cp1emu.c --- linux.sgi/arch/mips/math-emu/cp1emu.c Sun Aug 5 23:39:27 2001 +++ linux/arch/mips/math-emu/cp1emu.c Thu Aug 16 12:21:07 2001 @@ -686,7 +686,7 @@ * branch likely nullifies dslot if not * taken */ - xcp->cp0_epc += 4; + contpc += 4; /* else continue & execute dslot as normal insn */ } break; ----Next_Part(Thu_Aug_16_13:34:48_2001_982)---- From owner-linux-mips@oss.sgi.com Wed Aug 15 23:45:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G6jqj14782 for linux-mips-outgoing; Wed, 15 Aug 2001 23:45:52 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G6jpj14779 for ; Wed, 15 Aug 2001 23:45:51 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA28561; Wed, 15 Aug 2001 23:45:41 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA13494; Wed, 15 Aug 2001 23:45:42 -0700 (PDT) Received: from mips.com ([172.17.12.3]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G6iLa03876; Thu, 16 Aug 2001 08:44:22 +0200 (MEST) Message-ID: <3B7B6C04.A40B009C@mips.com> Date: Thu, 16 Aug 2001 08:45:24 +0200 From: Dan Temple X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: Ilya Volynets Subject: 2.4 on MIPS FTP site Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 957 Lines: 21 Ilya Volynets writes: > Do NOT go there. Do NOT look for development tools. > Port 2.4.x > I wonder when MIPS will remove that 2.2.12 kit from their site..... > as the one responsible for a (small) part of the MIPS website, I am wondering if you are seeing the same as I am! If I go to the Linux page: http://www.mips.com/devTools/devArea/Linux.html ..it mentions both 2.2.12 and 2.4 kernels, and the link to the FTP site leads to ftp://ftp.mips.com/pub/linux/mips/ ..where you will find both the 2.2 and 2.4 kernels under the kernel/ directory, complete with notes on how we recommend a userland upgrade. It is of course up to the user to choose what they want to do, but from your mail it sounds like you are seeing no 2.4 material on the site at all. Ilya - If you are seeing somewhere else on the site where the 2.2.12 kernel is hailed as the latest and greatest, please let me know and it will be severely dealt with. Dan Temple MIPS Denmark From owner-linux-mips@oss.sgi.com Thu Aug 16 00:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G79q915574 for linux-mips-outgoing; Thu, 16 Aug 2001 00:09:52 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G79oj15570 for ; Thu, 16 Aug 2001 00:09:50 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA28653; Thu, 16 Aug 2001 00:09:08 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA13758; Thu, 16 Aug 2001 00:09:09 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G77ma05129; Thu, 16 Aug 2001 09:07:49 +0200 (MEST) Message-ID: <3B7B7143.AFAF1ABF@mips.com> Date: Thu, 16 Aug 2001 09:07:48 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: FP emulator patch References: <3B7A70B8.ED92FE4@mips.com> <20010815110634.A19305@nevyn.them.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3005 Lines: 75 Daniel Jacobowitz wrote: > On Wed, Aug 15, 2001 at 02:53:12PM +0200, Carsten Langgaard wrote: > > There has been some reports regarding FP emulator failures, which the > > attached patch should solve. > > The patch include a fix for emulation of instructions in a COP1 > > delay-slot, a fix for FP context switching and some additional stuff , > > which was needed to pass our torture test. > > > > Ralf could you please apply this patch. > > Two comments, especially since parts of this seem to be the patch I > posted here over a month ago. You are absolutely right, it's your old patch. > > > Index: linux/arch/mips/kernel/signal.c > > > @@ -353,12 +355,11 @@ > > owned_fp = (current == last_task_used_math); > > err |= __put_user(owned_fp, &sc->sc_ownedfp); > > > > - if (current->used_math) { /* fp is active. */ > > + if (owned_fp) { /* fp is active. */ > > set_cp0_status(ST0_CU1); > > err |= save_fp_context(sc); > > last_task_used_math = NULL; > > regs->cp0_status &= ~ST0_CU1; > > - current->used_math = 0; > > } > > > > return err; > > This is absolutely not right. It's righter than the status quo. If we > don't own the FP, you don't save the FP. Then we can use FP in the > signal handler, corrupting the process's original floating point > context. You are probably right, this is not a proper fix, but at least it solves the problems people has been seeing. So until we come up with a better fix, this is still better than the current sources. > > > Index: linux/include/asm-mips/processor.h > > > @@ -235,8 +215,8 @@ > > * Do necessary setup to start up a newly executed thread. > > */ > > #define start_thread(regs, new_pc, new_sp) do { \ > > - /* New thread looses kernel privileges. */ \ > > - regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU)) | KU_USER;\ > > + /* New thread loses kernel and FPU privileges. */ \ > > + regs->cp0_status = (regs->cp0_status & ~(ST0_CU0|ST0_KSU|ST0_CU1)) | KU_USER;\ > > regs->cp0_epc = new_pc; \ > > regs->regs[29] = new_sp; \ > > current->thread.current_ds = USER_DS; \ > > I could be misremembering, but I believe that Ralf said this should be > unnecessary and the problem was somewhere else. On the other hand, I > still think it's a good idea. > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Aug 16 00:32:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G7WCA16182 for linux-mips-outgoing; Thu, 16 Aug 2001 00:32:12 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G7WBj16178 for ; Thu, 16 Aug 2001 00:32:11 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA28852; Thu, 16 Aug 2001 00:31:30 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA14018; Thu, 16 Aug 2001 00:31:29 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G7U8a06305; Thu, 16 Aug 2001 09:30:08 +0200 (MEST) Message-ID: <3B7B767F.C29A25A9@mips.com> Date: Thu, 16 Aug 2001 09:30:07 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brandon Barker CC: swang@mmc.atmel.com, linux-mips@oss.sgi.com Subject: Re: About booting malta board. References: <20010810153944.89482.qmail@web13906.mail.yahoo.com> <3B7AFD6B.C0891B97@mmc.atmel.com> <01081522093400.14676@dell.meginc.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1233 Lines: 37 Brandon Barker wrote: > On a slightly related note, is it possible to have more than 64MB of memory > on a Malta board? I have a Malta board with 128MB. Currently we have a problem in our bootloader (YAMON), it only see up till 128MB, which mean that we only use up till 128MB of the RAM module, even though the RAM module contain more than 128MB. That will be fix in a later release. > If so, I may get a Malta - it would be a little more > exciting to work with than my Indy. > > On Wednesday 15 August 2001 06:53 pm, you wrote: > > I try to install the Linux on the Malta board. In the big-endian mode, it > > works fine. But in the little-endian mode, the kernel just displayed > > "LINUX started..." and then deadlock. Does anybody can help me solve the > > problem ? > > > > I guess the system maybe failed to create an initial console for displaying > > messages to me? > > > > Thanks, > > > > --Shuanglin -- _ _ ____ ___ 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 Aug 16 00:33:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G7X7C16280 for linux-mips-outgoing; Thu, 16 Aug 2001 00:33:07 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G7X6j16275 for ; Thu, 16 Aug 2001 00:33:06 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA28873; Thu, 16 Aug 2001 00:32:58 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA14041; Thu, 16 Aug 2001 00:32:58 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G7VMa06401; Thu, 16 Aug 2001 09:31:22 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id JAA00011; Thu, 16 Aug 2001 09:31:21 +0200 (MET DST) Message-Id: <200108160731.JAA00011@copsun17.mips.com> Subject: Re: About booting malta board. To: swang@mmc.atmel.com Date: Thu, 16 Aug 2001 09:31:21 +0200 (MET DST) Cc: linux-mips@oss.sgi.com In-Reply-To: <3B7B0437.ECE7019F@mmc.atmel.com> from "Shuanglin Wang" at Aug 15, 2001 06:22:31 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: 1601 Lines: 40 So the key question is whether it is the precompiled bigendian kernel from ftp.mips.com that doesn't work or the one you compiled yourself? To verify, these are the precompiled 2.4.3 Malta kernels on ftp.mips.com: -rw-r--r-- 1 9618 40 1075193 Jul 6 04:35 vmlinux-2.4.3.malta.eb-01.00.srec.gz -rw-r--r-- 1 9618 40 1107586 Jul 6 04:35 vmlinux-2.4.3.malta.el-01.00.srec.gz If the precompiled kernel works and the one you compiled doesn't there could be something wrong in your compiler setup. We're currently compiling on Linux/x86 using the precompiled version from: ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/ It reports itself as being: /home/hartvige/tmp/linux-2.4.3> /usr/bin/mipsel-linux-gcc -v Reading specs from /usr/lib/gcc-lib/mipsel-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) /home/hartvige/tmp/linux-2.4.3> /usr/bin/mips-linux-gcc -v Reading specs from /usr/lib/gcc-lib/mips-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) /Hartvig Shuanglin Wang writes: > > I downloaded Linux pre-comipled kernel 2.4.3 from ftp.mips.com and built up > kernel images (big endian and little endian) by myself. AlsoI use NFS as the > boot directory. For the big-endian mode, everthing is fine. But, for little > endian mode, the system just display "LINUX started....", then monitor > terminal display nothing. But I'm sure the system continue booting, and after a > while, it hang. > > I just download the kernel and input: > go . nfsboot=hostIP:/linux/mipsel ip=boardIP > > Thanks From owner-linux-mips@oss.sgi.com Thu Aug 16 00:41:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G7fi016577 for linux-mips-outgoing; Thu, 16 Aug 2001 00:41:44 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G7fhj16574 for ; Thu, 16 Aug 2001 00:41:43 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA28951 for ; Thu, 16 Aug 2001 00:41:34 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA14131 for ; Thu, 16 Aug 2001 00:41:35 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G7eFa07018 for ; Thu, 16 Aug 2001 09:40:15 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id JAA00025 for linux-mips@oss.sgi.com; Thu, 16 Aug 2001 09:40:14 +0200 (MET DST) Message-Id: <200108160740.JAA00025@copsun17.mips.com> Subject: Patch to get IDE CDROM working on MIPS To: linux-mips@oss.sgi.com Date: Thu, 16 Aug 2001 09:40:14 +0200 (MET DST) 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: 1066 Lines: 27 I have gotten IDE CDROM support to work under MIPS now (tested on Malta both LE and BE with 2.4.3 kernel). It was broken due to a stack overwrite in the generic cdrom.c which for obscure reasons didn't kill an x86 kernel, but does kill a MIPS kernel, see the patch below. The patch has been accepted by the CDROM maintainer, but in case somebody wants to experiment with IDE CDROM now, have fun! /Hartvig /home/hartvige/tmp/linux-2.4.3/drivers/cdrom> diff -u cdrom.c.ORG cdrom.c --- cdrom.c.ORG Tue Aug 14 10:35:04 2001 +++ cdrom.c Tue Aug 14 14:44:14 2001 @@ -2244,8 +2244,13 @@ if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; - cgc.cmd[8] = cgc.buflen = be16_to_cpu(ti->track_information_length) + + cgc.buflen = be16_to_cpu(ti->track_information_length) + sizeof(ti->track_information_length); + + if (cgc.buflen > sizeof(track_information)) + cgc.buflen = sizeof(track_information); + + cgc.cmd[8] = cgc.buflen; return cdo->generic_packet(cdi, &cgc); } From owner-linux-mips@oss.sgi.com Thu Aug 16 00:45:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G7j6c16723 for linux-mips-outgoing; Thu, 16 Aug 2001 00:45:06 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G7j4j16719 for ; Thu, 16 Aug 2001 00:45:04 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA28991; Thu, 16 Aug 2001 00:44:52 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA14177; Thu, 16 Aug 2001 00:44:53 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7G7hOa07187; Thu, 16 Aug 2001 09:43:32 +0200 (MEST) Message-ID: <3B7B799B.BCFD1B5E@mips.com> Date: Thu, 16 Aug 2001 09:43:23 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Atsushi Nemoto CC: wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: Benchmark performance References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1572 Lines: 44 Atsushi Nemoto wrote: > >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher said: > wgowcher> a 23 % reduction in the Floating Point Index benchmark > > Current CVS kernel uses FPU emulator unconditionally. If one floating > point intruction causes a 'Unimplemented' exception (denormalized > result, etc.) following floating point instructions are also handle by > FPU emulator (not only the instruction which raise the exception). You got a point here, no need to emulate following floating point instructions, if one got a real FPU. But I think the check in the FP emulator should be a check if we got a real FPU, instead of a counter. We already has a flag for that in mips_cpu.options. The check could be something like: if (mips_cpu.options & MIPS_CPU_FPU) break; > > I do not know this is really desired behavior, but here is a patch to > change this. If Unimplemented exception had been occured during the > benchmark, aplying this patch may result better performance. > > --- > Atsushi Nemoto > > ------------------------------------------------------------------------ > Name: fpu_emu.patch > fpu_emu.patch Type: Plain Text (Text/Plain) > Encoding: 7bit -- _ _ ____ ___ 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 Aug 16 00:54:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G7sfj17063 for linux-mips-outgoing; Thu, 16 Aug 2001 00:54:41 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G7sYj17058; Thu, 16 Aug 2001 00:54:34 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA01484; Thu, 16 Aug 2001 09:56:50 +0200 (MET DST) Date: Thu, 16 Aug 2001 09:56:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Salisbury, Roger" cc: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: RE: /usr/bin/file 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: 513 Lines: 17 On Tue, 14 Aug 2001, Salisbury, Roger wrote: > where do I get "libtoolize" It's included in the libtool distribution. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) Gcc 2.95.3 is fine if patched appropriately. -- + 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 Aug 16 01:04:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G846l17434 for linux-mips-outgoing; Thu, 16 Aug 2001 01:04:06 -0700 Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G844j17428 for ; Thu, 16 Aug 2001 01:04:04 -0700 Message-ID: <20010816080404.58868.qmail@web13402.mail.yahoo.com> Received: from [194.201.166.113] by web13402.mail.yahoo.com; Thu, 16 Aug 2001 09:04:04 BST Date: Thu, 16 Aug 2001 09:04:04 +0100 (BST) From: =?iso-8859-1?q?Zoon?= Subject: Soft-Float emulation with gcc - pr3900 To: linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: 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: 1185 Lines: 39 Hello, Although this message is more about gcc, I post here, since I got no answer from gcc mailing lists. I use egcs-2.91.66(Algorithmics tools) configured as a cross-compiler on a i386 host. I got the binary version, so didn't configured it myself. I'm working with a PR3900 type MIPS core. Those core don't have a Floating Point Unit, nor floating point registers. When using -msoft-float, I am supposed to use the libgcc soft floating point emulation. However, I cannot prevent gcc from using fp registers. When looking at gcc specs: $ mips-linux-gcc -dumpspecs | grep r3900 .. %{m3900:-mips1 -mcpu=r3900 -mfp32 -mgp32}... The option -mfp32 is defined as the default, which means gcc assume 32 bit fp registers are available. I am aware of two soft-float emulation libraries: Gofast and libgcc. However I can't figure out how emulation can be achieved if gcc keeps using fp registers. I must miss something about it, could someone help me with this matter ? Many thanks, Alain ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-linux-mips@oss.sgi.com Thu Aug 16 01:50:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G8oYd19014 for linux-mips-outgoing; Thu, 16 Aug 2001 01:50:34 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G8oWj19008 for ; Thu, 16 Aug 2001 01:50:32 -0700 Received: from eicon.com (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7G8oPhT016842 for ; Thu, 16 Aug 2001 10:50:25 +0200 Message-ID: <3B7B8951.B666A175@eicon.com> Date: Thu, 16 Aug 2001 10:50:25 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: glibc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 450 Lines: 21 Alan Cox wrote: > > I am porting Linux version 2.2.12 to Mips R3000 and need to build glibc > > but I could not find the following files: > > Oh no not again. > > 2.2.12 is historical value only. It has remote vulnerabilities and shouldnt > be used for anything. > > > glibc-2.0.6.tar.gz > > glibc 2.0 is also obsolete, heavily so We use 2.0.6 here because it is half the size of the newer glibcs and it seems to work fine for us. /Brian From owner-linux-mips@oss.sgi.com Thu Aug 16 02:07:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7G97aT19770 for linux-mips-outgoing; Thu, 16 Aug 2001 02:07:36 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7G97Zj19765 for ; Thu, 16 Aug 2001 02:07:35 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA29382; Thu, 16 Aug 2001 02:07:27 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA14863; Thu, 16 Aug 2001 02:07:25 -0700 (PDT) Message-ID: <005b01c12633$813c8820$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Atsushi Nemoto" Cc: References: <20010809215522.A1958@lucon.org><20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> Subject: Re: Benchmark performance Date: Thu, 16 Aug 2001 11:11:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1060 Lines: 21 > Current CVS kernel uses FPU emulator unconditionally. If one floating > point intruction causes a 'Unimplemented' exception (denormalized > result, etc.) following floating point instructions are also handle by > FPU emulator (not only the instruction which raise the exception). > > I do not know this is really desired behavior, but here is a patch to > change this. If Unimplemented exception had been occured during the > benchmark, aplying this patch may result better performance. Not desired behavior, just an artifact. However, I agree with Carsten that changing the API to the emulator for this and using a counter as you have done is not appropriate, and that the existing CPU configuration flag is a more appriate mechanism. It's possible that Wayne's baseline numbers came from a pre-Algor-emulator kernel, and that this "feature" accounts for some of his degraded performance. But I'd be surprised if it accounted for all of it, unless his FP test does 10% of its calculations on denormalized numbers or something. Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 03:11:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GABPX21898 for linux-mips-outgoing; Thu, 16 Aug 2001 03:11:25 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GABDj21895 for ; Thu, 16 Aug 2001 03:11:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA03622; Thu, 16 Aug 2001 12:12:57 +0200 (MET DST) Date: Thu, 16 Aug 2001 12:12:56 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Simon Gee , linux-mips@oss.sgi.com, gcc-bugs@gcc.gnu.org Subject: Re: MIPS, profiling, and not working In-Reply-To: <20010814164438.A22825@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 698 Lines: 18 On Tue, 14 Aug 2001, Daniel Jacobowitz wrote: > *sigh* Yes, I think the adjustment was meant to be made before the > call. Perhaps binutils should warn about things in the "delay slot" of a > macro? .set nomacro? There is usually no need to force an instruction into a delay slot (unless there are nonobvious dependencies, but then you probably want to avoid macro expansions anyway). You may just place it before a branch/jump and gas will move it into the slot itself if it finds it can. -- + 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 Aug 16 03:37:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GAbnr22768 for linux-mips-outgoing; Thu, 16 Aug 2001 03:37:49 -0700 Received: from dea.waldorf-gmbh.de (u-43-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GAbej22761 for ; Thu, 16 Aug 2001 03:37:40 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7G9I3b17674; Thu, 16 Aug 2001 11:18:03 +0200 Date: Thu, 16 Aug 2001 11:18:03 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: Benchmark performance Message-ID: <20010816111803.A17469@bacchus.dhis.org> References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.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: <20010816125652N.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Thu, Aug 16, 2001 at 12:56:52PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1451 Lines: 39 On Thu, Aug 16, 2001 at 12:56:52PM +0900, Atsushi Nemoto wrote: > >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher said: > wgowcher> a 23 % reduction in the Floating Point Index benchmark > > Current CVS kernel uses FPU emulator unconditionally. If one floating > point intruction causes a 'Unimplemented' exception (denormalized > result, etc.) following floating point instructions are also handle by > FPU emulator (not only the instruction which raise the exception). > > I do not know this is really desired behavior, but here is a patch to > change this. If Unimplemented exception had been occured during the > benchmark, aplying this patch may result better performance. This is a know problem with the emulator. It may be used to keep the emulator in kernel for a long time or even maliciously to keep the CPU in the kernel for an unbounded time. Here's my suggested fix: Index: arch/mips/math-emu/cp1emu.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/math-emu/cp1emu.c,v retrieving revision 1.7 diff -u -r1.7 cp1emu.c --- arch/mips/math-emu/cp1emu.c 2001/08/02 21:55:26 1.7 +++ arch/mips/math-emu/cp1emu.c 2001/08/16 09:06:55 @@ -1672,6 +1672,9 @@ oldepc = xcp->cp0_epc; do { + if (current->need_resched) + break; + prevepc = xcp->cp0_epc; insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err); if (err) { Ralf From owner-linux-mips@oss.sgi.com Thu Aug 16 04:09:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GB9DS24090 for linux-mips-outgoing; Thu, 16 Aug 2001 04:09:13 -0700 Received: from dea.waldorf-gmbh.de (u-116-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.116]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GB8wj24052 for ; Thu, 16 Aug 2001 04:08:59 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7GB6uD18180; Thu, 16 Aug 2001 13:06:56 +0200 Date: Thu, 16 Aug 2001 13:06:56 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: wgowcher@yahoo.com, Atsushi Nemoto , linux-mips@oss.sgi.com Subject: Re: Benchmark performance Message-ID: <20010816130656.A18050@bacchus.dhis.org> References: <20010809215522.A1958@lucon.org><20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> <005b01c12633$813c8820$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: <005b01c12633$813c8820$0deca8c0@Ulysses>; from kevink@mips.com on Thu, Aug 16, 2001 at 11:11:56AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1524 Lines: 30 On Thu, Aug 16, 2001 at 11:11:56AM +0200, Kevin D. Kissell wrote: > > Current CVS kernel uses FPU emulator unconditionally. If one floating > > point intruction causes a 'Unimplemented' exception (denormalized > > result, etc.) following floating point instructions are also handle by > > FPU emulator (not only the instruction which raise the exception). > > > > I do not know this is really desired behavior, but here is a patch to > > change this. If Unimplemented exception had been occured during the > > benchmark, aplying this patch may result better performance. > > Not desired behavior, just an artifact. However, I agree with Carsten > that changing the API to the emulator for this and using a counter > as you have done is not appropriate, and that the existing CPU > configuration flag is a more appriate mechanism. It's possible > that Wayne's baseline numbers came from a pre-Algor-emulator > kernel, and that this "feature" accounts for some of his degraded > performance. But I'd be surprised if it accounted for all of it, > unless his FP test does 10% of its calculations on denormalized > numbers or something. As I don't know the exact nature of the calculations involved it may well be that the broken behaviour of a pre-fpuemu kernel did completly break the algorithem involved. As for the hard-fp case I agree with you. It would be interesting to know if fp instructions that need emulation appear in groups. Then it's the (hopefully) rare case which we don't really care about. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 16 04:09:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GB95m24065 for linux-mips-outgoing; Thu, 16 Aug 2001 04:09:05 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GB91j24056; Thu, 16 Aug 2001 04:09:01 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA29968; Thu, 16 Aug 2001 04:08:51 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA15988; Thu, 16 Aug 2001 04:08:53 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7GB7Ta17695; Thu, 16 Aug 2001 13:07:30 +0200 (MEST) Message-ID: <3B7BA970.56192BB8@mips.com> Date: Thu, 16 Aug 2001 13:07:28 +0200 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: Atsushi Nemoto , wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: Benchmark performance References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> <20010816111803.A17469@bacchus.dhis.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2091 Lines: 55 Ralf Baechle wrote: > On Thu, Aug 16, 2001 at 12:56:52PM +0900, Atsushi Nemoto wrote: > > > >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher said: > > wgowcher> a 23 % reduction in the Floating Point Index benchmark > > > > Current CVS kernel uses FPU emulator unconditionally. If one floating > > point intruction causes a 'Unimplemented' exception (denormalized > > result, etc.) following floating point instructions are also handle by > > FPU emulator (not only the instruction which raise the exception). > > > > I do not know this is really desired behavior, but here is a patch to > > change this. If Unimplemented exception had been occured during the > > benchmark, aplying this patch may result better performance. > > This is a know problem with the emulator. It may be used to keep the > emulator in kernel for a long time or even maliciously to keep the > CPU in the kernel for an unbounded time. > > Here's my suggested fix: > > Index: arch/mips/math-emu/cp1emu.c > =================================================================== > RCS file: /home/pub/cvs/linux/arch/mips/math-emu/cp1emu.c,v > retrieving revision 1.7 > diff -u -r1.7 cp1emu.c > --- arch/mips/math-emu/cp1emu.c 2001/08/02 21:55:26 1.7 > +++ arch/mips/math-emu/cp1emu.c 2001/08/16 09:06:55 > @@ -1672,6 +1672,9 @@ > > oldepc = xcp->cp0_epc; > do { > + if (current->need_resched) > + break; > + > prevepc = xcp->cp0_epc; > insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err); > if (err) { > > Ralf What is probably needed too, but I still think we need the check for real FPU, so we only emulate one instruction at a time, if we got a real FPU. -- _ _ ____ ___ 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 Aug 16 04:11:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GBBc024260 for linux-mips-outgoing; Thu, 16 Aug 2001 04:11:38 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GBBaj24257 for ; Thu, 16 Aug 2001 04:11:36 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 16 Aug 2001 11:11:36 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 7B8D054C0E; Thu, 16 Aug 2001 20:11:34 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id UAA70606; Thu, 16 Aug 2001 20:11:34 +0900 (JST) Date: Thu, 16 Aug 2001 20:15:50 +0900 (JST) Message-Id: <20010816.201550.15258322.nemoto@toshiba-tops.co.jp> To: kevink@mips.com Cc: wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: Benchmark performance From: Atsushi Nemoto In-Reply-To: <005b01c12633$813c8820$0deca8c0@Ulysses> References: <20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> <005b01c12633$813c8820$0deca8c0@Ulysses> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_16_20:15:50_2001_358)--" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1838 Lines: 51 ----Next_Part(Thu_Aug_16_20:15:50_2001_358)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Thu, 16 Aug 2001 11:11:56 +0200, "Kevin D. Kissell" said: >> I do not know this is really desired behavior, but here is a patch >> to change this. If Unimplemented exception had been occured during >> the benchmark, aplying this patch may result better performance. kevink> Not desired behavior, just an artifact. However, I agree with kevink> Carsten that changing the API to the emulator for this and kevink> using a counter as you have done is not appropriate, and that kevink> the existing CPU configuration flag is a more appriate mechanism. I see. I created that patch while debugging time an another FPU emulator's problem (as I reported in another message) on CPU with real FPU. Now the 'counter' method is not needed at all. Although another fix by Ralf is ready, here is my new patch. --- Atsushi Nemoto ----Next_Part(Thu_Aug_16_20:15:50_2001_358)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fpu_emu.patch" diff -ur linux.sgi/arch/mips/math-emu/cp1emu.c linux/arch/mips/math-emu/cp1emu.c --- linux.sgi/arch/mips/math-emu/cp1emu.c Sun Aug 5 23:39:27 2001 +++ linux/arch/mips/math-emu/cp1emu.c Thu Aug 16 19:41:35 2001 @@ -48,6 +48,8 @@ #include #include #include +#include +#include #include @@ -1682,6 +1684,8 @@ sig = cop1Emulate(xcp, ctx); else xcp->cp0_epc += 4; /* skip nops */ + if (mips_cpu.options & MIPS_CPU_FPU) + break; } while (xcp->cp0_epc > prevepc && sig == 0); /* SIGILL indicates a non-fpu instruction */ ----Next_Part(Thu_Aug_16_20:15:50_2001_358)---- From owner-linux-mips@oss.sgi.com Thu Aug 16 04:16:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GBGHL24427 for linux-mips-outgoing; Thu, 16 Aug 2001 04:16:17 -0700 Received: from dea.waldorf-gmbh.de (u-116-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.116]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GBGFj24424 for ; Thu, 16 Aug 2001 04:16:15 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7GBEMT20654; Thu, 16 Aug 2001 13:14:22 +0200 Date: Thu, 16 Aug 2001 13:14:22 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: Atsushi Nemoto , wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: Benchmark performance Message-ID: <20010816131422.B17970@bacchus.dhis.org> References: <20010809215522.A1958@lucon.org> <20010813173446.61234.qmail@web11901.mail.yahoo.com> <20010816125652N.nemoto@toshiba-tops.co.jp> <20010816111803.A17469@bacchus.dhis.org> <3B7BA970.56192BB8@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: <3B7BA970.56192BB8@mips.com>; from carstenl@mips.com on Thu, Aug 16, 2001 at 01:07:28PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 263 Lines: 8 On Thu, Aug 16, 2001 at 01:07:28PM +0200, Carsten Langgaard wrote: > What is probably needed too, but I still think we need the check for real > FPU, so we only emulate one instruction at a time, if we got a real FPU. I'm just about to put it into CVS. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 16 05:31:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GCVdk26720 for linux-mips-outgoing; Thu, 16 Aug 2001 05:31:39 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GCVcj26717 for ; Thu, 16 Aug 2001 05:31:38 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA00421; Thu, 16 Aug 2001 05:31:28 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA17200; Thu, 16 Aug 2001 05:31:29 -0700 (PDT) Message-ID: <009401c12650$021bcca0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Atsushi Nemoto" Cc: , References: <3B7A70B8.ED92FE4@mips.com><20010815110634.A19305@nevyn.them.org> <20010816132042T.nemoto@toshiba-tops.co.jp> Subject: Re: FP emulator patch Date: Thu, 16 Aug 2001 14:35:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 436 Lines: 13 > I also am trying to fix this problem. How about my patch? > > restore_sigcontext() can be more optimized, but I think this is a > smallest patch to fix the problem. I beleive that your patch might fix a symptom of the bugs that I talked about in my mail last night, but it doesn't solve the underlying problem. With the signal setup/restore changes I posted last night, your patch should not be necessary. Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 07:02:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GE22M29585 for linux-mips-outgoing; Thu, 16 Aug 2001 07:02:02 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GE21j29582 for ; Thu, 16 Aug 2001 07:02:01 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15XNl1-0005C7-00; Thu, 16 Aug 2001 15:04:23 +0100 Subject: Re: glibc To: brian.murphy@eicon.com (Brian Murphy) Date: Thu, 16 Aug 2001 15:04:23 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: <3B7B8951.B666A175@eicon.com> from "Brian Murphy" at Aug 16, 2001 10:50:25 AM X-Mailer: ELM [version 2.5 PL5] 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: 176 Lines: 4 > We use 2.0.6 here because it is half the size of the newer glibcs and it seems > to work fine for us. It trust someone patched the holes in it for things like DNS lookups ? From owner-linux-mips@oss.sgi.com Thu Aug 16 09:04:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GG4tH00599 for linux-mips-outgoing; Thu, 16 Aug 2001 09:04:55 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GG4sj00594 for ; Thu, 16 Aug 2001 09:04:54 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id DDDC0125C4; Thu, 16 Aug 2001 09:04:52 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 06AB7EFC0; Thu, 16 Aug 2001 09:04:51 -0700 (PDT) Date: Thu, 16 Aug 2001 09:04:51 -0700 From: "H . J . Lu" To: Brian Murphy Cc: linux-mips@oss.sgi.com Subject: Re: glibc Message-ID: <20010816090451.A3094@lucon.org> References: <3B7B8951.B666A175@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: <3B7B8951.B666A175@eicon.com>; from brian.murphy@eicon.com on Thu, Aug 16, 2001 at 10:50:25AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 262 Lines: 12 On Thu, Aug 16, 2001 at 10:50:25AM +0200, Brian Murphy wrote: > > We use 2.0.6 here because it is half the size of the newer glibcs and it seems > > to work fine for us. > I am working on sglibc. It has a smaller size by disabling selective features. H.J. From owner-linux-mips@oss.sgi.com Thu Aug 16 10:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GH0nn01793 for linux-mips-outgoing; Thu, 16 Aug 2001 10:00:49 -0700 Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GH0mj01790 for ; Thu, 16 Aug 2001 10:00:48 -0700 Received: from eicon.com (brian.localnet [10.0.0.2]) by ubik.localnet (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7GH0gGC001096 for ; Thu, 16 Aug 2001 19:00:42 +0200 Message-ID: <3B7BFC3A.A3C6CE62@eicon.com> Date: Thu, 16 Aug 2001 19:00:42 +0200 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: glibc References: <3B7B8951.B666A175@eicon.com> <20010816090451.A3094@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 172 Lines: 12 "H . J . Lu" wrote: > > I am working on sglibc. It has a smaller size by disabling selective > features. > > H.J. Sounds excellent. How do I get my hands on it? /Brian From owner-linux-mips@oss.sgi.com Thu Aug 16 10:36:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GHa9b02614 for linux-mips-outgoing; Thu, 16 Aug 2001 10:36:09 -0700 Received: from smtp (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GHa7j02611 for ; Thu, 16 Aug 2001 10:36:07 -0700 Received: from ex2k.pcs.psdc.com ([172.19.1.1]) by smtp (NAVIEG 2.1 bld 63) with SMTP id M2001081610365313012 for ; Thu, 16 Aug 2001 10:36:53 -0700 content-class: urn:content-classes:message Subject: glibc 2.0.6 building problem. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 16 Aug 2001 10:33:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B0A24C5@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: glibc 2.0.6 building problem. Thread-Index: AcEmeZfIQqIQ8WAUQcqmwvD+jX4G0Q== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7GHa7j02612 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1067 Lines: 36 Hi, ALL: After built Linux kernel 2.2.12 for mips r3000, I got the related files for glibc-2.0.6 build. But I found a problem when I were building glibc 2.0.6. Here is part of the screen printout: cd build C=mips-linux-gcc BUILD_CC=gcc AR=mips-linux-ar RANLIB=mips-linux-ranlib ../configure --prefix=/usr --host=mips-linux --enable-add-ons=crypt,linuxthreads,localedata --enable-profile ..... ...... checking installed Linux kernel header files... TOO OLD! configure: error: GNU libc requires kernel header files from Linux 2.0.10 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 2.0.10 or later. This check uses , so make sure that file was built correctly when installing the kernel header files. It seems that I need to copy the kernel's include files and lib to somewhere. I could not figure it out. If you know how to build the glibc, please let me know. Thank you all. Steven Liu From owner-linux-mips@oss.sgi.com Thu Aug 16 10:49:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GHnaW03118 for linux-mips-outgoing; Thu, 16 Aug 2001 10:49:36 -0700 Received: from dea.waldorf-gmbh.de (u-171-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.171]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GHnWj03115 for ; Thu, 16 Aug 2001 10:49:33 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7GGEJG31124; Thu, 16 Aug 2001 18:14:19 +0200 Date: Thu, 16 Aug 2001 18:14:19 +0200 From: Ralf Baechle To: Alan Cox Cc: Brian Murphy , linux-mips@oss.sgi.com Subject: Re: glibc Message-ID: <20010816181419.B30997@bacchus.dhis.org> References: <3B7B8951.B666A175@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: ; from alan@lxorguk.ukuu.org.uk on Thu, Aug 16, 2001 at 03:04:23PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 550 Lines: 15 On Thu, Aug 16, 2001 at 03:04:23PM +0100, Alan Cox wrote: > > We use 2.0.6 here because it is half the size of the newer glibcs and it > > seems to work fine for us. > > It trust someone patched the holes in it for things like DNS lookups ? The latest glibc 2.0.6 I was spreading only has MIPS-specific bug fixes. All the other big holes which are indeed big enough to drive a nice shipload of trucks through are unfixed. I haven't noticed that any other glibc 2.0 variant floating around has additional fixes. Nice for Cobalt boxen ... Ralf From owner-linux-mips@oss.sgi.com Thu Aug 16 11:19:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GIJGi03769 for linux-mips-outgoing; Thu, 16 Aug 2001 11:19:16 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GIJBj03765 for ; Thu, 16 Aug 2001 11:19:11 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA04168 for ; Thu, 16 Aug 2001 11:19:00 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA24514 for ; Thu, 16 Aug 2001 11:19:04 -0700 (PDT) Message-ID: <018201c12680$8f13e680$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "MIPS/Linux List \(SGI\)" Subject: Re: FP emulator patch Date: Thu, 16 Aug 2001 20:23:32 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_017F_01C12691.51701D60" 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: 5007 Lines: 131 This is a multi-part message in MIME format. ------=_NextPart_000_017F_01C12691.51701D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit As I wrote last night, it looks to me as if FPU context management in signals was broken in all versions and proposed patches that I've seen. The way I see it is this: If the current thread "owns" the FPU, we need to save the FPU state in the sigcontext and restore it on return. If the signal handler uses floating point, it already has the FPU, and can do what it wants with it. If it doesn't use the FPU, then we'll save and restore FPU state for nothing, but better safe than sorry. In either case, the current thread retains ownership of the FPU. There is no reason to muck with the ownership data or the Cp0.Status.CU1 enables, apart from the questionable bit of enabling it before the FP context save in case it wasn't enabled. I think that should go away, but I don't have time to test exhastively. In any case, CU1 should have it's pre-signal state going into the signal handler. If the current thread does *not* own the FPU, we don't need to save the thread FP state. If the signal handler does no FP, so much the better, there's nothing to be done. If the signal handler uses FP, it will acquire the FPU by normal means. The FP context will be saved into the thread context of the previous owner, the signalling thread will acquire the FPU, and the signal handler will do it's FP. On return from the signal, we *must* de-allocate the FPU and clear the CU1 bit. If that's done, and the thread (which had not *owned* the FPU prior to the signal) starts doing FP again, normal mechanisms will cause it's FP context to be restored. If we don't, it will start exectuing with a bogus FP context. The code I sketched last night is essentially correct, though it used a macro that doesn't exist. I attach a patch relative to the current OSS repository's signal.c. The patch includes the stack frame tweak for the FPU emulator that was part of previous patches, but which is orthogonal to the problem under discussion. I have built a kernel using this code and run 20 simultaneous copies of the MontaVista "stressor" program with no problems (though I also had the "v1.5" FPU emulator code). Regards, Kevin K. ------=_NextPart_000_017F_01C12691.51701D60 Content-Type: application/octet-stream; name="signal.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="signal.c.patch" Index: signal.c=0A= =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=0A= RCS file: /cvs/linux/arch/mips/kernel/signal.c,v=0A= retrieving revision 1.36=0A= diff -u -p -r1.36 signal.c=0A= --- signal.c 2001/06/18 22:43:35 1.36=0A= +++ signal.c 2001/08/16 18:01:58=0A= @@ -221,7 +221,13 @@ restore_sigcontext(struct pt_regs *regs,=0A= err |=3D __get_user(owned_fp, &sc->sc_ownedfp);=0A= if (owned_fp) {=0A= err |=3D restore_fp_context(sc);=0A= - last_task_used_math =3D current;=0A= + } else {=0A= + if (current =3D=3D last_task_used_math) {=0A= + /* Signal handler acquired FPU - give it back */=0A= + last_task_used_math =3D NULL;=0A= + current->used_math =3D 0;=0A= + regs->cp0_status &=3D ~ST0_CU1;=0A= + }=0A= }=0A= =0A= return err;=0A= @@ -326,6 +332,7 @@ setup_sigcontext(struct pt_regs *regs, s=0A= int owned_fp;=0A= int err =3D 0;=0A= u64 reg;=0A= + u32 tstat;=0A= =0A= err |=3D __put_user(regs->cp0_epc, &sc->sc_pc);=0A= err |=3D __put_user(regs->cp0_status, &sc->sc_status);=0A= @@ -353,12 +360,12 @@ setup_sigcontext(struct pt_regs *regs, s=0A= owned_fp =3D (current =3D=3D last_task_used_math);=0A= err |=3D __put_user(owned_fp, &sc->sc_ownedfp);=0A= =0A= - if (current->used_math) { /* fp is active. */=0A= + if (owned_fp) { /* fp is active. */=0A= + tstat =3D regs->cp0_status;=0A= + /* This enable should not really be necessary */=0A= set_cp0_status(ST0_CU1);=0A= err |=3D save_fp_context(sc);=0A= - last_task_used_math =3D NULL;=0A= - regs->cp0_status &=3D ~ST0_CU1;=0A= - current->used_math =3D 0;=0A= + regs->cp0_status =3D tstat;=0A= }=0A= =0A= return err;=0A= @@ -374,6 +381,16 @@ get_sigframe(struct k_sigaction *ka, str=0A= =0A= /* Default to using normal stack */=0A= sp =3D regs->regs[29];=0A= +=0A= +#ifdef CONFIG_MIPS_FPU_EMULATOR=0A= + /*=0A= + * FPU emulator may have it's own trampoline active just=0A= + * above the user stack, 16-bytes before the next lowest=0A= + * 16 byte boundary. Try to avoid trashing it.=0A= + */=0A= + sp -=3D 32; /* 32 ought to be enough, but... */=0A= +=0A= +#endif /* CONFIG_MIPS_FPU_EMULATOR */=0A= =0A= /* This is the X/Open sanctioned signal stack switching. */=0A= if ((ka->sa.sa_flags & SA_ONSTACK) && ! on_sig_stack(sp))=0A= ------=_NextPart_000_017F_01C12691.51701D60-- From owner-linux-mips@oss.sgi.com Thu Aug 16 11:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GIjl504302 for linux-mips-outgoing; Thu, 16 Aug 2001 11:45:47 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GIjUj04293 for ; Thu, 16 Aug 2001 11:45:46 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GInpA18452; Thu, 16 Aug 2001 11:49:52 -0700 Message-ID: <3B7C15A0.2040205@pacbell.net> Date: Thu, 16 Aug 2001 11:49:04 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2411 Lines: 51 Kevin D. Kissell wrote: > As I wrote last night, it looks to me as if FPU context > management in signals was broken in all versions and > proposed patches that I've seen. The way I see it is this: > > If the current thread "owns" the FPU, we need to save the > FPU state in the sigcontext and restore it on return. If > the signal handler uses floating point, it already has the > FPU, and can do what it wants with it. If it doesn't use > the FPU, then we'll save and restore FPU state for > nothing, but better safe than sorry. In either case, > the current thread retains ownership of the FPU. > There is no reason to muck with the ownership data > or the Cp0.Status.CU1 enables, apart from the > questionable bit of enabling it before the FP context > save in case it wasn't enabled. I think that should go > away, but I don't have time to test exhastively. In > any case, CU1 should have it's pre-signal state > going into the signal handler. > > If the current thread does *not* own the FPU, we don't > need to save the thread FP state. If the signal handler > does no FP, so much the better, there's nothing to > be done. If the signal handler uses FP, it will acquire > the FPU by normal means. The FP context will be saved > into the thread context of the previous owner, the signalling > thread will acquire the FPU, and the signal handler will do > it's FP. On return from the signal, we *must* de-allocate the > FPU and clear the CU1 bit. If that's done, and the > thread (which had not *owned* the FPU prior to the > signal) starts doing FP again, normal mechanisms > will cause it's FP context to be restored. If we don't, > it will start exectuing with a bogus FP context. > > The code I sketched last night is essentially correct, > though it used a macro that doesn't exist. I attach a > patch relative to the current OSS repository's signal.c. > The patch includes the stack frame tweak for the FPU > emulator that was part of previous patches, but which > is orthogonal to the problem under discussion. I have > built a kernel using this code and run 20 simultaneous > copies of the MontaVista "stressor" program with no > problems (though I also had the "v1.5" FPU emulator > code). I've lost track of all the patches now :-) Can I trouble you to create a complete patch of your arch/mips/math-emu, and whatever other files you've modifed, against Ralf's tree? Pete From owner-linux-mips@oss.sgi.com Thu Aug 16 11:52:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GIqwM04503 for linux-mips-outgoing; Thu, 16 Aug 2001 11:52:58 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GIqsj04499 for ; Thu, 16 Aug 2001 11:52:56 -0700 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15XSH7-0003DP-00; Thu, 16 Aug 2001 11:53:49 -0700 Date: Thu, 16 Aug 2001 11:53:49 -0700 From: Daniel Jacobowitz To: "Kevin D. Kissell" Cc: "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch Message-ID: <20010816115349.A12153@nevyn.them.org> References: <018201c12680$8f13e680$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <018201c12680$8f13e680$0deca8c0@Ulysses>; from kevink@mips.com on Thu, Aug 16, 2001 at 08:23:32PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2498 Lines: 56 On Thu, Aug 16, 2001 at 08:23:32PM +0200, Kevin D. Kissell wrote: > As I wrote last night, it looks to me as if FPU context > management in signals was broken in all versions and > proposed patches that I've seen. The way I see it is this: > > If the current thread "owns" the FPU, we need to save the > FPU state in the sigcontext and restore it on return. If > the signal handler uses floating point, it already has the > FPU, and can do what it wants with it. If it doesn't use > the FPU, then we'll save and restore FPU state for > nothing, but better safe than sorry. In either case, > the current thread retains ownership of the FPU. > There is no reason to muck with the ownership data > or the Cp0.Status.CU1 enables, apart from the > questionable bit of enabling it before the FP context > save in case it wasn't enabled. I think that should go > away, but I don't have time to test exhastively. In > any case, CU1 should have it's pre-signal state > going into the signal handler. This bit sounds fine to me. > If the current thread does *not* own the FPU, we don't > need to save the thread FP state. If the signal handler > does no FP, so much the better, there's nothing to > be done. If the signal handler uses FP, it will acquire > the FPU by normal means. The FP context will be saved > into the thread context of the previous owner, the signalling > thread will acquire the FPU, and the signal handler will do > it's FP. On return from the signal, we *must* de-allocate the > FPU and clear the CU1 bit. If that's done, and the > thread (which had not *owned* the FPU prior to the > signal) starts doing FP again, normal mechanisms > will cause it's FP context to be restored. If we don't, > it will start exectuing with a bogus FP context. No, this is wrong. - Current thread has an FPU state saved but does not own the FPU. - Signal handler uses FP - Acquires FP through a lazy switch - (FPU) Context switch occurs while in signal handler. Where do we put the state now? We save it in the process's thread structure, of course. Overwriting what was there. If the process has ever used math, the sigcontext must contain a saved FP state. current->used_math should never be set to zero in this sort of situation. It's not an ownership flag! It marks whether the FP state in the thread structure is valid. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Aug 16 12:09:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJ9pV04969 for linux-mips-outgoing; Thu, 16 Aug 2001 12:09:51 -0700 Received: from kuolema.infodrom.north.de (postfix@kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJ9jj04966; Thu, 16 Aug 2001 12:09:46 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id D69674D73F; Thu, 16 Aug 2001 21:09:34 +0200 (CEST) Received: from nautilus.noreply.org (unknown [138.232.34.77]) by finlandia.infodrom.north.de (Postfix) with ESMTP id 4EAD310918; Thu, 16 Aug 2001 21:09:29 +0200 (CEST) Received: by nautilus.noreply.org (Postfix, from userid 10) id BCF153581D; Thu, 16 Aug 2001 21:09:18 +0200 (CEST) Received: by fisch.cyrius.com (Postfix, from userid 1000) id 866B222B45; Thu, 16 Aug 2001 21:09:40 +0200 (CEST) Date: Thu, 16 Aug 2001 21:09:40 +0200 From: Martin Michlmayr To: Ralf Baechle Cc: Alan Cox , Brian Murphy , linux-mips@oss.sgi.com Subject: Re: glibc Message-ID: <20010816210940.A21001@fisch.cyrius.com> References: <3B7B8951.B666A175@eicon.com> <20010816181419.B30997@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010816181419.B30997@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, Aug 16, 2001 at 06:14:19PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 482 Lines: 12 * Ralf Baechle [20010816 18:14]: > The latest glibc 2.0.6 I was spreading only has MIPS-specific bug > fixes. All the other big holes which are indeed big enough to drive > a nice shipload of trucks through are unfixed. I haven't noticed > that any other glibc 2.0 variant floating around has additional > fixes. > > Nice for Cobalt boxen ... Debian is being ported to Cobalts. A base tar ball can be found at http://www.pocketlinux.com/~samc/debian-cobalt From owner-linux-mips@oss.sgi.com Thu Aug 16 12:16:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJG3405279 for linux-mips-outgoing; Thu, 16 Aug 2001 12:16:03 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJG1j05273 for ; Thu, 16 Aug 2001 12:16:01 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA04761 for ; Thu, 16 Aug 2001 12:15:51 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id MAA26120 for ; Thu, 16 Aug 2001 12:15:54 -0700 (PDT) Message-ID: <01a001c12688$7fdbbf00$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "MIPS/Linux List \(SGI\)" References: <018201c12680$8f13e680$0deca8c0@Ulysses> Subject: Re: FP emulator patch Date: Thu, 16 Aug 2001 21:20:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2159 Lines: 48 > If the current thread does *not* own the FPU, we don't > need to save the thread FP state. If the signal handler > does no FP, so much the better, there's nothing to > be done. If the signal handler uses FP, it will acquire > the FPU by normal means. The FP context will be saved > into the thread context of the previous owner, the signalling > thread will acquire the FPU, and the signal handler will do > it's FP. On return from the signal, we *must* de-allocate the > FPU and clear the CU1 bit. If that's done, and the > thread (which had not *owned* the FPU prior to the > signal) starts doing FP again, normal mechanisms > will cause it's FP context to be restored. If we don't, > it will start exectuing with a bogus FP context. There is, actually, one conceptual hole in this scheme (and in every other one we've seen) if the following scenario occurs. The current thread does not own the FPU, the signal handler executes FP instructions and runs for so long that it gets switched out. The thread's FP state will then become that of the signal handler, and, since the thread didn't have the FPU when the signal context was set up, it the pre-signal state will be lost. >From that standpoint, the old code that saved the contex if current->used_math was almost correct. Almost correct, because the naive dump-the-FPU code is correct only if the FPU belongs to the thread. If it doesn't, the last saved thead FPU context, and not the FPU contents, needs to be copied into the signal context. Symmetrically, in restore_sigcontext(), the current code restores the FPU if we *owned* the fp prior to the signal, but we must likewise restore the thread FPU context from the sigcontext if we *didn't* own the FPU, but the signal handler subsequently acquired it. The alternative to doing direct sigcontext<->thread context saves/restores without passing through the FPU would be to force a fpu context switch on every signal dispatch, which I find rather inelegant. I'll see if I can't come up with a new patch that also takes this into account, but may not have time before I take off on vacation this weekend... Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 12:20:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GJKrc05487 for linux-mips-outgoing; Thu, 16 Aug 2001 12:20:53 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GJKoj05482 for ; Thu, 16 Aug 2001 12:20:50 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GJPUA20317; Thu, 16 Aug 2001 12:25:30 -0700 Message-ID: <3B7C1BB9.7011790E@mvista.com> Date: Thu, 16 Aug 2001 12:15:05 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: "Kevin D. Kissell" , "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3070 Lines: 72 Daniel Jacobowitz wrote: > > On Thu, Aug 16, 2001 at 08:23:32PM +0200, Kevin D. Kissell wrote: > > As I wrote last night, it looks to me as if FPU context > > management in signals was broken in all versions and > > proposed patches that I've seen. The way I see it is this: > > > > If the current thread "owns" the FPU, we need to save the > > FPU state in the sigcontext and restore it on return. If > > the signal handler uses floating point, it already has the > > FPU, and can do what it wants with it. If it doesn't use > > the FPU, then we'll save and restore FPU state for > > nothing, but better safe than sorry. In either case, > > the current thread retains ownership of the FPU. > > There is no reason to muck with the ownership data > > or the Cp0.Status.CU1 enables, apart from the > > questionable bit of enabling it before the FP context > > save in case it wasn't enabled. I think that should go > > away, but I don't have time to test exhastively. In > > any case, CU1 should have it's pre-signal state > > going into the signal handler. > > This bit sounds fine to me. > > > If the current thread does *not* own the FPU, we don't > > need to save the thread FP state. If the signal handler > > does no FP, so much the better, there's nothing to > > be done. If the signal handler uses FP, it will acquire > > the FPU by normal means. The FP context will be saved > > into the thread context of the previous owner, the signalling > > thread will acquire the FPU, and the signal handler will do > > it's FP. On return from the signal, we *must* de-allocate the > > FPU and clear the CU1 bit. If that's done, and the > > thread (which had not *owned* the FPU prior to the > > signal) starts doing FP again, normal mechanisms > > will cause it's FP context to be restored. If we don't, > > it will start exectuing with a bogus FP context. > > No, this is wrong. > > - Current thread has an FPU state saved but does not own the FPU. > - Signal handler uses FP > - Acquires FP through a lazy switch > - (FPU) Context switch occurs while in signal handler. > > Where do we put the state now? We save it in the process's thread > structure, of course. Overwriting what was there. > > If the process has ever used math, the sigcontext must contain a saved > FP state. > We discovered this bug a while back. The right fix is to copy FP state from thread structure to signal stack *when* the current thread used FPU BUT not own it right now. > current->used_math should never be set to zero in this sort of > situation. It's not an ownership flag! It marks whether the FP state > in the thread structure is valid. > Daniel, it is funny that I agree with your last statement but cannot agree with your first one. Under the above mentioned situation, after we make the copy of FPU state from thread structure to the saved signal context, we need to set used_math bit to zero. This way when the signal handler uses FPU for the first time - if it ever uses it -, the normal lazy FPU switch mechanism can kick in smoothly. Jun Jun From owner-linux-mips@oss.sgi.com Thu Aug 16 13:05:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GK5q307217 for linux-mips-outgoing; Thu, 16 Aug 2001 13:05:52 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GK5nj07213; Thu, 16 Aug 2001 13:05:49 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7GK5ZTc031044; Thu, 16 Aug 2001 13:05:35 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7GK5Y3W031039; Thu, 16 Aug 2001 13:05:35 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 16 Aug 2001 13:05:33 -0700 (PDT) From: James Simmons To: Martin Michlmayr cc: Ralf Baechle , Alan Cox , Brian Murphy , linux-mips@oss.sgi.com Subject: Re: glibc In-Reply-To: <20010816210940.A21001@fisch.cyrius.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: 780 Lines: 18 > > The latest glibc 2.0.6 I was spreading only has MIPS-specific bug > > fixes. All the other big holes which are indeed big enough to drive > > a nice shipload of trucks through are unfixed. I haven't noticed > > that any other glibc 2.0 variant floating around has additional > > fixes. > > > > Nice for Cobalt boxen ... > > Debian is being ported to Cobalts. A base tar ball can be found at > http://www.pocketlinux.com/~samc/debian-cobalt All the latest stuff there. I use it for my native build system. The kernel is a 2.4.5 BTW if people are curious. I attempt a 2.4.6 kernel but for some reason the cube doesn't like it. I believe I have a bug in the old time code which is affected by the soft_pending change. I will attempt to track it down some time next week. From owner-linux-mips@oss.sgi.com Thu Aug 16 13:09:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GK9Rq07345 for linux-mips-outgoing; Thu, 16 Aug 2001 13:09:27 -0700 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 f7GK9Qj07342 for ; Thu, 16 Aug 2001 13:09:26 -0700 Received: from athlon-800 (athlon-pc [10.0.0.2]) by fenris.scrooge.dk (8.9.3/8.8.7) with ESMTP id WAA19938 for ; Thu, 16 Aug 2001 22:10:00 +0200 From: "Soeren Laursen" To: linux-mips@oss.sgi.com Date: Thu, 16 Aug 2001 22:10:00 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: glibc Reply-to: soeren.laursen@scrooge.dk Message-ID: <3B7C44B8.25165.17359A4@localhost> In-reply-to: <20010816210940.A21001@fisch.cyrius.com> References: <20010816181419.B30997@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, Aug 16, 2001 at 06:14:19PM +0200 X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 572 Lines: 17 > * Ralf Baechle [20010816 18:14]: > > The latest glibc 2.0.6 I was spreading only has MIPS-specific bug > > fixes. All the other big holes which are indeed big enough to drive > > a nice shipload of trucks through are unfixed. I haven't noticed > > that any other glibc 2.0 variant floating around has additional > > fixes. > > > > Nice for Cobalt boxen ... > > Debian is being ported to Cobalts. A base tar ball can be found at > http://www.pocketlinux.com/~samc/debian-cobalt Has anybody any luck running it on raq2 from Cobalt/SUN? Soeren, From owner-linux-mips@oss.sgi.com Thu Aug 16 13:26:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GKQeh07960 for linux-mips-outgoing; Thu, 16 Aug 2001 13:26:40 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GKQbj07957 for ; Thu, 16 Aug 2001 13:26:38 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GKVKA23927; Thu, 16 Aug 2001 13:31:20 -0700 Message-ID: <3B7C2B26.907BC359@mvista.com> Date: Thu, 16 Aug 2001 13:20:54 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> <01a001c12688$7fdbbf00$0deca8c0@Ulysses> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3294 Lines: 94 "Kevin D. Kissell" wrote: > > > If the current thread does *not* own the FPU, we don't > > need to save the thread FP state. If the signal handler > > does no FP, so much the better, there's nothing to > > be done. If the signal handler uses FP, it will acquire > > the FPU by normal means. The FP context will be saved > > into the thread context of the previous owner, the signalling > > thread will acquire the FPU, and the signal handler will do > > it's FP. On return from the signal, we *must* de-allocate the > > FPU and clear the CU1 bit. If that's done, and the > > thread (which had not *owned* the FPU prior to the > > signal) starts doing FP again, normal mechanisms > > will cause it's FP context to be restored. If we don't, > > it will start exectuing with a bogus FP context. > > There is, actually, one conceptual hole in this > scheme (and in every other one we've seen) if the > following scenario occurs. The current thread does > not own the FPU, the signal handler executes FP > instructions and runs for so long that it gets > switched out. The thread's FP state will then > become that of the signal handler, and, since the > thread didn't have the FPU when the signal context > was set up, it the pre-signal state will be lost. > > From that standpoint, the old code that saved the > contex if current->used_math was almost correct. > Almost correct, because the naive dump-the-FPU > code is correct only if the FPU belongs to the thread. > If it doesn't, the last saved thead FPU context, and not > the FPU contents, needs to be copied into the signal > context. Symmetrically, in restore_sigcontext(), the current > code restores the FPU if we *owned* the fp prior to the > signal, but we must likewise restore the thread FPU > context from the sigcontext if we *didn't* own the FPU, but > the signal handler subsequently acquired it. > > The alternative to doing direct sigcontext<->thread context > saves/restores without passing through the FPU would > be to force a fpu context switch on every signal dispatch, > which I find rather inelegant. > > I'll see if I can't come up with a new patch that also > takes this into account, but may not have time before > I take off on vacation this weekend... > > Kevin K. Kevin, The following pseudo code should take care of that bug. setup_sigcontext(): ... if (owned_fp) ASSERT(current->used_math); /* my assumption, obvious */ err |= __put_user(owned_fp, &sc->sc_ownedfp); err |= __put_user(current->used_math, &sc->sc_used_math); if (owned_math) { /* save current FP state to signal context */ current->used_math = 0; /* perhaps some other bits need to be modified etc */ } else if (current->used_math) { /* copy FP state from thread structure to signal context */ current->used_math = 0; /* perhaps some other bits need to be modified etc */ } .... restore_context(): .. __get_user(owned_fp, &sc->sc_ownedfp); __get_user(¤t->used_math, &sc->sc_used_math); if (owned_fp) ASSERT(current->used_math); /* my assumption, obvious */ if (owned_fp) { restore_fp_context(sc); last_task_used_math = current; } else if (current->used_math) { /* copy FP state from signal context to thread structure */ } (I meant to do that myself, of course, but yeah, yeah, ... :-0) Jun From owner-linux-mips@oss.sgi.com Thu Aug 16 13:36:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GKaH008302 for linux-mips-outgoing; Thu, 16 Aug 2001 13:36:17 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GKaFj08299 for ; Thu, 16 Aug 2001 13:36:15 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA05717; Thu, 16 Aug 2001 13:36:05 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA28150; Thu, 16 Aug 2001 13:36:06 -0700 (PDT) Message-ID: <01b001c12693$b4920140$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , "Daniel Jacobowitz" Cc: "MIPS/Linux List \(SGI\)" References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> Subject: Re: FP emulator patch Date: Thu, 16 Aug 2001 22:40:26 +0200 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1341 Lines: 35 > > current->used_math should never be set to zero in this sort of > > situation. It's not an ownership flag! It marks whether the FP state > > in the thread structure is valid. > > Daniel, it is funny that I agree with your last statement but cannot agree > with your first one. > > Under the above mentioned situation, after we make the copy of FPU state from > thread structure to the saved signal context, we need to set used_math bit to > zero. This way when the signal handler uses FPU for the first time - if it > ever uses it -, the normal lazy FPU switch mechanism can kick in smoothly. We've had a lot of messages crossing here, but please explain yourself here why clearing used_math helps in this case. If, as has been proposed, the current thread does not own the FPU, and thus CU1 is not enabled, the FPU switch mechanism should kick in during the signal handler regardless. The signal handler will inherit the thread's FPU state from the thread context, and will muck with it, but if, as has been noted, the sigcontext has been loaded from the thread context before the handler is dispatched, and is restored after the handler executes, we're fine. The only thing I can see that clearing used_math would achieve would be to guarantee the signal handler a virgin FPU context. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 14:15:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GLFxV09783 for linux-mips-outgoing; Thu, 16 Aug 2001 14:15:59 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GLFwj09780 for ; Thu, 16 Aug 2001 14:15:58 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 383FC125C4; Thu, 16 Aug 2001 14:15:57 -0700 (PDT) Date: Thu, 16 Aug 2001 14:15:57 -0700 From: "H . J . Lu" To: Brian Murphy Cc: linux-mips@oss.sgi.com Subject: Re: glibc Message-ID: <20010816141557.A18838@lucon.org> References: <3B7B8951.B666A175@eicon.com> <20010816090451.A3094@lucon.org> <3B7BFC3A.A3C6CE62@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: <3B7BFC3A.A3C6CE62@eicon.com>; from brian.murphy@eicon.com on Thu, Aug 16, 2001 at 07:00:42PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 322 Lines: 18 On Thu, Aug 16, 2001 at 07:00:42PM +0200, Brian Murphy wrote: > "H . J . Lu" wrote: > > > > > I am working on sglibc. It has a smaller size by disabling selective > > features. > > > > H.J. > > Sounds excellent. How do I get my hands on it? > http://sourceforge.net/projects/sglibc/ It is for developers only. H.J. From owner-linux-mips@oss.sgi.com Thu Aug 16 14:40:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GLed510480 for linux-mips-outgoing; Thu, 16 Aug 2001 14:40:39 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GLeXj10477 for ; Thu, 16 Aug 2001 14:40:33 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GLjBA27917; Thu, 16 Aug 2001 14:45:11 -0700 Message-ID: <3B7C3C75.4AB05B13@mvista.com> Date: Thu, 16 Aug 2001 14:34:45 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Daniel Jacobowitz , "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2358 Lines: 58 "Kevin D. Kissell" wrote: > > > > current->used_math should never be set to zero in this sort of > > > situation. It's not an ownership flag! It marks whether the FP state > > > in the thread structure is valid. > > > > Daniel, it is funny that I agree with your last statement but cannot agree > > with your first one. > > > > Under the above mentioned situation, after we make the copy of FPU state > from > > thread structure to the saved signal context, we need to set used_math bit > to > > zero. This way when the signal handler uses FPU for the first time - if > it > > ever uses it -, the normal lazy FPU switch mechanism can kick in smoothly. > > We've had a lot of messages crossing here, but please > explain yourself here why clearing used_math helps in > this case. If, as has been proposed, the current > thread does not own the FPU, and thus CU1 is not > enabled, the FPU switch mechanism should kick in > during the signal handler regardless. The signal > handler will inherit the thread's FPU state from > the thread context, and will muck with it, but > if, as has been noted, the sigcontext has > been loaded from the thread context before > the handler is dispatched, and is restored after > the handler executes, we're fine. The only thing > I can see that clearing used_math would achieve > would be to guarantee the signal handler a virgin > FPU context. > Yes, that is somewhat the purpose. Essentially we want to see, at the beginning of a signal handler execution, the process appears to have not used FPU at all. This requirement might be a must, because whether clearing current->used_math bit determine which patch we will take in the do_cpu(), when signal handler uses FPU for the first time. See the code below. if (current->used_math) { /* Using the FPU again. */ lazy_fpu_switch(last_task_used_math); } else { /* First time FPU user. */ init_fpu(); current->used_math = 1; } last_task_used_math = current; Clearly the second path is logically the correct one. BTW, do I see another bug here in do_cpu()? It seems that before we call init_fpu(), we should check last_task_used_math. If it is not NULL, we should save the FP state to the last_task_used_math. Hmm, strange ... Jun From owner-linux-mips@oss.sgi.com Thu Aug 16 15:29:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMTEc12219 for linux-mips-outgoing; Thu, 16 Aug 2001 15:29:14 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GMTCj12216 for ; Thu, 16 Aug 2001 15:29:12 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA07271; Thu, 16 Aug 2001 15:29:02 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA01537; Thu, 16 Aug 2001 15:29:04 -0700 (PDT) Message-ID: <01c701c126a3$7c5bcbc0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: "Daniel Jacobowitz" , "MIPS/Linux List \(SGI\)" References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> <3B7C3C75.4AB05B13@mvista.com> Subject: Re: FP emulator patch Date: Fri, 17 Aug 2001 00:33:31 +0200 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2168 Lines: 61 > > We've had a lot of messages crossing here, but please > > explain yourself here why clearing used_math helps in > > this case. If, as has been proposed, the current > > thread does not own the FPU, and thus CU1 is not > > enabled, the FPU switch mechanism should kick in > > during the signal handler regardless. The signal > > handler will inherit the thread's FPU state from > > the thread context, and will muck with it, but > > if, as has been noted, the sigcontext has > > been loaded from the thread context before > > the handler is dispatched, and is restored after > > the handler executes, we're fine. The only thing > > I can see that clearing used_math would achieve > > would be to guarantee the signal handler a virgin > > FPU context. > > Yes, that is somewhat the purpose. Essentially we want to see, at the > beginning of a signal handler execution, the process appears to have not used > FPU at all. > > This requirement might be a must, because whether clearing current->used_math > bit determine which patch we will take in the do_cpu(), when signal handler > uses FPU for the first time. See the code below. > > if (current->used_math) { /* Using the FPU again. */ > lazy_fpu_switch(last_task_used_math); > } else { /* First time FPU user. */ > init_fpu(); > current->used_math = 1; > } > last_task_used_math = current; > > Clearly the second path is logically the correct one. Not really. See below. > BTW, do I see another bug here in do_cpu()? It seems that before we call > init_fpu(), we should check last_task_used_math. If it is not NULL, we should > save the FP state to the last_task_used_math. Hmm, strange ... Strange indeed. And note that if the code were correct, your surmise about the init_fpu() path being "logically the correct" one would no longer be true - we'd be saving the FPU state of the current process for no good reason. The more I look at the FPU management code, the more I marvel that it even gives an appearance of working... Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 15:34:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMYpo12418 for linux-mips-outgoing; Thu, 16 Aug 2001 15:34:51 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GMYoj12415 for ; Thu, 16 Aug 2001 15:34:50 -0700 Received: from pacbell.net (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GMdMA30471; Thu, 16 Aug 2001 15:39:28 -0700 Message-ID: <3B7C4B6D.5080409@pacbell.net> Date: Thu, 16 Aug 2001 15:38:37 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Jun Sun , Daniel Jacobowitz , "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> <3B7C3C75.4AB05B13@mvista.com> <01c701c126a3$7c5bcbc0$0deca8c0@Ulysses> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 567 Lines: 16 > Strange indeed. And note that if the code were correct, your > surmise about the init_fpu() path being "logically the correct" > one would no longer be true - we'd be saving the FPU state of > the current process for no good reason. > > The more I look at the FPU management code, the more I marvel > that it even gives an appearance of working... Maybe no one has stress tested it enough up till now. As soon as we put he mips boards in QA we found a few fpu problems immediately. I hope those were it and we weren't just scratching the surface. Pete From owner-linux-mips@oss.sgi.com Thu Aug 16 15:47:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMl9E12810 for linux-mips-outgoing; Thu, 16 Aug 2001 15:47:09 -0700 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 f7GMl7j12806 for ; Thu, 16 Aug 2001 15:47:07 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA28006 for ; Thu, 16 Aug 2001 15:46:50 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15XVl8-0005kH-00; Thu, 16 Aug 2001 15:37:02 -0700 Date: Thu, 16 Aug 2001 15:37:02 -0700 From: Daniel Jacobowitz To: Jun Sun Cc: "Kevin D. Kissell" , "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch Message-ID: <20010816153702.A21978@nevyn.them.org> References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> <3B7C3C75.4AB05B13@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <3B7C3C75.4AB05B13@mvista.com>; from jsun@mvista.com on Thu, Aug 16, 2001 at 02:34:45PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1455 Lines: 34 On Thu, Aug 16, 2001 at 02:34:45PM -0700, Jun Sun wrote: > Yes, that is somewhat the purpose. Essentially we want to see, at the > beginning of a signal handler execution, the process appears to have not used > FPU at all. Why? > This requirement might be a must, because whether clearing current->used_math > bit determine which patch we will take in the do_cpu(), when signal handler > uses FPU for the first time. See the code below. > > if (current->used_math) { /* Using the FPU again. */ > lazy_fpu_switch(last_task_used_math); > } else { /* First time FPU user. */ > init_fpu(); > current->used_math = 1; > } > last_task_used_math = current; > > Clearly the second path is logically the correct one. Not really. Why should it get a clean set of FP registers? I think the CORRECT thing would actually be for it to have the app's FP registers. Changes should not propogate back to the app, that's all. > BTW, do I see another bug here in do_cpu()? It seems that before we call > init_fpu(), we should check last_task_used_math. If it is not NULL, we should > save the FP state to the last_task_used_math. Hmm, strange ... I thought I got all of these... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Aug 16 15:54:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GMsU113146 for linux-mips-outgoing; Thu, 16 Aug 2001 15:54:30 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GMsSj13142 for ; Thu, 16 Aug 2001 15:54:28 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA07597; Thu, 16 Aug 2001 15:53:39 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA02054; Thu, 16 Aug 2001 15:53:40 -0700 (PDT) Message-ID: <01e801c126a6$ec2a3420$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: "MIPS/Linux List \(SGI\)" , "Daniel Jacobowitz" Subject: Re: FP emulator patch Date: Fri, 17 Aug 2001 00:58:01 +0200 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1091 Lines: 32 > > > > if (current->used_math) { /* Using the FPU again. > */ > > lazy_fpu_switch(last_task_used_math); > > } else { /* First time FPU user. > */ > > init_fpu(); > > current->used_math = 1; > > } > > last_task_used_math = current; > > > > Clearly the second path is logically the correct one. > > Not really. See below. > > > BTW, do I see another bug here in do_cpu()? It seems that before we call > > init_fpu(), we should check last_task_used_math. If it is not NULL, we > should > > save the FP state to the last_task_used_math. Hmm, strange ... > > Strange indeed. And note that if the code were correct, your > surmise about the init_fpu() path being "logically the correct" > one would no longer be true - we'd be saving the FPU state of > the current process for no good reason. And note further that, by forcing current->used_math to zero, the old code was in fact driving the signal handler needlessly into the broken code... Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 16:18:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GNICC13848 for linux-mips-outgoing; Thu, 16 Aug 2001 16:18:12 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GNI9j13839 for ; Thu, 16 Aug 2001 16:18:10 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GNMnA32710; Thu, 16 Aug 2001 16:22:50 -0700 Message-ID: <3B7C5358.59C72108@mvista.com> Date: Thu, 16 Aug 2001 16:12:24 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: "Kevin D. Kissell" , "MIPS/Linux List (SGI)" Subject: Re: FP emulator patch References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> <3B7C3C75.4AB05B13@mvista.com> <20010816153702.A21978@nevyn.them.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2574 Lines: 61 Daniel Jacobowitz wrote: > > On Thu, Aug 16, 2001 at 02:34:45PM -0700, Jun Sun wrote: > > Yes, that is somewhat the purpose. Essentially we want to see, at the > > beginning of a signal handler execution, the process appears to have not used > > FPU at all. > > Why? > > > This requirement might be a must, because whether clearing current->used_math > > bit determine which patch we will take in the do_cpu(), when signal handler > > uses FPU for the first time. See the code below. > > > > if (current->used_math) { /* Using the FPU again. */ > > lazy_fpu_switch(last_task_used_math); > > } else { /* First time FPU user. */ > > init_fpu(); > > current->used_math = 1; > > } > > last_task_used_math = current; > > > > Clearly the second path is logically the correct one. > > Not really. Why should it get a clean set of FP registers? I think > the CORRECT thing would actually be for it to have the app's FP > registers. Changes should not propogate back to the app, that's all. > Ah, it seems I need to defend an "obvious" point. :-) I am from the school which view signal handler as an interrupt context to a normal process. (In fact, some OSes implement signal handling by using a separate thread/process). Under this view, it is natural to provide a fresh new context when a signal handler starts. In other words, I am thinking in the following semantics: a signal handler starting execution is equivalent to another process starting execution with the same address space, except that the original process won't resume until the "signal handler process" exits. Thinking from that, I feel we should clear the current->used_math bit. I think it is not correct for signal handler to inherit the FPU registers. If it wants to check the register values when the signal happens, it should do so by examing the signal context. Apparently a well code signal handler does not depend on whether we clear current->used_math bit or not, because it should always set a FPU register before it uses it. Jun > > BTW, do I see another bug here in do_cpu()? It seems that before we call > > init_fpu(), we should check last_task_used_math. If it is not NULL, we should > > save the FP state to the last_task_used_math. Hmm, strange ... > > I thought I got all of these... > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Aug 16 16:19:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GNJkk13930 for linux-mips-outgoing; Thu, 16 Aug 2001 16:19:46 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GNJjj13927 for ; Thu, 16 Aug 2001 16:19:45 -0700 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7GNOSA00330; Thu, 16 Aug 2001 16:24:28 -0700 Message-ID: <3B7C53BA.24B75620@mvista.com> Date: Thu, 16 Aug 2001 16:14:02 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "MIPS/Linux List (SGI)" , Daniel Jacobowitz Subject: Re: FP emulator patch References: <01e801c126a6$ec2a3420$0deca8c0@Ulysses> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1260 Lines: 37 "Kevin D. Kissell" wrote: > > > > > > > if (current->used_math) { /* Using the FPU again. > > */ > > > lazy_fpu_switch(last_task_used_math); > > > } else { /* First time FPU user. > > */ > > > init_fpu(); > > > current->used_math = 1; > > > } > > > last_task_used_math = current; > > > > > > Clearly the second path is logically the correct one. > > > > Not really. See below. > > > > > BTW, do I see another bug here in do_cpu()? It seems that before we > call > > > init_fpu(), we should check last_task_used_math. If it is not NULL, we > > should > > > save the FP state to the last_task_used_math. Hmm, strange ... > > > > Strange indeed. And note that if the code were correct, your > > surmise about the init_fpu() path being "logically the correct" > > one would no longer be true - we'd be saving the FPU state of > > the current process for no good reason. > > And note further that, by forcing current->used_math to > zero, the old code was in fact driving the signal handler > needlessly into the broken code... > By not clearing current->used_math bit, you are in fact restoring an FPU context unnecessarily. Jun From owner-linux-mips@oss.sgi.com Thu Aug 16 16:34:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GNY1C14388 for linux-mips-outgoing; Thu, 16 Aug 2001 16:34:01 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GNY0j14384 for ; Thu, 16 Aug 2001 16:34:00 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA08048; Thu, 16 Aug 2001 16:33:44 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA03090; Thu, 16 Aug 2001 16:33:46 -0700 (PDT) Message-ID: <01fc01c126ac$866ceb40$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Jun Sun" Cc: "MIPS/Linux List \(SGI\)" References: <018201c12680$8f13e680$0deca8c0@Ulysses> <20010816115349.A12153@nevyn.them.org> <3B7C1BB9.7011790E@mvista.com> <01b001c12693$b4920140$0deca8c0@Ulysses> <3B7C3C75.4AB05B13@mvista.com> <20010816153702.A21978@nevyn.them.org> Subject: Re: FP emulator patch Date: Fri, 17 Aug 2001 01:38:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1347 Lines: 42 > > if (current->used_math) { /* Using the FPU again. */ > > lazy_fpu_switch(last_task_used_math); > > } else { /* First time FPU user. */ > > init_fpu(); > > current->used_math = 1; > > } > > last_task_used_math = current; > > ... > > BTW, do I see another bug here in do_cpu()? It seems that before we call > > init_fpu(), we should check last_task_used_math. If it is not NULL, we should > > save the FP state to the last_task_used_math. Hmm, strange ... > > I thought I got all of these... Looks like that should be: } else { if (last_task_used_math != NULL) save_fp(last_task_used_math); init_fpu() current->used_math = 1; } And things will be OK. What's wierd is that I could have sworn that I looked at this code long ago, and that there was a save there. But even in the 2.2.12-based tree, there is none. It's quite late here in France. If one (or more) of you guys could sketch a code fragment that would copy FP context back and forth between a thread structure and a sigcontext without passing through the FPU while I'm sleeping, I'll put together an integrated patch tomorrow. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 16:43:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GNh6114712 for linux-mips-outgoing; Thu, 16 Aug 2001 16:43:06 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GNh5j14709 for ; Thu, 16 Aug 2001 16:43:05 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA08168; Thu, 16 Aug 2001 16:42:22 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA03284; Thu, 16 Aug 2001 16:42:24 -0700 (PDT) Message-ID: <020001c126ad$bad05e20$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: "MIPS/Linux List \(SGI\)" , "Daniel Jacobowitz" References: <01e801c126a6$ec2a3420$0deca8c0@Ulysses> <3B7C53BA.24B75620@mvista.com> Subject: Re: FP emulator patch Date: Fri, 17 Aug 2001 01:46:40 +0200 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 834 Lines: 22 > > > Strange indeed. And note that if the code were correct, your > > > surmise about the init_fpu() path being "logically the correct" > > > one would no longer be true - we'd be saving the FPU state of > > > the current process for no good reason. > > > > And note further that, by forcing current->used_math to > > zero, the old code was in fact driving the signal handler > > needlessly into the broken code... > > > > By not clearing current->used_math bit, you are in fact restoring an FPU > context unnecessarily. And by clearing it, you are destroying an FPU context unnecessarily. I'll take the overhead, thanks! ;-) Seriously, if that optimization is really that important, let's find some other mechanism for communicating to do_cpu() the fact that we're doing a signal. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu Aug 16 20:09:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7H397N20133 for linux-mips-outgoing; Thu, 16 Aug 2001 20:09:07 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7H393j20130 for ; Thu, 16 Aug 2001 20:09:04 -0700 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 17 Aug 2001 03:09:03 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 52C1354CDB; Fri, 17 Aug 2001 12:09:01 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA72165; Fri, 17 Aug 2001 12:09:01 +0900 (JST) Date: Fri, 17 Aug 2001 12:13:34 +0900 (JST) Message-Id: <20010817.121334.41627251.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: patch for ide_init_hwif_ports From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Aug_17_12:13:34_2001_424)--" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1684 Lines: 54 ----Next_Part(Fri_Aug_17_12:13:34_2001_424)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is 'ide_init_hwif_ports' member in ide_ops structure but currently never used. This is a patch to use this (again). --- Atsushi Nemoto ----Next_Part(Fri_Aug_17_12:13:34_2001_424)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ide.patch" diff -ur linux.sgi/arch/mips/lib/ide-std.c linux/arch/mips/lib/ide-std.c --- linux.sgi/arch/mips/lib/ide-std.c Thu Jun 17 22:25:49 1999 +++ linux/arch/mips/lib/ide-std.c Fri Aug 17 11:55:49 2001 @@ -60,6 +60,7 @@ } if (irq != NULL) *irq = 0; + hw->io_ports[IDE_IRQ_OFFSET] = 0; } static int std_ide_request_irq(unsigned int irq, diff -ur linux.sgi/include/asm-mips/ide.h linux/include/asm-mips/ide.h --- linux.sgi/include/asm-mips/ide.h Tue Apr 24 02:46:11 2001 +++ linux/include/asm-mips/ide.h Fri Aug 17 11:54:36 2001 @@ -56,21 +56,7 @@ static inline void ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, ide_ioreg_t ctrl_port, int *irq) { - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; + ide_ops->ide_init_hwif_ports(hw, data_port, ctrl_port, irq); } static __inline__ void ide_init_default_hwifs(void) ----Next_Part(Fri_Aug_17_12:13:34_2001_424)---- From owner-linux-mips@oss.sgi.com Thu Aug 16 21:33:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7H4XAF22190 for linux-mips-outgoing; Thu, 16 Aug 2001 21:33:10 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7H4X9j22187 for ; Thu, 16 Aug 2001 21:33:09 -0700 Received: from galt.foobazco.org (galt.foobazco.org [198.144.194.227]) by mail.foobazco.org (Postfix) with ESMTP id 6FE463E90; Thu, 16 Aug 2001 21:20:28 -0700 (PDT) Received: by galt.foobazco.org (Postfix, from userid 1014) id 986FF13FD0; Thu, 16 Aug 2001 21:27:27 -0700 (PDT) Date: Thu, 16 Aug 2001 21:27:27 -0700 From: Keith M Wesolowski To: Steven Liu Cc: linux-mips@oss.sgi.com Subject: Re: glibc 2.0.6 building problem. Message-ID: <20010816212727.A27405@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84CE342693F11946B9F54B18C1AB837B0A24C5@ex2k.pcs.psdc.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 622 Lines: 15 On Thu, Aug 16, 2001 at 10:33:43AM -0700, Steven Liu wrote: > It seems that I need to copy the kernel's include files and lib to > somewhere. I could not figure it out. Thankfully, you won't have to. I've already fully documented the entire process at http://foobazco.org/~wesolows/mips-cross.html. Repeat after me, "This mailing list is no substitute for Google." -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Fri Aug 17 04:23:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBNdu31252 for linux-mips-outgoing; Fri, 17 Aug 2001 04:23:39 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBNZj31247 for ; Fri, 17 Aug 2001 04:23:35 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBLnS05139 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:21:49 +0200 Date: Fri, 17 Aug 2001 12:02:21 +0200 From: Ralf Baechle To: Keith M Wesolowski Cc: Steven Liu , linux-mips@oss.sgi.com Subject: Re: glibc 2.0.6 building problem. Message-ID: <20010817120220.A4792@bacchus.dhis.org> References: <84CE342693F11946B9F54B18C1AB837B0A24C5@ex2k.pcs.psdc.com> <20010816212727.A27405@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010816212727.A27405@foobazco.org>; from wesolows@foobazco.org on Thu, Aug 16, 2001 at 09:27:27PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 472 Lines: 13 On Thu, Aug 16, 2001 at 09:27:27PM -0700, Keith M Wesolowski wrote: > > It seems that I need to copy the kernel's include files and lib to > > somewhere. I could not figure it out. > > Thankfully, you won't have to. I've already fully documented the > entire process at http://foobazco.org/~wesolows/mips-cross.html. > > Repeat after me, "This mailing list is no substitute for Google." As for me I'll forward glibc 2.0 questions to my watercooled /dev/zero. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 17 04:39:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBdBs31534 for linux-mips-outgoing; Fri, 17 Aug 2001 04:39:11 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBd8j31531 for ; Fri, 17 Aug 2001 04:39:08 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBbEL05267; Fri, 17 Aug 2001 13:37:14 +0200 Date: Fri, 17 Aug 2001 13:37:14 +0200 From: Ralf Baechle To: machael thailer Cc: linux-mips@oss.sgi.com Subject: Re: Where is the first entry point for linux-mips boot? Message-ID: <20010817133714.A5226@bacchus.dhis.org> References: <000701c11c8b$77e039e0$8021690a@huawei.com> <20010804071016.A1275@bacchus.dhis.org> <001501c126ca$4a5331a0$8021690a@huawei.com> <20010817052635.A2931@bacchus.dhis.org> <000901c12704$bf95c2e0$8021690a@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: <000901c12704$bf95c2e0$8021690a@huawei.com>; from dony.he@huawei.com on Fri, Aug 17, 2001 at 06:09:48PM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 392 Lines: 11 On Fri, Aug 17, 2001 at 06:09:48PM +0800, machael thailer wrote: > If I load the kernel to RAM address 0x80200000, is this a virtual address or > physical address at this time? Since my RAM can not be so large, I guess > this is virtual address,right? Should I enable MMU in my board > initializations? A virtual address in KSEG0. A MIPS MMU has no enable bit, it's always active. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 17 04:47:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBlJt31974 for linux-mips-outgoing; Fri, 17 Aug 2001 04:47:19 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBlCj31969 for ; Fri, 17 Aug 2001 04:47:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBjPR05331 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:45:25 +0200 Received: from artilemicro.com ([209.243.128.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7H2HGj18712 for ; Thu, 16 Aug 2001 19:17:16 -0700 Received: from artilemicro.com (sunrise [209.243.129.241]) by artilemicro.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12127 for ; Thu, 16 Aug 2001 19:17:09 -0700 (PDT) Message-ID: <3B7C7EA5.A307DAD@artilemicro.com> Date: Thu, 16 Aug 2001 19:17:09 -0700 From: Hua Wen Organization: Artile Microsystems, Inc. X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: zh-CN, en, zh, zh-TW MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Upgrade kernel from release 2.2.1 to 2.4.? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 429 Lines: 18 Hi, We made changes to linux/MIPS kernel 2.2.1 for our system and it's been running well so far. We now plan to upgrade the kernel to 2.4.X. The question we have is: Which sub release of 2.4 is more stable and is recommended to use? >From http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux, I can see available tags for kernel 2.4 are: linux_2_4_4, linux_2_4_3, linux_2_4_2, linux_2_4_0... Thanks in advance for your advice! -Hua From owner-linux-mips@oss.sgi.com Fri Aug 17 04:47:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBlQG31986 for linux-mips-outgoing; Fri, 17 Aug 2001 04:47:26 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBlIj31971 for ; Fri, 17 Aug 2001 04:47:18 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBjWn05335 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:45:32 +0200 Received: from smtp.huawei.com (nszx104.121.szptt.net.cn [202.104.121.208] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7H3Bfj20266; Thu, 16 Aug 2001 20:11:41 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GI6Z6000.016; Fri, 17 Aug 2001 11:03:36 +0800 Message-ID: <001501c126ca$4a5331a0$8021690a@huawei.com> From: "machael thailer" To: "Ralf Baechle" Cc: References: <000701c11c8b$77e039e0$8021690a@huawei.com> <20010804071016.A1275@bacchus.dhis.org> Subject: Re: Where is the first entry point for linux-mips boot? Date: Fri, 17 Aug 2001 11:11:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1324 Lines: 39 ----- Original Message ----- From: "Ralf Baechle" To: "machael thailer" Cc: Sent: Saturday, August 04, 2001 1:10 PM Subject: Re: Where is the first entry point for linux-mips boot? > On Sat, Aug 04, 2001 at 10:16:27AM +0800, machael thailer wrote: > > > There are many many subdirectories in arch/mips, I don't know where is > > the FIRST entry point for embedded linux-mips boot process? I find that > > there is "kernel_entry" in arch/mips/kernel/head.S. I know this is the entry > > point for linux kernel ,but it is not the FIRST entry point for embedded > > linux-mips boot process. So my questions is : > > After the board initializations finish, it should load linux kernel into > > RAM and jump there . Just before it runs the linux kernel, who calls > > "kernel_entry"? > > The firmware or bootloader. Another question: After my custom board finished initializations, It should load "linux kernel" into RAM. The question is : Is this a compressed "linux kernel" just like vmlinux.gz of X86 that I should load? Or is it "/usr/src/linux/vmlinux" that is not compressed that I should load? And what RAM address should it loaded at? Since it is linked at 0x80200000,Should I load there or at somewhere else? Thanks very much. machael From owner-linux-mips@oss.sgi.com Fri Aug 17 04:47:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBlfZ32008 for linux-mips-outgoing; Fri, 17 Aug 2001 04:47:41 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBlQj31994 for ; Fri, 17 Aug 2001 04:47:26 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBjd405339 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:45:39 +0200 Received: from dea.waldorf-gmbh.de (u-47-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.47]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7H3Y6j20772 for ; Thu, 16 Aug 2001 20:34:07 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7H3QZr03388; Fri, 17 Aug 2001 05:26:35 +0200 Date: Fri, 17 Aug 2001 05:26:35 +0200 From: Ralf Baechle To: machael thailer Cc: linux-mips@oss.sgi.com Subject: Re: Where is the first entry point for linux-mips boot? Message-ID: <20010817052635.A2931@bacchus.dhis.org> References: <000701c11c8b$77e039e0$8021690a@huawei.com> <20010804071016.A1275@bacchus.dhis.org> <001501c126ca$4a5331a0$8021690a@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: <001501c126ca$4a5331a0$8021690a@huawei.com>; from dony.he@huawei.com on Fri, Aug 17, 2001 at 11:11:21AM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 801 Lines: 19 On Fri, Aug 17, 2001 at 11:11:21AM +0800, machael thailer wrote: > After my custom board finished initializations, It should load "linux > kernel" into RAM. > The question is : Is this a compressed "linux kernel" just like vmlinux.gz > of X86 that I should load? Or is it "/usr/src/linux/vmlinux" that is not > compressed that I should load? The standard MIPS kernel doesn't support compressed kernels on MIPS. > And what RAM address should it loaded at? Since it is linked at > 0x80200000,Should I load there or at somewhere else? Obviously to the address it's linked for. You can adjust that address as you need. With compressed kernels it may be necessary to choose a different address however so the decompressed kernel doesn't overwrite the compressed kernel during compression. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 17 04:47:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBlhi32022 for linux-mips-outgoing; Fri, 17 Aug 2001 04:47:43 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBlbj32004 for ; Fri, 17 Aug 2001 04:47:37 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBjos05347 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:45:50 +0200 Received: from dea.waldorf-gmbh.de (u-13-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HA5sj29403 for ; Fri, 17 Aug 2001 03:05:55 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HA2Lh04826; Fri, 17 Aug 2001 12:02:21 +0200 Date: Fri, 17 Aug 2001 12:02:21 +0200 From: Ralf Baechle To: Keith M Wesolowski Cc: Steven Liu , linux-mips@oss.sgi.com Subject: Re: glibc 2.0.6 building problem. Message-ID: <20010817120220.A4792@bacchus.dhis.org> References: <84CE342693F11946B9F54B18C1AB837B0A24C5@ex2k.pcs.psdc.com> <20010816212727.A27405@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010816212727.A27405@foobazco.org>; from wesolows@foobazco.org on Thu, Aug 16, 2001 at 09:27:27PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 472 Lines: 13 On Thu, Aug 16, 2001 at 09:27:27PM -0700, Keith M Wesolowski wrote: > > It seems that I need to copy the kernel's include files and lib to > > somewhere. I could not figure it out. > > Thankfully, you won't have to. I've already fully documented the > entire process at http://foobazco.org/~wesolows/mips-cross.html. > > Repeat after me, "This mailing list is no substitute for Google." As for me I'll forward glibc 2.0 questions to my watercooled /dev/zero. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 17 04:50:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HBow032138 for linux-mips-outgoing; Fri, 17 Aug 2001 04:50:58 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HBosj32133 for ; Fri, 17 Aug 2001 04:50:55 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBmt805382; Fri, 17 Aug 2001 13:48:55 +0200 Date: Fri, 17 Aug 2001 13:48:55 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: patch for ide_init_hwif_ports Message-ID: <20010817134855.A5318@bacchus.dhis.org> References: <20010817.121334.41627251.nemoto@toshiba-tops.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: <20010817.121334.41627251.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Aug 17, 2001 at 12:13:34PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 222 Lines: 8 On Fri, Aug 17, 2001 at 12:13:34PM +0900, Atsushi Nemoto wrote: > There is 'ide_init_hwif_ports' member in ide_ops structure but > currently never used. This is a patch to use this (again). Looks good, applied. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 17 05:10:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HCAFf32580 for linux-mips-outgoing; Fri, 17 Aug 2001 05:10:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HCA3j32576 for ; Fri, 17 Aug 2001 05:10:03 -0700 Received: from dea.waldorf-gmbh.de (u-214-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.214]) 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 FAA05007 for ; Fri, 17 Aug 2001 05:09:48 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBjiB05343 for linux-mips@oss.sgi.com; Fri, 17 Aug 2001 13:45:44 +0200 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 f7HAGFj29642; Fri, 17 Aug 2001 03:16:15 -0700 Received: from smtp.huawei.com ([202.104.121.208]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id DAA27269; Fri, 17 Aug 2001 03:15:49 -0700 (PDT) mail_from (dony.he@huawei.com) Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GI7IJE03.A2S; Fri, 17 Aug 2001 18:02:02 +0800 Message-ID: <000901c12704$bf95c2e0$8021690a@huawei.com> From: "machael thailer" To: "Ralf Baechle" Cc: References: <000701c11c8b$77e039e0$8021690a@huawei.com> <20010804071016.A1275@bacchus.dhis.org> <001501c126ca$4a5331a0$8021690a@huawei.com> <20010817052635.A2931@bacchus.dhis.org> Subject: Re: Where is the first entry point for linux-mips boot? Date: Fri, 17 Aug 2001 18:09:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1336 Lines: 38 ----- Original Message ----- From: "Ralf Baechle" To: "machael thailer" Cc: Sent: Friday, August 17, 2001 11:26 AM Subject: Re: Where is the first entry point for linux-mips boot? > On Fri, Aug 17, 2001 at 11:11:21AM +0800, machael thailer wrote: > > > After my custom board finished initializations, It should load "linux > > kernel" into RAM. > > The question is : Is this a compressed "linux kernel" just like vmlinux.gz > > of X86 that I should load? Or is it "/usr/src/linux/vmlinux" that is not > > compressed that I should load? > > The standard MIPS kernel doesn't support compressed kernels on MIPS. > > > And what RAM address should it loaded at? Since it is linked at > > 0x80200000,Should I load there or at somewhere else? > > Obviously to the address it's linked for. You can adjust that address > as you need. With compressed kernels it may be necessary to choose a > different address however so the decompressed kernel doesn't overwrite > the compressed kernel during compression. If I load the kernel to RAM address 0x80200000, is this a virtual address or physical address at this time? Since my RAM can not be so large, I guess this is virtual address,right? Should I enable MMU in my board initializations? Thank you once again. machael From owner-linux-mips@oss.sgi.com Fri Aug 17 07:23:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7HENub03907 for linux-mips-outgoing; Fri, 17 Aug 2001 07:23:56 -0700 Received: from newsmtp2.atmel.com (newsmtp2.atmel.com [12.146.133.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HENsj03903 for ; Fri, 17 Aug 2001 07:23:54 -0700 Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105]) by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id HAA12538 for ; Fri, 17 Aug 2001 07:16:49 -0700 (PDT) Received: from mmc.atmel.com (mail [10.127.240.34]) by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA13565 for ; Fri, 17 Aug 2001 07:17:06 -0700 (PDT) Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163]) by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA04625 for ; Fri, 17 Aug 2001 10:24:00 -0400 (EDT) Message-ID: <3B7D3784.6F27145A@mmc.atmel.com> Date: Fri, 17 Aug 2001 10:25:56 -0500 From: Shuanglin Wang Reply-To: swang@mmc.atmel.com Organization: ATMEL MMC X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Malta board and Linux 2.4.4? Content-Type: multipart/alternative; boundary="------------F128D695AE8ED1390D5D3AB5" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1049 Lines: 37 --------------F128D695AE8ED1390D5D3AB5 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi, Does anybody make the standard Linux kernel 2.4.4 working on the Malta board? I used Lineo Embedix SDK to built up kernel image based on the kernel 2.4.4, but system will be panic when it tries to install NFS root directory. I wonder if anybody has tested Linux kernel 2.4.4 on the Malta board. Thanx, --Shuanglin --------------F128D695AE8ED1390D5D3AB5 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit Hi,

Does anybody make the standard Linux kernel 2.4.4 working on the Malta board?  I used Lineo Embedix SDK to built up kernel image based on the kernel 2.4.4,  but system will be panic when it tries to install NFS  root directory.  I wonder if anybody has tested Linux kernel 2.4.4 on the Malta board.

Thanx, 

--Shuanglin



--------------F128D695AE8ED1390D5D3AB5--


From owner-linux-mips@oss.sgi.com Fri Aug 17 10:32:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HHWCw07632
	for linux-mips-outgoing; Fri, 17 Aug 2001 10:32:12 -0700
Received: from artilemicro.com ([209.243.128.35])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HHWAj07629
	for ; Fri, 17 Aug 2001 10:32:10 -0700
Received: from taec.com (sunrise [209.243.129.241])
	by artilemicro.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12933
	for ; Fri, 17 Aug 2001 10:32:02 -0700 (PDT)
Message-ID: <3B7D5513.F10F35A1@taec.com>
Date: Fri, 17 Aug 2001 10:32:03 -0700
From: Hua Wen 
Organization: Artile Microsystems, Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: zh-CN, en, zh, zh-TW
MIME-Version: 1.0
To: linux-mips@oss.sgi.com
Subject: Upgrade kernel from release 2.2 to 2.4.?
References: 
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 421
Lines: 18

Hi,

We made changes to linux/MIPS kernel 2.2.1 for our
system and it's been running well so far. We now
plan to upgrade the kernel to 2.4.X. The question
is:

Which sub release of 2.4 is more stable and is
recommended to use? 

>From http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux,
I can see available tags for kernel 2.4 are:
linux_2_4_4, linux_2_4_3, linux_2_4_2,
linux_2_4_0...

Thanks in advance for your advice!

-Hua

From owner-linux-mips@oss.sgi.com Fri Aug 17 10:49:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HHnrA08055
	for linux-mips-outgoing; Fri, 17 Aug 2001 10:49:53 -0700
Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HHnpj08052
	for ; Fri, 17 Aug 2001 10:49:51 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7HHsVA08494;
	Fri, 17 Aug 2001 10:54:31 -0700
Message-ID: <3B7D57E4.D7B14D63@mvista.com>
Date: Fri, 17 Aug 2001 10:44:04 -0700
From: Jun Sun 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hua Wen 
CC: linux-mips@oss.sgi.com
Subject: Re: Upgrade kernel from release 2.2 to 2.4.?
References:  <3B7D5513.F10F35A1@taec.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 625
Lines: 25

Hua Wen wrote:
> 
> Hi,
> 
> We made changes to linux/MIPS kernel 2.2.1 for our
> system and it's been running well so far. We now
> plan to upgrade the kernel to 2.4.X. The question
> is:
> 
> Which sub release of 2.4 is more stable and is
> recommended to use?
> 
> From http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux,
> I can see available tags for kernel 2.4 are:
> linux_2_4_4, linux_2_4_3, linux_2_4_2,
> linux_2_4_0...
> 
> Thanks in advance for your advice!
> 
> -Hua

I suggest you use the latest CVS head.  So far it is usually the head that has
the most bug fixes, and really not much dramatic stuff introduced.

Jun

From owner-linux-mips@oss.sgi.com Fri Aug 17 12:20:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HJKdE10102
	for linux-mips-outgoing; Fri, 17 Aug 2001 12:20:39 -0700
Received: from artilemicro.com ([209.243.128.35])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HJKbj10099
	for ; Fri, 17 Aug 2001 12:20:37 -0700
Received: from taec.com (sunrise [209.243.129.241])
	by artilemicro.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13055;
	Fri, 17 Aug 2001 12:20:27 -0700 (PDT)
Message-ID: <3B7D6E7B.9994255@taec.com>
Date: Fri, 17 Aug 2001 12:20:27 -0700
From: Hua Wen 
Organization: Artile Microsystems, Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: zh-CN, en, zh, zh-TW
MIME-Version: 1.0
To: Jun Sun 
CC: linux-mips@oss.sgi.com
Subject: Re: Upgrade kernel from release 2.2 to 2.4.?
References:  <3B7D5513.F10F35A1@taec.com> <3B7D57E4.D7B14D63@mvista.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 818
Lines: 33


Thank you very much, Jun.

One more thing -- we've made quite some changes in
2.2.1 so I wonder what would be the best way to
upgrade. I'm thinking:

1> check out new kernel, use "merge directories"
function from emacs, or

2> use "cvs import" to import the new kernel to
our local cvs repository, then merge with our
local changes by "cvs update/co -j"..

Any comments/suggestions?

Thanks!
-Hua

> >
> > We made changes to linux/MIPS kernel 2.2.1 for our
> > system and it's been running well so far. We now
> > plan to upgrade the kernel to 2.4.X. The question
> > is:
> >
> > Which sub release of 2.4 is more stable and is
> > recommended to use?
> >
> 
> I suggest you use the latest CVS head.  So far it is usually the head that has
> the most bug fixes, and really not much dramatic stuff introduced.
> 
> Jun

From owner-linux-mips@oss.sgi.com Fri Aug 17 13:43:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HKhWo12255
	for linux-mips-outgoing; Fri, 17 Aug 2001 13:43:32 -0700
Received: from newsmtp2.atmel.com (newsmtp2.atmel.com [12.146.133.142])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HKhUj12250
	for ; Fri, 17 Aug 2001 13:43:30 -0700
Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105])
	by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA22623
	for ; Fri, 17 Aug 2001 13:36:22 -0700 (PDT)
Received: from mmc.atmel.com (mail [10.127.240.34])
	by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA03225
	for ; Fri, 17 Aug 2001 13:36:40 -0700 (PDT)
Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id QAA01119
	for ; Fri, 17 Aug 2001 16:43:34 -0400 (EDT)
Message-ID: <3B7D9079.8F7F768F@mmc.atmel.com>
Date: Fri, 17 Aug 2001 16:45:29 -0500
From: Shuanglin Wang 
Reply-To: swang@mmc.atmel.com
Organization: ATMEL MMC
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@oss.sgi.com
Subject: Malta board and Linux 2.4.4?
Content-Type: multipart/alternative;
 boundary="------------58F88112601457E72773E383"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1051
Lines: 40


--------------58F88112601457E72773E383
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

Hi,

Does anybody make the standard Linux kernel 2.4.4 working on the Malta
board?  I used Lineo Embedix SDK to built up kernel image based on the
kernel 2.4.4,  but system will be panic when it tries to install NFS
root directory.  I wonder if anybody has tested Linux kernel 2.4.4 on
the Malta board.

Thanx,

--Shuanglin





--------------58F88112601457E72773E383
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit



Hi,

Does anybody make the standard Linux kernel 2.4.4 working on the Malta
board?  I used Lineo Embedix SDK to built up kernel image based on
the kernel 2.4.4,  but system will be panic when it tries to install
NFS  root directory.  I wonder if anybody has tested Linux kernel
2.4.4 on the Malta board.

Thanx,

--Shuanglin

 

 

--------------58F88112601457E72773E383--


From owner-linux-mips@oss.sgi.com Fri Aug 17 13:51:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HKpuO12529
	for linux-mips-outgoing; Fri, 17 Aug 2001 13:51:56 -0700
Received: from mx.mips.com (mx.mips.com [206.31.31.226])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HKpoj12526
	for ; Fri, 17 Aug 2001 13:51:50 -0700
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA17656
	for ; Fri, 17 Aug 2001 13:51:42 -0700 (PDT)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA24823
	for ; Fri, 17 Aug 2001 13:51:39 -0700 (PDT)
Message-ID: <00b701c1275f$0c38a5e0$0deca8c0@Ulysses>
From: "Kevin D. Kissell" 
To: "MIPS/Linux List \(SGI\)" 
Subject: FP handling in signal.c and traps.c (was Re: FP Emulator Patch)
Date: Fri, 17 Aug 2001 22:56:02 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00B4_01C1276F.CA0590A0"
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: 8902
Lines: 237

This is a multi-part message in MIME format.

------=_NextPart_000_00B4_01C1276F.CA0590A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I attach a diff relative to the current OSS repository for a proposed
patch to fix the signal holes discussed over the past few days.
This *exact* patch has not been tested, since the sources are too
new to be compatible with any kernel that will read my accursed
hard drive, so you are taking your life in your hands with it, but
it is substantially similar to the version I posted yesterday that
worked perfectly - but had the conceptual hole if a signal
handler that acquired the FPU got switched out.   I've got
a plane to catch in the morning and can't spend any more
time on it, but it should at least give people something to
talk about - and something similar to it really should be
(IMHO) the correct approach.  It will slow down the signal
dispatch, without a doubt, but we should stop losing FP
state altogether.  I also fixed what looked to be a bug
in the handling of Hi and Lo in the sigcontext restore.
The code as written would certainly have worked in
big-endian code, but I believe that in little endian it could
have trashed both registers.

A note to Jun Sun about clearing the used_math flag
before launching a signal handler: consider what happens
to ptrace if the signal handler hits a breakpoint without
executing any FP instructions.  My code saves and
restores it with the sigcontext.  If the signal handler
acquires the FPU, but the application has not otherwise
used FP, it will be cleared as part of that restore.

I pass the torch, and hope for the best...

            Regards,

            Kevin K.


------=_NextPart_000_00B4_01C1276F.CA0590A0
Content-Type: application/octet-stream;
	name="cvsdiff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="cvsdiff"

? cvsdiff=0A=
? arch/mips/kernel/signal.c.diff=0A=
Index: arch/mips/kernel/signal.c=0A=
=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=0A=
RCS file: /cvs/linux/arch/mips/kernel/signal.c,v=0A=
retrieving revision 1.36=0A=
diff -u -p -r1.36 signal.c=0A=
--- arch/mips/kernel/signal.c	2001/06/18 22:43:35	1.36=0A=
+++ arch/mips/kernel/signal.c	2001/08/17 20:22:55=0A=
@@ -187,6 +187,47 @@ sys_sigaltstack(struct pt_regs regs)=0A=
 	return do_sigaltstack(uss, uoss, usp);=0A=
 }=0A=
 =0A=
+static void=0A=
+restore_thread_fp_context(struct sigcontext *sc)=0A=
+{=0A=
+	int i;=0A=
+	/* Note: This assumes that fpu.soft/fpu.hard union is isomorphic */	=0A=
+	u64 *pfreg =3D ¤t->thread.fpu.soft.regs[0];=0A=
+=0A=
+	/* =0A=
+	 * Copy all 32 64-bit values, for two reasons.=0A=
+	 * First, the R3000 and R4000/MIPS32 kernels use=0A=
+	 * the thread FP register storage differently,=0A=
+	 * such that a full copy is essentially necessary=0A=
+	 * to support both.  Someone obsessed with performance =0A=
+	 * could turn this into distinct routines in each=0A=
+	 * of the _fpu.S files.=0A=
+	 * =0A=
+	 */=0A=
+=0A=
+	for (i =3D 0; i < 32; i++ ) {=0A=
+		__get_user(pfreg[i], &sc->sc_fpregs[i]);=0A=
+	}=0A=
+	__get_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);=0A=
+}=0A=
+=0A=
+static void=0A=
+save_thread_fp_context(struct sigcontext *sc)=0A=
+{=0A=
+	int i;=0A=
+	/* Note: This assumes that fpu.soft/fpu.hard union is isomorphic */	=0A=
+	u64 *pfreg =3D ¤t->thread.fpu.soft.regs[0];=0A=
+=0A=
+	/* =0A=
+	 * See comment in restore_thread_fp_context()=0A=
+	 */=0A=
+=0A=
+	for (i =3D 0; i < 32; i++ ) {=0A=
+		__put_user(pfreg[i], &sc->sc_fpregs[i]);=0A=
+	}=0A=
+	__put_user(current->thread.fpu.soft.sr, &sc->sc_fpc_csr);=0A=
+}=0A=
+=0A=
 asmlinkage int=0A=
 restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)=0A=
 {=0A=
@@ -196,10 +237,8 @@ restore_sigcontext(struct pt_regs *regs,=0A=
 =0A=
 	err |=3D __get_user(regs->cp0_epc, &sc->sc_pc);=0A=
 =0A=
-	err |=3D __get_user(reg, &sc->sc_mdhi);=0A=
-	regs->hi =3D (int) reg;=0A=
-	err |=3D __get_user(reg, &sc->sc_mdlo);=0A=
-	regs->lo =3D (int) reg;=0A=
+	err |=3D __get_user(regs->hi, &sc->sc_mdhi);=0A=
+	err |=3D __get_user(regs->lo, &sc->sc_mdlo);=0A=
 =0A=
 #define restore_gp_reg(i) do {						\=0A=
 	err |=3D __get_user(reg, &sc->sc_regs[i]);			\=0A=
@@ -219,9 +258,20 @@ restore_sigcontext(struct pt_regs *regs,=0A=
 #undef restore_gp_reg=0A=
 =0A=
 	err |=3D __get_user(owned_fp, &sc->sc_ownedfp);=0A=
+	err |=3D __get_user(current->used_math, &sc->sc_used_math);=0A=
 	if (owned_fp) {=0A=
+		/* Can't tell if signal handler used FP, must restore */=0A=
 		err |=3D restore_fp_context(sc);=0A=
-		last_task_used_math =3D current;=0A=
+	} else {=0A=
+		if (current =3D=3D last_task_used_math) {=0A=
+		/* Signal handler acquired FPU - give it back */=0A=
+			last_task_used_math =3D NULL;=0A=
+			regs->cp0_status &=3D ~ST0_CU1;=0A=
+			if (current->used_math) {=0A=
+			/* Undo possible contamination of thread state */=0A=
+				restore_thread_fp_context(sc);=0A=
+			}=0A=
+		}=0A=
 	}=0A=
 =0A=
 	return err;=0A=
@@ -352,13 +402,20 @@ setup_sigcontext(struct pt_regs *regs, s=0A=
 =0A=
 	owned_fp =3D (current =3D=3D last_task_used_math);=0A=
 	err |=3D __put_user(owned_fp, &sc->sc_ownedfp);=0A=
+	err |=3D __put_user(current->used_math, &sc->sc_used_math);=0A=
 =0A=
-	if (current->used_math) {	/* fp is active.  */=0A=
-		set_cp0_status(ST0_CU1);=0A=
-		err |=3D save_fp_context(sc);=0A=
-		last_task_used_math =3D NULL;=0A=
-		regs->cp0_status &=3D ~ST0_CU1;=0A=
-		current->used_math =3D 0;=0A=
+	if (current->used_math) {=0A=
+	/* There exists FP thread state that may be trashed by signal */=0A=
+		if (owned_fp) {	=0A=
+		/* fp is active.  Save context from FPU */=0A=
+			err |=3D save_fp_context(sc);=0A=
+		} else {=0A=
+		/* =0A=
+		 * Someone else has FPU. =0A=
+		 * Copy Thread context into signal context =0A=
+		 */=0A=
+			save_thread_fp_context(sc);=0A=
+		}=0A=
 	}=0A=
 =0A=
 	return err;=0A=
@@ -374,6 +431,16 @@ get_sigframe(struct k_sigaction *ka, str=0A=
 =0A=
 	/* Default to using normal stack */=0A=
 	sp =3D regs->regs[29];=0A=
+=0A=
+#ifdef CONFIG_MIPS_FPU_EMULATOR=0A=
+	/*=0A=
+	 * FPU emulator may have it's own trampoline active just=0A=
+	 * above the user stack, 16-bytes before the next lowest=0A=
+	 * 16 byte boundary.  Try to avoid trashing it.=0A=
+	 */=0A=
+	sp -=3D 32;	/* 32 ought to be enough, but... */=0A=
+=0A=
+#endif /* CONFIG_MIPS_FPU_EMULATOR */=0A=
 =0A=
 	/* This is the X/Open sanctioned signal stack switching.  */=0A=
 	if ((ka->sa.sa_flags & SA_ONSTACK) && ! on_sig_stack(sp))=0A=
Index: arch/mips/kernel/traps.c=0A=
=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=0A=
RCS file: /cvs/linux/arch/mips/kernel/traps.c,v=0A=
retrieving revision 1.75=0A=
diff -u -p -r1.75 traps.c=0A=
--- arch/mips/kernel/traps.c	2001/08/02 21:58:46	1.75=0A=
+++ arch/mips/kernel/traps.c	2001/08/17 20:22:58=0A=
@@ -574,6 +574,7 @@ asmlinkage void do_cpu(struct pt_regs *r=0A=
 {=0A=
 	unsigned int cpid;=0A=
 	extern void lazy_fpu_switch(void *);=0A=
+	extern void save_fp(struct task_struct *);=0A=
 	extern void init_fpu(void);=0A=
 	void fpu_emulator_init_fpu(void);=0A=
 	int sig;=0A=
@@ -592,6 +593,7 @@ asmlinkage void do_cpu(struct pt_regs *r=0A=
 	if (current->used_math) {		/* Using the FPU again.  */=0A=
 		lazy_fpu_switch(last_task_used_math);=0A=
 	} else {				/* First time FPU user.  */=0A=
+		if (last_task_used_math !=3D NULL) save_fp(last_task_used_math);=0A=
 		init_fpu();=0A=
 		current->used_math =3D 1;=0A=
 	}=0A=
Index: include/asm-mips/sigcontext.h=0A=
=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=0A=
RCS file: /cvs/linux/include/asm-mips/sigcontext.h,v=0A=
retrieving revision 1.6=0A=
diff -u -p -r1.6 sigcontext.h=0A=
--- include/asm-mips/sigcontext.h	2000/03/27 23:02:57	1.6=0A=
+++ include/asm-mips/sigcontext.h	2001/08/17 20:23:00=0A=
@@ -18,10 +18,11 @@ struct sigcontext {=0A=
 	unsigned int       sc_status;=0A=
 	unsigned long long sc_pc;=0A=
 	unsigned long long sc_regs[32];=0A=
-	unsigned long long sc_fpregs[32];	/* Unused */=0A=
+	unsigned long long sc_fpregs[32];=0A=
 	unsigned int       sc_ownedfp;=0A=
-	unsigned int       sc_fpc_csr;		/* Unused */=0A=
+	unsigned int       sc_fpc_csr;=0A=
 	unsigned int       sc_fpc_eir;		/* Unused */=0A=
+	unsigned int       sc_used_math;=0A=
 	unsigned int       sc_ssflags;		/* Unused */=0A=
 	unsigned long long sc_mdhi;=0A=
 	unsigned long long sc_mdlo;=0A=

------=_NextPart_000_00B4_01C1276F.CA0590A0--


From owner-linux-mips@oss.sgi.com Fri Aug 17 14:32:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HLWJA13531
	for linux-mips-outgoing; Fri, 17 Aug 2001 14:32:19 -0700
Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HLWHj13528
	for ; Fri, 17 Aug 2001 14:32:17 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7HLavA20056;
	Fri, 17 Aug 2001 14:36:57 -0700
Message-ID: <3B7D8C06.D2DBC18C@mvista.com>
Date: Fri, 17 Aug 2001 14:26:30 -0700
From: Jun Sun 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hua Wen 
CC: linux-mips@oss.sgi.com
Subject: Re: Upgrade kernel from release 2.2 to 2.4.?
References:  <3B7D5513.F10F35A1@taec.com> <3B7D57E4.D7B14D63@mvista.com> <3B7D6E7B.9994255@taec.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1166
Lines: 43

Hua Wen wrote:
> 
> Thank you very much, Jun.
> 
> One more thing -- we've made quite some changes in
> 2.2.1 so I wonder what would be the best way to
> upgrade. I'm thinking:
> 
> 1> check out new kernel, use "merge directories"
> function from emacs, or
> 
> 2> use "cvs import" to import the new kernel to
> our local cvs repository, then merge with our
> local changes by "cvs update/co -j"..
> 
> Any comments/suggestions?
> 

Hmm, there is so much difference between 2.2.x and 2.4.x. I would think any
merging effort would be a nightmare.  Let alone later debugging effort.

The best thing is probably to extract what you *have* changed, and apply those
changes back to the current tree.

Jun

> Thanks!
> -Hua
> 
> > >
> > > We made changes to linux/MIPS kernel 2.2.1 for our
> > > system and it's been running well so far. We now
> > > plan to upgrade the kernel to 2.4.X. The question
> > > is:
> > >
> > > Which sub release of 2.4 is more stable and is
> > > recommended to use?
> > >
> >
> > I suggest you use the latest CVS head.  So far it is usually the head that has
> > the most bug fixes, and really not much dramatic stuff introduced.
> >
> > Jun

From owner-linux-mips@oss.sgi.com Fri Aug 17 16:07:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7HN7Ln15552
	for linux-mips-outgoing; Fri, 17 Aug 2001 16:07:21 -0700
Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7HN7Ij15546
	for ; Fri, 17 Aug 2001 16:07:18 -0700
Received: from pacbell.net ([63.194.214.47])
 by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GI8003UHIW4JX@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com;
 Fri, 17 Aug 2001 16:07:17 -0700 (PDT)
Date: Fri, 17 Aug 2001 16:07:15 -0700
From: Pete Popov 
Subject: latest au1000 updates
To: linux-mips-kernel@lists.sourceforge.net
Cc: linux-mips@oss.sgi.com
Reply-to: ppopov@pacbell.net
Message-id: <3B7DA3A3.8010000@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2010
Lines: 56

James,

I pushed the latest au1000 code. I had to add a new vec0 handler for the au1000 
in head.S, much like the other vec0 ones. I also checked in the vr41xx patch. 
Jun indicated that he and/or Ralf reworked some of the 41xx so the 41xx will 
probably have to be updated again, but at least the kernel compiles.


To compile the code right at this moment, you need to make this local change in 
kernel/Makefile:

[ppopov@zeus linux-dev]$ diff ../stock/kernel/Makefile  kernel/Makefile
14c14
< obj-y     = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
---
 > obj-y     = sched.o fork.o exec_domain.o panic.o printk.o \
17a18,21
 >
 > ifndef CONFIG_MIPS_AU1000
 > obj-y	 += dma.o
 > endif

and, this local change in drivers/net/Space.c:

diff ../stock/drivers/net/Space.c drivers/net/Space.c
103a104,105
 > extern int gt96100_probe(struct net_device *);
 > extern int au1000_probe(struct net_device *dev);
382a385,390
 > #endif
 > #ifdef CONFIG_MIPS_GT96100ETH
 > 	{gt96100_probe, 0},
 > #endif
 > #ifdef CONFIG_MIPS_AU1000_ENET
 > 	{au1000_probe, 0},


The Space.c patch really needs to go to Alan. I'll see if he'll take it. The 
kernel/Makefile patch probably needs to be reworked so that we don't have to 
touch kernel/Makefile.

I tested the kernel and it seems to work fine, so I think I got everything. 
However, I haven't tested the fb driver, pcmcia, usb, etc, etc with this kernel. 
Also, note that if anyone needs usb on this board or any other au1000 board, 
we'll need to send a local usb patch for non-pci devices. Steve already had most 
of his work accepted in the usb tree, but the non-pci patch wasn't accepted 
because the usb code is going through some reorg right now. So, without this usb 
patch which is only in the MontaVista tree at the moment, usb is not usable on 
this board.

There are Au1000 customers showing up all over the place, so having the latest 
code in sourceforge is a good thing.  Now I have to find the time to create a 
patch against the oss tree...

Pete


From owner-linux-mips@oss.sgi.com Fri Aug 17 20:25:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7I3P0J20911
	for linux-mips-outgoing; Fri, 17 Aug 2001 20:25:00 -0700
Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7I3Orj20846;
	Fri, 17 Aug 2001 20:24:54 -0700
Received: from prefect (gw1.ltc.com [38.149.17.163])
	by ns1.ltc.com (Postfix) with SMTP
	id CFE42590A9; Fri, 17 Aug 2001 23:21:16 -0400 (EDT)
Message-ID: <06eb01c12795$8b4bde20$3501010a@ltc.com>
From: "Bradley D. LaRonde" 
To: "Ralf Baechle" 
Cc: "Jun Sun" , 
Subject: PATCH: vrc5477 sound driver for-loop to udelay
Date: Fri, 17 Aug 2001 23:26:11 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1834
Lines: 59

2001-08-17 Bradley D. LaRonde 

* convert for-loop delay to udelay.  udelay is better since it is
MHz independent, but the real reason for this change is that gcc 3.0
didn't compile the for-loop as one might expect.

* eliminate unused variable warning


diff -u -B -b -r1.1 nec_vrc5477.c
--- drivers/sound/nec_vrc5477.c 2001/06/10 16:57:41 1.1
+++ drivers/sound/nec_vrc5477.c 2001/08/18 03:07:34
@@ -260,7 +260,6 @@
   (struct vrc5477_ac97_state *)codec->private_data;
  unsigned long flags;
  u32 result;
- int i;

  spin_lock_irqsave(&s->lock, flags);

@@ -272,7 +271,7 @@
  outl((addr << 16) | VRC5477_CODEC_WR_RWC, s->io + VRC5477_CODEC_WR);

  /* get the return result */
- for (i=10000; i; i--);  /* workaround hardware bug */
+ udelay(100); /* workaround hardware bug */
  while ( (result = inl(s->io + VRC5477_CODEC_RD)) &
                 (VRC5477_CODEC_RD_RRDYA | VRC5477_CODEC_RD_RRDYD) ) {
   /* we get either addr or data, or both */
@@ -1093,7 +1092,9 @@
         int totalCopyCount = 0;
         int totalCopyFragCount = 0;
         unsigned long flags;
+#if defined(VRC5477_AC97_VERBOSE_DEBUG)
  int i;
+#endif

         /* adjust count to signel channel byte count */
         count >>= s->dacChannels - 1;
@@ -1788,7 +1789,6 @@
 u16 myrdcodec(u8 addr)
 {
         u32 result;
-        u32 i;

         /* wait until we can access codec registers */
         // while (inl(VRC5477_CODEC_WR) & 0x80000000);
@@ -1798,7 +1798,7 @@
         myoutl((addr << 16) | VRC5477_CODEC_WR_RWC, VRC5477_CODEC_WR);

         /* get the return result */
-        for (i=10000; i; i--);
+        udelay(100); /* workaround hardware bug */
         // dump_memory(0xbb000000, 48);
         while ( ((result=myinl(VRC5477_CODEC_RD)) & 0xc0000000) !=
0xc0000000);
         MIPS_ASSERT(addr == ((result >> 16) & 0x7f) );



From owner-linux-mips@oss.sgi.com Mon Aug 20 02:53:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7K9rB612337
	for linux-mips-outgoing; Mon, 20 Aug 2001 02:53:11 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7K9r4j12331
	for ; Mon, 20 Aug 2001 02:53:06 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GID20P00.OEC for ; Mon, 20 Aug 2001
          17:50:49 +0800 
Message-ID: <000b01c1295e$0f2174c0$8021690a@huawei.com>
From: "machael thailer" 
Cc: 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org>
Subject: questions about eret....
Date: Mon, 20 Aug 2001 17:54:09 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 174
Lines: 11

Hello,all:

    I have a question to ask about eret.

    In RC4xxx/RC32334, after eret finished, does it automatically enable IE
bit of STATUS register?

Machael thailer




From owner-linux-mips@oss.sgi.com Mon Aug 20 06:56:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7KDuO719688
	for linux-mips-outgoing; Mon, 20 Aug 2001 06:56:24 -0700
Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KDtuj19678
	for ; Mon, 20 Aug 2001 06:55:57 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11015;
	Mon, 20 Aug 2001 15:57:21 +0200 (MET DST)
Date: Mon, 20 Aug 2001 15:57:21 +0200 (MET DST)
From: "Maciej W. Rozycki" 
Reply-To: "Maciej W. Rozycki" 
To: Ralf Baechle , Keith Owens 
cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: [patch] linux 2.4.5: __dbe_table iteration #2
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: 19265
Lines: 544

Hi,

 After a bit of work, I have implemented all the suggestions.  The
following changes have been made to the previous version: 

- default_be_board_handler() in traps.c (mips) only searches __dbe_table
for DBE faults and not IBE ones,

- search_dbe_table() in ip2[27]-berr.c (mips64) is modified to work
similarly to the traps.c (mips) one,

- init_modules() now calls platform-specific arch_init_modules(),

- module_arch_init() and arch_init_modules() are implemented for alpha
(moving the conditional stuff from module.c), mips and mips64.

The patch follows.  It has been rougly tested on mips and has proved to be
harmless on i386 as well.  The alpha and mips64 changes have not been
tested.  I haven't modified DBE handlers for mips64 to make them work like
the mips version since they don't return at all anyway.

 If we agree on the patch I'm going to submit it to mainline since it's
not MIPS-specific anymore.  The patch applies cleanly to 2.4.9. 

  Maciej

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

patch-mips-2.4.5-20010704-dbe-11
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c
--- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c	Fri Jun 15 04:27:07 2001
+++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c	Mon Aug 20 13:38:05 2001
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -254,23 +256,67 @@ search_one_table(const struct exception_
 	return (first == last && first->insn == value) ? first->nextinsn : 0;
 }
 
-#define search_dbe_table(addr)	\
-	search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr))
+extern spinlock_t modlist_lock;
+
+static inline unsigned long
+search_dbe_table(unsigned long addr)
+{
+	unsigned long ret = 0;
+
+#ifndef CONFIG_MODULES
+	/* There is only the kernel to search.  */
+	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_start) ||
+		    !mp->archdata_start)
+			continue;
+		ap = (struct archdata *)(mp->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
+}
 
 static void default_be_board_handler(struct pt_regs *regs)
 {
 	unsigned long new_epc;
-	unsigned long fixup = search_dbe_table(regs->cp0_epc);
+	unsigned long fixup;
+	int data = regs->cp0_cause & 4;
 
-	if (fixup) {
-		new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc);
-		regs->cp0_epc = new_epc;
-		return;
+	if (data && !user_mode(regs)) {
+		fixup = search_dbe_table(regs->cp0_epc);
+		if (fixup) {
+			new_epc = fixup_exception(dpf_reg, fixup,
+						  regs->cp0_epc);
+			regs->cp0_epc = new_epc;
+			return;
+		}
 	}
 
 	/*
 	 * Assume it would be too dangerous to continue ...
 	 */
+	printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n",
+	       data ? "Data" : "Instruction",
+	       regs->cp0_epc, regs->regs[31]);
+	die_if_kernel("Oops", regs);
 	force_sig(SIGBUS, current);
 }
 
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c
--- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c	Thu Feb 24 05:26:11 2000
+++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c	Mon Aug 20 00:25:46 2001
@@ -9,6 +9,9 @@
  */
 #include 
 #include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -41,16 +44,42 @@ search_one_table(const struct exception_
 	return 0;
 }
 
+extern spinlock_t modlist_lock;
+
 static inline unsigned long
 search_dbe_table(unsigned long addr)
 {
-	unsigned long ret;
+	unsigned long ret = 0;
 
+#ifndef CONFIG_MODULES
 	/* There is only the kernel to search.  */
 	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
-	if (ret) return ret;
-
-	return 0;
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_start) ||
+		    !mp->archdata_start)
+			continue;
+		ap = (struct archdata *)(mod->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
 }
 
 void do_ibe(struct pt_regs *regs)
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c
--- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c	Sat Feb 24 05:26:18 2001
+++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c	Mon Aug 20 13:39:45 2001
@@ -8,6 +8,9 @@
  */
 #include 
 #include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -43,16 +46,42 @@ search_one_table(const struct exception_
 	return 0;
 }
 
+extern spinlock_t modlist_lock;
+
 static inline unsigned long
 search_dbe_table(unsigned long addr)
 {
 	unsigned long ret;
 
+#ifndef CONFIG_MODULES
 	/* There is only the kernel to search.  */
 	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
-	if (ret) return ret;
-
-	return 0;
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_start) ||
+		    !mp->archdata_start)
+			continue;
+		ap = (struct archdata *)(mod->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
 }
 
 void do_ibe(struct pt_regs *regs)
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h linux-mips-2.4.5-20010704/include/asm-alpha/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-alpha/module.h	Sun Aug 19 20:07:45 2001
@@ -6,6 +6,23 @@
 
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	alpha_module_init(x)
+#define arch_init_modules(x)	alpha_init_modules(x)
+
+static inline int
+alpha_module_init(struct module *mod)
+{
+        if (!mod_bound(mod->gp - 0x8000, 0, mod)) {
+                printk(KERN_ERR "arch_init_module: mod->gp out of bounds.\n");
+                return 1;
+        }
+	return 0;
+}
+
+static inline void
+alpha_init_modules(struct module *mod)
+{
+	__asm__("stq $29,%0" : "=m" (mod->gp));
+}
 
 #endif /* _ASM_ALPHA_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h linux-mips-2.4.5-20010704/include/asm-arm/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-arm/module.h	Mon Aug 20 01:11:58 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_ARM_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h linux-mips-2.4.5-20010704/include/asm-cris/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h	Fri Mar  9 20:34:43 2001
+++ linux-mips-2.4.5-20010704/include/asm-cris/module.h	Mon Aug 20 01:12:04 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_CRIS_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h linux-mips-2.4.5-20010704/include/asm-i386/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-i386/module.h	Mon Aug 20 01:12:08 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_I386_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h linux-mips-2.4.5-20010704/include/asm-ia64/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h	Thu Jun 14 04:28:30 2001
+++ linux-mips-2.4.5-20010704/include/asm-ia64/module.h	Mon Aug 20 01:12:14 2001
@@ -14,6 +14,7 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		ia64_module_unmap(x)
 #define module_arch_init(x)	ia64_module_init(x)
+#define arch_init_modules(x)	do { } while (0)
 
 /*
  * This must match in size and layout the data created by
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h linux-mips-2.4.5-20010704/include/asm-m68k/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-m68k/module.h	Mon Aug 20 01:12:18 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_M68K_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h linux-mips-2.4.5-20010704/include/asm-mips/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-mips/module.h	Mon Aug 20 00:18:19 2001
@@ -4,8 +4,61 @@
  * This file contains the mips architecture specific module code.
  */
 
+#include 
+#include 
+
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	mips_module_init(x)
+#define arch_init_modules(x)	mips_init_modules(x)
+
+/*
+ * This must match in size and layout the data created by
+ * modutils/obj/obj-mips.c
+ */
+struct archdata {
+	const struct exception_table_entry *dbe_table_start;
+	const struct exception_table_entry *dbe_table_end;
+};
+
+static inline int
+mips_module_init(struct module *mod)
+{
+	struct archdata *archdata;
+
+	if (!mod_member_present(mod, archdata_start) || !mod->archdata_start)
+		return 0;
+	archdata = (struct archdata *)(mod->archdata_start);
+
+	if (archdata->dbe_table_start > archdata->dbe_table_end ||
+	    (archdata->dbe_table_start &&
+	     !((unsigned long)archdata->dbe_table_start >=
+	       ((unsigned long)mod + mod->size_of_struct) &&
+	       ((unsigned long)archdata->dbe_table_end <
+	        (unsigned long)mod + mod->size))) ||
+            (((unsigned long)archdata->dbe_table_start -
+	      (unsigned long)archdata->dbe_table_end) %
+	     sizeof(struct exception_table_entry))) {
+		printk(KERN_ERR
+			"arch_init_module: archdata->dbe_table_* invalid.\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+static inline void
+mips_init_modules(struct module *mod)
+{
+	extern const struct exception_table_entry __start___dbe_table[];
+	extern const struct exception_table_entry __stop___dbe_table[];
+	static struct archdata archdata = {
+		dbe_table_start:	__start___dbe_table,
+		dbe_table_end:		__stop___dbe_table,
+	};
+
+	mod->archdata_start = (char *)&archdata;
+	mod->archdata_end = mod->archdata_start + sizeof(archdata);
+}
 
 #endif /* _ASM_MIPS_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h linux-mips-2.4.5-20010704/include/asm-mips64/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-mips64/module.h	Mon Aug 20 00:18:32 2001
@@ -4,8 +4,61 @@
  * This file contains the mips64 architecture specific module code.
  */
 
+#include 
+#include 
+
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	mips64_module_init(x)
+#define arch_init_modules(x)	mips64_init_modules(x)
+
+/*
+ * This must match in size and layout the data created by
+ * modutils/obj/obj-mips64.c
+ */
+struct archdata {
+	const struct exception_table_entry *dbe_table_start;
+	const struct exception_table_entry *dbe_table_end;
+};
+
+static inline int
+mips64_module_init(struct module *mod)
+{
+	struct archdata *archdata;
+
+	if (!mod_member_present(mod, archdata_start) || !mod->archdata_start)
+		return 0;
+	archdata = (struct archdata *)(mod->archdata_start);
+
+	if (archdata->dbe_table_start > archdata->dbe_table_end ||
+	    (archdata->dbe_table_start &&
+	     !((unsigned long)archdata->dbe_table_start >=
+	       ((unsigned long)mod + mod->size_of_struct) &&
+	       ((unsigned long)archdata->dbe_table_end <
+	        (unsigned long)mod + mod->size))) ||
+            (((unsigned long)archdata->dbe_table_start -
+	      (unsigned long)archdata->dbe_table_end) %
+	     sizeof(struct exception_table_entry))) {
+		printk(KERN_ERR
+			"arch_init_module: archdata->dbe_table_* invalid.\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+static inline void
+mips64_init_modules(struct module *mod)
+{
+	extern const struct exception_table_entry __start___dbe_table[];
+	extern const struct exception_table_entry __stop___dbe_table[];
+	static struct archdata archdata = {
+		dbe_table_start:	__start___dbe_table,
+		dbe_table_end:		__stop___dbe_table,
+	};
+
+	mod->archdata_start = (char *)&archdata;
+	mod->archdata_end = mod->archdata_start + sizeof(archdata);
+}
 
 #endif /* _ASM_MIPS64_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h linux-mips-2.4.5-20010704/include/asm-ppc/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h	Thu Jun 14 04:28:38 2001
+++ linux-mips-2.4.5-20010704/include/asm-ppc/module.h	Mon Aug 20 01:12:29 2001
@@ -10,5 +10,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_PPC_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h linux-mips-2.4.5-20010704/include/asm-s390/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-s390/module.h	Mon Aug 20 01:12:37 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_S390_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h linux-mips-2.4.5-20010704/include/asm-s390x/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h	Fri Mar  9 20:34:52 2001
+++ linux-mips-2.4.5-20010704/include/asm-s390x/module.h	Mon Aug 20 01:12:53 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_S390_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h linux-mips-2.4.5-20010704/include/asm-sh/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-sh/module.h	Mon Aug 20 01:12:58 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_SH_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h linux-mips-2.4.5-20010704/include/asm-sparc/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-sparc/module.h	Mon Aug 20 01:13:03 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_SPARC_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h linux-mips-2.4.5-20010704/include/asm-sparc64/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-sparc64/module.h	Mon Aug 20 01:13:19 2001
@@ -7,5 +7,6 @@
 extern void * module_map (unsigned long size);
 extern void module_unmap (void *addr);
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_SPARC64_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/kernel/module.c linux-mips-2.4.5-20010704/kernel/module.c
--- linux-mips-2.4.5-20010704.macro/kernel/module.c	Thu Jun 14 04:28:48 2001
+++ linux-mips-2.4.5-20010704/kernel/module.c	Sun Aug 19 20:10:35 2001
@@ -246,9 +246,7 @@ void __init init_modules(void)
 {
 	kernel_module.nsyms = __stop___ksymtab - __start___ksymtab;
 
-#ifdef __alpha__
-	__asm__("stq $29,%0" : "=m"(kernel_module.gp));
-#endif
+	arch_init_modules(&kernel_module);
 }
 
 /*
@@ -440,12 +438,6 @@ sys_init_module(const char *name_user, s
 		printk(KERN_ERR "init_module: mod->flags invalid.\n");
 		goto err2;
 	}
-#ifdef __alpha__
-	if (!mod_bound(mod->gp - 0x8000, 0, mod)) {
-		printk(KERN_ERR "init_module: mod->gp out of bounds.\n");
-		goto err2;
-	}
-#endif
 	if (mod_member_present(mod, can_unload)
 	    && mod->can_unload && !mod_bound(mod->can_unload, 0, mod)) {
 		printk(KERN_ERR "init_module: mod->can_unload out of bounds.\n");


From owner-linux-mips@oss.sgi.com Mon Aug 20 07:02:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7KE2cu19922
	for linux-mips-outgoing; Mon, 20 Aug 2001 07:02:38 -0700
Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KE2Yj19919
	for ; Mon, 20 Aug 2001 07:02:35 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA11482;
	Mon, 20 Aug 2001 16:04:18 +0200 (MET DST)
Date: Mon, 20 Aug 2001 16:04:18 +0200 (MET DST)
From: "Maciej W. Rozycki" 
To: Keith Owens , Ralf Baechle 
cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: [patch] modutils 2.4.6: __dbe_table iteration #2
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: 1379
Lines: 45

Hi,

 Following is a modutils patch that complements __dbe_table handling for
modules for mips.

  Maciej

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

modutils-2.4.6-mips-dbe.patch
diff -up --recursive --new-file modutils-2.4.6.macro/obj/obj_mips.c modutils-2.4.6/obj/obj_mips.c
--- modutils-2.4.6.macro/obj/obj_mips.c	Fri Jan  5 01:45:19 2001
+++ modutils-2.4.6/obj/obj_mips.c	Mon Aug 20 03:47:36 2001
@@ -232,7 +232,26 @@ arch_finalize_section_address(struct obj
 }
 
 int
-arch_archdata (struct obj_file *fin, struct obj_section *sec)
+arch_archdata (struct obj_file *f, struct obj_section *archdata_sec)
 {
+  struct archdata {
+    unsigned tgt_long dbe_table_start;
+    unsigned tgt_long dbe_table_end;
+  } *ad;
+  struct obj_section *sec;
+
+  free(archdata_sec->contents);
+  archdata_sec->contents = xmalloc(sizeof(struct archdata));
+  memset(archdata_sec->contents, 0, sizeof(struct archdata));
+  archdata_sec->header.sh_size = sizeof(struct archdata);
+
+  ad = (struct archdata *)(archdata_sec->contents);
+
+  sec = obj_find_section(f, "__dbe_table");
+  if (sec) {
+    ad->dbe_table_start = sec->header.sh_addr;
+    ad->dbe_table_end = sec->header.sh_addr + sec->header.sh_size;
+  }
+
   return 0;
 }


From owner-linux-mips@oss.sgi.com Mon Aug 20 12:46:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7KJk0E29298
	for linux-mips-outgoing; Mon, 20 Aug 2001 12:46:00 -0700
Received: from smtp (smtp.psdc.com [209.125.203.83])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KJjt929295
	for ; Mon, 20 Aug 2001 12:45:55 -0700
Received: from ex2k.pcs.psdc.com ([172.19.1.1])
 by smtp (NAVIEG 2.1 bld 63) with SMTP id M2001082012464116031
 for ; Mon, 20 Aug 2001 12:46:41 -0700
content-class: urn:content-classes:message
Subject: The printf() function in libc of glibc-2.0.6 can print nothing.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Date: Mon, 20 Aug 2001 12:43:23 -0700
Message-ID: <84CE342693F11946B9F54B18C1AB837B0A254B@ex2k.pcs.psdc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The printf() function in libc of glibc-2.0.6 can print nothing.
Thread-Index: AcEpsF7MA2c/rm7GQwGSJUOMbvImuQ==
From: "Steven Liu" 
To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7KJju929296
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2362
Lines: 106

Hi, ALL:

I have successfully built linux kernel 2.2.12 on mips and glibc-2.0.6
with the following steps and options: 

Under glibc-2.0.6/build, run

CFLAGS="-mips2 -mcpu=r6000 -mmemcpy -O2 -D__MIPSEB__ " CC=mips-linux-gcc
BUILD_CC=gcc AR=mips-linux-ar RANLIB=mips-linux-ranlib ../configure
--prefix=/usr --host=mips-linux
--enable-add-ons=crypt,linuxthreads,localedata --disable-profile
--with-headers=/home/wenbo/linux/include

In file config.make, change CC = gcc into CC = mips-linux-gcc.

Then run make.

The build looks OK.

I also built an aplication as following:

liu.c:

#include 

void main()
{
  printf("My program is running\n");
}

Makefile:

ARCH = mips

.EXPORT_ALL_VARIABLES:


CROSS_COMPILE 	=mips-linux-

AS	=$(CROSS_COMPILE)as
LD	=$(CROSS_COMPILE)ld
CC	=$(CROSS_COMPILE)gcc  -D__mips__
-I/home/sliu/mips_lib/usr/include  
CPP	=$(CC) -E
AR	=$(CROSS_COMPILE)ar
NM	=$(CROSS_COMPILE)nm
STRIP	=$(CROSS_COMPILE)strip
OBJCOPY	=$(CROSS_COMPILE)objcopy
OBJDUMP	=$(CROSS_COMPILE)objdump
MAKE	=make
GENKSYMS=/sbin/genksyms

LINKFLAGS = -static
LIBS =/home/sliu/mips_lib/usr/lib/libc.a
CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mips2
-mcpu=r6000 -mmemcpy
#CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer  -mmemcpy

# use '-fno-strict-aliasing', but only if the compiler can take it
CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc
/dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)

# egcs-1.0.2 compiler for MIPS has a problem for which this is a
work-around
CFLAGS += $(shell if $(CC) -mno-split-addresses -S -o /dev/null -xc
/dev/null >/dev/null 2>&1; then echo "-mno-split-addresses"; fi)



.S.s:
	$(CC) -D__ASSEMBLY__  -traditional -E -o $*.s $<
.S.o:
	$(CC) -D__ASSEMBLY__  -traditional -c -o $*.o $<



liu: $(CONFIGURATION) liu.o
	$(LD) $(LINKFLAGS) $(HEAD) liu.o  \
          $(LIBS)  \
	  -o liu
	$(NM) liu | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map


liu.o: liu.c 
	$(CC) $(CFLAGS) $(PROFILING) -c -o $*.o $<

clean:
	rm -f *.o liu



------------------------------------------------------ Problem
-----------------------------------------------------------

The printf could not print the string "My program is running" on the
screen.

Any suggessions are greatly appreciated.

Regards and thanks.


Steven Liu



From owner-linux-mips@oss.sgi.com Mon Aug 20 14:10:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7KLAKd31098
	for linux-mips-outgoing; Mon, 20 Aug 2001 14:10:20 -0700
Received: from dea.linux-mips.net (u-145-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.145])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7KLAH931090
	for ; Mon, 20 Aug 2001 14:10:17 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7KL7tt11340;
	Mon, 20 Aug 2001 23:07:55 +0200
Date: Mon, 20 Aug 2001 23:07:55 +0200
From: Ralf Baechle 
To: machael thailer 
Cc: linux-mips@oss.sgi.com
Subject: Re: questions about eret....
Message-ID: <20010820230755.A11242@dea.linux-mips.net>
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@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: <000b01c1295e$0f2174c0$8021690a@huawei.com>; from dony.he@huawei.com on Mon, Aug 20, 2001 at 05:54:09PM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 274
Lines: 10

On Mon, Aug 20, 2001 at 05:54:09PM +0800, machael thailer wrote:

>     I have a question to ask about eret.
> 
>     In RC4xxx/RC32334, after eret finished, does it automatically enable IE
> bit of STATUS register?

ERET does not influence the state of the IE bit.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Aug 20 18:05:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7L15ac03684
	for linux-mips-outgoing; Mon, 20 Aug 2001 18:05:36 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L15V903681;
	Mon, 20 Aug 2001 18:05:31 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GIE89N00.C2E; Tue, 21 Aug 2001 09:03:23 +0800 
Message-ID: <001501c129dd$8acebb80$8021690a@huawei.com>
From: "machael thailer" 
To: "Ralf Baechle" 
Cc: 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net>
Subject: Re: questions about eret....
Date: Tue, 21 Aug 2001 09:06:43 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 679
Lines: 26


----- Original Message -----
From: "Ralf Baechle" 
To: "machael thailer" 
Cc: 
Sent: Tuesday, August 21, 2001 5:07 AM
Subject: Re: questions about eret....


> On Mon, Aug 20, 2001 at 05:54:09PM +0800, machael thailer wrote:
>
> >     I have a question to ask about eret.
> >
> >     In RC4xxx/RC32334, after eret finished, does it automatically enable
IE
> > bit of STATUS register?
>
> ERET does not influence the state of the IE bit.

I agree with you, but the RC32334 User manual (14-13 section) say  it does
and say we must run a "CLI" just before eret to disable IE bit in Status
register .

machael thailer



From owner-linux-mips@oss.sgi.com Mon Aug 20 18:32:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7L1WqB04409
	for linux-mips-outgoing; Mon, 20 Aug 2001 18:32:52 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L1Wl904406;
	Mon, 20 Aug 2001 18:32:48 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GIE9J400.93L; Tue, 21 Aug 2001 09:30:40 +0800 
Message-ID: <001901c129e1$5aaaadc0$8021690a@huawei.com>
From: "machael thailer" 
To: "Ralf Baechle" 
Cc: 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net>
Subject: questions about some bits of STATUS register and exception priority...
Date: Tue, 21 Aug 2001 09:34:00 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1357
Lines: 35

hello:

    I am confused about CU0 and UM(ERL EXL) bit of STATUS register.

    The user manual says that " CP0 is always usable when in Kernel mode,
regardless of the setting of CU0 bit". Does it mean that when in Kernel mode
, the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0 is
0, can we be sure that it is in User mode?

     If a user program is running in User mode, an interrupt happens at this
time(or an error occurs), then it will switch to Kernel mode to run the
interrupt handler(or the error exception handler). We know that the EXL(or
ERL) bit of Status register will be set to 1 by hardware. What about the UM
bit of Status? Does it remain unchangeable or change to 1 too? The user
manual doesn't say anything about it.


Another question about exception priority:
In entry.S, some exception handlers enables global interrupt bit(IE) but
others disables it.
Also syscall exception handler enables global interrupt bit(IE). Since the
interrupt priority  is lowest,If an interrupt happens in a syscall exception
handler, will it pause the syscall exception handler and run the interrupt
handler? If not, why it enable the IE bit(STI) in the syscall exception
handler??

If two interrupts happens at the same time, how can we decide the larger
priority interrupt and run its ISR?

Thank you very much.

machael thailer




From owner-linux-mips@oss.sgi.com Mon Aug 20 20:26:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7L3Qjc06446
	for linux-mips-outgoing; Mon, 20 Aug 2001 20:26:45 -0700
Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L3Qf906442
	for ; Mon, 20 Aug 2001 20:26:41 -0700
Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Aug 2001 03:26:41 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP
	id 21E4D54C0E; Tue, 21 Aug 2001 12:26:39 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id MAA83905; Tue, 21 Aug 2001 12:26:38 +0900 (JST)
Date: Tue, 21 Aug 2001 12:31:13 +0900 (JST)
Message-Id: <20010821.123113.25481933.nemoto@toshiba-tops.co.jp>
To: kevink@mips.com
Cc: linux-mips@oss.sgi.com
Subject: Re: FP handling in signal.c and traps.c
From: Atsushi Nemoto 
In-Reply-To: <00b701c1275f$0c38a5e0$0deca8c0@Ulysses>
References: <00b701c1275f$0c38a5e0$0deca8c0@Ulysses>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
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: 1583
Lines: 53

>>>>> On Fri, 17 Aug 2001 22:56:02 +0200, "Kevin D. Kissell"  said:
kevink> I attach a diff relative to the current OSS repository for a
kevink> proposed patch to fix the signal holes discussed over the past
kevink> few days.

Thanks for your patch.  I tried this patch and it seems to work fine,
but I think still there is a hole in it.

After patching it, codes in restore_sigcontext becomes:

	if (owned_fp) {
		/* Can't tell if signal handler used FP, must restore */
		err |= restore_fp_context(sc);
	} else {
		if (current == last_task_used_math) {
		/* Signal handler acquired FPU - give it back */
			last_task_used_math = NULL;
			regs->cp0_status &= ~ST0_CU1;
			if (current->used_math) {
			/* Undo possible contamination of thread state */
				restore_thread_fp_context(sc);
			}
		}
	}

But this should be:

	if (owned_fp) {
		/* Can't tell if signal handler used FP, must restore */
		err |= restore_fp_context(sc);
	} else {
		if (current == last_task_used_math) {
		/* Signal handler acquired FPU - give it back */
			last_task_used_math = NULL;
			regs->cp0_status &= ~ST0_CU1;
		}
		if (current->used_math) {
			/* Undo possible contamination of thread state */
			restore_thread_fp_context(sc);
		}
	}

This change fix a hole in case that:

- The signaled thread used the FPU but not owns it.
- and context switch occur in the signal handler.
- and other thread takes the FPU (the signal handler loses the FPU).

In this case, last_task_used_math is not current at
restore_sigcontext, but we must restore the saved fp context.

---
Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Tue Aug 21 00:39:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7L7dMw12447
	for linux-mips-outgoing; Tue, 21 Aug 2001 00:39:22 -0700
Received: from dea.linux-mips.net (u-32-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.32])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L7dF912441
	for ; Tue, 21 Aug 2001 00:39:15 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7L6Z8m13437;
	Tue, 21 Aug 2001 08:35:08 +0200
Date: Tue, 21 Aug 2001 08:35:08 +0200
From: Ralf Baechle 
To: machael thailer 
Cc: linux-mips@oss.sgi.com
Subject: Re: questions about eret....
Message-ID: <20010821083508.A13302@dea.linux-mips.net>
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@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: <001501c129dd$8acebb80$8021690a@huawei.com>; from dony.he@huawei.com on Tue, Aug 21, 2001 at 09:06:43AM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 660
Lines: 19

On Tue, Aug 21, 2001 at 09:06:43AM +0800, machael thailer wrote:

> > >     I have a question to ask about eret.
> > >
> > >     In RC4xxx/RC32334, after eret finished, does it automatically enable
> IE
> > > bit of STATUS register?
> >
> > ERET does not influence the state of the IE bit.
> 
> I agree with you, but the RC32334 User manual (14-13 section) say  it does
> and say we must run a "CLI" just before eret to disable IE bit in Status
> register .

That has a different reason.  Eret takes the return address from the
EPC register and if you'd take an exception between restoring that and the
eret you'd loose it's content - crash boom bang.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Aug 21 01:02:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7L82nX13184
	for linux-mips-outgoing; Tue, 21 Aug 2001 01:02:49 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7L82k913181
	for ; Tue, 21 Aug 2001 01:02:46 -0700
Received: from dea.linux-mips.net (u-32-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.32]) 
	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 BAA00081
	for ; Tue, 21 Aug 2001 01:01:17 -0700 (PDT)
	mail_from (ralf@linux-mips.net)
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7L6rrf13491;
	Tue, 21 Aug 2001 08:53:53 +0200
Date: Tue, 21 Aug 2001 08:53:53 +0200
From: Ralf Baechle 
To: machael thailer 
Cc: linux-mips@oss.sgi.com
Subject: Re: questions about some bits of STATUS register and exception priority...
Message-ID: <20010821085353.B13302@dea.linux-mips.net>
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001901c129e1$5aaaadc0$8021690a@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: <001901c129e1$5aaaadc0$8021690a@huawei.com>; from dony.he@huawei.com on Tue, Aug 21, 2001 at 09:34:00AM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1843
Lines: 42

On Tue, Aug 21, 2001 at 09:34:00AM +0800, machael thailer wrote:

>     I am confused about CU0 and UM(ERL EXL) bit of STATUS register.
> 
>     The user manual says that " CP0 is always usable when in Kernel mode,
> regardless of the setting of CU0 bit". Does it mean that when in Kernel mode
> , the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0 is
> 0, can we be sure that it is in User mode?

In the Linux kernel CU0 is used to indicate that we're running on the
kernel stack.

>      If a user program is running in User mode, an interrupt happens at this
> time(or an error occurs), then it will switch to Kernel mode to run the
> interrupt handler(or the error exception handler). We know that the EXL(or
> ERL) bit of Status register will be set to 1 by hardware. What about the UM
> bit of Status? Does it remain unchangeable or change to 1 too? The user
> manual doesn't say anything about it.

The hardware does not change UM (r4k: KSU bits).

> Another question about exception priority:
> In entry.S, some exception handlers enables global interrupt bit(IE) but
> others disables it.

We have to avoid infinite recursion of exceptions; in same cases it's
just paranoia or minor performance issue.

> Also syscall exception handler enables global interrupt bit(IE). Since the
> interrupt priority  is lowest,If an interrupt happens in a syscall exception
> handler, will it pause the syscall exception handler and run the interrupt
> handler? If not, why it enable the IE bit(STI) in the syscall exception
> handler??
> 
> If two interrupts happens at the same time, how can we decide the larger
> priority interrupt and run its ISR?

That's the decission of implementor of the respective board.  No strict
rules here; in general we priorize the timer interrupt highest but that's
no longer mandatory.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Aug 21 03:08:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LA8FG15766
	for linux-mips-outgoing; Tue, 21 Aug 2001 03:08:15 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LA8B915763;
	Tue, 21 Aug 2001 03:08:11 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GIEXE100.2CK; Tue, 21 Aug 2001 18:06:01 +0800 
Message-ID: <001201c12a29$57f3b660$8021690a@huawei.com>
From: "machael thailer" 
To: "Ralf Baechle" 
Cc: 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net>
Subject: Re: questions about eret....
Date: Tue, 21 Aug 2001 18:09:19 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1176
Lines: 32


>
> > > >     I have a question to ask about eret.
> > > >
> > > >     In RC4xxx/RC32334, after eret finished, does it automatically
enable
> > IE
> > > > bit of STATUS register?
> > >
> > > ERET does not influence the state of the IE bit.
> >
> > I agree with you, but the RC32334 User manual (14-13 section) say  it
does
> > and say we must run a "CLI" just before eret to disable IE bit in Status
> > register .
>
> That has a different reason.  Eret takes the return address from the
> EPC register and if you'd take an exception between restoring that and the
> eret you'd loose it's content - crash boom bang.

Yes.
But in the sourece codes, when we finish the exception handlers , we will
run "ret_from_irq" (ret_from_sys_call) in the entry.S and then run macro
"RESTORE_ALL_AND_RET".  The macro does restore all registers and then ERET.
But there is not a "CLI" just before ERET as the user manual suggested. Why?
so when we handle a syscall exception, we do "STI" in the handle_sys(). and
when ret_from_sys_call and we will run this macro "RESTORE_ALL_AND_RET".
because there is not a "CLI" just before ERET , is it possible to have some
problems?

machael thailer


From owner-linux-mips@oss.sgi.com Tue Aug 21 03:52:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LAqSZ16592
	for linux-mips-outgoing; Tue, 21 Aug 2001 03:52:28 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LAqM916586;
	Tue, 21 Aug 2001 03:52:23 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GIEZFR00.GCG; Tue, 21 Aug 2001 18:50:15 +0800 
Message-ID: <001901c12a2f$8626be00$8021690a@huawei.com>
From: "machael thailer" 
To: "Ralf Baechle" 
Cc: 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001901c129e1$5aaaadc0$8021690a@huawei.com> <20010821085353.B13302@dea.linux-mips.net>
Subject: Re: questions about some bits of STATUS register and exception priority...
Date: Tue, 21 Aug 2001 18:53:34 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1297
Lines: 41

> On Tue, Aug 21, 2001 at 09:34:00AM +0800, machael thailer wrote:
>
> >     I am confused about CU0 and UM(ERL EXL) bit of STATUS register.
> >
> >     The user manual says that " CP0 is always usable when in Kernel
mode,
> > regardless of the setting of CU0 bit". Does it mean that when in Kernel
mode
> > , the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0
is
> > 0, can we be sure that it is in User mode?
>
> In the Linux kernel CU0 is used to indicate that we're running on the
> kernel stack.

Yes, when CU0 is 1, we can see we are running on the kernel stack.
But when CU0 is 0, can we say it is in User mode?

>
> > Another question about exception priority:
> > In entry.S, some exception handlers enables global interrupt bit(IE) but
> > others disables it.
>
> We have to avoid infinite recursion of exceptions; in same cases it's
> just paranoia or minor performance issue.
>
> > Also syscall exception handler enables global interrupt bit(IE). Since
the
> > interrupt priority  is lowest,If an interrupt happens in a syscall
exception
> > handler, will it pause the syscall exception handler and run the
interrupt
> > handler? If not, why it enable the IE bit(STI) in the syscall exception
> > handler??


The answer of this question? Thanks.

machael thailer



From owner-linux-mips@oss.sgi.com Tue Aug 21 04:16:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LBGq817443
	for linux-mips-outgoing; Tue, 21 Aug 2001 04:16:52 -0700
Received: from dea.linux-mips.net (u-137-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.137])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LBGh917435
	for ; Tue, 21 Aug 2001 04:16:48 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7LBEG314545;
	Tue, 21 Aug 2001 13:14:16 +0200
Date: Tue, 21 Aug 2001 13:14:16 +0200
From: Ralf Baechle 
To: machael thailer 
Cc: linux-mips@oss.sgi.com
Subject: Re: questions about some bits of STATUS register and exception priority...
Message-ID: <20010821131416.E13302@dea.linux-mips.net>
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001901c129e1$5aaaadc0$8021690a@huawei.com> <20010821085353.B13302@dea.linux-mips.net> <001901c12a2f$8626be00$8021690a@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: <001901c12a2f$8626be00$8021690a@huawei.com>; from dony.he@huawei.com on Tue, Aug 21, 2001 at 06:53:34PM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 344
Lines: 11

On Tue, Aug 21, 2001 at 06:53:34PM +0800, machael thailer wrote:

> > In the Linux kernel CU0 is used to indicate that we're running on the
> > kernel stack.
> 
> Yes, when CU0 is 1, we can see we are running on the kernel stack.
> But when CU0 is 0, can we say it is in User mode?

No, think of the tlb exception handlers for example.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Aug 21 04:19:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LBJwi17549
	for linux-mips-outgoing; Tue, 21 Aug 2001 04:19:58 -0700
Received: from dea.linux-mips.net (u-137-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.137])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LBJp917545
	for ; Tue, 21 Aug 2001 04:19:51 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7LBHLe14564;
	Tue, 21 Aug 2001 13:17:21 +0200
Date: Tue, 21 Aug 2001 13:17:21 +0200
From: Ralf Baechle 
To: machael thailer 
Cc: linux-mips@oss.sgi.com
Subject: Re: questions about eret....
Message-ID: <20010821131721.F13302@dea.linux-mips.net>
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@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: <001201c12a29$57f3b660$8021690a@huawei.com>; from dony.he@huawei.com on Tue, Aug 21, 2001 at 06:09:19PM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 645
Lines: 15

On Tue, Aug 21, 2001 at 06:09:19PM +0800, machael thailer wrote:

> Yes.
> But in the sourece codes, when we finish the exception handlers , we will
> run "ret_from_irq" (ret_from_sys_call) in the entry.S and then run macro
> "RESTORE_ALL_AND_RET".  The macro does restore all registers and then ERET.
> But there is not a "CLI" just before ERET as the user manual suggested. Why?
> so when we handle a syscall exception, we do "STI" in the handle_sys(). and
> when ret_from_sys_call and we will run this macro "RESTORE_ALL_AND_RET".
> because there is not a "CLI" just before ERET , is it possible to have some
> problems?

Look again.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Aug 21 06:16:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LDG5g20367
	for linux-mips-outgoing; Tue, 21 Aug 2001 06:16:05 -0700
Received: from web9701.mail.yahoo.com (web9701.mail.yahoo.com [216.136.129.137])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LDG3920364
	for ; Tue, 21 Aug 2001 06:16:03 -0700
Message-ID: <20010821131603.5015.qmail@web9701.mail.yahoo.com>
Received: from [63.109.250.109] by web9701.mail.yahoo.com; Tue, 21 Aug 2001 06:16:03 PDT
Date: Tue, 21 Aug 2001 06:16:03 -0700 (PDT)
From: mukesh mishra 
Subject: ? Thread Problem on MIPS Malta Board
To: linux-mips@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 797
Lines: 28

Sir,
I got your mail id from net.I am software engineer.
presently I am working in MIPS Malta board using
redHat Linux.I am trying to porting some .c files and
try to run that files , but the problem is like this 

I am useing 4 threads in my application .It is works
in general Linux enviornment(pc).I am using thread say
"pthread_create".
 At the MIPS Malta (red hat Linux)enviornment 
it is compiling linking but at the time of executing
(exe file)it is giving error.It is returning value 11


I am using red hat linux 2.2.12 and MIPS cpu is
"MIPS4kc" .

Please give me some suggestion so that I can proceed

regards
Mukesh



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

From owner-linux-mips@oss.sgi.com Tue Aug 21 06:49:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LDnxL21374
	for linux-mips-outgoing; Tue, 21 Aug 2001 06:49:59 -0700
Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LDnt921368
	for ; Tue, 21 Aug 2001 06:49:55 -0700
Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3])
	by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f7LDnr433054;
	Tue, 21 Aug 2001 14:49:53 +0100 (BST)
Received: from snow (snow.isltd.insignia.com [172.16.17.209])
	by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id OAA15129;
	Tue, 21 Aug 2001 14:49:53 +0100 (BST)
Message-ID: <009d01c12a48$279347a0$d11110ac@snow.isltd.insignia.com>
From: "Andrew Thornton" 
To: "mukesh mishra" , 
Subject: Re: ? Thread Problem on MIPS Malta Board
Date: Tue, 21 Aug 2001 14:49:52 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_009A_01C12A50.89255500"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1960
Lines: 47

This is a multi-part message in MIME format.

------=_NextPart_000_009A_01C12A50.89255500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Mukesh,

>I am useing 4 threads in my application .It is works
>in general Linux enviornment(pc).I am using thread say
>"pthread_create".
> At the MIPS Malta (red hat Linux)enviornment
>it is compiling linking but at the time of executing
>(exe file)it is giving error.It is returning value 11

I did the same thing and found the problem to be that the return value from
the clone syscall is mishandled by glibc. My fix was to use the attached
clone.s. I'm sure there is a better fix, probably involving upgrading the
version of glibc, but this got me working.

Andrew Thornton


------=_NextPart_000_009A_01C12A50.89255500
Content-Type: application/octet-stream;
	name="clone.s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="clone.s"

CS50ZXh0CgovKgogKiBpbnQgX19jbG9uZShpbnQgKCpmbikgKHZvaWQgKmFyZyksIHZvaWQgKmNo
aWxkX3N0YWNrLCBpbnQgZmxhZ3MsCiAqIHZvaWQgKmFyZyk7CiAqLwoKCS5nbG9ibAlfX2Nsb25l
CgkuZW50CV9fY2xvbmUKCQpfX2Nsb25lOgoJLnNldAlub3Jlb3JkZXIKCS5jcGxvYWQgJDI1Cglh
ZGRpdSAgICRzcCwkc3AsLTE2CgkuY3ByZXN0b3JlIDgKCS5zZXQJcmVvcmRlcgoKCS8qIEFsaWdu
IHRoZSBzdGFjayB0byA4IGJ5dGVzICovCglsaQkJJDgsIDcKCW5vcgkJJDgsICQwLCAkOAoJYW5k
CQkkNSwgJDUsICQ4CgoJLyogU2V0dXAgdGhlIG5ldyB0aHJlYWQncyBzdGFjayAqLwoJYWRkaXUg
ICAkNSwkNSwtMTYKCXN3ICAgICAgJDQsMCgkNSkKCXN3ICAgICAgJDcsNCgkNSkKCXN3CQkkZ3As
OCgkNSkKCgkvKiBDYWxsIHRoZSBjbG9uZSBzeXNjYWxsICovCgltb3ZlICAgICQ0LCQ2CglsaSAg
ICAgICQyLDQxMjAKCXN5c2NhbGwKCWJuZXogICAgJDcsZXJyb3IKCWJndHogICAgJDIsZG9uZQoJ
Ym5leiAgICAkMixlcnJvcgoKCS8qIFRoZSBuZXcgdGhyZWFkIHN0YXJ0cyBoZXJlICovCglsdyAg
ICAgICQyNSwwKCRzcCkKCWx3ICAgICAgJDQsNCgkc3ApCglqYWwgICAgICQyNQoJbW92ZSAgICAk
NCwkMgoJamFsCQlfZXhpdAoKZXJyb3I6CglsaQkJJDIsLTEKCmRvbmU6CglhZGRpdSAgICRzcCwk
c3AsMTYKCWpyICAgICAgJDMxCgoJLmVuZAlfX2Nsb25lCgo=

------=_NextPart_000_009A_01C12A50.89255500--


From owner-linux-mips@oss.sgi.com Tue Aug 21 07:15:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LEFQO22235
	for linux-mips-outgoing; Tue, 21 Aug 2001 07:15:26 -0700
Received: from newsmtp2.atmel.com (newsmtp2.atmel.org [12.146.133.142])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LEFP922232
	for ; Tue, 21 Aug 2001 07:15:25 -0700
Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105])
	by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id HAA12880
	for ; Tue, 21 Aug 2001 07:08:12 -0700 (PDT)
Received: from mmc.atmel.com (mail [10.127.240.34])
	by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA05907
	for ; Tue, 21 Aug 2001 07:08:30 -0700 (PDT)
Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA16049
	for ; Tue, 21 Aug 2001 10:15:28 -0400 (EDT)
Message-ID: <3B827B7C.16A1C763@mmc.atmel.com>
Date: Tue, 21 Aug 2001 10:17:16 -0500
From: Shuanglin Wang 
Reply-To: swang@mmc.atmel.com
Organization: ATMEL MMC
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@oss.sgi.com
Subject: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 309
Lines: 12

Hi all,

I'm working on porting Linux to a third-part board. I don't know where to start.
Can anyone give me some tips?
By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
you think it is possible to port Linux to it?  And how difficult will it be?

A lot of thanks,

--Shuanglin



From owner-linux-mips@oss.sgi.com Tue Aug 21 07:29:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LETf122466
	for linux-mips-outgoing; Tue, 21 Aug 2001 07:29:41 -0700
Received: from cool.coventive.com (cool.coventive.com [211.79.9.188])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LETc922463
	for ; Tue, 21 Aug 2001 07:29:38 -0700
Received: from jefflee (miao.coventive.com [202.145.111.189])
	by cool.coventive.com (8.10.2/8.10.2) with SMTP id f7LETXA04902;
	Tue, 21 Aug 2001 22:29:33 +0800
Message-ID: <001101c12a4e$319e7b10$b310a8c0@jefflee>
From: "jeff_lee" 
To: , 
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com>
Subject: Re: Question on porting Linux...
Date: Tue, 21 Aug 2001 22:33:06 +0800
Organization: hardware
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 538
Lines: 25

What is your CPU arch?

Jeff
----- Original Message -----
From: "Shuanglin Wang" 
To: 
Sent: Tuesday, August 21, 2001 11:17 PM
Subject: Question on porting Linux...


> Hi all,
>
> I'm working on porting Linux to a third-part board. I don't know where to
start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.
Do
> you think it is possible to port Linux to it?  And how difficult will it
be?
>
> A lot of thanks,
>
> --Shuanglin
>


From owner-linux-mips@oss.sgi.com Tue Aug 21 07:32:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LEWBo22591
	for linux-mips-outgoing; Tue, 21 Aug 2001 07:32:11 -0700
Received: from newsmtp2.atmel.com (newsmtp2.atmel.org [12.146.133.142])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LEW6922584
	for ; Tue, 21 Aug 2001 07:32:06 -0700
Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105])
	by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id HAA13164;
	Tue, 21 Aug 2001 07:24:48 -0700 (PDT)
Received: from mmc.atmel.com (mail [10.127.240.34])
	by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA07229;
	Tue, 21 Aug 2001 07:25:05 -0700 (PDT)
Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id KAA16241;
	Tue, 21 Aug 2001 10:32:06 -0400 (EDT)
Message-ID: <3B827F60.F27A3045@mmc.atmel.com>
Date: Tue, 21 Aug 2001 10:33:52 -0500
From: Shuanglin Wang 
Reply-To: swang@mmc.atmel.com
Organization: ATMEL MMC
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: jeff_lee 
CC: linux-mips@oss.sgi.com
Subject: Re: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com> <001101c12a4e$319e7b10$b310a8c0@jefflee>
Content-Type: multipart/alternative;
 boundary="------------42B680886CDF7387576F17FE"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1899
Lines: 84


--------------42B680886CDF7387576F17FE
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

> What is your CPU arch?

MIPS 5kc.

>
>
> Jeff
> ----- Original Message -----
> From: "Shuanglin Wang" 
> To: 
> Sent: Tuesday, August 21, 2001 11:17 PM
> Subject: Question on porting Linux...
>
> > Hi all,
> >
> > I'm working on porting Linux to a third-part board. I don't know where to
> start.
> > Can anyone give me some tips?
> > By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.
> Do
> > you think it is possible to port Linux to it?  And how difficult will it
> be?
> >
> > A lot of thanks,
> >
> > --Shuanglin
> >

--
Shuanglin Wang
Atmel Multimedia & Communications
3800 Gateway Centre, Suite 311
Morrisville, NC 27560



--------------42B680886CDF7387576F17FE
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit





What is your CPU arch?

MIPS 5kc.

 

Jeff

----- Original Message -----

From: "Shuanglin Wang" <swang@mmc.atmel.com>

To: <linux-mips@oss.sgi.com>

Sent: Tuesday, August 21, 2001 11:17 PM

Subject: Question on porting Linux...

> Hi all,

>

> I'm working on porting Linux to a third-part board. I don't know
where to

start.

> Can anyone give me some tips?

> By the way, the board doesn't have PCI bus, Interrupt controller,
and RTC.

Do

> you think it is possible to port Linux to it?  And how difficult
will it

be?

>

> A lot of thanks,

>

> --Shuanglin

>



-- 
Shuanglin Wang
Atmel Multimedia & Communications
3800 Gateway Centre, Suite 311
Morrisville, NC 27560

 

--------------42B680886CDF7387576F17FE--


From owner-linux-mips@oss.sgi.com Tue Aug 21 10:32:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LHWiq25958
	for linux-mips-outgoing; Tue, 21 Aug 2001 10:32:44 -0700
Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LHWf925955
	for ; Tue, 21 Aug 2001 10:32:41 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7LHbCA29475;
	Tue, 21 Aug 2001 10:37:12 -0700
Message-ID: <3B8299CF.1444A271@mvista.com>
Date: Tue, 21 Aug 2001 10:26:39 -0700
From: Jun Sun 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: swang@mmc.atmel.com
CC: linux-mips@oss.sgi.com
Subject: Re: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 907
Lines: 43

Shuanglin Wang wrote:
> 
> Hi all,
> 
> I'm working on porting Linux to a third-part board. I don't know where to start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
> you think it is possible to port Linux to it?  And how difficult will it be?
> 
> A lot of thanks,
> 

Porting Linux/MIPS generally involves three tasks:

1. CPU support

If your CPU is already supported, then your task is as easy as include the
CONFIG_CPU_XXXX in your config file.

2. board support

This involves several subtasks:

a) hook your board/machines to the system.  Check include/asm/bootinfo.h,
arch/mips/setup.c.

b) prom_init().

c) board setup code (xxx_setup()): fix hardware, set Linux variables, etc

d) interrupt dispatching, time service

e) others

Look under various arch/mips subdirectories.

3) driver code

Serial, ether, etc.

Good luck.

Jun

From owner-linux-mips@oss.sgi.com Tue Aug 21 13:25:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LKPTu29663
	for linux-mips-outgoing; Tue, 21 Aug 2001 13:25:29 -0700
Received: from mx.mips.com (mx.mips.com [206.31.31.226])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LKPR929660
	for ; Tue, 21 Aug 2001 13:25:27 -0700
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA13898;
	Tue, 21 Aug 2001 13:25:18 -0700 (PDT)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA10483;
	Tue, 21 Aug 2001 13:25:17 -0700 (PDT)
Received: from mips.com (coppccl [172.17.27.2])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7LKNta13094;
	Tue, 21 Aug 2001 22:23:56 +0200 (MEST)
Message-ID: <3B82C410.5E82AD6D@mips.com>
Date: Tue, 21 Aug 2001 22:26:56 +0200
From: Carsten Langgaard 
Organization: MIPS Technologies
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: swang@mmc.atmel.com
CC: linux-mips@oss.sgi.com
Subject: Re: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 783
Lines: 24

You are probably referring to the MIPS SEAD board, I have made a port for that board
now.
It runs with a small ramdisk, which basically only consist of a stand-alone shell
and a few simple commands like ls, etc...
So you can't do much with it, but you can make you own ramdisk, and just merge it in
with the kernel.
I will try to put an image on our FTP site
(ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.

/Carsten

Shuanglin Wang wrote:

> Hi all,
>
> I'm working on porting Linux to a third-part board. I don't know where to start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
> you think it is possible to port Linux to it?  And how difficult will it be?
>
> A lot of thanks,
>
> --Shuanglin


From owner-linux-mips@oss.sgi.com Tue Aug 21 13:34:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LKYD129831
	for linux-mips-outgoing; Tue, 21 Aug 2001 13:34:13 -0700
Received: from newsmtp2.atmel.com (newsmtp2.atmel.com [12.146.133.142])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LKYC929828
	for ; Tue, 21 Aug 2001 13:34:12 -0700
Received: from hermes.sjo.atmel.com (newhermes [10.64.0.105])
	by newsmtp2.atmel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA20672;
	Tue, 21 Aug 2001 13:26:59 -0700 (PDT)
Received: from mmc.atmel.com (mail [10.127.240.34])
	by hermes.sjo.atmel.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA28809;
	Tue, 21 Aug 2001 13:27:17 -0700 (PDT)
Received: from mmc.atmel.com (IDENT:swang@pc-33.mmc.atmel.com [10.127.240.163])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id QAA19872;
	Tue, 21 Aug 2001 16:34:17 -0400 (EDT)
Message-ID: <3B82D443.4C9DBDBE@mmc.atmel.com>
Date: Tue, 21 Aug 2001 16:36:03 -0500
From: Shuanglin Wang 
Reply-To: swang@mmc.atmel.com
Organization: ATMEL MMC
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-8smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Carsten Langgaard 
CC: linux-mips@oss.sgi.com
Subject: Re: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com> <3B82C410.5E82AD6D@mips.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 572
Lines: 17

> You are probably referring to the MIPS SEAD board, I have made a port for that board
> now.
> It runs with a small ramdisk, which basically only consist of a stand-alone shell
> and a few simple commands like ls, etc...
> So you can't do much with it, but you can make you own ramdisk, and just merge it in
> with the kernel.
> I will try to put an image on our FTP site
> (ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.
>
> /Carsten
>

Yes, it is a MIPS SEAD-2 board. By the way, can I get the source code of the kernel
with SEAD-2 board support ?

>


From owner-linux-mips@oss.sgi.com Tue Aug 21 15:12:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7LMCKF31784
	for linux-mips-outgoing; Tue, 21 Aug 2001 15:12:20 -0700
Received: from smtp (smtp.psdc.com [209.125.203.83])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7LMCH931779
	for ; Tue, 21 Aug 2001 15:12:17 -0700
Received: from ex2k.pcs.psdc.com ([172.19.1.1])
 by smtp (NAVIEG 2.1 bld 63) with SMTP id M2001082115123217318
 for ; Tue, 21 Aug 2001 15:12:32 -0700
content-class: urn:content-classes:message
Subject: Want userland code for Mips Linux 2.2.12.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Date: Tue, 21 Aug 2001 15:09:11 -0700
Message-ID: <84CE342693F11946B9F54B18C1AB837B0A259D@ex2k.pcs.psdc.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Want userland code for Mips Linux 2.2.12.
Thread-Index: AcEqjecvC60xDJsCS4KSqEqKLqt9aw==
From: "Steven Liu" 
To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f7LMCJ931781
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 272
Lines: 12

Hi All:

I do not  know where I can find the userland source code of  Mips Linux
2.2.12 (bigendian) since I want to build the user applications such as
init, bash, pwd, tar, ... 

If anyone knows about it and let me know, I would be very pleased.

Thank you.

Steven Liu


From owner-linux-mips@oss.sgi.com Tue Aug 21 17:52:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M0qct02585
	for linux-mips-outgoing; Tue, 21 Aug 2001 17:52:38 -0700
Received: from hp5030-int.trinity200.org (adsl-64-173-206-186.dsl.renocs.nvbell.net [64.173.206.186])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M0qb902582
	for ; Tue, 21 Aug 2001 17:52:37 -0700
Received: from oss.sgi.com (tmoss@hmpiii2.trinity200.org [10.0.0.9])
	by hp5030-int.trinity200.org (8.11.1/8.11.1) with ESMTP id f7M0qnO27347;
	Tue, 21 Aug 2001 17:52:49 -0700
Message-ID: <3B830249.4060708@oss.sgi.com>
Date: Tue, 21 Aug 2001 17:52:25 -0700
From: Tim Moss 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010819
X-Accept-Language: en-us
MIME-Version: 1.0
To: linux-mips@oss.sgi.com
CC: ralf@gnu.org
Subject: serial console bug?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 434
Lines: 10

If I am connected to my Challenge S server via serial console using 
minicom from Linux and minicom dies (eg - the X server where minicom was 
running from crashes), the Challenge box resets. I haven't done really 
extensive testing but this error is definitely recreatable.

My current kernel is 2.4.5. I compiled it myself from CVS but I'm pretty 
sure this also happened with the precompiled 2.4.3 kernel from the oss 
ftp site.



From owner-linux-mips@oss.sgi.com Tue Aug 21 19:15:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M2FCJ04771
	for linux-mips-outgoing; Tue, 21 Aug 2001 19:15:12 -0700
Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M2FA904767
	for ; Tue, 21 Aug 2001 19:15:10 -0700
Received: from prefect (gw1.ltc.com [38.149.17.163])
	by ns1.ltc.com (Postfix) with SMTP id 504BD590A9
	for ; Tue, 21 Aug 2001 22:11:15 -0400 (EDT)
Message-ID: <14df01c12ab0$81ee66e0$3501010a@ltc.com>
From: "Bradley D. LaRonde" 
To: "Tim Moss" 
References: <3B830249.4060708@oss.sgi.com>
Subject: Re: serial console bug?
Date: Tue, 21 Aug 2001 22:16:51 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 711
Lines: 24

What if you just close minicom or pull the cable?

Regards,
Brad

----- Original Message ----- 
From: "Tim Moss" 
To: 
Cc: 
Sent: Tuesday, August 21, 2001 8:52 PM
Subject: serial console bug?


> If I am connected to my Challenge S server via serial console using 
> minicom from Linux and minicom dies (eg - the X server where minicom was 
> running from crashes), the Challenge box resets. I haven't done really 
> extensive testing but this error is definitely recreatable.
> 
> My current kernel is 2.4.5. I compiled it myself from CVS but I'm pretty 
> sure this also happened with the precompiled 2.4.3 kernel from the oss 
> ftp site.
> 
> 


From owner-linux-mips@oss.sgi.com Tue Aug 21 19:24:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M2ORr04965
	for linux-mips-outgoing; Tue, 21 Aug 2001 19:24:27 -0700
Received: from hp5030-int.trinity200.org (adsl-64-173-206-186.dsl.renocs.nvbell.net [64.173.206.186])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M2OP904962
	for ; Tue, 21 Aug 2001 19:24:25 -0700
Received: from oss.sgi.com (tmoss@hmpiii2.trinity200.org [10.0.0.9])
	by hp5030-int.trinity200.org (8.11.1/8.11.1) with ESMTP id f7M2OdO27459
	for ; Tue, 21 Aug 2001 19:24:39 -0700
Message-ID: <3B8317CE.5010508@oss.sgi.com>
Date: Tue, 21 Aug 2001 19:24:14 -0700
From: Tim Moss 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010819
X-Accept-Language: en-us
MIME-Version: 1.0
To: linux-mips@oss.sgi.com
Subject: Re: serial console bug?
References: <3B830249.4060708@oss.sgi.com> <14df01c12ab0$81ee66e0$3501010a@ltc.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: 615
Lines: 18

Bradley D. LaRonde wrote:
> What if you just close minicom or pull the cable?

> 
> 
>>If I am connected to my Challenge S server via serial console using 
>>minicom from Linux and minicom dies (eg - the X server where minicom was 
>>running from crashes), the Challenge box resets. I haven't done really 
>>extensive testing but this error is definitely recreatable.
>>
>>My current kernel is 2.4.5. I compiled it myself from CVS but I'm pretty 
>>sure this also happened with the precompiled 2.4.3 kernel from the oss 
>>ftp site.
>>


Closing minicom properly or pulling the plug don't cause the reset problem.


From owner-linux-mips@oss.sgi.com Tue Aug 21 19:31:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M2VxB05245
	for linux-mips-outgoing; Tue, 21 Aug 2001 19:31:59 -0700
Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged))
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M2Vv905240
	for ; Tue, 21 Aug 2001 19:31:57 -0700
Received: from hechendong11752 ([10.105.33.128]) by
          smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id
          GIG6XP00.R4L for ; Wed, 22 Aug 2001
          10:29:49 +0800 
Message-ID: <001201c12ab2$c7c4e700$8021690a@huawei.com>
From: "machael thailer" 
To: 
Subject: question about syscall and interrupts......
Date: Wed, 22 Aug 2001 10:33:08 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 377
Lines: 16

Hello,
    I find that in handle_sys() of scall_o32.S, it calls:
        SAVE_SOME
    But in the various board interrupt handlers entry(int-handler.S), it
calls:
        SAVE_ALL

    So before entering syscall and interrupt handler entry, why do they need
save different registers? and interrupt need save more things than syscalls?

Thank you very much.

machael thailer




From owner-linux-mips@oss.sgi.com Tue Aug 21 20:11:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M3B4914944
	for linux-mips-outgoing; Tue, 21 Aug 2001 20:11:04 -0700
Received: from dea.linux-mips.net (u-84-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.84])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M3B2914941
	for ; Tue, 21 Aug 2001 20:11:02 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7M38RP13069;
	Wed, 22 Aug 2001 05:08:27 +0200
Date: Wed, 22 Aug 2001 05:08:27 +0200
From: Ralf Baechle 
To: tim@to11.org
Cc: linux-mips@oss.sgi.com
Subject: Re: serial console bug?
Message-ID: <20010822050827.A3358@dea.linux-mips.net>
References: <3B830249.4060708@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: <3B830249.4060708@oss.sgi.com>; from linux-mips@oss.sgi.com on Tue, Aug 21, 2001 at 05:52:25PM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 172
Lines: 7

On Tue, Aug 21, 2001 at 05:52:25PM -0700, Tim Moss wrote:

> From: Tim Moss 

Stop forging from addresses or be treated like every spammer.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Aug 21 22:41:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M5fPr21150
	for linux-mips-outgoing; Tue, 21 Aug 2001 22:41:25 -0700
Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M5fE921147
	for ; Tue, 21 Aug 2001 22:41:15 -0700
Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 22 Aug 2001 05:41:14 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP
	id 30BA754C0E; Wed, 22 Aug 2001 14:41:13 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id OAA86356; Wed, 22 Aug 2001 14:41:12 +0900 (JST)
Date: Wed, 22 Aug 2001 14:45:47 +0900 (JST)
Message-Id: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp>
To: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Cc: Ralf Baechle 
Subject: Magic numbers about stack layout
From: Atsushi Nemoto 
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Wed_Aug_22_14:45:47_2001_172)--"
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 5896
Lines: 186

----Next_Part(Wed_Aug_22_14:45:47_2001_172)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There are some magic constant numbers about stack layout in
thread_saved_pc() and get_wchan() function.

I made a patch to eliminate these magic numbers.  This patch analyzes
some functions prologue codes in heuristic way at run-time.  "ps -l"
(and "MAGIC SYSRQ" feature) works fine with this patch.

---
Atsushi Nemoto

----Next_Part(Wed_Aug_22_14:45:47_2001_172)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="get_wchan.patch"

diff -ur linux.sgi/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
--- linux.sgi/arch/mips/kernel/process.c	Sun Aug  5 23:39:09 2001
+++ linux/arch/mips/kernel/process.c	Wed Aug 22 14:14:29 2001
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void cpu_idle(void)
 {
@@ -196,6 +198,59 @@
 #define first_sched	((unsigned long) scheduling_functions_start_here)
 #define last_sched	((unsigned long) scheduling_functions_end_here)
 
+struct mips_frame_info schedule_frame;
+static struct mips_frame_info schedule_timeout_frame;
+static struct mips_frame_info sleep_on_frame;
+static struct mips_frame_info sleep_on_timeout_frame;
+static int mips_frame_info_initialized;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
+{
+	int i;
+	union mips_instruction *ip = (union mips_instruction *)func;
+	info->pc_offset = -1;
+	info->frame_offset = -1;
+	for (i = 0; i < 128; i++, ip++) {
+		/* if jal, jalr, jr, stop. */
+		if (ip->j_format.opcode == jal_op ||
+		    (ip->r_format.opcode == spec_op &&
+		     (ip->r_format.func == jalr_op ||
+		      ip->r_format.func == jr_op)))
+			break;
+		if (ip->i_format.opcode == sw_op &&
+		    ip->i_format.rs == 29) {
+			/* sw $ra, offset($sp) */
+			if (ip->i_format.rt == 31) {
+				if (info->pc_offset != -1)
+					break;
+				info->pc_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+			/* sw $s8, offset($sp) */
+			if (ip->i_format.rt == 30) {
+				if (info->frame_offset != -1)
+					break;
+				info->frame_offset =
+					ip->i_format.simmediate / sizeof(long);
+			}
+		}
+	}
+	if (info->pc_offset == -1 || info->frame_offset == -1) {
+		printk("Can't analize prologue code at %p\n", func);
+		info->pc_offset = -1;
+		info->frame_offset = -1;
+		return -1;
+	}
+	return 0;
+}
+void __init frame_info_init(void)
+{
+	mips_frame_info_initialized =
+		!get_frame_info(&schedule_frame, schedule) &&
+		!get_frame_info(&schedule_timeout_frame, schedule_timeout) &&
+		!get_frame_info(&sleep_on_frame, sleep_on) &&
+		!get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout);
+}
+
 /* get_wchan - a maintenance nightmare ...  */
 unsigned long get_wchan(struct task_struct *p)
 {
@@ -204,6 +259,8 @@
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+	if (!mips_frame_info_initialized)
+		return 0;
 	pc = thread_saved_pc(&p->thread);
 	if (pc < first_sched || pc >= last_sched) {
 		return pc;
@@ -220,23 +277,24 @@
 	goto schedule_timeout_caller;
 
 schedule_caller:
-	frame = ((unsigned long *)p->thread.reg30)[9];
-	pc    = ((unsigned long *)frame)[11];
+	/* schedule_timeout called by interruptible_sleep_on or sleep_on */
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
+	pc    = ((unsigned long *)frame)[sleep_on_frame.pc_offset];
 	return pc;
 
 schedule_timeout_caller:
 	/* Must be schedule_timeout ...  */
-	pc    = ((unsigned long *)p->thread.reg30)[10];
-	frame = ((unsigned long *)p->thread.reg30)[9];
+	pc    = ((unsigned long *)p->thread.reg30)[schedule_frame.pc_offset];
+	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
 
 	/* The schedule_timeout frame ...  */
-	pc    = ((unsigned long *)frame)[14];
-	frame = ((unsigned long *)frame)[13];
+	pc    = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset];
+	frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset];
 
 	if (pc >= first_sched && pc < last_sched) {
 		/* schedule_timeout called by interruptible_sleep_on_timeout */
-		pc    = ((unsigned long *)frame)[11];
-		frame = ((unsigned long *)frame)[10];
+		pc    = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset];
+		frame = ((unsigned long *)frame)[sleep_on_timeout_frame.frame_offset];
 	}
 
 	return pc;
diff -ur linux.sgi/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c
--- linux.sgi/arch/mips/kernel/setup.c	Sun Aug  5 23:39:15 2001
+++ linux/arch/mips/kernel/setup.c	Wed Aug 22 14:26:19 2001
@@ -518,12 +518,14 @@
 	void malta_setup(void);
 	void momenco_ocelot_setup(void);
 	void nino_setup(void);
+	void frame_info_init(void);
 
 	unsigned long bootmap_size;
 	unsigned long start_pfn, max_pfn, first_usable_pfn;
 
 	int i;
 
+	frame_info_init();
 #ifdef CONFIG_BLK_DEV_FD
 	fd_ops = &no_fd_ops;
 #endif
diff -ur linux.sgi/include/asm-mips/processor.h linux/include/asm-mips/processor.h
--- linux.sgi/include/asm-mips/processor.h	Sun Aug  5 23:41:29 2001
+++ linux/include/asm-mips/processor.h	Wed Aug 22 14:14:59 2001
@@ -217,6 +217,11 @@
 #define copy_segments(p, mm) do { } while(0)
 #define release_segments(mm) do { } while(0)
 
+struct mips_frame_info {
+	int frame_offset;
+	int pc_offset;
+};
+extern struct mips_frame_info schedule_frame;
 /*
  * Return saved PC of a blocked thread.
  */
@@ -228,7 +233,9 @@
 	if (t->reg31 == (unsigned long) ret_from_fork)
 		return t->reg31;
 
-	return ((unsigned long *)t->reg29)[10];
+	if (schedule_frame.pc_offset < 0)
+		return 0;
+	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
 /*

----Next_Part(Wed_Aug_22_14:45:47_2001_172)----

From owner-linux-mips@oss.sgi.com Tue Aug 21 23:47:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M6laT22187
	for linux-mips-outgoing; Tue, 21 Aug 2001 23:47:36 -0700
Received: from mx.mips.com (mx.mips.com [206.31.31.226])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M6lY922183
	for ; Tue, 21 Aug 2001 23:47:34 -0700
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA19971;
	Tue, 21 Aug 2001 23:47:24 -0700 (PDT)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA21424;
	Tue, 21 Aug 2001 23:47:25 -0700 (PDT)
Received: from copsun17.mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7M6k2a18254;
	Wed, 22 Aug 2001 08:46:03 +0200 (MEST)
From: Hartvig Ekner 
Received: (from hartvige@localhost)
	by copsun17.mips.com (8.9.1/8.9.0) id IAA13918;
	Wed, 22 Aug 2001 08:46:01 +0200 (MET DST)
Message-Id: <200108220646.IAA13918@copsun17.mips.com>
Subject: Re: Magic numbers about stack layout
To: nemoto@toshiba-tops.co.jp (Atsushi Nemoto)
Date: Wed, 22 Aug 2001 08:46:01 +0200 (MET DST)
Cc: linux-mips@oss.sgi.com
In-Reply-To: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp> from "Atsushi Nemoto" at Aug 22, 2001 02:45:47 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: 868
Lines: 26

Hi,

what is the purpose of replacing the magic numbers with code analysis?
And what will happen when you run userland with MIPS16 or MIPS16e code?

We have it on our work-list to eventually clean up all the places in the
kernel that inspect code to allow MIPS16(e) code as well, so adding more
code inspection points is a bad idea unless it really is necessary.

/Hartvig

Atsushi Nemoto writes:
> 
> ----Next_Part(Wed_Aug_22_14:45:47_2001_172)--
> Content-Type: Text/Plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> There are some magic constant numbers about stack layout in
> thread_saved_pc() and get_wchan() function.
> 
> I made a patch to eliminate these magic numbers.  This patch analyzes
> some functions prologue codes in heuristic way at run-time.  "ps -l"
> (and "MAGIC SYSRQ" feature) works fine with this patch.
> 
> ---
> Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Tue Aug 21 23:48:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M6mAH22251
	for linux-mips-outgoing; Tue, 21 Aug 2001 23:48:10 -0700
Received: from mx.mips.com (mx.mips.com [206.31.31.226])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M6m8922248
	for ; Tue, 21 Aug 2001 23:48:08 -0700
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA19975;
	Tue, 21 Aug 2001 23:47:57 -0700 (PDT)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA21429;
	Tue, 21 Aug 2001 23:47:58 -0700 (PDT)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7M6kaa18314;
	Wed, 22 Aug 2001 08:46:37 +0200 (MEST)
Message-ID: <3B83554C.5FEC50A4@mips.com>
Date: Wed, 22 Aug 2001 08:46:36 +0200
From: Carsten Langgaard 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Steven Liu 
CC: linux-mips@oss.sgi.com
Subject: Re: Want userland code for Mips Linux 2.2.12.
References: <84CE342693F11946B9F54B18C1AB837B0A259D@ex2k.pcs.psdc.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 853
Lines: 30

Hard to tell what userland you are using from the kernel version, but I
guess you are having the HardHat5.1 userland (which is rather old).
You can find all the sources here:
ftp://oss.sgi.com/pub/linux/mips/redhat/SRPMS/

/Carsten

Steven Liu wrote:

> Hi All:
>
> I do not  know where I can find the userland source code of  Mips Linux
> 2.2.12 (bigendian) since I want to build the user applications such as
> init, bash, pwd, tar, ...
>
> If anyone knows about it and let me know, I would be very pleased.
>
> Thank you.
>
> Steven Liu

--
_    _ ____  ___   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 Aug 22 00:10:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7M7AxW22822
	for linux-mips-outgoing; Wed, 22 Aug 2001 00:10:59 -0700
Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7M7Av922819
	for ; Wed, 22 Aug 2001 00:10:57 -0700
Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 22 Aug 2001 07:10:57 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP
	id 81AB754C14; Wed, 22 Aug 2001 16:10:55 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id QAA86595; Wed, 22 Aug 2001 16:10:54 +0900 (JST)
Date: Wed, 22 Aug 2001 16:15:29 +0900 (JST)
Message-Id: <20010822.161529.115901259.nemoto@toshiba-tops.co.jp>
To: hartvige@mips.com
Cc: linux-mips@oss.sgi.com
Subject: Re: Magic numbers about stack layout
From: Atsushi Nemoto 
In-Reply-To: <200108220646.IAA13918@copsun17.mips.com>
References: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp>
	<200108220646.IAA13918@copsun17.mips.com>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
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: 570
Lines: 15

>>>>> On Wed, 22 Aug 2001 08:46:01 +0200 (MET DST), Hartvig Ekner  said:
hartvige> what is the purpose of replacing the magic numbers with code
hartvige> analysis?

The magic numbers are affected by frame size of some kernel functions
such as schedule(), sleep_on(), etc.  These values may change for
various reason (code modification, new compiler, more optimize, ...).

hartvige> And what will happen when you run userland with MIPS16 or
hartvige> MIPS16e code?

Nothing.  The targets of this analysis are only kernel functions.

---
Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Wed Aug 22 03:00:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7MA0Tc25380
	for linux-mips-outgoing; Wed, 22 Aug 2001 03:00:29 -0700
Received: from mx.mips.com (mx.mips.com [206.31.31.226])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MA0P925377
	for ; Wed, 22 Aug 2001 03:00:25 -0700
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA21080;
	Wed, 22 Aug 2001 03:00:17 -0700 (PDT)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA23197;
	Wed, 22 Aug 2001 03:00:14 -0700 (PDT)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f7M9wra04582;
	Wed, 22 Aug 2001 11:58:55 +0200 (MEST)
Message-ID: <3B83825D.47619A46@mips.com>
Date: Wed, 22 Aug 2001 11:58:53 +0200
From: Carsten Langgaard 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: swang@mmc.atmel.com
CC: linux-mips@oss.sgi.com
Subject: Re: Question on porting Linux...
References: <000701c12529$e1640580$8021690a@huawei.com> <20010815103314.A11966@bacchus.dhis.org> <000b01c1295e$0f2174c0$8021690a@huawei.com> <20010820230755.A11242@dea.linux-mips.net> <001501c129dd$8acebb80$8021690a@huawei.com> <20010821083508.A13302@dea.linux-mips.net> <001201c12a29$57f3b660$8021690a@huawei.com> <20010821131721.F13302@dea.linux-mips.net> <3B827B7C.16A1C763@mmc.atmel.com> <3B82C410.5E82AD6D@mips.com> <3B82D443.4C9DBDBE@mmc.atmel.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1588
Lines: 43

You can find a kernel images for the SEAD board here:
ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/vmlinux-2.4.3.sead.el-01.01.srec.gz
The sources are here:
ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/src/linux-2.4.3.mips-src-01.01.tar.gz

To build your own ramdisk see Documentation/initrd.txt (in the sources) for how-to do it.
Put your ramdisk images in arch/mips/ramdisk/ramdisk.gz and compile the kernel (you can
use the .config.sead file for configure your kernel for the SEAD board, just copy it to
.config and then do 'make config').
Note that you need a other MIPS linux system to build your ramdisk.

Hope this is useful.
/Carsten


Shuanglin Wang wrote:

> > You are probably referring to the MIPS SEAD board, I have made a port for that board
> > now.
> > It runs with a small ramdisk, which basically only consist of a stand-alone shell
> > and a few simple commands like ls, etc...
> > So you can't do much with it, but you can make you own ramdisk, and just merge it in
> > with the kernel.
> > I will try to put an image on our FTP site
> > (ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.
> >
> > /Carsten
> >
>
> Yes, it is a MIPS SEAD-2 board. By the way, can I get the source code of the kernel
> with SEAD-2 board support ?
>
> >

--
_    _ ____  ___   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 Aug 22 04:43:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7MBh4F27010
	for linux-mips-outgoing; Wed, 22 Aug 2001 04:43:04 -0700
Received: from dea.linux-mips.net (u-250-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.250])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MBh1927007
	for ; Wed, 22 Aug 2001 04:43:01 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7MBeHO18758;
	Wed, 22 Aug 2001 13:40:17 +0200
Date: Wed, 22 Aug 2001 13:40:17 +0200
From: Ralf Baechle 
To: Atsushi Nemoto 
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: Magic numbers about stack layout
Message-ID: <20010822134017.A18730@dea.linux-mips.net>
References: <20010822.144547.30190293.nemoto@toshiba-tops.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: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Aug 22, 2001 at 02:45:47PM +0900
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 573
Lines: 16

On Wed, Aug 22, 2001 at 02:45:47PM +0900, Atsushi Nemoto wrote:

> There are some magic constant numbers about stack layout in
> thread_saved_pc() and get_wchan() function.
> 
> I made a patch to eliminate these magic numbers.  This patch analyzes
> some functions prologue codes in heuristic way at run-time.  "ps -l"
> (and "MAGIC SYSRQ" feature) works fine with this patch.

Very nice, this part of the kernel used to be rather fragile on all
architectures; when wchan computation broke usually nobody complained
and this looks like a major improvment!

Thanks,

  Ralf

From owner-linux-mips@oss.sgi.com Wed Aug 22 16:09:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7MN9h808476
	for linux-mips-outgoing; Wed, 22 Aug 2001 16:09:43 -0700
Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7MN9ed08473
	for ; Wed, 22 Aug 2001 16:09:40 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7MNE8A12739;
	Wed, 22 Aug 2001 16:14:08 -0700
Message-ID: <3B843A46.6F39300F@mvista.com>
Date: Wed, 22 Aug 2001 16:03:34 -0700
From: Jun Sun 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com
Subject: [PATCH] set the number of serial ports
Content-Type: multipart/mixed;
 boundary="------------6CB43A7A0B4E1479BE594809"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2389
Lines: 64

This is a multi-part message in MIME format.
--------------6CB43A7A0B4E1479BE594809
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Who is maintaining serial.c file?  I sent this email to Ted Tso a while back
and did not get any replies.  Here is another try.

Jun
--------------6CB43A7A0B4E1479BE594809
Content-Type: text/plain; charset=us-ascii;
 name="num_serial_ports.2.4.0108xx.010822.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="num_serial_ports.2.4.0108xx.010822.patch"


This attempts to solve two problmes:

1. reserves rs_table size even without any SERIAL_PORT_DFNS.  This
   is necessary for machines that must detect serial ports at run-time.
   It is also a better way to use early_serial_setup() to set up serial
   ports, especially serial.h is *really* getting crowded for RISC arches.

2. When CONFIG_SERIAL_MANY_PORTS is defined, we will 64 rs_table entries
   (under MIPS and other arches).  We can save up to 11K with some
   more reasonable CONFIG_NUM_SERIAL_PORTS value.

Jun
08/22/2001

diff -Nru linux/drivers/char/Config.in.orig linux/drivers/char/Config.in
--- linux/drivers/char/Config.in.orig	Tue Jun 12 17:29:21 2001
+++ linux/drivers/char/Config.in	Wed Aug 22 15:28:54 2001
@@ -11,6 +11,7 @@
 tristate 'Standard/generic (8250/16550 and compatible UARTs) serial support' CONFIG_SERIAL
 if [ "$CONFIG_SERIAL" = "y" ]; then
    bool '  Support for console on serial port' CONFIG_SERIAL_CONSOLE
+   int '   Number of serial ports (0 for system default)' CONFIG_SERIAL_NUM_PORTS  0
    if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
       tristate '   Atomwide serial port support' CONFIG_ATOMWIDE_SERIAL
       tristate '   Dual serial port support' CONFIG_DUALSP_SERIAL
diff -Nru linux/drivers/char/serial.c.orig linux/drivers/char/serial.c
--- linux/drivers/char/serial.c.orig	Tue Jun 26 17:23:10 2001
+++ linux/drivers/char/serial.c	Wed Aug 22 15:48:46 2001
@@ -321,6 +321,14 @@
 MODULE_PARM_DESC(force_rsa, "Force I/O ports for RSA");
 #endif /* CONFIG_SERIAL_RSA  */
 
+/* 
+ * [jsun] We horner the CONFIG_SERIAL_NUM_PORTS variable
+ */
+#if (CONFIG_SERIAL_NUM_PORTS != 0)
+#undef RS_TABLE_SIZE
+#define RS_TABLE_SIZE	CONFIG_SERIAL_NUM_PORTS
+#endif
+
 static struct serial_state rs_table[RS_TABLE_SIZE] = {
 	SERIAL_PORT_DFNS	/* Defined in serial.h */
 };

--------------6CB43A7A0B4E1479BE594809--


From owner-linux-mips@oss.sgi.com Wed Aug 22 18:51:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7N1peO11422
	for linux-mips-outgoing; Wed, 22 Aug 2001 18:51:40 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7N1pad11418
	for ; Wed, 22 Aug 2001 18:51:36 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) 
	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 SAA03581
	for ; Wed, 22 Aug 2001 18:51:35 -0700 (PDT)
	mail_from (kaos@ocs.com.au)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06795; Thu, 23 Aug 2001 11:49:53 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens 
To: "Maciej W. Rozycki" 
cc: Ralf Baechle , linux-mips@fnet.fr,
   linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 
In-reply-to: Your message of "Mon, 20 Aug 2001 15:57:21 +0200."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Aug 2001 11:49:53 +1000
Message-ID: <19339.998531393@kao2.melbourne.sgi.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 993
Lines: 26

On Mon, 20 Aug 2001 15:57:21 +0200 (MET DST), 
"Maciej W. Rozycki"  wrote:
>+	for (mp = module_list; mp != NULL; mp = mp->next) {
>+		if (!mod_member_present(mp, archdata_start) ||
>+		    !mp->archdata_start)
>+			continue;
>+		ap = (struct archdata *)(mp->archdata_start);

The definition of struct archdata in kernel and modutils can be
different, a new kernel layout with an old modutils is legal but fatal
unless you code for it.  The correct test for archdata is

if (!mod_member_present(mp, archdata_start) ||
    (mp->archdata_end - mp->archdata_start) <=
     offsetof(struct archdata, dbe_table_end))
	continue;

Do not use archdata unless it is at least large enough to contain
dbe_table_end.  That test also takes care of NULL pointers, end - start
== 0 for NULL.

The rest of the code looks OK, except it needs a global change of
arch_init_module: to module_arch_init: to match the macro name.

Do you have the corresponding modutils patch or shall I do it?


From owner-linux-mips@oss.sgi.com Thu Aug 23 00:51:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7N7pcU17936
	for linux-mips-outgoing; Thu, 23 Aug 2001 00:51:38 -0700
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 f7N7pZd17933
	for ; Thu, 23 Aug 2001 00:51:35 -0700
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 15ZpH4-00022h-00; Thu, 23 Aug 2001 09:51:34 +0200
Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian))
	id 15ZpH3-0002zf-00; Thu, 23 Aug 2001 09:51:33 +0200
Date: Thu, 23 Aug 2001 09:51:33 +0200
From: Guido Guenther 
To: linux-mips@oss.sgi.com
Cc: Ralf Baechle 
Subject: Patch: don't report rd found when none is there
Message-ID: <20010823095133.A11435@galadriel.physik.uni-konstanz.de>
Mail-Followup-To: linux-mips@oss.sgi.com,
	Ralf Baechle 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1266
Lines: 34


--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

The current code in a/m/k/setup.c assigns __rd_start & __rd_end to
initrd_start and initrd_end even when no ramdisk was added to the kernel
image. This gives an "Initial ramdisk at:...." message even though no
ramdisk is there. Attached patch fixes this. It furthermore prevents
initrd_{start,end} being overriden(in case it gets set somewhere in the
board specific code).
 -- Guido

--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rd_found_2001-08-23.diff"

--- arch/mips/kernel/setup.c.orig	Thu Aug 23 09:36:31 2001
+++ arch/mips/kernel/setup.c	Thu Aug 23 09:36:40 2001
@@ -725,8 +719,10 @@
 #ifdef CONFIG_BLK_DEV_INITRD
 	/* Board specific code should have set up initrd_start and initrd_end */
 	ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
-	initrd_start = (unsigned long)&__rd_start;
-	initrd_end = (unsigned long)&__rd_end;
+	if( __rd_start != __rd_end ) {
+		initrd_start = (unsigned long)&__rd_start;
+		initrd_end = (unsigned long)&__rd_end;
+	}
 	initrd_below_start_ok = 1;
 	if (initrd_start) {
 		unsigned long initrd_size = ((unsigned char *)initrd_end) - ((unsigned char *)initrd_start); 

--LQksG6bCIzRHxTLp--

From owner-linux-mips@oss.sgi.com Thu Aug 23 03:28:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NASr621647
	for linux-mips-outgoing; Thu, 23 Aug 2001 03:28:53 -0700
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 f7NASnd21644
	for ; Thu, 23 Aug 2001 03:28:49 -0700
Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian))
	id 15ZrjE-0003kA-00; Thu, 23 Aug 2001 12:28:48 +0200
Date: Thu, 23 Aug 2001 12:28:48 +0200
From: Guido Guenther 
To: linux-mips@oss.sgi.com
Cc: Ralf Baechle 
Subject: Patch: linux_logo.h build_fix for 2.4.6
Message-ID: <20010823122848.A14308@gandalf.physik.uni-konstanz.de>
Mail-Followup-To: linux-mips@oss.sgi.com,
	Ralf Baechle 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1601
Lines: 47


--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Attached patch adds the definition of __HAVE_ARCH_LINUX_LOGO to let
current cvs build again.
 -- Guido

--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="arch_linux_logo-2001-08-23.diff"

Index: include/asm-mips/linux_logo_dec.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/linux_logo_dec.h,v
retrieving revision 1.1
diff -u -u -r1.1 linux_logo_dec.h
--- include/asm-mips/linux_logo_dec.h	2001/07/14 12:43:30	1.1
+++ include/asm-mips/linux_logo_dec.h	2001/08/23 10:26:54
@@ -16,6 +16,8 @@
 #define linux_logo_banner "Linux/MIPSel version " UTS_RELEASE
 #define LINUX_LOGO_COLORS 183
 
+#define __HAVE_ARCH_LINUX_LOGO
+
 #ifdef INCLUDE_LINUX_LOGO_DATA
 unsigned char linux_logo_red[] __initdata = {
     0x00, 0x06, 0x0a, 0x0e, 0x16, 0x1a, 0x1e, 0x22,
Index: include/asm-mips/linux_logo_sgi.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/linux_logo_sgi.h,v
retrieving revision 1.1
diff -u -u -r1.1 linux_logo_sgi.h
--- include/asm-mips/linux_logo_sgi.h	2001/07/14 12:43:30	1.1
+++ include/asm-mips/linux_logo_sgi.h	2001/08/23 10:26:54
@@ -16,6 +16,8 @@
 #define linux_logo_banner "Linux/MIPS version " UTS_RELEASE
 #define LINUX_LOGO_COLORS 212
 
+#define __HAVE_ARCH_LINUX_LOGO
+
 #ifdef INCLUDE_LINUX_LOGO_DATA
 unsigned char linux_logo_red[] __initdata = {
   0x03, 0x82, 0xE9, 0xBF, 0x42, 0xC9, 0x7E, 0xC0,

--7AUc2qLy4jB3hD7Z--

From owner-linux-mips@oss.sgi.com Thu Aug 23 04:31:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NBVuw22731
	for linux-mips-outgoing; Thu, 23 Aug 2001 04:31:56 -0700
Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NBVUd22717;
	Thu, 23 Aug 2001 04:31:32 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA19412;
	Thu, 23 Aug 2001 15:31:13 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA04309; Thu, 23 Aug 2001 15:08:55 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA20536; Thu, 23 Aug 2001 15:22:57 +0400 (MSD)
Message-ID: <3B84E796.EF5E5F39@niisi.msk.ru>
Date: Thu, 23 Aug 2001 15:23:02 +0400
From: "Gleb O. Raiko" 
Organization: NIISI RAN
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Maciej W. Rozycki" 
CC: Ralf Baechle , Harald Koerfgen ,
   Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules
References: 
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1356
Lines: 34

"Maciej W. Rozycki" wrote:
> 
> On Mon, 13 Aug 2001, Gleb O. Raiko wrote:
> 
> > DBE is treated as ACK* on write. Some HW design manuals advise to use
> > this fact even.
> 
>  And what is the use of ACK*?

Acknowledge. It's used to indicate current transaction has been
processed successfully. If you are interested in details, I would
suggest you read a MIPS hardware manual, for example, IDT's one.

The most intriguing feature is:
"Write transactions terminated by BusError* do not require the assertion
of Ack*. BusError* can be asserted at at any time the processor is
looking for Ack* to be asserted, up to and including the cycle in which
the memory system does signal Ack*."

> 
>  Note that that the state of the CPU at the moment of a write is
> completely unrelated to the action that triggered the write.  Therefore
> any reporting of a write failure is hardly useful -- possibly as a kind of
> an MCE only, i.e. report the event and kill the current process or panic
> if none.

I consider external signaling of write failures may be useful for kernel
debugging purposes. I agree it's hard (or even impossible) to achieve
proper behaviour on write failures for user space. There is a small
chance to kill another process, for example, write transactions may
delay due to write buffer. So, the kernel may only print something.

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Thu Aug 23 04:41:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NBflq22931
	for linux-mips-outgoing; Thu, 23 Aug 2001 04:41:47 -0700
Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NBffd22928;
	Thu, 23 Aug 2001 04:41:41 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA19507;
	Thu, 23 Aug 2001 15:41:13 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA04399; Thu, 23 Aug 2001 15:23:11 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA20895; Thu, 23 Aug 2001 15:38:14 +0400 (MSD)
Message-ID: <3B84EB2C.7643F00B@niisi.msk.ru>
Date: Thu, 23 Aug 2001 15:38:20 +0400
From: "Gleb O. Raiko" 
Organization: NIISI RAN
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Maciej W. Rozycki" 
CC: Ralf Baechle , Harald Koerfgen ,
   linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
References: 
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1676
Lines: 41


"Maciej W. Rozycki" wrote:
> 
> On Mon, 13 Aug 2001, Gleb O. Raiko wrote:
> 
> > >  Note that for PCI-based systems, there is usually no problem -- PCI IDs
> > > can be used instead in most cases.
> >
> > How? In fact, I've got two different boards with the same Ethernet chip.
> > Moreover, mach type shall be known as early as possible, early than pci
> > init for sure. Just imagine, I need a way to identify PCI controller by
> > mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I
> > miss something in your proposal?
> 
>  The PCI ID of a host bridge is usually sufficient to differentiate most
> systems for onboard devices that are not reported on PCI.  If it is not
> for your one, you just fall outside of the scope of "most cases" and you
> need a different way to identify a system.  Note I do not promote
> mips_machtype removal.

In order to read a PCI ID, you need to know how to do it. In pc world,
you may rely on configuation access types, at least, ports are known. On
other arches, you need to know where such "ports" are. Even if hardware
supports, say, configuration type 1 accesses, developers are free to put
port addresses anywhere.

> 
> > BTW, in my Baget case, I just need a number for mach type. I can ask to
> > change my prom in worst case.
> 
>  How do you set up mips_machtype on your system in the first place?  At
> kernel_entry the code does not know what machine it's running on anyway,
> so it has to set mips_machtype based on a detection algorithm.
> 

First, mips_machtype is accessed far later than kernel_entry is
executed. Personally, I am lucky :-), I may read firmware environment
variables.

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Thu Aug 23 05:31:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NCVPu24441
	for linux-mips-outgoing; Thu, 23 Aug 2001 05:31:25 -0700
Received: from dea.linux-mips.net (u-161-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.161])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NCVJd24437
	for ; Thu, 23 Aug 2001 05:31:19 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7NCSuc25637
	for linux-mips@oss.sgi.com; Thu, 23 Aug 2001 14:28:56 +0200
Date: Thu, 23 Aug 2001 14:28:56 +0200
From: Ralf Baechle 
To: linux-mips@oss.sgi.com
Subject: Re: Patch: linux_logo.h build_fix for 2.4.6
Message-ID: <20010823142856.B25422@dea.linux-mips.net>
References: <20010823122848.A14308@gandalf.physik.uni-konstanz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010823122848.A14308@gandalf.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Thu, Aug 23, 2001 at 12:28:48PM +0200
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 180
Lines: 8

On Thu, Aug 23, 2001 at 12:28:48PM +0200, Guido Guenther wrote:

> Attached patch adds the definition of __HAVE_ARCH_LINUX_LOGO to let
> current cvs build again.

Applied.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Aug 23 05:34:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NCYBo24572
	for linux-mips-outgoing; Thu, 23 Aug 2001 05:34:11 -0700
Received: from dea.linux-mips.net (u-161-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.161])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NCY7d24567
	for ; Thu, 23 Aug 2001 05:34:08 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7NCVi325659
	for linux-mips@oss.sgi.com; Thu, 23 Aug 2001 14:31:44 +0200
Date: Thu, 23 Aug 2001 14:31:44 +0200
From: Ralf Baechle 
To: linux-mips@oss.sgi.com
Subject: Re: Patch: don't report rd found when none is there
Message-ID: <20010823143144.C25422@dea.linux-mips.net>
References: <20010823095133.A11435@galadriel.physik.uni-konstanz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010823095133.A11435@galadriel.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Thu, Aug 23, 2001 at 09:51:33AM +0200
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 468
Lines: 12

On Thu, Aug 23, 2001 at 09:51:33AM +0200, Guido Guenther wrote:

> The current code in a/m/k/setup.c assigns __rd_start & __rd_end to
> initrd_start and initrd_end even when no ramdisk was added to the kernel
> image. This gives an "Initial ramdisk at:...." message even though no
> ramdisk is there. Attached patch fixes this. It furthermore prevents
> initrd_{start,end} being overriden(in case it gets set somewhere in the
> board specific code).

Applied,

  Ralf

From owner-linux-mips@oss.sgi.com Thu Aug 23 08:53:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NFrAZ30260
	for linux-mips-outgoing; Thu, 23 Aug 2001 08:53:10 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFr4d30255
	for ; Thu, 23 Aug 2001 08:53:04 -0700
Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA01506
	for ; Thu, 23 Aug 2001 08:53:01 -0700 (PDT)
	mail_from (macro@ds2.pg.gda.pl)
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22772;
	Thu, 23 Aug 2001 17:46:57 +0200 (MET DST)
Date: Thu, 23 Aug 2001 17:46:57 +0200 (MET DST)
From: "Maciej W. Rozycki" 
To: "Gleb O. Raiko" 
cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules
In-Reply-To: <3B84E796.EF5E5F39@niisi.msk.ru>
Message-ID: 
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2239
Lines: 43

On Thu, 23 Aug 2001, Gleb O. Raiko wrote:

> Acknowledge. It's used to indicate current transaction has been
> processed successfully. If you are interested in details, I would
> suggest you read a MIPS hardware manual, for example, IDT's one.

 I see if I can find a suitable onein my archive.  I have an IDT CD-ROM,
but it's quite new -- dated 1997 -- and it lacks a lot of earlier stuff.
There is an R5k hw manual there, though, I think.  Too bad they got rid of
end of line stuff -- there is only ~140MB of space consumed on the CD so
there would be much room for reference docs for older parts...

> The most intriguing feature is:
> "Write transactions terminated by BusError* do not require the assertion
> of Ack*. BusError* can be asserted at at any time the processor is
> looking for Ack* to be asserted, up to and including the cycle in which
> the memory system does signal Ack*."

 Interesting.  So bus errors on write transactions seem to be somehow
supported from the hardware's point of view.  But software can't determine
the type of a bus cycle that triggered an error.  E.g. if you expect a
load instruction to trigger a bus error in some cases and you indeed get
one, you can't tell if the error was due to this instruction or due to a
write cycle triggered by some antecedent code.  I think that's the reason
of the suggestion of not using this kind of reporting -- if you limit bus
errors to read/fetch transactions in the ISA definition, you get rid of
this ambiguity. 

> I consider external signaling of write failures may be useful for kernel
> debugging purposes. I agree it's hard (or even impossible) to achieve
> proper behaviour on write failures for user space. There is a small
> chance to kill another process, for example, write transactions may
> delay due to write buffer. So, the kernel may only print something.

 Or, more severly and importantly, a write-back cache.  We provide such
diagnostics but it's dubious for writes.  You are right, it might be
useful for debugging in some cases, though.

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


From owner-linux-mips@oss.sgi.com Thu Aug 23 08:57:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NFvwH30391
	for linux-mips-outgoing; Thu, 23 Aug 2001 08:57:58 -0700
Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NFvqd30388
	for ; Thu, 23 Aug 2001 08:57:52 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22926;
	Thu, 23 Aug 2001 17:59:51 +0200 (MET DST)
Date: Thu, 23 Aug 2001 17:59:51 +0200 (MET DST)
From: "Maciej W. Rozycki" 
To: "Gleb O. Raiko" 
cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
In-Reply-To: <3B84EB2C.7643F00B@niisi.msk.ru>
Message-ID: 
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1504
Lines: 34

On Thu, 23 Aug 2001, Gleb O. Raiko wrote:

> In order to read a PCI ID, you need to know how to do it. In pc world,
> you may rely on configuation access types, at least, ports are known. On
> other arches, you need to know where such "ports" are. Even if hardware
> supports, say, configuration type 1 accesses, developers are free to put
> port addresses anywhere.

 Yep, I see.  MIPS is quite special here, because, unlike for Alphas,
PowerPCs, SPARCs, etc. there is a couple of independend vendors making
systems, so there is no single way of obtaining a system ID.  So you need
to know how to access chipset from elsewhere.

> >  How do you set up mips_machtype on your system in the first place?  At
> > kernel_entry the code does not know what machine it's running on anyway,
> > so it has to set mips_machtype based on a detection algorithm.
> 
> First, mips_machtype is accessed far later than kernel_entry is

 That's quite obvious -- nothing can be done in Linux earlier. ;-)  But
you need to initialize mips_machtype somehow.

> executed. Personally, I am lucky :-), I may read firmware environment
> variables.

 Well, other system might as well (e.g. DECstations can), but that doesn't
solve the problem -- to access firmware variables you need to know which
kind of firmware you are on. 

-- 
+  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 Aug 23 09:51:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NGpBV31530
	for linux-mips-outgoing; Thu, 23 Aug 2001 09:51:11 -0700
Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NGp6d31527
	for ; Thu, 23 Aug 2001 09:51:07 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA23857;
	Thu, 23 Aug 2001 18:52:45 +0200 (MET DST)
Date: Thu, 23 Aug 2001 18:52:45 +0200 (MET DST)
From: "Maciej W. Rozycki" 
Reply-To: "Maciej W. Rozycki" 
To: Keith Owens 
cc: Ralf Baechle , linux-mips@fnet.fr,
   linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 
In-Reply-To: <19339.998531393@kao2.melbourne.sgi.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: 1804
Lines: 47

On Thu, 23 Aug 2001, Keith Owens wrote:

> The definition of struct archdata in kernel and modutils can be
> different, a new kernel layout with an old modutils is legal but fatal
> unless you code for it.  The correct test for archdata is
> 
> if (!mod_member_present(mp, archdata_start) ||
>     (mp->archdata_end - mp->archdata_start) <=
>      offsetof(struct archdata, dbe_table_end))
> 	continue;
> 
> Do not use archdata unless it is at least large enough to contain
> dbe_table_end.  That test also takes care of NULL pointers, end - start
> == 0 for NULL.

 Hmm, your suggested code checks if the passed struct is long enough for
dbe_table_start only -- what about dbe_table_end?  The following code: 

ap = (struct archdata *)(mod->archdata_start);
if (!mod_member_present(mp, archdata_start) ||
    (mp->archdata_end - mp->archdata_start) <
     offsetof(struct archdata, dbe_table_end) + sizeof(ap->dbe_table_end))
      continue;

should be stricter.  While modutils as released won't ever pass a smaller
struct, someone may modify them or use another program to invoke
init_module(), so we need to protect the kernel against bogus data. 

> The rest of the code looks OK, except it needs a global change of
> arch_init_module: to module_arch_init: to match the macro name.

 OK, I'll do it.  It should have been done for ia64 in the first place.
Or should it be changed into "_init_module" to match functions' real
names?

> Do you have the corresponding modutils patch or shall I do it? 

 I've send it to you separately just after the kernel patch.  Should I
resend it? 

  Maciej

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


From owner-linux-mips@oss.sgi.com Thu Aug 23 10:13:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NHDDg32014
	for linux-mips-outgoing; Thu, 23 Aug 2001 10:13:13 -0700
Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NHDAd32010
	for ; Thu, 23 Aug 2001 10:13:10 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7NHFfA26332;
	Thu, 23 Aug 2001 10:15:41 -0700
Message-ID: <3B8537C2.E18E5125@mvista.com>
Date: Thu, 23 Aug 2001 10:05:06 -0700
From: Jun Sun 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" 
CC: "Gleb O. Raiko" , linux-mips@fnet.fr,
   linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2605
Lines: 59

"Maciej W. Rozycki" wrote:
> 
> On Thu, 23 Aug 2001, Gleb O. Raiko wrote:
> 
> > In order to read a PCI ID, you need to know how to do it. In pc world,
> > you may rely on configuation access types, at least, ports are known. On
> > other arches, you need to know where such "ports" are. Even if hardware
> > supports, say, configuration type 1 accesses, developers are free to put
> > port addresses anywhere.
> 
>  Yep, I see.  MIPS is quite special here, because, unlike for Alphas,
> PowerPCs, SPARCs, etc. there is a couple of independend vendors making
> systems, so there is no single way of obtaining a system ID.  So you need
> to know how to access chipset from elsewhere.
> 
> > >  How do you set up mips_machtype on your system in the first place?  At
> > > kernel_entry the code does not know what machine it's running on anyway,
> > > so it has to set mips_machtype based on a detection algorithm.
> >
> > First, mips_machtype is accessed far later than kernel_entry is
> 
>  That's quite obvious -- nothing can be done in Linux earlier. ;-)  But
> you need to initialize mips_machtype somehow.
> 
> > executed. Personally, I am lucky :-), I may read firmware environment
> > variables.
> 
>  Well, other system might as well (e.g. DECstations can), but that doesn't
> solve the problem -- to access firmware variables you need to know which
> kind of firmware you are on.
> 

I talked about machine detection a while back.  My idea is following:

0. all machines that are *configured* into the image will supply _detect()
and _setup() functions.

1. at MIPS start up, we loop through all _detect(), which returns three
values, a) run-time detection negative, b) run-time detection positive, and c)
no run-time detection code, but I return positive because I am configured in.

2. the startup code resolves conflicts (which sometimes may panic); and decide
on one machine.

3. then the startup code calls the right _setup() code which will set up
the mach_type and other stuff. 

BTW, a side benenfit of doing this is that we can remove all the machine
specific code in common files such as bootinfo.h, setup.c, etc, which are
getting harder and harder to maintain as we are adding more and more embedded
boards to the tree.  

If we push it to an extreme by using mechnism like do_initcalls(), we can
achieve zero common source file modification when adding a new a machine. 
This will greatly facilitate embedded development as it allows more parallel
development and allow people to maintain their own board code much easier
before the code is submitted to the tree.

Jun

From owner-linux-mips@oss.sgi.com Thu Aug 23 10:29:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NHTYS32729
	for linux-mips-outgoing; Thu, 23 Aug 2001 10:29:34 -0700
Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NHTVd32726
	for ; Thu, 23 Aug 2001 10:29:31 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA24561;
	Thu, 23 Aug 2001 19:31:46 +0200 (MET DST)
Date: Thu, 23 Aug 2001 19:31:46 +0200 (MET DST)
From: "Maciej W. Rozycki" 
To: Jun Sun 
cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
In-Reply-To: <3B8537C2.E18E5125@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: 1008
Lines: 25

On Thu, 23 Aug 2001, Jun Sun wrote:

> I talked about machine detection a while back.  My idea is following:
> 
> 0. all machines that are *configured* into the image will supply _detect()
> and _setup() functions.
> 
> 1. at MIPS start up, we loop through all _detect(), which returns three
> values, a) run-time detection negative, b) run-time detection positive, and c)
> no run-time detection code, but I return positive because I am configured in.
> 
> 2. the startup code resolves conflicts (which sometimes may panic); and decide
> on one machine.
> 
> 3. then the startup code calls the right _setup() code which will set up
> the mach_type and other stuff. 

 It sounds reasonable.  We may also check the Alpha port for solutions --
it supports multiple dissimilar systems as well.

-- 
+  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 Aug 23 13:13:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NKDFF03933
	for linux-mips-outgoing; Thu, 23 Aug 2001 13:13:15 -0700
Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NKDCd03930
	for ; Thu, 23 Aug 2001 13:13:13 -0700
Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66])
	by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id FAA14539;
	Fri, 24 Aug 2001 05:12:35 +0900 (JST)
Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317)
	id FAA10611; Fri, 24 Aug 2001 05:12:35 +0900 (JST)
Received: from eecksm.sdel.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id FAA07209; Fri, 24 Aug 2001 05:12:34 +0900 (JST)
Received: from HirooPC (kddlos0115.mobile.toshiba.co.jp [10.16.11.34])
	by eecksm.sdel.toshiba.co.jp (Postfix) with SMTP
	id 848A0BAE3F; Fri, 24 Aug 2001 05:12:30 +0900 (JST)
From: "Hiroo Hayashi" 
To: "Maciej W. Rozycki" ,
   "Gleb O. Raiko" 
Cc: , 
Subject: bus error by write transaction (RE: [patch] linux 2.4.5: Make __dbe_table available to modules)
Date: Thu, 23 Aug 2001 15:11:33 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1156
Lines: 28

Hi,

> > I consider external signaling of write failures may be useful for kernel
> > debugging purposes. I agree it's hard (or even impossible) to achieve
> > proper behaviour on write failures for user space. There is a small
> > chance to kill another process, for example, write transactions may
> > delay due to write buffer. So, the kernel may only print something.
> 
>  Or, more severly and importantly, a write-back cache.  We provide such
> diagnostics but it's dubious for writes.  You are right, it might be
> useful for debugging in some cases, though.

Yes, most MIPS CPU except very old one use writeback cache.

Note that most MIPS documents use word 'load' and 'store' for instruction,
and 'read' and 'write' for bus transaction.  You have to distinguish them.

On a system with writeback cache, a write bus transaction is issued when
a modified cache line is replaced by a cache miss for either load
instruction or store instruction.

(Here I'm ignoring I/O access to make the point clear.)

The data on a write bus transaction may be a data modified by a store
instruction which was issued some years ago :-)  What the OS can do?

Hiro


From owner-linux-mips@oss.sgi.com Thu Aug 23 16:11:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7NNBJh03644
	for linux-mips-outgoing; Thu, 23 Aug 2001 16:11:19 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7NNBEd03640
	for ; Thu, 23 Aug 2001 16:11:14 -0700
Received: (qmail 24922 invoked from network); 23 Aug 2001 23:11:09 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 23 Aug 2001 23:11:09 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens 
To: "Maciej W. Rozycki" 
cc: Ralf Baechle , linux-mips@fnet.fr,
   linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 
In-reply-to: Your message of "Thu, 23 Aug 2001 18:52:45 +0200."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Aug 2001 09:11:09 +1000
Message-ID: <17182.998608269@ocs3.ocs-net>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 2358
Lines: 54

On Thu, 23 Aug 2001 18:52:45 +0200 (MET DST), 
"Maciej W. Rozycki"  wrote:
>On Thu, 23 Aug 2001, Keith Owens wrote:
>> The definition of struct archdata in kernel and modutils can be
>> different, a new kernel layout with an old modutils is legal but fatal
>> unless you code for it.  The correct test for archdata is
>> 
>> if (!mod_member_present(mp, archdata_start) ||
>>     (mp->archdata_end - mp->archdata_start) <=
>>      offsetof(struct archdata, dbe_table_end))
>> 	continue;
> Hmm, your suggested code checks if the passed struct is long enough for
>dbe_table_start only -- what about dbe_table_end?  The following code: 

If archdata_end-archdata_start <= offsetof(dbe_table_end) then archdata
is too small to contain the first byte of dbe_table_end, skip the
archdata.  If archdata is large enough to contain the first byte of
dbe_table_end, assume that it contains all of dbe_table_end.

>While modutils as released won't ever pass a smaller
>struct, someone may modify them or use another program to invoke
>init_module(), so we need to protect the kernel against bogus data. 

You have to be root to call init_module() or run insmod, root can do a
lot more damage than passing an invalid structure size.  This type of
test is not to catch malicious code, it is to detect that the user is
running an old modutils with a smaller archdata than the kernel can
handle.

You are correct that modutils as released will never pass a smaller
archdata struct for mips so strictly speaking this test is superfluous.
However this type of code gets cut and pasted so I want size checking
on all archdata, when it is copied the developer has to think about
changing the test instead of forgetting to add a test.

Your suggested code works just as well but is less readable.  Go with
either.

>> The rest of the code looks OK, except it needs a global change of
>> arch_init_module: to module_arch_init: to match the macro name.
>
> OK, I'll do it.  It should have been done for ia64 in the first place.
>Or should it be changed into "_init_module" to match functions' real
>names?

Leave it as module_arch_init, it tells us how the code was called.

>> Do you have the corresponding modutils patch or shall I do it? 
>
> I've send it to you separately just after the kernel patch.  Should I
>resend it? 

No thanks, I found it.


From owner-linux-mips@oss.sgi.com Fri Aug 24 01:01:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7O81rj06913
	for linux-mips-outgoing; Fri, 24 Aug 2001 01:01:53 -0700
Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O81od06910
	for ; Fri, 24 Aug 2001 01:01:51 -0700
Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 24 Aug 2001 08:01:50 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP
	id 0C8B254C12; Fri, 24 Aug 2001 17:01:47 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id RAA91025; Fri, 24 Aug 2001 17:01:46 +0900 (JST)
Date: Fri, 24 Aug 2001 17:06:21 +0900 (JST)
Message-Id: <20010824.170621.85418510.nemoto@toshiba-tops.co.jp>
To: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Cc: Ralf Baechle 
Subject: get_insn_opcode is broken (ll/sc emulation does not work)
From: Atsushi Nemoto 
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
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: 367
Lines: 20

I found that get_insn_opcode(in traps.c) is broken.


static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode)
...
	if (!get_user(opcode, epc))


This must be:


static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode)
...
	if (!get_user(*opcode, epc))


Without this fix, ll/sc emulation might not work.

---
Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Fri Aug 24 02:02:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7O92Ci08204
	for linux-mips-outgoing; Fri, 24 Aug 2001 02:02:12 -0700
Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7O91xd08199;
	Fri, 24 Aug 2001 02:02:00 -0700
Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 24 Aug 2001 09:01:59 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP
	id EDFA354C16; Fri, 24 Aug 2001 18:01:57 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id SAA91181; Fri, 24 Aug 2001 18:01:56 +0900 (JST)
Date: Fri, 24 Aug 2001 18:06:32 +0900 (JST)
Message-Id: <20010824.180632.39150208.nemoto@toshiba-tops.co.jp>
To: ralf@oss.sgi.com
Cc: carstenl@mips.com, wgowcher@yahoo.com, linux-mips@oss.sgi.com
Subject: Re: Benchmark performance
From: Atsushi Nemoto 
In-Reply-To: <20010816131422.B17970@bacchus.dhis.org>
References: <20010816111803.A17469@bacchus.dhis.org>
	<3B7BA970.56192BB8@mips.com>
	<20010816131422.B17970@bacchus.dhis.org>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
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: 509
Lines: 18

>>>>> On Thu, 16 Aug 2001 13:14:22 +0200, Ralf Baechle  said:
ralf> I'm just about to put it into CVS.

Please apply this small patch...

--- linux.sgi/arch/mips/math-emu/cp1emu.c	Fri Aug 24 17:57:36 2001
+++ linux/arch/mips/math-emu/cp1emu.c	Fri Aug 24 17:57:48 2001
@@ -1675,7 +1675,7 @@
 	oldepc = xcp->cp0_epc;
 	do {
 		if (current->need_resched)
-			schedule;
+			schedule();
 
 		prevepc = xcp->cp0_epc;
 		insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err);
---
Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Fri Aug 24 04:31:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7OBVW111247
	for linux-mips-outgoing; Fri, 24 Aug 2001 04:31:32 -0700
Received: from dea.linux-mips.net (u-138-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.138])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OBVSd11244
	for ; Fri, 24 Aug 2001 04:31:29 -0700
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.1/8.11.1) id f7OBSRo00426;
	Fri, 24 Aug 2001 13:28:27 +0200
Date: Fri, 24 Aug 2001 13:28:27 +0200
From: Ralf Baechle 
To: Atsushi Nemoto 
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: get_insn_opcode is broken (ll/sc emulation does not work)
Message-ID: <20010824132827.B325@dea.linux-mips.net>
References: <20010824.170621.85418510.nemoto@toshiba-tops.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: <20010824.170621.85418510.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Aug 24, 2001 at 05:06:21PM +0900
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 266
Lines: 12

On Fri, Aug 24, 2001 at 05:06:21PM +0900, Atsushi Nemoto wrote:

> I found that get_insn_opcode(in traps.c) is broken.
> 
> 
> static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode)
> ...
> 	if (!get_user(opcode, epc))

Thanks, fixed!

  Ralf

From owner-linux-mips@oss.sgi.com Fri Aug 24 04:54:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7OBsdV11745
	for linux-mips-outgoing; Fri, 24 Aug 2001 04:54:39 -0700
Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OBsZd11741
	for ; Fri, 24 Aug 2001 04:54:35 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA29920;
	Fri, 24 Aug 2001 15:54:19 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA00514; Fri, 24 Aug 2001 15:30:14 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA20010; Fri, 24 Aug 2001 13:37:24 +0400 (MSD)
Message-ID: <3B86206C.832A9801@niisi.msk.ru>
Date: Fri, 24 Aug 2001 13:37:48 +0400
From: "Gleb O. Raiko" 
Organization: NIISI RAN
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Maciej W. Rozycki" 
CC: Jun Sun , linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
References: 
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 1022
Lines: 26

"Maciej W. Rozycki" wrote:
>  It sounds reasonable.  We may also check the Alpha port for solutions --
> it supports multiple dissimilar systems as well.

Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at
fixed location anyway. 

In our case, almost every box has own location for kernel varying from
0x80000000 for brave people to 0x80100000 for people who doesn't care
much about 1 MB :-). (Well, I clearly understand it's firmware
requirements, not people's preferences. Almost.) Then, various binary
formats of the kernel image...

I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP
stuff.

However, I doubt whether we could support single kernel image for all
MIPS boxes. MIPS is typical embedded platform, where standards are
favourite because there are so many to choose from.

BTW, I remember, Ralf tried to implement CPU type recognition at
run-time, he dropped his efforts after he realized nobody could use this
feature because boxes are so different.

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Fri Aug 24 04:54:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7OBspp11807
	for linux-mips-outgoing; Fri, 24 Aug 2001 04:54:51 -0700
Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OBsRd11740
	for ; Fri, 24 Aug 2001 04:54:29 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA29899
	for ; Fri, 24 Aug 2001 15:54:16 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA00518 for linux-mips@oss.sgi.com; Fri, 24 Aug 2001 15:30:17 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA20624 for ; Fri, 24 Aug 2001 13:54:57 +0400 (MSD)
Message-ID: <3B862487.EF22D143@niisi.msk.ru>
Date: Fri, 24 Aug 2001 13:55:19 +0400
From: "Gleb O. Raiko" 
Organization: NIISI RAN
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "linux-mips@oss.sgi.com" 
Subject: arch/mips/pci* stuff
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 429
Lines: 14

Hello,

Could somebody, please, explain me what arch/mips/pci* stuff is for? My
understanding is drivers/pci code shall setup everything except proper
placing in PCI MEM/IO spaces and irqs. The code in arch/mips/pci*
contains much more.

Anyway, drivers/pci code provides enough fixup interface, doesn't it ?

BTW, if the code in arch/mips/pci* is really required how about
fine-grained placing, like in sparc64?

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Fri Aug 24 04:55:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7OBtIw11872
	for linux-mips-outgoing; Fri, 24 Aug 2001 04:55:18 -0700
Received: from t111.niisi.ras.ru (IDENT:root@[193.232.173.111])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OBsqd11818
	for ; Fri, 24 Aug 2001 04:55:16 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA29917;
	Fri, 24 Aug 2001 15:54:18 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA00515; Fri, 24 Aug 2001 15:30:15 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA20181; Fri, 24 Aug 2001 13:41:50 +0400 (MSD)
Message-ID: <3B862174.435C0324@niisi.msk.ru>
Date: Fri, 24 Aug 2001 13:42:12 +0400
From: "Gleb O. Raiko" 
Organization: NIISI RAN
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Maciej W. Rozycki" 
CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
References: 
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 348
Lines: 11

"Maciej W. Rozycki" wrote:
>  Well, other system might as well (e.g. DECstations can), but that doesn't
> solve the problem -- to access firmware variables you need to know which
> kind of firmware you are on.
> 

No way at run-time. You have to choose the box during compilation in
order to supply linker with proper load address.

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Fri Aug 24 08:43:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.2/8.11.3) id f7OFhM616898
	for linux-mips-outgoing; Fri, 24 Aug 2001 08:43:22 -0700
Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1])
	by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7OFgod16886
	for ; Fri, 24 Aug 2001 08:42:50 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15682;
	Fri, 24 Aug 2001 17:44:09 +0200 (MET DST)
Date: Fri, 24 Aug 2001 17:44:08 +0200 (MET DST)
From: "Maciej W. Rozycki" 
Reply-To: "Maciej W. Rozycki" 
To: Keith Owens 
cc: Ralf Baechle , linux-mips@fnet.fr,
   linux-mips@oss.sgi.com
Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 
In-Reply-To: <17182.998608269@ocs3.ocs-net>
Message-ID: 
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Content-Length: 22087
Lines: 614

On Fri, 24 Aug 2001, Keith Owens wrote:

> You have to be root to call init_module() or run insmod, root can do a
> lot more damage than passing an invalid structure size.  This type of
> test is not to catch malicious code, it is to detect that the user is
> running an old modutils with a smaller archdata than the kernel can
> handle.

 I mean it as a test to catch buggy, not malicious code.  For malicious
code run by root there is not much to do.  Besides, the code is not any
longer nor slower.  Adding a case-specific small constant instead of fixed
one is achieved via the same processor's instructions -- only their
operands differ. 

> You are correct that modutils as released will never pass a smaller
> archdata struct for mips so strictly speaking this test is superfluous.
> However this type of code gets cut and pasted so I want size checking
> on all archdata, when it is copied the developer has to think about
> changing the test instead of forgetting to add a test.

 Sure, agreed.  For this reason the ia64 code need a bit of cleanup, too. 

> Your suggested code works just as well but is less readable.  Go with
> either.

 Ok, that's not much readable, indeed.  Thus I've invented a macro.  See
a following patch hiding implementation details.

> Leave it as module_arch_init, it tells us how the code was called.

 OK.

  Maciej

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

patch-mips-2.4.5-20010704-dbe-13
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c
--- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c	Fri Jun 15 04:27:07 2001
+++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c	Fri Aug 24 00:58:00 2001
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -254,23 +256,68 @@ search_one_table(const struct exception_
 	return (first == last && first->insn == value) ? first->nextinsn : 0;
 }
 
-#define search_dbe_table(addr)	\
-	search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr))
+extern spinlock_t modlist_lock;
+
+static inline unsigned long
+search_dbe_table(unsigned long addr)
+{
+	unsigned long ret = 0;
+
+#ifndef CONFIG_MODULES
+	/* There is only the kernel to search.  */
+	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_end) ||
+        	    !mod_archdata_member_present(mp, struct archdata,
+						 dbe_table_end))
+			continue;
+		ap = (struct archdata *)(mp->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
+}
 
 static void default_be_board_handler(struct pt_regs *regs)
 {
 	unsigned long new_epc;
-	unsigned long fixup = search_dbe_table(regs->cp0_epc);
+	unsigned long fixup;
+	int data = regs->cp0_cause & 4;
 
-	if (fixup) {
-		new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc);
-		regs->cp0_epc = new_epc;
-		return;
+	if (data && !user_mode(regs)) {
+		fixup = search_dbe_table(regs->cp0_epc);
+		if (fixup) {
+			new_epc = fixup_exception(dpf_reg, fixup,
+						  regs->cp0_epc);
+			regs->cp0_epc = new_epc;
+			return;
+		}
 	}
 
 	/*
 	 * Assume it would be too dangerous to continue ...
 	 */
+	printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n",
+	       data ? "Data" : "Instruction",
+	       regs->cp0_epc, regs->regs[31]);
+	die_if_kernel("Oops", regs);
 	force_sig(SIGBUS, current);
 }
 
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c
--- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c	Thu Feb 24 05:26:11 2000
+++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c	Fri Aug 24 00:58:38 2001
@@ -9,6 +9,9 @@
  */
 #include 
 #include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -41,16 +44,43 @@ search_one_table(const struct exception_
 	return 0;
 }
 
+extern spinlock_t modlist_lock;
+
 static inline unsigned long
 search_dbe_table(unsigned long addr)
 {
-	unsigned long ret;
+	unsigned long ret = 0;
 
+#ifndef CONFIG_MODULES
 	/* There is only the kernel to search.  */
 	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
-	if (ret) return ret;
-
-	return 0;
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_end) ||
+        	    !mod_archdata_member_present(mp, struct archdata,
+						 dbe_table_end))
+			continue;
+		ap = (struct archdata *)(mod->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
 }
 
 void do_ibe(struct pt_regs *regs)
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c
--- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c	Sat Feb 24 05:26:18 2001
+++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c	Fri Aug 24 00:58:47 2001
@@ -8,6 +8,9 @@
  */
 #include 
 #include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -43,16 +46,43 @@ search_one_table(const struct exception_
 	return 0;
 }
 
+extern spinlock_t modlist_lock;
+
 static inline unsigned long
 search_dbe_table(unsigned long addr)
 {
 	unsigned long ret;
 
+#ifndef CONFIG_MODULES
 	/* There is only the kernel to search.  */
 	ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
-	if (ret) return ret;
-
-	return 0;
+	return ret;
+#else
+	unsigned long flags;
+
+	/* The kernel is the last "module" -- no need to treat it special.  */
+	struct module *mp;
+	struct archdata *ap;
+
+	spin_lock_irqsave(&modlist_lock, flags);
+	for (mp = module_list; mp != NULL; mp = mp->next) {
+		if (!mod_member_present(mp, archdata_end) ||
+        	    !mod_archdata_member_present(mp, struct archdata,
+						 dbe_table_end))
+			continue;
+		ap = (struct archdata *)(mod->archdata_start);
+
+		if (ap->dbe_table_start == NULL ||
+		    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
+			continue;
+		ret = search_one_table(ap->dbe_table_start,
+				       ap->dbe_table_end - 1, addr);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
+	return ret;
+#endif
 }
 
 void do_ibe(struct pt_regs *regs)
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h linux-mips-2.4.5-20010704/include/asm-alpha/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-alpha/module.h	Fri Aug 24 00:59:47 2001
@@ -6,6 +6,23 @@
 
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	alpha_module_init(x)
+#define arch_init_modules(x)	alpha_init_modules(x)
+
+static inline int
+alpha_module_init(struct module *mod)
+{
+        if (!mod_bound(mod->gp - 0x8000, 0, mod)) {
+                printk(KERN_ERR "module_arch_init: mod->gp out of bounds.\n");
+                return 1;
+        }
+	return 0;
+}
+
+static inline void
+alpha_init_modules(struct module *mod)
+{
+	__asm__("stq $29,%0" : "=m" (mod->gp));
+}
 
 #endif /* _ASM_ALPHA_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h linux-mips-2.4.5-20010704/include/asm-arm/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-arm/module.h	Mon Aug 20 01:11:58 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_ARM_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h linux-mips-2.4.5-20010704/include/asm-cris/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h	Fri Mar  9 20:34:43 2001
+++ linux-mips-2.4.5-20010704/include/asm-cris/module.h	Mon Aug 20 01:12:04 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_CRIS_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h linux-mips-2.4.5-20010704/include/asm-i386/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-i386/module.h	Mon Aug 20 01:12:08 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_I386_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h linux-mips-2.4.5-20010704/include/asm-ia64/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h	Thu Jun 14 04:28:30 2001
+++ linux-mips-2.4.5-20010704/include/asm-ia64/module.h	Fri Aug 24 01:03:17 2001
@@ -14,6 +14,7 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		ia64_module_unmap(x)
 #define module_arch_init(x)	ia64_module_init(x)
+#define ia64_module_inits(x)	do { } while (0)
 
 /*
  * This must match in size and layout the data created by
@@ -46,27 +47,27 @@ ia64_module_init(struct module *mod)
 
 	if (archdata->unw_table)
 	{
-		printk(KERN_ERR "arch_init_module: archdata->unw_table must be zero.\n");
+		printk(KERN_ERR "module_arch_init: archdata->unw_table must be zero.\n");
 		return 1;
 	}
 	if (!mod_bound(archdata->gp, 0, mod))
 	{
-		printk(KERN_ERR "arch_init_module: archdata->gp out of bounds.\n");
+		printk(KERN_ERR "module_arch_init: archdata->gp out of bounds.\n");
 		return 1;
 	}
 	if (!mod_bound(archdata->unw_start, 0, mod))
 	{
-		printk(KERN_ERR "arch_init_module: archdata->unw_start out of bounds.\n");
+		printk(KERN_ERR "module_arch_init: archdata->unw_start out of bounds.\n");
 		return 1;
 	}
 	if (!mod_bound(archdata->unw_end, 0, mod))
 	{
-		printk(KERN_ERR "arch_init_module: archdata->unw_end out of bounds.\n");
+		printk(KERN_ERR "module_arch_init: archdata->unw_end out of bounds.\n");
 		return 1;
 	}
 	if (!mod_bound(archdata->segment_base, 0, mod))
 	{
-		printk(KERN_ERR "arch_init_module: archdata->unw_table out of bounds.\n");
+		printk(KERN_ERR "module_arch_init: archdata->unw_table out of bounds.\n");
 		return 1;
 	}
 
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h linux-mips-2.4.5-20010704/include/asm-m68k/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-m68k/module.h	Mon Aug 20 01:12:18 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_M68K_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h linux-mips-2.4.5-20010704/include/asm-mips/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-mips/module.h	Fri Aug 24 00:54:50 2001
@@ -4,8 +4,64 @@
  * This file contains the mips architecture specific module code.
  */
 
+#include 
+#include 
+
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	mips_module_init(x)
+#define arch_init_modules(x)	mips_init_modules(x)
+
+/*
+ * This must match in size and layout the data created by
+ * modutils/obj/obj-mips.c
+ */
+struct archdata {
+	const struct exception_table_entry *dbe_table_start;
+	const struct exception_table_entry *dbe_table_end;
+};
+
+static inline int
+mips_module_init(struct module *mod)
+{
+	struct archdata *archdata;
+
+	if (!mod_member_present(mod, archdata_end))
+		return 0;
+
+	archdata = (struct archdata *)(mod->archdata_start);
+	if (!mod_archdata_member_present(mod, struct archdata, dbe_table_end))
+		return 0;
+
+	if (archdata->dbe_table_start > archdata->dbe_table_end ||
+	    (archdata->dbe_table_start &&
+	     !((unsigned long)archdata->dbe_table_start >=
+	       ((unsigned long)mod + mod->size_of_struct) &&
+	       ((unsigned long)archdata->dbe_table_end <
+	        (unsigned long)mod + mod->size))) ||
+            (((unsigned long)archdata->dbe_table_start -
+	      (unsigned long)archdata->dbe_table_end) %
+	     sizeof(struct exception_table_entry))) {
+		printk(KERN_ERR
+			"module_arch_init: archdata->dbe_table_* invalid.\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+static inline void
+mips_init_modules(struct module *mod)
+{
+	extern const struct exception_table_entry __start___dbe_table[];
+	extern const struct exception_table_entry __stop___dbe_table[];
+	static struct archdata archdata = {
+		dbe_table_start:	__start___dbe_table,
+		dbe_table_end:		__stop___dbe_table,
+	};
+
+	mod->archdata_start = (char *)&archdata;
+	mod->archdata_end = mod->archdata_start + sizeof(archdata);
+}
 
 #endif /* _ASM_MIPS_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h linux-mips-2.4.5-20010704/include/asm-mips64/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-mips64/module.h	Fri Aug 24 00:55:00 2001
@@ -4,8 +4,64 @@
  * This file contains the mips64 architecture specific module code.
  */
 
+#include 
+#include 
+
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
-#define module_arch_init(x)	(0)
+#define module_arch_init(x)	mips64_module_init(x)
+#define arch_init_modules(x)	mips64_init_modules(x)
+
+/*
+ * This must match in size and layout the data created by
+ * modutils/obj/obj-mips64.c
+ */
+struct archdata {
+	const struct exception_table_entry *dbe_table_start;
+	const struct exception_table_entry *dbe_table_end;
+};
+
+static inline int
+mips64_module_init(struct module *mod)
+{
+	struct archdata *archdata;
+
+	if (!mod_member_present(mod, archdata_end))
+		return 0;
+
+	archdata = (struct archdata *)(mod->archdata_start);
+	if (!mod_archdata_member_present(mod, struct archdata, dbe_table_end))
+		return 0;
+
+	if (archdata->dbe_table_start > archdata->dbe_table_end ||
+	    (archdata->dbe_table_start &&
+	     !((unsigned long)archdata->dbe_table_start >=
+	       ((unsigned long)mod + mod->size_of_struct) &&
+	       ((unsigned long)archdata->dbe_table_end <
+	        (unsigned long)mod + mod->size))) ||
+            (((unsigned long)archdata->dbe_table_start -
+	      (unsigned long)archdata->dbe_table_end) %
+	     sizeof(struct exception_table_entry))) {
+		printk(KERN_ERR
+			"module_arch_init: archdata->dbe_table_* invalid.\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+static inline void
+mips64_init_modules(struct module *mod)
+{
+	extern const struct exception_table_entry __start___dbe_table[];
+	extern const struct exception_table_entry __stop___dbe_table[];
+	static struct archdata archdata = {
+		dbe_table_start:	__start___dbe_table,
+		dbe_table_end:		__stop___dbe_table,
+	};
+
+	mod->archdata_start = (char *)&archdata;
+	mod->archdata_end = mod->archdata_start + sizeof(archdata);
+}
 
 #endif /* _ASM_MIPS64_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h linux-mips-2.4.5-20010704/include/asm-ppc/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h	Thu Jun 14 04:28:38 2001
+++ linux-mips-2.4.5-20010704/include/asm-ppc/module.h	Mon Aug 20 01:12:29 2001
@@ -10,5 +10,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_PPC_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h linux-mips-2.4.5-20010704/include/asm-s390/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h	Tue Nov 28 03:59:03 2000
+++ linux-mips-2.4.5-20010704/include/asm-s390/module.h	Mon Aug 20 01:12:37 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_S390_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h linux-mips-2.4.5-20010704/include/asm-s390x/module.h
--- linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h	Fri Mar  9 20:34:52 2001
+++ linux-mips-2.4.5-20010704/include/asm-s390x/module.h	Mon Aug 20 01:12:53 2001
@@ -7,5 +7,6 @@
 #define module_map(x)		vmalloc(x)
 #define module_unmap(x)		vfree(x)
 #define module_arch_init(x)	(0)
+#define arch_init_modules(x)	do { } while (0)
 
 #endif /* _ASM_S390_MODULE_H */
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h linux-mips-2.4.5-20010704/include/asm-sh/modu