From owner-linux-mips@oss.sgi.com Mon Apr 1 14:16:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31MGu401863 for linux-mips-outgoing; Mon, 1 Apr 2002 14:16:56 -0800 Received: from mailhost.uni-koblenz.de (root@mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31MGpo01830; Mon, 1 Apr 2002 14:16:51 -0800 Received: from eddie (eddie.uni-koblenz.de [141.26.64.59]) by mailhost.uni-koblenz.de (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g31MGnt00419; Tue, 2 Apr 2002 00:16:49 +0200 Received: from dea.linux-mips.net by eddie (SMI-8.6/KO-2.0) id AAA20962; Tue, 2 Apr 2002 00:16:48 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g31MGe103667; Mon, 1 Apr 2002 14:16:40 -0800 Date: Mon, 1 Apr 2002 14:16:40 -0800 From: Ralf Baechle To: Florian Lohoff Cc: Raoul Borenius , linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020401141640.A3643@dea.linux-mips.net> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> <20020330132856.GA24305@bunny.shuttle.de> <20020331150023.GA30224@bunny.shuttle.de> <20020401192957.GA1389@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: <20020401192957.GA1389@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Apr 01, 2002 at 09:29:57PM +0200 X-Accept-Language: de,en,fr X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 01, 2002 at 09:29:57PM +0200, Florian Lohoff wrote: > > Could you commit that too? > > > > I thought the callout devices are officially "dead" and should disappear > "Real Soon Now(tm)" as beeing a locking hell and unneeded. Really Soon Now doesn't mean what you want it to mean in a world that is driven by backward compatibility ... Ralf From owner-linux-mips@oss.sgi.com Mon Apr 1 14:12:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31MCtJ01475 for linux-mips-outgoing; Mon, 1 Apr 2002 14:12:55 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31MCjo01432; Mon, 1 Apr 2002 14:12:45 -0800 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA21785; Mon, 1 Apr 2002 11:39:03 -0800 (PST) mail_from (flo@rfc822.org) Received: by noose.gt.owl.de (Postfix, from userid 10) id 623A97F6; Mon, 1 Apr 2002 21:30:22 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 85A573704F; Mon, 1 Apr 2002 21:29:57 +0200 (CEST) Date: Mon, 1 Apr 2002 21:29:57 +0200 From: Florian Lohoff To: Raoul Borenius Cc: Ralf Baechle , linux-mips@oss.sgi.com, devfs@oss.sgi.com Subject: Re: broken devfs-support in SGI Zilog8530 serial driver Message-ID: <20020401192957.GA1389@paradigm.rfc822.org> References: <20020329103244.GA15765@bunny.shuttle.de> <20020329233559.A31160@dea.linux-mips.net> <20020330132856.GA24305@bunny.shuttle.de> <20020331150023.GA30224@bunny.shuttle.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20020331150023.GA30224@bunny.shuttle.de> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 31, 2002 at 05:00:23PM +0200, Raoul Borenius wrote: > Thanks for including the changes fr the ttyS's. But it seems you forgot t= he > callout-devices: >=20 > > @@ -1911,7 +1915,11 @@ > > * major number and the subtype code. > > */ > > callout_driver =3D serial_driver; > > +#ifdef CONFIG_DEVFS_FS > > + callout_driver.name =3D "cua/%d"; > > +#else > > callout_driver.name =3D "cua"; > > +#endif > > callout_driver.major =3D TTYAUX_MAJOR; > > callout_driver.subtype =3D SERIAL_TYPE_CALLOUT; > >=20 >=20 > Could you commit that too? >=20 I thought the callout devices are officially "dead" and should disappear "Real Soon Now(tm)" as beeing a locking hell and unneeded. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8qLU1Uaz2rXW+gJcRAjZpAJ9uVKLMj8Wgx6VQgc9W9IrpM7c+kACeMD0q BPbPAsgBEFTXxJrcTz2tUeQ= =QeeF -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-linux-mips@oss.sgi.com Mon Apr 8 01:27:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g388RcVK022601 for ; Mon, 8 Apr 2002 01:27:38 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g388Rcwh022600 for linux-mips-outgoing; Mon, 8 Apr 2002 01:27:38 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx15.freecom.ne.jp (mx15.freecom.ne.jp [210.235.164.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g388RXVK022594 for ; Mon, 8 Apr 2002 01:27:33 -0700 Received: (qmail 24422 invoked by alias); 8 Apr 2002 16:45:55 +0900 Received: (qmail 27433 invoked from network); 8 Apr 2002 16:20:44 +0900 Received: from unknown (HELO jobin.mx15.freecom.ne.jp) (203.104.146.240) by mx15.freecom.ne.jp with SMTP; 8 Apr 2002 16:20:44 +0900 Message-Id: <5.0.2.5.2.20020408155359.00c5fd00@mx15.freecom.ne.jp> X-Sender: asdd@mx15.freecom.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Mon, 08 Apr 2002 15:54:00 +0900 To: (Recipient list suppressed) From: sender Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISpFPj8mJTUhPCVTJTkbKEI=?= Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -------------------------------- $B"#A49q$N?M:`%P%s%/$XE>?&$N(B $B0l3g%(%s%H%j!?&%5%$%H$NJs=7@)%P%J!?&5a?&5G'(B $B?t$K1~$8$F!X(B1000$B1_(B/$B7o!Y99$KE>?&7h(B $BDj$G4pK\E*$K!X(B1O$BK|1_(B/$B7o!Y$r$*;YJ'(B $B$$CW$7$^$9!#(B $B"(1?1D\:Y$r$*Aw$j(B $BCW$7$^$9!#!c>\:Y4uK>!d(B bancom@bigfoot.com$B!!(B $B%3%`%W%i%s4k2h(B($B%8%g%V%5!<%S%9(B) -------------------------------- $B"(!Z2r=|![$O?=$7Lu$4$6$$$^$;$s$,(B $B!!2<5-$X!Z6u%a!<%k![$r$*Aw$j$/$@(B $B!!$5$k$h$&$*4j$$?=$7$"$2$^$9!#(B dm_delet@bigfoot.com -------------------------------- From owner-linux-mips@oss.sgi.com Mon Apr 8 10:06:40 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38H6e8d031043 for ; Mon, 8 Apr 2002 10:06:40 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38H6ewB031042 for linux-mips-outgoing; Mon, 8 Apr 2002 10:06:40 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38H6B8d031036 for ; Mon, 8 Apr 2002 10:06:11 -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 KAA02773 for ; Mon, 8 Apr 2002 10:06:45 -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 SAA08007; Mon, 8 Apr 2002 18:37:30 +0200 (MET DST) Date: Mon, 8 Apr 2002 18:37:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A correct implementation of barriers 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 Hello, Here is the barrier patch again. It was discussed quite extensively a few weeks ago. It makes rmb(), wmb() and mb() use sync as needed (Tx39xx included) and take writeback buffers into account (no Tx39xx code here -- someone interested in such a system should add it). It also adds iob() for code that needs to assure not only the order of the preceding and the following operations but also the completion of the preceding ones as well (from the CPU's point of view). 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.17-20020129-mb-wb-6 diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/arch/mips/config.in linux-mips-2.4.17-20020129/arch/mips/config.in --- linux-mips-2.4.17-20020129.macro/arch/mips/config.in Fri Jan 25 05:26:34 2002 +++ linux-mips-2.4.17-20020129/arch/mips/config.in Thu Feb 21 21:31:42 2002 @@ -384,6 +384,11 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" ]; then + define_bool CONFIG_CPU_HAS_SYNC n +else + define_bool CONFIG_CPU_HAS_SYNC y +fi endmenu mainmenu_option next_comment diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips/system.h linux-mips-2.4.17-20020129/include/asm-mips/system.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips/system.h Sun Jan 27 05:27:59 2002 +++ linux-mips-2.4.17-20020129/include/asm-mips/system.h Thu Feb 21 21:33:54 2002 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,58 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli(); #define local_irq_enable() __sti(); -/* - * These are probably defined overly paranoid ... - */ +#ifdef CONFIG_CPU_HAS_SYNC +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + ".set mips2\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") +#else +#define __sync() do { } while(0) +#endif + +#define __fast_iob() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __fast_iob(); \ + } while (0) + #ifdef CONFIG_CPU_HAS_WB #include -#define rmb() do { } while(0) -#define wmb() wbflush() -#define mb() wbflush() - -#else /* CONFIG_CPU_HAS_WB */ - -#define mb() \ -__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 rmb() mb() -#define wmb() mb() -#endif /* CONFIG_CPU_HAS_WB */ +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() wbflush(); +#define iob() wbflush(); + +#else /* !CONFIG_CPU_HAS_WB */ + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips/wbflush.h linux-mips-2.4.17-20020129/include/asm-mips/wbflush.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips/wbflush.h Fri Sep 7 04:26:33 2001 +++ linux-mips-2.4.17-20020129/include/asm-mips/wbflush.h Mon Feb 4 02:52:11 2002 @@ -6,29 +6,30 @@ * for more details. * * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ #ifndef __ASM_MIPS_WBFLUSH_H #define __ASM_MIPS_WBFLUSH_H #include -#if defined(CONFIG_CPU_HAS_WB) -/* - * R2000 or R3000 - */ -extern void (*__wbflush) (void); +#ifdef CONFIG_CPU_HAS_WB -#define wbflush() __wbflush() +extern void (*__wbflush)(void); +extern void wbflush_setup(void); -#else -/* - * we don't need no stinkin' wbflush - */ +#define wbflush() \ + do { \ + __sync(); \ + __wbflush(); \ + } while (0) -#define wbflush() do { } while(0) +#else /* !CONFIG_CPU_HAS_WB */ -#endif +#define wbflush_setup() do { } while (0) -extern void wbflush_setup(void); +#define wbflush() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #endif /* __ASM_MIPS_WBFLUSH_H */ diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips64/system.h linux-mips-2.4.17-20020129/include/asm-mips64/system.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips64/system.h Sun Jan 27 05:27:59 2002 +++ linux-mips-2.4.17-20020129/include/asm-mips64/system.h Mon Feb 4 02:12:27 2002 @@ -11,12 +11,13 @@ #define _ASM_SYSTEM_H #include - #include -#include #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -163,20 +164,32 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli(); #define local_irq_enable() __sti(); -/* - * These are probably defined overly paranoid ... - */ -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "sync\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") + +#define wmb() __sync() +#define rmb() __sync() +#define mb() __sync() +#define iob() \ + do { \ + __sync(); \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory"); \ + } while (0) #ifdef CONFIG_SMP #define smp_mb() mb() From owner-linux-mips@oss.sgi.com Mon Apr 8 10:07:08 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38H788d031068 for ; Mon, 8 Apr 2002 10:07:08 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38H78Cs031067 for linux-mips-outgoing; Mon, 8 Apr 2002 10:07:08 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38H6s8d031049 for ; Mon, 8 Apr 2002 10:07:01 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA08632; Mon, 8 Apr 2002 19:04:13 +0200 (MET DST) Date: Mon, 8 Apr 2002 19:04:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: New style IRQs for DECstation 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 Hello, Here is code that implements new style IRQ handlers for DECstation. Beside obvious things, like mask/unmask, etc. functions it adds IRQ routing tables for individual systems (including somewhat more complete basic support for the 5100) so that device drivers for onboard devices do not have to code IRQ guesswork based on model types. I tried to make hardware documentation more complete as well as its external sources are scarce to say at least, so it might be best to keep bits described within the code that deals with them. Also included there are a few updates to generic code: 1. A few clean-ups to arch/mips/kernel/irq_cpu.c. Just a five minute approach to fix obvious things. A deeper action is needed, in particular locking is missing altogether. 2. A new mips_cpu option to denote the dedicated FPU exception is present as there is currently no sane way to conclude whether it's available or not. 3. A few missing header inclusions. Actually the code is nothing new, but since I'm resubmitting it and a few people confirmed their interest in the DECstation port since the previous submission, I'm making the patch available to the public. I'm running the code since mid January successfully with only a few minor fixes since then. Due to a relatively large size the patch is available here: 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020402-irq-48.gz'. 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 Apr 8 10:27:20 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38HRK8d031456 for ; Mon, 8 Apr 2002 10:27:20 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38HRKgD031455 for linux-mips-outgoing; Mon, 8 Apr 2002 10:27:20 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38HQP8d031450 for ; Mon, 8 Apr 2002 10:26:25 -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 KAA04903 for ; Mon, 8 Apr 2002 10:27:00 -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 TAA08974; Mon, 8 Apr 2002 19:16:06 +0200 (MET DST) Date: Mon, 8 Apr 2002 19:16:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A wbflush() rework 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 Hello, Here is a rework of the wbflush() that makes code use iob() and possibly fast_iob() where appropriate. Additionally the DECstation __wbflush() backends are updated to match reality, yielding better and reliability performance for I/O ASIC systems. The code is needed specifically for R4k not to generate an excessive number of spurious interrupts on DECstation. The code applies on top of the "mb-wb" and "irq" patches. 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.18-20020323-wbflush-3 diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/Makefile linux-mips-2.4.18-20020323/arch/mips/dec/Makefile --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/Makefile Tue Jan 22 07:32:00 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/Makefile Mon Feb 4 01:06:32 2002 @@ -17,9 +17,10 @@ all: dec.o export-objs := setup.o wbflush.o obj-y := int-handler.o ioasic-irq.o kn02-irq.o reset.o rtc-dec.o setup.o \ - time.o wbflush.o + time.o obj-$(CONFIG_PROM_CONSOLE) += promcon.o +obj-$(CONFIG_CPU_HAS_WB) += wbflush.o int-handler.o: int-handler.S diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/ioasic-irq.c linux-mips-2.4.18-20020323/arch/mips/dec/ioasic-irq.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/ioasic-irq.c Tue Jan 22 06:44:47 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/ioasic-irq.c Mon Feb 4 01:00:53 2002 @@ -84,6 +84,7 @@ static inline void ack_ioasic_irq(unsign spin_lock(&ioasic_lock); mask_ioasic_irq(irq); spin_unlock(&ioasic_lock); + fast_iob(); } static inline void end_ioasic_irq(unsigned int irq) @@ -119,6 +120,7 @@ static struct hw_interrupt_type ioasic_i static inline void end_ioasic_dma_irq(unsigned int irq) { clear_ioasic_irq(irq); + fast_iob(); end_ioasic_irq(irq); } @@ -142,6 +144,7 @@ void __init init_ioasic_irqs(int base) /* Mask interrupts. */ ioasic_write(SIMR, 0); + fast_iob(); for (i = base; i < base + IO_INR_DMA; i++) { irq_desc[i].status = IRQ_DISABLED; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/kn02-irq.c linux-mips-2.4.18-20020323/arch/mips/dec/kn02-irq.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/kn02-irq.c Tue Jan 22 06:47:34 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/kn02-irq.c Mon Feb 4 01:01:59 2002 @@ -83,6 +83,7 @@ static void ack_kn02_irq(unsigned int ir spin_lock(&kn02_lock); mask_kn02_irq(irq); spin_unlock(&kn02_lock); + iob(); } static void end_kn02_irq(unsigned int irq) @@ -113,6 +114,7 @@ void __init init_kn02_irqs(int base) /* Mask interrupts and preset write-only bits. */ cached_kn02_csr = (*csr & ~0xff0000) | 0xff; *csr = cached_kn02_csr; + iob(); for (i = base; i < base + KN02_IRQ_LINES; i++) { irq_desc[i].status = IRQ_DISABLED; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/setup.c linux-mips-2.4.18-20020323/arch/mips/dec/setup.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/setup.c Tue Jan 22 07:31:08 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/setup.c Mon Feb 4 01:10:36 2002 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -87,8 +88,6 @@ static struct irqaction fpuirq = {NULL, static struct irqaction haltirq = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; - -extern void wbflush_setup(void); extern struct rtc_ops dec_rtc_ops; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/wbflush.c linux-mips-2.4.18-20020323/arch/mips/dec/wbflush.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/wbflush.c Tue Nov 6 05:26:15 2001 +++ linux-mips-2.4.18-20020323/arch/mips/dec/wbflush.c Mon Feb 4 01:03:17 2002 @@ -11,15 +11,18 @@ * for more details. * * Copyright (C) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ -#include #include +#include +#include +#include + static void wbflush_kn01(void); static void wbflush_kn210(void); -static void wbflush_kn02ba(void); -static void wbflush_kn03(void); +static void wbflush_mips(void); void (*__wbflush) (void); @@ -27,28 +30,23 @@ void __init wbflush_setup(void) { switch (mips_machtype) { case MACH_DS23100: - __wbflush = wbflush_kn01; - break; - case MACH_DS5100: /* DS5100 MIPSMATE */ - __wbflush = wbflush_kn210; - break; case MACH_DS5000_200: /* DS5000 3max */ - __wbflush = wbflush_kn01; - break; + __wbflush = wbflush_kn01; + break; + case MACH_DS5100: /* DS5100 MIPSMATE */ + __wbflush = wbflush_kn210; + break; case MACH_DS5000_1XX: /* DS5000/100 3min */ - __wbflush = wbflush_kn02ba; - break; - case MACH_DS5000_2X0: /* DS5000/240 3max+ */ - __wbflush = wbflush_kn03; - break; case MACH_DS5000_XX: /* Personal DS5000/2x */ - __wbflush = wbflush_kn02ba; - break; + case MACH_DS5000_2X0: /* DS5000/240 3max+ */ + default: + __wbflush = wbflush_mips; + break; } } /* - * For the DS3100 and DS5000/200 the writeback buffer functions + * For the DS3100 and DS5000/200 the R2020/R3220 writeback buffer functions * as part of Coprocessor 0. */ static void wbflush_kn01(void) @@ -78,29 +76,16 @@ static void wbflush_kn210(void) "mtc0\t$2,$12\n\t" "nop\n\t" ".set\tpop" - : : :"$2", "$3"); -} - -/* - * Looks like some magic with the System Interrupt Mask Register - * in the famous IOASIC for kmins and maxines. - */ -static void wbflush_kn02ba(void) -{ - asm(".set\tpush\n\t" - ".set\tnoreorder\n\t" - "lui\t$2,0xbc04\n\t" - "lw\t$3,0x120($2)\n\t" - "lw\t$3,0x120($2)\n\t" - ".set\tpop" - : : :"$2", "$3"); + : : : "$2", "$3"); } /* - * The DS500/2x0 doesnt need to write back the WB. + * I/O ASIC systems use a standard writeback buffer that gets flushed + * upon an uncached read. */ -static void wbflush_kn03(void) +static void wbflush_mips(void) { + __fast_iob(); } #include diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-r3k.c linux-mips-2.4.18-20020323/arch/mips/mm/c-r3k.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-r3k.c Tue Feb 19 05:28:14 2002 +++ linux-mips-2.4.18-20020323/arch/mips/mm/c-r3k.c Sun Mar 24 21:16:14 2002 @@ -19,7 +19,6 @@ #include #include #include -#include #include #include @@ -314,7 +313,7 @@ static void r3k_flush_cache_sigtramp(uns static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size) { - wbflush(); + iob(); r3k_flush_dcache_range(start, start + size); } diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-tx39.c linux-mips-2.4.18-20020323/arch/mips/mm/c-tx39.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-tx39.c Sat Dec 1 05:26:01 2001 +++ linux-mips-2.4.18-20020323/arch/mips/mm/c-tx39.c Mon Feb 4 01:12:41 2002 @@ -20,7 +20,6 @@ #include #include #include -#include #include #include @@ -63,8 +62,8 @@ static void tx39h_flush_icache_all(void) static void tx39h_dma_cache_wback_inv(unsigned long addr, unsigned long size) { unsigned long end, a; - wbflush(); + iob(); a = addr & ~(dcache_lsize - 1); end = (addr + size) & ~(dcache_lsize - 1); while (1) { diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/tlb-r3k.c linux-mips-2.4.18-20020323/arch/mips/mm/tlb-r3k.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/tlb-r3k.c Fri Jan 18 05:28:05 2002 +++ linux-mips-2.4.18-20020323/arch/mips/mm/tlb-r3k.c Mon Feb 4 00:59:46 2002 @@ -19,7 +19,6 @@ #include #include #include -#include #include #include diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/char/dz.c linux-mips-2.4.18-20020323/drivers/char/dz.c --- linux-mips-2.4.18-20020323.macro/drivers/char/dz.c Sun Jan 20 21:37:53 2002 +++ linux-mips-2.4.18-20020323/drivers/char/dz.c Mon Feb 4 01:13:30 2002 @@ -35,7 +35,6 @@ #include #include #include -#include #include #include @@ -53,6 +52,8 @@ #include #include +#include + #define CONSOLE_LINE (3) /* for definition of struct console */ extern int (*prom_printf) (char *,...); @@ -1420,7 +1421,7 @@ int __init dz_init(void) #ifndef CONFIG_SERIAL_CONSOLE dz_out(info, DZ_CSR, DZ_CLR); while ((tmp = dz_in(info, DZ_CSR)) & DZ_CLR); - wbflush(); + iob(); /* enable scanning */ dz_out(info, DZ_CSR, DZ_MSE); diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/net/declance.c linux-mips-2.4.18-20020323/drivers/net/declance.c --- linux-mips-2.4.18-20020323.macro/drivers/net/declance.c Sun Mar 24 20:58:18 2002 +++ linux-mips-2.4.18-20020323/drivers/net/declance.c Sun Mar 24 21:16:14 2002 @@ -60,7 +60,7 @@ static char *lancestr = "lance"; #include #include #include -#include +#include #include #include @@ -306,7 +306,7 @@ int dec_lance_debug = 2; static inline void writereg(volatile unsigned short *regptr, short value) { *regptr = value; - wbflush(); + iob(); } /* Load the CSR registers */ @@ -386,7 +386,7 @@ void cp_to_buf(void *to, const void *fro } } - wbflush(); + iob(); } void cp_from_buf(void *to, unsigned char *from, int len) @@ -514,7 +514,7 @@ static void lance_init_ring(struct net_d if (i < 3 && ZERO) printk("%d: 0x%8.8x(0x%8.8x)\n", i, leptr, (int) lp->rx_buf_ptr_cpu[i]); } - wbflush(); + iob(); } static int init_restart_lance(struct lance_private *lp) @@ -1084,7 +1084,7 @@ static int __init dec_lance_init(struct lp->dma_ptr_reg = (unsigned long *) (system_base + IOCTL + LANCE_DMA_P); *(lp->dma_ptr_reg) = PHYSADDR(dev->mem_start) << 3; *(unsigned long *) (system_base + IOCTL + SSR) |= (1 << 16); - wbflush(); + fast_iob(); break; case PMAD_LANCE: diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/scsi/NCR53C9x.h linux-mips-2.4.18-20020323/drivers/scsi/NCR53C9x.h --- linux-mips-2.4.18-20020323.macro/drivers/scsi/NCR53C9x.h Fri Oct 19 04:29:11 2001 +++ linux-mips-2.4.18-20020323/drivers/scsi/NCR53C9x.h Mon Feb 4 01:14:34 2002 @@ -144,12 +144,7 @@ #ifndef MULTIPLE_PAD_SIZES -#ifdef CONFIG_CPU_HAS_WB -#include -#define esp_write(__reg, __val) do{(__reg) = (__val); wbflush();} while(0) -#else -#define esp_write(__reg, __val) ((__reg) = (__val)) -#endif +#define esp_write(__reg, __val) do{(__reg) = (__val); iob();} while(0) #define esp_read(__reg) (__reg) struct ESP_regs { diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/scsi/dec_esp.c linux-mips-2.4.18-20020323/drivers/scsi/dec_esp.c --- linux-mips-2.4.18-20020323.macro/drivers/scsi/dec_esp.c Tue Jan 22 03:06:51 2002 +++ linux-mips-2.4.18-20020323/drivers/scsi/dec_esp.c Mon Feb 4 01:15:48 2002 @@ -46,6 +46,8 @@ #include #include +#include + /* * Once upon a time the pmaz code used to be working but * it hasn't been maintained for quite some time. @@ -308,17 +310,9 @@ static void scsi_dma_err_int(int irq, vo static void scsi_dma_int(int irq, void *dev_id, struct pt_regs *regs) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - /* next page */ *scsi_next_ptr = ((*scsi_dma_ptr + PAGE_SIZE) & PAGE_MASK) << 3; - - /* - * This routine will only work on IOASIC machines - * so we can avoid an indirect function call here - * and flush the writeback buffer the fast way - */ - *dummy; + fast_iob(); } static int dma_bytes_sent(struct NCR_ESP *esp, int fifo_count) @@ -370,8 +364,6 @@ static void dma_dump_state(struct NCR_ES static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - if (vaddress & 3) panic("dec_efs.c: unable to handle partial word transfers, yet..."); @@ -384,17 +376,11 @@ static void dma_init_read(struct NCR_ESP /* prepare for next page */ *scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3; *ioasic_ssr |= (SCSI_DMA_DIR | SCSI_DMA_EN); - - /* - * see above - */ - *dummy; + fast_iob(); } static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - if (vaddress & 3) panic("dec_efs.c: unable to handle partial word transfers, yet..."); @@ -407,11 +393,7 @@ static void dma_init_write(struct NCR_ES /* prepare for next page */ *scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3; *ioasic_ssr |= SCSI_DMA_EN; - - /* - * see above - */ - *dummy; + fast_iob(); } static void dma_ints_off(struct NCR_ESP *esp) diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c linux-mips-2.4.18-20020323/drivers/tc/zs.c --- linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c Sun Mar 24 21:02:44 2002 +++ linux-mips-2.4.18-20020323/drivers/tc/zs.c Sun Mar 24 21:16:14 2002 @@ -67,7 +67,6 @@ #include #include #include -#include #include #ifdef CONFIG_DECSTATION #include @@ -276,7 +275,7 @@ static inline unsigned char read_zsreg(s if (reg != 0) { *channel->control = reg & 0xf; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; } retval = *channel->control; RECOVERY_DELAY; @@ -288,10 +287,10 @@ static inline void write_zsreg(struct de { if (reg != 0) { *channel->control = reg & 0xf; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; } *channel->control = value; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; return; } @@ -308,7 +307,7 @@ static inline void write_zsdata(struct d unsigned char value) { *channel->data = value; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; return; } From owner-linux-mips@oss.sgi.com Mon Apr 8 10:48:43 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38Hmh8d031668 for ; Mon, 8 Apr 2002 10:48:43 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38HmhHL031667 for linux-mips-outgoing; Mon, 8 Apr 2002 10:48:43 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38Hmc8d031664 for ; Mon, 8 Apr 2002 10:48:38 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA20739; Mon, 8 Apr 2002 18:58:31 -0700 Message-ID: <3CB1D7E6.5010804@mvista.com> Date: Mon, 08 Apr 2002 10:48:22 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if it is just needed by DecStation. How many CPUs really need this? Jun Maciej W. Rozycki wrote: > Hello, > > Here is code that implements new style IRQ handlers for DECstation. > Beside obvious things, like mask/unmask, etc. functions it adds IRQ > routing tables for individual systems (including somewhat more complete > basic support for the 5100) so that device drivers for onboard devices do > not have to code IRQ guesswork based on model types. I tried to make > hardware documentation more complete as well as its external sources are > scarce to say at least, so it might be best to keep bits described within > the code that deals with them. > > Also included there are a few updates to generic code: > > 1. A few clean-ups to arch/mips/kernel/irq_cpu.c. Just a five minute > approach to fix obvious things. A deeper action is needed, in particular > locking is missing altogether. > > 2. A new mips_cpu option to denote the dedicated FPU exception is present > as there is currently no sane way to conclude whether it's available or > not. > > 3. A few missing header inclusions. > > Actually the code is nothing new, but since I'm resubmitting it and a few > people confirmed their interest in the DECstation port since the previous > submission, I'm making the patch available to the public. I'm running the > code since mid January successfully with only a few minor fixes since > then. > > Due to a relatively large size the patch is available here: > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020402-irq-48.gz'. > > Maciej > > From owner-linux-mips@oss.sgi.com Mon Apr 8 11:03:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38I3J8d031996 for ; Mon, 8 Apr 2002 11:03:19 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38I3Jsm031995 for linux-mips-outgoing; Mon, 8 Apr 2002 11:03:19 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38I3E8d031991 for ; Mon, 8 Apr 2002 11:03:15 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10414; Mon, 8 Apr 2002 20:03:45 +0200 (MET DST) Date: Mon, 8 Apr 2002 20:03:43 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB1D7E6.5010804@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 8 Apr 2002, Jun Sun wrote: > What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if > it is just needed by DecStation. How many CPUs really need this? It's needed by any system using a (logically) external FPU. If set it means there is no need to install a special FPU exception handler using a general-purpose interrupt line. It's a generic flag. Even if it's only of limited use now, it is not an excuse for not writing clean code. I'm afraid the current mess within the MIPS port is a result of people trying to think locally and I'm trying to avoid it. Are there any trade-offs of this flags you see and I don't? I'm willing to change the code if there really are. 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 Apr 8 11:25:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38IPt8d032488 for ; Mon, 8 Apr 2002 11:25:55 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38IPtNZ032487 for linux-mips-outgoing; Mon, 8 Apr 2002 11:25:55 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38IPp8d032481 for ; Mon, 8 Apr 2002 11:25:51 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id TAA22017; Mon, 8 Apr 2002 19:36:03 -0700 Message-ID: <3CB1E0B2.8020707@mvista.com> Date: Mon, 08 Apr 2002 11:25:54 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Maciej W. Rozycki wrote: > On Mon, 8 Apr 2002, Jun Sun wrote: > > >>What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if >>it is just needed by DecStation. How many CPUs really need this? >> > > It's needed by any system using a (logically) external FPU. If set it > means there is no need to install a special FPU exception handler using a > general-purpose interrupt line. It's a generic flag. > > Even if it's only of limited use now, it is not an excuse for not writing > clean code. I'm afraid the current mess within the MIPS port is a result > of people trying to think locally and I'm trying to avoid it. Are there > any trade-offs of this flags you see and I don't? I'm willing to change > the code if there really are. > Generally interrupt dispatching belongs to machine/board-specific code. So I think FPU exeption through an interrupt is probably best handled within DEC's code, instead of being generalized to the common code. In addition, conceptional you might have a system where FPU exception is handled through an interrupt and yet CPU has FPU exception. Of course abstraction and generalization can happen later when it becomes obvious. It is just not obvious, at least to me. Jun From owner-linux-mips@oss.sgi.com Mon Apr 8 21:46:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g394ks8d016206 for ; Mon, 8 Apr 2002 21:46:54 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g394ksP0016205 for linux-mips-outgoing; Mon, 8 Apr 2002 21:46:54 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g394kq8d016202 for ; Mon, 8 Apr 2002 21:46:52 -0700 Received: from Muruga.localdomain (adsl-63-201-59-68.dsl.snfc21.pacbell.net [63.201.59.68]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g394lEx152200 for ; Tue, 9 Apr 2002 00:47:14 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g394Xw625334 for ; Mon, 8 Apr 2002 21:33:58 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Mon, 8 Apr 2002 21:33:57 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: Subject: Where to get the latest kernel. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Where can I download the latest development kernel for MIPS? Thanks, Muthu. From owner-linux-mips@oss.sgi.com Tue Apr 9 01:50:44 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g398oi8d009493 for ; Tue, 9 Apr 2002 01:50:44 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g398oiiT009492 for linux-mips-outgoing; Tue, 9 Apr 2002 01:50:44 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g398ob8d009488 for ; Tue, 9 Apr 2002 01:50:41 -0700 Received: from excalibur.cologne.de (pD9E40558.dip.t-dialin.net [217.228.5.88]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id KAA07834; Tue, 9 Apr 2002 10:50:56 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16uqxt-0000GG-00; Tue, 09 Apr 2002 10:26:57 +0200 Date: Tue, 9 Apr 2002 10:26:57 +0200 From: Karsten Merker To: Muthukumar Ratty Cc: linux-mips@oss.sgi.com Subject: Re: Where to get the latest kernel. Message-ID: <20020409102657.C254@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , Muthukumar Ratty , linux-mips@oss.sgi.com 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 muthu5@sbcglobal.net on Mon, Apr 08, 2002 at 09:33:57PM -0700 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 08, 2002 at 09:33:57PM -0700, Muthukumar Ratty wrote: > Where can I download the latest development kernel for MIPS? cvs -d :pserver:cvs@oss.sgi.com:/cvs login (no password) cvs -z4 -d :pserver:cvs@oss.sgi.com:/cvs co linux or if you would like to get kernel version 2.4.x: cvs -z4 -d :pserver:cvs@oss.sgi.com:/cvs co -r linux_2_4 linux HTH, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Tue Apr 9 07:44:40 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39Eie8d021365 for ; Tue, 9 Apr 2002 07:44:40 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39Eie2q021364 for linux-mips-outgoing; Tue, 9 Apr 2002 07:44:40 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39EiX8d021360 for ; Tue, 9 Apr 2002 07:44:34 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08554; Tue, 9 Apr 2002 16:41:36 +0200 (MET DST) Date: Tue, 9 Apr 2002 16:41:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB1E0B2.8020707@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 8 Apr 2002, Jun Sun wrote: > Generally interrupt dispatching belongs to machine/board-specific code. So I > think FPU exeption through an interrupt is probably best handled within DEC's > code, instead of being generalized to the common code. The dispatching of the FPU interrupt for the DECstation is local to DEC-specific code (note that it's so mainly due to performance reasons anyway -- there is no problem with making dispatcher's code common with appropriate backends installed for different IRQ types, like it is already done in generic controller-based IRQ handling code). Any other system using a CPU/FPU in such a configuration has to provide its own dispatcher. The handler for the FPU interrupt is the very same handler used for the FPU exception; only a different entry point is used to accomodate the fact registers are already saved on the stack. And for safety you don't want the FPU exception handler to be enabled for FPUs that report exceptions via an FPU interrupt. For such systems a spurious FPU exception should be treated as a system error. > In addition, conceptional you might have a system where FPU exception is > handled through an interrupt and yet CPU has FPU exception. Not quite. The FPU exception is not maskable, so you can't make a choice at the run time. It has to be hardwired. > Of course abstraction and generalization can happen later when it becomes > obvious. It is just not obvious, at least to me. MIPS_CPU_FPUEX is specific to the CPU not to the system. IDT R3081 is another example (mysterious R3400 used in DECstation 5000/240 being the first one) of a CPU with an integrated FPU unit which is logically external and uses an interrupt to report FPU exceptions. And all R2k/R3k setups using a physically separate FPU deliver FPU exceptions via an interrupt line. I can't see a reason why to handle this option in system-specific code. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Apr 9 10:36:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39HaQ8d027815 for ; Tue, 9 Apr 2002 10:36:26 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39HaQBi027814 for linux-mips-outgoing; Tue, 9 Apr 2002 10:36:26 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39HaN8d027810 for ; Tue, 9 Apr 2002 10:36:23 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA20052; Tue, 9 Apr 2002 18:46:25 -0700 Message-ID: <3CB32694.1010503@mvista.com> Date: Tue, 09 Apr 2002 10:36:20 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Maciej W. Rozycki wrote: > I can't see a reason why to handle this option in > system-specific code. > How about "there will be likely no such CPUs/systems in the future"? Your patch will force every new CPU to add FPUEX option to the cpu_option, where apparently no place really need to use it. Leaving FPU exception enabled for a CPU that does not generate FPU exception is acceptable. (because it does *not* generate FPU exceptions). And hooking up/dispatching the FPU exception interrupt is system-specific already anyway. It, however, makes sense to provide a common wrapper code for fpu interrupt to jump to fpu exception handling code. Over-abstraction can make the picture cloudy rather than clear. My 2 cents. Jun From owner-linux-mips@oss.sgi.com Tue Apr 9 19:13:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3A2Dm8d022873 for ; Tue, 9 Apr 2002 19:13:48 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3A2DmQw022872 for linux-mips-outgoing; Tue, 9 Apr 2002 19:13:48 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-mips@oss.sgi.com using -f Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3A2Di8d022868 for ; Tue, 9 Apr 2002 19:13:45 -0700 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g3A2E9ZB027838 for ; Wed, 10 Apr 2002 04:14:09 +0200 Received: (from rani@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g3A2E87c027837 for linux-mips@oss.sgi.com; Wed, 10 Apr 2002 04:14:08 +0200 From: Rani Assaf Date: Wed, 10 Apr 2002 04:14:08 +0200 To: linux-mips@oss.sgi.com Subject: Question about r4k_clear_page_xxx() Message-ID: <20020410041408.G23127@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux darth 2.4.17-pre8 X-NCC-RegID: fr.proxad Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I was cleaning duplicate code between my port of IDT RC32355 and the current tree. I want to use r4k_clear_page_d16() but the function uses store double (sd) which is not available on this processor. What's the reason for having r4k_clear_page_xxx() use store double and not r4k_copy_page_xxx()?? Regards, Rani From owner-linux-mips@oss.sgi.com Wed Apr 10 04:10:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ABAC8d007836 for ; Wed, 10 Apr 2002 04:10:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ABACg1007835 for linux-mips-outgoing; Wed, 10 Apr 2002 04:10:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ABA58d007830 for ; Wed, 10 Apr 2002 04:10:06 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 4AB68843; Wed, 10 Apr 2002 13:10:32 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 2A6033704F; Wed, 10 Apr 2002 13:10:14 +0200 (CEST) Date: Wed, 10 Apr 2002 13:10:14 +0200 From: Florian Lohoff To: Rani Assaf Cc: linux-mips@oss.sgi.com Subject: Re: Question about r4k_clear_page_xxx() Message-ID: <20020410111014.GI9514@paradigm.rfc822.org> References: <20020410041408.G23127@paname.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G3juXO9GfR42w+sw" Content-Disposition: inline In-Reply-To: <20020410041408.G23127@paname.org> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --G3juXO9GfR42w+sw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2002 at 04:14:08AM +0200, Rani Assaf wrote: > Hi, >=20 > I was cleaning duplicate code between my port of IDT RC32355 and the > current tree. I want to use r4k_clear_page_d16() but the function uses > store double (sd) which is not available on this processor. >=20 > What's the reason for having r4k_clear_page_xxx() use store double and > not r4k_copy_page_xxx()?? Just from my guess - r4k_copy_page will pollute the d-cache with the empty page you are reading. You have twice as much instruction (load + store) which effectively will give you half the performance. If "sd" is not available you might want to implement your clear_page with sw zero, x(a0) like the sd version. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --G3juXO9GfR42w+sw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8tB2WUaz2rXW+gJcRApMOAJ4mnq4HS7XIa0Qyb2xtNj+PLX2BsACgk22Z z1sa4VsYc3q8LrsdPJjqPgE= =FMrc -----END PGP SIGNATURE----- --G3juXO9GfR42w+sw-- From owner-linux-mips@oss.sgi.com Wed Apr 10 06:31:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ADVc8d020563 for ; Wed, 10 Apr 2002 06:31:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ADVXnw020509 for linux-mips-outgoing; Wed, 10 Apr 2002 06:31:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ADVL8d020401 for ; Wed, 10 Apr 2002 06:31:24 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA06262; Wed, 10 Apr 2002 15:31:08 +0200 (MET DST) Date: Wed, 10 Apr 2002 15:31:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB32694.1010503@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 9 Apr 2002, Jun Sun wrote: > How about "there will be likely no such CPUs/systems in the future"? Does it mean code needs to be dirty? There is no performance hit for new CPUs and the code bloat is minimal and even that is discarded after boot. > Your patch will force every new CPU to add FPUEX option to the cpu_option, > where apparently no place really need to use it. Well, I agree to some extent here. I may negate the flag, so it's not needed for most CPUs. > Leaving FPU exception enabled for a CPU that does not generate FPU exception > is acceptable. (because it does *not* generate FPU exceptions). And hooking You never know. You may get one due to a hardware fault. It's better to trap it and panic then, than to try to pretend nothing special happened. > up/dispatching the FPU exception interrupt is system-specific already anyway. But pretty generic -- you just need to grab the right IRQ line. See the top of decstation_handle_int in arch/mips/dec/int-handler.S -- nothing system-specific until after the FPU path branch. You may cut and paste it for any other system. > It, however, makes sense to provide a common wrapper code for fpu interrupt to > jump to fpu exception handling code. No additional code is actually generated -- only a label for a second entry point is added. > Over-abstraction can make the picture cloudy rather than clear. My 2 cents. I appreciate your point of view. You haven't convinced me, though. Apart from the negation of MIPS_CPU_FPUEX, which sounds reasonable indeed. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Apr 10 12:51:08 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AJp88d019705 for ; Wed, 10 Apr 2002 12:51:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AJp8eM019704 for linux-mips-outgoing; Wed, 10 Apr 2002 12:51:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AJo38d019665 for ; Wed, 10 Apr 2002 12:50:03 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020410195026.BPCD15826.rwcrmhc54.attbi.com@ocean.lucon.org>; Wed, 10 Apr 2002 19:50:26 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5216D125C3; Wed, 10 Apr 2002 12:50:21 -0700 (PDT) Date: Wed, 10 Apr 2002 12:50:20 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.4 is released. Message-ID: <20020410125020.A10642@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.12.90.0.4 for Linux, which is based on binutils 2002 0408 in CVS on sourecs.redhat.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f 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.12.90.0.4 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.12.90.0.3: 1. Update from binutils 2002 0408. 2. Bug fixes for ELF/sparc. 3. Bug fixes for ELF/CRIS. Changes from binutils 2.12.90.0.1: 1. Update from binutils 2002 0323. 2. Fix linking a.out relocatable files with ELF. 3. Fix a PPC altivec assembler bug. Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.12.90.0.4.tar.gz. Source code. 2. binutils-2.12.90.0.3-2.12.90.0.4.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.4-1.i386.rpm. IA-32 binary RPM for RedHat 7.2. There is no separate source rpm. You can do # rpm -ta binutils-2.12.90.0.4.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 04/10/2002 From owner-linux-mips@oss.sgi.com Wed Apr 10 18:41:37 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3B1fb8d000569 for ; Wed, 10 Apr 2002 18:41:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3B1fbXl000568 for linux-mips-outgoing; Wed, 10 Apr 2002 18:41:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3B1fZ8d000565 for ; Wed, 10 Apr 2002 18:41:35 -0700 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g3B1g3ZB003941 for ; Thu, 11 Apr 2002 03:42:03 +0200 Received: (from news@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g3B1XHvf003915 for linux-mips@paname.org; Thu, 11 Apr 2002 03:33:17 +0200 Date: Thu, 11 Apr 2002 03:33:17 +0200 From: linux-mips-local@paname.org Message-Id: <200204110133.g3B1XHvf003915@darth.paname.org> X-Authentication-Warning: darth.paname.org: news set sender to linux-mips-local@paname.org using -f To: undisclosed-recipients:; Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From owner-linux-mips@oss.sgi.com Thu Apr 11 22:03:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C53b8d024038 for ; Thu, 11 Apr 2002 22:03:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C53bOm024037 for linux-mips-outgoing; Thu, 11 Apr 2002 22:03:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C53X8d024033 for ; Thu, 11 Apr 2002 22:03:34 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3C542p26971; Thu, 11 Apr 2002 22:04:02 -0700 Date: Thu, 11 Apr 2002 22:04:01 -0700 From: Ralf Baechle To: Rani Assaf Cc: linux-mips@oss.sgi.com Subject: Re: Question about r4k_clear_page_xxx() Message-ID: <20020411220401.A26953@dea.linux-mips.net> References: <20020410041408.G23127@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020410041408.G23127@paname.org>; from rani@paname.org on Wed, Apr 10, 2002 at 04:14:08AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 10, 2002 at 04:14:08AM +0200, Rani Assaf wrote: > I was cleaning duplicate code between my port of IDT RC32355 and the > current tree. I want to use r4k_clear_page_d16() but the function uses > store double (sd) which is not available on this processor. > > What's the reason for having r4k_clear_page_xxx() use store double and > not r4k_copy_page_xxx()?? The 32-bit kernel doesn't save or restore the upper 32-bits of general purpose registers. Therefore 64-bit stores can only be used with the $zero register. Ralf From owner-linux-mips@oss.sgi.com Thu Apr 11 23:54:51 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C6sp8d028205 for ; Thu, 11 Apr 2002 23:54:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C6spMk028204 for linux-mips-outgoing; Thu, 11 Apr 2002 23:54:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from libra.seed.net.tw (libra.seed.net.tw [192.72.81.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C6sn8d028200 for ; Thu, 11 Apr 2002 23:54:49 -0700 Received: from sw59-226-127.adsl.seed.net.tw ([61.59.226.127] helo=libra.seed.net.tw) by libra.seed.net.tw with esmtp (Seednet MTA build 20010831) id 16vuxv-0005ym-00 for linux-mips@oss.sgi.com; Fri, 12 Apr 2002 14:55:23 +0800 Message-ID: <3CB684C5.8090807@libra.seed.net.tw> Date: Fri, 12 Apr 2002 14:55:01 +0800 From: Tim Wu Reply-To: chtimwu@libra.seed.net.tw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: no permission to access archive Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, All: I can't access the archive of this mailing list. The server reponsed following message to me. Will someone fix it? Forbidden You don't have permission to access /mips/archive/ on this server. From owner-linux-mips@oss.sgi.com Fri Apr 12 00:29:05 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C7T58d029356 for ; Fri, 12 Apr 2002 00:29:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C7T5bp029355 for linux-mips-outgoing; Fri, 12 Apr 2002 00:29:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from libra.seed.net.tw (libra.seed.net.tw [192.72.81.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C7T08d029351 for ; Fri, 12 Apr 2002 00:29:01 -0700 Received: from sw59-226-127.adsl.seed.net.tw ([61.59.226.127] helo=libra.seed.net.tw) by libra.seed.net.tw with esmtp (Seednet MTA build 20010831) id 16vvV0-0003az-00 for linux-mips@oss.sgi.com; Fri, 12 Apr 2002 15:29:34 +0800 Message-ID: <3CB68CC8.1050207@libra.seed.net.tw> Date: Fri, 12 Apr 2002 15:29:12 +0800 From: Tim Wu Reply-To: chtimwu@libra.seed.net.tw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips Subject: LEXRA MIPS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, everybody: I'm working on porting Linux to a MIPS based processor whose IP is from Lexra's LX4189 processor. I started my work from the linux MIPS port of oss.sgi.com. Right now the kernel can boot and run some user applications well. But I met a problem that once a process raises any kind of signal, kernel will send a SIGILL signal to the process which let the process stop. I traced the kernel source and found SIGILL is sent by the exception handler, do_ri(). The problem is very weird because when I change to another crosscompiler or insert some asserting code to functions in signal.c. The kernel become unbootable. I hope someone can give me directions to solve this bug or tell me who already done Linux on Lexra? kernel version:2.4.17. toolchain: GCC 3.1 from ftp.cotw.com. use new IRQ and new timer interface. From owner-linux-mips@oss.sgi.com Fri Apr 12 04:41:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CBf28d008093 for ; Fri, 12 Apr 2002 04:41:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CBf2SK008092 for linux-mips-outgoing; Fri, 12 Apr 2002 04:41:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CBeq8d008080 for ; Fri, 12 Apr 2002 04:40:57 -0700 Received: from prefect (prefect.mshome.net [192.168.0.76]) by ns1.ltc.com (Postfix) with SMTP id 4A622590B2; Fri, 12 Apr 2002 07:37:06 -0400 (EDT) Message-ID: <005901c1e217$058f7f20$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: , "linux-mips" References: <3CB68CC8.1050207@libra.seed.net.tw> Subject: Re: LEXRA MIPS Date: Fri, 12 Apr 2002 07:41:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Tim Wu" To: "linux-mips" Sent: Friday, April 12, 2002 3:29 AM Subject: LEXRA MIPS > I traced the kernel source and found SIGILL is sent by the exception > handler, do_ri(). Can you tell what/where the reserved (illegal) instruction is that causes the trap? Regards, Brad From owner-linux-mips@oss.sgi.com Fri Apr 12 09:42:47 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CGgl8d010745 for ; Fri, 12 Apr 2002 09:42:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CGglF9010744 for linux-mips-outgoing; Fri, 12 Apr 2002 09:42:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CGgi8d010733 for ; Fri, 12 Apr 2002 09:42:45 -0700 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16w48q-0008EY-00 for ; Fri, 12 Apr 2002 11:43:16 -0500 Message-ID: <3CB71C48.B768A40D@cotw.com> Date: Fri, 12 Apr 2002 12:41:28 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "MIPS/Linux List (SGI)" Subject: Can modules be stripped? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk For my vr5432 based board (2.4.5) I can strip and run executables. If I strip a module, insmod dies in obj_load() with Floating point exception. Has anyone else seen this? -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Fri Apr 12 09:56:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CGuc8d011680 for ; Fri, 12 Apr 2002 09:56:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CGuc54011679 for linux-mips-outgoing; Fri, 12 Apr 2002 09:56:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CGuY8d011661 for ; Fri, 12 Apr 2002 09:56:35 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA15738; Fri, 12 Apr 2002 18:57:10 +0200 (MET DST) Date: Fri, 12 Apr 2002 18:57:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: Scott A McConnell cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-Reply-To: <3CB71C48.B768A40D@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 Fri, 12 Apr 2002, Scott A McConnell wrote: > If I strip a module, insmod dies in obj_load() with Floating point > exception. You can't strip modules as they are relocatables -- global symbols and relocations have to stay intact. You may try `strip -d' if you want to remove debugging symbols. -- + 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 Apr 12 09:56:24 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CGuO8d011641 for ; Fri, 12 Apr 2002 09:56:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CGuORN011640 for linux-mips-outgoing; Fri, 12 Apr 2002 09:56:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dell.lineo.com ([212.74.13.151]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CGuK8d011637 for ; Fri, 12 Apr 2002 09:56:21 -0700 Received: from zentropix.com (localhost.localdomain [127.0.0.1]) by dell.lineo.com (8.11.6/8.11.6) with ESMTP id g3CGujC19989; Fri, 12 Apr 2002 17:56:49 +0100 Message-ID: <3CB711CD.83F65C13@zentropix.com> Date: Fri, 12 Apr 2002 17:56:45 +0100 From: Stuart Hughes X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Scott A McConnell CC: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? References: <3CB71C48.B768A40D@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Scott A McConnell wrote: > > For my vr5432 based board (2.4.5) I can strip and run executables. > > If I strip a module, insmod dies in obj_load() with Floating point > exception. > > Has anyone else seen this? Yep, Be careful what you strip. I found the safest thing was to use 'strip -g' -- Regards, Stuart Hughes From owner-linux-mips@oss.sgi.com Fri Apr 12 10:48:46 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CHmk8d016018 for ; Fri, 12 Apr 2002 10:48:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CHmkgi016017 for linux-mips-outgoing; Fri, 12 Apr 2002 10:48:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CHm48d015964 for ; Fri, 12 Apr 2002 10:48:39 -0700 Received: from prefect (prefect.mshome.net [192.168.0.76]) by ns1.ltc.com (Postfix) with SMTP id 9A7B4590B2; Fri, 12 Apr 2002 13:44:08 -0400 (EDT) Message-ID: <00e601c1e24a$4d7bc9a0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Maciej W. Rozycki" Cc: "MIPS/Linux List (SGI)" References: Subject: Re: Can modules be stripped? Date: Fri, 12 Apr 2002 13:48:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Maciej W. Rozycki" To: "Scott A McConnell" Cc: "MIPS/Linux List (SGI)" Sent: Friday, April 12, 2002 12:57 PM Subject: Re: Can modules be stripped? > On Fri, 12 Apr 2002, Scott A McConnell wrote: > > > If I strip a module, insmod dies in obj_load() with Floating point > > exception. > > You can't strip modules as they are relocatables -- global symbols and > relocations have to stay intact. OK, you can't strip kernel modules (news to me, then again how often do I use modules?), but it can't be because they "are relocatables". I routinely strip libraries without problem, and those are relocatables too. So what's the real reason? Regards, Brad From owner-linux-mips@oss.sgi.com Fri Apr 12 11:04:54 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CI4s8d017172 for ; Fri, 12 Apr 2002 11:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CI4s5u017171 for linux-mips-outgoing; Fri, 12 Apr 2002 11:04:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CI4o8d017162 for ; Fri, 12 Apr 2002 11:04:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA16892; Fri, 12 Apr 2002 20:05:43 +0200 (MET DST) Date: Fri, 12 Apr 2002 20:05:43 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-Reply-To: <00e601c1e24a$4d7bc9a0$4c00a8c0@prefect> 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, 12 Apr 2002, Bradley D. LaRonde wrote: > OK, you can't strip kernel modules (news to me, then again how often do I > use modules?), but it can't be because they "are relocatables". I routinely > strip libraries without problem, and those are relocatables too. What kind of libraries? Shared libraries are shared objects and not relocatables. Static libraries ("ar" archives), OTOH, are sets of relocatables as is e.g. /usr/lib/crt1.o and any assembler output. The rule is a relocatable is any object that has unresolved static relocations, i.e. has not undergone final linking. If unsure check with file(1). -- + 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 Apr 12 11:43:28 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CIhS8d019672 for ; Fri, 12 Apr 2002 11:43:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CIhRqL019671 for linux-mips-outgoing; Fri, 12 Apr 2002 11:43:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CIhM8d019665 for ; Fri, 12 Apr 2002 11:43:24 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA17500; Fri, 12 Apr 2002 20:44:18 +0200 (MET DST) Date: Fri, 12 Apr 2002 20:44:18 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-Reply-To: <012f01c1e250$c93fb0a0$4c00a8c0@prefect> 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, 12 Apr 2002, Bradley D. LaRonde wrote: > Which brings up an interesting question - why doesn't the kernel use .so > files for modules? There is no need to bring all the dynamic stuff into the kernel. -- + 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 Apr 12 12:10:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CJAR8d021351 for ; Fri, 12 Apr 2002 12:10:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CJAR4D021350 for linux-mips-outgoing; Fri, 12 Apr 2002 12:10:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CJA68d021332 for ; Fri, 12 Apr 2002 12:10:19 -0700 Received: from prefect (prefect.mshome.net [192.168.0.76]) by ns1.ltc.com (Postfix) with SMTP id ED126590B2; Fri, 12 Apr 2002 14:30:32 -0400 (EDT) Message-ID: <012f01c1e250$c93fb0a0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Maciej W. Rozycki" Cc: "MIPS/Linux List (SGI)" References: Subject: Re: Can modules be stripped? Date: Fri, 12 Apr 2002 14:35:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Maciej W. Rozycki" To: "Bradley D. LaRonde" Cc: "MIPS/Linux List (SGI)" Sent: Friday, April 12, 2002 2:05 PM Subject: Re: Can modules be stripped? > On Fri, 12 Apr 2002, Bradley D. LaRonde wrote: > > > OK, you can't strip kernel modules (news to me, then again how often do I > > use modules?), but it can't be because they "are relocatables". I routinely > > strip libraries without problem, and those are relocatables too. > > What kind of libraries? Shared libraries are shared objects and not > relocatables. Oh, oops. :-P Now I see what you mean. I confused shared object w/relocatable. My bad. Did I know that kernel modules were "object files" i.e. relocatables. Yes. But I've always referred to them as object files (.o), not relocatables, hence the confusion. Which brings up an interesting question - why doesn't the kernel use .so files for modules? Regards, Brad From owner-linux-mips@oss.sgi.com Fri Apr 12 17:27:28 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D0RS8d030613 for ; Fri, 12 Apr 2002 17:27:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D0RSU4030612 for linux-mips-outgoing; Fri, 12 Apr 2002 17:27:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3D0RN8d030609 for ; Fri, 12 Apr 2002 17:27:23 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16wBOM-0003ev-00; Fri, 12 Apr 2002 20:27:46 -0400 Date: Fri, 12 Apr 2002 20:27:46 -0400 From: Daniel Jacobowitz To: "Bradley D. LaRonde" Cc: "Maciej W. Rozycki" , "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? Message-ID: <20020412202746.A14017@nevyn.them.org> References: <012f01c1e250$c93fb0a0$4c00a8c0@prefect> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012f01c1e250$c93fb0a0$4c00a8c0@prefect> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Apr 12, 2002 at 02:35:13PM -0400, Bradley D. LaRonde wrote: > ----- Original Message ----- > From: "Maciej W. Rozycki" > To: "Bradley D. LaRonde" > Cc: "MIPS/Linux List (SGI)" > Sent: Friday, April 12, 2002 2:05 PM > Subject: Re: Can modules be stripped? > > > > On Fri, 12 Apr 2002, Bradley D. LaRonde wrote: > > > > > OK, you can't strip kernel modules (news to me, then again how often do > I > > > use modules?), but it can't be because they "are relocatables". I > routinely > > > strip libraries without problem, and those are relocatables too. > > > > What kind of libraries? Shared libraries are shared objects and not > > relocatables. > > Oh, oops. :-P Now I see what you mean. I confused shared object > w/relocatable. My bad. > > Did I know that kernel modules were "object files" i.e. relocatables. Yes. > But I've always referred to them as object files (.o), not relocatables, > hence the confusion. > > Which brings up an interesting question - why doesn't the kernel use .so > files for modules? If you're really curious, compare the gunk in insmod (quite a bit) with the gunk in ld.so (unspeakable). Shared libraries are a great deal more complicated than modules need to be. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Apr 12 17:39:35 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D0dZ8d030952 for ; Fri, 12 Apr 2002 17:39:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D0dZG4030951 for linux-mips-outgoing; Fri, 12 Apr 2002 17:39:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from buzz.ichilton.co.uk (pc1-stocb3-0-cust156.mid.cable.ntl.com [80.4.62.156]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3D0dW8d030948 for ; Fri, 12 Apr 2002 17:39:32 -0700 Received: by buzz.ichilton.co.uk (Postfix, from userid 100) id A34151CE3CA; Sat, 13 Apr 2002 01:40:09 +0100 (BST) Date: Sat, 13 Apr 2002 01:40:09 +0100 From: Ian Chilton To: Stuart Hughes Cc: Scott A McConnell , "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? Message-ID: <20020413004009.GE897@buzz.ichilton.co.uk> Reply-To: Ian Chilton Mail-Followup-To: Stuart Hughes , Scott A McConnell , "MIPS/Linux List (SGI)" References: <3CB71C48.B768A40D@cotw.com> <3CB711CD.83F65C13@zentropix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB711CD.83F65C13@zentropix.com> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, > Be careful what you strip. I found the safest thing was to use 'strip > -g' I always use strip --strip-debug Bye for Now, Ian ----------------------------- Ian Chilton E-Mail: ian@ichilton.co.uk ----------------------------- From owner-linux-mips@oss.sgi.com Fri Apr 12 18:14:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D1EP8d031739 for ; Fri, 12 Apr 2002 18:14:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D1EPDK031738 for linux-mips-outgoing; Fri, 12 Apr 2002 18:14:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3D1E78d031730 for ; Fri, 12 Apr 2002 18:14:09 -0700 Received: (qmail 2787 invoked from network); 13 Apr 2002 01:14:44 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Apr 2002 01:14:44 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 407D43000BA; Sat, 13 Apr 2002 11:14:37 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B842E94 for ; Sat, 13 Apr 2002 11:14:37 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-reply-to: Your message of "Fri, 12 Apr 2002 12:41:28 EST." <3CB71C48.B768A40D@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Apr 2002 11:14:31 +1000 Message-ID: <22260.1018660471@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 12 Apr 2002 12:41:28 -0500, Scott A McConnell wrote: >For my vr5432 based board (2.4.5) I can strip and run executables. > >If I strip a module, insmod dies in obj_load() with Floating point >exception. The rules for stripping a module are "unusual". Some symbols have to be kept even if they are static, because even static symbols can be exported. The combination of strip -g to remove all debugging data plus the script below is safe. Run as 'strip_module $(modprobe -l)'. Also note that insmod supports compressed modules if you configure modutils with --enable-zlib. I do not know if busybox supports this feature of insmod. strip_module. #!/bin/sh # # Given a list of objects, strip all static symbols except those # required by insmod. # # Copyright Keith Owens . GPL. # Sat Feb 1 12:52:17 EST 1997 # # Mainly intended for reducing the size of modules to save space # on emergency and install disks. Be aware that removing the # static symbols reduces the amount of diagnostic information # available for oops. Not recommended for normal module usage. # # This code requires the modules use MODULE_PARM and EXPORT_. # Do not strip modules that have not been converted to use # MODULE_PARM or are using the old method of exporting symbols. # In particular do not use on modules prior to 2.1.20 (approx). # # The objects are stripped in /tmp, only if the strip works is # the original overwritten. If the command line to strip the # symbols becomes too long, the strip is done in multiple passes. # Running strip_module twice on the same object is safe (and a # waste of time). # cat > /tmp/$$.awk <<\EOF BEGIN { strip = "/usr/bin/objcopy"; nm = "/usr/bin/nm"; cp = "/bin/cp"; mv = "/bin/mv"; rm = "/bin/rm"; tmp = "/tmp"; command_size = 400; # arbitrary but safe getline < "/proc/self/stat"; pid = $1; tmpcopy = tmp "/" pid ".object"; nmout = tmp "/" pid ".nmout"; for (i = 1; i < ARGC; ++i) strip_module(ARGV[i]); do_command(rm " -f " tmpcopy " " nmout); exit(0); } function strip_module(object, keep_symbol, to_strip, symbol, command, changed) { do_command(cp " -a " object " " tmpcopy); do_command(nm " " tmpcopy " > " nmout); # delete array_name sometimes breaks, internal error, play safe for (symbol in keep_symbol) delete keep_symbol[symbol]; for (symbol in to_strip) delete to_strip[symbol]; new_module_format = 0; while ((getline < nmout) > 0) { $0 = substr($0, 10); # b static variable, uninitialised # d static variable, initialised # r static array, initialised # t static label/procedures if ($1 ~ /[bdrt]/) to_strip[$2] = ""; else if ($1 != "?") keep_symbol[$2] = ""; else if ($0 ~ /\? __ksymtab_/) keep_symbol[substr($2, 11)] = ""; else if ($0 ~ /\? __module_parm_/) keep_symbol[substr($2, 15)] = ""; if ($0 ~ /\? __module/) new_module_format = 1; } close(nmout); command = ""; changed = 0; if (new_module_format) { for (symbol in to_strip) { if (!(symbol in keep_symbol)) { changed = 1; if (length(command) > command_size) { do_command(strip command " " tmpcopy); command = ""; } command = command " --strip-symbol=" symbol; } } } if (command != "") { changed = 1; do_command(strip command " " tmpcopy); } if (changed) do_command(mv " " tmpcopy " " object); } function do_command(command) { if ((ret = system(command)) != 0) giveup("command \"" command "\" failed " ret, ret); } function giveup(message, ret) { print "strip_module: " message > "/dev/stderr"; exit(ret); } EOF awk -f /tmp/$$.awk "$@" ret=$? rm -f /tmp/$$.awk exit $ret From owner-linux-mips@oss.sgi.com Sat Apr 13 01:02:35 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D82Z8d008325 for ; Sat, 13 Apr 2002 01:02:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D82ZlE008324 for linux-mips-outgoing; Sat, 13 Apr 2002 01:02:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from libra.seed.net.tw (libra.seed.net.tw [192.72.81.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3D82S8d008318 for ; Sat, 13 Apr 2002 01:02:29 -0700 Received: from sw59-226-127.adsl.seed.net.tw ([61.59.226.127] helo=libra.seed.net.tw) by libra.seed.net.tw with esmtp (Seednet MTA build 20010831) id 16wIUo-0000P0-00; Sat, 13 Apr 2002 16:02:55 +0800 Message-ID: <3CB7E629.9060105@libra.seed.net.tw> Date: Sat, 13 Apr 2002 16:02:49 +0800 From: Tim Wu Reply-To: chtimwu@libra.seed.net.tw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: "Bradley D. LaRonde" CC: linux-mips Subject: Re: LEXRA MIPS References: <3CB68CC8.1050207@libra.seed.net.tw> <005901c1e217$058f7f20$4c00a8c0@prefect> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I insert a show_registers() into the begining of do_ri(). It seems that CPU runs into data section. $0 : 00000000 1000fc00 00000014 00000000 00000001 00000000 00000000 00000000 $8 : 0000fc00 7fff7a78 00000000 00000002 00000000 00000000 00000000 00000002 $16: 00000004 7fff7e10 7fff7e18 00000000 100604b0 00000600 7fff7e28 00000010 $24: 810d6080 00000000 1005e870 7fff7a58 7fff7db0 7fff7a68 Hi : 00000000 Lo : 00000000 epc : 7fff7aa8 Not tainted Status: 0000fc0c Cause : 10000028 Process ping (pid: 24, stackpage=81ff2000) Stack: 386d4381 31323100 00000000 00000000 24021000 00000000 00000000 0000fc0c 2ab39a1c 00000000 00000000 00000000 2ab9f550 00000000 00000200 00000000 00000000 00000000 00000003 00000000 7fff7d08 00000000 000000c0 00000000 00000000 00000000 0000fc00 00000000 81ff0210 00000000 00000000 00000000 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000002 ... Call Trace: Code: 00000000 00000003 00000000 <7fff7d08> 00000000 000000c0 00000000 00000000 00000000 Bradley D. LaRonde wrote: > ----- Original Message ----- > From: "Tim Wu" > To: "linux-mips" > Sent: Friday, April 12, 2002 3:29 AM > Subject: LEXRA MIPS > > > >>I traced the kernel source and found SIGILL is sent by the exception >>handler, do_ri(). >> > > Can you tell what/where the reserved (illegal) instruction is that causes > the trap? > > Regards, > Brad > > > From owner-linux-mips@oss.sgi.com Sat Apr 13 07:44:09 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3DEi88d021215 for ; Sat, 13 Apr 2002 07:44:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3DEi8NU021214 for linux-mips-outgoing; Sat, 13 Apr 2002 07:44:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns1.ltc.com (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3DEhl8d021201 for ; Sat, 13 Apr 2002 07:43:54 -0700 Received: from prefect (prefect.mshome.net [192.168.0.76]) by ns1.ltc.com (Postfix) with SMTP id EA6FC590B2; Sat, 13 Apr 2002 10:39:58 -0400 (EDT) Message-ID: <006a01c1e2f9$c2e053a0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: Cc: "linux-mips" References: <3CB68CC8.1050207@libra.seed.net.tw> <005901c1e217$058f7f20$4c00a8c0@prefect> <3CB7E629.9060105@libra.seed.net.tw> Subject: Re: LEXRA MIPS Date: Sat, 13 Apr 2002 10:44:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You say this only happens when a process raises a signal. Maybe the signal trampoline is getting messed up. Do you see the same behaviour with and without a signal handler installed for the raised signal? Regards, Brad ----- Original Message ----- From: "Tim Wu" To: "Bradley D. LaRonde" Cc: "linux-mips" Sent: Saturday, April 13, 2002 4:02 AM Subject: Re: LEXRA MIPS > I insert a show_registers() into the begining of do_ri(). > It seems that CPU runs into data section. > > $0 : 00000000 1000fc00 00000014 00000000 00000001 00000000 00000000 00000000 > $8 : 0000fc00 7fff7a78 00000000 00000002 00000000 00000000 00000000 00000002 > $16: 00000004 7fff7e10 7fff7e18 00000000 100604b0 00000600 7fff7e28 00000010 > $24: 810d6080 00000000 1005e870 7fff7a58 7fff7db0 7fff7a68 > Hi : 00000000 > Lo : 00000000 > epc : 7fff7aa8 Not tainted > Status: 0000fc0c > Cause : 10000028 > Process ping (pid: 24, stackpage=81ff2000) > Stack: 386d4381 31323100 00000000 00000000 24021000 00000000 00000000 0000fc0c > 2ab39a1c 00000000 00000000 00000000 2ab9f550 00000000 00000200 00000000 > 00000000 00000000 00000003 00000000 7fff7d08 00000000 000000c0 00000000 > 00000000 00000000 0000fc00 00000000 81ff0210 00000000 00000000 00000000 > 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000002 ... > Call Trace: > Code: 00000000 00000003 00000000 <7fff7d08> 00000000 000000c0 00000000 > 00000000 00000000 > > > > Bradley D. LaRonde wrote: > > > ----- Original Message ----- > > From: "Tim Wu" > > To: "linux-mips" > > Sent: Friday, April 12, 2002 3:29 AM > > Subject: LEXRA MIPS > > > > > > > >>I traced the kernel source and found SIGILL is sent by the exception > >>handler, do_ri(). > >> > > > > Can you tell what/where the reserved (illegal) instruction is that causes > > the trap? > > > > Regards, > > Brad > > > > > > > > > From owner-linux-mips@oss.sgi.com Sat Apr 13 16:02:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3DN2L8d001074 for ; Sat, 13 Apr 2002 16:02:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3DN2Lin001073 for linux-mips-outgoing; Sat, 13 Apr 2002 16:02:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3DN258d001061 for ; Sat, 13 Apr 2002 16:02:06 -0700 Received: (qmail 28674 invoked by uid 0); 13 Apr 2002 19:29:48 -0000 Received: from pd9e4155d.dip.t-dialin.net (HELO bogon.ms20.nix) (217.228.21.93) by mail.gmx.net (mp002-rz3) with SMTP; 13 Apr 2002 19:29:48 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 9F69537130; Sat, 13 Apr 2002 21:28:12 +0200 (CEST) Date: Sat, 13 Apr 2002 21:28:11 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: head.S and init_task.c vs addinitrd Message-ID: <20020413192811.GA25750@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --JYK4vJDZwFMowpUq Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, short:=20 The attached patch modifies head.S/init_task.c to restore the old habit of merging all sections(besides .reginfo) into one segment which lets elf2ecoff/addinitrd work again. long: some of the recent head.S/init_task.c changes break addinitrd. In 2.4.16 we had two segments which allowed elf2ecoff to put everything (besides bss) into one text section (dropping REGINFO) in the ecoff image leaving the data section emtpy. Addinitrd then later merged the initial ramdisk into that empty data section. ELF kernel: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align REGINFO 0x1c2ae0 0x881c3ae0 0x881c3ae0 0x00018 0x00018 R 0x4 LOAD 0x001000 0x88002000 0x88002000 0x1e8000 0x1ff560 RWE 0x1000 Section to Segment mapping: Segment Sections... 00 .reginfo=20 01 .text .fixup .kstrtab __ex_table __ksymtab .text.init .data.init = .setup.init .initcall.init .data.cacheline_aligned .reginfo .data .bss ECOFF kernel: Sections: Idx Name Size VMA LMA File off A= lgn 0 .text 001e8000 0000000088002000 0000000088002000 000000d0 2= **4 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000000 00000000881ea000 00000000881ea000 001e80d0 2= **4 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00017560 00000000881ea000 00000000881ea000 001e80d0 2= **4 CONTENTS, ALLOC, NEVER_LOAD Now as of 2.4.17+ we have three segments described in the program header: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align REGINFO 0x1c4ae0 0x881c5ae0 0x881c5ae0 0x00018 0x00018 R 0x4 LOAD 0x001000 0x88002000 0x88002000 0x1ab140 0x1ab140 R E 0x1000 LOAD 0x1ad000 0x881ae000 0x881ae000 0x43000 0x5a560 RWE 0x1000 Section to Segment mapping: Segment Sections... 00 .reginfo=20 01 .text .fixup .kstrtab __ex_table __ksymtab=20 02 .data.init_task .text.init .data.init .setup.init .initcall.init = .data.cacheline_aligned .reginfo .data .bss so there's no emtpy section left in the ecoff image for the initial ramdisk. What was the reasoning for the above change? And why exactly does this change cause a splitting into data and text segment where as of 2.4.16 there was only a "data" segment? Regards, -- Guido --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="init_task-2002-04-13.diff" Content-Transfer-Encoding: quoted-printable diff --exclude=3D*.orig --exclude=3D.* -Naur ../../kernel-source-2.4.17/arc= h/mips/kernel/head.S arch/mips/kernel/head.S --- ../../kernel-source-2.4.17/arch/mips/kernel/head.S Thu Mar 7 22:49:57 = 2002 +++ arch/mips/kernel/head.S Sat Apr 13 14:09:31 2002 @@ -178,10 +178,15 @@ .type \name, @object .endm =20 - .data - .align 12 + .text =20 page swapper_pg_dir, PGD_ORDER page empty_bad_page, 0 page empty_bad_page_table, 0 page invalid_pte_table, 0 + +/* + * Align to 8kb boundary for init_task_union which follows in the + * .text segment. + */ + .align 13 diff --exclude=3D*.orig --exclude=3D.* -Naur ../../kernel-source-2.4.17/arc= h/mips/kernel/init_task.c arch/mips/kernel/init_task.c --- ../../kernel-source-2.4.17/arch/mips/kernel/init_task.c Thu Mar 7 22:4= 9:57 2002 +++ arch/mips/kernel/init_task.c Sat Apr 13 14:09:31 2002 @@ -20,5 +20,5 @@ * The things we do for performance.. */ union task_union init_task_union - __attribute__((__section__(".data.init_task"))) =3D + __attribute__((__section__(".text"))) =3D { INIT_TASK(init_task_union.task) }; --T4sUOijqQbZv57TR-- --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8uIbLn88szT8+ZCYRAqXlAJ0W0hSSELN8/a+scajZDfl3ULObwACfZF4Y 8dTrKLlqWXRplOeDlqr9o2U= =xpP9 -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- From owner-linux-mips@oss.sgi.com Sun Apr 14 08:06:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EF618d003867 for ; Sun, 14 Apr 2002 08:06:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EF61Fw003866 for linux-mips-outgoing; Sun, 14 Apr 2002 08:06:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EF5r8d003852 for ; Sun, 14 Apr 2002 08:05:54 -0700 Received: (qmail 24676 invoked by uid 0); 14 Apr 2002 15:06:33 -0000 Received: from pd9e4155d.dip.t-dialin.net (HELO bogon.ms20.nix) (217.228.21.93) by mail.gmx.net (mp010-rz3) with SMTP; 14 Apr 2002 15:06:33 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 912AA365C6; Sun, 14 Apr 2002 17:04:56 +0200 (CEST) Date: Sun, 14 Apr 2002 17:04:56 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: ralf@gnu.org Subject: [patch]: minor addinitrd.c cleanup Message-ID: <20020414150456.GA11128@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com, ralf@gnu.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, patch makes sure we: - don't overwrite an existing .data section in the ecoff - opens the original kernel image read only applies to 2.4 as well as 2.5. -- Guido --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="addinitrd-2002-04-14.diff" Index: arch/mips/boot/addinitrd.c =================================================================== RCS file: /cvs/linux/arch/mips/boot/addinitrd.c,v retrieving revision 1.1.6.1 diff -u -u -r1.1.6.1 addinitrd.c --- arch/mips/boot/addinitrd.c 2001/12/13 21:22:23 1.1.6.1 +++ arch/mips/boot/addinitrd.c 2002/04/14 14:59:50 @@ -2,6 +2,8 @@ * addinitrd - program to add a initrd image to an ecoff kernel * * (C) 1999 Thomas Bogendoerfer + * 2002 Guido Guenther + * */ #include @@ -54,7 +56,7 @@ exit (1); } - if ((fd_vmlinux = open (argv[1],O_RDWR)) < 0) + if ((fd_vmlinux = open (argv[1],O_RDONLY)) < 0) die ("open vmlinux"); if (read (fd_vmlinux, &efile, sizeof efile) != sizeof efile) die ("read file header"); @@ -65,7 +67,10 @@ /* * check whether the file is good for us */ - /* TBD */ + if( eaout.dsize || esecs[1].s_size ) { + fprintf(2,".data section not empty. Giving up!\n"); + exit(1); + } /* * check, if we have to swab words --82I3+IH0IqGh5yIs-- From owner-linux-mips@oss.sgi.com Mon Apr 15 05:48:11 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FCmB8d020218 for ; Mon, 15 Apr 2002 05:48:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FCmBWS020217 for linux-mips-outgoing; Mon, 15 Apr 2002 05:48:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FCm78d020210 for ; Mon, 15 Apr 2002 05:48:08 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA21527; Mon, 15 Apr 2002 14:49:11 +0200 (MET DST) Date: Mon, 15 Apr 2002 14:49:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd In-Reply-To: <20020413192811.GA25750@bogon.ms20.nix> 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 Sat, 13 Apr 2002, Guido Guenther wrote: > some of the recent head.S/init_task.c changes break addinitrd. In 2.4.16 > we had two segments which allowed elf2ecoff to put everything (besides > bss) into one text section (dropping REGINFO) in the ecoff image leaving > the data section emtpy. Addinitrd then later merged the initial ramdisk > into that empty data section. Hmm, isn't that broken? I believe an initial RAM disk should be added to an ELF image, before converting it to ECOFF. Not everyone uses ECOFF and ELF is the "canonical" executable format for Linux. Everything else is a derivative. -- + 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 Apr 15 06:42:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FDgV8d023666 for ; Mon, 15 Apr 2002 06:42:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FDgVAi023665 for linux-mips-outgoing; Mon, 15 Apr 2002 06:42:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FDgQ8d023659 for ; Mon, 15 Apr 2002 06:42:27 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 1B0CB8D39; Mon, 15 Apr 2002 15:43:15 +0200 (CEST) Date: Mon, 15 Apr 2002 15:43:15 +0200 From: Guido Guenther To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd Message-ID: <20020415154314.A18602@gandalf.physik.uni-konstanz.de> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020413192811.GA25750@bogon.ms20.nix> 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, Apr 15, 2002 at 02:49:11PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 02:49:11PM +0200, Maciej W. Rozycki wrote: > On Sat, 13 Apr 2002, Guido Guenther wrote: > > > some of the recent head.S/init_task.c changes break addinitrd. In 2.4.16 > > we had two segments which allowed elf2ecoff to put everything (besides > > bss) into one text section (dropping REGINFO) in the ecoff image leaving > > the data section emtpy. Addinitrd then later merged the initial ramdisk > > into that empty data section. > > Hmm, isn't that broken? I believe an initial RAM disk should be added to > an ELF image, before converting it to ECOFF. Not everyone uses ECOFF and > ELF is the "canonical" executable format for Linux. Everything else is a > derivative. But we currently don't support relinking the ELF kernel to add a ramdisk, do we [1]? Elf2ecoff/addinitrd is the only way I know of to achieve this and I still don't understand why the recent init_task.c/head.S changes where necessary which broke this. -- Guido [1] I know that one can link a ramdisk into the ELF image but this ramdisk hat to be available at kernel compile time which is not an option in many situations(e.g. Debian "boot-floppies"). From owner-linux-mips@oss.sgi.com Mon Apr 15 06:52:58 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FDqw8d024209 for ; Mon, 15 Apr 2002 06:52:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FDqvLM024208 for linux-mips-outgoing; Mon, 15 Apr 2002 06:52:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FDqT8d024180 for ; Mon, 15 Apr 2002 06:52:30 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23063; Mon, 15 Apr 2002 15:53:25 +0200 (MET DST) Date: Mon, 15 Apr 2002 15:53:25 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Jun Sun cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4: FPU exception updates 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 Hello, Here are updates to negate the FPU exception presence flag. Tested on an R3400 and an R4400SC. FPU-less configurations not tested but they should work as the changes are straightforward. Ralf, 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.18-20020412-irq-49 diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/dec/setup.c linux-mips-2.4.18-20020412/arch/mips/dec/setup.c --- linux-mips-2.4.18-20020412.macro/arch/mips/dec/setup.c 2002-04-10 02:58:33.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/dec/setup.c 2002-04-13 01:42:32.000000000 +0000 @@ -733,7 +733,7 @@ void __init init_IRQ(void) set_except_vector(0, decstation_handle_int); /* Free the FPU interrupt if the exception is present. */ - if (mips_cpu.options & MIPS_CPU_FPUEX) { + if (!(mips_cpu.options & MIPS_CPU_NOFPUEX)) { cpu_fpu_mask = 0; dec_interrupt[DEC_IRQ_FPU] = -1; } diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/kernel/setup.c linux-mips-2.4.18-20020412/arch/mips/kernel/setup.c --- linux-mips-2.4.18-20020412.macro/arch/mips/kernel/setup.c 2002-04-10 02:58:36.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/kernel/setup.c 2002-04-13 01:47:38.000000000 +0000 @@ -234,7 +234,7 @@ static inline void cpu_probe(void) case PRID_IMP_R2000: mips_cpu.cputype = CPU_R2000; mips_cpu.isa_level = MIPS_CPU_ISA_I; - mips_cpu.options = MIPS_CPU_TLB; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; if (cpu_has_fpu()) mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; @@ -248,7 +248,7 @@ static inline void cpu_probe(void) else mips_cpu.cputype = CPU_R3000; mips_cpu.isa_level = MIPS_CPU_ISA_I; - mips_cpu.options = MIPS_CPU_TLB; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; if (cpu_has_fpu()) mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; @@ -261,7 +261,7 @@ static inline void cpu_probe(void) mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_VCE | MIPS_CPU_FPUEX; + MIPS_CPU_VCE; mips_cpu.tlbsize = 48; break; case PRID_IMP_VR41XX: @@ -274,14 +274,13 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R4300; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 32; break; case PRID_IMP_R4600: mips_cpu.cputype = CPU_R4600; mips_cpu.isa_level = MIPS_CPU_ISA_III; - mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU; mips_cpu.tlbsize = 48; break; #if 0 @@ -294,8 +293,7 @@ static inline void cpu_probe(void) */ mips_cpu.cputype = CPU_R4650; mips_cpu.isa_level = MIPS_CPU_ISA_III; - mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU; mips_cpu.tlbsize = 48; break; #endif @@ -329,14 +327,14 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R4700; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; break; case PRID_IMP_TX49: mips_cpu.cputype = CPU_TX49XX; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; mips_cpu.icache.ways = 4; mips_cpu.dcache.ways = 4; @@ -345,31 +343,28 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R5000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; break; case PRID_IMP_R5432: mips_cpu.cputype = CPU_R5432; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_WATCH; mips_cpu.tlbsize = 48; break; case PRID_IMP_R5500: mips_cpu.cputype = CPU_R5500; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_WATCH; mips_cpu.tlbsize = 48; break; case PRID_IMP_NEVADA: mips_cpu.cputype = CPU_NEVADA; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_DIVEC | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_DIVEC; mips_cpu.tlbsize = 48; mips_cpu.icache.ways = 2; mips_cpu.dcache.ways = 2; @@ -377,22 +372,20 @@ static inline void cpu_probe(void) case PRID_IMP_R6000: mips_cpu.cputype = CPU_R6000; mips_cpu.isa_level = MIPS_CPU_ISA_II; - mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU; mips_cpu.tlbsize = 32; break; case PRID_IMP_R6000A: mips_cpu.cputype = CPU_R6000A; mips_cpu.isa_level = MIPS_CPU_ISA_II; - mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU; mips_cpu.tlbsize = 32; break; case PRID_IMP_RM7000: mips_cpu.cputype = CPU_RM7000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; /* * Undocumented RM7000: Bit 29 in the info register of * the RM7000 v2.0 indicates if the TLB has 48 or 64 @@ -407,8 +400,7 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R8000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | - MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_FPUEX; + MIPS_CPU_FPU | MIPS_CPU_32FPR; mips_cpu.tlbsize = 384; /* has wierd TLB: 3-way x 128 */ break; case PRID_IMP_R10000: @@ -416,8 +408,7 @@ static inline void cpu_probe(void) mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_COUNTER | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_COUNTER | MIPS_CPU_WATCH; mips_cpu.tlbsize = 64; break; default: @@ -452,8 +443,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; case PRID_IMP_5KC: @@ -470,8 +460,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; default: @@ -497,8 +486,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; default: @@ -517,8 +505,7 @@ cpu_4kc: MIPS_CPU_MCHECK; #ifndef CONFIG_SB1_PASS_1_WORKAROUNDS /* FPU in pass1 is known to have issues. */ - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; #endif break; default: diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/kernel/traps.c linux-mips-2.4.18-20020412/arch/mips/kernel/traps.c --- linux-mips-2.4.18-20020412.macro/arch/mips/kernel/traps.c 2002-04-10 02:58:40.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/kernel/traps.c 2002-04-13 02:01:40.000000000 +0000 @@ -916,7 +916,8 @@ void __init trap_init(void) set_except_vector(12, handle_ov); set_except_vector(13, handle_tr); - if (mips_cpu.options & MIPS_CPU_FPUEX) + if ((mips_cpu.options & MIPS_CPU_FPU) && + !(mips_cpu.options & MIPS_CPU_NOFPUEX)) set_except_vector(15, handle_fpe); if (mips_cpu.options & MIPS_CPU_MCHECK) set_except_vector(24, handle_mcheck); diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/include/asm-mips/cpu.h linux-mips-2.4.18-20020412/include/asm-mips/cpu.h --- linux-mips-2.4.18-20020412.macro/include/asm-mips/cpu.h 2002-04-10 02:59:00.000000000 +0000 +++ linux-mips-2.4.18-20020412/include/asm-mips/cpu.h 2002-04-13 01:51:39.000000000 +0000 @@ -159,6 +159,6 @@ enum cputype { #define MIPS_CPU_CACHE_CDEX 0x00000800 /* Create_Dirty_Exclusive CACHE op */ #define MIPS_CPU_MCHECK 0x00001000 /* Machine check exception */ #define MIPS_CPU_EJTAG 0x00002000 /* EJTAG exception */ -#define MIPS_CPU_FPUEX 0x00004000 /* FPU exception */ +#define MIPS_CPU_NOFPUEX 0x00004000 /* no FPU exception */ #endif /* _ASM_CPU_H */ From owner-linux-mips@oss.sgi.com Mon Apr 15 07:08:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FE8c8d025005 for ; Mon, 15 Apr 2002 07:08:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FE8clt025004 for linux-mips-outgoing; Mon, 15 Apr 2002 07:08:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FE8W8d024999 for ; Mon, 15 Apr 2002 07:08:33 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23441; Mon, 15 Apr 2002 16:09:41 +0200 (MET DST) Date: Mon, 15 Apr 2002 16:09:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd In-Reply-To: <20020415154314.A18602@gandalf.physik.uni-konstanz.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 Mon, 15 Apr 2002, Guido Guenther wrote: > > Hmm, isn't that broken? I believe an initial RAM disk should be added to > > an ELF image, before converting it to ECOFF. Not everyone uses ECOFF and > > ELF is the "canonical" executable format for Linux. Everything else is a > > derivative. > But we currently don't support relinking the ELF kernel to add a ramdisk, I don't know. We are going to have to if the BOOTP/NFS-root code gets removed, which will supposedly happen quite soon. > do we [1]? Elf2ecoff/addinitrd is the only way I know of to achieve this > and I still don't understand why the recent init_task.c/head.S changes > where necessary which broke this. Maybe because that's an ugly hack (as I can see from your description). > [1] I know that one can link a ramdisk into the ELF image but this > ramdisk hat to be available at kernel compile time which is not an option in > many situations(e.g. Debian "boot-floppies"). It depends on how a kernel gets built. If we add "-r" to the current final link we'll get "vmlinux.o" that is a complete, self-contained kernel, that may be linked against a RAM-disk (or just relinked alone) without a problem. That's actually a generic solution and certainly something like this will likely have to get implemented as soon as a RAM-disk gets mandatory for block-device-less ;-) configurations. 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 Apr 15 07:20:08 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FEK88d025557 for ; Mon, 15 Apr 2002 07:20:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FEK8nf025555 for linux-mips-outgoing; Mon, 15 Apr 2002 07:20:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FEK48d025542 for ; Mon, 15 Apr 2002 07:20:05 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23682; Mon, 15 Apr 2002 16:21:11 +0200 (MET DST) Date: Mon, 15 Apr 2002 16:21:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-Reply-To: <22260.1018660471@ocs3.intra.ocs.com.au> 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 Sat, 13 Apr 2002, Keith Owens wrote: > The rules for stripping a module are "unusual". Some symbols have to > be kept even if they are static, because even static symbols can be > exported. The combination of strip -g to remove all debugging data Hmm, that looks weird to me. If exporting static symbols is permitted, shouldn't the symbols be marked global by EXPORT_SYMBOL() then? The following code seems to mark a static symbol global just fine: static int test = 0; asm(".global test"); so there should be no problem with doing the same in EXPORT_SYMBOL(). -- + 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 Apr 15 07:49:25 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FEnO8d027004 for ; Mon, 15 Apr 2002 07:49:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FEnO8o027003 for linux-mips-outgoing; Mon, 15 Apr 2002 07:49:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FEnK8d026996 for ; Mon, 15 Apr 2002 07:49:21 -0700 Received: (qmail 9251 invoked from network); 15 Apr 2002 14:50:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Apr 2002 14:50:08 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 988883000BA; Tue, 16 Apr 2002 00:50:05 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 8AA0794; Tue, 16 Apr 2002 00:50:05 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Maciej W. Rozycki" Cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-reply-to: Your message of "Mon, 15 Apr 2002 16:21:10 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2002 00:50:00 +1000 Message-ID: <7082.1018882200@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 15 Apr 2002 16:21:10 +0200 (MET DST), "Maciej W. Rozycki" wrote: >On Sat, 13 Apr 2002, Keith Owens wrote: > >> The rules for stripping a module are "unusual". Some symbols have to >> be kept even if they are static, because even static symbols can be >> exported. The combination of strip -g to remove all debugging data > > Hmm, that looks weird to me. If exporting static symbols is permitted, >shouldn't the symbols be marked global by EXPORT_SYMBOL() then? Exporting static symbols has always been allowed. Exported symbols are the module equivalent of lazy binding, which is logically no different from passing the address of a static symbol via a structure to a registration function. In either case the static symbol can be accessed from outside the object, without being marked as global. From owner-linux-mips@oss.sgi.com Mon Apr 15 08:31:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FFVu8d029089 for ; Mon, 15 Apr 2002 08:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FFVuwa029088 for linux-mips-outgoing; Mon, 15 Apr 2002 08:31:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FFVq8d029082 for ; Mon, 15 Apr 2002 08:31:53 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA25171; Mon, 15 Apr 2002 17:32:55 +0200 (MET DST) Date: Mon, 15 Apr 2002 17:32:54 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens cc: "MIPS/Linux List (SGI)" Subject: Re: Can modules be stripped? In-Reply-To: <7082.1018882200@ocs3.intra.ocs.com.au> 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, 16 Apr 2002, Keith Owens wrote: > Exporting static symbols has always been allowed. Exported symbols are > the module equivalent of lazy binding, which is logically no different > from passing the address of a static symbol via a structure to a > registration function. In either case the static symbol can be > accessed from outside the object, without being marked as global. Well, if you make a symbol available to other modules it becomes global implicitly as they may refer to it by its name (by means of relocations) and not an address known from elsewhere. So keeping the symbol marked local in the module's symbol table is against a run-time linker's usual behaviour. One may expect to perform `ld -rx' on a module and have it still work as it's what happens for every other relocatable. -- + 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 Apr 15 09:17:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FGH08d032271 for ; Mon, 15 Apr 2002 09:17:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FGH00s032270 for linux-mips-outgoing; Mon, 15 Apr 2002 09:17:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FGGs8d032265 for ; Mon, 15 Apr 2002 09:16:55 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id BFC898D35; Mon, 15 Apr 2002 18:17:43 +0200 (CEST) Date: Mon, 15 Apr 2002 18:17:43 +0200 From: Guido Guenther To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd Message-ID: <20020415181743.A24174@gandalf.physik.uni-konstanz.de> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020415154314.A18602@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 macro@ds2.pg.gda.pl on Mon, Apr 15, 2002 at 04:09:41PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 04:09:41PM +0200, Maciej W. Rozycki wrote: > On Mon, 15 Apr 2002, Guido Guenther wrote: > > > > Hmm, isn't that broken? I believe an initial RAM disk should be added to > > > an ELF image, before converting it to ECOFF. Not everyone uses ECOFF and > > > ELF is the "canonical" executable format for Linux. Everything else is a > > > derivative. > > But we currently don't support relinking the ELF kernel to add a ramdisk, > > I don't know. We are going to have to if the BOOTP/NFS-root code gets > removed, which will supposedly happen quite soon. > > > do we [1]? Elf2ecoff/addinitrd is the only way I know of to achieve this > > and I still don't understand why the recent init_task.c/head.S changes > > where necessary which broke this. > > Maybe because that's an ugly hack (as I can see from your description). Are you telling me the only reason for the changes in init_task.c/head.S were made to break the elf2ecoff/addinitrd "hack"? Where exactly was there a hack in head.S/init_task.c. Please point me to the line of code since I don't understand enough about the kernel to see it. > > > [1] I know that one can link a ramdisk into the ELF image but this > > ramdisk hat to be available at kernel compile time which is not an option in > > many situations(e.g. Debian "boot-floppies"). > > It depends on how a kernel gets built. If we add "-r" to the current > final link we'll get "vmlinux.o" that is a complete, self-contained > kernel, that may be linked against a RAM-disk (or just relinked alone) > without a problem. That's actually a generic solution and certainly > something like this will likely have to get implemented as soon as a > RAM-disk gets mandatory for block-device-less ;-) configurations. That's 2.5 stuff. We should not break expected behavior in 2.4. -- Guido From owner-linux-mips@oss.sgi.com Mon Apr 15 11:12:41 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FICf8d005975 for ; Mon, 15 Apr 2002 11:12:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FICfuq005974 for linux-mips-outgoing; Mon, 15 Apr 2002 11:12:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FICb8d005961 for ; Mon, 15 Apr 2002 11:12:38 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA29321; Mon, 15 Apr 2002 20:13:43 +0200 (MET DST) Date: Mon, 15 Apr 2002 20:13:42 +0200 (MET DST) From: "Maciej W. Rozycki" To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd In-Reply-To: <20020415181743.A24174@gandalf.physik.uni-konstanz.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 Mon, 15 Apr 2002, Guido Guenther wrote: > Are you telling me the only reason for the changes in init_task.c/head.S > were made to break the elf2ecoff/addinitrd "hack"? Where exactly was > there a hack in head.S/init_task.c. Please point me to the line of code > since I don't understand enough about the kernel to see it. I meant it stopped working because it is an ugly hack. It is too fragile to work in all cases. > That's 2.5 stuff. We should not break expected behavior in 2.4. Agreed. -- + 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 Apr 15 11:41:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FIfC8d008193 for ; Mon, 15 Apr 2002 11:41:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FIfCjQ008192 for linux-mips-outgoing; Mon, 15 Apr 2002 11:41:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-141.ayrnetworks.com [64.166.72.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FIf98d008182 for ; Mon, 15 Apr 2002 11:41:10 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g3FIciu21802 for linux-mips@oss.sgi.com; Mon, 15 Apr 2002 11:38:44 -0700 Date: Mon, 15 Apr 2002 11:38:44 -0700 From: William Jhun To: linux-mips@oss.sgi.com Subject: rm7k flush_icache_line() in rm7k_dma_cache_* Message-ID: <20020415113844.A21747@ayrnetworks.com> 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 Hello, We've been experiencing some problems with our RM7k cache code which is based on the sgi mm/rm7k.c from around kernel version 2.4.2. While trying to track this down, we noticed that someone added a call to flush_icache_line() in the rm7k_dma_cache_*() routines (now mm/c-rm7k.c). What is the reason for this? It is our understanding that the instruction cache does not write back, and so stale cache lines in the icache which are later used for data/dma would seem innocuous. Is this not true? We could not find a CVS log entry to explain this, either. Did anyone experience problems without these calls to flush_icache_line()? Thanks, Will From owner-linux-mips@oss.sgi.com Mon Apr 15 12:08:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJ8J8d009969 for ; Mon, 15 Apr 2002 12:08:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJ8JsZ009968 for linux-mips-outgoing; Mon, 15 Apr 2002 12:08:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.85]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJ8I8d009965 for ; Mon, 15 Apr 2002 12:08:18 -0700 Received: from smtp-relay01.mac.com (smtp-relay01-qfe3 [10.13.10.224]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g3FJ98FO026937 for ; Mon, 15 Apr 2002 12:09:08 -0700 (PDT) Received: from asmtp01.mac.com ([10.13.10.65]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GUMIJ300.1VV for ; Mon, 15 Apr 2002 12:09:03 -0700 Received: from localhost ([65.25.221.221]) by asmtp01.mac.com (Netscape Messaging Server 4.15 asmtp01 Jun 21 2001 23:53:48) with ESMTP id GUMIJ200.0HV; Mon, 15 Apr 2002 12:09:02 -0700 Date: Mon, 15 Apr 2002 14:08:55 -0500 Subject: Linux for MIPS on SGI Indigo2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: linux-mips@fnet.fr To: linux-mips@oss.sgi.com From: Chris Wright In-Reply-To: Message-Id: <3B792D54-50A4-11D6-B60A-0050E4AEBF2A@mac.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am looking for detailed instructions on installing a linux distribution onto an SGI Indigo2 4400. Thank you. --Chris From owner-linux-mips@oss.sgi.com Mon Apr 15 12:22:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJM18d010748 for ; Mon, 15 Apr 2002 12:22:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJM16D010747 for linux-mips-outgoing; Mon, 15 Apr 2002 12:22:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJLv8d010742 for ; Mon, 15 Apr 2002 12:21:58 -0700 Received: from galadriel.physik.uni-konstanz.de (galadriel.physik.uni-konstanz.de [134.34.144.79]) by gandalf.physik.uni-konstanz.de (Postfix) with ESMTP id 891FD8D35; Mon, 15 Apr 2002 21:22:47 +0200 (CEST) Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 16xC3r-0004sv-00; Mon, 15 Apr 2002 21:22:47 +0200 Date: Mon, 15 Apr 2002 21:22:47 +0200 From: Guido Guenther To: Chris Wright Cc: linux-mips@oss.sgi.com Subject: Re: Linux for MIPS on SGI Indigo2 Message-ID: <20020415212247.A18769@galadriel.physik.uni-konstanz.de> Mail-Followup-To: Chris Wright , linux-mips@oss.sgi.com References: <3B792D54-50A4-11D6-B60A-0050E4AEBF2A@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B792D54-50A4-11D6-B60A-0050E4AEBF2A@mac.com>; from chris_wright@mac.com on Mon, Apr 15, 2002 at 02:08:55PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 02:08:55PM -0500, Chris Wright wrote: > I am looking for detailed instructions on installing a linux > distribution onto an SGI Indigo2 4400. Thank you. --Chris The graphics boards in the I2 are still all unsupported. You will have to do a serial console install, see: http://www.linux-debian.de/howto/debian-mips-woody-install.html and http://oss.sgi.com/mips/i2-howto.html for details. -- Guido From owner-linux-mips@oss.sgi.com Mon Apr 15 14:53:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FLrv8d019133 for ; Mon, 15 Apr 2002 14:53:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FLrvFT019132 for linux-mips-outgoing; Mon, 15 Apr 2002 14:53:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FLrr8d019128 for ; Mon, 15 Apr 2002 14:53:54 -0700 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g3FLp1M17553 for ; Mon, 15 Apr 2002 17:51:01 -0400 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g3FLsi923967 for ; Mon, 15 Apr 2002 17:54:44 -0400 Received: from redhat.com (dhcp-166.hsv.redhat.com [172.16.17.166]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g3FLsl809044 for ; Mon, 15 Apr 2002 16:54:47 -0500 Message-ID: <3CBB4BA7.1010304@redhat.com> Date: Mon, 15 Apr 2002 16:52:39 -0500 From: Lanny DeVaney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: RTC question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've used the NEW_TIME_C method to implement support for the Dallas 1501 RTC in my MIPS port . I now successfully read the hw clock, and the date program works, and I can change the time. However, the hwclock program tells me that it can't access the Hardware Clock and tells me that /dev/rtc doesn't exist (although it actually does) when running hwclock --debug. Also, I see an oddity that may be related - ping reports zero (as in 0 msec) round trip times always. I configured CONFIG_RTC into the kernel, and checked the major, minor of /dev/rtc on my embedded ramdisk. Also, I don't see /proc/driver/rtc. Is this normal behavior with NEW_TIME_C configurations? I've checked my rtc_get_time and rtc_set_time, ..., like I said, the 'date' program works, reading and writing to the clock. Thanks, Lanny DeVaney From owner-linux-mips@oss.sgi.com Mon Apr 15 15:15:28 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FMFS8d020291 for ; Mon, 15 Apr 2002 15:15:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FMFStu020290 for linux-mips-outgoing; Mon, 15 Apr 2002 15:15:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ksc.net.th (mail.ksc.net.th [203.107.131.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FMFL8d020276 for ; Mon, 15 Apr 2002 15:15:23 -0700 Received: from VAIO (l224ppp003.ksc.net.th [203.155.224.3]) by mail.ksc.net.th (8.11.6/8.11.2) with SMTP id g3FM8NW02835 for linux-mips@oss.sgi.com; Tue, 16 Apr 2002 05:08:25 +0700 Message-Id: <200204152208.g3FM8NW02835@mail.ksc.net.th> From: career To: Date: Tue, 16 Apr 2002 07:17:37 +0900 Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISpFPj8mJTUhPCVTJTkbKEI=?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Oshirase-Mailer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk $B"#A49q$N?M:`%P%s%/$XE>?&$N(B $B0l3g%(%s%H%j!?&%5%$%H$NJs=7@)%P%J!?&5a?&5G'(B $B?t$K1~$8$F!X(B1000$B1_(B/$B7o!Y99$KE>?&7h(B $BDj$G4pK\E*$K!X(B1O$BK|1_(B/$B7o!Y$r$*;YJ'(B $B$$CW$7$^$9!#(B $B"(1?1D\:Y$r$*Aw$j(B $BCW$7$^$9!#!c>\:Y4uK>!d(B bancom@bigfoot.com$B!!(B -------------------------------- $B"(!Z2r=|![$O?=$7Lu$4$6$$$^$;$s$,(B $B!!2<5-$X!Z6u%a!<%k![$r$*Aw$j$/$@(B $B!!$5$k$h$&$*4j$$?=$7$"$2$^$9!#(B dm_delet@bigfoot.com -------------------------------- $B%3%`%W%i%s4k2h(B($B%8%g%V%5!<%S%9(B) career_01@hotmail.com From owner-linux-mips@oss.sgi.com Mon Apr 15 17:29:49 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G0Tn8d027437 for ; Mon, 15 Apr 2002 17:29:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G0TnLO027435 for linux-mips-outgoing; Mon, 15 Apr 2002 17:29:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G0Tj8d027426 for ; Mon, 15 Apr 2002 17:29:45 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id RAA16425 for linux-mips@oss.sgi.com; Mon, 15 Apr 2002 17:30:32 -0700 X-Sieve: cmu-sieve 2.0 Received: from orion.mvista.com (IDENT:root@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g3G0DMB04171 for ; Mon, 15 Apr 2002 17:13:22 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id RAA16335; Mon, 15 Apr 2002 17:18:08 -0700 Date: Mon, 15 Apr 2002 17:18:07 -0700 From: Jun Sun To: Lanny DeVaney Subject: Re: RTC question Message-ID: <20020415171807.A16300@mvista.com> References: <3CBB4BA7.1010304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CBB4BA7.1010304@redhat.com>; from ldevaney@redhat.com on Mon, Apr 15, 2002 at 04:52:39PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf has not checked in the higher-level RTC driver yet. You can either build a kernel from the linux-mips project on sourceforge.net, where the driver is included, or try to apply the outdated patch from http://linux.junsun.net/patches/oss.sgi.com/submitted/011110.mips-rtc.011110.1900.patch It was created on Nov 11, 2001. Jun On Mon, Apr 15, 2002 at 04:52:39PM -0500, Lanny DeVaney wrote: > I've used the NEW_TIME_C method to implement support for the Dallas 1501 > RTC in my MIPS port . I now successfully read the hw clock, and the > date program works, and I can change the time. > > However, the hwclock program tells me that it can't access the Hardware > Clock and tells me that /dev/rtc doesn't exist (although it actually > does) when running hwclock --debug. Also, I see an oddity that may be > related - ping reports zero (as in 0 msec) round trip times always. I > configured CONFIG_RTC into the kernel, and checked the major, minor of > /dev/rtc on my embedded ramdisk. Also, I don't see /proc/driver/rtc. > > Is this normal behavior with NEW_TIME_C configurations? I've checked > my rtc_get_time and rtc_set_time, ..., like I said, the 'date' program > works, reading and writing to the clock. > > Thanks, > Lanny DeVaney > > > From owner-linux-mips@oss.sgi.com Tue Apr 16 00:40:47 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G7el8d014236 for ; Tue, 16 Apr 2002 00:40:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G7elNj014235 for linux-mips-outgoing; Tue, 16 Apr 2002 00:40:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G7ei8d014232 for ; Tue, 16 Apr 2002 00:40:44 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3G7faG31542; Tue, 16 Apr 2002 00:41:36 -0700 Date: Tue, 16 Apr 2002 00:41:36 -0700 From: Ralf Baechle To: William Jhun Cc: linux-mips@oss.sgi.com Subject: Re: rm7k flush_icache_line() in rm7k_dma_cache_* Message-ID: <20020416004136.A28097@dea.linux-mips.net> References: <20020415113844.A21747@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020415113844.A21747@ayrnetworks.com>; from wjhun@ayrnetworks.com on Mon, Apr 15, 2002 at 11:38:44AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 11:38:44AM -0700, William Jhun wrote: > We've been experiencing some problems with our RM7k cache code which is > based on the sgi mm/rm7k.c from around kernel version 2.4.2. While > trying to track this down, we noticed that someone added a call to > flush_icache_line() in the rm7k_dma_cache_*() routines (now > mm/c-rm7k.c). What is the reason for this? It is our understanding that > the instruction cache does not write back, and so stale cache lines in > the icache which are later used for data/dma would seem innocuous. Is > this not true? We could not find a CVS log entry to explain this, > either. Did anyone experience problems without these calls to > flush_icache_line()? All the DMA cache flushes are only supposed to be used from within the PCI DMA API that is they don't have to deal with instruction caches ever. As such these flushes are bogus and I'll remove them. Ralf From owner-linux-mips@oss.sgi.com Tue Apr 16 02:14:00 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G9E08d021563 for ; Tue, 16 Apr 2002 02:14:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G9E0xu021562 for linux-mips-outgoing; Tue, 16 Apr 2002 02:14:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G9Du8d021551 for ; Tue, 16 Apr 2002 02:13:57 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id B713F8D35; Tue, 16 Apr 2002 11:14:49 +0200 (CEST) Date: Tue, 16 Apr 2002 11:14:49 +0200 From: Guido Guenther To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: head.S and init_task.c vs addinitrd Message-ID: <20020416111449.A18886@gandalf.physik.uni-konstanz.de> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020415181743.A24174@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 macro@ds2.pg.gda.pl on Mon, Apr 15, 2002 at 08:13:42PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 08:13:42PM +0200, Maciej W. Rozycki wrote: > On Mon, 15 Apr 2002, Guido Guenther wrote: > > > Are you telling me the only reason for the changes in > > init_task.c/head.S > > were made to break the elf2ecoff/addinitrd "hack"? Where exactly was > > there a hack in head.S/init_task.c. Please point me to the line of > > code > > since I don't understand enough about the kernel to see it. > > I meant it stopped working because it is an ugly hack. It is too > fragile > to work in all cases. I admit it's fragile but I'm still puzzled why the changes broke it and if we can revert those changes on the linux_2_4 branch. -- Guido From owner-linux-mips@oss.sgi.com Tue Apr 16 13:23:20 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GKNK8d013260 for ; Tue, 16 Apr 2002 13:23:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GKNK2F013259 for linux-mips-outgoing; Tue, 16 Apr 2002 13:23:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GKNB8d013240 for ; Tue, 16 Apr 2002 13:23:11 -0700 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g3GKKIM03538 for ; Tue, 16 Apr 2002 16:20:18 -0400 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g3GKO5932532 for ; Tue, 16 Apr 2002 16:24:05 -0400 Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g3GKO6828614; Tue, 16 Apr 2002 15:24:06 -0500 Message-ID: <3CBC88C5.1000604@redhat.com> Date: Tue, 16 Apr 2002 15:25:41 -0500 From: Louis Hamilton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Patch SR71K support - questions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, First a little background for the problem I'm looking at: I picked up an SR71000 support patch (from Jason Gunthorpe sent to this list) and have applied it to our 2.4 MIPS kernel tree. This is a Sandcraft EV-SR71000-500 cpu module running on a Galileo EV-64240-BP base board in big endian mode. What happens is the kernel comes up to the point in init where /sbin/init is execve'd and hangs (or waits) forever. Since our QED RM7000 module (which we also ported) is able to bootup all the way we don't suspect file system problems. This board has the PMON Galileo Technology monitor ver. 1.4 in 8-bit flash which does some SR71K cache init by doing a secondary/tertiary flash initialize operation as outlined in the SR71K Cpu Spec in section 7.5.18. At the load_mmu stage of bring-up I noticed I cannot call the "clear_enable_caches" routine without suffering an exeception. This is in arch/mips/mm/c-sr71000.c, routine ld_mmu_sr71000 where the call is made to clear_enable_caches as a KSEG1 address. I noticed the config register K0 is already set (before load_mmu) to 0x3 (Cached, Write-back) and that L2, L3 are enabled, no doubt due to some init done by the PMON monitor. Temporarily commenting out the call to clear_enable_caches step, the kernel gets past the exception problem and progresses to the point where execve seems to hang. So my questions are: Is this the latest SR71K support patch? (I can't get access in my browser to http://oss.sgi.com/mips/archive to see prior postings on this...) Is anyone else using this patch? If so, is it working ok and what hardware flavor(s) are you using? What SR71K cpu init is your bootloader or monitor doing before your kernel runs? Any ideas why the tag init loop and secondary/tertiary flash invalidate step in clear_enable_caches crashes the boot-up? Tia, Louis Louis Hamilton Red Hat, Inc. hamilton@redhat.com From owner-linux-mips@oss.sgi.com Tue Apr 16 17:18:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H0IV8d024990 for ; Tue, 16 Apr 2002 17:18:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H0IV0l024989 for linux-mips-outgoing; Tue, 16 Apr 2002 17:18:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3H0Hg8d024961 for ; Tue, 16 Apr 2002 17:17:42 -0700 Received: (qmail 25148 invoked from network); 17 Apr 2002 00:18:31 -0000 Received: from unknown (HELO wakko.debian.net) ([24.86.210.128]) (envelope-sender ) by crack-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 17 Apr 2002 00:18:30 -0000 Received: from localhost ([127.0.0.1] helo=wakko.debian.net ident=jgg) by wakko.debian.net with smtp (Exim 3.16 #1 (Debian)) id 16xd9c-0004nv-00; Tue, 16 Apr 2002 18:18:32 -0600 Date: Tue, 16 Apr 2002 18:18:32 -0600 (MDT) From: Jason Gunthorpe X-Sender: jgg@wakko.debian.net Reply-To: Jason Gunthorpe To: Louis Hamilton cc: linux-mips@oss.sgi.com Subject: Re: Patch SR71K support - questions In-Reply-To: <3CBC88C5.1000604@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1444446418-1735939474-1019002712=:18447" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1444446418-1735939474-1019002712=:18447 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 Apr 2002, Louis Hamilton wrote: > What happens is the kernel comes up to the point in init where /sbin/init is > execve'd and hangs (or waits) forever. Since our QED RM7000 module > (which we also ported) is able to bootup all the way we don't suspect > file system problems. You may want to try disabling support for WAIT, if the errata fix is not properly engaging for some reason you might hang in init. > At the load_mmu stage of bring-up I noticed I cannot call the > "clear_enable_caches" routine without suffering an exeception. This is in > arch/mips/mm/c-sr71000.c, routine > ld_mmu_sr71000 where the call is made to clear_enable_caches as a KSEG1 > address. That's a bit odd, Linux type exceptions are generally not active when cache init is done - so the exception must come from pmon? My stuff was tested without a monitor program like pmon, Linux is the first thing the processor executed when it came out of reset. The only init done (in prom_init) is to set the tcache size and enable the tcache bits. > I noticed the config register K0 is already set (before load_mmu) to 0x3 > (Cached, Write-back) > and that L2, L3 are enabled, no doubt due to some init done by the PMON > monitor. You definately do not want to try to cache init if the caches are turned on, it will blow away any pending writebacks. This is true on the RM7K code too, so I'm not sure what the proper solution should be. This may be why you see it crash when it runs, the stack/etc could be trashed if kseg0 caching is enabled when cec is called. Presumably your pmon has been hacked to support SR71K - if it it touching the caches it is really not safe to use stuff made for RM7K on the SR71K. I have tested this on the SR71010A-600 chips, with and without tcache. > Is this the latest SR71K support patch? (I can't get access in my > browser to > http://oss.sgi.com/mips/archive to see prior postings on this...) It is the latest I have posted, internally I have a version that is against a newer 2.4 kernel, has a bug fix for the cec routine and has the right name for the chip (woops). I don't have time to make a proper diff right now, but I have attached the mm/c-sr71000.c file (note the name change) I don't think the rest of the patch has really been changed. Jason --1444446418-1735939474-1019002712=:18447 Content-Type: TEXT/x-csrc; name="c-sr71000.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyoNCiAgSmFzb24gR3VudGhvcnBlIDxqZ2dAeW90dGF5b3R0YS5jb20+DQog IENvcHlyaWdodCAoQykgMjAwMiBZb3R0YVlvdHRhLiBJbmMuDQogICANCiAg QmFzZWQgb24gYy1taXBzMzI6DQogIEtldmluIEQuIEtpc3NlbGwsIGtldmlu a0BtaXBzLmNvbSBhbmQgQ2Fyc3RlbiBMYW5nZ2FhcmQsIGNhcnN0ZW5sQG1p cHMuY29tDQogIENvcHlyaWdodCAoQykgMjAwMCBNSVBTIFRlY2hub2xvZ2ll cywgSW5jLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICBUaGlzIGZpbGUg aXMgc3ViamVjdCB0byB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhl IEdOVSBHZW5lcmFsIFB1YmxpYw0KICBMaWNlbnNlLiAgU2VlIHRoZSBmaWxl ICJDT1BZSU5HIiBpbiB0aGUgbWFpbiBkaXJlY3Rvcnkgb2YgdGhpcyBhcmNo aXZlDQogIGZvciBtb3JlIGRldGFpbHMuDQogICANCiAgU2FuZGNyYWZ0IFNS NzEwMDAgY2FjaGUgcm91dGluZXMuIA0KICBUaGUgU1I3MTAwMCBpcyBhIE1J UFM2NCBjb21wYXRpYmxlIENQVSB3aXRoIDQgY2FjaGVzOg0KICAgKiA0IHdh eSAzMksgcHJpbWFyeSBJQ2FjaGUgLSB2aXJ0dWFsbHkgaW5kZXhlZC9waHlz aWNhbGx5IHRhZ2dlZA0KICAgKiA0IHdheSAzMksgcHJpbWFyeSBEQ2FjaGUg LSB2aXJ0dWFsbHkgaW5kZXhlZC9waHlzaWNhbGx5IHRhZ2dlZA0KICAgKiA4 IHdheSA1MTJLIHNlY29uZGFyeSBjYWNoZSAtIHBoeXNpY2FsbHkgaW5kZXhl ZC90YWdlZA0KICAgKiA4IHdheSB1cCB0byAxNk0gdGVydGlhcnkgY2FjaGUg LSBwaHlzaWNhbGx5IGluZGV4ZWQvdGFnZWQgKGFuZCBvZmYgY2hpcCkNCiAg IA0KICBJQ2FjaGUgYW5kIERDYWNoZSBkbyBub3QgaGF2ZSBhbnkgc29ydCBv ZiBzbm9vcGluZy4gVW5saWtlIHRoZSBSTTdrLA0KICB0aGUgdmlydHVhbCBp bmRleCBpcyAxMyBiaXRzLCBhbmQgd2UgdXNlIGEgNGsgcGFnZSBzaXplLiBU aGlzIG1lYW5zIHlvdSANCiAgY2FuIGhhdmUgY2FjaGUgYWxpYXNpbmcgZWZm ZWN0cywgc28gdGhleSBoYXZlIHRvIGJlIHRyZWF0ZWQgYXMgdmlydHVhbGx5 DQogIHRhZ2dlZC4gKHVubGVzcyB0aGF0IGNhbiBiZSBzb2x2ZWQgZWxzZXdo ZXJlLCBzaG91bGQgaW52ZXN0aWdhdGUpDQoNCiAgTm90ZSB0aGF0IG9uIHRo aXMgY2hpcCBhbGwgdGhlIF9TRCB0eXBlIGNhY2hlIG9wcyAoaWUgSGl0X1dy aXRlYmFja19JbnZfU0QpDQogIGFyZSByZWFsbHkganVzdCBfUy4gVGhpcyBp cyBpbiBsaW5lIHdpdGggd2hhdCB0aGUgTUlQUzY0IHNwZWMgcGVybWl0cy4N CiAgQWxzbywgdGhlIGxpbmUgc2l6ZSBvZiB0aGUgdGVydGlhcnkgY2FjaGUg aXMgcmVhbGx5IHRoZSBibG9jayBzaXplLiBUaGUNCiAgbGluZSBzaXplIGlz IGFsd2F5cyAzMiBieXRlcy4gVGhlIGNoaXAgY2FuIHRhZyBwYXJ0aWFsIGJs b2NrcyBhbmQgdGhlIGNhY2hlDQogIG9wIGluc3RydWN0aW9ucyB3b3JrIG9u IHRob3NlIHBhcnRpYWwgYmxvY2tzIHRvby4gDQogIA0KICBTZWUgLi9Eb2N1 bWVudGF0aW9uL2NhY2hldGxiLnR4dA0KICovDQojaW5jbHVkZSA8bGludXgv aW5pdC5oPg0KI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPg0KI2luY2x1ZGUg PGxpbnV4L3NjaGVkLmg+DQojaW5jbHVkZSA8bGludXgvbW0uaD4NCg0KI2lu Y2x1ZGUgPGFzbS9ib290aW5mby5oPg0KI2luY2x1ZGUgPGFzbS9jcHUuaD4N CiNpbmNsdWRlIDxhc20vYmNhY2hlLmg+DQojaW5jbHVkZSA8YXNtL2lvLmg+ DQojaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCiNpbmNsdWRlIDxhc20vcGd0YWJs ZS5oPg0KI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCiNpbmNsdWRlIDxhc20v bW11X2NvbnRleHQuaD4NCg0KLy8gU2hvdWxkIG1vdmUgdG8gbWlwc3JlZ3Mu aCANCiNkZWZpbmUgcmVhZF8zMmJpdF9jcDBfcmVnaXN0ZXJ4KHNvdXJjZSxz ZWwpICAgICAgICAgICAgICAgICAgICBcDQooeyBpbnQgX19yZXM7ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg XA0KICAgICAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXyggICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFwNCgkiLnNldFx0cHVzaFxuXHQiCQkJ CQlcDQoJIi5zZXRcdHJlb3JkZXJcblx0IgkJCQkJXA0KCSIuc2V0XHRtaXBz NjRcblx0IgkJCQkJXA0KICAgICAgICAibWZjMFx0JTAsIlNUUihzb3VyY2Up IiwiU1RSKHNlbCkiXG5cdCIgICAgICAgICAgICAgICAgIFwNCgkiLnNldFx0 bWlwczBcblx0IgkJCQkJXA0KCSIuc2V0XHRwb3AiCQkJCQkJXA0KICAgICAg ICA6ICI9ciIgKF9fcmVzKSk7ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFwNCiAgICAgICAgX19yZXM7fSkNCiNkZWZpbmUgd3Jp dGVfMzJiaXRfY3AwX3JlZ2lzdGVyeChyZWdpc3RlcixzZWwsdmFsdWUpICAg ICAgICAgICBcDQogICAgICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KCSIuc2V0XHRtaXBz NjRcblx0IgkJCQkJXA0KICAgICAgICAibXRjMFx0JTAsIlNUUihyZWdpc3Rl cikiLCJTVFIoc2VsKSJcblx0IgkJXA0KCSIuc2V0XHRtaXBzMFxuXHQiCQkJ CQlcDQoJIm5vcCIJCQkJCQkJXA0KICAgICAgICA6IDogInIiICh2YWx1ZSkp Ow0KDQojdW5kZWYgREVCVUdfQ0FDSEUNCg0KLyogUHJpbWFyeSBjYWNoZSBw YXJhbWV0ZXJzLiAqLw0KaW50IGljYWNoZV9zaXplLCBkY2FjaGVfc2l6ZTsg CQkJLyogU2l6ZSBpbiBieXRlcyAqLw0KaW50IGljX2xzaXplLCBkY19sc2l6 ZTsJCQkJLyogTGluZVNpemUgaW4gYnl0ZXMgKi8NCg0KLyogU2Vjb25kYXJ5 IGNhY2hlIHBhcmFtZXRlcnMuICovDQp1bnNpZ25lZCBpbnQgc2NhY2hlX3Np emUsIHNjX2xzaXplOwkJLyogQWdhaW4sIGluIGJ5dGVzICovDQoNCi8qIHRl cnRpYXJ5IGNhY2hlIChpZiBwcmVzZW50KSBwYXJhbWV0ZXJzLiAqLw0KdW5z aWduZWQgaW50IHRjYWNoZV9zaXplLCB0Y19sc2l6ZTsJCS8qIEFnYWluLCBp biBieXRlcyAqLw0KDQojaW5jbHVkZSA8YXNtL2NhY2hlb3BzLmg+DQojaW5j bHVkZSA8YXNtL21pcHMzMl9jYWNoZS5oPg0KDQovLyBVbmlxdWUgdGhlIFNS NzEwMDANCiNkZWZpbmUgSW5kZXhfSW52YWxpZGF0ZV9UIDB4Mg0KI2RlZmlu ZSBIaXRfSW52YWxpZGF0ZV9UIDB4MTYNCnN0YXRpYyBpbmxpbmUgdm9pZCBi bGFzdF90Y2FjaGUodm9pZCkNCnsNCgl1bnNpZ25lZCBsb25nIHN0YXJ0ID0g S1NFRzA7DQoJdW5zaWduZWQgbG9uZyBlbmQgPSBLU0VHMCArIHRjYWNoZV9z aXplOw0KCQ0KCS8vIENvdWxkIHVzZSBmbGFzaCBpbnZhbGlkYXRlIHBlcmhh cHMuLg0KCXdoaWxlKHN0YXJ0IDwgZW5kKQ0KCXsNCgkJY2FjaGVfdW5yb2xs KHN0YXJ0LEluZGV4X0ludmFsaWRhdGVfVCk7DQoJCXN0YXJ0ICs9IHRjX2xz aXplOw0KCX0JDQp9DQoNCnN0YXRpYyBpbmxpbmUgdm9pZCBmbHVzaF90Y2Fj aGVfbGluZSh1bnNpZ25lZCBsb25nIGFkZHIpDQp7DQoJX19hc21fXyBfX3Zv bGF0aWxlX18NCgkJKA0KCQkgIi5zZXQgbm9yZW9yZGVyXG5cdCINCgkJICIu c2V0IG1pcHMzXG5cdCINCgkJICJjYWNoZSAlMSwgKCUwKVxuXHQiDQoJCSAi LnNldCBtaXBzMFxuXHQiDQoJCSAiLnNldCByZW9yZGVyIg0KCQkgOg0KCQkg OiAiciIgKGFkZHIpLA0KCQkgImkiIChIaXRfSW52YWxpZGF0ZV9UKSk7DQp9 DQoNCi8qDQogKiBEdW1teSBjYWNoZSBoYW5kbGluZyByb3V0aW5lcyBmb3Ig bWFjaGluZXMgd2l0aG91dCBib2FyZGNhY2hlcw0KICovDQpzdGF0aWMgdm9p ZCBub19zY19ub29wKHZvaWQpIHt9DQoNCnN0YXRpYyBzdHJ1Y3QgYmNhY2hl X29wcyBub19zY19vcHMgPSB7DQoJKHZvaWQgKilub19zY19ub29wLCAodm9p ZCAqKW5vX3NjX25vb3AsDQoJKHZvaWQgKilub19zY19ub29wLCAodm9pZCAq KW5vX3NjX25vb3ANCn07DQpzdHJ1Y3QgYmNhY2hlX29wcyAqYmNvcHMgPSAm bm9fc2Nfb3BzOw0KDQovLyBDbGVhbiBhbGwgdmlydHVhbGx5IGluZGV4ZWQg Y2FjaGVzDQpzdGF0aWMgaW5saW5lIHZvaWQgc3I3MTAwMF9mbHVzaF9jYWNo ZV9hbGxfcGModm9pZCkNCnsNCgl1bnNpZ25lZCBsb25nIGZsYWdzOw0KDQoJ X19zYXZlX2FuZF9jbGkoZmxhZ3MpOw0KCWJsYXN0X2RjYWNoZSgpOyBibGFz dF9pY2FjaGUoKTsNCglfX3Jlc3RvcmVfZmxhZ3MoZmxhZ3MpOw0KfQ0KDQov LyBUaGlzIGNsZWFycyBhbGwgY2FjaGVzLiBJdCBpcyBvbmx5IHVzZWQgZnJv bSBhIHN5c2NhbGwuLg0Kc3RhdGljIGlubGluZSB2b2lkIHNyNzEwMDBfbnVr ZV9jYWNoZXModm9pZCkNCnsNCgl1bnNpZ25lZCBsb25nIGZsYWdzOw0KDQoJ X19zYXZlX2FuZF9jbGkoZmxhZ3MpOw0KCWJsYXN0X2RjYWNoZSgpOyBibGFz dF9pY2FjaGUoKTsgYmxhc3Rfc2NhY2hlKCk7DQoJaWYgKHRjYWNoZV9zaXpl ICE9IDApDQoJCWJsYXN0X3RjYWNoZSgpOw0KCV9fcmVzdG9yZV9mbGFncyhm bGFncyk7DQp9DQoNCi8qIFRoaXMgaXMgY2FsbGVkIHRvIGNsZWFuIG91dCBh IHZpcnR1YWwgbWFwcGluZy4gV2Ugb25seSBuZWVkIHRvIGZsdXNoIHRoZQ0K ICAgSSBhbmQgRCBjYWNoZXMgc2luY2UgdGhlIG90aGVyIHR3byBhcmUgcGh5 c2ljYWxseSB0YWdnZWQgKi8NCnN0YXRpYyB2b2lkIHNyNzEwMDBfZmx1c2hf Y2FjaGVfcmFuZ2VfcGMoc3RydWN0IG1tX3N0cnVjdCAqbW0sDQoJCQkJICAg ICB1bnNpZ25lZCBsb25nIHN0YXJ0LA0KCQkJCSAgICAgdW5zaWduZWQgbG9u ZyBlbmQpDQp7DQoJaWYobW0tPmNvbnRleHQgIT0gMCkgew0KCQl1bnNpZ25l ZCBsb25nIGZsYWdzOw0KDQojaWZkZWYgREVCVUdfQ0FDSEUNCgkJcHJpbnRr KCJjcmFuZ2VbJWQsJTA4bHgsJTA4bHhdIiwgKGludCltbS0+Y29udGV4dCwg c3RhcnQsIGVuZCk7DQojZW5kaWYNCgkJX19zYXZlX2FuZF9jbGkoZmxhZ3Mp Ow0KCQlibGFzdF9kY2FjaGUoKTsgYmxhc3RfaWNhY2hlKCk7DQoJCV9fcmVz dG9yZV9mbGFncyhmbGFncyk7DQoJfQ0KfQ0KDQovKg0KICogT24gYXJjaGl0 ZWN0dXJlcyBsaWtlIHRoZSBTcGFyYywgd2UgY291bGQgZ2V0IHJpZCBvZiBs aW5lcyBpbg0KICogdGhlIGNhY2hlIGNyZWF0ZWQgb25seSBieSBhIGNlcnRh aW4gY29udGV4dCwgYnV0IG9uIHRoZSBNSVBTDQogKiAoYW5kIGFjdHVhbGx5 IGNlcnRhaW4gU3BhcmMncykgd2UgY2Fubm90Lg0KICogQWdhaW4sIG9ubHkg Y2xlYW4gdGhlIHZpcnR1YWxseSB0YWdnZWQgY2FjaGUuDQogKi8NCnN0YXRp YyB2b2lkIHNyNzEwMDBfZmx1c2hfY2FjaGVfbW1fcGMoc3RydWN0IG1tX3N0 cnVjdCAqbW0pDQp7DQoJaWYobW0tPmNvbnRleHQgIT0gMCkgew0KI2lmZGVm IERFQlVHX0NBQ0hFDQoJCXByaW50aygiY21tWyVkXSIsIChpbnQpbW0tPmNv bnRleHQpOw0KI2VuZGlmDQoJCXNyNzEwMDBfZmx1c2hfY2FjaGVfYWxsX3Bj KCk7DQoJfQ0KfQ0KDQpzdGF0aWMgdm9pZCBzcjcxMDAwX2ZsdXNoX2NhY2hl X3BhZ2VfcGMoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsDQoJCQkJICAg IHVuc2lnbmVkIGxvbmcgcGFnZSkNCnsNCglzdHJ1Y3QgbW1fc3RydWN0ICpt bSA9IHZtYS0+dm1fbW07DQoJdW5zaWduZWQgbG9uZyBmbGFnczsNCglwZ2Rf dCAqcGdkcDsNCglwbWRfdCAqcG1kcDsNCglwdGVfdCAqcHRlcDsNCg0KCS8q DQoJICogSWYgb3duZXMgbm8gdmFsaWQgQVNJRCB5ZXQsIGNhbm5vdCBwb3Nz aWJseSBoYXZlIGdvdHRlbg0KCSAqIHRoaXMgcGFnZSBpbnRvIHRoZSBjYWNo ZS4NCgkgKi8NCglpZiAobW0tPmNvbnRleHQgPT0gMCkNCgkJcmV0dXJuOw0K DQojaWZkZWYgREVCVUdfQ0FDSEUNCglwcmludGsoImNwYWdlWyVkLCUwOGx4 XSIsIChpbnQpbW0tPmNvbnRleHQsIHBhZ2UpOw0KI2VuZGlmDQoJX19zYXZl X2FuZF9jbGkoZmxhZ3MpOw0KCXBhZ2UgJj0gUEFHRV9NQVNLOw0KCXBnZHAg PSBwZ2Rfb2Zmc2V0KG1tLCBwYWdlKTsNCglwbWRwID0gcG1kX29mZnNldChw Z2RwLCBwYWdlKTsNCglwdGVwID0gcHRlX29mZnNldChwbWRwLCBwYWdlKTsN Cg0KCS8qDQoJICogSWYgdGhlIHBhZ2UgaXNuJ3QgbWFya2VkIHZhbGlkLCB0 aGUgcGFnZSBjYW5ub3QgcG9zc2libHkgYmUNCgkgKiBpbiB0aGUgY2FjaGUu DQoJICovDQoJaWYgKCEocHRlX3ZhbCgqcHRlcCkgJiBfUEFHRV9WQUxJRCkp DQoJCWdvdG8gb3V0Ow0KDQoJLyoNCgkgKiBEb2luZyBmbHVzaGVzIGZvciBh bm90aGVyIEFTSUQgdGhhbiB0aGUgY3VycmVudCBvbmUgaXMNCgkgKiB0b28g ZGlmZmljdWx0IHNpbmNlIE1pcHMzMiBjYWNoZXMgZG8gYSBUTEIgdHJhbnNs YXRpb24NCgkgKiBmb3IgZXZlcnkgY2FjaGUgZmx1c2ggb3BlcmF0aW9uLiAg U28gd2UgZG8gaW5kZXhlZCBmbHVzaGVzDQoJICogaW4gdGhhdCBjYXNlLCB3 aGljaCBkb2Vzbid0IG92ZXJseSBmbHVzaCB0aGUgY2FjaGUgdG9vIG11Y2gu DQoJICovDQoJaWYgKG1tID09IGN1cnJlbnQtPmFjdGl2ZV9tbSkgew0KCQli bGFzdF9kY2FjaGVfcGFnZShwYWdlKTsNCgl9IGVsc2Ugew0KCQkvKiBEbyBp bmRleGVkIGZsdXNoLCB0b28gbXVjaCB3b3JrIHRvIGdldCB0aGUgKHBvc3Np YmxlKQ0KCQkgKiB0bGIgcmVmaWxscyB0byB3b3JrIGNvcnJlY3RseS4NCgkJ ICovDQoJCXBhZ2UgPSAoS1NFRzAgKyAocGFnZSAmIChkY2FjaGVfc2l6ZSAt IDEpKSk7DQoJCWJsYXN0X2RjYWNoZV9wYWdlX2luZGV4ZWQocGFnZSk7DQoJ fQ0Kb3V0Og0KCV9fcmVzdG9yZV9mbGFncyhmbGFncyk7DQp9DQoNCi8qIElm IHRoZSBhZGRyZXNzZXMgcGFzc2VkIHRvIHRoZXNlIHJvdXRpbmVzIGFyZSB2 YWxpZCwgdGhleSBhcmUNCiAqIGVpdGhlcjoNCiAqDQogKiAxKSBJbiBLU0VH MCwgc28gd2UgY2FuIGRvIGEgZGlyZWN0IGZsdXNoIG9mIHRoZSBwYWdlLg0K ICogMikgSW4gS1NFRzIsIGFuZCBzaW5jZSBldmVyeSBwcm9jZXNzIGNhbiB0 cmFuc2xhdGUgdGhvc2UNCiAqICAgIGFkZHJlc3NlcyBhbGwgdGhlIHRpbWUg aW4ga2VybmVsIG1vZGUgd2UgY2FuIGRvIGEgZGlyZWN0DQogKiAgICBmbHVz aC4NCiAqIDMpIEluIEtTRUcxLCBubyBmbHVzaCBuZWNlc3NhcnkuDQogKi8N CnN0YXRpYyB2b2lkIHNyNzEwMDBfZmx1c2hfcGFnZV90b19yYW1fcGMoc3Ry dWN0IHBhZ2UgKnBhZ2UpDQp7DQoJYmxhc3RfZGNhY2hlX3BhZ2UoKHVuc2ln bmVkIGxvbmcpcGFnZV9hZGRyZXNzKHBhZ2UpKTsNCn0NCg0KLyogSS1DYWNo ZSBhbmQgRC1DYWNoZSBhcmUgc2VwZXJhdGUgYW5kIHZpcnR1YWxseSB0YWdn ZWQsIHRoZXNlIG5lZWQgdG8NCiAgIGZsdXNoIHRoZW0gKi8NCnN0YXRpYyB2 b2lkIHNyNzEwMDBfZmx1c2hfaWNhY2hlX3JhbmdlKHVuc2lnbmVkIGxvbmcg c3RhcnQsIHVuc2lnbmVkIGxvbmcgZW5kKQ0Kew0KCWZsdXNoX2NhY2hlX2Fs bCgpOyAgLy8gb25seSBkb2VzIGkgYW5kIGQsIHByb2JhYmx5IGV4Y2Vzc2l2 ZQ0KfQ0KDQpzdGF0aWMgdm9pZCBzcjcxMDAwX2ZsdXNoX2ljYWNoZV9wYWdl KHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqdm1hLA0KCQkJCSAgICAgc3RydWN0 IHBhZ2UgKnBhZ2UpDQp7DQoJaW50IGFkZHJlc3M7DQoNCglpZiAoISh2bWEt PnZtX2ZsYWdzICYgVk1fRVhFQykpDQoJCXJldHVybjsNCg0KCWFkZHJlc3Mg PSBLU0VHMCArICgodW5zaWduZWQgbG9uZylwYWdlX2FkZHJlc3MocGFnZSkg JiBQQUdFX01BU0sgJiAoZGNhY2hlX3NpemUgLSAxKSk7DQoJYmxhc3RfaWNh Y2hlX3BhZ2VfaW5kZXhlZChhZGRyZXNzKTsNCn0NCg0KLyogV3JpdGViYWNr IGFuZCBpbnZhbGlkYXRlIHRoZSBwcmltYXJ5IGNhY2hlIGRjYWNoZSBiZWZv cmUgRE1BLg0KICAgU2VlIGFzbS1taXBzL2lvLmggDQogKi8NCnN0YXRpYyB2 b2lkIHNyNzEwMDBfZG1hX2NhY2hlX3diYWNrX2ludl9zYyh1bnNpZ25lZCBs b25nIGFkZHIsDQoJCQkJCSAgdW5zaWduZWQgbG9uZyBzaXplKQ0Kew0KCXVu c2lnbmVkIGxvbmcgZW5kLCBhOw0KDQoJaWYgKHNpemUgPj0gc2NhY2hlX3Np emUpIHsNCgkJc3I3MTAwMF9udWtlX2NhY2hlcygpOw0KCQlyZXR1cm47DQoJ fQ0KDQoJYSA9IGFkZHIgJiB+KHNjX2xzaXplIC0gMSk7DQoJZW5kID0gKGFk ZHIgKyBzaXplKSAmIH4oc2NfbHNpemUgLSAxKTsNCgl3aGlsZSAoMSkgew0K CQlmbHVzaF9kY2FjaGVfbGluZShhKTsNCgkJZmx1c2hfc2NhY2hlX2xpbmUo YSk7IC8vIEhpdF9Xcml0ZWJhY2tfSW52X1NEDQoJCWlmIChhID09IGVuZCkg YnJlYWs7DQoJCWEgKz0gc2NfbHNpemU7DQoJfQ0KfQ0KDQpzdGF0aWMgdm9p ZCBzcjcxMDAwX2RtYV9jYWNoZV93YmFja19pbnZfdGModW5zaWduZWQgbG9u ZyBhZGRyLA0KCQkJCQkgIHVuc2lnbmVkIGxvbmcgc2l6ZSkNCnsNCgl1bnNp Z25lZCBsb25nIGVuZCwgYTsNCg0KCWEgPSBhZGRyICYgfihzY19sc2l6ZSAt IDEpOw0KCWVuZCA9IChhZGRyICsgc2l6ZSkgJiB+KHNjX2xzaXplIC0gMSk7 DQoJd2hpbGUgKDEpIHsNCgkJZmx1c2hfZGNhY2hlX2xpbmUoYSk7DQoJCWZs dXNoX3NjYWNoZV9saW5lKGEpOyAvLyBIaXRfV3JpdGViYWNrX0ludl9TRA0K CQlmbHVzaF90Y2FjaGVfbGluZShhKTsgLy8gSGl0X0ludmFsaWRhdGVfVA0K CQlpZiAoYSA9PSBlbmQpIGJyZWFrOw0KCQlhICs9IHNjX2xzaXplOw0KCX0N Cn0NCg0KLyogSXQgaXMga2luZCBvZiBzaWxseSB0byB3cml0ZWJhY2sgZm9y IHRoZSBpbnYgY2FzZS4uIE9oIHdlbGwgKi8NCnN0YXRpYyB2b2lkIHNyNzEw MDBfZG1hX2NhY2hlX2ludl9zYyh1bnNpZ25lZCBsb25nIGFkZHIsIHVuc2ln bmVkIGxvbmcgc2l6ZSkNCnsNCgl1bnNpZ25lZCBsb25nIGVuZCwgYTsNCg0K CWlmIChzaXplID49IHNjYWNoZV9zaXplKSB7DQoJCXNyNzEwMDBfbnVrZV9j YWNoZXMoKTsNCgkJcmV0dXJuOw0KCX0NCg0KCWEgPSBhZGRyICYgfihzY19s c2l6ZSAtIDEpOw0KCWVuZCA9IChhZGRyICsgc2l6ZSkgJiB+KHNjX2xzaXpl IC0gMSk7DQoJd2hpbGUgKDEpIHsNCgkJZmx1c2hfZGNhY2hlX2xpbmUoYSk7 DQoJCWZsdXNoX3NjYWNoZV9saW5lKGEpOyAvLyBIaXRfV3JpdGViYWNrX0lu dl9TRCANCgkJaWYgKGEgPT0gZW5kKSBicmVhazsNCgkJYSArPSBzY19sc2l6 ZTsNCgl9DQp9DQoNCnN0YXRpYyB2b2lkIHNyNzEwMDBfZG1hX2NhY2hlX2lu dl90Yyh1bnNpZ25lZCBsb25nIGFkZHIsIHVuc2lnbmVkIGxvbmcgc2l6ZSkN CnsNCgl1bnNpZ25lZCBsb25nIGVuZCwgYTsNCg0KCWEgPSBhZGRyICYgfihz Y19sc2l6ZSAtIDEpOw0KCWVuZCA9IChhZGRyICsgc2l6ZSkgJiB+KHNjX2xz aXplIC0gMSk7DQoJd2hpbGUgKDEpIHsNCgkJZmx1c2hfZGNhY2hlX2xpbmUo YSk7DQoJCWZsdXNoX3NjYWNoZV9saW5lKGEpOyAvLyBIaXRfV3JpdGViYWNr X0ludl9TRA0KCQlmbHVzaF90Y2FjaGVfbGluZShhKTsgLy8gSGl0X0ludmFs aWRhdGVfVA0KCQlpZiAoYSA9PSBlbmQpIGJyZWFrOw0KCQlhICs9IHNjX2xz aXplOw0KCX0NCn0NCg0Kc3RhdGljIHZvaWQgc3I3MTAwMF9kbWFfY2FjaGVf d2JhY2sodW5zaWduZWQgbG9uZyBhZGRyLCB1bnNpZ25lZCBsb25nIHNpemUp DQp7DQoJcGFuaWMoInNyNzEwMDBfZG1hX2NhY2hlX3diYWNrIGNhbGxlZCAt IHNob3VsZCBub3QgaGFwcGVuLiIpOw0KfQ0KDQovKg0KICogV2hpbGUgd2Un cmUgcHJvdGVjdGVkIGFnYWluc3QgYmFkIHVzZXJsYW5kIGFkZHJlc3NlcyB3 ZSBkb24ndCBjYXJlDQogKiB2ZXJ5IG11Y2ggYWJvdXQgd2hhdCBoYXBwZW5z IGluIHRoYXQgY2FzZS4gIFVzdWFsbHkgYSBzZWdtZW50YXRpb24NCiAqIGZh dWx0IHdpbGwgZHVtcCB0aGUgcHJvY2VzcyBsYXRlciBvbiBhbnl3YXkgLi4u DQogKi8NCnN0YXRpYyB2b2lkIHNyNzEwMDBfZmx1c2hfY2FjaGVfc2lndHJh bXAodW5zaWduZWQgbG9uZyBhZGRyKQ0Kew0KCXByb3RlY3RlZF93cml0ZWJh Y2tfZGNhY2hlX2xpbmUoYWRkciAmIH4oZGNfbHNpemUgLSAxKSk7DQoJcHJv dGVjdGVkX2ZsdXNoX2ljYWNoZV9saW5lKGFkZHIgJiB+KGljX2xzaXplIC0g MSkpOw0KfQ0KDQovKiBEZXRlY3QgYW5kIHNpemUgdGhlIHZhcmlvdXMgY2Fj aGVzLiAqLw0Kc3RhdGljIHZvaWQgX19pbml0IHByb2JlX2ljYWNoZSh1bnNp Z25lZCBsb25nIGNvbmZpZyx1bnNpZ25lZCBsb25nIGNvbmZpZzEpDQp7DQoJ dW5zaWduZWQgaW50IGxzaXplOw0KDQoJY29uZmlnMSA9IHJlYWRfbWlwczMy X2NwMF9jb25maWcxKCk7IA0KCQ0KCWlmICgobHNpemUgPSAoKGNvbmZpZzEg Pj4gMTkpICYgNykpKQ0KCQltaXBzX2NwdS5pY2FjaGUubGluZXN6ID0gMiA8 PCBsc2l6ZTsNCgllbHNlIA0KCQltaXBzX2NwdS5pY2FjaGUubGluZXN6ID0g bHNpemU7DQoJbWlwc19jcHUuaWNhY2hlLnNldHMgPSA2NCA8PCAoKGNvbmZp ZzEgPj4gMjIpICYgNyk7DQoJbWlwc19jcHUuaWNhY2hlLndheXMgPSAxICsg KChjb25maWcxID4+IDE2KSAmIDcpOw0KCQ0KCWljX2xzaXplID0gbWlwc19j cHUuaWNhY2hlLmxpbmVzejsNCglpY2FjaGVfc2l6ZSA9IG1pcHNfY3B1Lmlj YWNoZS5zZXRzICogbWlwc19jcHUuaWNhY2hlLndheXMgKiANCgkJaWNfbHNp emU7DQoJcHJpbnRrKCJQcmltYXJ5IGluc3RydWN0aW9uIGNhY2hlICVka2Is IGxpbmVzaXplICVkIGJ5dGVzICglZCB3YXlzKVxuIiwNCgkgICAgICAgaWNh Y2hlX3NpemUgPj4gMTAsIGljX2xzaXplLCBtaXBzX2NwdS5pY2FjaGUud2F5 cyk7DQp9DQoNCnN0YXRpYyB2b2lkIF9faW5pdCBwcm9iZV9kY2FjaGUodW5z aWduZWQgbG9uZyBjb25maWcsdW5zaWduZWQgbG9uZyBjb25maWcxKQ0Kew0K CXVuc2lnbmVkIGludCBsc2l6ZTsNCg0KCWlmICgobHNpemUgPSAoKGNvbmZp ZzEgPj4gMTApICYgNykpKQ0KCQltaXBzX2NwdS5kY2FjaGUubGluZXN6ID0g MiA8PCBsc2l6ZTsNCgllbHNlIA0KCQltaXBzX2NwdS5kY2FjaGUubGluZXN6 ID0gbHNpemU7DQoJbWlwc19jcHUuZGNhY2hlLnNldHMgPSA2NCA8PCAoKGNv bmZpZzEgPj4gMTMpICYgNyk7DQoJbWlwc19jcHUuZGNhY2hlLndheXMgPSAx ICsgKChjb25maWcxID4+IDcpICYgNyk7DQoJDQoJZGNfbHNpemUgPSBtaXBz X2NwdS5kY2FjaGUubGluZXN6Ow0KCWRjYWNoZV9zaXplID0gDQoJCW1pcHNf Y3B1LmRjYWNoZS5zZXRzICogbWlwc19jcHUuZGNhY2hlLndheXMNCgkJKiBk Y19sc2l6ZTsNCglwcmludGsoIlByaW1hcnkgZGF0YSBjYWNoZSAlZGtiLCBs aW5lc2l6ZSAlZCBieXRlcyAoJWQgd2F5cylcbiIsDQoJICAgICAgIGRjYWNo ZV9zaXplID4+IDEwLCBkY19sc2l6ZSwgbWlwc19jcHUuZGNhY2hlLndheXMp Ow0KfQ0KDQpzdGF0aWMgdm9pZCBfX2luaXQgcHJvYmVfc2NhY2hlKHVuc2ln bmVkIGxvbmcgY29uZmlnLHVuc2lnbmVkIGxvbmcgY29uZmlnMikNCnsNCgl1 bnNpZ25lZCBpbnQgbHNpemU7DQoNCglpZiAoKGxzaXplID0gKChjb25maWcy ID4+IDQpICYgNykpKQ0KCQltaXBzX2NwdS5zY2FjaGUubGluZXN6ID0gMiA8 PCBsc2l6ZTsNCgllbHNlIA0KCQltaXBzX2NwdS5zY2FjaGUubGluZXN6ID0g bHNpemU7DQoJDQoJbWlwc19jcHUuc2NhY2hlLnNldHMgPSA2NCA8PCAoKGNv bmZpZzIgPj4gOCkgJiA3KTsNCgltaXBzX2NwdS5zY2FjaGUud2F5cyA9IDEg KyAoKGNvbmZpZzIgPj4gMCkgJiA3KTsNCg0KCXNjX2xzaXplID0gbWlwc19j cHUuc2NhY2hlLmxpbmVzejsNCglzY2FjaGVfc2l6ZSA9IG1pcHNfY3B1LnNj YWNoZS5zZXRzICogbWlwc19jcHUuc2NhY2hlLndheXMgKiBzY19sc2l6ZTsN CgkNCglwcmludGsoIlNlY29uZGFyeSBjYWNoZSAlZEssIGxpbmVzaXplICVk IGJ5dGVzICglZCB3YXlzKVxuIiwNCgkgICAgICAgc2NhY2hlX3NpemUgPj4g MTAsIHNjX2xzaXplLCBtaXBzX2NwdS5zY2FjaGUud2F5cyk7DQp9DQoNCnN0 YXRpYyB2b2lkIF9faW5pdCBwcm9iZV90Y2FjaGUodW5zaWduZWQgbG9uZyBj b25maWcsdW5zaWduZWQgbG9uZyBjb25maWcyKQ0Kew0KCXVuc2lnbmVkIGlu dCBsc2l6ZTsNCg0KCS8qIEZpcm13YXJlIG9yIHByb21faW5pdCBpcyByZXF1 aXJlZCB0byBjb25maWd1cmUgdGhlIHNpemUgb2YgdGhlIA0KCSAgIHRlcnRp YXJ5IGNhY2hlIGluIGNvbmZpZzIgYW5kIHNldCB0aGUgVEUgYml0IGluIGNv bmZpZzIgdG8gc2lnbmFsIA0KCSAgIHRoZSBleHRlcm5hbCBTUkFNIGNoaXBz IGFyZSBwcmVzZW50LiAqLw0KCWlmICgoY29uZmlnMiAmICgxPDwyOCkpID09 IDApDQoJCXJldHVybjsNCgkNCglpZiAoKGxzaXplID0gKChjb25maWcyID4+ IDIwKSAmIDcpKSkNCgkJbWlwc19jcHUudGNhY2hlLmxpbmVzeiA9IDIgPDwg bHNpemU7DQoJZWxzZSANCgkJbWlwc19jcHUudGNhY2hlLmxpbmVzeiA9IGxz aXplOw0KCQ0KCW1pcHNfY3B1LnRjYWNoZS5zZXRzID0gNjQgPDwgKChjb25m aWcyID4+IDI0KSAmIDcpOw0KCW1pcHNfY3B1LnRjYWNoZS53YXlzID0gMSAr ICgoY29uZmlnMiA+PiAxNikgJiA3KTsNCg0KCXRjX2xzaXplID0gbWlwc19j cHUudGNhY2hlLmxpbmVzejsNCgl0Y2FjaGVfc2l6ZSA9IG1pcHNfY3B1LnRj YWNoZS5zZXRzICogbWlwc19jcHUudGNhY2hlLndheXMgKiB0Y19sc2l6ZTsN CgkNCglwcmludGsoIlRlcnRpYXJ5IGNhY2hlICVkSywgbGluZXNpemUgJWQg Ynl0ZXMsIGJsb2Nrc2l6ZSAlZCAiDQoJICAgICAgICJieXRlcyAoJWQgd2F5 cylcbiIsDQoJICAgICAgIHRjYWNoZV9zaXplID4+IDEwLCBzY19sc2l6ZSwg dGNfbHNpemUsIG1pcHNfY3B1LnRjYWNoZS53YXlzKTsNCn0NCg0Kc3RhdGlj IHZvaWQgX19pbml0IHNldHVwX3NjYWNoZV9mdW5jcyh2b2lkKQ0Kew0KICAg ICAgICBfZmx1c2hfY2FjaGVfYWxsID0gc3I3MTAwMF9mbHVzaF9jYWNoZV9h bGxfcGM7DQogICAgICAgIF9fX2ZsdXNoX2NhY2hlX2FsbCA9IHNyNzEwMDBf bnVrZV9jYWNoZXM7DQoJX2ZsdXNoX2NhY2hlX21tID0gc3I3MTAwMF9mbHVz aF9jYWNoZV9tbV9wYzsNCglfZmx1c2hfY2FjaGVfcmFuZ2UgPSBzcjcxMDAw X2ZsdXNoX2NhY2hlX3JhbmdlX3BjOw0KCV9mbHVzaF9jYWNoZV9wYWdlID0g c3I3MTAwMF9mbHVzaF9jYWNoZV9wYWdlX3BjOw0KCV9mbHVzaF9wYWdlX3Rv X3JhbSA9IHNyNzEwMDBfZmx1c2hfcGFnZV90b19yYW1fcGM7DQoNCiAgICAg ICAgLy8gVGhlc2UgY2FuIG9ubHkgYmUgZG9uZSBvbiB0aGUgcHJpbWFyeSBj YWNoZS4NCglfY2xlYXJfcGFnZSA9ICh2b2lkICopbWlwczMyX2NsZWFyX3Bh Z2VfZGM7DQoJX2NvcHlfcGFnZSA9ICh2b2lkICopbWlwczMyX2NvcHlfcGFn ZV9kYzsNCg0KCV9mbHVzaF9pY2FjaGVfcGFnZSA9IHNyNzEwMDBfZmx1c2hf aWNhY2hlX3BhZ2U7DQoNCglpZiAodGNhY2hlX3NpemUgPT0gMCkNCgl7DQoJ CV9kbWFfY2FjaGVfd2JhY2tfaW52ID0gc3I3MTAwMF9kbWFfY2FjaGVfd2Jh Y2tfaW52X3NjOw0KCQlfZG1hX2NhY2hlX2ludiA9IHNyNzEwMDBfZG1hX2Nh Y2hlX2ludl9zYzsNCgl9DQoJZWxzZQ0KCXsNCgkJX2RtYV9jYWNoZV93YmFj a19pbnYgPSBzcjcxMDAwX2RtYV9jYWNoZV93YmFja19pbnZfdGM7DQoJCV9k bWFfY2FjaGVfaW52ID0gc3I3MTAwMF9kbWFfY2FjaGVfaW52X3RjOw0KCX0N CgkJDQoJX2RtYV9jYWNoZV93YmFjayA9IHNyNzEwMDBfZG1hX2NhY2hlX3di YWNrOw0KfQ0KDQovKiBUaGlzIGltcGxlbWVudHMgdGhlIGNhY2hlIGludGlh bGl6YXRpb24gc3R1ZmYgZnJvbSB0aGUgU1I3MTAwMCBndWlkZS4gQWZ0ZXIN CiAgIHRoaXMgYWxsIHRoZSBjYWNoZXMgd2lsbCBiZSBlbXB0eSBhbmQgcmVh ZHkgdG8gcnVuLiBJdCBtdXN0IGJlIHJ1biBmcm9tDQogICB1bmNhY2hlZCBz cGFjZS4gKi8NCnN0YXRpYyB2b2lkIF9faW5pdCBjbGVhcl9lbmFibGVfY2Fj aGVzKHVuc2lnbmVkIGxvbmcgY29uZmlnKQ0Kew0KCWNvbmZpZyA9IChjb25m aWcgJiAofkNPTkZfQ01fQ01BU0spKSB8IENPTkZfQ01fQ0FDSEFCTEVfTk9O Q09IRVJFTlQ7DQoJDQoJLyogUHJpbWFyeSBjYWNoZSBpbml0ICg3LjEuMSkN CgkgICBTUjcxMDAwIFByaW1hcnkgQ2FjaGUgaW5pdGlhbGl6YXRpb24gb2Yg NC13YXksIDMyIEtieXRlIGxpbmUgSS9EIA0KCSAgIGNhY2hlcy4gKi8NCglf X2FzbV9fIF9fdm9sYXRpbGVfXyANCgkJKA0KCQkgIi5zZXQgcHVzaFxuIg0K CQkgIi5zZXQgbm9yZW9yZGVyXG4iDQoJCSAiLnNldCBub2F0XG4iDQoJCSAi LnNldCBtaXBzNjRcbiINCgkJIA0KCQkgLy8gRW5hYmxlIEtTRUcwIGNhY2hp bmcNCgkJICIgbXRjMCAlMCwgJDE2XG4iDQoJCSANCgkJIC8qIEl0IGlzIHJl Y29tbWVuZGVkIHRoYXQgcGFyaXR5IGJlIGRpc2FibGVkIGR1cmluZyBjYWNo ZSANCgkJICAgIGluaXRpYWxpemF0aW9uLiAqLw0KCQkgIiBtZmMwICQxLCAk MTJcbiIgICAgICAvLyBSZWFkIENQMCBTdGF0dXMgUmVnaXN0ZXIuDQoJCSAi IGxpICQyLCAweDAwMDEwMDAwXG4iIC8vIERFIEJpdC4NCgkJICIgb3IgJDIs ICQxLCAkMlxuIg0KCQkgIiBtdGMwICQyLCAkMTJcbiIgICAgIC8vIERpc2Fi bGUgUGFyaXR5Lg0KCQkgDQoJCSAiIG9yaSAkMywgJTEsIDB4MUZFMFxuIiAv LyAyNTYgc2V0cy4NCgkJICIgbXRjMCAkMCwgJDI4XG4iIC8vIFNldCBDUDAg VGFnX0xvIFJlZ2lzdGVyDQoJCSAiMTpcbiINCgkJICIgY2FjaGUgOCwgMHgw MDAwKCQzKVxuIiAvLyBJbmRleF9TdG9yZV9UYWdfSQ0KCQkgIiBjYWNoZSA4 LCAweDIwMDAoJDMpXG4iIC8vIEluZGV4X1N0b3JlX1RhZ19JDQoJCSAiIGNh Y2hlIDgsIDB4NDAwMCgkMylcbiIgLy8gSW5kZXhfU3RvcmVfVGFnX0kNCgkJ ICIgY2FjaGUgOCwgMHg2MDAwKCQzKVxuIiAvLyBJbmRleF9TdG9yZV9UYWdf SQ0KCQkgIiBjYWNoZSA5LCAweDAwMDAoJDMpXG4iIC8vIEluZGV4X1N0b3Jl X1RhZ19EDQoJCSAiIGNhY2hlIDksIDB4MjAwMCgkMylcbiIgLy8gSW5kZXhf U3RvcmVfVGFnX0QNCgkJICIgY2FjaGUgOSwgMHg0MDAwKCQzKVxuIiAvLyBJ bmRleF9TdG9yZV9UYWdfRA0KCQkgIiBjYWNoZSA5LCAweDYwMDAoJDMpXG4i IC8vIEluZGV4X1N0b3JlX1RhZ19EDQoJCSAiIGJuZSAkMywgJTEsIDFiXG4i DQoJCSAiIGFkZGl1ICQzLCAkMywgLTB4MDAyMFxuIiAvLyAzMiBieXRlIGNh Y2hlIGxpbmUNCgkJICIgbXRjMCAkMSwgJDEyXG4iIC8vIFB1dCBvcmlnaW5h bCBiYWNrIGluIFN0YXR1cyBSZWdpc3Rlci4NCgkJICIuc2V0IHBvcFxuIg0K CQkgOg0KCQkgOiAiciIoY29uZmlnKSwgInIiKEtTRUcwIHwgMHg5RkQwKSAv LyBhcmJpdGFyeSBhZGRyZXNzDQoJCSA6ICIkMSIsIiQyIiwiJDMiKTsNCg0K CS8qIFNlY29uZGFyeSBhbmQgdGVydGlhcnkgZmxhc2ggaW52YWxpZGF0ZSAo Ny41LjE4KQkgICANCgkgICAgVGhpcyBjb2RlIGZyYWdtZW50LCBpbnZhbGlk YXRlcyAoYWxzbyBkaXNhYmxlcyksIGFuZA0KCSAgICByZXN0b3JlcyAocmUt ZW5hYmxlcykgdGhlIHNlY29uZGFyeSBhbmQgdGVydGlhcnkgY2FjaGVzLg0K CSAgICBFbnN1cmUgc3lzdGVtIGlzIG9wZXJhdGluZyBpbiB1bmNhY2hlZCBz cGFjZS4gKi8NCglfX2FzbV9fIF9fdm9sYXRpbGVfXyANCgkJICgNCgkJICIu c2V0IHB1c2hcbiINCgkJICIuc2V0IG5vcmVvcmRlclxuIg0KCQkgIi5zZXQg bm9hdFxuIg0KCQkgIi5zZXQgbWlwczY0XG4iDQoJCSAiICBzeW5jXG4iICAg Ly8gZmx1c2ggY29yZSBwaXBlbGluZQ0KCQkgIiAgbHcgJDIsIDAoJTApXG4i ICAgICAgICAgICAgIC8vIGZsdXNoIHBlbmRpbmcgYWNjZXNzZXMNCgkJICIg IGJuZSAkMiwgJDIsIDFmXG4iICAgICAgICAgICAvLyBwcmV2ZW50IEktZmV0 Y2hlcw0KCQkgIiAgbm9wXG4iDQoJCSAiMTogbWZjMCAkMSwgJDE2LCAyXG4i ICAgICAgICAvLyBzYXZlIGN1cnJlbnQgQ29uZmlnMg0KCQkgIiAgbGkgJDIs IDB4MjAwMDIwMDBcbiIgICAgICAgIC8vIHNldCBmbGFzaCBpbnZhbGlkYXRp b24gYml0cw0KCQkgIiAgb3IgJDIsICQxLCAkMlxuIg0KCQkgIiAgbXRjMCAk MiwgJDE2LCAyXG4iIC8vIGludmFsaWRhdGUgJiBkaXNhYmxlIGNhY2hlcw0K CQkgIiAgbXRjMCAkMSwgJDE2LCAyXG4iIC8vIHJlc3RvcmUgQ29uZmlnMg0K CQkgIi5zZXQgcG9wXG4iDQoJCSA6DQoJCSA6ICJyIihLU0VHMSkNCgkJIDog IiQxIiwiJDIiKTsJCSANCn0NCg0Kdm9pZCBfX2luaXQgbGRfbW11X3NyNzEw MDAodm9pZCkNCnsNCgl1bnNpZ25lZCBsb25nIGNvbmZpZyA9IHJlYWRfMzJi aXRfY3AwX3JlZ2lzdGVyeChDUDBfQ09ORklHLDApOw0KCXVuc2lnbmVkIGxv bmcgY29uZmlnMSA9IHJlYWRfMzJiaXRfY3AwX3JlZ2lzdGVyeChDUDBfQ09O RklHLDEpOw0KCXVuc2lnbmVkIGxvbmcgY29uZmlnMiA9IHJlYWRfMzJiaXRf Y3AwX3JlZ2lzdGVyeChDUDBfQ09ORklHLDIpOw0KCXZvaWQgKCprc2VnMV9j ZWMpKHVuc2lnbmVkIGxvbmcgY29uZmlnKSA9ICh2b2lkICopS1NFRzFBRERS KCZjbGVhcl9lbmFibGVfY2FjaGVzKTsNCg0KCS8vIFNob3VsZCBuZXZlciBo YXBwZW4NCiAgICAgICAgaWYgKCEoY29uZmlnICYgKDEgPDwgMzEpKSB8fCAh KGNvbmZpZzEgJiAoMSA8PCAzMSkpKQ0KCQlwYW5pYygic3I3MTAwMCBkb2Vz IG5vdCBoYXZlIG5lY2Vzc2FyeSBjb25maWcgcmVnaXN0ZXJzIik7DQoJDQoJ cHJvYmVfaWNhY2hlKGNvbmZpZyxjb25maWcxKTsNCglwcm9iZV9kY2FjaGUo Y29uZmlnLGNvbmZpZzEpOw0KCXByb2JlX3NjYWNoZShjb25maWcsY29uZmln Mik7DQoJcHJvYmVfdGNhY2hlKGNvbmZpZyxjb25maWcyKTsNCglzZXR1cF9z Y2FjaGVfZnVuY3MoKTsNCg0KCS8vIE1ha2Ugc3VyZSB0aGUgdGhlIHNlY29u ZGFyeSBjYWNoZSBpcyB0dXJuZWQgb24gKGFsd2F5cyBwcmVzZW50KQ0KCXdy aXRlXzMyYml0X2NwMF9yZWdpc3RlcngoQ1AwX0NPTkZJRywyLGNvbmZpZzIg fCAoMTw8MTIpKTsNCgkNCiNpZm5kZWYgQ09ORklHX01JUFNfVU5DQUNIRUQN CglpZiAoKGNvbmZpZyAmIENPTkZfQ01fQ01BU0spICE9IENPTkZfQ01fVU5D QUNIRUQpDQogICAgICAgICAgICAgICAgcHJpbnRrKCJDYWNoZXMgYWxyZWFk eSBlbmFibGVkLCBsZWF2aW5nIGFsb25lLi5cbiIpOw0KICAgICAgICBlbHNl DQogICAgICAgICAgICAgICAga3NlZzFfY2VjKGNvbmZpZyk7DQojZW5kaWYN CgkJCQkJCSAgDQoJX2ZsdXNoX2NhY2hlX3NpZ3RyYW1wID0gc3I3MTAwMF9m bHVzaF9jYWNoZV9zaWd0cmFtcDsNCglfZmx1c2hfaWNhY2hlX3JhbmdlID0g c3I3MTAwMF9mbHVzaF9pY2FjaGVfcmFuZ2U7DQp9DQo= --1444446418-1735939474-1019002712=:18447-- From owner-linux-mips@oss.sgi.com Wed Apr 17 03:02:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HA2M8d014912 for ; Wed, 17 Apr 2002 03:02:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HA2Lr8014911 for linux-mips-outgoing; Wed, 17 Apr 2002 03:02:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HA2G8d014907 for ; Wed, 17 Apr 2002 03:02:17 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id g3HA3Dc12954 for ; Wed, 17 Apr 2002 12:03:14 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JBQJ7RPG; Wed, 17 Apr 2002 12:03:13 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Wed, 17 Apr 2002 12:03:12 +0200 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 12:03:20 +0200 Message-ID: <86048F07C015D311864100902760F1DD01B5E8DD@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Wait queue problem Date: Wed, 17 Apr 2002 12:03:19 +0200 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 Hi, Does anybody else have problems using wait queues in a 2.4.5 MIPS kernel? When I try to wake up a process from an interrupt it won't start to execute. It always waits for the timeout before resuming work. In principal my code look like this: wait_queue_head_t wq; foo() { init_waitqueue_head(&wq); interruptible_sleep_on_timeout(&wq,10*HZ); } foo_int() { wake_up_interuptible(&wq); } Am I missing something? best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Wed Apr 17 03:18:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HAIL8d015798 for ; Wed, 17 Apr 2002 03:18:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HAILCw015797 for linux-mips-outgoing; Wed, 17 Apr 2002 03:18:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from jet.yi.org (mail@pD9509C36.dip.t-dialin.net [217.80.156.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HAIH8d015786 for ; Wed, 17 Apr 2002 03:18:18 -0700 Received: from al.romantica.wg ([192.168.1.11] ident=mail) by jet.yi.org with esmtp (Exim 3.34 #1 (Debian)) id 16xmWv-0007Gv-00 for ; Wed, 17 Apr 2002 12:19:13 +0200 Received: from ln by al.romantica.wg with local (Exim 3.34 #1 (Debian)) id 16xmX1-0001mj-00 for ; Wed, 17 Apr 2002 12:19:19 +0200 Date: Wed, 17 Apr 2002 12:19:18 +0200 From: Jens Taprogge To: Linux MIPS Mailing List Subject: vino v4l driver Message-ID: <20020417101917.GA6694@al.romantica.wg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to get the Indycam working on an Indy R4000SC. Is someone working on a driver or does someone have an unmaintained (half)working driver? Sorry if this is a FAQ, but I cannot access the mailing list archive. Regards Jens -- Jens Taprogge mailto:taprogge@idg.rwth-aachen.de Finger taprogge@www.idg.rwth-aachen.de for PGP key. From owner-linux-mips@oss.sgi.com Wed Apr 17 06:31:14 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HDV88d024647 for ; Wed, 17 Apr 2002 06:31:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HDV8MJ024646 for linux-mips-outgoing; Wed, 17 Apr 2002 06:31:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HDV48d024642 for ; Wed, 17 Apr 2002 06:31:05 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id B40968D35; Wed, 17 Apr 2002 15:32:01 +0200 (CEST) Date: Wed, 17 Apr 2002 15:32:01 +0200 From: Guido Guenther To: Gary.A.Grant@gsk.com Cc: linux-mips@oss.sgi.com Subject: Re: Indy --> Linux? Message-ID: <20020417153201.C31398@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Gary.A.Grant@gsk.com, linux-mips@oss.sgi.com 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 Gary.A.Grant@gsk.com on Wed, Apr 17, 2002 at 02:12:57PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Gary, On Wed, Apr 17, 2002 at 02:12:57PM +0100, Gary.A.Grant@gsk.com wrote: > OK, no problem! > > Hello Guido > Here is a hinv and gxfinfo of my Indy......can it be made to run Linux?? [..snip..] Linux should run fine on your Indy including audio and XFree86. There are several distributions available like a Red Hat miniport available at ftp://oss.sgi.com/pub/linux/mips and Debian available at: ftp.debian.org:/debian/dists/woody/main/disks-mips/current The later one might be slightly easier to set up since it comes with a netbooted installer. For more information see http://www.debian.org/ports/mips and http://www.linux-debian.de/howto/debian-mips-woody-install.html Regards, -- Guido From owner-linux-mips@oss.sgi.com Wed Apr 17 15:21:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HML48d023663 for ; Wed, 17 Apr 2002 15:21:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HML4Gs023662 for linux-mips-outgoing; Wed, 17 Apr 2002 15:21:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HML18d023657 for ; Wed, 17 Apr 2002 15:21:02 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Wed, 17 Apr 2002 15:21:54 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from nt-sjcb-0501.sv.broadcom.com ( nt-sjcb-0501.sj.broadcom.com [10.19.192.19]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA11685 for ; Wed, 17 Apr 2002 15:21:58 -0700 (PDT) Received: by mail.sv.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 17 Apr 2002 15:21:57 -0700 Message-ID: From: "Mark Huang" To: "'linux-mips@oss.sgi.com'" Subject: DBE table ordering Date: Wed, 17 Apr 2002 15:21:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10A32A08228643-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk search_one_table() in arch/mips/kernel/traps.c does a binary search for the erring instruction address in the DBE table. What guarantee is there that the table is in order by instruction address? It looks like the code hasn't changed in a long time and it has worked for me since at least 2.4.3. However, a top of tree (2.5.1) kernel crashes on me as soon as a get_dbe() fails, because the table is out of order at link time---possibly run time if there's some code that I missed that is reordering the table at __init. Any ideas? Thanks in advance, --Mark From owner-linux-mips@oss.sgi.com Wed Apr 17 17:45:23 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I0jN8d032255 for ; Wed, 17 Apr 2002 17:45:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I0jNvp032254 for linux-mips-outgoing; Wed, 17 Apr 2002 17:45:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I0j88d032242 for ; Wed, 17 Apr 2002 17:45:08 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA00127 for ; Wed, 17 Apr 2002 17:45:48 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA08255; Wed, 17 Apr 2002 17:30:09 -0700 Message-ID: <3CBE1399.9020702@mvista.com> Date: Wed, 17 Apr 2002 17:30:17 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ieee754_csr and smp (again) Content-Type: multipart/mixed; boundary="------------010108030005080606060305" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------010108030005080606060305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit OK, ieee754_csr is a global variable and it screws up fpu emulation code under smp. I have a patch that makes the problem go away. It basically transform this variable into an array of global variables. Each cpu only uses one of the elements. See the attachment. That patch works, but I think there might be a better fix. Looking through the code, I am rather confused by the usage of this variable. Hopefully someone with more better knowledge can help me out here. . should ieee754_csr be a per-thread variable? If yes, we should just use the current->thread->xxx instead of this global variable. . what is ieee754_csr for anyway? . Some of the fields in ieee754_csr (such as nod, rm, cx) gets set in fpu_emulator_cop1Handler(). But what about others? . I can't find anywhere we write iee754_csr back to the current->thread structure. Do I miss anything? Thanks. Jun --------------010108030005080606060305 Content-Type: text/plain; name="020411.math-emu-smp-safe.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="020411.math-emu-smp-safe.patch" Copy from the patch checked into our EAP. This is still a little hackish. Hopefully we can settle it better later. A per-cpu page would be nice so that we don't have declare arrays. BTW, ralf thinks ieee754_csr should belong to per thread fpu structure. I check it in now anyway so that we have some reliable for running. Jun diff -Nru smp/arch/mips/kernel/traps.c.orig smp/arch/mips/kernel/traps.c --- smp/arch/mips/kernel/traps.c.orig Wed Feb 13 16:23:12 2002 +++ smp/arch/mips/kernel/traps.c Thu Apr 11 15:46:11 2002 @@ -678,14 +678,11 @@ return; fp_emul: - if (last_task_used_math != current) { - if (!current->used_math) { - fpu_emulator_init_fpu(); - current->used_math = 1; - } + if (!current->used_math) { + fpu_emulator_init_fpu(); + current->used_math = 1; } sig = fpu_emulator_cop1Handler(regs); - last_task_used_math = current; if (sig) force_sig(sig, current); return; diff -Nru smp/arch/mips/math-emu/ieee754.h.orig smp/arch/mips/math-emu/ieee754.h --- smp/arch/mips/math-emu/ieee754.h.orig Tue Jan 22 17:11:40 2002 +++ smp/arch/mips/math-emu/ieee754.h Thu Apr 11 15:46:11 2002 @@ -323,7 +323,7 @@ /* the control status register */ -struct ieee754_csr { +struct ieee754_csr_struct { unsigned pad:13; unsigned nod:1; /* set 1 for no denormalised numbers */ unsigned cx:5; /* exceptions this operation */ @@ -331,7 +331,13 @@ unsigned sx:5; /* exceptions total */ unsigned rm:2; /* current rounding mode */ }; -extern struct ieee754_csr ieee754_csr; + +#include +#include +#include +#include +extern struct ieee754_csr_struct ieee754_csr_array[NR_CPUS]; +#define ieee754_csr ieee754_csr_array[smp_processor_id()] static __inline unsigned ieee754_getrm(void) { diff -Nru smp/arch/mips/math-emu/ieee754.c.orig smp/arch/mips/math-emu/ieee754.c --- smp/arch/mips/math-emu/ieee754.c.orig Tue Jan 15 13:25:24 2002 +++ smp/arch/mips/math-emu/ieee754.c Thu Apr 11 15:46:11 2002 @@ -52,7 +52,7 @@ /* the control status register */ -struct ieee754_csr ieee754_csr; +struct ieee754_csr_struct ieee754_csr_array[NR_CPUS]; /* special constants */ diff -Nru smp/arch/mips/math-emu/cp1emu.c.orig smp/arch/mips/math-emu/cp1emu.c --- smp/arch/mips/math-emu/cp1emu.c.orig Tue Jan 15 13:25:24 2002 +++ smp/arch/mips/math-emu/cp1emu.c Thu Apr 11 15:46:12 2002 @@ -945,7 +945,7 @@ static ieee754##p fpemu_##p##_##name (ieee754##p r, ieee754##p s, \ ieee754##p t) \ { \ - struct ieee754_csr ieee754_csr_save; \ + struct ieee754_csr_struct ieee754_csr_save; \ s = f1 (s, t); \ ieee754_csr_save = ieee754_csr; \ s = f2 (s, r); \ diff -Nru smp/arch/mips/math-emu/dp_sqrt.c.orig smp/arch/mips/math-emu/dp_sqrt.c --- smp/arch/mips/math-emu/dp_sqrt.c.orig Tue Jan 15 13:25:24 2002 +++ smp/arch/mips/math-emu/dp_sqrt.c Thu Apr 11 15:46:12 2002 @@ -37,7 +37,7 @@ ieee754dp ieee754dp_sqrt(ieee754dp x) { - struct ieee754_csr oldcsr; + struct ieee754_csr_struct oldcsr; ieee754dp y, z, t; unsigned scalx, yh; COMPXDP; --------------010108030005080606060305-- From owner-linux-mips@oss.sgi.com Wed Apr 17 18:09:43 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I19h8d001213 for ; Wed, 17 Apr 2002 18:09:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I19hAk001212 for linux-mips-outgoing; Wed, 17 Apr 2002 18:09:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I19d8d001206 for ; Wed, 17 Apr 2002 18:09:40 -0700 Received: from klystron.ieee.uow.edu.au (ieee.uow.edu.au [130.130.88.183]) 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 SAA07643 for ; Wed, 17 Apr 2002 18:10:18 -0700 (PDT) mail_from (daniel@ieee.uow.edu.au) Received: from magnetron.ieee.uow.edu.au ([192.168.84.3]) by klystron.ieee.uow.edu.au with smtp (Exim 3.34 #1 (Debian)) id 16y0Hf-0001Ag-00 for ; Thu, 18 Apr 2002 11:00:23 +1000 Received: by magnetron.ieee.uow.edu.au (sSMTP sendmail emulation); Thu, 18 Apr 2002 11:00:22 +1000 From: Daniel Robert Franklin Subject: Linux on the Origin 2000 To: linux-mips@oss.sgi.com Date: Thu, 18 Apr 2002 11:00:22 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL89 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, My research centre has been donated a beautiful SGI Origin 2000 server (512 MB RAM, 2x180 MHz R10000 CPU) machine... we got IRIX up on it, but I'm quite keen to try running Linux on it as well. I note in the linux-mips HOWTO there is a mention that as of last year the kernel boots, and code to support this machine is now in CVS, but it all sounds rather experimental. Can anyone tell me what the status of Origin 2000 support is, and is it worth trying to install? I'd be quite keen to help in testing Linux on this machine (if I can get Debian up and running on it I will be very very happy indeed :) Thanks, - Daniel -- ****************************************************************************** * Daniel Franklin - Postgraduate student in Electrical Engineering * University of Wollongong, NSW, Australia * d.franklin@ieee.org ****************************************************************************** From owner-linux-mips@oss.sgi.com Wed Apr 17 20:54:53 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I3sr8d011452 for ; Wed, 17 Apr 2002 20:54:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I3sr8q011451 for linux-mips-outgoing; Wed, 17 Apr 2002 20:54:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I3sk8d011439 for ; Wed, 17 Apr 2002 20:54:48 -0700 Received: (qmail 23279 invoked from network); 18 Apr 2002 03:55:44 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Apr 2002 03:55:44 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E2BEE3001E3; Thu, 18 Apr 2002 13:55:40 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id ACE4F94; Thu, 18 Apr 2002 13:55:40 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Mark Huang" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering In-reply-to: Your message of "Wed, 17 Apr 2002 15:21:56 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Apr 2002 13:55:35 +1000 Message-ID: <30922.1019102135@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 17 Apr 2002 15:21:56 -0700, "Mark Huang" wrote: >search_one_table() in arch/mips/kernel/traps.c does a binary search for the >erring instruction address in the DBE table. What guarantee is there that >the table is in order by instruction address? It looks like the code hasn't >changed in a long time and it has worked for me since at least 2.4.3. >However, a top of tree (2.5.1) kernel crashes on me as soon as a get_dbe() >fails, because the table is out of order at link time---possibly run time if >there's some code that I missed that is reordering the table at __init. Any >ideas? The kernel relies on several tables being correctly ordered by the linker, including the initialization vectors, so it is a fair bet that the linker is correctly appended these tables as the kernel is built. What is more likely is that one of the exception table entries was created out of order. Please send the following output to me, not the list. objdump -h vmlinux objdump -s -j __ex_table vmlinux nm -a vmlinux From owner-linux-mips@oss.sgi.com Wed Apr 17 21:07:54 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I47s8d012142 for ; Wed, 17 Apr 2002 21:07:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I47s0U012141 for linux-mips-outgoing; Wed, 17 Apr 2002 21:07:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I47m8d012133 for ; Wed, 17 Apr 2002 21:07:48 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418040844.MBDE1901.rwcrmhc52.attbi.com@ocean.lucon.org> for ; Thu, 18 Apr 2002 04:08:44 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7ACFF125C2; Wed, 17 Apr 2002 21:08:43 -0700 (PDT) Date: Wed, 17 Apr 2002 21:08:43 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Update of RedHat 7.1/mips Message-ID: <20020417210843.A10182@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 FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, glibc, binutils and gdb. H.J. --- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.[12]/x86 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. This toolchain is a combination of gcc, binutils, gdb and glibc. It is packaged for the cross compiling. It allows you to cross compile to RedHat 7.1/mips from a RedHat 7.[12]/x86 host. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Apr 17 23:38:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I6cP8d020800 for ; Wed, 17 Apr 2002 23:38:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I6cPAp020799 for linux-mips-outgoing; Wed, 17 Apr 2002 23:38:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I6cG8d020790 for ; Wed, 17 Apr 2002 23:38:16 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Wed, 17 Apr 2002 23:39:13 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from localhost.localdomain (dt-sv1-033.sj.broadcom.com [10.19.78.25]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA29024; Wed, 17 Apr 2002 23:39:16 -0700 (PDT) Subject: Re: DBE table ordering From: "Mark Huang" To: "Keith Owens" cc: "'linux-mips@oss.sgi.com'" In-Reply-To: <30922.1019102135@ocs3.intra.ocs.com.au> References: <30922.1019102135@ocs3.intra.ocs.com.au> X-Mailer: Evolution/1.0.2-5mdk Date: 17 Apr 2002 23:39:16 -0700 Message-ID: <1019111956.2095.66.camel@mathom> MIME-Version: 1.0 X-WSS-ID: 10A0B59B292501-01-01 Content-Type: multipart/mixed; boundary="=-gT+ogKjHt2stTVo7XKsc" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-gT+ogKjHt2stTVo7XKsc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >From the objdump output, it looks like the exception table is in order at link time, but the DBE table is definitely out of order. What seems to be throwing it off is the dummy call to get_dbe() in traps.c. After sprinkling a few more calls to get_dbe() around the kernel and seeing what happens during link, it looks like any call to get_dbe() inside an __init section (or probably any explicitly located section) will throw off the ordering of the table. I'd say just change the binary search to a linear one, or reorder the table at __init time if O(log n) is that important. If there were 600 entries in the table, sure, but I don't really see the benefit of the additional code to deal with only a handful, as in most cases. > The kernel relies on several tables being correctly ordered by the > linker, including the initialization vectors, so it is a fair bet that > the linker is correctly appended these tables as the kernel is built. > What is more likely is that one of the exception table entries was > created out of order. Please send the following output to me, not the > list. > > objdump -h vmlinux > objdump -s -j __ex_table vmlinux > nm -a vmlinux > --=-gT+ogKjHt2stTVo7XKsc Content-Disposition: attachment; filename=traps.c.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/x-diff; charset=iso-8859-1 Index: arch/mips/kernel/traps.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux/arch/mips/kernel/traps.c,v retrieving revision 1.107 diff -u -r1.107 traps.c --- arch/mips/kernel/traps.c 2002/02/26 23:29:05 1.107 +++ arch/mips/kernel/traps.c 2002/04/18 06:36:06 @@ -360,17 +360,12 @@ unsigned long value) { const struct exception_table_entry *mid; - long diff; =20 - while (first < last) { - mid =3D (last - first) / 2 + first; - diff =3D mid->insn - value; - if (diff < 0) - first =3D mid + 1; - else - last =3D mid; + for (mid =3D first; mid <=3D last; mid++) { + if (mid->insn =3D=3D value) + return mid->nextinsn; } - return (first =3D=3D last && first->insn =3D=3D value) ? first->nextinsn = : 0; + return 0; } =20 extern spinlock_t modlist_lock; --=-gT+ogKjHt2stTVo7XKsc-- From owner-linux-mips@oss.sgi.com Wed Apr 17 23:50:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I6ot8d021532 for ; Wed, 17 Apr 2002 23:50:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I6otog021530 for linux-mips-outgoing; Wed, 17 Apr 2002 23:50:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I6on8d021521 for ; Wed, 17 Apr 2002 23:50:50 -0700 Received: (qmail 25010 invoked from network); 18 Apr 2002 06:51:48 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Apr 2002 06:51:48 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 3E8A93001E3; Thu, 18 Apr 2002 16:51:45 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D76B394; Thu, 18 Apr 2002 16:51:45 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Mark Huang" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering In-reply-to: Your message of "17 Apr 2002 23:39:16 MST." <1019111956.2095.66.camel@mathom> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Apr 2002 16:51:40 +1000 Message-ID: <314.1019112700@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 17 Apr 2002 23:39:16 -0700, "Mark Huang" wrote: >From the objdump output, it looks like the exception table is in order >at link time, but the DBE table is definitely out of order. What seems >to be throwing it off is the dummy call to get_dbe() in traps.c. After >sprinkling a few more calls to get_dbe() around the kernel and seeing >what happens during link, it looks like any call to get_dbe() inside an >__init section (or probably any explicitly located section) will throw >off the ordering of the table. That is what I expected. Various tables are built up from special sections in each object. The linker is correctly appending those sections to the final table in vmlinux. The use of multiple text sections (init, exit, the rest) means that entries in a table for each object are not necessarily in order, breaking the assumption that the overall table is in order. This is a more general problem than mips dbe, other kernel tables and other architectures will have the same problem. I will do a general patch against 2.5.8 to sort these tables at init time, and backport the general fix to 2.4.19 later. In the meantime your patch will bypass the problem for mips dbe. From owner-linux-mips@oss.sgi.com Thu Apr 18 00:42:23 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I7gN8d024471 for ; Thu, 18 Apr 2002 00:42:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I7gNsG024470 for linux-mips-outgoing; Thu, 18 Apr 2002 00:42:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I7gH8d024460 for ; Thu, 18 Apr 2002 00:42:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA20496; Thu, 18 Apr 2002 09:43:30 +0200 (MET DST) Date: Thu, 18 Apr 2002 09:43:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: Export the DECstation's "system slot" address 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 Hello, Here is a trivial patch to export the base address of the "system slot" of TURBOchannel systems. Needed if the declance driver is to be modularized. Ralf, please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/drivers/tc/tc.c linux-mips-2.4.18-20020412/drivers/tc/tc.c --- linux-mips-2.4.18-20020412.macro/drivers/tc/tc.c 2002-04-10 02:58:49.000000000 +0000 +++ linux-mips-2.4.18-20020412/drivers/tc/tc.c 2002-04-17 00:53:43.000000000 +0000 @@ -247,4 +247,4 @@ EXPORT_SYMBOL(release_tc_card); EXPORT_SYMBOL(get_tc_base_addr); EXPORT_SYMBOL(get_tc_irq_nr); EXPORT_SYMBOL(get_tc_speed); - +EXPORT_SYMBOL(system_base); From owner-linux-mips@oss.sgi.com Thu Apr 18 01:01:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I81L8d027465 for ; Thu, 18 Apr 2002 01:01:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I81Leb027464 for linux-mips-outgoing; Thu, 18 Apr 2002 01:01:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I81G8d027456 for ; Thu, 18 Apr 2002 01:01:17 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA20923; Thu, 18 Apr 2002 10:02:35 +0200 (MET DST) Date: Thu, 18 Apr 2002 10:02:34 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Dave Airlie , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: declance: add module support, miscellanea 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 Hello, I've made several updates to the declance driver: 1. Module support. Tested for an I/O ASIC setup (/240). Changes seem to work well both as a module and when built-in. 2. Multiple interface support. While it should work in principle, its operation is impossible until PMAD-xx support is fixed. 3. Various fixes and clean-ups, including preparations to merge PMAD-xx changes by Dave. Due to a considerable size of the patch I'm not including it here. It's available at: 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020412-declance-11.gz'. For module support the "system_base" patch is required. It was sent to the list and is also available at the above address. I'd be pleased to hear from 2100/3100 users if the driver works fine for them. 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 Apr 18 02:38:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I9cj8d003062 for ; Thu, 18 Apr 2002 02:38:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I9cjrN003061 for linux-mips-outgoing; Thu, 18 Apr 2002 02:38:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from niisi.wave.ras.ru (niisi.wave.ras.ru [194.85.104.220]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I9cd8d003053 for ; Thu, 18 Apr 2002 02:38:40 -0700 Received: from t06.niisi.ras.ru (t06.systud.msk.su [193.232.173.6]) by niisi.wave.ras.ru (8.9.1/8.9.1) with ESMTP id NAA19836; Thu, 18 Apr 2002 13:39:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA06541; Thu, 18 Apr 2002 13:38:01 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA05008; Thu, 18 Apr 2002 13:34:16 +0400 (MSK) Message-ID: <3CBE93CA.EB27DB1A@niisi.msk.ru> Date: Thu, 18 Apr 2002 13:37:14 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Keith Owens CC: "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering References: <314.1019112700@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Keith, Keith Owens wrote: > > This is a more general problem than mips dbe, other kernel tables and > other architectures will have the same problem. I will do a general > patch against 2.5.8 to sort these tables at init time, and backport the > general fix to 2.4.19 later. In the meantime your patch will bypass > the problem for mips dbe. Consider it as a feature. It was known from the time Ralf designed it. If you really hate this behaviour and want to change it, I guess just linear serach is OK. Or just introduce set of get/put_dbe{b,w,l} routines instead of macros and expect just one fault address (well, 6 addresses, if you care). I think, it's better than rearranging the table on startup (your proposal) and searching in several dbe tables (was introduced last year). Another table (in fact, I know only the unaligned access table in arch/mips*/unaligned.c) is immune, because call from an __init routine from user space is somewhat tricky and, anyway, isn't allowed. If you know other tables, I think it's better to find a solution on individual basis. No needs for a common solution here. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Apr 18 02:48:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I9mj8d003721 for ; Thu, 18 Apr 2002 02:48:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I9mjog003720 for linux-mips-outgoing; Thu, 18 Apr 2002 02:48:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I9mf8d003714 for ; Thu, 18 Apr 2002 02:48:42 -0700 Received: (qmail 26043 invoked from network); 18 Apr 2002 09:49:42 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Apr 2002 09:49:42 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 43F703001E3; Thu, 18 Apr 2002 19:49:40 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2647994; Thu, 18 Apr 2002 19:49:40 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Gleb O. Raiko" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering In-reply-to: Your message of "Thu, 18 Apr 2002 13:37:14 +0400." <3CBE93CA.EB27DB1A@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Apr 2002 19:49:35 +1000 Message-ID: <1661.1019123375@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 18 Apr 2002 13:37:14 +0400, "Gleb O. Raiko" wrote: >If you really hate this behaviour and want to change it, I guess just >linear serach is OK. Performance matters for these tables. It is worth doing one sort at boot time to let the kernel run faster all the time. For some tables (ia64 unwind) the API mandates that the table be in ascending order. I just sent a general sort routine to l-k for comments before I do the rest of the work. From owner-linux-mips@oss.sgi.com Thu Apr 18 02:48:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I9mu8d003771 for ; Thu, 18 Apr 2002 02:48:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I9muMS003770 for linux-mips-outgoing; Thu, 18 Apr 2002 02:48:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I9mm8d003715 for ; Thu, 18 Apr 2002 02:48:50 -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 NAA25787; Thu, 18 Apr 2002 13:49:36 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA06619; Thu, 18 Apr 2002 13:50:26 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA05540; Thu, 18 Apr 2002 13:47:08 +0400 (MSK) Message-ID: <3CBE96CD.43620756@niisi.msk.ru> Date: Thu, 18 Apr 2002 13:50:05 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: Update of RedHat 7.1/mips References: <20020417210843.A10182@lucon.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, "H . J . Lu" wrote: > > FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, > glibc, binutils and gdb. Will your glibc work on r3k (w/o ll, sc, double word instructions)? Or you just don't care about 3rd class processors? Do you compile your distribution with -mips2 or there is a chance it will work on r3k? Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Apr 18 05:08:35 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IC8Z8d012906 for ; Thu, 18 Apr 2002 05:08:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IC8Z4Y012905 for linux-mips-outgoing; Thu, 18 Apr 2002 05:08:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IC8Q8d012895 for ; Thu, 18 Apr 2002 05:08:30 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id QAA31929; Thu, 18 Apr 2002 16:09:33 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id QAA07213; Thu, 18 Apr 2002 16:09: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 QAA12152; Thu, 18 Apr 2002 16:00:45 +0400 (MSK) Message-ID: <3CBEB61C.BC6F1746@niisi.msk.ru> Date: Thu, 18 Apr 2002 16:03:40 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Keith Owens CC: "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering References: <1661.1019123375@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 18 Apr 2002 13:37:14 +0400, > "Gleb O. Raiko" wrote: > >If you really hate this behaviour and want to change it, I guess just > >linear serach is OK. > > Performance matters for these tables. It is worth doing one sort at > boot time to let the kernel run faster all the time. For some tables > (ia64 unwind) the API mandates that the table be in ascending order. > No, performance doesn't matter here. First, we are speaking about DBE exception which slowdowns performance. Second, get/put_dbe are used for peripherial accesses which are slow anyway. Third, do you really want to speed up probe routines where those macros are used? I guess, not. Then, how many addresses you have in your dbe_table, 1000 or 6 ? I guess the latter. In the worst case, linear search requires 12 comparisons, while binary search takes 6. 6 extra comparisons is nothing in the dbe handler. If you have more than 6 addresses in the table, just replace macros by routines and get exactly 6. And 6 comparisons, btw, there is no need for loop, just 6 if-statements. I dont't know about other tables and other arches. Perhaps, they need sorting of some tables. But, definetely, sorting isn't required for mips dbe/unaligned access tables. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Apr 18 06:04:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ID4X8d020834 for ; Thu, 18 Apr 2002 06:04:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ID4XZn020833 for linux-mips-outgoing; Thu, 18 Apr 2002 06:04:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ID4P8d020821 for ; Thu, 18 Apr 2002 06:04:25 -0700 Received: from localhost ([65.96.250.215]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418130522.ZRYH1143.rwcrmhc51.attbi.com@localhost>; Thu, 18 Apr 2002 13:05:22 +0000 Date: Thu, 18 Apr 2002 09:05:39 -0400 Subject: FYI: release of snow toolchain builder 1.4 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jay Carlson To: linux-mips@oss.sgi.com Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.481) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I finally got around to writing a built-from-bare-sources toolchain for snow. snow's an alternate ABI for small MIPS systems which uses statically linked dynamically loaded shared libraries in -fno-pic -mno-abicalls mode. It has massive performance advantages on the Agenda VR3's Vr4181. New in this release is jumptable support; when used properly, it should allow careful library maintainers to provide forward binary compatibility against shared libraries. Snow could be the basis for MIPS16 work, since -fpic MIPS16 looks difficult. However, the compiler I currently use, Debian gcc 2.95.4, is completely broken for -mips16. (I'd say "can't compile dhrystone" is a good metric. :-) If anybody sends me a known-good MIPS16 platform, I'd be delighted to make snow work on it. (At this point, getting MIPS16 working under Linux is a matter of personal honor to me.) For background information on snow, see http://www.desertscenes.net/agenda/snow/ , although it's slightly out of date. The vrp stuff mentioned below is documented at http://www.desertscenes.net/index.cgi/Agenda_20Romdisk_20Building_20Instructions but is unlikely to be useful for other platforms as-is. Here's the announcement I made on the agenda-snow mailing list: snow-build-1.4 is available at http://place.org/~nop/snow- build-1.4.tar.gz . It builds a complete snow toolchain from sources, using the new jumptable snow implementation, which may allow for forwards binary compatibility of libraries. Also, it can build XFree86 4.2.0 for the Agenda from sources, including shared library-linked executables of many xc apps. Note that it is not compatible with the Agenda 1.2.0 toolchain, and it is likely that there will be a period of thrashing out library export lists that will break apps linked with it; however, this should improve future compatibility. Included in this release is an experimental interface to Brian Webb's snow distribution and build tools. It will build a working (if somewhat minimal) romdisk. Some changes to other source packages will be required; Debian gcc-2.95.4 has a different set of quirks from the gcc snapshot used previously, and ideally applications should switch from CC='mipsel-linux-gcc -B/opt/snow-gcc/lib/snow/' to CC='mipsel-linux-snow-gcc' to get rid of fixed paths in the build process. (Of course VRP sources that use ${VRP_COMPILER_CC} get this for free.) Documentation remains minimal, but hopefully not much is required to at least watch the pretty build scroll by. Necessary sources are again mirrored at http://vhl- tools.sf.net/snow-src/ . Gloating summary: after downloading the required source tarballs, you edit a config file to tell it where to build. Then, you type "make" in builder/ and "make" in vrp-build/, and around 45 minutes later out pops a romdisk! Let me know if it doesn't build on your box. The only two odd tools you'll need are for the vrp-build section. ash wants byacc. I want fakeroot, http://packages.debian.org/testing/utils/fakeroot.html , because I don't believe in building software as root. If you're daring, you can run the vrp-build section as root and nuke the calls to fakeroot. Jay From owner-linux-mips@oss.sgi.com Thu Apr 18 06:25:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IDPX8d026969 for ; Thu, 18 Apr 2002 06:25:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IDPXCc026968 for linux-mips-outgoing; Thu, 18 Apr 2002 06:25:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IDP68d026945 for ; Thu, 18 Apr 2002 06:25:06 -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 16yBvF-0006QE-00; Thu, 18 Apr 2002 08:26:01 -0500 Message-ID: <3CBEC961.2E319218@cotw.com> Date: Thu, 18 Apr 2002 08:25:53 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, uclibc@uclibc.org Subject: MIPS uClibc dynamic linker/loader progress and help?! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Greetings. I'm still "really close" to getting the MIPS uClibc dynamic linker working. I finally took some time to collect register dumps and values to see if someone can see something that I'm not. I took the resolver assembly code for MIPS verbatim from GLIBC and massaged it a bit for the uClibc framework. The file looks like this: ---------------------------------------------------------------------------- .text .align 2 .globl _dl_linux_resolve .type _dl_linux_resolve,@function .ent _dl_linux_resolve _dl_linux_resolve: .frame $29, 40, $31 .set noreorder move $3, $28 # Save GP addu $25, 8 # t9 ($25) now points at .cpload instruction .cpload $25 # Compute GP .set reorder move $2, $31 # Save slot call pc subu $29, 40 # Save arguments and sp value in stack .cprestore 32 sw $15, 36($29) sw $4, 16($29) sw $5, 20($29) sw $6, 24($29) sw $7, 28($29) move $4, $24 move $5, $15 move $6, $3 move $7, $2 jal _dl_linux_resolver lw $31, 36($29) lw $4, 16($29) lw $5, 20($29) lw $6, 24($29) lw $7, 28($29) addu $29, 40 move $25, $2 jr $25 .size _dl_linux_resolve,.-_dl_linux_resolve .end _dl_linux_resolve ---------------------------------------------------------------------------- The function, _dl_linux_resolver, looks like this: ---------------------------------------------------------------------------- void _dl_linux_resolver(void) { unsigned long foo; __asm__("\tmove %0, $7\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $15\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $24\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $25\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $28\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $29\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tmove %0, $31\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tlw %0, 0($25)\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); __asm__("\tlw %0, 0($29)\t\n":"=r"(foo)); SEND_ADDRESS_STDERR(foo,1); while(1); } ---------------------------------------------------------------------------- The output looks like this: ELF header=0x2aaa8000 First Dynamic section entry=0x2aaa80cc About to do library loader relocations. Done relocating library loader, so we can now use globals and make function calls! GOT found at 0x2aaaf000 Lib Loader: (0x2aaa8000) /usr/mipsel-linux-uclibc/lib/ld-uClibc.so.0 searching for library: 'libc.so.0' searching in ldso dir: /usr/mipsel-linux-uclibc/lib Loading: (0x2aaef000) /usr/mipsel-linux-uclibc/lib/libc.so.0 Beginning relocation fixups Beginning copy fixups Calling init/fini for shared libraries Calling application main() 0x0 <-- $7 0x7 <-- $15 0x0 <-- $24 0x7fff7a30 <-- $25 0x4d954 <-- $28 0x7fff7a28 <-- $29 0x2aaa8a6c <-- $31 0xa <-- 0($25) 0x4d954 <-- 0($29) According to 'readelf' and a 'objdump -d': GOT = 0x000463d0 _dl_linux_resolve = 0x00000990 _dl_linux_resolver = 0x00000a6c Ignore for the minute that we are passing four arguments when in fact we won't even use them. Now let us look at the values in the different registers: $7 - according the assembly code above, it should contain the old value of $31, but instead it's zero...that doesn't seem right -- $15 - according to the comments in the 'dl-machine.h' file from GLIBC, this value should be the return address to the caller of the function, but it's value is 7, that doesn't seem right either $24 - accrding to the comments in the 'dl-machine.h' file from GLIBC, this value should be the index for this function symbol in .dynsym, which probably isn't right $25 - this should be the address of the function called, but the value gets overwritten right after the function prologue as you can see, and it's value is 0xa for whatever reason 00000a6c <_dl_linux_resolver>: a6c: 3c1c0005 lui gp,0x5 a70: 279cd954 addiu gp,gp,-9900 a74: 0399e021 addu gp,gp,t9 a78: 27bdff18 addiu sp,sp,-232 a7c: afbc0000 sw gp,0(sp) a80: 27b90008 addiu t9,sp,8 a84: afbc00e0 sw gp,224(sp) $28 - this should be pointing to the GOT, let's see if that's right. Using the disassembly above the first two instructions give us gp = 0x0005000 - 0x000026ac which is 0x0004d954 and that matches the value printed above. I'm going to ignore the third assembly instruction, so: 0x00007ff0 - (0x0004d954 - 0x000463d0) = 0x00000a6c which is indeed the address of '_dl_linux_resolver', but that means that t9/$25 was zero when we entered the function which should not be $29 - this is the stack pointer and if we dereference that we get the value of the $28 register, is that correct? $31 - this is the return address and that return address turns out to be '_dl_linux_resolver' which should be '_dl_linux_resolve' I thought even though after we fix up the GOT entry, we will jump to that location So, what is the problem you say? If I attempt to make a function call or access a global variable outside of the '_dl_linux_resolver' like calling 'dl_dprintf' or attempt an instruction like: __asm__("\tla %0, _dl_linux_resolve\t\n":"r="(foo)); the linker SEFAULTs which means that the GP value is incorrect, even though it appears to be correct from the above? Any insight on what is going on? Or perhaps I don't have a complete understanding of PIC code yet. Clearly, the resolver stub is being called and the resolver function is being entered. I am unable to see how the stack and registers could be getting trashed. I have also placed the dynamic linker ELF binary on my FTP site along with this post at (ftp://ftp.cotw.com/MIPS/uclibc). Insight appreciated. Thanks. -Steve Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Apr 18 09:31:14 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGVD8d031500 for ; Thu, 18 Apr 2002 09:31:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGVDSm031499 for linux-mips-outgoing; Thu, 18 Apr 2002 09:31:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGVB8d031495 for ; Thu, 18 Apr 2002 09:31:11 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418163209.SIWC12144.rwcrmhc53.attbi.com@ocean.lucon.org>; Thu, 18 Apr 2002 16:32:09 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9B007125C2; Thu, 18 Apr 2002 09:32:08 -0700 (PDT) Date: Thu, 18 Apr 2002 09:32:08 -0700 From: "H . J . Lu" To: "Gleb O. Raiko" Cc: linux-mips@oss.sgi.com Subject: Re: Update of RedHat 7.1/mips Message-ID: <20020418093208.B20868@lucon.org> References: <20020417210843.A10182@lucon.org> <3CBE96CD.43620756@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CBE96CD.43620756@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Apr 18, 2002 at 01:50:05PM +0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Apr 18, 2002 at 01:50:05PM +0400, Gleb O. Raiko wrote: > Hi, > > "H . J . Lu" wrote: > > > > FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, > > glibc, binutils and gdb. > > Will your glibc work on r3k (w/o ll, sc, double word instructions)? Or > you just don't care about 3rd class processors? > I didn't compile anything with -mipsN. But I don't have a r3k to test. H.J. From owner-linux-mips@oss.sgi.com Thu Apr 18 09:48:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGmQ8d032702 for ; Thu, 18 Apr 2002 09:48:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGmQfT032701 for linux-mips-outgoing; Thu, 18 Apr 2002 09:48:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGmK8d032692 for ; Thu, 18 Apr 2002 09:48:22 -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 UAA03333; Thu, 18 Apr 2002 20:49:28 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id UAA08492; Thu, 18 Apr 2002 20:50:09 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id UAA22066; Thu, 18 Apr 2002 20:47:21 +0400 (MSK) Message-ID: <3CBEF932.5F189B55@niisi.msk.ru> Date: Thu, 18 Apr 2002 20:49:54 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: Update of RedHat 7.1/mips References: <20020417210843.A10182@lucon.org> <3CBE96CD.43620756@niisi.msk.ru> <20020418093208.B20868@lucon.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" wrote: > > On Thu, Apr 18, 2002 at 01:50:05PM +0400, Gleb O. Raiko wrote: > > Hi, > > > > "H . J . Lu" wrote: > > > > > > FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, > > > glibc, binutils and gdb. > > > > Will your glibc work on r3k (w/o ll, sc, double word instructions)? Or > > you just don't care about 3rd class processors? > > > > I didn't compile anything with -mipsN. But I don't have a r3k to test. OK. I will test myself. Regards, Gleb. From owner-linux-mips@oss.sgi.com Thu Apr 18 10:08:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IH8m8d001003 for ; Thu, 18 Apr 2002 10:08:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IH8mO8001002 for linux-mips-outgoing; Thu, 18 Apr 2002 10:08:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from zachs.place.org (postfix@place.org [192.207.126.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IH8k8d000997 for ; Thu, 18 Apr 2002 10:08:46 -0700 Received: from imipolex (place.org [127.0.0.1]) by zachs.place.org (Postfix) with SMTP id 258386B2CA; Thu, 18 Apr 2002 12:09:49 -0500 (CDT) Message-ID: <001501c1e6fc$34acc710$41745381@mitre.org> From: "Jay Carlson" To: "H . J . Lu" , References: <20020417210843.A10182@lucon.org> Subject: Re: Update of RedHat 7.1/mips Date: Thu, 18 Apr 2002 13:12:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" writes: > FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, > glibc, binutils and gdb. Is there a quick summary of those changes? Aside from binutils, which you already describe, of course---and thank you for that. Jay From owner-linux-mips@oss.sgi.com Thu Apr 18 10:59:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IHxM8d005471 for ; Thu, 18 Apr 2002 10:59:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IHxMXk005470 for linux-mips-outgoing; Thu, 18 Apr 2002 10:59:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IHxG8d005460 for ; Thu, 18 Apr 2002 10:59:17 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA05899; Thu, 18 Apr 2002 19:59:49 +0200 (MET DST) Date: Thu, 18 Apr 2002 19:59:47 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Keith Owens , "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering In-Reply-To: <3CBEB61C.BC6F1746@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 18 Apr 2002, Gleb O. Raiko wrote: > I dont't know about other tables and other arches. Perhaps, they need > sorting of some tables. But, definetely, sorting isn't required for mips > dbe/unaligned access tables. Still it can be done for consistency. It won't hurt, will it? -- + 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 Apr 18 16:27:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3INRX8d014592 for ; Thu, 18 Apr 2002 16:27:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3INRXSv014591 for linux-mips-outgoing; Thu, 18 Apr 2002 16:27:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3INRQ8d014585 for ; Thu, 18 Apr 2002 16:27:26 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020418171600.SOHB15826.rwcrmhc54.attbi.com@ocean.lucon.org>; Thu, 18 Apr 2002 17:16:00 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 3E5A7125C2; Thu, 18 Apr 2002 10:16:00 -0700 (PDT) Date: Thu, 18 Apr 2002 10:16:00 -0700 From: "H . J . Lu" To: Jay Carlson Cc: linux-mips@oss.sgi.com Subject: Re: Update of RedHat 7.1/mips Message-ID: <20020418101600.C21240@lucon.org> References: <20020417210843.A10182@lucon.org> <001501c1e6fc$34acc710$41745381@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001501c1e6fc$34acc710$41745381@mitre.org>; from nop@nop.com on Thu, Apr 18, 2002 at 01:12:22PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Apr 18, 2002 at 01:12:22PM -0400, Jay Carlson wrote: > "H . J . Lu" writes: > > > FYI, I updated a few packages in RedHat 7.1/mips. It has new gcc, > > glibc, binutils and gdb. > > Is there a quick summary of those changes? Aside from binutils, which you > already describe, of course---and thank you for that. > I merged all the recent RedHat 7.1 updates. I also took sh-utils from RedHat 7.2 to fix the date bug. Here is the list. H.J. ---- -rw-r--r-- 1 hjl hjl 175660 Apr 8 19:14 zlib-1.1.3-25.7.1.src.rpm -rw-r--r-- 1 hjl hjl 953640 Apr 8 19:17 pam-0.75-18.7.1.src.rpm -rw-r--r-- 1 hjl hjl 1454824 Apr 8 19:22 ncurses-5.2-8.2.src.rpm -rw-r--r-- 1 hjl hjl 6851075 Apr 8 19:27 tcltk-8.3.1-53.7.src.rpm -rw-r--r-- 1 hjl hjl 5865232 Apr 8 19:47 rpm-4.0.4-7x.1.src.rpm -rw-r--r-- 1 hjl hjl 1503718 Apr 8 19:56 freetype-2.0.5-3.1.src.rpm -rw-r--r-- 1 hjl hjl 264946 Apr 8 19:56 gd-1.8.4-4.1.src.rpm -rw-r--r-- 1 hjl hjl 10724600 Apr 8 20:07 binutils-2.12.90.0.4-1.src.rpm -rw-r--r-- 1 hjl hjl 4369377 Apr 8 20:14 mpatrol-1.4.7-1.src.rpm -rw-r--r-- 1 hjl hjl 36351 Apr 8 20:16 lockdev-1.0.0-5.1.src.rpm -rw-r--r-- 1 hjl hjl 146033 Apr 8 20:18 at-3.1.8-23.1.src.rpm -rw-r--r-- 1 hjl hjl 68948 Apr 8 20:18 authconfig-4.1.6-1.2.src.rpm -rw-r--r-- 1 hjl hjl 370575 Apr 8 20:19 automake-1.4-8.3.src.rpm -rw-r--r-- 1 hjl hjl 43152 Apr 8 20:21 devfsd-1.3.18-1.1.src.rpm -rw-r--r-- 1 hjl hjl 1367227 Apr 8 20:23 e2fsprogs-1.26-1.71.1.src.rpm -rw-r--r-- 1 hjl hjl 13356931 Apr 8 20:41 gcc-2.96-109.1.src.rpm -rw-r--r-- 1 hjl hjl 11701958 Apr 8 20:49 gdb-5.2-0.2.src.rpm -rw-r--r-- 1 hjl hjl 1283837 Apr 8 20:50 gettext-0.10.38-7.1.src.rpm -rw-r--r-- 1 hjl hjl 1774533 Apr 8 20:53 groff-1.17.2-7.0.2.1.src.rpm -rw-r--r-- 1 hjl hjl 29215 Apr 8 20:53 hdparm-4.1-3.1.src.rpm -rw-r--r-- 1 hjl hjl 234396 Apr 8 20:54 iptables-1.2.4-0.71.2.1.src.rpm -rw-r--r-- 1 hjl hjl 54885 Apr 8 20:55 ksymoops-2.4.0-3.2.src.rpm -rw-r--r-- 1 hjl hjl 22341 Apr 8 20:57 mingetty-0.9.4-16.2.src.rpm -rw-r--r-- 1 hjl hjl 966053 Apr 8 20:58 mount-2.11g-5.2.src.rpm -rw-r--r-- 1 hjl hjl 237448 Apr 8 20:58 modutils-2.4.13-0.7.1.1.src.rpm -rw-r--r-- 1 hjl hjl 2039668 Apr 8 21:00 mutt-1.2.5.1-0.7.1.src.rpm -rw-r--r-- 1 hjl hjl 395818 Apr 8 21:01 ncftp-3.0.2-1.1.src.rpm -rw-r--r-- 1 hjl hjl 247576 Apr 8 21:02 nfs-utils-1.0.1-1.src.rpm -rw-r--r-- 1 hjl hjl 911685 Apr 8 21:05 openssh-3.1p1-1.1.src.rpm -rw-r--r-- 1 hjl hjl 14645 Apr 8 21:09 rdate-1.0-7.1.src.rpm -rw-r--r-- 1 hjl hjl 130453 Apr 8 21:14 SysVinit-2.78-17.2.src.rpm -rw-r--r-- 1 hjl hjl 267754 Apr 8 21:15 telnet-0.17-18.1.1.src.rpm -rw-r--r-- 1 hjl hjl 995402 Apr 8 21:19 util-linux-2.11f-17.1.src.rpm -rw-r--r-- 1 hjl hjl 60015 Apr 8 21:21 wireless-tools-21-1.1.src.rpm -rw-r--r-- 1 hjl hjl 114943 Apr 8 21:21 wvdial-1.41-12.1.src.rpm -rw-r--r-- 1 hjl hjl 11921088 Apr 10 14:13 glibc-2.2.5-30.2.src.rpm -rw-r--r-- 1 hjl hjl 36746146 Apr 10 15:26 toolchain-20020408-1.src.rpm -rw-r--r-- 1 hjl hjl 50844326 Apr 11 11:43 XFree86-4.1.0-15.1.src.rpm -rw-r--r-- 1 hjl hjl 1159621 Apr 17 19:51 sh-utils-2.0.11-5.1.src.rpm From owner-linux-mips@oss.sgi.com Thu Apr 18 18:15:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J1Fp8d016895 for ; Thu, 18 Apr 2002 18:15:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J1Fpgg016894 for linux-mips-outgoing; Thu, 18 Apr 2002 18:15:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J1Fm8d016891 for ; Thu, 18 Apr 2002 18:15:48 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3J1Grt05965; Thu, 18 Apr 2002 18:16:53 -0700 Date: Thu, 18 Apr 2002 18:16:53 -0700 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Wait queue problem Message-ID: <20020418181652.A25562@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E8DD@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E8DD@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Wed, Apr 17, 2002 at 12:03:19PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 17, 2002 at 12:03:19PM +0200, Andre.Messerschmidt@infineon.com wrote: > Does anybody else have problems using wait queues in a 2.4.5 MIPS kernel? > When I try to wake up a process from an interrupt it won't start to execute. > It always waits for the timeout before resuming work. > In principal my code look like this: > > wait_queue_head_t wq; > > foo() { > init_waitqueue_head(&wq); > interruptible_sleep_on_timeout(&wq,10*HZ); > } > > foo_int() { > wake_up_interuptible(&wq); > } > > Am I missing something? A bad race condition in that code. If foo_int is called before your process had a chance to get to sleep it'll never be woken before the timeout. Ralf From owner-linux-mips@oss.sgi.com Thu Apr 18 18:17:47 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J1Hl8d017060 for ; Thu, 18 Apr 2002 18:17:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J1HlPL017059 for linux-mips-outgoing; Thu, 18 Apr 2002 18:17:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J1Hi8d017056 for ; Thu, 18 Apr 2002 18:17:44 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3J1Inu05981; Thu, 18 Apr 2002 18:18:49 -0700 Date: Thu, 18 Apr 2002 18:18:48 -0700 From: Ralf Baechle To: Daniel Robert Franklin Cc: linux-mips@oss.sgi.com Subject: Re: Linux on the Origin 2000 Message-ID: <20020418181848.B25562@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from daniel@ieee.uow.edu.au on Thu, Apr 18, 2002 at 11:00:22AM +1000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Apr 18, 2002 at 11:00:22AM +1000, Daniel Robert Franklin wrote: > My research centre has been donated a beautiful SGI Origin 2000 server (512 > MB RAM, 2x180 MHz R10000 CPU) machine... we got IRIX up on it, but I'm quite > keen to try running Linux on it as well. I note in the linux-mips HOWTO > there is a mention that as of last year the kernel boots, and code to > support this machine is now in CVS, but it all sounds rather experimental. > > Can anyone tell me what the status of Origin 2000 support is, and is it > worth trying to install? I'd be quite keen to help in testing Linux on this > machine (if I can get Debian up and running on it I will be very very happy > indeed :) Lacking access to a machine the code may have suffered some bitrot but basically it's supposed to work though not as fullfeatured as the 32-bit kernel. We had it running on MP systems of 2-128 processors. Ralf From owner-linux-mips@oss.sgi.com Thu Apr 18 19:00:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J20d8d017568 for ; Thu, 18 Apr 2002 19:00:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J20d4B017567 for linux-mips-outgoing; Thu, 18 Apr 2002 19:00:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J20S8d017564; Thu, 18 Apr 2002 19:00:29 -0700 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id TAA41383; Thu, 18 Apr 2002 19:01:33 -0700 (PDT) (envelope-from rh@matriplex.com) Date: Thu, 18 Apr 2002 19:01:33 -0700 (PDT) From: Richard Hodges To: Ralf Baechle cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: Wait queue problem In-Reply-To: <20020418181652.A25562@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Wed, Apr 17, 2002 at 12:03:19PM +0200, Andre.Messerschmidt@infineon.com wrote: > > > Does anybody else have problems using wait queues in a 2.4.5 MIPS kernel? > > When I try to wake up a process from an interrupt it won't start to execute. > > It always waits for the timeout before resuming work. > > In principal my code look like this: > > > > wait_queue_head_t wq; > > > > foo() { > > init_waitqueue_head(&wq); > > interruptible_sleep_on_timeout(&wq,10*HZ); > > } > > > > foo_int() { > > wake_up_interuptible(&wq); > > } > > > > Am I missing something? On Thu, 18 Apr 2002, Ralf Baechle wrote: > A bad race condition in that code. If foo_int is called before your process > had a chance to get to sleep it'll never be woken before the timeout. That reminds me :-) I have looked around for a version of wait_event_interruptible() that has a timeout (starting my search in sched.h of course). Before I get around to writing my own, does anyone have one already? Thanks, -Richard From owner-linux-mips@oss.sgi.com Fri Apr 19 01:28:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J8Sg8d028607 for ; Fri, 19 Apr 2002 01:28:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J8SgaK028606 for linux-mips-outgoing; Fri, 19 Apr 2002 01:28:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J8SM8d028581 for ; Fri, 19 Apr 2002 01:28:33 -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 MAA17224; Fri, 19 Apr 2002 12:29:16 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA12166; Fri, 19 Apr 2002 12:30:36 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA14299; Fri, 19 Apr 2002 12:24:36 +0400 (MSK) Message-ID: <3CBFD518.C413C72A@niisi.msk.ru> Date: Fri, 19 Apr 2002 12:28:08 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Keith Owens , "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Maciej, "Maciej W. Rozycki" wrote: > > On Thu, 18 Apr 2002, Gleb O. Raiko wrote: > > > I dont't know about other tables and other arches. Perhaps, they need > > sorting of some tables. But, definetely, sorting isn't required for mips > > dbe/unaligned access tables. > > Still it can be done for consistency. It won't hurt, will it? > Sure, it won't hurt performance. Just looks stupid in this place. Even if we'll add something like dbe_memcpy, which will require a lot of addresses in the table in order ot get adequate performance, it'll be still stupid. And answer your next question, dbe_memcpy is needed for accesses to busses like VME where Bus{Abort,Error,Fail} are quite legal and traditionally all of them are traslated to DBE. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Apr 19 05:18:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JCIV8d001804 for ; Fri, 19 Apr 2002 05:18:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JCIV8D001803 for linux-mips-outgoing; Fri, 19 Apr 2002 05:18:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JCIR8d001800 for ; Fri, 19 Apr 2002 05:18:28 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA00353; Fri, 19 Apr 2002 14:19:28 +0200 (MET DST) Date: Fri, 19 Apr 2002 14:19:25 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Keith Owens , "'linux-mips@oss.sgi.com'" Subject: Re: DBE table ordering In-Reply-To: <3CBFD518.C413C72A@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 19 Apr 2002, Gleb O. Raiko wrote: > Sure, it won't hurt performance. Just looks stupid in this place. If it's done uniformly across all such tables it isn't stupid any longer. The reason is some independent code may depend on the consistency now or in the future and creating unnecessary exceptions to rules makes maintenance complicated and prone to hard to detect errors. -- + 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 Apr 19 08:06:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JF6V8d005530 for ; Fri, 19 Apr 2002 08:06:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JF6VVI005529 for linux-mips-outgoing; Fri, 19 Apr 2002 08:06:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JF6R8d005523 for ; Fri, 19 Apr 2002 08:06:28 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 16yZym-0001ka-00; Fri, 19 Apr 2002 17:07:16 +0200 Date: Fri, 19 Apr 2002 17:07:16 +0200 From: Johannes Stezenbach To: Jay Carlson Cc: linux-mips@oss.sgi.com Subject: Re: FYI: release of snow toolchain builder 1.4 Message-ID: <20020419150716.GA6686@convergence.de> Mail-Followup-To: Johannes Stezenbach , Jay Carlson , linux-mips@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Apr 18, 2002 at 09:05:39AM -0400, Jay Carlson wrote: > Snow could be the basis for MIPS16 work, since -fpic MIPS16 looks > difficult. However, the compiler I currently use, Debian gcc 2.95.4, is > completely broken for -mips16. (I'd say "can't compile dhrystone" is a > good metric. :-) If anybody sends me a known-good MIPS16 platform, I'd > be delighted to make snow work on it. (At this point, getting MIPS16 > working under Linux is a matter of personal honor to me.) I've just asked on the gcc mailing list, and someone at Redhat is currently working on mips16 support on the CVS trunk, i.e. it won't be in gcc-3.1. If it receives sufficient testing, gcc-3.2 might work for mips16 stuff. GNU-Pro from Redhat and the Algorithmics toolchain should work, too. Regards, Johannes From owner-linux-mips@oss.sgi.com Fri Apr 19 09:14:20 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JGEK8d006800 for ; Fri, 19 Apr 2002 09:14:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JGEK17006799 for linux-mips-outgoing; Fri, 19 Apr 2002 09:14:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JGEF8d006795 for ; Fri, 19 Apr 2002 09:14:15 -0700 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g3JGDpG02449; Fri, 19 Apr 2002 18:13:51 +0200 From: Hartvig Ekner Message-Id: <200204191613.g3JGDpG02449@coplin09.mips.com> Subject: Re: FYI: release of snow toolchain builder 1.4 To: js@convergence.de (Johannes Stezenbach) Date: Fri, 19 Apr 2002 18:13:51 +0200 (CEST) Cc: nop@nop.com (Jay Carlson), linux-mips@oss.sgi.com In-Reply-To: <20020419150716.GA6686@convergence.de> from "Johannes Stezenbach" at Apr 19, 2002 05:07:16 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk We're doing a test-project with Algorithmics, implementing MIPS16 and MIPS16e PIC support in SDE. I'll post results on the list when we have some. /Hartvig Johannes Stezenbach writes: > > On Thu, Apr 18, 2002 at 09:05:39AM -0400, Jay Carlson wrote: > > Snow could be the basis for MIPS16 work, since -fpic MIPS16 looks > > difficult. However, the compiler I currently use, Debian gcc 2.95.4, is > > completely broken for -mips16. (I'd say "can't compile dhrystone" is a > > good metric. :-) If anybody sends me a known-good MIPS16 platform, I'd > > be delighted to make snow work on it. (At this point, getting MIPS16 > > working under Linux is a matter of personal honor to me.) > > I've just asked on the gcc mailing list, and someone at > Redhat is currently working on mips16 support on the > CVS trunk, i.e. it won't be in gcc-3.1. If it receives > sufficient testing, gcc-3.2 might work for mips16 stuff. > GNU-Pro from Redhat and the Algorithmics toolchain should > work, too. > > > Regards, > Johannes -- _ _ _____ ____ 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 Apr 19 10:05:00 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JH508d007604 for ; Fri, 19 Apr 2002 10:05:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JH507L007603 for linux-mips-outgoing; Fri, 19 Apr 2002 10:05:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from web11906.mail.yahoo.com (web11906.mail.yahoo.com [216.136.172.190]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JH4w8d007589 for ; Fri, 19 Apr 2002 10:04:58 -0700 Message-ID: <20020419170605.41020.qmail@web11906.mail.yahoo.com> Received: from [209.243.184.133] by web11906.mail.yahoo.com via HTTP; Fri, 19 Apr 2002 10:06:05 PDT Date: Fri, 19 Apr 2002 10:06:05 -0700 (PDT) From: Wayne Gowcher Subject: Equivalent of ioperm / iopl in linux mips ? To: Linux-MIPS In-Reply-To: <20020221095505.A28496@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I would like to access Io ports from a user land application. I found a MINI HOWTO giving an exmaple using ioperm / iopl and then outb, inb. Searching the mips source code I see that sys_ioperm returns "ENOSYS" function not implemented. Does anyone know how to implement ioperm / iopl type functionality on a mips system. Any example code would be appreciated. Wayne. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-linux-mips@oss.sgi.com Sat Apr 20 02:03:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3K93Jqf008144 for ; Sat, 20 Apr 2002 02:03:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3K93Ihg008143 for linux-mips-outgoing; Sat, 20 Apr 2002 02:03:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3K93Dqf008140 for ; Sat, 20 Apr 2002 02:03:14 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA25676; Sat, 20 Apr 2002 11:03:27 +0200 (MET DST) Date: Sat, 20 Apr 2002 11:03:26 +0200 (MEST) From: Geert Uytterhoeven To: Wayne Gowcher cc: Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? In-Reply-To: <20020419170605.41020.qmail@web11906.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 19 Apr 2002, Wayne Gowcher wrote: > I would like to access Io ports from a user land > application. I found a MINI HOWTO giving an exmaple > using ioperm / iopl and then outb, inb. Searching the > mips source code I see that sys_ioperm returns > "ENOSYS" function not implemented. > > Does anyone know how to implement ioperm / iopl type > functionality on a mips system. Any example code would > be appreciated. Like on most architectures that use memory mapped I/O: mmap() the relevant portion of /dev/mem and read/write to/from the mapped area. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Sun Apr 21 02:45:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3L9jRqf001041 for ; Sun, 21 Apr 2002 02:45:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3L9jRKK001040 for linux-mips-outgoing; Sun, 21 Apr 2002 02:45:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3L9jQqf001035 for ; Sun, 21 Apr 2002 02:45:26 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3L9jpx07486 for linux-mips@oss.sgi.com; Sun, 21 Apr 2002 02:45:51 -0700 Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JHvj8d008234 for ; Fri, 19 Apr 2002 10:57:46 -0700 Received: from smtp.swissonline.ch (mail-4.swissonline.ch [62.2.32.85]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id g3JHwJ279812 for ; Fri, 19 Apr 2002 19:58:19 +0200 (CEST) Received: from frodo2000 (dclient217-162-128-26.hispeed.ch [217.162.128.26]) by smtp.swissonline.ch (8.11.6/8.11.6/SMTPSOL/AWF/2002040101) with SMTP id g3JHwjr26506 for ; Fri, 19 Apr 2002 19:58:46 +0200 (MEST) From: "Dani Eichhorn" To: Subject: Challenge S crashes configuring the base system Date: Fri, 19 Apr 2002 19:57:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi! I really hope anyone can help me out of this. I've got a SGI Challenge S 180 MHz. First I did set up NetBsd on it and it worked fine, but because the lack of software I decided to install Linux. The installation process didn't cause any troubles, but during the first boot (and every boot afterwards) the Challenge restarts/crashes during configuring the base system. This is the output of the boot sequence: 2027520+0+95120 entry: 0x8800246c ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R5000 FPU ICACHE DCACHE SCACHE CPU revision is: 00002310 FPU revision is: 00002310 Primary instruction cache 32kb, linesize 32 bytes. Primary data cache 32kb, linesize 32 bytes. TLB has 48 entries. Linux version 2.4.16 (root@nocontrol) (gcc version 2.95.4 20011006 (Debian prere lease)) #1 Sun Dec 16 16:38:44 CET 2001 MC: SGI memory controller Revision 3 R4600/R5000 SCACHE size 512K, linesize 32 bytes. Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 00001000 @ 00001000 (reserved) memory: 00207000 @ 08002000 (reserved) memory: 00537000 @ 08209000 (usable) memory: 000c0000 @ 08740000 (ROM data) memory: 07800000 @ 08800000 (usable) On node 0 totalpages: 65536 zone(0): 65536 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 Calibrating system timer... 900000 [180.00 MHz CPU] zs0: console input Console: ttyS0 (Zilog8530), 9600 baud Calibrating delay loop... 179.81 BogoMIPS Memory: 124104k/128220k available (1732k kernel code, 4116k reserved, 157k data, 84k init) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Diskquotas version dquot_6.4.0 initialized Journalled Block Device driver loaded initialize_kbd: Keyboard reset failed, no ACK pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: 128 slots per queue, batch=32 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:0a:1f:8b loop: loaded (max 8 devices) SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Dec 16 2001 at 16:56:27 scsi0 : SGI WD93 sending SDTR 0103013f0csync_xfer=2c Vendor: SEAGATE Model: ST15150N Rev: 0020 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi disk sda at scsi0, channel 0, id 2, lun 0 SCSI device sda: 8388315 512-byte hdwr sectors (4295 MB) Partition check: sda: sda1 sda2 sda3 sda4 SGI Zilog8530 serial driver version 1.00 tty00 at 0xbfbd9830 (irq = 29) is a Zilog8530 tty01 at 0xbfbd9838 (irq = 29) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing prom memory: 768kb freed Freeing unused kernel memory: 84k freed INIT: version 2.84 booting Activating swap. Adding Swap: 66280k swap-space (priority -1) Checking root file system... fsck 1.27 (8-Mar-2002) /dev/sda1: clean, 7735/502944 files, 46723/1004970 blocks EXT3 FS 2.4-0.9.15, 06 Nov 2001 on sd(8,1), internal journal System time was Fri Apr 19 17:40:52 UTC 2002. Setting the System Clock using the Hardware Clock as reference... System Clock set. System local time is now Fri Apr 19 17:40:55 UTC 2002. Calculating module dependencies... done. Loading modules: sg Checking all file systems... fsck 1.27 (8-Mar-2002) Setting kernel variables. Mounting local filesystems... nothing was mounted Running 0dns-down to make sure resolv.conf is ok...done. Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Fri Apr 19 17:41:05 UTC 2002 Cleaning: /tmp /var/lock /var/run. Initializing random number generator... done. Recovering nvi editor sessions... done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting internet superserver: inetd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. Configuring the base system... Can you help me? What exactly is happening at this last boot point? You can hear the disk working for a few seconds after the last point appears, but then the serial console clears and a new boot sequence is started. Thank you Dani Eichhorn --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.346 / Virus Database: 194 - Release Date: 10.04.2002 From owner-linux-mips@oss.sgi.com Sun Apr 21 04:10:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3LBAhqf003602 for ; Sun, 21 Apr 2002 04:10:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LBAhUH003601 for linux-mips-outgoing; Sun, 21 Apr 2002 04:10:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LBAQqf003595 for ; Sun, 21 Apr 2002 04:10:27 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 0DFB98D35; Sun, 21 Apr 2002 13:10:51 +0200 (CEST) Date: Sun, 21 Apr 2002 13:10:51 +0200 From: Guido Guenther To: Dani Eichhorn Cc: linux-mips@oss.sgi.com Subject: Re: Challenge S crashes configuring the base system Message-ID: <20020421131051.A12044@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Dani Eichhorn , linux-mips@oss.sgi.com 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 dani.eichhorn@squix.ch on Fri, Apr 19, 2002 at 07:57:48PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Apr 19, 2002 at 07:57:48PM +0200, Dani Eichhorn wrote: > Hi! > > I really hope anyone can help me out of this. > I've got a SGI Challenge S 180 MHz. First I did set up NetBsd on it and it > worked fine, but because the lack of software I decided to install Linux. > The installation process didn't cause any troubles, but during the first > boot (and every boot afterwards) the Challenge restarts/crashes during > configuring the base system. This is the output of the boot sequence: > > 2027520+0+95120 entry: 0x8800246c > ARCH: SGI-IP22 > PROMLIB: ARC firmware Version 1 Revision 10 > CPU: MIPS-R5000 FPU ICACHE DCACHE SCACHE > CPU revision is: 00002310 > FPU revision is: 00002310 > Primary instruction cache 32kb, linesize 32 bytes. > Primary data cache 32kb, linesize 32 bytes. > TLB has 48 entries. > Linux version 2.4.16 (root@nocontrol) (gcc version 2.95.4 20011006 (Debian > prere > lease)) #1 Sun Dec 16 16:38:44 CET 2001 > MC: SGI memory controller Revision 3 > R4600/R5000 SCACHE size 512K, linesize 32 bytes. > Determined physical RAM map: > memory: 00001000 @ 00000000 (reserved) > memory: 00001000 @ 00001000 (reserved) > memory: 00207000 @ 08002000 (reserved) > memory: 00537000 @ 08209000 (usable) > memory: 000c0000 @ 08740000 (ROM data) > memory: 07800000 @ 08800000 (usable) > On node 0 totalpages: 65536 > zone(0): 65536 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: root=/dev/sda1 > Calibrating system timer... 900000 [180.00 MHz CPU] > zs0: console input > Console: ttyS0 (Zilog8530), 9600 baud > Calibrating delay loop... 179.81 BogoMIPS > Memory: 124104k/128220k available (1732k kernel code, 4116k reserved, 157k > data, > 84k init) > Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) > Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) > Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) > Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) > Page-cache hash table entries: 65536 (order: 6, 262144 bytes) > Checking for 'wait' instruction... available. > POSIX conformance testing by UNIFIX > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd > VFS: Diskquotas version dquot_6.4.0 initialized > Journalled Block Device driver loaded > initialize_kbd: Keyboard reset failed, no ACK > pty: 256 Unix98 ptys configured > keyboard: Timeout - AT keyboard not present?(ed) > keyboard: Timeout - AT keyboard not present?(f4) > DS1286 Real Time Clock Driver v1.0 > streamable misc devices registered (keyb:150, gfx:148) > block: 128 slots per queue, batch=32 > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > sgiseeq.c: David S. Miller (dm@engr.sgi.com) > eth0: SGI Seeq8003 08:00:69:0a:1f:8b > loop: loaded (max 8 devices) > SCSI subsystem driver Revision: 1.00 > wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 > setup_args=,,,,,,,,, > Version 1.25 - 09/Jul/1997, Compiled Dec 16 2001 at 16:56:27 > scsi0 : SGI WD93 > sending SDTR 0103013f0csync_xfer=2c Vendor: SEAGATE Model: ST15150N > Rev: 0020 > Type: Direct-Access ANSI SCSI revision: 02 > Attached scsi disk sda at scsi0, channel 0, id 2, lun 0 > SCSI device sda: 8388315 512-byte hdwr sectors (4295 MB) > Partition check: > sda: sda1 sda2 sda3 sda4 > SGI Zilog8530 serial driver version 1.00 > tty00 at 0xbfbd9830 (irq = 29) is a Zilog8530 > tty01 at 0xbfbd9838 (irq = 29) is a Zilog8530 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 2048 buckets, 16Kbytes > TCP: Hash tables configured (established 16384 bind 16384) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > EXT3-fs: INFO: recovery required on readonly filesystem. > EXT3-fs: write access will be enabled during recovery. > kjournald starting. Commit interval 5 seconds > EXT3-fs: recovery complete. > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing prom memory: 768kb freed > Freeing unused kernel memory: 84k freed > INIT: version 2.84 booting > Activating swap. > Adding Swap: 66280k swap-space (priority -1) > Checking root file system... > fsck 1.27 (8-Mar-2002) > /dev/sda1: clean, 7735/502944 files, 46723/1004970 blocks > EXT3 FS 2.4-0.9.15, 06 Nov 2001 on sd(8,1), internal journal > System time was Fri Apr 19 17:40:52 UTC 2002. > Setting the System Clock using the Hardware Clock as reference... > System Clock set. System local time is now Fri Apr 19 17:40:55 UTC 2002. > Calculating module dependencies... done. > Loading modules: sg > Checking all file systems... > fsck 1.27 (8-Mar-2002) > Setting kernel variables. > Mounting local filesystems... > nothing was mounted > Running 0dns-down to make sure resolv.conf is ok...done. > Cleaning: /etc/network/ifstate. > Setting up IP spoofing protection: rp_filter. > Configuring network interfaces: done. > > Setting the System Clock using the Hardware Clock as reference... > System Clock set. Local time: Fri Apr 19 17:41:05 UTC 2002 > > Cleaning: /tmp /var/lock /var/run. > Initializing random number generator... done. > Recovering nvi editor sessions... done. > INIT: Entering runlevel: 2 > Starting system log daemon: syslogd. > Starting kernel log daemon: klogd. > Starting internet superserver: inetd. > Starting deferred execution scheduler: atd. > Starting periodic command scheduler: cron. > Configuring the base system... It doesn't really "crash". The porblem is that the installer doesn't correctly detect the serial console and therefore displays everything on tty1 not ttyS0. Boot with /bin/bash as init (use "boot init=/bin/bash" in the PROM) and edit /etc/inittab. Look for lines containing "base-config". Are you using recent boot-floppies(3.0.22)? If so, please file a bugreport. -- Guido From owner-linux-mips@oss.sgi.com Mon Apr 22 04:34:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MBYhqf028327 for ; Mon, 22 Apr 2002 04:34:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MBYhPE028326 for linux-mips-outgoing; Mon, 22 Apr 2002 04:34:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MBYcqf028323 for ; Mon, 22 Apr 2002 04:34:39 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA10044; Mon, 22 Apr 2002 13:35:23 +0200 (MET DST) Date: Mon, 22 Apr 2002 13:35:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 20 Apr 2002, Geert Uytterhoeven wrote: > > Does anyone know how to implement ioperm / iopl type > > functionality on a mips system. Any example code would > > be appreciated. > > Like on most architectures that use memory mapped I/O: mmap() the relevant > portion of /dev/mem and read/write to/from the mapped area. Hmm, I admit I haven't looked at this matter, but aren't in/out/ioperm/iopl implemented as library functions in glibc like for other architectures doing MMIO? E.g. Alpha does this an it makes porting programs like XFree86 and SVGATextMode much more straightforward and less processor-specific. That makes sense as they are not processor specific but rather bus-specific. If we don't do that, we should. For platforms without an (E)ISA or a PCI bus ioperm/iopl would simply return an error. -- + 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 Apr 22 07:47:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MElJqf031266 for ; Mon, 22 Apr 2002 07:47:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MElJ6u031265 for linux-mips-outgoing; Mon, 22 Apr 2002 07:47:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MElFqf031260 for ; Mon, 22 Apr 2002 07:47:15 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id HAA04236 for ; Mon, 22 Apr 2002 07:47:37 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA05701 for ; Mon, 22 Apr 2002 07:47:38 -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 g3MEklA04371 for ; Mon, 22 Apr 2002 16:46:47 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id QAA23835 for linux-mips@oss.sgi.com; Mon, 22 Apr 2002 16:46:45 +0200 (MET DST) Message-Id: <200204221446.QAA23835@copsun17.mips.com> Subject: Problems with H.J's latest RPM 4.0.4 binary packages To: linux-mips@oss.sgi.com (user alias) Date: Mon, 22 Apr 2002 16:46:45 +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 have started to update our 7.1 RH/MIPS installation images with all the latest packages from H.J's collection. The latest RPM package gives an up-front error no matter what one does, but the command seems to work: [hartvige@copmalt13 /bin]$ rpm --version error: Macro %__id_u has empty body RPM version 4.0.4 [hartvige@copmalt13 /bin]$ Before I start digging any deeper, has anybody else seen this and found the explanation? (Note that I have not yet finished compiling the glibc RPM natively as required - this is currently ongoing). /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 Mon Apr 22 07:55:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MEtZqf031429 for ; Mon, 22 Apr 2002 07:55:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MEtZEU031428 for linux-mips-outgoing; Mon, 22 Apr 2002 07:55:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MEtUqf031421 for ; Mon, 22 Apr 2002 07:55:30 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA14605; Mon, 22 Apr 2002 16:55:08 +0200 (MET DST) Date: Mon, 22 Apr 2002 16:55:07 +0200 (MEST) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? 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 Mon, 22 Apr 2002, Maciej W. Rozycki wrote: > On Sat, 20 Apr 2002, Geert Uytterhoeven wrote: > > > Does anyone know how to implement ioperm / iopl type > > > functionality on a mips system. Any example code would > > > be appreciated. > > > > Like on most architectures that use memory mapped I/O: mmap() the relevant > > portion of /dev/mem and read/write to/from the mapped area. > > Hmm, I admit I haven't looked at this matter, but aren't > in/out/ioperm/iopl implemented as library functions in glibc like for > other architectures doing MMIO? E.g. Alpha does this an it makes porting Perhaps. Note that you still need some /proc magic to find out the correct address to map. Or you can use /dev/ports. > programs like XFree86 and SVGATextMode much more straightforward and less > processor-specific. That makes sense as they are not processor specific > but rather bus-specific. If we don't do that, we should. For platforms > without an (E)ISA or a PCI bus ioperm/iopl would simply return an error. Yes indeed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Apr 22 08:29:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MFTOqf031780 for ; Mon, 22 Apr 2002 08:29:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MFTO33031779 for linux-mips-outgoing; Mon, 22 Apr 2002 08:29:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MFTJqf031776 for ; Mon, 22 Apr 2002 08:29:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15670; Mon, 22 Apr 2002 17:30:08 +0200 (MET DST) Date: Mon, 22 Apr 2002 17:30:08 +0200 (MET DST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 22 Apr 2002, Geert Uytterhoeven wrote: > > Hmm, I admit I haven't looked at this matter, but aren't > > in/out/ioperm/iopl implemented as library functions in glibc like for > > other architectures doing MMIO? E.g. Alpha does this an it makes porting > > Perhaps. Note that you still need some /proc magic to find out the correct > address to map. Or you can use /dev/ports. Well, for Alpha ioperm/iopl functions check the system type in /proc/cpuinfo (we seem to have enough information there as well) and failing this they check a result of readlink of /etc/alpha_systype. Then an appropriate region of /dev/mem is mmapped with per-page permissions set up as requested if ioperm is used (with a worse granularity, though) and subsequent in/out function invocations access the area as appropriate. See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a pretty clever solution with good performance and only a few trade-offs. -- + 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 Apr 22 08:34:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MFY4qf031895 for ; Mon, 22 Apr 2002 08:34:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MFY4sK031894 for linux-mips-outgoing; Mon, 22 Apr 2002 08:34:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MFXvqf031888 for ; Mon, 22 Apr 2002 08:33:58 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA17722; Mon, 22 Apr 2002 17:33:31 +0200 (MET DST) Date: Mon, 22 Apr 2002 17:33:30 +0200 (MEST) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? 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 Mon, 22 Apr 2002, Maciej W. Rozycki wrote: > On Mon, 22 Apr 2002, Geert Uytterhoeven wrote: > > > Hmm, I admit I haven't looked at this matter, but aren't > > > in/out/ioperm/iopl implemented as library functions in glibc like for > > > other architectures doing MMIO? E.g. Alpha does this an it makes porting > > > > Perhaps. Note that you still need some /proc magic to find out the correct > > address to map. Or you can use /dev/ports. > > Well, for Alpha ioperm/iopl functions check the system type in > /proc/cpuinfo (we seem to have enough information there as well) and > failing this they check a result of readlink of /etc/alpha_systype. Then > an appropriate region of /dev/mem is mmapped with per-page permissions set > up as requested if ioperm is used (with a worse granularity, though) and > subsequent in/out function invocations access the area as appropriate. > See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a > pretty clever solution with good performance and only a few trade-offs. I think PPC has syscalls to find the I/O bases, too. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Apr 22 09:40:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MGeEqf002716 for ; Mon, 22 Apr 2002 09:40:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MGeEtV002715 for linux-mips-outgoing; Mon, 22 Apr 2002 09:40:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MGeBqf002690 for ; Mon, 22 Apr 2002 09:40:12 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020422164038.YSTK1143.rwcrmhc51.attbi.com@ocean.lucon.org>; Mon, 22 Apr 2002 16:40:38 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 86976125C7; Mon, 22 Apr 2002 09:40:37 -0700 (PDT) Date: Mon, 22 Apr 2002 09:40:37 -0700 From: "H . J . Lu" To: Hartvig Ekner Cc: user alias Subject: Re: Problems with H.J's latest RPM 4.0.4 binary packages Message-ID: <20020422094037.A12357@lucon.org> References: <200204221446.QAA23835@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: <200204221446.QAA23835@copsun17.mips.com>; from hartvige@mips.com on Mon, Apr 22, 2002 at 04:46:45PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 22, 2002 at 04:46:45PM +0200, Hartvig Ekner wrote: > I have started to update our 7.1 RH/MIPS installation images with all the > latest packages from H.J's collection. > > The latest RPM package gives an up-front error no matter what one does, but > the command seems to work: > > [hartvige@copmalt13 /bin]$ rpm --version > error: Macro %__id_u has empty body > RPM version 4.0.4 > [hartvige@copmalt13 /bin]$ > I have no problems with the mipsel rpm binary. Did you compile rpm 4.0.4 yourselves? Please send me # cd /usr/lib/rpm # grep __id_u * */* H.J. From owner-linux-mips@oss.sgi.com Mon Apr 22 10:41:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MHfxqf006298 for ; Mon, 22 Apr 2002 10:41:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MHfrPO006297 for linux-mips-outgoing; Mon, 22 Apr 2002 10:41:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MHfoqf006294 for ; Mon, 22 Apr 2002 10:41:50 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3MHgL410213; Mon, 22 Apr 2002 10:42:21 -0700 Date: Mon, 22 Apr 2002 10:42:21 -0700 From: Ralf Baechle To: Hartvig Ekner Cc: user alias Subject: Re: Problems with H.J's latest RPM 4.0.4 binary packages Message-ID: <20020422104221.A10146@dea.linux-mips.net> References: <200204221446.QAA23835@copsun17.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200204221446.QAA23835@copsun17.mips.com>; from hartvige@mips.com on Mon, Apr 22, 2002 at 04:46:45PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 22, 2002 at 04:46:45PM +0200, Hartvig Ekner wrote: > [hartvige@copmalt13 /bin]$ rpm --version > error: Macro %__id_u has empty body > RPM version 4.0.4 > [hartvige@copmalt13 /bin]$ > > Before I start digging any deeper, has anybody else seen this and found the > explanation? > > (Note that I have not yet finished compiling the glibc RPM natively as > required - this is currently ongoing). Rpm has this nasty property of inherting much of it's configuration from one generation into the next generation. To get around this you will have to hack the configuration of your current rpm in /usr/lib/rpm/ rsp. /etc/rpm and rebuild. I've seen even more funny things when crossbuilding rpm. Ralf From owner-linux-mips@oss.sgi.com Mon Apr 22 10:43:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MHhoqf006398 for ; Mon, 22 Apr 2002 10:43:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MHhoCL006397 for linux-mips-outgoing; Mon, 22 Apr 2002 10:43:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MHhmqf006394 for ; Mon, 22 Apr 2002 10:43:48 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3MHiHA10227; Mon, 22 Apr 2002 10:44:17 -0700 Date: Mon, 22 Apr 2002 10:44:17 -0700 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Geert Uytterhoeven , Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? Message-ID: <20020422104417.B10146@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Apr 22, 2002 at 05:30:08PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 22, 2002 at 05:30:08PM +0200, Maciej W. Rozycki wrote: > Well, for Alpha ioperm/iopl functions check the system type in > /proc/cpuinfo (we seem to have enough information there as well) and > failing this they check a result of readlink of /etc/alpha_systype. Then > an appropriate region of /dev/mem is mmapped with per-page permissions set > up as requested if ioperm is used (with a worse granularity, though) and > subsequent in/out function invocations access the area as appropriate. > See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a > pretty clever solution with good performance and only a few trade-offs. Thanks for volunteering ;) Ralf From owner-linux-mips@oss.sgi.com Mon Apr 22 11:01:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MI1Aqf006648 for ; Mon, 22 Apr 2002 11:01:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MI1Asm006647 for linux-mips-outgoing; Mon, 22 Apr 2002 11:01:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MI0wqf006638; Mon, 22 Apr 2002 11:00:59 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA19526; Mon, 22 Apr 2002 20:01:39 +0200 (MET DST) Date: Mon, 22 Apr 2002 20:01:38 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Geert Uytterhoeven , Wayne Gowcher , Linux-MIPS Subject: Re: Equivalent of ioperm / iopl in linux mips ? In-Reply-To: <20020422104417.B10146@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 22 Apr 2002, Ralf Baechle wrote: > > Well, for Alpha ioperm/iopl functions check the system type in > > /proc/cpuinfo (we seem to have enough information there as well) and > > failing this they check a result of readlink of /etc/alpha_systype. Then > > an appropriate region of /dev/mem is mmapped with per-page permissions set > > up as requested if ioperm is used (with a worse granularity, though) and > > subsequent in/out function invocations access the area as appropriate. > > See sysdeps/unix/sysv/linux/alpha/ioperm.c in glibc for details -- it's a > > pretty clever solution with good performance and only a few trade-offs. > > Thanks for volunteering ;) Sure, but I have too many tasks on my to-do list now and no ISA/PCI MIPS system to test code. So anyone impatient enough, please do not hesitate coding changes yourself. Surely if you can afford waiting three years or so, you probably need not worry as I shall have done it by then. Also I'd appreciate if someone sent me a system for testing. This could actually save you a year or two of waiting. ;-) -- + 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 Apr 22 11:08:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MI8vqf006843 for ; Mon, 22 Apr 2002 11:08:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MI8vXL006842 for linux-mips-outgoing; Mon, 22 Apr 2002 11:08:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.kendin.com (mail.kendin.com [209.128.93.97] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MI8gqf006839 for ; Mon, 22 Apr 2002 11:08:47 -0700 Received: from cambrian (209-128-93-100.BAYAREA.NET [209.128.93.100]) by mail.kendin.com (8.11.6/8.11.2) with SMTP id g3MI2HE14067 for ; Mon, 22 Apr 2002 11:02:17 -0700 From: "Hui Jia" To: Subject: linux for IDT79S334A Date: Mon, 22 Apr 2002 11:07:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Can any one tell me where I can find the linux porting to IDT79S334A board. Thanks. William Jia From owner-linux-mips@oss.sgi.com Tue Apr 23 02:47:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3N9lFwJ006220 for ; Tue, 23 Apr 2002 02:47:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N9lFTG006219 for linux-mips-outgoing; Tue, 23 Apr 2002 02:47:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3N9l2wJ006215; Tue, 23 Apr 2002 02:47:03 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id g3N9lMn14266; Tue, 23 Apr 2002 11:47:22 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JF1RT5LW; Tue, 23 Apr 2002 11:47:21 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Tue, 23 Apr 2002 11:47:21 +0200 Received: by DLFW003A with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 11:47:25 +0200 Message-ID: <86048F07C015D311864100902760F1DD01B5E90E@DLFW003A> From: Andre.Messerschmidt@infineon.com To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: AW: Wait queue problem Date: Tue, 23 Apr 2002 11:47:20 +0200 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 > A bad race condition in that code. If foo_int is called before your > process > had a chance to get to sleep it'll never be woken before the timeout. > I think this has been the problem. Thanks. Is there any possibility to check if there are processes waiting on a queue? regards Andre From owner-linux-mips@oss.sgi.com Tue Apr 23 15:59:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NMxDwJ003221 for ; Tue, 23 Apr 2002 15:59:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NMxClM003220 for linux-mips-outgoing; Tue, 23 Apr 2002 15:59:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NMx8wJ003217 for ; Tue, 23 Apr 2002 15:59:08 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020423225926.LQQH9486.rwcrmhc51.attbi.com@ocean.lucon.org>; Tue, 23 Apr 2002 22:59:26 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6DB28125C7; Tue, 23 Apr 2002 15:59:25 -0700 (PDT) Date: Tue, 23 Apr 2002 15:59:25 -0700 From: "H . J . Lu" To: Hartvig Ekner , linux-mips@oss.sgi.com Subject: Updates for RedHat 7.1/mips Message-ID: <20020423155925.A8846@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Apr 22, 2002 at 08:38:49PM +0200, Hartvig Ekner wrote: > Hi, > > H . J . Lu writes: > > > > On Mon, Apr 22, 2002 at 06:55:14PM +0200, Hartvig Ekner wrote: > > > Hi H.J, > > > > > > No, I did not compile myself, but used your binary (except for cracklib, > > > where I used our natively compiled package instead). But I did replace > > > ALL new updated packages at once during the upgrade. > > > > > > However, I have also tried to install (-U) rpm*rpm and the popt rpm on a > > > working system based on your original packages, and voila: the same error > > > appears. So it does appear to be linked to the rpm RPM package. > > > > > > The grep you asked for returns: > > > > Thanks. I will fix those among other bugs I have been working on. > > Great, thanks. Can you let me know as soon as the RPM problem has been fixed, > so that I can continue the update of the installation images? BTW, are the > other bugs you're working on something to wait for in this regard or not? > I updated glibc, python, gcc, gdb, rpm, openssl, binutils and toolchain at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ Let know know if there are any problems. H.J. From owner-linux-mips@oss.sgi.com Tue Apr 23 16:08:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NN8fwJ003381 for ; Tue, 23 Apr 2002 16:08:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NN8f5W003380 for linux-mips-outgoing; Tue, 23 Apr 2002 16:08:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NN7dwJ003372 for ; Tue, 23 Apr 2002 16:07:39 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020423230753.LPXD18004.rwcrmhc54.attbi.com@ocean.lucon.org>; Tue, 23 Apr 2002 23:07:53 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 45189125C7; Tue, 23 Apr 2002 16:07:49 -0700 (PDT) Date: Tue, 23 Apr 2002 16:07:49 -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 Subject: The Linux binutils 2.12.90.0.7 is released. Message-ID: <20020423160749.A9039@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.12.90.0.7 for Linux, which is based on binutils 2002 0423 in CVS on sourecs.redhat.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f 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.12.90.0.7 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.12.90.0.4: 1. Update from binutils 2002 0423. 2. ELF EH frame bug fix. 3. MIPS ELF visibility bug fix. Changes from binutils 2.12.90.0.3: 1. Update from binutils 2002 0408. 2. Bug fixes for ELF/sparc. 3. Bug fixes for ELF/CRIS. Changes from binutils 2.12.90.0.1: 1. Update from binutils 2002 0323. 2. Fix linking a.out relocatable files with ELF. 3. Fix a PPC altivec assembler bug. Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.12.90.0.7.tar.gz. Source code. 2. binutils-2.12.90.0.4-2.12.90.0.7.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.7-1.i386.rpm. IA-32 binary RPM for RedHat 7.2. There is no separate source rpm. You can do # rpm -ta binutils-2.12.90.0.7.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 04/23/2002 From owner-linux-mips@oss.sgi.com Tue Apr 23 16:42:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NNg1wJ003833 for ; Tue, 23 Apr 2002 16:42:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NNg1RV003832 for linux-mips-outgoing; Tue, 23 Apr 2002 16:42:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from darth.paname.org (root@ns0.paname.org [212.27.32.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NNftwJ003829 for ; Tue, 23 Apr 2002 16:41:56 -0700 Received: from darth.paname.org (localhost [127.0.0.1]) by darth.paname.org (8.12.1/8.12.1/Debian -2) with ESMTP id g3NNgHZB011459 for ; Wed, 24 Apr 2002 01:42:17 +0200 Received: (from rani@localhost) by darth.paname.org (8.12.1/8.12.1/Debian -2) id g3NNgHrI011458 for linux-mips@oss.sgi.com; Wed, 24 Apr 2002 01:42:17 +0200 From: Rani Assaf Date: Wed, 24 Apr 2002 01:42:17 +0200 To: linux-mips@oss.sgi.com Subject: Interrupts, exceptions and modules Message-ID: <20020424014217.W27181@paname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux darth 2.4.17-pre8 X-NCC-RegID: fr.proxad Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I run into the following problem when loading a module that uses interrupts (net driver): 1) Module loads and request_irq() 2) We take an interrupt before doing anything else in the module. Our low level IRQ handler (for the RC32300) disables interrupts by clearing the IE bit in CP0_STATUS (code based on the various implementations of other boards) 3) in handle_IRQ_event() the module handler is called through: action->handler(irq, action->dev_id, regs); 4) The processor does an exception (tlb miss/refill) to get the page pointed by action->handler. At the end of the tlb exception handler, we have an "eret" => interrupts are enabled again (IE bit goes to 1) 5) We take another interrupt (because we didn't get into the handler to clear the cause yet), in do_IRQ() we see that one is already pending => eret 6) goto 5 I had to disable interrupts through CP0_STATUS IM bits in the low level interrupt handler to handle this. I looked at the code of other boards and none seemed to do this. So did I miss something? Couldn't this happen to anyone who loads a module and get the modules's intialization code and the interrupt handler go into different pages? Regards, Rani From owner-linux-mips@oss.sgi.com Tue Apr 23 18:12:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O1C5wJ006672 for ; Tue, 23 Apr 2002 18:12:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O1C5wR006671 for linux-mips-outgoing; Tue, 23 Apr 2002 18:12:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O1BowJ006668 for ; Tue, 23 Apr 2002 18:11:50 -0700 Message-Id: <200204240111.g3O1BowJ006668@oss.sgi.com> Received: (qmail 16595 invoked from network); 24 Apr 2002 01:08:48 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 24 Apr 2002 01:08:48 -0000 Date: Wed, 24 Apr 2002 9:11:38 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: vga initialization 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 hi, I find most code is already there in scitech's x86emu-0.8. in one day it is adapted into linux kernel. If anybody is interested,my code can be fetched from ftp://ftp.gnuchina.org/incoming/mips-vga-init/freebiosvga.tar.gz For a short description,the READ in the package is paste here: This is x86/bios emulator adapted for used in 2.4 kernel to do initialize pc VGA cards. Port it to pmon/yamon should be easy,if you want an userland executable,please download the original x86emu-0.8 from SciTech Software, Inc. Usage: here is my choice: 1.add code in new directory arch/mips/freebiosvga/ 2.arch/mips/config.in: add config option CONFIG_VGA_POST to proper place bool ' Support for VGA POST' CONFIG_VGA_POST 3.arch/mips/Makefile add directory and target objects of freevgabios ifdef CONFIG_VGA_POST SUBDIRS += arch/mips/freebiosvga LIBS += arch/mips/freebiosvga/vga.o SUBDIRS += arch/mips/freebiosvga/x86emu LIBS += arch/mips/freebiosvga/x86emu/x86emu.o endif 4.init/main.c: add call to vgabios_init (right after pci_init) #ifdef CONFIG_VGA_POST vgabios_init(); #endif 5.select 'VGA text console' or proper framebuffer, you may need to slightly modify the code,because many of them is for x86 for 'VGA text console',the file is drivers/video/vgacon.c,propably you need to comment out the check for card's presence in vgacon_startup. Because card initialization is later than console_init,so at that time pci address 0xa0000-0xc0000 may not response to your requests. Problems & limits: 1.currently the code rely on system's pci resource allocator to assign a valid address to rom base register(offset 0x30 in pci header). I have modified the pci_auto.c to handle rom. Patch is here: diff -r1.2 pci_auto.c 107a108,110 > u32 bases[7] = {PCI_BASE_ADDRESS_0,PCI_BASE_ADDRESS_1,PCI_BASE_ADDRESS_2, > PCI_BASE_ADDRESS_3,PCI_BASE_ADDRESS_4,PCI_BASE_ADDRESS_5, > PCI_ROM_ADDRESS}; 110c113,116 < for (bar = PCI_BASE_ADDRESS_0; bar <= PCI_BASE_ADDRESS_5; bar+=4) { --- > for (bar_nr=0; bar_nr<7; bar_nr++) { > > bar = bases[bar_nr]; > 137c143 < if (bar_response & PCI_BASE_ADDRESS_SPACE) { --- > if (bar_nr != 6 && (bar_response & PCI_BASE_ADDRESS_SPACE)) { 209d214 < bar_nr++; 349,350d353 < < DBG("Skipping legacy mode IDE controller\n"); if you don't use pci_auto,then make sure your pmon/yamon do it. Of course,you can write an absolute,safe value for your specific platform to see it works:) If the base address read from your card is invalid,you will get message like: "No address assigned to rom" or "No valid bios found" 2. i am assuming ioremap(a_pci_address) will return a valid cpu virtue address for accessing memory located at 'a_pci_address'. 3. Multiple cards are not supported currently,though it may be a piece of cake.Complex cards,e.g. those contain bridges,may fail. 4. cards tested here include: trident 3Dimage9750,S3virge,Riva TNT2 DISCLAIMER: It is provided "as is" without express or implied warranty. Any problems you can contact fxzhang@ict.ac.cn. Happy hacking and good luck. -- Zhang Fuxin System Architecture Lab Institute of Computing Technology Chinese Academy of Sciences,China http://www.ict.ac.cn Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Wed Apr 24 03:12:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OACbwJ013726 for ; Wed, 24 Apr 2002 03:12:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OACbhx013725 for linux-mips-outgoing; Wed, 24 Apr 2002 03:12:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from msr.hinet.net (msr80.hinet.net [168.95.4.180]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OACTwJ013719 for ; Wed, 24 Apr 2002 03:12:30 -0700 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id SAA26648; Wed, 24 Apr 2002 18:12:52 +0800 (CST) From: "Ku" To: "Linux-Mips" Subject: Confused about Linux MIPS Boot Flow, Date: Wed, 24 Apr 2002 18:13:01 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g3OACUwJ013722 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi everybody, I got the source code about Linux PhilpNino and traced, BUT, If I use PMON for bootstrape code The situation I assume, 0. I prepare two compressed images about kernel image and ramdisk image in flash 1. With boot loader PMON 2.6 source code STEP 1: I modify go() function to decompress kernel image from to 0x80000000 STEP 2: with PMON monitor code, then execute "go -e 0x80000000" 2. then the flow into the kernel_entry point respect to the source code "arch\mips\jernel\head.s" the kernel_entry segmentation is continued by init_arch to call prom_init ... and start_kernel... -->IS THIS FLOW CORRECT? ================================= For example to load RAMDISK on Linux PowerPC, I ever make the "ramdisk.gz" from flash to a free memory firstly, after then, using PPCBOOT to transfer the "initrd_start" and "initrd_end" to kernel So, the kernel image can work well to loading ramdisk and mount root, and go on... BUT, For Linux PhilpNino on MIPS CPU, I just find the ramdisk setting. in "arch/mips/philps/nino/in ld.script" ==== OUTPUT_FORMAT("ecoff-littlemips") OUTPUT_ARCH(mips) SECTIONS { .initrd : { *(.data) } } ==== and the Makefile ==== ramdisk.o: ramdisk.gz ld.script $(LD) -T ld.script -b binary -o $@ ramdisk ==== then, obj-$(CONFIG_BLK_DEV_INITRD) += ramdisk.o I just do not know, How the "obj-y" can tell the kernel the entry adress to load ramdisk... Can I memcpy ramdisk,gz from flash to memory and pass the initrd_start and initrd_end to KERNEL (using the method as PowerPC's one)? Because I do not have the demo board for test, I just can trace the possible flow... thanks all, --Ku From owner-linux-mips@oss.sgi.com Wed Apr 24 06:12:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ODCJwJ021271 for ; Wed, 24 Apr 2002 06:12:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ODCJSS021270 for linux-mips-outgoing; Wed, 24 Apr 2002 06:12:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ODC1wJ021266 for ; Wed, 24 Apr 2002 06:12:01 -0700 Message-Id: <200204241312.g3ODC1wJ021266@oss.sgi.com> Received: (qmail 27258 invoked from network); 24 Apr 2002 13:09:14 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 24 Apr 2002 13:09:14 -0000 Date: Wed, 24 Apr 2002 21:11:20 +0800 From: Zhang Fuxin To: Girish Gulawani CC: "linux-mips@oss.sgi.com" Subject: Re: Re: vga initialization X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3ODC2wJ021267 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, I don't have that card at hand:(. But if you have tried this emulation code,please give more detailed message: 1. what you do 2. output (dmesg,or captured from your serial console). 3. your platform,esp. whether it has pc legacy hardware support. For example,a PIIX4 or via686a southbridge will give you functionality of the legacy vga support,8254 timer and standard io ports (0x41-0x43 timer,0x61->timer 2 enable,0x3c0-0x3cf ->vga ports etc.) ÔÚ 2002-04-24 20:15:00 you wrote£º >would you by any chance try this emulation on AOpen's PT80 card? i failed to >fire up this card. any clues? > > >----- Original Message ----- >From: "Zhang Fuxin" >To: >Sent: Wednesday, April 24, 2002 10:11 AM >Subject: vga initialization > > >> hi, >> I find most code is already there in scitech's x86emu-0.8. >> in one day it is adapted into linux kernel. >> >> If anybody is interested,my code can be fetched from >> ftp://ftp.gnuchina.org/incoming/mips-vga-init/freebiosvga.tar.gz >> >> For a short description,the READ in the package is paste here: >> >> This is x86/bios emulator adapted for used in 2.4 kernel >> to do initialize pc VGA cards. >> >> Port it to pmon/yamon should be easy,if you want an userland >> executable,please download the original x86emu-0.8 from SciTech >> Software, Inc. >> >> Usage: >> here is my choice: >> 1.add code in new directory arch/mips/freebiosvga/ >> 2.arch/mips/config.in: >> add config option CONFIG_VGA_POST to proper place >> bool ' Support for VGA POST' CONFIG_VGA_POST >> >> 3.arch/mips/Makefile >> add directory and target objects of freevgabios >> >> ifdef CONFIG_VGA_POST >> SUBDIRS += arch/mips/freebiosvga >> LIBS += arch/mips/freebiosvga/vga.o >> SUBDIRS += arch/mips/freebiosvga/x86emu >> LIBS += arch/mips/freebiosvga/x86emu/x86emu.o >> endif >> >> 4.init/main.c: >> add call to vgabios_init (right after pci_init) >> #ifdef CONFIG_VGA_POST >> vgabios_init(); >> #endif >> >> 5.select 'VGA text console' or proper framebuffer, you may need to >> slightly modify the code,because many of them is for x86 >> >> for 'VGA text console',the file is drivers/video/vgacon.c,propably >> you need to comment out the check for card's presence in vgacon_startup. >> Because card initialization is later than console_init,so at that time >> pci address 0xa0000-0xc0000 may not response to your requests. >> >> >> Problems & limits: >> 1.currently the code rely on system's pci resource allocator to assign >> a valid address to rom base register(offset 0x30 in pci header). >> I have modified the pci_auto.c to handle rom. Patch is here: >> >> diff -r1.2 pci_auto.c >> 107a108,110 >> > u32 bases[7] = >{PCI_BASE_ADDRESS_0,PCI_BASE_ADDRESS_1,PCI_BASE_ADDRESS_2, >> > >PCI_BASE_ADDRESS_3,PCI_BASE_ADDRESS_4,PCI_BASE_ADDRESS_5, >> > PCI_ROM_ADDRESS}; >> 110c113,116 >> < for (bar = PCI_BASE_ADDRESS_0; bar <= PCI_BASE_ADDRESS_5; >bar+=4) { >> --- >> > for (bar_nr=0; bar_nr<7; bar_nr++) { >> > >> > bar = bases[bar_nr]; >> > >> 137c143 >> < if (bar_response & PCI_BASE_ADDRESS_SPACE) { >> --- >> > if (bar_nr != 6 && (bar_response & >PCI_BASE_ADDRESS_SPACE)) { >> 209d214 >> < bar_nr++; >> 349,350d353 >> < >> < DBG("Skipping legacy mode IDE controller\n"); >> >> if you don't use pci_auto,then make sure your pmon/yamon do it. >> >> Of course,you can write an absolute,safe value for your specific >platform >> to see it works:) >> >> If the base address read from your card is invalid,you will get message >> like: >> "No address assigned to rom" or "No valid bios found" >> >> 2. i am assuming ioremap(a_pci_address) will return a valid cpu virtue >> address for accessing memory located at 'a_pci_address'. >> >> >> 3. Multiple cards are not supported currently,though it may be a piece of >> cake.Complex cards,e.g. those contain bridges,may fail. >> >> 4. cards tested here include: >> trident 3Dimage9750,S3virge,Riva TNT2 >> >> DISCLAIMER: >> It is provided "as is" without express or implied warranty. >> >> Any problems you can contact fxzhang@ict.ac.cn. >> >> >> Happy hacking and good luck. > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Wed Apr 24 06:35:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ODZwwJ021829 for ; Wed, 24 Apr 2002 06:35:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ODZwjd021828 for linux-mips-outgoing; Wed, 24 Apr 2002 06:35:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ODZrwJ021825 for ; Wed, 24 Apr 2002 06:35:53 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id GAA14093; Wed, 24 Apr 2002 06:36:10 -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 GAA11195; Wed, 24 Apr 2002 06:36:09 -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 g3ODZHA07656; Wed, 24 Apr 2002 15:35:17 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id PAA02613; Wed, 24 Apr 2002 15:35:16 +0200 (MET DST) Message-Id: <200204241335.PAA02613@copsun17.mips.com> Subject: Re: Updates for RedHat 7.1/mips To: hjl@lucon.org (H . J . Lu) Date: Wed, 24 Apr 2002 15:35:16 +0200 (MET DST) Cc: linux-mips@oss.sgi.com In-Reply-To: <20020423155925.A8846@lucon.org> from "H . J . Lu" at Apr 23, 2002 03:59:25 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 All the problems I reported are fixed (only tested LE so far). Thanks. Currently recompiling glibc natively for the installation images. We'll post a message here when our new installation images are ready. /Hartvig H . J . Lu writes: > > On Mon, Apr 22, 2002 at 08:38:49PM +0200, Hartvig Ekner wrote: > > Hi, > > > > H . J . Lu writes: > > > > > > On Mon, Apr 22, 2002 at 06:55:14PM +0200, Hartvig Ekner wrote: > > > > Hi H.J, > > > > > > > > No, I did not compile myself, but used your binary (except for cracklib, > > > > where I used our natively compiled package instead). But I did replace > > > > ALL new updated packages at once during the upgrade. > > > > > > > > However, I have also tried to install (-U) rpm*rpm and the popt rpm on a > > > > working system based on your original packages, and voila: the same error > > > > appears. So it does appear to be linked to the rpm RPM package. > > > > > > > > The grep you asked for returns: > > > > > > Thanks. I will fix those among other bugs I have been working on. > > > > Great, thanks. Can you let me know as soon as the RPM problem has been fixed, > > so that I can continue the update of the installation images? BTW, are the > > other bugs you're working on something to wait for in this regard or not? > > > > I updated glibc, python, gcc, gdb, rpm, openssl, binutils and toolchain at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > Let know know if there are any problems. > > > H.J. From owner-linux-mips@oss.sgi.com Wed Apr 24 08:31:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OFVvwJ025541 for ; Wed, 24 Apr 2002 08:31:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFVvuI025540 for linux-mips-outgoing; Wed, 24 Apr 2002 08:31:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFVswJ025537 for ; Wed, 24 Apr 2002 08:31:54 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA03667 for ; Wed, 24 Apr 2002 08:31:37 -0700 (PDT) mail_from (michael_pruznick@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA07792 for ; Wed, 24 Apr 2002 08:15:10 -0700 Message-ID: <3CC6CC21.45E7ABB1@mvista.com> Date: Wed, 24 Apr 2002 09:15:45 -0600 From: Michael Pruznick Reply-To: michael_pruznick@mvista.com Organization: MontaVista X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ps2 keyboard -- no key down events Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm working on this mips board with a smsc 90e66 south bridge and fdc37m812 super io. I'm using the standard pc_keyb.c driver. I only see keyboard interrupts and KBD_STAT_OBF set in response to "key up" events. I never see them in response to "key down" events. Thus, the shell running on the vga console never gets my input (since it is the "key down" events that pass the character typed to the shell). At this point, I'm thinking that the standard driver needs some mods to work with the super io's ps2 controller. The smsc doc only covers programming the plug and play registers and doesn't give any info about programming the ps2 controller. I've looked around the web, but haven't found anything useful. Can anyone point me towards some resources that might help out? -- Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085 From owner-linux-mips@oss.sgi.com Wed Apr 24 09:57:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OGvPwJ026824 for ; Wed, 24 Apr 2002 09:57:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OGvPPZ026823 for linux-mips-outgoing; Wed, 24 Apr 2002 09:57:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OGv0wJ026819 for ; Wed, 24 Apr 2002 09:57:11 -0700 Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 170Q3k-0000vc-00; Wed, 24 Apr 2002 12:56:00 -0400 Message-ID: <013401c1ebb1$12e39cd0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: , References: <3CC6CC21.45E7ABB1@mvista.com> Subject: Re: ps2 keyboard -- no key down events Date: Wed, 24 Apr 2002 12:57:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Could it be a level-trigger versus edge-trigger interrupt setting? Regards, Brad ----- Original Message ----- From: "Michael Pruznick" To: Sent: Wednesday, April 24, 2002 11:15 AM Subject: ps2 keyboard -- no key down events > I'm working on this mips board with a smsc 90e66 south bridge and > fdc37m812 super io. I'm using the standard pc_keyb.c driver. I only > see keyboard interrupts and KBD_STAT_OBF set in response to "key up" > events. I never see them in response to "key down" events. Thus, the > shell running on the vga console never gets my input (since it is the > "key down" events that pass the character typed to the shell). > > At this point, I'm thinking that the standard driver needs some mods > to work with the super io's ps2 controller. The smsc doc only covers > programming the plug and play registers and doesn't give any info about > programming the ps2 controller. > > I've looked around the web, but haven't found anything useful. > > Can anyone point me towards some resources that might help out? > > -- > Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com > MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085 > From owner-linux-mips@oss.sgi.com Wed Apr 24 11:05:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OI5fwJ002466 for ; Wed, 24 Apr 2002 11:05:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OI5f9P002465 for linux-mips-outgoing; Wed, 24 Apr 2002 11:05:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OI5ZwJ002462 for ; Wed, 24 Apr 2002 11:05:36 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA25301; Wed, 24 Apr 2002 20:06:21 +0200 (MET DST) Date: Wed, 24 Apr 2002 20:06:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Michael Pruznick cc: linux-mips@oss.sgi.com Subject: Re: ps2 keyboard -- no key down events In-Reply-To: <3CC6CC21.45E7ABB1@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 24 Apr 2002, Michael Pruznick wrote: > I'm working on this mips board with a smsc 90e66 south bridge and > fdc37m812 super io. I'm using the standard pc_keyb.c driver. I only > see keyboard interrupts and KBD_STAT_OBF set in response to "key up" > events. I never see them in response to "key down" events. Thus, the > shell running on the vga console never gets my input (since it is the > "key down" events that pass the character typed to the shell). > > At this point, I'm thinking that the standard driver needs some mods > to work with the super io's ps2 controller. The smsc doc only covers > programming the plug and play registers and doesn't give any info about > programming the ps2 controller. An 8042-compatible microcontroller (actually the firmware it runs) may need to be programmed to a PC/AT-compatible mode. On an i386 it is typically done by the BIOS. Try dumping configuration data from your chip and compare it with what is set up in an i386 system. You can dump 32 bytes of configuration data with the 0x20 command of the 8042 (5 low-order bits of a command byte specify an address). Writing can be performed using the 0x60 command (the same semantics). Some data is available in the Ralf Brown's interrupt list (look for "inter60*.zip" files on a SimTel DOS collection's mirror). I have an old Intel hardcopy document somewhere that describes to some extent the IBM-defined locations of the configuration data -- I may try to dig it out and see if I could help you. Anyway, you should probably contact the chip's manufacturer. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Apr 24 13:53:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OKrNwJ018501 for ; Wed, 24 Apr 2002 13:53:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OKrIYt018499 for linux-mips-outgoing; Wed, 24 Apr 2002 13:53:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OKrCwJ018496 for ; Wed, 24 Apr 2002 13:53:12 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id NAA56084; Wed, 24 Apr 2002 13:53:39 -0700 (PDT) Date: Wed, 24 Apr 2002 13:53:39 -0700 From: Geoffrey Espin To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: Updates for RedHat 7.1/mips Message-ID: <20020424135339.A24558@idiom.com> References: <20020423155925.A8846@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020423155925.A8846@lucon.org>; from H . J . Lu on Tue, Apr 23, 2002 at 03:59:25PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Apr 23, 2002 at 03:59:25PM -0700, H . J . Lu wrote: > I updated glibc, python, gcc, gdb, rpm, openssl, binutils and toolchain at > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > Let know know if there are any problems. I've been using your old October toolchain-20011020-* quite happily. So foolishly, I upgraded to this new toolchain*rpm for mipsel on i386. When building a linux-mips.sourceforge.net -based kernel, if I include CONFIG_PCI in the configuration, I get: ... mipsel-linux-ld -G 0 -static -T arch/mips/ld.script.0x80002000 arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o arch/mips/ramdisk/ramdisk.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/pci/driver.o drivers/mtd/mtdlink.o \ net/network.o \ arch/mips/lib/lib.a /home/espin/linux/lib/lib.a arch/mips/korva/korva.a \ --end-group \ -o vmlinux drivers/char/char.o(.data+0x3990): undefined reference to `local symbols in discarded section .text.exit' make: *** [vmlinux] Error 1 If I don't include CONFIG_PCI the problem goes away. It also sometimes complained about symbols in drivers/net/net.o. I stumbled on: http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg00768.html which says that Alan Cox came up with enabling CONFIG_HOTPLUG as a workaround. Seems to work. :-/ Other useful suggestions found were to downgrade ones' binutils. :-) Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Wed Apr 24 14:01:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OL1dwJ018774 for ; Wed, 24 Apr 2002 14:01:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OL1dmO018773 for linux-mips-outgoing; Wed, 24 Apr 2002 14:01:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OL1ZwJ018767 for ; Wed, 24 Apr 2002 14:01:35 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020424210157.CNBQ91.rwcrmhc52.attbi.com@ocean.lucon.org>; Wed, 24 Apr 2002 21:01:57 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 61767125C7; Wed, 24 Apr 2002 14:01:56 -0700 (PDT) Date: Wed, 24 Apr 2002 14:01:56 -0700 From: "H . J . Lu" To: Geoffrey Espin Cc: linux-mips@oss.sgi.com Subject: Re: Updates for RedHat 7.1/mips Message-ID: <20020424140156.A28438@lucon.org> References: <20020423155925.A8846@lucon.org> <20020424135339.A24558@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020424135339.A24558@idiom.com>; from espin@idiom.com on Wed, Apr 24, 2002 at 01:53:39PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 01:53:39PM -0700, Geoffrey Espin wrote: > On Tue, Apr 23, 2002 at 03:59:25PM -0700, H . J . Lu wrote: > > I updated glibc, python, gcc, gdb, rpm, openssl, binutils and toolchain at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > Let know know if there are any problems. > > I've been using your old October toolchain-20011020-* quite happily. > So foolishly, I upgraded to this new toolchain*rpm for mipsel on i386. > > When building a linux-mips.sourceforge.net -based kernel, if I > include CONFIG_PCI in the configuration, I get: > > drivers/char/char.o(.data+0x3990): undefined reference to `local symbols in discarded section .text.exit' > make: *** [vmlinux] Error 1 > > That is a kernel bug which has been fixed in the newer kernel. From my binutils release note: Changes from binutils 2.11.92.0.10: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. H.J. From owner-linux-mips@oss.sgi.com Wed Apr 24 14:11:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OLBKwJ020340 for ; Wed, 24 Apr 2002 14:11:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OLBKlM020338 for linux-mips-outgoing; Wed, 24 Apr 2002 14:11:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OLBEwJ020335 for ; Wed, 24 Apr 2002 14:11:15 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id OAA68127; Wed, 24 Apr 2002 14:11:36 -0700 (PDT) Date: Wed, 24 Apr 2002 14:11:36 -0700 From: Geoffrey Espin To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: Updates for RedHat 7.1/mips Message-ID: <20020424141136.A63873@idiom.com> References: <20020423155925.A8846@lucon.org> <20020424135339.A24558@idiom.com> <20020424140156.A28438@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020424140156.A28438@lucon.org>; from H . J . Lu on Wed, Apr 24, 2002 at 02:01:56PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 02:01:56PM -0700, H . J . Lu wrote: > That is a kernel bug which has been fixed in the newer kernel. From my > binutils release note: > Changes from binutils 2.11.92.0.10: > 1. Update from binutils 2001 1121. > 2. Fix a linker symbol version bug for common symbols. > 3. Update handling relocations against the discarded sections. You may > need to apply the kernel patch enclosed here to your kernel source. If > you still see things like > drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded > section .text.exit' > in the final kernel link, that means you have compiled a driver into > the kernel which has a reference to the symbol in a discarded section. > Kernel 2.4.17 or above should work fine. > H.J. Sorry, I should have specified my kernel *IS* recently (Monday) from linux-mips.sourceforge.net. And it was previously sync'd to oss.sgi.com on Sunday, 21Apr02. VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 18 EXTRAVERSION = -mips Hence my befuddlement. I'll fix the cc list to l-m-k. Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Wed Apr 24 14:18:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OLIOwJ020569 for ; Wed, 24 Apr 2002 14:18:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OLIOrB020568 for linux-mips-outgoing; Wed, 24 Apr 2002 14:18:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OLIJwJ020552 for ; Wed, 24 Apr 2002 14:18:19 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020424211841.BEYH29911.rwcrmhc53.attbi.com@ocean.lucon.org>; Wed, 24 Apr 2002 21:18:41 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9FB98125C7; Wed, 24 Apr 2002 14:18:40 -0700 (PDT) Date: Wed, 24 Apr 2002 14:18:40 -0700 From: "H . J . Lu" To: Geoffrey Espin Cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: Updates for RedHat 7.1/mips Message-ID: <20020424141840.A28683@lucon.org> References: <20020423155925.A8846@lucon.org> <20020424135339.A24558@idiom.com> <20020424140156.A28438@lucon.org> <20020424141136.A63873@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020424141136.A63873@idiom.com>; from espin@idiom.com on Wed, Apr 24, 2002 at 02:11:36PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 02:11:36PM -0700, Geoffrey Espin wrote: > On Wed, Apr 24, 2002 at 02:01:56PM -0700, H . J . Lu wrote: > > That is a kernel bug which has been fixed in the newer kernel. From my > > binutils release note: > > Changes from binutils 2.11.92.0.10: > > 1. Update from binutils 2001 1121. > > 2. Fix a linker symbol version bug for common symbols. > > 3. Update handling relocations against the discarded sections. You may > > need to apply the kernel patch enclosed here to your kernel source. If > > you still see things like > > drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded > > section .text.exit' > > in the final kernel link, that means you have compiled a driver into > > the kernel which has a reference to the symbol in a discarded section. > > Kernel 2.4.17 or above should work fine. > > H.J. > > Sorry, I should have specified my kernel *IS* recently (Monday) > from linux-mips.sourceforge.net. And it was previously sync'd > to oss.sgi.com on Sunday, 21Apr02. > Your kernel still have references to symbols in discarded sections. Please read linux/include/linux/init.h: /* Functions marked as __devexit may be discarded at kernel link time, depending on config options. Newer versions of binutils detect references from retained sections to discarded sections and flag an error. Pointers to __devexit functions must use __devexit_p(function_name), the wrapper will insert either the function_name or NULL, depending on the config options. */ #if defined(MODULE) || defined(CONFIG_HOTPLUG) #define __devexit_p(x) x #else #define __devexit_p(x) NULL #endif H.J. From owner-linux-mips@oss.sgi.com Wed Apr 24 14:26:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OLQqwJ020939 for ; Wed, 24 Apr 2002 14:26:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OLQqrx020938 for linux-mips-outgoing; Wed, 24 Apr 2002 14:26:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OLQmwJ020934 for ; Wed, 24 Apr 2002 14:26:48 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 24 Apr 2002 14:26:48 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from dtatlaturcotte (dhcp-10-24-65-229.atlanta.broadcom.com [10.24.65.229]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id OAA01263; Wed, 24 Apr 2002 14:27:14 -0700 (PDT) Reply-to: turcotte@broadcom.com From: "Maurice Turcotte" To: linux-mips@oss.sgi.com cc: "Maurice Turcotte" Subject: Linux Shared Memory Issue Date: Wed, 24 Apr 2002 17:27:12 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-WSS-ID: 10D9FC9D671529-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Greetings: I am having a problem with Linux Kernel 2.4.5 on a mips. I have two processes using share memory for IPC. This same code works fine with Kernel 2.4.7 on a x86. The problem is that the second process reads old data out of the shared memory. The executive summary-> Process #1 writes "A" to shared memory at 0x2aac7210 Process #2 reads 0 from shared memory at address 0x2aaca210 Process #1 writes "B" to shared memory at 0x2aac7210 Process #2 read "A" from shared memory at address 0x2aaca210 Process #1 writes "C" to shared memory at 0x2aac7210 Process #2 read "B" from shared memory at address 0x2aaca210 It is interesting that the processes get different addresses associated with the same shmId. I assume this is because of some user-space mapping that is going on. I left out the semaphore diddling, but I believe that part of the code is correct because it works flawlessly on the 2.4.7 x86. Any tips on debugging this would be greatly appreciated. If this is not the proper forum for questions like this, please point me in the right direction. Thanks, mturc From owner-linux-mips@oss.sgi.com Wed Apr 24 15:18:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OMIrwJ022879 for ; Wed, 24 Apr 2002 15:18:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OMIq60022878 for linux-mips-outgoing; Wed, 24 Apr 2002 15:18:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OMIbwJ022867 for ; Wed, 24 Apr 2002 15:18:37 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08674 for ; Wed, 24 Apr 2002 15:18:45 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA23171; Wed, 24 Apr 2002 15:02:37 -0700 Message-ID: <3CC72BA3.90600@mvista.com> Date: Wed, 24 Apr 2002 15:03:15 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: turcotte@broadcom.com CC: linux-mips@oss.sgi.com, Maurice Turcotte Subject: Re: Linux Shared Memory Issue References: Content-Type: multipart/mixed; boundary="------------050506030600070802060007" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------050506030600070802060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Looks like the infamous cache aliasing problem. Steve Longerbeam had a patch which may help. Please try it and let me know the results. Thanks. Jun Maurice Turcotte wrote: > Greetings: > > I am having a problem with Linux Kernel 2.4.5 on a mips. > > I have two processes using share memory for IPC. This same > code works fine with Kernel 2.4.7 on a x86. The problem is > that the second process reads old data out of the shared > memory. > > The executive summary-> > > Process #1 writes "A" to shared memory at 0x2aac7210 > Process #2 reads 0 from shared memory at address 0x2aaca210 > Process #1 writes "B" to shared memory at 0x2aac7210 > Process #2 read "A" from shared memory at address 0x2aaca210 > Process #1 writes "C" to shared memory at 0x2aac7210 > Process #2 read "B" from shared memory at address 0x2aaca210 > > It is interesting that the processes get different addresses > associated with the same shmId. I assume this is because of > some user-space mapping that is going on. > > I left out the semaphore diddling, but I believe that part of > the code is correct because it works flawlessly on the 2.4.7 x86. > > Any tips on debugging this would be greatly appreciated. If this > is not the proper forum for questions like this, please point me > in the right direction. > > Thanks, > > mturc > > --------------050506030600070802060007 Content-Type: text/plain; name="cache-alias.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cache-alias.patch" diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/arch/mips/kernel/syscall.c linux-2.4.17/arch/mips/kernel/syscall.c --- linux-2.4.17.orig/arch/mips/kernel/syscall.c Sun Sep 16 16:29:10 2001 +++ linux-2.4.17/arch/mips/kernel/syscall.c Thu Jan 24 15:02:18 2002 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -53,6 +54,50 @@ out: return res; } + +/* + * To avoid cache aliases, we map the shard page with same color. + */ +#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 *vma; + + 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 (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { + /* At this point: (!vma || addr < vma->vm_end). */ + if (TASK_SIZE - len < addr) + return -ENOMEM; + if (!vma || addr + len <= vma->vm_start) + return addr; + addr = vma->vm_end; + if (flags & MAP_SHARED) + addr = COLOUR_ALIGN(addr); + } +} + /* common code for old and new mmaps */ static inline long diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/include/asm-mips/pgtable.h linux-2.4.17/include/asm-mips/pgtable.h --- linux-2.4.17.orig/include/asm-mips/pgtable.h Thu Jan 24 14:35:06 2002 +++ linux-2.4.17/include/asm-mips/pgtable.h Thu Jan 24 14:56:52 2002 @@ -64,6 +64,9 @@ #define flush_icache_all() do { } while(0) #endif +/* We provide our own get_unmapped_area to avoid cache aliasing */ +#define HAVE_ARCH_UNMAPPED_AREA + /* * - add_wired_entry() add a fixed TLB entry, and move wired register */ --------------050506030600070802060007-- From owner-linux-mips@oss.sgi.com Wed Apr 24 15:22:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OMM6wJ022991 for ; Wed, 24 Apr 2002 15:22:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OMM6EW022990 for linux-mips-outgoing; Wed, 24 Apr 2002 15:22:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OMM5wJ022986 for ; Wed, 24 Apr 2002 15:22:05 -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 g3OMMLNg028624; Wed, 24 Apr 2002 15:22:21 -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 g3OMMKN1028618; Wed, 24 Apr 2002 15:22:21 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 24 Apr 2002 15:22:20 -0700 (PDT) From: James Simmons To: Zhang Fuxin cc: "linux-mips@oss.sgi.com" Subject: Re: vga initialization In-Reply-To: <200204240111.g3O1BowJ006668@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I find most code is already there in scitech's x86emu-0.8. > in one day it is adapted into linux kernel. Yipes!!! It has been discussed before and no x86 emulator will go into the kernel. Now what I really love to ses is a way to trace threw the bios code so we can write video drivers that don't need the BIOS to work. From owner-linux-mips@oss.sgi.com Wed Apr 24 15:39:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OMdQwJ023344 for ; Wed, 24 Apr 2002 15:39:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OMdQWd023343 for linux-mips-outgoing; Wed, 24 Apr 2002 15:39:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OMdNwJ023330 for ; Wed, 24 Apr 2002 15:39:23 -0700 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g3OMdSj21195; Wed, 24 Apr 2002 18:39:28 -0400 Date: Wed, 24 Apr 2002 18:39:28 -0400 From: Jim Paris To: James Simmons Cc: Zhang Fuxin , "linux-mips@oss.sgi.com" Subject: Re: vga initialization Message-ID: <20020424183928.A21149@neurosis.mit.edu> References: <200204240111.g3O1BowJ006668@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: ; from jsimmons@transvirtual.com on Wed, Apr 24, 2002 at 03:22:20PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Yipes!!! It has been discussed before and no x86 emulator will go into the > kernel. Now what I really love to ses is a way to trace threw the bios > code so we can write video drivers that don't need the BIOS to work. If you mean "trace through" as in automatically, well, that's an x86 emulator. :) If you mean manually, there's a problem, because every card is going to be entirely different. -jim From owner-linux-mips@oss.sgi.com Wed Apr 24 16:12:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ONCZwJ001433 for ; Wed, 24 Apr 2002 16:12:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ONCZJj001432 for linux-mips-outgoing; Wed, 24 Apr 2002 16:12:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ONCYwJ001429 for ; Wed, 24 Apr 2002 16:12:34 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA25456 for ; Wed, 24 Apr 2002 16:12:19 -0700 Subject: reiserfs From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 24 Apr 2002 16:13:06 -0700 Message-Id: <1019689986.8208.104.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone been able to run reiserfs on big endian systems? Pete From owner-linux-mips@oss.sgi.com Wed Apr 24 16:28:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ONSZwJ001656 for ; Wed, 24 Apr 2002 16:28:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ONSZUZ001655 for linux-mips-outgoing; Wed, 24 Apr 2002 16:28:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ONSWwJ001652 for ; Wed, 24 Apr 2002 16:28:32 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id QAA46078; Wed, 24 Apr 2002 16:28:58 -0700 (PDT) Date: Wed, 24 Apr 2002 16:28:58 -0700 From: Geoffrey Espin To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: Updates for RedHat 7.1/mips Message-ID: <20020424162858.A44115@idiom.com> References: <20020423155925.A8846@lucon.org> <20020424135339.A24558@idiom.com> <20020424140156.A28438@lucon.org> <20020424141136.A63873@idiom.com> <20020424141840.A28683@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020424141840.A28683@lucon.org>; from H . J . Lu on Wed, Apr 24, 2002 at 02:18:40PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 02:18:40PM -0700, H . J . Lu wrote: > > Sorry, I should have specified my kernel *IS* recently (Monday) > > from linux-mips.sourceforge.net. And it was previously sync'd > > to oss.sgi.com on Sunday, 21Apr02. > Your kernel still have references to symbols in discarded sections. Please > read linux/include/linux/init.h: Woops, I wasn't working in my latest OSS/SF tree, as I thought. All compiles and runs well. Sorry for the noise. Thanks for the new tools, H.J.. Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Wed Apr 24 16:38:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ONcRwJ001782 for ; Wed, 24 Apr 2002 16:38:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ONcRrJ001781 for linux-mips-outgoing; Wed, 24 Apr 2002 16:38:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ONcDwJ001778 for ; Wed, 24 Apr 2002 16:38:14 -0700 Received: (qmail 16664 invoked from network); 24 Apr 2002 23:38:39 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 24 Apr 2002 23:38:39 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 30E6D3000BA; Thu, 25 Apr 2002 09:38:37 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 183CF94; Thu, 25 Apr 2002 09:38:37 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Geoffrey Espin Cc: linux-mips@oss.sgi.com Subject: Re: Updates for RedHat 7.1/mips In-reply-to: Your message of "Wed, 24 Apr 2002 13:53:39 MST." <20020424135339.A24558@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Apr 2002 09:38:31 +1000 Message-ID: <30555.1019691511@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 24 Apr 2002 13:53:39 -0700, Geoffrey Espin wrote: >drivers/char/char.o(.data+0x3990): undefined reference to `local symbols in discarded section .text.exit' Assuming that your kernel is up to date, it is likely to be a MIPS only char driver that has not been converted to __devexit_p. Run this script to find the offending driver and correct the source code. #!/usr/bin/perl -w # # reference_discarded.pl (C) Keith Owens 2001 # # List dangling references to vmlinux discarded sections. use strict; die($0 . " takes no arguments\n") if($#ARGV >= 0); my %object; my $object; my $line; my $ignore; $| = 1; printf("Finding objects, "); open(OBJDUMP_LIST, "find . -name '*.o' | xargs objdump -h |") || die "getting objdump list failed"; while (defined($line = )) { chomp($line); if ($line =~ /:\s+file format/) { ($object = $line) =~ s/:.*//; $object{$object}->{'module'} = 0; $object{$object}->{'size'} = 0; $object{$object}->{'off'} = 0; } if ($line =~ /^\s*\d+\s+\.modinfo\s+/) { $object{$object}->{'module'} = 1; } if ($line =~ /^\s*\d+\s+\.comment\s+/) { ($object{$object}->{'size'}, $object{$object}->{'off'}) = (split(' ', $line))[2,5]; } } close(OBJDUMP_LIST); printf("%d objects, ", scalar keys(%object)); $ignore = 0; foreach $object (keys(%object)) { if ($object{$object}->{'module'}) { ++$ignore; delete($object{$object}); } } printf("ignoring %d module(s)\n", $ignore); # Ignore conglomerate objects, they have been built from multiple objects and we # only care about the individual objects. If an object has more than one GCC: # string in the comment section then it is conglomerate. This does not filter # out conglomerates that consist of exactly one object, can't be helped. printf("Finding conglomerates, "); $ignore = 0; foreach $object (keys(%object)) { if (exists($object{$object}->{'off'})) { my ($off, $size, $comment, $l); $off = hex($object{$object}->{'off'}); $size = hex($object{$object}->{'size'}); open(OBJECT, "<$object") || die "cannot read $object"; seek(OBJECT, $off, 0) || die "seek to $off in $object failed"; $l = read(OBJECT, $comment, $size); die "read $size bytes from $object .comment failed" if ($l != $size); close(OBJECT); if ($comment =~ /GCC\:.*GCC\:/m) { ++$ignore; delete($object{$object}); } } } printf("ignoring %d conglomerate(s)\n", $ignore); printf("Scanning objects\n"); foreach $object (keys(%object)) { my $from; open(OBJDUMP, "objdump -r $object|") || die "cannot objdump -r $object"; while (defined($line = )) { chomp($line); if ($line =~ /RELOCATION RECORDS FOR /) { ($from = $line) =~ s/.*\[([^]]*).*/$1/; } if (($line =~ /\.text\.exit$/ || $line =~ /\.data\.exit$/ || $line =~ /\.exitcall\.exit$/) && ($from !~ /\.text\.exit$/ && $from !~ /\.data\.exit$/ && $from !~ /\.exitcall\.exit$/)) { printf("Error: %s %s refers to %s\n", $object, $from, $line); } } close(OBJDUMP); } printf("Done\n"); From owner-linux-mips@oss.sgi.com Wed Apr 24 22:25:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P5P3wJ006333 for ; Wed, 24 Apr 2002 22:25:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P5P3mG006332 for linux-mips-outgoing; Wed, 24 Apr 2002 22:25:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P5P0wJ006327 for ; Wed, 24 Apr 2002 22:25:00 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [128.167.58.27]) with SMTP; 25 Apr 2002 05:25:29 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E6EAEB471; Thu, 25 Apr 2002 14:25:26 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id OAA91327; Thu, 25 Apr 2002 14:25:26 +0900 (JST) Date: Thu, 25 Apr 2002 14:25:18 +0900 (JST) Message-Id: <20020425.142518.85417141.nemoto@toshiba-tops.co.jp> To: jsun@mvista.com Cc: turcotte@broadcom.com, linux-mips@oss.sgi.com, mturc@broadcom.com Subject: Re: Linux Shared Memory Issue From: Atsushi Nemoto In-Reply-To: <3CC72BA3.90600@mvista.com> References: <3CC72BA3.90600@mvista.com> 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 X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Wed, 24 Apr 2002 15:03:15 -0700, Jun Sun said: jsun> Looks like the infamous cache aliasing problem. Steve jsun> Longerbeam had a patch which may help. Please try it and let me jsun> know the results. jsun> +#define COLOUR_ALIGN(addr) (((addr)+SHMLBA-1)&~(SHMLBA-1)) Recent sparc64's COLOUR_ALIGN macro have pgoff argument like this. We should do it same way for MIPS? #define COLOUR_ALIGN(addr,pgoff) \ ((((addr)+SHMLBA-1)&~(SHMLBA-1)) + \ (((pgoff)<; Thu, 25 Apr 2002 00:51:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P7p2CT008319 for linux-mips-outgoing; Thu, 25 Apr 2002 00:51:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P7p0wJ008316 for ; Thu, 25 Apr 2002 00:51:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3P7pSo26838; Thu, 25 Apr 2002 00:51:28 -0700 Date: Thu, 25 Apr 2002 00:51:28 -0700 From: Ralf Baechle To: Pete Popov Cc: linux-mips Subject: Re: reiserfs Message-ID: <20020425005128.A26673@dea.linux-mips.net> References: <1019689986.8208.104.camel@zeus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019689986.8208.104.camel@zeus>; from ppopov@mvista.com on Wed, Apr 24, 2002 at 04:13:06PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 04:13:06PM -0700, Pete Popov wrote: > Has anyone been able to run reiserfs on big endian systems? I've seen reports of people running Reiserfs on MIPS but I don't know what endianess. Ralf From owner-linux-mips@oss.sgi.com Thu Apr 25 01:11:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P8B2wJ011803 for ; Thu, 25 Apr 2002 01:11:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P8B24H011801 for linux-mips-outgoing; Thu, 25 Apr 2002 01:11:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P8AuwJ011796 for ; Thu, 25 Apr 2002 01:10:57 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA16878; Thu, 25 Apr 2002 10:10:54 +0200 (MET DST) Date: Thu, 25 Apr 2002 10:10:53 +0200 (MEST) From: Geert Uytterhoeven To: Jim Paris cc: James Simmons , Zhang Fuxin , "linux-mips@oss.sgi.com" Subject: Re: vga initialization In-Reply-To: <20020424183928.A21149@neurosis.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 24 Apr 2002, Jim Paris wrote: > > Yipes!!! It has been discussed before and no x86 emulator will go into the > > kernel. Now what I really love to ses is a way to trace threw the bios > > code so we can write video drivers that don't need the BIOS to work. > > If you mean "trace through" as in automatically, well, that's an x86 > emulator. :) If you mean manually, there's a problem, because every > card is going to be entirely different. I think he means a BIOS `compiler' instead of an `interpreter' or `emulator'. I.e. something that generates C code which can be compiled and used to initialize the card later, without caring about the BIOS. Some caveats: - BIOS code frequently uses the timers found in a typical PC-architecture box - The BIOS code copyright holder may consider this as a `translation' of his work, i.e. copyright infringement. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Apr 25 01:11:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P8BdwJ011861 for ; Thu, 25 Apr 2002 01:11:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P8BdBW011860 for linux-mips-outgoing; Thu, 25 Apr 2002 01:11:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P8BWwJ011847; Thu, 25 Apr 2002 01:11:33 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA16985; Thu, 25 Apr 2002 10:11:55 +0200 (MET DST) Date: Thu, 25 Apr 2002 10:11:55 +0200 (MEST) From: Geert Uytterhoeven To: Ralf Baechle cc: Pete Popov , linux-mips Subject: Re: reiserfs In-Reply-To: <20020425005128.A26673@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 25 Apr 2002, Ralf Baechle wrote: > On Wed, Apr 24, 2002 at 04:13:06PM -0700, Pete Popov wrote: > > Has anyone been able to run reiserfs on big endian systems? > > I've seen reports of people running Reiserfs on MIPS but I don't know what > endianess. Some people run it on PowerPC, which is big endian as far as Linux is concerned. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Apr 25 01:31:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P8VHwJ012128 for ; Thu, 25 Apr 2002 01:31:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P8VHRD012127 for linux-mips-outgoing; Thu, 25 Apr 2002 01:31:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P8VEwJ012123 for ; Thu, 25 Apr 2002 01:31:14 -0700 Received: from galadriel.physik.uni-konstanz.de (galadriel.physik.uni-konstanz.de [134.34.144.79]) by gandalf.physik.uni-konstanz.de (Postfix) with ESMTP id 581C78D35; Thu, 25 Apr 2002 10:31:42 +0200 (CEST) Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 170efG-0006S0-00; Thu, 25 Apr 2002 10:31:42 +0200 Date: Thu, 25 Apr 2002 10:31:42 +0200 From: Guido Guenther To: Dani Eichhorn , linux-mips@oss.sgi.com Subject: Re: Challenge S crashes configuring the base system Message-ID: <20020425103142.A24749@galadriel.physik.uni-konstanz.de> Mail-Followup-To: Dani Eichhorn , linux-mips@oss.sgi.com References: <20020421131051.A12044@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: <20020421131051.A12044@gandalf.physik.uni-konstanz.de>; from agx@sigxcpu.org on Sun, Apr 21, 2002 at 01:10:51PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Apr 21, 2002 at 01:10:51PM +0200, Guido Guenther wrote: [..snip..] > It doesn't really "crash". The porblem is that the installer doesn't > correctly detect the serial console and therefore displays everything on > tty1 not ttyS0. Boot with /bin/bash as init (use "boot init=/bin/bash" I just doublechecked this on an Indy. The installer detects the serial console with either console=ttyS0 as kernel command line argument or "console=d1" as prom var correctly. Can you try another installation and save /var/log/messages as well as /target/etc/inittab before you reboot from the installer? -- Guido From owner-linux-mips@oss.sgi.com Thu Apr 25 05:30:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PCU6wJ024755 for ; Thu, 25 Apr 2002 05:30:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PCU6AD024754 for linux-mips-outgoing; Thu, 25 Apr 2002 05:30:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PCTswJ024735 for ; Thu, 25 Apr 2002 05:29:54 -0700 Message-Id: <200204251229.g3PCTswJ024735@oss.sgi.com> Received: (qmail 5861 invoked from network); 25 Apr 2002 12:27:01 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 25 Apr 2002 12:27:01 -0000 Date: Thu, 25 Apr 2002 20:29:54 +0800 From: "Zhang Fuxin" To: "GIRISH V. GULAWANI" CC: "linux-mips@oss.sgi.com" Subject: Re: Re: Re: vga initialization X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3PCTtwJ024742 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, I met the situation you described before. x86emu0.6 will give such result on many cards. I believe it's because their bioses access vga memory between address [0xa0000-0xc0000],while in x86emu0.6, the mem_read/mem_write doesn't distinguish they from bios code section. I guess that your code: 1. copy bios code to PHYSICAL MEMORY 0xc0000 2. emulation code,and redirect accesses to [0xa0000-0xfffff] to PHYSICAL memory 0xa0000-0xfffff 3. code ok,vga memory access failed. Because pci addr !=physical addr in your platform x86emu-0.8 solve this. Another caution please,the original code may define #define char u8 and your compiler might treat 'char' as unsigned!At least my sde-gcc from algor seems to do this.it will lead to failure of 'JB' emulation. ======= 2002-04-25 03:14:00 ÄúÔÚÀ´ÐÅÖÐдµÀ£º======= >thanks for replying. this card PT80 seems a SPECIAL >one. perhaps i am the only user for it on non-x86 >platform. > >> 1. what you do >i borrowed an old MIPS board from my company. from >home i'm learning MIPS as well as linux. > >> 2. output (dmesg,or captured from your serial >> console). >i've NOT used your particular code. somebody gave me a >PMON code which has SciTech's bios emulation code. >i've integrated this code as part of bootloader. i >dont see any dmesg or something. > >> 3. your platform,esp. whether it has pc legacy >> hardware support. >the board has a custom PCI bridge with 2 PCI slots. >the PCI slots are 3.3v. i'm trying to port linux 2.4.3 >on this board. so far i'm able to build kernel with >serial console. in order to support x-windows i need >VGA monitor. hence i purchased one AOpen's PT80 card >which supports PCI 3.3v. i was trying to emulate the >BIOS. since it has only x86 bios. > >in my case, the emulation as such completes. with no >errors at any time. the monitor switches from power >down to power on mode & also appears there AOpen's >splash window. the one comes initially with AOpen's >icon & some text explaining the card configuration. >HOWEVER this whole screen is filled with colorful >vertical lines. that's it & i'm stucked. > >since i dont have any tools like PCI bus analyzer or >something. so i have no clue to proceed further. i >have checked the card & also the monitor. it works >well on a PC running both windows-me & redhat linux >7.1. > >one thing i checked however is, an user command build >on linux dumps the register access. the register >access & the values written there or read from are >ditto. exact match. > >could you make out anything from this?? any clues?? > >many thanks & best regards, >girish. > ><> > >__________________________________________________ >Do You Yahoo!? >Yahoo! Games - play chess, backgammon, pool and more >http://games.yahoo.com/ = = = = = = = = = = = = = = = = = = = = ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhang Fuxin ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡fxzhang@ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-04-25 From owner-linux-mips@oss.sgi.com Thu Apr 25 08:37:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PFbwwJ003125 for ; Thu, 25 Apr 2002 08:37:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PFbwkj003124 for linux-mips-outgoing; Thu, 25 Apr 2002 08:37:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PFbqwJ003119 for ; Thu, 25 Apr 2002 08:37:53 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8CE68845; Thu, 25 Apr 2002 17:38:20 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D0D5B37049; Thu, 25 Apr 2002 17:36:22 +0200 (CEST) Date: Thu, 25 Apr 2002 17:36:22 +0200 From: Florian Lohoff To: Maurice Turcotte Cc: linux-mips@oss.sgi.com, Maurice Turcotte Subject: Re: Linux Shared Memory Issue Message-ID: <20020425153622.GA10683@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2002 at 05:27:12PM -0400, Maurice Turcotte wrote: > Greetings: >=20 > I am having a problem with Linux Kernel 2.4.5 on a mips. >=20 > I have two processes using share memory for IPC. This same > code works fine with Kernel 2.4.7 on a x86. The problem is=20 > that the second process reads old data out of the shared > memory. This also shows with x-windows on mips with shared pixmaps. We see this for a long time and did not come to a solution. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8yCJ2Uaz2rXW+gJcRAoLEAJ9smB0DEpS1dzI7Cdc31YlX8QawSQCgx4XU 764m4qJCeS3KSF5VUUXYRvs= =LW93 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-linux-mips@oss.sgi.com Thu Apr 25 09:12:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PGCuwJ016004 for ; Thu, 25 Apr 2002 09:12:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PGCu6w016003 for linux-mips-outgoing; Thu, 25 Apr 2002 09:12:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PGClwJ016000; Thu, 25 Apr 2002 09:12:47 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08570; Thu, 25 Apr 2002 09:12:57 -0700 (PDT) mail_from (ppopov@mvista.com) Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA10850; Thu, 25 Apr 2002 09:07:22 -0700 Subject: Re: reiserfs From: Pete Popov To: Geert Uytterhoeven Cc: Ralf Baechle , linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 25 Apr 2002 09:08:20 -0700 Message-Id: <1019750900.16901.143.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 01:11, Geert Uytterhoeven wrote: > On Thu, 25 Apr 2002, Ralf Baechle wrote: > > On Wed, Apr 24, 2002 at 04:13:06PM -0700, Pete Popov wrote: > > > Has anyone been able to run reiserfs on big endian systems? > > > > I've seen reports of people running Reiserfs on MIPS but I don't know what > > endianess. > > Some people run it on PowerPC, which is big endian as far as Linux is > concerned. Right, but mips be hangs hard. I'll have to investigate ... MIPS LE is fine. Pete From owner-linux-mips@oss.sgi.com Thu Apr 25 09:53:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PGrNwJ017300 for ; Thu, 25 Apr 2002 09:53:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PGrMtM017299 for linux-mips-outgoing; Thu, 25 Apr 2002 09:53:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PGr4wJ017288; Thu, 25 Apr 2002 09:53:04 -0700 Received: from csh.rit.edu (anna.csh.rit.edu [129.21.61.85]) by mcp.csh.rit.edu (Postfix) with ESMTP id 1768AE5; Thu, 25 Apr 2002 12:18:55 -0400 (EDT) Message-ID: <3CC82C2F.7010104@csh.rit.edu> Date: Thu, 25 Apr 2002 12:17:51 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geert Uytterhoeven Cc: Ralf Baechle , Pete Popov , linux-mips Subject: Re: reiserfs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Geert Uytterhoeven wrote: >On Thu, 25 Apr 2002, Ralf Baechle wrote: > >>On Wed, Apr 24, 2002 at 04:13:06PM -0700, Pete Popov wrote: >> >>>Has anyone been able to run reiserfs on big endian systems? >>> >>I've seen reports of people running Reiserfs on MIPS but I don't know what >>endianess. >> > >Some people run it on PowerPC, which is big endian as far as Linux is >concerned. > >Gr{oetje,eeting}s, > > Geert > >-- >Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > >In personal conversations with technical people, I call myself a hacker. But >when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > Jeff Mahoney, probably the lead big-endian reiserfs developer, has run reiserfs on (that I've seen with my own eyes) Sun and Apple (G3 or later). There is no reason his code would not similarly work on big-endian mips machines. -George From owner-linux-mips@oss.sgi.com Thu Apr 25 12:32:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJWlwJ021980 for ; Thu, 25 Apr 2002 12:32:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJWl6Z021979 for linux-mips-outgoing; Thu, 25 Apr 2002 12:32:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJWhwJ021975 for ; Thu, 25 Apr 2002 12:32:43 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05022 for ; Thu, 25 Apr 2002 12:32:57 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA17551; Thu, 25 Apr 2002 11:45:30 -0700 Message-ID: <3CC84EEC.8060100@mvista.com> Date: Thu, 25 Apr 2002 11:46:04 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Atsushi Nemoto CC: turcotte@broadcom.com, linux-mips@oss.sgi.com, mturc@broadcom.com Subject: Re: Linux Shared Memory Issue References: <3CC72BA3.90600@mvista.com> <20020425.142518.85417141.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Atsushi Nemoto wrote: >>>>>>On Wed, 24 Apr 2002 15:03:15 -0700, Jun Sun said: >>>>>> > jsun> Looks like the infamous cache aliasing problem. Steve > jsun> Longerbeam had a patch which may help. Please try it and let me > jsun> know the results. > > jsun> +#define COLOUR_ALIGN(addr) (((addr)+SHMLBA-1)&~(SHMLBA-1)) > > Recent sparc64's COLOUR_ALIGN macro have pgoff argument like this. > We should do it same way for MIPS? > > #define COLOUR_ALIGN(addr,pgoff) \ > ((((addr)+SHMLBA-1)&~(SHMLBA-1)) + \ > (((pgoff)< What is the purpose of adding the pgoff part? To avoid mapping all shared regions into the beginning of cache? Jun From owner-linux-mips@oss.sgi.com Thu Apr 25 20:10:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q3AwwJ000718 for ; Thu, 25 Apr 2002 20:10:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q3AwN3000717 for linux-mips-outgoing; Thu, 25 Apr 2002 20:10:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3Q3ArwJ000713 for ; Thu, 25 Apr 2002 20:10:54 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [128.167.58.27]) with SMTP; 26 Apr 2002 03:11:26 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id C667EB474; Fri, 26 Apr 2002 12:11:15 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA94452; Fri, 26 Apr 2002 12:11:15 +0900 (JST) Date: Fri, 26 Apr 2002 12:11:07 +0900 (JST) Message-Id: <20020426.121107.126571593.nemoto@toshiba-tops.co.jp> To: jsun@mvista.com Cc: turcotte@broadcom.com, linux-mips@oss.sgi.com, mturc@broadcom.com Subject: Re: Linux Shared Memory Issue From: Atsushi Nemoto In-Reply-To: <3CC84EEC.8060100@mvista.com> References: <3CC72BA3.90600@mvista.com> <20020425.142518.85417141.nemoto@toshiba-tops.co.jp> <3CC84EEC.8060100@mvista.com> 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 X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Thu, 25 Apr 2002 11:46:04 -0700, Jun Sun said: >> #define COLOUR_ALIGN(addr,pgoff) \ ((((addr)+SHMLBA-1)&~(SHMLBA-1)) >> + \ (((pgoff)< What is the purpose of adding the pgoff part? To avoid mapping jsun> all shared regions into the beginning of cache? I suppose so. For example, mmapping offset 0x1000 of /dev/kmem will return 0xXXXX0000 address if we ignore pgoff. This can cause aliasing problem with KSEG0 address (0x80001000). Adding pgoff, mmap will return 0xXXXX1000. In case of IPC shm, pgoff is always 0 so this change does not effect. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Fri Apr 26 08:20:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QFKmwJ011689 for ; Fri, 26 Apr 2002 08:20:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QFKmO4011688 for linux-mips-outgoing; Fri, 26 Apr 2002 08:20:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QFKiwJ011683 for ; Fri, 26 Apr 2002 08:20:45 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA19935 for ; Fri, 26 Apr 2002 17:21:12 +0200 (MET DST) Date: Fri, 26 Apr 2002 17:21:12 +0200 (MEST) From: Geert Uytterhoeven To: Linux/MIPS Development Subject: asm type names Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, include/asm-mips*/unaligned.h uses different terminology for the same sizes, sometimes even in the same file, making things a bit confusing: - double vs. quad - word vs. long - halfword vs. word Which set of terms is preferred, so we can increase consistency? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Fri Apr 26 11:33:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QIXIwJ020827 for ; Fri, 26 Apr 2002 11:33:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QIXIkb020826 for linux-mips-outgoing; Fri, 26 Apr 2002 11:33:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QIXCwJ020820; Fri, 26 Apr 2002 11:33:12 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA18441; Fri, 26 Apr 2002 11:32:53 -0700 Subject: Re: reiserfs From: Pete Popov To: Geert Uytterhoeven Cc: Ralf Baechle , linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 26 Apr 2002 11:34:09 -0700 Message-Id: <1019846051.13973.24.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 01:11, Geert Uytterhoeven wrote: > On Thu, 25 Apr 2002, Ralf Baechle wrote: > > On Wed, Apr 24, 2002 at 04:13:06PM -0700, Pete Popov wrote: > > > Has anyone been able to run reiserfs on big endian systems? > > > > I've seen reports of people running Reiserfs on MIPS but I don't know what > > endianess. > > Some people run it on PowerPC, which is big endian as far as Linux is > concerned. FYI, it turned out to be a toolchain bug (2.95.3). Versions 2.96 and 3.x work just fine. Pete From owner-linux-mips@oss.sgi.com Fri Apr 26 14:04:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QL4VwJ006864 for ; Fri, 26 Apr 2002 14:04:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QL4Ui2006863 for linux-mips-outgoing; Fri, 26 Apr 2002 14:04:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QL4RwJ006860 for ; Fri, 26 Apr 2002 14:04:27 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g3QL51A05381; Fri, 26 Apr 2002 14:05:01 -0700 Date: Fri, 26 Apr 2002 14:05:01 -0700 From: Ralf Baechle To: Geert Uytterhoeven Cc: Linux/MIPS Development Subject: Re: asm type names Message-ID: <20020426140501.B5107@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from geert@linux-m68k.org on Fri, Apr 26, 2002 at 05:21:12PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Apr 26, 2002 at 05:21:12PM +0200, Geert Uytterhoeven wrote: > include/asm-mips*/unaligned.h uses different terminology for the same sizes, > sometimes even in the same file, making things a bit confusing: > - double vs. quad > - word vs. long > - halfword vs. word > > Which set of terms is preferred, so we can increase consistency? The MIPS terminology is: - 2 bytes - halfword - 4 bytes - word - 8 bytes - doubleword - 16 bytes - quadword Unfortunately part of the industry have a different idea of what the size of a word should be, so for example on i386 the use of the terms is: - 2 bytes word - 4 bytes doubleword - 8 bytes quadword At times it's hard to avoid confusion; in general I therefore prefer to avoid these terms or their abreviations but there are places like the old assembler implementation of inw() where both are used next to each other ... Ralf From owner-linux-mips@oss.sgi.com Sat Apr 27 13:00:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RK0XwJ026439 for ; Sat, 27 Apr 2002 13:00:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RK0WJO026438 for linux-mips-outgoing; Sat, 27 Apr 2002 13:00:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3RK0SwJ026435 for ; Sat, 27 Apr 2002 13:00:30 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 171Yfh-0000gA-00; Sat, 27 Apr 2002 21:19:53 +0100 Subject: Re: reiserfs To: ppopov@mvista.com (Pete Popov) Date: Sat, 27 Apr 2002 21:19:53 +0100 (BST) Cc: linux-mips@oss.sgi.com (linux-mips) In-Reply-To: <1019689986.8208.104.camel@zeus> from "Pete Popov" at Apr 24, 2002 04:13:06 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Has anyone been able to run reiserfs on big endian systems? Should work on newer 2.4 kernels From owner-linux-mips@oss.sgi.com Sat Apr 27 13:06:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RK6HwJ026650 for ; Sat, 27 Apr 2002 13:06:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RK6H1I026649 for linux-mips-outgoing; Sat, 27 Apr 2002 13:06:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3RK6FwJ026644 for ; Sat, 27 Apr 2002 13:06:15 -0700 Received: from localhost ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GV800I24T7JZH@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Sat, 27 Apr 2002 13:06:55 -0700 (PDT) Date: Sat, 27 Apr 2002 13:05:53 -0700 From: Pete Popov Subject: Re: reiserfs In-reply-to: To: Alan Cox Cc: linux-mips Message-id: <1019937954.1260.22.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.3 Content-type: text/plain Content-transfer-encoding: 7bit References: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 2002-04-27 at 13:19, Alan Cox wrote: > > Has anyone been able to run reiserfs on big endian systems? > > Should work on newer 2.4 kernels Yes, it does. I sent an email yesterday explaining what the problem was. The 2.95.3 toolchain is miscompiling the cpu_to_le16 and le16_to_cpu functions. The problem appears to be fixed in 2.96 and 3.x so reiserfs is looking good for both, LE and BE mips systems. Pete From owner-linux-mips@oss.sgi.com Sat Apr 27 14:45:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RLjqwJ028787 for ; Sat, 27 Apr 2002 14:45:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RLjq5R028786 for linux-mips-outgoing; Sat, 27 Apr 2002 14:45:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3RLjUwJ028770; Sat, 27 Apr 2002 14:45:31 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 0E23283B; Sat, 27 Apr 2002 23:46:10 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5FCB537116; Sat, 27 Apr 2002 23:45:05 +0200 (CEST) Date: Sat, 27 Apr 2002 23:45:05 +0200 From: Florian Lohoff To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com, agx@sigxcpu.org Subject: XSHM/shared-pixmap fix Was: Linux Shared Memory Issue Message-ID: <20020427214505.GA23046@paradigm.rfc822.org> References: <3CC72BA3.90600@mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <3CC72BA3.90600@mvista.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --ZoaI/ZTpAVc4A5k6 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ralf, *, On Wed, Apr 24, 2002 at 03:03:15PM -0700, Jun Sun wrote: > Looks like the infamous cache aliasing problem. Steve Longerbeam had a= =20 > patch which may help. Please try it and let me know the results. > Maurice Turcotte wrote: > >I am having a problem with Linux Kernel 2.4.5 on a mips. > > > >I have two processes using share memory for IPC. This same > >code works fine with Kernel 2.4.7 on a x86. The problem is=20 > >that the second process reads old data out of the shared > >memory. > > > >The executive summary-> > > > >Process #1 writes "A" to shared memory at 0x2aac7210 > >Process #2 reads 0 from shared memory at address 0x2aaca210 > >Process #1 writes "B" to shared memory at 0x2aac7210 > >Process #2 read "A" from shared memory at address 0x2aaca210 > >Process #1 writes "C" to shared memory at 0x2aac7210 > >Process #2 read "B" from shared memory at address 0x2aaca210 > > I today tried the patch in conjunction with XFree86 and XSHM on an Indy R5000/150. Usually all gtk shared-pixmaps get destroyed and written lines in it. With this patch all these garbage disappears. As long as there a no serious issues against this patch i would vote for inclused. It applies against todays cvs with only little offsets and gave me no problems. It definitly solves some serious issues with shm. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cache-alias.patch" Content-Transfer-Encoding: quoted-printable diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/arch/mips/kernel/sysc= all.c linux-2.4.17/arch/mips/kernel/syscall.c --- linux-2.4.17.orig/arch/mips/kernel/syscall.c Sun Sep 16 16:29:10 2001 +++ linux-2.4.17/arch/mips/kernel/syscall.c Thu Jan 24 15:02:18 2002 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -53,6 +54,50 @@ out: return res; } + +/* + * To avoid cache aliases, we map the shard page with same color. + */ +#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 *vma; + + 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 =3D TASK_UNMAPPED_BASE; + + if (flags & MAP_SHARED) + addr =3D COLOUR_ALIGN(addr); + else + addr =3D PAGE_ALIGN(addr); + + for (vma =3D find_vma(current->mm, addr); ; vma =3D vma->vm_next) { + /* At this point: (!vma || addr < vma->vm_end). */ + if (TASK_SIZE - len < addr) + return -ENOMEM; + if (!vma || addr + len <=3D vma->vm_start) + return addr; + addr =3D vma->vm_end; + if (flags & MAP_SHARED) + addr =3D COLOUR_ALIGN(addr); + } +} + =20 /* common code for old and new mmaps */ static inline long diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/include/asm-mips/pgta= ble.h linux-2.4.17/include/asm-mips/pgtable.h --- linux-2.4.17.orig/include/asm-mips/pgtable.h Thu Jan 24 14:35:06 2002 +++ linux-2.4.17/include/asm-mips/pgtable.h Thu Jan 24 14:56:52 2002 @@ -64,6 +64,9 @@ #define flush_icache_all() do { } while(0) #endif =20 +/* We provide our own get_unmapped_area to avoid cache aliasing */ +#define HAVE_ARCH_UNMAPPED_AREA + /* * - add_wired_entry() add a fixed TLB entry, and move wired register */ --jI8keyz6grp/JLjh-- --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8yxvhUaz2rXW+gJcRAq/hAJsHLbUHoUcxT/lOB2M7YHsyFqSXQgCgyj4K omj5qc6Ax6IwdmgtD9ibH/4= =5COE -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From owner-linux-mips@oss.sgi.com Mon Apr 29 10:36:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3THaXwJ002432 for ; Mon, 29 Apr 2002 10:36:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3THaXUD002431 for linux-mips-outgoing; Mon, 29 Apr 2002 10:36:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3THaMwJ002428 for ; Mon, 29 Apr 2002 10:36:22 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA01549; Mon, 29 Apr 2002 10:35:29 -0700 Message-ID: <3CCD847A.8050905@mvista.com> Date: Mon, 29 Apr 2002 10:35:54 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete Popov CC: Alan Cox , linux-mips Subject: Re: reiserfs References: <1019937954.1260.22.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="------------060504060505070508050507" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------060504060505070508050507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pete Popov wrote: > On Sat, 2002-04-27 at 13:19, Alan Cox wrote: > >>>Has anyone been able to run reiserfs on big endian systems? >>> >>Should work on newer 2.4 kernels >> > > Yes, it does. I sent an email yesterday explaining what the problem > was. The 2.95.3 toolchain is miscompiling the cpu_to_le16 and > le16_to_cpu functions. The problem appears to be fixed in 2.96 and 3.x > so reiserfs is looking good for both, LE and BE mips systems. > Here is the test case that reveals the toolchain problem. Brave souls are welcome to look into it. Apparently the bug only happens on be tools with 2.95.x. Jun --------------060504060505070508050507 Content-Type: text/plain; name="gcc-2.95-le16-to-cpu.bug.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-2.95-le16-to-cpu.bug.c" #if 0 compile instructions: /opt/hardhat/devkit/mips/fp_be/bin/mips_fp_be-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -g -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe -c -o try.o try.c #endif typedef unsigned short __u16; typedef unsigned __u32; #define ___swab16_new(x) \ ({ \ __u32 __x = (x); \ __x = ((__u32)( \ ((__u32)(__x) << 8) | \ (((__u32)(__x) & (__u16)0xff00U) >> 8) )); \ (__u16)(__x & 0xffff); \ }) #define ___swab16(x) \ ({ \ __u16 __x = (x); \ ((__u16)( \ (((__u16)(__x) & (__u16)0x00ffU) << 8) | \ (((__u16)(__x) & (__u16)0xff00U) >> 8) )); \ }) # define __swab16(x) \ (__builtin_constant_p((__u16)(x)) ? \ ___swab16((x)) : \ __fswab16((x))) #ifndef __arch__swab16 # define __arch__swab16(x) ({ __u16 __tmp = (x) ; ___swab16(__tmp); }) #endif static __inline__ __const__ __u16 __fswab16(__u16 x) { return __arch__swab16(x); } #define __le16_to_cpu(x) __swab16((x)) #define le16_to_cpu __le16_to_cpu extern __u16 x; extern __u16 y; void foo_old(void) { if (le16_to_cpu(x) > y) y = x; } --------------060504060505070508050507-- From owner-linux-mips@oss.sgi.com Mon Apr 29 11:52:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TIq9wJ007543 for ; Mon, 29 Apr 2002 11:52:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TIq8Ra007542 for linux-mips-outgoing; Mon, 29 Apr 2002 11:52:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TIq7wJ007539 for ; Mon, 29 Apr 2002 11:52:07 -0700 Received: (qmail 328 invoked by uid 104); 29 Apr 2002 18:52:50 -0000 Received: from Manoj_Ekbote@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4199. . Clean. Processed in 0.413694 secs); 29 Apr 2002 18:52:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 29 Apr 2002 18:52:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3TIqkp19588 for ; Mon, 29 Apr 2002 11:52:46 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 11:52:51 -0700 Message-ID: <71690137A786F7428FF9670D47CB95ED18AD02@SJE4EXM01> From: Manoj Ekbote To: "Linux (E-mail)" Subject: sash for MIPS Date: Mon, 29 Apr 2002 11:52:48 -0700 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 Hi, Is there a port of sash(shell) on MIPS? TIA Manoj From owner-linux-mips@oss.sgi.com Mon Apr 29 12:26:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TJQawJ008011 for ; Mon, 29 Apr 2002 12:26:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TJQabL008010 for linux-mips-outgoing; Mon, 29 Apr 2002 12:26:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from luonnotar.infodrom.org (postfix@luonnotar.infodrom.org [195.124.48.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TJQXwJ008007 for ; Mon, 29 Apr 2002 12:26:33 -0700 Received: by luonnotar.infodrom.org (Postfix, from userid 10) id 3715A366AA6; Mon, 29 Apr 2002 21:27:12 +0200 (CEST) Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2) from infodrom.org by finlandia.Infodrom.North.DE via smail from stdin id for linux-mips@oss.sgi.com; Mon, 29 Apr 2002 21:17:53 +0200 (CEST) Date: Mon, 29 Apr 2002 21:17:53 +0200 From: Martin Schulze To: Manoj Ekbote Cc: "Linux (E-mail)" Subject: Re: sash for MIPS Message-ID: <20020429191752.GK10703@finlandia.infodrom.north.de> References: <71690137A786F7428FF9670D47CB95ED18AD02@SJE4EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <71690137A786F7428FF9670D47CB95ED18AD02@SJE4EXM01> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Manoj Ekbote wrote: > Hi, > > Is there a port of sash(shell) on MIPS? http://ftp.debian.org/debian/pool/main/s/sash/sash_3.4-8.2_mips.deb Regards, Joey -- Experience is something you don't get until just after you need it. From owner-linux-mips@oss.sgi.com Mon Apr 29 14:39:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TLdfwJ019662 for ; Mon, 29 Apr 2002 14:39:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TLdfxm019661 for linux-mips-outgoing; Mon, 29 Apr 2002 14:39:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TLdawJ019656 for ; Mon, 29 Apr 2002 14:39:37 -0700 Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]) by ux3.sp.cs.cmu.edu id aa19953; 29 Apr 2002 15:29 EDT Subject: Re: sash for MIPS From: Justin Carlson To: Manoj Ekbote Cc: "Linux (E-mail)" In-Reply-To: <71690137A786F7428FF9670D47CB95ED18AD02@SJE4EXM01> References: <71690137A786F7428FF9670D47CB95ED18AD02@SJE4EXM01> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1ktbTQliteq2MI9MPaRE" X-Mailer: Ximian Evolution 1.0.4 Date: 29 Apr 2002 15:29:18 -0400 Message-Id: <1020108558.29417.1.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-1ktbTQliteq2MI9MPaRE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-04-29 at 14:52, Manoj Ekbote wrote: > Hi, >=20 > Is there a port of sash(shell) on MIPS? >=20 A bit more than a year ago I got it working on a MIPS board with very little effort. Don't have it anymore, though. Have you tried just grabbing the source and compiling it? -Justin --=-1ktbTQliteq2MI9MPaRE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8zZ8O47Lg4cGgb74RAqudAJ49S+Zt3U6o28mKxiykY79UD5Z9ngCgi1IL 2pWmTQLLWzRR68kg8QjGfFw= =qPxN -----END PGP SIGNATURE----- --=-1ktbTQliteq2MI9MPaRE-- From owner-linux-mips@oss.sgi.com Mon Apr 29 18:04:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U14KwJ026442 for ; Mon, 29 Apr 2002 18:04:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U14KNl026441 for linux-mips-outgoing; Mon, 29 Apr 2002 18:04:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U14FwJ026438 for ; Mon, 29 Apr 2002 18:04:16 -0700 Received: from mail3.sony.co.jp (mail3.sony.co.jp [43.0.1.203]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g3U14wL67525; Tue, 30 Apr 2002 10:04:58 +0900 (JST) Received: from mail3.sony.co.jp (localhost [127.0.0.1]) by mail3.sony.co.jp (R8/Sony) with ESMTP id g3U14vt03520; Tue, 30 Apr 2002 10:04:57 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail3.sony.co.jp (R8/Sony) with ESMTP id g3U14vL03516; Tue, 30 Apr 2002 10:04:57 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id KAA01180; Tue, 30 Apr 2002 10:04:51 +0900 (JST) Received: from mach0.sm.sony.co.jp (mach0.sm.sony.co.jp [43.2.226.27]) by imail.sm.sony.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA15200; Tue, 30 Apr 2002 10:04:56 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g3U14tS20456; Tue, 30 Apr 2002 10:04:55 +0900 (JST) Date: Tue, 30 Apr 2002 10:04:55 +0900 (JST) Message-Id: <20020430.100455.68542723.machida@sm.sony.co.jp> To: jsun@mvista.com Cc: ppopov@mvista.com, alan@lxorguk.ukuu.org.uk, linux-mips@oss.sgi.com Subject: Re: reiserfs From: Hiroyuki Machida In-Reply-To: <3CCD847A.8050905@mvista.com> References: <1019937954.1260.22.camel@localhost.localdomain> <3CCD847A.8050905@mvista.com> X-Mailer: Mew version 2.1.51 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, all From: Jun Sun Subject: Re: reiserfs Date: Mon, 29 Apr 2002 10:35:54 -0700 > Here is the test case that reveals the toolchain problem. Brave souls are > welcome to look into it. > > Apparently the bug only happens on be tools with 2.95.x. > > Jun I think this bug has been fixed with http://gcc.gnu.org/ml/gcc-patches/2000-02/msg00489.html for gcc-3.x. You can apply the patch included that mail to gcc-2.95.x, easily. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Tue Apr 30 03:15:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UAFhwJ003513 for ; Tue, 30 Apr 2002 03:15:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UAFh6U003512 for linux-mips-outgoing; Tue, 30 Apr 2002 03:15:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UAFUwJ003506 for ; Tue, 30 Apr 2002 03:15:32 -0700 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g3UAGH211139; Tue, 30 Apr 2002 11:16:18 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15566.28397.770794.272735@gladsmuir.algor.co.uk> Date: Tue, 30 Apr 2002 11:16:13 +0100 To: Johannes Stezenbach , Eric Christopher cc: gcc@gcc.gnu.org, linux-mips@oss.sgi.com Cc: dom@algor.co.uk, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] In-Reply-To: <3CBFEAA9.9070707@algor.co.uk> References: <3CBFEAA9.9070707@algor.co.uk> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 17th April (yes, I know that's a long time) Johannes wrote: > I quickly discovered that mips16 support in gcc-2.95 is broken. > ... > gcc-3.1 does seem to generate correct code for my tiny > test programs, but lacks mips16 support routines in > libgcc.a when configured for target mips-linux. > ... > Dominic Sweetman from Algorithmics mentioned in a posting > to the linux-mips list (http://oss.sgi.com/mips/mail.html) > that they have numerous patches against an old gcc version. > Has someone had a look at the Algorithmics gcc, or even > attempted to incorporate thier patches into gcc-3.x? I really owe you guys a reply, so I'll go for a cross-post. Eric replied: > mips16 support was broken for quite some time. Recently a lot of bug > fixes have gone into making it quite usable, though fairly unstable... Sounds fair. > I have not looked at the Algorithmics code because I don't have > copyright on it... We do publish our sources on our web server. Not only are they GPL but we have a copyright assignment to the FSF in place (which I know was sent to Jim Wilson of Cygnus, albeit in 1993...) We're operating from a baseline which was a Cygnus/RedHat "2.96" release made to MIPS Technologies in late 2000. A snapshot from a contract which had run into some kind of dissension, it had some new MIPS16 support but it was very buggy (the regular 32-bit MIPS code generator, too). It has some nice features, though, like the "Haifa" scheduler and the DFA extensions to machine descriptions for superscalar CPUs. It's true we have not contributed patches lately. We don't really have the resouces; our success rate used to be very low, and since we're not working around the developing 3.x sources the prospects seem even dimmer. We're working (with funding from MIPS Technologies) on building a toolchain which: o Can build Linux kernel, libraries and applications alike; o Is substantially more efficient than other GCC versions when producing MIPS application ("MIPS/ABI", PIC) code; o Will produce ugly-but-correct PIC code for MIPS16 functions, so MIPS16 can be tested in a standard Linux environment; o Operates to a known and documented ABI (even the forgotten details, like gprof...) (The modesty of those ambitions should be measured against the reality of today's Linux/MIPS...) We should be done in 6 weeks or so. Our intention is to provide this port as both source and binary RPMs for free download, and to encourage its widespread use. We appreciate it would be great if this work was converged into a robust 3.x compiler (though the change in C++ code conventions means, I think, that it will be a long time before such a compiler can be used by a majority of substantial embedded projects). We're canvassing anyone we can think of with the funds or influence to help make it happen. It would be even more valuable if we could ensure that MIPS becomes a "first-class" architecture for the evolving GCC - but the latter surely is a big commitment for the core GCC group. It's a pity that the different priorities of various funders and developers mean that there is no baseline toolkit for Linux/MIPS, so that such resources as are available are frequently used to re-invent the wheel. Anyone got any ideas how to make it better? -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Apr 30 11:03:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UI3XwJ025548 for ; Tue, 30 Apr 2002 11:03:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UI3Xeh025547 for linux-mips-outgoing; Tue, 30 Apr 2002 11:03:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UI3QwJ025544 for ; Tue, 30 Apr 2002 11:03:27 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA32743; Tue, 30 Apr 2002 11:03:03 -0700 Message-ID: <3CCEDC94.B668649E@mvista.com> Date: Tue, 30 Apr 2002 12:04:04 -0600 From: Michael Pruznick Reply-To: michael_pruznick@mvista.com Organization: MontaVista X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@oss.sgi.com Subject: Re: ps2 keyboard -- no key down events 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: > > On Wed, 24 Apr 2002, Michael Pruznick wrote: > > > I'm working on this mips board with a smsc 90e66 south bridge and > > fdc37m812 super io. I'm using the standard pc_keyb.c driver. I only > > see keyboard interrupts and KBD_STAT_OBF set in response to "key up" > > events. I never see them in response to "key down" events. Thus, the > > shell running on the vga console never gets my input (since it is the > > "key down" events that pass the character typed to the shell). > > > > At this point, I'm thinking that the standard driver needs some mods > > to work with the super io's ps2 controller. The smsc doc only covers > > programming the plug and play registers and doesn't give any info about > > programming the ps2 controller. > > An 8042-compatible microcontroller (actually the firmware it runs) may > need to be programmed to a PC/AT-compatible mode. On an i386 it is > typically done by the BIOS. Try dumping configuration data from your chip > and compare it with what is set up in an i386 system. You can dump 32 > bytes of configuration data with the 0x20 command of the 8042 (5 low-order > bits of a command byte specify an address). Writing can be performed > using the 0x60 command (the same semantics). > > Some data is available in the Ralf Brown's interrupt list (look for > "inter60*.zip" files on a SimTel DOS collection's mirror). I have an old > Intel hardcopy document somewhere that describes to some extent the > IBM-defined locations of the configuration data -- I may try to dig it out > and see if I could help you. Anyway, you should probably contact the > chip's manufacturer. Thanks, that seams to be the issue or at least part of it. I dumped offset 0x20-0x3f on several systems. All gave different results. Some helped, some did not. In the case of the ones that helped, all the keys I tried (alpha,num,symbol) worked, until I pressed a shift, control, or alt key, in which case the keyboard was stuck sending the shifted value of all keys. I sent a message to the chip manufacturer, waiting for their response. In all cases, the mouse doesn't work and enabling the mouse via "gpm -t ps2 -m /dev/mouse" or "od -tx1 -w1 /dev/mouse" causes the keyboard to stop sending scancodes (on key up or key down). -- Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085 direct voice/fax:970-266-1108, main office:408-328-9200