From owner-linux-mips@oss.sgi.com Fri Feb 1 00:00:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1180uZ25548 for linux-mips-outgoing; Fri, 1 Feb 2002 00:00:56 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1180pd25544 for ; Fri, 1 Feb 2002 00:00:51 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 59746125C3; Thu, 31 Jan 2002 23:00:50 -0800 (PST) Date: Thu, 31 Jan 2002 23:00:50 -0800 From: "H . J . Lu" To: Hiroyuki Machida Cc: kaz@ashi.footprints.net, macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips Message-ID: <20020131230050.C32690@lucon.org> References: <20020201.123523.50041631.machida@sm.sony.co.jp> <20020201.135903.123568420.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020201.135903.123568420.machida@sm.sony.co.jp>; from machida@sm.sony.co.jp on Fri, Feb 01, 2002 at 01:59:03PM +0900 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 01:59:03PM +0900, Hiroyuki Machida wrote: > > From: Kaz Kylheku > Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips > Date: Thu, 31 Jan 2002 20:02:25 -0800 (PST) > > > On Fri, 1 Feb 2002, Hiroyuki Machida wrote: > > > Please note that "sc" may fail even if nobody write the > > > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See > > > MIPS RUN" for more detail.) > > > So, after your patch applied, compare_and_swap() may fail, even if > > > *p is equal to oldval. > > > > I can't think of anything that will break because of this, as long > > as the compare_and_swap eventually succeeds on some subsequent trial. > > If the atomic operation has to abort for some reason other than *p being > > unequal to oldval, that should be cool. > > I mean that this patch breaks the spec of compare_and_swap(). > In most case, this patch may works as Kaz said. If this patch have > no side-effect to any application, it's ok to apply the patch. But > we can't know how to use compare_and_swap() in all aplications in a > whole world. So we have to follow the spec. > Please note that the old compare_and_swap is broken. If you use compare_and_swap to check if *p == oldval, my patch doesn't help you. But if you use it to swap old/new, my patch works fine. But I don't think you can use it check if *p == oldval since *p can change at any time. It is the same as simply using "*p == oldval". I don't see my patch should break any sane applications. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 00:04:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1184Iw25670 for linux-mips-outgoing; Fri, 1 Feb 2002 00:04:18 -0800 Received: from mail.pha.ha-vel.cz (mail.pha.ha-vel.cz [195.39.72.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1184Ad25665 for ; Fri, 1 Feb 2002 00:04:11 -0800 Received: (qmail 10665 invoked from network); 1 Feb 2002 07:04:05 -0000 Received: from twilight.ucw.cz (HELO twilight.suse.cz) (root@195.39.74.230) by mail.pha.ha-vel.cz with SMTP; 1 Feb 2002 07:04:05 -0000 Received: (from vojtech@localhost) by twilight.suse.cz (8.10.2/8.9.3) id g11745Z15608; Fri, 1 Feb 2002 08:04:05 +0100 Date: Fri, 1 Feb 2002 08:04:05 +0100 From: Vojtech Pavlik To: James Simmons Cc: Russell King , Linux Kernel Mailing List , linux-mips@oss.sgi.com, Linux ARM mailing list Subject: Re: [PATCH] Migration to input api for keyboards Message-ID: <20020201080405.B15571@suse.cz> References: <20020131004041.K19292@flint.arm.linux.org.uk> 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 Thu, Jan 31, 2002 at 12:06:36PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jan 31, 2002 at 12:06:36PM -0800, James Simmons wrote: > > > As some on you know the input api drivers for the PS/2 keyboard/mice > > > have gone into the dj tree for 2.5.X. I need people on other platforms > > > besides ix86 to test it out. I made the following patch that forces the > > > use of the new input drivers so people can test it. Shortly this patch > > > will be placed into the DJ tree but before I do this I want to make sure > > > it works for all platforms. Here is the patch to do this. Thank you. > > > > Oops. > > Oops? > > > Out of those 3 ARM machines, only 1 or maybe 2 has an 8042-compatible > > port. > > > > CONFIG_PC_KEYB != i8042 controller present. Please look more closely > > at stuff in include/asm-arm/arch-*/keyboard.h > > I posted to find out which ones. BTW we have a driver for the acorn > keyboard controller. No acorn keyboard but we do have support the acorn The acorn RiscPC keyboard controller has a connector for the standard AT keyboard, so it's rpckbd.c + atkbd.c doing the trick there. > mouse. I can create a patch so you can give the mouse driver a try. Also > help on porting the acorn keyboard driver would be helpful, any docs on > it. Not needed. It's atkbd.c. And that way it'll be for a lot of other hardware - AT keyboards are used everywhere, only the controllers differ. That's the main reason for the keyboard (input) and keyboard controller (serio) driver split! -- Vojtech Pavlik SuSE Labs From owner-linux-mips@oss.sgi.com Fri Feb 1 00:10:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g118Afo25801 for linux-mips-outgoing; Fri, 1 Feb 2002 00:10:41 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g118Add25797 for ; Fri, 1 Feb 2002 00:10:39 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 13857125C3; Thu, 31 Jan 2002 23:10:36 -0800 (PST) Date: Thu, 31 Jan 2002 23:10:36 -0800 From: "H . J . Lu" To: Kaz Kylheku Cc: Hiroyuki Machida , macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips Message-ID: <20020131231036.D32690@lucon.org> References: <20020201.123523.50041631.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kaz@ashi.footprints.net on Thu, Jan 31, 2002 at 08:02:25PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jan 31, 2002 at 08:02:25PM -0800, Kaz Kylheku wrote: > On Fri, 1 Feb 2002, Hiroyuki Machida wrote: > > Please note that "sc" may fail even if nobody write the > > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See > > MIPS RUN" for more detail.) > > So, after your patch applied, compare_and_swap() may fail, even if > > *p is equal to oldval. > > I can't think of anything that will break because of this, as long > as the compare_and_swap eventually succeeds on some subsequent trial. > If the atomic operation has to abort for some reason other than *p being > unequal to oldval, that should be cool. Maybe we should document it in glibc, something like compare_and_swap compares the contents of a variable with an old value. If the values are equal and a new value is stored in the variable atomically, 1 is returned; otherwise, 1 is returned. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 00:17:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g118HKZ25951 for linux-mips-outgoing; Fri, 1 Feb 2002 00:17:20 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g118HGd25948 for ; Fri, 1 Feb 2002 00:17:16 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 92E2D125C3; Thu, 31 Jan 2002 23:17:14 -0800 (PST) Date: Thu, 31 Jan 2002 23:17:14 -0800 From: "H . J . Lu" To: Hiroyuki Machida Cc: macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips Message-ID: <20020131231714.E32690@lucon.org> References: <20020131123547.A22759@lucon.org> <20020131144100.A24634@lucon.org> <20020201.123523.50041631.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020201.123523.50041631.machida@sm.sony.co.jp>; from machida@sm.sony.co.jp on Fri, Feb 01, 2002 at 12:35:23PM +0900 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 12:35:23PM +0900, Hiroyuki Machida wrote: > > _test_and_set (int *p, int v) __THROW > > { > > int r, t; > > > > __asm__ __volatile__ > > (".set push\n\t" > > ".set noreorder\n" > > "1:\n\t" > > "ll %0,%3\n\t" > > "beq %0,%4,2f\n\t" > > "move %1,%4\n\t" > > "sc %1,%2\n\t" > > "beqz %1,1b\n\t" > > "nop\n" > > "2:\n\t" > > ".set pop" > > : "=&r" (r), "=&r" (t), "=m" (*p) > > : "m" (*p), "r" (v) > > : "memory"); > > > > return r; > > } > > Gas will fill delay slots. Same object codes will be produced, so I > think you don't have to do that by hand. It will make the code more readable. We don't have to guess what the assembler will do. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 01:55:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g119ti127581 for linux-mips-outgoing; Fri, 1 Feb 2002 01:55:44 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g119tYd27576 for ; Fri, 1 Feb 2002 01:55:35 -0800 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g118tEa10310; Fri, 1 Feb 2002 08:55:14 GMT Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id IAA00394; Fri, 1 Feb 2002 08:55:10 GMT Date: Fri, 1 Feb 2002 08:55:10 GMT Message-Id: <200202010855.IAA00394@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jason Gunthorpe Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > No, a sync will still empty the write buffer. It may halt the > > >pipeline for many (~80 perhaps) cycles while posted write data is > > >dumped to the system controller. > > > > Then it's an implementation bug. For a CPU in the UP mode "sync" > > is only defined to prevent write and read reordering -- there is > > nothing about flushing. > > Did some more research + phoning.. RM7K is definately documented to dump > the write buffer on 'sync'. The RM7000 sync does more than is required by the ISA. However, since the write-buffer is not part of the architecture, this is not a bug. Though it might well be held to be undesirable. And there has to be *some* way to force the write buffer to empty, and this is cheaper than the standard alternative of an uncached read. I believe the RM7000 write buffer can hold one pending cache-line writeback or up to four uncached writes. Emptying the write buffer can only occupy more than a handful of cycles when the system controller is already backed-up with pending writes; under those circumstances the system was probably about to stall anyway, so I wouldn't be too worried about the performance implications of a 'sync'. > The RM7K guide even has an example (7.8.5) > where it implies that sync also forces a write back of any dirty cache > lines - gah! (Hard to belive though..) There's not a word of truth in that (there just aren't the right wires in the hardware to make that possible). But I think what it means is that it stops the CPU until a pending cache line write back is complete. It's hard to see why that would be useful, but since it uses the same write buffer hardware it's easy to see why it would happen. Of course (as everyone has been piling in and pointing out) the real problems are: 1. The MIPS people who invented 'sync' had a much more sophisticated understanding of read/write behaviour than is common in those who support, document and program uniprocessor "embedded" CPUs; so there's lots of scope for misunderstanding 'sync'. 2. When write-posting bites you, it's usually not in the CPU but somewhere further down the system. You should never believe a write has actually arrived at the device you sent it to, until you see the device itself change state... And a plea: the word "flush" in Linux is already abused for caches (where it means invalidate, write back, or possibly both). That's enough trouble: if you also "flush" write buffers, your confusion will be complete. Maybe we should leave "flush" to plumbers and use more precise terminology for computers... -- 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 Fri Feb 1 02:53:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11ArFv29146 for linux-mips-outgoing; Fri, 1 Feb 2002 02:53:15 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Ar6d29143 for ; Fri, 1 Feb 2002 02:53:06 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA10156; Fri, 1 Feb 2002 01:52:50 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA03140; Fri, 1 Feb 2002 01:52:44 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g119qKA19597; Fri, 1 Feb 2002 10:52:20 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id KAA23996; Fri, 1 Feb 2002 10:52:42 +0100 (MET) Message-Id: <200202010952.KAA23996@copsun18.mips.com> Subject: Re: [patch] linux 2.4.17: An mb() rework To: jgg@debian.org Date: Fri, 1 Feb 2002 10:52:42 +0100 (MET) Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: from "Jason Gunthorpe" at Jan 31, 2002 11:44:30 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 Jason Gunthorpe writes: > > > On Thu, 31 Jan 2002, Maciej W. Rozycki wrote: > > > Hmm, wmb() is pretty clearly defined. The current implementation does > > not enforce strict ordering and is thus incorrect. Note that the R4400 > > manual explicitly states a cached write can bypass an uncached one, hence > > the CPU may exploit weak ordering under certain circumstances. The "sync" > > instruction was specifically defined to avoid such a risk. > > Yes, you are correct. I suppose *mb() must also work correctly with the > cache flush macros - didn't think about that one! > > I'm afraid I don't have any manuals for any of the MIPS chips just 3rd > party ones SB1, RM7K and SR71000 - which is why I have some many > odd questions. :> > > > > No, a sync will still empty the write buffer. It may halt the pipeline for > > > many (~80 perhaps) cycles while posted write data is dumped to the system > > > controller. > > > > Then it's an implementation bug. For a CPU in the UP mode "sync" is only > > defined to prevent write and read reordering -- there is nothing about > > flushing. Not quite. Extract from the MIPS32 Architecture Reference Manual (available on www.mips.com, documentation section): SYNC Purpose: To order loads and stores. Description: * SYNC affects only uncached and cached coherent loads and stores. The loads and stores that occur before the SYNC must be completed before the loads and stores after the SYNC are allowed to start. * Loads are completed when the destination register is written. Stores are completed when the stored value is visible to every other processor in the system. * SYNC is required, potentially in conjunction with SSNOP, to guarantee that memory reference results are visible across operating mode changes. For example, a SYNC is required on some implementations on entry to and exit from Debug Mode to guarantee that memory affects are handled correctly. Detailed Description: * When the stype field has a value of zero, every synchronizable load and store that occurs in the instruction stream before the SYNC instruction must be globally performed before any synchronizable load or store that occurs after the SYNC can be performed, with respect to any other processor or coherent I/O module. * SYNC does not guarantee the order in which instruction fetches are performed. The stype values 1-31 are reserved; they produce the same result as the value zero. ----------- end of extract The interesting one is the second-last bullet, and where the synchronization point lies. All the cores from MIPS technologies provide the means through lines and/or signalling on the bus interface to move the synchronization point outside the processor. That is, without doing anything additional, the processor itself will empty all writebuffers and present the writes on the bus interface before any bus transaction of an instruction following the sync will appear on the bus interface. Through the use of the additional signalling mentioned above, the system logic can choose to delay even more, thus moving the synchronization point further out. /Hartvig -- _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com |\ /| | |____)(____ Direct: +45 4486 5503 | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 From owner-linux-mips@oss.sgi.com Fri Feb 1 03:51:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11BpZg30136 for linux-mips-outgoing; Fri, 1 Feb 2002 03:51:35 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11BpSd30131 for ; Fri, 1 Feb 2002 03:51:29 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2BD051EE67; Fri, 1 Feb 2002 11:49:43 +0100 (MET) X-Authentication-Warning: sykes.suse.de: schwab set sender to schwab@suse.de using -f To: Hiroyuki Machida Cc: kaz@ashi.footprints.net, hjl@lucon.org, macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips References: <20020201.123523.50041631.machida@sm.sony.co.jp> <20020201.135903.123568420.machida@sm.sony.co.jp> X-Yow: .. I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS... From: Andreas Schwab Date: Fri, 01 Feb 2002 11:49:22 +0100 In-Reply-To: <20020201.135903.123568420.machida@sm.sony.co.jp> (Hiroyuki Machida's message of "Fri, 01 Feb 2002 13:59:03 +0900 (JST)") Message-ID: Lines: 38 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2.50 (ia64-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hiroyuki Machida writes: |> From: Kaz Kylheku |> Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips |> Date: Thu, 31 Jan 2002 20:02:25 -0800 (PST) |> |> > On Fri, 1 Feb 2002, Hiroyuki Machida wrote: |> > > Please note that "sc" may fail even if nobody write the |> > > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See |> > > MIPS RUN" for more detail.) |> > > So, after your patch applied, compare_and_swap() may fail, even if |> > > *p is equal to oldval. |> > |> > I can't think of anything that will break because of this, as long |> > as the compare_and_swap eventually succeeds on some subsequent trial. |> > If the atomic operation has to abort for some reason other than *p being |> > unequal to oldval, that should be cool. |> |> I mean that this patch breaks the spec of compare_and_swap(). |> |> In most case, this patch may works as Kaz said. If this patch have |> no side-effect to any application, it's ok to apply the patch. But |> we can't know how to use compare_and_swap() in all aplications in a |> whole world. So we have to follow the spec. There is no way to find out anything about intermediate values of *p when compare_and_swap returns zero. The value of *p can change anytime, even if it only was different from oldval just at the time compare_and_swap did the comparison. So there is zero chance that a spurious failure of compare_and_swap breaks anything. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From owner-linux-mips@oss.sgi.com Fri Feb 1 04:13:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11CD5A00414 for linux-mips-outgoing; Fri, 1 Feb 2002 04:13:05 -0800 Received: from ns6.sony.co.jp (NS6.Sony.CO.JP [146.215.0.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11CCrd00410 for ; Fri, 1 Feb 2002 04:12:53 -0800 Received: from mail2.sony.co.jp (mail2.sony.co.jp [43.0.1.202]) by ns6.sony.co.jp (R8/Sony) with ESMTP id g11BChW17024; Fri, 1 Feb 2002 20:12:43 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g11BCgH02200; Fri, 1 Feb 2002 20:12:42 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g11BCfA02180; Fri, 1 Feb 2002 20:12:41 +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 UAA24352; Fri, 1 Feb 2002 20:17:20 +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 UAA04105; Fri, 1 Feb 2002 20:12:40 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g11BCeJ10159; Fri, 1 Feb 2002 20:12:40 +0900 (JST) Date: Fri, 01 Feb 2002 20:12:40 +0900 (JST) Message-Id: <20020201.201240.103027706.machida@sm.sony.co.jp> To: hjl@lucon.org Cc: kaz@ashi.footprints.net, macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips From: Hiroyuki Machida In-Reply-To: <20020131230050.C32690@lucon.org> References: <20020201.135903.123568420.machida@sm.sony.co.jp> <20020131230050.C32690@lucon.org> 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 From: "H . J . Lu" Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips Date: Thu, 31 Jan 2002 23:00:50 -0800 > On Fri, Feb 01, 2002 at 01:59:03PM +0900, Hiroyuki Machida wrote: > > > > From: Kaz Kylheku > > Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips > > Date: Thu, 31 Jan 2002 20:02:25 -0800 (PST) > > > > > On Fri, 1 Feb 2002, Hiroyuki Machida wrote: > > > > Please note that "sc" may fail even if nobody write the > > > > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See > > > > MIPS RUN" for more detail.) > > > > So, after your patch applied, compare_and_swap() may fail, even if > > > > *p is equal to oldval. > > > > > > I can't think of anything that will break because of this, as long > > > as the compare_and_swap eventually succeeds on some subsequent trial. > > > If the atomic operation has to abort for some reason other than *p being > > > unequal to oldval, that should be cool. > > > > I mean that this patch breaks the spec of compare_and_swap(). > > In most case, this patch may works as Kaz said. If this patch have > > no side-effect to any application, it's ok to apply the patch. But > > we can't know how to use compare_and_swap() in all aplications in a > > whole world. So we have to follow the spec. > > > > Please note that the old compare_and_swap is broken. If you use > compare_and_swap to check if *p == oldval, my patch doesn't help > you. But if you use it to swap old/new, my patch works fine. But I > don't think you can use it check if *p == oldval since *p can change > at any time. It is the same as simply using "*p == oldval". I don't > see my patch should break any sane applications. > > > H.J. > I know the orinal compare_and_swap() is bad, and I believe the spec of compare_and_swap() as below; compare_and_swap(p, oldval, newval) { retval = 0; begin_atomic if (*p==oldval) { *p = newval; retval = 1; } end_atomic return retval; } So, compare_and_swap() should be ... __compare_and_swap (a0 long int oldval, long int newval) a0: *p a1: oldval a2: newval v0: return value .set noreorder retry: ll v0, (a0) bne v0, a1 move v0, zero move v0, a2 sc v0, (a0) beqz v0, retry nop j ra But, with your patch ... .set noreorder ll t0, (a0) bne t0, a1 move v0, zero move v0, a sc v0, (a0) j ra In this way, compare_and_swap() was changed as compare_and_swap(p, oldval, newval) { retval = 0; begin_atomic if (*p==oldval) { if "sc" was failed goto out; *p = newval; retval = 1; } out: end_atomic return retval; } --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Fri Feb 1 04:24:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11CO1P00719 for linux-mips-outgoing; Fri, 1 Feb 2002 04:24:01 -0800 Received: from desire.geoffk.org (12-234-190-114.client.attbi.com [12.234.190.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11CNwd00716 for ; Fri, 1 Feb 2002 04:23:58 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g11BNhg01794; Fri, 1 Feb 2002 03:23:43 -0800 Date: Fri, 1 Feb 2002 03:23:43 -0800 From: Geoff Keating Message-Id: <200202011123.g11BNhg01794@desire.geoffk.org> To: schwab@suse.de CC: machida@sm.sony.co.jp, kaz@ashi.footprints.net, hjl@lucon.org, macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com In-reply-to: (message from Andreas Schwab on Fri, 01 Feb 2002 11:49:22 +0100) Subject: Re: [libc-alpha] Re: PATCH: Fix ll/sc for mips Reply-to: Geoff Keating References: <20020201.123523.50041631.machida@sm.sony.co.jp> <20020201.135903.123568420.machida@sm.sony.co.jp> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > From: Andreas Schwab > Date: Fri, 01 Feb 2002 11:49:22 +0100 > There is no way to find out anything about intermediate values of *p when > compare_and_swap returns zero. The value of *p can change anytime, even > if it only was different from oldval just at the time compare_and_swap did > the comparison. So there is zero chance that a spurious failure of > compare_and_swap breaks anything. Something to watch out for, though, is livelock. Consider the situation in which two processors are competing for a cache line, and both only win at the 'wrong' time: when computing a new value to be passed to compare_and_swap rather than when actually trying to perform the compare_and_swap. This is why on powerpc the loop is coded in the asm statement. -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Fri Feb 1 04:46:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11CkDj01132 for linux-mips-outgoing; Fri, 1 Feb 2002 04:46:13 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Ck7d01129 for ; Fri, 1 Feb 2002 04:46:08 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA26518; Fri, 1 Feb 2002 12:45:02 +0100 (MET) Date: Fri, 1 Feb 2002 12:45:02 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips In-Reply-To: <20020131231714.E32690@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 31 Jan 2002, H . J . Lu wrote: > > Gas will fill delay slots. Same object codes will be produced, so I > > think you don't have to do that by hand. > > It will make the code more readable. We don't have to guess what > the assembler will do. But you lose a chance for something useful being reordered to the slot. That might not necessarily be a "nop". Please don't forget of indents anyway. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Feb 1 04:51:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11CpEF01298 for linux-mips-outgoing; Fri, 1 Feb 2002 04:51:14 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11CpBd01295 for ; Fri, 1 Feb 2002 04:51:11 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA26608; Fri, 1 Feb 2002 12:50:48 +0100 (MET) Date: Fri, 1 Feb 2002 12:50:48 +0100 (MET) From: "Maciej W. Rozycki" To: Hiroyuki Machida cc: hjl@lucon.org, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips In-Reply-To: <20020201.123523.50041631.machida@sm.sony.co.jp> 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, 1 Feb 2002, Hiroyuki Machida wrote: > > It will fail if *p is not same as oldval. > > Please note that "sc" may fail even if nobody write the > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See > MIPS RUN" for more detail.) > So, after your patch applied, compare_and_swap() may fail, even if > *p is equal to oldval. That's exactly what I meant -- "sc" may fail to execute the store, while "cmpxchgl" may not. -- + 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 Feb 1 05:02:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11D2iV01606 for linux-mips-outgoing; Fri, 1 Feb 2002 05:02:44 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11D2ed01603 for ; Fri, 1 Feb 2002 05:02:40 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27210; Fri, 1 Feb 2002 13:01:57 +0100 (MET) Date: Fri, 1 Feb 2002 13:01:57 +0100 (MET) From: "Maciej W. Rozycki" To: Jason Gunthorpe cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework 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 Thu, 31 Jan 2002, Jason Gunthorpe wrote: > I'm afraid I don't have any manuals for any of the MIPS chips just 3rd > party ones SB1, RM7K and SR71000 - which is why I have some many > odd questions. :> Please feel free to grab a few from 'http://www.mips.com/Documentation/' and 'http://www.mips.com/declassified/'. ;-) I have a few excellent IDT manuals on their original CD-ROM as well. If they can't be downloaded anymore, I may put them online at my site. > Did some more research + phoning.. RM7K is definately documented to dump > the write buffer on 'sync'. The RM7K guide even has an example (7.8.5) > where it implies that sync also forces a write back of any dirty cache > lines - gah! (Hard to belive though..) If RM7K is always strongly ordered, I may code a workaround. -- + 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 Feb 1 05:05:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11D5Fg01709 for linux-mips-outgoing; Fri, 1 Feb 2002 05:05:15 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11D5Bd01706 for ; Fri, 1 Feb 2002 05:05:12 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27319; Fri, 1 Feb 2002 13:04:24 +0100 (MET) Date: Fri, 1 Feb 2002 13:04:23 +0100 (MET) From: "Maciej W. Rozycki" To: Dominic Sweetman cc: Jason Gunthorpe , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework In-Reply-To: <200202010855.IAA00394@mudchute.algor.co.uk> 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, 1 Feb 2002, Dominic Sweetman wrote: > And a plea: the word "flush" in Linux is already abused for caches > (where it means invalidate, write back, or possibly both). That's > enough trouble: if you also "flush" write buffers, your confusion will > be complete. Maybe we should leave "flush" to plumbers and use more > precise terminology for computers... Too bad the original name for the function is wbflush() already... At least IDT uses it in their docs. -- + 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 Feb 1 05:28:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11DSif02116 for linux-mips-outgoing; Fri, 1 Feb 2002 05:28:44 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11DSad02105 for ; Fri, 1 Feb 2002 05:28:36 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27942; Fri, 1 Feb 2002 13:27:42 +0100 (MET) Date: Fri, 1 Feb 2002 13:27:42 +0100 (MET) From: "Maciej W. Rozycki" To: Alan Cox cc: jgg@debian.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework 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 Thu, 31 Jan 2002, Alan Cox wrote: > The x86 behaviour forced as I understand it is > > barrier() - compiler level store barrier > rmb() - read barrier to bus/DMA level > [no operation] > wmb() - write barrier to bus/DMA level > [synchronizing instruction sequence > of locked add of 0 to stack top] > > (mb and wmb as names come from Alpha so I guess its definitive 8)) Well, after looking at the Alpha Architecture Handbook I see "mb" and "wmb" are pure ordering barriers -- any transactions at the CPU bus (pins) may still be deferred or prefetched (architecturally -- can't comment on specific chips). So after all, maybe all the macros should be purely "sync" for MIPS ("" for MIPS I, and mb() equal to wbflush() for R3220 and similar setups) and anything that wants to see all writes actually committed should use wbflush(), which would be defined as "mb(); uncached_read();" (or in a system-specific way, for R3220, etc.)? The i386 implementation seems stronger than it should be, but that's probably because of the limited choice available. Any thoughts? > It does not enforce PCI posting. Also your spurious interrupt case is > wrong for other horrible reasons. Interrupt delivery must never be > assumed to be synchronous in a portable driver. (In fact you'll see async > irq delivery on an X86) For interrupts arriving to an interrupt controller -- agreed. But we don't generally expect a spurious interrupt from a line that was already masked at the controller level. In other words mask_and_ack() must undertake any means possible, to assure the addressed controller received the new mask. If an interrupt passes by ocassionally anyway, then it's not fatal, i.e. we can handle it, but it shouldn't be a rule (i.e. receiving as many spurious interrupts as real ones). Am I right? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Feb 1 05:47:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11Dl5R03600 for linux-mips-outgoing; Fri, 1 Feb 2002 05:47:05 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Dl2d03597 for ; Fri, 1 Feb 2002 05:47:02 -0800 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 16Wd5m-000695-00; Fri, 01 Feb 2002 13:46:58 +0100 Date: Fri, 1 Feb 2002 13:46:06 +0100 From: Guido Guenther To: George Gensure Cc: linux-mips@lists.debian.org Subject: Re: Newport XZ Message-ID: <20020201134606.A22880@gandalf.physik.uni-konstanz.de> References: <20020131111144.A14922@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 werkt@csh.rit.edu on Thu, Jan 31, 2002 at 03:43:04PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jan 31, 2002 at 03:43:04PM -0500, George Gensure wrote: > It's definitely not a dual head board, however, attached to the sgi bus > (s-bus?) these two cards are stacked on top of one another. The top one > has the display adapter. I only say it is a XZ because of a hardware site GIO Bus. You misunderstood me here. I'm not taling about two video outs on one card. I actually ment: http://www.reputable.com/indytech.html#DualHead This "dual head graphics option board"(as it is called there) looks very much like a XL. Is that what you have? > that I found that showed all the different Newport cards, and this was the > only one that matched it. I don't have a problem doing the serial (found > a cord), but I looked at the kernel source for the graphics and gconsole > drivers, and it looked like they work now by some dark black magic. There > is no probing of the card of any kind, and even the code that looks as > though it might be able to run on more than one machine has been #if 0 -ed > out. Would only the base address for the XZ be different, or would it be > a completely different arrangement for the card as opposed to the XLs? GIO bus probing is being worked at. The current "probing" is crap and let's an I2 halt immediately with a bus error. As I said before: if both of these cards are XL(aka newport, although the "lower" one might be a slight variation to allow for the daughter board) and not XZ(aka fullhouse) you might have chances to get this working by only adjusting the base addresses(the likely ones are in include/video/newport.h). -- Guido From owner-linux-mips@oss.sgi.com Fri Feb 1 06:46:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11EkI204723 for linux-mips-outgoing; Fri, 1 Feb 2002 06:46:18 -0800 Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11EkCd04719 for ; Fri, 1 Feb 2002 06:46:12 -0800 Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g11Dk7h90984; Fri, 1 Feb 2002 05:46:07 -0800 (PST) (envelope-from weasel@meer.net) Received: from localhost.meer.net (ptn-130.mv.meer.net [209.157.137.130]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id FAA4109180; Fri, 1 Feb 2002 05:45:20 -0800 (PST) To: binutils@sources.redhat.com, linux-mips@oss.sgi.com Subject: me vs gas mips64 relocation From: d p chang User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Reply-To: weasel@cs.stanford.edu Date: 01 Feb 2002 05:45:19 -0800 Message-ID: Lines: 53 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi there, I'm trying to figure out if i've just misconfigured something here or if there is a real problem in gas. I did some grovelling through the mailing list archives, but really am still catching up. Anyway, here at home i grabbed the current cvs binutils and configured (i thought successfully since I only checked the assembly before the final link and hadn't been looking at the reloc bits) it to cross compile from macos x to mips64-linux. It appeared to be successful but it wasn't until i had written the rest of my chipset startup logic that I noticed a problem. My test case looks like this: .text .comm my_test_global, 8, 8 LEAF(reloc_hi_test) ld t0, my_test_global ; my problem lui t0, %hi(my_test_global) ; works addiu t0, %lo(my_test_global) END(reloc_hi_test) .end i compile this w/ (i only just added all the verbosity flags). mips64-linux-gcc -I /Volumes/Homey/dpc/Devel/linux-2.4.17/include/asm/gcc -D__KERNEL__ -I/Volumes/Homey/dpc/Devel/linux-2.4.17/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mips4 -mmad -Wa,-march=r5231 -mlong64 -mgp64 -mfp64 -ffreestanding -mabi=n32 reloc.S -c -o reloc.o -Wa,-acdhls -v -Wa,-v -Wa,-O0 and I get this from objdump: reloc.o: file format elf32-tradbigmips Disassembly of section .text: 00000000 : 0: 3c0c0000 lui t0,0x0 4: 258c0000 addiu t0,t0,0 4: R_MIPS_LO16 my_test_global 8: 3c0c0000 lui t0,0x0 8: R_MIPS_HI16 my_test_global c: 258c0000 addiu t0,t0,0 c: R_MIPS_LO16 my_test_global Anyway, the missing R_MIPS_HI16 relocation at offset 0 is my problem. I had expected the two to generate the same code. am i mistaken, did i screw something up configuring, is this a bug, or something else? \p From owner-linux-mips@oss.sgi.com Fri Feb 1 07:09:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11F99A05460 for linux-mips-outgoing; Fri, 1 Feb 2002 07:09:09 -0800 Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11F96d05449 for ; Fri, 1 Feb 2002 07:09:07 -0800 Received: from libero.it (193.70.192.44) by smtp2.libero.it (6.0.040) id 3C58404400135E7D; Fri, 1 Feb 2002 15:08:40 +0100 Date: Fri, 1 Feb 2002 15:08:40 +0100 Message-Id: Subject: =?iso-8859-1?Q?help_for_linux?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?utf-8?Q?info@bbeuropean.com?=" To: brad@ltc.com Cc: linux-mips@oss.sgi.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 193.206.138.36 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g11F98d05454 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Installation mips linux to indy where is the readmy in the web site of sgi ?. http://www.bbeuropean.com http://www.spazio-formazione.it http://www.antigravity.it http://www.prestare.it Raffella tel 3476980419 preferibilmnet ore serali From owner-linux-mips@oss.sgi.com Fri Feb 1 10:40:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11IetR15686 for linux-mips-outgoing; Fri, 1 Feb 2002 10:40:55 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11IeSd15683 for ; Fri, 1 Feb 2002 10:40:28 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 78793125C3; Fri, 1 Feb 2002 09:40:25 -0800 (PST) Date: Fri, 1 Feb 2002 09:40:25 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips Message-ID: <20020201094025.A10392@lucon.org> References: <20020201.123523.50041631.machida@sm.sony.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 01, 2002 at 12:50:48PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 12:50:48PM +0100, Maciej W. Rozycki wrote: > On Fri, 1 Feb 2002, Hiroyuki Machida wrote: > > > > It will fail if *p is not same as oldval. > > > > Please note that "sc" may fail even if nobody write the > > variable. (See P.211 "8.4.2 Load-Linked/Sotre-Conditional" of "See > > MIPS RUN" for more detail.) > > So, after your patch applied, compare_and_swap() may fail, even if > > *p is equal to oldval. > > That's exactly what I meant -- "sc" may fail to execute the store, while > "cmpxchgl" may not. > Here is the updated patch. H.J. --- 2002-01-31 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Use a different register in the delayed slot. * sysdeps/mips/pt-machine.h (testandset): Call _test_and_set. (__compare_and_swap): Return 0 only when failed to compare. 2002-01-31 H.J. Lu * sysdeps/mips/atomicity.h (compare_and_swap): Return 0 only when failed to compare. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Fill the delay slot. --- glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c.llsc Thu Jan 31 10:49:37 2002 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c Thu Jan 31 10:49:37 2002 @@ -29,20 +29,21 @@ int __pthread_spin_lock (pthread_spinlock_t *lock) { - unsigned int tmp; + unsigned int tmp1, tmp2; asm volatile ("\t\t\t# spin_lock\n\t" - "1:\n\t" - "ll %1,%2\n\t" ".set push\n\t" - ".set noreorder\n\t" + ".set noreorder\n" + "1:\n\t" + "ll %1,%3\n\t" "bnez %1,1b\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%0\n\t" - "beqz %1,1b" - : "=m" (*lock), "=&r" (tmp) + "li %2,1\n\t" + "sc %2,%0\n\t" + "beqz %2,1b\n\t" + "nop\n\t" + ".set pop" + : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) : "memory"); --- glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h.llsc Sat Dec 9 08:55:34 2000 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h Fri Feb 1 09:19:44 2002 @@ -33,41 +33,11 @@ /* Spinlock implementation; required. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - -PT_EI long int -testandset (int *spinlock) -{ - long int ret, temp; - - __asm__ __volatile__ - ("/* Inline spinlock test & set */\n\t" - "1:\n\t" - "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "bnez %0,2f\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n\t" - "/* End spinlock test & set */" - : "=&r" (ret), "=&r" (temp), "=m" (*spinlock) - : "m" (*spinlock) - : "memory"); - - return ret; -} - -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - PT_EI long int testandset (int *spinlock) { return _test_and_set (spinlock, 1); } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ /* Get some notion of the current stack. Need not be exactly the top @@ -84,22 +54,24 @@ register char * stack_pointer __asm__ (" PT_EI int __compare_and_swap (long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" + ("/* Inline compare & swap */\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + "ll %1,%5\n\t" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - " move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + "move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqz %0,1b\n\t" + "nop\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/mips/atomicity.h.llsc Mon Jul 9 11:58:19 2001 +++ glibc-2.2.4/sysdeps/mips/atomicity.h Fri Feb 1 09:21:41 2002 @@ -32,12 +32,16 @@ exchange_and_add (volatile uint32_t *mem int result, tmp; __asm__ __volatile__ - ("/* Inline exchange & add */\n\t" + ("/* Inline exchange & add */\n" "1:\n\t" "ll %0,%3\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" + ".set push\n\t" + ".set noreorder\n\t" "beqz %1,1b\n\t" + "nop\n\t" + ".set pop\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) : "m" (*mem), "r"(val) @@ -53,12 +57,16 @@ atomic_add (volatile uint32_t *mem, int int result; __asm__ __volatile__ - ("/* Inline atomic add */\n\t" + ("/* Inline atomic add */\n" "1:\n\t" "ll %0,%2\n\t" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" + ".set push\n\t" + ".set noreorder\n\t" "beqz %0,1b\n\t" + "nop\n\t" + ".set pop\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) : "m" (*mem), "r"(val) @@ -69,22 +77,24 @@ static inline int __attribute__ ((unused)) compare_and_swap (volatile long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" + ("/* Inline compare & swap */\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + "ll %1,%5\n\t" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - "move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + "move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqz %0,1b\n\t" + "nop\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Jul 9 11:58:45 2001 +++ glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h Thu Jan 31 10:49:37 2002 @@ -42,16 +42,17 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("1:\n\t" + (".set push\n\t" + ".set noreorder\n" + "1:\n\t" "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" "beq %0,%4,2f\n\t" - " move %1,%4\n\t" - ".set pop\n\t" + "move %1,%4\n\t" "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n" + "beqz %1,1b\n\t" + "nop\n" + "2:\n\t" + ".set pop" : "=&r" (r), "=&r" (t), "=m" (*p) : "m" (*p), "r" (v) : "memory"); From owner-linux-mips@oss.sgi.com Fri Feb 1 11:30:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11JUFP16570 for linux-mips-outgoing; Fri, 1 Feb 2002 11:30:15 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11JTkd16548 for ; Fri, 1 Feb 2002 11:29:46 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 4BEE5125C3; Fri, 1 Feb 2002 10:29:43 -0800 (PST) Date: Fri, 1 Feb 2002 10:29:43 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020201102943.A11146@lucon.org> References: <20020131231714.E32690@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 01, 2002 at 12:45:02PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > think you don't have to do that by hand. > > > > It will make the code more readable. We don't have to guess what > > the assembler will do. > > But you lose a chance for something useful being reordered to the slot. > That might not necessarily be a "nop". Please don't forget of indents > anyway. > Here is a new patch. I use branch likely to get rid of nops. Please tell me which indents I may have missed. Thanks. H.J. ---- 2002-02-01 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Use a different register in the delayed slot. Use branch likely. * sysdeps/mips/pt-machine.h (testandset): Call _test_and_set. (__compare_and_swap): Return 0 only when failed to compare. Use branch likely. 2002-02-01 H.J. Lu * sysdeps/mips/atomicity.h (exchange_and_add): Use branch likely. (atomic_add): Likewise. (compare_and_swap): Return 0 only when failed to compare. Use branch likely. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Use branch likely. --- glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c.llsc Thu Jan 31 10:49:37 2002 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c Fri Feb 1 10:17:47 2002 @@ -29,20 +29,21 @@ int __pthread_spin_lock (pthread_spinlock_t *lock) { - unsigned int tmp; + unsigned int tmp1, tmp2; asm volatile ("\t\t\t# spin_lock\n\t" + "ll %1,%3\n" "1:\n\t" - "ll %1,%2\n\t" ".set push\n\t" ".set noreorder\n\t" "bnez %1,1b\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%0\n\t" - "beqz %1,1b" - : "=m" (*lock), "=&r" (tmp) + "li %2,1\n\t" + "sc %2,%0\n\t" + "beqzl %2,1b\n\t" + "ll %1,%3\n\t" + ".set pop" + : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) : "memory"); --- glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h.llsc Sat Dec 9 08:55:34 2000 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h Fri Feb 1 10:14:18 2002 @@ -33,41 +33,11 @@ /* Spinlock implementation; required. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - -PT_EI long int -testandset (int *spinlock) -{ - long int ret, temp; - - __asm__ __volatile__ - ("/* Inline spinlock test & set */\n\t" - "1:\n\t" - "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "bnez %0,2f\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n\t" - "/* End spinlock test & set */" - : "=&r" (ret), "=&r" (temp), "=m" (*spinlock) - : "m" (*spinlock) - : "memory"); - - return ret; -} - -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - PT_EI long int testandset (int *spinlock) { return _test_and_set (spinlock, 1); } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ /* Get some notion of the current stack. Need not be exactly the top @@ -84,22 +54,24 @@ register char * stack_pointer __asm__ (" PT_EI int __compare_and_swap (long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ ("/* Inline compare & swap */\n\t" + "ll %1,%5\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - " move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + "move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqzl %0,1b\n\t" + "ll %1,%5\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/mips/atomicity.h.llsc Mon Jul 9 11:58:19 2001 +++ glibc-2.2.4/sysdeps/mips/atomicity.h Fri Feb 1 09:55:05 2002 @@ -33,11 +33,15 @@ exchange_and_add (volatile uint32_t *mem __asm__ __volatile__ ("/* Inline exchange & add */\n\t" + "ll %0,%3\n" "1:\n\t" - "ll %0,%3\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" - "beqz %1,1b\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beqzl %1,1b\n\t" + "ll %0,%3\n\t" + ".set pop\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) : "m" (*mem), "r"(val) @@ -54,11 +58,15 @@ atomic_add (volatile uint32_t *mem, int __asm__ __volatile__ ("/* Inline atomic add */\n\t" + "ll %0,%2\n" "1:\n\t" - "ll %0,%2\n\t" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" - "beqz %0,1b\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beqzl %0,1b\n\t" + "ll %0,%2\n\t" + ".set pop\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) : "m" (*mem), "r"(val) @@ -69,22 +77,24 @@ static inline int __attribute__ ((unused)) compare_and_swap (volatile long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ ("/* Inline compare & swap */\n\t" + "ll %1,%5\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - "move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + "move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqzl %0,1b\n\t" + "ll %1,%5\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Jul 9 11:58:45 2001 +++ glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h Fri Feb 1 09:56:47 2002 @@ -42,16 +42,19 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("1:\n\t" - "ll %0,%3\n\t" + ("/* Inline test and set */\n\t" + "ll %0,%3\n" + "1:\n\t" ".set push\n\t" ".set noreorder\n\t" "beq %0,%4,2f\n\t" - " move %1,%4\n\t" - ".set pop\n\t" + "move %1,%4\n\t" "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n" + "beqzl %1,1b\n\t" + "ll %0,%3\n\t" + ".set pop\n" + "2:\n\t" + "/* End test and set */" : "=&r" (r), "=&r" (t), "=m" (*p) : "m" (*p), "r" (v) : "memory"); From owner-linux-mips@oss.sgi.com Fri Feb 1 12:57:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11KvJr18080 for linux-mips-outgoing; Fri, 1 Feb 2002 12:57:19 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11KvFd18074 for ; Fri, 1 Feb 2002 12:57:15 -0800 Received: from orion.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 LAA04454 for ; Fri, 1 Feb 2002 11:57:05 -0800 (PST) mail_from (jsun@orion.mvista.com) Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id LAA18199; Fri, 1 Feb 2002 11:52:06 -0800 Date: Fri, 1 Feb 2002 11:52:06 -0800 From: Jun Sun To: linux-mips@oss.sgi.com Subject: gcc 3.x, -ansi and "static inline" Message-ID: <20020201115206.A18085@mvista.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 We are trying to build userland apps with the newer kernel headers. Unexpected problems occur with the "static inline" declaration when "-ansi" option is used. Anybody else is having the problem? Also, what are the reasons for us to switch to "static inline" in the kernel header? Here is an example I am talking about: In 2.4.2, we have in bitops.h: extern __inline__ unsigned long ffz(unsigned long word) In 2.4.17, we have instead: static inline unsigned long ffz(unsigned long word) This problem seems only happening with gcc 3.x. I start to wonder whether we should fix kernel header. In some case, the fix seems to be not exposing to userland (by #ifdef __KERNEL__). In others, the fix might be using __inline__. However, I really like to know what was the original motivation to do such a change. BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary and caused a bunch of similar errors. Jun From owner-linux-mips@oss.sgi.com Fri Feb 1 13:53:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11LrOg18966 for linux-mips-outgoing; Fri, 1 Feb 2002 13:53:24 -0800 Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11LrLd18960 for ; Fri, 1 Feb 2002 13:53:21 -0800 Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g11KrCh99062; Fri, 1 Feb 2002 12:53:12 -0800 (PST) (envelope-from weasel@meer.net) Received: from localhost.meer.net (bob.sonicblue.com [209.10.223.219]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id MAA4669480; Fri, 1 Feb 2002 12:52:59 -0800 (PST) To: binutils@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: me vs gas mips64 relocation References: Reply-To: weasel@cs.stanford.edu From: d p chang Date: 01 Feb 2002 12:52:59 -0800 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk d p chang writes: > i compile this w/ (i only just added all the verbosity flags). > > mips64-linux-gcc -I /Volumes/Homey/dpc/Devel/linux-2.4.17/include/asm/gcc -D__KERNEL__ -I/Volumes/Homey/dpc/Devel/linux-2.4.17/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mips4 -mmad -Wa,-march=r5231 -mlong64 -mgp64 -mfp64 -ffreestanding -mabi=n32 reloc.S -c -o reloc.o -Wa,-acdhls -v -Wa,-v -Wa,-O0 Looking at this some more I realize that my problem is probably that I'm lying to the compiler/assembler by claiming n32 and long64. We would like to have 64 bit registers available to us in user space, but enabling -mabi=64 gives an assertion in ld when it is trying to output relocations for a .pdr section. ideas? (other than for me to take the crack pipe out of my ass) \p --- I feel discomfort, therefore I am alive. --- Graham Greene From owner-linux-mips@oss.sgi.com Fri Feb 1 14:23:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11MNlT19457 for linux-mips-outgoing; Fri, 1 Feb 2002 14:23:47 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11MNid19454 for ; Fri, 1 Feb 2002 14:23:44 -0800 Received: from localhost.localdomain (taarna.sfbay.redhat.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA10372; Fri, 1 Feb 2002 13:23:35 -0800 (PST) Subject: Re: me vs gas mips64 relocation From: Eric Christopher To: weasel@cs.stanford.edu Cc: binutils@sources.redhat.com, linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Feb 2002 13:23:12 -0800 Message-Id: <1012598592.1689.33.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > ideas? (other than for me to take the crack pipe out of my ass) You can try to help Thiemo Seufer finish n32 and n64 support in binutils... -eric -- I will not use abbrev. From owner-linux-mips@oss.sgi.com Fri Feb 1 14:41:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11Mfvs19769 for linux-mips-outgoing; Fri, 1 Feb 2002 14:41:57 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Mfsd19761 for ; Fri, 1 Feb 2002 14:41:54 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA10068; Fri, 1 Feb 2002 22:41:17 +0100 (MET) Date: Fri, 1 Feb 2002 22:41:17 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips In-Reply-To: <20020201094025.A10392@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 1 Feb 2002, H . J . Lu wrote: > Here is the updated patch. Please do indent instructions in branch delay slots like it's done in other code (and here originally as well). It much improves the perception of what exactly is going on. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Feb 1 14:43:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11MhL019866 for linux-mips-outgoing; Fri, 1 Feb 2002 14:43:21 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11MhDd19853; Fri, 1 Feb 2002 14:43:13 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g11LhAX12217; Fri, 1 Feb 2002 13:43:10 -0800 From: "Matthew Dharm" To: "Ralf Baechle" , "Carsten Langgaard" , Cc: Subject: RE: fsck fails on latest 2.4 kernel Date: Fri, 1 Feb 2002 13:43:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020116235232.A2760@dea.linux-mips.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hrm... Looks like I'm getting bitten by this bug also. I'm using H.J.'s toolchain RPMs for building the userspace applications, but the same tools as Carsten for building the kernel. I guess that combination doesn't work, either. Unfortunately, the RPMs that H.J. has put on oss.sgi.com won't install on my system -- wrong version of RedHat. And I don't see the source to his toolchain RPMs, so I can't rebuild it myself for the local libraries. Any suggestions on what the best approach is? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle > Sent: Wednesday, January 16, 2002 11:53 PM > To: Carsten Langgaard > Cc: linux-mips@oss.sgi.com > Subject: Re: fsck fails on latest 2.4 kernel > > > On Thu, Jan 17, 2002 at 08:25:56AM +0100, Carsten Langgaard wrote: > > > > Don't use these for building userspace apps. > > > > I'm only building the kernel with these. > > What are you using for building the kernel ? > > Exactly the binaries which I put on oss. I know that in > the meantime > various problems with them have shown up so I'm waiting for the next > official binutils release to replace them. > > Ralf > From owner-linux-mips@oss.sgi.com Fri Feb 1 15:47:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11NluK21328 for linux-mips-outgoing; Fri, 1 Feb 2002 15:47:56 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11NlVd21316 for ; Fri, 1 Feb 2002 15:47:31 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0F316125C3; Fri, 1 Feb 2002 14:47:28 -0800 (PST) Date: Fri, 1 Feb 2002 14:47:27 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips Message-ID: <20020201144727.A15521@lucon.org> References: <20020201094025.A10392@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 01, 2002 at 10:41:17PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 10:41:17PM +0100, Maciej W. Rozycki wrote: > On Fri, 1 Feb 2002, H . J . Lu wrote: > > > Here is the updated patch. > > Please do indent instructions in branch delay slots like it's done in > other code (and here originally as well). It much improves the perception > of what exactly is going on. > Like this? H.J. ---- 2002-02-01 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Use a different register in the delayed slot. Use branch likely. * sysdeps/mips/pt-machine.h (testandset): Call _test_and_set. (__compare_and_swap): Return 0 only when failed to compare. Use branch likely. 2002-02-01 H.J. Lu * sysdeps/mips/atomicity.h (exchange_and_add): Use branch likely. (atomic_add): Likewise. (compare_and_swap): Return 0 only when failed to compare. Use branch likely. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Use branch likely. --- glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c.llsc Fri Feb 1 10:37:16 2002 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pspinlock.c Fri Feb 1 14:42:46 2002 @@ -29,20 +29,21 @@ int __pthread_spin_lock (pthread_spinlock_t *lock) { - unsigned int tmp; + unsigned int tmp1, tmp2; asm volatile ("\t\t\t# spin_lock\n\t" + "ll %1,%3\n" "1:\n\t" - "ll %1,%2\n\t" ".set push\n\t" ".set noreorder\n\t" "bnez %1,1b\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%0\n\t" - "beqz %1,1b" - : "=m" (*lock), "=&r" (tmp) + " li %2,1\n\t" + "sc %2,%0\n\t" + "beqzl %2,1b\n\t" + " ll %1,%3\n\t" + ".set pop" + : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) : "memory"); --- glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h.llsc Sat Dec 9 08:55:34 2000 +++ glibc-2.2.4/linuxthreads/sysdeps/mips/pt-machine.h Fri Feb 1 14:42:20 2002 @@ -33,41 +33,11 @@ /* Spinlock implementation; required. */ -#if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - -PT_EI long int -testandset (int *spinlock) -{ - long int ret, temp; - - __asm__ __volatile__ - ("/* Inline spinlock test & set */\n\t" - "1:\n\t" - "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "bnez %0,2f\n\t" - " li %1,1\n\t" - ".set pop\n\t" - "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n\t" - "/* End spinlock test & set */" - : "=&r" (ret), "=&r" (temp), "=m" (*spinlock) - : "m" (*spinlock) - : "memory"); - - return ret; -} - -#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - PT_EI long int testandset (int *spinlock) { return _test_and_set (spinlock, 1); } -#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ /* Get some notion of the current stack. Need not be exactly the top @@ -84,22 +54,24 @@ register char * stack_pointer __asm__ (" PT_EI int __compare_and_swap (long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ ("/* Inline compare & swap */\n\t" + "ll %1,%5\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - " move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + " move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqzl %0,1b\n\t" + " ll %1,%5\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/mips/atomicity.h.llsc Mon Jul 9 11:58:19 2001 +++ glibc-2.2.4/sysdeps/mips/atomicity.h Fri Feb 1 14:43:34 2002 @@ -33,11 +33,15 @@ exchange_and_add (volatile uint32_t *mem __asm__ __volatile__ ("/* Inline exchange & add */\n\t" + "ll %0,%3\n" "1:\n\t" - "ll %0,%3\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" - "beqz %1,1b\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beqzl %1,1b\n\t" + " ll %0,%3\n\t" + ".set pop\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) : "m" (*mem), "r"(val) @@ -54,11 +58,15 @@ atomic_add (volatile uint32_t *mem, int __asm__ __volatile__ ("/* Inline atomic add */\n\t" + "ll %0,%2\n" "1:\n\t" - "ll %0,%2\n\t" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" - "beqz %0,1b\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beqzl %0,1b\n\t" + " ll %0,%2\n\t" + ".set pop\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) : "m" (*mem), "r"(val) @@ -69,22 +77,24 @@ static inline int __attribute__ ((unused)) compare_and_swap (volatile long int *p, long int oldval, long int newval) { - long int ret; + long int ret, temp; __asm__ __volatile__ ("/* Inline compare & swap */\n\t" + "ll %1,%5\n" "1:\n\t" - "ll %0,%4\n\t" - ".set push\n" + ".set push\n\t" ".set noreorder\n\t" - "bne %0,%2,2f\n\t" - "move %0,%3\n\t" - ".set pop\n\t" - "sc %0,%1\n\t" - "beqz %0,1b\n" + "bne %1,%3,2f\n\t" + " move %0,$0\n\t" + "move %0,%4\n\t" + "sc %0,%2\n\t" + "beqzl %0,1b\n\t" + " ll %1,%5\n\t" + ".set pop\n" "2:\n\t" "/* End compare & swap */" - : "=&r" (ret), "=m" (*p) + : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); --- glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Jul 9 11:58:45 2001 +++ glibc-2.2.4/sysdeps/unix/sysv/linux/mips/sys/tas.h Fri Feb 1 14:43:52 2002 @@ -42,16 +42,19 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("1:\n\t" - "ll %0,%3\n\t" + ("/* Inline test and set */\n\t" + "ll %0,%3\n" + "1:\n\t" ".set push\n\t" ".set noreorder\n\t" "beq %0,%4,2f\n\t" " move %1,%4\n\t" - ".set pop\n\t" "sc %1,%2\n\t" - "beqz %1,1b\n" - "2:\n" + "beqzl %1,1b\n\t" + " ll %0,%3\n\t" + ".set pop\n" + "2:\n\t" + "/* End test and set */" : "=&r" (r), "=&r" (t), "=m" (*p) : "m" (*p), "r" (v) : "memory"); From owner-linux-mips@oss.sgi.com Fri Feb 1 15:52:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g11Nqr021452 for linux-mips-outgoing; Fri, 1 Feb 2002 15:52:53 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11Nqmd21449; Fri, 1 Feb 2002 15:52:48 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8B15C125C3; Fri, 1 Feb 2002 14:52:44 -0800 (PST) Date: Fri, 1 Feb 2002 14:52:44 -0800 From: "H . J . Lu" To: Matthew Dharm Cc: Ralf Baechle , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel Message-ID: <20020201145244.B15521@lucon.org> References: <20020116235232.A2760@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Fri, Feb 01, 2002 at 01:43:10PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 01:43:10PM -0800, Matthew Dharm wrote: > Hrm... Looks like I'm getting bitten by this bug also. > > I'm using H.J.'s toolchain RPMs for building the userspace > applications, but the same tools as Carsten for building the kernel. > I guess that combination doesn't work, either. > > Unfortunately, the RPMs that H.J. has put on oss.sgi.com won't install > on my system -- wrong version of RedHat. And I don't see the source > to his toolchain RPMs, so I can't rebuild it myself for the local > libraries. My toolchain source rpm is on oss.sgi.com: ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/toolchain-20011020-1.src.rpm H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 16:02:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12026P21984 for linux-mips-outgoing; Fri, 1 Feb 2002 16:02:06 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12023d21980 for ; Fri, 1 Feb 2002 16:02:03 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16WmgQ-0006BJ-00; Fri, 01 Feb 2002 18:01:26 -0500 Date: Fri, 1 Feb 2002 18:01:26 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020201180126.A23740@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020201102943.A11146@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote: > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > > think you don't have to do that by hand. > > > > > > It will make the code more readable. We don't have to guess what > > > the assembler will do. > > > > But you lose a chance for something useful being reordered to the slot. > > That might not necessarily be a "nop". Please don't forget of indents > > anyway. > > > > Here is a new patch. I use branch likely to get rid of nops. Please > tell me which indents I may have missed. Can you really assume presence of the branch-likely instruction? I don't think so. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Feb 1 16:03:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1203fa22123 for linux-mips-outgoing; Fri, 1 Feb 2002 16:03:41 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1203Yd22114; Fri, 1 Feb 2002 16:03:34 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g11N3VX12727; Fri, 1 Feb 2002 15:03:31 -0800 From: "Matthew Dharm" To: "H . J . Lu" Cc: "Ralf Baechle" , "Carsten Langgaard" , Subject: RE: fsck fails on latest 2.4 kernel Date: Fri, 1 Feb 2002 15:03:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020201145244.B15521@lucon.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Okay... I'm a moron. I totally missed that SRPM after looking more than 3 times. Maybe I need stronger coffee.... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of H . J . Lu > Sent: Friday, February 01, 2002 2:53 PM > To: Matthew Dharm > Cc: Ralf Baechle; Carsten Langgaard; linux-mips@oss.sgi.com > Subject: Re: fsck fails on latest 2.4 kernel > > > On Fri, Feb 01, 2002 at 01:43:10PM -0800, Matthew Dharm wrote: > > Hrm... Looks like I'm getting bitten by this bug also. > > > > I'm using H.J.'s toolchain RPMs for building the userspace > > applications, but the same tools as Carsten for building > the kernel. > > I guess that combination doesn't work, either. > > > > Unfortunately, the RPMs that H.J. has put on oss.sgi.com > won't install > > on my system -- wrong version of RedHat. And I don't see > the source > > to his toolchain RPMs, so I can't rebuild it myself for the local > > libraries. > > My toolchain source rpm is on oss.sgi.com: > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/toolchain- > 20011020-1.src.rpm > > > H.J. > From owner-linux-mips@oss.sgi.com Fri Feb 1 16:15:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g120FLM22801 for linux-mips-outgoing; Fri, 1 Feb 2002 16:15:21 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g120FHd22797 for ; Fri, 1 Feb 2002 16:15:17 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 37BA2125C3; Fri, 1 Feb 2002 15:15:14 -0800 (PST) Date: Fri, 1 Feb 2002 15:15:13 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020201151513.A15913@lucon.org> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020201180126.A23740@nevyn.them.org>; from dan@debian.org on Fri, Feb 01, 2002 at 06:01:26PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 06:01:26PM -0500, Daniel Jacobowitz wrote: > On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote: > > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > > > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > > > think you don't have to do that by hand. > > > > > > > > It will make the code more readable. We don't have to guess what > > > > the assembler will do. > > > > > > But you lose a chance for something useful being reordered to the slot. > > > That might not necessarily be a "nop". Please don't forget of indents > > > anyway. > > > > > > > Here is a new patch. I use branch likely to get rid of nops. Please > > tell me which indents I may have missed. > > Can you really assume presence of the branch-likely instruction? I > don't think so. Why not? Can you show me a MIPS II or above CPU which doesn't have branch-likely instruction? From gcc, /* ISA has branch likely instructions (eg. mips2). */ /* Disable branchlikely for tx39 until compare rewrite. They haven't been generated up to this point. */ #define ISA_HAS_BRANCHLIKELY (mips_isa != 1 \ /* || TARGET_MIPS3900 */) Did I miss something? H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 18:09:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12298V25670 for linux-mips-outgoing; Fri, 1 Feb 2002 18:09:08 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12290d25660; Fri, 1 Feb 2002 18:09:00 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1218vX13253; Fri, 1 Feb 2002 17:08:57 -0800 From: "Matthew Dharm" To: "H . J . Lu" Cc: "Ralf Baechle" , "Carsten Langgaard" , Subject: RE: fsck fails on latest 2.4 kernel Date: Fri, 1 Feb 2002 17:08:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020201145244.B15521@lucon.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk As an aside, it looks like you can't rebuild this from source without gettext installed, but that isn't a pre-req given in the spec file. It looks like there is code to detect gettext and substitute a local copy if it's not available, but that code doesn't seem to work right. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: H . J . Lu [mailto:hjl@lucon.org] > Sent: Friday, February 01, 2002 2:53 PM > To: Matthew Dharm > Cc: Ralf Baechle; Carsten Langgaard; linux-mips@oss.sgi.com > Subject: Re: fsck fails on latest 2.4 kernel > > > On Fri, Feb 01, 2002 at 01:43:10PM -0800, Matthew Dharm wrote: > > Hrm... Looks like I'm getting bitten by this bug also. > > > > I'm using H.J.'s toolchain RPMs for building the userspace > > applications, but the same tools as Carsten for building > the kernel. > > I guess that combination doesn't work, either. > > > > Unfortunately, the RPMs that H.J. has put on oss.sgi.com > won't install > > on my system -- wrong version of RedHat. And I don't see > the source > > to his toolchain RPMs, so I can't rebuild it myself for the local > > libraries. > > My toolchain source rpm is on oss.sgi.com: > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/toolchain- > 20011020-1.src.rpm > > > H.J. > From owner-linux-mips@oss.sgi.com Fri Feb 1 18:47:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g122lkf26148 for linux-mips-outgoing; Fri, 1 Feb 2002 18:47:46 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g122lgd26145; Fri, 1 Feb 2002 18:47:42 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9AFCC125C3; Fri, 1 Feb 2002 17:47:38 -0800 (PST) Date: Fri, 1 Feb 2002 17:47:38 -0800 From: "H . J . Lu" To: Matthew Dharm Cc: Ralf Baechle , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: fsck fails on latest 2.4 kernel Message-ID: <20020201174738.A18322@lucon.org> References: <20020201145244.B15521@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Fri, Feb 01, 2002 at 05:08:57PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 05:08:57PM -0800, Matthew Dharm wrote: > As an aside, it looks like you can't rebuild this from source without > gettext installed, but that isn't a pre-req given in the spec file. > > It looks like there is code to detect gettext and substitute a local > copy if it's not available, but that code doesn't seem to work right. > There are many things left out, like gcc, binutils, glibc-devel, ..... I don't like to list all of them. It should be no different to bootstrap gcc. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 1 19:37:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g123baQ26856 for linux-mips-outgoing; Fri, 1 Feb 2002 19:37:36 -0800 Received: from ns6.sony.co.jp (NS6.Sony.CO.JP [146.215.0.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g123bWd26853 for ; Fri, 1 Feb 2002 19:37:32 -0800 Received: from mail2.sony.co.jp (mail2.sony.co.jp [43.0.1.202]) by ns6.sony.co.jp (R8/Sony) with ESMTP id g122bJW20863; Sat, 2 Feb 2002 11:37:19 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g122bIH12818; Sat, 2 Feb 2002 11:37:18 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g122bIA12810; Sat, 2 Feb 2002 11:37:18 +0900 (JST) Received: from imail.sm.sony.co.jp (imail.sm.sony.co.jp [43.2.217.16]) by smail1.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id LAA08031; Sat, 2 Feb 2002 11:41:56 +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 LAA20470; Sat, 2 Feb 2002 11:37:17 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g122bHJ12472; Sat, 2 Feb 2002 11:37:17 +0900 (JST) Date: Sat, 02 Feb 2002 11:37:17 +0900 (JST) Message-Id: <20020202.113717.68552217.machida@sm.sony.co.jp> To: hjl@lucon.org Cc: macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) From: Hiroyuki Machida In-Reply-To: <20020201151513.A15913@lucon.org> References: <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> 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 From: "H . J . Lu" Subject: Re: PATCH: Fix ll/sc for mips (take 3) Date: Fri, 1 Feb 2002 15:15:13 -0800 > Why not? Can you show me a MIPS II or above CPU which doesn't have > branch-likely instruction? From gcc, > > /* ISA has branch likely instructions (eg. mips2). */ > /* Disable branchlikely for tx39 until compare rewrite. They haven't > been generated up to this point. */ > #define ISA_HAS_BRANCHLIKELY (mips_isa != 1 \ > /* || TARGET_MIPS3900 */) > > Did I miss something? I think we can assume CPU has branch-likely insns, if CPU has MIPS ISA 2 or greater ISA, as H.J said. I don't know any exception of this. If anyone know exceptions, please let us know. (FYI: we can't assume CPU has LL/SC even if CPU has branch-likely insns. ) HL's patch looks good for me. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Fri Feb 1 20:27:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g124RC527590 for linux-mips-outgoing; Fri, 1 Feb 2002 20:27:12 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g124R7d27586 for ; Fri, 1 Feb 2002 20:27:07 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16WqpN-0003TY-00; Fri, 01 Feb 2002 22:26:57 -0500 Date: Fri, 1 Feb 2002 22:26:57 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020201222657.A13339@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020201151513.A15913@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 03:15:13PM -0800, H . J . Lu wrote: > On Fri, Feb 01, 2002 at 06:01:26PM -0500, Daniel Jacobowitz wrote: > > On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote: > > > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > > > > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > > > > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > > > > think you don't have to do that by hand. > > > > > > > > > > It will make the code more readable. We don't have to guess what > > > > > the assembler will do. > > > > > > > > But you lose a chance for something useful being reordered to the slot. > > > > That might not necessarily be a "nop". Please don't forget of indents > > > > anyway. > > > > > > > > > > Here is a new patch. I use branch likely to get rid of nops. Please > > > tell me which indents I may have missed. > > > > Can you really assume presence of the branch-likely instruction? I > > don't think so. > > Why not? Can you show me a MIPS II or above CPU which doesn't have > branch-likely instruction? From gcc, > > /* ISA has branch likely instructions (eg. mips2). */ > /* Disable branchlikely for tx39 until compare rewrite. They haven't > been generated up to this point. */ > #define ISA_HAS_BRANCHLIKELY (mips_isa != 1 \ > /* || TARGET_MIPS3900 */) > > Did I miss something? My fault. I was indeed thinking of the tx39, which is not normally MIPS2. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Feb 1 23:23:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g127N7130451 for linux-mips-outgoing; Fri, 1 Feb 2002 23:23:07 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g127N4d30447 for ; Fri, 1 Feb 2002 23:23:04 -0800 Message-Id: <200202020723.g127N4d30447@oss.sgi.com> Received: (qmail 5953 invoked from network); 2 Feb 2002 06:22:56 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 2 Feb 2002 06:22:56 -0000 Date: Sat, 2 Feb 2002 14:20:6 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: used_math not cleared for new processes? 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,linux-mips, I find that current->used_math isn't cleared when we start a new process.Is it intended? I mean 'start_thread' in do_exec but not 'copy_thread' in do_fork when speaking 'start a new process'. We can/should? keep used_math for the latter,but for the former? It leads to a failure in libm-test(the fpu control register doesn't equal to default) I think the reason is that init_fpu fail to be called with used_math set. BTW: besides this failure,i see a lot of more related to extra "Invalid operation" exception. e.g.: exp(NaN) == NaN: Exception "Invalid operation" set fmax (0, NaN) == 0: Exception "Invalid operation" set .. My cpu is IDT RC64474,which is basically a r4600. I think the cause probably is mips's special SNaN and QNaN handling. Could somebody explain? Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Sat Feb 2 02:18:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12AI9P00933 for linux-mips-outgoing; Sat, 2 Feb 2002 02:18:09 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12AI3d00930 for ; Sat, 2 Feb 2002 02:18:03 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA13347; Sat, 2 Feb 2002 10:17:49 +0100 (MET) Date: Sat, 2 Feb 2002 10:17:50 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: Linux/MIPS Development Subject: Re: gcc 3.x, -ansi and "static inline" In-Reply-To: <20020201115206.A18085@mvista.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, 1 Feb 2002, Jun Sun wrote: > We are trying to build userland apps with the newer kernel headers. > Unexpected problems occur with the "static inline" declaration > when "-ansi" option is used. > > Anybody else is having the problem? > > Also, what are the reasons for us to switch to "static inline" in the > kernel header? > > Here is an example I am talking about: > > In 2.4.2, we have in bitops.h: > > extern __inline__ unsigned long ffz(unsigned long word) > > In 2.4.17, we have instead: > > static inline unsigned long ffz(unsigned long word) > > This problem seems only happening with gcc 3.x. I start to wonder > whether we should fix kernel header. In some case, the fix seems > to be not exposing to userland (by #ifdef __KERNEL__). In others, > the fix might be using __inline__. Yes, #ifdef __KERNEL__ is the right fix. > However, I really like to know what was the original motivation > to do such a change. See linux-kernel 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 Sat Feb 2 04:06:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12C6kx02652 for linux-mips-outgoing; Sat, 2 Feb 2002 04:06:46 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12C6fd02648 for ; Sat, 2 Feb 2002 04:06:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA22923; Sat, 2 Feb 2002 12:06:07 +0100 (MET) Date: Sat, 2 Feb 2002 12:06:07 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips In-Reply-To: <20020201144727.A15521@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 1 Feb 2002, H . J . Lu wrote: > > Please do indent instructions in branch delay slots like it's done in > > other code (and here originally as well). It much improves the perception > > of what exactly is going on. > > Like this? Exactly. Thanks. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Sat Feb 2 05:11:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12DB2P03760 for linux-mips-outgoing; Sat, 2 Feb 2002 05:11:02 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12DAhd03748 for ; Sat, 2 Feb 2002 05:10:43 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA24037; Sat, 2 Feb 2002 13:09:48 +0100 (MET) Date: Sat, 2 Feb 2002 13:09:47 +0100 (MET) From: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com cc: jgg@debian.org Subject: Re: [patch] linux 2.4.17: An mb() rework 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 Fri, 1 Feb 2002, Maciej W. Rozycki wrote: > Well, after looking at the Alpha Architecture Handbook I see "mb" and > "wmb" are pure ordering barriers -- any transactions at the CPU bus (pins) > may still be deferred or prefetched (architecturally -- can't comment on > specific chips). So after all, maybe all the macros should be purely > "sync" for MIPS ("" for MIPS I, and mb() equal to wbflush() for R3220 and > similar setups) and anything that wants to see all writes actually > committed should use wbflush(), which would be defined as "mb(); > uncached_read();" (or in a system-specific way, for R3220, etc.)? > > The i386 implementation seems stronger than it should be, but that's > probably because of the limited choice available. > > Any thoughts? Well, I've seen no thoughts so far. :-( Anyway here is a new patch, which takes my considerations about a synchronization vs a write commitment into account. This implementation only assures the absolute minimum specified in the operations. I am also tempted to add "#define iob() wbflush()" to system.h and attempt to define the macro for other architectures as well. The intended semantics is to assure all preceding transactions arrived at a system bus and none of following ones were started yet. The "system bus" here is defined: "the bus that connects the bus controller of a CPU (whether internal to the chip or not) to the rest of a system." -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.17-20020111-mb-wb-1 diff -up --recursive --new-file linux-mips-2.4.17-20020111.macro/arch/mips/config.in linux-mips-2.4.17-20020111/arch/mips/config.in --- linux-mips-2.4.17-20020111.macro/arch/mips/config.in Mon Jan 7 05:27:13 2002 +++ linux-mips-2.4.17-20020111/arch/mips/config.in Sat Jan 26 02:35:35 2002 @@ -363,6 +363,12 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" -o \ + "$CONFIG_CPU_TX39XX" = "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-20020111.macro/include/asm-mips/system.h linux-mips-2.4.17-20020111/include/asm-mips/system.h --- linux-mips-2.4.17-20020111.macro/include/asm-mips/system.h Thu Dec 13 05:28:09 2001 +++ linux-mips-2.4.17-20020111/include/asm-mips/system.h Sat Feb 2 00:05:19 2002 @@ -167,32 +167,31 @@ 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__("sync" : : : "memory") +#else +#define __sync() do { } while(0) +#endif + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() + #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(); + +#else /* !CONFIG_CPU_HAS_WB */ + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() + +#endif /* !CONFIG_CPU_HAS_WB */ #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.17-20020111.macro/include/asm-mips/wbflush.h linux-mips-2.4.17-20020111/include/asm-mips/wbflush.h --- linux-mips-2.4.17-20020111.macro/include/asm-mips/wbflush.h Fri Sep 7 04:26:33 2001 +++ linux-mips-2.4.17-20020111/include/asm-mips/wbflush.h Sat Feb 2 00:05:21 2002 @@ -6,28 +6,49 @@ * 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); +#include +#include -#define wbflush() __wbflush() +#define __fast_wbflush() \ + __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_wbflush() \ + do { \ + fast_mb(); \ + __fast_wbflush(); \ + } while (0) + + +#ifdef CONFIG_CPU_HAS_WB + +extern void (*__wbflush)(void); + +#define wbflush() \ + do { \ + fast_mb(); \ + __wbflush(); \ + } while (0) -#else -/* - * we don't need no stinkin' wbflush - */ +#else /* !CONFIG_CPU_HAS_WB */ -#define wbflush() do { } while(0) +#define wbflush() fast_wbflush() -#endif +#endif /* !CONFIG_CPU_HAS_WB */ extern void wbflush_setup(void); From owner-linux-mips@oss.sgi.com Sat Feb 2 11:52:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12Jqbv14167 for linux-mips-outgoing; Sat, 2 Feb 2002 11:52:37 -0800 Received: from xyzzy.stargate.net ([198.144.45.122]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12JqUd14163 for ; Sat, 2 Feb 2002 11:52:30 -0800 Received: (from justin@localhost) by xyzzy.stargate.net (8.11.6/8.11.6) id g12IrOg01938; Sat, 2 Feb 2002 13:53:24 -0500 X-Authentication-Warning: xyzzy.stargate.net: justin set sender to justinca@ri.cmu.edu using -f Subject: Re: PATCH: Fix ll/sc for mips (take 3) From: Justin Carlson To: Daniel Jacobowitz Cc: "H . J . Lu" , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com In-Reply-To: <20020201222657.A13339@nevyn.them.org> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 02 Feb 2002 13:53:23 -0500 Message-Id: <1012676003.1563.6.camel@xyzzy.stargate.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2002-02-01 at 22:26, Daniel Jacobowitz wrote: > On Fri, Feb 01, 2002 at 03:15:13PM -0800, H . J . Lu wrote: > > On Fri, Feb 01, 2002 at 06:01:26PM -0500, Daniel Jacobowitz wrote: > > > On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote: > > > > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > > > > > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > > > > > > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > > > > > think you don't have to do that by hand. > > > > > > > > > > > > It will make the code more readable. We don't have to guess what > > > > > > the assembler will do. > > > > > > > > > > But you lose a chance for something useful being reordered to the slot. > > > > > That might not necessarily be a "nop". Please don't forget of indents > > > > > anyway. > > > > > > > > > > > > > Here is a new patch. I use branch likely to get rid of nops. Please > > > > tell me which indents I may have missed. > > > > > > Can you really assume presence of the branch-likely instruction? I > > > don't think so. > > Actually, regardless of whether modern cpus implement it, I'd argue that avoiding the branch likely is a good idea for 2 reasons: 1) In the latest MIPS specs (mips32 and mips64) branch likelies have officially been deprecated as probable removals from the architecture in the not-too-distant future. 2) More importantly, most implementations don't use any sort of dynamic branch prediction on branch likelies. They predict taken, always, since that's the specified intent (it's a branch *likely* to be taken). For most spin locks, the normal behaviour is a fall through, not taking that branch, so you're inflicting a branch mispredict penalty on every lock grabbed without contention. Even for locks which the general case is contention, giving the processor branch predictor a chance to learn that is a Good Idea. -Justin From owner-linux-mips@oss.sgi.com Sat Feb 2 13:04:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12L42Z20444 for linux-mips-outgoing; Sat, 2 Feb 2002 13:04:02 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12L3wd20441 for ; Sat, 2 Feb 2002 13:03:59 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 29000125C3; Sat, 2 Feb 2002 12:03:54 -0800 (PST) Date: Sat, 2 Feb 2002 12:03:54 -0800 From: "H . J . Lu" To: Justin Carlson Cc: Daniel Jacobowitz , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020202120354.A1522@lucon.org> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1012676003.1563.6.camel@xyzzy.stargate.net>; from justinca@ri.cmu.edu on Sat, Feb 02, 2002 at 01:53:23PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Feb 02, 2002 at 01:53:23PM -0500, Justin Carlson wrote: > > Actually, regardless of whether modern cpus implement it, I'd argue that > avoiding the branch likely is a good idea for 2 reasons: > > 1) In the latest MIPS specs (mips32 and mips64) branch likelies have > officially been deprecated as probable removals from the architecture in > the not-too-distant future. > > 2) More importantly, most implementations don't use any sort of dynamic > branch prediction on branch likelies. They predict taken, always, since > that's the specified intent (it's a branch *likely* to be taken). For > most spin locks, the normal behaviour is a fall through, not taking that > branch, so you're inflicting a branch mispredict penalty on every lock > grabbed without contention. Even for locks which the general case is > contention, giving the processor branch predictor a chance to learn that > is a Good Idea. > Does everyone agree with this? If yes, I can make a patch not to use branch likely. But on the other hand, "gcc -mips2" will generate code using branch likely. If branch likely doesn't buy you anything, shouldn't we change gcc not to generate branch likely instructions? H.J. From owner-linux-mips@oss.sgi.com Sat Feb 2 13:49:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12Lnmu27535 for linux-mips-outgoing; Sat, 2 Feb 2002 13:49:48 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12Lnjd27484 for ; Sat, 2 Feb 2002 13:49:45 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA29253; Sat, 2 Feb 2002 12:49:35 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA22911; Sat, 2 Feb 2002 12:49:32 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g12Kn7A24635; Sat, 2 Feb 2002 21:49:07 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id VAA15305; Sat, 2 Feb 2002 21:49:29 +0100 (MET) Message-Id: <200202022049.VAA15305@copsun18.mips.com> Subject: Re: PATCH: Fix ll/sc for mips (take 3) To: hjl@lucon.org (H . J . Lu) Date: Sat, 2 Feb 2002 21:49:29 +0100 (MET) Cc: justinca@ri.cmu.edu (Justin Carlson), dan@debian.org (Daniel Jacobowitz), macro@ds2.pg.gda.pl (Maciej W. Rozycki), machida@sm.sony.co.jp (Hiroyuki Machida), libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org In-Reply-To: <20020202120354.A1522@lucon.org> from "H . J . Lu" at Feb 02, 2002 12:03:54 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 H . J . Lu writes: > Does everyone agree with this? If yes, I can make a patch not to use > branch likely. But on the other hand, "gcc -mips2" will generate code > using branch likely. If branch likely doesn't buy you anything, > shouldn't we change gcc not to generate branch likely instructions? I would say it's still too early to actively remove them. There are many processors out there (certainly in the embedded world most of them) without branch prediction, and for all of those branch-likelys actually help performance. /Hartvig From owner-linux-mips@oss.sgi.com Sun Feb 3 00:26:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138QlU05654 for linux-mips-outgoing; Sun, 3 Feb 2002 00:26:47 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138QjA05651 for ; Sun, 3 Feb 2002 00:26:45 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16XH35-0000V1-00; Sun, 03 Feb 2002 02:26:51 -0500 Date: Sun, 3 Feb 2002 02:26:51 -0500 From: Daniel Jacobowitz To: weasel@cs.stanford.edu Cc: Eric Christopher , binutils@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: me vs gas mips64 relocation Message-ID: <20020203022651.A1903@nevyn.them.org> Mail-Followup-To: weasel@cs.stanford.edu, Eric Christopher , binutils@sources.redhat.com, linux-mips@oss.sgi.com References: <1012598592.1689.33.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Feb 02, 2002 at 08:47:30PM -0800, d p chang wrote: > Eric Christopher writes: > > > > ideas? (other than for me to take the crack pipe out of my ass) > > > > You can try to help Thiemo Seufer finish n32 and n64 support in > > binutils... > > Is there a todo or something that I could start w/? Search for TODO in elf64-mips.c, if I recall correctly. Among other things PIC support is non-functional. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Sun Feb 3 00:43:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g138hT206043 for linux-mips-outgoing; Sun, 3 Feb 2002 00:43:29 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g138hLA05993 for ; Sun, 3 Feb 2002 00:43:21 -0800 Received: from xyzzy.stargate.net ([198.144.45.122]) 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 VAA00825 for ; Sat, 2 Feb 2002 21:50:15 -0800 (PST) mail_from (justinca@ri.cmu.edu) Received: (from justin@localhost) by xyzzy.stargate.net (8.11.6/8.11.6) id g135lVu02334; Sun, 3 Feb 2002 00:47:31 -0500 X-Authentication-Warning: xyzzy.stargate.net: justin set sender to justinca@ri.cmu.edu using -f Subject: Re: PATCH: Fix ll/sc for mips (take 3) From: Justin Carlson To: "H . J . Lu" Cc: Daniel Jacobowitz , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org In-Reply-To: <20020202120354.A1522@lucon.org> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 03 Feb 2002 00:47:30 -0500 Message-Id: <1012715250.2297.9.camel@xyzzy.stargate.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 2002-02-02 at 15:03, H . J . Lu wrote: > On Sat, Feb 02, 2002 at 01:53:23PM -0500, Justin Carlson wrote: > > > > Actually, regardless of whether modern cpus implement it, I'd argue that > > avoiding the branch likely is a good idea for 2 reasons: > > > > 1) In the latest MIPS specs (mips32 and mips64) branch likelies have > > officially been deprecated as probable removals from the architecture in > > the not-too-distant future. > > > > 2) More importantly, most implementations don't use any sort of dynamic > > branch prediction on branch likelies. They predict taken, always, since > > that's the specified intent (it's a branch *likely* to be taken). For > > most spin locks, the normal behaviour is a fall through, not taking that > > branch, so you're inflicting a branch mispredict penalty on every lock > > grabbed without contention. Even for locks which the general case is > > contention, giving the processor branch predictor a chance to learn that > > is a Good Idea. > > > > Does everyone agree with this? If yes, I can make a patch not to use > branch likely. But on the other hand, "gcc -mips2" will generate code > using branch likely. If branch likely doesn't buy you anything, > shouldn't we change gcc not to generate branch likely instructions? > I know of at least one internal version of gcc which already has been hacked to remove generation of branch likely instructions. It actually helped performance a bit because gcc has (possibly had, this was 6-9 months ago) the bad habit of generating code like this: beqzl $1, next daddiu $2, $3, 1 next: ... This looks like a nice, compact way to do a conditional move. In practice, it's a horrendous idea due to the lack of consideration of the branch prediction. It's easier to tell the compiler not to generate branch likelies than to try to fix the code generation for this case. :) Also, I didn't say branch likely doesn't buy you anything; there are situations where it works well. Looking at the spin_lock code, though, this isn't one of them. The cases where it is a win are far enough between that my personal practice is to generally avoid them. -Justin From owner-linux-mips@oss.sgi.com Sun Feb 3 01:34:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g139Y1N07084 for linux-mips-outgoing; Sun, 3 Feb 2002 01:34:01 -0800 Received: from dea.linux-mips.net (a1as10-p200.stg.tli.de [195.252.189.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g139XuA07078 for ; Sun, 3 Feb 2002 01:33:57 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g138Wra20903; Sun, 3 Feb 2002 09:32:53 +0100 Date: Sun, 3 Feb 2002 09:32:53 +0100 From: Ralf Baechle To: Girish Gulawani Cc: "MIPS/Linux List (SGI)" Subject: Re: MIPS/Linux NonSGI Message-ID: <20020203093253.J20021@dea.linux-mips.net> References: <3C505900.9685DDE3@cotw.com> <003901c1a532$d01576e0$de920dd3@gol.com> <20020124174521.B8860@dea.linux-mips.net> <007001c1a97a$6e52a9e0$c1900dd3@gol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007001c1a97a$6e52a9e0$c1900dd3@gol.com>; from girishvg@yahoo.com on Wed, Jan 30, 2002 at 07:39:41PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Jan 30, 2002 at 07:39:41PM +0900, Girish Gulawani wrote: > could solve the disk corruption problem, thanks to you. it was due to my > over-confident source code for bus mastering device. while re-targeting the > driver from vxworks to linux i had introduced a bug. its all working great > now. thanks again. while this problem is solved i have one more query. > > as i mentioned earlier, our core supports page size of 16K. hence the mmu > code is changed accordingly, for kernel 2.4.9. but any command load fails > giving page alignment error. seems some problem from binfmt_elf.c file. i > have build the command, ash, using egcc-2.91.66. to change the page > alignment the option given was "--n16384". this option is surely wrong, > hence could you tell me what is correct option? HOW TO CHANGE PAGE ALIGNMENT > TO 16K WHILE LINKING USER COMMANDS?? I hate to say it but at this time we don't support any other pagesize than 4kb on MIPS. I haven't looked into details but I'd expect to hit a number of subtle bugs when we go to a larger pagesize. So I expect your way to be stony. Ralf From owner-linux-mips@oss.sgi.com Sun Feb 3 01:33:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g139XYm07023 for linux-mips-outgoing; Sun, 3 Feb 2002 01:33:34 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g139XWA07020 for ; Sun, 3 Feb 2002 01:33:32 -0800 Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) 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 UAA08933 for ; Sat, 2 Feb 2002 20:51:55 -0800 (PST) mail_from (weasel@meer.net) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g134m6X22934; Sat, 2 Feb 2002 20:48:06 -0800 (PST) (envelope-from weasel@meer.net) Received: from localhost.meer.net (ptn-133.mv.meer.net [209.157.137.133]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id UAA4873664; Sat, 2 Feb 2002 20:47:30 -0800 (PST) To: Eric Christopher , binutils@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: me vs gas mips64 relocation References: <1012598592.1689.33.camel@ghostwheel.cygnus.com> Reply-To: weasel@cs.stanford.edu From: d p chang Date: 02 Feb 2002 20:47:30 -0800 In-Reply-To: <1012598592.1689.33.camel@ghostwheel.cygnus.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Eric Christopher writes: > > ideas? (other than for me to take the crack pipe out of my ass) > > You can try to help Thiemo Seufer finish n32 and n64 support in > binutils... Is there a todo or something that I could start w/? \p From owner-linux-mips@oss.sgi.com Sun Feb 3 02:31:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13AVhX13308 for linux-mips-outgoing; Sun, 3 Feb 2002 02:31:43 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13AVeA13290 for ; Sun, 3 Feb 2002 02:31:40 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA00195 for ; Sat, 2 Feb 2002 18:34:32 -0800 (PST) mail_from (drepper@redhat.com) Received: from myware.mynet (fiendish.sfbay.redhat.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA01398; Sat, 2 Feb 2002 18:29:56 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g132TpP17826; Sat, 2 Feb 2002 18:29:51 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips References: <20020201094025.A10392@lucon.org> <20020201144727.A15521@lucon.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 02 Feb 2002 18:29:51 -0800 In-Reply-To: <20020201144727.A15521@lucon.org> Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" writes: > Like this? > [...] >From what I've seen this patch was generally agreed on. I've checked it in. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Sun Feb 3 10:02:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13I2xt11590 for linux-mips-outgoing; Sun, 3 Feb 2002 10:02:59 -0800 Received: from dea.linux-mips.net (a1as04-p166.stg.tli.de [195.252.186.166]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13I2tA11587 for ; Sun, 3 Feb 2002 10:02:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g13H1pl05691; Sun, 3 Feb 2002 18:01:51 +0100 Date: Sun, 3 Feb 2002 18:01:51 +0100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: gcc 3.x, -ansi and "static inline" Message-ID: <20020203180151.A5371@dea.linux-mips.net> References: <20020201115206.A18085@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020201115206.A18085@mvista.com>; from jsun@mvista.com on Fri, Feb 01, 2002 at 11:52:06AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote: > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary > and caused a bunch of similar errors. Indeed, it was pointless and I therefore removed it. Ralf From owner-linux-mips@oss.sgi.com Sun Feb 3 11:38:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g13JcUj03259 for linux-mips-outgoing; Sun, 3 Feb 2002 11:38:30 -0800 Received: from dea.linux-mips.net (a1as09-p51.stg.tli.de [195.252.189.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g13JcQA03256 for ; Sun, 3 Feb 2002 11:38:26 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g13IbHY06652; Sun, 3 Feb 2002 19:37:17 +0100 Date: Sun, 3 Feb 2002 19:37:17 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20020203193717.B6317@dea.linux-mips.net> References: <200202022138.g12LcZU24388@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 macro@ds2.pg.gda.pl on Sun, Feb 03, 2002 at 07:18:01PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 07:18:01PM +0100, Maciej W. Rozycki wrote: > > Log message: > > i8259.c assumes that i8259 are interrupt 0 to 15. Change DDB5476 > > code accordingly. > > Hmm, the assumption might be justifiable for the i386 only? Shouldn't > i8259.c be fixed instead? These are the ISA interrupts; many drivers make assumptions about the interrupts numbers, so we can't really change the numbers anyway. For any non-ISA interrupt it's number can be choosen freely. Ralf From owner-linux-mips@oss.sgi.com Sun Feb 3 16:29:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g140Til20174 for linux-mips-outgoing; Sun, 3 Feb 2002 16:29:44 -0800 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g140TXA20000 for ; Sun, 3 Feb 2002 16:29:33 -0800 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Sun, 03 Feb 2002 15:29:13 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g13NTSKf006263; Sun, 3 Feb 2002 15:29:28 -0800 (PST) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id PAA19089; Sun, 3 Feb 2002 15:29:28 -0800 (PST) To: hjl@lucon.org cc: "Justin Carlson" , "Daniel Jacobowitz" , "Maciej W. Rozycki" , "Hiroyuki Machida" , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org Subject: Re: PATCH: Fix ll/sc for mips (take 3) References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> From: cgd@broadcom.com Date: 03 Feb 2002 15:29:28 -0800 In-Reply-To: hjl@lucon.org's message of "Sat, 2 Feb 2002 20:04:10 +0000 (UTC)" Message-ID: Lines: 54 X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 104318431312682-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk [ Hi Justin, enjoying winter in pgh? 8-] At Sat, 2 Feb 2002 20:04:10 +0000 (UTC), "H . J . Lu" wrote: > Does everyone agree with this? If yes, I can make a patch not to use > branch likely. But on the other hand, "gcc -mips2" will generate code > using branch likely. If branch likely doesn't buy you anything, > shouldn't we change gcc not to generate branch likely instructions? Branch-likely instructions probably _do_ buy you something (at least, slightly less code size) on some CPUs, probably even some CPUs which are still being produced. FYI, somebody, i think it was Mike Stump, submitted a patch to add a flag to disable branch-likely instructions N months ago. It was discussed a little bit, not AFAIK nothing was ever done with it. To quote the MIPS32 instruction set document from the MIPS web site: > Programming Notes: > > [ ... ] > > Software is strongly encouraged to avoid the use of the Branch > Likely instructions, as they will be removed from a future revision > of the MIPS Architecture. > > Some implementations always predict the branch will be taken, so > there is a significant penalty if the branch is not taken. Software > should only use this instruction when there is a very high > probability (98% or more) that the branch will be taken. If the > branch is not likely to be taken or if the probability of a taken > branch is unknown, software is encouraged to use the BGEZAL > instruction instead. If you have a sufficiently high static likelyhood of branch-taken, it may well be worthwhile to use branch-likely even on MIPS32/MIPS64 if it'll save you code space, or if you can determine that not clogging up your branch history / predictor buffers makes your code run faster. However, it should definitely not be the default. Anyway, from where I sit, this should be resolved like: * -mips1 - -mips5 should generate them by default (for strongly-predicted branches), -mips32 & -mips64 should not. (modify that for your favorite flag names, -march or whatever. 8-) * There should be flags to override the defaults either way, so you could say -mips2 -mno-branch-likely, or -mips32 -mbranch-likely. cgd From owner-linux-mips@oss.sgi.com Sun Feb 3 20:20:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g144KhT12057 for linux-mips-outgoing; Sun, 3 Feb 2002 20:20:43 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g144KeA11997 for ; Sun, 3 Feb 2002 20:20:40 -0800 Received: from delllaptop ([208.187.134.82]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g143KfF10060 for ; Sun, 3 Feb 2002 19:20:41 -0800 From: "Robert Rusek" To: Subject: RPM Problems Date: Sun, 3 Feb 2002 19:21:09 -0800 Message-ID: <001301c1ad2a$feb2b1c0$6701a8c0@delllaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am getting a Segmentation fault (core dumped) when trying to run rpm -i or -u. What dependencies does rpm use? I figure it may be a program that rpm is dependent on that is causing the error. Any help would be much appreciated. Without rpm I am dead in the water. Thanks -- Robert Rusek From owner-linux-mips@oss.sgi.com Sun Feb 3 23:46:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g147k4Q23049 for linux-mips-outgoing; Sun, 3 Feb 2002 23:46:04 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g147k0A23002 for ; Sun, 3 Feb 2002 23:46:01 -0800 Message-Id: <200202040746.g147k0A23002@oss.sgi.com> Received: (qmail 19041 invoked from network); 4 Feb 2002 06:26:07 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 4 Feb 2002 06:26:07 -0000 Date: Mon, 4 Feb 2002 14:22:48 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: SNaN & QNaN on mips 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, Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both say so.And experiments confirm this. Should we correct it? > >Regards > Zhang Fuxin > fxzhang@ict.ac.cn Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Sun Feb 3 23:45:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g147jvD22915 for linux-mips-outgoing; Sun, 3 Feb 2002 23:45:57 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g147jtA22893 for ; Sun, 3 Feb 2002 23:45:55 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8C8CF125C8; Sun, 3 Feb 2002 22:45:52 -0800 (PST) Date: Sun, 3 Feb 2002 22:45:52 -0800 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Please try new libtool Message-ID: <20020203224552.A4998@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I put a new libtool at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm I think I have fixed the shared library problem. Please verify it and let me know. Thanks. H.J. From owner-linux-mips@oss.sgi.com Sun Feb 3 23:55:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g147t0031248 for linux-mips-outgoing; Sun, 3 Feb 2002 23:55:00 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g147svA31223 for ; Sun, 3 Feb 2002 23:54:57 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id A7D26125C8; Sun, 3 Feb 2002 22:54:54 -0800 (PST) Date: Sun, 3 Feb 2002 22:54:54 -0800 From: "H . J . Lu" To: Zhang Fuxin Cc: "linux-mips@oss.sgi.com" Subject: Re: SNaN & QNaN on mips Message-ID: <20020203225454.A5158@lucon.org> References: <200202040746.g147k0A23002@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: <200202040746.g147k0A23002@oss.sgi.com>; from fxzhang@ict.ac.cn on Mon, Feb 04, 2002 at 02:22:48PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 02:22:48PM +0800, Zhang Fuxin wrote: > hi, > > Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and > optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu > (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both > say so.And experiments confirm this. > > Should we correct it? Yes. Do you have a patch? Thanks. H.J. From owner-linux-mips@oss.sgi.com Mon Feb 4 00:00:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1480Vb03985 for linux-mips-outgoing; Mon, 4 Feb 2002 00:00:31 -0800 Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1480NA03910 for ; Mon, 4 Feb 2002 00:00:24 -0800 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g146x6U03946; Mon, 4 Feb 2002 07:59:06 +0100 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Mon, 4 Feb 2002 07:59:06 +0100 (CET) From: Kjeld Borch Egevang To: Zhang Fuxin cc: "linux-mips@oss.sgi.com" Subject: Re: SNaN & QNaN on mips In-Reply-To: <200202040746.g147k0A23002@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 On Mon, 4 Feb 2002, Zhang Fuxin wrote: > hi, > > Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and > optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu > (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both > say so.And experiments confirm this. MIPS interprets Signalling NaN's different than e.g. Intel. According to IEEE754 it _is_ a matter of interpretation. 0x7fc00000 is an SNaN while 0x7fbfffff is an QNaN. It would be great if you could fix it. /Kjeld > Should we correct it? > > > > >Regards > > Zhang Fuxin > > fxzhang@ict.ac.cn > > Regards > Zhang Fuxin > fxzhang@ict.ac.cn > -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Mon Feb 4 01:54:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g149s0D18077 for linux-mips-outgoing; Mon, 4 Feb 2002 01:54:00 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g149rrA17976 for ; Mon, 4 Feb 2002 01:53:56 -0800 Message-Id: <200202040953.g149rrA17976@oss.sgi.com> Received: (qmail 2779 invoked from network); 4 Feb 2002 08:54:06 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 4 Feb 2002 08:54:06 -0000 Date: Mon, 4 Feb 2002 16:50:43 +0800 From: Zhang Fuxin To: "H . J . Lu" CC: "linux-mips@oss.sgi.com" Subject: Re: Re: SNaN & QNaN on mips 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 g149ruA18014 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ÔÚ 2002-02-03 22:54:00 you wrote£ş >On Mon, Feb 04, 2002 at 02:22:48PM +0800, Zhang Fuxin wrote: >> hi, >> >> Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and >> optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu >> (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both >> say so.And experiments confirm this. >> >> Should we correct it? > >Yes. Do you have a patch? Not currently but I will have a try. glibc seems having the same problem. > >Thanks. > > >H.J. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Feb 4 02:32:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14AWqY24591 for linux-mips-outgoing; Mon, 4 Feb 2002 02:32:52 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14AWjA24547 for ; Mon, 4 Feb 2002 02:32:45 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g149Waa27266; Mon, 4 Feb 2002 09:32:37 GMT From: Dominic Sweetman Message-ID: <15454.21812.39310.478616@gladsmuir.algor.co.uk> Date: Mon, 4 Feb 2002 09:32:36 +0000 MIME-Version: 1.0 To: Hiroyuki Machida Cc: hjl@lucon.org, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <20020202.113717.68552217.machida@sm.sony.co.jp> References: <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020202.113717.68552217.machida@sm.sony.co.jp> 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 Hiroyuki Machida (machida@sm.sony.co.jp) writes: > I think we can assume CPU has branch-likely insns, if CPU has MIPS > ISA 2 or greater ISA.. "MIPS II" is officially the instruction set introduced for the long lost R6000 CPU. But "MIPS II" is now used to mean "the 32-bit subset of MIPS III" (which is extremely close to the same thing, but I'm never quite sure about the last details of the R6000 - Kevin would remember better, probably). OK: branch-likely is definitely part of MIPS II and MIPS32. There are still MIPS CPUs in regular use which are based on MIPS I and don't provide them. Generally the advantages of MIPS II are slight, so if you want to build a kernel which will not require instruction-set variants, it's no big deal to restrict it to MIPS I. > (FYI: we can't assume CPU has LL/SC even if CPU has branch-likely > insns. ) LL/SC is also part of MIPS III (and the 32-bit variants are thus taken to be in MIPS II). Unfortunately, the documentation of LL/SC gave the impression that they were useful only in multiprocessor systems, so they were omitted by NEC building the Vr41xx and Toshiba's R59xx. In both cases it's a bug - but since it isn't about to be fixed, you need workarounds. In these more enlightened days, CPU vendors are more likely to ask an operating system person before they leave out bits of the instruction set, so we hope it won't happen again! 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 Mon Feb 4 02:47:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Al6M07468 for linux-mips-outgoing; Mon, 4 Feb 2002 02:47:06 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14AkvA07339 for ; Mon, 4 Feb 2002 02:46:58 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g149kma27958; Mon, 4 Feb 2002 09:46:50 GMT From: Dominic Sweetman Message-ID: <15454.22661.855423.532827@gladsmuir.algor.co.uk> Date: Mon, 4 Feb 2002 09:46:45 +0000 MIME-Version: 1.0 To: cgd@broadcom.com Cc: linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk cgd@broadcom.com (cgd@broadcom.com) writes: > Branch-likely instructions probably _do_ buy you something (at > least, slightly less code size) on some CPUs, probably even some > CPUs which are still being produced. Here's how branch likely is used to improve performance in a simple MIPS CPU, and why it has no effect on code size. You start off with this: loopstart: insn 1 insn 2 .... insn last branch to loopstart nop In small loops, the last instruction in the loop might well calculate the branch condition, so it can't be moved into the delay slot of the loop-closing branch. That puts a no-op into every loop iteration. With branch-likely, you can transform the loop to loopstart: insn 1 loop2: insn 2 .... insn last branch-likely loop2 insn 1 (copy) The nop is replaced by a duplicate instruction from the top of the loop. Good for performance, no effect on code size. Builders of clever modern CPUs full of branch prediction hardware, multiple instruction issue and instruction re-ordering find the coupling of the branch-likely to the following instruction makes their CPUs more complicated. That's why MIPS have warned that the instructions will be removed from some future version of the MIPS instruction set. -- 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 Mon Feb 4 04:33:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14CX9X10429 for linux-mips-outgoing; Mon, 4 Feb 2002 04:33:09 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14CWxA10273; Mon, 4 Feb 2002 04:33:00 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA09990; Mon, 4 Feb 2002 12:32:41 +0100 (MET) Date: Mon, 4 Feb 2002 12:32:40 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20020203193717.B6317@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 Sun, 3 Feb 2002, Ralf Baechle wrote: > > Hmm, the assumption might be justifiable for the i386 only? Shouldn't > > i8259.c be fixed instead? > > These are the ISA interrupts; many drivers make assumptions about the > interrupts numbers, so we can't really change the numbers anyway. For > any non-ISA interrupt it's number can be choosen freely. I don't think such assumptions are sane even for the i386 -- an I/O APIC system is free to route ISA interrupts to whichever I/O APIC inputs are available, not necessarily the low 16. The Intel MP Spec explicitly allows such a setup -- ISA interrupts are only tied in default configurations, which are rarely used (probably not at all these days). Anyway, only the drivers that read an IRQ number from jumpers or Flash memory need to be checked, and these are a minority (3Com Ethernet cards and possibly very few others). These that do probing (with probe_irq) or simply take the number from an option will work automatically. While I agree for 2.4 it might be not the best idea to do such changes, for 2.5 it's worth considering, isn't 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 Mon Feb 4 05:11:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14DBCP08384 for linux-mips-outgoing; Mon, 4 Feb 2002 05:11:12 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14DAgA08143 for ; Mon, 4 Feb 2002 05:10:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA11331; Mon, 4 Feb 2002 13:10:25 +0100 (MET) Date: Mon, 4 Feb 2002 13:10:25 +0100 (MET) From: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com cc: Ralf Baechle Subject: [patch] linux 2.4.17: The second mb() 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 the second version of the mb() approach again. It adds iob() as the strongest barrier, implying committing all writes to the CPU bus. I consider this version final. Any objections (barring "sync" workarounds we may consider later)? 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-5 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 Mon Feb 4 00:07:13 2002 @@ -384,6 +384,12 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" -o \ + "$CONFIG_CPU_TX39XX" = "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 Mon Feb 4 02:10:33 2002 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,57 @@ 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" \ + "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 Feb 4 05:20:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14DKSf16032 for linux-mips-outgoing; Mon, 4 Feb 2002 05:20:28 -0800 Received: from dea.linux-mips.net (a1as01-p54.stg.tli.de [195.252.185.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14DKNA15981 for ; Mon, 4 Feb 2002 05:20:24 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1471j719209; Mon, 4 Feb 2002 08:01:45 +0100 Date: Mon, 4 Feb 2002 08:01:45 +0100 From: Ralf Baechle To: "H . J . Lu" Cc: Hiroyuki Machida , macro@ds2.pg.gda.pl, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips Message-ID: <20020204080145.C13799@dea.linux-mips.net> References: <20020131123547.A22759@lucon.org> <20020131144100.A24634@lucon.org> <20020201.123523.50041631.machida@sm.sony.co.jp> <20020131231714.E32690@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020131231714.E32690@lucon.org>; from hjl@lucon.org on Thu, Jan 31, 2002 at 11:17:14PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jan 31, 2002 at 11:17:14PM -0800, H . J . Lu wrote: > > Gas will fill delay slots. Same object codes will be produced, so I > > think you don't have to do that by hand. > > It will make the code more readable. We don't have to guess what > the assembler will do. Generally speaking a MIPS assembler is free to do arbitrary reordering. In the past there have been non-GNU assembler that were doing more massive reordering than gcc does ... Using .set noreorder means you dump the assembler's intelligence and take full responsibility for dealing with all interlocks (or the lack thereof) and other performance issues yourself. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 05:20:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14DKxZ16534 for linux-mips-outgoing; Mon, 4 Feb 2002 05:20:59 -0800 Received: from dea.linux-mips.net (a1as01-p54.stg.tli.de [195.252.185.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14DKsA16468 for ; Mon, 4 Feb 2002 05:20:54 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g146kJh19091; Mon, 4 Feb 2002 07:46:19 +0100 Date: Mon, 4 Feb 2002 07:46:19 +0100 From: Ralf Baechle To: Justin Carlson Cc: Daniel Jacobowitz , "H . J . Lu" , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204074619.B13799@dea.linux-mips.net> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1012676003.1563.6.camel@xyzzy.stargate.net>; from justinca@ri.cmu.edu on Sat, Feb 02, 2002 at 01:53:23PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Feb 02, 2002 at 01:53:23PM -0500, Justin Carlson wrote: > 2) More importantly, most implementations don't use any sort of dynamic > branch prediction on branch likelies. They predict taken, always, since > that's the specified intent (it's a branch *likely* to be taken). CPU guys hate branch likely and would probably love if whoever invented them hires at Intel ;-) > For most spin locks, the normal behaviour is a fall through, not taking > that branch, so you're inflicting a branch mispredict penalty on every > lock grabbed without contention. Even for locks which the general case > is contention, giving the processor branch predictor a chance to learn > that is a Good Idea. I was thinking about spinlocks like retry: la addrreg, retry ll reg, lockvar ... sc reg, lockvar teq $0, reg That would depend on the price of a trap instruction when it's not taken and the probability of the lock being congested. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 05:21:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14DLVq17058 for linux-mips-outgoing; Mon, 4 Feb 2002 05:21:31 -0800 Received: from dea.linux-mips.net (a1as01-p54.stg.tli.de [195.252.185.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14DLQA16969 for ; Mon, 4 Feb 2002 05:21:26 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1467fO18828; Mon, 4 Feb 2002 07:07:41 +0100 Date: Mon, 4 Feb 2002 07:07:41 +0100 From: Ralf Baechle To: cgd@broadcom.com Cc: hjl@lucon.org, Justin Carlson , Daniel Jacobowitz , "Maciej W. Rozycki" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204070741.A13799@dea.linux-mips.net> References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cgd@broadcom.com on Sun, Feb 03, 2002 at 03:29:28PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Feb 03, 2002 at 03:29:28PM -0800, cgd@broadcom.com wrote: > At Sat, 2 Feb 2002 20:04:10 +0000 (UTC), "H . J . Lu" wrote: > > Does everyone agree with this? If yes, I can make a patch not to use > > branch likely. But on the other hand, "gcc -mips2" will generate code > > using branch likely. If branch likely doesn't buy you anything, > > shouldn't we change gcc not to generate branch likely instructions? > > Branch-likely instructions probably _do_ buy you something (at least, > slightly less code size) on some CPUs, probably even some CPUs which > are still being produced. I benchmarked the performance improvment on R4000/R4400 by using branch likely instructions to be in the range of 1-2% in a piece of pretty "branchy" code, so we don't want to disable branch likely right entirely. Newer CPU types, in particular those featuring branch prediction tend to perform differently. I suggest to enable branch likely in gcc for those > MIPS II CPUs where they're known to improve performance or when optimizing for code size. Unfortunately gcc's knowledge about such architecture details is rather limited. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 08:00:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14G0Ej28110 for linux-mips-outgoing; Mon, 4 Feb 2002 08:00:14 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14FxvA27903; Mon, 4 Feb 2002 07:59:58 -0800 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 GAA09246; Mon, 4 Feb 2002 06:58:37 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA16007; Mon, 4 Feb 2002 15:54:11 +0100 (MET) Date: Mon, 4 Feb 2002 15:54:11 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: "H . J . Lu" , Hiroyuki Machida , libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips In-Reply-To: <20020204080145.C13799@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, 4 Feb 2002, Ralf Baechle wrote: > > It will make the code more readable. We don't have to guess what > > the assembler will do. > > Generally speaking a MIPS assembler is free to do arbitrary reordering. > In the past there have been non-GNU assembler that were doing more massive > reordering than gcc does ... Using .set noreorder means you dump the > assembler's intelligence and take full responsibility for dealing with > all interlocks (or the lack thereof) and other performance issues > yourself. That's why I'm still uneasy about the patch or, specifically, its _test_and_set hunk. It's best to avoid pretending we have the knowledge beyond what an assembler has, as it's often not the case -- consider all the options an assembler can accept for code variations. Using "noreorder" is really justified if you need to generate an exact opcode stream for some reason (perhaps for a trampoline with a fixed format) or you know you have the knowledege beyond what an assembler has, e.g. you know an instruction can (or must) really be placed in a delay slot even though a dependency analysis performed by an assembler shows otherwise. Also beware of implicit macros which may expand into multiple instructions -- their semantics when placed in a delay slot may differ from what one may expect! -- + 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 Feb 4 09:31:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14HVQ222103 for linux-mips-outgoing; Mon, 4 Feb 2002 09:31:26 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14HVJA21979 for ; Mon, 4 Feb 2002 09:31:19 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 2B8CE125C8; Mon, 4 Feb 2002 08:31:15 -0800 (PST) Date: Mon, 4 Feb 2002 08:31:15 -0800 From: "H . J . Lu" To: Dominic Sweetman Cc: cgd@broadcom.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204083115.C13384@lucon.org> References: <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15454.22661.855423.532827@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Feb 04, 2002 at 09:46:45AM +0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 09:46:45AM +0000, Dominic Sweetman wrote: > > cgd@broadcom.com (cgd@broadcom.com) writes: > > > Branch-likely instructions probably _do_ buy you something (at > > least, slightly less code size) on some CPUs, probably even some > > CPUs which are still being produced. > > Here's how branch likely is used to improve performance in a simple > MIPS CPU, and why it has no effect on code size. > > You start off with this: > > loopstart: insn 1 > insn 2 > .... > insn last > branch to loopstart > nop > > In small loops, the last instruction in the loop might well calculate > the branch condition, so it can't be moved into the delay slot of the > loop-closing branch. That puts a no-op into every loop iteration. > With branch-likely, you can transform the loop to > > loopstart: insn 1 > loop2: insn 2 > .... > insn last > branch-likely loop2 > insn 1 (copy) > > The nop is replaced by a duplicate instruction from the top > of the loop. Good for performance, no effect on code size. > > Builders of clever modern CPUs full of branch prediction hardware, > multiple instruction issue and instruction re-ordering find the > coupling of the branch-likely to the following instruction makes their > CPUs more complicated. That's why MIPS have warned that the > instructions will be removed from some future version of the MIPS > instruction set. I can change glibc not to use branch-likely without using nop. But it may require one or two instructions outside of the loop. Should I do it given what we know now? H.J. From owner-linux-mips@oss.sgi.com Mon Feb 4 09:46:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14HkMd07052 for linux-mips-outgoing; Mon, 4 Feb 2002 09:46:22 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14HkJA06989 for ; Mon, 4 Feb 2002 09:46:19 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g14GkAa11615; Mon, 4 Feb 2002 16:46:12 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15454.47823.837119.847975@gladsmuir.algor.co.uk> Date: Mon, 4 Feb 2002 16:46:07 +0000 To: "H . J . Lu" Cc: Dominic Sweetman , cgd@broadcom.com, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <20020204083115.C13384@lucon.org> References: <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H . J . Lu (hjl@lucon.org) writes: > I can change glibc not to use branch-likely without using nop. But it > may require one or two instructions outside of the loop. Should I do > it given what we know now? I would not recommend using "branch likely" in assembler coding, if that's what you're asking. Dominic From owner-linux-mips@oss.sgi.com Mon Feb 4 10:27:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14IRLA12002 for linux-mips-outgoing; Mon, 4 Feb 2002 10:27:21 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14IRIA11984 for ; Mon, 4 Feb 2002 10:27:18 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14HPBB03539 for ; Mon, 4 Feb 2002 09:25:11 -0800 Subject: madplay on mips From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 04 Feb 2002 09:29:13 -0800 Message-Id: <1012843753.14993.106.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone used madplay on mips to play mp3 files successfully? I've tried it on two mips boards with different sound drivers, and in both cases it plays the song slower and a bit muffled. It works on x86 and supposedly ppc. Pete From owner-linux-mips@oss.sgi.com Mon Feb 4 10:44:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Iig326911 for linux-mips-outgoing; Mon, 4 Feb 2002 10:44:42 -0800 Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14IibA26779 for ; Mon, 4 Feb 2002 10:44:37 -0800 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Mon, 04 Feb 2002 09:43:20 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-2.sj.broadcom.com (mail-sj1-2 [10.16.128.232]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g14HiVKf011646; Mon, 4 Feb 2002 09:44:31 -0800 (PST) Received: (from cgd@localhost) by mail-sj1-2.sj.broadcom.com ( 8.9.1/SJ8.9.1) id JAA06295; Mon, 4 Feb 2002 09:44:31 -0800 (PST) To: "Dominic Sweetman" cc: linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> From: cgd@broadcom.com Date: 04 Feb 2002 09:44:31 -0800 In-Reply-To: "Dominic Sweetman"'s message of "Mon, 4 Feb 2002 09:46:45 +0000" Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 104017B272261-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk thanks for the explanation. just goes to show that i should probably sit down and read your book from cover to cover one day, rather than just recommending it to the newbies. 8-) chris From owner-linux-mips@oss.sgi.com Mon Feb 4 11:19:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14JJDf26418 for linux-mips-outgoing; Mon, 4 Feb 2002 11:19:13 -0800 Received: from dea.linux-mips.net (a1as18-p231.stg.tli.de [195.252.193.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14JJ8A26331 for ; Mon, 4 Feb 2002 11:19:08 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g14H2w404022; Mon, 4 Feb 2002 18:02:58 +0100 Date: Mon, 4 Feb 2002 18:02:58 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jason Gunthorpe , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework Message-ID: <20020204180258.A6124@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jan 31, 2002 at 01:17:39PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Jan 31, 2002 at 01:17:39PM +0100, Maciej W. Rozycki wrote: > Certain DECstation models have a write-back buffer that needs to be > handled explicitly. For example rmb() is "1: bc0f 1b" for the R3220 WB > chip. Wmb() is null, certainly, as the buffer is strongly-ordered. See > arch/mips/dec/wbflush.c for details. Just as an aside that isn't directly relevant to DECstations. To date all MIPS _processors_ are strongly ordered. I now know of at least one processor that implements a weakly ordered memory model, so the assumption of a strongly ordered memory model has become void for large parts of the kernel. Even before that some systems had strongly ordered processors in system environments that may reorder requests. Bugs due to surprise memory reordering are entirely unfun to debug, so be paranoid. They're out there to get you ... Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 11:42:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14JgYx14961 for linux-mips-outgoing; Mon, 4 Feb 2002 11:42:34 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14JgWA14928 for ; Mon, 4 Feb 2002 11:42:32 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14IeOB08958; Mon, 4 Feb 2002 10:40:24 -0800 Message-ID: <3C5ED610.529C020E@mvista.com> Date: Mon, 04 Feb 2002 10:42:24 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: linux-mips Subject: Re: madplay on mips References: <1012843753.14993.106.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > > Has anyone used madplay on mips to play mp3 files successfully? I've > tried it on two mips boards with different sound drivers, and in both > cases it plays the song slower and a bit muffled. It works on x86 and > supposedly ppc. > I tried it before, and had the same results. I looked over the system calls, and was pretty much sure that the problem was on madplay side, and not on the driver side. One problem suspected was the floating point issue, but did get into it. Jun From owner-linux-mips@oss.sgi.com Mon Feb 4 11:45:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Jj2O16812 for linux-mips-outgoing; Mon, 4 Feb 2002 11:45:02 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14JixA16774 for ; Mon, 4 Feb 2002 11:44:59 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14IgqB09457; Mon, 4 Feb 2002 10:42:52 -0800 Subject: Re: madplay on mips From: Pete Popov To: Jun Sun Cc: linux-mips In-Reply-To: <3C5ED610.529C020E@mvista.com> References: <1012843753.14993.106.camel@zeus> <3C5ED610.529C020E@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 04 Feb 2002 10:46:54 -0800 Message-Id: <1012848414.15163.140.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 2002-02-04 at 10:42, Jun Sun wrote: > Pete Popov wrote: > > > > Has anyone used madplay on mips to play mp3 files successfully? I've > > tried it on two mips boards with different sound drivers, and in both > > cases it plays the song slower and a bit muffled. It works on x86 and > > supposedly ppc. > > > > I tried it before, and had the same results. > > I looked over the system calls, and was pretty much sure that the problem was > on madplay side, and not on the driver side. One problem suspected was the > floating point issue, but did get into it. Even though madplay claims that no floating point is used, the disassembly of the latest version shows otherwise. But I tried it on a board with a cpu that does have a hardware floating point unit with the same result. Pete From owner-linux-mips@oss.sgi.com Mon Feb 4 12:05:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14K5tV30992 for linux-mips-outgoing; Mon, 4 Feb 2002 12:05:55 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14K5jA30793; Mon, 4 Feb 2002 12:05:45 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14J1aB11076; Mon, 4 Feb 2002 11:01:36 -0800 Message-ID: <3C5EDB08.B4F2FF7B@mvista.com> Date: Mon, 04 Feb 2002 11:03:36 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux 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 Sun, 3 Feb 2002, Ralf Baechle wrote: > > > > Hmm, the assumption might be justifiable for the i386 only? Shouldn't > > > i8259.c be fixed instead? > > > > These are the ISA interrupts; many drivers make assumptions about the > > interrupts numbers, so we can't really change the numbers anyway. For > > any non-ISA interrupt it's number can be choosen freely. > > I don't think such assumptions are sane even for the i386 -- an I/O APIC > system is free to route ISA interrupts to whichever I/O APIC inputs are > available, not necessarily the low 16. The Intel MP Spec explicitly > allows such a setup -- ISA interrupts are only tied in default > configurations, which are rarely used (probably not at all these days). > > Anyway, only the drivers that read an IRQ number from jumpers or Flash > memory need to be checked, and these are a minority (3Com Ethernet cards > and possibly very few others). These that do probing (with probe_irq) or > simply take the number from an option will work automatically. > > While I agree for 2.4 it might be not the best idea to do such changes, > for 2.5 it's worth considering, isn't it? > This patch is from me. It merely reflects a change of the irq base mapping from 0x20 to 0x0. I think someone did this change for Malta board. A better solution is to have init_i8259_irqs() take an argument that is the base IRQ number, like many other irq controller code do. This way it is a board level decision as what block of IRQs i8259 should use. Jun From owner-linux-mips@oss.sgi.com Mon Feb 4 12:20:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14KKNv10302 for linux-mips-outgoing; Mon, 4 Feb 2002 12:20:23 -0800 Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14KKHA10161 for ; Mon, 4 Feb 2002 12:20:17 -0800 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g14JHC606535; Mon, 4 Feb 2002 14:17:12 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g14JH8704342; Mon, 4 Feb 2002 14:17:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15454.56884.108220.380799@pkoning.dev.equallogic.com> Date: Mon, 4 Feb 2002 14:17:08 -0500 (EST) From: Paul Koning To: justinca@ri.cmu.edu Cc: hjl@lucon.org, dan@debian.org, macro@ds2.pg.gda.pl, machida@sm.sony.co.jp, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org Subject: Re: PATCH: Fix ll/sc for mips (take 3) References: <20020131231714.E32690@lucon.org> <20020201102943.A11146@lucon.org> <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <1012715250.2297.9.camel@xyzzy.stargate.net> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> "Justin" == Justin Carlson writes: Justin> On Sat, 2002-02-02 at 15:03, H . J . Lu wrote: >> Does everyone agree with this? If yes, I can make a patch not to >> use branch likely. But on the other hand, "gcc -mips2" will >> generate code using branch likely. If branch likely doesn't buy >> you anything, shouldn't we change gcc not to generate branch >> likely instructions? >> Justin> I know of at least one internal version of gcc which already Justin> has been hacked to remove generation of branch likely Justin> instructions. More precisely (if you're looking at the same one I was) -- it has a target processor type check that disables it for those CPUs where it is known to be not a good idea. Justin> Also, I didn't say branch likely doesn't buy you anything; Justin> there are situations where it works well. Looking at the Justin> spin_lock code, though, this isn't one of them. I agree, and I think that point was missed. Independent of whether a particular processor (MIPS or otherwise) has the concept of "branch likely", the design rule of spinlocks is that you try to avoid spinning (i.e., avoid lock contention) in the system design. So for that particular construct, the right answer is "branch not likely". paul From owner-linux-mips@oss.sgi.com Mon Feb 4 12:28:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14KSWV23268 for linux-mips-outgoing; Mon, 4 Feb 2002 12:28:32 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14KSNA23073; Mon, 4 Feb 2002 12:28:23 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14JQGB12611; Mon, 4 Feb 2002 11:26:16 -0800 Message-ID: <3C5EE0D0.F2CC94CE@mvista.com> Date: Mon, 04 Feb 2002 11:28:16 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: gcc 3.x, -ansi and "static inline" References: <20020201115206.A18085@mvista.com> <20020203180151.A5371@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote: > > > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary > > and caused a bunch of similar errors. > > Indeed, it was pointless and I therefore removed it. > What about ffz()? We can do: diff -Nru include/asm-mips/bitops.h.orig include/asm-mips/bitops.h --- include/asm-mips/bitops.h.orig Mon Feb 4 11:07:31 2002 +++ include/asm-mips/bitops.h Mon Feb 4 11:21:14 2002 @@ -675,7 +675,7 @@ * * Undefined if no zero exists, so code should check against ~0UL first. */ -static inline unsigned long ffz(unsigned long word) +static __inline__ unsigned long ffz(unsigned long word) { int b = 0, s; or diff -Nru include/asm-mips/bitops.h.orig include/asm-mips/bitops.h --- include/asm-mips/bitops.h.orig Mon Feb 4 11:07:31 2002 +++ include/asm-mips/bitops.h Mon Feb 4 11:27:55 2002 @@ -669,6 +669,8 @@ #endif /* !(__MIPSEB__) */ +#ifdef __KERNEL__ + /* * ffz - find first zero in word. * @word: The word to search @@ -689,8 +691,6 @@ return b; } - -#ifdef __KERNEL__ /** * ffs - find first bit set Jun From owner-linux-mips@oss.sgi.com Mon Feb 4 14:22:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14MMk115876 for linux-mips-outgoing; Mon, 4 Feb 2002 14:22:46 -0800 Received: from dea.linux-mips.net (a1as18-p231.stg.tli.de [195.252.193.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14MMdA15872 for ; Mon, 4 Feb 2002 14:22:40 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g14ML8c07451; Mon, 4 Feb 2002 23:21:08 +0100 Date: Mon, 4 Feb 2002 23:21:08 +0100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: gcc 3.x, -ansi and "static inline" Message-ID: <20020204232108.A7266@dea.linux-mips.net> References: <20020201115206.A18085@mvista.com> <20020203180151.A5371@dea.linux-mips.net> <3C5EE0D0.F2CC94CE@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C5EE0D0.F2CC94CE@mvista.com>; from jsun@mvista.com on Mon, Feb 04, 2002 at 11:28:16AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 11:28:16AM -0800, Jun Sun wrote: > > On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote: > > > > > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary > > > and caused a bunch of similar errors. > > > > Indeed, it was pointless and I therefore removed it. > > What about ffz()? We can do: Including kernel header files into user code is the actual bug but if you think fixing that isn't an option I can certainly so a s/inline/__inline__/ Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 14:56:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14Muta18698 for linux-mips-outgoing; Mon, 4 Feb 2002 14:56:55 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14MumA18693; Mon, 4 Feb 2002 14:56:48 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g14MshB25272; Mon, 4 Feb 2002 14:54:43 -0800 Message-ID: <3C5F11AB.957DDA6C@mvista.com> Date: Mon, 04 Feb 2002 14:56:43 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: gcc 3.x, -ansi and "static inline" References: <20020201115206.A18085@mvista.com> <20020203180151.A5371@dea.linux-mips.net> <3C5EE0D0.F2CC94CE@mvista.com> <20020204232108.A7266@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Mon, Feb 04, 2002 at 11:28:16AM -0800, Jun Sun wrote: > > > > On Fri, Feb 01, 2002 at 11:52:06AM -0800, Jun Sun wrote: > > > > > > > BTW, the inclusion of "mipsregs.h" file in bitops.h seems unnecessary > > > > and caused a bunch of similar errors. > > > > > > Indeed, it was pointless and I therefore removed it. > > > > What about ffz()? We can do: > > Including kernel header files into user code is the actual bug In theory, yes. In practice, kernel head is all a big mesh where we don't have a clear division as which part can go to userland and which part can't. The inline function makes mesh even meshier. > but if > you think fixing that isn't an option I can certainly so a > s/inline/__inline__/ > I think this is the case. See the inclusion chain below. BTW, the app is libcap. In file included from /opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/linux/fs.h:26, from /opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/linux/capability.h:17, from /var/tmp/BUILD/libcap-1.10.orig/libcap/include/sys/capability.h:24, from libcap.h:19, from cap_alloc.c:12: /opt/hardhat/devkit/mips/sb1_fp_be/target/usr/include/asm/bitops.h:678: syntax error before "unsigned" Jun From owner-linux-mips@oss.sgi.com Mon Feb 4 15:02:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14N2dd19186 for linux-mips-outgoing; Mon, 4 Feb 2002 15:02:39 -0800 Received: from dea.linux-mips.net (a1as18-p231.stg.tli.de [195.252.193.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g14N2ZA19183 for ; Mon, 4 Feb 2002 15:02:36 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g14N19j07967; Tue, 5 Feb 2002 00:01:09 +0100 Date: Tue, 5 Feb 2002 00:01:09 +0100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: gcc 3.x, -ansi and "static inline" Message-ID: <20020205000109.A7512@dea.linux-mips.net> References: <20020201115206.A18085@mvista.com> <20020203180151.A5371@dea.linux-mips.net> <3C5EE0D0.F2CC94CE@mvista.com> <20020204232108.A7266@dea.linux-mips.net> <3C5F11AB.957DDA6C@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C5F11AB.957DDA6C@mvista.com>; from jsun@mvista.com on Mon, Feb 04, 2002 at 02:56:43PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 02:56:43PM -0800, Jun Sun wrote: > In theory, yes. In practice, kernel head is all a big mesh where we don't > have a clear division as which part can go to userland and which part can't. The answer is already l-k faq probably - copy the kernel header to userspace and hack it into your favorite shape. I'm not a fan of this policy but ... Ralf From owner-linux-mips@oss.sgi.com Mon Feb 4 17:29:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g151TCn07877 for linux-mips-outgoing; Mon, 4 Feb 2002 17:29:12 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g151SwA07872 for ; Mon, 4 Feb 2002 17:28:58 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id CEDCC125C8; Mon, 4 Feb 2002 17:28:57 -0800 (PST) Date: Mon, 4 Feb 2002 17:28:57 -0800 From: "H . J . Lu" To: Dominic Sweetman Cc: GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204172857.A22337@lucon.org> References: <20020201180126.A23740@nevyn.them.org> <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15454.47823.837119.847975@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Feb 04, 2002 at 04:46:07PM +0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 04:46:07PM +0000, Dominic Sweetman wrote: > > H . J . Lu (hjl@lucon.org) writes: > > > I can change glibc not to use branch-likely without using nop. But it > > may require one or two instructions outside of the loop. Should I do > > it given what we know now? > > I would not recommend using "branch likely" in assembler coding, if > that's what you're asking. > Here is a patch to remove branch likely. But I couldn't find a way not to fill the delay slot with nop. BTW, is that safe to remove ".set noreorder"? H.J. --- 2002-02-04 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Not use branch likely. * sysdeps/mips/pt-machine.h (testandset): Liekwise. (__compare_and_swap): Liekwise. 2002-02-04 H.J. Lu * sysdeps/mips/atomicity.h (exchange_and_add): Not use branch likely. (atomic_add): Likewise. (compare_and_swap): Likewise. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Likewise. --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Mon Feb 4 17:09:02 2002 @@ -40,7 +40,7 @@ __pthread_spin_lock (pthread_spinlock_t "bnez %1,1b\n\t" " li %2,1\n\t" "sc %2,%0\n\t" - "beqzl %2,1b\n\t" + "beqz %2,1b\n\t" " ll %1,%3\n\t" ".set pop" : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Mon Feb 4 17:09:36 2002 @@ -66,7 +66,7 @@ __compare_and_swap (long int *p, long in " move %0,$0\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" + "beqz %0,1b\n\t" " ll %1,%5\n\t" ".set pop\n" "2:\n\t" --- libc/sysdeps/mips/atomicity.h.llsc Mon Feb 4 13:45:18 2002 +++ libc/sysdeps/mips/atomicity.h Mon Feb 4 17:14:48 2002 @@ -32,15 +32,15 @@ exchange_and_add (volatile uint32_t *mem int result, tmp; __asm__ __volatile__ - ("/* Inline exchange & add */\n\t" + ("/* Inline exchange & add */\n" + "1:\n" "ll %0,%3\n" - "1:\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" ".set push\n\t" ".set noreorder\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" + "beqz %1,1b\n\t" + " nop\n\t" ".set pop\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) @@ -57,15 +57,15 @@ atomic_add (volatile uint32_t *mem, int int result; __asm__ __volatile__ - ("/* Inline atomic add */\n\t" - "ll %0,%2\n" + ("/* Inline atomic add */\n" "1:\n\t" + "ll %0,%2\n" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" ".set push\n\t" ".set noreorder\n\t" - "beqzl %0,1b\n\t" - " ll %0,%2\n\t" + "beqz %0,1b\n\t" + " nop\n\t" ".set pop\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) @@ -89,7 +89,7 @@ compare_and_swap (volatile long int *p, " move %0,$0\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" + "beqz %0,1b\n\t" " ll %1,%5\n\t" ".set pop\n" "2:\n\t" --- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Feb 4 13:45:28 2002 +++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h Mon Feb 4 17:19:06 2002 @@ -42,16 +42,16 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("/* Inline test and set */\n\t" - "ll %0,%3\n" + ("/* Inline test and set */\n" "1:\n\t" + "ll %0,%3\n" ".set push\n\t" ".set noreorder\n\t" "beq %0,%4,2f\n\t" " move %1,%4\n\t" "sc %1,%2\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" + "beqz %1,1b\n\t" + " nop\n\t" ".set pop\n" "2:\n\t" "/* End test and set */" From owner-linux-mips@oss.sgi.com Mon Feb 4 18:58:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g152waS09788 for linux-mips-outgoing; Mon, 4 Feb 2002 18:58:36 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g152wRA09781 for ; Mon, 4 Feb 2002 18:58:27 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16Xvo4-0000Yy-00; Mon, 04 Feb 2002 21:58:04 -0500 Date: Mon, 4 Feb 2002 21:58:04 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204215804.A2095@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com References: <20020201151513.A15913@lucon.org> <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020204172857.A22337@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 05:28:57PM -0800, H . J . Lu wrote: > On Mon, Feb 04, 2002 at 04:46:07PM +0000, Dominic Sweetman wrote: > > > > H . J . Lu (hjl@lucon.org) writes: > > > > > I can change glibc not to use branch-likely without using nop. But it > > > may require one or two instructions outside of the loop. Should I do > > > it given what we know now? > > > > I would not recommend using "branch likely" in assembler coding, if > > that's what you're asking. > > > > Here is a patch to remove branch likely. But I couldn't find a way > not to fill the delay slot with nop. BTW, is that safe to remove > ".set noreorder"? You mean, if there is nothing which can be put there? Yes, it's safe. > --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 > +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Mon Feb 4 17:09:02 2002 > @@ -40,7 +40,7 @@ __pthread_spin_lock (pthread_spinlock_t > "bnez %1,1b\n\t" > " li %2,1\n\t" > "sc %2,%0\n\t" > - "beqzl %2,1b\n\t" > + "beqz %2,1b\n\t" > " ll %1,%3\n\t" > ".set pop" > : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) Is that really what you meant to do? The ll is now in the delay slot of the beqz. > --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Mon Feb 4 13:45:01 2002 > +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Mon Feb 4 17:09:36 2002 > @@ -66,7 +66,7 @@ __compare_and_swap (long int *p, long in > " move %0,$0\n\t" > "move %0,%4\n\t" > "sc %0,%2\n\t" > - "beqzl %0,1b\n\t" > + "beqz %0,1b\n\t" > " ll %1,%5\n\t" > ".set pop\n" > "2:\n\t" Ditto. > @@ -89,7 +89,7 @@ compare_and_swap (volatile long int *p, > " move %0,$0\n\t" > "move %0,%4\n\t" > "sc %0,%2\n\t" > - "beqzl %0,1b\n\t" > + "beqz %0,1b\n\t" > " ll %1,%5\n\t" > ".set pop\n" > "2:\n\t" Ditto. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Feb 4 20:42:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g154gsZ11694 for linux-mips-outgoing; Mon, 4 Feb 2002 20:42:54 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g154goA11686 for ; Mon, 4 Feb 2002 20:42:51 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 29CBA125C8; Mon, 4 Feb 2002 20:42:47 -0800 (PST) Date: Mon, 4 Feb 2002 20:42:47 -0800 From: "H . J . Lu" To: Daniel Jacobowitz Cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204204247.A25254@lucon.org> References: <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020204215804.A2095@nevyn.them.org>; from dan@debian.org on Mon, Feb 04, 2002 at 09:58:04PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 09:58:04PM -0500, Daniel Jacobowitz wrote: > > > --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 > > +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Mon Feb 4 17:09:02 2002 > > @@ -40,7 +40,7 @@ __pthread_spin_lock (pthread_spinlock_t > > "bnez %1,1b\n\t" > > " li %2,1\n\t" > > "sc %2,%0\n\t" > > - "beqzl %2,1b\n\t" > > + "beqz %2,1b\n\t" > > " ll %1,%3\n\t" > > ".set pop" > > : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) > > Is that really what you meant to do? The ll is now in the delay slot > of the beqz. Yes, it is ok since we don't care what ll does if the branch is not taken. H.J. From owner-linux-mips@oss.sgi.com Mon Feb 4 20:51:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g154pJC11848 for linux-mips-outgoing; Mon, 4 Feb 2002 20:51:19 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g154pFA11845 for ; Mon, 4 Feb 2002 20:51:15 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16XxVe-0001rD-00; Mon, 04 Feb 2002 23:47:10 -0500 Date: Mon, 4 Feb 2002 23:47:10 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020204234710.A7094@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com References: <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020204204247.A25254@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020204204247.A25254@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 08:42:47PM -0800, H . J . Lu wrote: > On Mon, Feb 04, 2002 at 09:58:04PM -0500, Daniel Jacobowitz wrote: > > > > > --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 > > > +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Mon Feb 4 17:09:02 2002 > > > @@ -40,7 +40,7 @@ __pthread_spin_lock (pthread_spinlock_t > > > "bnez %1,1b\n\t" > > > " li %2,1\n\t" > > > "sc %2,%0\n\t" > > > - "beqzl %2,1b\n\t" > > > + "beqz %2,1b\n\t" > > > " ll %1,%3\n\t" > > > ".set pop" > > > : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) > > > > Is that really what you meant to do? The ll is now in the delay slot > > of the beqz. > > Yes, it is ok since we don't care what ll does if the branch is not > taken. Won't this cause some gratuitous thrashing if someone else is trying to get the spinlock at the same time? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Feb 4 21:29:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g155TdE12673 for linux-mips-outgoing; Mon, 4 Feb 2002 21:29:39 -0800 Received: from xyzzy.stargate.net ([198.144.45.122]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g155TZA12670 for ; Mon, 4 Feb 2002 21:29:35 -0800 Received: (from justin@localhost) by xyzzy.stargate.net (8.11.6/8.11.6) id g155UMa04455; Tue, 5 Feb 2002 00:30:22 -0500 X-Authentication-Warning: xyzzy.stargate.net: justin set sender to justinca@ri.cmu.edu using -f Subject: Re: PATCH: Fix ll/sc for mips (take 3) From: Justin Carlson To: Daniel Jacobowitz Cc: "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com In-Reply-To: <20020204234710.A7094@nevyn.them.org> References: <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020204204247.A25254@lucon.org> <20020204234710.A7094@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Feb 2002 00:30:22 -0500 Message-Id: <1012887022.3343.9.camel@xyzzy.stargate.net> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 2002-02-04 at 23:47, Daniel Jacobowitz wrote: > > Won't this cause some gratuitous thrashing if someone else is trying to > get the spinlock at the same time? > Actually, if you look at the required semantics of ll, no. A ll by itself can never cause a sc from another cpu to fail. It's part of the semantic definition to avoid potential livelock cases, e.g. A does ll B does ll, foiling A's lock attempt A does sc, which fails A does ll, foiling B's lock attempt B does sc, which fails B does ll, foiling A's lock attempt ... Instead, this case becomes: A does ll B does ll A does sc, which succeeds, even though B has done a ll B does sc which fails A does critical section work B spins on ll until A releases the lock -Justin From owner-linux-mips@oss.sgi.com Mon Feb 4 22:20:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g156KXp13939 for linux-mips-outgoing; Mon, 4 Feb 2002 22:20:33 -0800 Received: from chmls18.ne.ipsvc.net (chmls18.ne.ipsvc.net [24.147.1.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g156KRA13936 for ; Mon, 4 Feb 2002 22:20:27 -0800 Received: from localhost (h00a0cc39f081.ne.mediaone.net [65.96.250.215]) by chmls18.ne.ipsvc.net (8.11.6/8.11.6) with ESMTP id g156GlG19456; Tue, 5 Feb 2002 01:16:47 -0500 (EST) Date: Tue, 5 Feb 2002 01:16:46 -0500 Subject: Re: PATCH: Fix ll/sc for mips (take 3) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Jay Carlson , Hiroyuki Machida , hjl@lucon.org, linux-mips@oss.sgi.com To: Dominic Sweetman From: Jay Carlson In-Reply-To: <15454.21812.39310.478616@gladsmuir.algor.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Monday, February 4, 2002, at 04:32 AM, Dominic Sweetman wrote: > > Hiroyuki Machida (machida@sm.sony.co.jp) writes: > >> I think we can assume CPU has branch-likely insns, if CPU has MIPS >> ISA 2 or greater ISA.. > > "MIPS II" is officially the instruction set introduced for the long > lost R6000 CPU. > > But "MIPS II" is now used to mean "the 32-bit subset of MIPS III" > (which is extremely close to the same thing, but I'm never quite sure > about the last details of the R6000 - Kevin would remember better, > probably). > > OK: branch-likely is definitely part of MIPS II and MIPS32. There are > still MIPS CPUs in regular use which are based on MIPS I and don't > provide them. Generally the advantages of MIPS II are slight, so if > you want to build a kernel which will not require instruction-set > variants, it's no big deal to restrict it to MIPS I. There's load interlocks, which you can depend on starting with MIPS II. They're also present on the TX39 and VR41xx. For non-PIC code, I see around a 5-7% reduction in userland code size by compiling with -Wa,-mips2, which afaict just eliminates the generation of nops after loads. The compiler is still generating code anticipating the delays, which is good. For PIC code, I remember the benefits being in the same range. And you're fighting gas, which will generate load-delay nops in the middle of la/lw/sw macro expansions in PIC mode regardless of what mips architecture you're building for. I made some patches against an older binutils to eliminate those nops for mips2 and up, and got ANOTHER 5-7%, of course depending on actual instruction mix. Given that I tossed out the SVR4 ABI in search of code density in snow, I'm probably a little abnormal in these concerns. But other people on small platforms may care. Jay From owner-linux-mips@oss.sgi.com Mon Feb 4 22:57:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g156v2419735 for linux-mips-outgoing; Mon, 4 Feb 2002 22:57:02 -0800 Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g156uxA19725 for ; Mon, 4 Feb 2002 22:56:59 -0800 Message-Id: <200202050656.g156uxA19725@oss.sgi.com> Received: from unknown (HELO tp240) (218.76.14.216) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Feb 2002 06:56:58 -0000 Date: Tue, 5 Feb 2002 14:58:22 +0800 From: Wu Qingbo To: "linux-mips@oss.sgi.com" Subject: can mipsel linux support UDF? X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, all, I use mipsel-2.4.2 kernel and added udf into it. When the system is up, I mount -t udf /dev/cdrom /mnt. And it is ok, but sometimes will report {Drive Ready, Seek Complete}. But when I cd /mnt, and ls, I could not find anything. Sometimes the system is pause. My question is: Can mipsel linux support UDF? My DVD-ROM can work well use iso9660 format. If someone knows, Please help me. TIA Wu Qingbo wu_qingbo2000@yahoo.com.cn _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Tue Feb 5 00:26:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g158QLR32019 for linux-mips-outgoing; Tue, 5 Feb 2002 00:26:21 -0800 Received: from dea.linux-mips.net (a1as18-p231.stg.tli.de [195.252.193.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g158QHA32000 for ; Tue, 5 Feb 2002 00:26:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g158Oag02647; Tue, 5 Feb 2002 09:24:36 +0100 Date: Tue, 5 Feb 2002 09:24:36 +0100 From: Ralf Baechle To: Wu Qingbo Cc: "linux-mips@oss.sgi.com" Subject: Re: can mipsel linux support UDF? Message-ID: <20020205092436.B2582@dea.linux-mips.net> References: <200202050656.g156uxA19725@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: <200202050656.g156uxA19725@oss.sgi.com>; from wu_qingbo2000@yahoo.com.cn on Tue, Feb 05, 2002 at 02:58:22PM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 02:58:22PM +0800, Wu Qingbo wrote: > I use mipsel-2.4.2 kernel and added udf into it. When the system is up, > I mount -t udf /dev/cdrom /mnt. And it is ok, but sometimes will > report {Drive Ready, Seek Complete}. > But when I cd /mnt, and ls, I could not find anything. Sometimes the > system is pause. My question is: Can mipsel linux support UDF? > My DVD-ROM can work well use iso9660 format. If someone knows, That still looks like some sort of hardware problem. Maybe your DVD disk has scratches or the drive is just broken enough no longer read DVD's. I have observed the same problem on non-MIPS systems. Ralf From owner-linux-mips@oss.sgi.com Tue Feb 5 00:30:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g158UXm00513 for linux-mips-outgoing; Tue, 5 Feb 2002 00:30:33 -0800 Received: from dea.linux-mips.net (a1as18-p231.stg.tli.de [195.252.193.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g158UUA00503 for ; Tue, 5 Feb 2002 00:30:30 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g158SBn02688; Tue, 5 Feb 2002 09:28:11 +0100 Date: Tue, 5 Feb 2002 09:28:11 +0100 From: Ralf Baechle To: Jay Carlson Cc: Dominic Sweetman , Hiroyuki Machida , hjl@lucon.org, linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020205092811.C2582@dea.linux-mips.net> References: <15454.21812.39310.478616@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nop@nop.com on Tue, Feb 05, 2002 at 01:16:46AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 01:16:46AM -0500, Jay Carlson wrote: > Given that I tossed out the SVR4 ABI in search of code density in snow, > I'm probably a little abnormal in these concerns. But other people on > small platforms may care. SNOW certainly was a nice invention and the definition of small is changing. Are you planning to keep up the support for SNOW? Ralf From owner-linux-mips@oss.sgi.com Tue Feb 5 00:38:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g158cxH01515 for linux-mips-outgoing; Tue, 5 Feb 2002 00:38:59 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g158ciA01489; Tue, 5 Feb 2002 00:38:45 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 5 Feb 2002 08:38:44 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 5F93EB46B; Tue, 5 Feb 2002 17:38:43 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id RAA22086; Tue, 5 Feb 2002 17:38:43 +0900 (JST) Date: Tue, 05 Feb 2002 17:43:20 +0900 (JST) Message-Id: <20020205.174320.78702446.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: endless recursive loop in pow() From: Atsushi Nemoto In-Reply-To: <200202040953.g149rrA17976@oss.sgi.com> References: <200202040953.g149rrA17976@oss.sgi.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.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Feb__5_17:43:20_2002_271)--" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----Next_Part(Tue_Feb__5_17:43:20_2002_271)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I found that pow() of glibc 2.2.4 causes stack overflow on some testcase with NaN operand. Try this simple (and dirty) test program (for little endian). main() { double x, y, z; *(int*)(&x) = 0x00000000; *((int*)(&x) + 1) = 0xfff00001; *(int*)(&y) = 0x80000000; *((int*)(&y) + 1) = 0xcff00000; z = pow(x, y); printf("%x %x\n", *((int*)&z + 1), *(int*)&z); return 0; } This program fall into endless recursive call at line 128 in sysdeps/ieee754/dbl-64/e_pow.c. 128: return (k==1)?__ieee754_pow(-x,y):-__ieee754_pow(-x,y); /* if y even or odd */ The problem occur if sign-bit of a NaN and negation of the NaN is same. I saw this problem only if the neg.d instruction was interpreted by kernel fp emulation. The patch below is a fix for kernel fp emulation. Is this a right fix? Or glibc should be fixed? --- Atsushi Nemoto ----Next_Part(Tue_Feb__5_17:43:20_2002_271)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="neg.patch" diff -u linux-sgi-cvs/arch/mips/math-emu/dp_simple.c linux.new/arch/mips/math-emu/dp_simple.c --- linux-sgi-cvs/arch/mips/math-emu/dp_simple.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/math-emu/dp_simple.c Tue Feb 5 17:36:29 2002 @@ -48,16 +48,18 @@ CLEARCX; FLUSHXDP; + /* quick fix up */ + DPSIGN(x) ^= 1; + if (xc == IEEE754_CLASS_SNAN) { + ieee754dp y = ieee754dp_indef(); SETCX(IEEE754_INVALID_OPERATION); - return ieee754dp_nanxcpt(ieee754dp_indef(), "neg"); + DPSIGN(y) = DPSIGN(x); + return ieee754dp_nanxcpt(y, "neg"); } if (ieee754dp_isnan(x)) /* but not infinity */ return ieee754dp_nanxcpt(x, "neg", x); - - /* quick fix up */ - DPSIGN(x) ^= 1; return x; } diff -u linux-sgi-cvs/arch/mips/math-emu/sp_simple.c linux.new/arch/mips/math-emu/sp_simple.c --- linux-sgi-cvs/arch/mips/math-emu/sp_simple.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/math-emu/sp_simple.c Tue Feb 5 17:36:29 2002 @@ -48,16 +48,18 @@ CLEARCX; FLUSHXSP; + /* quick fix up */ + SPSIGN(x) ^= 1; + if (xc == IEEE754_CLASS_SNAN) { + ieee754sp y = ieee754sp_indef(); SETCX(IEEE754_INVALID_OPERATION); - return ieee754sp_nanxcpt(ieee754sp_indef(), "neg"); + SPSIGN(y) = SPSIGN(x); + return ieee754sp_nanxcpt(y, "neg"); } if (ieee754sp_isnan(x)) /* but not infinity */ return ieee754sp_nanxcpt(x, "neg", x); - - /* quick fix up */ - SPSIGN(x) ^= 1; return x; } ----Next_Part(Tue_Feb__5_17:43:20_2002_271)---- From owner-linux-mips@oss.sgi.com Tue Feb 5 00:39:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g158djH01673 for linux-mips-outgoing; Tue, 5 Feb 2002 00:39:45 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g158ddA01653 for ; Tue, 5 Feb 2002 00:39:39 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA01772; Tue, 5 Feb 2002 00:39:30 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA03164; Tue, 5 Feb 2002 00:39:29 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g158d3A21047; Tue, 5 Feb 2002 09:39:04 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id JAA00051; Tue, 5 Feb 2002 09:39:27 +0100 (MET) Message-Id: <200202050839.JAA00051@copsun18.mips.com> Subject: Re: PATCH: Fix ll/sc for mips (take 3) To: justinca@ri.cmu.edu (Justin Carlson) Date: Tue, 5 Feb 2002 09:39:27 +0100 (MET) Cc: dan@debian.org (Daniel Jacobowitz), hjl@lucon.org (H . J . Lu), dom@algor.co.uk (Dominic Sweetman), libc-alpha@sources.redhat.com (GNU C Library), linux-mips@oss.sgi.com In-Reply-To: <1012887022.3343.9.camel@xyzzy.stargate.net> from "Justin Carlson" at Feb 05, 2002 12:30:22 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Note that the issue of a "LL" will trigger bus watching activity in the system logic (and maybe delays?) I would personally try to avoid issuing "dangling" ll's in the normal case, even though the functionality would be ok, and in some cases they are inavoidable. /Hartvig Justin Carlson writes: > > On Mon, 2002-02-04 at 23:47, Daniel Jacobowitz wrote: > > > > Won't this cause some gratuitous thrashing if someone else is trying to > > get the spinlock at the same time? > > > > Actually, if you look at the required semantics of ll, no. A ll by > itself can never cause a sc from another cpu to fail. It's part of the > semantic definition to avoid potential livelock cases, e.g. > > A does ll > B does ll, foiling A's lock attempt > A does sc, which fails > A does ll, foiling B's lock attempt > B does sc, which fails > B does ll, foiling A's lock attempt > ... > > Instead, this case becomes: > A does ll > B does ll > A does sc, which succeeds, even though B has done a ll > B does sc which fails > A does critical section work > B spins on ll until A releases the lock > > > -Justin > > -- _ _ _____ ____ 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 Tue Feb 5 01:51:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g159p8609646 for linux-mips-outgoing; Tue, 5 Feb 2002 01:51:08 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g159owA09632 for ; Tue, 5 Feb 2002 01:50:58 -0800 Message-Id: <200202050950.g159owA09632@oss.sgi.com> Received: (qmail 5848 invoked from network); 5 Feb 2002 09:51:27 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 5 Feb 2002 09:51:27 -0000 Date: Tue, 5 Feb 2002 17:48:18 +0800 From: Zhang Fuxin To: "H . J . Lu" CC: "linux-mips@oss.sgi.com" Subject: Re: Re: SNaN & QNaN on mips 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 g159owA09633 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, I am sorry but it seems i can't fix this without ugly changes. since i am not familiar with gcc code, i decide to leave it to you, but provide some information instead. In gcc there are 3 spaces where the NaN handling is assumed the Intel way. 1. gcc/real.c (the most important one) here the author seems to have known the NaN pattern problem,so he leaves a interface macro for defining non intel NaN patterns: (comment of function "make_nan()",at about line 6219) /* Output a binary NaN bit pattern in the target machine's format. */ /* If special NaN bit patterns are required, define them in tm.h as arrays of unsigned 16-bit shorts. Otherwise, use the default patterns here. */ I have read through this file and decided that the follow defined should be enough for mips: /* NaN pattern,mips QNAN & SNAN is different from intel's * DFMODE_NAN and SFMODE_NAN is used in real.c */ #define DFMODE_NAN \ unsigned short DFbignan[4] = {0x7ff7, 0xffff, 0xffff, 0xffff}; \ unsigned short DFlittlenan[4] = {0xffff, 0xffff, 0xffff, 0xfff7} #define SFMODE_NAN \ unsigned short SFbignan[2] = {0x7fbf, 0xffff}; \ unsigned short SFlittlenan[2] = {0xffff, 0xffbf} But the problem is where to put them:(. Obviously it is target specified definitions and should be in config/mips/. Documents say tm.h is a symbol link and included in config.h,but it is no long true.If i add them to xm-mips.h then for native compilation it is ok but it fails for cross-compile. 2.gcc/reg-stack.c There is a hardcoded QNaN used around line 477: nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); I sugest defining a macro QNAN_HAS_1ST_FRACBIT_CLEARED for mips and change it to,just don't know where to put it: #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); #else nan = gen_lowpart (SFmode, GEN_INT (0x7fbfffff)); #endif 3. config/fp-bit.c this is for machine having no fpu hardware. again i susgest define QNAN_HAS_1ST_FRACBIT_CLEARED and then apply this patch: 190d189 < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED 192,195d190 < #else < fraction &= ~QUIET_NAN; < #endif < 379,380d373 < < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED 382,384d374 < #else < if (!(fraction & QUIET_NAN)) < #endif ÔÚ 2002-02-03 22:54:00 you wrote£ş >On Mon, Feb 04, 2002 at 02:22:48PM +0800, Zhang Fuxin wrote: >> hi, >> >> Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and >> optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu >> (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both >> say so.And experiments confirm this. >> >> Should we correct it? > >Yes. Do you have a patch? > >Thanks. > > >H.J. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Feb 5 02:33:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15AXno16988 for linux-mips-outgoing; Tue, 5 Feb 2002 02:33:49 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15AXhA16974; Tue, 5 Feb 2002 02:33:43 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA10108; Tue, 5 Feb 2002 11:33:24 +0100 (MET) Date: Tue, 5 Feb 2002 11:33:23 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jason Gunthorpe , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework In-Reply-To: <20020204180258.A6124@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, 4 Feb 2002, Ralf Baechle wrote: > Bugs due to surprise memory reordering are entirely unfun to debug, so be > paranoid. They're out there to get you ... The rule of thumb is to use barriers whenever a *device* requires them and depend on the platform to define them appropriately. They will expand to nothing if unneeded, so there is no trade-off. -- + 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 Feb 5 03:39:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15BdMx27178 for linux-mips-outgoing; Tue, 5 Feb 2002 03:39:22 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15BdHA27168 for ; Tue, 5 Feb 2002 03:39:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA12048; Tue, 5 Feb 2002 12:37:06 +0100 (MET) Date: Tue, 5 Feb 2002 12:37:06 +0100 (MET) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: Justin Carlson , Daniel Jacobowitz , "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <200202050839.JAA00051@copsun18.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002, Hartvig Ekner wrote: > Note that the issue of a "LL" will trigger bus watching activity in the > system logic (and maybe delays?) I would personally try to avoid issuing > "dangling" ll's in the normal case, even though the functionality would > be ok, and in some cases they are inavoidable. I'd suppose the address comparator to be active all the time, as it's the simpler approach and involves trivial asynchronous hardware and certainly no performance hit. -- + 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 Feb 5 04:15:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15CFFt32475 for linux-mips-outgoing; Tue, 5 Feb 2002 04:15:15 -0800 Received: from dea.linux-mips.net (a1as14-p209.stg.tli.de [195.252.191.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15CFBA32462 for ; Tue, 5 Feb 2002 04:15:12 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g15CCvs04561; Tue, 5 Feb 2002 13:12:57 +0100 Date: Tue, 5 Feb 2002 13:12:57 +0100 From: Ralf Baechle To: Hartvig Ekner Cc: Justin Carlson , Daniel Jacobowitz , "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020205131257.A4482@dea.linux-mips.net> References: <1012887022.3343.9.camel@xyzzy.stargate.net> <200202050839.JAA00051@copsun18.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: <200202050839.JAA00051@copsun18.mips.com>; from hartvige@mips.com on Tue, Feb 05, 2002 at 09:39:27AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 09:39:27AM +0100, Hartvig Ekner wrote: > Note that the issue of a "LL" will trigger bus watching activity in the > system logic (and maybe delays?) I would personally try to avoid issuing > "dangling" ll's in the normal case, even though the functionality would > be ok, and in some cases they are inavoidable. Some of the processor manuals explicitly note that the execution of a ll instruction may not be visible at all externally. That's the case if the address is already in a primary cache line in exclusive (ll) or dirty (sc) state. That makes even if a processor supports full coherency since there is no reason to indicate the update to any other external agent. Or am I missing something? Ralf From owner-linux-mips@oss.sgi.com Tue Feb 5 04:31:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15CVh702203 for linux-mips-outgoing; Tue, 5 Feb 2002 04:31:43 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15CVYA02179; Tue, 5 Feb 2002 04:31:35 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA13528; Tue, 5 Feb 2002 13:31:06 +0100 (MET) Date: Tue, 5 Feb 2002 13:31:05 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Hartvig Ekner , Justin Carlson , Daniel Jacobowitz , "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <20020205131257.A4482@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 Tue, 5 Feb 2002, Ralf Baechle wrote: > Some of the processor manuals explicitly note that the execution of a > ll instruction may not be visible at all externally. That's the case if > the address is already in a primary cache line in exclusive (ll) or > dirty (sc) state. That makes even if a processor supports full coherency > since there is no reason to indicate the update to any other external > agent. Or am I missing something? By definition, apart from an ordinary load, an "ll" does only the following two additional actions: 1. Loads the LLAddr register (it's visible in CP0, at least in certain implementations) to set up the ll comparator. 2. Sets the LLbit flip-flop to set the ll state to valid initially. None of the actions should normally involve externally visible activity. -- + 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 Feb 5 04:38:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Ccu303064 for linux-mips-outgoing; Tue, 5 Feb 2002 04:38:56 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15CclA03044; Tue, 5 Feb 2002 04:38:47 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA04442; Tue, 5 Feb 2002 04:38:40 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA07880; Tue, 5 Feb 2002 04:38:37 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g15CcAA08992; Tue, 5 Feb 2002 13:38:10 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id NAA03846; Tue, 5 Feb 2002 13:38:34 +0100 (MET) Message-Id: <200202051238.NAA03846@copsun18.mips.com> Subject: Re: PATCH: Fix ll/sc for mips (take 3) To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Tue, 5 Feb 2002 13:38:34 +0100 (MET) Cc: ralf@oss.sgi.com (Ralf Baechle), hartvige@mips.com (Hartvig Ekner), justinca@ri.cmu.edu (Justin Carlson), dan@debian.org (Daniel Jacobowitz), hjl@lucon.org (H . J . Lu), dom@algor.co.uk (Dominic Sweetman), libc-alpha@sources.redhat.com (GNU C Library), linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Feb 05, 2002 01:31:05 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 Some of MIPS's cores do externalize the event of a "LL" and make it visible on the bus interface. Similarly, the SC is externalized and requires a go/nogo response from the system logic. Think of it as putting a shared LLAddr & LLBit outside the processor. The SC will only succeed if the internal LLBit is ok *and* the external logic gives the go-ahead as well. The reasoning behind all this is that one can then utilize LL/SC in multi CPU systems without full coherency support being required. But then again, this might not be relevant for MIPS/Linux as it will not run without full HW coherency on multiple CPUs? /Hartvig Maciej W. Rozycki writes: > > On Tue, 5 Feb 2002, Ralf Baechle wrote: > > > Some of the processor manuals explicitly note that the execution of a > > ll instruction may not be visible at all externally. That's the case if > > the address is already in a primary cache line in exclusive (ll) or > > dirty (sc) state. That makes even if a processor supports full coherency > > since there is no reason to indicate the update to any other external > > agent. Or am I missing something? > > By definition, apart from an ordinary load, an "ll" does only the > following two additional actions: > > 1. Loads the LLAddr register (it's visible in CP0, at least in certain > implementations) to set up the ll comparator. > > 2. Sets the LLbit flip-flop to set the ll state to valid initially. > > None of the actions should normally involve externally visible activity. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > -- _ _ _____ ____ 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 Tue Feb 5 05:30:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15DUP318730 for linux-mips-outgoing; Tue, 5 Feb 2002 05:30:25 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15DU9A18515; Tue, 5 Feb 2002 05:30:10 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA14932; Tue, 5 Feb 2002 14:29:00 +0100 (MET) Date: Tue, 5 Feb 2002 14:28:59 +0100 (MET) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: Ralf Baechle , Justin Carlson , Daniel Jacobowitz , "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <200202051238.NAA03846@copsun18.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002, Hartvig Ekner wrote: > Some of MIPS's cores do externalize the event of a "LL" and make it > visible on the bus interface. Similarly, the SC is externalized and > requires a go/nogo response from the system logic. Think of it as > putting a shared LLAddr & LLBit outside the processor. The SC will > only succeed if the internal LLBit is ok *and* the external logic gives > the go-ahead as well. OK, but an external register shouldn't need any additional CPU time to get its contents latched. > The reasoning behind all this is that one can then utilize LL/SC in > multi CPU systems without full coherency support being required. Nor should an external comparator. > But then again, this might not be relevant for MIPS/Linux as it will not > run without full HW coherency on multiple CPUs? How do you maintain coherency on such a system? To support such a model all shared area write accesses should be followed by explicit synchronization requests. It should be trivial but tedious to do for Linux, but it might not be that easy for threads. One bit I've forgotten about "ll" -- it also implies a "sync". -- + 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 Feb 5 05:48:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15DmO228987 for linux-mips-outgoing; Tue, 5 Feb 2002 05:48:24 -0800 Received: from surveyor.mars.org (surveyor.mars.org [216.98.134.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15DmIA28955 for ; Tue, 5 Feb 2002 05:48:18 -0800 Received: from mars.org (localhost [127.0.0.1]) by surveyor.mars.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id FAA32122; Tue, 5 Feb 2002 05:48:15 -0800 Message-Id: <200202051348.FAA32122@surveyor.mars.org> From: Rob Leslie To: Pete Popov Cc: linux-mips@oss.sgi.com Subject: Re: madplay on mips In-reply-to: Your message of "04 Feb 2002 10:46:54 PST." <1012848414.15163.140.camel@zeus> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Feb 2002 05:48:15 -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > Has anyone used madplay on mips to play mp3 files successfully? I've > tried it on two mips boards with different sound drivers, and in both > cases it plays the song slower and a bit muffled. It works on x86 and > supposedly ppc. Muffled sound could be the result of a poor FPM choice, or a buggy compiler. For best performance, MAD needs a multiply/accumulate instruction, which is not available on all MIPS platforms. Check the MIPS section of libmad/fixed.h and see whether you can use either of the MADD_ASM alternatives, then change your libmad/config.h to suit (or consider updating libmad/configure.in). In the worst case you might need to write a new asm alternative, or try something more generic like FPM_64BIT or FPM_DEFAULT -- though the latter could also be the cause of poor sound. I've encountered problems with certain gcc optimization options on some platforms, notably ARM and MIPS, the symptom being a sort of muffled sound result rather than the clear sound MAD ought to produce. I never traced these bugs in the compiler, so my only advice is to try different combinations of -fstrength-reduce and -finline-functions if you suspect this to be a problem. > Even though madplay claims that no floating point is used, the > disassembly of the latest version shows otherwise. But I tried it on a > board with a cpu that does have a hardware floating point unit with the > same result. The _only_ floating point used by madplay is in option parsing and calculation of peak amplitude in decibels upon completion of decoding. There is no floating point used in the decoder proper (libmad). I'm not sure what you mean by songs "playing slower" but it could be either libmad is not reaching real-time performance, or there could be issues with channel/sampling frequency selection in your sound driver. You could try -m and/or --downsample, or modify the audio output module to use a fixed known good sampling frequency. Also try sending output to a file (-o out.wav) and see if you can play that successfully with another program. If the problem is real-time performance, you can try the --enable-speed option to `configure' at the expense of some accuracy. -- Rob Leslie rob@mars.org From owner-linux-mips@oss.sgi.com Tue Feb 5 06:22:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15EMQW07935 for linux-mips-outgoing; Tue, 5 Feb 2002 06:22:26 -0800 Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15EMJA07921; Tue, 5 Feb 2002 06:22:19 -0800 Received: from exchange2.zdv.Uni-Mainz.DE (exchange2.zdv.Uni-Mainz.DE [134.93.8.113]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g15EMEh07927; Tue, 5 Feb 2002 15:22:14 +0100 (MET) Received: from exstore1.zdv.uni-mainz.de ([134.93.8.124]) by exchange2.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 15:22:11 +0100 Received: from mail pickup service by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC; Tue, 5 Feb 2002 15:22:10 +0100 Received: from mailgate1.zdv.Uni-Mainz.DE ([134.93.8.56]) by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 11:38:11 +0100 Received: from guadalquivir.fnet.fr (guadalquivir.fnet.fr [193.104.112.133]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g15AcBe21591 for ; Tue, 5 Feb 2002 11:38:11 +0100 (MET) Received: (list@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id LAA06457; Tue, 5 Feb 2002 11:34:31 +0100 (MET) Received-Date: Tue, 5 Feb 2002 11:34:24 +0100 (MET) Date: Tue, 5 Feb 2002 11:33:23 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jason Gunthorpe , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: An mb() rework In-Reply-To: <20020204180258.A6124@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: archive/latest/6639 X-Loop: linux-mips@fnet.fr X-OriginalArrivalTime: 05 Feb 2002 10:38:11.0840 (UTC) FILETIME=[3590D800:01C1AE31] Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 4 Feb 2002, Ralf Baechle wrote: > Bugs due to surprise memory reordering are entirely unfun to debug, so be > paranoid. They're out there to get you ... The rule of thumb is to use barriers whenever a *device* requires them and depend on the platform to define them appropriately. They will expand to nothing if unneeded, so there is no trade-off. -- + 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 Feb 5 06:58:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Ew6c12453 for linux-mips-outgoing; Tue, 5 Feb 2002 06:58:06 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15EvfA12401 for ; Tue, 5 Feb 2002 06:57:41 -0800 Message-Id: <200202051457.g15EvfA12401@oss.sgi.com> Received: (qmail 28346 invoked from network); 5 Feb 2002 14:58:14 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 5 Feb 2002 14:58:14 -0000 Date: Tue, 5 Feb 2002 22:54:42 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" Subject: another gcc optimization bug? 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, It seems gcc with optimization > -O2 will produce incorrect code for fp code: I find this example when tracking down the libm-test failures. ( expf(NaN) == NaN will report an extra "invalid operation" exception ) The faulting code snippet is: float __my_expf(float x) /* wrapper expf */ { float z; unsigned int hx; z = __ieee754_expf(x); if(_LIB_VERSION == _IEEE_) return z; if(__finitef(x)) { if(x>o_threshold) return 1.0; else if(x: 401290: 3c1c0fc0 lui gp,0xfc0 401294: 279c6dd0 addiu gp,gp,28112 401298: 0399e021 addu gp,gp,t9 40129c: 27bdffd0 addiu sp,sp,-48 4012a0: afbc0010 sw gp,16(sp) 4012a4: afbf0028 sw ra,40(sp) 4012a8: afbe0024 sw s8,36(sp) 4012ac: afbc0020 sw gp,32(sp) 4012b0: 03a0f021 move s8,sp 4012b4: e7cc0030 swc1 $f12,48(s8) 4012b8: c7cc0030 lwc1 $f12,48(s8) 4012bc: 8f998088 lw t9,-32632(gp) 4012c0: 00000000 nop 4012c4: 0320f809 jalr t9 4012c8: 00000000 nop 4012cc: 8fdc0010 lw gp,16(s8) 4012d0: e7c00018 swc1 $f0,24(s8) 4012d4: 8f8380ac lw v1,-32596(gp) 4012d8: 00000000 nop 4012dc: 8c630000 lw v1,0(v1) 4012e0: 2402ffff li v0,-1 4012e4: 14620004 bne v1,v0,4012f8 <__my_expf+0x68> 4012e8: 00000000 nop 4012ec: c7c00018 lwc1 $f0,24(s8) 4012f0: 10000032 b 4013bc <__my_expf+0x12c> 4012f4: 00000000 nop 4012f8: c7cc0030 lwc1 $f12,48(s8) 4012fc: 8f998090 lw t9,-32624(gp) 401300: 00000000 nop 401304: 0320f809 jalr t9 401308: 00000000 nop 40130c: 8fdc0010 lw gp,16(s8) 401310: 10400029 beqz v0,4013b8 <__my_expf+0x128> 401314: 00000000 nop 401318: c7c20030 lwc1 $f2,48(s8) 40131c: 8f818018 lw at,-32744(gp) 401320: 00000000 nop 401324: 242142a0 addiu at,at,17056 401328: c4200000 lwc1 $f0,0(at) 40132c: 00000000 nop 401330: 4602003c c.lt.s $f0,$f2 401334: 00000000 nop 401338: 45010003 bc1t 401348 <__my_expf+0xb8> 40133c: 00000000 nop 401340: 10000005 b 401358 <__my_expf+0xc8> 401344: 00000000 nop 401348: 3c013f80 lui at,0x3f80 40134c: 44810000 mtc1 at,$f0 401350: 1000001a b 4013bc <__my_expf+0x12c> 401354: 00000000 nop 401358: c7c20030 lwc1 $f2,48(s8) 40135c: 8f818018 lw at,-32744(gp) 401360: 00000000 nop 401364: 242142a4 addiu at,at,17060 401368: c4200000 lwc1 $f0,0(at) 40136c: 00000000 nop 401370: 4600103c c.lt.s $f2,$f0 401374: 00000000 nop 401378: 45010003 bc1t 401388 <__my_expf+0xf8> 40137c: 00000000 nop 401380: 10000005 b 401398 <__my_expf+0x108> 401384: 00000000 nop 401388: 3c014000 lui at,0x4000 40138c: 44810000 mtc1 at,$f0 401390: 1000000a b 4013bc <__my_expf+0x12c> 401394: 00000000 nop 401398: 8f848018 lw a0,-32744(gp) 40139c: 00000000 nop 4013a0: 248442a8 addiu a0,a0,17064 4013a4: 8f998058 lw t9,-32680(gp) 4013a8: 00000000 nop 4013ac: 0320f809 jalr t9 4013b0: 00000000 nop 4013b4: 8fdc0010 lw gp,16(s8) 4013b8: c7c00018 lwc1 $f0,24(s8) 4013bc: 03c0e821 move sp,s8 4013c0: 8fbf0028 lw ra,40(sp) 4013c4: 8fbe0024 lw s8,36(sp) 4013c8: 03e00008 jr ra 4013cc: 27bd0030 addiu sp,sp,48 2. with -O 000000000400fc0 <__my_expf>: 400fc0: 3c1c0fc0 lui gp,0xfc0 400fc4: 279c70a0 addiu gp,gp,28832 400fc8: 0399e021 addu gp,gp,t9 400fcc: 27bdffd0 addiu sp,sp,-48 400fd0: afbc0010 sw gp,16(sp) 400fd4: e7b60028 swc1 $f22,40(sp) 400fd8: e7b7002c swc1 $f23,44(sp) 400fdc: e7b40020 swc1 $f20,32(sp) 400fe0: e7b50024 swc1 $f21,36(sp) 400fe4: afbf001c sw ra,28(sp) 400fe8: 46006506 mov.s $f20,$f12 400fec: afbc0018 sw gp,24(sp) 400ff0: 8f998088 lw t9,-32632(gp) 400ff4: 00000000 nop 400ff8: 0320f809 jalr t9 400ffc: 00000000 nop 401000: 8fbc0010 lw gp,16(sp) 401004: 00000000 nop 401008: 8f8380ac lw v1,-32596(gp) 40100c: 00000000 nop 401010: 8c630000 lw v1,0(v1) 401014: 2402ffff li v0,-1 401018: 46000586 mov.s $f22,$f0 40101c: 1062000a beq v1,v0,401048 <__my_expf+0x88> 401020: 4600a306 mov.s $f12,$f20 401024: 8f998090 lw t9,-32624(gp) 401028: 00000000 nop 40102c: 0320f809 jalr t9 401030: 00000000 nop 401034: 8fbc0010 lw gp,16(sp) 401038: 44800000 mtc1 zero,$f0 40103c: 14400002 bnez v0,401048 <__my_expf+0x88> 401040: 00000000 nop 401044: 4600b006 mov.s $f0,$f22 401048: 8fbf001c lw ra,28(sp) 40104c: c7b60028 lwc1 $f22,40(sp) 401050: c7b7002c lwc1 $f23,44(sp) 401054: c7b40020 lwc1 $f20,32(sp) 401058: c7b50024 lwc1 $f21,36(sp) 40105c: 03e00008 jr ra 401060: 27bd0030 addiu sp,sp,48 3. with -O2 0000000000400fc0 <__my_expf>: 400fc0: 3c1c0fc0 lui gp,0xfc0 400fc4: 279c70a0 addiu gp,gp,28832 400fc8: 0399e021 addu gp,gp,t9 400fcc: 27bdffd0 addiu sp,sp,-48 400fd0: afbc0010 sw gp,16(sp) 400fd4: e7b60028 swc1 $f22,40(sp) 400fd8: e7b7002c swc1 $f23,44(sp) 400fdc: e7b40020 swc1 $f20,32(sp) 400fe0: e7b50024 swc1 $f21,36(sp) 400fe4: afbf001c sw ra,28(sp) 400fe8: 46006506 mov.s $f20,$f12 400fec: afbc0018 sw gp,24(sp) 400ff0: 8f998088 lw t9,-32632(gp) 400ff4: 00000000 nop 400ff8: 0320f809 jalr t9 400ffc: 00000000 nop 401000: 8fbc0010 lw gp,16(sp) 401004: 00000000 nop 401008: 8f8380ac lw v1,-32596(gp) 40100c: 00000000 nop 401010: 8c630000 lw v1,0(v1) 401014: 2402ffff li v0,-1 401018: 46000586 mov.s $f22,$f0 40101c: 10620021 beq v1,v0,4010a4 <__my_expf+0xe4> 401020: 4600a306 mov.s $f12,$f20 401024: 8f998090 lw t9,-32624(gp) 401028: 00000000 nop 40102c: 0320f809 jalr t9 401030: 00000000 nop 401034: 8fbc0010 lw gp,16(sp) 401038: 3c0142b1 lui at,0x42b1 40103c: 34217180 ori at,at,0x7180 401040: 44811000 mtc1 at,$f2 401044: 3c013f80 lui at,0x3f80 401048: 44810000 mtc1 at,$f0 40104c: 4614103c c.lt.s $f2,$f20 // this is wrongly put ahead ? 401050: 10400013 beqz v0,4010a0 <__my_expf+0xe0> 401054: 00000000 nop 401058: 45010012 bc1t 4010a4 <__my_expf+0xe4> 40105c: 00000000 nop 401060: 3c01c2cf lui at,0xc2cf 401064: 3421f1b5 ori at,at,0xf1b5 401068: 44810000 mtc1 at,$f0 40106c: 8f848018 lw a0,-32744(gp) 401070: 00000000 nop 401074: 24843fa8 addiu a0,a0,16296 401078: 4600a03c c.lt.s $f20,$f0 40107c: 3c014000 lui at,0x4000 401080: 44810000 mtc1 at,$f0 401084: 45010007 bc1t 4010a4 <__my_expf+0xe4> 401088: 00000000 nop 40108c: 8f998058 lw t9,-32680(gp) 401090: 00000000 nop 401094: 0320f809 jalr t9 401098: 00000000 nop 40109c: 8fbc0010 lw gp,16(sp) 4010a0: 4600b006 mov.s $f0,$f22 4010a4: 8fbf001c lw ra,28(sp) 4010a8: c7b60028 lwc1 $f22,40(sp) 4010ac: c7b7002c lwc1 $f23,44(sp) 4010b0: c7b40020 lwc1 $f20,32(sp) 4010b4: c7b50024 lwc1 $f21,36(sp) 4010b8: 03e00008 jr ra 4010bc: 27bd0030 addiu sp,sp,48 Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Feb 5 07:11:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15FBlc14205 for linux-mips-outgoing; Tue, 5 Feb 2002 07:11:47 -0800 Received: from chmls20.mediaone.net (chmls20.ne.ipsvc.net [24.147.1.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15FBQA14155; Tue, 5 Feb 2002 07:11:26 -0800 Received: from localhost (h00a0cc39f081.ne.mediaone.net [65.96.250.215]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id g15FCZx09366; Tue, 5 Feb 2002 10:12:35 -0500 (EST) Date: Tue, 5 Feb 2002 10:10:29 -0500 Subject: Re: PATCH: Fix ll/sc for mips (take 3) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Jay Carlson , Dominic Sweetman , Hiroyuki Machida , hjl@lucon.org, linux-mips@oss.sgi.com To: Ralf Baechle From: Jay Carlson In-Reply-To: <20020205092811.C2582@dea.linux-mips.net> Message-Id: <7E232BAE-1A4A-11D6-927F-0030658AB11E@nop.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tuesday, February 5, 2002, at 03:28 AM, Ralf Baechle wrote: > On Tue, Feb 05, 2002 at 01:16:46AM -0500, Jay Carlson wrote: > >> Given that I tossed out the SVR4 ABI in search of code density in snow, >> I'm probably a little abnormal in these concerns. But other people on >> small platforms may care. > > SNOW certainly was a nice invention and the definition of small is > changing. Are you planning to keep up the support for SNOW? Yeah, although it's slow going. As usual, "which toolchain" plays a major part in the delay :-) (Quick background for the list: Because there's such a large code size penalty to PIC/abicalls, I resurrected the bad old Linux/SVR3 statically linked, dynamically loaded libraries, which are linked at absolute locations. Shane Nay took this from a cute demo to a working distribution for the Agenda VR3; Brian Webb helped. Typical code reduction is ~25-40%, eg 391k->272k.) I think I finally have a working jumptable implementation, which should allow (careful!) upgrades of libraries without triggering app rebuilds. The pain was not actually jumptables themselves; it was getting all exported data in a library shuffled around so it could live at fixed addresses. -fdata-sections let me do most of this with linker scripts. Unfortunately, g++ was still emitting "int foo;" in ".bss", so I had to fix it to generate the proper ".bss.foo". I created a toolchain builder based on the RH71 SRPMs. About halfway through this, I remembered why I hadn't upgraded from glibc 2.0 to 2.2 before---the library size doubled. So after getting a few huge statically linked executables tested to make sure the toolchain was sound, I backtracked to uclibc and the old Agenda glibc "2.0.7". I have plausible-looking builds of both, but I haven't actually run them on real hardware..... (Is there any hope of patching glibc 2.2.4 with the sglibc patches? If so, how?) I started writing a /lib/ld-snow.so.1 to get the library loading code out of the main body of executables. I'm hoping to have a beta of a full toolchain/library build tool shipped this weekend or next, and from there hook into the community efforts to automate rebuilding the Agenda VR3 from source. I figure X and a pile of C++ fltk apps will expose any lingering bugs in the toolchain and new bugs in the shared library mechanism. I'd like to be less Agenda-centric. I think this work would benefit the Helio as well as other small platforms. But as you say, the definition of "small" is changing; hopefully in few years, machines will be big enough to support the SVR4 ABI without second thoughts. I don't know; it's possible that the really low end machines will just get cheaper instead of bigger. Speaking of small, anybody have a Linux box with a CPU with working MIPS16 support? (Other than Vr41xx; I have plenty of those to test on.) I have a small test case I'd like someone to run. Jay From owner-linux-mips@oss.sgi.com Tue Feb 5 08:06:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15G6Si21476 for linux-mips-outgoing; Tue, 5 Feb 2002 08:06:28 -0800 Received: from chmls05.mediaone.net (chmls05.ne.ipsvc.net [24.147.1.143]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15G6MA21451 for ; Tue, 5 Feb 2002 08:06:22 -0800 Received: from localhost (h00a0cc39f081.ne.mediaone.net [65.96.250.215]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id g15G64u29653; Tue, 5 Feb 2002 11:06:05 -0500 (EST) Date: Tue, 5 Feb 2002 11:06:15 -0500 Subject: Re: PATCH: Fix ll/sc for mips (take 3) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: linux-mips@oss.sgi.com To: Jay Carlson From: Jay Carlson In-Reply-To: <7E232BAE-1A4A-11D6-927F-0030658AB11E@nop.com> Message-Id: <48264C88-1A52-11D6-927F-0030658AB11E@nop.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tuesday, February 5, 2002, at 10:10 AM, Jay Carlson wrote: > (Quick background for the list: Because there's such a large code size > penalty to PIC/abicalls, I resurrected the bad old Linux/SVR3 > statically linked, dynamically loaded libraries, which are linked at > absolute locations. Shane Nay took this from a cute demo to a working > distribution for the Agenda VR3; Brian Webb helped. Typical code > reduction is ~25-40%, eg 391k->272k.) Oh yes, performance. Apps on the Agenda VR3 built in the snow ABI are dramatically faster/more responsive. If you don't believe me, go search the agenda-dev list and read the testimonials :-) I don't fully understand why, though. Here are my speculations; bear in mind that the VR3 and some of the other small boxes have 16-bit memory interfaces with small i/d caches. 1) Better icache efficiency. 2) Fewer loads (and stalls) to get typical work done. In PIC, you need a load per symbol reference, and that's every function call. 3) Better dcache efficiency. The GOT no longer needs to be hit for those symbol references. 4) Reduced TLB usage. The GOT pages for each module are quite hot, so now that we're no longer touching them, their 4k (ouch) TLB entries can point somewhere more useful. 5) No symbol resolution at load time. For C++ apps, this can help startup a lot. (prelinking fixes this too) 6) Better scheduling from gcc. egcs seemed to do a better job of arranging loads ahead of use when building non-pic; on the TX39, this helps even more due to non-blocking loads. I dunno. Jay From owner-linux-mips@oss.sgi.com Tue Feb 5 08:50:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15GoY427163 for linux-mips-outgoing; Tue, 5 Feb 2002 08:50:34 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15GoWA27156 for ; Tue, 5 Feb 2002 08:50:32 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16Y8na-0000JQ-00 for ; Tue, 05 Feb 2002 10:50:26 -0600 Message-ID: <3C600D4C.43CBA784@cotw.com> Date: Tue, 05 Feb 2002 10:50:20 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: What is the maximum physical RAM for a 32bit MIPS core? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am just trying to fill in some more MIPS knowledge here. With a 32-bit MIPS processor, we are forever limited to a userspace of 2GB in size thanks to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 is 1GB in size and hence it could address another 1GB of RAM. So, is the maximum amount of RAM for a 32bit MIPS core: 1) 1.5GB = 0.5GB kseg0/1 + 1.0GB kseg2 2) 4.0GB = largest 32-bit address 3) Something larger than 4.0GB by adding fancy external HW logic Also, for choice #3, while it would be a hit in performance, could you use the fp registers for 64-bit pointers to address larger than 4.0GB? Thanks in advance. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Tue Feb 5 09:47:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Hlk909304 for linux-mips-outgoing; Tue, 5 Feb 2002 09:47:46 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15HlfA09301 for ; Tue, 5 Feb 2002 09:47:41 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA08451; Tue, 5 Feb 2002 09:47:33 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id JAA15438; Tue, 5 Feb 2002 09:47:32 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g15Hl4A25550; Tue, 5 Feb 2002 18:47:04 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id SAA21696; Tue, 5 Feb 2002 18:47:28 +0100 (MET) Message-Id: <200202051747.SAA21696@copsun18.mips.com> Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? To: sjhill@cotw.com Date: Tue, 5 Feb 2002 18:47:28 +0100 (MET) Cc: linux-mips@oss.sgi.com In-Reply-To: <3C600D4C.43CBA784@cotw.com> from "Steven J. Hill" at Feb 05, 2002 10:50:20 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk You have to distinguish between physical and virtual memory. The MIPS32 architecture supports implementations with up to 36 bits of physical address space, however the virtual address space in kernel and user mode is as you describe below. One note: Many MIPS32 implementations choose not to implement all 36 PA bits, but limit themselves to 32 bits. This saves a few bits in the TLB and a few address lines. And no to the FP thing: FP registers can only be used to hold FP values. All addressing is done through integer registers. And any given process can only see 2GB anyway. /Hartvig Steven J. Hill writes: > > I am just trying to fill in some more MIPS knowledge here. With a 32-bit > MIPS processor, we are forever limited to a userspace of 2GB in size thanks > to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 > is 1GB in size and hence it could address another 1GB of RAM. So, is the > maximum amount of RAM for a 32bit MIPS core: > > 1) 1.5GB = 0.5GB kseg0/1 + 1.0GB kseg2 > > 2) 4.0GB = largest 32-bit address > > 3) Something larger than 4.0GB by adding fancy external HW logic > > Also, for choice #3, while it would be a hit in performance, could you use > the fp registers for 64-bit pointers to address larger than 4.0GB? > > Thanks in advance. > > -Steve > > -- > Steven J. Hill - Embedded SW Engineer > -- _ _ _____ ____ 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 Tue Feb 5 11:28:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JSof30389 for linux-mips-outgoing; Tue, 5 Feb 2002 11:28:50 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JSiA30386 for ; Tue, 5 Feb 2002 11:28:44 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA10568; Tue, 5 Feb 2002 11:28:36 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA21674; Tue, 5 Feb 2002 11:28:36 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g15JSAA29091; Tue, 5 Feb 2002 20:28:10 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id UAA21774; Tue, 5 Feb 2002 20:28:34 +0100 (MET) Message-Id: <200202051928.UAA21774@copsun18.mips.com> Subject: Re: PATCH: Fix ll/sc for mips (take 3) To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Tue, 5 Feb 2002 20:28:34 +0100 (MET) Cc: linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Feb 05, 2002 02:28:59 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 Maciej W. Rozycki writes: > How do you maintain coherency on such a system? To support such a model > all shared area write accesses should be followed by explicit > synchronization requests. It should be trivial but tedious to do for > Linux, but it might not be that easy for threads. This would have to be a loosely coupled system - something using either software coherency or uncached accesses for the shared areas. And then LL/SC for synchronization primitives. There are a fair number of SOC designs like this, even with more than two processors. /Hartvig From owner-linux-mips@oss.sgi.com Tue Feb 5 11:30:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JUaF30901 for linux-mips-outgoing; Tue, 5 Feb 2002 11:30:36 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JUIA30898 for ; Tue, 5 Feb 2002 11:30:18 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5C5A5125CC; Tue, 5 Feb 2002 11:30:17 -0800 (PST) Date: Tue, 5 Feb 2002 11:30:17 -0800 From: "H . J . Lu" To: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020205113017.A6144@lucon.org> References: <20020201222657.A13339@nevyn.them.org> <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020204215804.A2095@nevyn.them.org>; from dan@debian.org on Mon, Feb 04, 2002 at 09:58:04PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Feb 04, 2002 at 09:58:04PM -0500, Daniel Jacobowitz wrote: > On Mon, Feb 04, 2002 at 05:28:57PM -0800, H . J . Lu wrote: > > On Mon, Feb 04, 2002 at 04:46:07PM +0000, Dominic Sweetman wrote: > > > > > > H . J . Lu (hjl@lucon.org) writes: > > > > > > > I can change glibc not to use branch-likely without using nop. But it > > > > may require one or two instructions outside of the loop. Should I do > > > > it given what we know now? > > > > > > I would not recommend using "branch likely" in assembler coding, if > > > that's what you're asking. > > > > > > > Here is a patch to remove branch likely. But I couldn't find a way > > not to fill the delay slot with nop. BTW, is that safe to remove > > ".set noreorder"? > > You mean, if there is nothing which can be put there? Yes, it's safe. > Here is a new patch. I removed the extra "ll" in the delay slot. H.J. --- 2002-02-05 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Not use branch likely. Remove ".set noreorder". * sysdeps/mips/pt-machine.h (testandset): Liekwise. (__compare_and_swap): Liekwise. 2002-02-05 H.J. Lu * sysdeps/mips/atomicity.h (exchange_and_add): Not use branch likely. Remove ".set noreorder". (atomic_add): Likewise. (compare_and_swap): Likewise. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Likewise. --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Tue Feb 5 11:26:22 2002 @@ -32,17 +32,13 @@ __pthread_spin_lock (pthread_spinlock_t unsigned int tmp1, tmp2; asm volatile - ("\t\t\t# spin_lock\n\t" - "ll %1,%3\n" + ("\t\t\t# spin_lock\n" "1:\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "ll %1,%3\n" "bnez %1,1b\n\t" " li %2,1\n\t" "sc %2,%0\n\t" - "beqzl %2,1b\n\t" - " ll %1,%3\n\t" - ".set pop" + "beqz %2,1b\n\t" : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) : "memory"); --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Tue Feb 5 11:26:51 2002 @@ -57,18 +57,14 @@ __compare_and_swap (long int *p, long in long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" - "ll %1,%5\n" + ("/* Inline compare & swap */\n" "1:\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "ll %1,%5\n" "bne %1,%3,2f\n\t" " move %0,$0\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" - " ll %1,%5\n\t" - ".set pop\n" + "beqz %0,1b\n\t" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) --- libc/sysdeps/mips/atomicity.h.llsc Mon Feb 4 13:45:18 2002 +++ libc/sysdeps/mips/atomicity.h Tue Feb 5 11:25:09 2002 @@ -32,16 +32,12 @@ exchange_and_add (volatile uint32_t *mem int result, tmp; __asm__ __volatile__ - ("/* Inline exchange & add */\n\t" + ("/* Inline exchange & add */\n" + "1:\n" "ll %0,%3\n" - "1:\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" - ".set pop\n\t" + "beqz %1,1b\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) : "m" (*mem), "r"(val) @@ -57,16 +53,12 @@ atomic_add (volatile uint32_t *mem, int int result; __asm__ __volatile__ - ("/* Inline atomic add */\n\t" - "ll %0,%2\n" + ("/* Inline atomic add */\n" "1:\n\t" + "ll %0,%2\n" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "beqzl %0,1b\n\t" - " ll %0,%2\n\t" - ".set pop\n\t" + "beqz %0,1b\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) : "m" (*mem), "r"(val) @@ -80,18 +72,14 @@ compare_and_swap (volatile long int *p, long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" - "ll %1,%5\n" + ("/* Inline compare & swap */\n" "1:\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "ll %1,%5\n" "bne %1,%3,2f\n\t" " move %0,$0\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" - " ll %1,%5\n\t" - ".set pop\n" + "beqz %0,1b\n\t" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) --- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Feb 4 13:45:28 2002 +++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h Tue Feb 5 11:25:34 2002 @@ -42,17 +42,13 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("/* Inline test and set */\n\t" - "ll %0,%3\n" + ("/* Inline test and set */\n" "1:\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "ll %0,%3\n" "beq %0,%4,2f\n\t" " move %1,%4\n\t" "sc %1,%2\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" - ".set pop\n" + "beqz %1,1b\n\t" "2:\n\t" "/* End test and set */" : "=&r" (r), "=&r" (t), "=m" (*p) From owner-linux-mips@oss.sgi.com Tue Feb 5 11:30:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15JUos30968 for linux-mips-outgoing; Tue, 5 Feb 2002 11:30:50 -0800 Received: from dea.linux-mips.net (a1as03-p87.stg.tli.de [195.252.186.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15JUkA30961 for ; Tue, 5 Feb 2002 11:30:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g15IxDK07734; Tue, 5 Feb 2002 19:59:13 +0100 Date: Tue, 5 Feb 2002 19:59:12 +0100 From: Ralf Baechle To: Hartvig Ekner Cc: "Maciej W. Rozycki" , Justin Carlson , Daniel Jacobowitz , "H . J . Lu" , Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020205195912.A7023@dea.linux-mips.net> References: <200202051238.NAA03846@copsun18.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: <200202051238.NAA03846@copsun18.mips.com>; from hartvige@mips.com on Tue, Feb 05, 2002 at 01:38:34PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 01:38:34PM +0100, Hartvig Ekner wrote: > Some of MIPS's cores do externalize the event of a "LL" and make it > visible on the bus interface. Similarly, the SC is externalized and > requires a go/nogo response from the system logic. Think of it as > putting a shared LLAddr & LLBit outside the processor. The SC will > only succeed if the internal LLBit is ok *and* the external logic gives > the go-ahead as well. > > The reasoning behind all this is that one can then utilize LL/SC in > multi CPU systems without full coherency support being required. > > But then again, this might not be relevant for MIPS/Linux as it will not > run without full HW coherency on multiple CPUs? Linux could easily be hacked into handle such a configuration as a cluster. Anything else would be a pretty large job. Ralf From owner-linux-mips@oss.sgi.com Tue Feb 5 12:46:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Kkp805016 for linux-mips-outgoing; Tue, 5 Feb 2002 12:46:51 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15KklA04983 for ; Tue, 5 Feb 2002 12:46:47 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16YCUC-0000XP-00; Tue, 05 Feb 2002 14:46:40 -0600 Message-ID: <3C6044A7.13FEB2E2@cotw.com> Date: Tue, 05 Feb 2002 14:46:31 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Hartvig Ekner CC: linux-mips@oss.sgi.com Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? References: <200202051747.SAA21696@copsun18.mips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hartvig Ekner wrote: > > You have to distinguish between physical and virtual memory. The MIPS32 > architecture supports implementations with up to 36 bits of physical > address space, however the virtual address space in kernel and user mode > is as you describe below. > I wasn't talking about the MIP32[tm] cores specifically, I was using a generalization of 32bit. However, this is good to know. All of the data sheets that I just downloaded from the MIPS site for the R4k[X] cores don't mention the 36-bit PA item. Care to elaborate? > One note: Many MIPS32 implementations choose not to implement all 36 PA > bits, but limit themselves to 32 bits. This saves a few bits in the TLB > and a few address lines. > So, if someone did want 36 PA bits on Linux, the TLB exception handlers and a little of the page table construction/management code would have to change. The userspace contraints and such would still remain. Cool. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Tue Feb 5 12:54:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15KsCH10683 for linux-mips-outgoing; Tue, 5 Feb 2002 12:54:12 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15Ks8A10637 for ; Tue, 5 Feb 2002 12:54:08 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA12073; Tue, 5 Feb 2002 12:54:02 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA25903; Tue, 5 Feb 2002 12:54:00 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g15KrYA01845; Tue, 5 Feb 2002 21:53:34 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id VAA21843; Tue, 5 Feb 2002 21:53:58 +0100 (MET) Message-Id: <200202052053.VAA21843@copsun18.mips.com> Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? To: sjhill@cotw.com Date: Tue, 5 Feb 2002 21:53:58 +0100 (MET) Cc: hartvige@mips.com (Hartvig Ekner), linux-mips@oss.sgi.com In-Reply-To: <3C6044A7.13FEB2E2@cotw.com> from "Steven J. Hill" at Feb 05, 2002 02:46:31 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Steven J. Hill writes: > > Hartvig Ekner wrote: > > > > You have to distinguish between physical and virtual memory. The MIPS32 > > architecture supports implementations with up to 36 bits of physical > > address space, however the virtual address space in kernel and user mode > > is as you describe below. > > > I wasn't talking about the MIP32[tm] cores specifically, I was using a > generalization of 32bit. However, this is good to know. All of the data > sheets that I just downloaded from the MIPS site for the R4k[X] cores > don't mention the 36-bit PA item. Care to elaborate? Sure. All the 4K, 4KE and 4KS families (all MIPS32 cores) from MTI only provide 32 bits of PA. The 5K and 20K families (MIPS64 implementations) both provide 36 bit of PA. Also note that all of the above is only relevant for cores which have a TLB. The low-end 4K/4KE/4KS cores all come in variants without TLB (to save die area) and these can of course only generate 32-bits of PA regardless. /Hartvig From owner-linux-mips@oss.sgi.com Tue Feb 5 13:13:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15LD5Z14875 for linux-mips-outgoing; Tue, 5 Feb 2002 13:13:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LD1A14871 for ; Tue, 5 Feb 2002 13:13:02 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g15LAoB19474; Tue, 5 Feb 2002 13:10:50 -0800 Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? From: Pete Popov To: sjhill@cotw.com Cc: Hartvig Ekner , linux-mips In-Reply-To: <3C6044A7.13FEB2E2@cotw.com> References: <200202051747.SAA21696@copsun18.mips.com> <3C6044A7.13FEB2E2@cotw.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 05 Feb 2002 13:15:09 -0800 Message-Id: <1012943709.10659.106.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2002-02-05 at 12:46, Steven J. Hill wrote: > Hartvig Ekner wrote: > > > > You have to distinguish between physical and virtual memory. The MIPS32 > > architecture supports implementations with up to 36 bits of physical > > address space, however the virtual address space in kernel and user mode > > is as you describe below. > > > I wasn't talking about the MIP32[tm] cores specifically, I was using a > generalization of 32bit. However, this is good to know. All of the data > sheets that I just downloaded from the MIPS site for the R4k[X] cores > don't mention the 36-bit PA item. Care to elaborate? > > > One note: Many MIPS32 implementations choose not to implement all 36 PA > > bits, but limit themselves to 32 bits. This saves a few bits in the TLB > > and a few address lines. > > > So, if someone did want 36 PA bits on Linux, the TLB exception handlers > and a little of the page table construction/management code would have to > change. The userspace contraints and such would still remain. Cool. I'm not sure if it's a "little" though. Ralf has already done the work for 64bit memory support on 32bit kernels, but that only works currently on 64bit CPUs. I started hacking on the 64bit memory patch to get it to work on 32bit processors, but had to put that aside for a few weeks. I hope to get back to it soon. Pete From owner-linux-mips@oss.sgi.com Tue Feb 5 13:24:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15LOOI15252 for linux-mips-outgoing; Tue, 5 Feb 2002 13:24:24 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LOLA15248 for ; Tue, 5 Feb 2002 13:24:21 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16YD4W-0000aG-00; Tue, 05 Feb 2002 15:24:12 -0600 Message-ID: <3C604D73.88F1CDCE@cotw.com> Date: Tue, 05 Feb 2002 15:24:03 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: Hartvig Ekner , linux-mips Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? References: <200202051747.SAA21696@copsun18.mips.com> <3C6044A7.13FEB2E2@cotw.com> <1012943709.10659.106.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > > I'm not sure if it's a "little" though. Ralf has already done the work > for 64bit memory support on 32bit kernels, but that only works currently > on 64bit CPUs. I started hacking on the 64bit memory patch to get it to > work on 32bit processors, but had to put that aside for a few weeks. I > hope to get back to it soon. > Sure, the "little" is a relative term. As far as your patch is concerned, you are essentially trying to use a true 32-bit processor (my definition being that it is not a 64-bit processor running in 32-bit mode), to address address more than 4GB of physical memory. I don't see how that is possible with just the MMU and TLB unless you are using chip selects and customm logic. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Tue Feb 5 13:41:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Lfvq15520 for linux-mips-outgoing; Tue, 5 Feb 2002 13:41:57 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LfsA15517 for ; Tue, 5 Feb 2002 13:41:54 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g15LdjB21511; Tue, 5 Feb 2002 13:39:45 -0800 Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? From: Pete Popov To: sjhill@cotw.com Cc: Hartvig Ekner , linux-mips In-Reply-To: <3C604D73.88F1CDCE@cotw.com> References: <200202051747.SAA21696@copsun18.mips.com> <3C6044A7.13FEB2E2@cotw.com> <1012943709.10659.106.camel@zeus> <3C604D73.88F1CDCE@cotw.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 05 Feb 2002 13:44:03 -0800 Message-Id: <1012945444.10720.113.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2002-02-05 at 13:24, Steven J. Hill wrote: > Pete Popov wrote: > > > > I'm not sure if it's a "little" though. Ralf has already done the work > > for 64bit memory support on 32bit kernels, but that only works currently > > on 64bit CPUs. I started hacking on the 64bit memory patch to get it to > > work on 32bit processors, but had to put that aside for a few weeks. I > > hope to get back to it soon. > > > Sure, the "little" is a relative term. As far as your patch is concerned, > you are essentially trying to use a true 32-bit processor (my definition > being that it is not a 64-bit processor running in 32-bit mode), to address > address more than 4GB of physical memory. I don't see how that is possible > with just the MMU and TLB unless you are using chip selects and customm > logic. I failed to mention that the additional patch, once working, would be for MIPS32 (as in the MIPS Tech's MIPS32 spec, not just any 32 bit CPU) CPUs that implemented the full 36 bit physical address space. So the support really won't be 64bit, it will be 36bit. Pete From owner-linux-mips@oss.sgi.com Tue Feb 5 13:54:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15LsHe15818 for linux-mips-outgoing; Tue, 5 Feb 2002 13:54:17 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15Ls9A15815 for ; Tue, 5 Feb 2002 13:54:09 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 09DAF125C8; Tue, 5 Feb 2002 13:54:08 -0800 (PST) Date: Tue, 5 Feb 2002 13:54:07 -0800 From: "H . J . Lu" To: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020205135407.A8309@lucon.org> References: <1012676003.1563.6.camel@xyzzy.stargate.net> <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020205113017.A6144@lucon.org>; from hjl@lucon.org on Tue, Feb 05, 2002 at 11:30:17AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 11:30:17AM -0800, H . J . Lu wrote: > On Mon, Feb 04, 2002 at 09:58:04PM -0500, Daniel Jacobowitz wrote: > > On Mon, Feb 04, 2002 at 05:28:57PM -0800, H . J . Lu wrote: > > > On Mon, Feb 04, 2002 at 04:46:07PM +0000, Dominic Sweetman wrote: > > > > > > > > H . J . Lu (hjl@lucon.org) writes: > > > > > > > > > I can change glibc not to use branch-likely without using nop. But it > > > > > may require one or two instructions outside of the loop. Should I do > > > > > it given what we know now? > > > > > > > > I would not recommend using "branch likely" in assembler coding, if > > > > that's what you're asking. > > > > > > > > > > Here is a patch to remove branch likely. But I couldn't find a way > > > not to fill the delay slot with nop. BTW, is that safe to remove > > > ".set noreorder"? > > > > You mean, if there is nothing which can be put there? Yes, it's safe. > > > > Here is a new patch. I removed the extra "ll" in the delay slot. > This patch is wrong. The assmebler turns that into 0x2ab0f724 <__pthread_alt_lock+212>: ll v1,0(s1) 0x2ab0f728 <__pthread_alt_lock+216>: bne v1,s0,0x2ab0f744 <__pthread_alt_lock+244> 0x2ab0f72c <__pthread_alt_lock+220>: nop 0x2ab0f730 <__pthread_alt_lock+224>: move a1,zero 0x2ab0f734 <__pthread_alt_lock+228>: move a1,v0 0x2ab0f738 <__pthread_alt_lock+232>: sc a1,0(s1) 0x2ab0f73c <__pthread_alt_lock+236>: beqz a1,0x2ab0f724 <__pthread_alt_lock+212> 0x2ab0f740 <__pthread_alt_lock+240>: nop If I do __asm__ __volatile__ ("/* Inline compare & swap */\n" "1:\n\t" "ll %1,%5\n\t" "move %0,$0\n\t" "bne %1,%3,2f\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" "beqz %0,1b\n\t" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); The assembler will do 0xd724 <__pthread_alt_lock+212>: ll v1,0(s1) 0xd728 <__pthread_alt_lock+216>: move a1,zero 0xd72c <__pthread_alt_lock+220>: bne v1,s0,0xd744 <__pthread_alt_lock+244> 0xd730 <__pthread_alt_lock+224>: nop 0xd734 <__pthread_alt_lock+228>: move a1,v0 0xd738 <__pthread_alt_lock+232>: sc a1,0(s1) 0xd73c <__pthread_alt_lock+236>: beqz a1,0xd724 <__pthread_alt_lock+212> 0xd740 <__pthread_alt_lock+240>: nop There is an extra "nop" in the delay slot. I don't think gas is smart enough to fill the delay slot. I will put back those ".set noredor". H.J. From owner-linux-mips@oss.sgi.com Tue Feb 5 13:57:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15LvfA16018 for linux-mips-outgoing; Tue, 5 Feb 2002 13:57:41 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15LvUA16012 for ; Tue, 5 Feb 2002 13:57:32 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id DAF41590A9; Tue, 5 Feb 2002 16:49:21 -0500 (EST) Message-ID: <02a001c1ae90$43748d40$5601010a@prefect> From: "Bradley D. LaRonde" To: Cc: "linux-mips" References: <200202051747.SAA21696@copsun18.mips.com> <3C6044A7.13FEB2E2@cotw.com> <1012943709.10659.106.camel@zeus> <3C604D73.88F1CDCE@cotw.com> Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? Date: Tue, 5 Feb 2002 16:58:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Steven J. Hill" To: "Pete Popov" Cc: "Hartvig Ekner" ; "linux-mips" Sent: Tuesday, February 05, 2002 4:24 PM Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? > Pete Popov wrote: > > > > I'm not sure if it's a "little" though. Ralf has already done the work > > for 64bit memory support on 32bit kernels, but that only works currently > > on 64bit CPUs. I started hacking on the 64bit memory patch to get it to > > work on 32bit processors, but had to put that aside for a few weeks. I > > hope to get back to it soon. > > > Sure, the "little" is a relative term. As far as your patch is concerned, > you are essentially trying to use a true 32-bit processor (my definition > being that it is not a 64-bit processor running in 32-bit mode), to address > address more than 4GB of physical memory. I don't see how that is possible > with just the MMU and TLB unless you are using chip selects and customm > logic. As already mentioned, a MIPS TLB entry typically can point with 36 bits (that's 67TB of address space?) at physical memory. If you have more than 2^31 bytes of physical memory, then a single process can't map all of physical memory into it's address space, but it can map in pages (using TLB entries) from anywhere within the 36-bit physical memory space. In other words, process address space doesn't limit physical address space. Only TLB capability limits physical address space. And right, KSEG0 and KSEG1 can only get at the low 0.5GB of physical memory. You can imagine that KSEG0 is implemented with a single hardwired TLB entry that maps virtual address 0x80000000 to physical address 0x0, 0.5GB wide. The only way to get to physical memory above 0.5GB is through a TLB entry. Regards, Brad From owner-linux-mips@oss.sgi.com Tue Feb 5 15:05:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15N57522011 for linux-mips-outgoing; Tue, 5 Feb 2002 15:05:07 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15N4tA21965 for ; Tue, 5 Feb 2002 15:04:55 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 54B88125C8; Tue, 5 Feb 2002 15:04:54 -0800 (PST) Date: Tue, 5 Feb 2002 15:04:54 -0800 From: "H . J . Lu" To: Zhang Fuxin Cc: gcc-patches@gcc.gnu.org, "linux-mips @ oss . sgi . com" Subject: PATCH: Re: SNaN & QNaN on mips Message-ID: <20020205150454.A8759@lucon.org> References: <20020205095056.735A5125C8@ocean.lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020205095056.735A5125C8@ocean.lucon.org>; from fxzhang@ict.ac.cn on Tue, Feb 05, 2002 at 05:48:18PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 05:48:18PM +0800, Zhang Fuxin wrote: > hi, > > I am sorry but it seems i can't fix this without ugly changes. > since i am not familiar with gcc code, i decide to leave it to you, > but provide some information instead. > > In gcc there are 3 spaces where the NaN handling is assumed the > Intel way. > > 1. gcc/real.c (the most important one) > here the author seems to have known the NaN pattern problem,so > he leaves a interface macro for defining non intel NaN patterns: > (comment of function "make_nan()",at about line 6219) > > /* Output a binary NaN bit pattern in the target machine's format. */ > > /* If special NaN bit patterns are required, define them in tm.h > as arrays of unsigned 16-bit shorts. Otherwise, use the default > patterns here. */ > > I have read through this file and decided that the follow defined should > be enough for mips: > > /* NaN pattern,mips QNAN & SNAN is different from intel's > * DFMODE_NAN and SFMODE_NAN is used in real.c */ > #define DFMODE_NAN \ > unsigned short DFbignan[4] = {0x7ff7, 0xffff, 0xffff, 0xffff}; \ > unsigned short DFlittlenan[4] = {0xffff, 0xffff, 0xffff, 0xfff7} > #define SFMODE_NAN \ > unsigned short SFbignan[2] = {0x7fbf, 0xffff}; \ > unsigned short SFlittlenan[2] = {0xffff, 0xffbf} > > But the problem is where to put them:(. Obviously it is target specified > definitions and should be in config/mips/. Documents say tm.h is a symbol > link and included in config.h,but it is no long true.If i add them to xm-mips.h > then for native compilation it is ok but it fails for cross-compile. I am enclosing a patch here. > > 2.gcc/reg-stack.c > There is a hardcoded QNaN used around line 477: > nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); > I sugest defining a macro QNAN_HAS_1ST_FRACBIT_CLEARED for mips and change > it to,just don't know where to put it: > #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED > nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); > #else > nan = gen_lowpart (SFmode, GEN_INT (0x7fbfffff)); > #endif MIPS doesn't use reg-stack.c. > > 3. config/fp-bit.c > this is for machine having no fpu hardware. > again i susgest define QNAN_HAS_1ST_FRACBIT_CLEARED and then apply this patch: > > 190d189 > < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED > 192,195d190 > < #else > < fraction &= ~QUIET_NAN; > < #endif > < > 379,380d373 > < > < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED > 382,384d374 > < #else > < if (!(fraction & QUIET_NAN)) > < #endif This one is tricky. fp-bit.c is not supposed to be target specific. I think we add SET_QUIET_NAN/IS_QUIET_NAN and provide the special ones for MIPS. H.J. ---- 2002-02-05 H.J. Lu Base on suggestions from Zhang Fuxin : * config/mips/mips.h (DFMODE_NAN): Defined. (SFMODE_NAN): Likewise. --- gcc/config/mips/mips.h.ieee Thu Nov 15 12:21:17 2001 +++ gcc/config/mips/mips.h Tue Feb 5 14:38:11 2002 @@ -4637,3 +4637,10 @@ do \ } \ } \ while (0) + +#define DFMODE_NAN \ + unsigned short DFbignan[4] = {0x7ff7, 0xffff, 0xffff, 0xffff}; \ + unsigned short DFlittlenan[4] = {0xffff, 0xffff, 0xffff, 0xfff7} +#define SFMODE_NAN \ + unsigned short SFbignan[2] = {0x7fbf, 0xffff}; \ + unsigned short SFlittlenan[2] = {0xffff, 0xffbf} From owner-linux-mips@oss.sgi.com Tue Feb 5 15:44:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15NigY24816 for linux-mips-outgoing; Tue, 5 Feb 2002 15:44:42 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15NicA24813 for ; Tue, 5 Feb 2002 15:44:38 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id A73B4125C8; Tue, 5 Feb 2002 15:44:37 -0800 (PST) Date: Tue, 5 Feb 2002 15:44:37 -0800 From: "H . J . Lu" To: Zhang Fuxin Cc: "linux-mips@oss.sgi.com" Subject: Re: another gcc optimization bug? Message-ID: <20020205154437.A9605@lucon.org> References: <200202051457.g15EvfA12401@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: <200202051457.g15EvfA12401@oss.sgi.com>; from fxzhang@ict.ac.cn on Tue, Feb 05, 2002 at 10:54:42PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 10:54:42PM +0800, Zhang Fuxin wrote: > hi, > It seems gcc with optimization > -O2 will produce incorrect code for fp code: > I find this example when tracking down the libm-test failures. > ( expf(NaN) == NaN will report an extra "invalid operation" exception ) > The faulting code snippet is: > float __my_expf(float x) /* wrapper expf */ > { > float z; > unsigned int hx; > z = __ieee754_expf(x); > if(_LIB_VERSION == _IEEE_) return z; > if(__finitef(x)) { > if(x>o_threshold) > return 1.0; > else if(x return 2.0; > printf("haha\n"); > } > return z; > } > > with -O2(or higher),some statements inside "if (__finitef(x))" are put before > testing the return value of __finitef(x),one of which is a c.lt.s that cause > the extra "invalid operation" exception being raised. > This bug seem fixed in gcc 3.1. H.J. From owner-linux-mips@oss.sgi.com Tue Feb 5 18:03:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16234e05019 for linux-mips-outgoing; Tue, 5 Feb 2002 18:03:04 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1622jA05015 for ; Tue, 5 Feb 2002 18:02:45 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 81605125C8; Tue, 5 Feb 2002 18:02:43 -0800 (PST) Date: Tue, 5 Feb 2002 18:02:43 -0800 From: "H . J . Lu" To: linux-mips@oss.sgi.com, GNU C Library Subject: PATCH: Not use branch likely on mips Message-ID: <20020205180243.A11993@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 patch removes branch likely. H.J. ---- 2002-02-05 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Not use branch likely. * sysdeps/mips/pt-machine.h (testandset): Liekwise. (__compare_and_swap): Liekwise. 2002-02-05 H.J. Lu * sysdeps/mips/atomicity.h (exchange_and_add): Not use branch likely. (atomic_add): Likewise. (compare_and_swap): Likewise. * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Likewise. --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Tue Feb 5 14:11:01 2002 @@ -32,17 +32,16 @@ __pthread_spin_lock (pthread_spinlock_t unsigned int tmp1, tmp2; asm volatile - ("\t\t\t# spin_lock\n\t" - "ll %1,%3\n" + ("\t\t\t# spin_lock\n" "1:\n\t" + "ll %1,%3\n\t" ".set push\n\t" ".set noreorder\n\t" "bnez %1,1b\n\t" " li %2,1\n\t" + ".set pop\n\t" "sc %2,%0\n\t" - "beqzl %2,1b\n\t" - " ll %1,%3\n\t" - ".set pop" + "beqz %2,1b" : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) : "m" (*lock) : "memory"); --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Mon Feb 4 13:45:01 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Tue Feb 5 14:01:11 2002 @@ -57,18 +57,17 @@ __compare_and_swap (long int *p, long in long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" - "ll %1,%5\n" + ("/* Inline compare & swap */\n" "1:\n\t" + "ll %1,%5\n\t" ".set push\n\t" ".set noreorder\n\t" "bne %1,%3,2f\n\t" " move %0,$0\n\t" + ".set pop\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" - " ll %1,%5\n\t" - ".set pop\n" + "beqz %0,1b\n" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) --- libc/sysdeps/mips/atomicity.h.llsc Mon Feb 4 13:45:18 2002 +++ libc/sysdeps/mips/atomicity.h Tue Feb 5 13:58:59 2002 @@ -32,16 +32,12 @@ exchange_and_add (volatile uint32_t *mem int result, tmp; __asm__ __volatile__ - ("/* Inline exchange & add */\n\t" - "ll %0,%3\n" + ("/* Inline exchange & add */\n" "1:\n\t" + "ll %0,%3\n\t" "addu %1,%4,%0\n\t" "sc %1,%2\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" - ".set pop\n\t" + "beqz %1,1b\n\t" "/* End exchange & add */" : "=&r"(result), "=&r"(tmp), "=m"(*mem) : "m" (*mem), "r"(val) @@ -57,16 +53,12 @@ atomic_add (volatile uint32_t *mem, int int result; __asm__ __volatile__ - ("/* Inline atomic add */\n\t" - "ll %0,%2\n" + ("/* Inline atomic add */\n" "1:\n\t" + "ll %0,%2\n\t" "addu %0,%3,%0\n\t" "sc %0,%1\n\t" - ".set push\n\t" - ".set noreorder\n\t" - "beqzl %0,1b\n\t" - " ll %0,%2\n\t" - ".set pop\n\t" + "beqz %0,1b\n\t" "/* End atomic add */" : "=&r"(result), "=m"(*mem) : "m" (*mem), "r"(val) @@ -80,18 +72,17 @@ compare_and_swap (volatile long int *p, long int ret, temp; __asm__ __volatile__ - ("/* Inline compare & swap */\n\t" - "ll %1,%5\n" + ("/* Inline compare & swap */\n" "1:\n\t" + "ll %1,%5\n\t" ".set push\n\t" ".set noreorder\n\t" "bne %1,%3,2f\n\t" " move %0,$0\n\t" + ".set pop\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" - "beqzl %0,1b\n\t" - " ll %1,%5\n\t" - ".set pop\n" + "beqz %0,1b\n" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) --- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Mon Feb 4 13:45:28 2002 +++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h Tue Feb 5 13:59:52 2002 @@ -42,17 +42,16 @@ _test_and_set (int *p, int v) __THROW int r, t; __asm__ __volatile__ - ("/* Inline test and set */\n\t" - "ll %0,%3\n" + ("/* Inline test and set */\n" "1:\n\t" + "ll %0,%3\n\t" ".set push\n\t" ".set noreorder\n\t" "beq %0,%4,2f\n\t" " move %1,%4\n\t" + ".set pop\n\t" "sc %1,%2\n\t" - "beqzl %1,1b\n\t" - " ll %0,%3\n\t" - ".set pop\n" + "beqz %1,1b\n" "2:\n\t" "/* End test and set */" : "=&r" (r), "=&r" (t), "=m" (*p) From owner-linux-mips@oss.sgi.com Tue Feb 5 18:35:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g162Zbe05324 for linux-mips-outgoing; Tue, 5 Feb 2002 18:35:37 -0800 Received: from dea.linux-mips.net (a1as11-p112.stg.tli.de [195.252.190.112]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g162ZXA05321 for ; Tue, 5 Feb 2002 18:35:33 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g162Xkf11663; Wed, 6 Feb 2002 03:33:46 +0100 Date: Wed, 6 Feb 2002 03:33:46 +0100 From: Ralf Baechle To: "Steven J. Hill" Cc: linux-mips@oss.sgi.com Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? Message-ID: <20020206033346.A7298@dea.linux-mips.net> References: <3C600D4C.43CBA784@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C600D4C.43CBA784@cotw.com>; from sjhill@cotw.com on Tue, Feb 05, 2002 at 10:50:20AM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 10:50:20AM -0600, Steven J. Hill wrote: > I am just trying to fill in some more MIPS knowledge here. With a 32-bit > MIPS processor, we are forever limited to a userspace of 2GB in size thanks > to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 > is 1GB in size and hence it could address another 1GB of RAM. So, is the 2gb virtual memory per process. In theory physical memory is limited by the size of the address bus with highmem; the practical limit for highmem should be in the range of 16-32gb RAM. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 6 00:50:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g168obA12581 for linux-mips-outgoing; Wed, 6 Feb 2002 00:50:37 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g168oVA12572 for ; Wed, 6 Feb 2002 00:50:31 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA03368; Wed, 6 Feb 2002 09:49:23 +0100 (MET) Date: Wed, 6 Feb 2002 09:49:24 +0100 (MET) From: Geert Uytterhoeven To: "Bradley D. LaRonde" cc: sjhill@cotw.com, linux-mips Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? In-Reply-To: <02a001c1ae90$43748d40$5601010a@prefect> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002, Bradley D. LaRonde wrote: > As already mentioned, a MIPS TLB entry typically can point with 36 bits > (that's 67TB of address space?) at physical memory. If you have more than At bit less: 64 GiB or approx. 69 GB :-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed Feb 6 03:17:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16BH2Z17251 for linux-mips-outgoing; Wed, 6 Feb 2002 03:17:02 -0800 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16BGuA17246 for ; Wed, 6 Feb 2002 03:16:57 -0800 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id GAA04302 for ; Wed, 6 Feb 2002 06:16:49 -0500 Date: Wed, 6 Feb 2002 06:16:49 -0500 (EST) From: X-Sender: nick@ns cc: linux-mips Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? 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 The fact that idiot marketoids in some moronic HD maker decided "GB" ment "billion bytes" is not a good excuse for useing the term to refer to anything that has never been polluted this way. It's not an excuse to use it to refer to things that have been polluted this way either, but that won't stop ppl. How bout you say GB is gigabits and claim ~549 of your mythical "GB"? Nick On Wed, 6 Feb 2002, Geert Uytterhoeven wrote: > On Tue, 5 Feb 2002, Bradley D. LaRonde wrote: > > As already mentioned, a MIPS TLB entry typically can point with 36 bits > > (that's 67TB of address space?) at physical memory. If you have more than > > At bit less: 64 GiB or approx. 69 GB :-) > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > From owner-linux-mips@oss.sgi.com Wed Feb 6 03:38:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16BcgD17625 for linux-mips-outgoing; Wed, 6 Feb 2002 03:38:42 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16BcbA17622 for ; Wed, 6 Feb 2002 03:38:37 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA11977; Wed, 6 Feb 2002 12:37:31 +0100 (MET) Date: Wed, 6 Feb 2002 12:37:31 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) In-Reply-To: <20020205135407.A8309@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 5 Feb 2002, H . J . Lu wrote: > 0xd724 <__pthread_alt_lock+212>: ll v1,0(s1) > 0xd728 <__pthread_alt_lock+216>: move a1,zero > 0xd72c <__pthread_alt_lock+220>: bne v1,s0,0xd744 <__pthread_alt_lock+244> > 0xd730 <__pthread_alt_lock+224>: nop > 0xd734 <__pthread_alt_lock+228>: move a1,v0 > 0xd738 <__pthread_alt_lock+232>: sc a1,0(s1) > 0xd73c <__pthread_alt_lock+236>: beqz a1,0xd724 <__pthread_alt_lock+212> > 0xd740 <__pthread_alt_lock+240>: nop > > There is an extra "nop" in the delay slot. I don't think gas is smart > enough to fill the delay slot. I will put back those ".set noredor". The code uses the same count of cycles either way. As you may see above, gas was smart enough to fill the "ll" load delay slot. Maybe it should prefer filling the branch delay slot instead due to smaller code... -- + 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 Feb 6 04:08:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16C8Cc18864 for linux-mips-outgoing; Wed, 6 Feb 2002 04:08:12 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16C85A18859 for ; Wed, 6 Feb 2002 04:08:06 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA20357; Wed, 6 Feb 2002 13:07:12 +0100 (MET) Date: Wed, 6 Feb 2002 13:07:13 +0100 (MET) From: Geert Uytterhoeven To: nick@snowman.net cc: linux-mips Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? 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 Wed, 6 Feb 2002 nick@snowman.net wrote: > The fact that idiot marketoids in some moronic HD maker decided "GB" ment > "billion bytes" is not a good excuse for useing the term to refer to > anything that has never been polluted this way. It's not an excuse to use > it to refer to things that have been polluted this way either, but that > won't stop ppl. How bout you say GB is gigabits and claim ~549 of your > mythical "GB"? Then I would say `Gb' (lower case b). > On Wed, 6 Feb 2002, Geert Uytterhoeven wrote: > > On Tue, 5 Feb 2002, Bradley D. LaRonde wrote: > > > As already mentioned, a MIPS TLB entry typically can point with 36 bits > > > (that's 67TB of address space?) at physical memory. If you have more than > > > > At bit less: 64 GiB or approx. 69 GB :-) But the main issue here was: tera vs. giga. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed Feb 6 05:17:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16DHri20298 for linux-mips-outgoing; Wed, 6 Feb 2002 05:17:53 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16DHmA20295; Wed, 6 Feb 2002 05:17:48 -0800 Received: from wli by holomorphy with local (Exim 3.33 #1 (Debian)) id 16YRx7-0002tw-00; Wed, 06 Feb 2002 05:17:33 -0800 Date: Wed, 6 Feb 2002 05:17:33 -0800 From: William Lee Irwin III To: Ralf Baechle Cc: "Steven J. Hill" , linux-mips@oss.sgi.com Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? Message-ID: <20020206131733.GF744@holomorphy.com> References: <3C600D4C.43CBA784@cotw.com> <20020206033346.A7298@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline In-Reply-To: <20020206033346.A7298@dea.linux-mips.net> User-Agent: Mutt/1.3.25i Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 10:50:20AM -0600, Steven J. Hill wrote: >> I am just trying to fill in some more MIPS knowledge here. With a 32-bit >> MIPS processor, we are forever limited to a userspace of 2GB in size thanks >> to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 >> is 1GB in size and hence it could address another 1GB of RAM. So, is the On Wed, Feb 06, 2002 at 03:33:46AM +0100, Ralf Baechle wrote: > 2gb virtual memory per process. In theory physical memory is limited by > the size of the address bus with highmem; the practical limit for highmem > should be in the range of 16-32gb RAM. I'm aware that some of those issues have to do with boot-time allocations proportional to memory size filling the direct-mapped portion of the kernel virtual address space. Do you have in mind others? I'm just generally curious. Thanks, Bill From owner-linux-mips@oss.sgi.com Wed Feb 6 06:07:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16E7EA21628 for linux-mips-outgoing; Wed, 6 Feb 2002 06:07:14 -0800 Received: from mail.laser5.co.jp (gw1.laser5.co.jp [202.221.8.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16E6xA21618 for ; Wed, 6 Feb 2002 06:07:00 -0800 Received: from l5ac227.l5.laser5.co.jp (unknown [192.168.128.227]) by mail.laser5.co.jp (Postfix) with ESMTP id F2720833A5 for ; Wed, 6 Feb 2002 23:06:58 +0900 (JST) Date: Wed, 06 Feb 2002 23:06:57 +0900 Message-ID: From: Kunihiko IMAI To: Linux-MIPS Subject: Re: One bug fixed, another found? In-Reply-To: References: User-Agent: Wanderlust/2.4.0 (Rio) WEMI/1.13.7 (Shimada) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-vine-linux) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I also got the Oops in same place. My environment is: o board: Pb1000 ( Au1000 eval. board ) o kernel: SGI version of 2.4.17 o root fs: nfs root o userland: RedHat 7.1 got from SGI ftp site. When rebuilding rpm package on the MIPS board, I also got error in same place. Today I compiled kernel with __wake_up_common not inline function, and got same result. And also made kgdb version. I found that the line p = curr->task; made the memory violation. When trap occurs, gdb says curr = 0xfffffffc So here is the place of memory violation. At Thu, 31 Jan 2002 18:09:29 -0800, Matthew Dharm wrote: > Unable to handle kernel paging request at virtual address fffffffc, > epc == 8010b > 1ec, ra == 8010b19c > $0 : 00000000 b0045400 00000000 00000000 00000017 802d51cc 92bdc000 > 93e7d120 > $8 : 92bdc000 b0045401 00000000 00000000 00000000 00000000 00000088 > 00000000 > $16: 00000000 b0045400 00000001 b0045401 802de998 802dad88 00000001 > 92ce1160 > $24: 00000000 2acce4e0 92bdc000 92bddd68 92bddd68 > 8010b19c > epc : 8010b1ec Not tainted > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 > Status: b0045402 > Cause : 80008008 > Process bladeenc (pid: 660, stackpage=92bdc000) > Stack: 92bddd68 92bddd68 92bddd68 92bddd68 802df378 00000001 00000000 > 93ff8bf0 > 802df1fc 802df36c 000001d2 92bc4060 8012c588 8012c528 00001000 > 92bc4060 > 00000000 92bc4060 81018fc0 92ce1160 00000005 92bc4120 00001a55 > 93ff8bf0 > 92ce1160 0000001f 00001000 8012c180 81018fc0 92bc4120 00001a54 > 93ff8bec > 80122aa0 80122af8 93f036c0 00000000 80170988 80170980 00000005 > 00001a50 > 92ce1160 ... > Call Trace: [<8012c588>] [<8012c528>] [<8012c180>] [<80122aa0>] > [<80122af8>] [<8 > 0170988>] > [<80170980>] [<801233ec>] [<8012372c>] [<8012377c>] [<80126198>] > [<80123d80>] > [<80123c78>] [<801680dc>] [<8010703c>] [<8013290c>] [<80113158>] > [<80106508>] > [<80106508>] > Code: 12400004 00000000 8e100000 <5614ffcc> 8e05fffc 40016000 > 32730001 3421 > 0001 38210001 > > >>RA; 8010b19c <__wake_up+ec/198> > >>PC; 8010b1ec <__wake_up+13c/198> <===== > Trace; 8012c588 <__alloc_pages+d0/21c> > Trace; 8012c528 <__alloc_pages+70/21c> > Trace; 8012c180 <_alloc_pages+20/2c> > Trace; 80122aa0 > Trace; 80122af8 > Trace; 80170988 > Trace; 80170980 > Trace; 801233ec > Trace; 8012372c > Trace; 8012377c > Trace; 80126198 > Trace; 80123d80 > Trace; 80123c78 > Trace; 801680dc > Trace; 8010703c > Trace; 8013290c > Trace; 80113158 > Trace; 80106508 > Trace; 80106508 > Code; 8010b1e0 <__wake_up+130/198> > 00000000 <_PC>: > Code; 8010b1e0 <__wake_up+130/198> > 0: 12400004 beqz s2,14 <_PC+0x14> 8010b1f4 > <__wake_up+144/198> > Code; 8010b1e4 <__wake_up+134/198> > 4: 00000000 nop > Code; 8010b1e8 <__wake_up+138/198> > 8: 8e100000 lw s0,0(s0) > Code; 8010b1ec <__wake_up+13c/198> <===== > c: 5614ffcc 0x5614ffcc <===== This is MIPS2 code. If you use objdump to disassemble, add -m mips:4600 option to get correct mnemonic. And the cause register says exception occurred in delay slot, so: > Code; 8010b1f0 <__wake_up+140/198> > 10: 8e05fffc lw a1,-4(s0) The memory violation occurs here. Registers dump says s0 = 00000000, memory access to 0xfffffffc occurs here. > Code; 8010b1f4 <__wake_up+144/198> > 14: 40016000 mfc0 at,$12 > Code; 8010b1f8 <__wake_up+148/198> > 18: 32730001 andi s3,s3,0x1 > Code; 8010b1fc <__wake_up+14c/198> > 1c: 34210001 ori at,at,0x1 > Code; 8010b200 <__wake_up+150/198> > 20: 38210001 xori at,at,0x1 Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Wed Feb 6 06:13:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16EDmI21881 for linux-mips-outgoing; Wed, 6 Feb 2002 06:13:48 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16EDdA21876 for ; Wed, 6 Feb 2002 06:13:41 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 055CA590A9; Wed, 6 Feb 2002 09:05:36 -0500 (EST) Message-ID: <002f01c1af18$a8685410$5601010a@prefect> From: "Bradley D. LaRonde" To: "Geert Uytterhoeven" Cc: , "linux-mips" References: Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? Date: Wed, 6 Feb 2002 09:14:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Geert Uytterhoeven" To: "Bradley D. LaRonde" Cc: ; "linux-mips" Sent: Wednesday, February 06, 2002 3:49 AM Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? > On Tue, 5 Feb 2002, Bradley D. LaRonde wrote: > > As already mentioned, a MIPS TLB entry typically can point with 36 bits > > (that's 67TB of address space?) at physical memory. If you have more than > > At bit less: 64 GiB or approx. 69 GB :-) Oops, yeah. 67TB seemed a little high. :-P Regards, Brad From owner-linux-mips@oss.sgi.com Wed Feb 6 07:22:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16FMht24518 for linux-mips-outgoing; Wed, 6 Feb 2002 07:22:43 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16FMeA24515 for ; Wed, 6 Feb 2002 07:22:40 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16YTu6-0001LD-00; Wed, 06 Feb 2002 09:22:34 -0600 Message-ID: <3C614A30.928E6BC5@cotw.com> Date: Wed, 06 Feb 2002 09:22:24 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Comments on new Linux MIPS FAQ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk First off, this is not a replacement for the awesome FAQ at SGI maintained by Ralf. The FAQ I wrote addresses 32-bit and 64-bit Linux kernel/userspace questions (well, starts to). I would greatly appreciate comments from everyone on this. You can read it here: http://www.cotw.com/mips/mips64.txt Please send me comments and corrections and make sure you copy the mailing list(s). After the corrections settle down a bit, we can come up with a name and get it hosted on SGI's site or the http://www.linuxmips.net/ site or even my site, I don't care. The inspiration for this came from Matthew Dharm's questions as well as my management asking about 32-bit versus 64-bit Linux kernels and wanting to know current toolchain status. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Wed Feb 6 09:04:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16H4Wu26538 for linux-mips-outgoing; Wed, 6 Feb 2002 09:04:32 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16H4QA26526 for ; Wed, 6 Feb 2002 09:04:26 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 90AC385B; Wed, 6 Feb 2002 18:04:06 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 335DC3FB4; Wed, 6 Feb 2002 18:04:16 +0100 (CET) Date: Wed, 6 Feb 2002 18:04:16 +0100 From: Florian Lohoff To: "Steven J. Hill" Cc: linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: Comments on new Linux MIPS FAQ... Message-ID: <20020206170416.GB2589@paradigm.rfc822.org> References: <3C614A30.928E6BC5@cotw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: <3C614A30.928E6BC5@cotw.com> User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 06, 2002 at 09:22:24AM -0600, Steven J. Hill wrote: > First off, this is not a replacement for the awesome FAQ at > SGI maintained by Ralf. The FAQ I wrote addresses 32-bit and > 64-bit Linux kernel/userspace questions (well, starts to). I > would greatly appreciate comments from everyone on this. You > can read it here: >=20 > http://www.cotw.com/mips/mips64.txt >=20 > Please send me comments and corrections and make sure you copy > the mailing list(s). After the corrections settle down a bit, > we can come up with a name and get it hosted on SGI's site or > the http://www.linuxmips.net/ site or even my site, I don't care. >=20 > The inspiration for this came from Matthew Dharm's questions as > well as my management asking about 32-bit versus 64-bit Linux > kernels and wanting to know current toolchain status. Thanks. My impression is that the number of FAQs grows rapidly - I would like to see them all be integrated into the one and only Linux/Mips FAQ as it makes pointing people to informations a lot easier. I dont think this distributed information storage of Linux/Mips helps keeping people together. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --8P1HSweYDcXXzwPJ 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 iD8DBQE8YWIQUaz2rXW+gJcRAn5WAJwLgS97Ny04xlZykjTN3Z/Nhf8YqACfW1un xfwwz1nplRHFSzfIqVRGfRs= =Mq9r -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From owner-linux-mips@oss.sgi.com Wed Feb 6 11:17:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16JH3Z29088 for linux-mips-outgoing; Wed, 6 Feb 2002 11:17:03 -0800 Received: from dea.linux-mips.net (a1as20-p202.stg.tli.de [195.252.194.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16JGwA29084 for ; Wed, 6 Feb 2002 11:16:59 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g16H82l17705; Wed, 6 Feb 2002 18:08:02 +0100 Date: Wed, 6 Feb 2002 18:08:02 +0100 From: Ralf Baechle To: Florian Lohoff Cc: "Steven J. Hill" , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: Comments on new Linux MIPS FAQ... Message-ID: <20020206180802.A17344@dea.linux-mips.net> References: <3C614A30.928E6BC5@cotw.com> <20020206170416.GB2589@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: <20020206170416.GB2589@paradigm.rfc822.org>; from flo@rfc822.org on Wed, Feb 06, 2002 at 06:04:16PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Feb 06, 2002 at 06:04:16PM +0100, Florian Lohoff wrote: > > Please send me comments and corrections and make sure you copy > > the mailing list(s). After the corrections settle down a bit, > > we can come up with a name and get it hosted on SGI's site or > > the http://www.linuxmips.net/ site or even my site, I don't care. > > > > The inspiration for this came from Matthew Dharm's questions as > > well as my management asking about 32-bit versus 64-bit Linux > > kernels and wanting to know current toolchain status. Thanks. > > My impression is that the number of FAQs grows rapidly - I would > like to see them all be integrated into the one and only Linux/Mips > FAQ as it makes pointing people to informations a lot easier. > > I dont think this distributed information storage of Linux/Mips helps > keeping people together. I agree on that one. So for anything that seems to belong into the MIPS FAQ I'll take a patch to the SGML code. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 6 11:17:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16JHwO29161 for linux-mips-outgoing; Wed, 6 Feb 2002 11:17:58 -0800 Received: from dea.linux-mips.net (a1as20-p202.stg.tli.de [195.252.194.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16JHmA29157 for ; Wed, 6 Feb 2002 11:17:49 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g16AWxB15749; Wed, 6 Feb 2002 11:32:59 +0100 Date: Wed, 6 Feb 2002 11:32:59 +0100 From: Ralf Baechle To: "H . J . Lu" Cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: PATCH: Fix ll/sc for mips (take 3) Message-ID: <20020206113259.A15431@dea.linux-mips.net> References: <20020202120354.A1522@lucon.org> <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020205135407.A8309@lucon.org>; from hjl@lucon.org on Tue, Feb 05, 2002 at 01:54:07PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 01:54:07PM -0800, H . J . Lu wrote: > __asm__ __volatile__ > ("/* Inline compare & swap */\n" > "1:\n\t" > "ll %1,%5\n\t" > "move %0,$0\n\t" > "bne %1,%3,2f\n\t" > "move %0,%4\n\t" > "sc %0,%2\n\t" > "beqz %0,1b\n\t" > "2:\n\t" > "/* End compare & swap */" > : "=&r" (ret), "=&r" (temp), "=m" (*p) > : "r" (oldval), "r" (newval), "m" (*p) > : "memory"); > > The assembler will do > > 0xd724 <__pthread_alt_lock+212>: ll v1,0(s1) > 0xd728 <__pthread_alt_lock+216>: move a1,zero > 0xd72c <__pthread_alt_lock+220>: bne v1,s0,0xd744 <__pthread_alt_lock+244> > 0xd730 <__pthread_alt_lock+224>: nop > 0xd734 <__pthread_alt_lock+228>: move a1,v0 > 0xd738 <__pthread_alt_lock+232>: sc a1,0(s1) > 0xd73c <__pthread_alt_lock+236>: beqz a1,0xd724 <__pthread_alt_lock+212> > 0xd740 <__pthread_alt_lock+240>: nop > > There is an extra "nop" in the delay slot. I don't think gas is smart > enough to fill the delay slot. I will put back those ".set noredor". The solution is to move the move instruction in front of the branch instruction. The assembler will then move it into the delay slot: __asm__ __volatile__ ("/* Inline compare & swap */\n" "1:\n\t" "ll %1,%5\n\t" "move %0,$0\n\t" "move %0,%4\n\t" "bne %1,%3,2f\n\t" "sc %0,%2\n\t" "beqz %0,1b\n\t" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=m" (*p) : "r" (oldval), "r" (newval), "m" (*p) : "memory"); Also this function looks like a good candidate for inlining (Is it actually inlined? Haven't checked ...) where depending on it's use the address of *p is loaded twice from the GOT, so changing the code to: __asm__ __volatile__ ("/* Inline compare & swap */\n" "1:\n\t" "ll %1,(%5)\n\t" "move %0,$0\n\t" "move %0,%4\n\t" "bne %1,%3,2f\n\t" "sc %0,(%2)\n\t" "beqz %0,1b\n\t" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=&r" (temp), "=r" (p) : "r" (oldval), "r" (newval), "r" (p) : "memory"); will avoid having to pay that PIC bloat twice and get you around the gas inefficiency of putting in too many nops into PIC code. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 6 11:18:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16JIgS29229 for linux-mips-outgoing; Wed, 6 Feb 2002 11:18:42 -0800 Received: from dea.linux-mips.net (a1as20-p202.stg.tli.de [195.252.194.202]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16JIcA29226 for ; Wed, 6 Feb 2002 11:18:38 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g165Tjm13904; Wed, 6 Feb 2002 06:29:45 +0100 Date: Wed, 6 Feb 2002 06:29:45 +0100 From: Ralf Baechle To: "Steven J. Hill" Cc: Hartvig Ekner , linux-mips@oss.sgi.com Subject: Re: What is the maximum physical RAM for a 32bit MIPS core? Message-ID: <20020206062945.A13634@dea.linux-mips.net> References: <200202051747.SAA21696@copsun18.mips.com> <3C6044A7.13FEB2E2@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6044A7.13FEB2E2@cotw.com>; from sjhill@cotw.com on Tue, Feb 05, 2002 at 02:46:31PM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Feb 05, 2002 at 02:46:31PM -0600, Steven J. Hill wrote: > > One note: Many MIPS32 implementations choose not to implement all 36 PA > > bits, but limit themselves to 32 bits. This saves a few bits in the TLB > > and a few address lines. > > > So, if someone did want 36 PA bits on Linux, the TLB exception handlers > and a little of the page table construction/management code would have to > change. The userspace contraints and such would still remain. Cool. Basically the whole code is already in place except a few bugs fixes that still need to go in. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 6 12:45:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16KjmK31182 for linux-mips-outgoing; Wed, 6 Feb 2002 12:45:48 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16KjfA31179; Wed, 6 Feb 2002 12:45:41 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id F18F7125C8; Wed, 6 Feb 2002 12:45:38 -0800 (PST) Date: Wed, 6 Feb 2002 12:45:38 -0800 From: "H . J . Lu" To: Ralf Baechle Cc: Dominic Sweetman , GNU C Library , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Why does -g turn off filling the delat slot? Message-ID: <20020206124538.A28632@lucon.org> References: <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020206113259.A15431@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Feb 06, 2002 at 11:32:59AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Feb 06, 2002 at 11:32:59AM +0100, Ralf Baechle wrote: > > > > There is an extra "nop" in the delay slot. I don't think gas is smart > > enough to fill the delay slot. I will put back those ".set noredor". > > The solution is to move the move instruction in front of the branch > instruction. The assembler will then move it into the delay slot: > I found out why it didn't work for me. The problem is -g turns off filling the delay slot. The mips as has case 'g': if (arg == NULL) mips_debug = 2; else mips_debug = atoi (arg); /* When the MIPS assembler sees -g or -g2, it does not do optimizations which limit full symbolic debugging. We take that to be equivalent to -O0. */ if (mips_debug == 2) mips_optimize = 1; break; It doesn't matter of you pass -O to as or not. I'd like to override it if -O is seen. H.J. From owner-linux-mips@oss.sgi.com Wed Feb 6 12:46:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16KkdC31251 for linux-mips-outgoing; Wed, 6 Feb 2002 12:46:39 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16KkcA31248 for ; Wed, 6 Feb 2002 12:46:38 -0800 Received: from whrrusek (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g16KkbR02642 for ; Wed, 6 Feb 2002 12:46:37 -0800 Message-ID: <001f01c1af4f$5f3af0e0$261510ac@AD.WEIDERPUB.COM> From: "Robert Rusek" To: Subject: ftp.mips.com RedHat 7.1 Build Date: Wed, 6 Feb 2002 12:46:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone sucessfully got the ftp.mips.com Redhat 7.1 build working on a SGI Indy/Challenge S ? Thanks, Rob. From owner-linux-mips@oss.sgi.com Wed Feb 6 12:55:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16KtEh31476 for linux-mips-outgoing; Wed, 6 Feb 2002 12:55:14 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16KsvA31442 for ; Wed, 6 Feb 2002 12:54:57 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g16KsqR08536; Wed, 6 Feb 2002 12:54:52 -0800 From: "Matthew Dharm" To: "Kunihiko IMAI" , "Linux-MIPS" Subject: RE: One bug fixed, another found? Date: Wed, 6 Feb 2002 12:54:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk It turns out that this is a toolchain bug. Get a newer toolchain -- I'm using the one from H.J., which is on oss.sgi.com in the redhat 7.1 mini-port. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Kunihiko IMAI > Sent: Wednesday, February 06, 2002 6:07 AM > To: Linux-MIPS > Subject: Re: One bug fixed, another found? > > > Hi, > > I also got the Oops in same place. > > My environment is: > > o board: Pb1000 ( Au1000 eval. board ) > o kernel: SGI version of 2.4.17 > o root fs: nfs root > o userland: RedHat 7.1 got from SGI ftp site. > > When rebuilding rpm package on the MIPS board, I also got error in > same place. > > Today I compiled kernel with __wake_up_common not inline > function, and > got same result. And also made kgdb version. I found that the line > > p = curr->task; > > made the memory violation. When trap occurs, gdb says > > curr = 0xfffffffc > > So here is the place of memory violation. > > At Thu, 31 Jan 2002 18:09:29 -0800, > Matthew Dharm wrote: > > > Unable to handle kernel paging request at virtual address > fffffffc, > > epc == 8010b > > 1ec, ra == 8010b19c > > $0 : 00000000 b0045400 00000000 00000000 00000017 > 802d51cc 92bdc000 > > 93e7d120 > > $8 : 92bdc000 b0045401 00000000 00000000 00000000 > 00000000 00000088 > > 00000000 > > $16: 00000000 b0045400 00000001 b0045401 802de998 > 802dad88 00000001 > > 92ce1160 > > $24: 00000000 2acce4e0 92bdc000 > 92bddd68 92bddd68 > > 8010b19c > > epc : 8010b1ec Not tainted > > Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000 > > Status: b0045402 > > Cause : 80008008 > > Process bladeenc (pid: 660, stackpage=92bdc000) > > Stack: 92bddd68 92bddd68 92bddd68 92bddd68 802df378 > 00000001 00000000 > > 93ff8bf0 > > 802df1fc 802df36c 000001d2 92bc4060 8012c588 > 8012c528 00001000 > > 92bc4060 > > 00000000 92bc4060 81018fc0 92ce1160 00000005 > 92bc4120 00001a55 > > 93ff8bf0 > > 92ce1160 0000001f 00001000 8012c180 81018fc0 > 92bc4120 00001a54 > > 93ff8bec > > 80122aa0 80122af8 93f036c0 00000000 80170988 > 80170980 00000005 > > 00001a50 > > 92ce1160 ... > > Call Trace: [<8012c588>] [<8012c528>] [<8012c180>] [<80122aa0>] > > [<80122af8>] [<8 > > 0170988>] > > [<80170980>] [<801233ec>] [<8012372c>] [<8012377c>] [<80126198>] > > [<80123d80>] > > [<80123c78>] [<801680dc>] [<8010703c>] [<8013290c>] [<80113158>] > > [<80106508>] > > [<80106508>] > > Code: 12400004 00000000 8e100000 <5614ffcc> 8e05fffc 40016000 > > 32730001 3421 > > 0001 38210001 > > > > >>RA; 8010b19c <__wake_up+ec/198> > > >>PC; 8010b1ec <__wake_up+13c/198> <===== > > Trace; 8012c588 <__alloc_pages+d0/21c> > > Trace; 8012c528 <__alloc_pages+70/21c> > > Trace; 8012c180 <_alloc_pages+20/2c> > > Trace; 80122aa0 > > Trace; 80122af8 > > Trace; 80170988 > > Trace; 80170980 > > Trace; 801233ec > > Trace; 8012372c > > Trace; 8012377c > > Trace; 80126198 > > Trace; 80123d80 > > Trace; 80123c78 > > Trace; 801680dc > > Trace; 8010703c > > Trace; 8013290c > > Trace; 80113158 > > Trace; 80106508 > > Trace; 80106508 > > Code; 8010b1e0 <__wake_up+130/198> > > 00000000 <_PC>: > > Code; 8010b1e0 <__wake_up+130/198> > > 0: 12400004 beqz s2,14 <_PC+0x14> 8010b1f4 > > <__wake_up+144/198> > > Code; 8010b1e4 <__wake_up+134/198> > > 4: 00000000 nop > > Code; 8010b1e8 <__wake_up+138/198> > > 8: 8e100000 lw s0,0(s0) > > Code; 8010b1ec <__wake_up+13c/198> <===== > > c: 5614ffcc 0x5614ffcc <===== > > This is MIPS2 code. If you use objdump to disassemble, add > -m mips:4600 option to get correct mnemonic. > > And the cause register says exception occurred in delay slot, so: > > > Code; 8010b1f0 <__wake_up+140/198> > > 10: 8e05fffc lw a1,-4(s0) > > The memory violation occurs here. > > Registers dump says s0 = 00000000, memory access to > 0xfffffffc occurs > here. > > > Code; 8010b1f4 <__wake_up+144/198> > > 14: 40016000 mfc0 at,$12 > > Code; 8010b1f8 <__wake_up+148/198> > > 18: 32730001 andi s3,s3,0x1 > > Code; 8010b1fc <__wake_up+14c/198> > > 1c: 34210001 ori at,at,0x1 > > Code; 8010b200 <__wake_up+150/198> > > 20: 38210001 xori at,at,0x1 > > Thanks. > _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. > .____ _ . ... _ > > > Kunihiko IMAI > From owner-linux-mips@oss.sgi.com Wed Feb 6 13:00:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16L0lP31682 for linux-mips-outgoing; Wed, 6 Feb 2002 13:00:47 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16L0cA31676 for ; Wed, 6 Feb 2002 13:00:38 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7654F125C8; Wed, 6 Feb 2002 13:00:37 -0800 (PST) Date: Wed, 6 Feb 2002 13:00:37 -0800 From: "H . J . Lu" To: echristo@redhat.com Cc: linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: PATCH: Modify the mips gas behavior for -g -O Message-ID: <20020206130037.A29208@lucon.org> References: <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020206124538.A28632@lucon.org>; from hjl@lucon.org on Wed, Feb 06, 2002 at 12:45:38PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Feb 06, 2002 at 12:45:38PM -0800, H . J . Lu wrote: > On Wed, Feb 06, 2002 at 11:32:59AM +0100, Ralf Baechle wrote: > > > > > > There is an extra "nop" in the delay slot. I don't think gas is smart > > > enough to fill the delay slot. I will put back those ".set noredor". > > > > The solution is to move the move instruction in front of the branch > > instruction. The assembler will then move it into the delay slot: > > > > I found out why it didn't work for me. The problem is -g turns off > filling the delay slot. The mips as has > > case 'g': > if (arg == NULL) > mips_debug = 2; > else > mips_debug = atoi (arg); > /* When the MIPS assembler sees -g or -g2, it does not do > optimizations which limit full symbolic debugging. We take > that to be equivalent to -O0. */ > if (mips_debug == 2) > mips_optimize = 1; > break; > > It doesn't matter of you pass -O to as or not. I'd like to override it > if -O is seen. > > Here is a patch which does what I want. Any comments? Eric, can you approve http://sources.redhat.com/ml/binutils/2002-02/msg00028.html Thanks. H.J. ---- 2002-02-06 H.J. Lu (hjl@gnu.org) * config/tc-mips.c (mips_optimize): Initialize to -2. (md_begin): Set mips_optimize to -mips_optimize if it is less than 0. (md_parse_option): Set mips_optimize to 1 for -g only if it is less than 0. --- gas/config/tc-mips.c.opt Sun Feb 3 23:47:26 2002 +++ gas/config/tc-mips.c Wed Feb 6 12:55:39 2002 @@ -431,7 +431,7 @@ static int mips_frame_reg_valid = 0; unneeded NOPs and swap branch instructions when possible. A value of 1 means to not swap branches. A value of 0 means to always insert NOPs. */ -static int mips_optimize = 2; +static int mips_optimize = -2; /* Debugging level. -g sets this to 2. -gN sets this to N. -g0 is equivalent to seeing no -g option at all. */ @@ -1020,6 +1020,9 @@ md_begin () int target_cpu_had_mips16 = 0; const struct mips_cpu_info *ci; + if (mips_optimize < 0) + mips_optimize = -mips_optimize; + /* GP relative stuff not working for PE */ if (strncmp (TARGET_OS, "pe", 2) == 0 && g_switch_value != 0) @@ -9794,7 +9797,7 @@ md_parse_option (c, arg) /* When the MIPS assembler sees -g or -g2, it does not do optimizations which limit full symbolic debugging. We take that to be equivalent to -O0. */ - if (mips_debug == 2) + if (mips_debug == 2 && mips_optimize < 0) mips_optimize = 1; break; From owner-linux-mips@oss.sgi.com Wed Feb 6 13:17:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16LHdS32171 for linux-mips-outgoing; Wed, 6 Feb 2002 13:17:39 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16LHZA32163 for ; Wed, 6 Feb 2002 13:17:35 -0800 Received: from localhost.localdomain (taarna.sfbay.redhat.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA18750; Wed, 6 Feb 2002 13:17:26 -0800 (PST) Subject: Re: PATCH: Modify the mips gas behavior for -g -O From: Eric Christopher To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, binutils@sources.redhat.com In-Reply-To: <20020206130037.A29208@lucon.org> References: <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> <20020206130037.A29208@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Feb 2002 13:16:47 -0800 Message-Id: <1013030208.19162.6.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Here is a patch which does what I want. Any comments? > Does anyone care if we have MIPS compatibility? I remember seeing this a few years ago and wondering why we were doing it this way. I remember at one time debuggers had problems with optimized code, but gdb has come a long way since then. Is there any reason to have this code in there at all now, i.e. should we just go off of optimization level and not debug level at all? > Eric, can you approve > > http://sources.redhat.com/ml/binutils/2002-02/msg00028.html > If this is the one for header file information, then go ahead. We need to come up with a better way of doing this though. -eric -- I will not use abbrev. From owner-linux-mips@oss.sgi.com Wed Feb 6 13:31:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16LVHZ32567 for linux-mips-outgoing; Wed, 6 Feb 2002 13:31:17 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16LVEA32554 for ; Wed, 6 Feb 2002 13:31:14 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id DEB56125C8; Wed, 6 Feb 2002 13:31:13 -0800 (PST) Date: Wed, 6 Feb 2002 13:31:13 -0800 From: "H . J . Lu" To: GNU C Library Cc: linux-mips@oss.sgi.com Subject: PATCH: Fix for Linux/mips Message-ID: <20020206133113.A29718@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 We have been using the wrong for Linux/mips. Here is a patch. H.J. ---- 2002-02-06 H.J. Lu * sysdeps/mips/elf/ldsodefs.h: Make sure the right is included. --- sysdeps/mips/elf/ldsodefs.h.mips Sat Jul 7 16:46:05 2001 +++ sysdeps/mips/elf/ldsodefs.h Wed Feb 6 13:25:17 2002 @@ -22,4 +22,4 @@ #define DL_RO_DYN_SECTION 1 -#include +#include_next From owner-linux-mips@oss.sgi.com Wed Feb 6 13:40:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16LeT000359 for linux-mips-outgoing; Wed, 6 Feb 2002 13:40:29 -0800 Received: from foghorn.airs.com (IDENT:qmailr@foghorn.airs.com [63.201.54.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16LeQA00356 for ; Wed, 6 Feb 2002 13:40:26 -0800 Received: (qmail 7673 invoked by uid 10); 6 Feb 2002 21:40:25 -0000 Received: (qmail 29608 invoked by uid 269); 6 Feb 2002 21:40:20 -0000 Mail-Followup-To: hjl@lucon.org, linux-mips@oss.sgi.com, binutils@sources.redhat.com, echristo@redhat.com To: Eric Christopher Cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sources.redhat.com Subject: Re: PATCH: Modify the mips gas behavior for -g -O References: <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> <20020206130037.A29208@lucon.org> <1013030208.19162.6.camel@ghostwheel.cygnus.com> From: Ian Lance Taylor Date: 06 Feb 2002 13:40:20 -0800 In-Reply-To: <1013030208.19162.6.camel@ghostwheel.cygnus.com> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Eric Christopher writes: > > Here is a patch which does what I want. Any comments? > > > > Does anyone care if we have MIPS compatibility? I remember seeing this a > few years ago and wondering why we were doing it this way. I remember at > one time debuggers had problems with optimized code, but gdb has come a > long way since then. Is there any reason to have this code in there at > all now, i.e. should we just go off of optimization level and not debug > level at all? In general the reason for this sort of compatibility is for easier gcc support. It's normally more convenient if the GNU assembler and the native assembler present the same interface, so that you don't have to use --with-gnu-assembler to get the right result when configuring gcc. It's far more common to invoke the assembler via the compiler than to invoke it directly, so making it work correctly when invoked via the compiler is normally best. H.J., my question on this patch would be: why is -g being passed to the assembler? Ian From owner-linux-mips@oss.sgi.com Wed Feb 6 13:47:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16LlXC00558 for linux-mips-outgoing; Wed, 6 Feb 2002 13:47:33 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16LlUA00555 for ; Wed, 6 Feb 2002 13:47:31 -0800 Received: from localhost.localdomain (taarna.sfbay.redhat.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA22008; Wed, 6 Feb 2002 13:47:23 -0800 (PST) Subject: Re: PATCH: Modify the mips gas behavior for -g -O From: Eric Christopher To: Ian Lance Taylor Cc: "H . J . Lu" , linux-mips@oss.sgi.com, binutils@sources.redhat.com In-Reply-To: References: <15454.22661.855423.532827@gladsmuir.algor.co.uk> <20020204083115.C13384@lucon.org> <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> <20020206130037.A29208@lucon.org> <1013030208.19162.6.camel@ghostwheel.cygnus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Feb 2002 13:46:45 -0800 Message-Id: <1013032006.19159.13.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > In general the reason for this sort of compatibility is for easier gcc > support. It's normally more convenient if the GNU assembler and the > native assembler present the same interface, so that you don't have to > use --with-gnu-assembler to get the right result when configuring gcc. > Ok. That's fair enough. I was hoping you'd pipe up here. :) -eric -- I will not use abbrev. From owner-linux-mips@oss.sgi.com Wed Feb 6 14:00:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16M0MV00886 for linux-mips-outgoing; Wed, 6 Feb 2002 14:00:22 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16M0IA00883 for ; Wed, 6 Feb 2002 14:00:18 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 06A4C125C8; Wed, 6 Feb 2002 14:00:16 -0800 (PST) Date: Wed, 6 Feb 2002 14:00:16 -0800 From: "H . J . Lu" To: Ian Lance Taylor Cc: Eric Christopher , linux-mips@oss.sgi.com, binutils@sources.redhat.com, gcc-patches@gcc.gnu.org Subject: PATCH: Define SUBTARGET_ASM_DEBUGGING_SPEC for Linux/mips Message-ID: <20020206140016.A30178@lucon.org> References: <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> <20020206130037.A29208@lucon.org> <1013030208.19162.6.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ian@airs.com on Wed, Feb 06, 2002 at 01:40:20PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Feb 06, 2002 at 01:40:20PM -0800, Ian Lance Taylor wrote: > > H.J., my question on this patch would be: why is -g being passed to > the assembler? > Here is a patch similar to Irix 6. H.J. ---- 2002-02-06 H.J. Lu * config/mips/linux.h (SUBTARGET_ASM_DEBUGGING_SPEC): Defined. --- gcc/config/mips/linux.h.gas Thu Nov 15 12:21:17 2001 +++ gcc/config/mips/linux.h Wed Feb 6 13:57:47 2002 @@ -170,6 +170,9 @@ Boston, MA 02111-1307, USA. */ %{!fno-PIC:%{!fno-pic:-KPIC}} \ %{fno-PIC:-non_shared} %{fno-pic:-non_shared}" +#undef SUBTARGET_ASM_DEBUGGING_SPEC +#define SUBTARGET_ASM_DEBUGGING_SPEC "-g0" + /* We don't need those nonsenses. */ #undef INVOKE__main #undef CTOR_LIST_BEGIN From owner-linux-mips@oss.sgi.com Wed Feb 6 14:48:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g16Mmts01883 for linux-mips-outgoing; Wed, 6 Feb 2002 14:48:55 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g16MmoA01879 for ; Wed, 6 Feb 2002 14:48:50 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 8F3571EC9F; Wed, 6 Feb 2002 23:48:44 +0100 (MET) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 16Yarr-0001Wy-00; Wed, 06 Feb 2002 23:48:43 +0100 Mail-Copies-To: never To: "H . J . Lu" Cc: GNU C Library , linux-mips@oss.sgi.com Subject: Re: PATCH: Fix for Linux/mips References: <20020206133113.A29718@lucon.org> From: Andreas Jaeger Date: Wed, 06 Feb 2002 23:48:42 +0100 In-Reply-To: <20020206133113.A29718@lucon.org> ("H . J . Lu"'s message of "Wed, 6 Feb 2002 13:31:13 -0800") Message-ID: Lines: 33 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks, I've committed this, Andreas "H . J . Lu" writes: > We have been using the wrong for Linux/mips. Here is a > patch. > > > H.J. > ---- > 2002-02-06 H.J. Lu > > * sysdeps/mips/elf/ldsodefs.h: Make sure the right > is included. > > --- sysdeps/mips/elf/ldsodefs.h.mips Sat Jul 7 16:46:05 2001 > +++ sysdeps/mips/elf/ldsodefs.h Wed Feb 6 13:25:17 2002 > @@ -22,4 +22,4 @@ > > #define DL_RO_DYN_SECTION 1 > > -#include > +#include_next > -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Wed Feb 6 17:22:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g171MSK05135 for linux-mips-outgoing; Wed, 6 Feb 2002 17:22:28 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g171MAA05115 for ; Wed, 6 Feb 2002 17:22:10 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g171LtR10473; Wed, 6 Feb 2002 17:21:56 -0800 From: "Matthew Dharm" To: "Ralf Baechle" Cc: "Linux-MIPS" Subject: PATCH: Momentum Ocelot (CP7000) fixes Date: Wed, 6 Feb 2002 17:21:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C1AF32.C66555C0" 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.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1AF32.C66555C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ralf -- Attached to this message is a patch to make the Momentum Computer Ocelot (CP7000) SBC port of Linux work. I made this patch against a recent (2 days ago) CVS snapshot. Please apply it to the CVS repository. It turns out that the existing code only worked for boards with 512MiB of SDRAM. This patch makes all memory configurations work. While discontiguous memory configurations seemed to work, there was some "unusual" behavior. This patch uses a contiguous memory approach, which seems much more stable. BTW, did you ever wind up in the same place as the board we sent you? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_0016_01C1AF32.C66555C0 Content-Type: application/octet-stream; name="patch20020204" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch20020204" ? a.out=0A= ? arch/mips/boot/elf2ecoff=0A= ? arch/mips/boot/vmlinux.ecoff=0A= ? arch/mips/boot/addinitrd=0A= Index: arch/mips/gt64120/momenco_ocelot/setup.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/setup.c,v=0A= retrieving revision 1.5=0A= diff -u -r1.5 setup.c=0A= --- arch/mips/gt64120/momenco_ocelot/setup.c 2001/11/25 09:25:53 1.5=0A= +++ arch/mips/gt64120/momenco_ocelot/setup.c 2002/02/05 02:24:48=0A= @@ -2,11 +2,12 @@=0A= * setup.c=0A= *=0A= * BRIEF MODULE DESCRIPTION=0A= - * Galileo Evaluation Boards - board dependent boot routines=0A= + * Momentum Computer Ocelot (CP7000) - board dependent boot routines=0A= *=0A= * Copyright (C) 1996, 1997, 2001 Ralf Baechle=0A= * Copyright (C) 2000 RidgeRun, Inc.=0A= * Copyright (C) 2001 Red Hat, Inc.=0A= + * Copyright (C) 2002 Momentum Computer=0A= *=0A= * Author: RidgeRun, Inc.=0A= * glonnon@ridgerun.com, skranz@ridgerun.com, stevej@ridgerun.com=0A= @@ -116,8 +117,7 @@=0A= =0A= /* Also a temporary entry to let us talk to the Ocelot PLD and NVRAM=0A= in the CS[012] region. We can't use ioremap() yet. The NVRAM=0A= - appears to be one of the variants of ST M48T35 - see =0A= - = http://www.st.com/stonline/bin/sftab.exe?table=3D172&filter0=3DM48T35=0A= + is a ST M48T37Y, which includes NVRAM, RTC, and Watchdog functions.=0A= =0A= Ocelot PLD (CS0) 0x2c000000 0xe0020000=0A= NVRAM 0x2c800000 0xe0030000=0A= @@ -155,6 +155,7 @@=0A= GT_WRITE(GT_PCI1M0LD_OFS, 0x32000000 >> 21);=0A= GT_WRITE(GT_PCI1M1LD_OFS, 0x34000000 >> 21);=0A= =0A= + /* For the initial programming, we assume 512MB configuration */=0A= /* Relocate the CPU's view of the RAM... */=0A= GT_WRITE(GT_SCS10LD_OFS, 0);=0A= GT_WRITE(GT_SCS10HD_OFS, 0x0fe00000 >> 21);=0A= @@ -207,17 +208,66 @@=0A= switch(tmpword &3) {=0A= case 3:=0A= /* 512MiB */=0A= - add_memory_region(256<<20, 256<<20, BOOT_MEM_RAM);=0A= + /* Decoders are allready set -- just add the=0A= + * appropriate region */=0A= + add_memory_region( 0x40<<20, 0xC0<<20, BOOT_MEM_RAM);=0A= + add_memory_region(0x100<<20, 0x100<<20, BOOT_MEM_RAM);=0A= + break;=0A= case 2:=0A= - /* 256MiB */=0A= - /* FIXME: Is it actually here, or at 0x10000000? */=0A= - add_memory_region(128<<20, 128<<20, BOOT_MEM_RAM);=0A= + /* 256MiB -- two banks of 128MiB */=0A= + GT_WRITE(GT_SCS10HD_OFS, 0x07e00000 >> 21);=0A= + GT_WRITE(GT_SCS32LD_OFS, 0x08000000 >> 21);=0A= + GT_WRITE(GT_SCS32HD_OFS, 0x0fe00000 >> 21);=0A= +=0A= + GT_WRITE(GT_SCS0HD_OFS, 0x7f);=0A= + GT_WRITE(GT_SCS2LD_OFS, 0x80);=0A= + GT_WRITE(GT_SCS2HD_OFS, 0xff);=0A= +=0A= + /* reconfigure the PCI0 interface view of memory */=0A= + GT_WRITE(GT_PCI0_CFGADDR_OFS, 0x80000014);=0A= + GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x08000000);=0A= + GT_WRITE(GT_PCI0_BS_SCS10_OFS, 0x0ffff000);=0A= + GT_WRITE(GT_PCI0_BS_SCS32_OFS, 0x0ffff000);=0A= +=0A= + add_memory_region(0x40<<20, 0x40<<20, BOOT_MEM_RAM);=0A= + add_memory_region(0x80<<20, 0x80<<20, BOOT_MEM_RAM);=0A= + break;=0A= case 1:=0A= - /* 128MiB */=0A= - add_memory_region(64<<20, 64<<20, BOOT_MEM_RAM);=0A= + /* 128MiB -- 64MiB per bank */=0A= + GT_WRITE(GT_SCS10HD_OFS, 0x03e00000 >> 21);=0A= + GT_WRITE(GT_SCS32LD_OFS, 0x04000000 >> 21);=0A= + GT_WRITE(GT_SCS32HD_OFS, 0x07e00000 >> 21);=0A= +=0A= + GT_WRITE(GT_SCS0HD_OFS, 0x3f);=0A= + GT_WRITE(GT_SCS2LD_OFS, 0x40);=0A= + GT_WRITE(GT_SCS2HD_OFS, 0x7f);=0A= +=0A= + /* reconfigure the PCI0 interface view of memory */=0A= + GT_WRITE(GT_PCI0_CFGADDR_OFS, 0x80000014);=0A= + GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x04000000);=0A= + GT_WRITE(GT_PCI0_BS_SCS10_OFS, 0x03fff000);=0A= + GT_WRITE(GT_PCI0_BS_SCS32_OFS, 0x03fff000);=0A= +=0A= + /* add the appropriate region */=0A= + add_memory_region(0x40<<20, 0x40<<20, BOOT_MEM_RAM);=0A= + break;=0A= case 0:=0A= /* 64MiB */=0A= - ;=0A= + GT_WRITE(GT_SCS10HD_OFS, 0x01e00000 >> 21);=0A= + GT_WRITE(GT_SCS32LD_OFS, 0x02000000 >> 21);=0A= + GT_WRITE(GT_SCS32HD_OFS, 0x03e00000 >> 21);=0A= +=0A= + GT_WRITE(GT_SCS0HD_OFS, 0x1f);=0A= + GT_WRITE(GT_SCS2LD_OFS, 0x20);=0A= + GT_WRITE(GT_SCS2HD_OFS, 0x3f);=0A= +=0A= + /* reconfigure the PCI0 interface view of memory */=0A= + GT_WRITE(GT_PCI0_CFGADDR_OFS, 0x80000014);=0A= + GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x04000000);=0A= + GT_WRITE(GT_PCI0_BS_SCS10_OFS, 0x01fff000);=0A= + GT_WRITE(GT_PCI0_BS_SCS32_OFS, 0x01fff000);=0A= +=0A= + break;=0A= }=0A= =0A= /* Fix up the DiskOnChip mapping */=0A= ------=_NextPart_000_0016_01C1AF32.C66555C0-- From owner-linux-mips@oss.sgi.com Thu Feb 7 00:36:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g178aok17079 for linux-mips-outgoing; Thu, 7 Feb 2002 00:36:50 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g178alA17076 for ; Thu, 7 Feb 2002 00:36:47 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged)) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA27220 for ; Thu, 7 Feb 2002 00:32:21 -0800 (PST) mail_from (echristo@redhat.com) Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id AAA03407; Thu, 7 Feb 2002 00:25:21 -0800 (PST) Subject: Re: PATCH: Define SUBTARGET_ASM_DEBUGGING_SPEC for Linux/mips From: Eric Christopher To: "H . J . Lu" Cc: Ian Lance Taylor , linux-mips@oss.sgi.com, binutils@sources.redhat.com, gcc-patches@gcc.gnu.org In-Reply-To: <20020206140016.A30178@lucon.org> References: <15454.47823.837119.847975@gladsmuir.algor.co.uk> <20020204172857.A22337@lucon.org> <20020204215804.A2095@nevyn.them.org> <20020205113017.A6144@lucon.org> <20020205135407.A8309@lucon.org> <20020206113259.A15431@dea.linux-mips.net> <20020206124538.A28632@lucon.org> <20020206130037.A29208@lucon.org> <1013030208.19162.6.camel@ghostwheel.cygnus.com> <20020206140016.A30178@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 00:24:40 -0800 Message-Id: <1013070285.19162.74.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 215 Lines: 18 > Here is a patch similar to Irix 6. > > > H.J. > ---- > 2002-02-06 H.J. Lu > > * config/mips/linux.h (SUBTARGET_ASM_DEBUGGING_SPEC): Defined. > Have at. :) -eric -- I will not use abbrev. From owner-linux-mips@oss.sgi.com Thu Feb 7 02:38:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17AcLn19426 for linux-mips-outgoing; Thu, 7 Feb 2002 02:38:21 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17AcGA19420 for ; Thu, 7 Feb 2002 02:38:17 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id DA9371E8CA; Thu, 7 Feb 2002 11:38:10 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Not use branch likely on mips References: <20020205180243.A11993@lucon.org> From: Andreas Jaeger Date: Thu, 07 Feb 2002 11:38:09 +0100 In-Reply-To: <20020205180243.A11993@lucon.org> ("H . J . Lu"'s message of "Tue, 5 Feb 2002 18:02:43 -0800") Message-ID: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 34 "H . J . Lu" writes: > This patch removes branch likely. Please update the copyright years next time. I've committed the patch, Andreas > > H.J. > ---- > 2002-02-05 H.J. Lu > > * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Not use > branch likely. > * sysdeps/mips/pt-machine.h (testandset): Liekwise. > (__compare_and_swap): Liekwise. > > 2002-02-05 H.J. Lu > > * sysdeps/mips/atomicity.h (exchange_and_add): Not use branch > likely. > (atomic_add): Likewise. > (compare_and_swap): Likewise. > * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): > Likewise. > [...] -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Thu Feb 7 02:53:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17ArMH19676 for linux-mips-outgoing; Thu, 7 Feb 2002 02:53:22 -0800 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17ArGA19673; Thu, 7 Feb 2002 02:53:17 -0800 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17Ar8a04663; Thu, 7 Feb 2002 11:53:08 +0100 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.1/8.12.1/Debian -5) with ESMTP id g17Ar247002552; Thu, 7 Feb 2002 11:53:03 +0100 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.34 #1 (Debian)) id 16YWGa-0000oD-00; Wed, 06 Feb 2002 18:53:56 +0100 Date: Wed, 6 Feb 2002 18:53:56 +0100 (CET) From: Vivien Chappelier X-Sender: glaurung@melkor To: Kunihiko IMAI cc: Ralf Baechle , Linux-MIPS Subject: Re: One bug fixed, another found? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 874 Lines: 23 On Wed, 6 Feb 2002, Kunihiko IMAI wrote: > Today I compiled kernel with __wake_up_common not inline function, and > got same result. And also made kgdb version. I found that the line > p = curr->task; > made the memory violation. If you're using binutils 2.9.5, upgrade to a newer version or use the workaround I've posted about one month ago to this list (Subject: binutils workaround), this should fix your bug. Actually list_for_each fails to detect the end of the q->task_list as it is not properly initialized by binutils. This happens when kswapd wakes up, it calls wake_up on the kwapd_wait wait queue which is a global variable initialized at compile time (mm/vmscan.c). Ralf, could you forbid compiling with this version of binutils, as I've already answered 3 times to the same bug :) gcc < 2.91 seem to be alread forbidden in init.c ... regards, Vivien. From owner-linux-mips@oss.sgi.com Thu Feb 7 03:08:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17B8Wi20092 for linux-mips-outgoing; Thu, 7 Feb 2002 03:08:32 -0800 Received: from dea.linux-mips.net (a1as20-p188.stg.tli.de [195.252.194.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17B8SA20089 for ; Thu, 7 Feb 2002 03:08:28 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g17B6Ms18043; Thu, 7 Feb 2002 12:06:22 +0100 Date: Thu, 7 Feb 2002 12:06:22 +0100 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: PATCH: Momentum Ocelot (CP7000) fixes Message-ID: <20020207120622.A18012@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 06, 2002 at 05:21:55PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 614 Lines: 16 On Wed, Feb 06, 2002 at 05:21:55PM -0800, Matthew Dharm wrote: > Attached to this message is a patch to make the Momentum Computer > Ocelot (CP7000) SBC port of Linux work. I made this patch against a > recent (2 days ago) CVS snapshot. Please apply it to the CVS > repository. > > It turns out that the existing code only worked for boards with 512MiB > of SDRAM. This patch makes all memory configurations work. While > discontiguous memory configurations seemed to work, there was some > "unusual" behavior. This patch uses a contiguous memory approach, > which seems much more stable. Applied, Ralf From owner-linux-mips@oss.sgi.com Thu Feb 7 03:38:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17BcK620496 for linux-mips-outgoing; Thu, 7 Feb 2002 03:38:20 -0800 Received: from mail.laser5.co.jp (gw1.laser5.co.jp [202.221.8.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17BcCA20493; Thu, 7 Feb 2002 03:38:13 -0800 Received: from l5ac227.l5.laser5.co.jp (unknown [192.168.128.227]) by mail.laser5.co.jp (Postfix) with ESMTP id F3E83833A5; Thu, 7 Feb 2002 20:38:09 +0900 (JST) Date: Thu, 07 Feb 2002 20:38:09 +0900 Message-ID: From: Kunihiko IMAI To: Vivien Chappelier Cc: Kunihiko IMAI , Ralf Baechle , Linux-MIPS Subject: Re: One bug fixed, another found? In-Reply-To: References: User-Agent: Wanderlust/2.4.0 (Rio) WEMI/1.13.7 (Shimada) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-vine-linux) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 902 Lines: 29 Hi, It goes well to work by Matthew's and Vivien's advices. Thank you very much. The toolchain which I used for kernel compilation was binutils-mipsel-linux-2.9.5-3.i386.rpm egcs-mipsel-linux-1.1.2-4.i386.rpm got from ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/. By this toolchain, The kernel make Oops message at __wake_up_common. I rebuilt and replaced binutils to binutils-2.11.92.0.10. Then it works fine without no Oops at __wake_up_common. At Wed, 6 Feb 2002 18:53:56 +0100 (CET), Vivien Chappelier wrote: > Ralf, could you forbid compiling with this version of binutils, as I've > already answered 3 times to the same bug :) > gcc < 2.91 seem to be alread forbidden in init.c ... I'm sorry for my laziness. Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Thu Feb 7 06:31:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17EV6Q23689 for linux-mips-outgoing; Thu, 7 Feb 2002 06:31:06 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17EUmA23686; Thu, 7 Feb 2002 06:30:48 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16YpZS-0002be-00; Thu, 07 Feb 2002 08:30:42 -0600 Message-ID: <3C628F81.B7079B89@cotw.com> Date: Thu, 07 Feb 2002 08:30:25 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: ralf@oss.sgi.com CC: linux-mips@oss.sgi.com Subject: [PATCH] Fix printk format error, remove dead code, eliminate warnings... Content-Type: multipart/mixed; boundary="------------123C0BC0ED6B31E34070338C" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7984 Lines: 125 This is a multi-part message in MIME format. --------------123C0BC0ED6B31E34070338C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ralf, Please apply. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer --------------123C0BC0ED6B31E34070338C Content-Type: application/octet-stream; name="mipslinux-20020207.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mipslinux-20020207.diff" ZGlmZiAtdXJOIC1YIGN2cy1leGMudHh0IG1pcHNsaW51eC0yLjQuMTcteGZzL2FyY2gvbWlw cy9rZXJuZWwvc2V0dXAuYyBzZXR0b3AvYXJjaC9taXBzL2tlcm5lbC9zZXR1cC5jCi0tLSBt aXBzbGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMva2VybmVsL3NldHVwLmMJVGh1IEZlYiAg NyAwMDowNDo1MyAyMDAyCisrKyBzZXR0b3AvYXJjaC9taXBzL2tlcm5lbC9zZXR1cC5jCVRo dSBGZWIgIDcgMDg6MDA6MTkgMjAwMgpAQCAtNTc2LDcgKzU3NiwxMSBAQAogCWludCBpOwog CiAJZm9yIChpID0gMDsgaSA8IGJvb3RfbWVtX21hcC5ucl9tYXA7IGkrKykgeworI2lmZGVm IENPTkZJR182NEJJVF9QSFlTX0FERFIKIAkJcHJpbnRrKCIgbWVtb3J5OiAlMDhMeCBAICUw OEx4ICIsCisjZWxzZQorCQlwcmludGsoIiBtZW1vcnk6ICUwOGx4IEAgJTA4bHggIiwKKyNl bmRpZgogCQkJYm9vdF9tZW1fbWFwLm1hcFtpXS5zaXplLCBib290X21lbV9tYXAubWFwW2ld LmFkZHIpOwogCQlzd2l0Y2ggKGJvb3RfbWVtX21hcC5tYXBbaV0udHlwZSkgewogCQljYXNl IEJPT1RfTUVNX1JBTToKQEAgLTg3MSw3ICs4ODEsNyBAQAogI2lmbmRlZiBDT05GSUdfSElH SE1FTQogCQkvKiBNYXhpbXVtIG1lbW9yeSB1c2FibGUgaXMgd2hhdCBpcyBkaXJlY3RseSBh ZGRyZXNzYWJsZSAqLwogCQlwcmludGsoS0VSTl9XQVJOSU5HICJXYXJuaW5nIG9ubHkgJWxk TUIgd2lsbCBiZSB1c2VkLlxuIiwKLQkJICAgICAgIE1BWE1FTT4+MjApOworCQkgICAgICAg KHVuc2lnbmVkIGxvbmcpIE1BWE1FTT4+MjApOwogCQlwcmludGsoS0VSTl9XQVJOSU5HICJV c2UgYSBISUdITUVNIGVuYWJsZWQga2VybmVsLlxuIik7CiAjZW5kaWYKIAl9CmRpZmYgLXVy TiAtWCBjdnMtZXhjLnR4dCBtaXBzbGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMvbWF0aC1l bXUvaWVlZTc1NHhjcHQuYyBzZXR0b3AvYXJjaC9taXBzL21hdGgtZW11L2llZWU3NTR4Y3B0 LmMKLS0tIG1pcHNsaW51eC0yLjQuMTcteGZzL2FyY2gvbWlwcy9tYXRoLWVtdS9pZWVlNzU0 eGNwdC5jCVNhdCBKYW4gMTMgMTI6MTc6NTggMjAwMQorKysgc2V0dG9wL2FyY2gvbWlwcy9t YXRoLWVtdS9pZWVlNzU0eGNwdC5jCVdlZCBKYW4gMzAgMDk6MTI6NDggMjAwMgpAQCAtMzAs NiArMzAsNyBAQAogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAKICNpbmNsdWRlICJpZWVlNzU0 LmgiCisjaW5jbHVkZSA8bGludXgva2VybmVsLmg+CiAKIC8qCiAgKiBWZXJ5IG5hZmYgZXhj ZXB0aW9uIGhhbmRsZXIgKHlvdSBjYW4gcGx1ZyBpbiB5b3VyIG93biBhbmQKZGlmZiAtdXJO IC1YIGN2cy1leGMudHh0IG1pcHNsaW51eC0yLjQuMTcteGZzL2FyY2gvbWlwcy9tYXRoLWVt dS9zcF9zdWIuYyBzZXR0b3AvYXJjaC9taXBzL21hdGgtZW11L3NwX3N1Yi5jCi0tLSBtaXBz bGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMvbWF0aC1lbXUvc3Bfc3ViLmMJVGh1IE9jdCAg NCAwODoxOTo0NCAyMDAxCisrKyBzZXR0b3AvYXJjaC9taXBzL21hdGgtZW11L3NwX3N1Yi5j CVdlZCBKYW4gMzAgMTA6Mzg6MjcgMjAwMgpAQCAtMTY3LDExICsxNjcsMTIgQEAKIAkJCXhl ID0geGU7CiAJCQl4cyA9IHlzOwogCQl9Ci0JCWlmICh4bSA9PSAwKQorCQlpZiAoeG0gPT0g MCkgewogCQkJaWYgKGllZWU3NTRfY3NyLnJtID09IElFRUU3NTRfUkQpCiAJCQkJcmV0dXJu IGllZWU3NTRzcF96ZXJvKDEpOwkvKiByb3VuZCBuZWdhdGl2ZSBpbmYuID0+IHNpZ24gPSAt MSAqLwogCQkJZWxzZQogCQkJCXJldHVybiBpZWVlNzU0c3BfemVybygwKTsJLyogb3RoZXIg cm91bmQgbW9kZXMgICA9PiBzaWduID0gMSAqLworCQl9CiAKIAkJLyogbm9ybWFsaXplIHRv IHJvdW5kaW5nIHByZWNpc2lvbiAKIAkJICovCmRpZmYgLXVyTiAtWCBjdnMtZXhjLnR4dCBt aXBzbGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMvbW0vYy1yNTQzMi5jIHNldHRvcC9hcmNo L21pcHMvbW0vYy1yNTQzMi5jCi0tLSBtaXBzbGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMv bW0vYy1yNTQzMi5jCUZyaSBOb3YgMzAgMDc6Mjg6MDYgMjAwMQorKysgc2V0dG9wL2FyY2gv bWlwcy9tbS9jLXI1NDMyLmMJV2VkIEphbiAzMCAxMTowOTo0NyAyMDAyCkBAIC00MiwzNCAr NDIsNiBAQAogLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KIC8qICNpbmNsdWRlIDxhc20vcjRrY2Fj aGUuaD4gKi8KIAotc3RhdGljIGlubGluZSB2b2lkIGZsdXNoX2ljYWNoZV9saW5lX2luZGV4 ZWQodW5zaWduZWQgbG9uZyBhZGRyKQotewotCV9fYXNtX18gX192b2xhdGlsZV9fKAotCQki LnNldCBub3Jlb3JkZXJcblx0IgotCQkiLnNldCBtaXBzM1xuXHQiCi0JCSJjYWNoZSAlMSwg KCUwKVxuXHQiCi0JCSJjYWNoZSAlMSwgMSglMClcblx0IgotCQkiLnNldCBtaXBzMFxuXHQi Ci0JCSIuc2V0IHJlb3JkZXIiCi0JCToKLQkJOiAiciIgKGFkZHIpLAotCQkgICJpIiAoSW5k ZXhfSW52YWxpZGF0ZV9JKSk7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBmbHVzaF9kY2Fj aGVfbGluZV9pbmRleGVkKHVuc2lnbmVkIGxvbmcgYWRkcikKLXsKLQlfX2FzbV9fIF9fdm9s YXRpbGVfXygKLQkJIi5zZXQgbm9yZW9yZGVyXG5cdCIKLQkJIi5zZXQgbWlwczNcblx0Igot CQkiY2FjaGUgJTEsICglMClcblx0IgotCQkiY2FjaGUgJTEsIDEoJTApXG5cdCIKLQkJIi5z ZXQgbWlwczBcblx0IgotCQkiLnNldCByZW9yZGVyIgotCQk6Ci0JCTogInIiIChhZGRyKSwK LQkJICAiaSIgKEluZGV4X1dyaXRlYmFja19JbnZfRCkpOwotfQotCiBzdGF0aWMgaW5saW5l IHZvaWQgZmx1c2hfaWNhY2hlX2xpbmUodW5zaWduZWQgbG9uZyBhZGRyKQogewogCV9fYXNt X18gX192b2xhdGlsZV9fKApkaWZmIC11ck4gLVggY3ZzLWV4Yy50eHQgbWlwc2xpbnV4LTIu NC4xNy14ZnMvYXJjaC9taXBzL21tL2ZhdWx0LmMgc2V0dG9wL2FyY2gvbWlwcy9tbS9mYXVs dC5jCi0tLSBtaXBzbGludXgtMi40LjE3LXhmcy9hcmNoL21pcHMvbW0vZmF1bHQuYwlXZWQg SmFuIDE2IDAwOjA1OjIxIDIwMDIKKysrIHNldHRvcC9hcmNoL21pcHMvbW0vZmF1bHQuYwlX ZWQgSmFuIDMwIDExOjA4OjMwIDIwMDIKQEAgLTE4LDYgKzE4LDkgQEAKICNpbmNsdWRlIDxs aW51eC9zbXAuaD4KICNpbmNsdWRlIDxsaW51eC9zbXBfbG9jay5oPgogI2luY2x1ZGUgPGxp bnV4L3ZlcnNpb24uaD4KKyNpZmRlZiBDT05GSUdfVlQKKyNpbmNsdWRlIDxsaW51eC92dF9r ZXJuLmg+CisjZW5kaWYKIAogI2luY2x1ZGUgPGFzbS9oYXJkaXJxLmg+CiAjaW5jbHVkZSA8 YXNtL3BnYWxsb2MuaD4KZGlmZiAtdXJOIC1YIGN2cy1leGMudHh0IG1pcHNsaW51eC0yLjQu MTcteGZzL2FyY2gvbWlwcy9tbS9pbml0LmMgc2V0dG9wL2FyY2gvbWlwcy9tbS9pbml0LmMK LS0tIG1pcHNsaW51eC0yLjQuMTcteGZzL2FyY2gvbWlwcy9tbS9pbml0LmMJVGh1IEZlYiAg NyAwMDowNDo1NCAyMDAyCisrKyBzZXR0b3AvYXJjaC9taXBzL21tL2luaXQuYwlUaHUgRmVi ICA3IDA3OjAxOjE1IDIwMDIKQEAgLTE2MSw2ICsxNjEsNyBAQAogZXh0ZXJuIGNoYXIgX2Z0 ZXh0LCBfZXRleHQsIF9mZGF0YSwgX2VkYXRhOwogZXh0ZXJuIGNoYXIgX19pbml0X2JlZ2lu LCBfX2luaXRfZW5kOwogCisjaWZkZWYgQ09ORklHX0hJR0hNRU0KIHN0YXRpYyB2b2lkIF9f aW5pdCBmaXhyYW5nZV9pbml0ICh1bnNpZ25lZCBsb25nIHN0YXJ0LCB1bnNpZ25lZCBsb25n IGVuZCwKIAlwZ2RfdCAqcGdkX2Jhc2UpCiB7CkBAIC0xODksMTMgKzE5MCwxNyBAQAogCQlq ID0gMDsKIAl9CiB9CisjZW5kaWYKIAogdm9pZCBfX2luaXQgcGFnZXRhYmxlX2luaXQodm9p ZCkKIHsKKyNpZmRlZiBDT05GSUdfSElHSE1FTQogCXVuc2lnbmVkIGxvbmcgdmFkZHI7Ci0J cGdkX3QgKnBnZCwgKnBnZF9iYXNlOworCXBnZF90ICpwZ2Q7CiAJcG1kX3QgKnBtZDsKIAlw dGVfdCAqcHRlOworI2VuZGlmCisJcGdkX3QgKnBnZF9iYXNlOwogCiAJLyogSW5pdGlhbGl6 ZSB0aGUgZW50aXJlIHBnZC4gICovCiAJcGdkX2luaXQoKHVuc2lnbmVkIGxvbmcpc3dhcHBl cl9wZ19kaXIpOwpkaWZmIC11ck4gLVggY3ZzLWV4Yy50eHQgbWlwc2xpbnV4LTIuNC4xNy14 ZnMvaW5jbHVkZS9saW51eC9ydG5ldGxpbmsuaCBzZXR0b3AvaW5jbHVkZS9saW51eC9ydG5l dGxpbmsuaAotLS0gbWlwc2xpbnV4LTIuNC4xNy14ZnMvaW5jbHVkZS9saW51eC9ydG5ldGxp bmsuaAlTYXQgRGVjIDI5IDAwOjA1OjEzIDIwMDEKKysrIHNldHRvcC9pbmNsdWRlL2xpbnV4 L3J0bmV0bGluay5oCVdlZCBKYW4gMzAgMDg6NDM6MDggMjAwMgpAQCAtNTg2LDkgKzU4Niw5 IEBACiBleHRlcm4gdm9pZCBydG5ldGxpbmtfaW5pdCh2b2lkKTsKIAogI2RlZmluZSBBU1NF UlRfUlROTCgpIGRvIHsgaWYgKGRvd25fdHJ5bG9jaygmcnRubF9zZW0pID09IDApICB7IHVw KCZydG5sX3NlbSk7IFwKLXByaW50aygiUlROTDogYXNzZXJ0aW9uIGZhaWxlZCBhdCAiIF9f RklMRV9fICIoJWQpOiIgX19GVU5DVElPTl9fICJcbiIsIF9fTElORV9fKTsgfSBcCitwcmlu dGsoIlJUTkw6IGFzc2VydGlvbiBmYWlsZWQgYXQgIiBfX0ZJTEVfXyAiKCVkKTogJXNcbiIs IF9fTElORV9fLCBfX0ZVTkNUSU9OX18pOyB9IFwKIAkJICAgfSB3aGlsZSgwKTsKLSNkZWZp bmUgQlVHX1RSQVAoeCkgaWYgKCEoeCkpIHsgcHJpbnRrKCJLRVJORUw6IGFzc2VydGlvbiAo IiAjeCAiKSBmYWlsZWQgYXQgIiBfX0ZJTEVfXyAiKCVkKToiIF9fRlVOQ1RJT05fXyAiXG4i LCBfX0xJTkVfXyk7IH0KKyNkZWZpbmUgQlVHX1RSQVAoeCkgaWYgKCEoeCkpIHsgcHJpbnRr KCJLRVJORUw6IGFzc2VydGlvbiAoIiAjeCAiKSBmYWlsZWQgYXQgIiBfX0ZJTEVfXyAiKCVk KTogJXNcbiIsIF9fTElORV9fLCBfX0ZVTkNUSU9OX18pOyB9CiAKIAogI2VuZGlmIC8qIF9f S0VSTkVMX18gKi8KZGlmZiAtdXJOIC1YIGN2cy1leGMudHh0IG1pcHNsaW51eC0yLjQuMTct eGZzL25ldC9uZXRsaW5rL2FmX25ldGxpbmsuYyBzZXR0b3AvbmV0L25ldGxpbmsvYWZfbmV0 bGluay5jCi0tLSBtaXBzbGludXgtMi40LjE3LXhmcy9uZXQvbmV0bGluay9hZl9uZXRsaW5r LmMJVHVlIEF1ZyAyMSAyMjoyNToyMCAyMDAxCisrKyBzZXR0b3AvbmV0L25ldGxpbmsvYWZf bmV0bGluay5jCVdlZCBKYW4gMzAgMTA6Mzc6MzggMjAwMgpAQCAtNDgsNyArNDgsNyBAQAog I2RlZmluZSBOTF9FTVVMQVRFX0RFVgogI2VuZGlmCiAKLSNkZWZpbmUgQlVHX1RSQVAoeCkg aWYgKCEoeCkpIHsgcHJpbnRrKCJBc3NlcnRpb24gKCIgI3ggIikgZmFpbGVkIGF0ICIgX19G SUxFX18gIiglZCk6IiBfX0ZVTkNUSU9OX18gIlxuIiwgX19MSU5FX18pOyB9CisjZGVmaW5l IEJVR19UUkFQKHgpIGlmICghKHgpKSB7IHByaW50aygiQXNzZXJ0aW9uICgiICN4ICIpIGZh aWxlZCBhdCAiIF9fRklMRV9fICIoJWQpOiVzXG4iLCBfX0xJTkVfXywgX19GVU5DVElPTl9f KTsgfQogCiBzdHJ1Y3QgbmV0bGlua19vcHQKIHsK --------------123C0BC0ED6B31E34070338C-- From owner-linux-mips@oss.sgi.com Thu Feb 7 07:57:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17Fvgk25676 for linux-mips-outgoing; Thu, 7 Feb 2002 07:57:42 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17FvVA25673; Thu, 7 Feb 2002 07:57:31 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16YqvN-0002fF-00; Thu, 07 Feb 2002 09:57:25 -0600 Message-ID: <3C62A3D5.C9F7808E@cotw.com> Date: Thu, 07 Feb 2002 09:57:09 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: [PATCH] Eliminate more compiler warnings... Content-Type: multipart/mixed; boundary="------------F4570B76FBC979731E93AC39" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4349 Lines: 73 This is a multi-part message in MIME format. --------------F4570B76FBC979731E93AC39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please apply this too. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer --------------F4570B76FBC979731E93AC39 Content-Type: application/octet-stream; name="mipslinux-20020207p2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mipslinux-20020207p2.diff" ZGlmZiAtdXJOIC1YIGN2cy1leGMudHh0IG1pcHNsaW51eC0yLjQuMTcteGZzL2FyY2gvbWlw cy9rZXJuZWwvaXJxLmMgc2V0dG9wL2FyY2gvbWlwcy9rZXJuZWwvaXJxLmMKLS0tIG1pcHNs aW51eC0yLjQuMTcteGZzL2FyY2gvbWlwcy9rZXJuZWwvaXJxLmMJVHVlIERlYyAxOCAwMDow NDowMCAyMDAxCisrKyBzZXR0b3AvYXJjaC9taXBzL2tlcm5lbC9pcnEuYwlUaHUgRmViICA3 IDA5OjA1OjA0IDIwMDIKQEAgLTI1LDYgKzI1LDggQEAKICNpbmNsdWRlIDxhc20vc3lzdGVt Lmg+CiAjaW5jbHVkZSA8YXNtL3VhY2Nlc3MuaD4KIAorc3RhdGljIHZvaWQgcmVnaXN0ZXJf aXJxX3Byb2MgKHVuc2lnbmVkIGludCBpcnEpOworCiAvKgogICogQ29udHJvbGxlciBtYXBw aW5ncyBmb3IgYWxsIGludGVycnVwdCBzb3VyY2VzOgogICovCkBAIC05OCw3ICsxMDAsNyBA QAogCQkJcCArPSBzcHJpbnRmKHAsICIsICVzIiwgYWN0aW9uLT5uYW1lKTsKIAkJKnArKyA9 ICdcbic7CiAJfQotCXAgKz0gc3ByaW50ZihwLCAiRVJSOiAlMTBsdVxuIiwgaXJxX2Vycl9j b3VudCk7CisJcCArPSBzcHJpbnRmKHAsICJFUlI6ICUxMHVcbiIsIGF0b21pY19yZWFkKCZp cnFfZXJyX2NvdW50KSk7CiAJcmV0dXJuIHAgLSBidWY7CiB9CiAKZGlmZiAtdXJOIC1YIGN2 cy1leGMudHh0IG1pcHNsaW51eC0yLjQuMTcteGZzL2RyaXZlcnMvaWRlL2lkZS1wcm9iZS5j IHNldHRvcC9kcml2ZXJzL2lkZS9pZGUtcHJvYmUuYwotLS0gbWlwc2xpbnV4LTIuNC4xNy14 ZnMvZHJpdmVycy9pZGUvaWRlLXByb2JlLmMJU3VuIERlYyAgMiAwNjowODowMyAyMDAxCisr KyBzZXR0b3AvZHJpdmVycy9pZGUvaWRlLXByb2JlLmMJVHVlIEphbiAyOSAxNDowNjozOSAy MDAyCkBAIC03MjAsOSArNzIwLDkgQEAKIAogI2lmICFkZWZpbmVkKF9fbWM2ODAwMF9fKSAm JiAhZGVmaW5lZChDT05GSUdfQVBVUykgJiYgIWRlZmluZWQoX19zcGFyY19fKQogCXByaW50 aygiJXMgYXQgMHglMDN4LTB4JTAzeCwweCUwM3ggb24gaXJxICVkIiwgaHdpZi0+bmFtZSwK LQkJaHdpZi0+aW9fcG9ydHNbSURFX0RBVEFfT0ZGU0VUXSwKLQkJaHdpZi0+aW9fcG9ydHNb SURFX0RBVEFfT0ZGU0VUXSs3LAotCQlod2lmLT5pb19wb3J0c1tJREVfQ09OVFJPTF9PRkZT RVRdLCBod2lmLT5pcnEpOworCQkodW5zaWduZWQgaW50KSBod2lmLT5pb19wb3J0c1tJREVf REFUQV9PRkZTRVRdLAorCQkodW5zaWduZWQgaW50KSBod2lmLT5pb19wb3J0c1tJREVfREFU QV9PRkZTRVRdKzcsCisJCSh1bnNpZ25lZCBpbnQpIGh3aWYtPmlvX3BvcnRzW0lERV9DT05U Uk9MX09GRlNFVF0sIGh3aWYtPmlycSk7CiAjZWxpZiBkZWZpbmVkKF9fc3BhcmNfXykKIAlw cmludGsoIiVzIGF0IDB4JTAzbHgtMHglMDNseCwweCUwM2x4IG9uIGlycSAlcyIsIGh3aWYt Pm5hbWUsCiAJCWh3aWYtPmlvX3BvcnRzW0lERV9EQVRBX09GRlNFVF0sCmRpZmYgLXVyTiAt WCBjdnMtZXhjLnR4dCBtaXBzbGludXgtMi40LjE3LXhmcy9kcml2ZXJzL3BjaS9wY2kuaWRz IHNldHRvcC9kcml2ZXJzL3BjaS9wY2kuaWRzCi0tLSBtaXBzbGludXgtMi40LjE3LXhmcy9k cml2ZXJzL3BjaS9wY2kuaWRzCVN1biBEZWMgIDIgMDU6MzQ6NDUgMjAwMQorKysgc2V0dG9w L2RyaXZlcnMvcGNpL3BjaS5pZHMJVGh1IEZlYiAgNyAwOTozNDoxOSAyMDAyCkBAIC0xMzky LDcgKzEzOTIsNyBAQAogMTA5ZSAgQnJvb2t0cmVlIENvcnBvcmF0aW9uCiAJMDM1MCAgQnQ4 NDggVFYgd2l0aCBETUEgcHVzaAogCTAzNTEgIEJ0ODQ5QSBWaWRlbyBjYXB0dXJlCi0JMDM2 YyAgQnQ4NzkoPz8pIFZpZGVvIENhcHR1cmUKKwkwMzZjICBCdDg3OVs/P10gVmlkZW8gQ2Fw dHVyZQogCQkxM2U5IDAwNzAgIFdpbi9UViAoVmlkZW8gU2VjdGlvbikKIAkwMzZlICBCdDg3 OAogCQkwMDcwIDEzZWIgIFdpblRWL0dPCkBAIC00NjU2LDcgKzQ2NTYsNyBAQAogMjcwYiAg WGFudGVsIENvcnBvcmF0aW9uCiAyNzBmICBDaGFpbnRlY2ggQ29tcHV0ZXIgQ28uIEx0ZAog MjcxMSAgQVZJRCBUZWNobm9sb2d5IEluYy4KLTJhMTUgIDNEIFZpc2lvbig/Pz8pCisyYTE1 ICAzRCBWaXNpb25bPz8/XQogMzAwMCAgSGFuc29sIEVsZWN0cm9uaWNzIEluYy4KIDMxNDIg IFBvc3QgSW1wcmVzc2lvbiBTeXN0ZW1zLgogMzM4OCAgSGludCBDb3JwCmRpZmYgLXVyTiAt WCBjdnMtZXhjLnR4dCBtaXBzbGludXgtMi40LjE3LXhmcy9kcml2ZXJzL3BjaS9wcm9jLmMg c2V0dG9wL2RyaXZlcnMvcGNpL3Byb2MuYwotLS0gbWlwc2xpbnV4LTIuNC4xNy14ZnMvZHJp dmVycy9wY2kvcHJvYy5jCVN1biBEZWMgIDIgMDU6MzQ6NDUgMjAwMQorKysgc2V0dG9wL2Ry aXZlcnMvcGNpL3Byb2MuYwlXZWQgSmFuIDMwIDA4OjM0OjAzIDIwMDIKQEAgLTIwMCw3ICsy MDAsNyBAQAogc3RhdGljIGludCBwcm9jX2J1c19wY2lfaW9jdGwoc3RydWN0IGlub2RlICpp bm9kZSwgc3RydWN0IGZpbGUgKmZpbGUsIHVuc2lnbmVkIGludCBjbWQsIHVuc2lnbmVkIGxv bmcgYXJnKQogewogCWNvbnN0IHN0cnVjdCBwcm9jX2Rpcl9lbnRyeSAqZHAgPSBpbm9kZS0+ dS5nZW5lcmljX2lwOwotCXN0cnVjdCBwY2lfZGV2ICpkZXYgPSBkcC0+ZGF0YTsKKwlzdHJ1 Y3QgcGNpX2RldiAqZGV2OwogI2lmZGVmIEhBVkVfUENJX01NQVAKIAlzdHJ1Y3QgcGNpX2Zp bHBfcHJpdmF0ZSAqZnByaXYgPSBmaWxlLT5wcml2YXRlX2RhdGE7CiAjZW5kaWYgLyogSEFW RV9QQ0lfTU1BUCAqLwpAQCAtMjA4LDYgKzIwOCw3IEBACiAKIAlzd2l0Y2ggKGNtZCkgewog CWNhc2UgUENJSU9DX0NPTlRST0xMRVI6CisJCWRldiA9IGRwLT5kYXRhOwogCQlyZXQgPSBw Y2lfY29udHJvbGxlcl9udW0oZGV2KTsKIAkJYnJlYWs7CiAK --------------F4570B76FBC979731E93AC39-- From owner-linux-mips@oss.sgi.com Thu Feb 7 08:18:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17GIiE26159 for linux-mips-outgoing; Thu, 7 Feb 2002 08:18:44 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17GIUA26153; Thu, 7 Feb 2002 08:18:30 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA17743; Thu, 7 Feb 2002 17:18:30 +0100 (MET) Date: Thu, 7 Feb 2002 17:18:30 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Steven J. Hill" cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] Eliminate more compiler warnings... In-Reply-To: <3C62A3D5.C9F7808E@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 Content-Length: 935 Lines: 22 On Thu, 7 Feb 2002, Steven J. Hill wrote: > Please apply this too. Thanks. [...] > printk("%s at 0x%03x-0x%03x,0x%03x on irq %d", hwif->name, > - hwif->io_ports[IDE_DATA_OFFSET], > - hwif->io_ports[IDE_DATA_OFFSET]+7, > - hwif->io_ports[IDE_CONTROL_OFFSET], hwif->irq); > + (unsigned int) hwif->io_ports[IDE_DATA_OFFSET], > + (unsigned int) hwif->io_ports[IDE_DATA_OFFSET]+7, > + (unsigned int) hwif->io_ports[IDE_CONTROL_OFFSET], hwif->irq); Why is it needed? hwif->io_ports[...] or ide_ioreg_t is short which gets promoted to int due to varargs automatically. BTW, please send patches to the list as inlined plain text if possible. -- + 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 Feb 7 08:28:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17GS9C26320 for linux-mips-outgoing; Thu, 7 Feb 2002 08:28:09 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17GRuA26315; Thu, 7 Feb 2002 08:27:57 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA20472; Thu, 7 Feb 2002 17:27:16 +0100 (MET) Date: Thu, 7 Feb 2002 17:27:16 +0100 (MET) From: Geert Uytterhoeven To: "Steven J. Hill" cc: Ralf Baechle , Linux/MIPS Development Subject: Re: [PATCH] Eliminate more compiler warnings... In-Reply-To: <3C62A3D5.C9F7808E@cotw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2581 Lines: 57 On Thu, 7 Feb 2002, Steven J. Hill wrote: > Please apply this too. Thanks. diff -urN -X cvs-exc.txt mipslinux-2.4.17-xfs/drivers/ide/ide-probe.c settop/drivers/ide/ide-probe.c --- mipslinux-2.4.17-xfs/drivers/ide/ide-probe.c Sun Dec 2 06:08:03 2001 +++ settop/drivers/ide/ide-probe.c Tue Jan 29 14:06:39 2002 @@ -720,9 +720,9 @@ #if !defined(__mc68000__) && !defined(CONFIG_APUS) && !defined(__sparc__) printk("%s at 0x%03x-0x%03x,0x%03x on irq %d", hwif->name, - hwif->io_ports[IDE_DATA_OFFSET], - hwif->io_ports[IDE_DATA_OFFSET]+7, - hwif->io_ports[IDE_CONTROL_OFFSET], hwif->irq); + (unsigned int) hwif->io_ports[IDE_DATA_OFFSET], + (unsigned int) hwif->io_ports[IDE_DATA_OFFSET]+7, + (unsigned int) hwif->io_ports[IDE_CONTROL_OFFSET], hwif->irq); #elif defined(__sparc__) printk("%s at 0x%03lx-0x%03lx,0x%03lx on irq %s", hwif->name, hwif->io_ports[IDE_DATA_OFFSET], Wouldn't it be better to treat MIPS the same as SPARC here, so you don't need the casts? Both MIPS and SPARC define ide_ioreg_t to be unsigned long. And perhaps the #if mess (__sparc__ is checked twice) can be cleant up a bit as well. BTW, find include/asm-* -type f | xargs grep 'typedef.*ide_ioreg_t' shows that very few platforms define ide_ioreg_t to be unsigned short... | include/asm-alpha/hdreg.h:typedef unsigned short ide_ioreg_t; | include/asm-arm/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-cris/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-i386/hdreg.h:typedef unsigned short ide_ioreg_t; | include/asm-ia64/hdreg.h:typedef unsigned short ide_ioreg_t; | include/asm-m68k/hdreg.h:typedef unsigned int q40ide_ioreg_t; | include/asm-m68k/hdreg.h:typedef unsigned char * ide_ioreg_t; | include/asm-mips/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-mips64/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-parisc/hdreg.h:typedef unsigned short ide_ioreg_t; | include/asm-ppc/hdreg.h:typedef unsigned int ide_ioreg_t; | include/asm-s390/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-s390x/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-sh/hdreg.h:typedef unsigned int ide_ioreg_t; | include/asm-sparc/hdreg.h:typedef unsigned long ide_ioreg_t; | include/asm-sparc64/hdreg.h:typedef unsigned long ide_ioreg_t; 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 Feb 7 08:51:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17GpAX26844 for linux-mips-outgoing; Thu, 7 Feb 2002 08:51:10 -0800 Received: from dea.linux-mips.net (a1as01-p27.stg.tli.de [195.252.185.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17Gp6A26837 for ; Thu, 7 Feb 2002 08:51:07 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g17Gmgn23669; Thu, 7 Feb 2002 17:48:42 +0100 Date: Thu, 7 Feb 2002 17:48:41 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Steven J. Hill" , linux-mips@oss.sgi.com Subject: Re: [PATCH] Eliminate more compiler warnings... Message-ID: <20020207174841.A23659@dea.linux-mips.net> References: <3C62A3D5.C9F7808E@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Feb 07, 2002 at 05:18:30PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 329 Lines: 10 On Thu, Feb 07, 2002 at 05:18:30PM +0100, Maciej W. Rozycki wrote: > Why is it needed? hwif->io_ports[...] or ide_ioreg_t is short which gets > promoted to int due to varargs automatically. > > BTW, please send patches to the list as inlined plain text if possible. And split into individual independant patches. Ralf From owner-linux-mips@oss.sgi.com Thu Feb 7 09:13:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17HDdQ27274 for linux-mips-outgoing; Thu, 7 Feb 2002 09:13:39 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17HDSA27271 for ; Thu, 7 Feb 2002 09:13:28 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id DC9E0125C8; Thu, 7 Feb 2002 09:13:27 -0800 (PST) Date: Thu, 7 Feb 2002 09:13:27 -0800 From: "H . J . Lu" To: Andreas Jaeger Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Not use branch likely on mips Message-ID: <20020207091327.B15331@lucon.org> References: <20020205180243.A11993@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aj@suse.de on Thu, Feb 07, 2002 at 11:38:09AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2911 Lines: 101 On Thu, Feb 07, 2002 at 11:38:09AM +0100, Andreas Jaeger wrote: > "H . J . Lu" writes: > > > This patch removes branch likely. > > Please update the copyright years next time. > > I've committed the patch, > Here is a new patch. I have checked in a gcc patch which makes ".set noreorder" unnecessary even with "gcc -g". Thanks. H.J. ---- 2002-02-07 H.J. Lu * sysdeps/mips/pspinlock.c (__pthread_spin_lock): Silence the gcc warning. (__pthread_spin_lock): Remove ".set noreorder". * sysdeps/mips/pt-machine.h (__compare_and_swap): Liekwise. 2002-02-07 H.J. Lu * sysdeps/mips/atomicity.h (compare_and_swap): Remove ".set noreorder". * sysdeps/unix/sysv/linux/mips/sys/tas.h (_test_and_set): Likewise. --- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc Thu Feb 7 08:48:57 2002 +++ libc/linuxthreads/sysdeps/mips/pspinlock.c Wed Feb 6 12:12:50 2002 @@ -35,11 +35,8 @@ __pthread_spin_lock (pthread_spinlock_t ("\t\t\t# spin_lock\n" "1:\n\t" "ll %1,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "li %2,1\n\t" "bnez %1,1b\n\t" - " li %2,1\n\t" - ".set pop\n\t" "sc %2,%0\n\t" "beqz %2,1b" : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2) @@ -54,7 +51,7 @@ __pthread_spin_lock (pthread_spinlock_t int __pthread_spin_lock (pthread_spinlock_t *lock) { - while (_test_and_set (lock, 1)); + while (_test_and_set ((int *) lock, 1)); return 0; } --- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc Thu Feb 7 08:48:57 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Wed Feb 6 12:12:50 2002 @@ -60,11 +60,8 @@ __compare_and_swap (long int *p, long in ("/* Inline compare & swap */\n" "1:\n\t" "ll %1,%5\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "move %0,$0\n\t" "bne %1,%3,2f\n\t" - " move %0,$0\n\t" - ".set pop\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" "beqz %0,1b\n" --- libc/sysdeps/mips/atomicity.h.llsc Thu Feb 7 08:50:14 2002 +++ libc/sysdeps/mips/atomicity.h Wed Feb 6 12:12:50 2002 @@ -75,11 +75,8 @@ compare_and_swap (volatile long int *p, ("/* Inline compare & swap */\n" "1:\n\t" "ll %1,%5\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "move %0,$0\n\t" "bne %1,%3,2f\n\t" - " move %0,$0\n\t" - ".set pop\n\t" "move %0,%4\n\t" "sc %0,%2\n\t" "beqz %0,1b\n" --- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc Thu Feb 7 08:50:15 2002 +++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h Wed Feb 6 12:12:50 2002 @@ -45,11 +45,8 @@ _test_and_set (int *p, int v) __THROW ("/* Inline test and set */\n" "1:\n\t" "ll %0,%3\n\t" - ".set push\n\t" - ".set noreorder\n\t" + "move %1,%4\n\t" "beq %0,%4,2f\n\t" - " move %1,%4\n\t" - ".set pop\n\t" "sc %1,%2\n\t" "beqz %1,1b\n" "2:\n\t" From owner-linux-mips@oss.sgi.com Thu Feb 7 10:46:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17IkUR30167 for linux-mips-outgoing; Thu, 7 Feb 2002 10:46:30 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17IkSA30161 for ; Thu, 7 Feb 2002 10:46:28 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id KAA20093 for ; Thu, 7 Feb 2002 10:46:20 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id KAA18070 for ; Thu, 7 Feb 2002 10:46:20 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g17IjrA14142 for ; Thu, 7 Feb 2002 19:45:53 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id TAA27734 for linux-mips@oss.sgi.com; Thu, 7 Feb 2002 19:46:17 +0100 (MET) Message-Id: <200202071846.TAA27734@copsun18.mips.com> Subject: madplay on MIPS To: linux-mips@oss.sgi.com Date: Thu, 7 Feb 2002 19:46:17 +0100 (MET) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 15 I seem to recall somebody asking about madplay mp3 player about a week ago. For what it's worth, we just ran mad-0.14.2b on our Malta board with the 2.4.3 kernel, and it works without a hitch (so far only LE tested). CPU utilization is around 25% of a 200 MHz CPU. The soundcard was a Creative SB card, based on the Ensoniq chip and using the es1371.c driver. /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 Thu Feb 7 10:59:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17IxGi30705 for linux-mips-outgoing; Thu, 7 Feb 2002 10:59:16 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17IxDA30702 for ; Thu, 7 Feb 2002 10:59:13 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g17Iv0B16346; Thu, 7 Feb 2002 10:57:00 -0800 Subject: Re: madplay on MIPS From: Pete Popov To: Hartvig Ekner Cc: linux-mips In-Reply-To: <200202071846.TAA27734@copsun18.mips.com> References: <200202071846.TAA27734@copsun18.mips.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 07 Feb 2002 11:00:39 -0800 Message-Id: <1013108440.2956.40.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 484 Lines: 13 On Thu, 2002-02-07 at 10:46, Hartvig Ekner wrote: > I seem to recall somebody asking about madplay mp3 player about a week > ago. For what it's worth, we just ran mad-0.14.2b on our Malta board > with the 2.4.3 kernel, and it works without a hitch (so far only LE > tested). CPU utilization is around 25% of a 200 MHz CPU. > > The soundcard was a Creative SB card, based on the Ensoniq chip and > using the es1371.c driver. OK, thanks. I'll take a look at the es1371 driver. Pete From owner-linux-mips@oss.sgi.com Fri Feb 8 00:00:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1880Iw21187 for linux-mips-outgoing; Fri, 8 Feb 2002 00:00:18 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1880DA21183 for ; Fri, 8 Feb 2002 00:00:14 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 581011E24B; Fri, 8 Feb 2002 09:00:07 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Not use branch likely on mips References: <20020205180243.A11993@lucon.org> <20020207091327.B15331@lucon.org> From: Andreas Jaeger Date: Fri, 08 Feb 2002 09:00:02 +0100 In-Reply-To: <20020207091327.B15331@lucon.org> ("H . J . Lu"'s message of "Thu, 7 Feb 2002 09:13:27 -0800") Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 583 Lines: 24 "H . J . Lu" writes: > On Thu, Feb 07, 2002 at 11:38:09AM +0100, Andreas Jaeger wrote: >> "H . J . Lu" writes: >> >> > This patch removes branch likely. >> >> Please update the copyright years next time. >> >> I've committed the patch, >> > > Here is a new patch. I have checked in a gcc patch which makes > ".set noreorder" unnecessary even with "gcc -g". But what about current GCC releases? Does it work there also without problems? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Feb 8 02:33:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AXFa25810 for linux-mips-outgoing; Fri, 8 Feb 2002 02:33:15 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AX3A25804 for ; Fri, 8 Feb 2002 02:33:03 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 8 Feb 2002 10:33:03 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 58C3CB479 for ; Fri, 8 Feb 2002 19:33:01 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA32445; Fri, 8 Feb 2002 19:33:00 +0900 (JST) Date: Fri, 08 Feb 2002 19:37:31 +0900 (JST) Message-Id: <20020208.193731.48536791.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Subject: gcc-2.96-99 optimization bug? From: Atsushi Nemoto 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.1 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 Content-Length: 2815 Lines: 102 I found gcc 2.96 (gcc-2.96-99.1.mipsel.rpm in H.J.Lu's RedHat 7.1) outputs wrong code for this short program. int foo(unsigned long long a, unsigned long long b) { int as, bs; as = a >> 63; bs = b >> 63; if (as != bs) return as || !(b << 1); return (a == b) || as; } int main(int argc, char **argv) { return foo(0, 0xffffffffffffffffull); } This program must return 0. But compiling with -O2 it returns 1 !! # gcc -O -o foo foo.c;./foo;echo $? 0 # gcc -O2 -o foo foo.c;./foo;echo $? 1 Output wth -O -g are: 00400780 : 400780: 3c1c0fc0 lui gp,0xfc0 400784: 279c78b0 addiu gp,gp,30896 400788: 0399e021 addu gp,gp,t9 40078c: 00804021 move t0,a0 400790: 00a04821 move t1,a1 400794: 000917c2 srl v0,t1,0x1f 400798: 00402821 move a1,v0 40079c: 000717c2 srl v0,a3,0x1f 4007a0: 10a2000d beq a1,v0,4007d8 4007a4: 00001821 move v1,zero 4007a8: 14a00008 bnez a1,4007cc 4007ac: 00004021 move t0,zero 4007b0: 00071840 sll v1,a3,0x1 4007b4: 000627c2 srl a0,a2,0x1f 4007b8: 00641825 or v1,v1,a0 4007bc: 00061040 sll v0,a2,0x1 4007c0: 00621025 or v0,v1,v0 4007c4: 14400002 bnez v0,4007d0 4007c8: 00000000 nop 4007cc: 24080001 li t0,1 4007d0: 03e00008 jr ra 4007d4: 01001021 move v0,t0 4007d8: 15060003 bne t0,a2,4007e8 4007dc: 00001021 move v0,zero 4007e0: 11270003 beq t1,a3,4007f0 4007e4: 00000000 nop 4007e8: 10a00002 beqz a1,4007f4 4007ec: 00000000 nop 4007f0: 24020001 li v0,1 4007f4: 03e00008 jr ra 4007f8: 00000000 nop Output with -O2 -g are: 00400780 : 400780: 3c1c0fc0 lui gp,0xfc0 400784: 279c78b0 addiu gp,gp,30896 400788: 0399e021 addu gp,gp,t9 40078c: 00805021 move t2,a0 400790: 00c04021 move t0,a2 400794: 00a05821 move t3,a1 400798: 00e04821 move t1,a3 40079c: 000b17c2 srl v0,t3,0x1f 4007a0: 000927c2 srl a0,t1,0x1f 4007a4: 00001821 move v1,zero 4007a8: 1044000a beq v0,a0,4007d4 4007ac: 00002821 move a1,zero 4007b0: 14400006 bnez v0,4007cc 4007b4: 24050001 li a1,1 4007b8: 00091840 sll v1,t1,0x1 4007bc: 000827c2 srl a0,t0,0x1f 4007c0: 00641825 or v1,v1,a0 4007c4: 00081040 sll v0,t0,0x1 4007c8: 00621025 or v0,v1,v0 4007cc: 03e00008 jr ra 4007d0: 00a01021 move v0,a1 4007d4: 15480003 bne t2,t0,4007e4 4007d8: 00001821 move v1,zero 4007dc: 11690003 beq t3,t1,4007ec 4007e0: 00000000 nop 4007e4: 10400002 beqz v0,4007f0 4007e8: 00000000 nop 4007ec: 24030001 li v1,1 4007f0: 03e00008 jr ra 4007f4: 00601021 move v0,v1 It seems one 'bnez' in good code (at 4007c4) was lost in bad code. Is this a know problem? If so, is there any patches available? Thank you. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Fri Feb 8 02:56:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AuVr27040 for linux-mips-outgoing; Fri, 8 Feb 2002 02:56:31 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AuIA27035 for ; Fri, 8 Feb 2002 02:56:18 -0800 Message-Id: <200202081056.g18AuIA27035@oss.sgi.com> Received: (qmail 21926 invoked from network); 8 Feb 2002 10:57:19 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 8 Feb 2002 10:57:19 -0000 Date: Fri, 8 Feb 2002 18:53:46 +0800 From: Zhang Fuxin To: Atsushi Nemoto CC: "linux-mips@oss.sgi.com" Subject: Re: gcc-2.96-99 optimization bug? 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 g18AuJA27037 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3151 Lines: 113 hi, it seems fixed in latest gcc (3.1). gcc 2.96 does produce wrong code for -O2, i posted another example one or two days ago. ÔÚ 2002-02-08 19:37:00 you wrote£ş >I found gcc 2.96 (gcc-2.96-99.1.mipsel.rpm in H.J.Lu's RedHat 7.1) >outputs wrong code for this short program. > >int foo(unsigned long long a, unsigned long long b) >{ > int as, bs; > as = a >> 63; > bs = b >> 63; > if (as != bs) > return as || !(b << 1); > return (a == b) || as; >} > >int main(int argc, char **argv) >{ > return foo(0, 0xffffffffffffffffull); >} > >This program must return 0. But compiling with -O2 it returns 1 !! > ># gcc -O -o foo foo.c;./foo;echo $? >0 ># gcc -O2 -o foo foo.c;./foo;echo $? >1 > >Output wth -O -g are: > >00400780 : > 400780: 3c1c0fc0 lui gp,0xfc0 > 400784: 279c78b0 addiu gp,gp,30896 > 400788: 0399e021 addu gp,gp,t9 > 40078c: 00804021 move t0,a0 > 400790: 00a04821 move t1,a1 > 400794: 000917c2 srl v0,t1,0x1f > 400798: 00402821 move a1,v0 > 40079c: 000717c2 srl v0,a3,0x1f > 4007a0: 10a2000d beq a1,v0,4007d8 > 4007a4: 00001821 move v1,zero > 4007a8: 14a00008 bnez a1,4007cc > 4007ac: 00004021 move t0,zero > 4007b0: 00071840 sll v1,a3,0x1 > 4007b4: 000627c2 srl a0,a2,0x1f > 4007b8: 00641825 or v1,v1,a0 > 4007bc: 00061040 sll v0,a2,0x1 > 4007c0: 00621025 or v0,v1,v0 > 4007c4: 14400002 bnez v0,4007d0 > 4007c8: 00000000 nop > 4007cc: 24080001 li t0,1 > 4007d0: 03e00008 jr ra > 4007d4: 01001021 move v0,t0 > 4007d8: 15060003 bne t0,a2,4007e8 > 4007dc: 00001021 move v0,zero > 4007e0: 11270003 beq t1,a3,4007f0 > 4007e4: 00000000 nop > 4007e8: 10a00002 beqz a1,4007f4 > 4007ec: 00000000 nop > 4007f0: 24020001 li v0,1 > 4007f4: 03e00008 jr ra > 4007f8: 00000000 nop > >Output with -O2 -g are: > >00400780 : > 400780: 3c1c0fc0 lui gp,0xfc0 > 400784: 279c78b0 addiu gp,gp,30896 > 400788: 0399e021 addu gp,gp,t9 > 40078c: 00805021 move t2,a0 > 400790: 00c04021 move t0,a2 > 400794: 00a05821 move t3,a1 > 400798: 00e04821 move t1,a3 > 40079c: 000b17c2 srl v0,t3,0x1f > 4007a0: 000927c2 srl a0,t1,0x1f > 4007a4: 00001821 move v1,zero > 4007a8: 1044000a beq v0,a0,4007d4 > 4007ac: 00002821 move a1,zero > 4007b0: 14400006 bnez v0,4007cc > 4007b4: 24050001 li a1,1 > 4007b8: 00091840 sll v1,t1,0x1 > 4007bc: 000827c2 srl a0,t0,0x1f > 4007c0: 00641825 or v1,v1,a0 > 4007c4: 00081040 sll v0,t0,0x1 > 4007c8: 00621025 or v0,v1,v0 > 4007cc: 03e00008 jr ra > 4007d0: 00a01021 move v0,a1 > 4007d4: 15480003 bne t2,t0,4007e4 > 4007d8: 00001821 move v1,zero > 4007dc: 11690003 beq t3,t1,4007ec > 4007e0: 00000000 nop > 4007e4: 10400002 beqz v0,4007f0 > 4007e8: 00000000 nop > 4007ec: 24030001 li v1,1 > 4007f0: 03e00008 jr ra > 4007f4: 00601021 move v0,v1 > > >It seems one 'bnez' in good code (at 4007c4) was lost in bad code. > >Is this a know problem? If so, is there any patches available? > >Thank you. >--- >Atsushi Nemoto Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Fri Feb 8 04:05:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18C5JM29185 for linux-mips-outgoing; Fri, 8 Feb 2002 04:05:19 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18C5DA29182 for ; Fri, 8 Feb 2002 04:05:13 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA09027; Fri, 8 Feb 2002 13:03:41 +0100 (MET) Date: Fri, 8 Feb 2002 13:03:40 +0100 (MET) From: "Maciej W. Rozycki" To: Andreas Jaeger cc: "H . J . Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Not use branch likely on 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 Content-Length: 506 Lines: 15 On Fri, 8 Feb 2002, Andreas Jaeger wrote: > > Here is a new patch. I have checked in a gcc patch which makes > > ".set noreorder" unnecessary even with "gcc -g". > > But what about current GCC releases? Does it work there also without > problems? At worst you lose a few cycles for superfluous nops. -- + 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 Feb 8 05:40:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Del131478 for linux-mips-outgoing; Fri, 8 Feb 2002 05:40:47 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18DeZA31470; Fri, 8 Feb 2002 05:40:36 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 12B39853; Fri, 8 Feb 2002 14:40:13 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3773D3FB4; Fri, 8 Feb 2002 14:39:38 +0100 (CET) Date: Fri, 8 Feb 2002 14:39:38 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: [PATCH] endianess in /proc/cpuinfo Message-ID: <20020208133938.GA29298@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1358 Lines: 48 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As Ralf also suffers the LTPDS* this is a resend of the needed patch. Index: arch/mips/arc/identify.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/arc/identify.c,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 identify.c --- arch/mips/arc/identify.c 2001/12/12 13:45:57 1.5.2.1 +++ arch/mips/arc/identify.c 2001/12/13 18:00:04 @@ -26,7 +26,7 @@ =20 static struct smatch mach_table[] =3D { { "SGI-IP22", - "SGI Indy", + "SGI ", MACH_GROUP_SGI, MACH_SGI_INDY, PROM_FLAG_ARCS Flo * Linux Thorvalds Patch Drop Syndrom --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --M9NhX3UHpAaciwkO 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 iD8DBQE8Y9UaUaz2rXW+gJcRAmMBAJ9mWVmrl8uyrff4loZs33FTRjrDjQCfWkbV WxyKx27gVAhaMdMMpaGSAAI= =8E/3 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-linux-mips@oss.sgi.com Fri Feb 8 05:40:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18Deui31505 for linux-mips-outgoing; Fri, 8 Feb 2002 05:40:56 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18DeZA31471; Fri, 8 Feb 2002 05:40:36 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2A08D859; Fri, 8 Feb 2002 14:40:13 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 96FD03FB4; Fri, 8 Feb 2002 14:40:23 +0100 (CET) Date: Fri, 8 Feb 2002 14:40:23 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: [PATCH] /proc/cpuinfo endianess Message-ID: <20020208134023.GB29298@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline User-Agent: Mutt/1.3.25i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1597 Lines: 52 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Again a LTPDS solution: Index: arch/mips/kernel/proc.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/proc.c,v retrieving revision 1.27.2.6 diff -u -r1.27.2.6 proc.c --- arch/mips/kernel/proc.c 2002/01/07 01:16:33 1.27.2.6 +++ arch/mips/kernel/proc.c 2002/02/08 13:37:18 @@ -97,6 +97,11 @@ seq_printf(m, "BogoMIPS\t\t: %lu.%02lu\n", loops_per_jiffy / (500000/HZ), (loops_per_jiffy / (5000/HZ)) % 100); +#ifdef __MIPSEB__ + seq_printf(m, "byteorder\t\t: big endian\n"); +#else + seq_printf(m, "byteorder\t\t: little endian\n"); +#endif seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no"); seq_printf(m, "microsecond timers\t: %s\n", (mips_cpu.options & MIPS_CPU_COUNTER) ? "yes" : "no"); Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --CdrF4e02JqNVZeln 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 iD8DBQE8Y9VHUaz2rXW+gJcRAivqAKCgpv1mKbIZ7AxE747a6D2L4z8R0gCfeLRo 6Q1V4AihstNEHDD+imm0h1g= =mtj2 -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-linux-mips@oss.sgi.com Fri Feb 8 07:34:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18FYAp01127 for linux-mips-outgoing; Fri, 8 Feb 2002 07:34:10 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18FY3A01123 for ; Fri, 8 Feb 2002 07:34:03 -0800 Received: from sjhill by real.realitydiluted.com with local (Exim 3.22 #1 (Red Hat Linux)) id 16ZD2B-0003iv-00 for ; Fri, 08 Feb 2002 09:33:55 -0600 To: linux-mips@oss.sgi.com Subject: [PATCH] Removal of warning messages for gdb-stub.c Message-Id: From: "Steven J. Hill" Date: Fri, 08 Feb 2002 09:33:55 -0600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1319 Lines: 60 Just more clean ups. I tested it, it works. -Steve diff -urN -X cvs-exc.txt mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c settop/arch/mips/kernel/gdb-stub.c --- mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c Thu Nov 29 09:13:08 2001 +++ settop/arch/mips/kernel/gdb-stub.c Fri Feb 8 09:14:52 2002 @@ -306,7 +306,7 @@ unsigned char ch; while (count-- > 0) { - if (kgdb_read_byte(mem++, &ch) != 0) + if (kgdb_read_byte((unsigned *) mem++, (unsigned *) &ch) != 0) return 0; *buf++ = hexchars[ch >> 4]; *buf++ = hexchars[ch & 0xf]; @@ -332,7 +332,7 @@ { ch = hex(*buf++) << 4; ch |= hex(*buf++); - if (kgdb_write_byte(ch, mem++) != 0) + if (kgdb_write_byte((unsigned) ch, (unsigned *) mem++) != 0) return 0; } @@ -902,23 +902,21 @@ if (!initialized) return; - __asm__ __volatile__(" - .globl breakinst - .set noreorder - nop -breakinst: break - nop - .set reorder - "); + __asm__ __volatile__( + ".globl\tbreakinst\n\t" + ".set\tnoreorder\n\t" + "nop\n\t" + "breakinst:\tbreak\n\t" + "nop\n\t" + ".set\treorder\n\t"); } void adel(void) { - __asm__ __volatile__(" - .globl adel - la $8,0x80000001 - lw $9,0($8) - "); + __asm__ __volatile__( + ".globl\tadel\n\t" + "la\t$8,0x80000001\n\t" + "lw\t$9,0($8)\n\t"); } #ifdef CONFIG_GDB_CONSOLE From owner-linux-mips@oss.sgi.com Fri Feb 8 08:16:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18GGs704840 for linux-mips-outgoing; Fri, 8 Feb 2002 08:16:54 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18GGkA04835 for ; Fri, 8 Feb 2002 08:16:47 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA21330; Fri, 8 Feb 2002 17:15:59 +0100 (MET) Date: Fri, 8 Feb 2002 17:16:00 +0100 (MET) From: Geert Uytterhoeven To: "Steven J. Hill" cc: Linux/MIPS Development Subject: Re: [PATCH] Removal of warning messages for gdb-stub.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1482 Lines: 49 On Fri, 8 Feb 2002, Steven J. Hill wrote: > Just more clean ups. I tested it, it works. > > -Steve > > diff -urN -X cvs-exc.txt mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c settop/arch/mips/kernel/gdb-stub.c > --- mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c Thu Nov 29 09:13:08 2001 > +++ settop/arch/mips/kernel/gdb-stub.c Fri Feb 8 09:14:52 2002 > @@ -306,7 +306,7 @@ > unsigned char ch; > > while (count-- > 0) { > - if (kgdb_read_byte(mem++, &ch) != 0) > + if (kgdb_read_byte((unsigned *) mem++, (unsigned *) &ch) != 0) > return 0; > *buf++ = hexchars[ch >> 4]; > *buf++ = hexchars[ch & 0xf]; > @@ -332,7 +332,7 @@ > { > ch = hex(*buf++) << 4; > ch |= hex(*buf++); > - if (kgdb_write_byte(ch, mem++) != 0) > + if (kgdb_write_byte((unsigned) ch, (unsigned *) mem++) != 0) > return 0; > } > Wouldn't it be better to change the prototypes | int kgdb_read_byte(unsigned *address, unsigned *dest); | int kgdb_write_byte(unsigned val, unsigned *dest); instead? If these routines work on bytes, why have them taking unsigned (wasn't plain `unsigned' deprecated in some recent C standard?) parameters instead of char parameters? 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 Feb 8 08:16:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18GGvj04853 for linux-mips-outgoing; Fri, 8 Feb 2002 08:16:57 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18GGrA04839 for ; Fri, 8 Feb 2002 08:16:54 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 248B21E9B8; Fri, 8 Feb 2002 17:15:46 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: PATCH: Not use branch likely on mips References: <20020205180243.A11993@lucon.org> <20020207091327.B15331@lucon.org> From: Andreas Jaeger Date: Fri, 08 Feb 2002 17:15:45 +0100 In-Reply-To: <20020207091327.B15331@lucon.org> ("H . J . Lu"'s message of "Thu, 7 Feb 2002 09:13:27 -0800") Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 534 Lines: 25 "H . J . Lu" writes: > On Thu, Feb 07, 2002 at 11:38:09AM +0100, Andreas Jaeger wrote: >> "H . J . Lu" writes: >> >> > This patch removes branch likely. >> >> Please update the copyright years next time. >> >> I've committed the patch, >> > > Here is a new patch. I have checked in a gcc patch which makes > ".set noreorder" unnecessary even with "gcc -g". > > Thanks. Thanks, committed, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Feb 8 09:28:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18HSVx05842 for linux-mips-outgoing; Fri, 8 Feb 2002 09:28:31 -0800 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18HS5A05837 for ; Fri, 8 Feb 2002 09:28:06 -0800 Received: (qmail 16460 invoked by uid 0); 8 Feb 2002 17:27:58 -0000 Received: from pd9e41821.dip.t-dialin.net (HELO bogon.ms20.nix) (217.228.24.33) by mail.gmx.net (mp011-rz3) with SMTP; 8 Feb 2002 17:27:58 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 936B036BDC; Fri, 8 Feb 2002 18:27:11 +0100 (CET) Date: Fri, 8 Feb 2002 18:27:11 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: ip22 watchdog timer Message-ID: <20020208172711.GA5605@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com, ralf@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6764 Lines: 238 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached is an updated patch for the ip22 watchdog timer. Please apply. -- Guido --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="indydog-2001-02-08.diff" diff -Naur kernel-source-2.4.17.clean/Documentation/Configure.help kernel-source-2.4.17/Documentation/Configure.help --- kernel-source-2.4.17.clean/Documentation/Configure.help Wed Mar 26 05:57:18 2003 +++ kernel-source-2.4.17/Documentation/Configure.help Wed Mar 26 18:50:52 2003 @@ -3129,6 +3129,13 @@ via the file /proc/rtc and its behaviour is set by various ioctls on /dev/rtc. +Indy/I2 Hardware Watchdog +CONFIG_INDYDOG + Hardwaredriver for the Indy's/I2's watchdog. This is a + watchdog timer that will reboot the machine after a 60 second + timer expired and no process has written to /dev/watchdog during + that time. + Support the Bell Technologies HUB6 card CONFIG_HUB6 Say Y here to enable support in the dumb serial driver to support diff -Naur kernel-source-2.4.17.clean/arch/mips/config.in kernel-source-2.4.17/arch/mips/config.in --- kernel-source-2.4.17.clean/arch/mips/config.in Wed Mar 26 05:57:19 2003 +++ kernel-source-2.4.17/arch/mips/config.in Wed Mar 26 19:03:33 2003 @@ -574,6 +574,11 @@ fi # we always need the dummy console to make the serial console I2 happy define_bool CONFIG_DUMMY_CONSOLE y + bool 'Watchdog Timer Support' CONFIG_WATCHDOG + if [ "$CONFIG_WATCHDOG" != "n" ]; then + bool ' Disable watchdog shutdown on close' CONFIG_WATCHDOG_NOWAYOUT + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG + fi endmenu fi diff -Naur kernel-source-2.4.17.clean/arch/mips/sgi-ip22/ip22-mc.c kernel-source-2.4.17/arch/mips/sgi-ip22/ip22-mc.c --- kernel-source-2.4.17.clean/arch/mips/sgi-ip22/ip22-mc.c Wed Mar 26 05:57:28 2003 +++ kernel-source-2.4.17/arch/mips/sgi-ip22/ip22-mc.c Wed Mar 26 18:38:55 2003 @@ -82,6 +82,14 @@ * interrupts are first enabled etc. */ + /* Step 0: Make sure we turn off the watchdog in case it's + * still running (which might be the case after a + * soft reboot). + */ + tmpreg = mcmisc_regs->cpuctrl0; + tmpreg &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = tmpreg; + /* Step 1: The CPU/GIO error status registers will not latch * up a new error status until the register has been * cleared by the cpu. These status registers are diff -Naur kernel-source-2.4.17.clean/drivers/char/Makefile kernel-source-2.4.17/drivers/char/Makefile --- kernel-source-2.4.17.clean/drivers/char/Makefile Wed Mar 26 05:57:32 2003 +++ kernel-source-2.4.17/drivers/char/Makefile Wed Mar 26 18:38:47 2003 @@ -245,6 +245,7 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o +obj-$(CONFIG_INDYDOG) += indydog.o subdir-$(CONFIG_MWAVE) += mwave ifeq ($(CONFIG_MWAVE),y) diff -Naur kernel-source-2.4.17.clean/drivers/char/indydog.c kernel-source-2.4.17/drivers/char/indydog.c --- kernel-source-2.4.17.clean/drivers/char/indydog.c Thu Jan 1 01:00:00 1970 +++ kernel-source-2.4.17/drivers/char/indydog.c Wed Mar 26 20:33:59 2003 @@ -0,0 +1,158 @@ +/* + * IndyDog 0.0.2 A Hardware Watchdog Device for SGI IP22 + * + * (c) Copyright 2001 Guido Guenther , All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * based on softdog.c by Alan Cox + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int indydog_alive; +static struct sgimc_misc_ctrl *mcmisc_regs; + +static void indydog_ping() +{ + mcmisc_regs->watchdogt = 0; +} + + +/* + * Allow only one person to hold it open + */ + +static int indydog_open(struct inode *inode, struct file *file) +{ + u32 mc_ctrl0; + + if(indydog_alive) + return -EBUSY; +#ifdef CONFIG_WATCHDOG_NOWAYOUT + MOD_INC_USE_COUNT; +#endif + /* + * Activate timer + */ + mcmisc_regs = (struct sgimc_misc_ctrl *)(KSEG1+0x1fa00000); + + mc_ctrl0 = mcmisc_regs->cpuctrl0 | SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + indydog_ping(); + + indydog_alive=1; + printk("Started watchdog timer.\n"); + return 0; +} + +static int indydog_release(struct inode *inode, struct file *file) +{ + /* + * Shut off the timer. + * Lock it in if it's a module and we defined ...NOWAYOUT + */ + lock_kernel(); +#ifndef CONFIG_WATCHDOG_NOWAYOUT + { + u32 mc_ctrl0 = mcmisc_regs->cpuctrl0; + mc_ctrl0 &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + printk("Stopped watchdog timer.\n"); + } +#endif + indydog_alive=0; + unlock_kernel(); + return 0; +} + +static ssize_t indydog_write(struct file *file, const char *data, size_t len, loff_t *ppos) +{ + /* Can't seek (pwrite) on this device */ + if (ppos != &file->f_pos) + return -ESPIPE; + + /* + * Refresh the timer. + */ + if(len) { + indydog_ping(); + return 1; + } + return 0; +} + +static int indydog_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + static struct watchdog_info ident = { + identity: "Hardware Watchdog for SGI IP22", + }; + switch (cmd) { + default: + return -ENOIOCTLCMD; + case WDIOC_GETSUPPORT: + if(copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))) + return -EFAULT; + return 0; + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + return put_user(0,(int *)arg); + case WDIOC_KEEPALIVE: + indydog_ping(); + return 0; + } +} + +static struct file_operations indydog_fops = { + owner: THIS_MODULE, + write: indydog_write, + ioctl: indydog_ioctl, + open: indydog_open, + release: indydog_release, +}; + +static struct miscdevice indydog_miscdev = { + minor: WATCHDOG_MINOR, + name: "watchdog", + fops: &indydog_fops, +}; + +static const char banner[] __initdata = KERN_INFO "Hardware Watchdog Timer for SGI IP22: 0.0.2\n"; + +static int __init watchdog_init(void) +{ + int ret; + + ret = misc_register(&indydog_miscdev); + + if (ret) + return ret; + + printk(banner); + + return 0; +} + +static void __exit watchdog_exit(void) +{ + misc_deregister(&indydog_miscdev); +} + +module_init(watchdog_init); +module_exit(watchdog_exit); +MODULE_LICENSE("GPL"); --y0ulUmNC+osPPQO6-- From owner-linux-mips@oss.sgi.com Fri Feb 8 09:42:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18HgdV06130 for linux-mips-outgoing; Fri, 8 Feb 2002 09:42:39 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18HgXA06126 for ; Fri, 8 Feb 2002 09:42:33 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16ZF2Y-0006Lq-00; Fri, 08 Feb 2002 12:42:26 -0500 Date: Fri, 8 Feb 2002 12:42:26 -0500 From: Daniel Jacobowitz To: Geert Uytterhoeven Cc: "Steven J. Hill" , Linux/MIPS Development Subject: Re: [PATCH] Removal of warning messages for gdb-stub.c Message-ID: <20020208124226.A24322@nevyn.them.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1664 Lines: 46 On Fri, Feb 08, 2002 at 05:16:00PM +0100, Geert Uytterhoeven wrote: > On Fri, 8 Feb 2002, Steven J. Hill wrote: > > Just more clean ups. I tested it, it works. > > > > -Steve > > > > diff -urN -X cvs-exc.txt mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c settop/arch/mips/kernel/gdb-stub.c > > --- mipslinux-2.4.17-xfs/arch/mips/kernel/gdb-stub.c Thu Nov 29 09:13:08 2001 > > +++ settop/arch/mips/kernel/gdb-stub.c Fri Feb 8 09:14:52 2002 > > @@ -306,7 +306,7 @@ > > unsigned char ch; > > > > while (count-- > 0) { > > - if (kgdb_read_byte(mem++, &ch) != 0) > > + if (kgdb_read_byte((unsigned *) mem++, (unsigned *) &ch) != 0) > > return 0; > > *buf++ = hexchars[ch >> 4]; > > *buf++ = hexchars[ch & 0xf]; > > @@ -332,7 +332,7 @@ > > { > > ch = hex(*buf++) << 4; > > ch |= hex(*buf++); > > - if (kgdb_write_byte(ch, mem++) != 0) > > + if (kgdb_write_byte((unsigned) ch, (unsigned *) mem++) != 0) > > return 0; > > } > > > > Wouldn't it be better to change the prototypes > > | int kgdb_read_byte(unsigned *address, unsigned *dest); > | int kgdb_write_byte(unsigned val, unsigned *dest); > > instead? > > If these routines work on bytes, why have them taking unsigned (wasn't plain > `unsigned' deprecated in some recent C standard?) parameters instead of char > parameters? Because Ralf dropped one of my patches, or messed up a merge, or more likely I simply sent him a bad patch. My working directory from when I remember writing those functions says unsigned char... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Feb 8 10:30:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18IUpu06839 for linux-mips-outgoing; Fri, 8 Feb 2002 10:30:51 -0800 Received: from ocean.lucon.org (12-234-19-19.client.attbi.com [12.234.19.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18IUmA06836 for ; Fri, 8 Feb 2002 10:30:49 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5EA31125C8; Fri, 8 Feb 2002 10:30:47 -0800 (PST) Date: Fri, 8 Feb 2002 10:30:47 -0800 From: "H . J . Lu" To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: gcc-2.96-99 optimization bug? Message-ID: <20020208103047.A6079@lucon.org> References: <20020208.193731.48536791.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020208.193731.48536791.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Feb 08, 2002 at 07:37:31PM +0900 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 439 Lines: 14 On Fri, Feb 08, 2002 at 07:37:31PM +0900, Atsushi Nemoto wrote: > I found gcc 2.96 (gcc-2.96-99.1.mipsel.rpm in H.J.Lu's RedHat 7.1) > outputs wrong code for this short program. > > It seems one 'bnez' in good code (at 4007c4) was lost in bad code. > > Is this a know problem? If so, is there any patches available? > gcc 3.1 seems fine. No one is working on gcc 2.96. I am working on a new Linuxx/mips which will use gcc 3.1. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 8 14:04:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18M4mr11612 for linux-mips-outgoing; Fri, 8 Feb 2002 14:04:48 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18M4gA11609 for ; Fri, 8 Feb 2002 14:04:42 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2F92284B; Fri, 8 Feb 2002 23:04:22 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 61B8F4162; Fri, 8 Feb 2002 22:58:51 +0100 (CET) Date: Fri, 8 Feb 2002 22:58:51 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: gdb disassemble bug Message-ID: <20020208215851.GA18416@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1184 Lines: 41 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, while debugging arcboot and some interesting crashes related to caching etc i found a disassemble bug in gdb=20 0x88166b58 : mtc0 zero,gp 0x88166b5c : nop 0x88166b60 : mtc0 zero,sp 0x88166b64 : nop mtc0/mfc0 do not address cpu registers but CP0 registers. The decoding as "gp" or "sp" is not correct. These are "TagLo" and "TagHi". If somebody has an idea why the kernel crashes when writing to TagHi - Speak up ... This only seems to happen sometimes not always. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --sm4nu43k4a2Rpi4c 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 iD8DBQE8ZEobUaz2rXW+gJcRAqOBAKDAWzd1m5if/pBuuxQIwTsg0IqMmgCgmiB+ 4/jAlCVlpDoUnYy9s259UIM= =nn3I -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-linux-mips@oss.sgi.com Fri Feb 8 14:11:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18MBLO11735 for linux-mips-outgoing; Fri, 8 Feb 2002 14:11:21 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18MBIA11731 for ; Fri, 8 Feb 2002 14:11:18 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16ZJEJ-0000Uy-00; Fri, 08 Feb 2002 17:10:51 -0500 Date: Fri, 8 Feb 2002 17:10:51 -0500 From: Daniel Jacobowitz To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: gdb disassemble bug Message-ID: <20020208171051.A1829@nevyn.them.org> References: <20020208215851.GA18416@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020208215851.GA18416@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 706 Lines: 20 On Fri, Feb 08, 2002 at 10:58:51PM +0100, Florian Lohoff wrote: > > Hi, > while debugging arcboot and some interesting crashes related to caching > etc i found a disassemble bug in gdb > > 0x88166b58 : mtc0 zero,gp > 0x88166b5c : nop > 0x88166b60 : mtc0 zero,sp > 0x88166b64 : nop > > mtc0/mfc0 do not address cpu registers but CP0 registers. The decoding > as "gp" or "sp" is not correct. These are "TagLo" and "TagHi". - what version of GDB? - does objdump do the same thing? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Feb 8 14:19:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18MJ7q11874 for linux-mips-outgoing; Fri, 8 Feb 2002 14:19:07 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18MIxA11870 for ; Fri, 8 Feb 2002 14:18:59 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 9078B84B; Fri, 8 Feb 2002 23:18:39 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 93AA94162; Fri, 8 Feb 2002 23:18:49 +0100 (CET) Date: Fri, 8 Feb 2002 23:18:49 +0100 From: Florian Lohoff To: Daniel Jacobowitz Cc: linux-mips@oss.sgi.com Subject: Re: gdb disassemble bug Message-ID: <20020208221849.GA18922@paradigm.rfc822.org> References: <20020208215851.GA18416@paradigm.rfc822.org> <20020208171051.A1829@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20020208171051.A1829@nevyn.them.org> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2226 Lines: 64 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2002 at 05:10:51PM -0500, Daniel Jacobowitz wrote: > On Fri, Feb 08, 2002 at 10:58:51PM +0100, Florian Lohoff wrote: > > 0x88166b58 : mtc0 zero,gp > > 0x88166b5c : nop > > 0x88166b60 : mtc0 zero,sp > > 0x88166b64 : nop > >=20 > > mtc0/mfc0 do not address cpu registers but CP0 registers. The decoding > > as "gp" or "sp" is not correct. These are "TagLo" and "TagHi". >=20 > - what version of GDB? > - does objdump do the same thing? reset:~# gdb --version GNU gdb 5.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mips-linux". reset:~# dpkg -l gdb Desired=3DUnknown/Install/Remove/Purge/Hold | Status=3DNot/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=3D(none)/Hold/Reinst-required/X=3Dboth-problems (Status,Err: upperc= ase=3Dbad) ||/ Name Version Description +++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ii gdb 5.1-1 The GNU Debugger Objdump does seem to get this right: 88166b58: 4080e000 mtc0 zero,$28 88166b60: 4080e800 mtc0 zero,$29 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --EeQfGwPcQSOJBaQU 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 iD8DBQE8ZE7JUaz2rXW+gJcRAnBKAJ9j3mlpOklYr58fP56LiYK1CyL9CgCgo6OF AQXHnjP5p1nwFl6Hc+3qdwg= =DV4t -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-linux-mips@oss.sgi.com Fri Feb 8 14:31:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18MVDn12057 for linux-mips-outgoing; Fri, 8 Feb 2002 14:31:13 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18MV9A12054 for ; Fri, 8 Feb 2002 14:31:09 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16ZJXv-0000kG-00; Fri, 08 Feb 2002 17:31:07 -0500 Date: Fri, 8 Feb 2002 17:31:07 -0500 From: Daniel Jacobowitz To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: gdb disassemble bug Message-ID: <20020208173107.A2758@nevyn.them.org> References: <20020208215851.GA18416@paradigm.rfc822.org> <20020208171051.A1829@nevyn.them.org> <20020208221849.GA18922@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020208221849.GA18922@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1682 Lines: 37 On Fri, Feb 08, 2002 at 11:18:49PM +0100, Florian Lohoff wrote: > On Fri, Feb 08, 2002 at 05:10:51PM -0500, Daniel Jacobowitz wrote: > > On Fri, Feb 08, 2002 at 10:58:51PM +0100, Florian Lohoff wrote: > > > 0x88166b58 : mtc0 zero,gp > > > 0x88166b5c : nop > > > 0x88166b60 : mtc0 zero,sp > > > 0x88166b64 : nop > > > > > > mtc0/mfc0 do not address cpu registers but CP0 registers. The decoding > > > as "gp" or "sp" is not correct. These are "TagLo" and "TagHi". > > > > - what version of GDB? > > - does objdump do the same thing? > > reset:~# gdb --version > GNU gdb 5.1 > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "mips-linux". > reset:~# dpkg -l gdb > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) > ||/ Name Version Description > +++-==============-==============-============================================ > ii gdb 5.1-1 The GNU Debugger OK. You may want to try a CVS snapshot; I'm 99% certain that this was fixed after gdb 5.1 branched. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Fri Feb 8 14:40:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18MeuC12232 for linux-mips-outgoing; Fri, 8 Feb 2002 14:40:56 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18MeRA12228 for ; Fri, 8 Feb 2002 14:40:27 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g18MeOR26336; Fri, 8 Feb 2002 14:40:24 -0800 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: PATCH: Updated support for Ocelot boot PROM Date: Fri, 8 Feb 2002 14:40:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01C1B0AE.8B076400" 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.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10215 Lines: 282 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1B0AE.8B076400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ralf et al -- Attached is a patch made against the lastest CVS snapshot (from about an hour ago). Please apply. This patch adds support for our PMON v2.0 boot PROM. This boot prom uses a completely different mapping from the v1 boot prom, so the kernel code had to change significantly. This code auto-detects the version of PMON and adjusts accordingly. Oh, it also adds support for some of the debugging callbacks, which can be used before the MMU/TLBs are reconfigured. And it prints a nice "Booting Linux kernel" message just to let you know that life is good. :) Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_0024_01C1B0AE.8B076400 Content-Type: application/octet-stream; name="patch20020208" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch20020208" ? arch/mips/boot/elf2ecoff=0A= ? arch/mips/boot/vmlinux.ecoff=0A= ? arch/mips/boot/addinitrd=0A= ? arch/mips/gt64120/momenco_ocelot/setup-save.c=0A= Index: arch/mips/gt64120/momenco_ocelot/prom.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/prom.c,v=0A= retrieving revision 1.3.2.1=0A= diff -u -r1.3.2.1 prom.c=0A= --- arch/mips/gt64120/momenco_ocelot/prom.c 2001/12/12 13:45:58 1.3.2.1=0A= +++ arch/mips/gt64120/momenco_ocelot/prom.c 2002/02/08 21:32:29=0A= @@ -15,34 +15,35 @@=0A= #include =0A= #include =0A= =0A= -#define PLD_BASE 0xbc000000=0A= +struct callvectors {=0A= + int (*open) (char*, int, int);=0A= + int (*close) (int);=0A= + int (*read) (int, void*, int);=0A= + int (*write) (int, void*, int);=0A= + off_t (*lseek) (int, off_t, int);=0A= + int (*printf) (const char*, ...);=0A= + void (*cacheflush) (void);=0A= + char* (*gets) (char*);=0A= +};=0A= =0A= -#define REV 0x0 /* Board Assembly Revision */=0A= -#define PLD1ID 0x1 /* PLD 1 ID */=0A= -#define PLD2ID 0x2 /* PLD 2 ID */=0A= -#define RESET_STAT 0x3 /* Reset Status Register */=0A= -#define BOARD_STAT 0x4 /* Board Status Register */=0A= -#define CPCI_ID 0x5 /* Compact PCI ID Register */=0A= -#define CONTROL 0x8 /* Control Register */=0A= -#define CPU_EEPROM 0x9 /* CPU Configuration EEPROM Register */=0A= -#define INTMASK 0xA /* Interrupt Mask Register */=0A= -#define INTSTAT 0xB /* Interrupt Status Register */=0A= -#define INTSET 0xC /* Interrupt Set Register */=0A= -#define INTCLR 0xD /* Interrupt Clear Register */=0A= -=0A= -#define PLD_REG(x) ((uint8_t*)(PLD_BASE+(x)))=0A= -=0A= +struct callvectors* debug_vectors;=0A= char arcs_cmdline[CL_SIZE];=0A= =0A= +extern unsigned long gt64120_base;=0A= +=0A= const char *get_system_type(void)=0A= {=0A= return "Momentum Ocelot";=0A= }=0A= =0A= /* [jsun@junsun.net] PMON passes arguments in C main() style */=0A= -void __init prom_init(int argc, const char **arg)=0A= +void __init prom_init(int argc, char **arg, char** env, struct = callvectors *cv)=0A= {=0A= int i;=0A= + uint32_t tmp;=0A= +=0A= + /* save the PROM vectors for debugging use */=0A= + debug_vectors =3D cv;=0A= =0A= /* arg[0] is "g", the rest is boot parameters */=0A= arcs_cmdline[0] =3D '\0';=0A= @@ -56,10 +57,17 @@=0A= =0A= mips_machgroup =3D MACH_GROUP_MOMENCO;=0A= mips_machtype =3D MACH_MOMENCO_OCELOT;=0A= +=0A= + while (*env) {=0A= + if (strncmp("gtbase", *env, 6) =3D=3D 0) {=0A= + gt64120_base =3D simple_strtol(*env + strlen("gtbase=3D"),=0A= + NULL, 16);=0A= + break;=0A= + }=0A= + *env++;=0A= + }=0A= =0A= - /* turn off the Bit Error LED, which comes on automatically=0A= - * at power-up reset */=0A= - *PLD_REG(INTCLR) =3D 0x80;=0A= + debug_vectors->printf("Booting Linux kernel...\n");=0A= =0A= /* All the boards have at least 64MiB. If there's more, we=0A= detect and register it later */=0A= Index: arch/mips/gt64120/momenco_ocelot/setup.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/setup.c,v=0A= retrieving revision 1.5.2.1=0A= diff -u -r1.5.2.1 setup.c=0A= --- arch/mips/gt64120/momenco_ocelot/setup.c 2002/02/07 01:58:06 1.5.2.1=0A= +++ arch/mips/gt64120/momenco_ocelot/setup.c 2002/02/08 21:32:29=0A= @@ -83,25 +83,9 @@=0A= =0A= static void __init setup_l3cache(unsigned long size);=0A= =0A= -void __init momenco_ocelot_setup(void)=0A= +/* setup code for a handoff from a version 1 PMON 2000 PROM */=0A= +void PMON_v1_setup()=0A= {=0A= - void (*l3func)(unsigned long)=3DKSEG1ADDR(&setup_l3cache);=0A= - unsigned int tmpword;=0A= -=0A= - board_time_init =3D gt64120_time_init;=0A= -=0A= - _machine_restart =3D momenco_ocelot_restart;=0A= - _machine_halt =3D momenco_ocelot_halt;=0A= - _machine_power_off =3D momenco_ocelot_power_off;=0A= -=0A= - /*=0A= - * initrd_start =3D (ulong)ocelot_initrd_start;=0A= - * initrd_end =3D (ulong)ocelot_initrd_start + = (ulong)ocelot_initrd_size;=0A= - * initrd_below_start_ok =3D 1;=0A= - */=0A= - rtc_ops =3D &no_rtc_ops;=0A= -=0A= -=0A= /* A wired TLB entry for the GT64120A and the serial port. The=0A= GT64120A is going to be hit on every IRQ anyway - there's=0A= absolutely no point in letting it be a random TLB entry, as=0A= @@ -122,12 +106,10 @@=0A= Ocelot PLD (CS0) 0x2c000000 0xe0020000=0A= NVRAM 0x2c800000 0xe0030000=0A= */=0A= - =0A= add_temporary_entry(ENTRYLO(0x2C000000), ENTRYLO(0x2d000000), = 0xe0020000, PM_64K);=0A= =0A= -=0A= /* Relocate the CS3/BootCS region */=0A= - GT_WRITE( GT_CS3BOOTLD_OFS, 0x2f000000 >> 21);=0A= + GT_WRITE(GT_CS3BOOTLD_OFS, 0x2f000000 >> 21);=0A= =0A= /* Relocate CS[012] */=0A= GT_WRITE(GT_CS20LD_OFS, 0x2c000000 >> 21);=0A= @@ -142,18 +124,74 @@=0A= GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x24000000);=0A= GT_WRITE(GT_PCI0_CFGADDR_OFS, 0x80000024);=0A= GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x24000001);=0A= +}=0A= =0A= - /* Relocate PCI0 I/O and Mem0 */=0A= - GT_WRITE(GT_PCI0IOLD_OFS, 0x20000000 >> 21);=0A= - GT_WRITE(GT_PCI0M0LD_OFS, 0x22000000 >> 21);=0A= +/* setup code for a handoff from a version 2 PMON 2000 PROM */=0A= +void PMON_v2_setup()=0A= +{=0A= + /* A wired TLB entry for the GT64120A and the serial port. The=0A= + GT64120A is going to be hit on every IRQ anyway - there's=0A= + absolutely no point in letting it be a random TLB entry, as=0A= + it'll just cause needless churning of the TLB. And we use=0A= + the other half for the serial port, which is just a PITA=0A= + otherwise :)=0A= =0A= - /* Relocate PCI0 Mem1 */=0A= - GT_WRITE(GT_PCI0M1LD_OFS, 0x36000000 >> 21);=0A= + Device Physical Virtual=0A= + GT64120 Internal Regs 0xf4000000 0xe0000000=0A= + UARTs (CS2) 0xfd000000 0xe0001000=0A= + */=0A= + add_wired_entry(ENTRYLO(0xf4000000), ENTRYLO(0xfD000000), 0xe0000000, = PM_4K);=0A= +=0A= + /* Also a temporary entry to let us talk to the Ocelot PLD and NVRAM=0A= + in the CS[012] region. We can't use ioremap() yet. The NVRAM=0A= + is a ST M48T37Y, which includes NVRAM, RTC, and Watchdog functions.=0A= +=0A= + Ocelot PLD (CS0) 0xfc000000 0xe0020000=0A= + NVRAM 0xfc800000 0xe0030000=0A= + */=0A= + add_temporary_entry(ENTRYLO(0xfC000000), ENTRYLO(0xfd000000), = 0xe0020000, PM_64K);=0A= +=0A= + gt64120_base =3D 0xe0000000;=0A= +}=0A= +=0A= +void __init momenco_ocelot_setup(void)=0A= +{=0A= + void (*l3func)(unsigned long)=3DKSEG1ADDR(&setup_l3cache);=0A= + unsigned int tmpword;=0A= +=0A= + board_time_init =3D gt64120_time_init;=0A= +=0A= + _machine_restart =3D momenco_ocelot_restart;=0A= + _machine_halt =3D momenco_ocelot_halt;=0A= + _machine_power_off =3D momenco_ocelot_power_off;=0A= +=0A= + /*=0A= + * initrd_start =3D (ulong)ocelot_initrd_start;=0A= + * initrd_end =3D (ulong)ocelot_initrd_start + = (ulong)ocelot_initrd_size;=0A= + * initrd_below_start_ok =3D 1;=0A= + */=0A= + rtc_ops =3D &no_rtc_ops;=0A= +=0A= + /* do handoff reconfiguration */=0A= + if (gt64120_base =3D=3D KSEG1ADDR(GT_DEF_BASE))=0A= + PMON_v1_setup();=0A= + else=0A= + PMON_v2_setup();=0A= =0A= + /* Turn off the Bit-Error LED */=0A= + OCELOT_PLD_WRITE(0x80, INTCLR);=0A= +=0A= /* Relocate all the PCI1 stuff, not that we use it */=0A= GT_WRITE(GT_PCI1IOLD_OFS, 0x30000000 >> 21);=0A= GT_WRITE(GT_PCI1M0LD_OFS, 0x32000000 >> 21);=0A= GT_WRITE(GT_PCI1M1LD_OFS, 0x34000000 >> 21);=0A= +=0A= + /* Relocate PCI0 I/O and Mem0 */=0A= + GT_WRITE(GT_PCI0IOLD_OFS, 0x20000000 >> 21);=0A= + GT_WRITE(GT_PCI0M0LD_OFS, 0x22000000 >> 21);=0A= +=0A= + /* Relocate PCI0 Mem1 */=0A= + GT_WRITE(GT_PCI0M1LD_OFS, 0x36000000 >> 21);=0A= =0A= /* For the initial programming, we assume 512MB configuration */=0A= /* Relocate the CPU's view of the RAM... */=0A= Index: drivers/mtd/devices/docprobe.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/drivers/mtd/devices/docprobe.c,v=0A= retrieving revision 1.3=0A= diff -u -r1.3 docprobe.c=0A= --- drivers/mtd/devices/docprobe.c 2001/11/05 20:15:52 1.3=0A= +++ drivers/mtd/devices/docprobe.c 2002/02/08 21:32:30=0A= @@ -88,6 +88,7 @@=0A= 0xe4000000,=0A= #elif defined(CONFIG_MOMENCO_OCELOT)=0A= 0x2f000000,=0A= + 0xff000000,=0A= #else=0A= #warning Unknown architecture for DiskOnChip. No default probe = locations defined=0A= #endif=0A= ------=_NextPart_000_0024_01C1B0AE.8B076400-- From owner-linux-mips@oss.sgi.com Fri Feb 8 14:44:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18MieO12326 for linux-mips-outgoing; Fri, 8 Feb 2002 14:44:40 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18MibA12322 for ; Fri, 8 Feb 2002 14:44:37 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g18MibR26360 for ; Fri, 8 Feb 2002 14:44:37 -0800 From: "Matthew Dharm" To: "Linux-MIPS" Subject: ANNOUNCE: GT-64240 project Date: Fri, 8 Feb 2002 14:44:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1122 Lines: 25 I wanted to publically announce that I'm now working on a port of Linux to the Momentum Computer Ocelot-G board, which uses a Gallileo/Marvell GT-64240 host bridge. I know that there is at least one other person who is/will be working on a similar board. Pooling resources will be good, especially since this chip is a total nightmare. There was some earlier discussion on this list about it -- I won't rehash the details now. Suffice to say, I have a 16550A-compatible UART, and I'm feeling really lucky about it. :) If anyone has anything to contribute/share, please let me know. Since there are going to be at least two different boards which use this chip and have linux support, getting together now will be good -- if nothing else, it will eliminate the pain of trying to merge lots of functionally-equivalent code later. Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Sat Feb 9 07:15:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g19FFDP21238 for linux-mips-outgoing; Sat, 9 Feb 2002 07:15:13 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g19FF8A21235 for ; Sat, 9 Feb 2002 07:15:08 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id D62CE843; Sat, 9 Feb 2002 16:14:46 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id E646F4291; Sat, 9 Feb 2002 16:01:55 +0100 (CET) Date: Sat, 9 Feb 2002 16:01:55 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: gcc include strangeness Message-ID: <20020209150155.GA853@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1012 Lines: 35 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i just stumbled when i tried to compile a program (bootloader) with gcc which uses varargs. I got the error that "sgidefs.h" was missing. sgidefs.h is contained in the glibc which gets included by va-mips.h from stdarg.h - I dont think this is correct as i should be able to compile programs without glibc. Shouldnt sgidefs.h or its content be included in the gcc ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --liOOAslEiF7prFVr 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 iD8DBQE8ZTnjUaz2rXW+gJcRAuTkAJ9H+sVgYOSbtXMKkXJAVyY/YcX98ACgvrws ZXWEY67msOME7XupO4kAhzE= =qKjo -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-linux-mips@oss.sgi.com Sun Feb 10 10:24:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1AIOqw20653 for linux-mips-outgoing; Sun, 10 Feb 2002 10:24:52 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1AIOV920649 for ; Sun, 10 Feb 2002 10:24:31 -0800 Received: from post.webmailer.de ([192.67.198.70]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA29833 for ; Sun, 10 Feb 2002 09:20:03 -0800 (PST) mail_from (karsten@excalibur.cologne.de) Received: from excalibur.cologne.de (p50851953.dip.t-dialin.net [80.133.25.83]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id SAA18143 for ; Sun, 10 Feb 2002 18:10:42 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16ZxbK-0000Am-00 for ; Sun, 10 Feb 2002 18:17:18 +0100 Date: Sun, 10 Feb 2002 18:17:18 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: DECstation keyboard mappings and XFree Message-ID: <20020210181718.A641@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6245 Lines: 204 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hallo everybody, I have modified the keycode remapping table in drivers/tc/lk201-remap.c to deliver PC compatible keycodes. Aim of this modification is easier use of XFree86 on DECstations (with the standard PC-keyboard map) and the possibility to use existing loadable national keymaps for i386. In theory, this should work, in practice, it does not :-(. I have encountered several problems when running the new remapping table with a standard i386 us.kmap.gz: - the "Alt Function" keys on an LK401 seem to deliver no keypress event (same behaviour with the original DECstation mapping, so this seems to be a generic problem. Does the LK401 need a particular initialization to use these keys (which do not exist on an LK201)? - When running in console mode, everything besides console switching (because of the missing ALT-keycode) and activating NumLock (keypad is always in cursor mode) works. In XFree86 the normal character keys and the main keyboard number keys work fine, but cursor keys, the Del/Insert/Pos1/End/etc. block and the numeric keyblock do not work at all or deliver wrong keycodes. I would be very grateful if somebody could give me a hint about the reason for this behaviour, the modified lk201-remap.c is attached to this mail. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. --h31gzZEtNLTqOjlF Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="lk201-remap.c" /* * PC-compatible keyboard mappings for DEC LK201/401/501 keyboards * 2002/02/09 by Karsten Merker , * based on the layout of the original lk201-remap.c written * 17.05.99 by Michael Engel (engel@unix-ag.org). * This file is subject to the terms and conditions of the GNU General * Public License, version 2. See the file "COPYING" in the main * directory of this archive for more details. * * Rationale: * * DEC US keyboards generate keycodes in the range 0x55 - 0xfb * * The (historically PC-centric) Linux keycodes have to be in the * range 0x00-0x7f, so the raw keycodes from the keyboard have to * be remapped appropriately. * * This remapping table in contrast to the original lk201-remap.c (which * numbered the keys by their position from top left to lower right) * delivers PC-compatible keycodes. * * Relocated keys (from a PC-keyboard point of view): * SysReq/ScrollLock/Pause are on F13/F14/Help * Pos1/End are on Find/Select * ESC is on Do * LeftPenguin/RightPenguin are on LeftCompose/RightCompose * Menu/RightControl are on F17/F18 * The numeric keypad has PC-like layout */ unsigned char scancodeRemap[256] = { /* ----- */ /* 0 */ 0, 0, 0, 0, /* ----- */ /* 4 */ 0, 0, 0, 0, /* ----- */ /* 8 */ 0, 0, 0, 0, /* ----- */ /* c */ 0, 0, 0, 0, /* ----- */ /* 10 */ 0, 0, 0, 0, /* ----- */ /* 14 */ 0, 0, 0, 0, /* ----- */ /* 18 */ 0, 0, 0, 0, /* ----- */ /* 1c */ 0, 0, 0, 0, /* ----- */ /* 20 */ 0, 0, 0, 0, /* ----- */ /* 24 */ 0, 0, 0, 0, /* ----- */ /* 28 */ 0, 0, 0, 0, /* ----- */ /* 2c */ 0, 0, 0, 0, /* ----- */ /* 30 */ 0, 0, 0, 0, /* ----- */ /* 34 */ 0, 0, 0, 0, /* ----- */ /* 38 */ 0, 0, 0, 0, /* ----- */ /* 3c */ 0, 0, 0, 0, /* ----- */ /* 40 */ 0, 0, 0, 0, /* ----- */ /* 44 */ 0, 0, 0, 0, /* ----- */ /* 48 */ 0, 0, 0, 0, /* ----- */ /* 4c */ 0, 0, 0, 0, /* ----- */ /* 50 */ 0, 0, 0, 0, /* ----- F1 F2 */ /* 54 */ 0, 0, 59, 60, /* ----- F3 F4 F5 */ /* 58 */ 61, 62, 63, 0, /* ----- */ /* 5c */ 0, 0, 0, 0, /* ----- */ /* 60 */ 0, 0, 0, 0, /* ----- F6 F7 F8 F9 */ /* 64 */ 64, 65, 66, 67, /* ----- F10 */ /* 68 */ 68, 0, 0, 0, /* ----- */ /* 6c */ 0, 0, 0, 0, /* ----- F11 F12 F13/SYSREQ */ /* 70 */ 0, 87, 88, 99, /* ----- F14/SCR.LOCK */ /* 74 */ 70, 0, 0, 0, /* ----- */ /* 78 */ 0, 0, 0, 0, /* ----- HELP/PAUSE DO/ESC */ /* 7c */ 119, 1, 0, 0, /* ----- F17/MENU F18/R.CTRL F19 F20 */ /* 80 */ 127, 97, 0, 0, /* ----- */ /* 84 */ 0, 0, 0, 0, /* ----- FIND/POS1 INSERT */ /* 88 */ 0, 0, 102, 110, /* ----- REMOVE SELECT/END PREV/PAGEUP NEXT/PAGEDOWN */ /* 8c */ 111, 107, 104, 109, /* ----- KP 0 */ /* 90 */ 0, 0, 82, 0, /* ----- KP . KP ENTER KP 1 KP 2 */ /* 94 */ 83, 96, 79, 80, /* ----- KP 3 KP 4 KP 5 KP 6 */ /* 98 */ 81, 75, 76, 77, /* ----- KP ,/KP + KP 7 KP 8 KP 9 */ /* 9c */ 78, 71, 72, 73, /* ----- KP -/KP+ KP F1/NUM LCK KP F2/KP / KP F3/KP * */ /* a0 */ 78, 69, 98, 55, /* ----- KP F4/KP - LEFT */ /* a4 */ 74, 0, 0, 105, /* ----- RIGHT DOWN UP SHIFT Rt */ /* a8 */ 106, 108, 103, 54, /* ----- ALT R.COMP/R.TUX SHIFT CONTROL */ /* ac */ 56, 126, 42, 29, /* ----- CAPS L.COMP/L.TUX ALT Rt */ /* b0 */ 58, 125, 100, 0, /* ----- */ /* b4 */ 0, 0, 0, 0, /* ----- */ /* b8 */ 0, 0, 0, 0, /* ----- BKSP RET TAB ` */ /* bc */ 14, 28, 15, 0x15, /* ----- 1 q a z */ /* c0 */ 2, 16, 30, 44, /* ----- 2 w s */ /* c4 */ 0, 3, 17, 31, /* ----- x ; Mon, 11 Feb 2002 05:52:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19824; Mon, 11 Feb 2002 13:51:47 +0100 (MET) Date: Mon, 11 Feb 2002 13:51:47 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020209150155.GA853@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 774 Lines: 23 On Sat, 9 Feb 2002, Florian Lohoff wrote: > i just stumbled when i tried to compile a program (bootloader) with > gcc which uses varargs. I got the error that "sgidefs.h" was missing. > sgidefs.h is contained in the glibc which gets included by va-mips.h > from stdarg.h - I dont think this is correct as i should be able > to compile programs without glibc. Hmm, in 2.95.3 in va-mips.h I see: /* Get definitions for _MIPS_SIM_ABI64 etc. */ #ifdef _MIPS_SIM #include #endif so you shouldn't need sgidefs.h normally. Or did something get broken for 3.x? -- + 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 Feb 11 06:53:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BErIp10011 for linux-mips-outgoing; Mon, 11 Feb 2002 06:53:18 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BEr9910008 for ; Mon, 11 Feb 2002 06:53:09 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id E0F4984C; Mon, 11 Feb 2002 14:52:46 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 253384292; Mon, 11 Feb 2002 14:53:02 +0100 (CET) Date: Mon, 11 Feb 2002 14:53:02 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211135302.GB30314@paradigm.rfc822.org> References: <20020209150155.GA853@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2318 Lines: 74 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote: > On Sat, 9 Feb 2002, Florian Lohoff wrote: >=20 > > i just stumbled when i tried to compile a program (bootloader) with > > gcc which uses varargs. I got the error that "sgidefs.h" was missing. > > sgidefs.h is contained in the glibc which gets included by va-mips.h > > from stdarg.h - I dont think this is correct as i should be able > > to compile programs without glibc. >=20 > Hmm, in 2.95.3 in va-mips.h I see:=20 >=20 > /* Get definitions for _MIPS_SIM_ABI64 etc. */ > #ifdef _MIPS_SIM > #include > #endif >=20 > so you shouldn't need sgidefs.h normally. Or did something get broken for > 3.x? revamp:/tmp/arcboot-0.2# make cd arclib; make all make[1]: Entering directory `/tmp/arcboot-0.2/arclib' cc -O -Werror -Wall -mno-abicalls -G 0 -fno-pic -c -o arc.o arc.c cc -O -Werror -Wall -mno-abicalls -G 0 -fno-pic -c -o stdio.o stdio.c In file included from /usr/lib/gcc-lib/mips-linux/2.95.4/include/stdarg.h:27, from stdio.h:8, from stdio.c:7: /usr/lib/gcc-lib/mips-linux/2.95.4/include/va-mips.h:89: sgidefs.h: No such file or directory make[1]: *** [stdio.o] Error 1 make[1]: Leaving directory `/tmp/arcboot-0.2/arclib' make: *** [all] Error 2 revamp:/tmp/arcboot-0.2# gcc -v Reading specs from /usr/lib/gcc-lib/mips-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) revamp:/tmp/arcboot-0.2# vi /usr/lib/gcc-lib/mips-linux/2.95.4/include/va-m= ips.h [...] 87 /* Get definitions for _MIPS_SIM_ABI64 etc. */ 88 #ifdef _MIPS_SIM 89 #include 90 #endif [...] I just saw it - I cant explain it ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --4bRzO86E/ozDv8r1 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 iD8DBQE8Z8y9Uaz2rXW+gJcRAgIGAKDePhcd7reW8Dgat1jApOHOhfDbmgCgp69G urxYbdizNiUq1X7NqkuX50I= =Cfob -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-linux-mips@oss.sgi.com Mon Feb 11 07:07:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BF7UN10310 for linux-mips-outgoing; Mon, 11 Feb 2002 07:07:30 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BF7N910303 for ; Mon, 11 Feb 2002 07:07:24 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA22256; Mon, 11 Feb 2002 15:07:08 +0100 (MET) Date: Mon, 11 Feb 2002 15:07:08 +0100 (MET) From: "Maciej W. Rozycki" To: Karsten Merker cc: linux-mips@oss.sgi.com Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: <20020210181718.A641@excalibur.cologne.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 Content-Length: 1282 Lines: 33 On Sun, 10 Feb 2002, Karsten Merker wrote: > I have modified the keycode remapping table in drivers/tc/lk201-remap.c > to deliver PC compatible keycodes. Aim of this modification is easier > use of XFree86 on DECstations (with the standard PC-keyboard map) and > the possibility to use existing loadable national keymaps for i386. > In theory, this should work, in practice, it does not :-(. Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201 keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*". Just set up your "Keyboard" section of XF86Config correctly. E.g. (completely untested): Section "Keyboard" XkbKeycodes "digital/lk(lk201)" XkbSymbols "digital/us(us)" XkbGeometry "digital/lk(lk201)" EndSection It might be nice to add these values to Xkb rules somewhere ("/usr/X11R6/lib/X11/xkb/rules/digital"?) one day, so you don't need to specify components separately for default values, but I'm not sure our XFree86 support is stable enough to consider it now. 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 Feb 11 07:15:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFFtd10469 for linux-mips-outgoing; Mon, 11 Feb 2002 07:15:55 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFFl910463 for ; Mon, 11 Feb 2002 07:15:48 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA22466; Mon, 11 Feb 2002 15:15:44 +0100 (MET) Date: Mon, 11 Feb 2002 15:15:43 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Florian Lohoff cc: linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020211135302.GB30314@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 510 Lines: 14 On Mon, 11 Feb 2002, Florian Lohoff wrote: > I just saw it - I cant explain it ... Hmm, it's "subtarget_cpp_spec" in gcc's specs that defines _MIPS_SIM. It seems should be a part of gcc indeed. It would let avoiding including the weird asm-mips/gcc/sgidefs.h header for the kernel as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Feb 11 07:20:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFK5O10583 for linux-mips-outgoing; Mon, 11 Feb 2002 07:20:05 -0800 Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFK1910580 for ; Mon, 11 Feb 2002 07:20:01 -0800 Received: from excalibur.cologne.de (pD9E40306.dip.t-dialin.net [217.228.3.6]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id PAA04904 for ; Mon, 11 Feb 2002 15:19:52 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 16aHPR-0003jW-00 for ; Mon, 11 Feb 2002 15:26:21 +0100 Date: Mon, 11 Feb 2002 15:26:21 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: DECstation keyboard mappings and XFree Message-ID: <20020211152621.A14342@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20020210181718.A641@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Feb 11, 2002 at 03:07:08PM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1447 Lines: 29 On Mon, Feb 11, 2002 at 03:07:08PM +0100, Maciej W. Rozycki wrote: > On Sun, 10 Feb 2002, Karsten Merker wrote: > > > I have modified the keycode remapping table in drivers/tc/lk201-remap.c > > to deliver PC compatible keycodes. Aim of this modification is easier > > use of XFree86 on DECstations (with the standard PC-keyboard map) and > > the possibility to use existing loadable national keymaps for i386. > > In theory, this should work, in practice, it does not :-(. > > Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that > barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201 > keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*". Because the original code does not deliver LK201 keycodes - LK201 keycodes are in the range 0x55 - 0xfb, but the kernel to my knowledge accepts only keycodes in the range 0x01 - 0x7f, so the original code already did a remapping of the LK201 raw codes (it delivered the key numbers from the top left to the downmost right keys, i.e. F1=1, F2=2, F3=3 etc.). This means that the XFree LK201 mapping did not work, and if we have to remap keycodes anyway into the range 0x01-0x7f, using a PC-compatible keymap seemed the best solution to me. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Mon Feb 11 07:27:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFRit10878 for linux-mips-outgoing; Mon, 11 Feb 2002 07:27:44 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFRc910873 for ; Mon, 11 Feb 2002 07:27:38 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 16aHQC-0000gD-00; Mon, 11 Feb 2002 15:27:08 +0100 Date: Mon, 11 Feb 2002 15:27:08 +0100 From: Johannes Stezenbach To: Florian Lohoff Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211142708.GA2577@convergence.de> Mail-Followup-To: Johannes Stezenbach , Florian Lohoff , "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020209150155.GA853@paradigm.rfc822.org> <20020211135302.GB30314@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020211135302.GB30314@paradigm.rfc822.org> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1619 Lines: 50 On Mon, Feb 11, 2002 at 02:53:02PM +0100, Florian Lohoff wrote: > On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote: > > On Sat, 9 Feb 2002, Florian Lohoff wrote: > > > > > i just stumbled when i tried to compile a program (bootloader) with > > > gcc which uses varargs. I got the error that "sgidefs.h" was missing. > > > sgidefs.h is contained in the glibc which gets included by va-mips.h > > > from stdarg.h - I dont think this is correct as i should be able > > > to compile programs without glibc. The glibc-2.2.5/FAQ says: 1.20. Which tools should I use for MIPS? {AJ} You should use the current development version of gcc 3.0 or newer from CVS. gcc 2.95.x does not work correctly on mips-linux. I'm not shure if this only applies to glibc, but the gcc-2.95.x I tried to build could not even compile a kernel because of: #ifndef __linux__ #error Use a Linux compiler or give up. #endif in linux/include/asm-mips/sgidefs.h. The gcc-3.0.3 I now use has a totally different set of predefines than gcc-2.95.x, and it seems to work. > > Hmm, in 2.95.3 in va-mips.h I see: > > > > /* Get definitions for _MIPS_SIM_ABI64 etc. */ > > #ifdef _MIPS_SIM > > #include > > #endif > > > > so you shouldn't need sgidefs.h normally. Or did something get broken for > > 3.x? sgidefs.h comes from the kernel includes. gcc-3.x does not use va-mips.h or sgidefs,h, but simply has the following in stdarg.h: #define va_start(v,l) __builtin_stdarg_start((v),l) #define va_end __builtin_va_end #define va_arg __builtin_va_arg etc. Regards, Johannes From owner-linux-mips@oss.sgi.com Mon Feb 11 07:59:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BFxlt11546 for linux-mips-outgoing; Mon, 11 Feb 2002 07:59:47 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BFxh911537 for ; Mon, 11 Feb 2002 07:59:43 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA00810 for ; Mon, 11 Feb 2002 06:55:13 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23152; Mon, 11 Feb 2002 15:49:20 +0100 (MET) Date: Mon, 11 Feb 2002 15:49:19 +0100 (MET) From: "Maciej W. Rozycki" To: Karsten Merker cc: linux-mips@oss.sgi.com Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: <20020211152621.A14342@excalibur.cologne.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 Content-Length: 1368 Lines: 29 On Mon, 11 Feb 2002, Karsten Merker wrote: > > Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that > > barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201 > > keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*". > > Because the original code does not deliver LK201 keycodes - LK201 keycodes > are in the range 0x55 - 0xfb, but the kernel to my knowledge accepts only > keycodes in the range 0x01 - 0x7f, so the original code already did a > remapping of the LK201 raw codes (it delivered the key numbers from the > top left to the downmost right keys, i.e. F1=1, F2=2, F3=3 etc.). This may be reasonable for the pc_keyb.c driver, but we don't use it, do we? > This means that the XFree LK201 mapping did not work, and if we have > to remap keycodes anyway into the range 0x01-0x7f, using a PC-compatible > keymap seemed the best solution to me. Then the kernel needs to be fixed -- raw scancodes should be passed as is and the translation should be done in kbd_translate(). I'm adding it to my to-do list (to be resolved soon, hopefully, together with the annoying indefinite timeout when no keyboard is attached). -- + 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 Feb 11 08:08:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BG8U411929 for linux-mips-outgoing; Mon, 11 Feb 2002 08:08:30 -0800 Received: from aretha.informatik.uni-siegen.de (aretha.informatik.Uni-Siegen.DE [141.99.92.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BG87911925 for ; Mon, 11 Feb 2002 08:08:23 -0800 Received: (from engel@localhost) by aretha.informatik.uni-siegen.de (Mailhost) id QAA214284; Mon, 11 Feb 2002 16:07:15 +0100 (MET) Date: Mon, 11 Feb 2002 16:07:15 +0100 From: Michael Engel To: "Maciej W. Rozycki" Cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: DECstation keyboard mappings and XFree Message-ID: <20020211160715.A214199@aretha.informatik.uni-siegen.de> References: <20020211152621.A14342@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Feb 11, 2002 at 03:49:19PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1677 Lines: 40 Hi, On Mon, Feb 11, 2002 at 03:49:19PM +0100, Maciej W. Rozycki wrote: > On Mon, 11 Feb 2002, Karsten Merker wrote: > > > > Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that > > > barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201 > > > keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*". > > > > Because the original code does not deliver LK201 keycodes - LK201 keycodes > > are in the range 0x55 - 0xfb, but the kernel to my knowledge accepts only > > keycodes in the range 0x01 - 0x7f, so the original code already did a > > remapping of the LK201 raw codes (it delivered the key numbers from the > > top left to the downmost right keys, i.e. F1=1, F2=2, F3=3 etc.). > > This may be reasonable for the pc_keyb.c driver, but we don't use it, do > we? Unfortunately, handle_scancode still uses the 0x80 bit internally to indicate key up transisitions (see drivers/char/keyboard.c). So IMHO only keycodes <= 0x7f are usable. Same problem with Access.Bus LK501 keyboards, btw. > > This means that the XFree LK201 mapping did not work, and if we have > > to remap keycodes anyway into the range 0x01-0x7f, using a PC-compatible > > keymap seemed the best solution to me. > > Then the kernel needs to be fixed -- raw scancodes should be passed as is > and the translation should be done in kbd_translate(). I'm adding it to > my to-do list (to be resolved soon, hopefully, together with the annoying > indefinite timeout when no keyboard is attached). Hmmm, this change would probably affect a lot of the console infrastructure. I'm still waiting for the promised rewritten console code in 2.5 ;-). regards, Michael From owner-linux-mips@oss.sgi.com Mon Feb 11 08:08:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BG8s611944 for linux-mips-outgoing; Mon, 11 Feb 2002 08:08:54 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BG8l911941 for ; Mon, 11 Feb 2002 08:08:48 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA21003; Mon, 11 Feb 2002 16:07:00 +0100 (MET) Date: Mon, 11 Feb 2002 16:07:00 +0100 (MET) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Karsten Merker , Linux/MIPS Development Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1937 Lines: 43 On Mon, 11 Feb 2002, Maciej W. Rozycki wrote: > On Mon, 11 Feb 2002, Karsten Merker wrote: > > > Hmm, why do you need (sh*tty) PC-compatible keycodes for a keaboard that > > > barely resembles a PC keyboard? AFAIK, XFree86 has appropriate LK201 > > > keymaps -- see "/usr/X11R6/lib/X11/xkb/*/digital/*". > > > > Because the original code does not deliver LK201 keycodes - LK201 keycodes > > are in the range 0x55 - 0xfb, but the kernel to my knowledge accepts only > > keycodes in the range 0x01 - 0x7f, so the original code already did a > > remapping of the LK201 raw codes (it delivered the key numbers from the > > top left to the downmost right keys, i.e. F1=1, F2=2, F3=3 etc.). > > This may be reasonable for the pc_keyb.c driver, but we don't use it, do > we? > > > This means that the XFree LK201 mapping did not work, and if we have > > to remap keycodes anyway into the range 0x01-0x7f, using a PC-compatible > > keymap seemed the best solution to me. > > Then the kernel needs to be fixed -- raw scancodes should be passed as is > and the translation should be done in kbd_translate(). I'm adding it to > my to-do list (to be resolved soon, hopefully, together with the annoying > indefinite timeout when no keyboard is attached). The keyboard mid-layer assumes keycodes are in the range 1-127 (with some minor hack 0 can be made to work, cfr. Amiga keboards). Bit 7 is used to differentiate between up and down events. This means you cannot get keyboards with more than 128 keys to work (e.g. some specialized keyboards for old workstations). Perhaps it's different in the new input layer. I don't know. 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 Feb 11 08:11:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGB7212086 for linux-mips-outgoing; Mon, 11 Feb 2002 08:11:07 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGAv912082 for ; Mon, 11 Feb 2002 08:10:57 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23750; Mon, 11 Feb 2002 16:10:37 +0100 (MET) Date: Mon, 11 Feb 2002 16:10:34 +0100 (MET) From: "Maciej W. Rozycki" To: Johannes Stezenbach cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020211142708.GA2577@convergence.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 Content-Length: 1741 Lines: 45 On Mon, 11 Feb 2002, Johannes Stezenbach wrote: > The glibc-2.2.5/FAQ says: > 1.20. Which tools should I use for MIPS? > > {AJ} You should use the current development version of gcc 3.0 or newer from > CVS. gcc 2.95.x does not work correctly on mips-linux. Is gcc 3.x already stable enough to be used by people not directly involved in gcc development? More specifically for MIPS/Linux and i386/Linux, for both the kernel and the userland? I'm told it is not. > I'm not shure if this only applies to glibc, but the > gcc-2.95.x I tried to build could not even compile a kernel > because of: > #ifndef __linux__ > #error Use a Linux compiler or give up. > #endif > in linux/include/asm-mips/sgidefs.h. The gcc-3.0.3 I now use > has a totally different set of predefines than gcc-2.95.x, and > it seems to work. Gcc 2.95.x as distributed certainly doesn't work. With a set of patches it appears rock solid. For MIPS/Linux I'm using it for over two years for both the kernel and the userland. The last time I found bug and needed to apply a fix to gcc 2.95.3 for MIPS/Linux was in April 2001. With gcc 2.95.3 if I spot a weird behaviour, I'm pretty confident it's a bug in the kernel or in user code, and not the compiler generating bad code. > gcc-3.x does not use va-mips.h or sgidefs,h, but simply > has the following in stdarg.h: > #define va_start(v,l) __builtin_stdarg_start((v),l) > #define va_end __builtin_va_end > #define va_arg __builtin_va_arg > etc. Thanks for the info. -- + 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 Feb 11 08:36:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGaTi13005 for linux-mips-outgoing; Mon, 11 Feb 2002 08:36:29 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGaN913002 for ; Mon, 11 Feb 2002 08:36:26 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24431; Mon, 11 Feb 2002 16:36:13 +0100 (MET) Date: Mon, 11 Feb 2002 16:36:13 +0100 (MET) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Karsten Merker , Linux/MIPS Development Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 818 Lines: 19 On Mon, 11 Feb 2002, Geert Uytterhoeven wrote: > The keyboard mid-layer assumes keycodes are in the range 1-127 (with some minor > hack 0 can be made to work, cfr. Amiga keboards). Bit 7 is used to > differentiate between up and down events. This means you cannot get keyboards > with more than 128 keys to work (e.g. some specialized keyboards for old > workstations). But the raw scancode should be passed as is. A brief look at drivers/char/keyboard.c suggests it's doable without breaking anything. Keycodes seem to be limited to 1 - 127, but it's not a problem -- LK keyboards do not have that many keys. -- + 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 Feb 11 08:41:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGfLx13099 for linux-mips-outgoing; Mon, 11 Feb 2002 08:41:21 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGf9913094 for ; Mon, 11 Feb 2002 08:41:10 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24488; Mon, 11 Feb 2002 16:39:27 +0100 (MET) Date: Mon, 11 Feb 2002 16:39:27 +0100 (MET) From: "Maciej W. Rozycki" To: Michael Engel cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: <20020211160715.A214199@aretha.informatik.uni-siegen.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 Content-Length: 782 Lines: 19 On Mon, 11 Feb 2002, Michael Engel wrote: > > Then the kernel needs to be fixed -- raw scancodes should be passed as is > > and the translation should be done in kbd_translate(). I'm adding it to > > my to-do list (to be resolved soon, hopefully, together with the annoying > > indefinite timeout when no keyboard is attached). > > Hmmm, this change would probably affect a lot of the console > infrastructure. I'm still waiting for the promised rewritten console > code in 2.5 ;-). Not at all. There is only a small bug that needs to be fixed in drivers/char/keyboard.c. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Feb 11 08:53:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGrTw13288 for linux-mips-outgoing; Mon, 11 Feb 2002 08:53:29 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGrO913285 for ; Mon, 11 Feb 2002 08:53:24 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id E8A03836; Mon, 11 Feb 2002 16:53:02 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id BC3EB4292; Mon, 11 Feb 2002 16:37:32 +0100 (CET) Date: Mon, 11 Feb 2002 16:37:32 +0100 From: Florian Lohoff To: Johannes Stezenbach , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211153732.GA31248@paradigm.rfc822.org> References: <20020209150155.GA853@paradigm.rfc822.org> <20020211135302.GB30314@paradigm.rfc822.org> <20020211142708.GA2577@convergence.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20020211142708.GA2577@convergence.de> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1175 Lines: 40 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote: >=20 > The glibc-2.2.5/FAQ says: > 1.20. Which tools should I use for MIPS? >=20 > {AJ} You should use the current development version of gcc 3.0 or newer= from > CVS. gcc 2.95.x does not work correctly on mips-linux. >=20 Its not about gcc development but rather keeping a distribution in sync. All Debian archs try to use the same compiler which is currently 2.95.4 which we are happy with right now - Except some minor issues breaking 2-3 Packages ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --d6Gm4EdcadzBjdND 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 iD8DBQE8Z+U8Uaz2rXW+gJcRAqa2AJ0TKnxZ/GCWuKkVmT4SFsJo5OnNqACcCSfU U9OAznrWIVqq8V8tvuEFjj0= =zSgo -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-linux-mips@oss.sgi.com Mon Feb 11 08:58:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BGwOS13471 for linux-mips-outgoing; Mon, 11 Feb 2002 08:58:24 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BGvv913465 for ; Mon, 11 Feb 2002 08:57:57 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA23298 for ; Mon, 11 Feb 2002 07:53:27 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24645; Mon, 11 Feb 2002 16:45:54 +0100 (MET) Date: Mon, 11 Feb 2002 16:45:54 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.17: The second mb() rework (final) Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5979 Lines: 239 Ralf, I haven't seen any objections. Could you please apply it? 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-5 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 Mon Feb 4 00:07:13 2002 @@ -384,6 +384,12 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" -o \ + "$CONFIG_CPU_TX39XX" = "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 Mon Feb 4 02:10:33 2002 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,57 @@ 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" \ + "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 Feb 11 09:29:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BHTEA13946 for linux-mips-outgoing; Mon, 11 Feb 2002 09:29:14 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BHT9913943 for ; Mon, 11 Feb 2002 09:29:09 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 16aJJs-0000nH-00; Mon, 11 Feb 2002 17:28:44 +0100 Date: Mon, 11 Feb 2002 17:28:44 +0100 From: Johannes Stezenbach To: "Maciej W. Rozycki" Cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211162844.GD2918@convergence.de> Mail-Followup-To: Johannes Stezenbach , "Maciej W. Rozycki" , Florian Lohoff , linux-mips@oss.sgi.com References: <20020211142708.GA2577@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 915 Lines: 24 On Mon, Feb 11, 2002 at 04:10:34PM +0100, Maciej W. Rozycki wrote: > > Is gcc 3.x already stable enough to be used by people not directly > involved in gcc development? More specifically for MIPS/Linux and > i386/Linux, for both the kernel and the userland? I'm told it is not. I'm reading about gcc 3.x code generation bugs every now and then, but so far I did not hit any of them. I would prefer gcc 2.95.x though, if I only could get it to work on MIPS. > Gcc 2.95.x as distributed certainly doesn't work. With a set of patches > it appears rock solid. For MIPS/Linux I'm using it for over two years for > both the kernel and the userland. The last time I found bug and needed to > apply a fix to gcc 2.95.3 for MIPS/Linux was in April 2001. I would certainly be interested in getting my hands on those patches. Do you mind if I ask why they did not go into gcc-2_95-branch CVS? Regards, Johannes From owner-linux-mips@oss.sgi.com Mon Feb 11 09:53:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BHrbW15206 for linux-mips-outgoing; Mon, 11 Feb 2002 09:53:37 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BHrY915197 for ; Mon, 11 Feb 2002 09:53:34 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 16aJhl-0000rU-00; Mon, 11 Feb 2002 17:53:25 +0100 Date: Mon, 11 Feb 2002 17:53:25 +0100 From: Johannes Stezenbach To: Florian Lohoff Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211165325.GB3261@convergence.de> Mail-Followup-To: Johannes Stezenbach , Florian Lohoff , "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020209150155.GA853@paradigm.rfc822.org> <20020211135302.GB30314@paradigm.rfc822.org> <20020211142708.GA2577@convergence.de> <20020211153732.GA31248@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020211153732.GA31248@paradigm.rfc822.org> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 761 Lines: 22 On Mon, Feb 11, 2002 at 04:37:32PM +0100, Florian Lohoff wrote: > On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote: > > > > The glibc-2.2.5/FAQ says: > > 1.20. Which tools should I use for MIPS? > > > > {AJ} You should use the current development version of gcc 3.0 or newer from > > CVS. gcc 2.95.x does not work correctly on mips-linux. > > > > Its not about gcc development but rather keeping a distribution in > sync. All Debian archs try to use the same compiler which is currently > 2.95.4 which we are happy with right now - Except some minor issues > breaking 2-3 Packages ... So does this mean that Debian's gcc 2.95.4 works on MIPS? Does it include patches which are not in CVS (gcc-2_95-branch)? Regards, Johannes From owner-linux-mips@oss.sgi.com Mon Feb 11 10:06:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BI6tl07215 for linux-mips-outgoing; Mon, 11 Feb 2002 10:06:55 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BI6j907212 for ; Mon, 11 Feb 2002 10:06:48 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA26492; Mon, 11 Feb 2002 18:06:35 +0100 (MET) Date: Mon, 11 Feb 2002 18:06:34 +0100 (MET) From: "Maciej W. Rozycki" To: Johannes Stezenbach cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020211162844.GD2918@convergence.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 Content-Length: 997 Lines: 25 On Mon, 11 Feb 2002, Johannes Stezenbach wrote: > I would certainly be interested in getting my hands on those > patches. Do you mind if I ask why they did not go into > gcc-2_95-branch CVS? RPM packages are available at my site -- "ftp://ftp.ds2.pg.gda.pl/pub/macro/". They used to be recommended tools for glibc 2.2 for MIPS/Linux before gcc 3.0 was released. As to why they did not go into the CVS? Well, I wasn't aware gcc 2.95.x was maintained until after 2.95.3 was released (but patches that were relevant either went in to 2.96 or were rejected). And now we have 3.x. If 2.95.x is still maintained and you feel the patches would be useful for inclusion, feel free to commit them. The change log in the spec file contains descriptions of the purpose of every patch. 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 Feb 11 10:08:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BI8ag07288 for linux-mips-outgoing; Mon, 11 Feb 2002 10:08:36 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BI8V907282 for ; Mon, 11 Feb 2002 10:08:31 -0800 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 16aJwL-0005gu-00; Mon, 11 Feb 2002 18:08:29 +0100 Date: Mon, 11 Feb 2002 18:08:29 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211180829.A21744@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020209150155.GA853@paradigm.rfc822.org> <20020211135302.GB30314@paradigm.rfc822.org> <20020211142708.GA2577@convergence.de> <20020211153732.GA31248@paradigm.rfc822.org> <20020211165325.GB3261@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020211165325.GB3261@convergence.de>; from js@convergence.de on Mon, Feb 11, 2002 at 05:53:25PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 976 Lines: 23 On Mon, Feb 11, 2002 at 05:53:25PM +0100, Johannes Stezenbach wrote: > On Mon, Feb 11, 2002 at 04:37:32PM +0100, Florian Lohoff wrote: > > On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote: > > > > > > The glibc-2.2.5/FAQ says: > > > 1.20. Which tools should I use for MIPS? > > > > > > {AJ} You should use the current development version of gcc 3.0 or newer from > > > CVS. gcc 2.95.x does not work correctly on mips-linux. > > > > > > > Its not about gcc development but rather keeping a distribution in > > sync. All Debian archs try to use the same compiler which is currently > > 2.95.4 which we are happy with right now - Except some minor issues > > breaking 2-3 Packages ... > > So does this mean that Debian's gcc 2.95.4 works on MIPS? The whole distribution is compiled with 2.95.4. > Does it include patches which are not in CVS (gcc-2_95-branch)? Yes. See the debian/patches directory after unpacking the source-package. -- Guido From owner-linux-mips@oss.sgi.com Mon Feb 11 10:18:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BIIF607492 for linux-mips-outgoing; Mon, 11 Feb 2002 10:18:15 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BIIB907488 for ; Mon, 11 Feb 2002 10:18:11 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA28413 for ; Mon, 11 Feb 2002 09:13:41 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA26492; Mon, 11 Feb 2002 18:06:35 +0100 (MET) Date: Mon, 11 Feb 2002 18:06:34 +0100 (MET) From: "Maciej W. Rozycki" To: Johannes Stezenbach cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020211162844.GD2918@convergence.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 Content-Length: 997 Lines: 25 On Mon, 11 Feb 2002, Johannes Stezenbach wrote: > I would certainly be interested in getting my hands on those > patches. Do you mind if I ask why they did not go into > gcc-2_95-branch CVS? RPM packages are available at my site -- "ftp://ftp.ds2.pg.gda.pl/pub/macro/". They used to be recommended tools for glibc 2.2 for MIPS/Linux before gcc 3.0 was released. As to why they did not go into the CVS? Well, I wasn't aware gcc 2.95.x was maintained until after 2.95.3 was released (but patches that were relevant either went in to 2.96 or were rejected). And now we have 3.x. If 2.95.x is still maintained and you feel the patches would be useful for inclusion, feel free to commit them. The change log in the spec file contains descriptions of the purpose of every patch. 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 Feb 11 12:23:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BKNe310318 for linux-mips-outgoing; Mon, 11 Feb 2002 12:23:40 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BKNA910310 for ; Mon, 11 Feb 2002 12:23:10 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1BJMZR10170; Mon, 11 Feb 2002 11:22:35 -0800 From: "Matthew Dharm" To: "Maciej W. Rozycki" , "Ralf Baechle" Cc: , Subject: RE: [patch] linux 2.4.17: The second mb() rework (final) Date: Mon, 11 Feb 2002 11:22:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7168 Lines: 281 My only comment about this is: Aren't there more processors that have sync? I thought the RM7000 (PMC-Sierra) did too... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Maciej W. Rozycki > Sent: Monday, February 11, 2002 7:46 AM > To: Ralf Baechle > Cc: linux-mips@fnet.fr; linux-mips@oss.sgi.com > Subject: [patch] linux 2.4.17: The second mb() rework (final) > > > Ralf, > > I haven't seen any objections. Could you please apply it? > > 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-5 > 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 Mon > Feb 4 00:07:13 2002 > @@ -384,6 +384,12 @@ else > fi > fi > fi > +if [ "$CONFIG_CPU_R3000" = "y" -o \ > + "$CONFIG_CPU_TX39XX" = "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 > Mon Feb 4 02:10:33 2002 > @@ -18,9 +18,12 @@ > > #include > #include > -#include > + > #include > > +#include > +#include > + > __asm__ ( > ".macro\t__sti\n\t" > ".set\tpush\n\t" > @@ -166,32 +169,57 @@ 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" \ > + "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 Feb 11 12:27:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BKRbS10679 for linux-mips-outgoing; Mon, 11 Feb 2002 12:27:37 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BKRW910669 for ; Mon, 11 Feb 2002 12:27:32 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g1BJQCn4010977; Mon, 11 Feb 2002 11:26:12 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g1BJQA5C010973; Mon, 11 Feb 2002 11:26:11 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 11 Feb 2002 11:26:10 -0800 (PST) From: James Simmons To: Geert Uytterhoeven cc: "Maciej W. Rozycki" , Karsten Merker , Linux/MIPS Development Subject: Re: DECstation keyboard mappings and XFree In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1450 Lines: 42 > > Then the kernel needs to be fixed -- raw scancodes should be passed as is > > and the translation should be done in kbd_translate(). I'm adding it to > > my to-do list (to be resolved soon, hopefully, together with the annoying > > indefinite timeout when no keyboard is attached). > > The keyboard mid-layer assumes keycodes are in the range 1-127 (with some minor > hack 0 can be made to work, cfr. Amiga keboards). Bit 7 is used to > differentiate between up and down events. This means you cannot get keyboards > with more than 128 keys to work (e.g. some specialized keyboards for old > workstations). > > Perhaps it's different in the new input layer. I don't know. With the input layer the below is translated to what the console system wants. struct input_event { struct timeval time; unsigned short type; unsigned short code; unsigned int value; }; The type field tells us if it is a key or mouse movement etc. The code field is the value of the key. For example if you press the A key you would get KEY_A. Now buttons and keys are considered the same thing. Because of this their is a range for keys and a range for buttons. At present you can have up to 255 types of keys. For buttons and keys you can have 0x1ff buttons. Here the value field represents the states the key press can be in: 0: The key has been released. 1: The key has been pressed. 2: The key has been pressed again. From owner-linux-mips@oss.sgi.com Mon Feb 11 13:10:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BLAl512189 for linux-mips-outgoing; Mon, 11 Feb 2002 13:10:47 -0800 Received: from dea.linux-mips.net (a1as09-p62.stg.tli.de [195.252.189.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BLAd912186 for ; Mon, 11 Feb 2002 13:10:42 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1ABBZX12654; Sun, 10 Feb 2002 12:11:35 +0100 Date: Sun, 10 Feb 2002 12:11:34 +0100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020210121134.B2018@dea.linux-mips.net> References: <20020209150155.GA853@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: <20020209150155.GA853@paradigm.rfc822.org>; from flo@rfc822.org on Sat, Feb 09, 2002 at 04:01:55PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 696 Lines: 16 On Sat, Feb 09, 2002 at 04:01:55PM +0100, Florian Lohoff wrote: > i just stumbled when i tried to compile a program (bootloader) with > gcc which uses varargs. I got the error that "sgidefs.h" was missing. > sgidefs.h is contained in the glibc which gets included by va-mips.h > from stdarg.h - I dont think this is correct as i should be able > to compile programs without glibc. > > Shouldnt sgidefs.h or its content be included in the gcc ? There should be a copy of sgidefs.h in /usr/include rsp. for crosscompilers in //include/sgidefs.h. However the gcc varargs stuff has been rewritten completely; the new implementation does no longer try to include sgidefs.h. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 11 15:07:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BN7IN17808 for linux-mips-outgoing; Mon, 11 Feb 2002 15:07:18 -0800 Received: from dea.linux-mips.net (a1as09-p62.stg.tli.de [195.252.189.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BN7E917805 for ; Mon, 11 Feb 2002 15:07:14 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1BM4RA05134; Mon, 11 Feb 2002 23:04:27 +0100 Date: Mon, 11 Feb 2002 23:04:27 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211230427.D4623@dea.linux-mips.net> References: <20020209150155.GA853@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Feb 11, 2002 at 01:51:47PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 674 Lines: 21 On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote: > > i just stumbled when i tried to compile a program (bootloader) with > > gcc which uses varargs. I got the error that "sgidefs.h" was missing. > > sgidefs.h is contained in the glibc which gets included by va-mips.h > > from stdarg.h - I dont think this is correct as i should be able > > to compile programs without glibc. > > Hmm, in 2.95.3 in va-mips.h I see: > > /* Get definitions for _MIPS_SIM_ABI64 etc. */ > #ifdef _MIPS_SIM > #include > #endif > > so you shouldn't need sgidefs.h normally. Or did something get broken for > 3.x? Gcc is supposed to define _MIPS_SIM. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 11 15:10:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNASG17914 for linux-mips-outgoing; Mon, 11 Feb 2002 15:10:28 -0800 Received: from dea.linux-mips.net (a1as09-p62.stg.tli.de [195.252.189.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNAO917907 for ; Mon, 11 Feb 2002 15:10:25 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1BM7cX05176; Mon, 11 Feb 2002 23:07:38 +0100 Date: Mon, 11 Feb 2002 23:07:38 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Johannes Stezenbach , Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211230738.E4623@dea.linux-mips.net> References: <20020211142708.GA2577@convergence.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, Feb 11, 2002 at 04:10:34PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 372 Lines: 10 On Mon, Feb 11, 2002 at 04:10:34PM +0100, Maciej W. Rozycki wrote: > Is gcc 3.x already stable enough to be used by people not directly > involved in gcc development? More specifically for MIPS/Linux and > i386/Linux, for both the kernel and the userland? I'm told it is not. >From the reports I'm gathering that we should ignore 3.0 and directly go for 3.1. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 11 15:22:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1BNMjI18900 for linux-mips-outgoing; Mon, 11 Feb 2002 15:22:45 -0800 Received: from dea.linux-mips.net (a1as09-p62.stg.tli.de [195.252.189.62]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1BNMe918896 for ; Mon, 11 Feb 2002 15:22:40 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1BMK1U05333; Mon, 11 Feb 2002 23:20:01 +0100 Date: Mon, 11 Feb 2002 23:20:01 +0100 From: Ralf Baechle To: Johannes Stezenbach Cc: "Maciej W. Rozycki" , Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness Message-ID: <20020211232001.G4623@dea.linux-mips.net> References: <20020211142708.GA2577@convergence.de> <20020211162844.GD2918@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020211162844.GD2918@convergence.de>; from js@convergence.de on Mon, Feb 11, 2002 at 05:28:44PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 15 On Mon, Feb 11, 2002 at 05:28:44PM +0100, Johannes Stezenbach wrote: > > Is gcc 3.x already stable enough to be used by people not directly > > involved in gcc development? More specifically for MIPS/Linux and > > i386/Linux, for both the kernel and the userland? I'm told it is not. > > I'm reading about gcc 3.x code generation bugs every now and then, > but so far I did not hit any of them. I've fixed several kernel bugs that got triggered by building with 3.0. We've got an a piece of inline assembler where a constraint gets ignored by 3.0 resulting in bad code. Add slow compilation and slow code. 3.0? No way. Yet. Ralf From owner-linux-mips@oss.sgi.com Mon Feb 11 19:00:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1C302C23164 for linux-mips-outgoing; Mon, 11 Feb 2002 19:00:02 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1C2x3923115 for ; Mon, 11 Feb 2002 18:59:04 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 12 Feb 2002 01:59:03 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 AB49FB46D; Tue, 12 Feb 2002 10:59:01 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA41913; Tue, 12 Feb 2002 10:59:01 +0900 (JST) Date: Tue, 12 Feb 2002 11:03:33 +0900 (JST) Message-Id: <20020212.110333.41627061.nemoto@toshiba-tops.co.jp> To: hjl@lucon.org Cc: linux-mips@oss.sgi.com Subject: Re: gcc-2.96-99 optimization bug? From: Atsushi Nemoto In-Reply-To: <20020208103047.A6079@lucon.org> References: <20020208.193731.48536791.nemoto@toshiba-tops.co.jp> <20020208103047.A6079@lucon.org> 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.1 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 Content-Length: 273 Lines: 8 >>>>> On Fri, 8 Feb 2002 10:30:47 -0800, "H . J . Lu" said: hjl> gcc 3.1 seems fine. No one is working on gcc 2.96. I am working hjl> on a new Linuxx/mips which will use gcc 3.1. Thank you. I will wait for your new package and try it. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Feb 12 04:41:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CCfjK30130 for linux-mips-outgoing; Tue, 12 Feb 2002 04:41:45 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CCfQ930125 for ; Tue, 12 Feb 2002 04:41:27 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA17975; Tue, 12 Feb 2002 12:41:02 +0100 (MET) Date: Tue, 12 Feb 2002 12:41:01 +0100 (MET) From: "Maciej W. Rozycki" To: Matthew Dharm cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: RE: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 478 Lines: 13 On Mon, 11 Feb 2002, Matthew Dharm wrote: > Aren't there more processors that have sync? I thought the RM7000 > (PMC-Sierra) did too... Obviously there are as "sync" is standard for MIPS II and above. That's why only CONFIG_CPU_R3000 and CONFIG_CPU_TX39XX disable "sync". -- + 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 Feb 12 04:50:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CCo3630240 for linux-mips-outgoing; Tue, 12 Feb 2002 04:50:03 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CCnk930234; Tue, 12 Feb 2002 04:49:47 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA18197; Tue, 12 Feb 2002 12:49:30 +0100 (MET) Date: Tue, 12 Feb 2002 12:49:29 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Florian Lohoff , linux-mips@oss.sgi.com Subject: Re: gcc include strangeness In-Reply-To: <20020210121134.B2018@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 784 Lines: 21 On Sun, 10 Feb 2002, Ralf Baechle wrote: > > Shouldnt sgidefs.h or its content be included in the gcc ? > > There should be a copy of sgidefs.h in /usr/include rsp. for crosscompilers > in //include/sgidefs.h. However the gcc varargs stuff That file is part of libc, not gcc. OTOH, gcc when configured for "mipsel-linux" is allowed to assume glibc is available. So there is no need to migrate the file after all. > has been rewritten completely; the new implementation does no longer try > to include sgidefs.h. That's fine but for 2.95.x the issue exists. -- + 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 Feb 12 05:01:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CD1Ms30509 for linux-mips-outgoing; Tue, 12 Feb 2002 05:01:22 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CD1J930506 for ; Tue, 12 Feb 2002 05:01:20 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA18097; Tue, 12 Feb 2002 04:01:13 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA28977; Tue, 12 Feb 2002 04:01:09 -0800 (PST) Message-ID: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Matthew Dharm" Cc: "Ralf Baechle" , , References: Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) Date: Tue, 12 Feb 2002 13:02:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 532 Lines: 15 From: "Maciej W. Rozycki" : > On Mon, 11 Feb 2002, Matthew Dharm wrote: > > > Aren't there more processors that have sync? I thought the RM7000 > > (PMC-Sierra) did too... > > Obviously there are as "sync" is standard for MIPS II and above. That's > why only CONFIG_CPU_R3000 and CONFIG_CPU_TX39XX disable "sync". According to the (rather old) Tx39xx specs at my disposal, those parts should also support the SYNC instruction. Does anyone know for a fact that some of them do not? Kevin K. From owner-linux-mips@oss.sgi.com Tue Feb 12 05:48:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CDmsW31695 for linux-mips-outgoing; Tue, 12 Feb 2002 05:48:54 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CDmh931692 for ; Tue, 12 Feb 2002 05:48:47 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19778; Tue, 12 Feb 2002 13:45:22 +0100 (MET) Date: Tue, 12 Feb 2002 13:45:21 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Matthew Dharm , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 974 Lines: 21 On Tue, 12 Feb 2002, Kevin D. Kissell wrote: > > Obviously there are as "sync" is standard for MIPS II and above. That's > > why only CONFIG_CPU_R3000 and CONFIG_CPU_TX39XX disable "sync". > > According to the (rather old) Tx39xx specs at my disposal, > those parts should also support the SYNC instruction. Does > anyone know for a fact that some of them do not? I set these values according to what I found in arch/mips/setup.c -- Tx39xx are marked as MIPS_CPU_ISA_I, but obviously if they still implement "sync" as an extension they should be marked to enable the code that uses it. The patch should be applied as is anyway -- until it's clear if all members of the Tx39xx family implement "sync", it's better to leave their configuration in the current state. -- + 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 Feb 12 05:57:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CDvSW31873 for linux-mips-outgoing; Tue, 12 Feb 2002 05:57:28 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CDvP931869 for ; Tue, 12 Feb 2002 05:57:25 -0800 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 EAA07047 for ; Tue, 12 Feb 2002 04:57:11 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19778; Tue, 12 Feb 2002 13:45:22 +0100 (MET) Date: Tue, 12 Feb 2002 13:45:21 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Matthew Dharm , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 974 Lines: 21 On Tue, 12 Feb 2002, Kevin D. Kissell wrote: > > Obviously there are as "sync" is standard for MIPS II and above. That's > > why only CONFIG_CPU_R3000 and CONFIG_CPU_TX39XX disable "sync". > > According to the (rather old) Tx39xx specs at my disposal, > those parts should also support the SYNC instruction. Does > anyone know for a fact that some of them do not? I set these values according to what I found in arch/mips/setup.c -- Tx39xx are marked as MIPS_CPU_ISA_I, but obviously if they still implement "sync" as an extension they should be marked to enable the code that uses it. The patch should be applied as is anyway -- until it's clear if all members of the Tx39xx family implement "sync", it's better to leave their configuration in the current state. -- + 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 Feb 12 08:55:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CGtNp12219 for linux-mips-outgoing; Tue, 12 Feb 2002 08:55:23 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CGtB912215; Tue, 12 Feb 2002 08:55:11 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g1CFt5400907; Tue, 12 Feb 2002 15:55:07 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15465.15062.840707.525971@gladsmuir.algor.co.uk> Date: Tue, 12 Feb 2002 15:55:02 +0000 To: linux-mips@oss.sgi.com Cc: Johannes Stezenbach , nigel@algor.co.uk, "Hartvig Ekner \"Maciej W. Rozycki\"" , Florian Lohoff , Ralf Baechle Subject: Re: gcc include strangeness In-Reply-To: <20020211232001.G4623@dea.linux-mips.net> References: <20020211142708.GA2577@convergence.de> <20020211162844.GD2918@convergence.de> <20020211232001.G4623@dea.linux-mips.net> 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1CGtC912216 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3365 Lines: 74 I've been keeping quiet through all this, but perhaps I should speak up. Algorithmics maintains a GNU toolchain for embedded systems and supplies it bundled with support and a basic run-time system as our product SDE-MIPS. >From version 5.0 (just gone into beta) we are configuring and testing the compiler/assembler/object tools for Linux use. We always publish the GNU sources used to build SDE-MIPS on our web-site, but we are currently leaning towards going further and putting binary RPMs of the Linux toolchain out for free download - so those of you who want can just use it. The upside of this is that we have the resource and skill (and it looks like we'll be able to get enough support/development funding) to maintain a Linux/MIPS compiler. It would be a good thing for the Linux/MIPS community if compiler bugs and shortcomings got fixed on a fairly stable base, instead of relying on pick-your-version folklore. We should also be able to get funding to do things like fixing support for SGI n32/n64 code-generation conventions. Our compiler already has support for pretty much every wrinkle of any MIPS instruction set anywhere, and command-line-selectable machine descriptions for many different MIPS pipelines. The downside: our development process is not currently very Linux-shaped. We "release late, release rarely". In providing a stable compiler for embedded use we have found it easier to avoid the bleeding edge of GCC. We've found it necessary to make bold changes in "machine-independent" code - GCC is a wonderful multi-target compiler, but it's x86 (PPC a distant second) which is routinely tested. The leading edge is a fertile breeding ground of bugs for minor architectures. And more: our v5.0 compiler's ancestor was a 2.96 release from Cygnus' internal development tree, provided to MIPS Technologies in the fall of 2000. We picked it up because it had work MIPS had already funded, and some valuable multiple-issue machine description features which didn't make it into 3.0. But it has taken a long time to make sure the new compiler is as well-tuned and reliable as the EGCS 1.1-based compiler it replaced, and the 2.96-derived compiler is only now shipping as part of a beta release. So now we have numerous patches, many of them not in officially "MIPS machine-dependent" code, against an 18-months old and slightly strange version of GCC. Nobody is currently doing the substantial work to turn our changes into patches for GCC 3.x. What I think we ought to do is to: o Release the existing compiler for use among Linux/MIPS enthusiasts (we're hoping that some commercial developers will take support contracts, of course); o Hope that many of you will use it and feed back bug reports, and that some of you will grab the sources and help track & fix them; o Aim to make earlier and more frequent releases for adventurous Linux users (we will keep a slow-moving 'stable' release for those whose priority is elsewhere); o Aim over the next couple of years - and with all the help we can get - to converge closer to the evolving GCC 3.x mainstream. I guess the question for this list is: is anyone interested? -- 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 Feb 12 10:08:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CI8va16958 for linux-mips-outgoing; Tue, 12 Feb 2002 10:08:57 -0800 Received: from spider.cphdev.eicon.com (firewall.i-data.com [195.24.22.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CI8u916955 for ; Tue, 12 Feb 2002 10:08:56 -0800 Received: from (null) ([127.0.0.1] helo=eicon.com) by spider.cphdev.eicon.com with esmtp (Exim 3.33 #1 (Debian)) id 16agQH-0000md-00 for ; Tue, 12 Feb 2002 18:08:54 +0100 Message-ID: <3C694C25.E828889E@eicon.com> Date: Tue, 12 Feb 2002 18:08:53 +0100 From: Brian Murphy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@oss.sgi.com" Subject: Re: gcc include strangeness References: <20020211142708.GA2577@convergence.de> <20020211162844.GD2918@convergence.de> <20020211232001.G4623@dea.linux-mips.net> <15465.15062.840707.525971@gladsmuir.algor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 80 Lines: 6 > I guess the question for this list is: is anyone interested? > Yes. /Brian From owner-linux-mips@oss.sgi.com Tue Feb 12 10:20:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1CIKW517233 for linux-mips-outgoing; Tue, 12 Feb 2002 10:20:32 -0800 Received: from web10204.mail.yahoo.com (web10204.mail.yahoo.com [216.136.130.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1CIKU917230 for ; Tue, 12 Feb 2002 10:20:30 -0800 Message-ID: <20020212172029.61237.qmail@web10204.mail.yahoo.com> Received: from [195.143.217.178] by web10204.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 09:20:29 PST Date: Tue, 12 Feb 2002 09:20:29 -0800 (PST) From: Timothy Daly Subject: Re: gcc include strangeness To: linux-mips@oss.sgi.com In-Reply-To: <15465.15062.840707.525971@gladsmuir.algor.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 231 Lines: 17 > I guess the question for this list is: is anyone interested? Hai! (yes) -Tim __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-linux-mips@oss.sgi.com Tue Feb 12 18:23:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1D2NdY32095 for linux-mips-outgoing; Tue, 12 Feb 2002 18:23:39 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1D2Na932091 for ; Tue, 12 Feb 2002 18:23:36 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 13 Feb 2002 01:23:36 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 EF68EB46B; Wed, 13 Feb 2002 10:23:33 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA44828; Wed, 13 Feb 2002 10:23:33 +0900 (JST) Date: Wed, 13 Feb 2002 10:28:05 +0900 (JST) Message-Id: <20020213.102805.74755945.nemoto@toshiba-tops.co.jp> To: kevink@mips.com Cc: macro@ds2.pg.gda.pl, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) From: Atsushi Nemoto In-Reply-To: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> References: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> 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.1 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 Content-Length: 510 Lines: 14 >>>>> On Tue, 12 Feb 2002 13:02:13 +0100, "Kevin D. Kissell" said: kevink> According to the (rather old) Tx39xx specs at my disposal, kevink> those parts should also support the SYNC instruction. Does kevink> anyone know for a fact that some of them do not? There are two types of TX39: TX39/H and TX39/H2. To my knowledge, both TX39/H (3904, 3912, etc.) and TX39/H2 (3922, 3927, etc.) have then SYNC instruction. TX39/H2 also have a write buffer but TX39/H does not. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Feb 13 12:14:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1DKE3P01983 for linux-mips-outgoing; Wed, 13 Feb 2002 12:14:03 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1DKDm901953 for ; Wed, 13 Feb 2002 12:13:50 -0800 Received: from delllaptop (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g1DJDme02025 for ; Wed, 13 Feb 2002 11:13:48 -0800 From: "Robert Rusek" To: Subject: NFS ROOT Problem - boot (newbie) Date: Wed, 13 Feb 2002 11:07:44 -0800 Message-ID: <002f01c1b4c1$b7c4cb60$6d1510ac@delllaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4272 Lines: 108 I am relatively new to this. I am trying to boot to an nfs root on my PC RedHat 7.2 box. I downloaded the nfs image from ftp.mips.org (nfsroot.mips.redhat7.1.eb-01.00.tar.gz). I have a working 2.4.3 kernel that I have installed on a SGI. I need to boot to the nfs image so that I can install to a local drive. I have setup nfs on my PC RedHat 7.2 box and it is working. When I boot the kernel on my SGI as follows: >> boot nfsroot=192.168.0.75:mips ip=192.168.0.50 I get the following: --- 1503232+0+147092 entry: 0x880025a8 ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R5000 FPU ICACHE DCACHE SCACHE Loading R4000 MMU routines. CPU revision is: 00002310 Primary instruction cache 32kb, linesize 32 bytes. Primary data cache 32kb, linesize 32 bytes. Linux version 2.4.3 (flo@paradigm) (gcc version 3.0 20010303 (prerelease)) #1 Thu Apr 12 22:38:03 CEST 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: 00193000 @ 08002000 (reserved) memory: 005ab000 @ 08195000 (usable) memory: 000c0000 @ 08740000 (ROM data) memory: 03800000 @ 08800000 (usable) On node 0 totalpages: 49152 zone(0): 49152 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=scsi(0)disk(1)rdisk(0)partition(0) nfsroot=192.168.0.75:mips ip=192.168.0.50 Calibrating system timer... 900000 [180.00 MHz CPU] zs0: console input Console: ttyS0 (Zilog8530) Calibrating delay loop... 179.81 BogoMIPS Memory: 60056k/63148k available (1311k kernel code, 3092k reserved, 83k data, 72k init) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 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 Starting kswapd v1.8 initialize_kbd: Keyboard reset failed, no ACK pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: queued sectors max/low 39482kB/13160kB, 128 slots per queue sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:0a:31:7a 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 Apr 12 2001 at 22:38:57 scsi0 : SGI WD93 sending SDTR 0103013f0csync_xfer=2c Vendor: SGI Model: IBM DORS-32160 Rev: W80D Type: Direct-Access ANSI SCSI revision: 02 sending SDTR 0103013f0csync_xfer=2c Vendor: SGI Model: SEAGATE ST51080N Rev: 0950 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0 SCSI device sda: 4197405 512-byte hdwr sectors (2149 MB) Partition check: sda: sda1 sda2 sda3 sda4 SCSI device sdb: 2070235 512-byte hdwr sectors (1060 MB) sdb: sdb1 sdb2 sdb3 sdb4 SGI Zilog8530 serial driver version 1.00 tty00 at 0xbfbd9830 (irq = 21) is a Zilog8530 tty01 at 0xbfbd9838 (irq = 21) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) IP-Config: Guessing netmask 255.255.255.0 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 192.168.0.75 Looking up port of RPC 100005/2 on 192.168.0.75 VFS: Mounted root (nfs filesystem) readonly. Freeing prom memory: 768kb freed Freeing unused kernel memory: 72k freed nfs: server 192.168.0.75 not responding, still trying --- It seems that it initially finds the root on the nfs box but it never get to do an init. It just stops and waits... Do I need to modify any setting manually on my NFS image in order for the kernel to boot? Thanks -- Robert Rusek From owner-linux-mips@oss.sgi.com Wed Feb 13 17:17:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E1Hnn11486 for linux-mips-outgoing; Wed, 13 Feb 2002 17:17:49 -0800 Received: from spinics.net (IDENT:root@vzn1-22.ce.ftel.net [206.24.95.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E1Hl911483 for ; Wed, 13 Feb 2002 17:17:47 -0800 Received: (from ellis@localhost) by spinics.net (8.11.6/8.11.6) id g1E0HqT11565 for linux-mips@oss.sgi.com; Wed, 13 Feb 2002 16:17:52 -0800 From: ellis@spinics.net Message-Id: <200202140017.g1E0HqT11565@spinics.net> Subject: Re: NFS ROOT Problem - boot (newbie) To: linux-mips@oss.sgi.com Date: Wed, 13 Feb 2002 16:17:52 -0800 (PST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 474 Lines: 12 >It seems that it initially finds the root on the nfs box but it >never get to do an init. It just stops and waits... Do I need >to modify any setting manually on my NFS image in order for the >kernel to boot? I had something like that happen to me. It'd start mounting the NFS root but would stop sending packets after a while. I thought it was the ethernet driver but I never did find the problem before I had to move to other projects. -- http://www.spinics.net/linux/ From owner-linux-mips@oss.sgi.com Wed Feb 13 18:05:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1E25Nq12384 for linux-mips-outgoing; Wed, 13 Feb 2002 18:05:23 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1E25I912378 for ; Wed, 13 Feb 2002 18:05:18 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g1E157D03578; Wed, 13 Feb 2002 20:05:07 -0500 Date: Wed, 13 Feb 2002 20:05:07 -0500 From: Jim Paris To: ellis@spinics.net Cc: linux-mips@oss.sgi.com Subject: Re: NFS ROOT Problem - boot (newbie) Message-ID: <20020213200507.A3446@neurosis.mit.edu> Reply-To: jim@jtan.com References: <200202140017.g1E0HqT11565@spinics.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202140017.g1E0HqT11565@spinics.net>; from ellis@spinics.net on Wed, Feb 13, 2002 at 04:17:52PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1404 Lines: 30 > >It seems that it initially finds the root on the nfs box but it > >never get to do an init. It just stops and waits... Do I need > >to modify any setting manually on my NFS image in order for the > >kernel to boot? > > I had something like that happen to me. It'd start mounting the > NFS root but would stop sending packets after a while. I thought > it was the ethernet driver but I never did find the problem > before I had to move to other projects. I also saw a similar problem when booting the kernel with a ramdisk and attempting to NFS mount from there via a wireless card. I don't even remember which kernel it was now, but I eventually concluded that the issue was with fragmented UDP packets. Linux has NFS_DEF_FILE_IO_BUFFER_SIZE set to 4096, which is of course larger than an Ethernet frame (1536) and must fragment. I'm not sure if it that was the fault with the kernel or the wireless access point I was using, but my host would send all fragments, and the MIPS box would eventually send back a reassembly timeout. Anyway, my solution was: mount -o rsize=1024,wsize=1024 ... I presume you could also set those from the boot command line if you need to use nfsroot. (The symptoms were that I could mount, and a very small number of operations would occasionally work. Of course, the ones that worked were just whatever ones happened to fit in an unfragmented UDP packet) -jim From owner-linux-mips@oss.sgi.com Thu Feb 14 03:03:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EB3oU08240 for linux-mips-outgoing; Thu, 14 Feb 2002 03:03:50 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EB3f908237; Thu, 14 Feb 2002 03:03:42 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 14 Feb 2002 10:03:41 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 D1E92B479; Thu, 14 Feb 2002 19:03:38 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA49061; Thu, 14 Feb 2002 19:03:38 +0900 (JST) Date: Thu, 14 Feb 2002 19:08:07 +0900 (JST) Message-Id: <20020214.190807.28780825.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: cvt.s.d emulation fix From: Atsushi Nemoto 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.1 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 Content-Length: 934 Lines: 26 I found two small problem on cvt.s.d emulation. 1. Converting a denormalized number does not raise Inexact exception. 2. Any denormalized double precision numbers are converted to zero regardless rounding mode. If rounding mode was "up", a positive denormalized double precision number should be converted to minimal (denormalized) single precision number. Here is a patch. --- linux-sgi-cvs/arch/mips/math-emu/sp_fdp.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/math-emu/sp_fdp.c Thu Feb 14 18:56:06 2002 @@ -55,6 +55,10 @@ case IEEE754_CLASS_DNORM: /* cant possibly be sp representable */ SETCX(IEEE754_UNDERFLOW); + SETCX(IEEE754_INEXACT); + if ((ieee754_csr.rm == IEEE754_RU && !xs) || + (ieee754_csr.rm == IEEE754_RD && xs)) + return ieee754sp_xcpt(ieee754sp_mind(xs), "fdp", x); return ieee754sp_xcpt(ieee754sp_zero(xs), "fdp", x); case IEEE754_CLASS_NORM: break; --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Feb 14 14:40:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EMeX201815 for linux-mips-outgoing; Thu, 14 Feb 2002 14:40:33 -0800 Received: from mailhost.taec.toshiba.com (mailhost.taec.com [209.243.128.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EMeQ901812 for ; Thu, 14 Feb 2002 14:40:26 -0800 Received: from hdqmta.taec.com (hdqmta [209.243.180.59]) by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id NAA29253 for ; Thu, 14 Feb 2002 13:40:18 -0800 (PST) Subject: Tools issue To: linux-mips@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: Adrian.Hulse@taec.toshiba.com Date: Thu, 14 Feb 2002 13:42:31 -0800 X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.8 |June 18, 2001) at 02/14/2002 01:39:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2087 Lines: 56 I am experiencing some strange behaviour dependent on the tools I use and I was wondering if anyone on this list, has experienced similar problems or may know the answer to my problem. To date I have been using the following tools from the SGI site to successfully compile and boot a 2.4.12 little endian mips kernel : binutils-mipsel-linux-2.8.1-2.i386.rpm egcs-mipsel-linux-1.1.2-4.i386.rpm As an experiment I decided to try the "toolchain-20011020" tools also from the SGI site to compile the exact same kernel, but the compile fails with the following 2 errors : ctfb.c:1158: warning: duplicate `const' {standard input}:11123: Error: expression too complex {standard input}:11123: Fatal Error: internal Error, line 1980, ../../tools-20011020/gas/config/tc-mips.c make[3]: ***[ctfb.o] Error 2 int-handler.s:59: Error: missing ')' int-handler.s:59: Error: illegal operands `lui' int-handler.s:60: Error: missing ')' int-handler.s:60: Error: illegal operands `sb' make[1]: *** [ int-handler.o ] Error 1 I can get around the first error by just disabling CONFIG_FB_CT in the config and recompiling. Note the monta vista toolchain also fails in the same file, with I think the same error. I can get around the second error by one of two methods : a, just comment it out because all it's doing is lighting up an led according to the interrupt received b, by changing a parenthesised define to non-parenthesised form : int-handler.S lui t1, %hi(TSDB_LED_ADDR) sb t0, %lo(TSDB_LDE_ADDR)(t1) Failed define : #define TSDB_LED_ADDR (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020) Compilable define : #define TSDB_LED_ADDR KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020 So with the above 2 kludges I can get the kernel to compile, but now when I come to boot it, the board it just locks failing somewhere in console_init ( currently investigating ). Anyone else seen anything like this and know of a solution to the problem ? Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick your own version folklore" method of picking tools :). Thx From owner-linux-mips@oss.sgi.com Thu Feb 14 18:56:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2ukr05499 for linux-mips-outgoing; Thu, 14 Feb 2002 18:56:46 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F2uj905495 for ; Thu, 14 Feb 2002 18:56:45 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g1F1sFB10416; Thu, 14 Feb 2002 17:54:15 -0800 Message-ID: <3C6C6ACF.CAD2FFC@mvista.com> Date: Thu, 14 Feb 2002 17:56:31 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: FPU emulator unsafe for SMP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 384 Lines: 11 I have been chasing a FPU register corruption problem on a SMP box. The curruption seems to be caused by FPU emulator code. Is that code SMP safe? If not, what are the volunerable spots? Just thought I'd check before I dive into it .... BTW, I think even with the latest fpu emu patch, the classic fpu/signal problem is still there. I will post in a separate email later. Jun From owner-linux-mips@oss.sgi.com Thu Feb 14 19:14:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F3Ene05790 for linux-mips-outgoing; Thu, 14 Feb 2002 19:14:49 -0800 Received: from dea.linux-mips.net (a1as18-p131.stg.tli.de [195.252.193.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F3Ei905786 for ; Thu, 14 Feb 2002 19:14:44 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1F2BI221209; Fri, 15 Feb 2002 03:11:18 +0100 Date: Fri, 15 Feb 2002 03:11:18 +0100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020215031118.B21011@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6C6ACF.CAD2FFC@mvista.com>; from jsun@mvista.com on Thu, Feb 14, 2002 at 05:56:31PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 872 Lines: 21 On Thu, Feb 14, 2002 at 05:56:31PM -0800, Jun Sun wrote: > I have been chasing a FPU register corruption problem on a SMP box. The > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > If not, what are the volunerable spots? > > Just thought I'd check before I dive into it .... In theory the fp emulation code should be MP safe as the full emulation is only accessing it's context in the fp register set of struct task_struct. The 32-bit kernel's fp register switching is entirely broken (read: close to non-existant). Lots of brownie points for somebody to backport that from the 64-bit kernel to the 32-bit kernel and forward port all the FPU emu bits to the 64-bit kernel ... > BTW, I think even with the latest fpu emu patch, the classic fpu/signal > problem is still there. I will post in a separate email later. Urgs ... Ralf From owner-linux-mips@oss.sgi.com Thu Feb 14 19:53:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F3rk806264 for linux-mips-outgoing; Thu, 14 Feb 2002 19:53:46 -0800 Received: from dea.linux-mips.net (a1as18-p131.stg.tli.de [195.252.193.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F3rb906261 for ; Thu, 14 Feb 2002 19:53:37 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1F2nwm23669; Fri, 15 Feb 2002 03:49:58 +0100 Date: Fri, 15 Feb 2002 03:49:58 +0100 From: Ralf Baechle To: Adrian.Hulse@taec.toshiba.com Cc: linux-mips@oss.sgi.com Subject: Re: Tools issue Message-ID: <20020215034958.C21011@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Adrian.Hulse@taec.toshiba.com on Thu, Feb 14, 2002 at 01:42:31PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2741 Lines: 68 On Thu, Feb 14, 2002 at 01:42:31PM -0800, Adrian.Hulse@taec.toshiba.com wrote: > I am experiencing some strange behaviour dependent on the tools I use and I > was wondering if anyone on this list, has experienced similar problems or > may know the answer to my problem. > > To date I have been using the following tools from the SGI site to > successfully compile and boot a 2.4.12 little endian mips kernel : > > binutils-mipsel-linux-2.8.1-2.i386.rpm > egcs-mipsel-linux-1.1.2-4.i386.rpm > > As an experiment I decided to try the "toolchain-20011020" tools also from > the SGI site to compile the exact same kernel, but the compile fails with > the following 2 errors : > > ctfb.c:1158: warning: duplicate `const' > {standard input}:11123: Error: expression too complex > {standard input}:11123: Fatal Error: internal Error, line 1980, > ../../tools-20011020/gas/config/tc-mips.c > make[3]: ***[ctfb.o] Error 2 Can you post the compiler generated assembler that is causing this error? What kernel version is this? > int-handler.s:59: Error: missing ')' > int-handler.s:59: Error: illegal operands `lui' > int-handler.s:60: Error: missing ')' > int-handler.s:60: Error: illegal operands `sb' > make[1]: *** [ int-handler.o ] Error 1 > > I can get around the first error by just disabling CONFIG_FB_CT in the > config and recompiling. Note the monta vista toolchain also fails in the > same file, with I think the same error. > I can get around the second error by one of two methods : > a, just comment it out because all it's doing is lighting up an led > according to the interrupt received > b, by changing a parenthesised define to non-parenthesised form : > > int-handler.S > lui t1, %hi(TSDB_LED_ADDR) > sb t0, %lo(TSDB_LDE_ADDR)(t1) > > Failed define : > #define TSDB_LED_ADDR (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020) > > Compilable define : > #define TSDB_LED_ADDR KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020 > > So with the above 2 kludges I can get the kernel to compile, but now when I > come to boot it, the board it just locks failing somewhere in console_init > ( currently investigating ). Binutils 2.8.x are definately buggy; 2.9.5.x on oss are the oldest version that's sortof working ... > Anyone else seen anything like this and know of a solution to the problem ? > Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick > your own version folklore" method of picking tools :). I hope that for binutils we can solve that problem when 2.9.12 gets released; as for gcc it seems Maciej's 2.95.3 version is already pretty close to what we want. C++ users may disagree ;-) Somewhat longer term Algorithmics's toolchain should resolve the situation. Ralf From owner-linux-mips@oss.sgi.com Thu Feb 14 20:27:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F4R5g06669 for linux-mips-outgoing; Thu, 14 Feb 2002 20:27:05 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F4R1906666 for ; Thu, 14 Feb 2002 20:27:02 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 15 Feb 2002 03:27:01 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 2653AB46B; Fri, 15 Feb 2002 12:26:59 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA50808; Fri, 15 Feb 2002 12:26:58 +0900 (JST) Date: Fri, 15 Feb 2002 12:31:24 +0900 (JST) Message-Id: <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> To: kevink@mips.com Cc: macro@ds2.pg.gda.pl, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) From: Atsushi Nemoto In-Reply-To: <20020213.102805.74755945.nemoto@toshiba-tops.co.jp> References: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> <20020213.102805.74755945.nemoto@toshiba-tops.co.jp> 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.1 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 Content-Length: 383 Lines: 11 >>>>> On Wed, 13 Feb 2002 10:28:05 +0900 (JST), Atsushi Nemoto said: nemoto> TX39/H2 also have a write buffer but TX39/H does not. Sorry, this is wrong. TX39/H also have a write buffer. Note that SYNC on TX39/H and TX39/H2 does not flush a write buffer. Some operation (for example, bc0f loop) are required to flush a write buffer. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Feb 14 21:59:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F5xqk07727 for linux-mips-outgoing; Thu, 14 Feb 2002 21:59:52 -0800 Received: from dea.linux-mips.net (a1as18-p131.stg.tli.de [195.252.193.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F5xl907724 for ; Thu, 14 Feb 2002 21:59:47 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1F4uLt25251 for linux-mips@oss.sgi.com; Fri, 15 Feb 2002 05:56:21 +0100 Date: Fri, 15 Feb 2002 05:56:20 +0100 From: Ralf Baechle To: linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215055620.A25211@dea.linux-mips.net> References: <20020208172711.GA5605@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: <20020208172711.GA5605@bogon.ms20.nix>; from agx@sigxcpu.org on Fri, Feb 08, 2002 at 06:27:11PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 29 On Fri, Feb 08, 2002 at 06:27:11PM +0100, Guido Guenther wrote: > attached is an updated patch for the ip22 watchdog timer. Please apply. Patch doesn't apply cleanly. *************** *** 574,579 **** fi # we always need the dummy console to make the serial console I2 happy define_bool CONFIG_DUMMY_CONSOLE y endmenu fi --- 574,584 ---- fi # we always need the dummy console to make the serial console I2 happy define_bool CONFIG_DUMMY_CONSOLE y + bool 'Watchdog Timer Support' CONFIG_WATCHDOG + if [ "$CONFIG_WATCHDOG" != "n" ]; then + bool ' Disable watchdog shutdown on close' CONFIG_WATCHDOG_NOWAYOUT + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG + fi endmenu fi Anyway, the comment about the I2 looks suspicious ... Ralf From owner-linux-mips@oss.sgi.com Fri Feb 15 00:20:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F8Kp609012 for linux-mips-outgoing; Fri, 15 Feb 2002 00:20:51 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F8Kj909009; Fri, 15 Feb 2002 00:20:45 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id XAA03608; Thu, 14 Feb 2002 23:20:30 -0800 Date: Thu, 14 Feb 2002 23:20:30 -0800 From: Jun Sun To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020214232030.A3601@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020215031118.B21011@dea.linux-mips.net>; from ralf@oss.sgi.com on Fri, Feb 15, 2002 at 03:11:18AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 994 Lines: 22 On Fri, Feb 15, 2002 at 03:11:18AM +0100, Ralf Baechle wrote: > On Thu, Feb 14, 2002 at 05:56:31PM -0800, Jun Sun wrote: > > > I have been chasing a FPU register corruption problem on a SMP box. The > > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > > If not, what are the volunerable spots? > > > > Just thought I'd check before I dive into it .... > > In theory the fp emulation code should be MP safe as the full emulation > is only accessing it's context in the fp register set of struct > task_struct. The 32-bit kernel's fp register switching is entirely broken > (read: close to non-existant). Lots of brownie points for somebody to > backport that from the 64-bit kernel to the 32-bit kernel and forward > port all the FPU emu bits to the 64-bit kernel ... > Brownie sounds good. :-) So what is the "fp register switching" you are referring to? There is set of code related to lazy fpu context switch, which seems to be working fine now. Jun From owner-linux-mips@oss.sgi.com Fri Feb 15 01:31:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F9V3Z11782 for linux-mips-outgoing; Fri, 15 Feb 2002 01:31:03 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1F9Us911778; Fri, 15 Feb 2002 01:30:55 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id AAA03677; Fri, 15 Feb 2002 00:30:38 -0800 Date: Fri, 15 Feb 2002 00:30:37 -0800 From: Jun Sun To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020215003037.A3670@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020214232030.A3601@mvista.com>; from jsun@mvista.com on Thu, Feb 14, 2002 at 11:20:30PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1209 Lines: 27 On Thu, Feb 14, 2002 at 11:20:30PM -0800, Jun Sun wrote: > On Fri, Feb 15, 2002 at 03:11:18AM +0100, Ralf Baechle wrote: > > On Thu, Feb 14, 2002 at 05:56:31PM -0800, Jun Sun wrote: > > > > > I have been chasing a FPU register corruption problem on a SMP box. The > > > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > > > If not, what are the volunerable spots? > > > > > > Just thought I'd check before I dive into it .... > > > > In theory the fp emulation code should be MP safe as the full emulation > > is only accessing it's context in the fp register set of struct > > task_struct. The 32-bit kernel's fp register switching is entirely broken > > (read: close to non-existant). Lots of brownie points for somebody to > > backport that from the 64-bit kernel to the 32-bit kernel and forward > > port all the FPU emu bits to the 64-bit kernel ... > > > > Brownie sounds good. :-) So what is the "fp register switching" you are > referring to? There is set of code related to lazy fpu context switch, > which seems to be working fine now. > Hmm, I see. The lazy fpu context switch code is not SMP safe. I see fishy things like "last_task_used_math" etc... Jun From owner-linux-mips@oss.sgi.com Fri Feb 15 02:49:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FAn3r13141 for linux-mips-outgoing; Fri, 15 Feb 2002 02:49:03 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FAn0913138 for ; Fri, 15 Feb 2002 02:49:00 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA09495; Fri, 15 Feb 2002 01:48:55 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA08010; Fri, 15 Feb 2002 01:48:50 -0800 (PST) Message-ID: <006d01c1b606$21929c80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , References: <3C6C6ACF.CAD2FFC@mvista.com> Subject: Re: FPU emulator unsafe for SMP? Date: Fri, 15 Feb 2002 09:14:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1008 Lines: 26 > I have been chasing a FPU register corruption problem on a SMP box. The > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > If not, what are the volunerable spots? > > Just thought I'd check before I dive into it .... While the very first prototype was grossly SMP unsafe, the state associated with the emulated "FPU" was migrated into the thread context area long ago. It is just possible, however, that some internal emulator state persists in a global variable somewhere, which could create problems under SMP execution. > BTW, I think even with the latest fpu emu patch, the classic fpu/signal > problem is still there. I will post in a separate email later. I submitted a series of patches a year or so ago, the last of which really should have been a comprehensive fix to the FPU context switch and signal problems. The last time I looked, that patch had never made it into the OSS repository, but neither had anyone reported any holes in it. Kevin K. From owner-linux-mips@oss.sgi.com Fri Feb 15 02:49:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FAnDX13176 for linux-mips-outgoing; Fri, 15 Feb 2002 02:49:13 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FAnA913170 for ; Fri, 15 Feb 2002 02:49:10 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA09499; Fri, 15 Feb 2002 01:49:05 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA08013; Fri, 15 Feb 2002 01:48:52 -0800 (PST) Message-ID: <006e01c1b606$27b1b060$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Atsushi Nemoto" Cc: , , , , References: <010601c1b3bd$1da618e0$0deca8c0@Ulysses><20020213.102805.74755945.nemoto@toshiba-tops.co.jp> <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) Date: Fri, 15 Feb 2002 09:30:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 843 Lines: 19 From: "Atsushi Nemoto" : > Note that SYNC on TX39/H and TX39/H2 does not flush a write buffer. > Some operation (for example, bc0f loop) are required to flush a write > buffer. That is, I would say, a bug in the TX39 implementation of SYNC. The specification is states that all stores prior to the SYNC must complete before any memory ops after the sync, and that the definition of a store completing is that all stored values be "visible to every other processor in the system", which pretty clearly implies that the write buffers must be flushed. So I think that the Linux code was perfectly correct in considering the TX39 to be without SYNC, just as a Vr4101 must be consdered to be without LL/SC. They decode the instructions, but they don't actually implement them as specified. Kevin K. From owner-linux-mips@oss.sgi.com Fri Feb 15 02:55:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FAtfr13393 for linux-mips-outgoing; Fri, 15 Feb 2002 02:55:41 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FAtX913378; Fri, 15 Feb 2002 02:55:33 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA09559; Fri, 15 Feb 2002 01:55:27 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA08131; Fri, 15 Feb 2002 01:55:22 -0800 (PST) Message-ID: <002b01c1b607$6afbd5c0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" , "Ralf Baechle" Cc: References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> Subject: Re: FPU emulator unsafe for SMP? Date: Fri, 15 Feb 2002 10:59:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1117 Lines: 25 > > > > I have been chasing a FPU register corruption problem on a SMP box. The > > > > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > > > > If not, what are the volunerable spots? > > > > > > In theory the fp emulation code should be MP safe as the full emulation > > > is only accessing it's context in the fp register set of struct > > > task_struct. The 32-bit kernel's fp register switching is entirely broken > > > (read: close to non-existant). Lots of brownie points for somebody to > > > backport that from the 64-bit kernel to the 32-bit kernel and forward > > > port all the FPU emu bits to the 64-bit kernel ... > > > > > > > Brownie sounds good. :-) So what is the "fp register switching" you are > > referring to? There is set of code related to lazy fpu context switch, > > which seems to be working fine now. > > > > Hmm, I see. The lazy fpu context switch code is not SMP safe. > I see fishy things like "last_task_used_math" etc... What, you mean "last_task_used_math" isn't allocated in a processor-specific page of kseg3??? ;-) Kevin K. From owner-linux-mips@oss.sgi.com Fri Feb 15 04:50:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FCoBc16606 for linux-mips-outgoing; Fri, 15 Feb 2002 04:50:11 -0800 Received: from dea.linux-mips.net (a1as06-p212.stg.tli.de [195.252.187.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FCo7916603 for ; Fri, 15 Feb 2002 04:50:08 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1FAvBu26813; Fri, 15 Feb 2002 11:57:11 +0100 Date: Fri, 15 Feb 2002 11:57:11 +0100 From: Ralf Baechle To: "Kevin D. Kissell" , carstenl@mips.com Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020215115711.A26798@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <006d01c1b606$21929c80$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006d01c1b606$21929c80$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Feb 15, 2002 at 09:14:52AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 492 Lines: 13 On Fri, Feb 15, 2002 at 09:14:52AM +0100, Kevin D. Kissell wrote: > I submitted a series of patches a year or so ago, the > last of which really should have been a comprehensive > fix to the FPU context switch and signal problems. > The last time I looked, that patch had never made it into > the OSS repository, but neither had anyone reported > any holes in it. I was actually beliving that the bundle of patches I received from Carsten maybe 3 months ago did fix all the issues? Ralf From owner-linux-mips@oss.sgi.com Fri Feb 15 04:50:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FCoT016625 for linux-mips-outgoing; Fri, 15 Feb 2002 04:50:29 -0800 Received: from dea.linux-mips.net (a1as06-p212.stg.tli.de [195.252.187.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FCoP916616 for ; Fri, 15 Feb 2002 04:50:25 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1FAo6S26781; Fri, 15 Feb 2002 11:50:06 +0100 Date: Fri, 15 Feb 2002 11:50:06 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Atsushi Nemoto , macro@ds2.pg.gda.pl, mdharm@momenco.com, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) Message-ID: <20020215115006.B26756@dea.linux-mips.net> References: <010601c1b3bd$1da618e0$0deca8c0@Ulysses><20020213.102805.74755945.nemoto@toshiba-tops.co.jp> <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> <006e01c1b606$27b1b060$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006e01c1b606$27b1b060$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Feb 15, 2002 at 09:30:45AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 831 Lines: 17 On Fri, Feb 15, 2002 at 09:30:45AM +0100, Kevin D. Kissell wrote: > That is, I would say, a bug in the TX39 implementation of SYNC. > The specification is states that all stores prior to the SYNC must > complete before any memory ops after the sync, and that the > definition of a store completing is that all stored values be > "visible to every other processor in the system", which pretty > clearly implies that the write buffers must be flushed. In practice sync just isn't good enough. Most systems these days use an I/O bus like PCI which uses posted writes or have some other non-strongly ordered memory model. Which is why something wmb() or mb() aren't good enough in driver. I'm just having a nice discussion about this topic with SGI's IA64 people; we have to come up with a portable and efficient ABI. Ralf From owner-linux-mips@oss.sgi.com Fri Feb 15 04:58:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FCw0Y16881 for linux-mips-outgoing; Fri, 15 Feb 2002 04:58:00 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FCvu916878 for ; Fri, 15 Feb 2002 04:57:57 -0800 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g1FBv5402720; Fri, 15 Feb 2002 11:57:05 GMT Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id LAA17485; Fri, 15 Feb 2002 11:56:59 GMT Date: Fri, 15 Feb 2002 11:56:59 GMT Message-Id: <200202151156.LAA17485@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kevin D. Kissell" Cc: "Atsushi Nemoto" , , , , , Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <006e01c1b606$27b1b060$0deca8c0@Ulysses> References: <010601c1b3bd$1da618e0$0deca8c0@Ulysses> <20020213.102805.74755945.nemoto@toshiba-tops.co.jp> <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> <006e01c1b606$27b1b060$0deca8c0@Ulysses> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 653 Lines: 19 Kevin D. Kissell (kevink@mips.com) writes: > > Note that SYNC on TX39/H and TX39/H2 does not flush a write buffer. > > Some operation (for example, bc0f loop) are required to flush a write > > buffer. > > That is, I would say, a bug in the TX39 implementation of SYNC. That's only a problem if the CPU permitted reads to overtake buffered writes. [Early R3000 write buffers did that (with an address check to avoid the disaster of allowing a read to overtake a write to the same location).] But my recollection is that the TX39 does all memory operations in order: so SYNC has very little to do, but it isn't a bug. Dominic Sweetman Algorithmics From owner-linux-mips@oss.sgi.com Fri Feb 15 05:06:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FD68N17220 for linux-mips-outgoing; Fri, 15 Feb 2002 05:06:08 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FD63917213 for ; Fri, 15 Feb 2002 05:06:03 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA10821; Fri, 15 Feb 2002 04:05:52 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA10661; Fri, 15 Feb 2002 04:05:49 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g1FC5GA17265; Fri, 15 Feb 2002 13:05:17 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id NAA25636; Fri, 15 Feb 2002 13:05:16 +0100 (MET) Message-Id: <200202151205.NAA25636@copsun18.mips.com> Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) To: dom@algor.co.uk (Dominic Sweetman) Date: Fri, 15 Feb 2002 13:05:16 +0100 (MET) Cc: kevink@mips.com (Kevin D. Kissell), nemoto@toshiba-tops.co.jp (Atsushi Nemoto), macro@ds2.pg.gda.pl, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: <200202151156.LAA17485@mudchute.algor.co.uk> from "Dominic Sweetman" at Feb 15, 2002 11:56:59 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1409 Lines: 41 But in-order for the CPU is not enough - it also needs to make sure all written data is visible for DMA accesses to memory from the outside, which is why the writebuffer needs to be flushed by a SYNC as well. From the definition of "SYNC": "A store is completed when the stored value is visible to every other processor in the system". Which presumably also includes DMA I/O devices... /Hartvig Dominic Sweetman writes: > > > Kevin D. Kissell (kevink@mips.com) writes: > > > > Note that SYNC on TX39/H and TX39/H2 does not flush a write buffer. > > > Some operation (for example, bc0f loop) are required to flush a write > > > buffer. > > > > That is, I would say, a bug in the TX39 implementation of SYNC. > > That's only a problem if the CPU permitted reads to overtake buffered > writes. [Early R3000 write buffers did that (with an address check to > avoid the disaster of allowing a read to overtake a write to the same > location).] > > But my recollection is that the TX39 does all memory operations in > order: so SYNC has very little to do, but it isn't a bug. > > Dominic Sweetman > Algorithmics > -- _ _ _____ ____ 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 Feb 15 05:06:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FD6iF17278 for linux-mips-outgoing; Fri, 15 Feb 2002 05:06:44 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FD6F917263; Fri, 15 Feb 2002 05:06:15 -0800 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 225F8B489; Fri, 15 Feb 2002 13:06:14 +0100 (CET) Date: Fri, 15 Feb 2002 13:06:14 +0100 From: Guido Guenther To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215130613.A301@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Ralf Baechle , linux-mips@oss.sgi.com References: <20020208172711.GA5605@bogon.ms20.nix> <20020215055620.A25211@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020215055620.A25211@dea.linux-mips.net>; from ralf@oss.sgi.com on Fri, Feb 15, 2002 at 05:56:20AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6878 Lines: 241 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 15, 2002 at 05:56:20AM +0100, Ralf Baechle wrote: > On Fri, Feb 08, 2002 at 06:27:11PM +0100, Guido Guenther wrote: > > > attached is an updated patch for the ip22 watchdog timer. Please apply. > > Patch doesn't apply cleanly. Artifacts of my other IP22 patches, I moved the config stuff to the other watchdog drivers in drivers/char/Config.in now. Applies cleanly on fresh 2.4.17 CVS checkout. -- Guido --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="indydog-2002-02-15.diff" diff --exclude=CVS -Naur linux-2.4.17.orig/Documentation/Configure.help linux-2.4.17/Documentation/Configure.help --- linux-2.4.17.orig/Documentation/Configure.help Sat Dec 29 06:37:46 2001 +++ linux-2.4.17/Documentation/Configure.help Fri Feb 15 09:55:06 2002 @@ -3129,6 +3129,13 @@ via the file /proc/rtc and its behaviour is set by various ioctls on /dev/rtc. +Indy/I2 Hardware Watchdog +CONFIG_INDYDOG + Hardwaredriver for the Indy's/I2's watchdog. This is a + watchdog timer that will reboot the machine after a 60 second + timer expired and no process has written to /dev/watchdog during + that time. + Support the Bell Technologies HUB6 card CONFIG_HUB6 Say Y here to enable support in the dumb serial driver to support diff --exclude=CVS -Naur linux-2.4.17.orig/arch/mips/sgi-ip22/ip22-mc.c linux-2.4.17/arch/mips/sgi-ip22/ip22-mc.c --- linux-2.4.17.orig/arch/mips/sgi-ip22/ip22-mc.c Tue Nov 27 16:57:11 2001 +++ linux-2.4.17/arch/mips/sgi-ip22/ip22-mc.c Fri Feb 15 09:55:07 2002 @@ -82,6 +82,14 @@ * interrupts are first enabled etc. */ + /* Step 0: Make sure we turn off the watchdog in case it's + * still running (which might be the case after a + * soft reboot). + */ + tmpreg = mcmisc_regs->cpuctrl0; + tmpreg &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = tmpreg; + /* Step 1: The CPU/GIO error status registers will not latch * up a new error status until the register has been * cleared by the cpu. These status registers are diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/Config.in linux-2.4.17/drivers/char/Config.in --- linux-2.4.17.orig/drivers/char/Config.in Sun Dec 2 12:34:40 2001 +++ linux-2.4.17/drivers/char/Config.in Fri Feb 15 10:00:59 2002 @@ -199,6 +199,7 @@ tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG fi endmenu diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/Makefile linux-2.4.17/drivers/char/Makefile --- linux-2.4.17.orig/drivers/char/Makefile Mon Jan 7 04:33:54 2002 +++ linux-2.4.17/drivers/char/Makefile Fri Feb 15 09:55:07 2002 @@ -245,6 +245,7 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o +obj-$(CONFIG_INDYDOG) += indydog.o subdir-$(CONFIG_MWAVE) += mwave ifeq ($(CONFIG_MWAVE),y) diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/indydog.c linux-2.4.17/drivers/char/indydog.c --- linux-2.4.17.orig/drivers/char/indydog.c Thu Jan 1 01:00:00 1970 +++ linux-2.4.17/drivers/char/indydog.c Fri Feb 15 09:55:07 2002 @@ -0,0 +1,158 @@ +/* + * IndyDog 0.2 A Hardware Watchdog Device for SGI IP22 + * + * (c) Copyright 2002 Guido Guenther , All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * based on softdog.c by Alan Cox + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int indydog_alive; +static struct sgimc_misc_ctrl *mcmisc_regs; + +static void indydog_ping() +{ + mcmisc_regs->watchdogt = 0; +} + + +/* + * Allow only one person to hold it open + */ + +static int indydog_open(struct inode *inode, struct file *file) +{ + u32 mc_ctrl0; + + if(indydog_alive) + return -EBUSY; +#ifdef CONFIG_WATCHDOG_NOWAYOUT + MOD_INC_USE_COUNT; +#endif + /* + * Activate timer + */ + mcmisc_regs = (struct sgimc_misc_ctrl *)(KSEG1+0x1fa00000); + + mc_ctrl0 = mcmisc_regs->cpuctrl0 | SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + indydog_ping(); + + indydog_alive=1; + printk("Started watchdog timer.\n"); + return 0; +} + +static int indydog_release(struct inode *inode, struct file *file) +{ + /* + * Shut off the timer. + * Lock it in if it's a module and we defined ...NOWAYOUT + */ + lock_kernel(); +#ifndef CONFIG_WATCHDOG_NOWAYOUT + { + u32 mc_ctrl0 = mcmisc_regs->cpuctrl0; + mc_ctrl0 &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + printk("Stopped watchdog timer.\n"); + } +#endif + indydog_alive=0; + unlock_kernel(); + return 0; +} + +static ssize_t indydog_write(struct file *file, const char *data, size_t len, loff_t *ppos) +{ + /* Can't seek (pwrite) on this device */ + if (ppos != &file->f_pos) + return -ESPIPE; + + /* + * Refresh the timer. + */ + if(len) { + indydog_ping(); + return 1; + } + return 0; +} + +static int indydog_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + static struct watchdog_info ident = { + identity: "Hardware Watchdog for SGI IP22", + }; + switch (cmd) { + default: + return -ENOIOCTLCMD; + case WDIOC_GETSUPPORT: + if(copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))) + return -EFAULT; + return 0; + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + return put_user(0,(int *)arg); + case WDIOC_KEEPALIVE: + indydog_ping(); + return 0; + } +} + +static struct file_operations indydog_fops = { + owner: THIS_MODULE, + write: indydog_write, + ioctl: indydog_ioctl, + open: indydog_open, + release: indydog_release, +}; + +static struct miscdevice indydog_miscdev = { + minor: WATCHDOG_MINOR, + name: "watchdog", + fops: &indydog_fops, +}; + +static const char banner[] __initdata = KERN_INFO "Hardware Watchdog Timer for SGI IP22: 0.2\n"; + +static int __init watchdog_init(void) +{ + int ret; + + ret = misc_register(&indydog_miscdev); + + if (ret) + return ret; + + printk(banner); + + return 0; +} + +static void __exit watchdog_exit(void) +{ + misc_deregister(&indydog_miscdev); +} + +module_init(watchdog_init); +module_exit(watchdog_exit); +MODULE_LICENSE("GPL"); --8t9RHnE3ZwKMSgU+-- From owner-linux-mips@oss.sgi.com Fri Feb 15 05:10:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FDAYY17404 for linux-mips-outgoing; Fri, 15 Feb 2002 05:10:34 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FDAN917400 for ; Fri, 15 Feb 2002 05:10:24 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA00974; Fri, 15 Feb 2002 13:08:21 +0100 (MET) Date: Fri, 15 Feb 2002 13:08:20 +0100 (MET) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: kevink@mips.com, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1013 Lines: 26 On Fri, 15 Feb 2002, Atsushi Nemoto wrote: > Note that SYNC on TX39/H and TX39/H2 does not flush a write buffer. That's perfectly fine -- it does not need to. It's only a synchronization point. > Some operation (for example, bc0f loop) are required to flush a write > buffer. This is bad, though. No extra operations must be needed. After a "sync" the buffer should be written back as soon as not doing so would be visible externally. IOW, two consecutive writes separated by a "sync" need not imply a write-back, but as soon as a read happens a preceding write-back is a must. It sounds weird: it looks like "sync" is useless and basically a "nop". If this is the case the processors need their own wbflush() implementation. Can you point to specific chapters of specifications that document 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 Fri Feb 15 05:13:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FDD7N17489 for linux-mips-outgoing; Fri, 15 Feb 2002 05:13:07 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FDCc917484 for ; Fri, 15 Feb 2002 05:12:39 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA01131; Fri, 15 Feb 2002 13:11:16 +0100 (MET) Date: Fri, 15 Feb 2002 13:11:15 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Atsushi Nemoto , mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <006e01c1b606$27b1b060$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 701 Lines: 16 On Fri, 15 Feb 2002, Kevin D. Kissell wrote: > So I think that the Linux code was perfectly correct in considering > the TX39 to be without SYNC, just as a Vr4101 must be > consdered to be without LL/SC. They decode the instructions, > but they don't actually implement them as specified. The code is not correct if "bc0f" is needed to be sure a write-back happened. If that is the case, the processors need their own wbflush() implementation like R2k/R3k configurations in older DECstations. -- + 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 Feb 15 05:32:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FDW4E17688 for linux-mips-outgoing; Fri, 15 Feb 2002 05:32:04 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FDVd917684; Fri, 15 Feb 2002 05:31:40 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA01735; Fri, 15 Feb 2002 13:31:44 +0100 (MET) Date: Fri, 15 Feb 2002 13:31:43 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Kevin D. Kissell" , Atsushi Nemoto , mdharm@momenco.com, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <20020215115006.B26756@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1945 Lines: 40 On Fri, 15 Feb 2002, Ralf Baechle wrote: > In practice sync just isn't good enough. Most systems these days use > an I/O bus like PCI which uses posted writes or have some other > non-strongly ordered memory model. Which is why something wmb() or > mb() aren't good enough in driver. I'm just having a nice discussion It depends on what a driver needs. They are perfectly sufficient and actually needed for host bus devices if you need to be sure writes and/or reads happen in order. It's only when a side-effect of a write needs to happen immediately a write-back flush is needed. It doesn't happen that often. AFAIK, PCI only allows posted writes -- it doesn't allow write or read reordering, so mb() and friends are sufficient. Are there any busses we support or are going to in foreseeable future that have a weak ordering model? > about this topic with SGI's IA64 people; we have to come up with a > portable and efficient ABI. ABI? API, I suppose. I can't see anything special here -- drivers already know the bus they are on and they know if it needs any specific handling. I don't think it's possibly to define general functions for I/O buses as actions depend on the device that's being addressed. E.g. for a PCI device a driver needs to perform a read from one of the device's assigned regions and which location exactly, depends on what memory or registers the device implements (surely it can't read one that implies side effects). It can't just do an arbitrary read from a location decoded to the bus. Anyway, will my patch get applied or do we have to wait until the discussion concludes? The patch doesn't affect any I/O bus-specific operations, so it's orthogonal. Also a new API is surely a 2.5 item. -- + 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 Feb 15 05:44:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FDiNc17882 for linux-mips-outgoing; Fri, 15 Feb 2002 05:44:23 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FDiK917878 for ; Fri, 15 Feb 2002 05:44:20 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA11123; Fri, 15 Feb 2002 04:44:14 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA11277; Fri, 15 Feb 2002 04:44:11 -0800 (PST) Message-ID: <008601c1b61e$ff4d88b0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: "Atsushi Nemoto" , , , , References: Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) Date: Fri, 15 Feb 2002 13:47:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 755 Lines: 18 > On Fri, 15 Feb 2002, Kevin D. Kissell wrote: > > > So I think that the Linux code was perfectly correct in considering > > the TX39 to be without SYNC, just as a Vr4101 must be > > consdered to be without LL/SC. They decode the instructions, > > but they don't actually implement them as specified. > > The code is not correct if "bc0f" is needed to be sure a write-back > happened. If that is the case, the processors need their own wbflush() > implementation like R2k/R3k configurations in older DECstations. Note that I did not say that "the code is correct", only that it is correct *in considering the TX39 to be effectively SYNC-less*. I'm sure that the code is anyway broken six ways from Wednesday, as usual. ;-) Kevin K. From owner-linux-mips@oss.sgi.com Fri Feb 15 06:01:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FE1UN18235 for linux-mips-outgoing; Fri, 15 Feb 2002 06:01:30 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FE1Q918232 for ; Fri, 15 Feb 2002 06:01:26 -0800 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 FAA07078 for ; Fri, 15 Feb 2002 05:01:21 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA02328; Fri, 15 Feb 2002 13:53:51 +0100 (MET) Date: Fri, 15 Feb 2002 13:53:50 +0100 (MET) From: "Maciej W. Rozycki" To: Dominic Sweetman cc: "Kevin D. Kissell" , Atsushi Nemoto , mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <200202151156.LAA17485@mudchute.algor.co.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1046 Lines: 24 On Fri, 15 Feb 2002, Dominic Sweetman wrote: > That's only a problem if the CPU permitted reads to overtake buffered > writes. [Early R3000 write buffers did that (with an address check to > avoid the disaster of allowing a read to overtake a write to the same > location).] The R2020 and the R3220 write buffers that are used in older DECstations seem to provide buffered values themselves if hit by a read. This way they are completely safe for ordinary memory references and there is no need to stall for a write-back completion for memory operations. At least this is what DECstation specifications imply -- it seems hard to get to original docs for the chips these days. For I/O resources implying side effects a stall is needed, of course. The way the chips work is not that uncommon -- e.g. Intel's i486 does exactly the same. -- + 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 Feb 15 06:14:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FEE5S18402 for linux-mips-outgoing; Fri, 15 Feb 2002 06:14:05 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FEDa918388 for ; Fri, 15 Feb 2002 06:13:49 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA02690; Fri, 15 Feb 2002 14:03:45 +0100 (MET) Date: Fri, 15 Feb 2002 14:03:45 +0100 (MET) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: Dominic Sweetman , "Kevin D. Kissell" , Atsushi Nemoto , mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <200202151205.NAA25636@copsun18.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1233 Lines: 28 On Fri, 15 Feb 2002, Hartvig Ekner wrote: > But in-order for the CPU is not enough - it also needs to make sure all > written data is visible for DMA accesses to memory from the outside, which > is why the writebuffer needs to be flushed by a SYNC as well. From the > definition of "SYNC": > > "A store is completed when the stored value is visible to every other > processor in the system". > > Which presumably also includes DMA I/O devices... The description found in the R4k manual seems to contradict. A "sync" on a single CPU only assures transactions on it's external bus will happen in order wrt the "sync". In a multiple-CPU environment all CPUs interested in a barrier need to execute a "sync". That's seems natural -- how would you define a synchronization point for a CPU that does not execute a "sync". Since I/O devices have no means to signal a CPU a "sync" operation, how can you expect a "sync" on the CPU to complete all preceding writes to the device? It's only a following read that may imply 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 Fri Feb 15 06:20:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FEKRi18534 for linux-mips-outgoing; Fri, 15 Feb 2002 06:20:27 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FEKL918531 for ; Fri, 15 Feb 2002 06:20:21 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA03199; Fri, 15 Feb 2002 14:17:30 +0100 (MET) Date: Fri, 15 Feb 2002 14:17:30 +0100 (MET) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Atsushi Nemoto , mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <008601c1b61e$ff4d88b0$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1352 Lines: 29 On Fri, 15 Feb 2002, Kevin D. Kissell wrote: > > The code is not correct if "bc0f" is needed to be sure a write-back > > happened. If that is the case, the processors need their own wbflush() > > implementation like R2k/R3k configurations in older DECstations. > > Note that I did not say that "the code is correct", only that it > is correct *in considering the TX39 to be effectively SYNC-less*. Then you are probably misinterpreting CONFIG_CPU_HAS_SYNC (shame on me for not documenting it at all). It means a CPU has the "sync" instruction but it does not imply a "sync" is sufficient for mb() on the CPU. See the code in include/asm-mips/system.h in my patch. If CONFIG_CPU_HAS_WB is set wbflush() is executed for mb() regardless the setting of CONFIG_CPU_HAS_SYNC. Fast_mb() is set to a "sync" in case a wbflush() implementation needs it for something -- the DECstation's wbflush() actually uses it in a patch I have queued waiting for my pending submissions to be applied by Ralf. > I'm sure that the code is anyway broken six ways from Wednesday, > as usual. ;-) I hope with my fixes the number of ways decreases, though. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Feb 15 06:42:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FEg4K19084 for linux-mips-outgoing; Fri, 15 Feb 2002 06:42:04 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FEg1919081 for ; Fri, 15 Feb 2002 06:42:01 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 07:41:32 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B7578@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: hot patching Date: Fri, 15 Feb 2002 07:39:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1420 Lines: 27 I posted a general question a couple months back about this. Now that I have an approach in place, I wanted to see if the approach is workable before I spend a bunch of time trying to debug an approach that absolutely won't work for some fundamental reason. I am not yet a kernel guru (don't know that I want to be) but this "feature" seems to require intimate knowledge of the inner workings of the kernel's memory management. I'm attempting to set up a "hot patcher" in an embedded product. I'm attempting to use shared memory, however the "target" process is not aware of the patch being applied to it. Can a pseudo-driver attach a shared memory segment to a process which can then be executable by that process via a jump or jump-and-link, or is shared memory only for passing data and messages between collaborating processes? The references I've read only indicate the RW permissions, no X permissions. Or should I have the pseudo-driver actually allocate (by get_free_pages()) the memory required? And can it do this on behalf of the target process? If neither of these look workable, I've been thinking about the concept of using software interrupts. Any thoughts? Any constructive comments and/or insights greatly appreciated. ++++++++++++++++++++++++++++++++++++++++++++++++++ Keith Siders Software Engineer Toshiba Advanced Television Technology Center ++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-linux-mips@oss.sgi.com Fri Feb 15 06:50:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FEost19289 for linux-mips-outgoing; Fri, 15 Feb 2002 06:50:54 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FEoo919286 for ; Fri, 15 Feb 2002 06:50:51 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16biyn-0003EB-00; Fri, 15 Feb 2002 14:04:49 +0000 Subject: Re: hot patching To: keith_siders@toshibatv.com (Siders, Keith) Date: Fri, 15 Feb 2002 14:04:49 +0000 (GMT) Cc: linux-mips@oss.sgi.com ("Linux-Mips (E-mail)") In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA1B7578@ATVX> from "Siders, Keith" at Feb 15, 2002 07:39:49 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 854 Lines: 14 > I'm attempting to set up a "hot patcher" in an embedded product. I'm > attempting to use shared memory, however the "target" process is not aware > of the patch being applied to it. Can a pseudo-driver attach a shared memory > segment to a process which can then be executable by that process via a jump > or jump-and-link, or is shared memory only for passing data and messages > between collaborating processes? The references I've read only indicate the > RW permissions, no X permissions. Or should I have the pseudo-driver > actually allocate (by get_free_pages()) the memory required? And can it do > this on behalf of the target process? You shouldnt even need a driver if you are clever. The ptrace() functionality for debuggers is sufficient to patch running code, and to do other interesting things by adding new functions and calling them From owner-linux-mips@oss.sgi.com Fri Feb 15 07:18:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFIHI22635 for linux-mips-outgoing; Fri, 15 Feb 2002 07:18:17 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFHg922629; Fri, 15 Feb 2002 07:17:43 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA05630; Fri, 15 Feb 2002 15:17:18 +0100 (MET) Date: Fri, 15 Feb 2002 15:17:17 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Guido Guenther cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer In-Reply-To: <20020215130613.A301@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 Content-Length: 1154 Lines: 27 On Fri, 15 Feb 2002, Guido Guenther wrote: > diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/Config.in > linux-2.4.17/drivers/char/Config.in > --- linux-2.4.17.orig/drivers/char/Config.in Sun Dec 2 12:34:40 2001 > +++ linux-2.4.17/drivers/char/Config.in Fri Feb 15 10:00:59 2002 > @@ -199,6 +199,7 @@ > tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT > tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT > tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT > + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG > fi > endmenu This looks suspicious. Haven't you meant "dep_tristate"? Especially as indydog.c doesn't seem to make any effort to validate it's running on the system it thinks it is before poking random memory locations. It won't probably even compile for a non-MIPS kernel. BTW, why do people insist on sending patches as attachments -- it makes commenting them helly twisted, sigh... -- + 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 Feb 15 07:19:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFJjn22739 for linux-mips-outgoing; Fri, 15 Feb 2002 07:19:45 -0800 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFJf922736 for ; Fri, 15 Feb 2002 07:19:42 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 08:19:13 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B7579@ATVX> From: "Siders, Keith" To: "'Alan Cox'" Cc: "'linux-mips@oss.sgi.com'" Subject: RE: hot patching Date: Fri, 15 Feb 2002 08:17:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 863 Lines: 23 -> > I'm attempting to set up a "hot patcher" in an embedded -> >product. I'm ... -> -> You shouldnt even need a driver if you are clever. The -> ptrace() functionality -> for debuggers is sufficient to patch running code, and to do -> other interesting -> things by adding new functions and calling them -> Well, I never claimed to be terribly clever... When I looked at the ptrace code it looked to me like it was intended for inserting breakpoints for the most part. Are you saying that I can patch into a process and have it vector off to executable code? At this point I've identified at least three types of patches: a jump, a call, and simply overwrite a few instructions (the easiest and common to all types). I'd love to _not_ need a driver. -------------------------------------- Keith Siders Toshiba ATVTC -------------------------------------- From owner-linux-mips@oss.sgi.com Fri Feb 15 07:25:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFPd622962 for linux-mips-outgoing; Fri, 15 Feb 2002 07:25:39 -0800 Received: from dea.linux-mips.net (a1as07-p91.stg.tli.de [195.252.188.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFPZ922959 for ; Fri, 15 Feb 2002 07:25:35 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1FELWU00640; Fri, 15 Feb 2002 15:21:32 +0100 Date: Fri, 15 Feb 2002 15:21:32 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215152132.A602@dea.linux-mips.net> References: <20020215130613.A301@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 Fri, Feb 15, 2002 at 03:17:17PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 690 Lines: 15 On Fri, Feb 15, 2002 at 03:17:17PM +0100, Maciej W. Rozycki wrote: > This looks suspicious. Haven't you meant "dep_tristate"? Especially as > indydog.c doesn't seem to make any effort to validate it's running on the > system it thinks it is before poking random memory locations. It won't > probably even compile for a non-MIPS kernel. > > BTW, why do people insist on sending patches as attachments -- it makes > commenting them helly twisted, sigh... How true. MIME - broken solution for a broken design ;) More serious, MIME makes sense when using a MUA that garbles patches like Netscape or certain versions of Pine. Ralf (Prolly still be using Mutt + vi in 5 years ...) From owner-linux-mips@oss.sgi.com Fri Feb 15 07:41:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFfQp25746 for linux-mips-outgoing; Fri, 15 Feb 2002 07:41:26 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFfN925740 for ; Fri, 15 Feb 2002 07:41:23 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 16bjli-0003Lr-00; Fri, 15 Feb 2002 14:55:22 +0000 Subject: Re: hot patching To: keith_siders@toshibatv.com (Siders, Keith) Date: Fri, 15 Feb 2002 14:55:22 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk ('Alan Cox'), linux-mips@oss.sgi.com ('linux-mips@oss.sgi.com') In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA1B7579@ATVX> from "Siders, Keith" at Feb 15, 2002 08:17:30 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 476 Lines: 11 > When I looked at the ptrace code it looked to me like it was intended for > inserting breakpoints for the most part. Are you saying that I can patch Mostly yes > into a process and have it vector off to executable code? At this point I've > identified at least three types of patches: a jump, a call, and simply > overwrite a few instructions (the easiest and common to all types). I'd love > to _not_ need a driver. Have a look at how gdb implements "call functionname" From owner-linux-mips@oss.sgi.com Fri Feb 15 07:41:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FFfqR25815 for linux-mips-outgoing; Fri, 15 Feb 2002 07:41:52 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FFfe925811; Fri, 15 Feb 2002 07:41:41 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA06254; Fri, 15 Feb 2002 15:41:50 +0100 (MET) Date: Fri, 15 Feb 2002 15:41:49 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer In-Reply-To: <20020215152132.A602@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1248 Lines: 28 On Fri, 15 Feb 2002, Ralf Baechle wrote: > > BTW, why do people insist on sending patches as attachments -- it makes > > commenting them helly twisted, sigh... > > How true. MIME - broken solution for a broken design ;) More serious, Why broken? It's not broken for what it was invented to, i.e. for passing unsafe characters via SMTP. Source patches do not qualify as containing such. > MIME makes sense when using a MUA that garbles patches like Netscape or > certain versions of Pine. MIME is not a solution for broken MUAs or MDAs and was not intended as one, definitely. Pine got broken quite recently (it eats white space at line ends; that may be circumvented by using `patch -l' and may actually be advantageous in not adding white space there if present in the patch; the drawback is `patch' doesn't eat white space to be removed either) and there is a patch available (the package I have at my site doesn't have it applied, though, I admit; the next version should). The ancient version I'm using here seems safe as is. -- + 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 Feb 15 08:10:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGA6126302 for linux-mips-outgoing; Fri, 15 Feb 2002 08:10:06 -0800 Received: from dea.linux-mips.net (a1as07-p91.stg.tli.de [195.252.188.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGA0926287 for ; Fri, 15 Feb 2002 08:10:00 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1FF61R01153; Fri, 15 Feb 2002 16:06:01 +0100 Date: Fri, 15 Feb 2002 16:06:01 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215160601.A845@dea.linux-mips.net> References: <20020215152132.A602@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 15, 2002 at 03:41:49PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 662 Lines: 15 On Fri, Feb 15, 2002 at 03:41:49PM +0100, Maciej W. Rozycki wrote: > > How true. MIME - broken solution for a broken design ;) More serious, > > Why broken? It's not broken for what it was invented to, i.e. for > passing unsafe characters via SMTP. Source patches do not qualify as > containing such. The transition time from pre-MIME to MIME was pretty painful. If you'd have gone through the same pains that I did during the MIME introduction you'd probably understand why I call it a broken fix for a broken system. Fortunately now that the childhood problems have been solved MIME looks alot saner but still I prefer plaintext for patches. Ralf From owner-linux-mips@oss.sgi.com Fri Feb 15 08:27:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FGRwK26674 for linux-mips-outgoing; Fri, 15 Feb 2002 08:27:58 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FGRi926670; Fri, 15 Feb 2002 08:27:45 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 16bkGv-0002Is-00; Fri, 15 Feb 2002 16:27:37 +0100 Date: Fri, 15 Feb 2002 16:27:37 +0100 From: Johannes Stezenbach To: Ralf Baechle Cc: Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com Subject: Re: Tools issue Message-ID: <20020215152737.GA8809@convergence.de> Mail-Followup-To: Johannes Stezenbach , Ralf Baechle , Adrian.Hulse@taec.toshiba.com, linux-mips@oss.sgi.com References: <20020215034958.C21011@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020215034958.C21011@dea.linux-mips.net> User-Agent: Mutt/1.3.27i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1473 Lines: 39 On Fri, Feb 15, 2002 at 03:49:58AM +0100, Ralf Baechle wrote: > On Thu, Feb 14, 2002 at 01:42:31PM -0800, Adrian.Hulse@taec.toshiba.com wrote: > > > int-handler.s:59: Error: missing ')' > > int-handler.s:59: Error: illegal operands `lui' > > int-handler.s:60: Error: missing ')' > > int-handler.s:60: Error: illegal operands `sb' > > make[1]: *** [ int-handler.o ] Error 1 ... > > int-handler.S > > lui t1, %hi(TSDB_LED_ADDR) > > sb t0, %lo(TSDB_LDE_ADDR)(t1) > > > > Failed define : > > #define TSDB_LED_ADDR (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020) > > > > Compilable define : > > #define TSDB_LED_ADDR KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020 ... > > Anyone else seen anything like this and know of a solution to the problem ? > > Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick > > your own version folklore" method of picking tools :). I had a similar problem with binutils-2.11.92.0.12.3, but Thiemo Seufer posted a patch on the binutils mailing list. Should be fixed in binutils CVS. It seems that it worked with the binutils-2.10.91.0.2 recommended here: http://www.junsun.net/linux/porting-howto/ > I hope that for binutils we can solve that problem when 2.9.12 gets > released; as for gcc it seems Maciej's 2.95.3 version is already pretty > close to what we want. C++ users may disagree ;-) Somewhat longer term > Algorithmics's toolchain should resolve the situation. ;-) Regards, Johannes From owner-linux-mips@oss.sgi.com Fri Feb 15 09:11:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FHB8H28845 for linux-mips-outgoing; Fri, 15 Feb 2002 09:11:08 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FHAa928781; Fri, 15 Feb 2002 09:10:36 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA08397; Fri, 15 Feb 2002 08:06:11 -0800 (PST) mail_from (agx@gandalf.physik.uni-konstanz.de) Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 0EAF5B489; Fri, 15 Feb 2002 16:42:01 +0100 (CET) Date: Fri, 15 Feb 2002 16:42:01 +0100 From: Guido Guenther To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215164201.A21563@gandalf.physik.uni-konstanz.de> Mail-Followup-To: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@oss.sgi.com References: <20020215130613.A301@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 Fri, Feb 15, 2002 at 03:17:17PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7350 Lines: 243 On Fri, Feb 15, 2002 at 03:17:17PM +0100, Maciej W. Rozycki wrote: > > linux-2.4.17/drivers/char/Config.in > > --- linux-2.4.17.orig/drivers/char/Config.in Sun Dec 2 12:34:40 2001 > > +++ linux-2.4.17/drivers/char/Config.in Fri Feb 15 10:00:59 2002 > > @@ -199,6 +199,7 @@ > > tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT > > tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT > > tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT > > + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG > > fi > > endmenu > > This looks suspicious. Haven't you meant "dep_tristate"? Especially as > indydog.c doesn't seem to make any effort to validate it's running on the > system it thinks it is before poking random memory locations. It won't > probably even compile for a non-MIPS kernel. Oh yes. Thanks. I missed that when moving it out of IP22 specific stuff. While we're at this: The machine selection in config.in is of type bool. Shouldn't this be of type "choice"? Do we really support several(arbitrary) machine selections in one kernel? -- Guido Does this look better? diff --exclude=CVS -Naur linux-2.4.17.orig/Documentation/Configure.help linux-2.4.17/Documentation/Configure.help --- linux-2.4.17.orig/Documentation/Configure.help Sat Dec 29 06:37:46 2001 +++ linux-2.4.17/Documentation/Configure.help Fri Feb 15 09:55:06 2002 @@ -3129,6 +3129,13 @@ via the file /proc/rtc and its behaviour is set by various ioctls on /dev/rtc. +Indy/I2 Hardware Watchdog +CONFIG_INDYDOG + Hardwaredriver for the Indy's/I2's watchdog. This is a + watchdog timer that will reboot the machine after a 60 second + timer expired and no process has written to /dev/watchdog during + that time. + Support the Bell Technologies HUB6 card CONFIG_HUB6 Say Y here to enable support in the dumb serial driver to support diff --exclude=CVS -Naur linux-2.4.17.orig/arch/mips/sgi-ip22/ip22-mc.c linux-2.4.17/arch/mips/sgi-ip22/ip22-mc.c --- linux-2.4.17.orig/arch/mips/sgi-ip22/ip22-mc.c Tue Nov 27 16:57:11 2001 +++ linux-2.4.17/arch/mips/sgi-ip22/ip22-mc.c Fri Feb 15 09:55:07 2002 @@ -82,6 +82,14 @@ * interrupts are first enabled etc. */ + /* Step 0: Make sure we turn off the watchdog in case it's + * still running (which might be the case after a + * soft reboot). + */ + tmpreg = mcmisc_regs->cpuctrl0; + tmpreg &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = tmpreg; + /* Step 1: The CPU/GIO error status registers will not latch * up a new error status until the register has been * cleared by the cpu. These status registers are diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/Config.in linux-2.4.17/drivers/char/Config.in --- linux-2.4.17.orig/drivers/char/Config.in Sun Dec 2 12:34:40 2001 +++ linux-2.4.17/drivers/char/Config.in Fri Feb 15 10:00:59 2002 @@ -199,6 +199,7 @@ tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT + dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG $CONFIG_SGI_IP22 fi endmenu diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/Makefile linux-2.4.17/drivers/char/Makefile --- linux-2.4.17.orig/drivers/char/Makefile Mon Jan 7 04:33:54 2002 +++ linux-2.4.17/drivers/char/Makefile Fri Feb 15 09:55:07 2002 @@ -245,6 +245,7 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o +obj-$(CONFIG_INDYDOG) += indydog.o subdir-$(CONFIG_MWAVE) += mwave ifeq ($(CONFIG_MWAVE),y) diff --exclude=CVS -Naur linux-2.4.17.orig/drivers/char/indydog.c linux-2.4.17/drivers/char/indydog.c --- linux-2.4.17.orig/drivers/char/indydog.c Thu Jan 1 01:00:00 1970 +++ linux-2.4.17/drivers/char/indydog.c Fri Feb 15 09:55:07 2002 @@ -0,0 +1,158 @@ +/* + * IndyDog 0.2 A Hardware Watchdog Device for SGI IP22 + * + * (c) Copyright 2002 Guido Guenther , All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * based on softdog.c by Alan Cox + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int indydog_alive; +static struct sgimc_misc_ctrl *mcmisc_regs; + +static void indydog_ping() +{ + mcmisc_regs->watchdogt = 0; +} + + +/* + * Allow only one person to hold it open + */ + +static int indydog_open(struct inode *inode, struct file *file) +{ + u32 mc_ctrl0; + + if(indydog_alive) + return -EBUSY; +#ifdef CONFIG_WATCHDOG_NOWAYOUT + MOD_INC_USE_COUNT; +#endif + /* + * Activate timer + */ + mcmisc_regs = (struct sgimc_misc_ctrl *)(KSEG1+0x1fa00000); + + mc_ctrl0 = mcmisc_regs->cpuctrl0 | SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + indydog_ping(); + + indydog_alive=1; + printk("Started watchdog timer.\n"); + return 0; +} + +static int indydog_release(struct inode *inode, struct file *file) +{ + /* + * Shut off the timer. + * Lock it in if it's a module and we defined ...NOWAYOUT + */ + lock_kernel(); +#ifndef CONFIG_WATCHDOG_NOWAYOUT + { + u32 mc_ctrl0 = mcmisc_regs->cpuctrl0; + mc_ctrl0 &= ~SGIMC_CCTRL0_WDOG; + mcmisc_regs->cpuctrl0 = mc_ctrl0; + printk("Stopped watchdog timer.\n"); + } +#endif + indydog_alive=0; + unlock_kernel(); + return 0; +} + +static ssize_t indydog_write(struct file *file, const char *data, size_t len, loff_t *ppos) +{ + /* Can't seek (pwrite) on this device */ + if (ppos != &file->f_pos) + return -ESPIPE; + + /* + * Refresh the timer. + */ + if(len) { + indydog_ping(); + return 1; + } + return 0; +} + +static int indydog_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + static struct watchdog_info ident = { + identity: "Hardware Watchdog for SGI IP22", + }; + switch (cmd) { + default: + return -ENOIOCTLCMD; + case WDIOC_GETSUPPORT: + if(copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))) + return -EFAULT; + return 0; + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + return put_user(0,(int *)arg); + case WDIOC_KEEPALIVE: + indydog_ping(); + return 0; + } +} + +static struct file_operations indydog_fops = { + owner: THIS_MODULE, + write: indydog_write, + ioctl: indydog_ioctl, + open: indydog_open, + release: indydog_release, +}; + +static struct miscdevice indydog_miscdev = { + minor: WATCHDOG_MINOR, + name: "watchdog", + fops: &indydog_fops, +}; + +static const char banner[] __initdata = KERN_INFO "Hardware Watchdog Timer for SGI IP22: 0.2\n"; + +static int __init watchdog_init(void) +{ + int ret; + + ret = misc_register(&indydog_miscdev); + + if (ret) + return ret; + + printk(banner); + + return 0; +} + +static void __exit watchdog_exit(void) +{ + misc_deregister(&indydog_miscdev); +} + +module_init(watchdog_init); +module_exit(watchdog_exit); +MODULE_LICENSE("GPL"); From owner-linux-mips@oss.sgi.com Fri Feb 15 09:19:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FHJpp29953 for linux-mips-outgoing; Fri, 15 Feb 2002 09:19:51 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FHJc929888; Fri, 15 Feb 2002 09:19:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA09259; Fri, 15 Feb 2002 17:19:32 +0100 (MET) Date: Fri, 15 Feb 2002 17:19:31 +0100 (MET) From: "Maciej W. Rozycki" To: Guido Guenther cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer In-Reply-To: <20020215164201.A21563@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 Content-Length: 584 Lines: 18 On Fri, 15 Feb 2002, Guido Guenther wrote: > While we're at this: The machine selection in config.in is of type bool. Shouldn't this > be of type "choice"? Do we really support several(arbitrary) machine selections in > one kernel? Not at this time, AFAIK, but the intent is to do one day, I believe, at least for ones that it's possible. > Does this look better? OK for me. -- + 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 Feb 15 11:59:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FJxRV07274 for linux-mips-outgoing; Fri, 15 Feb 2002 11:59:27 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FJxP907268 for ; Fri, 15 Feb 2002 11:59:25 -0800 Received: from delllaptop (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g1FIxOq02065 for ; Fri, 15 Feb 2002 10:59:24 -0800 From: "Robert Rusek" To: Subject: SGI Question Date: Fri, 15 Feb 2002 10:53:38 -0800 Message-ID: <000901c1b652$146680c0$631510ac@delllaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 270 Lines: 10 Is it possible to build a linux root from within IRIX? I created an efs partition on a new drive. Can I build the root on the new drive then point to it from my Linux kernel? If not, is there any benefit of running a dual os on the system? Thanks. -- Robert Rusek From owner-linux-mips@oss.sgi.com Fri Feb 15 12:00:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FK07307396 for linux-mips-outgoing; Fri, 15 Feb 2002 12:00:07 -0800 Received: from crack-ext.ab.videon.ca (crack-ext.ab.videon.ca [206.75.216.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FK03907389 for ; Fri, 15 Feb 2002 12:00:03 -0800 Received: (qmail 7774 invoked from network); 15 Feb 2002 19:00:01 -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 ; 15 Feb 2002 19:00:01 -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 16bnaS-0002rM-00; Fri, 15 Feb 2002 12:00:00 -0700 Date: Fri, 15 Feb 2002 12:00:00 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.debian.net To: "Kevin D. Kissell" cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <006e01c1b606$27b1b060$0deca8c0@Ulysses> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 853 Lines: 21 On Fri, 15 Feb 2002, Kevin D. Kissell wrote: > That is, I would say, a bug in the TX39 implementation of SYNC. > The specification is states that all stores prior to the SYNC must > complete before any memory ops after the sync, and that the > definition of a store completing is that all stored values be > "visible to every other processor in the system", which pretty > clearly implies that the write buffers must be flushed. Sorry, why? If the TX39 is the only processor in the system then write buffers can be left alone. You can't consider PCI IO devices to be processors because the bus protocols would never allow you to satisfy the requirements for 'sync'. IMHO the only time *mb should care about a write buffer is if the buffer breaks PCI ordering semantics, by, say returning reads from posted write data, re-ordering, etc. Jason From owner-linux-mips@oss.sgi.com Fri Feb 15 12:39:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FKdNY07888 for linux-mips-outgoing; Fri, 15 Feb 2002 12:39:23 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FKdG907883 for ; Fri, 15 Feb 2002 12:39:17 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA14500; Fri, 15 Feb 2002 20:39:11 +0100 (MET) Date: Fri, 15 Feb 2002 20:39:09 +0100 (MET) From: "Maciej W. Rozycki" To: Jason Gunthorpe cc: "Kevin D. Kissell" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1305 Lines: 31 On Fri, 15 Feb 2002, Jason Gunthorpe wrote: > Sorry, why? If the TX39 is the only processor in the system then write > buffers can be left alone. You can't consider PCI IO devices to be That depends on the implementation of the buffers. > processors because the bus protocols would never allow you to satisfy the > requirements for 'sync'. Fully agreed -- I've already expressed that in another mail. > IMHO the only time *mb should care about a write buffer is if the buffer > breaks PCI ordering semantics, by, say returning reads from posted write > data, re-ordering, etc. Well, the "classic" MIPS R2020 and R3220 ones would break PCI (or actually any I/O) ordering semantics as they return data from a posted write upon a hit. The affected read never appears at the I/O bus in that case. They never reorder writes though, as they work as FIFOs (the former is four stage deep and the latter is six stage deep), so wmb() may be null for them. I've read a suggestion a "bc0f" might be needed for the TX39's write buffer as a barrier. That means the buffer behaves as the "classic" ones. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Feb 15 12:40:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FKefK08086 for linux-mips-outgoing; Fri, 15 Feb 2002 12:40:41 -0800 Received: from dea.linux-mips.net (a1as10-p172.stg.tli.de [195.252.189.172]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FKeb908059 for ; Fri, 15 Feb 2002 12:40:38 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1FJapp20048; Fri, 15 Feb 2002 20:36:51 +0100 Date: Fri, 15 Feb 2002 20:36:51 +0100 From: Ralf Baechle To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: SGI Question Message-ID: <20020215203651.A6491@dea.linux-mips.net> References: <000901c1b652$146680c0$631510ac@delllaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000901c1b652$146680c0$631510ac@delllaptop>; from robru@teknuts.com on Fri, Feb 15, 2002 at 10:53:38AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 461 Lines: 14 On Fri, Feb 15, 2002 at 10:53:38AM -0800, Robert Rusek wrote: > Is it possible to build a linux root from within IRIX? I created an efs > partition on a new drive. Can I build the root on the new drive then > point to it from my Linux kernel? Not really. Linux has only read-only support for EFS filesystems. > If not, is there any benefit of running a dual os on the system? You have twice as many possibilities to get angry about an OS ;-) Ralf > From owner-linux-mips@oss.sgi.com Fri Feb 15 13:33:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FLXDd10126 for linux-mips-outgoing; Fri, 15 Feb 2002 13:33:13 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FLX6910110; Fri, 15 Feb 2002 13:33:07 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g1FKX5J11137; Fri, 15 Feb 2002 15:33:05 -0500 Date: Fri, 15 Feb 2002 15:33:05 -0500 From: Jim Paris To: Ralf Baechle Cc: "Maciej W. Rozycki" , Guido Guenther , linux-mips@oss.sgi.com Subject: Re: ip22 watchdog timer Message-ID: <20020215153305.A11087@neurosis.mit.edu> Reply-To: jim@jtan.com References: <20020215130613.A301@gandalf.physik.uni-konstanz.de> <20020215152132.A602@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020215152132.A602@dea.linux-mips.net>; from ralf@oss.sgi.com on Fri, Feb 15, 2002 at 03:21:32PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 733 Lines: 20 > > BTW, why do people insist on sending patches as attachments -- it makes > > commenting them helly twisted, sigh... > > How true. MIME - broken solution for a broken design ;) More serious, > MIME makes sense when using a MUA that garbles patches like Netscape or > certain versions of Pine. > > Ralf (Prolly still be using Mutt + vi in 5 years ...) Patches as attachments are actually really convenient with Mutt. You can view them seperately, extract and save them easily, etc. To comment on both the original message and the attachments: use view-attachments (v), use tag-entry (t) on all of the parts you want quoted in your reply, and then use tag-prefix & reply (;r) (or ;g or whatever). But I digress :) -jim From owner-linux-mips@oss.sgi.com Fri Feb 15 14:02:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1FM2QV13408 for linux-mips-outgoing; Fri, 15 Feb 2002 14:02:26 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1FM2I913403; Fri, 15 Feb 2002 14:02:18 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1FL2HR31050; Fri, 15 Feb 2002 13:02:17 -0800 From: "Matthew Dharm" To: "Ralf Baechle" , "Maciej W. Rozycki" Cc: "Guido Guenther" , Subject: RE: ip22 watchdog timer Date: Fri, 15 Feb 2002 13:02:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020215160601.A845@dea.linux-mips.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1924 Lines: 54 Oddly enough, I have the exact opposite attitude... I will barely accept inlined patches (to the usb-storage driver, which I maintain). About 85-90% of the inlined patches I get won't apply cleanly because of whitespace mangling. MIME-attachments (of type text/plain) seem to have a _much_ higher success rate. Yes, the transition was painful. Heck, it still is. Some versions of Outlook still don't understand the RFC-compliant way of attaching a digital signature to a message -- I get complaints from people every so often that all they see is a blank message with two attachments, one of which is the "message" itself, and the other is my signature. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle > Sent: Friday, February 15, 2002 7:06 AM > To: Maciej W. Rozycki > Cc: Guido Guenther; linux-mips@oss.sgi.com > Subject: Re: ip22 watchdog timer > > > On Fri, Feb 15, 2002 at 03:41:49PM +0100, Maciej W. Rozycki wrote: > > > > How true. MIME - broken solution for a broken design > ;) More serious, > > > > Why broken? It's not broken for what it was invented > to, i.e. for > > passing unsafe characters via SMTP. Source patches do > not qualify as > > containing such. > > The transition time from pre-MIME to MIME was pretty > painful. If you'd > have gone through the same pains that I did during the MIME > introduction > you'd probably understand why I call it a broken fix for a > broken system. > Fortunately now that the childhood problems have been > solved MIME looks > alot saner but still I prefer plaintext for patches. > > Ralf > From owner-linux-mips@oss.sgi.com Sat Feb 16 03:52:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GBqgQ26849 for linux-mips-outgoing; Sat, 16 Feb 2002 03:52:42 -0800 Received: from web10208.mail.yahoo.com (web10208.mail.yahoo.com [216.136.130.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GBqd926846 for ; Sat, 16 Feb 2002 03:52:39 -0800 Message-ID: <20020216105239.5160.qmail@web10208.mail.yahoo.com> Received: from [213.23.38.17] by web10208.mail.yahoo.com via HTTP; Sat, 16 Feb 2002 02:52:39 PST Date: Sat, 16 Feb 2002 02:52:39 -0800 (PST) From: Timothy Daly Subject: indigo2 video To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 576 Lines: 19 Hi all. :) AFAIK, none of the SGI graphics cards for the indigo2 are yet supported by linux or X. However, it recently struck me, these machines have EISA slots. It might be pretty straightforward to use an old EISA card like an ATI Mach32 instead. Sure, it's not as cool as an Impact card, but it's perfectly adequate for emacs. Is this a good idea? How would you estimate the effort involved? Thanks for any feedback, Tim __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-linux-mips@oss.sgi.com Sat Feb 16 04:17:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GCHDb27315 for linux-mips-outgoing; Sat, 16 Feb 2002 04:17:13 -0800 Received: from ull.minus-9.com (IDENT:postfix@ull.minus-9.com [195.26.34.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GCH9927312 for ; Sat, 16 Feb 2002 04:17:09 -0800 Received: by ull.minus-9.com (Postfix, from userid 500) id DE43336C922; Sat, 16 Feb 2002 11:20:58 +0000 (GMT) Date: Sat, 16 Feb 2002 11:20:58 +0000 From: Mat Withers To: Timothy Daly Cc: linux-mips@oss.sgi.com Subject: Re: indigo2 video Message-ID: <20020216112058.C8787@minus-9.com> References: <20020216105239.5160.qmail@web10208.mail.yahoo.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: <20020216105239.5160.qmail@web10208.mail.yahoo.com>; from remote_bob@yahoo.com on Sat, Feb 16, 2002 at 02:52:39 -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 805 Lines: 26 Timothy Daly (remote_bob@yahoo.com) wrote: > > Hi all. :) > > AFAIK, none of the SGI graphics cards for the indigo2 are yet > supported by linux or X. However, it recently struck me, these > machines have EISA slots. It might be pretty straightforward to use > an old EISA card like an ATI Mach32 instead. Sure, it's not as cool > as an Impact card, but it's perfectly adequate for emacs. > > Is this a good idea? How would you estimate the effort involved? > I was also wondering this. On the intel architecture EISA slots also supported ISA cards. Is this also the case on the Indigo 2 ? or are the EISA slots a bit more "non-standard". Just a thought Mat -- Mat Withers mat@minus-9.com http://minus-9.com phone/fax: +44 7092 375299 "a sarcasm detector, *that's* a real useful invention." From owner-linux-mips@oss.sgi.com Sat Feb 16 10:32:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GIWbn30505 for linux-mips-outgoing; Sat, 16 Feb 2002 10:32:37 -0800 Received: from localhost (adsl-64-166-230-246.dsl.snfc21.pacbell.net [64.166.230.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GIWW930502 for ; Sat, 16 Feb 2002 10:32:35 -0800 Received: from localhost ([127.0.0.1] helo=snort.org) by localhost with esmtp (Exim 3.34 #1 (Debian)) id 16c8g9-0005bX-00; Sat, 16 Feb 2002 09:31:17 -0800 Message-ID: <3C6E9764.31A271D8@snort.org> Date: Sat, 16 Feb 2002 09:31:16 -0800 From: "Andrew R. Baker" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mat Withers CC: Timothy Daly , linux-mips@oss.sgi.com Subject: Re: indigo2 video References: <20020216105239.5160.qmail@web10208.mail.yahoo.com> <20020216112058.C8787@minus-9.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 441 Lines: 12 Mat Withers wrote: > > I was also wondering this. On the intel architecture EISA slots also > supported ISA cards. Is this also the case on the Indigo 2 ? or are the > EISA slots a bit more "non-standard". The EISA slots on the Indigo2 do support ISA cards. I was running an old 3Com Etherlink III card in a Linux Indigo2 several years ago. Running a video card on one of them may be a bit more tricky, but should be possible. -Andrew From owner-linux-mips@oss.sgi.com Sat Feb 16 13:55:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GLtRM32343 for linux-mips-outgoing; Sat, 16 Feb 2002 13:55:27 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GLtO932338 for ; Sat, 16 Feb 2002 13:55:24 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id g1GKtIU19243; Sat, 16 Feb 2002 15:55:18 -0500 Date: Sat, 16 Feb 2002 15:55:18 -0500 From: Jim Paris To: "Andrew R. Baker" Cc: Mat Withers , Timothy Daly , linux-mips@oss.sgi.com Subject: Re: indigo2 video Message-ID: <20020216155518.A19235@neurosis.mit.edu> Reply-To: jim@jtan.com References: <20020216105239.5160.qmail@web10208.mail.yahoo.com> <20020216112058.C8787@minus-9.com> <3C6E9764.31A271D8@snort.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6E9764.31A271D8@snort.org>; from andrewb@snort.org on Sat, Feb 16, 2002 at 09:31:16AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 752 Lines: 16 > > I was also wondering this. On the intel architecture EISA slots also > > supported ISA cards. Is this also the case on the Indigo 2 ? or are the > > EISA slots a bit more "non-standard". > > The EISA slots on the Indigo2 do support ISA cards. I was running an > old 3Com Etherlink III card in a Linux Indigo2 several years ago. > Running a video card on one of them may be a bit more tricky, but should > be possible. You're going to have a problem initializing the card because you won't be able to execute the BIOS. Solutions would be to disassemble the ROM on your particular card and see what it's doing (all cards I've seen are initialized slightly differently); or perhaps some cool solution involving an x86 emulator like Bochs. -jim From owner-linux-mips@oss.sgi.com Sat Feb 16 22:54:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1H6sMJ05583 for linux-mips-outgoing; Sat, 16 Feb 2002 22:54:22 -0800 Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1H6r8905556 for ; Sat, 16 Feb 2002 22:53:08 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217055302.PMOK2626.rwcrmhc51.attbi.com@ocean.lucon.org>; Sun, 17 Feb 2002 05:53:02 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B8CCC125C7; Sat, 16 Feb 2002 21:52:58 -0800 (PST) Date: Sat, 16 Feb 2002 21:52:58 -0800 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: Binutils 2.11.93.0.2 is released Message-ID: <20020216215258.A26150@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14924 Lines: 535 This is the beta release of binutils 2.11.93.0.2 for Linux, which is based on binutils 2002 0207 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.11.93.0.2 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.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.11.93.0.2.tar.gz. Source code. 2. binutils-2.11.92.0.12.3-2.11.93.0.2.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.93.0.2-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.93.0.2.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 02/08/2002 From owner-linux-mips@oss.sgi.com Mon Feb 18 00:59:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I8xwM12794 for linux-mips-outgoing; Mon, 18 Feb 2002 00:59:58 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I8xr912786 for ; Mon, 18 Feb 2002 00:59:53 -0800 Message-Id: <200202180859.g1I8xr912786@oss.sgi.com> Received: (qmail 4574 invoked from network); 18 Feb 2002 08:02:33 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Feb 2002 08:02:33 -0000 Date: Mon, 18 Feb 2002 15:57:4 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" CC: "libc-alpha@sources.redhat.com" , "gcc@gcc.gnu.org" Subject: math broken on mips X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1319 Lines: 33 hi, There are so many problems on math handling for linux-mips,including: 1. SNaN & QNan handling(both gcc & glibc) 2. gcc2.96 generates wrong code with -O2,at least one will lead to exception handling problem(reported by me) one will lead to some 'long long' type mishandling(reported by Atsushi Nemoto) (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is a segment fault when using ld.so.1: ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv: ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o xbootparam_prot.T make[1]: *** [xbootparam_prot.stmp] Segmentation fault ) 3. problems with math-emu 4. other problems to be investigated for its cause,including this one, pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD = 64.1547.. when rounding = DOWNWARD or TOWARDZERO when today i find out the above problem I was feeling almost despaired:( I want to fix these problems,if i could.But it concerns so many things that i am not expert on and no time to dig:(. So any help will be highly appreciated. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Feb 18 01:18:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I9ID413310 for linux-mips-outgoing; Mon, 18 Feb 2002 01:18:13 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1I9I8913300 for ; Mon, 18 Feb 2002 01:18:08 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020218081802.UYLG1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Mon, 18 Feb 2002 08:18:02 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id A0024125C1; Mon, 18 Feb 2002 00:18:01 -0800 (PST) Date: Mon, 18 Feb 2002 00:18:01 -0800 From: "H . J . Lu" To: Zhang Fuxin Cc: "linux-mips@oss.sgi.com" , "libc-alpha@sources.redhat.com" , "gcc@gcc.gnu.org" Subject: Re: math broken on mips Message-ID: <20020218001801.A21719@lucon.org> References: <200202180859.g1I8xr912786@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: <200202180859.g1I8xr912786@oss.sgi.com>; from fxzhang@ict.ac.cn on Mon, Feb 18, 2002 at 03:57:04PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1563 Lines: 43 On Mon, Feb 18, 2002 at 03:57:04PM +0800, Zhang Fuxin wrote: > > (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile > current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is > a segment fault when using ld.so.1: > ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv: > ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o > xbootparam_prot.T You need to get the current glibc/gcc from CVS. You also need to apply my glibc patches for mips if they are not in CVS yet. They are: 2002-01-20 H.J. Lu * config.make.in (inline-limit): New. * configure.in: Check if gcc supports -finline-limit=xxx. * configure: Rebuild. * elf/Makefile (CFLAGS-rtld.c): Set to -finline-limit=2000 if needed. 2002-02-04 H.J. Lu * elf/dl-conflict.c (_dl_resolve_conflicts): Dummy if _DL_HAVE_NO_ELF_MACHINE_RELA is defined. 2001-07-10 H.J. Lu * sysdeps/unix/sysv/linux/powerpc/mmap64.c: Moved to ... * sysdeps/unix/sysv/linux/mmap64.c: Here. * sysdeps/unix/sysv/linux/mmap64.c (MMAP2_PAGE_SHIFT): Renamed from PAGE_SHIFT. Define if not defined. Check MMAP2_PAGE_SHIFT only if __NR_mmap2 is defined. * sysdeps/unix/sysv/linux/hppa/mmap64.c : Removed. * sysdeps/unix/sysv/linux/sparc/sparc32/mmap64.c: Likewise. Please check the glibc mailing list archive for those patches. H.J. From owner-linux-mips@oss.sgi.com Mon Feb 18 02:05:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IA5at14953 for linux-mips-outgoing; Mon, 18 Feb 2002 02:05:36 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IA5R914950 for ; Mon, 18 Feb 2002 02:05:27 -0800 Message-Id: <200202181005.g1IA5R914950@oss.sgi.com> Received: (qmail 6316 invoked from network); 18 Feb 2002 09:08:05 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Feb 2002 09:08:05 -0000 Date: Mon, 18 Feb 2002 17:2:22 +0800 From: Zhang Fuxin To: Hartvig Ekner CC: "linux-mips@oss.sgi.com" Subject: Re: Re: math broken on mips 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 g1IA5S914951 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2554 Lines: 73 hi, Thank you very much. I will gather all the problems and examples to show them i know and post them today. Please wait for some time. ÔÚ 2002-02-18 09:16:00 you wrote£ş >Hi Zhang, > >we're talking to Algorithmics about the possibility of productizing their >SDE compiler for Linux. If this materializes, we should be able to get the >GCC issues you mention fixed. > >Could you therefore pls. send me examples showing all the GCC issues you >mention: > >1) SNan & QNan handling wrong >2) Wrong code generated with -O2 (exception handling problem) >3) Wrong code generated with -O2 (long long type problem) > >I would like (small!) examples suitable for inclusion directly in a work I like small one too:). >specification, so items like "Mozilla doesn't run" is not good enough :-) > >Finally, Kjeld E. at MIPS is spending some time on math-emu. So if you have >specific issues, you can try to mail him as well (kjelde@mips.com). > >Problem #4 you report could be either in glibc or math-emu. If it's math-emu >we'll fix it. > >/Hartvig > > >Zhang Fuxin writes: >> >> hi, >> There are so many problems on math handling for linux-mips,including: >> 1. SNaN & QNan handling(both gcc & glibc) >> 2. gcc2.96 generates wrong code with -O2,at least >> one will lead to exception handling problem(reported by me) >> one will lead to some 'long long' type mishandling(reported by Atsushi Nemoto) >> >> (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile >> current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is >> a segment fault when using ld.so.1: >> ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv: >> ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o >> xbootparam_prot.T >> make[1]: *** [xbootparam_prot.stmp] Segmentation fault >> ) >> 3. problems with math-emu >> 4. other problems to be investigated for its cause,including this one, >> >> pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD >> = 64.1547.. when rounding = DOWNWARD or TOWARDZERO >> >> when today i find out the above problem I was feeling almost despaired:( >> >> I want to fix these problems,if i could.But it concerns so many things that i am not >> expert on and no time to dig:(. So any help will be highly appreciated. >> >> >> >> >> Regards >> Zhang Fuxin >> fxzhang@ict.ac.cn Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Feb 18 02:12:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IACiJ15133 for linux-mips-outgoing; Mon, 18 Feb 2002 02:12:44 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IACb915128 for ; Mon, 18 Feb 2002 02:12:37 -0800 Message-Id: <200202181012.g1IACb915128@oss.sgi.com> Received: (qmail 6526 invoked from network); 18 Feb 2002 09:15:18 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Feb 2002 09:15:18 -0000 Date: Mon, 18 Feb 2002 17:9:32 +0800 From: Zhang Fuxin To: "H . J . Lu" CC: "linux-mips@oss.sgi.com" Subject: Re: Re: math broken on mips 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 g1IACc915129 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1738 Lines: 53 hi, will try later,thank you. ÔÚ 2002-02-18 00:18:00 you wrote£ş >On Mon, Feb 18, 2002 at 03:57:04PM +0800, Zhang Fuxin wrote: >> >> (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile >> current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is >> a segment fault when using ld.so.1: >> ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv: >> ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o >> xbootparam_prot.T > >You need to get the current glibc/gcc from CVS. You also need to apply >my glibc patches for mips if they are not in CVS yet. They are: > >2002-01-20 H.J. Lu > > * config.make.in (inline-limit): New. > > * configure.in: Check if gcc supports -finline-limit=xxx. > * configure: Rebuild. > > * elf/Makefile (CFLAGS-rtld.c): Set to -finline-limit=2000 if > needed. > >2002-02-04 H.J. Lu > > * elf/dl-conflict.c (_dl_resolve_conflicts): Dummy if > _DL_HAVE_NO_ELF_MACHINE_RELA is defined. > >2001-07-10 H.J. Lu > > * sysdeps/unix/sysv/linux/powerpc/mmap64.c: Moved to ... > * sysdeps/unix/sysv/linux/mmap64.c: Here. > > * sysdeps/unix/sysv/linux/mmap64.c (MMAP2_PAGE_SHIFT): Renamed > from PAGE_SHIFT. Define if not defined. Check MMAP2_PAGE_SHIFT > only if __NR_mmap2 is defined. > > * sysdeps/unix/sysv/linux/hppa/mmap64.c : Removed. > * sysdeps/unix/sysv/linux/sparc/sparc32/mmap64.c: Likewise. > >Please check the glibc mailing list archive for those patches. > > >H.J. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Feb 18 02:55:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IAtEB16058 for linux-mips-outgoing; Mon, 18 Feb 2002 02:55:14 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IAsQ916008 for ; Mon, 18 Feb 2002 02:54:26 -0800 Message-Id: <200202181054.g1IAsQ916008@oss.sgi.com> Received: (qmail 7693 invoked from network); 18 Feb 2002 09:57:06 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 18 Feb 2002 09:57:06 -0000 Date: Mon, 18 Feb 2002 17:51:22 +0800 From: Zhang Fuxin To: Hartvig Ekner CC: "linux-mips@oss.sgi.com" Subject: Re: Re: math broken on mips 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 g1IAsR916009 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14858 Lines: 450 hi, I find that you are asking only gcc related parts,that is related less, here they are(from posts on linux-mips,i cc them to the list in case it is useful,sorry if it brings you inconvenience): 1.about NaN handling -----------------begin of the first problem-------------------------------- I am sorry but it seems i can't fix this without ugly changes. since i am not familiar with gcc code, i decide to leave it to you, but provide some information instead. In gcc there are 3 spaces where the NaN handling is assumed the Intel way. 1. gcc/real.c (the most important one) here the author seems to have known the NaN pattern problem,so he leaves a interface macro for defining non intel NaN patterns: (comment of function "make_nan()",at about line 6219) /* Output a binary NaN bit pattern in the target machine's format. */ /* If special NaN bit patterns are required, define them in tm.h as arrays of unsigned 16-bit shorts. Otherwise, use the default patterns here. */ I have read through this file and decided that the follow defined should be enough for mips: /* NaN pattern,mips QNAN & SNAN is different from intel's * DFMODE_NAN and SFMODE_NAN is used in real.c */ #define DFMODE_NAN \ unsigned short DFbignan[4] = {0x7ff7, 0xffff, 0xffff, 0xffff}; \ unsigned short DFlittlenan[4] = {0xffff, 0xffff, 0xffff, 0xfff7} #define SFMODE_NAN \ unsigned short SFbignan[2] = {0x7fbf, 0xffff}; \ unsigned short SFlittlenan[2] = {0xffff, 0xffbf} But the problem is where to put them:(. Obviously it is target specified definitions and should be in config/mips/. Documents say tm.h is a symbol link and included in config.h,but it is no long true.If i add them to xm-mips.h then for native compilation it is ok but it fails for cross-compile. 2.gcc/reg-stack.c (H.J. tell me it is not used on mips) There is a hardcoded QNaN used around line 477: nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); I sugest defining a macro QNAN_HAS_1ST_FRACBIT_CLEARED for mips and change it to,just don't know where to put it: #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); #else nan = gen_lowpart (SFmode, GEN_INT (0x7fbfffff)); #endif 3. config/fp-bit.c (H.J. said it is not mean to target specified) this is for machine having no fpu hardware. again i susgest define QNAN_HAS_1ST_FRACBIT_CLEARED and then apply this patch: 190d189 < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED 192,195d190 < #else < fraction &= ~QUIET_NAN; < #endif < 379,380d373 < < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED 382,384d374 < #else < if (!(fraction & QUIET_NAN)) < #endif ÔÚ 2002-02-03 22:54:00 you wrote£ş >On Mon, Feb 04, 2002 at 02:22:48PM +0800, Zhang Fuxin wrote: >> hi, >> >> Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and >> optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu >> (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both >> say so.And experiments confirm this. >> >> Should we correct it? > >Yes. Do you have a patch? > >Thanks. > > >H.J. -------------------------end of first problem-------------------------------- --------------------------begin of the second problem------------------------ 2. gcc -O2 optimization bug No.1 It seems gcc with optimization > -O2 will produce incorrect code for fp code: I find this example when tracking down the libm-test failures. ( expf(NaN) == NaN will report an extra "invalid operation" exception ) The faulting code snippet is(from glibc/sysdeps/ieee754/flt-32/w_expf.c): float __my_expf(float x) /* wrapper expf */ { float z; unsigned int hx; z = __ieee754_expf(x); if(_LIB_VERSION == _IEEE_) return z; if(__finitef(x)) { if(x>o_threshold) return 1.0; else if(x: 401290: 3c1c0fc0 lui gp,0xfc0 401294: 279c6dd0 addiu gp,gp,28112 401298: 0399e021 addu gp,gp,t9 40129c: 27bdffd0 addiu sp,sp,-48 4012a0: afbc0010 sw gp,16(sp) 4012a4: afbf0028 sw ra,40(sp) 4012a8: afbe0024 sw s8,36(sp) 4012ac: afbc0020 sw gp,32(sp) 4012b0: 03a0f021 move s8,sp 4012b4: e7cc0030 swc1 $f12,48(s8) 4012b8: c7cc0030 lwc1 $f12,48(s8) 4012bc: 8f998088 lw t9,-32632(gp) 4012c0: 00000000 nop 4012c4: 0320f809 jalr t9 4012c8: 00000000 nop 4012cc: 8fdc0010 lw gp,16(s8) 4012d0: e7c00018 swc1 $f0,24(s8) 4012d4: 8f8380ac lw v1,-32596(gp) 4012d8: 00000000 nop 4012dc: 8c630000 lw v1,0(v1) 4012e0: 2402ffff li v0,-1 4012e4: 14620004 bne v1,v0,4012f8 <__my_expf+0x68> 4012e8: 00000000 nop 4012ec: c7c00018 lwc1 $f0,24(s8) 4012f0: 10000032 b 4013bc <__my_expf+0x12c> 4012f4: 00000000 nop 4012f8: c7cc0030 lwc1 $f12,48(s8) 4012fc: 8f998090 lw t9,-32624(gp) 401300: 00000000 nop 401304: 0320f809 jalr t9 401308: 00000000 nop 40130c: 8fdc0010 lw gp,16(s8) 401310: 10400029 beqz v0,4013b8 <__my_expf+0x128> 401314: 00000000 nop 401318: c7c20030 lwc1 $f2,48(s8) 40131c: 8f818018 lw at,-32744(gp) 401320: 00000000 nop 401324: 242142a0 addiu at,at,17056 401328: c4200000 lwc1 $f0,0(at) 40132c: 00000000 nop 401330: 4602003c c.lt.s $f0,$f2 401334: 00000000 nop 401338: 45010003 bc1t 401348 <__my_expf+0xb8> 40133c: 00000000 nop 401340: 10000005 b 401358 <__my_expf+0xc8> 401344: 00000000 nop 401348: 3c013f80 lui at,0x3f80 40134c: 44810000 mtc1 at,$f0 401350: 1000001a b 4013bc <__my_expf+0x12c> 401354: 00000000 nop 401358: c7c20030 lwc1 $f2,48(s8) 40135c: 8f818018 lw at,-32744(gp) 401360: 00000000 nop 401364: 242142a4 addiu at,at,17060 401368: c4200000 lwc1 $f0,0(at) 40136c: 00000000 nop 401370: 4600103c c.lt.s $f2,$f0 401374: 00000000 nop 401378: 45010003 bc1t 401388 <__my_expf+0xf8> 40137c: 00000000 nop 401380: 10000005 b 401398 <__my_expf+0x108> 401384: 00000000 nop 401388: 3c014000 lui at,0x4000 40138c: 44810000 mtc1 at,$f0 401390: 1000000a b 4013bc <__my_expf+0x12c> 401394: 00000000 nop 401398: 8f848018 lw a0,-32744(gp) 40139c: 00000000 nop 4013a0: 248442a8 addiu a0,a0,17064 4013a4: 8f998058 lw t9,-32680(gp) 4013a8: 00000000 nop 4013ac: 0320f809 jalr t9 4013b0: 00000000 nop 4013b4: 8fdc0010 lw gp,16(s8) 4013b8: c7c00018 lwc1 $f0,24(s8) 4013bc: 03c0e821 move sp,s8 4013c0: 8fbf0028 lw ra,40(sp) 4013c4: 8fbe0024 lw s8,36(sp) 4013c8: 03e00008 jr ra 4013cc: 27bd0030 addiu sp,sp,48 2. with -O2 0000000000400fc0 <__my_expf>: 400fc0: 3c1c0fc0 lui gp,0xfc0 400fc4: 279c70a0 addiu gp,gp,28832 400fc8: 0399e021 addu gp,gp,t9 400fcc: 27bdffd0 addiu sp,sp,-48 400fd0: afbc0010 sw gp,16(sp) 400fd4: e7b60028 swc1 $f22,40(sp) 400fd8: e7b7002c swc1 $f23,44(sp) 400fdc: e7b40020 swc1 $f20,32(sp) 400fe0: e7b50024 swc1 $f21,36(sp) 400fe4: afbf001c sw ra,28(sp) 400fe8: 46006506 mov.s $f20,$f12 400fec: afbc0018 sw gp,24(sp) 400ff0: 8f998088 lw t9,-32632(gp) 400ff4: 00000000 nop 400ff8: 0320f809 jalr t9 400ffc: 00000000 nop 401000: 8fbc0010 lw gp,16(sp) 401004: 00000000 nop 401008: 8f8380ac lw v1,-32596(gp) 40100c: 00000000 nop 401010: 8c630000 lw v1,0(v1) 401014: 2402ffff li v0,-1 401018: 46000586 mov.s $f22,$f0 40101c: 10620021 beq v1,v0,4010a4 <__my_expf+0xe4> 401020: 4600a306 mov.s $f12,$f20 401024: 8f998090 lw t9,-32624(gp) 401028: 00000000 nop 40102c: 0320f809 jalr t9 401030: 00000000 nop 401034: 8fbc0010 lw gp,16(sp) 401038: 3c0142b1 lui at,0x42b1 40103c: 34217180 ori at,at,0x7180 401040: 44811000 mtc1 at,$f2 401044: 3c013f80 lui at,0x3f80 401048: 44810000 mtc1 at,$f0 40104c: 4614103c c.lt.s $f2,$f20 // this is wrongly put ahead ? 401050: 10400013 beqz v0,4010a0 <__my_expf+0xe0> 401054: 00000000 nop 401058: 45010012 bc1t 4010a4 <__my_expf+0xe4> 40105c: 00000000 nop 401060: 3c01c2cf lui at,0xc2cf 401064: 3421f1b5 ori at,at,0xf1b5 401068: 44810000 mtc1 at,$f0 40106c: 8f848018 lw a0,-32744(gp) 401070: 00000000 nop 401074: 24843fa8 addiu a0,a0,16296 401078: 4600a03c c.lt.s $f20,$f0 40107c: 3c014000 lui at,0x4000 401080: 44810000 mtc1 at,$f0 401084: 45010007 bc1t 4010a4 <__my_expf+0xe4> 401088: 00000000 nop 40108c: 8f998058 lw t9,-32680(gp) 401090: 00000000 nop 401094: 0320f809 jalr t9 401098: 00000000 nop 40109c: 8fbc0010 lw gp,16(sp) 4010a0: 4600b006 mov.s $f0,$f22 4010a4: 8fbf001c lw ra,28(sp) 4010a8: c7b60028 lwc1 $f22,40(sp) 4010ac: c7b7002c lwc1 $f23,44(sp) 4010b0: c7b40020 lwc1 $f20,32(sp) 4010b4: c7b50024 lwc1 $f21,36(sp) 4010b8: 03e00008 jr ra 4010bc: 27bd0030 addiu sp,sp,48 ----------------------------end of the second problem------------------------ ----------------------------begin of 3rd problem----------------------------- 3.wrong code from gcc -O2,No.2 hi, it seems fixed in latest gcc (3.1). gcc 2.96 does produce wrong code for -O2, i posted another example one or two days ago. ÔÚ 2002-02-08 19:37:00 you wrote£ş >I found gcc 2.96 (gcc-2.96-99.1.mipsel.rpm in H.J.Lu's RedHat 7.1) >outputs wrong code for this short program. > >int foo(unsigned long long a, unsigned long long b) >{ > int as, bs; > as = a >> 63; > bs = b >> 63; > if (as != bs) > return as || !(b << 1); > return (a == b) || as; >} > >int main(int argc, char **argv) >{ > return foo(0, 0xffffffffffffffffull); >} > >This program must return 0. But compiling with -O2 it returns 1 !! > ># gcc -O -o foo foo.c;./foo;echo $? >0 ># gcc -O2 -o foo foo.c;./foo;echo $? >1 > >Output wth -O -g are: > >00400780 : > 400780: 3c1c0fc0 lui gp,0xfc0 > 400784: 279c78b0 addiu gp,gp,30896 > 400788: 0399e021 addu gp,gp,t9 > 40078c: 00804021 move t0,a0 > 400790: 00a04821 move t1,a1 > 400794: 000917c2 srl v0,t1,0x1f > 400798: 00402821 move a1,v0 > 40079c: 000717c2 srl v0,a3,0x1f > 4007a0: 10a2000d beq a1,v0,4007d8 > 4007a4: 00001821 move v1,zero > 4007a8: 14a00008 bnez a1,4007cc > 4007ac: 00004021 move t0,zero > 4007b0: 00071840 sll v1,a3,0x1 > 4007b4: 000627c2 srl a0,a2,0x1f > 4007b8: 00641825 or v1,v1,a0 > 4007bc: 00061040 sll v0,a2,0x1 > 4007c0: 00621025 or v0,v1,v0 > 4007c4: 14400002 bnez v0,4007d0 > 4007c8: 00000000 nop > 4007cc: 24080001 li t0,1 > 4007d0: 03e00008 jr ra > 4007d4: 01001021 move v0,t0 > 4007d8: 15060003 bne t0,a2,4007e8 > 4007dc: 00001021 move v0,zero > 4007e0: 11270003 beq t1,a3,4007f0 > 4007e4: 00000000 nop > 4007e8: 10a00002 beqz a1,4007f4 > 4007ec: 00000000 nop > 4007f0: 24020001 li v0,1 > 4007f4: 03e00008 jr ra > 4007f8: 00000000 nop > >Output with -O2 -g are: > >00400780 : > 400780: 3c1c0fc0 lui gp,0xfc0 > 400784: 279c78b0 addiu gp,gp,30896 > 400788: 0399e021 addu gp,gp,t9 > 40078c: 00805021 move t2,a0 > 400790: 00c04021 move t0,a2 > 400794: 00a05821 move t3,a1 > 400798: 00e04821 move t1,a3 > 40079c: 000b17c2 srl v0,t3,0x1f > 4007a0: 000927c2 srl a0,t1,0x1f > 4007a4: 00001821 move v1,zero > 4007a8: 1044000a beq v0,a0,4007d4 > 4007ac: 00002821 move a1,zero > 4007b0: 14400006 bnez v0,4007cc > 4007b4: 24050001 li a1,1 > 4007b8: 00091840 sll v1,t1,0x1 > 4007bc: 000827c2 srl a0,t0,0x1f > 4007c0: 00641825 or v1,v1,a0 > 4007c4: 00081040 sll v0,t0,0x1 > 4007c8: 00621025 or v0,v1,v0 > 4007cc: 03e00008 jr ra > 4007d0: 00a01021 move v0,a1 > 4007d4: 15480003 bne t2,t0,4007e4 > 4007d8: 00001821 move v1,zero > 4007dc: 11690003 beq t3,t1,4007ec > 4007e0: 00000000 nop > 4007e4: 10400002 beqz v0,4007f0 > 4007e8: 00000000 nop > 4007ec: 24030001 li v1,1 > 4007f0: 03e00008 jr ra > 4007f4: 00601021 move v0,v1 > > >It seems one 'bnez' in good code (at 4007c4) was lost in bad code. > >Is this a know problem? If so, is there any patches available? > >Thank you. >--- >Atsushi Nemoto -----------------------------end of 3rd problem------------------------ ÔÚ 2002-02-18 09:16:00 you wrote£ş >Hi Zhang, > >we're talking to Algorithmics about the possibility of productizing their >SDE compiler for Linux. If this materializes, we should be able to get the >GCC issues you mention fixed. > >Could you therefore pls. send me examples showing all the GCC issues you >mention: > >1) SNan & QNan handling wrong >2) Wrong code generated with -O2 (exception handling problem) >3) Wrong code generated with -O2 (long long type problem) > >I would like (small!) examples suitable for inclusion directly in a work >specification, so items like "Mozilla doesn't run" is not good enough :-) > >Finally, Kjeld E. at MIPS is spending some time on math-emu. So if you have >specific issues, you can try to mail him as well (kjelde@mips.com). > >Problem #4 you report could be either in glibc or math-emu. If it's math-emu >we'll fix it. > >/Hartvig > > >Zhang Fuxin writes: >> >> hi, >> There are so many problems on math handling for linux-mips,including: >> 1. SNaN & QNan handling(both gcc & glibc) >> 2. gcc2.96 generates wrong code with -O2,at least >> one will lead to exception handling problem(reported by me) >> one will lead to some 'long long' type mishandling(reported by Atsushi Nemoto) >> >> (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile >> current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is >> a segment fault when using ld.so.1: >> ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv: >> ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o >> xbootparam_prot.T >> make[1]: *** [xbootparam_prot.stmp] Segmentation fault >> ) >> 3. problems with math-emu >> 4. other problems to be investigated for its cause,including this one, >> >> pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD >> = 64.1547.. when rounding = DOWNWARD or TOWARDZERO >> >> when today i find out the above problem I was feeling almost despaired:( >> >> I want to fix these problems,if i could.But it concerns so many things that i am not >> expert on and no time to dig:(. So any help will be highly appreciated. >> >> >> >> >> Regards >> Zhang Fuxin >> fxzhang@ict.ac.cn Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Feb 18 05:53:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IDrNM27233 for linux-mips-outgoing; Mon, 18 Feb 2002 05:53:23 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IDrG927229 for ; Mon, 18 Feb 2002 05:53:16 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA12886; Mon, 18 Feb 2002 04:53:08 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA04156; Mon, 18 Feb 2002 04:53:04 -0800 (PST) Received: from copsun18.mips.com (copsun18 [192.168.205.28]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g1ICqKA23120; Mon, 18 Feb 2002 13:52:20 +0100 (MET) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun18.mips.com (8.9.1/8.9.0) id NAA03169; Mon, 18 Feb 2002 13:52:47 +0100 (MET) Message-Id: <200202181252.NAA03169@copsun18.mips.com> Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Mon, 18 Feb 2002 13:52:47 +0100 (MET) Cc: hartvige@mips.com (Hartvig Ekner), dom@algor.co.uk (Dominic Sweetman), kevink@mips.com (Kevin D. Kissell), nemoto@toshiba-tops.co.jp (Atsushi Nemoto), mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Feb 15, 2002 02:03:45 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2147 Lines: 51 Maciej W. Rozycki writes: > > On Fri, 15 Feb 2002, Hartvig Ekner wrote: > > > But in-order for the CPU is not enough - it also needs to make sure all > > written data is visible for DMA accesses to memory from the outside, which > > is why the writebuffer needs to be flushed by a SYNC as well. From the > > definition of "SYNC": > > > > "A store is completed when the stored value is visible to every other > > processor in the system". > > > > Which presumably also includes DMA I/O devices... > > The description found in the R4k manual seems to contradict. A "sync" on > a single CPU only assures transactions on it's external bus will happen in > order wrt the "sync". In a multiple-CPU environment all CPUs interested > in a barrier need to execute a "sync". That's seems natural -- how would > you define a synchronization point for a CPU that does not execute a > "sync". You are no doubt correct regarding the R4K manual - so my comment probably only applies for CPU's that claim to be MIPS32/MIPS64 compliant. All MTI's CPU offerings (cores only) do in fact flush the WB on a SYNC to comply with the current spec. > Since I/O devices have no means to signal a CPU a "sync" operation, how > can you expect a "sync" on the CPU to complete all preceding writes to the > device? It's only a following read that may imply it. This I do have a problem understanding. If the SYNC does not flush the WB on some processor/writebuffer combinations, and a read can be satisfied out of the WB, how would you ever be able to guarantee that DMA data written by the CPU has reached memory before triggering the IO device? /Hartvig > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > -- _ _ _____ ____ 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 Feb 18 07:31:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IFV8d01072 for linux-mips-outgoing; Mon, 18 Feb 2002 07:31:08 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IFV2901052 for ; Mon, 18 Feb 2002 07:31:03 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA18433; Mon, 18 Feb 2002 15:24:02 +0100 (MET) Date: Mon, 18 Feb 2002 15:24:02 +0100 (MET) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: Dominic Sweetman , "Kevin D. Kissell" , Atsushi Nemoto , mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <200202181252.NAA03169@copsun18.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1267 Lines: 27 On Mon, 18 Feb 2002, Hartvig Ekner wrote: > You are no doubt correct regarding the R4K manual - so my comment probably > only applies for CPU's that claim to be MIPS32/MIPS64 compliant. All MTI's > CPU offerings (cores only) do in fact flush the WB on a SYNC to comply with > the current spec. Note that the MIPS II spec doesn't forbid a "sync" implementation to be stronger than required. > This I do have a problem understanding. If the SYNC does not flush the WB > on some processor/writebuffer combinations, and a read can be satisfied > out of the WB, how would you ever be able to guarantee that DMA data written > by the CPU has reached memory before triggering the IO device? If after a "sync" an uncached read could be satisfied from an uncommittedd write pending since before the "sync" in a CPU's oncore WB, then the CPU would violate the MIPS II spec of "sync", as the order of transactions at this CPU's external bus would not be preserved. You may exploit this property to do a write-back flush to the host bus -- that's what I added iob() for. -- + 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 Feb 18 12:50:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKonS09945 for linux-mips-outgoing; Mon, 18 Feb 2002 12:50:49 -0800 Received: from moshier.net (moshier.ne.mediaone.net [65.96.130.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IKok909942 for ; Mon, 18 Feb 2002 12:50:46 -0800 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [65.96.130.103]) by moshier.net (8.9.3/8.9.3) with ESMTP id OAA25620; Mon, 18 Feb 2002 14:50:31 -0500 Date: Mon, 18 Feb 2002 14:50:30 -0500 (EST) From: Stephen L Moshier Reply-To: moshier@moshier.net To: Zhang Fuxin cc: linux-mips@oss.sgi.com, Subject: Re: math broken on mips Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 993 Lines: 22 > pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD > = 64.1547.. when rounding = DOWNWARD or TOWARDZERO The libm functions from IBM that were recently installed in glibc come with this remark in sysdeps/ieee754/dbl-64/MathLib.h: /* Assumption: Machine arithmetic operations are performed in */ /* round nearest mode of IEEE 754 standard. */ These math functions use a doubled-precision Dekker arithmetic which is very sensitive to rounding rules and arithetic flaws. Fixing the routines to give reasonable answers with other rounding modes would not be practical. It is customary for a system math library to expect default environment conditions, and I do not think this design actually violates any standards. If you want to use non-default arithmetic settings and have them work portably on various systems, you will have to take defensive steps to protect your program from damage by the operating system and the system library. From owner-linux-mips@oss.sgi.com Mon Feb 18 13:23:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILNgX10652 for linux-mips-outgoing; Mon, 18 Feb 2002 13:23:42 -0800 Received: from moshier.net (moshier.ne.mediaone.net [65.96.130.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILNe910649 for ; Mon, 18 Feb 2002 13:23:40 -0800 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [65.96.130.103]) by moshier.net (8.9.3/8.9.3) with ESMTP id PAA25645; Mon, 18 Feb 2002 15:23:35 -0500 Date: Mon, 18 Feb 2002 15:23:34 -0500 (EST) From: Stephen L Moshier Reply-To: moshier@moshier.net To: Geoff Keating cc: fxzhang@ict.ac.cn, , Subject: Re: math broken on mips In-Reply-To: <200202182018.g1IKIk802891@desire.geoffk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 209 Lines: 9 On Mon, 18 Feb 2002, Geoff Keating wrote: > ... actually, C99 seems to imply that all supported rounding > precisions should work for the math library Could you point out specifically where it says that? From owner-linux-mips@oss.sgi.com Mon Feb 18 13:45:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILjVv11345 for linux-mips-outgoing; Mon, 18 Feb 2002 13:45:31 -0800 Received: from desire.geoffk.org (12-234-190-114.client.attbi.com [12.234.190.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILjS911338 for ; Mon, 18 Feb 2002 13:45:28 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g1IKjM702963; Mon, 18 Feb 2002 12:45:22 -0800 Date: Mon, 18 Feb 2002 12:45:22 -0800 From: Geoff Keating Message-Id: <200202182045.g1IKjM702963@desire.geoffk.org> To: moshier@moshier.net CC: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, libc-alpha@sources.redhat.com In-reply-to: (message from Stephen L Moshier on Mon, 18 Feb 2002 15:23:34 -0500 (EST)) Subject: Re: math broken on mips Reply-to: Geoff Keating References: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 921 Lines: 23 > Date: Mon, 18 Feb 2002 15:23:34 -0500 (EST) > From: Stephen L Moshier > On Mon, 18 Feb 2002, Geoff Keating wrote: > > > ... actually, C99 seems to imply that all supported rounding > > precisions should work for the math library > > Could you point out specifically where it says that? It would have to specifically say that it doesn't, and I can't find that. For example, in s. 7.12.1 para 4, it says that HUGE_VAL is a guaranteed result only in the default rounding mode. Appendix F says, in s. F.9 para 10, "Whether the [elementary] functions honour the rounding direction mode is implementation-defined." but this doesn't allow the functions to produce invalid results, just to ignore the mode and use some other mode instead. A good math library should honour the current rounding mode, as this is what is most useful. -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Mon Feb 18 13:45:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1ILjXL11368 for linux-mips-outgoing; Mon, 18 Feb 2002 13:45:33 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILjU911342 for ; Mon, 18 Feb 2002 13:45:30 -0800 Received: from myware.mynet (fiendish.cygnus.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA19566; Mon, 18 Feb 2002 12:44:58 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g1IKiSY29278; Mon, 18 Feb 2002 12:44:28 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: Geoff Keating Cc: moshier@moshier.net, fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, libc-alpha@sources.redhat.com Subject: Re: math broken on mips References: <200202182018.g1IKIk802891@desire.geoffk.org> Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Feb 2002 12:44:28 -0800 In-Reply-To: <200202182018.g1IKIk802891@desire.geoffk.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 613 Lines: 16 Geoff Keating writes: > Maybe we should add appropriate fesetround() calls to the math > library? No, this would punish the people who do not do stupid things with rounding modes. The user must know much better where such changes are needed. As you mentioned, there is no promise of precision in the standard therefore everything is just fine as it is, standard-wise. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Feb 18 14:06:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IM6LL13034 for linux-mips-outgoing; Mon, 18 Feb 2002 14:06:21 -0800 Received: from moshier.net (moshier.ne.mediaone.net [65.96.130.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IM6J913031 for ; Mon, 18 Feb 2002 14:06:19 -0800 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [65.96.130.103]) by moshier.net (8.9.3/8.9.3) with ESMTP id QAA25674; Mon, 18 Feb 2002 16:06:14 -0500 Date: Mon, 18 Feb 2002 16:06:14 -0500 (EST) From: Stephen L Moshier Reply-To: moshier@moshier.net To: Geoff Keating cc: fxzhang@ict.ac.cn, , Subject: Re: math broken on mips In-Reply-To: <200202182045.g1IKjM702963@desire.geoffk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 184 Lines: 7 > Appendix F says, in s. F.9 para 10, "Whether the [elementary] > functions honour the rounding direction mode is > implementation-defined." Does the glibc documentation define it? From owner-linux-mips@oss.sgi.com Mon Feb 18 14:08:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IM8Lc13115 for linux-mips-outgoing; Mon, 18 Feb 2002 14:08:21 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IM8J913112 for ; Mon, 18 Feb 2002 14:08:19 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 0AB651EA6E; Mon, 18 Feb 2002 22:08:05 +0100 (MET) X-Authentication-Warning: sykes.suse.de: schwab set sender to schwab@suse.de using -f To: Geoff Keating Cc: moshier@moshier.net, fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, libc-alpha@sources.redhat.com Subject: Re: math broken on mips References: <200202182018.g1IKIk802891@desire.geoffk.org> X-Yow: I have many CHARTS and DIAGRAMS.. From: Andreas Schwab Date: Mon, 18 Feb 2002 22:07:59 +0100 In-Reply-To: <200202182018.g1IKIk802891@desire.geoffk.org> (Geoff Keating's message of "Mon, 18 Feb 2002 12:18:46 -0800") Message-ID: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2.50 (ia64-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 431 Lines: 14 Geoff Keating writes: |> ... actually, C99 seems to imply that all supported rounding |> precisions should work for the math library Only if #pragma STDC FENV_ACCESS "on" is in effect. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From owner-linux-mips@oss.sgi.com Mon Feb 18 14:39:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IMdQI13613 for linux-mips-outgoing; Mon, 18 Feb 2002 14:39:26 -0800 Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IMdN913610 for ; Mon, 18 Feb 2002 14:39:23 -0800 Received: from myware.mynet (fiendish.cygnus.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA25095; Mon, 18 Feb 2002 13:39:06 -0800 (PST) Received: (from drepper@localhost) by myware.mynet (8.11.6/8.11.6) id g1ILd4829506; Mon, 18 Feb 2002 13:39:04 -0800 X-Authentication-Warning: myware.mynet: drepper set sender to drepper@redhat.com using -f To: moshier@moshier.net Cc: Geoff Keating , fxzhang@ict.ac.cn, , Subject: Re: math broken on mips References: Reply-To: drepper@redhat.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 18 Feb 2002 13:39:04 -0800 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (asparagus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 641 Lines: 14 Stephen L Moshier writes: > Does the glibc documentation define it? No version of any math library reliably worked with anything but round-to-nearest. Only functions which were implemented using integer operations were immune and this set varied among different platforms. It's not written down but was always said. If somebody wants to add it to the documentation s/he can write something up. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Feb 18 16:13:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J0DxN02903 for linux-mips-outgoing; Mon, 18 Feb 2002 16:13:59 -0800 Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J0Dv902900 for ; Mon, 18 Feb 2002 16:13:57 -0800 Received: from g055068.ppp.asahi-net.or.jp (HELO nazneen) (211.132.55.68) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Feb 2002 23:13:56 -0000 Message-ID: <002301c1b8d2$22a0efe0$443784d3@gol.com> From: "Girish Gulawani" To: Subject: Page Size 16KB. Date: Tue, 19 Feb 2002 08:15:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 570 Lines: 15 hi, all. while in the process of changing page size of kernel to 16KB i am facing a strange problem. the kernel boots up & user command, currently statically linked shell, loads. it displays first prompt. pressing enter keys, the serial device receives the interrupts but no activity on shell's part. where could the shell possibly be stuck? this is LSI MIPS EZ4021 implementation. please please help!!! many thanks & regards, girish. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Mon Feb 18 18:34:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J2YPW04210 for linux-mips-outgoing; Mon, 18 Feb 2002 18:34:25 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J2YM904207 for ; Mon, 18 Feb 2002 18:34:22 -0800 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g1J1YJN15989; Mon, 18 Feb 2002 17:34:19 -0800 Date: Mon, 18 Feb 2002 17:34:19 -0800 From: Matthew Dharm To: Girish Gulawani Cc: linux-mips@oss.sgi.com Subject: Re: Page Size 16KB. Message-ID: <20020218173419.A15980@momenco.com> References: <002301c1b8d2$22a0efe0$443784d3@gol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002301c1b8d2$22a0efe0$443784d3@gol.com>; from girishvg@yahoo.com on Tue, Feb 19, 2002 at 08:15:18AM +0900 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 842 Lines: 24 Does your userspace shell set the CREAD flag properly? Matt On Tue, Feb 19, 2002 at 08:15:18AM +0900, Girish Gulawani wrote: > hi, all. > while in the process of changing page size of kernel to 16KB i am facing a > strange problem. the kernel boots up & user command, currently statically > linked shell, loads. it displays first prompt. pressing enter keys, the > serial device receives the interrupts but no activity on shell's part. where > could the shell possibly be stuck? > this is LSI MIPS EZ4021 implementation. please please help!!! > many thanks & regards, > girish. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Mon Feb 18 19:23:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J3NvI04850 for linux-mips-outgoing; Mon, 18 Feb 2002 19:23:57 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J3Ne904847 for ; Mon, 18 Feb 2002 19:23:40 -0800 Message-Id: <200202190323.g1J3Ne904847@oss.sgi.com> Received: (qmail 29502 invoked from network); 19 Feb 2002 02:26:24 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 19 Feb 2002 02:26:24 -0000 Date: Tue, 19 Feb 2002 10:20:37 +0800 From: Zhang Fuxin To: "linux-mips@oss.sgi.com" CC: "libc-alpha@sources.redhat.com" Subject: endless loop in remainder() on mips X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_Dragon655117627178_=====" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8979 Lines: 152 This is a multi-part message in MIME format. --=====_Dragon655117627178_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit hi, for this testcase,remaider() will enter an endless loop: rounding is TONEAREST x=(7fefffff,ffffffff),y=(00000000,00000001) attached is a little program to test it(gcc t-remainder.c -lm) most important part is listed here: while (l>0) { ... printf("u=(%08lx,%08lx),d=(%08lx,%08lx),w=(%08lx,%08lx)\n",u.i[1],u.i[0],tmp2.i[1],tmp2.i[0],w.i[1],w.i[0]); tmp1.x = d*w.x; tmp2.x = u.x - tmp1.x; u.x=(u.x-d*w.x)/*-d*ww.x*/; printf("d*w=(%08lx,%08lx),u.x-d*w=(%08lx,%08lx),u=(%08lx,%08lx)\n",tmp1.i[1],tmp1.i[0],tmp2.i[1],tmp2.i[0],u.i[1],u.i[0]); l=(u.i[HIGH_HALF]&0x7ff00000)-nn; } It is weird enough for me that u doesn't equal to tmp2,that is where x86 and mips differ. the output from my P4: rounding is TONEAREST x=(7fefffff,ffffffff),y=(00000000,00000001) x=(7fefffff,ffffffff),y=(04d00000,00000000) 1/y=7b100000,00000000 n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fca00000,00000000) <--notice this u=(fca00000,00000000),d=(c1300000,00000000),w=(7b600000,00000000) d*w=(fca00000,00000000),u.x-d*w=(00000000,00000000),u=(00000000,00000000) x=(00000000,00000000),y=(04d00000,00000000) output from mipsel: rounding is TONEAREST x=(7fefffff,ffffffff),y=(00000000,00000001) x=(7fefffff,ffffffff),y=(04d00000,00000000) 1/y=7b100000,00000000 n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fff00000,00000000) <--notice this u=(fff00000,00000000),d=(fff00000,00000000),w=(7eb00000,00000000) d*w=(fff00000,00000000),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) ... Thank you. Regards Zhang Fuxin fxzhang@ict.ac.cn --=====_Dragon655117627178_===== Content-Type: application/octet-stream; name="t-remainder.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="t-remainder.c" I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxtYXRoLmg+CiNpbmNsdWRlIDxmZW52Lmg+CiNp bmNsdWRlIDxlbmRpYW4uaD4KCnR5cGVkZWYgaW50IGludDQ7CnR5cGVkZWYgdW5pb24ge2ludDQg aVsyXTsgZG91YmxlIHg7fSBteW51bWJlcjsKCiNkZWZpbmUgQUJTKHgpICAgKCgoeCk+MCk/KHgp Oi0oeCkpCiNkZWZpbmUgbWF4KHgseSkgICgoKHkpPih4KSk/KHkpOih4KSkKI2RlZmluZSBtaW4o eCx5KSAgKCgoeSk8KHgpKT8oeSk6KHgpKQoKI2RlZmluZSBISUdIX0hBTEYgMQojZGVmaW5lIExP V19IQUxGIDAKI2RlZmluZSBMSVRUTEVfRU5ESQoKc3RhdGljIGNvbnN0IG15bnVtYmVyIGJpZyA9 IHt7MCwgMHg0MzM4MDAwMH19LCAgLyogNjc1NTM5OTQ0MTA1NTc0NCAqLwogICAgICAgICAgICAg ICAgICAgICB0MTI4ID0ge3swLCAweDQ3ZjAwMDAwfX0sICAvKiAgMl4gMTI4ICAgICAgICAgICov CiAgICAgICAgICAgICAgICAgICAgdG0xMjggPSB7ezAsIDB4MzdmMDAwMDB9fSwgIC8qICAyXi0x MjggICAgICAgICAgKi8KICAgICAgICAgICAgICAgICAgICAgIFpFUk8gPSB7ezAsIDB9fSwgICAg ICAgICAgLyogIDAuMCAgICAgICAgICAgICAqLwogICAgICAgICAgICAgICAgICAgICBuWkVSTyA9 IHt7MCwgMHg4MDAwMDAwMH19LCAvKiAtMC4wICAgICAgICAgICAgICovCiAgICAgICAgICAgICAg ICAgICAgICAgTkFOID0ge3swLCAweDdmZjgwMDAwfX0sIC8qICBOYU4gICAgICAgICAgICAgKi8K ICAgICAgICAgICAgICAgICAgICAgIG5OQU4gPSB7ezAsIDB4ZmZmODAwMDB9fTsgLyogLU5hTiAg ICAgICAgICAgICAqLwoKZG91YmxlIHVyZW1haW5kZXIoZG91YmxlICwgZG91YmxlICk7CgovKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiovCi8qIEFuIHVsdGltYXRlIHJlbWFpbmRlciByb3V0aW5lLiBHaXZlbiB0 d28gSUVFRSBkb3VibGUgbWFjaGluZSBudW1iZXJzIHggKi8KLyogLHkgICBpdCBjb21wdXRlcyB0 aGUgY29ycmVjdGx5IHJvdW5kZWQgKHRvIG5lYXJlc3QpIHZhbHVlIG9mIHJlbWFpbmRlciAqLwov KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKiovCmRvdWJsZSBteV9yZW1haW5kZXIoZG91YmxlIHgsIGRvdWJsZSB5 KQp7CiAgZG91YmxlIHosZCx4eDsKI2lmIDAKICBkb3VibGUgeXk7CiNlbmRpZgogIGludDQga3gs a3ksbixubixuMSxtMSxsOwojaWYgMAogIGludDQgbTsKI2VuZGlmCiAgbXludW1iZXIgdSx0LHc9 e3swLDB9fSx2PXt7MCwwfX0sd3c9e3swLDB9fSxyLHRtcDEsdG1wMjsKICB1Lng9eDsKICB0Lng9 eTsKICBreD11LmlbSElHSF9IQUxGXSYweDdmZmZmZmZmOyAvKiBubyBzaWduICBmb3IgeCovCiAg dC5pW0hJR0hfSEFMRl0mPTB4N2ZmZmZmZmY7ICAgLypubyBzaWduIGZvciB5ICovCiAga3k9dC5p W0hJR0hfSEFMRl07CiAgcHJpbnRmKCJ4PSglMDhseCwlMDhseCkseT0oJTA4bHgsJTA4bHgpXG4i LHUuaVsxXSx1LmlbMF0sdC5pWzFdLHQuaVswXSk7CiAgLyotLS0tLS0gfHh8IDwgMl4xMDI0ICBh bmQgICAyXi05NzAgPCB8eXwgPCAyXjEwMjQgLS0tLS0tLS0tLS0tLS0tLS0tKi8KICBpZiAoa3g8 MHg3ZmYwMDAwMCAmJiBreTwweDdmZjAwMDAwICYmIGt5Pj0weDAzNTAwMDAwKSB7CiAgICBpZiAo a3grMHgwMDEwMDAwMDxreSkgcmV0dXJuIHg7CiAgICBpZiAoKGt4LTB4MDE1MDAwMDApPGt5KSB7 CiAgICAgIHo9eC90Lng7CiAgICAgIHYuaVtISUdIX0hBTEZdPXQuaVtISUdIX0hBTEZdOwogICAg ICBkPSh6K2JpZy54KS1iaWcueDsKICAgICAgeHg9KHgtZCp2LngpLWQqKHQueC12LngpOwogICAg ICBpZiAoZC16IT0wLjUmJmQteiE9LTAuNSkgcmV0dXJuICh4eCE9MCk/eHg6KCh4PjApP1pFUk8u eDpuWkVSTy54KTsKICAgICAgZWxzZSB7CglpZiAoQUJTKHh4KT4wLjUqdC54KSByZXR1cm4gKHo+ ZCk/eHgtdC54Onh4K3QueDsKCWVsc2UgcmV0dXJuIHh4OwogICAgICB9CiAgICB9ICAgLyogICAg KGt4PChreSsweDAxNTAwMDAwKSkgICAgICAgICAqLwogICAgZWxzZSAgewogICAgICByLng9MS4w L3QueDsKICAgICAgcHJpbnRmKCIxL3k9JTA4bHgsJTA4bHhcbiIsci5pWzFdLHIuaVswXSk7CQog ICAgICBuPXQuaVtISUdIX0hBTEZdOwogICAgICBubj0obiYweDdmZjAwMDAwKSsweDAxNDAwMDAw OwogICAgICB3LmlbSElHSF9IQUxGXT1uOwogICAgICB3dy54PXQueC13Lng7CiAgICAgIGw9KGt4 LW5uKSYweGZmZjAwMDAwOwogICAgICBuMT13dy5pW0hJR0hfSEFMRl07CiAgICAgIG0xPXIuaVtI SUdIX0hBTEZdOwogICAgICBwcmludGYoIm49JTA4bHgsbm49JTA4bHgsd3c9KCUwOGx4LCUwOGx4 KSx3PSglMDhseCwlMDhseCksbD0lMDhseFxuIixuLG5uLHd3LmlbMV0sd3cuaVswXSx3LmlbMV0s dy5pWzBdLGwpOwkKICAgICAgd2hpbGUgKGw+MCkgewoJci5pW0hJR0hfSEFMRl09bTEtbDsKCXo9 dS54KnIueDsKICAgICAgICB0bXAxLnggPSB6OwoJdy5pW0hJR0hfSEFMRl09bitsOwoJd3cuaVtI SUdIX0hBTEZdPShuMSk/bjErbDpuMTsKCWQ9KHorYmlnLngpLWJpZy54OwogICAgICAgIHRtcDIu eCA9IGQ7CiAgICAgICAgcHJpbnRmKCJ1PSglMDhseCwlMDhseCksZD0oJTA4bHgsJTA4bHgpLHc9 KCUwOGx4LCUwOGx4KVxuIix1LmlbMV0sdS5pWzBdLHRtcDIuaVsxXSx0bXAyLmlbMF0sdy5pWzFd LHcuaVswXSk7IAogICAgICAgIHRtcDEueCA9IGQqdy54OwoJdG1wMi54ID0gdS54IC0gdG1wMS54 OyAKCS8vdG1wMS54ID0gdS54LWQqdy54OwoJLy90bXAyLnggPSB0bXAxLnggLSBkKnd3Lng7IAoJ dS54PSh1LngtZCp3LngpLyotZCp3dy54Ki87CiAgICAgICAgcHJpbnRmKCJkKnc9KCUwOGx4LCUw OGx4KSx1LngtZCp3PSglMDhseCwlMDhseCksdT0oJTA4bHgsJTA4bHgpXG4iLHRtcDEuaVsxXSx0 bXAxLmlbMF0sdG1wMi5pWzFdLHRtcDIuaVswXSx1LmlbMV0sdS5pWzBdKTsgCglsPSh1LmlbSElH SF9IQUxGXSYweDdmZjAwMDAwKS1ubjsKCS8vcHJpbnRmKCJ1PSglMDhseCwlMDhseCksej0oJTA4 bHgsJTA4bHgpLHd3PSglMDhseCwlMDhseCksZD0oJTA4bHgsJTA4bHgpLGw9JTA4bHhcbiIsdS5p WzFdLHUuaVswXSx0bXAxLmlbMV0sdG1wMS5pWzBdLHd3LmlbMV0sd3cuaVswXSx0bXAyLmlbMV0s dG1wMi5pWzBdLGwpOwogICAgICB9CiAgICAgIHIuaVtISUdIX0hBTEZdPW0xOwogICAgICB3Lmlb SElHSF9IQUxGXT1uOwogICAgICB3dy5pW0hJR0hfSEFMRl09bjE7CiAgICAgIHo9dS54KnIueDsK ICAgICAgZD0oeitiaWcueCktYmlnLng7CiAgICAgIHUueD0odS54LWQqdy54KS1kKnd3Lng7CiAg ICAgIGlmIChBQlModS54KTwwLjUqdC54KSByZXR1cm4gKHUueCE9MCk/dS54OigoeD4wKT9aRVJP Lng6blpFUk8ueCk7CiAgICAgIGVsc2UKICAgICAgICBpZiAoQUJTKHUueCk+MC41KnQueCkgcmV0 dXJuIChkPnopP3UueCt0Lng6dS54LXQueDsKICAgICAgICBlbHNlCiAgICAgICAge3o9dS54L3Qu eDsgZD0oeitiaWcueCktYmlnLng7IHJldHVybiAoKHUueC1kKncueCktZCp3dy54KTt9CiAgICB9 CgogIH0gICAvKiAgIChreDwweDdmZjAwMDAwJiZreTwweDdmZjAwMDAwJiZreT49MHgwMzUwMDAw MCkgICAgICovCiAgZWxzZSB7CiAgICBpZiAoa3g8MHg3ZmYwMDAwMCYma3k8MHg3ZmYwMDAwMCYm KGt5PjB8fHQuaVtMT1dfSEFMRl0hPTApKSB7CiAgICAgIHk9QUJTKHkpKnQxMjgueDsKICAgICAg ej1teV9yZW1haW5kZXIoeCx5KSp0MTI4Lng7CiAgICAgIHo9bXlfcmVtYWluZGVyKHoseSkqdG0x MjgueDsKICAgICAgcmV0dXJuIHo7CiAgICB9CiAgICBlbHNlIHsgLyogaWYgeCBpcyB0b28gYmln ICovCiAgICAgIGlmIChreCA9PSAweDdmZjAwMDAwICYmIHUuaVtMT1dfSEFMRl0gPT0gMCAmJiB5 ID09IDEuMCkKCXJldHVybiB4IC8geDsKICAgICAgaWYgKGt4Pj0weDdmZjAwMDAwfHwoa3k9PTAm JnQuaVtMT1dfSEFMRl09PTApfHxreT4weDdmZjAwMDAwfHwKCSAgKGt5PT0weDdmZjAwMDAwJiZ0 LmlbTE9XX0hBTEZdIT0wKSkKCXJldHVybiAodS5pW0hJR0hfSEFMRl0mMHg4MDAwMDAwMCk/bk5B Ti54Ok5BTi54OwogICAgICBlbHNlIHJldHVybiB4OwogICAgfQogIH0KfQp2b2lkIHByaW50X3Jv dW5kKCkKewoJaW50IHI7CgoJcj1mZWdldHJvdW5kKCk7CglpZiAocj09RkVfVE9ORUFSRVNUKSB7 CgkJcHJpbnRmKCJyb3VuZGluZyBpcyBUT05FQVJFU1RcbiIpOyAKCX1lbHNlIGlmIChyPT1GRV9E T1dOV0FSRCkgewoJCXByaW50Zigicm91bmRpbmcgaXMgRE9XTldBUkRcbiIpOyAKCX1lbHNlIGlm IChyPT1GRV9VUFdBUkQpIHsKCQlwcmludGYoInJvdW5kaW5nIGlzIFVQV0FSRFxuIik7IAoJfWVs c2UgewoJCXByaW50Zigicm91bmRpbmcgaXMgVE9XQVJEWkVST1xuIik7IAoJfQp9CgoJCQppbnQg bWFpbihpbnQgYXJnYyxjaGFyICoqYXJndikKewoJbXludW1iZXIgdDsKCWRvdWJsZSB0dCx4eDsK CglwcmludF9yb3VuZCgpOwoJdC5pWzFdID0gMHgwMDAwMDAwMDsKCXQuaVswXSA9IDB4MDAwMDAw MDE7Cgl0dCA9IHQueDsKCXQuaVsxXSA9IDB4N2ZlZmZmZmY7Cgl0LmlbMF0gPSAweGZmZmZmZmZm OwoJeHggPSB0Lng7Cgl4eCA9IG15X3JlbWFpbmRlcih4eCx0dCk7CgoJcmV0dXJuIDA7Cn0K --=====_Dragon655117627178_=====-- From owner-linux-mips@oss.sgi.com Tue Feb 19 03:47:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JBlLE13877 for linux-mips-outgoing; Tue, 19 Feb 2002 03:47:21 -0800 Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JBl8913870 for ; Tue, 19 Feb 2002 03:47:08 -0800 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g1JAkSj26763; Tue, 19 Feb 2002 11:46:28 +0100 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Tue, 19 Feb 2002 11:46:28 +0100 (CET) From: Kjeld Borch Egevang To: Zhang Fuxin cc: "linux-mips@oss.sgi.com" , "libc-alpha@sources.redhat.com" Subject: Re: endless loop in remainder() on mips In-Reply-To: <200202190323.g1J3Ne904847@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 Content-Length: 3033 Lines: 92 On Tue, 19 Feb 2002, Zhang Fuxin wrote: ... > It is weird enough for me that u doesn't equal to tmp2,that is where x86 and mips differ. > > the output from my P4: > rounding is TONEAREST > x=(7fefffff,ffffffff),y=(00000000,00000001) > x=(7fefffff,ffffffff),y=(04d00000,00000000) > 1/y=7b100000,00000000 > n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 > u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) > d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fca00000,00000000) <--notice this > u=(fca00000,00000000),d=(c1300000,00000000),w=(7b600000,00000000) > d*w=(fca00000,00000000),u.x-d*w=(00000000,00000000),u=(00000000,00000000) > x=(00000000,00000000),y=(04d00000,00000000) > > output from mipsel: > rounding is TONEAREST > x=(7fefffff,ffffffff),y=(00000000,00000001) > x=(7fefffff,ffffffff),y=(04d00000,00000000) > 1/y=7b100000,00000000 > n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 > u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) > d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fff00000,00000000) <--notice this > u=(fff00000,00000000),d=(fff00000,00000000),w=(7eb00000,00000000) > d*w=(fff00000,00000000),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) > u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) > d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) > u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) > d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) > u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) > d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) You're right. Not a bug. Internally your P4 uses more than 64 bits in its calculations. Here's my test and output from my AMD, Sun and MIPS: typedef union number_s { long long ll; double d; } t_number; #define P(x) printf(#x "=%e %016llx\n", x.d, x.ll) int main() { t_number u, d, w, t, r; u.ll = 0x7fefffffffffffff; d.ll = 0x4140000000000000; w.ll = 0x7ea0000000000000; t.d = d.d * w.d; t.d = u.d - t.d; r.d = (u.d - d.d * w.d); P(u); P(d); P(w); P(r); P(t); } AMD: u=1.797693e+308 7fefffffffffffff d=2.097152e+06 4140000000000000 w=8.572069e+301 7ea0000000000000 r=-1.995840e+292 fca0000000000000 t=-inf fff0000000000000 Sun: u=1.797693e+308 7fefffffffffffff d=2.097152e+06 4140000000000000 w=8.572069e+301 7ea0000000000000 r=-Inf fff0000000000000 t=-Inf fff0000000000000 MIPS: u=1.797693e+308 7fefffffffffffff d=2.097152e+06 4140000000000000 w=8.572069e+301 7ea0000000000000 r=-inf fff0000000000000 t=-inf fff0000000000000 /Kjeld -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Tue Feb 19 04:22:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JCM5Y14855 for linux-mips-outgoing; Tue, 19 Feb 2002 04:22:05 -0800 Received: from dea.linux-mips.net (a1as02-p137.stg.tli.de [195.252.185.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JCLi914852 for ; Tue, 19 Feb 2002 04:21:47 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1JBLcc27213 for linux-mips@oss.sgi.com; Tue, 19 Feb 2002 12:21:38 +0100 Received: from desire.geoffk.org (12-234-190-114.client.attbi.com [12.234.190.114]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1ILIp910604 for ; Mon, 18 Feb 2002 13:18:51 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g1IKIk802891; Mon, 18 Feb 2002 12:18:46 -0800 Date: Mon, 18 Feb 2002 12:18:46 -0800 From: Geoff Keating Message-Id: <200202182018.g1IKIk802891@desire.geoffk.org> To: moshier@moshier.net CC: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, libc-alpha@sources.redhat.com In-reply-to: (message from Stephen L Moshier on Mon, 18 Feb 2002 14:50:30 -0500 (EST)) Subject: Re: math broken on mips Reply-to: Geoff Keating References: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2234 Lines: 46 > Mailing-List: contact libc-alpha-help@sources.redhat.com; run by ezmlm > List-Unsubscribe: > List-Subscribe: > List-Archive: > List-Post: > List-Help: , > Date: Mon, 18 Feb 2002 14:50:30 -0500 (EST) > From: Stephen L Moshier > Reply-To: moshier@moshier.net > cc: linux-mips@oss.sgi.com, > > > > pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD > > = 64.1547.. when rounding = DOWNWARD or TOWARDZERO > > The libm functions from IBM that were recently installed in glibc come > with this remark in sysdeps/ieee754/dbl-64/MathLib.h: > > /* Assumption: Machine arithmetic operations are performed in */ > /* round nearest mode of IEEE 754 standard. */ > > These math functions use a doubled-precision Dekker arithmetic which is > very sensitive to rounding rules and arithetic flaws. Fixing the > routines to give reasonable answers with other rounding modes would not > be practical. > > It is customary for a system math library to expect default environment > conditions, and I do not think this design actually violates any > standards. If you want to use non-default arithmetic settings and have > them work portably on various systems, you will have to take defensive steps > to protect your program from damage by the operating system and the system > library. ... actually, C99 seems to imply that all supported rounding precisions should work for the math library, although of course C99 doesn't promise very much about accuracy of the math library in the first place. Maybe we should add appropriate fesetround() calls to the math library? Usually most of each routine should be done with round-to-nearest and then there's one or two operations at the end that should be in the user's rounding mode, to get the correctly-rounded value for the user's rounding mode. -- - Geoffrey Keating From owner-linux-mips@oss.sgi.com Tue Feb 19 04:24:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JCOi814931 for linux-mips-outgoing; Tue, 19 Feb 2002 04:24:44 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JCOV914928 for ; Tue, 19 Feb 2002 04:24:32 -0800 Message-Id: <200202191224.g1JCOV914928@oss.sgi.com> Received: (qmail 12663 invoked from network); 19 Feb 2002 11:27:21 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 19 Feb 2002 11:27:21 -0000 Date: Tue, 19 Feb 2002 19:21:57 +0800 From: Zhang Fuxin To: Kjeld Borch Egevang CC: "linux-mips@oss.sgi.com" , "libc-alpha@sources.redhat.com" Subject: Re: Re: endless loop in remainder() on mips 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 g1JCOW914929 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3226 Lines: 96 ÔÚ 2002-02-19 11:46:00 you wrote£ş >.... >> It is weird enough for me that u doesn't equal to tmp2,that is where x86 and mips differ. >> >> the output from my P4: >> rounding is TONEAREST >> x=(7fefffff,ffffffff),y=(00000000,00000001) >> x=(7fefffff,ffffffff),y=(04d00000,00000000) >> 1/y=7b100000,00000000 >> n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 >> u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) >> d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fca00000,00000000) <--notice this >> u=(fca00000,00000000),d=(c1300000,00000000),w=(7b600000,00000000) >> d*w=(fca00000,00000000),u.x-d*w=(00000000,00000000),u=(00000000,00000000) >> x=(00000000,00000000),y=(04d00000,00000000) >> >> output from mipsel: >> rounding is TONEAREST >> x=(7fefffff,ffffffff),y=(00000000,00000001) >> x=(7fefffff,ffffffff),y=(04d00000,00000000) >> 1/y=7b100000,00000000 >> n=04d00000,nn=06100000,ww=(00000000,00000000),w=(04d00000,00000000),l=79d00000 >> u=(7fefffff,ffffffff),d=(41400000,00000000),w=(7ea00000,00000000) >> d*w=(7ff00000,00000000),u.x-d*w=(fff00000,00000000),u=(fff00000,00000000) <--notice this >> u=(fff00000,00000000),d=(fff00000,00000000),w=(7eb00000,00000000) >> d*w=(fff00000,00000000),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) >> u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) >> d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) >> u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) >> d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) >> u=(7ff7ffff,ffffffff),d=(7ff7ffff,ffffffff),w=(7eb00000,00000000) >> d*w=(7ff7ffff,ffffffff),u.x-d*w=(7ff7ffff,ffffffff),u=(7ff7ffff,ffffffff) > >You're right. Not a bug. Internally your P4 uses more than 64 bits in its Then libm needs a fix. I see,Thank you. >calculations. Here's my test and output from my AMD, Sun and MIPS: > >typedef union number_s { > long long ll; > double d; >} t_number; > >#define P(x) printf(#x "=%e %016llx\n", x.d, x.ll) > >int main() >{ > t_number u, d, w, t, r; > > u.ll = 0x7fefffffffffffff; > d.ll = 0x4140000000000000; > w.ll = 0x7ea0000000000000; > t.d = d.d * w.d; > t.d = u.d - t.d; > r.d = (u.d - d.d * w.d); > P(u); > P(d); > P(w); > P(r); > P(t); >} > >AMD: >u=1.797693e+308 7fefffffffffffff >d=2.097152e+06 4140000000000000 >w=8.572069e+301 7ea0000000000000 >r=-1.995840e+292 fca0000000000000 >t=-inf fff0000000000000 > >Sun: >u=1.797693e+308 7fefffffffffffff >d=2.097152e+06 4140000000000000 >w=8.572069e+301 7ea0000000000000 >r=-Inf fff0000000000000 >t=-Inf fff0000000000000 > >MIPS: >u=1.797693e+308 7fefffffffffffff >d=2.097152e+06 4140000000000000 >w=8.572069e+301 7ea0000000000000 >r=-inf fff0000000000000 >t=-inf fff0000000000000 > > >/Kjeld > >-- >_ _ ____ ___ Mailto:kjelde@mips.com >|\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 >| \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 > TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 > Denmark http://www.mips.com/ Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Feb 19 06:19:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JEJFU16413 for linux-mips-outgoing; Tue, 19 Feb 2002 06:19:15 -0800 Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JEJ9916410 for ; Tue, 19 Feb 2002 06:19:09 -0800 Received: from e145033.ppp.asahi-net.or.jp (HELO nazneen) (211.13.145.33) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Feb 2002 13:19:08 -0000 Message-ID: <004101c1b948$32f9cc60$21910dd3@gol.com> From: "Girish Gulawani" To: References: <002301c1b8d2$22a0efe0$443784d3@gol.com> <20020218173419.A15980@momenco.com> Subject: Re: Page Size 16KB. Date: Tue, 19 Feb 2002 22:20:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1239 Lines: 39 > Does your userspace shell set the CREAD flag properly? i think so. and btw, my kernel version is 2.4.9. i thought this CREAD problem isnt there in this version. but shall check again. thanks for this info. other than this where else could be the problem that i'm overlooking?? > Matt > > On Tue, Feb 19, 2002 at 08:15:18AM +0900, Girish Gulawani wrote: > > hi, all. > > while in the process of changing page size of kernel to 16KB i am facing a > > strange problem. the kernel boots up & user command, currently statically > > linked shell, loads. it displays first prompt. pressing enter keys, the > > serial device receives the interrupts but no activity on shell's part. where > > could the shell possibly be stuck? > > this is LSI MIPS EZ4021 implementation. please please help!!! > > many thanks & regards, > > girish. > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > -- > Matthew Dharm Work: mdharm@momenco.com > Senior Software Designer, Momentum Computer _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Tue Feb 19 08:28:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JGS4318548 for linux-mips-outgoing; Tue, 19 Feb 2002 08:28:04 -0800 Received: from moshier.net (moshier.ne.mediaone.net [65.96.130.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JGS2918545 for ; Tue, 19 Feb 2002 08:28:02 -0800 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [65.96.130.103]) by moshier.net (8.9.3/8.9.3) with ESMTP id KAA26179; Tue, 19 Feb 2002 10:27:52 -0500 Date: Tue, 19 Feb 2002 10:27:52 -0500 (EST) From: Stephen L Moshier Reply-To: steve@moshier.net To: Zhang Fuxin cc: linux-mips@oss.sgi.com, Subject: Re: endless loop in remainder() on mips Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 284 Lines: 11 > t-remainder.c This code does not look like the current version of sysdeps/ieee754/dbl-64/e_remainder.c IBM fixed the bug, and I thought there was acknowledgment here that the fix worked on a MIPS. The change was installed December 5, 2001 and it seems to be in glibc-2.2.5. From owner-linux-mips@oss.sgi.com Tue Feb 19 15:05:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JN5r628484 for linux-mips-outgoing; Tue, 19 Feb 2002 15:05:53 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JN5l928481; Tue, 19 Feb 2002 15:05:47 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id OAA25810; Tue, 19 Feb 2002 14:05:14 -0800 Date: Tue, 19 Feb 2002 14:05:14 -0800 From: Jun Sun To: "Kevin D. Kissell" Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219140514.C25739@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002b01c1b607$6afbd5c0$10eca8c0@grendel>; from kevink@mips.com on Fri, Feb 15, 2002 at 10:59:09AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1362 Lines: 30 On Fri, Feb 15, 2002 at 10:59:09AM +0100, Kevin D. Kissell wrote: > > > > > I have been chasing a FPU register corruption problem on a SMP box. The > > > > > curruption seems to be caused by FPU emulator code. Is that code SMP safe? > > > > > If not, what are the volunerable spots? > > > > > > > > In theory the fp emulation code should be MP safe as the full emulation > > > > is only accessing it's context in the fp register set of struct > > > > task_struct. The 32-bit kernel's fp register switching is entirely broken > > > > (read: close to non-existant). Lots of brownie points for somebody to > > > > backport that from the 64-bit kernel to the 32-bit kernel and forward > > > > port all the FPU emu bits to the 64-bit kernel ... > > > > > > > > > > Brownie sounds good. :-) So what is the "fp register switching" you are > > > referring to? There is set of code related to lazy fpu context switch, > > > which seems to be working fine now. > > > > > > > Hmm, I see. The lazy fpu context switch code is not SMP safe. > > I see fishy things like "last_task_used_math" etc... > > What, you mean "last_task_used_math" isn't allocated in a > processor-specific page of kseg3??? ;-) > You must be talking about another OS, right? :-) I don't think Linux has processor-specific page, although this sounds like a good idea to explore. Jun From owner-linux-mips@oss.sgi.com Tue Feb 19 15:08:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JN8ah28560 for linux-mips-outgoing; Tue, 19 Feb 2002 15:08:36 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JN8V928557; Tue, 19 Feb 2002 15:08:31 -0800 Received: from orion.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 OAA03364; Tue, 19 Feb 2002 14:08:29 -0800 (PST) mail_from (jsun@orion.mvista.com) Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id OAA25805; Tue, 19 Feb 2002 14:02:57 -0800 Date: Tue, 19 Feb 2002 14:02:57 -0800 From: Jun Sun To: Ralf Baechle Cc: "Kevin D. Kissell" , carstenl@mips.com, linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219140257.B25739@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <006d01c1b606$21929c80$0deca8c0@Ulysses> <20020215115711.A26798@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020215115711.A26798@dea.linux-mips.net>; from ralf@oss.sgi.com on Fri, Feb 15, 2002 at 11:57:11AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 776 Lines: 19 On Fri, Feb 15, 2002 at 11:57:11AM +0100, Ralf Baechle wrote: > On Fri, Feb 15, 2002 at 09:14:52AM +0100, Kevin D. Kissell wrote: > > > I submitted a series of patches a year or so ago, the > > last of which really should have been a comprehensive > > fix to the FPU context switch and signal problems. > > The last time I looked, that patch had never made it into > > the OSS repository, but neither had anyone reported > > any holes in it. > > I was actually beliving that the bundle of patches I received from > Carsten maybe 3 months ago did fix all the issues? > False alarm - I did some tests and kgdb trace, and confirmed that the the current FPU code indeed solved all the fpu/signal problems that I know of. Good to know we can actually make things work! Jun From owner-linux-mips@oss.sgi.com Tue Feb 19 15:19:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JNJd228798 for linux-mips-outgoing; Tue, 19 Feb 2002 15:19:39 -0800 Received: from dea.linux-mips.net (a1as20-p228.stg.tli.de [195.252.194.228]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JNJa928795 for ; Tue, 19 Feb 2002 15:19:37 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1JMJLA06767; Tue, 19 Feb 2002 23:19:21 +0100 Date: Tue, 19 Feb 2002 23:19:21 +0100 From: Ralf Baechle To: Jun Sun Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219231921.B5886@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219140514.C25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 02:05:14PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 278 Lines: 9 On Tue, Feb 19, 2002 at 02:05:14PM -0800, Jun Sun wrote: > You must be talking about another OS, right? :-) I don't think > Linux has processor-specific page, although this sounds like > a good idea to explore. Patches for 2.5 have been posted to l-k very recently. Ralf From owner-linux-mips@oss.sgi.com Tue Feb 19 15:41:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1JNfjg29006 for linux-mips-outgoing; Tue, 19 Feb 2002 15:41:45 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1JNfS929000; Tue, 19 Feb 2002 15:41:29 -0800 Received: from dev1 (unknown [10.1.1.85]) by ns1.ltc.com (Postfix) with ESMTP id BD69A590A9; Tue, 19 Feb 2002 17:30:58 -0500 (EST) Received: from brad by dev1 with local (Exim 3.33 #1 (Debian)) id 16dIos-0000W8-00; Tue, 19 Feb 2002 17:33:06 -0500 Date: Tue, 19 Feb 2002 17:33:02 -0500 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: [PATCH] remove die/die_if_kernel __FUNCTION__ cat for gcc 3.x's sake Message-ID: <20020219173302.A1989@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde " Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2519 Lines: 60 diff -urNbB --exclude-from=diff-linux-exclude linux-oss-2.4-2002-01-20/include/asm-mips/system.h linux-encore-2.4.17-2/include/asm-mips/system.h --- linux-oss-2.4-2002-01-20/include/asm-mips/system.h Sun Dec 16 04:34:16 2001 +++ linux-encore-2.4.17-2/include/asm-mips/system.h Tue Feb 19 17:05:36 2002 @@ -276,14 +276,14 @@ extern void *set_except_vector(int n, void *addr); -extern void __die(const char *, struct pt_regs *, const char *where, - unsigned long line) __attribute__((noreturn)); -extern void __die_if_kernel(const char *, struct pt_regs *, const char *where, - unsigned long line); +extern void __die(const char *, struct pt_regs *, const char *file, + const char *function, unsigned long line) __attribute__((noreturn)); +extern void __die_if_kernel(const char *, struct pt_regs *, const char *file, + const char *function, unsigned long line); #define die(msg, regs) \ - __die(msg, regs, __FILE__ ":"__FUNCTION__, __LINE__) + __die(msg, regs, __FILE__, __FUNCTION__, __LINE__) #define die_if_kernel(msg, regs) \ - __die_if_kernel(msg, regs, __FILE__ ":"__FUNCTION__, __LINE__) + __die_if_kernel(msg, regs, __FILE__, __FUNCTION__, __LINE__) #endif /* _ASM_SYSTEM_H */ diff -urNbB --exclude-from=diff-linux-exclude linux-oss-2.4-2002-01-20/arch/mips/kernel/traps.c linux-encore-2.4.17-2/arch/mips/kernel/traps.c --- linux-oss-2.4-2002-01-20/arch/mips/kernel/traps.c Sun Jan 20 17:06:08 2002 +++ linux-encore-2.4.17-2/arch/mips/kernel/traps.c Tue Feb 19 17:20:25 2002 @@ -327,25 +327,25 @@ static spinlock_t die_lock = SPIN_LOCK_UNLOCKED; -void __die(const char * str, struct pt_regs * regs, const char *where, - unsigned long line) +void __die(const char * str, struct pt_regs * regs, const char *file, + const char *function, unsigned long line) { console_verbose(); spin_lock_irq(&die_lock); printk("%s", str); - if (where) - printk(" in %s, line %ld", where, line); + if (file && function) + printk(" in %s:%s, line %ld", file, function, line); printk(":\n"); show_registers(regs); spin_unlock_irq(&die_lock); do_exit(SIGSEGV); } -void __die_if_kernel(const char * str, struct pt_regs * regs, const char *where, - unsigned long line) +void __die_if_kernel(const char * str, struct pt_regs * regs, const char *file, + const char* function, unsigned long line) { if (!user_mode(regs)) - __die(str, regs, where, line); + __die(str, regs, file, function, line); } extern const struct exception_table_entry __start___dbe_table[]; From owner-linux-mips@oss.sgi.com Tue Feb 19 17:05:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K155N32479 for linux-mips-outgoing; Tue, 19 Feb 2002 17:05:05 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K14w932473 for ; Tue, 19 Feb 2002 17:04:58 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA05743; Tue, 19 Feb 2002 16:04:50 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA02722; Tue, 19 Feb 2002 16:04:49 -0800 (PST) Message-ID: <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> Subject: Re: FPU emulator unsafe for SMP? Date: Wed, 20 Feb 2002 01:08:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2393 Lines: 47 > > > Hmm, I see. The lazy fpu context switch code is not SMP safe. > > > I see fishy things like "last_task_used_math" etc... > > > > What, you mean "last_task_used_math" isn't allocated in a > > processor-specific page of kseg3??? ;-) > > You must be talking about another OS, right? :-) I don't think > Linux has processor-specific page, although this sounds like > a good idea to explore. It's gotta be done. I mean, the last I heard (which was a long time ago) mips64 Linux was keeping the CPU node number in a watchpoint register (or something equally unwholesome) and using that value as an index into tables. Sticking all the per-CPU state in a kseg3 VM page which is allocated and locked at boot time would be much cleaner and on the average probably quite a bit faster (definitely faster in the kernel but to be fair one has to factor in the increase in TLB pressure from the locked entry). But getting back to the original topic, there's another fun bug waiting for us in MIPS/Linux SMP floating point that can't be fixed as easly with VM slight-of-hand. Consider processes "A" and "B", where A uses FP and B does not: A gets scheduled on CPU 1, runs for a while, gets preempted, and B gets CPU 1. CPU 2 gets freed, so A gets scheduled on CPU 2. Unfortunately, A's FP state is still in the FP register set of CPU 1. The lazy FPU context switch either needs to be turned off (bleah!) or be fixed for SMP to handle the case where the "owner" of the FPR's on one CPU gets scheduled on another. The brute force would be somehow to send an interrupt to the CPU with the FP state that will cause it to cough it up into the thread context area. One alternative would be to give strict CPU affinity to the thread that has it's FP state on a particular CPU. That could complicate load balancing, but might not really be too bad. At most one thread per CPU will be non-migratable at a given point in time. In the above scenario, "A" could never migrate off of CPU 1, but "B" could, and would presumably be picked up by an idle CPU 2 as soon as it's time slice is up on CPU 1. That will be less efficient than doing an "FPU shootdown" in some cases, but it should also be more portable and easier to get right. Does this come up in x86-land? The FPU state is much smaller there, so lazy context switching is presumably less important. Kevin K. From owner-linux-mips@oss.sgi.com Tue Feb 19 17:49:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K1ngF00776 for linux-mips-outgoing; Tue, 19 Feb 2002 17:49:42 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K1nT900770 for ; Tue, 19 Feb 2002 17:49:29 -0800 Message-Id: <200202200149.g1K1nT900770@oss.sgi.com> Received: (qmail 31397 invoked from network); 20 Feb 2002 00:52:16 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 20 Feb 2002 00:52:16 -0000 Date: Wed, 20 Feb 2002 8:46:40 +0800 From: Zhang Fuxin To: Hartvig Ekner CC: "linux-mips@oss.sgi.com" Subject: Re: Re: Re: math broken on mips 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 g1K1nT900771 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4306 Lines: 125 hi, a quick example: main() { float t,zero=0.0; t = 0.0/0.0; printf("t=%08lx\n",*(unsigned long*)&t); (0x7fc00000) t = zero/zero; printf("t=%08lx\n",*(unsigned long*)&t); (0x7fbfffff) } you should see different output,because the first one is optimized by gcc to a QNaN,but it's signalling for MIPS. ÔÚ 2002-02-19 16:37:00 you wrote£ş >Hello Zhang, > >I am going to test your reported bugs on the current SDE compiler. > >Do you have some test example for the first problem (Nan handling)? >If you have found it in the sources, and that source is actually being >used by the MIPS compiler generated, it must be possible to provide >a small example showing wrong behaviour from the compiler? > >/Hartvig > > >Zhang Fuxin writes: >> >> hi, >> I find that you are asking only gcc related parts,that is related less, >> here they are(from posts on linux-mips,i cc them to the list in case it is >> useful,sorry if it brings you inconvenience): >> >> 1.about NaN handling >> -----------------begin of the first problem-------------------------------- >> I am sorry but it seems i can't fix this without ugly changes. >> since i am not familiar with gcc code, i decide to leave it to you, >> but provide some information instead. >> >> In gcc there are 3 spaces where the NaN handling is assumed the >> Intel way. >> >> 1. gcc/real.c (the most important one) >> here the author seems to have known the NaN pattern problem,so >> he leaves a interface macro for defining non intel NaN patterns: >> (comment of function "make_nan()",at about line 6219) >> >> /* Output a binary NaN bit pattern in the target machine's format. */ >> >> /* If special NaN bit patterns are required, define them in tm.h >> as arrays of unsigned 16-bit shorts. Otherwise, use the default >> patterns here. */ >> >> I have read through this file and decided that the follow defined should >> be enough for mips: >> >> /* NaN pattern,mips QNAN & SNAN is different from intel's >> * DFMODE_NAN and SFMODE_NAN is used in real.c */ >> #define DFMODE_NAN \ >> unsigned short DFbignan[4] = {0x7ff7, 0xffff, 0xffff, 0xffff}; \ >> unsigned short DFlittlenan[4] = {0xffff, 0xffff, 0xffff, 0xfff7} >> #define SFMODE_NAN \ >> unsigned short SFbignan[2] = {0x7fbf, 0xffff}; \ >> unsigned short SFlittlenan[2] = {0xffff, 0xffbf} >> >> But the problem is where to put them:(. Obviously it is target specified >> definitions and should be in config/mips/. Documents say tm.h is a symbol >> link and included in config.h,but it is no long true.If i add them to xm-mips.h >> then for native compilation it is ok but it fails for cross-compile. >> >> 2.gcc/reg-stack.c (H.J. tell me it is not used on mips) >> There is a hardcoded QNaN used around line 477: >> nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); >> I sugest defining a macro QNAN_HAS_1ST_FRACBIT_CLEARED for mips and change >> it to,just don't know where to put it: >> #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED >> nan = gen_lowpart (SFmode, GEN_INT (0x7fc00000)); >> #else >> nan = gen_lowpart (SFmode, GEN_INT (0x7fbfffff)); >> #endif >> >> 3. config/fp-bit.c (H.J. said it is not mean to target specified) >> this is for machine having no fpu hardware. >> again i susgest define QNAN_HAS_1ST_FRACBIT_CLEARED and then apply this patch: >> >> 190d189 >> < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED >> 192,195d190 >> < #else >> < fraction &= ~QUIET_NAN; >> < #endif >> < >> 379,380d373 >> < >> < #ifndef QNAN_HAS_1ST_FRACBIT_CLEARED >> 382,384d374 >> < #else >> < if (!(fraction & QUIET_NAN)) >> < #endif >> >> >> ÔÚ 2002-02-03 22:54:00 you wrote£ş >> >On Mon, Feb 04, 2002 at 02:22:48PM +0800, Zhang Fuxin wrote: >> >> hi, >> >> >> >> Gcc (2.96 20000731,H.J.LU's rh port for mips) think 0x7fc00000 is QNaN and >> >> optimize 0.0/0.0 as 0x7fc00000 for single precision ops,while for my cpu >> >> (maybe most mips cpu) is a SNaN. R4k user's manual and "See Mips Run" both >> >> say so.And experiments confirm this. >> >> >> >> Should we correct it? >> > >> >Yes. Do you have a patch? >> > >> >Thanks. >> > >> > >> >H.J. Regards Zhang Fuxin fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Feb 19 18:13:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K2DHe01072 for linux-mips-outgoing; Tue, 19 Feb 2002 18:13:17 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K2DB901069 for ; Tue, 19 Feb 2002 18:13:11 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id RAA25904; Tue, 19 Feb 2002 17:12:38 -0800 Date: Tue, 19 Feb 2002 17:12:38 -0800 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219171238.E25739@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel>; from kevink@mips.com on Wed, Feb 20, 2002 at 01:08:30AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2802 Lines: 59 On Wed, Feb 20, 2002 at 01:08:30AM +0100, Kevin D. Kissell wrote: > > > > Hmm, I see. The lazy fpu context switch code is not SMP safe. > > > > I see fishy things like "last_task_used_math" etc... > > > > > > What, you mean "last_task_used_math" isn't allocated in a > > > processor-specific page of kseg3??? ;-) > > > > You must be talking about another OS, right? :-) I don't think > > Linux has processor-specific page, although this sounds like > > a good idea to explore. > > It's gotta be done. I mean, the last I heard (which was a long > time ago) mips64 Linux was keeping the CPU node number in > a watchpoint register (or something equally unwholesome) It seems that people are getting smarter by putting cpu id to context register. In fact isn't this part of new MIPS standard? > > But getting back to the original topic, there's another fun bug > waiting for us in MIPS/Linux SMP floating point that can't > be fixed as easly with VM slight-of-hand. Consider processes > "A" and "B", where A uses FP and B does not: A gets scheduled > on CPU 1, runs for a while, gets preempted, and B gets CPU 1. > CPU 2 gets freed, so A gets scheduled on CPU 2. Unfortunately, > A's FP state is still in the FP register set of CPU 1. The lazy FPU > context switch either needs to be turned off (bleah!) or be fixed > for SMP to handle the case where the "owner" of the FPR's > on one CPU gets scheduled on another. > > The brute force would be somehow to send an interrupt to the CPU > with the FP state that will cause it to cough it up into the thread context > area. One alternative would be to give strict CPU affinity to the thread > that has it's FP state on a particular CPU. That could complicate load > balancing, but might not really be too bad. At most one thread per CPU > will be non-migratable at a given point in time. In the above scenario, > "A" could never migrate off of CPU 1, but "B" could, and would > presumably be picked up by an idle CPU 2 as soon as it's time slice > is up on CPU 1. That will be less efficient than doing an "FPU shootdown" > in some cases, but it should also be more portable and easier > to get right. > As I looked into FPU/SMP issue, I realized this problem. I agree that locking fpu owner to the current cpu is the best solution. I bet this won't really hurt performance because any alternative would incur transferring FPU registers across cpus, which is not a small overhead. > Does this come up in x86-land? The FPU state is much smaller > there, so lazy context switching is presumably less important. > It appears x86 is not doing lazy fpu switching, at least not as agressively as MIPS. I am actually curious how IRIX handles this case, assuming IRIX is reasonable enough to have lazy FPU switching... Jun From owner-linux-mips@oss.sgi.com Tue Feb 19 18:51:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K2p2v01367 for linux-mips-outgoing; Tue, 19 Feb 2002 18:51:02 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K2os901361 for ; Tue, 19 Feb 2002 18:50:54 -0800 Received: from delllaptop (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g1K1orZ03517 for ; Tue, 19 Feb 2002 17:50:53 -0800 From: "Robert Rusek" To: Subject: Error Compiling 2.4.3 kernel on SGI IP22... Date: Tue, 19 Feb 2002 17:45:46 -0800 Message-ID: <000901c1b9b0$51cdd0b0$0f1610ac@delllaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2489 Lines: 68 Initially I got errors telling me that mips-linux-gcc, mips-linux-ld, and mips-linux-ar did not exists. I simply made a link for: mips-linux-gcc -> gcc mips-linux-ld -> ld mips-linux-ar -> ar Once doing so I got make to complete except for the last part when it goes to make the vmlinux file. I included the last few lines before it errors out. Any help would be greatly appreciated. --- make[1]: Entering directory `/usr/src/linux-2.4.3/arch/mips/kernel' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/linux-2.4.3/arch/mips/kernel' make CFLAGS="-I /usr/src/linux-2.4.3/include/asm/gcc -D__KERNEL__ -I/usr/src/lin ux-2.4.3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict- aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe " -C a rch/mips/mm make[1]: Entering directory `/usr/src/linux-2.4.3/arch/mips/mm' make all_targets make[2]: Entering directory `/usr/src/linux-2.4.3/arch/mips/mm' make[2]: Nothing to be done for `all_targets'. make[2]: Leaving directory `/usr/src/linux-2.4.3/arch/mips/mm' make[1]: Leaving directory `/usr/src/linux-2.4.3/arch/mips/mm' make CFLAGS="-I /usr/src/linux-2.4.3/include/asm/gcc -D__KERNEL__ -I/usr/src/lin ux-2.4.3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict- aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe " -C a rch/mips/lib make[1]: Entering directory `/usr/src/linux-2.4.3/arch/mips/lib' make all_targets make[2]: Entering directory `/usr/src/linux-2.4.3/arch/mips/lib' make[2]: Nothing to be done for `all_targets'. make[2]: Leaving directory `/usr/src/linux-2.4.3/arch/mips/lib' make[1]: Leaving directory `/usr/src/linux-2.4.3/arch/mips/lib' mips-linux-ld -static -G 0 -T arch/mips/ld.script arch/mips/kernel/head.o arch/m ips/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/f s.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o arch/mips/sgi/kernel/ip22-kern.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/ne t/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o dri vers/sgi/sgi.a drivers/video/video.o \ net/network.o \ arch/mips/lib/lib.a /usr/src/linux-2.4.3/lib/lib.a arch/mips/arc/arclib. a \ --end-group \ -o vmlinux mips-linux-ld: target elf32-bigmips not found make: *** [vmlinux] Error 1 --- -- Robert Rusek From owner-linux-mips@oss.sgi.com Tue Feb 19 18:59:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K2xAN01523 for linux-mips-outgoing; Tue, 19 Feb 2002 18:59:10 -0800 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K2x2901518 for ; Tue, 19 Feb 2002 18:59:02 -0800 Message-Id: <200202200259.g1K2x2901518@oss.sgi.com> Received: (qmail 1554 invoked from network); 20 Feb 2002 02:02:00 -0000 Received: from unknown (HELO foxsen) (@159.226.40.150) by 159.226.39.4 with SMTP; 20 Feb 2002 02:02:00 -0000 Date: Wed, 20 Feb 2002 9:56:28 +0800 From: Zhang Fuxin To: Hartvig Ekner CC: "linux-mips@oss.sgi.com" Subject: Re: Your problem #2 X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====_Dragon277531244025_=====" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2731 Lines: 70 This is a multi-part message in MIME format. --=====_Dragon277531244025_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable hi, My way is to extract code from glibc source,math code is= related independent so it is not so hard. But anyway for your convenience i have adapted a little program= for you. gcc t-expf.c -lm gcc -O2 t-expf.c -lm should give different output. =D4=DA 2002-02-19 22:09:00 you wrote=A3=BA >Hi Zhang, > >I have verified your problem #3 to exist on the SDE compiler as= well, >and it has been reported. > >Regarding your problem #2, do you have a self-contained example >(similar to your small program in #3) which exhibits the error?= I don't >want to spend time installing glibc and dealing with getting= that compile >to run in order to check whether this issue also exists on SDE. > >(This is similar to my request on sample failing code for= problem #1 you >reported). > >/Hartvig Regards Zhang Fuxin fxzhang@ict.ac.cn --=====_Dragon277531244025_===== Content-Type: application/octet-stream; name="t-expf.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="t-expf.c" I2luY2x1ZGUgPG1hdGguaD4KI2luY2x1ZGUgPGZlbnYuaD4KCnZvaWQgcHJpbnRfcm91bmQoKQp7 CglpbnQgcjsKCglyPWZlZ2V0cm91bmQoKTsKCWlmIChyPT1GRV9UT05FQVJFU1QpIHsKCQlwcmlu dGYoInJvdW5kaW5nIGlzIFRPTkVBUkVTVFxuIik7IAoJfWVsc2UgaWYgKHI9PUZFX0RPV05XQVJE KSB7CgkJcHJpbnRmKCJyb3VuZGluZyBpcyBET1dOV0FSRFxuIik7IAoJfWVsc2UgaWYgKHI9PUZF X1VQV0FSRCkgewoJCXByaW50Zigicm91bmRpbmcgaXMgVVBXQVJEXG4iKTsgCgl9ZWxzZSB7CgkJ cHJpbnRmKCJyb3VuZGluZyBpcyBUT1dBUkRaRVJPXG4iKTsgCgl9Cn0KCnZvaWQgcHJpbnRfZXhj ZXB0aW9uKCkKewoJcHJpbnRmKCJmbGFnczoiKTsKCWlmIChmZXRlc3RleGNlcHQoRkVfSU5WQUxJ RCkpIHByaW50ZigiaSIpOwoJaWYgKGZldGVzdGV4Y2VwdChGRV9ESVZCWVpFUk8pKSBwcmludGYo IjAiKTsKCWlmIChmZXRlc3RleGNlcHQoRkVfT1ZFUkZMT1cpKSBwcmludGYoIk8iKTsKCWlmIChm ZXRlc3RleGNlcHQoRkVfVU5ERVJGTE9XKSkgcHJpbnRmKCJVIik7CglpZiAoZmV0ZXN0ZXhjZXB0 KEZFX0lORVhBQ1QpKSBwcmludGYoIlgiKTsKCXByaW50ZigiXG4iKTsKfQoKc3RhdGljIGNvbnN0 IGZsb2F0Cm9fdGhyZXNob2xkPSAgOC44NzIxNjc5Njg4ZSswMSwgIC8qIDB4NDJiMTcxODAgKi8K dV90aHJlc2hvbGQ9IC0xLjAzOTcyMDg0MDVlKzAyOyAgLyogMHhjMmNmZjFiNSAqLwoKZmxvYXQg bXlleHBmKGZsb2F0IHgpCnsKCWZsb2F0IHo7Cgl1bnNpZ25lZCBpbnQgaHg7CglpZiAoX0xJQl9W RVJTSU9OID09IF9JRUVFXykgcmV0dXJuIHo7CglpZihmaW5pdGVmKHgpKSB7CgkgICAgaWYoeD5v X3RocmVzaG9sZCkKCQlyZXR1cm4gMS4wOwoJICAgIGVsc2UgaWYoeDx1X3RocmVzaG9sZCkKCQly ZXR1cm4gMi4wOwoJfSAKfQoKaW50IG1haW4oaW50IGFyZ2MsY2hhciAqKmFyZ3YpCnsKCWZsb2F0 IHgsemVybz0wLjA7CgoJeCA9IHplcm8vemVybzsKCWZlY2xlYXJleGNlcHQoRkVfQUxMX0VYQ0VQ VCk7CglwcmludF9leGNlcHRpb24oKTsKCXggPSBteWV4cGYoeCk7CglwcmludF9leGNlcHRpb24o KTsKCXJldHVybiAwOwp9Cgo= --=====_Dragon277531244025_=====-- From owner-linux-mips@oss.sgi.com Tue Feb 19 19:44:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K3iwu02059 for linux-mips-outgoing; Tue, 19 Feb 2002 19:44:58 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K3ik902055 for ; Tue, 19 Feb 2002 19:44:52 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 6110B590A9; Tue, 19 Feb 2002 21:35:04 -0500 (EST) Message-ID: <002501c1b9b8$a87addb0$5601010a@prefect> From: "Bradley D. LaRonde" To: "Robert Rusek" , References: <000901c1b9b0$51cdd0b0$0f1610ac@delllaptop> Subject: Re: Error Compiling 2.4.3 kernel on SGI IP22... Date: Tue, 19 Feb 2002 21:45:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 547 Lines: 19 Check your arch/mips/ld.script file. I think you need to remove the OUTPUT_FORMAT line in there. This was fixed in CVS on May 10, 2001; your snapshot might be right before that. Regards, Brad ----- Original Message ----- From: "Robert Rusek" To: Sent: Tuesday, February 19, 2002 8:45 PM Subject: Error Compiling 2.4.3 kernel on SGI IP22... > make[1]: Entering directory `/usr/src/linux-2.4.3/arch/mips/kernel' > mips-linux-ld: target elf32-bigmips not found > make: *** [vmlinux] Error 1 From owner-linux-mips@oss.sgi.com Tue Feb 19 20:28:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K4Si502671 for linux-mips-outgoing; Tue, 19 Feb 2002 20:28:44 -0800 Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K4Se902668 for ; Tue, 19 Feb 2002 20:28:40 -0800 Received: (qmail 3656 invoked from network); 20 Feb 2002 03:28:40 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 20 Feb 2002 03:28:40 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g1K3SZN04338 for linux-mips@oss.sgi.com; Tue, 19 Feb 2002 22:28:35 -0500 X-Authentication-Warning: localhost.hpti.com: lindahl set sender to lindahl@conservativecomputer.com using -f Date: Tue, 19 Feb 2002 22:28:35 -0500 From: Greg Lindahl To: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219222835.A4195@wumpus.skymv.com> Mail-Followup-To: linux-mips@oss.sgi.com References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219171238.E25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 05:12:38PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1471 Lines: 33 On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote: > As I looked into FPU/SMP issue, I realized this problem. I agree > that locking fpu owner to the current cpu is the best solution. > I bet this won't really hurt performance because any alternative would > incur transferring FPU registers across cpus, which is not a small > overhead. There are other CPUs out there with large cpu contexts, like the Alpha and Itanium. So we can look at what Linux does with them. Alpha seems to always save the fpu state (the comments say that gcc always generates code that uses it in every user process.) The Itanium seems to be lazy only for nonSMP. If a process touches the fpu registers and doesn't own their contents, it will save the fpu contents to the appropriate process' state and load the correct fpu state. For SMP it seems to always save the fpu state, if the process modified it. I suspect that the optimization of not saving the fpu state for a process that doesn't use the fpu is the most critical optimization. And that you do already. What you propose, locking the fpu owner to the current cpu, will not result in a fair solution. Imagine a 2 cpu machine with 2 processes using integer math and 1 using floating point... how much cpu time will each process get? Imagine all the funky effects. Now add in a MIPS design in which interrupts are not delivered uniformly to all the cpus... I don't know if there are any or will ever be any, but... greg From owner-linux-mips@oss.sgi.com Tue Feb 19 21:25:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K5PC303181 for linux-mips-outgoing; Tue, 19 Feb 2002 21:25:12 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K5P8903178 for ; Tue, 19 Feb 2002 21:25:08 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id UAA03511; Tue, 19 Feb 2002 20:24:34 -0800 Date: Tue, 19 Feb 2002 20:24:34 -0800 From: Jun Sun To: Greg Lindahl Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219202434.F25739@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219222835.A4195@wumpus.skymv.com>; from lindahl@conservativecomputer.com on Tue, Feb 19, 2002 at 10:28:35PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1303 Lines: 33 On Tue, Feb 19, 2002 at 10:28:35PM -0500, Greg Lindahl wrote: > > Alpha seems to always save the fpu state (the comments say that gcc > always generates code that uses it in every user process.) > I think the comment might be an execuse. :-) Never heard of gcc generating unnecessary floating point code. > I suspect that the optimization of not saving the fpu state for a > process that doesn't use the fpu is the most critical optimization. > And that you do already. If you do use floating point, I think it is pretty common to have only process that uses fpu and runs for very long. In that case, leaving FPU owned by the process also saves quite a bit. > What you propose, locking the fpu owner to the current cpu, will not > result in a fair solution. Imagine a 2 cpu machine with 2 processes > using integer math and 1 using floating point... how much cpu time > will each process get? In this case, proc that uses fpu gets about 50% of one cpu, i.e., 25% of total load, while the other two integer math proces split the rest 75%, which gives 37.5% each. Not too bad in my opinion. > Imagine all the funky effects. Now add in a > MIPS design in which interrupts are not delivered uniformly to all the > cpus... This is chip-specific, I think. Not related to general MIPS arch. Jun From owner-linux-mips@oss.sgi.com Tue Feb 19 21:32:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K5WXo03279 for linux-mips-outgoing; Tue, 19 Feb 2002 21:32:33 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K5WT903276 for ; Tue, 19 Feb 2002 21:32:30 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16dOQY-0005mZ-00; Tue, 19 Feb 2002 23:32:22 -0500 Date: Tue, 19 Feb 2002 23:32:22 -0500 From: Daniel Jacobowitz To: Jun Sun Cc: Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219233222.A22099@nevyn.them.org> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020219202434.F25739@mvista.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1275 Lines: 32 On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote: > On Tue, Feb 19, 2002 at 10:28:35PM -0500, Greg Lindahl wrote: > > > > Alpha seems to always save the fpu state (the comments say that gcc > > always generates code that uses it in every user process.) > > > > I think the comment might be an execuse. :-) Never heard of gcc > generating unnecessary floating point code. I have :) It may do memory moves in them, for instance. Not sure if that makes sense on Alpha. > > I suspect that the optimization of not saving the fpu state for a > > process that doesn't use the fpu is the most critical optimization. > > And that you do already. > > If you do use floating point, I think it is pretty common to have > only process that uses fpu and runs for very long. In that case, > leaving FPU owned by the process also saves quite a bit. Not true. For instance, on a processor with hardware FPU, setjmp() will save FPU registers. That means most processes will actually end up taking the FPU at least once. The general approach in Linux is to disable lazy switching on SMP. I'm 95% sure that PowerPC does that. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Feb 19 21:33:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K5Xm803350 for linux-mips-outgoing; Tue, 19 Feb 2002 21:33:48 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K5Xg903347 for ; Tue, 19 Feb 2002 21:33:42 -0800 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16dORn-0005n4-00; Tue, 19 Feb 2002 23:33:39 -0500 Date: Tue, 19 Feb 2002 23:33:39 -0500 From: Daniel Jacobowitz To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Error Compiling 2.4.3 kernel on SGI IP22... Message-ID: <20020219233339.B22099@nevyn.them.org> References: <000901c1b9b0$51cdd0b0$0f1610ac@delllaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c1b9b0$51cdd0b0$0f1610ac@delllaptop> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1380 Lines: 42 On Tue, Feb 19, 2002 at 05:45:46PM -0800, Robert Rusek wrote: > Initially I got errors telling me that mips-linux-gcc, mips-linux-ld, > and mips-linux-ar did not exists. I simply made a link for: > > mips-linux-gcc -> gcc > mips-linux-ld -> ld > mips-linux-ar -> ar No, set CROSS_COMPILE=mips-linux- > mips-linux-ld -static -G 0 -T arch/mips/ld.script > arch/mips/kernel/head.o arch/m > ips/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/f > s.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o > arch/mips/sgi/kernel/ip22-kern.o > \ > drivers/block/block.o drivers/char/char.o drivers/misc/misc.o > drivers/ne > t/net.o drivers/media/media.o drivers/scsi/scsidrv.o > drivers/cdrom/driver.o dri > vers/sgi/sgi.a drivers/video/video.o \ > net/network.o \ > arch/mips/lib/lib.a /usr/src/linux-2.4.3/lib/lib.a > arch/mips/arc/arclib. > a \ > --end-group \ > -o vmlinux > mips-linux-ld: target elf32-bigmips not found > make: *** [vmlinux] Error 1 2.4.3 is too old for your tools. I recommend you use a newer kernel. Otherwise, just changing that to elf32-tradbigmips should work. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Feb 19 21:48:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K5mHV03489 for linux-mips-outgoing; Tue, 19 Feb 2002 21:48:17 -0800 Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K5mD903486 for ; Tue, 19 Feb 2002 21:48:13 -0800 Received: (qmail 11470 invoked from network); 20 Feb 2002 04:48:13 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 20 Feb 2002 04:48:13 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g1K4m8C04590 for linux-mips@oss.sgi.com; Tue, 19 Feb 2002 23:48:08 -0500 X-Authentication-Warning: localhost.hpti.com: lindahl set sender to lindahl@conservativecomputer.com using -f Date: Tue, 19 Feb 2002 23:48:08 -0500 From: Greg Lindahl To: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020219234808.A4475@wumpus.skymv.com> Mail-Followup-To: linux-mips@oss.sgi.com References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219202434.F25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 08:24:34PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1088 Lines: 29 On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote: > I think the comment might be an execuse. :-) Never heard of gcc > generating unnecessary floating point code. I don't really remember, but I think the Alpha calling standards encourages using some of the fp registers as scratch all the time. The price is that you have to always save them, but you get more registers, which helps you avoid spills, which speeds up all kinds of code. > If you do use floating point, I think it is pretty common to have > only process that uses fpu and runs for very long. In that case, > leaving FPU owned by the process also saves quite a bit. You're assuming, I guess, that there are a lot of interrupts. OK, so how much CPU time is saved? You can't compare the cost if you don't know the number. > In this case, proc that uses fpu gets about 50% of one cpu, i.e., > 25% of total load, while the other two integer math proces split the > rest 75%, which gives 37.5% each. Not too bad in my opinion. One man's "not too bad" can be another man's "oh my God, that's horrible!" -- greg From owner-linux-mips@oss.sgi.com Tue Feb 19 22:36:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K6aee04096 for linux-mips-outgoing; Tue, 19 Feb 2002 22:36:40 -0800 Received: from gda-server ([202.88.152.146]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K6aa904093 for ; Tue, 19 Feb 2002 22:36:36 -0800 Received: from [192.168.0.186] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Wed, 20 Feb 2002 11:09:32 Message-ID: <3C73DE53.1D7D1930@gdatech.co.in> Date: Wed, 20 Feb 2002 23:05:15 +0530 From: santhosh <ps.santhosh@gdatech.co.in> Organization: gdatech X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: MIPS64 Kernel SB1250 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 226 Lines: 12 Hai MIPSian I am working one MIPS64 type processor(SB1250 Sibyte family) I need MIPS64 kernel to porting my project board(SB1250).. shall I get it?? or tell where can i go to collect..... with regds sant From owner-linux-mips@oss.sgi.com Wed Feb 20 01:27:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1K9RYG06644 for linux-mips-outgoing; Wed, 20 Feb 2002 01:27:34 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1K9RS906640 for ; Wed, 20 Feb 2002 01:27:29 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g1K8RK411834; Wed, 20 Feb 2002 08:27:21 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15475.24039.877276.257999@gladsmuir.algor.co.uk> Date: Wed, 20 Feb 2002 08:27:19 +0000 To: Jun Sun Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? In-Reply-To: <20020219171238.E25739@mvista.com> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1006 Lines: 26 Somewhere in this thread: > > > > > Hmm, I see. The lazy fpu context switch code is not SMP safe. > > > > > I see fishy things like "last_task_used_math" etc... Lazy FPU context switching? Let's turn the whole thing off... It may be heretical... but the lazy FPU context switch was invented for 16MHz CPUs using a write-through cache and non-burst memory, where saving 16 x 64-bit registers took 6us or so (and quite a bit less, later, to read them back). Call it 8us. A 500MHz CPU with a writeback primary cache - which typically keeps up with the CPU pipeline - takes about 120ns to do the job (there are more registers these days). The overhead is not only less than 2% in absolute terms, but is about a third what it used to be relative to the overall CPU performance... Really, is it worth all this trouble? 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 Wed Feb 20 02:31:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KAVAN07935 for linux-mips-outgoing; Wed, 20 Feb 2002 02:31:10 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KAV5907928 for ; Wed, 20 Feb 2002 02:31:05 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id BB589884; Wed, 20 Feb 2002 10:30:40 +0100 (CET) Received: by localhost (Postfix, from userid 1000) id DA7E51A23B; Wed, 20 Feb 2002 10:27:35 +0100 (CET) Date: Wed, 20 Feb 2002 10:27:35 +0100 From: Florian Lohoff To: Jun Sun Cc: Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220092735.GE11654@paradigm.rfc822.org> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5oH/S/bF6lOfqCQb" Content-Disposition: inline In-Reply-To: <20020219202434.F25739@mvista.com> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1072 Lines: 36 --5oH/S/bF6lOfqCQb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote: > On Tue, Feb 19, 2002 at 10:28:35PM -0500, Greg Lindahl wrote: > > Alpha seems to always save the fpu state (the comments say that gcc > > always generates code that uses it in every user process.) >=20 > I think the comment might be an execuse. :-) Never heard of gcc > generating unnecessary floating point code. >=20 Its not gcc its glibc's startup code i guess ...=20 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --5oH/S/bF6lOfqCQb 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 iD8DBQE8c2wHUaz2rXW+gJcRAv0mAJ9NrdwpH2Njnrwlzg6tKsC9AJJwLgCfWuW6 GyuUi8w2+Xt/ld7S1fZuzjs= =Cpki -----END PGP SIGNATURE----- --5oH/S/bF6lOfqCQb-- From owner-linux-mips@oss.sgi.com Wed Feb 20 02:31:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KAVIS07964 for linux-mips-outgoing; Wed, 20 Feb 2002 02:31:18 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KAV5907929 for ; Wed, 20 Feb 2002 02:31:05 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 1C0BE883; Wed, 20 Feb 2002 10:30:41 +0100 (CET) Received: by localhost (Postfix, from userid 1000) id 838821A23B; Wed, 20 Feb 2002 10:30:12 +0100 (CET) Date: Wed, 20 Feb 2002 10:30:12 +0100 From: Florian Lohoff To: Dominic Sweetman Cc: Jun Sun , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220093012.GF11654@paradigm.rfc822.org> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <15475.24039.877276.257999@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dgjlcl3Tl+kb3YDk" Content-Disposition: inline In-Reply-To: <15475.24039.877276.257999@gladsmuir.algor.co.uk> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1095 Lines: 34 --dgjlcl3Tl+kb3YDk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 08:27:19AM +0000, Dominic Sweetman wrote: > It may be heretical... but the lazy FPU context switch was invented > for 16MHz CPUs using a write-through cache and non-burst memory, where > saving 16 x 64-bit registers took 6us or so (and quite a bit less, > later, to read them back). Call it 8us. We are still running on good ol Decstations *snief* Going the way to make it SMP only like others archs seem to do it would be good. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --dgjlcl3Tl+kb3YDk 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 iD8DBQE8c2ykUaz2rXW+gJcRAtT+AJ40ZITjrI5zafu+ckPVIRKwLT4UWACeJCfS pak03BnkPcyMuxk5LWtM52s= =h2CX -----END PGP SIGNATURE----- --dgjlcl3Tl+kb3YDk-- From owner-linux-mips@oss.sgi.com Wed Feb 20 02:49:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KAn0i08344 for linux-mips-outgoing; Wed, 20 Feb 2002 02:49:00 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KAmv908341 for ; Wed, 20 Feb 2002 02:48:57 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id BAA03695; Wed, 20 Feb 2002 01:48:22 -0800 Date: Wed, 20 Feb 2002 01:48:21 -0800 From: Jun Sun To: Daniel Jacobowitz Cc: Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220014821.H25739@mvista.com> References: <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> <20020219233222.A22099@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219233222.A22099@nevyn.them.org>; from dan@debian.org on Tue, Feb 19, 2002 at 11:32:22PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1092 Lines: 27 On Tue, Feb 19, 2002 at 11:32:22PM -0500, Daniel Jacobowitz wrote: > > If you do use floating point, I think it is pretty common to have > > only process that uses fpu and runs for very long. In that case, > > leaving FPU owned by the process also saves quite a bit. > > Not true. For instance, on a processor with hardware FPU, setjmp() > will save FPU registers. That means most processes will actually end > up taking the FPU at least once. > It is true that almost all process will take FPU once, but that does not affect my statement unless you have a lot of programs come in and go away. On other hand, I do agree with Greg that hand-waving does not mean much here. It would be nice to have some performance data on a benchmark apps. Any good candidate? It should be easy to do a comparison. BTW, I just found out that almost all processes have their used_math bit set - this is because init uses math at the beginning and later all forked processes inherit that bit. Interesting - that also hides a couple of bugs related to if (!current->used) branch in do_cpu(). Jun From owner-linux-mips@oss.sgi.com Wed Feb 20 02:57:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KAvZH08631 for linux-mips-outgoing; Wed, 20 Feb 2002 02:57:35 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KAvU908626 for ; Wed, 20 Feb 2002 02:57:31 -0800 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA13863; Wed, 20 Feb 2002 10:56:50 +0100 (MET) Date: Wed, 20 Feb 2002 10:56:50 +0100 (MET) From: Geert Uytterhoeven To: Greg Lindahl cc: Linux/MIPS Development Subject: Re: FPU emulator unsafe for SMP? In-Reply-To: <20020219222835.A4195@wumpus.skymv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1329 Lines: 32 On Tue, 19 Feb 2002, Greg Lindahl wrote: > On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote: > > As I looked into FPU/SMP issue, I realized this problem. I agree > > that locking fpu owner to the current cpu is the best solution. > > I bet this won't really hurt performance because any alternative would > > incur transferring FPU registers across cpus, which is not a small > > overhead. [...] > What you propose, locking the fpu owner to the current cpu, will not > result in a fair solution. Imagine a 2 cpu machine with 2 processes > using integer math and 1 using floating point... how much cpu time > will each process get? Imagine all the funky effects. Now add in a > MIPS design in which interrupts are not delivered uniformly to all the > cpus... I don't know if there are any or will ever be any, but... What if you have 2 processes who are running at the same CPU when they start using the FPU? Won't they be locked to that CPU, while all other's stay idle (if no other processes are to be run)? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Wed Feb 20 03:07:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KB7ux08979 for linux-mips-outgoing; Wed, 20 Feb 2002 03:07:56 -0800 Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KB7l908974 for ; Wed, 20 Feb 2002 03:07:47 -0800 Received: from gladsmuir.algor.co.uk.algor.co.uk (IDENT:dom@gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g1KA7e414594; Wed, 20 Feb 2002 10:07:41 GMT From: Dominic Sweetman MIME-Version: 1.0 Message-ID: <15475.30060.604015.257576@gladsmuir.algor.co.uk> Date: Wed, 20 Feb 2002 10:07:40 +0000 To: Zhang Fuxin Cc: nigel@algor.co.uk, Hartvig Ekner , "linux-mips@oss.sgi.com" Subject: Re: Re: Re: math broken on mips In-Reply-To: <200202200149.g1K1nT900770@oss.sgi.com> References: <200202200149.g1K1nT900770@oss.sgi.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid User-Agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YbKEI=?= =?ISO-2022-JP?B?GyRCJU4+MRsoQg==?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2766 Lines: 71 Zhang, > a quick example: > main() > { > float t,zero=0.0; > t = 0.0/0.0; > printf("t=%08lx\n",*(unsigned long*)&t); (0x7fc00000) > t = zero/zero; > printf("t=%08lx\n",*(unsigned long*)&t); (0x7fbfffff) > } > > you should see different output,because the first one is optimized > by gcc to a QNaN,but it's signalling for MIPS. On my RedHat 7.1 x86 machine you get something of the same kind. The constant expression ("0.0/0.0") is always computed at compile time, but the "zero/zero" is only resolved as a constant once you turn on the optimiser. So I see two different values printed without optimisation, but the same value twice with -O2. (Note that the 0.0/0.0 will be computed as a double, while zero/zero will be computed as a float - but I don't think that makes any difference in this case). A floating point purist would say that the compiler should never try to propagate floating point constants where the calculation might produce any exception or exceptional result. That's standards-correct, but unacceptable in practice. If I write float pi = 3.1415926535897932384626433832795029; the decimal->binary conversion will be inexact and might produce an exception (if that flag is set: it almost never is, but the compiler doesn't know that). But I'll be annoyed if my compiler doesn't generate a binary floating point value for 'pi' at compile time. Once you open this door and allow the compiler to work on some floating point constants, life gets tougher. It might be a good rule that if an expression produces an exceptional value (NaN, infinity), you leave it to run-time... but it may mean some ugly back-tracking. In this case gcc for x86 (and MIPS) has had no inhibitions: it's just seen a constant expression and reduced it. With no way to predict the FP mode settings which will be in effect it has no way of knowing what kind of exceptional result to produce in this case. The compiler is now kind of outside the specs: but it's still better style to produce a signalling NaN (anyone who wanted their NaNs quiet probably has exceptions turned off so won't know the difference; anyone who didn't want their NaNs quiet should probably get an exception). But frankly, it's not important. In expecting floating point maths to "just work" in corner cases, you're expecting too much. If you want to be appropriately frightened, here's a paper I came across fairly recently - David Goldberg's "What Every Computer Scientist should Know about Floating Point": http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf -- 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 Wed Feb 20 03:14:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KBEWI09159 for linux-mips-outgoing; Wed, 20 Feb 2002 03:14:32 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KBEN909156 for ; Wed, 20 Feb 2002 03:14:23 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA11758; Wed, 20 Feb 2002 02:14:08 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA17723; Wed, 20 Feb 2002 02:14:06 -0800 (PST) Message-ID: <006001c1b9f7$7da1c920$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Jun Sun" Cc: "Greg Lindahl" , References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> <20020219233222.A22099@nevyn.them.org> Subject: Re: FPU emulator unsafe for SMP? Date: Wed, 20 Feb 2002 11:14:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3414 Lines: 82 Daniel Jacobowitz wrote: > On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote: > > On Tue, Feb 19, 2002 at 10:28:35PM -0500, Greg Lindahl wrote: > > > > > > Alpha seems to always save the fpu state (the comments say that gcc > > > always generates code that uses it in every user process.) > > > > I think the comment might be an execuse. :-) Never heard of gcc > > generating unnecessary floating point code. It ain't gcc, it's glibc. And it ain't just on the Alpha, just about every MIPS process has FP state, even those who do not declare a single FP variable. However that's not a real justification for whether or not one does lazy FPU context management. See below... > I have :) It may do memory moves in them, for instance. Not sure if > that makes sense on Alpha. It probably does on one implementation or another. We used the same trick back in the 1980's in libc for the Fairchild Clipper, since it allowed better parallelism between address computation and memory operations. Not only for memory moves, but string operations! > > > I suspect that the optimization of not saving the fpu state for a > > > process that doesn't use the fpu is the most critical optimization. > > > And that you do already. Let me rephrase that - the advantage is of not saving *or restoring* the FPU state for a process that isn't using the FPU *in its current time slice*. > > If you do use floating point, I think it is pretty common to have > > only process that uses fpu and runs for very long. In that case, > > leaving FPU owned by the process also saves quite a bit. One cannot make design decisions based on what one "thinks is pretty common". Binding threads to CPUs (CPU affinity) is almost always more efficient when the behavior of the workload looks like batch FORTRAN processing. It's when one gets a mix of computational and interactive jobs that it often creates unfortunate artifacts, and thus must be handled with care. > Not true. For instance, on a processor with hardware FPU, setjmp() > will save FPU registers. That means most processes will actually end > up taking the FPU at least once. Almost all MIPS/Linux threads, from init() onward, have FPU state, due to setjmp(), printf() (which uses the FP registers even if one does not specify a floating point data item or format), etc. > The general approach in Linux is to disable lazy switching on SMP. I'm > 95% sure that PowerPC does that. Has anyone ever measured the performance impact of lazy FPU context switching on MIPS? It's one of those ideas that was trendy in the 1980's, but I recall that when we implemented it for SVR2 on the Fairchild Clipper (which had only 16 FP registers), the measured improvement on average context switch time was tiny - a percent or so. We left it in, because it worked and it *was* an improvement, but we would never have gone through the hassle had we known how little it would buy us. It occurs to me that we can to some degree "split the difference" on FPU context management for SMP if we *always* save the FPU state when a thread switches out, but preserve the logic that schedules threads with CU1 inhibited so that the context is only *loaded* if the thread executes FP instructions. That would save about half of the context switch overhead for non-FP-intensive threads, while eliminating the migration problem. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Feb 20 04:13:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KCDQn10765 for linux-mips-outgoing; Wed, 20 Feb 2002 04:13:26 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KCDN910762 for ; Wed, 20 Feb 2002 04:13:23 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA12341; Wed, 20 Feb 2002 03:13:16 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA19202; Wed, 20 Feb 2002 03:13:13 -0800 (PST) Message-ID: <008001c1b9ff$bffe5600$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Geert Uytterhoeven" , "Greg Lindahl" Cc: "Linux/MIPS Development" References: Subject: Re: FPU emulator unsafe for SMP? Date: Wed, 20 Feb 2002 12:14:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1072 Lines: 26 Geert wrote: > On Tue, 19 Feb 2002, Greg Lindahl wrote: > > On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote: > > > What you propose, locking the fpu owner to the current cpu, will not > > result in a fair solution. Imagine a 2 cpu machine with 2 processes > > using integer math and 1 using floating point... how much cpu time > > will each process get? Imagine all the funky effects. Now add in a > > MIPS design in which interrupts are not delivered uniformly to all the > > cpus... I don't know if there are any or will ever be any, but... > > What if you have 2 processes who are running at the same CPU when they start > using the FPU? Won't they be locked to that CPU, while all other's stay idle > (if no other processes are to be run)? What would bind a thread to a CPU would not be having FPU state, but owning the *current* FPU state. Only one such process has that characteristic. Any others who might or might not have used the FPU in the past have their FPU state in the thread context structure, and can be freely migrated. Kevin K. From owner-linux-mips@oss.sgi.com Wed Feb 20 07:00:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF0Md13435 for linux-mips-outgoing; Wed, 20 Feb 2002 07:00:22 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF0F913425 for ; Wed, 20 Feb 2002 07:00:18 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KDOGd16319; Wed, 20 Feb 2002 14:24:16 +0100 Date: Wed, 20 Feb 2002 14:24:16 +0100 From: Ralf Baechle To: Daniel Jacobowitz Cc: Jun Sun , Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220142416.F15588@dea.linux-mips.net> References: <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> <20020219233222.A22099@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219233222.A22099@nevyn.them.org>; from dan@debian.org on Tue, Feb 19, 2002 at 11:32:22PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 665 Lines: 15 On Tue, Feb 19, 2002 at 11:32:22PM -0500, Daniel Jacobowitz wrote: > > If you do use floating point, I think it is pretty common to have > > only process that uses fpu and runs for very long. In that case, > > leaving FPU owned by the process also saves quite a bit. > > Not true. For instance, on a processor with hardware FPU, setjmp() > will save FPU registers. That means most processes will actually end > up taking the FPU at least once. The cleassic reason to take the FPU is the ctc1 $0, $31 instruction used to initalize the FPU control register rsp. it's equivalent on other architectures. This should be fixed in glibc since a few years. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:01:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF10F13620 for linux-mips-outgoing; Wed, 20 Feb 2002 07:01:00 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF0l913560 for ; Wed, 20 Feb 2002 07:00:48 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KD3fo16150; Wed, 20 Feb 2002 14:03:41 +0100 Date: Wed, 20 Feb 2002 14:03:41 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220140341.B15588@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel>; from kevink@mips.com on Wed, Feb 20, 2002 at 01:08:30AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3620 Lines: 69 On Wed, Feb 20, 2002 at 01:08:30AM +0100, Kevin D. Kissell wrote: > It's gotta be done. I mean, the last I heard (which was a long > time ago) mips64 Linux was keeping the CPU node number in > a watchpoint register (or something equally unwholesome) and > using that value as an index into tables. NUMA nitpicking: cpu number != node number. We store the CPU number in the PTEBase field from bit 23 on in the c0_context register. This number is then used to index the pgd_current[] array to find the root of the page table tree. Having some extra on-die memory for such tiny bits of frequently accessed information on the CPU die would be really cool. I bet it would make a visible difference. > Sticking all the per-CPU > state in a kseg3 VM page which is allocated and locked at boot > time would be much cleaner and on the average probably quite > a bit faster (definitely faster in the kernel but to be fair one has > to factor in the increase in TLB pressure from the locked entry). The plan is actually to map 32-bit page tables into a flat array of 4mb in size and use one wired mapping for that. The other half of the TLB entry mapping the root would still be available. > But getting back to the original topic, there's another fun bug > waiting for us in MIPS/Linux SMP floating point that can't > be fixed as easly with VM slight-of-hand. Consider processes > "A" and "B", where A uses FP and B does not: A gets scheduled > on CPU 1, runs for a while, gets preempted, and B gets CPU 1. > CPU 2 gets freed, so A gets scheduled on CPU 2. Unfortunately, > A's FP state is still in the FP register set of CPU 1. The lazy FPU > context switch either needs to be turned off (bleah!) or be fixed > for SMP to handle the case where the "owner" of the FPR's > on one CPU gets scheduled on another. > > The brute force would be somehow to send an interrupt to the CPU > with the FP state that will cause it to cough it up into the thread context > area. One alternative would be to give strict CPU affinity to the thread > that has it's FP state on a particular CPU. That could complicate load > balancing, but might not really be too bad. At most one thread per CPU > will be non-migratable at a given point in time. In the above scenario, > "A" could never migrate off of CPU 1, but "B" could, and would > presumably be picked up by an idle CPU 2 as soon as it's time slice > is up on CPU 1. That will be less efficient than doing an "FPU shootdown" > in some cases, but it should also be more portable and easier > to get right. > > Does this come up in x86-land? The FPU state is much smaller > there, so lazy context switching is presumably less important. Yes, it's an issue also on x86-land. Since the i386 code stopped using task segments for context switching their whole context switching code has actually become reasonably sane and can be used as a template. In particular I like the fact that they got away without tons of CONFIG_SMP that used to live in their kernel fp code. Time to re-read the i386 code. Using an IPI for migration of an FP context between CPUs a really bad idea which may result in rather sucky worst case context switching times. One of the facts that many performace tradeoffs in the Linux world assume to be granted is blindingly fast context switch times. The number of SMP platforms is growing. I thought it's mindboggling but people are actually building SMP on a chip systems from cores that were designed for uniprocessing. I'd expect such systems to perform like the early SMPs from the 80's, that's not very much at all ... Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:00:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF0Ta13464 for linux-mips-outgoing; Wed, 20 Feb 2002 07:00:29 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF0N913443 for ; Wed, 20 Feb 2002 07:00:24 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KDAqd16227; Wed, 20 Feb 2002 14:10:52 +0100 Date: Wed, 20 Feb 2002 14:10:51 +0100 From: Ralf Baechle To: Greg Lindahl Cc: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220141051.D15588@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219222835.A4195@wumpus.skymv.com>; from lindahl@conservativecomputer.com on Tue, Feb 19, 2002 at 10:28:35PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 524 Lines: 12 On Tue, Feb 19, 2002 at 10:28:35PM -0500, Greg Lindahl wrote: > What you propose, locking the fpu owner to the current cpu, will not > result in a fair solution. Imagine a 2 cpu machine with 2 processes > using integer math and 1 using floating point... how much cpu time > will each process get? Imagine all the funky effects. Now add in a > MIPS design in which interrupts are not delivered uniformly to all the > cpus... I don't know if there are any or will ever be any, but... They already exist, SGI Origin. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:00:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF0et13515 for linux-mips-outgoing; Wed, 20 Feb 2002 07:00:40 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF0Z913501 for ; Wed, 20 Feb 2002 07:00:36 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KD9HY16210; Wed, 20 Feb 2002 14:09:17 +0100 Date: Wed, 20 Feb 2002 14:09:17 +0100 From: Ralf Baechle To: Jun Sun Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220140917.C15588@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219171238.E25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 05:12:38PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 749 Lines: 17 On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote: > > It's gotta be done. I mean, the last I heard (which was a long > > time ago) mips64 Linux was keeping the CPU node number in > > a watchpoint register (or something equally unwholesome) > > It seems that people are getting smarter by putting cpu id to > context register. In fact isn't this part of new MIPS > standard? The context register is actually intended to be used for indexing a flat 4mb array of pagetables on a 32-bit processor. It's a bit ill-defined on R4000-class processors as it assumes a size of 8 bytes per pte, so cannot be used in the Linux/MIPS kernel without shifting bits around. Also in case of Linux it means entering the world of cache aliases ... Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:00:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF03D13368 for linux-mips-outgoing; Wed, 20 Feb 2002 07:00:03 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KExm913344 for ; Wed, 20 Feb 2002 06:59:51 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KDIfO16279; Wed, 20 Feb 2002 14:18:41 +0100 Date: Wed, 20 Feb 2002 14:18:41 +0100 From: Ralf Baechle To: Jun Sun Cc: Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220141841.E15588@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219202434.F25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 08:24:34PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 681 Lines: 16 On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote: > > What you propose, locking the fpu owner to the current cpu, will not > > result in a fair solution. Imagine a 2 cpu machine with 2 processes > > using integer math and 1 using floating point... how much cpu time > > will each process get? > > In this case, proc that uses fpu gets about 50% of one cpu, i.e., 25% of > total load, while the other two integer math proces split the rest 75%, > which gives 37.5% each. Not too bad in my opinion. Certainly not good either. Still not having checked the x86 solution I currently favor the approach of only always storing the fp context but lazily restoring it. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:01:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF1rW13757 for linux-mips-outgoing; Wed, 20 Feb 2002 07:01:53 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF1m913754 for ; Wed, 20 Feb 2002 07:01:49 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KCNm615858; Wed, 20 Feb 2002 13:23:48 +0100 Date: Wed, 20 Feb 2002 13:23:48 +0100 From: Ralf Baechle To: santhosh <ps.santhosh@gdatech.co.in> Cc: linux-mips@oss.sgi.com Subject: Re: MIPS64 Kernel SB1250 Message-ID: <20020220132348.A15588@dea.linux-mips.net> References: <3C73DE53.1D7D1930@gdatech.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C73DE53.1D7D1930@gdatech.co.in>; from ps.santhosh@gdatech.co.in on Wed, Feb 20, 2002 at 11:05:15PM +0530 X-Accept-Language: de,en,fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1KF1o913755 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 564 Lines: 16 On Wed, Feb 20, 2002 at 11:05:15PM +0530, santhosh wrote: To: santhosh <ps.santhosh@gdatech.co.in> ^^ (Your from address has a control-C character embedded. That will make many mailsystems drop your email!) > I am working one MIPS64 type processor(SB1250 Sibyte family) > I need MIPS64 kernel to porting my project board(SB1250).. > > shall I get it?? or tell where can i go to collect..... Ask Sibyte / Broadcom for their latest kernel. Unfortunately recently they changed the server's name so I don't know it offhand. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:03:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KF31k13867 for linux-mips-outgoing; Wed, 20 Feb 2002 07:03:01 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KF2t913847 for ; Wed, 20 Feb 2002 07:02:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KDunJ16534; Wed, 20 Feb 2002 14:56:49 +0100 Date: Wed, 20 Feb 2002 14:56:49 +0100 From: Ralf Baechle To: Florian Lohoff Cc: Dominic Sweetman , Jun Sun , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220145649.H15588@dea.linux-mips.net> References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <15475.24039.877276.257999@gladsmuir.algor.co.uk> <20020220093012.GF11654@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: <20020220093012.GF11654@paradigm.rfc822.org>; from flo@rfc822.org on Wed, Feb 20, 2002 at 10:30:12AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 702 Lines: 16 On Wed, Feb 20, 2002 at 10:30:12AM +0100, Florian Lohoff wrote: > > It may be heretical... but the lazy FPU context switch was invented > > for 16MHz CPUs using a write-through cache and non-burst memory, where > > saving 16 x 64-bit registers took 6us or so (and quite a bit less, > > later, to read them back). Call it 8us. > > We are still running on good ol Decstations *snief* Going the way to > make it SMP only like others archs seem to do it would be good. While I don't intend to kill support for any of the old machines like DECstations as long as anybody keeps maintaining support for them certainly performance tradeoffs in generic code will not be based on antique systems ... Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:23:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KFNr514515 for linux-mips-outgoing; Wed, 20 Feb 2002 07:23:53 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KFNj914512 for ; Wed, 20 Feb 2002 07:23:45 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) 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 GAA04445 for ; Wed, 20 Feb 2002 06:23:41 -0800 (PST) mail_from (ralf@linux-mips.net) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KDoNa16490; Wed, 20 Feb 2002 14:50:23 +0100 Date: Wed, 20 Feb 2002 14:50:23 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Daniel Jacobowitz , Jun Sun , Greg Lindahl , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220145023.G15588@dea.linux-mips.net> References: <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> <20020219233222.A22099@nevyn.them.org> <006001c1b9f7$7da1c920$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006001c1b9f7$7da1c920$0deca8c0@Ulysses>; from kevink@mips.com on Wed, Feb 20, 2002 at 11:14:02AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3282 Lines: 67 On Wed, Feb 20, 2002 at 11:14:02AM +0100, Kevin D. Kissell wrote: > One cannot make design decisions based on what one > "thinks is pretty common". Binding threads to CPUs > (CPU affinity) is almost always more efficient when > the behavior of the workload looks like batch FORTRAN > processing. It's when one gets a mix of computational > and interactive jobs that it often creates unfortunate > artifacts, and thus must be handled with care. Today's CPU performance is mainly dictated by exploiting caches as well as possible. So that means timeslices should be as long as possible. At the same time we have the contradicting issue of scheduling latency. The Linux scheduler already contains some heuristics that is trying to find a sweet spot in between those two. > > Not true. For instance, on a processor with hardware FPU, setjmp() > > will save FPU registers. That means most processes will actually end > > up taking the FPU at least once. > > Almost all MIPS/Linux threads, from init() onward, have FPU state, > due to setjmp(), printf() (which uses the FP registers even > if one does not specify a floating point data item or format), etc. Printf doesn't ever use floating point due to possible rounding errors. > Has anyone ever measured the performance impact of > lazy FPU context switching on MIPS? It's one of those > ideas that was trendy in the 1980's, but I recall that when > we implemented it for SVR2 on the Fairchild Clipper > (which had only 16 FP registers), the measured improvement > on average context switch time was tiny - a percent or so. > We left it in, because it worked and it *was* an improvement, > but we would never have gone through the hassle had we > known how little it would buy us. These days I assume the difference to be greater for cache reasons. Our stored fp registers take 256 bytes and also tend to be located at a constant offset from start of the 8kB (64-bit: 16kB) aligned task_struct. Combined with the usually low degree of cache associativity on MIPS that means we'll frequently miss L1. And many MIPS systems still don't come with L2 caches, so fiddling with anything stored in the task_struct may easily become quite expensive. In fact on the worst case CPU, the R4000PC context switching the fprs will result in guaranteed worst case performance, we'll *always* have to writeback / refill the affected cache lines from memory. In this context I should also note that the FP context used by the kernel stores in the 32-bit kernel provides space for 32 double precission registers. We only use the 16/32 register model so will pump twice as many cachelines over the memory bus at postcard speed ... Btw, Fairchild Clipper is the same Clipper that was used by Intergraph? > It occurs to me that we can to some degree "split > the difference" on FPU context management for > SMP if we *always* save the FPU state when a > thread switches out, but preserve the logic that > schedules threads with CU1 inhibited so that the > context is only *loaded* if the thread executes > FP instructions. That would save about half of > the context switch overhead for non-FP-intensive > threads, while eliminating the migration problem. As I also suggested in my other mail. Guess we got a winner. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 07:41:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KFfi316823 for linux-mips-outgoing; Wed, 20 Feb 2002 07:41:44 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KFfb916814; Wed, 20 Feb 2002 07:41:37 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA14433; Wed, 20 Feb 2002 06:41:29 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA23848; Wed, 20 Feb 2002 06:41:28 -0800 (PST) Message-ID: <002f01c1ba1c$d6d7c4c0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Jun Sun" Cc: References: <3C6C6ACF.CAD2FFC@mvista.com> <20020215031118.B21011@dea.linux-mips.net> <20020214232030.A3601@mvista.com> <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020220140917.C15588@dea.linux-mips.net> Subject: Re: FPU emulator unsafe for SMP? Date: Wed, 20 Feb 2002 15:42:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1243 Lines: 31 Ralf wrote: > On Tue, Feb 19, 2002 at 05:12:38PM -0800, Jun Sun wrote: > > > > It's gotta be done. I mean, the last I heard (which was a long > > > time ago) mips64 Linux was keeping the CPU node number in > > > a watchpoint register (or something equally unwholesome) > > > > It seems that people are getting smarter by putting cpu id to > > context register. In fact isn't this part of new MIPS > > standard? > > The context register is actually intended to be used for indexing a flat > 4mb array of pagetables on a 32-bit processor. It's a bit ill-defined > on R4000-class processors as it assumes a size of 8 bytes per pte, so > cannot be used in the Linux/MIPS kernel without shifting bits around. I think what Jun Sun is alluding to is the fact that MIPS has announced that the next revision of the MIPS privileged resource architecture will support "variable geometry" MMU features that will, among other things, allow for the Context register to be configured to provide for smaller PTEs and non-flat page table organizations. It was announced and described at Microprocessor Forum last year. The spec has been stable for a long time now, but I don't know if it's yet public. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Feb 20 07:46:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KFkwf16994 for linux-mips-outgoing; Wed, 20 Feb 2002 07:46:58 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KFkk916990; Wed, 20 Feb 2002 07:46:46 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08601; Wed, 20 Feb 2002 15:46:32 +0100 (MET) Date: Wed, 20 Feb 2002 15:46:32 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? In-Reply-To: <20020220140917.C15588@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 695 Lines: 16 On Wed, 20 Feb 2002, Ralf Baechle wrote: > The context register is actually intended to be used for indexing a flat > 4mb array of pagetables on a 32-bit processor. It's a bit ill-defined > on R4000-class processors as it assumes a size of 8 bytes per pte, so > cannot be used in the Linux/MIPS kernel without shifting bits around. Ill??? I think someone was just longsighted enough not to limit PTEs to 38-bit physical addresses. A shift costs a single cycle if we want to save memory. -- + 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 Feb 20 08:06:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KG6Hf18263 for linux-mips-outgoing; Wed, 20 Feb 2002 08:06:17 -0800 Received: from dea.linux-mips.net (a1as06-p249.stg.tli.de [195.252.187.249]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KG6C918260 for ; Wed, 20 Feb 2002 08:06:12 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1KF5D817400; Wed, 20 Feb 2002 16:05:13 +0100 Date: Wed, 20 Feb 2002 16:05:13 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220160513.A17227@dea.linux-mips.net> References: <20020220140917.C15588@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Feb 20, 2002 at 03:46:32PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1054 Lines: 22 On Wed, Feb 20, 2002 at 03:46:32PM +0100, Maciej W. Rozycki wrote: > > The context register is actually intended to be used for indexing a flat > > 4mb array of pagetables on a 32-bit processor. It's a bit ill-defined > > on R4000-class processors as it assumes a size of 8 bytes per pte, so > > cannot be used in the Linux/MIPS kernel without shifting bits around. > > Ill??? I think someone was just longsighted enough not to limit PTEs to > 38-bit physical addresses. A shift costs a single cycle if we want to > save memory. The idea of the register was to directly generate the address of a PTE. An extra instruction in TLB exception handlers isn't only visible in performance, it also means introducing constraints on the address itself - an arithmetic shift by one bit for 4 byte PTEs will result in the two high bits of the address being identical, an arithmetic shift will make the high bit a null etc. Just on 32-bit kernels on 64-bit hw you're lucky, you have a bit 32 in c0_context which will be shifted into bit 31. Messy? Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 08:45:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KGjr118896 for linux-mips-outgoing; Wed, 20 Feb 2002 08:45:53 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KGjK918892; Wed, 20 Feb 2002 08:45:45 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA10233; Wed, 20 Feb 2002 16:45:08 +0100 (MET) Date: Wed, 20 Feb 2002 16:45:08 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , "Kevin D. Kissell" , linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? In-Reply-To: <20020220160513.A17227@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1367 Lines: 35 On Wed, 20 Feb 2002, Ralf Baechle wrote: > > Ill??? I think someone was just longsighted enough not to limit PTEs to > > 38-bit physical addresses. A shift costs a single cycle if we want to > > save memory. > > The idea of the register was to directly generate the address of a PTE. And it does -- doesn't it? It simply cannot fit all needs at once. What about pages larger than 4kB, for example? > An extra instruction in TLB exception handlers isn't only visible in > performance, it also means introducing constraints on the address itself - The performance is an issue, of course -- you get about 10% hit in the exception handler. You need to decide (possibly at the run time) what's more important: the gain from a faster TLB refill or the gain from a compression of page tables. > an arithmetic shift by one bit for 4 byte PTEs will result in the two > high bits of the address being identical, an arithmetic shift will make > the high bit a null etc. Just on 32-bit kernels on 64-bit hw you're > lucky, you have a bit 32 in c0_context which will be shifted into bit 31. Since the address is virtual -- what's the deal? > Messy? Hardly. -- + 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 Feb 20 13:53:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KLrcA27120 for linux-mips-outgoing; Wed, 20 Feb 2002 13:53:38 -0800 Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KLrZ927117 for ; Wed, 20 Feb 2002 13:53:35 -0800 Received: (qmail 19733 invoked from network); 20 Feb 2002 20:53:34 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 20 Feb 2002 20:53:34 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g1KKrWr02843 for linux-mips@oss.sgi.com; Wed, 20 Feb 2002 15:53:32 -0500 X-Authentication-Warning: localhost.hpti.com: lindahl set sender to lindahl@conservativecomputer.com using -f Date: Wed, 20 Feb 2002 15:53:32 -0500 From: Greg Lindahl To: linux-mips@oss.sgi.com Subject: Re: FPU emulator unsafe for SMP? Message-ID: <20020220155332.A2766@wumpus.skymv.com> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020215003037.A3670@mvista.com> <002b01c1b607$6afbd5c0$10eca8c0@grendel> <20020219140514.C25739@mvista.com> <00af01c1b9a2$c0d6d5f0$10eca8c0@grendel> <20020219171238.E25739@mvista.com> <20020219222835.A4195@wumpus.skymv.com> <20020219202434.F25739@mvista.com> <20020219233222.A22099@nevyn.them.org> <006001c1b9f7$7da1c920$0deca8c0@Ulysses> <20020220145023.G15588@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020220145023.G15588@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Feb 20, 2002 at 02:50:23PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 896 Lines: 20 On Wed, Feb 20, 2002 at 02:50:23PM +0100, Ralf Baechle wrote: > These days I assume the difference to be greater for cache reasons. Our > stored fp registers take 256 bytes and also tend to be located at a constant > offset from start of the 8kB (64-bit: 16kB) aligned task_struct. Combined > with the usually low degree of cache associativity on MIPS that means > we'll frequently miss L1. Ouch. That cache miss is much more expensive than saving the FPU state. Can we un-align task_struct? I see it is allocated as a whole page, but it's apparently much smaller. We could add an offset to its start (hm, should be a multiple of the cache line size), and that ought to give much nicer L1 usage. Any other struct which is allocated as a whole page but is much smaller could be a candidate for this, too. But we should experiment once to see if it's a win before getting that excited. greg From owner-linux-mips@oss.sgi.com Wed Feb 20 14:58:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KMwfk31536 for linux-mips-outgoing; Wed, 20 Feb 2002 14:58:41 -0800 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KMwd931533 for ; Wed, 20 Feb 2002 14:58:39 -0800 Received: from computer ([208.187.134.72]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g1KLwbu02589 for ; Wed, 20 Feb 2002 13:58:37 -0800 Message-ID: <000d01c1ba5a$083b1fc0$6701a8c0@computer> From: "Robert Rusek" To: Subject: Latest kernel? Date: Wed, 20 Feb 2002 14:00:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 241 Lines: 8 Where can I obtain the latest stable build of the kernel. I need it to work on my SGI IP22. If possible I do not want to use CSV since I do not have a high speed internet connection. Any help would be greatly appreciated. Thanks, Rob. From owner-linux-mips@oss.sgi.com Wed Feb 20 15:15:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1KNFEj31962 for linux-mips-outgoing; Wed, 20 Feb 2002 15:15:14 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1KNF8931958 for ; Wed, 20 Feb 2002 15:15:09 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id DBFD87FA; Wed, 20 Feb 2002 23:14:41 +0100 (CET) Received: by localhost (Postfix, from userid 1000) id 6FE0A1A2C7; Wed, 20 Feb 2002 23:15:07 +0100 (CET) Date: Wed, 20 Feb 2002 23:15:07 +0100 From: Florian Lohoff To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Latest kernel? Message-ID: <20020220221507.GC29624@paradigm.rfc822.org> References: <000d01c1ba5a$083b1fc0$6701a8c0@computer> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: <000d01c1ba5a$083b1fc0$6701a8c0@computer> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1222 Lines: 40 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 02:00:36PM -0800, Robert Rusek wrote: > Where can I obtain the latest stable build of the kernel. I need it to w= ork > on my SGI IP22. If possible I do not want to use CSV since I do not have= a > high speed internet connection. Any help would be greatly appreciated. I dont think there are regular tarballs - Take the pain once - checkout the kernel and before modifying make a tarball. Then you can just cvs -z3 update -Pd=20 Your tarball all the time. BTW: You should checkout -r linux_2_4 as i dont think 2.5 has success reports on mips already. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --PuGuTyElPB9bOcsM 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 iD8DBQE8dB/rUaz2rXW+gJcRAgfdAJ4ltnzDlHK7sE91tPl+Xxt3jW/X4ACg0Nhf zrbHlkNfmRLglhJx/Mgaveg= =Aaiy -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From owner-linux-mips@oss.sgi.com Wed Feb 20 18:36:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L2aHd04887 for linux-mips-outgoing; Wed, 20 Feb 2002 18:36:17 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L2a9904884 for ; Wed, 20 Feb 2002 18:36:09 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1L1a5R26771 for ; Wed, 20 Feb 2002 17:36:05 -0800 From: "Matthew Dharm" To: "Linux-MIPS" Subject: set_io_port_base()? Date: Wed, 20 Feb 2002 17:36:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2026 Lines: 46 So, what's the proper usage for set_io_port_base()? I'm trying to bring up Linux on our newest board (the Ocelot-G -- see www.momenco.com for more information). I think I'm pretty far along, but I can't get a plug-in PCI ethernet device to work. What I get is: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others PCI setting cache line size to 8 from 0 eth0: Invalid EEPROM checksum 0x0000, check settings before activating this device! eth0: Intel Corp. 82559ER, 00:00:00:00:00:00, IRQ 9. Receiver lock-up bug exists -- enabling work-around. Board assembly 000000-000, Physical connectors present: Primary interface chip None PHY #0. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x1d68d8db). Receiver lock-up workaround activated. Now, I'm pretty sure this has something to do with the initcall to set_io_port_base() and ioremap(), which are in my setup.c (copied from linux/arch/mips/gt64120/momenco_ocelot/setup.c and modified). Without that bit of code at the bottom of that function, I don't even get this -- it just crashes. So I know I need this code, but I'm just not certain what/how I should be using it... My initial guess is that it's used to map some virtual address space onto the physical addresses needed to actually generate PCI I/O transactions, but that's just a guess. If that's right, then the code I'm using _should_ work... I call ioremap() with the physical base and size, and then set_io_port_base() using the result of ioremap(). Anyone have any thoughts? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Wed Feb 20 18:39:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L2d5T04987 for linux-mips-outgoing; Wed, 20 Feb 2002 18:39:05 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L2cx904982; Wed, 20 Feb 2002 18:38:59 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1L1cxR26789; Wed, 20 Feb 2002 17:38:59 -0800 From: "Matthew Dharm" To: "Ralf Baechle" , "Linux-MIPS" Subject: Adding code to the tree... Date: Wed, 20 Feb 2002 17:38:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1029 Lines: 23 So, I'm porting Linux to our latest board... and I've got this pile of new code, and I'm itching to check it in somewhere. It's not perfect yet, but the board definately starts to come up, and the Symbios 53c875 driver can probe and identify devices on the SCSI bus.... so I'm thinking that I'm doing pretty well here. So, if I send this code as is, will it be accepted into the tree? Or do I have to wait until it's completely finished before I send it? I can see arguments either way, so I'm guessing it really comes down to Ralf's personal preferences... Matt P.S. Is there any way to get permission to make CVS commits, or should everything be done via Ralf? I've got another 2 designs behind this one which will all get Linux ported to them... -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From owner-linux-mips@oss.sgi.com Wed Feb 20 18:51:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L2plS05167 for linux-mips-outgoing; Wed, 20 Feb 2002 18:51:47 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L2pg905164 for ; Wed, 20 Feb 2002 18:51:42 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L1pLm29629; Thu, 21 Feb 2002 02:51:21 +0100 Date: Thu, 21 Feb 2002 02:51:21 +0100 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: Adding code to the tree... Message-ID: <20020221025121.A29466@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 20, 2002 at 05:38:59PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1171 Lines: 25 On Wed, Feb 20, 2002 at 05:38:59PM -0800, Matthew Dharm wrote: > So, I'm porting Linux to our latest board... and I've got this pile of > new code, and I'm itching to check it in somewhere. It's not perfect > yet, but the board definately starts to come up, and the Symbios > 53c875 driver can probe and identify devices on the SCSI bus.... so > I'm thinking that I'm doing pretty well here. > > So, if I send this code as is, will it be accepted into the tree? Or > do I have to wait until it's completely finished before I send it? I > can see arguments either way, so I'm guessing it really comes down to > Ralf's personal preferences... I also take patches for partial support if I have confidence that the support will be completed not too far after. > P.S. Is there any way to get permission to make CVS commits, or should > everything be done via Ralf? I've got another 2 designs behind this > one which will all get Linux ported to them... The intent is to move CVS to another machine in the near future. By then I'll be able to generate accounts as I want but at this time it's a pain to go through the SGI burocracy so I'm trying to avoid it. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 18:58:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L2wAs05358 for linux-mips-outgoing; Wed, 20 Feb 2002 18:58:10 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L2w3905355 for ; Wed, 20 Feb 2002 18:58:04 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L1vtD29867; Thu, 21 Feb 2002 02:57:55 +0100 Date: Thu, 21 Feb 2002 02:57:55 +0100 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: set_io_port_base()? Message-ID: <20020221025755.B29466@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 20, 2002 at 05:36:05PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 859 Lines: 18 On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote: > Now, I'm pretty sure this has something to do with the initcall to > set_io_port_base() and ioremap(), which are in my setup.c (copied from > linux/arch/mips/gt64120/momenco_ocelot/setup.c and modified). Without > that bit of code at the bottom of that function, I don't even get > this -- it just crashes. So I know I need this code, but I'm just not > certain what/how I should be using it... > > My initial guess is that it's used to map some virtual address space > onto the physical addresses needed to actually generate PCI I/O > transactions, but that's just a guess. If that's right, then the code > I'm using _should_ work... I call ioremap() with the physical base and > size, and then set_io_port_base() using the result of ioremap(). That is exactly the intended use. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 18:59:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L2xoh05426 for linux-mips-outgoing; Wed, 20 Feb 2002 18:59:50 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L2xj905423 for ; Wed, 20 Feb 2002 18:59:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L1xUD29890; Thu, 21 Feb 2002 02:59:30 +0100 Date: Thu, 21 Feb 2002 02:59:30 +0100 From: Ralf Baechle To: Florian Lohoff Cc: Robert Rusek , linux-mips@oss.sgi.com Subject: Re: Latest kernel? Message-ID: <20020221025930.C29466@dea.linux-mips.net> References: <000d01c1ba5a$083b1fc0$6701a8c0@computer> <20020220221507.GC29624@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: <20020220221507.GC29624@paradigm.rfc822.org>; from flo@rfc822.org on Wed, Feb 20, 2002 at 11:15:07PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 710 Lines: 18 On Wed, Feb 20, 2002 at 11:15:07PM +0100, Florian Lohoff wrote: > > Where can I obtain the latest stable build of the kernel. I need it to work > > on my SGI IP22. If possible I do not want to use CSV since I do not have a > > high speed internet connection. Any help would be greatly appreciated. > > I dont think there are regular tarballs - Take the pain once - checkout > the kernel and before modifying make a tarball. Then you can just > > cvs -z3 update -Pd > > Your tarball all the time. BTW: You should checkout -r linux_2_4 as > i dont think 2.5 has success reports on mips already. I received success reports for some eval boards but at the same time 2.5 is a construction zone ... Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 19:05:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L35Tf05602 for linux-mips-outgoing; Wed, 20 Feb 2002 19:05:29 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L35L905599; Wed, 20 Feb 2002 19:05:21 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1L25LR26900; Wed, 20 Feb 2002 18:05:21 -0800 From: "Matthew Dharm" To: "Ralf Baechle" Cc: "Linux-MIPS" Subject: RE: set_io_port_base()? Date: Wed, 20 Feb 2002 18:05:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20020221025755.B29466@dea.linux-mips.net> Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1759 Lines: 51 If it works as I think it does, then is the code in linux/arch/mips/gt64120/momenco_ocelot/setup.c correct? Specifically, it calls ioremap() and then calls set_io_port_base() with a very strange value -- it's the value from ioremap() modified by the I/O physical address base... That doesn't look right to me... or I just don't quite understand how this is supposed to work. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Ralf Baechle [mailto:ralf@oss.sgi.com] > Sent: Wednesday, February 20, 2002 5:58 PM > To: Matthew Dharm > Cc: Linux-MIPS > Subject: Re: set_io_port_base()? > > > On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote: > > > Now, I'm pretty sure this has something to do with the initcall to > > set_io_port_base() and ioremap(), which are in my setup.c > (copied from > > linux/arch/mips/gt64120/momenco_ocelot/setup.c and > modified). Without > > that bit of code at the bottom of that function, I don't even get > > this -- it just crashes. So I know I need this code, but > I'm just not > > certain what/how I should be using it... > > > > My initial guess is that it's used to map some virtual > address space > > onto the physical addresses needed to actually generate PCI I/O > > transactions, but that's just a guess. If that's right, > then the code > > I'm using _should_ work... I call ioremap() with the > physical base and > > size, and then set_io_port_base() using the result of ioremap(). > > That is exactly the intended use. > > Ralf > From owner-linux-mips@oss.sgi.com Wed Feb 20 19:08:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L38lr05675 for linux-mips-outgoing; Wed, 20 Feb 2002 19:08:47 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L38e905672; Wed, 20 Feb 2002 19:08:40 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1L28dR26915; Wed, 20 Feb 2002 18:08:39 -0800 From: "Matthew Dharm" To: "Ralf Baechle" Cc: "Linux-MIPS" Subject: RE: set_io_port_base()? Date: Wed, 20 Feb 2002 18:08:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20020221025755.B29466@dea.linux-mips.net> Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1452 Lines: 44 Also, does this have to be done only for PCI I/O, or PCI memory also? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Ralf Baechle [mailto:ralf@oss.sgi.com] > Sent: Wednesday, February 20, 2002 5:58 PM > To: Matthew Dharm > Cc: Linux-MIPS > Subject: Re: set_io_port_base()? > > > On Wed, Feb 20, 2002 at 05:36:05PM -0800, Matthew Dharm wrote: > > > Now, I'm pretty sure this has something to do with the initcall to > > set_io_port_base() and ioremap(), which are in my setup.c > (copied from > > linux/arch/mips/gt64120/momenco_ocelot/setup.c and > modified). Without > > that bit of code at the bottom of that function, I don't even get > > this -- it just crashes. So I know I need this code, but > I'm just not > > certain what/how I should be using it... > > > > My initial guess is that it's used to map some virtual > address space > > onto the physical addresses needed to actually generate PCI I/O > > transactions, but that's just a guess. If that's right, > then the code > > I'm using _should_ work... I call ioremap() with the > physical base and > > size, and then set_io_port_base() using the result of ioremap(). > > That is exactly the intended use. > > Ralf > From owner-linux-mips@oss.sgi.com Wed Feb 20 19:13:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L3DnT05756 for linux-mips-outgoing; Wed, 20 Feb 2002 19:13:49 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L3Dj905753 for ; Wed, 20 Feb 2002 19:13:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L2Dcu31289; Thu, 21 Feb 2002 03:13:38 +0100 Date: Thu, 21 Feb 2002 03:13:38 +0100 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: set_io_port_base()? Message-ID: <20020221031338.A31129@dea.linux-mips.net> References: <20020221025755.B29466@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 20, 2002 at 06:05:21PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 718 Lines: 20 On Wed, Feb 20, 2002 at 06:05:21PM -0800, Matthew Dharm wrote: > If it works as I think it does, then is the code in > linux/arch/mips/gt64120/momenco_ocelot/setup.c correct? Specifically, > it calls ioremap() and then calls set_io_port_base() with a very > strange value -- it's the value from ioremap() > modified by the I/O physical address base... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I was reading too fast and missed that part. > That doesn't look right to me... or I just don't quite understand how > this is supposed to work. That's definately looks fishy. Another crime people keep comitting is using the same address space for both I/O memory and the base address of the port space. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 19:16:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L3GAg05838 for linux-mips-outgoing; Wed, 20 Feb 2002 19:16:10 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L3G7905835 for ; Wed, 20 Feb 2002 19:16:07 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L2G0d31333; Thu, 21 Feb 2002 03:16:00 +0100 Date: Thu, 21 Feb 2002 03:16:00 +0100 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: set_io_port_base()? Message-ID: <20020221031600.B31129@dea.linux-mips.net> References: <20020221025755.B29466@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 20, 2002 at 06:08:39PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 239 Lines: 8 On Wed, Feb 20, 2002 at 06:08:39PM -0800, Matthew Dharm wrote: > Also, does this have to be done only for PCI I/O, or PCI memory also? This is just so all the inb/inw/outl etc. functions in know how to access ioports. Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 19:28:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L3S9E05964 for linux-mips-outgoing; Wed, 20 Feb 2002 19:28:09 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L3S1905961; Wed, 20 Feb 2002 19:28:01 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g1L2PFB05290; Wed, 20 Feb 2002 18:25:15 -0800 Message-ID: <3C745B0B.84203D3F@mvista.com> Date: Wed, 20 Feb 2002 18:27:23 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Matthew Dharm , Linux-MIPS Subject: Re: set_io_port_base()? References: <20020221025755.B29466@dea.linux-mips.net> <20020221031338.A31129@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 27 Ralf Baechle wrote: > > On Wed, Feb 20, 2002 at 06:05:21PM -0800, Matthew Dharm wrote: > > > If it works as I think it does, then is the code in > > linux/arch/mips/gt64120/momenco_ocelot/setup.c correct? Specifically, > > it calls ioremap() and then calls set_io_port_base() with a very > > strange value -- it's the value from ioremap() > > > modified by the I/O physical address base... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I was reading too fast and missed that part. > > > That doesn't look right to me... or I just don't quite understand how > > this is supposed to work. > > That's definately looks fishy. This is actually right. This way if you pass an virtual at (mips_io_port_base + delta), you will get a physical address (GT_PCI_IO_BASE + delta), the desired place. Most boards don't need this funky ioremap() and base addr substraction trick, but ocelot has the IO address placed beyond normal kseg1 addressing range. Jun From owner-linux-mips@oss.sgi.com Wed Feb 20 19:48:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L3mx206217 for linux-mips-outgoing; Wed, 20 Feb 2002 19:48:59 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L3mo906213; Wed, 20 Feb 2002 19:48:51 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1L2moR27080; Wed, 20 Feb 2002 18:48:50 -0800 From: "Matthew Dharm" To: , "Ralf Baechle" Cc: "Linux-MIPS" Subject: RE: set_io_port_base()? Date: Wed, 20 Feb 2002 18:48:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C745B0B.84203D3F@mvista.com> Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1707 Lines: 55 But isn't that what all the complicated logic in ioremap() is for? It looks like it checks to see if it can directly address the I/O space via kseg1 and if not, set up a translation for it... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: jsun@mvista.com [mailto:jsun@mvista.com] > Sent: Wednesday, February 20, 2002 6:27 PM > To: Ralf Baechle > Cc: Matthew Dharm; Linux-MIPS > Subject: Re: set_io_port_base()? > > > Ralf Baechle wrote: > > > > On Wed, Feb 20, 2002 at 06:05:21PM -0800, Matthew Dharm wrote: > > > > > If it works as I think it does, then is the code in > > > linux/arch/mips/gt64120/momenco_ocelot/setup.c correct? > Specifically, > > > it calls ioremap() and then calls set_io_port_base() with a very > > > strange value -- it's the value from ioremap() > > > > > modified by the I/O physical address base... > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > I was reading too fast and missed that part. > > > > > That doesn't look right to me... or I just don't quite > understand how > > > this is supposed to work. > > > > That's definately looks fishy. > > This is actually right. This way if you pass an virtual at > (mips_io_port_base > + delta), you will get a physical address (GT_PCI_IO_BASE + > delta), the > desired place. > > Most boards don't need this funky ioremap() and base addr > substraction trick, > but ocelot has the IO address placed beyond normal kseg1 > addressing range. > > Jun > From owner-linux-mips@oss.sgi.com Wed Feb 20 20:03:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L43dE06528 for linux-mips-outgoing; Wed, 20 Feb 2002 20:03:39 -0800 Received: from skip-ext.ab.videon.ca (skip-ext.ab.videon.ca [206.75.216.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L43a906524 for ; Wed, 20 Feb 2002 20:03:37 -0800 Received: (qmail 10399 invoked from network); 21 Feb 2002 03:03:35 -0000 Received: from unknown (HELO wakko.debian.net) ([24.86.210.128]) (envelope-sender ) by skip-ext.ab.videon.ca (qmail-ldap-1.03) with SMTP for ; 21 Feb 2002 03:03:35 -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 16djWB-00016i-00; Wed, 20 Feb 2002 20:03:35 -0700 Date: Wed, 20 Feb 2002 20:03:34 -0700 (MST) From: Jason Gunthorpe X-Sender: jgg@wakko.debian.net Reply-To: Jason Gunthorpe To: Matthew Dharm cc: Linux-MIPS Subject: RE: set_io_port_base()? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 19 On Wed, 20 Feb 2002, Matthew Dharm wrote: > But isn't that what all the complicated logic in ioremap() is for? It > looks like it checks to see if it can directly address the I/O space > via kseg1 and if not, set up a translation for it... Yes, but ioremap does not remap io.. it remamps what linux dubs MMIO regions. Look at drivers/net/8139too.c and check out the difference from io and mmio. Linux's io* primitives expect an i386 like 64K IO port space, which in mips land starts at the virtual address passed into set_io_port_base(). BTW, the 'eepro100' driver seems to default to MMIO operation so it should not care about set_io_port_base.. You might want to crank up speedo_debug and make sure of the mode. Jason From owner-linux-mips@oss.sgi.com Wed Feb 20 20:30:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L4UnB08120 for linux-mips-outgoing; Wed, 20 Feb 2002 20:30:49 -0800 Received: from dea.linux-mips.net (a1as20-p220.stg.tli.de [195.252.194.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L4Uj908116 for ; Wed, 20 Feb 2002 20:30:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1L3UY227199; Thu, 21 Feb 2002 04:30:34 +0100 Date: Thu, 21 Feb 2002 04:30:33 +0100 From: Ralf Baechle To: Jun Sun Cc: Matthew Dharm , Linux-MIPS Subject: Re: set_io_port_base()? Message-ID: <20020221043033.A1430@dea.linux-mips.net> References: <20020221025755.B29466@dea.linux-mips.net> <20020221031338.A31129@dea.linux-mips.net> <3C745B0B.84203D3F@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C745B0B.84203D3F@mvista.com>; from jsun@mvista.com on Wed, Feb 20, 2002 at 06:27:23PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 486 Lines: 13 On Wed, Feb 20, 2002 at 06:27:23PM -0800, Jun Sun wrote: > This is actually right. This way if you pass an virtual at > (mips_io_port_base + delta), you will get a physical address > (GT_PCI_IO_BASE + delta), the desired place. > > Most boards don't need this funky ioremap() and base addr substraction trick, > but ocelot has the IO address placed beyond normal kseg1 addressing range. If you ever think about the value of the the address you're making something wrong ... Ralf From owner-linux-mips@oss.sgi.com Wed Feb 20 22:36:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1L6ajA10190 for linux-mips-outgoing; Wed, 20 Feb 2002 22:36:45 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1L6ad910186; Wed, 20 Feb 2002 22:36:39 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id VAA08957; Wed, 20 Feb 2002 21:35:57 -0800 Date: Wed, 20 Feb 2002 21:35:57 -0800 From: Jun Sun To: Matthew Dharm Cc: Ralf Baechle , Linux-MIPS Subject: Re: set_io_port_base()? Message-ID: <20020220213557.A8883@mvista.com> References: <3C745B0B.84203D3F@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mdharm@momenco.com on Wed, Feb 20, 2002 at 06:48:50PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 945 Lines: 26 On Wed, Feb 20, 2002 at 06:48:50PM -0800, Matthew Dharm wrote: > But isn't that what all the complicated logic in ioremap() is for? Not exactly. Here is the whole picture: drivers do inb(delta)/outb(delta) -> translated to an virtual address (mips_io_port_base + delta) -> mapped into (GT_IO_BASE + delta) physical addr -> Bingo! you got the devices. Here your goal is to make the drivers that do inb()/outb() happy (i.e., be able to reuse them without modification) If you only use drivers that directly access memory (such as drivers/net/nec_korva.c on linux-mips.sf.net), then you don't even have to set mips_io_port_base at all. The ioremap() comes into place because by default you can not set a mips_io_port_base value in kseg1 range on ocelot (it is at 0x20000000 in physical addr space). Therefore you do a ioremap(), blah blah as explained above. Someday I should finish the PCI chapter on my porting guide ... Jun From owner-linux-mips@oss.sgi.com Thu Feb 21 04:37:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LCb3825969 for linux-mips-outgoing; Thu, 21 Feb 2002 04:37:03 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LCaw925940 for ; Thu, 21 Feb 2002 04:36:58 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Feb 2002 11:36:58 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 6087BB46B; Thu, 21 Feb 2002 20:36:56 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id UAA70710; Thu, 21 Feb 2002 20:36:56 +0900 (JST) Date: Thu, 21 Feb 2002 20:41:20 +0900 (JST) Message-Id: <20020221.204120.102764790.nemoto@toshiba-tops.co.jp> To: macro@ds2.pg.gda.pl Cc: kevink@mips.com, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) From: Atsushi Nemoto In-Reply-To: References: <20020215.123124.70226832.nemoto@toshiba-tops.co.jp> 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.1 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 Content-Length: 1062 Lines: 26 >>>>> On Fri, 15 Feb 2002 13:08:20 +0100 (MET), "Maciej W. Rozycki" said: macro> IOW, two consecutive writes separated by a "sync" need not macro> imply a write-back, but as soon as a read happens a preceding macro> write-back is a must. TX39 satisfy this on uncached load/store. "sync" does not flush a write buffer, but any uncached load are executed AFTER completion of pending uncached store. On combination of cached and uncached operation, TX39 does not satisfy this order. macro> It sounds weird: it looks like "sync" is useless and basically macro> a "nop". TX39 has a function called "non-blocking load". This function is described on chapter 4.4 of TX39/H2 manual. "sync" operation is meaningful with this function. macro> If this is the case the processors need their own wbflush() macro> implementation. Can you point to specific chapters of macro> specifications that document it? Chapter 4.9.4 in TX39/H2 Japanese manual describes write buffer. But I could not find it in the English manual... --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Feb 21 04:56:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LCuZj10282 for linux-mips-outgoing; Thu, 21 Feb 2002 04:56:35 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LCuU910227 for ; Thu, 21 Feb 2002 04:56:30 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Feb 2002 11:56:30 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 AE931B46B; Thu, 21 Feb 2002 20:56:28 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id UAA70757; Thu, 21 Feb 2002 20:56:28 +0900 (JST) Date: Thu, 21 Feb 2002 21:00:52 +0900 (JST) Message-Id: <20020221.210052.38718643.nemoto@toshiba-tops.co.jp> To: macro@ds2.pg.gda.pl Cc: jgg@debian.org, kevink@mips.com, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) From: Atsushi Nemoto In-Reply-To: References: 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.1 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 Content-Length: 1031 Lines: 23 >>>>> On Fri, 15 Feb 2002 20:39:09 +0100 (MET), "Maciej W. Rozycki" said: macro> Well, the "classic" MIPS R2020 and R3220 ones would break PCI macro> (or actually any I/O) ordering semantics as they return data macro> from a posted write upon a hit. The affected read never macro> appears at the I/O bus in that case. They never reorder writes macro> though, as they work as FIFOs (the former is four stage deep macro> and the latter is six stage deep), so wmb() may be null for macro> them. macro> I've read a suggestion a "bc0f" might be needed for the TX39's macro> write buffer as a barrier. That means the buffer behaves as macro> the "classic" ones. As I wrote in another mail, TX39's uncached load does NOT return data from a write buffer. Uncached load/store always appears on I/O bus in same order. The problem of TX39's write buffer is that cached load/store operation can overtake preceding uncached store operation (even if "SYNC" was exist between these operations). --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Feb 21 05:32:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LDWYD02999 for linux-mips-outgoing; Thu, 21 Feb 2002 05:32:34 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LDWS902944 for ; Thu, 21 Feb 2002 05:32:29 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 1B2D89EF2; Thu, 21 Feb 2002 13:32:23 +0100 (CET) Date: Thu, 21 Feb 2002 13:32:22 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Toolchain question Message-ID: <20020221133222.J21530@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1BdFSKqAqVdu8k/" Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 875 Lines: 34 --k1BdFSKqAqVdu8k/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm to build a new toolchain and looked around. There's still the cross-all-20010423.tar package on oss.sgi.com. Is it still recommened to use this, or am I better off using a current CVS co of binutils and gcc? MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --k1BdFSKqAqVdu8k/ 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 iEYEARECAAYFAjx06NYACgkQHb1edYOZ4bvTJgCeIO1a/Ga3piLcOP0QoLKx90hR I9gAnjX91fXMCgpiQPC8o7IFPK9zvKSm =kOGN -----END PGP SIGNATURE----- --k1BdFSKqAqVdu8k/-- From owner-linux-mips@oss.sgi.com Thu Feb 21 07:15:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LFFXs23234 for linux-mips-outgoing; Thu, 21 Feb 2002 07:15:33 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LFFJ923079 for ; Thu, 21 Feb 2002 07:15:22 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08434; Thu, 21 Feb 2002 15:12:44 +0100 (MET) Date: Thu, 21 Feb 2002 15:12:43 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Atsushi Nemoto cc: kevink@mips.com, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <20020221.204120.102764790.nemoto@toshiba-tops.co.jp> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2399 Lines: 51 On Thu, 21 Feb 2002, Atsushi Nemoto wrote: > TX39 satisfy this on uncached load/store. "sync" does not flush a > write buffer, but any uncached load are executed AFTER completion of > pending uncached store. On combination of cached and uncached > operation, TX39 does not satisfy this order. With respect to cache refills (what is already cached is irrelevant, obviously, as read accesse to it don't appear externally), "32-bit RISC Microprocessor TX39 Family Core Architecture User's Manual" seems to contradict. In the description of the "sync" instruction it states: "Interlocks the pipeline until the load, store or data cache refill operation of the previous instruction is completed. The R3900 Processor Core can continue processing instructions following a load instruction even if a cache refill is caused by the load instruction or a load is made from a noncacheable area. Executing a SYNC instruction interlocks subsequent instructions until the SYNC instruction execution is completed. This ensures that the instructions following a load instruction are executed in the proper sequence." It's clear "sync" is strong on the TX39, stronger then required by MIPS II. > TX39 has a function called "non-blocking load". This function is > described on chapter 4.4 of TX39/H2 manual. "sync" operation is > meaningful with this function. Chapter 4.3 ("") of the quoted manual. The statement I quoted assures it, indeed (modulo errata, which hopefully don't exist here). > Chapter 4.9.4 in TX39/H2 Japanese manual describes write buffer. But > I could not find it in the English manual... The write buffer is described in the part about "TMPR3901F" (it appears two manuals are concatenated in a single file), chapter 2.3 ("Bus Interface Unit (Bus Controller / Write Buffer)"). It looks like a "bc0f" loop is needed for mb(). The only difference comparing to R2020/R3220 is only a single "nop" is needed after a write for the coprocessor status to become valid, it would seem. It's not documented explicitly but the supplied example code suggests so. The document I'm referring to is available at: "http:/pdf.toshiba.com/taec/components/Generic/TX39_Core_um.pdf". -- + 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 Feb 21 07:24:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LFOa127781 for linux-mips-outgoing; Thu, 21 Feb 2002 07:24:36 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LFOU927699 for ; Thu, 21 Feb 2002 07:24:31 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08638; Thu, 21 Feb 2002 15:19:26 +0100 (MET) Date: Thu, 21 Feb 2002 15:19:25 +0100 (MET) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: jgg@debian.org, kevink@mips.com, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <20020221.210052.38718643.nemoto@toshiba-tops.co.jp> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 858 Lines: 22 On Thu, 21 Feb 2002, Atsushi Nemoto wrote: > As I wrote in another mail, TX39's uncached load does NOT return data > from a write buffer. Uncached load/store always appears on I/O bus in > same order. Well, the specification suggests that a load doesn't stall until all data from the buffer are written back. Therefore a load will appear on the host bus before pending writes. It implies mb() has to stall on the "buffer not empty" condition. > The problem of TX39's write buffer is that cached load/store operation > can overtake preceding uncached store operation (even if "SYNC" was > exist between these operations). It's implied by the above. -- + 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 Feb 21 09:34:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LHYeg08283 for linux-mips-outgoing; Thu, 21 Feb 2002 09:34:40 -0800 Received: from web11907.mail.yahoo.com (web11907.mail.yahoo.com [216.136.172.191]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LHYb908280 for ; Thu, 21 Feb 2002 09:34:37 -0800 Message-ID: <20020221163436.76127.qmail@web11907.mail.yahoo.com> Received: from [209.243.184.191] by web11907.mail.yahoo.com via HTTP; Thu, 21 Feb 2002 08:34:36 PST Date: Thu, 21 Feb 2002 08:34:36 -0800 (PST) From: Wayne Gowcher Subject: pthread support in mipsel-linux To: Linux-MIPS In-Reply-To: <3C745B0B.84203D3F@mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 439 Lines: 15 Could anyone tell me if the 2.4.x kernel / redhat 7.1 mipsel-linux distribution on the sgi ftp site supports posix threads ? In particular, I have a driver that I am trying to port from x86 that links against the libraries "-lm -lpthread" can anyone tell me what rpms I might find them in ? TIA __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-linux-mips@oss.sgi.com Thu Feb 21 10:55:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LItGj09234 for linux-mips-outgoing; Thu, 21 Feb 2002 10:55:16 -0800 Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LItC909231 for ; Thu, 21 Feb 2002 10:55:12 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020221175507.LPDA2626.rwcrmhc51.attbi.com@ocean.lucon.org>; Thu, 21 Feb 2002 17:55:07 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id D60BF125C1; Thu, 21 Feb 2002 09:55:05 -0800 (PST) Date: Thu, 21 Feb 2002 09:55:05 -0800 From: "H . J . Lu" To: Wayne Gowcher Cc: Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020221095505.A28496@lucon.org> References: <3C745B0B.84203D3F@mvista.com> <20020221163436.76127.qmail@web11907.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020221163436.76127.qmail@web11907.mail.yahoo.com>; from wgowcher@yahoo.com on Thu, Feb 21, 2002 at 08:34:36AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 566 Lines: 19 On Thu, Feb 21, 2002 at 08:34:36AM -0800, Wayne Gowcher wrote: > Could anyone tell me if the 2.4.x kernel / redhat 7.1 > mipsel-linux distribution on the sgi ftp site supports > posix threads ? The threads works well with glibc compiled with -mips2. But the threads in my RedHat 7.1 is broken when compiled with -mips2 :-(. I have fixed it in glibc CVS. > > In particular, I have a driver that I am trying to > port from x86 that links against the libraries "-lm > -lpthread" can anyone tell me what rpms I might find > them in ? It is the part of glibc. H.J. From owner-linux-mips@oss.sgi.com Thu Feb 21 11:12:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LJC8a09569 for linux-mips-outgoing; Thu, 21 Feb 2002 11:12:08 -0800 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LJC5909566 for ; Thu, 21 Feb 2002 11:12:05 -0800 Message-ID: <20020221181204.48818.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com via HTTP; Thu, 21 Feb 2002 10:12:04 PST Date: Thu, 21 Feb 2002 10:12:04 -0800 (PST) From: Wayne Gowcher Subject: Re: pthread support in mipsel-linux To: "H . J . Lu" Cc: 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 Content-Length: 804 Lines: 28 H.J. Thank you for your reply. > The threads works well with glibc compiled with > -mips2. But the threads > in my RedHat 7.1 is broken when compiled with -mips2 > :-(. I have fixed > it in glibc CVS. Just to clarify, the glibc rpm in your Redhat 7.1 is compiled with -mips1 right ? So as it is broken yes ? So if I REALLY wanted to use pthreads with your redhat 7.1 distribution, could I get away with checking out the current glibc from CVS, recompiling it and installing over the rpm glibc ? Or is that too simplistic, and it will need recompilation of a lot of other applications ? If so could you give me an idea of just how big a job that is ? Wayne __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-linux-mips@oss.sgi.com Thu Feb 21 11:25:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LJPEo09792 for linux-mips-outgoing; Thu, 21 Feb 2002 11:25:14 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LJPA909789 for ; Thu, 21 Feb 2002 11:25:10 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020221182504.VMBQ1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Thu, 21 Feb 2002 18:25:04 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B0867125C1; Thu, 21 Feb 2002 10:25:03 -0800 (PST) Date: Thu, 21 Feb 2002 10:25:03 -0800 From: "H . J . Lu" To: Wayne Gowcher Cc: Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020221102503.A28936@lucon.org> References: <20020221095505.A28496@lucon.org> <20020221181204.48818.qmail@web11908.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020221181204.48818.qmail@web11908.mail.yahoo.com>; from wgowcher@yahoo.com on Thu, Feb 21, 2002 at 10:12:04AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 917 Lines: 31 On Thu, Feb 21, 2002 at 10:12:04AM -0800, Wayne Gowcher wrote: > H.J. > > Thank you for your reply. > > > The threads works well with glibc compiled with > > -mips2. But the threads > > in my RedHat 7.1 is broken when compiled with -mips2 > > :-(. I have fixed > > it in glibc CVS. > > Just to clarify, the glibc rpm in your Redhat 7.1 is > compiled with -mips1 right ? So as it is broken yes ? Yes. -mips1 doesn't work well with thread. > > So if I REALLY wanted to use pthreads with your redhat > 7.1 distribution, could I get away with checking out > the current glibc from CVS, recompiling it and > installing over the rpm glibc ? Or is that too > simplistic, and it will need recompilation of a lot of > other applications ? It should be mostly ok if you use gcc 2.96. But glibc in CVS lacks a few mips change in my glibc in RedHat 7.1. At least, you may want glibc-2.2-mmap64.patch in my glibc. H.J. From owner-linux-mips@oss.sgi.com Thu Feb 21 11:46:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1LJk1210176 for linux-mips-outgoing; Thu, 21 Feb 2002 11:46:01 -0800 Received: from web11906.mail.yahoo.com (web11906.mail.yahoo.com [216.136.172.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1LJjw910173 for ; Thu, 21 Feb 2002 11:45:58 -0800 Message-ID: <20020221184558.33231.qmail@web11906.mail.yahoo.com> Received: from [209.243.184.191] by web11906.mail.yahoo.com via HTTP; Thu, 21 Feb 2002 10:45:58 PST Date: Thu, 21 Feb 2002 10:45:58 -0800 (PST) From: Wayne Gowcher Subject: Re: pthread support in mipsel-linux To: Linux-MIPS In-Reply-To: <20020221102503.A28936@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 352 Lines: 13 It seems like getting pthread support for mips1 could be a lengthy and involved process. So I was wondering has anyone out there used pthreads for with mips1 with any of the redhat distributions on sgi ? TIA __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-linux-mips@oss.sgi.com Thu Feb 21 16:10:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M0APE15119 for linux-mips-outgoing; Thu, 21 Feb 2002 16:10:25 -0800 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M0AK915115 for ; Thu, 21 Feb 2002 16:10:21 -0800 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA21216 for ; Fri, 22 Feb 2002 10:10:13 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdD0Rq4_; Fri Feb 22 10:09:26 2002 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA15630 for ; Fri, 22 Feb 2002 10:09:25 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0reHzv; Fri Feb 22 10:08:39 2002 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA27460 for ; Fri, 22 Feb 2002 10:08:38 +1100 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 10:08:37 +1100 Message-ID: From: "Salisbury, Roger G" To: "'linux-mips'" Subject: Where can I find archives for this site please ??? Date: Fri, 22 Feb 2002 10:08:34 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 543 Lines: 31 Anybody Where can I find archives for this site please ??? for example if I wanted the 'debian-mips@lists.debian.org' archives I would go to this exellent site. http://www.geocrawler.com/lists/3/Debian-Linux/ ==== 'debian-mips@lists.debian.org' Is there a site that will do similar for linux-mips@oss.sgi.com IE ????????????????????????????????????????????/ ======= 'linux-mips@oss.sgi.com' http://www.geocrawler.com/lists/3/Debian-Linux/ ==== 'debian-mips@lists.debian.org' Thanks very much Roger Salisbury Australia From owner-linux-mips@oss.sgi.com Thu Feb 21 16:25:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M0Ppv15624 for linux-mips-outgoing; Thu, 21 Feb 2002 16:25:51 -0800 Received: from [64.152.86.3] (unknown.Level3.net [64.152.86.3] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M0Pl915621 for ; Thu, 21 Feb 2002 16:25:47 -0800 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Feb 2002 23:29:21 UT Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.11.6/8.11.6) with SMTP id g1LNNM522754; Thu, 21 Feb 2002 15:23:22 -0800 (PST) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id PAA27655; Thu, 21 Feb 2002 15:24:54 -0800 Received: from esstech.com by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id RAA18525; Thu, 21 Feb 2002 17:17:30 -0600 Message-ID: <3C758319.2010704@esstech.com> Date: Thu, 21 Feb 2002 17:30:33 -0600 From: Gerald Champagne User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: "Salisbury, Roger G" CC: "'linux-mips'" Subject: Re: Where can I find archives for this site please ??? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 605 Lines: 27 Salisbury, Roger G wrote: > Anybody > Where can I find archives for this site please ??? > There's a web-based archive here: http://marc.theaimsgroup.com/?l=linux-mips&r=1&w=2 but it looks like it isn't archiving all of the messages. You can get the mail archive files directly from sgi here: http://oss.sgi.com/mips/archive/ You can download a file, place it in the directory where your Email package stores its folders, and it should appear as a normal folder in most Email packages. These arechives are a gold mine to anyone doing Mips development, with or without Linux as the OS. Gerald From owner-linux-mips@oss.sgi.com Thu Feb 21 16:27:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M0RUX15709 for linux-mips-outgoing; Thu, 21 Feb 2002 16:27:30 -0800 Received: from 125.26.4.3 (tnt-21-72.easynet.co.uk [212.134.228.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M0RP915704 for ; Thu, 21 Feb 2002 16:27:25 -0800 Date: Thu, 21 Feb 2002 16:27:25 -0800 From: Information Team To: Message-Id: <419.437308.98117963info@ptl-online.co.uk> Subject: Home Entertainment and Leisure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 458 Lines: 17 *** YOU ARE NOT ON A MAILING LIST AND WILL NOT BE CONTACTED AGAIN *** We can simply provide you with the best prices on all PC and Console Games and Hardware. Playstation 1 & 2, Xbox, Game Cube, Dreamcast, Game Boy Advance, Game Boy Colour, PC etc. Tell us what you want and we will provide the best price for you! We can also provide DVD films. http:\\www.ptl-online.co.uk IF YOU CAN'T SEE WHAT YOU WANT LET US KNOW AND WE WILL FIND IT FOR YOU. From owner-linux-mips@oss.sgi.com Thu Feb 21 19:32:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M3WIw18895 for linux-mips-outgoing; Thu, 21 Feb 2002 19:32:18 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M3WC918892 for ; Thu, 21 Feb 2002 19:32:13 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [216.32.174.27]) with SMTP; 22 Feb 2002 02:32:12 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 5D24EB474; Fri, 22 Feb 2002 11:32:10 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA72359; Fri, 22 Feb 2002 11:32:10 +0900 (JST) Date: Fri, 22 Feb 2002 11:36:34 +0900 (JST) Message-Id: <20020222.113634.45519920.nemoto@toshiba-tops.co.jp> To: macro@ds2.pg.gda.pl Cc: kevink@mips.com, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) From: Atsushi Nemoto In-Reply-To: References: <20020221.204120.102764790.nemoto@toshiba-tops.co.jp> 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.1 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 Content-Length: 1509 Lines: 31 >>>>> On Thu, 21 Feb 2002 15:12:43 +0100 (MET), "Maciej W. Rozycki" said: macro> With respect to cache refills (what is already cached is macro> irrelevant, obviously, as read accesse to it don't appear macro> externally), "32-bit RISC Microprocessor TX39 Family Core macro> Architecture User's Manual" seems to contradict. In the macro> description of the "sync" instruction it states: macro> "Interlocks the pipeline until the load, store or data cache macro> refill operation of the previous instruction is completed. The macro> R3900 Processor Core can continue processing instructions macro> following a load instruction even if a cache refill is caused macro> by the load instruction or a load is made from a noncacheable macro> area. Executing a SYNC instruction interlocks subsequent macro> instructions until the SYNC instruction execution is completed. macro> This ensures that the instructions following a load instruction macro> are executed in the proper sequence." The contradiction is came from some confusion about usage of a word "Core" in TX39 manual. Maybe a writer of the quoted statements assumes a write buffer is outside of a "R3900 Processor Core". So if he said "operation is completed" it means "data are sent to a write buffer". Of course this point of view is not acceptable for software programmers... macro> It's clear "sync" is strong on the TX39, stronger then required macro> by MIPS II. So unfortunately this is not true. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Feb 21 19:49:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M3nKF19212 for linux-mips-outgoing; Thu, 21 Feb 2002 19:49:20 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M3nE919209 for ; Thu, 21 Feb 2002 19:49:14 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g1M2kRB10028; Thu, 21 Feb 2002 18:46:27 -0800 Message-ID: <3C75B181.C5A065A1@mvista.com> Date: Thu, 21 Feb 2002 18:48:33 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: lazy fpu switch irrelavant to no-fpu case? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1644 Lines: 54 It appears to me that lazy fpu switch has no relevancy to CPUs that don't have FPU. If you do a scan, you will see last_task_used_math are used in four kernel files: ptrace.c process.c signal.c traps.c In the case of ptrace.c and process.c, the variable is used only when CPU has FPU. In the case of traps.c (do_cpu()), it used redaundantly with another condition checking. In the case of signal.c, no matter what last_task_used_math is, the same code will be executed anyway. Now think about it, it actually makes sense - if we don't have hardware FPU, why do we care of fpu context switch. Anyhow, the problem I am seeing with FPU/SMP case seems to be caused by FPU emulation code itself, if we can assume it is not caused by fpu context switch. Right now the FPU is not turned on on the box. The following patch cleans it up a little based on the above observation. Make sense? Jun diff -Nru linux/arch/mips/kernel/traps.c.orig linux/arch/mips/kernel/traps.c --- linux/arch/mips/kernel/traps.c.orig Wed Jan 30 15:17:12 2002 +++ linux/arch/mips/kernel/traps.c Thu Feb 21 18:46:28 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; From owner-linux-mips@oss.sgi.com Thu Feb 21 20:44:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M4iIM20030 for linux-mips-outgoing; Thu, 21 Feb 2002 20:44:18 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M4gT920013; Thu, 21 Feb 2002 20:42:29 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g1M3gTR00321; Thu, 21 Feb 2002 19:42:29 -0800 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: PATCH: Ocelot (resend) and Ocelot-G Date: Thu, 21 Feb 2002 19:42:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003F_01C1BB0F.E5696E00" 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.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 16878 Lines: 459 This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C1BB0F.E5696E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ralf -- Attached to this message is a patch to update the support for the Ocelot to support both v1 and v2 PROMs (with auto-detection!) and add support for the Ocelot-G. The update to the Ocelot is something I _thought_ I already sent you... but it's not in the CVS repository, so I can't be sure. It's in my development tree, so I figured I'd send it as part of this update anyway. Support for the Ocelot-G isn't quite done yet, but it's very close. The ethernet drivers need to be worked on, but the board is currently running on my workbench with an add-on ethernet card and NFS-root. So far, it seems pretty stable. This patch is against a recent CVS snapshot (from about an hour ago). Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_003F_01C1BB0F.E5696E00 Content-Type: application/octet-stream; name="patch20020221-3" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch20020221-3" ? arch/mips/gt64240=0A= ? arch/mips/boot/elf2ecoff=0A= ? arch/mips/boot/vmlinux.ecoff=0A= ? arch/mips/boot/addinitrd=0A= Index: arch/mips/Makefile=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/Makefile,v=0A= retrieving revision 1.78.2.2=0A= diff -u -r1.78.2.2 Makefile=0A= --- arch/mips/Makefile 2002/02/15 21:05:47 1.78.2.2=0A= +++ arch/mips/Makefile 2002/02/22 04:34:35=0A= @@ -262,6 +262,17 @@=0A= endif=0A= =0A= #=0A= +# Momentum Ocelot-G board=0A= +#=0A= +ifdef CONFIG_MOMENCO_OCELOT_G=0A= +# The Ocelot-G setup.o must be linked early - it does the ioremap() for = the=0A= +# mips_io_port_base.=0A= +CORE_FILES +=3D arch/mips/gt64240/momenco_ocelot_g.o=0A= +SUBDIRS +=3D arch/mips/gt64240=0A= +LOADADDR +=3D 0x80100000=0A= +endif=0A= +=0A= +#=0A= # Philips Nino=0A= #=0A= ifdef CONFIG_NINO=0A= Index: arch/mips/config.in=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/config.in,v=0A= retrieving revision 1.154.2.14=0A= diff -u -r1.154.2.14 config.in=0A= --- arch/mips/config.in 2002/02/15 21:05:47 1.154.2.14=0A= +++ arch/mips/config.in 2002/02/22 04:34:37=0A= @@ -56,6 +56,7 @@=0A= fi=0A= bool 'Support for Mips Magnum 4000' CONFIG_MIPS_MAGNUM_4000=0A= bool 'Support for Momentum Ocelot board' CONFIG_MOMENCO_OCELOT=0A= +bool 'Support for Momentum Ocelot-G board' CONFIG_MOMENCO_OCELOT_G=0A= bool 'Support for NEC DDB Vrc-5476' CONFIG_DDB5476=0A= bool 'Support for NEC DDB Vrc-5477' CONFIG_DDB5477=0A= bool 'Support for NEC Osprey board' CONFIG_NEC_OSPREY=0A= @@ -161,6 +162,13 @@=0A= if [ "$CONFIG_MOMENCO_OCELOT" =3D "y" ]; then=0A= define_bool CONFIG_PCI y=0A= define_bool CONFIG_SYSCLK_100 y=0A= + define_bool CONFIG_SWAP_IO_SPACE y=0A= + define_bool CONFIG_NEW_IRQ y=0A= + define_bool CONFIG_NONCOHERENT_IO y=0A= + define_bool CONFIG_OLD_TIME_C y=0A= +fi=0A= +if [ "$CONFIG_MOMENCO_OCELOT_G" =3D "y" ]; then=0A= + define_bool CONFIG_PCI y=0A= define_bool CONFIG_SWAP_IO_SPACE y=0A= define_bool CONFIG_NEW_IRQ y=0A= define_bool CONFIG_NONCOHERENT_IO y=0A= Index: arch/mips/gt64120/momenco_ocelot/prom.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/prom.c,v=0A= retrieving revision 1.3.2.1=0A= diff -u -r1.3.2.1 prom.c=0A= --- arch/mips/gt64120/momenco_ocelot/prom.c 2001/12/12 13:45:58 1.3.2.1=0A= +++ arch/mips/gt64120/momenco_ocelot/prom.c 2002/02/22 04:34:38=0A= @@ -15,34 +15,35 @@=0A= #include =0A= #include =0A= =0A= -#define PLD_BASE 0xbc000000=0A= +struct callvectors {=0A= + int (*open) (char*, int, int);=0A= + int (*close) (int);=0A= + int (*read) (int, void*, int);=0A= + int (*write) (int, void*, int);=0A= + off_t (*lseek) (int, off_t, int);=0A= + int (*printf) (const char*, ...);=0A= + void (*cacheflush) (void);=0A= + char* (*gets) (char*);=0A= +};=0A= =0A= -#define REV 0x0 /* Board Assembly Revision */=0A= -#define PLD1ID 0x1 /* PLD 1 ID */=0A= -#define PLD2ID 0x2 /* PLD 2 ID */=0A= -#define RESET_STAT 0x3 /* Reset Status Register */=0A= -#define BOARD_STAT 0x4 /* Board Status Register */=0A= -#define CPCI_ID 0x5 /* Compact PCI ID Register */=0A= -#define CONTROL 0x8 /* Control Register */=0A= -#define CPU_EEPROM 0x9 /* CPU Configuration EEPROM Register */=0A= -#define INTMASK 0xA /* Interrupt Mask Register */=0A= -#define INTSTAT 0xB /* Interrupt Status Register */=0A= -#define INTSET 0xC /* Interrupt Set Register */=0A= -#define INTCLR 0xD /* Interrupt Clear Register */=0A= -=0A= -#define PLD_REG(x) ((uint8_t*)(PLD_BASE+(x)))=0A= -=0A= +struct callvectors* debug_vectors;=0A= char arcs_cmdline[CL_SIZE];=0A= =0A= +extern unsigned long gt64120_base;=0A= +=0A= const char *get_system_type(void)=0A= {=0A= return "Momentum Ocelot";=0A= }=0A= =0A= /* [jsun@junsun.net] PMON passes arguments in C main() style */=0A= -void __init prom_init(int argc, const char **arg)=0A= +void __init prom_init(int argc, char **arg, char** env, struct = callvectors *cv)=0A= {=0A= int i;=0A= + uint32_t tmp;=0A= +=0A= + /* save the PROM vectors for debugging use */=0A= + debug_vectors =3D cv;=0A= =0A= /* arg[0] is "g", the rest is boot parameters */=0A= arcs_cmdline[0] =3D '\0';=0A= @@ -56,10 +57,17 @@=0A= =0A= mips_machgroup =3D MACH_GROUP_MOMENCO;=0A= mips_machtype =3D MACH_MOMENCO_OCELOT;=0A= +=0A= + while (*env) {=0A= + if (strncmp("gtbase", *env, 6) =3D=3D 0) {=0A= + gt64120_base =3D simple_strtol(*env + strlen("gtbase=3D"),=0A= + NULL, 16);=0A= + break;=0A= + }=0A= + *env++;=0A= + }=0A= =0A= - /* turn off the Bit Error LED, which comes on automatically=0A= - * at power-up reset */=0A= - *PLD_REG(INTCLR) =3D 0x80;=0A= + debug_vectors->printf("Booting Linux kernel...\n");=0A= =0A= /* All the boards have at least 64MiB. If there's more, we=0A= detect and register it later */=0A= Index: arch/mips/gt64120/momenco_ocelot/setup.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/gt64120/momenco_ocelot/setup.c,v=0A= retrieving revision 1.5.2.1=0A= diff -u -r1.5.2.1 setup.c=0A= --- arch/mips/gt64120/momenco_ocelot/setup.c 2002/02/07 01:58:06 1.5.2.1=0A= +++ arch/mips/gt64120/momenco_ocelot/setup.c 2002/02/22 04:34:38=0A= @@ -83,25 +83,9 @@=0A= =0A= static void __init setup_l3cache(unsigned long size);=0A= =0A= -void __init momenco_ocelot_setup(void)=0A= +/* setup code for a handoff from a version 1 PMON 2000 PROM */=0A= +void PMON_v1_setup()=0A= {=0A= - void (*l3func)(unsigned long)=3DKSEG1ADDR(&setup_l3cache);=0A= - unsigned int tmpword;=0A= -=0A= - board_time_init =3D gt64120_time_init;=0A= -=0A= - _machine_restart =3D momenco_ocelot_restart;=0A= - _machine_halt =3D momenco_ocelot_halt;=0A= - _machine_power_off =3D momenco_ocelot_power_off;=0A= -=0A= - /*=0A= - * initrd_start =3D (ulong)ocelot_initrd_start;=0A= - * initrd_end =3D (ulong)ocelot_initrd_start + = (ulong)ocelot_initrd_size;=0A= - * initrd_below_start_ok =3D 1;=0A= - */=0A= - rtc_ops =3D &no_rtc_ops;=0A= -=0A= -=0A= /* A wired TLB entry for the GT64120A and the serial port. The=0A= GT64120A is going to be hit on every IRQ anyway - there's=0A= absolutely no point in letting it be a random TLB entry, as=0A= @@ -122,12 +106,10 @@=0A= Ocelot PLD (CS0) 0x2c000000 0xe0020000=0A= NVRAM 0x2c800000 0xe0030000=0A= */=0A= - =0A= add_temporary_entry(ENTRYLO(0x2C000000), ENTRYLO(0x2d000000), = 0xe0020000, PM_64K);=0A= =0A= -=0A= /* Relocate the CS3/BootCS region */=0A= - GT_WRITE( GT_CS3BOOTLD_OFS, 0x2f000000 >> 21);=0A= + GT_WRITE(GT_CS3BOOTLD_OFS, 0x2f000000 >> 21);=0A= =0A= /* Relocate CS[012] */=0A= GT_WRITE(GT_CS20LD_OFS, 0x2c000000 >> 21);=0A= @@ -142,18 +124,74 @@=0A= GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x24000000);=0A= GT_WRITE(GT_PCI0_CFGADDR_OFS, 0x80000024);=0A= GT_WRITE(GT_PCI0_CFGDATA_OFS, 0x24000001);=0A= +}=0A= =0A= - /* Relocate PCI0 I/O and Mem0 */=0A= - GT_WRITE(GT_PCI0IOLD_OFS, 0x20000000 >> 21);=0A= - GT_WRITE(GT_PCI0M0LD_OFS, 0x22000000 >> 21);=0A= +/* setup code for a handoff from a version 2 PMON 2000 PROM */=0A= +void PMON_v2_setup()=0A= +{=0A= + /* A wired TLB entry for the GT64120A and the serial port. The=0A= + GT64120A is going to be hit on every IRQ anyway - there's=0A= + absolutely no point in letting it be a random TLB entry, as=0A= + it'll just cause needless churning of the TLB. And we use=0A= + the other half for the serial port, which is just a PITA=0A= + otherwise :)=0A= =0A= - /* Relocate PCI0 Mem1 */=0A= - GT_WRITE(GT_PCI0M1LD_OFS, 0x36000000 >> 21);=0A= + Device Physical Virtual=0A= + GT64120 Internal Regs 0xf4000000 0xe0000000=0A= + UARTs (CS2) 0xfd000000 0xe0001000=0A= + */=0A= + add_wired_entry(ENTRYLO(0xf4000000), ENTRYLO(0xfD000000), 0xe0000000, = PM_4K);=0A= +=0A= + /* Also a temporary entry to let us talk to the Ocelot PLD and NVRAM=0A= + in the CS[012] region. We can't use ioremap() yet. The NVRAM=0A= + is a ST M48T37Y, which includes NVRAM, RTC, and Watchdog functions.=0A= +=0A= + Ocelot PLD (CS0) 0xfc000000 0xe0020000=0A= + NVRAM 0xfc800000 0xe0030000=0A= + */=0A= + add_temporary_entry(ENTRYLO(0xfC000000), ENTRYLO(0xfd000000), = 0xe0020000, PM_64K);=0A= +=0A= + gt64120_base =3D 0xe0000000;=0A= +}=0A= +=0A= +void __init momenco_ocelot_setup(void)=0A= +{=0A= + void (*l3func)(unsigned long)=3DKSEG1ADDR(&setup_l3cache);=0A= + unsigned int tmpword;=0A= +=0A= + board_time_init =3D gt64120_time_init;=0A= +=0A= + _machine_restart =3D momenco_ocelot_restart;=0A= + _machine_halt =3D momenco_ocelot_halt;=0A= + _machine_power_off =3D momenco_ocelot_power_off;=0A= +=0A= + /*=0A= + * initrd_start =3D (ulong)ocelot_initrd_start;=0A= + * initrd_end =3D (ulong)ocelot_initrd_start + = (ulong)ocelot_initrd_size;=0A= + * initrd_below_start_ok =3D 1;=0A= + */=0A= + rtc_ops =3D &no_rtc_ops;=0A= +=0A= + /* do handoff reconfiguration */=0A= + if (gt64120_base =3D=3D KSEG1ADDR(GT_DEF_BASE))=0A= + PMON_v1_setup();=0A= + else=0A= + PMON_v2_setup();=0A= =0A= + /* Turn off the Bit-Error LED */=0A= + OCELOT_PLD_WRITE(0x80, INTCLR);=0A= +=0A= /* Relocate all the PCI1 stuff, not that we use it */=0A= GT_WRITE(GT_PCI1IOLD_OFS, 0x30000000 >> 21);=0A= GT_WRITE(GT_PCI1M0LD_OFS, 0x32000000 >> 21);=0A= GT_WRITE(GT_PCI1M1LD_OFS, 0x34000000 >> 21);=0A= +=0A= + /* Relocate PCI0 I/O and Mem0 */=0A= + GT_WRITE(GT_PCI0IOLD_OFS, 0x20000000 >> 21);=0A= + GT_WRITE(GT_PCI0M0LD_OFS, 0x22000000 >> 21);=0A= +=0A= + /* Relocate PCI0 Mem1 */=0A= + GT_WRITE(GT_PCI0M1LD_OFS, 0x36000000 >> 21);=0A= =0A= /* For the initial programming, we assume 512MB configuration */=0A= /* Relocate the CPU's view of the RAM... */=0A= Index: arch/mips/kernel/setup.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/arch/mips/kernel/setup.c,v=0A= retrieving revision 1.96.2.12=0A= diff -u -r1.96.2.12 setup.c=0A= --- arch/mips/kernel/setup.c 2002/02/15 21:05:48 1.96.2.12=0A= +++ arch/mips/kernel/setup.c 2002/02/22 04:34:39=0A= @@ -665,6 +665,7 @@=0A= void malta_setup(void);=0A= void ikos_setup(void);=0A= void momenco_ocelot_setup(void);=0A= + void momenco_ocelot_g_setup(void);=0A= void nino_setup(void);=0A= void nec_osprey_setup(void);=0A= void jmr3927_setup(void);=0A= @@ -730,6 +731,11 @@=0A= #ifdef CONFIG_MOMENCO_OCELOT=0A= case MACH_GROUP_MOMENCO:=0A= momenco_ocelot_setup();=0A= + break;=0A= +#endif=0A= +#ifdef CONFIG_MOMENCO_OCELOT_G=0A= + case MACH_GROUP_MOMENCO:=0A= + momenco_ocelot_g_setup();=0A= break;=0A= #endif=0A= #ifdef CONFIG_SGI_IP22=0A= Index: drivers/mtd/devices/docprobe.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/drivers/mtd/devices/docprobe.c,v=0A= retrieving revision 1.3=0A= diff -u -r1.3 docprobe.c=0A= --- drivers/mtd/devices/docprobe.c 2001/11/05 20:15:52 1.3=0A= +++ drivers/mtd/devices/docprobe.c 2002/02/22 04:34:53=0A= @@ -88,6 +88,9 @@=0A= 0xe4000000,=0A= #elif defined(CONFIG_MOMENCO_OCELOT)=0A= 0x2f000000,=0A= + 0xff000000,=0A= +#elif defined(CONFIG_MOMENCO_OCELOT_G)=0A= + 0xff000000,=0A= #else=0A= #warning Unknown architecture for DiskOnChip. No default probe = locations defined=0A= #endif=0A= Index: include/asm-mips/bootinfo.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v=0A= retrieving revision 1.43.2.8=0A= diff -u -r1.43.2.8 bootinfo.h=0A= --- include/asm-mips/bootinfo.h 2002/02/15 21:05:49 1.43.2.8=0A= +++ include/asm-mips/bootinfo.h 2002/02/22 04:35:04=0A= @@ -121,6 +121,7 @@=0A= * Valid machtype for group MOMENCO=0A= */=0A= #define MACH_MOMENCO_OCELOT 0=0A= +#define MACH_MOMENCO_OCELOT_G 1=0A= =0A= =0A= /*=0A= Index: include/asm-mips/serial.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/include/asm-mips/serial.h,v=0A= retrieving revision 1.23.2.2=0A= diff -u -r1.23.2.2 serial.h=0A= --- include/asm-mips/serial.h 2002/01/07 03:33:54 1.23.2.2=0A= +++ include/asm-mips/serial.h 2002/02/22 04:35:04=0A= @@ -267,6 +267,23 @@=0A= #define MOMENCO_OCELOT_SERIAL_PORT_DEFNS=0A= #endif=0A= =0A= +#ifdef CONFIG_MOMENCO_OCELOT_G=0A= +/* Ordinary NS16552 duart with a 20MHz crystal. */=0A= +#define OCELOT_G_BASE_BAUD ( 20000000 / 16 )=0A= +=0A= +#define OCELOT_G_SERIAL1_IRQ 4=0A= +#define OCELOT_G_SERIAL1_BASE 0xe0001020=0A= +=0A= +#define _OCELOT_G_SERIAL_INIT(int, base) \=0A= + { baud_base: OCELOT_G_BASE_BAUD, irq: int, flags: STD_COM_FLAGS,\=0A= + iomem_base: (u8 *) base, iomem_reg_shift: 2, \=0A= + io_type: SERIAL_IO_MEM }=0A= +#define MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS \=0A= + _OCELOT_G_SERIAL_INIT(OCELOT_G_SERIAL1_IRQ, OCELOT_G_SERIAL1_BASE)=0A= +#else=0A= +#define MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS=0A= +#endif=0A= +=0A= #ifdef CONFIG_DDB5477=0A= #define DDB5477_SERIAL_PORT_DEFNS = \=0A= { baud_base: BASE_BAUD, irq: 12, flags: STD_COM_FLAGS, = \=0A= @@ -279,17 +296,18 @@=0A= #define DDB5477_SERIAL_PORT_DEFNS=0A= #endif=0A= =0A= -#define SERIAL_PORT_DFNS \=0A= - IVR_SERIAL_PORT_DEFNS \=0A= - ITE_SERIAL_PORT_DEFNS \=0A= - ATLAS_SERIAL_PORT_DEFNS \=0A= - COBALT_SERIAL_PORT_DEFNS \=0A= - EV96100_SERIAL_PORT_DEFNS \=0A= - JAZZ_SERIAL_PORT_DEFNS \=0A= - STD_SERIAL_PORT_DEFNS \=0A= - EXTRA_SERIAL_PORT_DEFNS \=0A= - HUB6_SERIAL_PORT_DFNS \=0A= - MOMENCO_OCELOT_SERIAL_PORT_DEFNS\=0A= - AU1000_SERIAL_PORT_DEFNS \=0A= - TXX927_SERIAL_PORT_DEFNS \=0A= +#define SERIAL_PORT_DFNS \=0A= + IVR_SERIAL_PORT_DEFNS \=0A= + ITE_SERIAL_PORT_DEFNS \=0A= + ATLAS_SERIAL_PORT_DEFNS \=0A= + COBALT_SERIAL_PORT_DEFNS \=0A= + EV96100_SERIAL_PORT_DEFNS \=0A= + JAZZ_SERIAL_PORT_DEFNS \=0A= + STD_SERIAL_PORT_DEFNS \=0A= + EXTRA_SERIAL_PORT_DEFNS \=0A= + HUB6_SERIAL_PORT_DFNS \=0A= + MOMENCO_OCELOT_SERIAL_PORT_DEFNS \=0A= + MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS \=0A= + AU1000_SERIAL_PORT_DEFNS \=0A= + TXX927_SERIAL_PORT_DEFNS \=0A= DDB5477_SERIAL_PORT_DEFNS=0A= ------=_NextPart_000_003F_01C1BB0F.E5696E00-- From owner-linux-mips@oss.sgi.com Thu Feb 21 20:58:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M4w7l20275 for linux-mips-outgoing; Thu, 21 Feb 2002 20:58:07 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M4vv920270 for ; Thu, 21 Feb 2002 20:57:57 -0800 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id g1M3tAB13008; Thu, 21 Feb 2002 19:55:10 -0800 Message-ID: <3C75C19C.13BB0FCC@mvista.com> Date: Thu, 21 Feb 2002 19:57:16 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case? References: <3C75B181.C5A065A1@mvista.com> Content-Type: multipart/mixed; boundary="------------A6523E81F65DE547E9307DC0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3263 Lines: 96 This is a multi-part message in MIME format. --------------A6523E81F65DE547E9307DC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jun Sun wrote: > Anyhow, the problem I am seeing with FPU/SMP case seems to be caused by FPU > emulation code itself, if we can assume it is not caused by fpu context > switch. Right now the FPU is not turned on on the box. > OK, I found the guilt part in FPU emul. It is the global variable ieee754_csr. The following patch seems to fix the problem. I am sure someone who are more familiar with FPU might be able to make it more elegant. There is another global variable which is potentially dangerous for SMP. It is fpuemuprivate. Currently it is used in almost used for accounting and read-only purpose. I did not bother to change it. It should be fixed too, I suppose. Cheers. Jun --------------A6523E81F65DE547E9307DC0 Content-Type: text/plain; charset=us-ascii; name="patch3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch3" diff -Nru linux/arch/mips/math-emu/ieee754.h.orig linux/arch/mips/math-emu/ieee754.h --- linux/arch/mips/math-emu/ieee754.h.orig Thu Jan 31 17:13:26 2002 +++ linux/arch/mips/math-emu/ieee754.h Thu Feb 21 19:34:06 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 linux/arch/mips/math-emu/ieee754.c.orig linux/arch/mips/math-emu/ieee754.c --- linux/arch/mips/math-emu/ieee754.c.orig Mon Jan 28 11:17:14 2002 +++ linux/arch/mips/math-emu/ieee754.c Thu Feb 21 19:37:32 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 linux/arch/mips/math-emu/cp1emu.c.orig linux/arch/mips/math-emu/cp1emu.c --- linux/arch/mips/math-emu/cp1emu.c.orig Mon Jan 28 11:17:14 2002 +++ linux/arch/mips/math-emu/cp1emu.c Thu Feb 21 19:22:45 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 linux/arch/mips/math-emu/dp_sqrt.c.orig linux/arch/mips/math-emu/dp_sqrt.c --- linux/arch/mips/math-emu/dp_sqrt.c.orig Thu Feb 21 19:41:09 2002 +++ linux/arch/mips/math-emu/dp_sqrt.c Thu Feb 21 19:39:08 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; --------------A6523E81F65DE547E9307DC0-- From owner-linux-mips@oss.sgi.com Fri Feb 22 01:54:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M9sKd27153 for linux-mips-outgoing; Fri, 22 Feb 2002 01:54:20 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M9sF927150 for ; Fri, 22 Feb 2002 01:54:15 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id E6DE6866; Fri, 22 Feb 2002 09:53:49 +0100 (CET) Received: by localhost (Postfix, from userid 1000) id 024BC1A2C8; Fri, 22 Feb 2002 09:52:12 +0100 (CET) Date: Fri, 22 Feb 2002 09:52:12 +0100 From: Florian Lohoff To: Wayne Gowcher Cc: Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020222085212.GB21544@paradigm.rfc822.org> References: <20020221102503.A28936@lucon.org> <20020221184558.33231.qmail@web11906.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <20020221184558.33231.qmail@web11906.mail.yahoo.com> User-Agent: Mutt/1.3.27i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1143 Lines: 38 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2002 at 10:45:58AM -0800, Wayne Gowcher wrote: > It seems like getting pthread support for mips1 could > be a lengthy and involved process. >=20 > So I was wondering has anyone out there used pthreads > for with mips1 with any of the redhat distributions on > sgi ? Its just the matter of ll/sc support - There are also some=20 "mips2" which lack ll/sc. There is some kernel emulation for ll/sc and also SYSMIPS(MIPS_ATOMIC_SET) which should be enough to get pthreads working on mips1. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --St7VIuEGZ6dlpu13 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 iD8DBQE8dga8Uaz2rXW+gJcRAiVJAKCi9LxMWEir/x18dCaO00FIe8i6egCg4L0i O9SzEGnwWIRmfvPzJWr/Ws0= =nkzU -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-linux-mips@oss.sgi.com Fri Feb 22 02:44:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MAifa29375 for linux-mips-outgoing; Fri, 22 Feb 2002 02:44:41 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MAiU929371 for ; Fri, 22 Feb 2002 02:44:30 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA14818; Fri, 22 Feb 2002 01:44:24 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA15171; Fri, 22 Feb 2002 01:44:20 -0800 (PST) Message-ID: <005801c1bb85$a9e9c980$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , References: <3C75B181.C5A065A1@mvista.com> Subject: Re: lazy fpu switch irrelavant to no-fpu case? Date: Fri, 22 Feb 2002 10:45:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3371 Lines: 107 In the very first cut at integrating the Algorithmics emulator with Linux, the emulator actually contained storage that represented the FPU registers, and FP context management was meaningful. Using thread context storage directly for the FPU registers was an optimisaton that I did after I got the code running, and I didn't bother eliminating the last_task_used_math setup, probably on the basis that it wasn't costing much and that it might still be useful in some way. I don't think you'll break anything by getting rid of it, but I don't think you'll fix anything either. As I stated in another message on the subject of SMP problems observed with the FPU emulator, while the basic mechanisms of FP emulation should be SMP safe, there may well be non-SMP artifcacts in the code. A cursory inspection shows that there is a single mips_fpu_emulator_private data structure for the emulator, which contains statistics which risk being screwed up due to non-atomic increments being used. That ought to be fixed, but should not cause any user-mode-visible problems. But I also note that the emulator uses a single global storage location for "ieee754_csr". The kernel port of the code does copies between the thread context image of the MIPS csr and this global which are manifestly SMP unsafe. Could the bugs you're seeing be explainable by corruption of rounding mode and exception state? Regards, Kevin K. ----- Original Message ----- From: "Jun Sun" To: Sent: Friday, February 22, 2002 3:48 AM Subject: lazy fpu switch irrelavant to no-fpu case? > > It appears to me that lazy fpu switch has no relevancy to CPUs that don't have > FPU. > > If you do a scan, you will see last_task_used_math are used in four kernel > files: > > ptrace.c > process.c > signal.c > traps.c > > In the case of ptrace.c and process.c, the variable is used only when CPU has > FPU. > > In the case of traps.c (do_cpu()), it used redaundantly with another condition > checking. > > In the case of signal.c, no matter what last_task_used_math is, the same code > will be executed anyway. > > Now think about it, it actually makes sense - if we don't have hardware FPU, > why do we care of fpu context switch. > > Anyhow, the problem I am seeing with FPU/SMP case seems to be caused by FPU > emulation code itself, if we can assume it is not caused by fpu context > switch. Right now the FPU is not turned on on the box. > > The following patch cleans it up a little based on the above observation. > Make sense? > > Jun > > diff -Nru linux/arch/mips/kernel/traps.c.orig linux/arch/mips/kernel/traps.c > --- linux/arch/mips/kernel/traps.c.orig Wed Jan 30 15:17:12 2002 > +++ linux/arch/mips/kernel/traps.c Thu Feb 21 18:46:28 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; > From owner-linux-mips@oss.sgi.com Fri Feb 22 02:59:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MAxHc29698 for linux-mips-outgoing; Fri, 22 Feb 2002 02:59:17 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MAx3929693 for ; Fri, 22 Feb 2002 02:59:03 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA15024; Fri, 22 Feb 2002 01:58:56 -0800 (PST) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA15479; Fri, 22 Feb 2002 01:58:54 -0800 (PST) Message-ID: <006701c1bb87$b2b6fb80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , References: <3C75B181.C5A065A1@mvista.com> <3C75C19C.13BB0FCC@mvista.com> Subject: Re: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case? Date: Fri, 22 Feb 2002 10:59:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3979 Lines: 123 This is what I get for processing my mail in-order. I just got done writing a message asking if the ieee_754_csr issue might be at the root of your problem. Anyway, rather than create an array of the damned things, I would think that the "best" thing to do would be to merge the "abstract" IEEE CSR with the simulated MIPS CSR (by adding the "noq" and "nod" bits in otherwise unused/reserved bit positions), and using the thread-local CSR copy for all of the ieee_754_csr manipulations, much as I did for the FP registers. That would be a bit more intrusive than your proposed hack, however, and only slightly more efficient. Kevin K. ----- Original Message ----- From: "Jun Sun" To: Sent: Friday, February 22, 2002 4:57 AM Subject: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case? > Jun Sun wrote: > > Anyhow, the problem I am seeing with FPU/SMP case seems to be caused by FPU > > emulation code itself, if we can assume it is not caused by fpu context > > switch. Right now the FPU is not turned on on the box. > > > > OK, I found the guilt part in FPU emul. It is the global variable > ieee754_csr. The following patch seems to fix the problem. I am sure someone > who are more familiar with FPU might be able to make it more elegant. > > There is another global variable which is potentially dangerous for SMP. It > is fpuemuprivate. Currently it is used in almost used for accounting and > read-only purpose. I did not bother to change it. It should be fixed too, I > suppose. > > Cheers. > > Jun ---------------------------------------------------------------------------- ---- > diff -Nru linux/arch/mips/math-emu/ieee754.h.orig linux/arch/mips/math-emu/ieee754.h > --- linux/arch/mips/math-emu/ieee754.h.orig Thu Jan 31 17:13:26 2002 > +++ linux/arch/mips/math-emu/ieee754.h Thu Feb 21 19:34:06 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 linux/arch/mips/math-emu/ieee754.c.orig linux/arch/mips/math-emu/ieee754.c > --- linux/arch/mips/math-emu/ieee754.c.orig Mon Jan 28 11:17:14 2002 > +++ linux/arch/mips/math-emu/ieee754.c Thu Feb 21 19:37:32 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 linux/arch/mips/math-emu/cp1emu.c.orig linux/arch/mips/math-emu/cp1emu.c > --- linux/arch/mips/math-emu/cp1emu.c.orig Mon Jan 28 11:17:14 2002 > +++ linux/arch/mips/math-emu/cp1emu.c Thu Feb 21 19:22:45 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 linux/arch/mips/math-emu/dp_sqrt.c.orig linux/arch/mips/math-emu/dp_sqrt.c > --- linux/arch/mips/math-emu/dp_sqrt.c.orig Thu Feb 21 19:41:09 2002 > +++ linux/arch/mips/math-emu/dp_sqrt.c Thu Feb 21 19:39:08 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; > From owner-linux-mips@oss.sgi.com Fri Feb 22 04:57:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MCv9404223 for linux-mips-outgoing; Fri, 22 Feb 2002 04:57:09 -0800 Received: from multitech.co.in ([202.54.39.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MCv4904220 for ; Fri, 22 Feb 2002 04:57:05 -0800 Received: from multitech.co.in (Venkatesh [192.168.3.26]) by multitech.co.in (8.12.1/8.12.1) with ESMTP id g1MBuBQd004928 for ; Fri, 22 Feb 2002 17:26:12 +0530 Message-ID: <3C763244.5030206@multitech.co.in> Date: Fri, 22 Feb 2002 17:27:56 +0530 From: Venkatesh M R Organization: Multitech Software Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux-MIPS Subject: How To Remove Write Protection Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 292 Lines: 10 Hello, I am presently porting RTLinux to MIPS Atlas board ( with 4Kc core ). Can you please tell me how to remove the write protection of the Linux kernel (2.4.3) . Because I am getting the page fault when i am trying to insert the Rtlinux module. Best Regards & Thanks, Venkatesh M R From owner-linux-mips@oss.sgi.com Fri Feb 22 05:00:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MD0U804382 for linux-mips-outgoing; Fri, 22 Feb 2002 05:00:30 -0800 Received: from multitech.co.in ([202.54.39.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MD0P904377 for ; Fri, 22 Feb 2002 05:00:26 -0800 Received: from multitech.co.in (Venkatesh [192.168.3.26]) by multitech.co.in (8.12.1/8.12.1) with ESMTP id g1MBxXQd005031 for ; Fri, 22 Feb 2002 17:29:34 +0530 Message-ID: <3C76330E.1080208@multitech.co.in> Date: Fri, 22 Feb 2002 17:31:18 +0530 From: Venkatesh M R Organization: Multitech Software Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux-MIPS Subject: Porting RTLinux Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 168 Lines: 8 Hello, Is any one working (or has worked ) on Porting of RTLinux to MIPS (4Kc core) . If so can you please share your Ideas with me. Best Regards Venkatesh M R From owner-linux-mips@oss.sgi.com Fri Feb 22 06:40:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MEeZT11373 for linux-mips-outgoing; Fri, 22 Feb 2002 06:40:35 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MEeR911370 for ; Fri, 22 Feb 2002 06:40:28 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA07299; Fri, 22 Feb 2002 14:38:53 +0100 (MET) Date: Fri, 22 Feb 2002 14:38:53 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Wayne Gowcher , Linux-MIPS Subject: Re: pthread support in mipsel-linux In-Reply-To: <20020221102503.A28936@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 543 Lines: 15 On Thu, 21 Feb 2002, H . J . Lu wrote: > > Just to clarify, the glibc rpm in your Redhat 7.1 is > > compiled with -mips1 right ? So as it is broken yes ? > > Yes. -mips1 doesn't work well with thread. What's wrong with -mips1 currently? It used to be OK around glibc 2.2 -- has anything changed since then that needs -mips1 to be fixed? -- + 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 Feb 22 06:45:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MEje311504 for linux-mips-outgoing; Fri, 22 Feb 2002 06:45:40 -0800 Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [146.215.0.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MEjb911501 for ; Fri, 22 Feb 2002 06:45:37 -0800 Received: from mail2.sony.co.jp (mail2.sony.co.jp [43.0.1.202]) by ns5.sony.co.jp (R8/Sony) with ESMTP id g1MDjQS99525; Fri, 22 Feb 2002 22:45:26 +0900 (JST) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id g1MDjPH12995; Fri, 22 Feb 2002 22:45:25 +0900 (JST) Received: from smail1.sm.sony.co.jp (smail1.sm.sony.co.jp [43.11.253.1]) by mail2.sony.co.jp (R8) with ESMTP id g1MDjO712958; Fri, 22 Feb 2002 22:45:24 +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 WAA15480; Fri, 22 Feb 2002 22:45:18 +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 WAA08343; Fri, 22 Feb 2002 22:45:23 +0900 (JST) Received: from localhost by mach0.sm.sony.co.jp (8.11.0/8.11.0) with ESMTP id g1MDjNS24593; Fri, 22 Feb 2002 22:45:23 +0900 (JST) Date: Fri, 22 Feb 2002 22:45:22 +0900 (JST) Message-Id: <20020222.224522.80690047.machida@sm.sony.co.jp> To: macro@ds2.pg.gda.pl Cc: hjl@lucon.org, wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: pthread support in mipsel-linux From: Hiroyuki Machida In-Reply-To: References: <20020221102503.A28936@lucon.org> 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 Content-Length: 636 Lines: 23 From: "Maciej W. Rozycki" Subject: Re: pthread support in mipsel-linux Date: Fri, 22 Feb 2002 14:38:53 +0100 (MET) > On Thu, 21 Feb 2002, H . J . Lu wrote: > > > > Just to clarify, the glibc rpm in your Redhat 7.1 is > > > compiled with -mips1 right ? So as it is broken yes ? > > > > Yes. -mips1 doesn't work well with thread. > > What's wrong with -mips1 currently? It used to be OK around glibc 2.2 -- > has anything changed since then that needs -mips1 to be fixed? > Functions such as compre_and_swap() in sysdeps/mips/atomicity.h are not atmoic with -mips1 option. --- Hiroyuki Machida Sony Corp. From owner-linux-mips@oss.sgi.com Fri Feb 22 07:08:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MF8CP11931 for linux-mips-outgoing; Fri, 22 Feb 2002 07:08:12 -0800 Received: from dea.linux-mips.net (a1as04-p242.stg.tli.de [195.252.186.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MF88911928 for ; Fri, 22 Feb 2002 07:08:09 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g1ME7jv28928; Fri, 22 Feb 2002 15:07:45 +0100 Date: Fri, 22 Feb 2002 15:07:45 +0100 From: Ralf Baechle To: Venkatesh M R Cc: Linux-MIPS Subject: Re: How To Remove Write Protection Message-ID: <20020222150745.A28918@dea.linux-mips.net> References: <3C763244.5030206@multitech.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C763244.5030206@multitech.co.in>; from venkatesh@multitech.co.in on Fri, Feb 22, 2002 at 05:27:56PM +0530 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 361 Lines: 11 On Fri, Feb 22, 2002 at 05:27:56PM +0530, Venkatesh M R wrote: > I am presently porting RTLinux to MIPS Atlas board ( with 4Kc core ). > Can you please tell me how to remove the write protection of the Linux > kernel (2.4.3) . > Because I am getting the page fault when i am trying to insert the > Rtlinux module. Modules aren't write protected. Ralf From owner-linux-mips@oss.sgi.com Fri Feb 22 07:16:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MFGXY12108 for linux-mips-outgoing; Fri, 22 Feb 2002 07:16:33 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MFGH912102 for ; Fri, 22 Feb 2002 07:16:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08019; Fri, 22 Feb 2002 15:10:55 +0100 (MET) Date: Fri, 22 Feb 2002 15:10:55 +0100 (MET) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: kevink@mips.com, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.17: The second mb() rework (final) In-Reply-To: <20020222.113634.45519920.nemoto@toshiba-tops.co.jp> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1042 Lines: 28 On Fri, 22 Feb 2002, Atsushi Nemoto wrote: > The contradiction is came from some confusion about usage of a word > "Core" in TX39 manual. Maybe a writer of the quoted statements > assumes a write buffer is outside of a "R3900 Processor Core". So if > he said "operation is completed" it means "data are sent to a write That's how I understand it. > buffer". Of course this point of view is not acceptable for software > programmers... If we handle it for the DECstation, we can do so for the TX39 as well. > macro> It's clear "sync" is strong on the TX39, stronger then required > macro> by MIPS II. > > So unfortunately this is not true. It is, considering the write buffer is actually external to the CPU. It's even required to be executed before checking the write buffer, as otherwise you may get a false positive result. -- + 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 Feb 22 07:31:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MFVxU12496 for linux-mips-outgoing; Fri, 22 Feb 2002 07:31:59 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MFVg912489 for ; Fri, 22 Feb 2002 07:31:43 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA08463; Fri, 22 Feb 2002 15:28:58 +0100 (MET) Date: Fri, 22 Feb 2002 15:28:57 +0100 (MET) From: "Maciej W. Rozycki" To: Hiroyuki Machida cc: hjl@lucon.org, wgowcher@yahoo.com, linux-mips@oss.sgi.com Subject: Re: pthread support in mipsel-linux In-Reply-To: <20020222.224522.80690047.machida@sm.sony.co.jp> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 663 Lines: 17 On Fri, 22 Feb 2002, Hiroyuki Machida wrote: > > What's wrong with -mips1 currently? It used to be OK around glibc 2.2 -- > > has anything changed since then that needs -mips1 to be fixed? > > Functions such as compre_and_swap() in sysdeps/mips/atomicity.h are > not atmoic with -mips1 option. They used not to be used for threads -- has it changed recently? It would make threads non-operational on the i386 as well, yet it doesn't seem to be the case. -- + 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 Feb 22 08:33:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MGXdc15072 for linux-mips-outgoing; Fri, 22 Feb 2002 08:33:39 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MGXc915069 for ; Fri, 22 Feb 2002 08:33:38 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA17995; Fri, 22 Feb 2002 07:33:29 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA21494; Fri, 22 Feb 2002 07:33:28 -0800 (PST) Message-ID: <002e01c1bbb6$d436d5d0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Venkatesh M R" , "Linux-MIPS" References: <3C763244.5030206@multitech.co.in> Subject: Re: How To Remove Write Protection Date: Fri, 22 Feb 2002 16:37:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 454 Lines: 12 > I am presently porting RTLinux to MIPS Atlas board ( with 4Kc core ). > Can you please tell me how to remove the write protection of the Linux > kernel (2.4.3) . > Because I am getting the page fault when i am trying to insert the > Rtlinux module. I rather doubt that write protection has anything to do with what you are seeing. It is far more likely that you are making the kernel dereference an uninitialized pointer. Kevin K. From owner-linux-mips@oss.sgi.com Fri Feb 22 09:53:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MHrK916217 for linux-mips-outgoing; Fri, 22 Feb 2002 09:53:20 -0800 Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MHrH916214 for ; Fri, 22 Feb 2002 09:53:17 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020222165312.RPYZ2951.rwcrmhc53.attbi.com@ocean.lucon.org>; Fri, 22 Feb 2002 16:53:12 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7A202125C1; Fri, 22 Feb 2002 08:53:11 -0800 (PST) Date: Fri, 22 Feb 2002 08:53:10 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Wayne Gowcher , Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020222085310.A17035@lucon.org> References: <20020221102503.A28936@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 22, 2002 at 02:38:53PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 559 Lines: 17 On Fri, Feb 22, 2002 at 02:38:53PM +0100, Maciej W. Rozycki wrote: > On Thu, 21 Feb 2002, H . J . Lu wrote: > > > > Just to clarify, the glibc rpm in your Redhat 7.1 is > > > compiled with -mips1 right ? So as it is broken yes ? > > > > Yes. -mips1 doesn't work well with thread. > > What's wrong with -mips1 currently? It used to be OK around glibc 2.2 -- > has anything changed since then that needs -mips1 to be fixed? > Mutex is now implemented with spin lock by default. BTW, how many people have run "make check" on glibc compiled -mips1? H.J. From owner-linux-mips@oss.sgi.com Fri Feb 22 09:57:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MHvTQ16370 for linux-mips-outgoing; Fri, 22 Feb 2002 09:57:29 -0800 Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MHvR916367 for ; Fri, 22 Feb 2002 09:57:27 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020222165721.YOMU1214.rwcrmhc54.attbi.com@ocean.lucon.org>; Fri, 22 Feb 2002 16:57:21 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 085CD125C1; Fri, 22 Feb 2002 08:57:20 -0800 (PST) Date: Fri, 22 Feb 2002 08:57:20 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Wayne Gowcher , Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020222085720.B17035@lucon.org> References: <20020221102503.A28936@lucon.org> <20020222085310.A17035@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020222085310.A17035@lucon.org>; from hjl@lucon.org on Fri, Feb 22, 2002 at 08:53:10AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 822 Lines: 22 On Fri, Feb 22, 2002 at 08:53:10AM -0800, H . J . Lu wrote: > On Fri, Feb 22, 2002 at 02:38:53PM +0100, Maciej W. Rozycki wrote: > > On Thu, 21 Feb 2002, H . J . Lu wrote: > > > > > > Just to clarify, the glibc rpm in your Redhat 7.1 is > > > > compiled with -mips1 right ? So as it is broken yes ? > > > > > > Yes. -mips1 doesn't work well with thread. > > > > What's wrong with -mips1 currently? It used to be OK around glibc 2.2 -- > > has anything changed since then that needs -mips1 to be fixed? > > > > Mutex is now implemented with spin lock by default. BTW, how many > people have run "make check" on glibc compiled -mips1? Also, how many people have bootstrapped and run "make check" on gcc 3.1 from CVS on Linux/mips with glibc compiled with -mips1? There are some thread tests in libstdc++-v3. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 22 10:09:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MI92N16640 for linux-mips-outgoing; Fri, 22 Feb 2002 10:09:02 -0800 Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MI8w916637 for ; Fri, 22 Feb 2002 10:08:58 -0800 Received: (from kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) id g1MH8pX13027; Fri, 22 Feb 2002 18:08:51 +0100 Date: Fri, 22 Feb 2002 18:08:51 +0100 From: Kjeld Borch Egevang Message-Id: <200202221708.g1MH8pX13027@coplin19.mips.com> To: Subject: Re: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case? In-Reply-To: <006701c1bb87$b2b6fb80$0deca8c0@Ulysses> References: <3C75B181.C5A065A1@mvista.com> <3C75C19C.13BB0FCC@mvista.com> <006701c1bb87$b2b6fb80$0deca8c0@Ulysses> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1060 Lines: 27 In mips.test, you wrote: >This is what I get for processing my mail in-order. >I just got done writing a message asking if the >ieee_754_csr issue might be at the root of your >problem. > >Anyway, rather than create an array of the damned >things, I would think that the "best" thing to do would >be to merge the "abstract" IEEE CSR with the >simulated MIPS CSR (by adding the "noq" and >"nod" bits in otherwise unused/reserved bit positions), >and using the thread-local CSR copy for all of the >ieee_754_csr manipulations, much as I did for >the FP registers. That would be a bit more intrusive >than your proposed hack, however, and only slightly >more efficient. I've been wondering: Why was the CSR copy made in the first place? /Kjeld -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Fri Feb 22 10:14:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MIERK16791 for linux-mips-outgoing; Fri, 22 Feb 2002 10:14:27 -0800 Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MIEO916787 for ; Fri, 22 Feb 2002 10:14:24 -0800 Received: from ocean.lucon.org ([12.234.16.87]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020222171419.YJQL1147.rwcrmhc52.attbi.com@ocean.lucon.org>; Fri, 22 Feb 2002 17:14:19 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6994A125C1; Fri, 22 Feb 2002 09:14:18 -0800 (PST) Date: Fri, 22 Feb 2002 09:14:17 -0800 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Wayne Gowcher , Linux-MIPS Subject: Re: pthread support in mipsel-linux Message-ID: <20020222091417.A17377@lucon.org> References: <20020222085310.A17035@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Feb 22, 2002 at 06:06:58PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 720 Lines: 20 On Fri, Feb 22, 2002 at 06:06:58PM +0100, Maciej W. Rozycki wrote: > On Fri, 22 Feb 2002, H . J . Lu wrote: > > > Mutex is now implemented with spin lock by default. BTW, how many > > Well, testandset() from linuxthreads/sysdeps/mips/pt-machine.h should > work fine with -mips1. As should __pthread_spin_lock() from > linuxthreads/sysdeps/mips/pspinlock.c. > > > people have run "make check" on glibc compiled -mips1? > > No idea. I may run `./configure && make all && make check' tonight on my > system as it's going to be idle over the weekend anyway. It should finish > by Monday. ;-) You should also try "make check" on the current gcc 3.1. I found and fixed the MIPS II ll/sc bugs by doing that. H.J. From owner-linux-mips@oss.sgi.com Fri Feb 22 10:22:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MIMoe16951 for linux-mips-outgoing; Fri, 22 Feb 2002 10:22:50 -0800 Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MILR916944 for ; Fri, 22 Feb 2002 10:21:27 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA11973; Fri, 22 Feb 2002 18:06:58 +0100 (MET) Date: Fri, 22 Feb 2002 18:06:58 +0100 (MET) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Wayne Gowcher , Linux-MIPS Subject: Re: pthread support in mipsel-linux In-Reply-To: <20020222085310.A17035@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 707 Lines: 19 On Fri, 22 Feb 2002, H . J . Lu wrote: > Mutex is now implemented with spin lock by default. BTW, how many Well, testandset() from linuxthreads/sysdeps/mips/pt-machine.h should work fine with -mips1. As should __pthread_spin_lock() from linuxthreads/sysdeps/mips/pspinlock.c. > people have run "make check" on glibc compiled -mips1? No idea. I may run `./configure && make all && make check' tonight on my system as it's going to be idle over the weekend anyway. It should finish by Monday. ;-) -- + 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 Feb 22 11:17:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MJHmw17810 for linux-mips-outgoing; Fri, 22 Feb 2002 11:17:48 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MJHc917807 for ; Fri, 22 Feb 2002 11:17:39 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 840FAA1CB; Fri, 22 Feb 2002 19:17:34 +0100 (CET) Date: Fri, 22 Feb 2002 19:17:34 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Problem with delo Message-ID: <20020222191734.B15503@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2348 Lines: 81 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've just installed delo on my /125, but it doesn't boot the kernel. It *seems* (to me) that it successfully load it's second stage, but second stage bootloader failed to load /etc/delo.conf. Layout is like this: /dev/sda1 Small Linux/ext2 partition containing nothing /dev/sda2 Large Linux/ext2 partition containing the / filesystem (including /boot directory) /dev/sda3 Linux swap My delo.conf looks like this: label=3Dlinux image=3D/boot/vmlinux append=3D"root=3D/dev/sda2 init=3D/bin/bash" I recompiled delo with -DDEBUG and now, I'm getting this bootup message: >> boot 3/rz1 2/linux delo V0.7 Copyright 2000 Florian Lohoff callv addr a0002f88 clo: 0 boot clo: 1 3/rz1 clo: 2 2/linux Getting partition info Partition '2' 2 bootread returned 512 DOS disklabel found 1 0 83 62 98146 2 0 83 98208 5665374 delo_open: called delo_open: bootinit returned 0 delo_set_blksize: called 1024 delo_read_blk: called for 98210 count 1024 to 805402f8 delo_set_blksize: called 4096 delo_read_blk: called for 98216 count 4096 to 805406f8 delo_read_blk: called for 98240 count 4096 to 80542710 delo_read_blk: called for 102264 count 4096 to 805416f8 delo_read_blk: called for 3506112 count 4096 to 80542710 delo_read_blk: called for 364520 count 4096 to 805416f8 delo_read_blk: called for 364528 count 4096 to 805416f8 delo_read_blk: called for 364536 count 4096 to 805416f8 delo_read_blk: called for 156648 count 4096 to 805416f8 readfile: ext2fs_namei_follow returned 2133571404 extfs_open returned Unknown ext2 error(2133571404) Couldnt fetch config.file /etc/delo.conf I'm not exactly familiar with delo's code. Flo, do you have a hint? MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --OwLcNYc0lM97+oe1 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 iEYEARECAAYFAjx2iz0ACgkQHb1edYOZ4bt/4QCgh1vjD9m+1wFD4eLz0lRzcISD E2EAnR7pb23/HKLuqVs8eUXWlxtM9yKN =Yh7R -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- From owner-linux-mips@oss.sgi.com Fri Feb 22 16:11:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1N0BnW24140 for linux-mips-outgoing; Fri, 22 Feb 2002 16:11:49 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1N0BP924137 for ; Fri, 22 Feb 2002 16:11:25 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001