From ralf@oss.sgi.com Fri Dec 1 03:07:24 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id DAA18791; Fri, 1 Dec 2000 03:07:24 +0100 (MET) Received-Date: Fri, 1 Dec 2000 03:07:24 +0100 (MET) Received: from u-3-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.3) via SMTP by guadalquivir.fnet.fr, id smtpd018789; Fri Dec 1 03:07:14 2000 Received: (ralf@lappi) by bacchus.dhis.org id ; Fri, 1 Dec 2000 03:06:19 +0100 Date: Fri, 1 Dec 2000 03:06:19 +0100 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: binutils upgrade Message-ID: <20001201030619.A7444@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Content-Length: 345 Lines: 7 Binutils were buggy handling a cases involving empty object files. I've uploaded fixed binutils 2.8.1 cross-linker packages to oss.sgi.com; I'll upload fixed binutils 2.9.5 binaries (mips64 only) later. The worarounds for this bug have been removed from the CVS archive that is updating is required for building a current 2.4 kernel. Ralf From ralf@oss.sgi.com Sat Dec 2 05:03:37 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA01422; Sat, 2 Dec 2000 05:03:37 +0100 (MET) Received-Date: Sat, 2 Dec 2000 05:03:37 +0100 (MET) Received: from u-183-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.183) via SMTP by guadalquivir.fnet.fr, id smtpd001420; Sat Dec 2 05:03:28 2000 Received: (ralf@lappi) by bacchus.dhis.org id ; Sat, 2 Dec 2000 05:03:06 +0100 Date: Sat, 2 Dec 2000 05:03:06 +0100 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Support for smaller glibc Message-ID: <20001202050306.A12319@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Content-Length: 1631 Lines: 45 For the information of the embedded community. Ralf ----- Forwarded message from "H . J . Lu" ----- Date: Fri, 1 Dec 2000 09:12:35 -0800 From: "H . J . Lu" To: Ralf Baechle Cc: sglibc@external-lists.valinux.com Subject: Re: Support for smaller glibc On Fri, Dec 01, 2000 at 02:14:14PM +0100, Ralf Baechle wrote: > On Tue, Nov 28, 2000 at 04:24:29PM -0800, H . J . Lu wrote: > > > The current glibc 2.2 has many features. But some of them are not > > needed in some cases. I am wondering if there is an interest to > > make those features configurabled at the build time. The ones I am > > thinging now are intl, iconv, iconvdata, locale, localedata, wcsmbs, > > wctype and wide char IO. They will be enabled by default. But you > > can disable them at the build time. It will make glibc much smaller. > > Any comments? > > The MIPS community is shifting more and more into the embedded area; one > of the increasing pains is glibc's increasing size which makes various > people continue to maintain glibc 2.0, the oldest and smallest libc for > MIPS. So your suggestion is very interesting indeed. > > I just have acknowledge Uli's concerns in this thread; they need to be > solved. But forking a smaller libc of standard glibc is nothing but the > St. Florian's principle ... > Ulrich is refusing to do anything with it. Do you have any suggestions? I will do my best to do it right. But I am afraid I cannot do it alone. BTW, please discuss it on sglibc@external-lists.valinux.com. -- H.J. Lu (hjl@valinux.com) ----- End forwarded message ----- Ralf From alan@lxorguk.ukuu.org.uk Sat Dec 2 14:06:34 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA05778; Sat, 2 Dec 2000 14:06:34 +0100 (MET) Received-Date: Sat, 2 Dec 2000 14:06:34 +0100 (MET) Received: from lightning.swansea.linux.org.uk(194.168.151.1), claiming to be "the-village.bc.nu" via SMTP by guadalquivir.fnet.fr, id smtpd005765; Sat Dec 2 14:06:25 2000 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 142CN5-0001Wk-00; Sat, 2 Dec 2000 13:06:31 +0000 Subject: Re: Support for smaller glibc To: ralf@oss.sgi.com (Ralf Baechle) Date: Sat, 2 Dec 2000 13:06:28 +0000 (GMT) Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr In-Reply-To: <20001202050306.A12319@bacchus.dhis.org> from "Ralf Baechle" at Dec 02, 2000 05:03:06 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Content-Length: 403 Lines: 10 > > solved. But forking a smaller libc of standard glibc is nothing but the > > St. Florian's principle ... > > Ulrich is refusing to do anything with it. Do you have any suggestions? > I will do my best to do it right. But I am afraid I cannot do it alone. Ulrich is right. Start from a library that is intended to be modular and embedded. Folks are already looking at using newlib for this. Alan From alhaz@xmission.com Sat Dec 2 17:14:03 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA07530; Sat, 2 Dec 2000 17:14:03 +0100 (MET) Received-Date: Sat, 2 Dec 2000 17:14:03 +0100 (MET) Received: from mail.xmission.com(198.60.22.22) via SMTP by guadalquivir.fnet.fr, id smtpd007528; Sat Dec 2 17:13:55 2000 Received: from xmission.xmission.com ([198.60.22.20]) by mail.xmission.com with esmtp (Exim 3.12 #1) id 142FII-0003TX-00; Sat, 02 Dec 2000 09:13:46 -0700 Received: from alhaz by xmission.xmission.com with local (Exim 2.12 #1) id 142FIH-00017w-00; Sat, 2 Dec 2000 09:13:45 -0700 Subject: Re: Support for smaller glibc To: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Sat, 2 Dec 2000 09:13:45 -0700 (MST) Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr In-Reply-To: from "Alan Cox" at Dec 02, 2000 01:06:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Eric Jorgensen Content-Length: 983 Lines: 23 > > > > solved. But forking a smaller libc of standard glibc is nothing but the > > > St. Florian's principle ... > > > > Ulrich is refusing to do anything with it. Do you have any suggestions? > > I will do my best to do it right. But I am afraid I cannot do it alone. > > Ulrich is right. Start from a library that is intended to be modular and > embedded. Folks are already looking at using newlib for this. There are a few other methods. Lineo for instance has a utility called Lipo which goes through all the binaries on a system and then strips out all the library code that's unused, usually resulting in a substantial reduction in the size of libc6. Lipo is a proprietary app tho, currently only available supporting ia32 and ppc archetectures as part of the Embedix SDK. There's also uClibc, and i've heard some talk of using bsd's libc, which i understand is also smaller. These may require modification to the sourcecode of your apps to work properly. - Eric From alan@lxorguk.ukuu.org.uk Sat Dec 2 17:31:53 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA08089; Sat, 2 Dec 2000 17:31:53 +0100 (MET) Received-Date: Sat, 2 Dec 2000 17:31:53 +0100 (MET) Received: from lightning.swansea.linux.org.uk(194.168.151.1), claiming to be "the-village.bc.nu" via SMTP by guadalquivir.fnet.fr, id smtpd008087; Sat Dec 2 17:31:50 2000 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 142FZs-0001he-00; Sat, 2 Dec 2000 16:31:56 +0000 Subject: Re: Support for smaller glibc To: alhaz@xmission.com (Eric Jorgensen) Date: Sat, 2 Dec 2000 16:31:53 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-mips@oss.sgi.com, linux-mips@fnet.fr In-Reply-To: from "Eric Jorgensen" at Dec 02, 2000 09:13:45 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Content-Length: 914 Lines: 20 > There are a few other methods. Lineo for instance has a utility > called Lipo which goes through all the binaries on a system and then Try it on a real application and with glibc 2.2 at least its far from large. glibc isnt designed to be modular. > substantial reduction in the size of libc6. Lipo is a proprietary > app tho, currently only available supporting ia32 and ppc archetectures as > part of the Embedix SDK. Lipo is an afternoons work to do with libbfd so thats a path that is easy to pursue. ( > There's also uClibc, and i've heard some talk of using bsd's libc, > which i understand is also smaller. These may require modification to the > sourcecode of your apps to work properly. BSD libc is smaller, uClibc is pretty ropey and not very modular. Both the BSD libc and newlib are modular. Newlib for mips32 without mips16 support including FPU emulation with every option on is about 350K From ralf@oss.sgi.com Sun Dec 3 13:22:06 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA18935; Sun, 3 Dec 2000 13:22:06 +0100 (MET) Received-Date: Sun, 3 Dec 2000 13:22:06 +0100 (MET) Received: from u-162-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.162) via SMTP by guadalquivir.fnet.fr, id smtpd018932; Sun Dec 3 13:21:59 2000 Received: (ralf@lappi) by bacchus.dhis.org id ; Sun, 3 Dec 2000 13:21:33 +0100 Date: Sun, 3 Dec 2000 13:21:33 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Ulrich Drepper , "H . J . Lu" , Nick Clifton , binutils@sources.redhat.com, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: Update readelf to know about the new ELF constants Message-ID: <20001203132132.B21272@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Nov 29, 2000 at 01:10:58PM +0100 X-Accept-Language: de,en,fr Content-Length: 818 Lines: 18 On Wed, Nov 29, 2000 at 01:10:58PM +0100, Maciej W. Rozycki wrote: > Well, I would only add the name should probably be EM_MIPS_R3_LE (and > ditto the comment). We might actually use it for mipsel-linux especially > as the ABI explicitly states EM_MIPS is for big endian machines but I'm > not sure it's worth bothering as the endianness is specified > independently. The entire ABI only covers big endianess, so you can't directly make conclusions for little endian boxes based. So whatever a little endian system ``ABI compliant'' system does it's only based on an effort to stick as closely as possible to the ABI. > I believe all software involved should handle it well -- I recall Linux, > glibc, binutils, modutils all handle both tags fine. It's just BFD that > does not generate EM_MIPS_R3_LE. Ralf From kaos@ocs.com.au Sat Dec 16 12:01:57 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA12578; Sat, 16 Dec 2000 12:01:57 +0100 (MET) Received-Date: Sat, 16 Dec 2000 12:01:57 +0100 (MET) Received: from ppp0.ocs.com.au(203.34.97.3), claiming to be "mail.ocs.com.au" via SMTP by guadalquivir.fnet.fr, id smtpd012576; Sat Dec 16 12:01:52 2000 Received: (qmail 5351 invoked from network); 16 Dec 2000 11:01:29 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Dec 2000 11:01:29 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-mips@fnet.fr Subject: Dead files in 2.4.0-test13-pre2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Dec 2000 22:01:29 +1100 Message-ID: <15004.976964489@ocs3.ocs-net> Content-Length: 71 Lines: 1 AFAICT, nothing refers to arch/mips64/sgi-ip27/ip27-rtc.c. Dead file? From K.H.C.vanHouten@kpn.com Sun Dec 17 19:06:46 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA24647; Sun, 17 Dec 2000 19:06:46 +0100 (MET) Received-Date: Sun, 17 Dec 2000 19:06:46 +0100 (MET) Received: from hermes.research.kpn.com(139.63.192.8) via SMTP by guadalquivir.fnet.fr, id smtpd024645; Sun Dec 17 19:06:35 2000 Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JXTL7SASYY00170B@research.kpn.com> for linux-mips@fnet.fr; Sun, 17 Dec 2000 19:06:32 +0100 Received: from kpn.com (aodi2.research.kpn.com [139.63.167.2]) by l04.research.kpn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y9TYGPKK; Sun, 17 Dec 2000 19:06:25 +0100 Date: Sun, 17 Dec 2000 19:06:18 +0100 From: Karel van Houten Subject: Kernel patch to make DECStation serial devfs aware. Sender: karel@research.kpn.com To: MIPS Linux list , "MIPS Linux list (FNET)" Message-id: <3A3D009A.CC605186@kpn.com> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.10 i686) Content-type: multipart/mixed; boundary="------------B556931F0E1CCED6BE2E1F56" X-Accept-Language: en Content-Length: 4356 Lines: 149 This is a multi-part message in MIME format. --------------B556931F0E1CCED6BE2E1F56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I've attached a small patch to the DECStation serial drivers (zs.c and dz.c) in order to make them devfs aware. Would you please test this patch, and report any resulting problems? -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. --------------B556931F0E1CCED6BE2E1F56 Content-Type: text/plain; charset=us-ascii; name="dec-devfs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dec-devfs.patch" --- drivers/tc/zs.c.orig Sun Dec 17 15:59:21 2000 +++ drivers/tc/zs.c Sun Dec 17 12:30:07 2000 @@ -18,6 +18,7 @@ */ #include +#include #include #include #include @@ -1720,7 +1721,11 @@ memset(&serial_driver, 0, sizeof(struct tty_driver)); serial_driver.magic = TTY_DRIVER_MAGIC; +#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS)) + serial_driver.name = "tts/%d"; +#else serial_driver.name = "ttyS"; +#endif serial_driver.major = TTY_MAJOR; serial_driver.minor_start = 64; serial_driver.num = zs_channels_found; @@ -1730,7 +1735,7 @@ serial_driver.init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL; - serial_driver.flags = TTY_DRIVER_REAL_RAW; + serial_driver.flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_NO_DEVFS; serial_driver.refcount = &serial_refcount; serial_driver.table = serial_table; serial_driver.termios = serial_termios; @@ -1758,7 +1763,11 @@ * major number and the subtype code. */ callout_driver = serial_driver; +#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS)) + callout_driver.name = "cua/%d"; +#else callout_driver.name = "cua"; +#endif callout_driver.major = TTYAUX_MAJOR; callout_driver.subtype = SERIAL_TYPE_CALLOUT; @@ -1820,6 +1829,11 @@ printk("ttyS%02d at 0x%08x (irq = %d)", info->line, info->port, info->irq); printk(" is a Z85C30 SCC\n"); + tty_register_devfs(&serial_driver, 0, + serial_driver.minor_start + info->line); + tty_register_devfs(&callout_driver, 0, + callout_driver.minor_start + info->line); + } restore_flags(flags); --- drivers/char/dz.c.orig Sun Dec 17 15:59:36 2000 +++ drivers/char/dz.c Sun Dec 17 16:59:57 2000 @@ -21,9 +21,9 @@ #define DEBUG_DZ 1 +#include #ifdef MODULE #include -#include #else #define MOD_INC_USE_COUNT #define MOD_DEC_USE_COUNT @@ -1290,7 +1290,7 @@ int __init dz_init(void) { - int i, flags; + int i, flags, tmp; struct dz_serial *info; /* Setup base handler, and timer table. */ @@ -1300,7 +1300,11 @@ memset(&serial_driver, 0, sizeof(struct tty_driver)); serial_driver.magic = TTY_DRIVER_MAGIC; +#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS)) serial_driver.name = "ttyS"; +#else + serial_driver.name = "tts/%d"; +#endif serial_driver.major = TTY_MAJOR; serial_driver.minor_start = 64; serial_driver.num = DZ_NB_PORT; @@ -1309,7 +1313,7 @@ serial_driver.init_termios = tty_std_termios; serial_driver.init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL; - serial_driver.flags = TTY_DRIVER_REAL_RAW; + serial_driver.flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_NO_DEVFS; serial_driver.refcount = &serial_refcount; serial_driver.table = serial_table; serial_driver.termios = serial_termios; @@ -1336,7 +1340,11 @@ * major number and the subtype code. */ callout_driver = serial_driver; +#if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS)) callout_driver.name = "cua"; +#else + callout_driver.name = "cua/%d"; +#endif callout_driver.major = TTYAUX_MAJOR; callout_driver.subtype = SERIAL_TYPE_CALLOUT; @@ -1380,6 +1388,11 @@ return 0; printk("ttyS%02d at 0x%08x (irq = %d)\n", info->line, info->port, SERIAL); + + tty_register_devfs(&serial_driver, 0, + serial_driver.minor_start + info->line); + tty_register_devfs(&callout_driver, 0, + callout_driver.minor_start + info->line); } /* reset the chip */ --------------B556931F0E1CCED6BE2E1F56-- From jadb@redhat.com Tue Dec 26 17:52:19 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA01514; Tue, 26 Dec 2000 17:52:19 +0100 (MET) Received-Date: Tue, 26 Dec 2000 17:52:19 +0100 (MET) Received: from blackdog.wirespeed.com(208.170.106.25) via SMTP by guadalquivir.fnet.fr, id smtpd001512; Tue Dec 26 17:52:11 2000 Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id KAA20412; Tue, 26 Dec 2000 10:45:03 -0600 Message-ID: <3A48CC1D.9000204@redhat.com> Date: Tue, 26 Dec 2000 10:49:33 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: the list , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: sysmips call and glibc atomic set References: <3A46F4D8.9060605@redhat.com> <20001226140204.D894@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2483 Lines: 91 Ralf, firstly, thank you for the answers :) Ralf Baechle wrote: > > Ok, but since the kernel disables MIPS III you're limited to MIPS II anyway ... > This makes sense... > > > Read the ISA manual; sc will fail if the LL-bit in c0_status is cleared > which will be cleared when the interrupt returns using the eret instruction. > I tried to find a MIPSIII manual from mips.com but all I could find was mips32 and mips64 (which are not the same as MIPSII/MIPSIII/MIPSIV). > > > Not having swap doesn't mean you're safe. Think of any kind of previously > unmapped page. > Is there a reason why it doesn't just force that page to be mapped first? > >> QUESTION 2) Wouldn't it be better to pass back the initial value of >> *arg1 in *arg3 and return zero or negative error code? > > > The semantics of this syscall were previously defined by Risc/OS and later > on continued to be used by IRIX. > > >> case MIPS_ATOMIC_SET: { >> /* This is broken in case of page faults and SMP ... >> Risc/OS faults after maximum 20 tries with EAGAIN. */ >> unsigned int tmp; >> >> p = (int *) arg1; >> errno = verify_area(VERIFY_WRITE, p, sizeof(*p)); >> if (errno) >> return errno; >> errno = 0; >> save_and_cli(flags); >> errno |= __get_user(tmp, p); >> errno |= __put_user(arg2, p); >> restore_flags(flags); >> >> if (errno) >> return tmp; >> >> return tmp; /* This is broken ... */ >> } >> >> QUESTION 3) I notice that the code for this particular case of sysmips >> has changed recently. The old code looked more like the 'll/sc' version >> of glibc above. I would think that the 'll/sc' code would be better on >> SMP systems. > > > Don't think about SMP without ll/sc. There's algorithems available for > that but their complexity leaves them a unpractical, theoretical construct. > > >> Is there a good reason why this reverted? > Looking at 2.4.0-test5 I see the ll/sc code, but -test12 doesn't use it. I was just curious at why it was taken out. > > Above code will break if the old content of memory has bit 31 set or you take > pagefaults. The latter problem is a problem even on UP - think multi- > threading. > > Finally, post such things to one of the MIPS-related mailing lists. If > you're unlucky nobody of the MIPS'ers might see your posting on l-k. > > Ralf -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 From macro@ds2.pg.gda.pl Thu Dec 28 13:11:04 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA16818; Thu, 28 Dec 2000 13:11:04 +0100 (MET) Received-Date: Thu, 28 Dec 2000 13:11:04 +0100 (MET) Received: from delta.ds2.pg.gda.pl(153.19.144.1) via SMTP by guadalquivir.fnet.fr, id smtpd016816; Thu Dec 28 13:10:58 2000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA22306; Thu, 28 Dec 2000 13:07:01 +0100 (MET) Date: Thu, 28 Dec 2000 13:06:59 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Joe deBlaquiere , the list , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: sysmips call and glibc atomic set In-Reply-To: <20001226140204.D894@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1082 Lines: 27 On Tue, 26 Dec 2000, Ralf Baechle wrote: > The semantics of this syscall were previously defined by Risc/OS and later > on continued to be used by IRIX. Ralf, could you please provide me a copy of a man page for the call? I don't have access to either of the systems and a search of the Net returned nothing. > Don't think about SMP without ll/sc. There's algorithems available for > that but their complexity leaves them a unpractical, theoretical construct. For SMP there is a simple kernel solution available. It suitable for a syscall or a ll/sc emulation. There is no easy userland-only solution AFAIK. > Above code will break if the old content of memory has bit 31 set or you take > pagefaults. The latter problem is a problem even on UP - think multi- > threading. If the code is written carefully you don't ever get a pagefault that would break consistency. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Dec 28 13:29:54 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA17344; Thu, 28 Dec 2000 13:29:54 +0100 (MET) Received-Date: Thu, 28 Dec 2000 13:29:54 +0100 (MET) Received: from delta.ds2.pg.gda.pl(153.19.144.1) via SMTP by guadalquivir.fnet.fr, id smtpd017342; Thu Dec 28 13:29:45 2000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA22644; Thu, 28 Dec 2000 13:25:57 +0100 (MET) Date: Thu, 28 Dec 2000 13:25:56 +0100 (MET) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Ralf Baechle , the list , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: sysmips call and glibc atomic set In-Reply-To: <3A48CC1D.9000204@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 722 Lines: 16 On Tue, 26 Dec 2000, Joe deBlaquiere wrote: > > Read the ISA manual; sc will fail if the LL-bit in c0_status is cleared > > which will be cleared when the interrupt returns using the eret instruction. > > I tried to find a MIPSIII manual from mips.com but all I could find was > mips32 and mips64 (which are not the same as MIPSII/MIPSIII/MIPSIV). Get "IDT MIPS Microprocessor Software Reference Manual" from http://decstation.unix-ag.org/docs/ic_docs/3715.pdf (the original is no longer available from IDT servers). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From Harald.Koerfgen@home.ivm.de Sun Dec 31 12:43:28 2000 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA18399; Sun, 31 Dec 2000 12:43:28 +0100 (MET) Received-Date: Sun, 31 Dec 2000 12:43:28 +0100 (MET) Received: from mail.ivm.net(62.204.1.4) via SMTP by guadalquivir.fnet.fr, id smtpd018397; Sun Dec 31 12:43:19 2000 Received: from franz.no.dom (port203.duesseldorf.ivm.de [195.247.65.203]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id MAA30831; Sun, 31 Dec 2000 12:43:05 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 31 Dec 2000 12:41:11 +0100 (CET) Reply-To: Harald Koerfgen Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: SGI/ARCS related fixes Content-Length: 2543 Lines: 76 Hi, wanting to bring my O2 patches up to date I stumbled over some minor hickups. I don't have the appropriate hardware to test, ok to commit? -- Regards, Harald diff -ruN /nfs/cvs/linux-2.3/linux/arch/mips/arc/memory.c linux/arch/mips/arc/memory.c --- /nfs/cvs/linux-2.3/linux/arch/mips/arc/memory.c Mon Dec 11 18:07:34 2000 +++ linux/arch/mips/arc/memory.c Sat Dec 30 21:49:32 2000 @@ -124,7 +124,7 @@ size = p->pages << PAGE_SHIFT; type = prom_memtype_classify(p->type); - add_memory_region(base, pages, type); + add_memory_region(base, size, type); } } @@ -143,12 +143,13 @@ addr = boot_mem_map.map[i].addr; while (addr < boot_mem_map.map[i].addr + boot_mem_map.map[i].size) { - ClearPageReserved(virt_to_page(__va(addr))); - set_page_count(virt_to_page(__va(addr)), 1); - free_page(__va(addr)); + ClearPageReserved(virt_to_page(addr)); + set_page_count(virt_to_page(addr), 1); + free_page(addr); addr += PAGE_SIZE; freed += PAGE_SIZE; } } printk("Freeing prom memory: %ldkb freed\n", freed >> 10); } + diff -ruN /nfs/cvs/linux-2.3/linux/drivers/char/misc.c linux/drivers/char/misc.c --- /nfs/cvs/linux-2.3/linux/drivers/char/misc.c Fri Nov 24 11:17:05 2000 +++ linux/drivers/char/misc.c Sat Dec 30 21:42:45 2000 @@ -283,9 +283,6 @@ #ifdef CONFIG_SGI_NEWPORT_GFX gfx_register (); #endif -#ifdef CONFIG_SGI - streamable_init (); -#endif #ifdef CONFIG_TOSHIBA tosh_init(); #endif @@ -296,3 +293,4 @@ } return 0; } + diff -ruN /nfs/cvs/linux-2.3/linux/include/asm-mips/sgialib.h linux/include/asm-mips/sgialib.h --- /nfs/cvs/linux-2.3/linux/include/asm-mips/sgialib.h Mon Dec 11 18:08:10 2000 +++ linux/include/asm-mips/sgialib.h Sat Dec 30 21:40:40 2000 @@ -20,7 +20,7 @@ * Init the PROM library and it's internal data structures. Called * at boot time from head.S before start_kernel is invoked. */ -extern int prom_init(int argc, char **argv, char **envp, int *prom_vec); +extern void prom_init(int argc, char **argv, char **envp, int *prom_vec); /* Simple char-by-char console I/O. */ extern void prom_putchar(char c); @@ -104,3 +104,4 @@ extern void prom_cacheflush(void); #endif /* _ASM_SGIALIB_H */ +