From alhaz@xmission.com Thu Oct 1 06:01:56 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA24652; Thu, 1 Oct 1998 06:01:54 +0200 (MET DST) Received-Date: Thu, 1 Oct 1998 06:01:54 +0200 (MET DST) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zOZw3-0006kP-00 for linux-mips@fnet.fr; Wed, 30 Sep 1998 22:01:47 -0600 Sender: alhaz@fnet.fr Message-ID: <3612FE23.D9DDC93F@xmission.com> Date: Wed, 30 Sep 1998 21:59:31 -0600 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Wheee - Magnum 4000PC-50 almost on-line, I think. the hardware atleast . . Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2448 Lines: 52 Well I found a deal on full parity 4 meg simms, and filled each and every simm socket of my Magnum with a 12-chip 4 meg simm. Half of them with Kingston simms no less. I don't have a monitor that works with this thing (yet). I have a Sun monitor that may work if I adapt the cable, but I'm not yet certian. If I remember right, when the prom LED blinks out various letters and numbers and goes blank, that's considered a successful POST. If that's the case, I'm more or less in business. I was hoping that I could run this beast with a serial console, since I'd like to eventually use it as a dedicated MP3 player. Or atleast that's more or less what I'm figuring. Can someone verify that this is a successful POST? Also, does anyone know for sure if this system classicly has problems with gold-pinned simms? Half of the simms I have are gold, the other half are tin. I know as a general rule you should match gold simms to gold slots, and that the slots on this motherboard are not gold. However, I have not personally ever experienced ill effects from the use of gold simms in tin slots, or ill effects from mixing gold and tin simms. I actually used one gold and one tin 16-meg simms together for the past 3 years in various motherboards, and I've never experienced system instability due to it. So, I'd like to hear any comments anyone here has on the particulars of this system with gold simms. Also, I've thought long and hard about storage options, and while I'm a big fan of SCSI drives (All I use in my Linux/Intel system), I aint rich. Does anybody know if I could get away with a small scsi drive as the root partition and an IDE drive on an isa controller as the /usr partition? If I do end up using this machine as an MP3 stereo component, I'll want lots of local storage, and when I can get a 6.4gb ide drive for $145, that's pretty appealing when compared to $475 for a 4.3gb scsi drive (new atleast). As an aside, if anyone out there could tell me for sure if my Sun-branded Sony GDM-1662b really does require composite sync, it'd be nice to know before I start hacking away at an SGI to Sun video cable. (Same connector, violently different pin assignments) I ask because I know that not all Sun framebuffers use a composite sync, and while I know how to build the circuit to convert the individual sync signals to composite or sync-on-green, it'd be nice if I didn't have to. Anyway, thanks. - Eric From tsbogend@alpha.franken.de Fri Oct 2 00:18:20 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA00609; Fri, 2 Oct 1998 00:18:19 +0200 (MET DST) Received-Date: Fri, 2 Oct 1998 00:18:19 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA17843; Fri, 2 Oct 1998 00:18:16 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA04265; Fri, 2 Oct 1998 00:10:53 +0200 Message-ID: <19981002001053.41224@alpha.franken.de> Date: Fri, 2 Oct 1998 00:10:53 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: Wheee - Magnum 4000PC-50 almost on-line, I think. the hardware atleast . . References: <3612FE23.D9DDC93F@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <3612FE23.D9DDC93F@xmission.com>; from Eric Jorgensen on Wed, Sep 30, 1998 at 09:59:31PM -0600 Content-Length: 1535 Lines: 32 On Wed, Sep 30, 1998 at 09:59:31PM -0600, Eric Jorgensen wrote: > I was hoping that I could run this beast with a serial console, since > I'd like to eventually use it as a dedicated MP3 player. Or atleast > that's more or less what I'm figuring. some days ago I tried to boot my Olivetti M700 (Magnum clone) headless. And it worked after I've figured out, that the console used COM2 and not COM1 as serial console. You need also to install the configuration jumper (JP2 on my board) to get a chance to change ConsoleIn/ConsoleOut in the enviroment. That was the good news, now the bad one: While I have a working serial console with the Linux kernel, the mips boot loader (milo) isn't happy about the missing graphic card. My big plan is to avoid milo at all and boot the kernel straight from the console prom. But that's more a long term solution. I'll have a look at milo over the weekend, and hope to get fix for this problem. > rich. Does anybody know if I could get away with a small scsi drive as > the root partition and an IDE drive on an isa controller as the /usr > partition? If I do end up using this machine as an MP3 stereo component, I haven't tried it, but as a ISA controller does only PIO, it shouldn't be a big problem. Ralf had some IDE stuff working on Linux/MIPS (probably on his RM200, but I'm not sure). Thomas. -- See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>] From akonstantinov@yahoo.com Fri Oct 2 18:04:11 1998 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id SAA08015; Fri, 2 Oct 1998 18:04:06 +0200 (MET DST) Received-Date: Fri, 2 Oct 1998 18:04:06 +0200 (MET DST) Message-ID: <19981002160110.23487.rocketmail@send1e.yahoomail.com> Received: from [193.219.1.35] by send1e; Fri, 02 Oct 1998 09:01:10 PDT Date: Fri, 2 Oct 1998 09:01:10 -0700 (PDT) From: Aleksandr Konstantinov Subject: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 643 Lines: 18 Hello We have RM200 box with broken SINIX in it. We would like to try Linux. We tryed to load MILO through prom monitor but it don't recognize FAT (it's sinix firmware, we don't have sinix_to_nt) When trying to load from rawriten floppy it complains about bad DEV_BSIZE. When from SCSI disk partition (we have put Reliant on it temporarily) it says Magic Number is bad. Could You help us. Thanks in advance. Aleksandr Konstantinov _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From engel@math.uni-siegen.de Fri Oct 2 21:34:05 1998 Received: from fourier.numerik.math.uni-siegen.de (fourier.numerik.math.uni-siegen.de [141.99.2.230]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA09481; Fri, 2 Oct 1998 21:34:03 +0200 (MET DST) Received-Date: Fri, 2 Oct 1998 21:34:03 +0200 (MET DST) Received: (from engel@localhost) by fourier.numerik.math.uni-siegen.de (Mailhost) id VAA22570 for linux-mips@fnet.fr; Fri, 2 Oct 1998 21:34:25 +0200 (MET DST) From: Michael Engel Message-Id: <199810021934.VAA22570@fourier.numerik.math.uni-siegen.de> Subject: Re: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr Date: Fri, 2 Oct 1998 21:34:24 +0200 (MET DST) In-Reply-To: <19981002160110.23487.rocketmail@send1e.yahoomail.com> from "Aleksandr Konstantinov" at Oct 2, 98 09:01:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 731 Lines: 22 Hi, > We have RM200 box with broken SINIX in it. Just out of interest - is this a RM200 with ISA slots or the newer RM200C PCI-based machine ? > We would like to try Linux. We tryed to load MILO > through prom monitor but it don't recognize > FAT (it's sinix firmware, we don't have sinix_to_nt) That's (one of) the problem(s). The Sinix firmware runs in big endian mode whereas ARC runs in little endian mode. I'm not sure where to find SINIX_TO_NT, perhaps we could convince Siemens to release the firmware update images now that the RM200 seems to be discontinued. Btw., IIRC there may still be problems with Ralf's RM200 code - he'll surely comment on this. regards, Michael Engel (engel@numerik.math.uni-siegen.de) From ralf@uni-koblenz.de Sat Oct 3 18:14:47 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA17209; Sat, 3 Oct 1998 18:14:46 +0200 (MET DST) Received-Date: Sat, 3 Oct 1998 18:14:46 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (pmport-17.uni-koblenz.de [141.26.249.17]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id SAA10620 for ; Sat, 3 Oct 1998 18:14:41 +0200 (MET DST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id CAA00370; Sat, 3 Oct 1998 02:32:48 +0200 Message-ID: <19981003023248.A362@uni-koblenz.de> Date: Sat, 3 Oct 1998 02:32:48 +0200 To: Thomas Bogendoerfer , linux-mips@fnet.fr Subject: Re: Wheee - Magnum 4000PC-50 almost on-line, I think. the hardware atleast . . References: <3612FE23.D9DDC93F@xmission.com> <19981002001053.41224@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981002001053.41224@alpha.franken.de>; from Thomas Bogendoerfer on Fri, Oct 02, 1998 at 12:10:53AM +0200 Content-Length: 696 Lines: 15 On Fri, Oct 02, 1998 at 12:10:53AM +0200, Thomas Bogendoerfer wrote: > > rich. Does anybody know if I could get away with a small scsi drive as > > the root partition and an IDE drive on an isa controller as the /usr > > partition? If I do end up using this machine as an MP3 stereo component, > > I haven't tried it, but as a ISA controller does only PIO, it shouldn't be > a big problem. Ralf had some IDE stuff working on Linux/MIPS (probably on > his RM200, but I'm not sure). ISA IDE is trivial. None of these hostadapters use DMA afaik so all one has to do is to get interrupts and I/O ports working right and you're set. I had ISA IDE working in both the Acer PICA and RM200. Ralf From ralf@uni-koblenz.de Sat Oct 3 18:14:47 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA17210; Sat, 3 Oct 1998 18:14:46 +0200 (MET DST) Received-Date: Sat, 3 Oct 1998 18:14:46 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (pmport-17.uni-koblenz.de [141.26.249.17]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id SAA10596 for ; Sat, 3 Oct 1998 18:14:38 +0200 (MET DST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id CAA00413; Sat, 3 Oct 1998 02:46:24 +0200 Message-ID: <19981003024624.A407@uni-koblenz.de> Date: Sat, 3 Oct 1998 02:46:24 +0200 To: Thomas Bogendoerfer , linux-mips@fnet.fr Subject: Re: Wheee - Magnum 4000PC-50 almost on-line, I think. the hardware atleast . . References: <3612FE23.D9DDC93F@xmission.com> <19981002001053.41224@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981002001053.41224@alpha.franken.de>; from Thomas Bogendoerfer on Fri, Oct 02, 1998 at 12:10:53AM +0200 Content-Length: 598 Lines: 13 On Fri, Oct 02, 1998 at 12:10:53AM +0200, Thomas Bogendoerfer wrote: > some days ago I tried to boot my Olivetti M700 (Magnum clone) headless. > And it worked after I've figured out, that the console used COM2 and > not COM1 as serial console. You need also to install the configuration > jumper (JP2 on my board) to get a chance to change ConsoleIn/ConsoleOut > in the enviroment. Btw, your findings should be helpful to quite a number of guys which don't have graphics cards for the machine any longer. All we need is getting (E)ISA graphics cards to fly and they're back in business. Ralf From alhaz@xmission.com Sat Oct 3 18:45:10 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA17398; Sat, 3 Oct 1998 18:45:09 +0200 (MET DST) Received-Date: Sat, 3 Oct 1998 18:45:09 +0200 (MET DST) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zPUnk-00056S-00 for linux-mips@fnet.fr; Sat, 3 Oct 1998 10:45:01 -0600 Sender: alhaz@fnet.fr Message-ID: <361653EE.8F61043B@xmission.com> Date: Sat, 03 Oct 1998 10:42:22 -0600 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: Wheee - Magnum 4000PC-50 almost on-line, I think. the hardware atleast . . References: <3612FE23.D9DDC93F@xmission.com> <19981002001053.41224@alpha.franken.de> <19981003024624.A407@uni-koblenz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 826 Lines: 21 ralf@uni-koblenz.de wrote: > > On Fri, Oct 02, 1998 at 12:10:53AM +0200, Thomas Bogendoerfer wrote: > > > some days ago I tried to boot my Olivetti M700 (Magnum clone) headless. > > And it worked after I've figured out, that the console used COM2 and > > not COM1 as serial console. You need also to install the configuration > > jumper (JP2 on my board) to get a chance to change ConsoleIn/ConsoleOut > > in the enviroment. > > Btw, your findings should be helpful to quite a number of guys which don't > have graphics cards for the machine any longer. All we need is getting > (E)ISA graphics cards to fly and they're back in business. Yeah. I believe the Magnum graphics cards are still available from Carrera, but they cost well over $300. Certianly not worth it. I'll let you all know what I find out. - Eric From harald.koerfgen@netcologne.de Sat Oct 3 21:36:46 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA18423; Sat, 3 Oct 1998 21:36:44 +0200 (MET DST) Received-Date: Sat, 3 Oct 1998 21:36:44 +0200 (MET DST) Received: from franz.no.dom (dial5-78.netcologne.de [194.8.195.78]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA28561 for ; Sat, 3 Oct 1998 21:36:35 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 03 Oct 1998 21:38:00 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: DECstation-Linux is going single user! Content-Length: 2778 Lines: 101 Hello all, recently on a DECstation nearby: >>boot 1067296+113504+120800 Linux/MIPS DECstation Boot This DECStation is a DS5000/1xx with 49152kB RAM Got the following for the console env. variable: s Moving Kernel Image from 80200000 to 80030000 Launching Kernel ... Loading R[23]00 MMU routines. CPU revision is: 00000230 Instruction cache 64kb Data cache 128kb Linux version 2.1.121 (harry@franz) (gcc version 2.7.2) #38 Sat Oct 3 20:43:14 8 Calibrating delay loop... 32.90 BogoMIPS Memory: 47104k/49148k available (924k kernel code, 812k data) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 12.5 MHz (no parity) slot 0: DEC PMAZ-AA V5.3d slot 2: DEC PMAG-DA V5.3g Swansea University Computer Society NET3.039 for Linux 2.1 NET3: Unix domain sockets 0.16 for Linux NET3.038. Swansea University Computer Society TCP/IP for NET3.037 IP Protocols: ICMP, UDP, TCP Starting kswapd v 1.5 DECstation Z8530 serial driver version 0.03 tty00 at 0xbc100001 (irq = 3) is a Z85C30 SCC tty01 at 0xbc100009 (irq = 3) is a Z85C30 SCC tty02 at 0xbc180001 (irq = 3) is a Z85C30 SCC tty03 at 0xbc180009 (irq = 3) is a Z85C30 SCC RAM disk driver initialized: 16 RAM disks of 4096K size declance.c: v0.003 by Linux Mips DECstation task force Found a LANCE for eth0, with hw-address 08:00:2b:37:f0:99 RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 40k freed Stand-alone shell (version 1.0) > help alias [name [command]] cd [dirname] -chgrp gid filename ... -chmod mode filename ... -chown uid filename ... -cmp filename1 filename2 -cp srcname ... destname -dd if=name of=name [bs=n] [count=n] [skip=n] [seek=n] -echo [args] ... -ed [filename] exec filename [args] exit -grep [-in] word filename ... help -kill [-sig] pid ... -ln [-s] srcname ... destname -ls [-lid] filename ... -mkdir dirname ... -mknod filename type major minor -more filename ... -mount [-t type] devname dirname -mv srcname ... destname -printenv [name] prompt string -pwd quit -rm filename ... -rmdir dirname ... setenv name value source filename -sync -tar [xtv]f devname filename ... -touch filename ... umask [mask] -umount filename unalias name > -ls >. . bin dev etc lost+found mnt proc usr > Whopee! Unfortunately, it does so only on my DS5k/133. My DS5k/240 hangs after "Stan". Looks like my serial device driver still needs some polishing. Nevertheless, I found the bug which has been annoying me for weeks and the task queues are running now! I'll put the stuff on the net tomorrow. --- Regards, Harald From harald.koerfgen@netcologne.de Sun Oct 4 21:22:23 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA01221; Sun, 4 Oct 1998 21:22:17 +0200 (MET DST) Received-Date: Sun, 4 Oct 1998 21:22:17 +0200 (MET DST) Received: from franz.no.dom (dial5-107.netcologne.de [194.8.195.107]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA05463 for ; Sun, 4 Oct 1998 21:22:07 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 04 Oct 1998 21:23:21 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: DECstation-Linux is dead, long live Linux-R3000! Content-Length: 1870 Lines: 41 Hi all, while writing this I am uploading linux-2.1.121-r3000-pre1.tgz to ftp.linux.sgi.com/pub/test. Changes: o Merging with the latest and greatest Linux/MIPS source tree. o The DECstation people and the Baget people aren't alone anymore. This is phase 2 of the merging of Gleb's and Vladmir's and my code and includes all the Baget stuff. The subject says it all. o I have implemented a routine to write back the contents of the R3000's writeback buffer for the different DECstations. The spurious interrupts are gone! This may be very important for every device driver developer. o I fixed an ancient bug in the R3000 implementation of xchg() (took me quite some time to track this down :-(). This bug had the consequence that queued tasks were never executed. This might explain a few oddities we have experienced in the past, which includes the strange freeze with my hello world program and Florian Lohoff's problems with down(&sem). Florian, you may want to try your PMAZ-AA driver with 2.1.121. Gleb and Vladimir, the bottom_halves are working now! o With the above changes my DS5000/133 goes single user! (Unfortunately my DS5000/240 does not, the serial device driver still needs some polishing :-(). Feedbacks from other machines are welcome. I called this source tree pre1 because IMHO we have a candidate here which might be checked into the main Linux/MIPS repository, but I'd like to have a few things worked out and cleaned up before considering this honestly (and Ralf has to give his okay, obviously). BTW, I have changed linux-2.1.121-r3000 so that it still can be compiled with gcc-2.7.2. The original Linux/MIPS-2.1.121 has been changed to be compiled with ecgs-1.0.2. I'll investigate using the ecgs comiler because I think that this will become the official Linux/MIPS compiler. Ralf, any comments on that? Have fun. --- Regards, Harald From ralf@uni-koblenz.de Mon Oct 5 01:04:03 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA03619; Mon, 5 Oct 1998 01:04:02 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 01:04:02 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (pmport-14.uni-koblenz.de [141.26.249.14]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id BAA12054 for ; Mon, 5 Oct 1998 01:03:59 +0200 (MET DST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id BAA01070; Mon, 5 Oct 1998 01:03:46 +0200 Message-ID: <19981005010346.H409@uni-koblenz.de> Date: Mon, 5 Oct 1998 01:03:46 +0200 To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Death of Milo Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 295 Lines: 9 Hi all, Thomas and me have finally decided to put in the bit of work to kill Milo. When we're done with that all ARC platforms, be they SGI or little endian, will use the same code which will basically be what we're using now for the Indy plus a couple of megatons of ARC workarounds. Ralf From akonstantinov@yahoo.com Mon Oct 5 14:11:36 1998 Received: from send102.yahoomail.com (send102.yahoomail.com [205.180.60.90]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id OAA10956; Mon, 5 Oct 1998 14:11:32 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 14:11:32 +0200 (MET DST) Message-ID: <19981005121145.6203.rocketmail@send102.yahoomail.com> Received: from [193.219.1.35] by send102.yahoomail.com; Mon, 05 Oct 1998 05:11:45 PDT Date: Mon, 5 Oct 1998 05:11:45 -0700 (PDT) From: Aleksandr Konstantinov Subject: Re: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 1331 Lines: 43 ---Michael Engel wrote: > > > Hi, Thank for answer Michael. > > > We have RM200 box with broken SINIX in it. > > Just out of interest - is this a RM200 with ISA slots or the newer > RM200C PCI-based machine ? It is old ISA machine. > > > We would like to try Linux. We tryed to load MILO > > through prom monitor but it don't recognize > > FAT (it's sinix firmware, we don't have > > sinix_to_nt) > > That's (one of) the problem(s). The Sinix firmware runs in big endian mode > whereas ARC runs in little endian mode. I'm not sure >where to find > SINIX_TO_NT, perhaps we could convince Siemens to > release the firmware > update images now that the RM200 seems to be > discontinued. And what are other problems? Maybe someone having RM200 could share sinix_to_nt (is it possible or it should be unique? ) > > Btw., IIRC there may still be problems with Ralf's > RM200 code - he'll surely > comment on this. Ralf, could You,please, tell Your word ? Is it possible to run Linux on old ISA RM200 ? > > regards, > Michael Engel (engel@numerik.math.uni-siegen.de) > Aleksandr Konstantinov _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From engel@math.uni-siegen.de Mon Oct 5 14:26:48 1998 Received: from fourier.numerik.math.uni-siegen.de (fourier.numerik.math.uni-siegen.de [141.99.2.230]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA11097; Mon, 5 Oct 1998 14:26:46 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 14:26:46 +0200 (MET DST) Received: (from engel@localhost) by fourier.numerik.math.uni-siegen.de (Mailhost) id OAA27979 for linux-mips@fnet.fr; Mon, 5 Oct 1998 14:27:06 +0200 (MET DST) From: Michael Engel Message-Id: <199810051227.OAA27979@fourier.numerik.math.uni-siegen.de> Subject: Re: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr Date: Mon, 5 Oct 1998 14:27:05 +0200 (MET DST) In-Reply-To: <19981005121145.6203.rocketmail@send102.yahoomail.com> from "Aleksandr Konstantinov" at Oct 5, 98 05:11:45 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1486 Lines: 40 Hi, > ---Michael Engel wrote: > Thank for answer Michael. You're welcome ... > > > We have RM200 box with broken SINIX in it. > > Just out of interest - is this a RM200 with ISA slots or the newer > > RM200C PCI-based machine ? > It is old ISA machine. OK ... Ralf has the newer PCI-based RM200C, I own three of the older ISA/ VLB based systems. I managed to get Linux running on a RM200 ISA - currently with an IDE controller and NE2000 ethernet in the two ISA slots. I'm still working on getting the onboard NCR53C710 SCSI and intel 82586 ethernet to run. The port is still not quite usable, I'm afraid ... [...] > And what are other problems? Mostly lack of support for onboard SCSI and ethernet so far. I also experienced file system corruption with Linux 2.1.99 on my RM200 but this may also be related to the old IDE disk I am using ... > Maybe someone having RM200 could share sinix_to_nt > (is it possible or it should be unique? ) Sorry, I don't have it :-(. I currently have three RM200s here - two with ARC/NT firmware and one with the big endian SINIX firmware. The SINIX machine has one of these Quantum 1 GB hard disks with stiction problem, so I can't get SINIX to boot reliably :-(. Over the weekend I started to hack on a standalone fdisk/mke2fs tool for the RM200 based on MILO sources. As Ralf and Thomas decided that MILO is dead now I'm interested what the new bootloader will look like ... regards, Michael From R.vandenBerg@inter.NL.net Mon Oct 5 21:48:46 1998 Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA15437; Mon, 5 Oct 1998 21:48:45 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 21:48:45 +0200 (MET DST) Received: from dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-16.Hoorn.NL.net [193.79.46.180] with ESMTP for id VAA13079 (8.8.8/3.28); Mon, 5 Oct 1998 21:48:43 +0200 (MET DST) Received: from whale.dutch.mountain(really [192.168.1.1]) by dutch.mountain via in.smtpd with smtp id for ; Mon, 5 Oct 1998 21:45:51 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Mon, 5 Oct 1998 21:45:50 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: DECstation-Linux is dead, long live Linux-R3000! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1430 Lines: 34 Hello Harald and all other DEC fans, On Sun, 4 Oct 1998, Harald Koerfgen wrote: [...] > o With the above changes my DS5000/133 goes single user! (Unfortunately my > DS5000/240 does not, the serial device driver still needs some polishing :-(). > Feedbacks from other machines are welcome. Guess which machines. :-) It seems that the DS5k/133 here has some serial hardware trouble. :-( It has shown sash, but not the kernel booting. Setting the console enviroment variable to s doesn't move the prom-console to the terminal. To get the console back I had to exercise the trick with the nvr jumper. Booting with prom-console support build in the kernel-messages show up but it goes slower then an old XT. On the other hand the MAXine behaves more decent till it says "Freeing unused kernel memory" at the prom-console at usual speed with support for it compiled in and on the serial console. It shows all the kernel goodies at the serial console real fast. It does it without specifying console=ttyS0, specifying it goes allright too, specifying an other tty, it shows till "Launching Kernel ..." BTW, does somebody out there knows the right settings to make minicom behave like a terminal, I haven't succeeded yet, clearing out all init strings and setting the right communication parameters of course (9600, 8n1) it says online, but no contact with the DEC. Regards, Richard P.S. I'm of for a week DECstation less, ttyl. From tsbogend@alpha.franken.de Mon Oct 5 23:34:43 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA17602; Mon, 5 Oct 1998 23:34:42 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 23:34:42 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id XAA15153; Mon, 5 Oct 1998 23:34:40 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id VAA02431; Mon, 5 Oct 1998 21:51:05 +0200 Message-ID: <19981005215104.34902@alpha.franken.de> Date: Mon, 5 Oct 1998 21:51:04 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: Unsuccesful trying to run Linux on RM200 References: <19981005121145.6203.rocketmail@send102.yahoomail.com> <199810051227.OAA27979@fourier.numerik.math.uni-siegen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <199810051227.OAA27979@fourier.numerik.math.uni-siegen.de>; from Michael Engel on Mon, Oct 05, 1998 at 02:27:05PM +0200 Content-Length: 824 Lines: 18 On Mon, Oct 05, 1998 at 02:27:05PM +0200, Michael Engel wrote: > Over the weekend I started to hack on a standalone fdisk/mke2fs tool for > the RM200 based on MILO sources. As Ralf and Thomas decided that MILO is > dead now I'm interested what the new bootloader will look like ... :-)) We don't need an extra bootloader. With only minor hacks I got a kernel for my Olli, which boots directly from the ARC firmware. The only problem, which we probably have to face, are ARC firmware bugs. For example the RM200 loads executables off by 4 bytes to memory:-( But that's IMHO a small price for not having to maintain milo. Thomas. -- See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>] From ralf@uni-koblenz.de Mon Oct 5 22:48:59 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA17289; Mon, 5 Oct 1998 22:48:57 +0200 (MET DST) Received-Date: Mon, 5 Oct 1998 22:48:57 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from zaphod (zaphod.uni-koblenz.de [141.26.4.13]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with SMTP id WAA08489; Mon, 5 Oct 1998 22:48:50 +0200 (MET DST) Received: by zaphod (SMI-8.6/KO-2.0) id WAA01505; Mon, 5 Oct 1998 22:48:53 +0200 Message-ID: <19981005224853.52553@uni-koblenz.de> Date: Mon, 5 Oct 1998 22:48:53 +0200 To: Michael Engel Cc: linux-mips@fnet.fr Subject: Re: Unsuccesful trying to run Linux on RM200 References: <19981005121145.6203.rocketmail@send102.yahoomail.com> <199810051227.OAA27979@fourier.numerik.math.uni-siegen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199810051227.OAA27979@fourier.numerik.math.uni-siegen.de>; from Michael Engel on Mon, Oct 05, 1998 at 02:27:05PM +0200 Content-Length: 423 Lines: 10 On Mon, Oct 05, 1998 at 02:27:05PM +0200, Michael Engel wrote: > Over the weekend I started to hack on a standalone fdisk/mke2fs tool for > the RM200 based on MILO sources. As Ralf and Thomas decided that MILO is > dead now I'm interested what the new bootloader will look like ... Exactly as on the Indy. Just run the kernel executable directly from the command line. In fact we'll use alot of the Indy code. Ralf From engel@math.uni-siegen.de Tue Oct 6 00:09:34 1998 Received: from fourier.numerik.math.uni-siegen.de (fourier.numerik.math.uni-siegen.de [141.99.2.230]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA18405; Tue, 6 Oct 1998 00:09:33 +0200 (MET DST) Received-Date: Tue, 6 Oct 1998 00:09:33 +0200 (MET DST) Received: (from engel@localhost) by fourier.numerik.math.uni-siegen.de (Mailhost) id AAA29436 for linux-mips@fnet.fr; Tue, 6 Oct 1998 00:09:59 +0200 (MET DST) From: Michael Engel Message-Id: <199810052209.AAA29436@fourier.numerik.math.uni-siegen.de> Subject: Re: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr Date: Tue, 6 Oct 1998 00:09:58 +0200 (MET DST) In-Reply-To: <19981005215104.34902@alpha.franken.de> from "Thomas Bogendoerfer" at Oct 5, 98 09:51:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 826 Lines: 20 > On Mon, Oct 05, 1998 at 02:27:05PM +0200, Michael Engel wrote: > > Over the weekend I started to hack on a standalone fdisk/mke2fs tool for > > the RM200 based on MILO sources. As Ralf and Thomas decided that MILO is > > dead now I'm interested what the new bootloader will look like ... > > :-)) We don't need an extra bootloader. With only minor hacks I got a > kernel for my Olli, which boots directly from the ARC firmware. Well, that's nice ! ;-) > The only problem, which we probably have to face, are ARC firmware bugs. > For example the RM200 loads executables off by 4 bytes to memory:-( But > that's IMHO a small price for not having to maintain milo. Yep. One could also try to build a kernel for the big-endian SINIX firmware on the RM200, perhaps the SINIX firmware has less bugs ... regards, Michael From tsbogend@alpha.franken.de Tue Oct 6 01:22:19 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA19990; Tue, 6 Oct 1998 01:22:19 +0200 (MET DST) Received-Date: Tue, 6 Oct 1998 01:22:19 +0200 (MET DST) Received: from alpha.franken.de (tsbogend@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id BAA16169; Tue, 6 Oct 1998 01:22:17 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id BAA04523; Tue, 6 Oct 1998 01:19:51 +0200 Message-ID: <19981006011950.09261@alpha.franken.de> Date: Tue, 6 Oct 1998 01:19:50 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: Unsuccesful trying to run Linux on RM200 References: <19981005215104.34902@alpha.franken.de> <199810052209.AAA29436@fourier.numerik.math.uni-siegen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <199810052209.AAA29436@fourier.numerik.math.uni-siegen.de>; from Michael Engel on Tue, Oct 06, 1998 at 12:09:58AM +0200 Content-Length: 500 Lines: 13 On Tue, Oct 06, 1998 at 12:09:58AM +0200, Michael Engel wrote: > Yep. One could also try to build a kernel for the big-endian SINIX firmware > on the RM200, perhaps the SINIX firmware has less bugs ... I wouldn't bet, but feel free to do it:-) Is the SINIX firmware also ARC or a different beast ? Thomas. -- See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>] From resident@orc.ru Tue Oct 6 12:44:39 1998 Received: from katja.nc.orc.ru (katja.nc.orc.ru [212.48.128.154]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA27810; Tue, 6 Oct 1998 12:44:37 +0200 (MET DST) Received-Date: Tue, 6 Oct 1998 12:44:37 +0200 (MET DST) Received: from orc.ru (localhost [127.0.0.1]) by katja.nc.orc.ru (8.8.7/8.8.7) with ESMTP id OAA00682 for ; Tue, 6 Oct 1998 14:44:48 +0400 Sender: wrath@katja.nc.orc.ru Message-ID: <3619F49C.FA684703@orc.ru> Date: Tue, 06 Oct 1998 14:44:45 +0400 From: Dmitry Morozov Organization: ORC X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.123 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Linux for old MIPSes Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 293 Lines: 11 Hello! I have very old MIPS 2030 box. Just for fun I would like to run a Linux on it. In you HOW-TO you refer to some people who have the similar boxes and similar problems hence. Can you help me some way? I would appreciate an email addresses of that people or any hints. Thank you. Bye! From tsbogend@alpha.franken.de Wed Oct 7 00:28:40 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA04078; Wed, 7 Oct 1998 00:28:39 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 00:28:39 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA25811; Wed, 7 Oct 1998 00:28:36 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA02634; Wed, 7 Oct 1998 00:25:48 +0200 Message-ID: <19981007002547.44731@alpha.franken.de> Date: Wed, 7 Oct 1998 00:25:47 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Tags are dead alias Milo is dead part II Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 Content-Length: 858 Lines: 19 In the process of making Milo obsolete I've also removed tags stuff. This was simple for the Indy and took only a few hours for the Olivetti. I hope it's also possible for the Decstation. Before I'll start commiting the changes we should make sure, how to solve the missing tags for all plattforms. Another old code, which might be obsolete now is the wired entry stuff in arch/mips/kernel/head.S. It's already disabled for R4k CPUs and I would prefer to remove that stuff also for the other CPUs. If you need wired entries, I would propose using the add_wired_entry() function as I already do it for the JAZZ hardware (arch/mips/jazz/setup.c). Comments ? Thomas. -- See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>] From roganov@niisi.msk.ru Wed Oct 7 14:20:47 1998 Received: from mail2.ras.ru (root@phobos.ras.ru [193.124.148.76]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA11268; Wed, 7 Oct 1998 14:20:24 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 14:20:24 +0200 (MET DST) Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by mail2.ras.ru (8.9.1/8.9.1) with ESMTP id OAA24826 for ; Wed, 7 Oct 1998 14:53:58 +0300 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA15928 for ; Wed, 7 Oct 1998 15:50:06 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA19872 for linux-mips@fnet.fr; Wed, 7 Oct 1998 14:56:18 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA15646 for ; Wed, 7 Oct 1998 15:47:19 +0300 (MSK) Sender: vladimir@niisi.msk.ru Message-ID: <361B55A5.3FF2F228@niisi.msk.ru> Date: Wed, 07 Oct 1998 15:51:01 +0400 From: Vladimir Roganov Organization: NIISI RAS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Linux support for R3000-series computers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 19758 Lines: 793 This message is addressed to developers who is working on Linux support for R3000-series computers. It contains some reliability/performance test results, obtained for BAGET (BE R3000A/25MHz) embedded computer, running under kernels 2.1.116/2.1.121 and HardHat (RedHat 5.1) NFS-ROOT installation. This information may be actual due regular support for R3000 is just added, and few processor-specific routines is under development. o Linux on BAGET reliability: We need to have stable Linux kernel, so we are testing it under various conditions. We found a good test for basis system reliability: to configure and build GDB (from sources downloaded from vger cvs). Fortunately, after some investigations, we reach desirable result: Linux do it from first attempt, what takes about 1.5 hours. (but to reach it we have changed our RAM module with bugs :-). Most important increasement of reliability we obtained commenting (new) TLB-related code (define TOTAL_TLB_FLUSH in attached r2300.c), and redesign cache invalidation code (see following topic. We will happy to receive any comments about it). We are peace about TLB-flush/ASID logic -- it possibly just not debugged enough, and will be fixed too. But yet another thing is more interesting: when we define NO_TLB_OPTIMIZE in r2300_misc.S: we received kernel page fault: 'unix_gc' function uses VMALLOC, which reserves addresses in KSEG2, but 'do_page_fault' function mean it is not right. It is very interesting for us, due we want to use VMALLOC-like mechanism to map KSEG2 area to our lance network adapter memory to avoid Baget-specific options in r2300_misc.S (that is, to have something like sparc_alloc_io). If anybody have ideas how to do it in current Linux structure, please inform us. o Cache code improvement suggestions: We spend many hours measuring BAGET performance and found that cache code speedup is very desirable. One more reason for cache code revision: we found that few cache invalidation functions really accept virtual addresses instead physical. After few revisions we lead to following structure: 1) To avoid code duplication struct 'cache_space' is used for both I & D cache spaces. Initialization of these structures is done at functions 'probe_?cache', calling 'cache_size'. It is so called initialization level. 2) Low-level functions for cache spaces invalidation are called 'flush_cache_space_page' and 'flush_cache_space_all'. First accepts 'cache_space' structure, performs some checks and flushes physical cache page as fast as possible. Second function just uses above to flush needed quantity of KSEG0 pages. To translate address to physical page 'get_phys_page' function is used. It carefully checks segments and returns 0 or page real memory address. We have red D.Miller article about Linux cache flush architecture, where noticed what DMA/Drivers dcache cache coherency should be implemented at driver layer. So we are now avoiding dcache invalidation, and introduce DO_DCACHE_FLUSH flag if somebody need to flush dcache here. 3) All exported 'r2300_*' functions obtain physical page(s) and flushes one(s). Few top-level optimizations are commented in a source code. Please find below our current revision of arch/mips/mm/r2300.c for comments: <<<<<<<<<<<<<<<<< /* * r2300.c: R2000 and R3000 specific mmu/cache code. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * * with a lot of changes to make this thing work for R3000s * Copyright (C) 1998 Harald Koerfgen * Copyright (C) 1998 Gleb Raiko & Vladimir Roganov * * $Id: r2300.c,v 1.2 1998/10/07 08:56:29 vladimir Exp $ */ #include #include #include #include #include #include #include #include #include #include #define TOTAL_TLB_FLUSH /* For tests: to avoid ASID logic */ /* * According to the paper written by D. Miller about Linux cache & TLB * flush implementation, DMA/Driver coherence should be done at the * driver layer. Thus, normally, we don't need flush dcache for R3000. * Define this if driver does not handle cache consistency during DMA ops. */ #undef DO_DCACHE_FLUSH /* * Unified cache space description structure */ static struct cache_space { unsigned long ca_flags; /* Cache space access flags */ int size; /* Cache space size */ } icache, dcache; #undef DEBUG_TLB #undef DEBUG_CACHE extern unsigned long mips_tlb_entries; #define NTLB_ENTRIES 64 /* Fixed on all R23000 variants... */ /* page functions */ void r2300_clear_page(unsigned long page) { __asm__ __volatile__( ".set\tnoreorder\n\t" ".set\tnoat\n\t" "addiu\t$1,%0,%2\n" "1:\tsw\t$0,(%0)\n\t" "sw\t$0,4(%0)\n\t" "sw\t$0,8(%0)\n\t" "sw\t$0,12(%0)\n\t" "addiu\t%0,32\n\t" "sw\t$0,-16(%0)\n\t" "sw\t$0,-12(%0)\n\t" "sw\t$0,-8(%0)\n\t" "bne\t$1,%0,1b\n\t" "sw\t$0,-4(%0)\n\t" ".set\tat\n\t" ".set\treorder" :"=r" (page) :"0" (page), "I" (PAGE_SIZE) :"$1","memory"); } static void r2300_copy_page(unsigned long to, unsigned long from) { unsigned long dummy1, dummy2; unsigned long reg1, reg2, reg3, reg4; __asm__ __volatile__( ".set\tnoreorder\n\t" ".set\tnoat\n\t" "addiu\t$1,%0,%8\n" "1:\tlw\t%2,(%1)\n\t" "lw\t%3,4(%1)\n\t" "lw\t%4,8(%1)\n\t" "lw\t%5,12(%1)\n\t" "sw\t%2,(%0)\n\t" "sw\t%3,4(%0)\n\t" "sw\t%4,8(%0)\n\t" "sw\t%5,12(%0)\n\t" "lw\t%2,16(%1)\n\t" "lw\t%3,20(%1)\n\t" "lw\t%4,24(%1)\n\t" "lw\t%5,28(%1)\n\t" "sw\t%2,16(%0)\n\t" "sw\t%3,20(%0)\n\t" "sw\t%4,24(%0)\n\t" "sw\t%5,28(%0)\n\t" "addiu\t%0,64\n\t" "addiu\t%1,64\n\t" "lw\t%2,-32(%1)\n\t" "lw\t%3,-28(%1)\n\t" "lw\t%4,-24(%1)\n\t" "lw\t%5,-20(%1)\n\t" "sw\t%2,-32(%0)\n\t" "sw\t%3,-28(%0)\n\t" "sw\t%4,-24(%0)\n\t" "sw\t%5,-20(%0)\n\t" "lw\t%2,-16(%1)\n\t" "lw\t%3,-12(%1)\n\t" "lw\t%4,-8(%1)\n\t" "lw\t%5,-4(%1)\n\t" "sw\t%2,-16(%0)\n\t" "sw\t%3,-12(%0)\n\t" "sw\t%4,-8(%0)\n\t" "bne\t$1,%0,1b\n\t" "sw\t%5,-4(%0)\n\t" ".set\tat\n\t" ".set\treorder" :"=r" (dummy1), "=r" (dummy2), "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) :"0" (to), "1" (from), "I" (PAGE_SIZE)); } __initfunc(static unsigned long size_cache(unsigned long ca_flags)) { unsigned long flags, status, dummy, size; volatile unsigned long *p; p = (volatile unsigned long *) KSEG0; save_and_cli(flags); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, ca_flags); *p = 0xa5a55a5a; dummy = *p; status = read_32bit_cp0_register(CP0_STATUS); if (dummy != 0xa5a55a5a || (status & (1<<19))) { size = 0; } else { for (size = 512; size <= 0x40000; size <<= 1) *(p + size) = 0; *p = -1; for (size = 512; (size <= 0x40000) && (*(p + size) == 0); size <<= 1) ; if (size > 0x40000) size = 0; } restore_flags(flags); return size * sizeof(*p); } __initfunc(static void probe_dcache(void)) { dcache.size = size_cache(dcache.ca_flags = ST0_DE); printk("Data cache %dkb\n", dcache.size >> 10); } __initfunc(static void probe_icache(void)) { icache.size = size_cache(icache.ca_flags = ST0_DE|ST0_CE); printk("Instruction cache %dkb\n", icache.size >> 10); } static inline unsigned long get_phys_page (unsigned long page, struct mm_struct *mm) { page &= PAGE_MASK; if (page >= KSEG0 && page < KSEG1) { /* * We already have physical address */ return page; } else { if (!mm) { printk ("get_phys_page: vaddr without mm\n"); return 0; } else { /* * Find a physical page using mm_struct */ pgd_t *page_dir; pmd_t *page_middle; pte_t *page_table, pte; unsigned long address = page; page_dir = pgd_offset(mm, address); if (pgd_none(*page_dir)) return 0; page_middle = pmd_offset(page_dir, address); if (pmd_none(*page_middle)) return 0; page_table = pte_offset(page_middle, address); pte = *page_table; if (!pte_present(pte)) return 0; return pte_page(pte); } } } static inline void flush_cache_space_page(struct cache_space *space, unsigned long page) { register unsigned long i, flags, size = space->size; register volatile unsigned char *p = (volatile unsigned char*) page; #ifndef DO_DCACHE_FLUSH if (space == &dcache) return; #endif if (size > PAGE_SIZE) size = PAGE_SIZE; save_and_cli(flags); /* isolate cache space */ write_32bit_cp0_register(CP0_STATUS, space->ca_flags); for (i = 0; i < size; i += 64) { asm ( "sb\t$0,(%0)\n\t" "sb\t$0,4(%0)\n\t" "sb\t$0,8(%0)\n\t" "sb\t$0,12(%0)\n\t" "sb\t$0,16(%0)\n\t" "sb\t$0,20(%0)\n\t" "sb\t$0,24(%0)\n\t" "sb\t$0,28(%0)\n\t" "sb\t$0,32(%0)\n\t" "sb\t$0,36(%0)\n\t" "sb\t$0,40(%0)\n\t" "sb\t$0,44(%0)\n\t" "sb\t$0,48(%0)\n\t" "sb\t$0,52(%0)\n\t" "sb\t$0,56(%0)\n\t" "sb\t$0,60(%0)\n\t" : : "r" (p) ); p += 64; } restore_flags(flags); } static inline void flush_cache_space_all(struct cache_space *space) { unsigned long page = KSEG0; int size = space->size; #ifndef DO_DCACHE_FLUSH if (space == &dcache) return; #endif while(size > 0) { flush_cache_space_page(space, page); page += PAGE_SIZE; size -= PAGE_SIZE; } } static inline void r2300_flush_cache_all(void) { flush_cache_space_all(&dcache); flush_cache_space_all(&icache); } static void r2300_flush_cache_mm(struct mm_struct *mm) { if(mm->context == 0) return; #ifdef DEBUG_CACHE printk("cmm[%d]", (int)mm->context); #endif /* * This function is called not offen, so it looks * enough good to flush all caches than scan mm_struct, * count pages to flush (and, very probably, flush more * than cache space size :-) */ flush_cache_all(); } static void r2300_flush_cache_range(struct mm_struct *mm, unsigned long start, unsigned long end) { /* * In general, we need to flush both i- & d- caches here. * Optimization: if cache space is less than given range, * it is more quickly to flush all cache than all pages in range. */ unsigned long page; int icache_done = 0, dcache_done = 0; if(mm->context == 0) return; #ifdef DEBUG_CACHE printk("crange[%d]", (int)mm->context); #endif if (end - start >= icache.size) { flush_cache_space_all(&icache); icache_done = 1; } if (end - start >= dcache.size) { flush_cache_space_all(&dcache); dcache_done = 1; } if (icache_done && dcache_done) return; for (page = start; page < end; page += PAGE_SIZE) { unsigned long phys_page = get_phys_page(page, mm); if (phys_page) { if (!icache_done) flush_cache_space_page(&icache, phys_page); if (!dcache_done) flush_cache_space_page(&dcache, phys_page); } } } static void r2300_flush_cache_page(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm = vma->vm_mm; if(mm->context == 0) return; #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif /* * User changes page, so we need to check: * is icache page flush needed ? * It looks we don't need to flush dcache, * due it is write-transparent on R3000 */ if (vma->vm_flags & VM_EXEC) { unsigned long phys_page = get_phys_page(page, vma->vm_mm); if (phys_page) flush_cache_space_page(&icache, phys_page); } } static void r2300_flush_page_to_ram(unsigned long page) { /* * We need to flush both i- & d- caches :-( */ unsigned long phys_page = get_phys_page(page, NULL); #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif if (phys_page) { flush_cache_space_page(&icache, phys_page); flush_cache_space_page(&dcache, phys_page); } } static void r2300_flush_cache_sigtramp(unsigned long page) { /* * We need only flush i-cache here * * This function receives virtual address (from signal.c), * but this moment we have needed mm_struct in 'current' */ unsigned long phys_page = get_phys_page(page, current->mm); #ifdef DEBUG_CACHE printk("csigtramp[%08lx]", page); #endif if (phys_page) flush_cache_space_page(&icache, phys_page); } /* TLB operations. */ static inline void r2300_flush_tlb_all(void) { unsigned long flags; unsigned long old_ctx; int entry; #ifdef DEBUG_TLB printk("[tlball]"); #endif save_and_cli(flags); old_ctx = (get_entryhi() & ASID_MASK); write_32bit_cp0_register(CP0_ENTRYLO0, 0); for(entry = 0; entry < mips_tlb_entries; entry++) { write_32bit_cp0_register(CP0_INDEX, entry << 8); write_32bit_cp0_register(CP0_ENTRYHI, ((entry | 0x80000) << 12)); __asm__ __volatile__("tlbwi"); } set_entryhi(old_ctx); restore_flags(flags); } static void r2300_flush_tlb_mm(struct mm_struct *mm) { #ifndef TOTAL_TLB_FLUSH if(mm->context != 0) { unsigned long flags; #ifdef DEBUG_TLB printk("[tlbmm<%d>]", mm->context); #endif save_and_cli(flags); get_new_mmu_context(mm, asid_cache); if(mm == current->mm) set_entryhi(mm->context & ASID_MASK); restore_flags(flags); } #else flush_tlb_all(); #endif } static void r2300_flush_tlb_range(struct mm_struct *mm, unsigned long start, unsigned long end) { #ifndef TOTAL_TLB_FLUSH if(mm->context != 0) { unsigned long flags; int size; #ifdef DEBUG_TLB printk("[tlbrange<%02x,%08lx,%08lx>]", (mm->context & ASID_MASK), start, end); #endif save_and_cli(flags); size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT; if(size <= NTLB_ENTRIES) { int oldpid = (get_entryhi() & ASID_MASK); int newpid = (mm->context & ASID_MASK); start &= PAGE_MASK; end += (PAGE_SIZE - 1); end &= PAGE_MASK; while(start < end) { int idx; set_entryhi(start | newpid); start += PAGE_SIZE; tlb_probe(); idx = get_index(); set_entrylo0(0); set_entryhi(KSEG0); if(idx < 0) continue; tlb_write_indexed(); } set_entryhi(oldpid); } else { get_new_mmu_context(mm, asid_cache); if(mm == current->mm) set_entryhi(mm->context & ASID_MASK); } restore_flags(flags); } #else flush_tlb_all(); #endif } static void r2300_flush_tlb_page(struct vm_area_struct *vma, unsigned long page) { #ifndef TOTAL_TLB_FLUSH if(vma->vm_mm->context != 0) { unsigned long flags; int oldpid, newpid, idx; #ifdef DEBUG_TLB printk("[tlbpage<%d,%08lx>]", vma->vm_mm->context, page); #endif newpid = (vma->vm_mm->context & ASID_MASK); page &= PAGE_MASK; save_and_cli(flags); oldpid = (get_entryhi() & ASID_MASK); set_entryhi(page | newpid); tlb_probe(); idx = get_index(); set_entrylo0(0); set_entryhi(KSEG0); if(idx < 0) goto finish; tlb_write_indexed(); finish: set_entryhi(oldpid); restore_flags(flags); } #else flush_tlb_all(); #endif } /* Load a new root pointer into the TLB. */ static void r2300_load_pgd(unsigned long pg_dir) { #ifdef TOTAL_TLB_FLUSH flush_tlb_all(); #endif } /* * Initialize new page directory with pointers to invalid ptes */ static void r2300_pgd_init(unsigned long page) { unsigned long dummy1, dummy2; /* * The plain and boring version for the R3000. No cache flushing * stuff is implemented since the R3000 has physical caches. */ __asm__ __volatile__( ".set\tnoreorder\n" "1:\tsw\t%2,(%0)\n\t" "sw\t%2,4(%0)\n\t" "sw\t%2,8(%0)\n\t" "sw\t%2,12(%0)\n\t" "sw\t%2,16(%0)\n\t" "sw\t%2,20(%0)\n\t" "sw\t%2,24(%0)\n\t" "sw\t%2,28(%0)\n\t" "subu\t%1,1\n\t" "bnez\t%1,1b\n\t" "addiu\t%0,32\n\t" ".set\treorder" :"=r" (dummy1), "=r" (dummy2) :"r" ((unsigned long) invalid_pte_table), "0" (page), "1" (PAGE_SIZE/(sizeof(pmd_t)*8))); #ifdef TOTAL_TLB_FLUSH flush_tlb_all(); #endif } static void r2300_update_mmu_cache(struct vm_area_struct * vma, unsigned long address, pte_t pte) { #ifndef TOTAL_TLB_FLUSH unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; int idx, pid; pid = (get_entryhi() & ASID_MASK); #ifdef DEBUG_TLB if((pid != (vma->vm_mm->context & ASID_MASK)) || (vma->vm_mm->context == 0)) { printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d tlbpid=%d\n", (int) (vma->vm_mm->context & ASID_MASK), pid); } #endif save_and_cli(flags); address &= PAGE_MASK; set_entryhi(address | (pid)); pgdp = pgd_offset(vma->vm_mm, address); tlb_probe(); pmdp = pmd_offset(pgdp, address); idx = get_index(); ptep = pte_offset(pmdp, address); set_entrylo0(pte_val(*ptep)); set_entryhi(address | (pid)); if(idx < 0) { tlb_write_random(); #if 0 printk("[MISS]"); #endif } else { tlb_write_indexed(); #if 0 printk("[HIT]"); #endif } #if 0 if(!strcmp(current->comm, "args")) { printk("<"); for(idx = 0; idx < NTLB_ENTRIES; idx++) { set_index(idx); tlb_read(); address = get_entryhi(); if((address & ASID_MASK) != 0) printk("[%08lx]", address); } printk(">\n"); } #endif set_entryhi(pid); restore_flags(flags); #else flush_tlb_all(); #endif } static void r2300_show_regs(struct pt_regs * regs) { /* * Saved main processor registers */ printk("$0 : %08x %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", 0, (unsigned long) regs->regs[1], (unsigned long) regs->regs[2], (unsigned long) regs->regs[3], (unsigned long) regs->regs[4], (unsigned long) regs->regs[5], (unsigned long) regs->regs[6], (unsigned long) regs->regs[7]); printk("$8 : %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", (unsigned long) regs->regs[8], (unsigned long) regs->regs[9], (unsigned long) regs->regs[10], (unsigned long) regs->regs[11], (unsigned long) regs->regs[12], (unsigned long) regs->regs[13], (unsigned long) regs->regs[14], (unsigned long) regs->regs[15]); printk("$16: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", (unsigned long) regs->regs[16], (unsigned long) regs->regs[17], (unsigned long) regs->regs[18], (unsigned long) regs->regs[19], (unsigned long) regs->regs[20], (unsigned long) regs->regs[21], (unsigned long) regs->regs[22], (unsigned long) regs->regs[23]); printk("$24: %08lx %08lx %08lx %08lx %08lx %08lx\n", (unsigned long) regs->regs[24], (unsigned long) regs->regs[25], (unsigned long) regs->regs[28], (unsigned long) regs->regs[29], (unsigned long) regs->regs[30], (unsigned long) regs->regs[31]); /* * Saved cp0 registers */ printk("epc : %08lx\nStatus: %08x\nCause : %08x\n", (unsigned long) regs->cp0_epc, (unsigned int) regs->cp0_status, (unsigned int) regs->cp0_cause); } static void r2300_add_wired_entry(unsigned long entrylo0, unsigned long entrylo1, unsigned long entryhi, unsigned long pagemask) { printk("r2300_add_wired_entry"); /* * FIXME, to be done */ } static int r2300_user_mode(struct pt_regs *regs) { return !(regs->cp0_status & KU_USER); } __initfunc(void ld_mmu_r2300(void)) { printk("CPU revision is: %08x\n", read_32bit_cp0_register(CP0_PRID)); clear_page = r2300_clear_page; copy_page = r2300_copy_page; probe_icache(); probe_dcache(); flush_cache_all = r2300_flush_cache_all; flush_cache_mm = r2300_flush_cache_mm; flush_cache_range = r2300_flush_cache_range; flush_cache_page = r2300_flush_cache_page; flush_cache_sigtramp = r2300_flush_cache_sigtramp; flush_page_to_ram = r2300_flush_page_to_ram; flush_tlb_all = r2300_flush_tlb_all; flush_tlb_mm = r2300_flush_tlb_mm; flush_tlb_range = r2300_flush_tlb_range; flush_tlb_page = r2300_flush_tlb_page; load_pgd = r2300_load_pgd; pgd_init = r2300_pgd_init; update_mmu_cache = r2300_update_mmu_cache; show_regs = r2300_show_regs; add_wired_entry = r2300_add_wired_entry; user_mode = r2300_user_mode; flush_tlb_all(); } >>>>>>>>>>>>>>>>>>> From raiko@niisi.msk.ru Wed Oct 7 14:37:51 1998 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA11350; Wed, 7 Oct 1998 14:35:28 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 14:35:28 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id QAA16192 for ; Wed, 7 Oct 1998 16:35:05 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA20150 for linux-mips@fnet.fr; Wed, 7 Oct 1998 15:41:05 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id QAA16966 for ; Wed, 7 Oct 1998 16:31:08 +0300 (MSK) Message-ID: <361B6049.89F2FB68@niisi.msk.ru> Date: Wed, 07 Oct 1998 15:36:25 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: [PATCH]: binutils-2.8.1 for mips Content-Type: multipart/mixed; boundary="------------B4F9160E8BE4CD51EBFA0C6D" Content-Length: 1841 Lines: 41 This is a multi-part message in MIME format. --------------B4F9160E8BE4CD51EBFA0C6D Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi folks, The patch teaches 'as' to insert nops between mtc0/tlb{p,r,wi,wr}. This is the requrement for R3000 and without it we need add nops manually after *each* mtc0 in the kernel macros in pgtable.h in order to ensure we never touch tlb before CPU updates its internal registers. Harald, with this patch applied we may throw away all nops I inserted in 2.1.116. I'll send a patch to you soon. Regards, Gleb. --------------B4F9160E8BE4CD51EBFA0C6D Content-Type: text/plain; charset=koi8-r; name="binutils-r3k.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="binutils-r3k.patch" --- binutils-2.8.1.orig/opcodes/mips-opc.c Mon May 26 21:34:19 1997 +++ binutils-2.8.1/opcodes/mips-opc.c Wed Oct 7 14:16:21 1998 @@ -655,10 +655,10 @@ {"tgeu", "s,t", 0x00000031, 0xfc00003f, RD_s|RD_t|I2|TRAP }, {"tgeu", "s,j", 0x04090000, 0xfc1f0000, RD_s|I2|TRAP }, /* tgeiu */ {"tgeu", "s,I", 2, (int) M_TGEU_I, INSN_MACRO }, -{"tlbp", "", 0x42000008, 0xffffffff, INSN_TLB }, -{"tlbr", "", 0x42000001, 0xffffffff, INSN_TLB }, -{"tlbwi", "", 0x42000002, 0xffffffff, INSN_TLB }, -{"tlbwr", "", 0x42000006, 0xffffffff, INSN_TLB }, +{"tlbp", "", 0x42000008, 0xffffffff, INSN_TLB|INSN_COP|COD }, +{"tlbr", "", 0x42000001, 0xffffffff, INSN_TLB|INSN_COP|COD }, +{"tlbwi", "", 0x42000002, 0xffffffff, INSN_TLB|INSN_COP|COD }, +{"tlbwr", "", 0x42000006, 0xffffffff, INSN_TLB|INSN_COP|COD }, {"tlti", "s,j", 0x040a0000, 0xfc1f0000, RD_s|I2|TRAP }, {"tlt", "s,t", 0x00000032, 0xfc00003f, RD_s|RD_t|I2|TRAP }, {"tlt", "s,j", 0x040a0000, 0xfc1f0000, RD_s|I2|TRAP }, /* tlti */ --------------B4F9160E8BE4CD51EBFA0C6D-- From harald.koerfgen@netcologne.de Wed Oct 7 20:18:59 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA18669; Wed, 7 Oct 1998 20:18:57 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 20:18:57 +0200 (MET DST) Received: from franz.no.dom (dial1-6.netcologne.de [194.8.196.6]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id UAA00634 for ; Wed, 7 Oct 1998 20:18:44 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <361B6049.89F2FB68@niisi.msk.ru> Date: Wed, 07 Oct 1998 20:20:13 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: [PATCH]: binutils-2.8.1 for mips Content-Length: 704 Lines: 23 Hi all, On 07-Oct-98 Gleb O. Raiko wrote: > Hi folks, > > The patch teaches 'as' to insert nops between mtc0/tlb{p,r,wi,wr}. This > is the requrement for R3000 and without it we need add nops manually > after *each* mtc0 in the kernel macros in pgtable.h in order to ensure > we never touch tlb before CPU updates its internal registers. Absolutely great, already recompiled my binutils :-). Well, I'm not a binutils hacker but in my opinion as a kernel hacker wannabe this is a serious bug in as, to whom should this patch be sent to make it official? > Harald, with this patch applied we may throw away all nops I inserted in > 2.1.116. I'll send a patch to you soon. Great. --- Regards, Harald From harald.koerfgen@netcologne.de Wed Oct 7 20:19:01 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA18670; Wed, 7 Oct 1998 20:18:57 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 20:18:57 +0200 (MET DST) Received: from franz.no.dom (dial1-6.netcologne.de [194.8.196.6]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id UAA00650 for ; Wed, 7 Oct 1998 20:18:52 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981007002547.44731@alpha.franken.de> Date: Wed, 07 Oct 1998 20:20:22 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: Tags are dead alias Milo is dead part II Content-Length: 4054 Lines: 123 On 06-Oct-98 Thomas Bogendoerfer wrote: > In the process of making Milo obsolete I've also removed tags stuff. This > was simple for the Indy and took only a few hours for the Olivetti. I hope > it's also possible for the Decstation. Before I'll start commiting the > changes > we should make sure, how to solve the missing tags for all plattforms. Well, that'd certainly be possible for the DECstations too. We would then have to use PROM callback functions from within the kernel with the disadvantage that we have to keep the memory range 0x80000000 - 0x8002ffff reserved for the PROM, thus wasting 192KB memory :-(. Or do you have another way in mind passing information from the boot PROM/boot loader to the kernel? To be able to move the kernel down to 0x8000000 we rely quite heavily on having infomation already gathered from the PROM and passed to the kernel. This is actually done via tags, in fact, I have added some tags to the DECstation source tree. But when common opinion is not to use tags, well, then let it be so. > Another old code, which might be obsolete now is the wired entry stuff > in arch/mips/kernel/head.S. It's already disabled for R4k CPUs and > I would prefer to remove that stuff also for the other CPUs. If you > need wired entries, I would propose using the add_wired_entry() > function as I already do it for the JAZZ hardware (arch/mips/jazz/setup.c). No problem for the DECstations. --- Regards, Harald P.S.: when you are already messing around with head.S, could you please apply the following little patch? --- snip here --- --- linux-2.1.121-clean/arch/mips/kernel/head.S Wed Sep 23 23:28:05 1998 +++ linux-2.1.121-r3000/arch/mips/kernel/head.S Wed Oct 7 19:58:32 1998 @@ -11,7 +11,7 @@ * Copyright (C) 1995, 1996, 1997, 1998 Ralf Baechle * Copyright (C) 1996 Paul M. Antoine * Modified for DECStation and hence R3000 support by Paul M. Antoine - * Further modifications by David S. Miller + * Further modifications by David S. Miller and Harald Koerfgen * * Head.S contains the MIPS exception handler and startup code. */ @@ -257,6 +257,7 @@ /* TLB refill, EXL == 0, R[23]00 version */ LEAF(except_vec0_r2300) + .set noat .set mips1 mfc0 k0, CP0_BADVADDR _GET_CURRENT(k1) # get current task ptr @@ -266,23 +267,17 @@ addu k1, k1, k0 mfc0 k0, CP0_CONTEXT lw k1, (k1) - srl k0, k0, 1 - and k0, k0, 0xffc + andi k0, k0, 0xffc addu k1, k1, k0 lw k0, (k1) - srl k0, k0, 12 + nop mtc0 k0, CP0_ENTRYLO0 mfc0 k1, CP0_EPC tlbwr - nop - nop - nop - nop jr k1 rfe END(except_vec0_r2300) - /* XTLB refill, EXL == 0, R4xx0 cpus only use this... */ NESTED(except_vec1_generic, 0, sp) .set noat @@ -338,6 +333,7 @@ /* General exception vector. */ NESTED(except_vec3_generic, 0, sp) .set noat + .set mips0 mfc0 k1, CP0_CAUSE la k0, exception_handlers andi k1, k1, 0x7c @@ -374,6 +370,14 @@ nop probe_done: + /* + * Stack for kernel and init, current variable + */ + la $28, init_task_union + addiu t0, $28, KERNEL_STACK_SIZE-32 + sw t0, kernelsp + subu sp, t0, 4*SZREG + #ifndef CONFIG_SGI /* Get the memory upper limit the bootloader passed to us @@ -451,16 +455,8 @@ jal wire_mappings_r3000 nop - /* - * Stack for kernel and init, current variable - */ -9: la $28, init_task_union - addiu t0, $28, KERNEL_STACK_SIZE-32 - sw t0, kernelsp - subu sp, t0, 4*SZREG - /* Disable coprocessors */ - mfc0 t0, CP0_STATUS +9: mfc0 t0, CP0_STATUS li t1, ~(ST0_CU1|ST0_CU2|ST0_CU3|ST0_KX|ST0_SX) and t0, t1 or t0, ST0_CU0 From dsmith@ActiveVoice.com Wed Oct 7 21:49:48 1998 Received: from activevoice.com (exchange.avoice.com [198.207.218.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA21341; Wed, 7 Oct 1998 21:49:47 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 21:49:47 +0200 (MET DST) Received: by gateway.activevoice.com via suspension id <31366>; Wed, 7 Oct 1998 12:46:41 -0700 Received: from exchange2.activevoice.com ([10.1.2.0]) by gateway.activevoice.com with ESMTP id <31362>; Wed, 7 Oct 1998 12:46:34 -0700 Received: by exchange2.avoice.com with Internet Mail Service (5.5.2232.9) id ; Wed, 7 Oct 1998 12:45:11 -0700 Message-ID: <61B452CEA1F9D11195A600A024C65C690A6D08@exchange2.avoice.com> From: Dave Smith To: "'linux-mips@fnet.fr'" Subject: VMLINUX for MIPS Date: Wed, 7 Oct 1998 12:45:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Content-Length: 852 Lines: 17 Please excuse this extremely "new user" question. I read through the HOWTO for creating a floppy disk with MILO and VMLINUX on it, but the instructions don't indicate where to find the VMLINUX image. I downloaded MILO 0.27 and I also downloaded the 2.1.36 kernel distribution, but the distribution didn't include a binary image and I don't have the compiler tools to rebuild the kernel image. Am I going to need to download and configure the cross compiler just to build the VMLINUX image so that I can boot from floppy? I do not have any other Linux system available right now. If it's available, could you please point me to a binary image of VMLINUX for an NEC RISCServer 4200? If the image is actually available in the kernel distribution I downloaded, please just tell me where I can find it. Thank You, Dave Smith Future Linux Mips User From tsbogend@alpha.franken.de Wed Oct 7 23:48:56 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA25818; Wed, 7 Oct 1998 23:48:55 +0200 (MET DST) Received-Date: Wed, 7 Oct 1998 23:48:55 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id XAA04876; Wed, 7 Oct 1998 23:48:53 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id XAA03116; Wed, 7 Oct 1998 23:44:51 +0200 Message-ID: <19981007234450.41955@alpha.franken.de> Date: Wed, 7 Oct 1998 23:44:50 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: Tags are dead alias Milo is dead part II References: <19981007002547.44731@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: ; from Harald Koerfgen on Wed, Oct 07, 1998 at 08:20:22PM +0200 Content-Length: 1785 Lines: 42 On Wed, Oct 07, 1998 at 08:20:22PM +0200, Harald Koerfgen wrote: > Well, that'd certainly be possible for the DECstations too. We would then have > to use PROM callback functions from within the kernel with the disadvantage > that we have to keep the memory range 0x80000000 - 0x8002ffff reserved for the > PROM, thus wasting 192KB memory :-(. we can reclaim the PROM memory, when we are done with PROM calls. This can be done the same way as we get memory back for __initfuncs(). Ralf had also the idea to save the content of the PROM memory and bring it back, when there is a need to do PROM calls, which probably happens only for config stuff. But we haven't found a really good solution to do this. > actually done via tags, in fact, I have added some tags to the DECstation > source tree. But when common opinion is not to use tags, well, then let it be > so. Just read DaveM comments in arch/mips/sgi/prom/tags.c. Out of curiousity, how do you boot a kernel on a Decstation ? Have you ported Milo to it ? > > Another old code, which might be obsolete now is the wired entry stuff > > in arch/mips/kernel/head.S. It's already disabled for R4k CPUs and > > I would prefer to remove that stuff also for the other CPUs. If you > > need wired entries, I would propose using the add_wired_entry() > > function as I already do it for the JAZZ hardware (arch/mips/jazz/setup.c). > > No problem for the DECstations. great. > P.S.: when you are already messing around with head.S, could you please apply > the following little patch? If Ralf doesn't see a problem, I'll apply it. Thomas. -- See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>] From ralf@lappi.waldorf-gmbh.de Thu Oct 8 18:16:43 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08444; Thu, 8 Oct 1998 18:16:38 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 18:16:38 +0200 (MET DST) Received: from newshost (root@newshost.uni-koblenz.de [141.26.4.18]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with SMTP id SAA23138 for ; Thu, 8 Oct 1998 18:16:31 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de by newshost (SMI-8.6/KO-2.0) id SAA25132; Thu, 8 Oct 1998 18:16:29 +0200 Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA08374; Thu, 8 Oct 1998 12:19:06 +0200 Message-ID: <19981008121905.A8357@uni-koblenz.de> Date: Thu, 8 Oct 1998 12:19:05 +0200 From: ralf@uni-koblenz.de To: Thomas Bogendoerfer , linux-mips@fnet.fr Subject: Re: Unsuccesful trying to run Linux on RM200 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981006011950.09261@alpha.franken.de>; from Thomas Bogendoerfer on Tue, Oct 06, 1998 at 01:19:50AM +0200 Content-Length: 804 Lines: 19 On Tue, Oct 06, 1998 at 01:19:50AM +0200, Thomas Bogendoerfer wrote: > On Tue, Oct 06, 1998 at 12:09:58AM +0200, Michael Engel wrote: > > Yep. One could also try to build a kernel for the big-endian SINIX firmware > > on the RM200, perhaps the SINIX firmware has less bugs ... Not bugs but _very_ unfunny features ... > I wouldn't bet, but feel free to do it:-) Is the SINIX firmware also > ARC or a different beast ? Both little endian and big endian mode of the RM use the ARC firmware. In little endian mode the ARC firmware behaves like a Magnum etc., that is it tries to read it's OS from a FAT partition. In big endian mode the machine behaves like a true MIPS machine, that is they seem to be using the ``MIPS disk volume header'' just like IRIX. Oh, surprise - we support the dvh. Ralf From ralf@lappi.waldorf-gmbh.de Thu Oct 8 18:16:34 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08422; Thu, 8 Oct 1998 18:16:32 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 18:16:32 +0200 (MET DST) Received: from newshost (root@newshost.uni-koblenz.de [141.26.4.18]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with SMTP id SAA23109 for ; Thu, 8 Oct 1998 18:16:28 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de by newshost (SMI-8.6/KO-2.0) id SAA25127; Thu, 8 Oct 1998 18:16:26 +0200 Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA08457; Thu, 8 Oct 1998 12:29:15 +0200 Message-ID: <19981008122915.A8447@uni-koblenz.de> Date: Thu, 8 Oct 1998 12:29:15 +0200 From: ralf@uni-koblenz.de To: Richard van den Berg , linux-mips@fnet.fr Subject: Re: DECstation-Linux is dead, long live Linux-R3000! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 X-Mailer: Mutt 0.91.1 In-Reply-To: ; Content-Length: 538 Lines: 13 +from Richard van den Berg on Mon, Oct 05, 1998 at 09:45:50PM +0200 On Mon, Oct 05, 1998 at 09:45:50PM +0200, Richard van den Berg wrote: > BTW, does somebody out there knows the right settings to make minicom > behave like a terminal, I haven't succeeded yet, clearing out all init > strings and setting the right communication parameters of course (9600, > 8n1) it says online, but no contact with the DEC. I use cu for that case. Do something like ``cu -l /dev/ttyS0'' or so. (Cu is usually contained in the UUCP package). Ralf From ralf@lappi.waldorf-gmbh.de Thu Oct 8 18:14:50 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08264; Thu, 8 Oct 1998 18:14:48 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 18:14:48 +0200 (MET DST) Received: from newshost (root@newshost.uni-koblenz.de [141.26.4.18]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with SMTP id SAA22324 for ; Thu, 8 Oct 1998 18:14:46 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de by newshost (SMI-8.6/KO-2.0) id SAA24643; Thu, 8 Oct 1998 18:14:43 +0200 Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id RAA09608; Thu, 8 Oct 1998 17:03:35 +0200 Message-ID: <19981008170335.H4058@uni-koblenz.de> Date: Thu, 8 Oct 1998 17:03:35 +0200 From: ralf@uni-koblenz.de To: Thomas Bogendoerfer , linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@engr.sgi.com Subject: Re: Tags are dead alias Milo is dead part II References: <19981007002547.44731@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981007002547.44731@alpha.franken.de>; from Thomas Bogendoerfer on Wed, Oct 07, 1998 at 12:25:47AM +0200 Content-Length: 2030 Lines: 51 On Wed, Oct 07, 1998 at 12:25:47AM +0200, Thomas Bogendoerfer wrote: > In the process of making Milo obsolete I've also removed tags stuff. This > was simple for the Indy and took only a few hours for the Olivetti. I hope > it's also possible for the Decstation. Before I'll start commiting the changes > we should make sure, how to solve the missing tags for all plattforms. > > Another old code, which might be obsolete now is the wired entry stuff > in arch/mips/kernel/head.S. It's already disabled for R4k CPUs and > I would prefer to remove that stuff also for the other CPUs. If you > need wired entries, I would propose using the add_wired_entry() > function as I already do it for the JAZZ hardware (arch/mips/jazz/setup.c). People should consider that TLB entries are a scarce resource. Wiring them can seriously impact performance. (Which reminds me of the lock warning bit in the 68851 - Moto people we seriously assuming somebody could wire all ATC (that is TLB in Moto slang) entries ...) Our current 32 bit page table structure is good for mapping everything in the lowest 4gb of physical address space. Things outside of this area are the only things which will need to be mapped by some other mean. We've so far used wired entries which in most cases they're a bad idea for the above mentioned reason. Since loading and flushing a single TLB entry is a quite cheap thing on MIPS parts of the kernel could do things like struct wired { caddr_t physical; caddr_t virtual; u32 mask; u32 usage; u8 entry; } gfx_entry = { GFX_PBASE, GFX_VBASE, PM_4M }; entry = load_wired_entry(&gfx_entry); ... /* Munge mapped address space */ flush_wired_entry(entry); Applied to the G364 drivers (which as of now is still MIPS specific anyway) this means that we'll avoid TLB trashing in the case of scrolling and have the full TLB available for userland. The second alternative which can be used where it's ok to disable interrupts is to access memory using one of the XKPHYS segments. Ralf From ralf@lappi.waldorf-gmbh.de Thu Oct 8 18:14:28 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08242; Thu, 8 Oct 1998 18:14:25 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 18:14:25 +0200 (MET DST) Received: from newshost (root@newshost.uni-koblenz.de [141.26.4.18]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with SMTP id SAA22150 for ; Thu, 8 Oct 1998 18:14:21 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de by newshost (SMI-8.6/KO-2.0) id SAA24540; Thu, 8 Oct 1998 18:14:19 +0200 Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id RAA09947; Thu, 8 Oct 1998 17:22:00 +0200 Message-ID: <19981008172200.I4058@uni-koblenz.de> Date: Thu, 8 Oct 1998 17:22:00 +0200 From: ralf@uni-koblenz.de To: Harald Koerfgen , linux-mips@fnet.fr Subject: Re: DECstation-Linux is dead, long live Linux-R3000! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harald Koerfgen on Sun, Oct 04, 1998 at 09:23:21PM +0200 Content-Length: 541 Lines: 12 On Sun, Oct 04, 1998 at 09:23:21PM +0200, Harald Koerfgen wrote: > ecgs-1.0.2. I'll investigate using the ecgs comiler because I think that this > will become the official Linux/MIPS compiler. Ralf, any comments on that? Yes, I'm already playing with the -msplit-addresses optimization that doesn't work with gcc 2.7.2. Anyway, the FSF style of managing gcc development moved gcc into a dead corner, so egcs is the way to go. The next reason to got with egcs is the fact that RH does the same for all architectures except Intel. Ralf From akonstantinov@yahoo.com Thu Oct 8 21:02:23 1998 Received: from send101.yahoomail.com (send101.yahoomail.com [205.180.60.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id VAA12273; Thu, 8 Oct 1998 21:02:21 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 21:02:21 +0200 (MET DST) Message-ID: <19981008190123.217.rocketmail@send101.yahoomail.com> Received: from [193.219.1.35] by send101.yahoomail.com; Thu, 08 Oct 1998 12:01:23 PDT Date: Thu, 8 Oct 1998 12:01:23 -0700 (PDT) From: Aleksandr Konstantinov Subject: Re: Unsuccesful trying to run Linux on RM200 To: linux-mips@fnet.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 948 Lines: 27 ---ralf@uni-koblenz.de wrote: > Both little endian and big endian mode of the RM use >the ARC firmware. > In little endian mode the ARC firmware behaves like a >Magnum etc., that > is it tries to read it's OS from a FAT partition. In >big endian mode > the machine behaves like a true MIPS machine, that is >they seem to be > using the ``MIPS disk volume header'' just like IRIX. > > Excuse me for newbie question, but how to switch to that litle endian mode? Or maybe there is MILO for big endian mode ? Unfortunately we have no Linux here and can't use any crosscompiler to recompile MILO or VMLINUX for big endian. Does kernel use any bios code or need no firmware after switching to litle endian ? How to make 'MIPS disk volume header' ? A.K. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From tsbogend@alpha.franken.de Thu Oct 8 22:03:09 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA13288; Thu, 8 Oct 1998 22:03:08 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 22:03:08 +0200 (MET DST) Received: from alpha.franken.de (tsbogend@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id WAA14735; Thu, 8 Oct 1998 22:03:05 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id VAA03189; Thu, 8 Oct 1998 21:58:35 +0200 Message-ID: <19981008215834.51243@alpha.franken.de> Date: Thu, 8 Oct 1998 21:58:34 +0200 From: Thomas Bogendoerfer To: ralf@uni-koblenz.de Cc: linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@engr.sgi.com Subject: Re: Tags are dead alias Milo is dead part II References: <19981007002547.44731@alpha.franken.de> <19981008170335.H4058@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19981008170335.H4058@uni-koblenz.de>; from ralf@uni-koblenz.de on Thu, Oct 08, 1998 at 05:03:35PM +0200 Content-Length: 1062 Lines: 21 On Thu, Oct 08, 1998 at 05:03:35PM +0200, ralf@uni-koblenz.de wrote: > Applied to the G364 drivers (which as of now is still MIPS specific anyway) > this means that we'll avoid TLB trashing in the case of scrolling and have > the full TLB available for userland. I don't believe this will buy us anything. When we add a temporary TLB we need do clear one TLB, which might be used by the userland. So we end up loading our wired entry, killing it, and later the user process has to reload the TLB again. This way we force TLB trashing, with one wired entry more we _might_ get a little bit more TLB trashing. As you might know, I'm using three wired entries for the Magnum, and I don't think doing the same trick for the other entries is a real good idea. When we make them temporary, we have to mess with TLBs on every interrupt. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From harald.koerfgen@netcologne.de Thu Oct 8 21:57:33 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA13222; Thu, 8 Oct 1998 21:57:31 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 21:57:31 +0200 (MET DST) Received: from franz.no.dom (dial4-119.netcologne.de [195.14.233.119]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA21364; Thu, 8 Oct 1998 21:57:16 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 08 Oct 1998 21:58:45 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Richard van den Berg Subject: Re: DECstation-Linux is dead, long live Linux-R3000! Cc: linux-mips@fnet.fr Content-Length: 425 Lines: 13 On 05-Oct-98 Richard van den Berg wrote: > BTW, does somebody out there knows the right settings to make minicom > behave like a terminal, I haven't succeeded yet, clearing out all init > strings and setting the right communication parameters of course (9600, > 8n1) it says online, but no contact with the DEC. Are you shure you have disabled "Hardware Flow Control"? (Ctrl-A O "Serial port setup" F) --- Regards, Harald From wje@fir.engr.sgi.com Thu Oct 8 23:16:37 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA14586; Thu, 8 Oct 1998 23:16:36 +0200 (MET DST) Received-Date: Thu, 8 Oct 1998 23:16:36 +0200 (MET DST) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA17460; Thu, 8 Oct 1998 14:14:18 -0700 (PDT) mail_from (wje@fir.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA01301; Thu, 8 Oct 1998 14:15:57 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.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 OAA09314; Thu, 8 Oct 1998 14:07:49 -0700 (PDT) mail_from (wje@fir.engr.sgi.com) Received: from fir.engr.sgi.com (fir.engr.sgi.com [150.166.49.183]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id NAA36707; Thu, 8 Oct 1998 13:31:47 -0700 (PDT) mail_from (wje@fir.engr.sgi.com) Received: (from wje@localhost) by fir.engr.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA04597; Thu, 8 Oct 1998 13:30:36 -0700 Date: Thu, 8 Oct 1998 13:30:36 -0700 Message-Id: <199810082030.NAA04597@fir.engr.sgi.com> From: "William J. Earl" To: Thomas Bogendoerfer Cc: ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com Subject: Re: Tags are dead alias Milo is dead part II In-Reply-To: <19981008215834.51243@alpha.franken.de> References: <19981007002547.44731@alpha.franken.de> <19981008170335.H4058@uni-koblenz.de> <19981008215834.51243@alpha.franken.de> Content-Length: 1080 Lines: 19 Thomas Bogendoerfer writes: > On Thu, Oct 08, 1998 at 05:03:35PM +0200, ralf@uni-koblenz.de wrote: > > Applied to the G364 drivers (which as of now is still MIPS specific anyway) > > this means that we'll avoid TLB trashing in the case of scrolling and have > > the full TLB available for userland. > > I don't believe this will buy us anything. When we add a temporary TLB we need > do clear one TLB, which might be used by the userland. So we end up loading > our wired entry, killing it, and later the user process has to reload the > TLB again. This way we force TLB trashing, with one wired entry more we > _might_ get a little bit more TLB trashing. > > As you might know, I'm using three wired entries for the Magnum, and I don't > think doing the same trick for the other entries is a real good idea. When > we make them temporary, we have to mess with TLBs on every interrupt. You could do what IRIX does in some cases, which is to save and restore the TLB entry you replace. Beware of doing this, however, if your code could take a page fault. From triemer@apt4g.a3nyc.com Fri Oct 9 03:16:54 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA18955; Fri, 9 Oct 1998 03:16:53 +0200 (MET DST) Received-Date: Fri, 9 Oct 1998 03:16:53 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id UAA00770 for ; Thu, 8 Oct 1998 20:38:06 -0400 Date: Thu, 8 Oct 1998 20:38:06 -0400 (EDT) From: Thomas Riemer Reply-To: Thomas Riemer To: linux-mips@fnet.fr Subject: 2.1.121 build for ds2100 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 714 Lines: 25 I downloaded the 2.1.21 pre1 release and tried to build it - for a a ds2100. I'm getting: VFS: Mounted root (ext2 filesystem). VFS: Cannot open root device 00:00 Kernel panic: VFS: Unable to mount root fs on 00:00 This error is generated in super.c. Anyone else seeing this? Please respond directly - as I recently got removed from linux-mips - I went on vacation for 2 weeks and my landlord decided not to pay for the T-1. (Now the T-1 is in my name and that won't ever happen again.) In that time, the mailing list withdrew me from subscription. (I'm waiting to be put back on) -Tom ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From harald.koerfgen@netcologne.de Fri Oct 9 19:20:56 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA24051; Fri, 9 Oct 1998 19:20:54 +0200 (MET DST) Received-Date: Fri, 9 Oct 1998 19:20:54 +0200 (MET DST) Received: from franz.no.dom (dial6k-147.netcologne.de [195.14.233.147]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id TAA01322 for ; Fri, 9 Oct 1998 19:20:47 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981007234450.41955@alpha.franken.de> Date: Fri, 09 Oct 1998 19:22:17 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: Tags are dead alias Milo is dead part II Content-Length: 1204 Lines: 34 Hi, On 07-Oct-98 Thomas Bogendoerfer wrote: >> [...] We would then have >> to use PROM callback functions from within the kernel with the disadvantage >> that we have to keep the memory range 0x80000000 - 0x8002ffff reserved for the >> PROM, thus wasting 192KB memory :-(. > > we can reclaim the PROM memory, when we are done with PROM calls. This can > be done the same way as we get memory back for __initfuncs(). Fine. In that case I don't have a problem with this. > Ralf had also > the idea to save the content of the PROM memory and bring it back, when there > is a need to do PROM calls, which probably happens only for config stuff. > But we haven't found a really good solution to do this. The PROM calls are indeed only needed for config stuff. Well, except the PROM console, which is a temporary solution anyway. > Out of curiousity, how do you boot a kernel on a Decstation ? Have you ported > Milo to it ? Not yet and never will. But we will need a bootloader for the DECstations because the DECstation PROM doesn't know anything about filesystems. Actually we boot the kernel as single file, i.e. merged with the startup stuff and the ramdisk image, via TFTP. --- Regards, Harald From harald.koerfgen@netcologne.de Fri Oct 9 19:21:08 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA24073; Fri, 9 Oct 1998 19:21:06 +0200 (MET DST) Received-Date: Fri, 9 Oct 1998 19:21:06 +0200 (MET DST) Received: from franz.no.dom (dial6k-147.netcologne.de [195.14.233.147]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id TAA01327; Fri, 9 Oct 1998 19:20:50 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 09 Oct 1998 19:22:20 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Thomas Riemer Subject: RE: 2.1.121 build for ds2100 Cc: linux-mips@fnet.fr Content-Length: 653 Lines: 28 Hi Tom, On 09-Oct-98 Thomas Riemer wrote: > I downloaded the 2.1.21 pre1 release and tried to build it - for a > a ds2100. > > I'm getting: > > VFS: Mounted root (ext2 filesystem). > VFS: Cannot open root device 00:00 > Kernel panic: VFS: Unable to mount root fs on 00:00 > > > This error is generated in super.c. > Anyone else seeing this? This is normal If you haven't specified the root fs with an command line option. To be able to play around with the nfsroot option I have removed a hack that mounted the ramdisk as the root fs. Just boot the kernel with >>boot root=/dev/ram Have fun. --- Regards, Harald From triemer@apt4g.a3nyc.com Sat Oct 10 17:10:38 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA01590; Sat, 10 Oct 1998 17:10:37 +0200 (MET DST) Received-Date: Sat, 10 Oct 1998 17:10:37 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id LAA02692 for ; Sat, 10 Oct 1998 11:10:37 -0400 Date: Sat, 10 Oct 1998 11:10:37 -0400 (EDT) From: Thomas Riemer To: linux-mips@fnet.fr Subject: minor patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 794 Lines: 29 Here is a minor patch for declance.c: -Tom Riemer ----------------------------------------- diff -rubN linux-2.1.121-r3000/drivers/net/declance.c linux-2.1.121-r3000_pl1/drivers/net/declance.c --- linux-2.1.121-r3000/drivers/net/declance.c Thu Oct 1 14:55:26 1998 +++ linux-2.1.121-r3000_pl1/drivers/net/declance.c Thu Oct 8 19:54:05 1998 @@ -963,6 +963,7 @@ return 0; } +#ifdef CONFIG_TC static int tc_probe(struct device *dev, unsigned char *esar_base) { extern slot_info tc_bus[MAX_SLOT]; @@ -984,6 +985,7 @@ } return 0; } +#endif /* Find all the lance cards on the system and initialize them */ __initfunc(int dec_lance_probe (struct device *dev)) ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From harald.koerfgen@netcologne.de Sat Oct 10 18:15:44 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA01858; Sat, 10 Oct 1998 18:15:41 +0200 (MET DST) Received-Date: Sat, 10 Oct 1998 18:15:41 +0200 (MET DST) Received: from franz.no.dom (dial2-21.netcologne.de [194.8.195.21]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id SAA07168 for ; Sat, 10 Oct 1998 18:15:35 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.2.p0.Linux:981010181606:276=_" In-Reply-To: <361B55A5.3FF2F228@niisi.msk.ru> Date: Sat, 10 Oct 1998 18:17:03 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: Linux support for R3000-series computers Content-Length: 8112 Lines: 290 This message is in MIME format --_=XFMail.1.2.p0.Linux:981010181606:276=_ Content-Type: text/plain; charset=us-ascii Hi Vladimir (and all the others, of course), On 07-Oct-98 Vladimir Roganov wrote: > Most important increasement of reliability we obtained commenting (new) > TLB-related code (define TOTAL_TLB_FLUSH in attached r2300.c), and > redesign > cache invalidation code (see following topic. We will happy to receive > any > comments about it). Well, happy reading. > We are peace about TLB-flush/ASID logic -- it possibly just not debugged > enough, and will be fixed too. Yup. I simply copied the routines from r4000.c with a few adaptions for the R3000 and it's very probable that not everything is right. Now that my DECstation goes single user I'll be able to make a few tests. > But yet another thing is more interesting: when we define > NO_TLB_OPTIMIZE > in r2300_misc.S: we received kernel page fault: 'unix_gc' function uses > VMALLOC, which reserves addresses in KSEG2, but 'do_page_fault' function > mean it is not right. > It is very interesting for us, due we want to use VMALLOC-like mechanism > to map KSEG2 area to our lance network adapter memory to avoid > Baget-specific > options in r2300_misc.S (that is, to have something like > sparc_alloc_io). > If anybody have ideas how to do it in current Linux structure, please > inform us. That should be easy to fix (been there done that). The R3000 handle KSEG2 misses through a different exception mechanism than the R4000. A KSEG2 on a R4000 causes a TLB miss exception (except_vec0) whereas on the R3000 a KSEG2 miss causes a TLB[LS] exception (except_vec3_generic -> handle_r2300_tlb[ls]) and do_fault() get's very confused. The attached patch should fix this, the code has been here from 2.1.14 - 2.1.100. BTW, the code in this file is strictly R3000 related and we don't need no stinking .set push/.set reorder/.set pop here and can insert as many nops as we like. I have cleaned up the code accordingly. > o Cache code improvement suggestions: > > We spend many hours measuring BAGET performance and found that cache > code speedup is very desirable. One more reason for cache code > revision: we found that few cache invalidation functions really accept > virtual addresses instead physical. > > After few revisions we lead to following structure: > > 1) To avoid code duplication struct 'cache_space' is used for both > I & D cache spaces. Initialization of these structures is done > at functions 'probe_?cache', calling 'cache_size'. > It is so called initialization level. > > 2) Low-level functions for cache spaces invalidation are called > 'flush_cache_space_page' and 'flush_cache_space_all'. > First accepts 'cache_space' structure, performs some checks and > flushes physical cache page as fast as possible. > Second function just uses above to flush needed quantity of KSEG0 > pages. > > To translate address to physical page 'get_phys_page' function is > used. > It carefully checks segments and returns 0 or page real memory > address. > > We have red D.Miller article about Linux cache flush architecture, > where noticed what DMA/Drivers dcache cache coherency should be > implemented at driver layer. So we are now avoiding dcache > invalidation, > and introduce DO_DCACHE_FLUSH flag if somebody need to flush dcache > here. Fine, less is more :-). I've been thinking about that too but have been faster. Honestly, I read Daves paper too and I agree, we probably don't have to invalidate the dcache ever in the mmu related code. DMA is another thing and should stricly be driver related. > 3) All exported 'r2300_*' functions obtain physical page(s) and flushes > one(s). Few top-level optimizations are commented in a source code. Good work, my DECstation seems to run fine with your changes. --- Regards, Harald --_=XFMail.1.2.p0.Linux:981010181606:276=_ Content-Disposition: attachment; filename="patch.r2300_misc" Content-Transfer-Encoding: 7bit Content-Description: patch.r2300_misc Content-Type: text/plain; charset=us-ascii; name=patch.r2300_misc; SizeOnDisk=3892 --- r2300_misc.S.old Sat Oct 10 17:38:43 1998 +++ r2300_misc.S Sat Oct 10 17:40:52 1998 @@ -1,14 +1,20 @@ -/* $Id: r2300_misc.S,v 1.2 1996/06/29 12:41:08 dm Exp $ +/* * r2300_misc.S: Misc. exception handling code for R3000/R2000. * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * * Copyright (C) 1994, 1995, 1996 by Ralf Baechle and Andreas Busse * * Multi-cpu abstraction reworking: * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * * Further modifications to make this work: - * Copyright (c) 1998 Harald Koerfgen + * Copyright (c) 1997, 1998 Harald Koerfgen * Copyright (c) 1998 Gleb Raiko & Vladimir Roganov + * + + $Id: $ */ #include @@ -30,7 +36,7 @@ .set mips1 .set noreorder -#define NOTLB_OPTIMIZE /* If you are paranoid, define this. */ +#undef NOTLB_OPTIMIZE /* If you are paranoid, define this. */ /* ABUSE of CPP macros 101. */ @@ -59,8 +65,7 @@ #define PTE_RELOAD(ptr) \ lw ptr, (ptr) ; \ nop ; \ - mtc0 ptr, CP0_ENTRYLO0; \ - nop; + mtc0 ptr, CP0_ENTRYLO0; #ifdef CONFIG_BAGET_MIPS @@ -113,10 +118,8 @@ andi pte, pte, (_PAGE_PRESENT | _PAGE_READ); \ xori pte, pte, (_PAGE_PRESENT | _PAGE_READ); \ bnez pte, label; \ - .set push; \ - .set reorder; \ lw pte, (ptr); \ - .set pop; + nop; /* Make PTE valid, store result in PTR. */ #define PTE_MAKEVALID(pte, ptr) \ @@ -130,10 +133,8 @@ andi pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \ xori pte, pte, (_PAGE_PRESENT | _PAGE_WRITE); \ bnez pte, label; \ - .set push; \ - .set reorder; \ lw pte, (ptr); \ - .set pop; + nop; /* Make PTE writable, update software status bits as well, @@ -150,6 +151,14 @@ NESTED(r2300_handle_tlbl, PT_SIZE, sp) .set noat +/* + * check wether this is a KSEG2 TLB miss + */ + mfc0 k0,CP0_BADVADDR + nop + bltz k0, go_kseg2_miss + nop + #ifndef NOTLB_OPTIMIZE /* Test present bit in entry. */ LOAD_PTE(k0, k1) @@ -158,10 +167,8 @@ PTE_PRESENT(k0, k1, nopage_tlbl) PTE_MAKEVALID(k0, k1) PTE_RELOAD(k1) - tlbwi - nop mfc0 k0, CP0_EPC - nop + tlbwi jr k0 rfe nopage_tlbl: @@ -173,6 +180,14 @@ NESTED(r2300_handle_tlbs, PT_SIZE, sp) .set noat +/* + * check wether this is a KSEG2 TLB miss + */ + mfc0 k0,CP0_BADVADDR + nop + bltz k0, go_kseg2_miss + nop + #ifndef NOTLB_OPTIMIZE LOAD_PTE(k0, k1) tlbp # find faulting entry @@ -180,10 +195,8 @@ PTE_WRITABLE(k0, k1, nopage_tlbs) PTE_MAKEWRITE(k0, k1) PTE_RELOAD(k1) - tlbwi - nop mfc0 k0, CP0_EPC - nop + tlbwi jr k0 rfe nopage_tlbs: @@ -192,29 +205,47 @@ DO_FAULT(1) END(r2300_handle_tlbs) + +/* + * Handle KSEG2 miss + */ + +go_kseg2_miss: + .set macro + _GET_CURRENT(k1) + srl k0, k0, 22 # Get pgd only bits + lw k1, THREAD_PGDIR(k1) # Get task pg_dir + sll k0, k0, 2 + addu k1, k1, k0 # Add in pgd offset + mfc0 k0, CP0_CONTEXT # Get context reg + lw k1, (k1) + and k0, k0, 0xffc # Get pte offset + addu k1, k1, k0 # Add in offset + lw k0, (k1) # Get pte + nop # needed!!! + mtc0 k0, CP0_ENTRYLO0 + mfc0 k1, CP0_EPC # Get return address + tlbwr # Write random + jr k1 # Return + rfe + .align 5 NESTED(r2300_handle_mod, PT_SIZE, sp) .set noat + #ifndef NOTLB_OPTIMIZE LOAD_PTE(k0, k1) tlbp # find faulting entry + nop andi k0, k0, _PAGE_WRITE beqz k0, nowrite_mod - .set push - .set reorder lw k0, (k1) - .set pop + nop - /* Present and writable bits set, set accessed and dirty bits. */ PTE_MAKEWRITE(k0, k1) - - /* Now reload the entry into the tlb. */ PTE_RELOAD(k1) - nop - tlbwi - nop mfc0 k0, CP0_EPC - nop + tlbwi jr k0 rfe #endif @@ -222,3 +253,4 @@ nowrite_mod: DO_FAULT(1) END(r2300_handle_mod) + --_=XFMail.1.2.p0.Linux:981010181606:276=_-- End of MIME message From imp@village.org Sun Oct 11 20:19:37 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id UAA10287; Sun, 11 Oct 1998 20:19:35 +0200 (MET DST) Received-Date: Sun, 11 Oct 1998 20:19:35 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zSQ5Q-0007gk-00; Sun, 11 Oct 1998 12:19:20 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id MAA03022 for ; Sun, 11 Oct 1998 12:18:57 -0600 (MDT) Message-Id: <199810111818.MAA03022@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board In-reply-to: Your message of "Sun, 11 Oct 1998 18:10:45 PDT." <36215714.1B05@tip.nl> References: <36215714.1B05@tip.nl> Date: Sun, 11 Oct 1998 12:18:57 -0600 From: Warner Losh Content-Length: 1021 Lines: 30 In message <36215714.1B05@tip.nl> Bert Morrien writes: : I've a 79S361 Evaluation board from IDT, based upon the : IDT RC36100 RISController. These are fun boards. I have one myself, but haven't looked at putting Linux on this board. The R4xxx version of this board is too flakey to really do serious work with. Hmmm, actually I think that I have the older board because there is no FLASH on mine. : 1. Is Linux suitable for embedded (unatended) applications, especially : where communication protocol stacks are needed? Yes. : 2. Could Linux run on a system with capabilities such as the mentioned : 79S361 Evaluation board, without disk storage but with sufficient : RAM and Flash memory? Yes, care must be taken to not wear out the Flash, however. : 3. Can I contribute in some way by porting Linux to my 79S361 board? Yes. : 4. What would be a good starting point for such a port? : Maybe an existing MIPS R4x00 port? The existing Linux/MIPS CVS tree has support for most R3xxx CPUs. Warner From dom@algor.co.uk Sun Oct 11 21:48:56 1998 Received: from embankment.algor.co.uk (0@embankment.algor.co.uk [193.117.190.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA11056; Sun, 11 Oct 1998 21:48:55 +0200 (MET DST) Received-Date: Sun, 11 Oct 1998 21:48:55 +0200 (MET DST) Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [193.117.190.129]) by embankment.algor.co.uk (8.8.8/8.8.8) with ESMTP id UAA00270 for ; Sun, 11 Oct 1998 20:48:48 +0100 (BST) Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.8.5/8.8.5) id UAA01737; Sun, 11 Oct 1998 20:48:49 +0100 (GMT/BST) Date: Sun, 11 Oct 1998 20:48:49 +0100 (GMT/BST) Message-Id: <199810111948.UAA01737@gladsmuir.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board In-Reply-To: <36215714.1B05@tip.nl> References: <36215714.1B05@tip.nl> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 415 Lines: 16 Bert, > I've a 79S361 Evaluation board from IDT, based upon the > IDT RC36100 RISController. > ... > 2. Could Linux run on a system with capabilities such as the mentioned > 79S361 Evaluation board, without disk storage but with sufficient > RAM and Flash memory? The 36100 CPU has no memory management hardware, which makes it unsuitable for linux/MIPS. Dominic Sweetman Algorithmics Ltd dom@algor.co.uk From alhaz@xmission.com Sun Oct 11 22:08:25 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA11207; Sun, 11 Oct 1998 22:08:24 +0200 (MET DST) Received-Date: Sun, 11 Oct 1998 22:08:24 +0200 (MET DST) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zSRmq-0003Ur-00 for linux-mips@fnet.fr; Sun, 11 Oct 1998 14:08:17 -0600 Sender: alhaz@fnet.fr Message-ID: <3621101A.4C7D545E@xmission.com> Date: Sun, 11 Oct 1998 14:07:54 -0600 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board References: <36215714.1B05@tip.nl> <199810111948.UAA01737@gladsmuir.algor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 644 Lines: 21 Dominic Sweetman wrote: > > Bert, > > > I've a 79S361 Evaluation board from IDT, based upon the > > IDT RC36100 RISController. > > ... > > 2. Could Linux run on a system with capabilities such as the mentioned > > 79S361 Evaluation board, without disk storage but with sufficient > > RAM and Flash memory? > > The 36100 CPU has no memory management hardware, which makes it > unsuitable for linux/MIPS. The ELKS project has done some work on systems that lack MMU hardware, but I don't believe they've even touched MIPS. This is to say that it's plausible, but inadvisable. And probably much more trouble than it's worth. - Eric From ralf@lappi.waldorf-gmbh.de Mon Oct 12 01:11:41 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA14115; Mon, 12 Oct 1998 01:11:40 +0200 (MET DST) Received-Date: Mon, 12 Oct 1998 01:11:40 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-24.uni-koblenz.de [141.26.249.24]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id BAA27082 for ; Mon, 12 Oct 1998 01:11:32 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id BAA01949; Mon, 12 Oct 1998 01:07:01 +0200 Message-ID: <19981012010701.C402@uni-koblenz.de> Date: Mon, 12 Oct 1998 01:07:01 +0200 From: ralf@uni-koblenz.de To: Eric Jorgensen , linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board References: <36215714.1B05@tip.nl> <199810111948.UAA01737@gladsmuir.algor.co.uk> <3621101A.4C7D545E@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <3621101A.4C7D545E@xmission.com>; from Eric Jorgensen on Sun, Oct 11, 1998 at 02:07:54PM -0600 Content-Length: 410 Lines: 11 On Sun, Oct 11, 1998 at 02:07:54PM -0600, Eric Jorgensen wrote: > The ELKS project has done some work on systems that lack MMU hardware, > but I don't believe they've even touched MIPS. This is to say that it's > plausible, but inadvisable. And probably much more trouble than it's > worth. The ELKS project was actually wrapped around the 8086 segmented architecture, so it isn't really portable. Ralf From imp@village.org Mon Oct 12 01:16:38 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id BAA14158; Mon, 12 Oct 1998 01:16:36 +0200 (MET DST) Received-Date: Mon, 12 Oct 1998 01:16:36 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zSUix-00001q-00; Sun, 11 Oct 1998 17:16:27 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id RAA04469 for ; Sun, 11 Oct 1998 17:16:06 -0600 (MDT) Message-Id: <199810112316.RAA04469@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board In-reply-to: Your message of "Sun, 11 Oct 1998 20:48:49 BST." <199810111948.UAA01737@gladsmuir.algor.co.uk> References: <199810111948.UAA01737@gladsmuir.algor.co.uk> <36215714.1B05@tip.nl> Date: Sun, 11 Oct 1998 17:16:06 -0600 From: Warner Losh Content-Length: 443 Lines: 12 In message <199810111948.UAA01737@gladsmuir.algor.co.uk> Dominic Sweetman writes: : The 36100 CPU has no memory management hardware, which makes it : unsuitable for linux/MIPS. This is also why the DSP enabled, but MMU challanged, 4650 isn't supported by Linux. Does the 36100 have any MMU at all? The 4650 had base and bounds registers which could be put to use inside of unix, but it would be a huge pain and likely not worth it. Warner From ralf@lappi.waldorf-gmbh.de Mon Oct 12 01:26:08 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA14319; Mon, 12 Oct 1998 01:26:07 +0200 (MET DST) Received-Date: Mon, 12 Oct 1998 01:26:07 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-24.uni-koblenz.de [141.26.249.24]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id BAA02658 for ; Mon, 12 Oct 1998 01:26:04 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id BAA02173; Mon, 12 Oct 1998 01:21:19 +0200 Message-ID: <19981012012119.E402@uni-koblenz.de> Date: Mon, 12 Oct 1998 01:21:19 +0200 From: ralf@uni-koblenz.de To: Warner Losh , linux-mips@fnet.fr Subject: Re: Porting Linux to my 79S361 MIPS board References: <199810111948.UAA01737@gladsmuir.algor.co.uk> <36215714.1B05@tip.nl> <199810111948.UAA01737@gladsmuir.algor.co.uk> <199810112316.RAA04469@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810112316.RAA04469@harmony.village.org>; from Warner Losh on Sun, Oct 11, 1998 at 05:16:06PM -0600 Content-Length: 634 Lines: 17 On Sun, Oct 11, 1998 at 05:16:06PM -0600, Warner Losh wrote: > In message <199810111948.UAA01737@gladsmuir.algor.co.uk> Dominic Sweetman writes: > : The 36100 CPU has no memory management hardware, which makes it > : unsuitable for linux/MIPS. > > This is also why the DSP enabled, but MMU challanged, 4650 isn't > supported by Linux. > > Does the 36100 have any MMU at all? The 4650 had base and bounds > registers which could be put to use inside of unix, but it would be a > huge pain and likely not worth it. It's worth it. If we support the R4650 then we almost support the memory managment of the vector Crays :-) Ralf From bert.morrien@tip.nl Sun Oct 11 18:32:29 1998 Received: from worldonline.nl (leda.worldonline.nl [195.241.48.135]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA09602; Sun, 11 Oct 1998 18:32:24 +0200 (MET DST) Received-Date: Sun, 11 Oct 1998 18:32:24 +0200 (MET DST) Received: from bm (vp183-28.worldonline.nl [195.241.183.28]) by worldonline.nl (8.8.5/8.8.5) with SMTP id SAA15895 for ; Sun, 11 Oct 1998 18:31:59 +0200 (MET DST) Message-ID: <36215714.1B05@tip.nl> Date: Sun, 11 Oct 1998 18:10:45 -0700 From: Bert Morrien Reply-To: bert.morrien@tip.nl Organization: b&d enterprises X-Mailer: Mozilla 3.03Gold (Win95; I) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Porting Linux to my 79S361 MIPS board Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1887 Lines: 60 Dear sirs I've a 79S361 Evaluation board from IDT, based upon the IDT RC36100 RISController. RC36100 on-chip features: - CPU core with MIPS-I Instruction Set Architecture (binary compatible with RC3000 / RC4000 family) - System Control Co-Processor, manages exception handling operations and virtual-to-physical address memory mapping - Clock Generator Unit - 4 KB instruction cache - 1 KB data cache - Bus Interface Unit - Memory Controller - DRAM Controller - I/O Controller - DMA Control and Interface - Counter/Timers - PIO Interface - Serial Communications Controller, dual port, supporting RS-232C, LocalTalk, SDLC and HDLC. - Interrupt Controller - IEE1248 Bidirectional Centronics parallel port Additional 79S361 Evaluation board features: - Interleaved DRAM - SRAM - Flash EPROM - Ethernet port My questions are: 1. Is Linux suitable for embedded (unatended) applications, especially where communication protocol stacks are needed? 2. Could Linux run on a system with capabilities such as the mentioned 79S361 Evaluation board, without disk storage but with sufficient RAM and Flash memory? 3. Can I contribute in some way by porting Linux to my 79S361 board? 4. What would be a good starting point for such a port? Maybe an existing MIPS R4x00 port? I am a retired senior SW engineer, have experience with design and implementation of OS and communication SW. My last professional job was the design of SW for DECT cordless telephony. In the gray past I have implemented UNIX (System V) device drivers, but I am hardly familiar with the Linux kernel. I've installed the GCC 2.7.2 cross-compiler on my Linux system, but I do not yet have a working C library. Best regards Bert Morrien -- Bert Morrien _/-+ mailto:bert.morrien@tip.nl +-\_ Fazantenhof 132 3755 EK Eemnes Tel.: +31 35 5389293 _/-+ http://www.tip.nl/users/bert.morrien +-\_ From roganov@niisi.msk.ru Mon Oct 12 17:34:02 1998 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA20752; Mon, 12 Oct 1998 17:33:51 +0200 (MET DST) Received-Date: Mon, 12 Oct 1998 17:33:51 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id TAA23667 for ; Mon, 12 Oct 1998 19:33:36 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id SAA26757 for linux-mips@fnet.fr; Mon, 12 Oct 1998 18:40:15 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id TAA03343 for ; Mon, 12 Oct 1998 19:13:37 +0300 (MSK) Sender: vladimir@niisi.msk.ru Message-ID: <36221D8F.F5B81197@niisi.msk.ru> Date: Mon, 12 Oct 1998 19:17:35 +0400 From: Vladimir Roganov Organization: NIISI RAS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Linux support for R[34]000-series computers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 5145 Lines: 196 This message is addressed to developers who is working on Linux support for R[34]000-series computers. It is dedicated to Linux/2.1.121 code for R3000. Hello all, hello Harald ! o Strange code detected in 'asm-mips/mmu_context.h' file: extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) { /* check if it's legal.. */ if (((asid & ASID_MASK) >> ASID_SHIFT) > MAX_ASID) { /* start a new version, invalidate all old asid's */ flush_tlb_all(); asid = (asid & ASID_VERSION_MASK) + ASID_FIRST_VERSION; if (!asid) asid = ASID_FIRST_VERSION; } asid_cache = asid + (1 << ASID_SHIFT); mm->context = asid; /* full version + asid */ } The first 'if' condition will never succeed for both R3000/R4000. Yet another problem can (theoretically) lead to security hole: the version counter is only 16-bits long. If we will start a lot of processes, it is possible to obtain same versions for old (long time sleeping) and new process, so we can exchange mapping for some addresses. We do not reproduce it now, but remember about problem with one-byte counter of active I/O requests in RSX-11M system, where after 256 QIO$ directives executive regards task able to swap... :-) It is also looks strange that function 'get_new_mmu_context' takes asid as parameter, due it must be only 'asid_cache' -- all other values can lead to problems. Really, both `r4xx0.c` and `r2300.c` use it only with 'asid_cache' parameter, so may be we eliminate second parameter at all ? Suggested (tested for R3000) code looks fixing above problems, due it uses all bits upper than hardware asid as their version: <<<<<<<<<<<<< /* * All unused by hardware upper bits will be considered * as software asid extension -- asid version. */ #define ASID_VERSION_MASK (~(ASID_MASK|(ASID_MASK-1))) #define ASID_FIRST_VERSION ((~ASID_VERSION_MASK) + 1) extern inline void get_new_mmu_context(struct mm_struct *mm) { /* Version of task asid is zero or obsolete, we should assign actual version and next hardware asid */ /* Increment _full_ asid carefully, to avoid zero version */ if (!(asid_cache += (1<context = asid_cache; } extern inline void get_mmu_context(struct task_struct *p) { struct mm_struct *mm = p->mm; if (mm) { /* Check if our ASID is of an older version and thus invalid */ if ((mm->context ^ asid_cache) & ASID_VERSION_MASK) get_new_mmu_context(mm); } } >>>>>>>>>>>>>>> We also have changed line (in `r2300_resume`): andi a3, KU_USER to: andi a3, ASID_MASK due it eliminates TLB/ASID logic at all. R4xx0-code looks does not have this problem. After this change 'flush_tlb_all()' was removed from 'switch_to' without problems. 'wire_mappings_r3000' which looks present by historical/(futures ?) reasons, does not restore ENTRYHI correctly, what can also lead to problems. Fortunately, it is called only at kernel startup. o Strange code detected in 'lib/memcpy.S' file: Code, checking memmove arguments overlapping, looks like: <<<<<<<<<<< LEAF(memmove) sltu t0, a0, a1 # dst < src -> memcpy bnez t0, memcpy addu v0, a0, a2 sltu t0, v0, a1 # dst + len < src -> non- bnez t0, __memcpy # overlapping, can use memcpy move v0, a0 /* return value */ END(memmove) LEAF(__rmemcpy) /* a0=dst a1=src a2=len */ addu a0, a2 # dst = dst + len addu a1, a2 # src = src + len /* many comments */ r_end_bytes: lb t0, -1(a1) subu a2, a2, 0x1 sb t0, -1(a0) subu a1, a1, 0x1 bnez a2, r_end_bytes subu a0, a0, 0x1 r_out: jr ra move a2, zero >>>>>>>>>>>> First branch is okey: when destination is less than source, we can use memcpy. But second condition checks something strange... Really, see picture: <.........src..........> <---- memcpy <......dst.......> <.........src..........> <.......dst.......> <---- rmemcpy <.........src..........> <....dst....> <---- memcpy So, best check should be: src + len < dst The result is not a bug, but a feature -- in a half of cases use 4-slower code. Suggested (tested) code is following: <<<<<<<<<<<< LEAF(memmove) sltu t0, a0, a1 # dst < src -> memcpy bnez t0, memcpy addu v0, a1, a2 sltu t0, v0, a0 # src + len < dst -> memcpy bnez t0, __memcpy move v0, a0 /* return value */ END(memmove) >>>>>>>>>>>> After above changes were produced, Linux compiles GDB normally (and even seems faster), using two gcc in parallel, and with restored `r2300.c` TLB-optimization code -- we have removed our (introduced for test) TOTAL_TLB_FLUSH logic from one. Gleb Raiko will send our patch to Harald, due we have more fixes, than were described here, so ask Harald for actual code. Please send Your related comments and results, Best wishes, Vladimir From ralf@lappi.waldorf-gmbh.de Tue Oct 13 00:05:08 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA23462; Tue, 13 Oct 1998 00:05:06 +0200 (MET DST) Received-Date: Tue, 13 Oct 1998 00:05:06 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-30.uni-koblenz.de [141.26.249.30]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA03713 for ; Tue, 13 Oct 1998 00:05:01 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id UAA03245; Mon, 12 Oct 1998 20:15:09 +0200 Message-ID: <19981012201509.A2812@uni-koblenz.de> Date: Mon, 12 Oct 1998 20:15:09 +0200 From: ralf@uni-koblenz.de To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: R4000SC Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 215 Lines: 7 Hi all, today I've received an R4000SC module which has been sent to me by Ulf Carlsson. Thanks Ulf! I'm quite confident that after finishing todays sad duties I'll be able to fix the problem quite fast. Ralf From ralf@lappi.waldorf-gmbh.de Wed Oct 14 00:35:47 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA03291; Wed, 14 Oct 1998 00:35:45 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 00:35:45 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-03.uni-koblenz.de [141.26.249.3]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA17377 for ; Wed, 14 Oct 1998 00:35:41 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id DAA01162; Tue, 13 Oct 1998 03:11:26 +0200 Message-ID: <19981013031126.E394@uni-koblenz.de> Date: Tue, 13 Oct 1998 03:11:26 +0200 From: ralf@uni-koblenz.de To: Vladimir Roganov , linux-mips@fnet.fr Subject: Re: Linux support for R[34]000-series computers References: <36221D8F.F5B81197@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <36221D8F.F5B81197@niisi.msk.ru>; from Vladimir Roganov on Mon, Oct 12, 1998 at 07:17:35PM +0400 X-Mutt-References: <36221D8F.F5B81197@niisi.msk.ru> Content-Length: 2668 Lines: 80 On Mon, Oct 12, 1998 at 07:17:35PM +0400, Vladimir Roganov wrote: > o Strange code detected in 'asm-mips/mmu_context.h' file: > > extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned > long asid) [...] > The first 'if' condition will never succeed for both R3000/R4000. > > > Yet another problem can (theoretically) lead to security hole: > the version counter is only 16-bits long. > If we will start a lot of processes, it is possible to obtain same > versions > for old (long time sleeping) and new process, so we can exchange mapping > for > some addresses. This version does not have any of the mentioned problems. #define MAX_ASID 0x0fc0 #define ASID_VERSION_SHIFT 16 #define ASID_VERSION_MASK ((~0UL) << ASID_VERSION_SHIFT) #define ASID_VERSION_INC 0x40 #define ASID_FIRST_VERSION (1UL << ASID_VERSION_SHIFT) extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) { /* check if it's legal.. */ if ((asid & ~ASID_VERSION_MASK) > MAX_ASID) { /* start a new version, invalidate all old asid's */ flush_tlb_all(); asid = (asid & ASID_VERSION_MASK) + ASID_FIRST_VERSION; if (!asid) asid = ASID_FIRST_VERSION; } asid_cache = asid + ASID_VERSION_INC; mm->context = asid; /* full version + asid */ } Note that it's just a little bit different from what is shipping in my sources. The whole difference are the values for MAX_ASID and the new definition for ASID_VERSION_INC. Unlike your version this code doesn't have a second if which kills performance. With a little bit of code patching on startup this routine can stay the same for R3000 and R4000 series. > We do not reproduce it now, but remember about problem with one-byte > counter > of active I/O requests in RSX-11M system, where after 256 QIO$ > directives > executive regards task able to swap... :-) Heh, I guess most people don't even know what RSX was. > It is also looks strange that function 'get_new_mmu_context' takes asid > as > parameter, due it must be only 'asid_cache' -- all other values can lead > to problems. Really, both `r4xx0.c` and `r2300.c` use it only with > 'asid_cache' parameter, so may be we eliminate second parameter at all > ? Look at the assembler code generated from this routine by gcc. That's actually quite often the explanation for strange looking Linux code :-) [memcpy ...] > So, best check should be: src + len < dst > > The result is not a bug, but a feature -- in a half of cases use > 4-slower code. The 4 times slower code is actually only being used because there seems to be some capital bug in the code for backward copying which I glued this really _bad_ way. Ralf From cwhalen@nih.gov Tue Oct 13 21:29:08 1998 Received: from atlas.niaid.nih.gov (atlas.niaid.nih.gov [128.231.240.60]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA01019; Tue, 13 Oct 1998 21:29:08 +0200 (MET DST) Received-Date: Tue, 13 Oct 1998 21:29:08 +0200 (MET DST) Received: from nih.gov (128.231.216.62 [128.231.216.62]) by atlas.niaid.nih.gov with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4W7P0SAH; Tue, 13 Oct 1998 15:29:03 -0400 Message-ID: <3623A94A.6EFD0B98@nih.gov> Date: Tue, 13 Oct 1998 15:26:02 -0400 From: Chris Whalen X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: NEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 337 Lines: 7 Any word on getting Linux ported to the RiscServers? I have 4 of these boxes that I am getting ready to reluctantly surplus because they have been damn reliable servers under NT 3.5.1 and 4.0sp3. I would love to have some use for them other than the scrap heap. Thanks for any information, good or bad...... Chris Whalen cwhalen@nih.gov From ralf@lappi.waldorf-gmbh.de Wed Oct 14 00:34:11 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA03246; Wed, 14 Oct 1998 00:34:10 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 00:34:10 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-03.uni-koblenz.de [141.26.249.3]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA16751 for ; Wed, 14 Oct 1998 00:34:06 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id VAA02698; Tue, 13 Oct 1998 21:59:27 +0200 Message-ID: <19981013215927.A2692@uni-koblenz.de> Date: Tue, 13 Oct 1998 21:59:27 +0200 From: ralf@uni-koblenz.de To: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Subject: get_mmu_context() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 2554 Lines: 86 Ok, here is a draft version of an agressively optimized version of get_mmu_context(). I just didn't like the idea of referencing global variables in get_mmu_context() if avoidable. The code below will work on both R3000 and R4000 with no performance penalty for being generic. The trick is to patch the operands of two machine instructions at runtime, shoot me. The code below should be integrated into . The CPU specific code in arch/mips/mm/... will then just have to include that header file and call r3000_asid_setup rsp. r4xx0_asid_setup. Have fun, Ralf #define ASID_VERSION_SHIFT 16 #define ASID_VERSION_MASK ((~0UL) << ASID_VERSION_SHIFT) #define ASID_FIRST_VERSION (1UL << ASID_VERSION_SHIFT) unsigned long asid_cache = ASID_FIRST_VERSION; /* The next two macros know that they will only be assembled once per kernel. */ #define ASID_VERSION_INC \ ({ unsigned long __asid_inc; \ __asm__(".globl\tasid_inc\n" \ "asid_inc:\n\t" \ "li\t%0,0\t\t\t#patched\n\t" \ :"=r" (__asid_inc)); \ __asid_inc; }) #define ASID_OVERFLOW(asid) \ ({ unsigned long __res; \ __asm__(".global\tasid_overflow\n" \ "asid_overflow:\n\t" \ "sltu\t%0,%1,0\t\t\t#patched\n\t" \ :"=r" (__res) \ :"r" (asid)); \ __res; }) extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) { /* check if it's legal.. */ if (ASID_OVERFLOW(asid & ~ASID_VERSION_MASK)) { /* start a new version, invalidate all old asid's */ flush_tlb_all(); asid = (asid & ASID_VERSION_MASK) + ASID_FIRST_VERSION; if (!asid) asid = ASID_FIRST_VERSION; } asid_cache = asid + ASID_VERSION_INC; mm->context = asid; /* full version + asid */ } extern void get_mmu_context(struct task_struct *p) { struct mm_struct *mm = p->mm; if (mm) { unsigned long asid = asid_cache; /* Check if our ASID is of an older version and thus invalid */ if ((mm->context ^ asid) & ASID_VERSION_MASK) get_new_mmu_context(mm, asid); } } extern inline void __asid_setup(unsigned long asid_inc, unsigned long asid_cmp) { extern u32 asid_inc; extern u32 asid_overflow; asid_inc = (asid_inc & 0xffff0000) | asid_inc; flush_icache_range(&asid_inc, 4); asid_overflow = (asid_overflow & 0xffff0000) | asid_cmp; flush_icache_range(&asid_overflow, 4); } extern inline void r3000_asid_setup(void) { __asid_setup(0x40, 0xfc1); } extern inline void r4xx0_asid_setup(void) { __asid_setup(1, 0x100); } From ralf@lappi.waldorf-gmbh.de Wed Oct 14 00:32:37 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA03219; Wed, 14 Oct 1998 00:32:36 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 00:32:36 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-03.uni-koblenz.de [141.26.249.3]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA16126 for ; Wed, 14 Oct 1998 00:32:31 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id WAA02702; Tue, 13 Oct 1998 22:00:43 +0200 Message-ID: <19981013220043.A2620@uni-koblenz.de> Date: Tue, 13 Oct 1998 22:00:43 +0200 From: ralf@uni-koblenz.de To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: R4000SC ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 801 Lines: 18 Hi all, accepting the danger that I'm going to frustrate someone on this list - I managed to get the R4000SC V3.0 going under Linux in less than two hours. I'm now typing this email logged on from my Indy running from local disk to another Linux machine. The worst part was actually to get rid of all the MIPS IV code on my machine before I could do anything useful again with a MIPS III CPU. The patch which I'm going to commit will actually be quite a bit larger than the fixes for the SC actually needed to be because large parts of the support for the SC CPU were overly complex, better-than-nothing implementations or supporting CPU configurations that aren't possible at all. Benefit of all this for everybody is 10kb less kernel code. Time to fix the "CPU too expensive" panic ;-) Ralf From tsbogend@alpha.franken.de Wed Oct 14 00:11:35 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA02192; Wed, 14 Oct 1998 00:11:35 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 00:11:35 +0200 (MET DST) Received: from alpha.franken.de (tsbogend@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA26322; Wed, 14 Oct 1998 00:11:32 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA03901; Wed, 14 Oct 1998 00:09:01 +0200 Message-ID: <19981014000900.A3208@alpha.franken.de> Date: Wed, 14 Oct 1998 00:09:00 +0200 From: Thomas Bogendoerfer To: Chris Whalen , linux-mips@fnet.fr Subject: Re: NEC References: <3623A94A.6EFD0B98@nih.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <3623A94A.6EFD0B98@nih.gov>; from Chris Whalen on Tue, Oct 13, 1998 at 03:26:02PM -0400 Content-Length: 619 Lines: 16 On Tue, Oct 13, 1998 at 03:26:02PM -0400, Chris Whalen wrote: > Any word on getting Linux ported to the RiscServers? it's always matter of getting a machine to the person who is able (time and skill) to do the port and to get enough documentation. Right now none of the Linux/MIPS developers has a Nec machine. Some weeks ago someone offered a Nec SMP machine to Ralf, which I might get. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From ralf@lappi.waldorf-gmbh.de Thu Oct 15 01:38:04 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA12327; Thu, 15 Oct 1998 01:38:03 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 01:38:03 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-29.uni-koblenz.de [141.26.249.29]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id BAA07293 for ; Thu, 15 Oct 1998 01:37:59 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id OAA00789; Wed, 14 Oct 1998 14:24:43 +0200 Message-ID: <19981014142443.F392@uni-koblenz.de> Date: Wed, 14 Oct 1998 14:24:43 +0200 From: ralf@uni-koblenz.de To: tsbogend@alpha.franken.de Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Milo & R4000SC Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 438 Lines: 10 I've just found yet another SC problem. Due bugs in a certain ARC firmware in the FlushAllCaches() function Milo uses it's own cache flushing routine. Which does not has the feature of flushing R4000 caches 32 times in a row, it also doesn't correctly deal with R4000 second level caches. It just happens to work for the Magnum 4000SCs because they use a unified second level cache. Any success in finally getting rid of Milo? Ralf From H.H.vanRiel@phys.uu.nl Wed Oct 14 17:29:45 1998 Received: from max.phys.uu.nl (max.phys.uu.nl [131.211.32.73]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA08277; Wed, 14 Oct 1998 17:29:43 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 17:29:43 +0200 (MET DST) Received: from mirkwood.dummy.home (root@anx1p4.phys.uu.nl [131.211.33.93]) by max.phys.uu.nl (8.8.7/8.8.7/hjm) with ESMTP id RAA01550; Wed, 14 Oct 1998 17:29:27 +0200 (MET DST) Received: from localhost (riel@localhost) by mirkwood.dummy.home (8.9.0/8.8.3) with SMTP id OAA11788; Wed, 14 Oct 1998 14:45:45 GMT X-Authentication-Warning: mirkwood.dummy.home: riel owned process doing -bs Date: Wed, 14 Oct 1998 14:45:45 +0000 (/etc/localtime) From: Rik van Riel X-Sender: riel@mirkwood.dummy.home Reply-To: Rik van Riel To: ralf@uni-koblenz.de cc: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Subject: Re: get_mmu_context() In-Reply-To: <19981013215927.A2692@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1157 Lines: 31 On Tue, 13 Oct 1998 ralf@uni-koblenz.de wrote: > Ok, here is a draft version of an agressively optimized version of > get_mmu_context(). I just didn't like the idea of referencing > global variables in get_mmu_context() if avoidable. The code below > will work on both R3000 and R4000 with no performance penalty for > being generic. The trick is to patch the operands of two machine > instructions at runtime, shoot me. ROFL! No offense to the code, I'm sure it works, but this just _has_ to be the funniest piece of source code to appear on the lists this month... Self-modifying code -- this is so much fun :) > extern inline void r3000_asid_setup(void) > > extern inline void r4xx0_asid_setup(void) Very nice Ralf... My compliments on this piece of code -- I can only imagine the amount of phantasy and inspiration that was needed to create it... tschuess, Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+ From imp@village.org Wed Oct 14 22:36:13 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id WAA10240; Wed, 14 Oct 1998 22:36:11 +0200 (MET DST) Received-Date: Wed, 14 Oct 1998 22:36:11 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zTXeB-0002LD-00; Wed, 14 Oct 1998 14:35:51 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id OAA17102; Wed, 14 Oct 1998 14:36:03 -0600 (MDT) Message-Id: <199810142036.OAA17102@harmony.village.org> To: linux-mips@fnet.fr Cc: cwhalen@nih.gov Subject: Re: NEC In-reply-to: Your message of "Tue, 13 Oct 1998 15:26:02 EDT." <3623A94A.6EFD0B98@nih.gov> References: <3623A94A.6EFD0B98@nih.gov> Date: Wed, 14 Oct 1998 14:36:03 -0600 From: Warner Losh Content-Length: 318 Lines: 8 In message <3623A94A.6EFD0B98@nih.gov> Chris Whalen writes: : Any word on getting Linux ported to the RiscServers? I have made the offer several times to port Linux to the UP version of the RiscServer if someone will ship me one and pay for return shipping when the port is complete. The offer still stands. Warner From mmarch@mindspring.net Thu Oct 15 00:20:00 1998 Received: from db.indirect.com (root@db.indirect.com [165.247.198.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA11477; Thu, 15 Oct 1998 00:19:59 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 00:19:59 +0200 (MET DST) Received: from cowmix (minot.phoenix.mindspring.com [165.247.1.246]) by db.indirect.com (8.8.8/8.8.5) with SMTP id PAA28324 for ; Wed, 14 Oct 1998 15:22:09 -0700 Reply-To: From: "Michael F. March" To: Subject: how do I subscribe to this list? Date: Wed, 14 Oct 1998 15:17:17 -0700 Message-ID: <000501bdf7c0$6772cc00$83010101@cowmix.eng.mindspring.net> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Length: 246 Lines: 8 -- Michael F. March ------- KB7EXY (yep...a tech) ------ mmarch@mindspring.net MindSpring Enterprises, Inc. ------------------------------- Phoenix Office http://business.mindspring.com -------------------------- (602)707-6000x105 From ralf@lappi.waldorf-gmbh.de Fri Oct 16 04:56:10 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA22170; Fri, 16 Oct 1998 04:56:09 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 04:56:09 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-21.uni-koblenz.de [141.26.249.21]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id EAA25149 for ; Fri, 16 Oct 1998 04:56:06 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id BAA01719; Thu, 15 Oct 1998 01:49:55 +0200 Message-ID: <19981015014955.K392@uni-koblenz.de> Date: Thu, 15 Oct 1998 01:49:55 +0200 From: ralf@uni-koblenz.de To: Rik van Riel Cc: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Subject: Re: get_mmu_context() References: <19981013215927.A2692@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Rik van Riel on Wed, Oct 14, 1998 at 02:45:45PM +0000 Content-Length: 1450 Lines: 35 On Wed, Oct 14, 1998 at 02:45:45PM +0000, Rik van Riel wrote: > > Ok, here is a draft version of an agressively optimized version of > > get_mmu_context(). I just didn't like the idea of referencing > > global variables in get_mmu_context() if avoidable. The code below > > will work on both R3000 and R4000 with no performance penalty for > > being generic. The trick is to patch the operands of two machine > > instructions at runtime, shoot me. > > ROFL! No offense to the code, I'm sure it works, but > this just _has_ to be the funniest piece of source > code to appear on the lists this month... > > Self-modifying code -- this is so much fun :) Lame example of self modifying code, it doesn't even modify the instructions and only on bootup. > > extern inline void r3000_asid_setup(void) > > > > extern inline void r4xx0_asid_setup(void) > > Very nice Ralf... My compliments on this piece > of code -- I can only imagine the amount of > phantasy and inspiration that was needed to > create it... Guess why I had to post it :-) Seriously, I didn't like the proposed alternative and some of the older machines which have main memory latencies like 1400ns for shure win each time when _not_ using memory. Even in case of a l1 hit the amount of time wasted for the load should still be visible in context switching times. So, no mercy. Patch as patch can. And maintenance isn't the issue. I messed it up, I maintain it :-) Ralf From triemer@apt4g.a3nyc.com Thu Oct 15 04:28:23 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA13582; Thu, 15 Oct 1998 04:28:21 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 04:28:21 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id WAA04976 for ; Wed, 14 Oct 1998 22:28:34 -0400 Date: Wed, 14 Oct 1998 22:28:31 -0400 (EDT) From: Thomas Riemer To: linux-mips@fnet.fr Subject: DZ-11 interrupts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 590 Lines: 20 Ok - after playing with the dz serial device - I'm getting effectively nowhere - I have enabled the UART scan I have enabled the transmit. I can force one character across - but as far as I can tell the interrupt that is supposed to be generated when the dz11 is ready to process another character never happens. I'm guessing that somehow we are not catching it. What's the best way to approach this? How do I find out what's going on under the hood? -Tom Riemer ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From ralf@lappi.waldorf-gmbh.de Fri Oct 16 04:54:09 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA22095; Fri, 16 Oct 1998 04:54:05 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 04:54:05 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-21.uni-koblenz.de [141.26.249.21]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id EAA24237 for ; Fri, 16 Oct 1998 04:53:47 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA02181; Thu, 15 Oct 1998 12:56:02 +0200 Message-ID: <19981015125602.A2130@uni-koblenz.de> Date: Thu, 15 Oct 1998 12:56:02 +0200 From: ralf@uni-koblenz.de To: Ulf Carlsson Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: R4000SC ... References: <19981013220043.A2620@uni-koblenz.de> <19981014181331.A26597@zigzegv.ml.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=envbJBWh7q8WU6mo X-Mailer: Mutt 0.91.1 In-Reply-To: <19981014181331.A26597@zigzegv.ml.org>; from Ulf Carlsson on Wed, Oct 14, 1998 at 06:13:31PM +0200 Content-Length: 34049 Lines: 1290 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii On Wed, Oct 14, 1998 at 06:13:31PM +0200, Ulf Carlsson wrote: > Can you please explain to me what the fixes actually needed for the SC were? I > am quite interested. Ok, here we go again. Attached the patch which I checked in yesterday. Should tell most easy what I've changed: - The VCE exceptions need special handling in the general exception vector. In particular it's important that we cannot do any cached loads / stores before we've brought caches back to a sane state. So all the old handlers in entry.S and traps.c had to go away. - Some of the cache operations defined in r4xx0.c use Hit_*_SD operations to work on the caches. These have the nice property that they will also invalidate any primary cache line in both icache and dcache that maps to the affected secondary cache line. In other words code sequences like blast_dcache16_page(start); if(text) blast_icache16_page(start); blast_scache16_page(start); can simply be replaced by blast_scache16_page(start); This change does not represent any kind of bug, it's just important performance work because cache instructions are expensive even if there is no work to do, that is no writebacks or invalidates. Aside due to the massive loop unrolling used in that code we just saved us close to 10kb in kernel size. - We had code to support a cache configuration with a data cache linesize of 32 bytes and second level linesize of 16 bytes. Configurations where the second level linesize is smaller than the primary cache linesize are however forbidden, so away with the code. - As you remember I disabled the use of the Create_Dirty_Excl_D based versions of clear_page and copy_page for R4000 / R4400 SC and MC versions as part of the first round of SC fixes. Now I implemented a set of four routines optimized for each possible second level cache linesize. Right now there are only new variants of clear_page; copy_page will come asap. I attempted to implement optimized variants using both Create_Dirty_Excl_SD and Create_Dirty_Excl_D in clear_page but the resulting kernel crashed immediately. Not shure what the cause is. - The untested draft variant of head.S which I mailed to you was not word- aligning the address used to index the primary cache tag array. The effect is somewhat hidden, just occasionally programs will die with SIGBUS. No idea why this is necessary. - One structure in sgiseeq needed extra padding. This was not an actual SC-bug; the driver would have failed on any machine with cachelines larger than 64 bytes. I increased the number of fill bytes to make the driver work with 128 byte linesized caches which is the largest available for the IP22. Somebody asked me why the general exception handler or the VCED / VCEI exception handlers never crash with a VCE exception resulting in a infinite loop. First of all don't do any loads or stores before we've serviced a VCED / VCEI exception, so we can never catch any VCED exception. Second, a VCED / VCEI exception will only occur in case of both a primary and secondary cache hit where the second level cache virtual index is different from the actual virtual address' index bits. In normal live this will never happen since the exception handlers are only accessed via KSEG0 but never mapped. In other words mmaping /dev/mem and just _reading_ the wrong RAM addresses is a safe way to crash the machine. Well, you're not supposed to even try that. Ralf --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=vce-patch diff -u linux/arch/mips/kernel/entry.S:1.14 linux/arch/mips/kernel/entry.S:1.15 --- linux/arch/mips/kernel/entry.S:1.14 Tue Sep 8 21:11:46 1998 +++ linux/arch/mips/kernel/entry.S Wed Oct 14 22:26:26 1998 @@ -152,10 +152,8 @@ BUILD_HANDLER(cpu,cpu,sti,silent) /* #11 */ BUILD_HANDLER(ov,ov,sti,silent) /* #12 */ BUILD_HANDLER(tr,tr,sti,silent) /* #13 */ - BUILD_HANDLER(vcei,vcei,sti,verbose) /* #14 */ BUILD_HANDLER(fpe,fpe,fpe,silent) /* #15 */ BUILD_HANDLER(watch,watch,sti,verbose) /* #23 */ - BUILD_HANDLER(vced,vced,sti,verbose) /* #31 */ BUILD_HANDLER(reserved,reserved,sti,verbose) /* others */ /* diff -u linux/arch/mips/kernel/head.S:1.12 linux/arch/mips/kernel/head.S:1.13 --- linux/arch/mips/kernel/head.S:1.12 Tue May 26 08:16:52 1998 +++ linux/arch/mips/kernel/head.S Wed Oct 14 22:26:27 1998 @@ -19,6 +19,7 @@ #include #include +#include #include #include #include @@ -34,10 +35,10 @@ /* * Reserved space for exception handlers. * Necessary for machines which link their kernels at KSEG0. - * FIXME: We could overwrite some of the useless handlers - * with those actually being used. + * FIXME: Use the initcode feature to get rid of unused handler + * variants. */ - .fill 520 + .fill 0x280 /* * This is space for the interrupt handlers. * After trap_init() they are located at virtual address KSEG0. @@ -322,16 +323,48 @@ NESTED(except_vec3_r4000, 0, sp) .set noat mfc0 k1, CP0_CAUSE - - /* XXX Have to check for VCE's _before_ we do a load or store. */ - - la k0, exception_handlers andi k1, k1, 0x7c + li k0, 31<<2 + beq k1, k0, handle_vced + li k0, 14<<2 + beq k1, k0, handle_vcei + la k0, exception_handlers addu k0, k0, k1 lw k0, (k0) nop jr k0 nop + +/* + * Big shit, we now may have two dirty primary cache lines for the same + * physical address. We can savely invalidate the line pointed to by + * c0_badvaddr because after return from this exception handler the load / + * store will be re-executed. + */ +handle_vced: + mfc0 k0, CP0_BADVADDR + li k1, -4 + and k0, k1 + mtc0 zero, CP0_TAGLO + // nop;nop + cache Index_Store_Tag_D,(k0) + // nop;nop + cache Hit_Writeback_Inv_SD,(k0) + lui k0, %hi(vced_count) + lw k1, %lo(vced_count)(k0) + addiu k1, 1 + sw k1, %lo(vced_count)(k0) + eret + +handle_vcei: + mfc0 k0, CP0_BADVADDR + cache Hit_Writeback_Inv_SD,(k0) # also cleans pi + lui k0, %hi(vcei_count) + lw k1, %lo(vcei_count)(k0) + addiu k1, 1 + sw k1, %lo(vcei_count)(k0) + eret + END(except_vec3_r4000) .set at diff -u linux/arch/mips/kernel/proc.c:1.3 linux/arch/mips/kernel/proc.c:1.4 --- linux/arch/mips/kernel/proc.c:1.3 Thu Oct 2 23:55:16 1997 +++ linux/arch/mips/kernel/proc.c Wed Oct 14 22:27:49 1998 @@ -12,6 +12,7 @@ #include unsigned long unaligned_instructions; +unsigned int vced_count, vcei_count; /* * BUFFER is PAGE_SIZE bytes long. @@ -21,6 +22,7 @@ */ int get_cpuinfo(char *buffer) { + char fmt [64]; const char *cpu_name[] = CPU_NAMES; const char *mach_group_names[] = GROUP_NAMES; const char *mach_unknown_names[] = GROUP_UNKNOWN_NAMES; @@ -71,6 +73,11 @@ dedicated_iv_available ? "yes" : "no"); len += sprintf(buffer + len, "hardware watchpoint\t: %s\n", watch_available ? "yes" : "no"); + + sprintf(fmt, "VCE%%c exceptions\t\t: %s\n", + vce_available ? "%d" : "not available"); + len += sprintf(buffer + len, fmt, 'D', vced_count); + len += sprintf(buffer + len, fmt, 'I', vcei_count); return len; } diff -u linux/arch/mips/kernel/traps.c:1.19 linux/arch/mips/kernel/traps.c:1.20 --- linux/arch/mips/kernel/traps.c:1.19 Thu Aug 20 18:33:18 1998 +++ linux/arch/mips/kernel/traps.c Wed Oct 14 22:26:26 1998 @@ -55,9 +55,7 @@ extern asmlinkage void handle_cpu(void); extern asmlinkage void handle_ov(void); extern asmlinkage void handle_tr(void); -extern asmlinkage void handle_vcei(void); extern asmlinkage void handle_fpe(void); -extern asmlinkage void handle_vced(void); extern asmlinkage void handle_watch(void); extern asmlinkage void handle_reserved(void); @@ -65,6 +63,7 @@ char watch_available = 0; char dedicated_iv_available = 0; +char vce_available = 0; void (*ibe_board_handler)(struct pt_regs *regs); void (*dbe_board_handler)(struct pt_regs *regs); @@ -359,24 +358,6 @@ force_sig(SIGILL, current); } -void do_vcei(struct pt_regs *regs) -{ - /* - * Only possible on R4[04]00[SM]C. No handler because I don't have - * such a cpu. Theory says this exception doesn't happen. - */ - panic("Caught VCEI exception - should not happen"); -} - -void do_vced(struct pt_regs *regs) -{ - /* - * Only possible on R4[04]00[SM]C. No handler because I don't have - * such a cpu. Theory says this exception doesn't happen. - */ - panic("Caught VCE exception - should not happen"); -} - void do_watch(struct pt_regs *regs) { /* @@ -513,11 +494,8 @@ case CPU_R4400MC: case CPU_R4000SC: case CPU_R4400SC: - /* XXX The following won't work because we _cannot_ - * XXX perform any load/store before the VCE handler. - */ - set_except_vector(14, handle_vcei); - set_except_vector(31, handle_vced); + vce_available = 1; + /* Fall through ... */ case CPU_R4000PC: case CPU_R4400PC: case CPU_R4200: @@ -533,13 +511,16 @@ else memcpy((void *)KSEG0, &except_vec0_r4000, 0x80); - /* - * The idea is that this special r4000 general exception - * vector will check for VCE exceptions before calling - * out of the exception array. XXX TODO - */ + /* Cache error vector */ memcpy((void *)(KSEG0 + 0x100), (void *) KSEG0, 0x80); - memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, 0x80); + + if (vce_available) { + memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, + 0x180); + } else { + memcpy((void *)(KSEG0 + 0x180), &except_vec3_generic, + 0x100); + } save_fp_context = r4k_save_fp_context; restore_fp_context = r4k_restore_fp_context; diff -u linux/arch/mips/mm/r4xx0.c:1.28 linux/arch/mips/mm/r4xx0.c:1.29 --- linux/arch/mips/mm/r4xx0.c:1.28 Tue Aug 18 22:45:08 1998 +++ linux/arch/mips/mm/r4xx0.c Wed Oct 14 22:29:59 1998 @@ -41,7 +41,7 @@ static int ic_lsize, dc_lsize; /* LineSize in bytes */ /* Secondary cache (if present) parameters. */ -static unsigned long scache_size, sc_lsize; /* Again, in bytes */ +static unsigned int scache_size, sc_lsize; /* Again, in bytes */ #include #include @@ -78,10 +78,7 @@ * - a version which handles the buggy R4600 v1.x * - a version which handles the buggy R4600 v2.0 * - Finally a last version without fancy cache games for the SC and MC - * versions of R4000 and R4400. Cache instructions are quite expensive - * and I guess using them for both the primary and the second level cache - * wouldn't be worth the effort. - * This needs to be verified by benchmarking. + * versions of R4000 and R4400. */ static void r4k_clear_page_d16(unsigned long page) @@ -245,14 +242,84 @@ restore_flags(flags); } -static void r4k_clear_page(unsigned long page) +/* + * The next 4 versions are optimized for all possible scache configurations + * of the SC / MC versions of R4000 and R4400 ... + * + * Todo: For even better performance we should have a routine optimized for + * every legal combination of dcache / scache linesize. When I (Ralf) tried + * this the kernel crashed shortly after mounting the root filesystem. CPU + * bug? Weirdo cache instruction semantics? + */ +static void r4k_clear_page_s16(unsigned long page) +{ + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%2\n" + "1:\tcache\t%3,(%0)\n\t" + "sd\t$0,(%0)\n\t" + "sd\t$0,8(%0)\n\t" + "cache\t%3,16(%0)\n\t" + "sd\t$0,16(%0)\n\t" + "sd\t$0,24(%0)\n\t" + "daddiu\t%0,64\n\t" + "cache\t%3,-32(%0)\n\t" + "sd\t$0,-32(%0)\n\t" + "sd\t$0,-24(%0)\n\t" + "cache\t%3,-16(%0)\n\t" + "sd\t$0,-16(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sd\t$0,-8(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (page) + :"0" (page), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD) + :"$1","memory"); +} + +static void r4k_clear_page_s32(unsigned long page) +{ + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%2\n" + "1:\tcache\t%3,(%0)\n\t" + "sd\t$0,(%0)\n\t" + "sd\t$0,8(%0)\n\t" + "sd\t$0,16(%0)\n\t" + "sd\t$0,24(%0)\n\t" + "daddiu\t%0,64\n\t" + "cache\t%3,-32(%0)\n\t" + "sd\t$0,-32(%0)\n\t" + "sd\t$0,-24(%0)\n\t" + "sd\t$0,-16(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sd\t$0,-8(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (page) + :"0" (page), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD) + :"$1","memory"); +} + +static void r4k_clear_page_s64(unsigned long page) { __asm__ __volatile__( ".set\tnoreorder\n\t" ".set\tnoat\n\t" ".set\tmips3\n\t" "daddiu\t$1,%0,%2\n" - "1:\tsd\t$0,(%0)\n\t" + "1:\tcache\t%3,(%0)\n\t" + "sd\t$0,(%0)\n\t" "sd\t$0,8(%0)\n\t" "sd\t$0,16(%0)\n\t" "sd\t$0,24(%0)\n\t" @@ -267,7 +334,44 @@ ".set\treorder" :"=r" (page) :"0" (page), - "I" (PAGE_SIZE) + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD) + :"$1","memory"); +} + +static void r4k_clear_page_s128(unsigned long page) +{ + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%2\n" + "1:\tcache\t%3,(%0)\n\t" + "sd\t$0,(%0)\n\t" + "sd\t$0,8(%0)\n\t" + "sd\t$0,16(%0)\n\t" + "sd\t$0,24(%0)\n\t" + "sd\t$0,32(%0)\n\t" + "sd\t$0,40(%0)\n\t" + "sd\t$0,48(%0)\n\t" + "sd\t$0,56(%0)\n\t" + "daddiu\t%0,128\n\t" + "sd\t$0,-64(%0)\n\t" + "sd\t$0,-56(%0)\n\t" + "sd\t$0,-48(%0)\n\t" + "sd\t$0,-40(%0)\n\t" + "sd\t$0,-32(%0)\n\t" + "sd\t$0,-24(%0)\n\t" + "sd\t$0,-16(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sd\t$0,-8(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (page) + :"0" (page), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD) :"$1","memory"); } @@ -529,7 +633,10 @@ restore_flags(flags); } -static void r4k_copy_page(unsigned long to, unsigned long from) +/* + * These are for R4000SC / R4400MC + */ +static void r4k_copy_page_s16(unsigned long to, unsigned long from) { unsigned long dummy1, dummy2; unsigned long reg1, reg2, reg3, reg4; @@ -539,7 +646,8 @@ ".set\tnoat\n\t" ".set\tmips3\n\t" "daddiu\t$1,%0,%8\n" - "1:\tlw\t%2,(%1)\n\t" + "1:\tcache\t%9,(%0)\n\t" + "lw\t%2,(%1)\n\t" "lw\t%3,4(%1)\n\t" "lw\t%4,8(%1)\n\t" "lw\t%5,12(%1)\n\t" @@ -547,6 +655,7 @@ "sw\t%3,4(%0)\n\t" "sw\t%4,8(%0)\n\t" "sw\t%5,12(%0)\n\t" + "cache\t%9,16(%0)\n\t" "lw\t%2,16(%1)\n\t" "lw\t%3,20(%1)\n\t" "lw\t%4,24(%1)\n\t" @@ -555,6 +664,7 @@ "sw\t%3,20(%0)\n\t" "sw\t%4,24(%0)\n\t" "sw\t%5,28(%0)\n\t" + "cache\t%9,32(%0)\n\t" "daddiu\t%0,64\n\t" "daddiu\t%1,64\n\t" "lw\t%2,-32(%1)\n\t" @@ -565,6 +675,208 @@ "sw\t%3,-28(%0)\n\t" "sw\t%4,-24(%0)\n\t" "sw\t%5,-20(%0)\n\t" + "cache\t%9,-16(%0)\n\t" + "lw\t%2,-16(%1)\n\t" + "lw\t%3,-12(%1)\n\t" + "lw\t%4,-8(%1)\n\t" + "lw\t%5,-4(%1)\n\t" + "sw\t%2,-16(%0)\n\t" + "sw\t%3,-12(%0)\n\t" + "sw\t%4,-8(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sw\t%5,-4(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (dummy1), "=r" (dummy2), + "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) + :"0" (to), "1" (from), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD)); +} + +static void r4k_copy_page_s32(unsigned long to, unsigned long from) +{ + unsigned long dummy1, dummy2; + unsigned long reg1, reg2, reg3, reg4; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%8\n" + "1:\tcache\t%9,(%0)\n\t" + "lw\t%2,(%1)\n\t" + "lw\t%3,4(%1)\n\t" + "lw\t%4,8(%1)\n\t" + "lw\t%5,12(%1)\n\t" + "sw\t%2,(%0)\n\t" + "sw\t%3,4(%0)\n\t" + "sw\t%4,8(%0)\n\t" + "sw\t%5,12(%0)\n\t" + "lw\t%2,16(%1)\n\t" + "lw\t%3,20(%1)\n\t" + "lw\t%4,24(%1)\n\t" + "lw\t%5,28(%1)\n\t" + "sw\t%2,16(%0)\n\t" + "sw\t%3,20(%0)\n\t" + "sw\t%4,24(%0)\n\t" + "sw\t%5,28(%0)\n\t" + "cache\t%9,32(%0)\n\t" + "daddiu\t%0,64\n\t" + "daddiu\t%1,64\n\t" + "lw\t%2,-32(%1)\n\t" + "lw\t%3,-28(%1)\n\t" + "lw\t%4,-24(%1)\n\t" + "lw\t%5,-20(%1)\n\t" + "sw\t%2,-32(%0)\n\t" + "sw\t%3,-28(%0)\n\t" + "sw\t%4,-24(%0)\n\t" + "sw\t%5,-20(%0)\n\t" + "lw\t%2,-16(%1)\n\t" + "lw\t%3,-12(%1)\n\t" + "lw\t%4,-8(%1)\n\t" + "lw\t%5,-4(%1)\n\t" + "sw\t%2,-16(%0)\n\t" + "sw\t%3,-12(%0)\n\t" + "sw\t%4,-8(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sw\t%5,-4(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (dummy1), "=r" (dummy2), + "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) + :"0" (to), "1" (from), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD)); +} + +static void r4k_copy_page_s64(unsigned long to, unsigned long from) +{ + unsigned long dummy1, dummy2; + unsigned long reg1, reg2, reg3, reg4; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%8\n" + "1:\tcache\t%9,(%0)\n\t" + "lw\t%2,(%1)\n\t" + "lw\t%3,4(%1)\n\t" + "lw\t%4,8(%1)\n\t" + "lw\t%5,12(%1)\n\t" + "sw\t%2,(%0)\n\t" + "sw\t%3,4(%0)\n\t" + "sw\t%4,8(%0)\n\t" + "sw\t%5,12(%0)\n\t" + "lw\t%2,16(%1)\n\t" + "lw\t%3,20(%1)\n\t" + "lw\t%4,24(%1)\n\t" + "lw\t%5,28(%1)\n\t" + "sw\t%2,16(%0)\n\t" + "sw\t%3,20(%0)\n\t" + "sw\t%4,24(%0)\n\t" + "sw\t%5,28(%0)\n\t" + "daddiu\t%0,64\n\t" + "daddiu\t%1,64\n\t" + "lw\t%2,-32(%1)\n\t" + "lw\t%3,-28(%1)\n\t" + "lw\t%4,-24(%1)\n\t" + "lw\t%5,-20(%1)\n\t" + "sw\t%2,-32(%0)\n\t" + "sw\t%3,-28(%0)\n\t" + "sw\t%4,-24(%0)\n\t" + "sw\t%5,-20(%0)\n\t" + "lw\t%2,-16(%1)\n\t" + "lw\t%3,-12(%1)\n\t" + "lw\t%4,-8(%1)\n\t" + "lw\t%5,-4(%1)\n\t" + "sw\t%2,-16(%0)\n\t" + "sw\t%3,-12(%0)\n\t" + "sw\t%4,-8(%0)\n\t" + "bne\t$1,%0,1b\n\t" + "sw\t%5,-4(%0)\n\t" + ".set\tmips0\n\t" + ".set\tat\n\t" + ".set\treorder" + :"=r" (dummy1), "=r" (dummy2), + "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) + :"0" (to), "1" (from), + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD)); +} + +static void r4k_copy_page_s128(unsigned long to, unsigned long from) +{ + unsigned long dummy1, dummy2; + unsigned long reg1, reg2, reg3, reg4; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + ".set\tmips3\n\t" + "daddiu\t$1,%0,%8\n" + "1:\tcache\t%9,(%0)\n\t" + "lw\t%2,(%1)\n\t" + "lw\t%3,4(%1)\n\t" + "lw\t%4,8(%1)\n\t" + "lw\t%5,12(%1)\n\t" + "sw\t%2,(%0)\n\t" + "sw\t%3,4(%0)\n\t" + "sw\t%4,8(%0)\n\t" + "sw\t%5,12(%0)\n\t" + "lw\t%2,16(%1)\n\t" + "lw\t%3,20(%1)\n\t" + "lw\t%4,24(%1)\n\t" + "lw\t%5,28(%1)\n\t" + "sw\t%2,16(%0)\n\t" + "sw\t%3,20(%0)\n\t" + "sw\t%4,24(%0)\n\t" + "sw\t%5,28(%0)\n\t" + "lw\t%2,32(%1)\n\t" + "lw\t%3,36(%1)\n\t" + "lw\t%4,40(%1)\n\t" + "lw\t%5,44(%1)\n\t" + "sw\t%2,32(%0)\n\t" + "sw\t%3,36(%0)\n\t" + "sw\t%4,40(%0)\n\t" + "sw\t%5,44(%0)\n\t" + "lw\t%2,48(%1)\n\t" + "lw\t%3,52(%1)\n\t" + "lw\t%4,56(%1)\n\t" + "lw\t%5,60(%1)\n\t" + "sw\t%2,48(%0)\n\t" + "sw\t%3,52(%0)\n\t" + "sw\t%4,56(%0)\n\t" + "sw\t%5,60(%0)\n\t" + "daddiu\t%0,128\n\t" + "daddiu\t%1,128\n\t" + "lw\t%2,-64(%1)\n\t" + "lw\t%3,-60(%1)\n\t" + "lw\t%4,-56(%1)\n\t" + "lw\t%5,-52(%1)\n\t" + "sw\t%2,-64(%0)\n\t" + "sw\t%3,-60(%0)\n\t" + "sw\t%4,-56(%0)\n\t" + "sw\t%5,-52(%0)\n\t" + "lw\t%2,-48(%1)\n\t" + "lw\t%3,-44(%1)\n\t" + "lw\t%4,-40(%1)\n\t" + "lw\t%5,-36(%1)\n\t" + "sw\t%2,-48(%0)\n\t" + "sw\t%3,-44(%0)\n\t" + "sw\t%4,-40(%0)\n\t" + "sw\t%5,-36(%0)\n\t" + "lw\t%2,-32(%1)\n\t" + "lw\t%3,-28(%1)\n\t" + "lw\t%4,-24(%1)\n\t" + "lw\t%5,-20(%1)\n\t" + "sw\t%2,-32(%0)\n\t" + "sw\t%3,-28(%0)\n\t" + "sw\t%4,-24(%0)\n\t" + "sw\t%5,-20(%0)\n\t" "lw\t%2,-16(%1)\n\t" "lw\t%3,-12(%1)\n\t" "lw\t%4,-8(%1)\n\t" @@ -580,9 +892,11 @@ :"=r" (dummy1), "=r" (dummy2), "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) :"0" (to), "1" (from), - "I" (PAGE_SIZE)); + "I" (PAGE_SIZE), + "i" (Create_Dirty_Excl_SD)); } + /* * If you think for one second that this stuff coming up is a lot * of bulky code eating too many kernel cache lines. Think _again_. @@ -632,15 +946,6 @@ restore_flags(flags); } -static inline void r4k_flush_cache_all_s16d32i32(void) -{ - unsigned long flags; - - save_and_cli(flags); - blast_dcache32(); blast_icache32(); blast_scache16(); - restore_flags(flags); -} - static inline void r4k_flush_cache_all_s32d32i32(void) { unsigned long flags; @@ -718,12 +1023,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache16_page(start); - if(text) - blast_icache16_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache16_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -763,12 +1064,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache16_page(start); - if(text) - blast_icache16_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache32_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -807,12 +1104,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache16_page(start); - if(text) - blast_icache16_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache64_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -851,56 +1144,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache16_page(start); - if(text) - blast_icache16_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache128_page(start); - } - start += PAGE_SIZE; - } - restore_flags(flags); - } - } -} - -static void r4k_flush_cache_range_s16d32i32(struct mm_struct *mm, - unsigned long start, - unsigned long end) -{ - struct vm_area_struct *vma; - unsigned long flags; - - if(mm->context == 0) - return; - - start &= PAGE_MASK; -#ifdef DEBUG_CACHE - printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); -#endif - vma = find_vma(mm, start); - if(vma) { - if(mm->context != current->mm->context) { - r4k_flush_cache_all_s16d32i32(); - } else { - pgd_t *pgd; - pmd_t *pmd; - pte_t *pte; - int text; - - save_and_cli(flags); - text = vma->vm_flags & VM_EXEC; - while(start < end) { - pgd = pgd_offset(mm, start); - pmd = pmd_offset(pgd, start); - pte = pte_offset(pmd, start); - - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache32_page(start); - if(text) - blast_icache32_page(start); - blast_scache16_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -939,12 +1184,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache32_page(start); - if(text) - blast_icache32_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache32_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -983,12 +1224,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache32_page(start); - if(text) - blast_icache32_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache64_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -1027,12 +1264,8 @@ pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); - if(pte_val(*pte) & _PAGE_VALID) { - blast_dcache32_page(start); - if(text) - blast_icache32_page(start); + if(pte_val(*pte) & _PAGE_VALID) blast_scache128_page(start); - } start += PAGE_SIZE; } restore_flags(flags); @@ -1117,16 +1350,6 @@ } } -static void r4k_flush_cache_mm_s16d32i32(struct mm_struct *mm) -{ - if(mm->context != 0) { -#ifdef DEBUG_CACHE - printk("cmm[%d]", (int)mm->context); -#endif - r4k_flush_cache_all_s16d32i32(); - } -} - static void r4k_flush_cache_mm_s32d32i32(struct mm_struct *mm) { if(mm->context != 0) { @@ -1225,12 +1448,8 @@ if(text) blast_icache16_page_indexed(page); blast_scache16_page_indexed(page); - } else { - blast_dcache16_page(page); - if(text) - blast_icache16_page(page); + } else blast_scache16_page(page); - } out: restore_flags(flags); } @@ -1282,12 +1501,8 @@ if(text) blast_icache16_page_indexed(page); blast_scache32_page_indexed(page); - } else { - blast_dcache16_page(page); - if(text) - blast_icache16_page(page); + } else blast_scache32_page(page); - } out: restore_flags(flags); } @@ -1340,12 +1555,8 @@ if(text) blast_icache16_page_indexed(page); blast_scache64_page_indexed(page); - } else { - blast_dcache16_page(page); - if(text) - blast_icache16_page(page); + } else blast_scache64_page(page); - } out: restore_flags(flags); } @@ -1399,70 +1610,8 @@ if(text) blast_icache16_page_indexed(page); blast_scache128_page_indexed(page); - } else { - blast_dcache16_page(page); - if(text) - blast_icache16_page(page); + } else blast_scache128_page(page); - } -out: - restore_flags(flags); -} - -static void r4k_flush_cache_page_s16d32i32(struct vm_area_struct *vma, - unsigned long page) -{ - struct mm_struct *mm = vma->vm_mm; - unsigned long flags; - pgd_t *pgdp; - pmd_t *pmdp; - pte_t *ptep; - int text; - - /* - * If ownes no valid ASID yet, cannot possibly have gotten - * this page into the cache. - */ - if(mm->context == 0) - return; - -#ifdef DEBUG_CACHE - printk("cpage[%d,%08lx]", (int)mm->context, page); -#endif - save_and_cli(flags); - page &= PAGE_MASK; - pgdp = pgd_offset(mm, page); - pmdp = pmd_offset(pgdp, page); - ptep = pte_offset(pmdp, page); - - /* If the page isn't marked valid, the page cannot possibly be - * in the cache. - */ - if(!(pte_val(*ptep) & _PAGE_VALID)) - goto out; - - text = (vma->vm_flags & VM_EXEC); - /* - * Doing flushes for another ASID than the current one is - * too difficult since stupid R4k caches do a TLB translation - * for every cache flush operation. So we do indexed flushes - * in that case, which doesn't overly flush the cache too much. - */ - if(mm->context != current->mm->context) { - /* Do indexed flush, too much work to get the (possible) - * tlb refills to work correctly. - */ - page = (KSEG0 + (page & (scache_size - 1))); - blast_dcache32_page_indexed(page); - if(text) - blast_icache32_page_indexed(page); - blast_scache16_page_indexed(page); - } else { - blast_dcache32_page(page); - if(text) - blast_icache32_page(page); - blast_scache16_page(page); - } out: restore_flags(flags); } @@ -1517,12 +1666,8 @@ if(text) blast_icache32_page_indexed(page); blast_scache32_page_indexed(page); - } else { - blast_dcache32_page(page); - if(text) - blast_icache32_page(page); + } else blast_scache32_page(page); - } out: restore_flags(flags); } @@ -1577,12 +1722,8 @@ if(text) blast_icache32_page_indexed(page); blast_scache64_page_indexed(page); - } else { - blast_dcache32_page(page); - if(text) - blast_icache32_page(page); + } else blast_scache64_page(page); - } out: restore_flags(flags); } @@ -1635,12 +1776,8 @@ if(text) blast_icache32_page_indexed(page); blast_scache128_page_indexed(page); - } else { - blast_dcache32_page(page); - if(text) - blast_icache32_page(page); + } else blast_scache128_page(page); - } out: restore_flags(flags); } @@ -1832,15 +1969,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache16_page(page); blast_scache16_page(page); - restore_flags(flags); } } @@ -1848,15 +1980,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache16_page(page); blast_scache32_page(page); - restore_flags(flags); } } @@ -1864,15 +1991,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache16_page(page); blast_scache64_page(page); - restore_flags(flags); } } @@ -1880,31 +2002,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache16_page(page); blast_scache128_page(page); - restore_flags(flags); - } -} - -static void r4k_flush_page_to_ram_s16d32i32(unsigned long page) -{ - page &= PAGE_MASK; - if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - -#ifdef DEBUG_CACHE - printk("cram[%08lx]", page); -#endif - save_and_cli(flags); - blast_dcache32_page(page); - blast_scache16_page(page); - restore_flags(flags); } } @@ -1912,15 +2013,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache32_page(page); blast_scache32_page(page); - restore_flags(flags); } } @@ -1928,15 +2024,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache32_page(page); blast_scache64_page(page); - restore_flags(flags); } } @@ -1944,15 +2035,10 @@ { page &= PAGE_MASK; if((page >= KSEG0 && page < KSEG1) || (page >= KSEG2)) { - unsigned long flags; - #ifdef DEBUG_CACHE printk("cram[%08lx]", page); #endif - save_and_cli(flags); - blast_dcache32_page(page); blast_scache128_page(page); - restore_flags(flags); } } @@ -2026,20 +2112,10 @@ r4k_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size) { unsigned long end, a; - unsigned int flags; if (size >= scache_size) { flush_cache_all(); - } else { - save_and_cli(flags); - a = addr & ~(dc_lsize - 1); - end = (addr + size) & ~(dc_lsize - 1); - while (1) { - flush_dcache_line(a); /* Hit_Writeback_Inv_D */ - if (a == end) break; - a += dc_lsize; - } - restore_flags(flags); + return; } a = addr & ~(sc_lsize - 1); @@ -2081,20 +2157,10 @@ r4k_dma_cache_inv_sc(unsigned long addr, unsigned long size) { unsigned long end, a; - unsigned int flags; if (size >= scache_size) { flush_cache_all(); - } else { - save_and_cli(flags); - a = addr & ~(dc_lsize - 1); - end = (addr + size) & ~(dc_lsize - 1); - while (1) { - flush_dcache_line(a); /* Hit_Writeback_Inv_D */ - if (a == end) break; - a += dc_lsize; - } - restore_flags(flags); + return; } a = addr & ~(sc_lsize - 1); @@ -2546,8 +2612,8 @@ } restore_flags(flags); addr -= begin; - printk("Secondary cache sized at %dK linesize %d\n", (int) (addr >> 10), - sc_lsize); + printk("Secondary cache sized at %dK linesize %d\n", + (int) (addr >> 10), sc_lsize); scache_size = addr; return 1; } @@ -2602,13 +2668,10 @@ flush_page_to_ram = r4k_flush_page_to_ram_s16d16i16; break; case 32: - flush_cache_all = r4k_flush_cache_all_s16d32i32; - flush_cache_mm = r4k_flush_cache_mm_s16d32i32; - flush_cache_range = r4k_flush_cache_range_s16d32i32; - flush_cache_page = r4k_flush_cache_page_s16d32i32; - flush_page_to_ram = r4k_flush_page_to_ram_s16d32i32; - break; + panic("Invalid cache configuration detected"); }; + clear_page = r4k_clear_page_s16; + copy_page = r4k_copy_page_s16; break; case 32: switch(dc_lsize) { @@ -2627,6 +2690,9 @@ flush_page_to_ram = r4k_flush_page_to_ram_s32d32i32; break; }; + clear_page = r4k_clear_page_s32; + copy_page = r4k_copy_page_s32; + break; case 64: switch(dc_lsize) { case 16: @@ -2644,6 +2710,9 @@ flush_page_to_ram = r4k_flush_page_to_ram_s64d32i32; break; }; + clear_page = r4k_clear_page_s64; + copy_page = r4k_copy_page_s64; + break; case 128: switch(dc_lsize) { case 16: @@ -2661,10 +2730,10 @@ flush_page_to_ram = r4k_flush_page_to_ram_s128d32i32; break; }; + clear_page = r4k_clear_page_s128; + copy_page = r4k_copy_page_s128; break; } - clear_page = r4k_clear_page; - copy_page = r4k_copy_page; dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc; dma_cache_inv = r4k_dma_cache_inv_sc; } diff -u linux/drivers/net/sgiseeq.c:1.8 linux/drivers/net/sgiseeq.c:1.9 --- linux/drivers/net/sgiseeq.c:1.8 Wed Aug 19 23:55:06 1998 +++ linux/drivers/net/sgiseeq.c Wed Oct 14 22:22:48 1998 @@ -86,7 +86,7 @@ /* Ptrs to the descriptors in KSEG1 uncached space. */ struct sgiseeq_rx_desc *rx_desc; struct sgiseeq_tx_desc *tx_desc; - unsigned long _padding[14]; /* Pad out to largest cache line size. */ + unsigned long _padding[30]; /* Pad out to largest cache line size. */ struct sgiseeq_rx_desc rxvector[SEEQ_RX_BUFFERS]; struct sgiseeq_tx_desc txvector[SEEQ_TX_BUFFERS]; diff -u linux/include/asm-mips/processor.h:1.17 linux/include/asm-mips/processor.h:1.18 --- linux/include/asm-mips/processor.h:1.17 Tue Aug 18 22:46:41 1998 +++ linux/include/asm-mips/processor.h Wed Oct 14 22:31:12 1998 @@ -30,8 +30,10 @@ extern char wait_available; /* only available on R4[26]00 */ extern char cyclecounter_available; /* only available from R4000 upwards. */ extern char dedicated_iv_available; /* some embedded MIPS like Nevada */ +extern char vce_available; /* Supports VCED / VCEI exceptions */ extern struct mips_cpuinfo boot_cpu_data; +extern unsigned int vced_count, vcei_count; #ifdef __SMP__ extern struct mips_cpuinfo cpu_data[]; --envbJBWh7q8WU6mo-- From roganov@niisi.msk.ru Thu Oct 15 13:14:21 1998 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA15895; Thu, 15 Oct 1998 13:14:06 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 13:14:06 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA13835; Thu, 15 Oct 1998 15:07:46 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA18619; Thu, 15 Oct 1998 14:17:08 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA26227; Thu, 15 Oct 1998 15:04:03 +0300 (MSK) Sender: vladimir@niisi.msk.ru Message-ID: <3625D799.7D923FA9@niisi.msk.ru> Date: Thu, 15 Oct 1998 15:08:09 +0400 From: Vladimir Roganov Organization: NIISI RAS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ralf@uni-koblenz.de, linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu Subject: Re: get_mmu_context() References: <19981013215927.A2692@uni-koblenz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 6588 Lines: 182 ralf@uni-koblenz.de wrote: > > Ok, here is a draft version of an agressively optimized version of > get_mmu_context(). I just didn't like the idea of referencing > global variables in get_mmu_context() if avoidable. The code below > will work on both R3000 and R4000 with no performance penalty for > being generic. The trick is to patch the operands of two machine > instructions at runtime, shoot me. > > The code below should be integrated into . The > CPU specific code in arch/mips/mm/... will then just have to include > that header file and call r3000_asid_setup rsp. r4xx0_asid_setup. > > Have fun, > > Ralf > > #define ASID_VERSION_SHIFT 16 > #define ASID_VERSION_MASK ((~0UL) << ASID_VERSION_SHIFT) > #define ASID_FIRST_VERSION (1UL << ASID_VERSION_SHIFT) > > unsigned long asid_cache = ASID_FIRST_VERSION; > > /* The next two macros know that they will only be assembled once > per kernel. */ > #define ASID_VERSION_INC \ > ({ unsigned long __asid_inc; \ > __asm__(".globl\tasid_inc\n" \ > "asid_inc:\n\t" \ > "li\t%0,0\t\t\t#patched\n\t" \ > :"=r" (__asid_inc)); \ > __asid_inc; }) > > #define ASID_OVERFLOW(asid) \ > ({ unsigned long __res; \ > __asm__(".global\tasid_overflow\n" \ > "asid_overflow:\n\t" \ > "sltu\t%0,%1,0\t\t\t#patched\n\t" \ > :"=r" (__res) \ > :"r" (asid)); \ > __res; }) > > extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) > { > /* check if it's legal.. */ > if (ASID_OVERFLOW(asid & ~ASID_VERSION_MASK)) { > /* start a new version, invalidate all old asid's */ > flush_tlb_all(); > asid = (asid & ASID_VERSION_MASK) + ASID_FIRST_VERSION; > if (!asid) > asid = ASID_FIRST_VERSION; > } > asid_cache = asid + ASID_VERSION_INC; > mm->context = asid; /* full version + asid */ > } > > extern void get_mmu_context(struct task_struct *p) > { > struct mm_struct *mm = p->mm; > > if (mm) { > unsigned long asid = asid_cache; > /* Check if our ASID is of an older version and thus invalid */ > if ((mm->context ^ asid) & ASID_VERSION_MASK) > get_new_mmu_context(mm, asid); > } > } > > extern inline void __asid_setup(unsigned long asid_inc, unsigned long asid_cmp) > { > extern u32 asid_inc; > extern u32 asid_overflow; > > asid_inc = (asid_inc & 0xffff0000) | asid_inc; > flush_icache_range(&asid_inc, 4); > asid_overflow = (asid_overflow & 0xffff0000) | asid_cmp; > flush_icache_range(&asid_overflow, 4); > } > > extern inline void r3000_asid_setup(void) > { > __asid_setup(0x40, 0xfc1); > } > > extern inline void r4xx0_asid_setup(void) > { > __asid_setup(1, 0x100); > } ;----------------------------------------------------------------------- Hello Ralf, hello others ! Thanks for Your comments about optimization and 'asid_cache' parameter, but I see no reason to make 'get_new_mmu_context' so complex, due code we suggested can be easily optimized without problems. I looked assembler generated by gcc and don't see any performance penalty against code-modified version. Optimized (and tested) code looks more easily: <<<<<<<<<<<< /* * All unused by hardware upper bits will be considered * as software asid extension -- asid version. */ #define ASID_VERSION_MASK ((unsigned long)~(ASID_MASK|(ASID_MASK-1))) #define ASID_FIRST_VERSION ((unsigned long)(~ASID_VERSION_MASK) + 1) extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) { if (! ((asid += (1<context = asid_cache = asid; } >>>>>>>>>>>> 800d7d54: 26100040 addiu $s0,$s0,64 800d7d58: 32020fc0 andi $v0,$s0,0xfc0 800d7d5c: 14400009 bnez $v0,800d7d84 800d7d60: afbf0018 sw $ra,24($sp) 800d7d64: 3c028012 lui $v0,0x8012 800d7d68: 8c423708 lw $v0,14088($v0) 800d7d6c: 00000000 nop 800d7d70: 0040f809 jalr $v0 800d7d74: 00000000 nop 800d7d78: 16000002 bnez $s0,800d7d84 800d7d7c: 00000000 nop 800d7d80: 24101000 li $s0,4096 800d7d84: 3c018010 lui $at,0x8010 800d7d88: ac307010 sw $s0,28688($at) 800d7d8c: ae300020 sw $s0,32($s1) So it takes usually 6 instructions. Code You suggested compiled as: (numbers must be changed relatively startup-patch values) 800d7df8: 3202ffff andi $v0,$s0,0xffff 800d7dfc: 2c420000 sltiu $v0,$v0,0 800d7e00: 1040000d beqz $v0,800d7e38 800d7e04: 00000000 nop 800d7e08: 3c028012 lui $v0,0x8012 800d7e0c: 8c423708 lw $v0,14088($v0) 800d7e10: 00000000 nop 800d7e14: 0040f809 jalr $v0 800d7e18: 00000000 nop 800d7e1c: 3c02ffff lui $v0,0xffff 800d7e20: 02021024 and $v0,$s0,$v0 800d7e24: 3c030001 lui $v1,0x1 800d7e28: 00438021 addu $s0,$v0,$v1 800d7e2c: 16000002 bnez $s0,800d7e38 800d7e30: 00000000 nop 800d7e34: 3c100001 lui $s0,0x1 800d7e38: 24020000 li $v0,0 800d7e3c: 02021021 addu $v0,$s0,$v0 800d7e40: 3c018010 lui $at,0x8010 800d7e44: ac227010 sw $v0,28688($at) 800d7e48: ae300020 sw $s0,32($s1) It does not add performance I can see. So, I don't understand why idea of using all free upper bits as asid extension is bad -- same time it increases security it allows to increment version automatically when asid overflow occurs. Best wishes, Vladimir From R.vandenBerg@inter.NL.net Thu Oct 15 17:51:09 1998 Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA17366; Thu, 15 Oct 1998 17:51:08 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 17:51:08 +0200 (MET DST) Received: from dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-42.Hoorn.NL.net [193.79.46.206] with ESMTP for id RAA19545 (8.8.8/3.28); Thu, 15 Oct 1998 17:51:05 +0200 (MET DST) Received: from whale.dutch.mountain(really [192.168.1.1]) by dutch.mountain via in.smtpd with smtp id for ; Thu, 15 Oct 1998 17:50:36 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Thu, 15 Oct 1998 17:50:35 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: DECstation-Linux is dead, long live Linux-R3000! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 507 Lines: 17 On Thu, 8 Oct 1998, Harald Koerfgen wrote: > On 05-Oct-98 Richard van den Berg wrote: > > > BTW, does somebody out there knows the right settings to make minicom > > behave like a terminal, I haven't succeeded yet, clearing out all init > > strings and setting the right communication parameters of course (9600, > > 8n1) it says online, but no contact with the DEC. > > Are you shure you have disabled "Hardware Flow Control"? > > (Ctrl-A O "Serial port setup" F) That's it! Thanks. Regards, Richard From ralf@lappi.waldorf-gmbh.de Fri Oct 16 04:56:39 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA22196; Fri, 16 Oct 1998 04:56:38 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 04:56:38 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-21.uni-koblenz.de [141.26.249.21]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id EAA25348 for ; Fri, 16 Oct 1998 04:56:34 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id WAA03513; Thu, 15 Oct 1998 22:21:02 +0200 Message-ID: <19981015222100.E2079@uni-koblenz.de> Date: Thu, 15 Oct 1998 22:21:00 +0200 From: ralf@uni-koblenz.de To: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu Subject: Re: get_mmu_context() References: <19981013215927.A2692@uni-koblenz.de> <3625D799.7D923FA9@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <3625D799.7D923FA9@niisi.msk.ru>; from Vladimir Roganov on Thu, Oct 15, 1998 at 03:08:09PM +0400 Content-Length: 3218 Lines: 64 > It does not add performance I can see. Your code is actually a bit shorter, so I'll mix something based on your version and my code patching thing. It must be good, Rik sent me fan email ;-) The performance hit will come into the game as soon as one tries to build a generic kernel for both R3000 and R4000. The R3000 PID and the R4000 ASID mechanism are slightly different and the simple approach to fix that is to use global variables. Which affects both your version and the current version. Which I want to avoid because in worst case that means we'll have to eat a latency of over 1400ns per cache line to fetch from memory. This number is measured on a R4000SC with 100Mhz. That is enough to show up right away on the context switch times which now look fairly nice as long as we don't have to swallow cache faults. (Let me dig out a cite from somebody ``Some systems seem to think a system call without a cache miss is a day without sunshine. :-)'') Talking about cache faults & context switching times. Especially on the R4000 with it's 8kb direct mapped cache _every_ context switch will result in cache misses which explain the fairly lousy context switch times on R4000. R4400 isn't much better. For the case when we have the perfect most cache friendly layout we can switch between two processes without taking page faults. Things got worse when we switched to 8kb, 8kb aligned, stacks as delivered by __get_free_pages(1,...). It's somewhat better on R4600 and R5000 which have set associative caches but still they could need some optimization. Also R3000 with it's typically 2 x 64kb per cache direct mapped caches will looks relativly better in that aspect. > So, I don't understand why idea of using all free upper bits as asid > extension is bad -- same time it increases security it allows to > increment > version automatically when asid overflow occurs. No. It gives us a view bits more, but way not enough. The mmu context code we have has been copied almost unmodified from the Alpha which from EV5 on also supports ASNs. The big difference between the Alpha and the MIPS implementation is that on the Alpha the type ``unsigned long'' which is used for counting ASN and ASN version number has 64 bit. Assuming UP and the worst case which is 2^7 ASNs they still have 2^57 versions before a version overflow will happen. In other words, assuming 1,000,000 context switches per second they still have almost 600,000 years before an ASN collission may occur. The MIPS implementation does worse, especially for the R3000 where waste the lowest 6 bits which effectivly truncates our ASID (or PID) to 26 bits. Assuming just 100,000 context switches we'll wrap around after just a bit more than 11 minutes. I think we can do more than 100,000 context switches per second on a reasonable R3000 system. A possible actual solution could be to extend the ASID / PID counter to 64 bit. This adds some overhead which I'd get rid of if possible at all. Ideas for that wanted. Btw, is any of the R3000 machines stable enough to run lmbench? I'm interested to get results, best the raw result file from lmbench/results/mips-linux/. Reminds me to run lmbench on my RS3230. Ralf From tsbogend@alpha.franken.de Thu Oct 15 23:14:43 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA19193; Thu, 15 Oct 1998 23:14:42 +0200 (MET DST) Received-Date: Thu, 15 Oct 1998 23:14:42 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id XAA14848; Thu, 15 Oct 1998 23:14:40 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id WAA02817; Thu, 15 Oct 1998 22:59:24 +0200 Message-ID: <19981015225923.A2812@alpha.franken.de> Date: Thu, 15 Oct 1998 22:59:23 +0200 From: Thomas Bogendoerfer To: ralf@uni-koblenz.de Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Milo & R4000SC References: <19981014142443.F392@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981014142443.F392@uni-koblenz.de>; from ralf@uni-koblenz.de on Wed, Oct 14, 1998 at 02:24:43PM +0200 Content-Length: 486 Lines: 12 On Wed, Oct 14, 1998 at 02:24:43PM +0200, ralf@uni-koblenz.de wrote: > Any success in finally getting rid of Milo? Milo was already gone, when I posted my questions about tags. My kernel is also nearly free of tags, only the RM200 code contains some pieces. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From triemer@apt4g.a3nyc.com Fri Oct 16 02:28:34 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA21484; Fri, 16 Oct 1998 02:28:33 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 02:28:33 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id UAA06103 for ; Thu, 15 Oct 1998 20:28:49 -0400 Date: Thu, 15 Oct 1998 20:28:48 -0400 (EDT) From: Thomas Riemer To: linux-mips@fnet.fr Subject: decstation 2100 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 344 Lines: 11 Has anyone ever had interrupts running in the decstation 2100 port? I'm looking at the setup.c and int-handler.s code and it sort of looks like it might not work for the 2100... Anyone have any thoughts on the matter? -Tom ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From triemer@apt4g.a3nyc.com Fri Oct 16 05:15:04 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA22329; Fri, 16 Oct 1998 05:15:03 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 05:15:03 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id XAA06250 for ; Thu, 15 Oct 1998 23:15:16 -0400 Date: Thu, 15 Oct 1998 23:15:10 -0400 (EDT) From: Thomas Riemer To: linux-mips@fnet.fr Subject: Missing set? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 899 Lines: 22 Looking at int-handler.S the code testing the CAUSE register($12) against the STATUS register($13). It only processes if both bits in the two registers are set. Somehow the clock is being set in the STATUS register and I am getting hardware interrupts - which is a good sign. After having looked for about an hour for where the STATUS register is set, I seem to be unable to find where that happens. In the case of the dz driver, I believe that the kernel is generating interrupts, but because the STATUS register is not set, the kernel is ignoring these interrupts. I would think the STATUS register should be set in request_irq - but it isn't. Where is the code that sets the STATUS bit for the clock? and in general for irqs? Am I totally missing the mark here? -Tom ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From harald.koerfgen@netcologne.de Fri Oct 16 12:43:27 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA26714; Fri, 16 Oct 1998 12:43:24 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 12:43:24 +0200 (MET DST) Received: from franz.no.dom (dial1-23.netcologne.de [194.8.196.23]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id MAA09216 for ; Fri, 16 Oct 1998 12:43:09 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Oct 1998 12:44:42 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: R3000 and wbflush (was: DZ-11 interrupts) Content-Length: 2002 Lines: 61 Hi Tom, fellow DECstation hackers On 15-Oct-98 Thomas Riemer wrote: > Ok - after playing with the dz serial device - > > I'm getting effectively nowhere - > I have enabled the UART scan > I have enabled the transmit. > > I can force one character across - but as far > as I can tell the interrupt that is supposed to be generated > when the dz11 is ready to process another character never happens. > > I'm guessing that somehow we are not catching it. > > What's the best way to approach this? How do I find out what's > going on under the hood? Your problem might be another one. The R3000 Family processors (including the R2000) have a four word writeback buffer which usually is transparent to memory accesses, but may have side effects when dealing with hardware registers. Example: Let's assume data and status to be two hardware registers and writing something to data has an influence on the content of the status register. A code snippet like: data = whatever; if (status == OK) do_something(); might fail because it cannot be guaranteed that the write access to data happens before the read access from status. The solution to this problem is to wait until the writeback buffer is empty i.e., all write accesses are done. Unfortunately the mechanism for this is hardware implementation specific and the DECstation engineers chose four different ways to do this. You might want to look at arch/mips/dec/wbflush.c. To make a long story short, the above code snippet should look like: #include data = whatever; wbflush(); if (status == OK) do_something(); If you have to write to several hardware registers in a certain sequence, you have to wait for the writeback buffer to be empty too. For example: reg_1 = a_value; wbflush(); reg_2 = another_value; when the access to reg_1 should be done before the access to reg_2. Hope this helps. --- Regards, Harald From harald.koerfgen@netcologne.de Mon May 17 00:49:16 1999 Date: Fri, 16 Oct 1998 12:44:42 +0200 (MEST) From: Harald Koerfgen Reply-To: linux-mips@fnet.fr To: linux-mips@fnet.fr Subject: R3000 and wbflush (was: DZ-11 interrupts) Resent-Date: Fri, 16 Oct 1998 12:49:18 +0200 (MET DST) Resent-From: linux-mips@fnet.fr Content-Length: 2003 Lines: 62 Hi Tom, fellow DECstation hackers On 15-Oct-98 Thomas Riemer wrote: > Ok - after playing with the dz serial device - > > I'm getting effectively nowhere - > I have enabled the UART scan > I have enabled the transmit. > > I can force one character across - but as far > as I can tell the interrupt that is supposed to be generated > when the dz11 is ready to process another character never happens. > > I'm guessing that somehow we are not catching it. > > What's the best way to approach this? How do I find out what's > going on under the hood? Your problem might be another one. The R3000 Family processors (including the R2000) have a four word writeback buffer which usually is transparent to memory accesses, but may have side effects when dealing with hardware registers. Example: Let's assume data and status to be two hardware registers and writing something to data has an influence on the content of the status register. A code snippet like: data = whatever; if (status == OK) do_something(); might fail because it cannot be guaranteed that the write access to data happens before the read access from status. The solution to this problem is to wait until the writeback buffer is empty i.e., all write accesses are done. Unfortunately the mechanism for this is hardware implementation specific and the DECstation engineers chose four different ways to do this. You might want to look at arch/mips/dec/wbflush.c. To make a long story short, the above code snippet should look like: #include data = whatever; wbflush(); if (status == OK) do_something(); If you have to write to several hardware registers in a certain sequence, you have to wait for the writeback buffer to be empty too. For example: reg_1 = a_value; wbflush(); reg_2 = another_value; when the access to reg_1 should be done before the access to reg_2. Hope this helps. --- Regards, Harald From harald.koerfgen@netcologne.de Fri Oct 16 12:43:26 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA26713; Fri, 16 Oct 1998 12:43:23 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 12:43:23 +0200 (MET DST) Received: from franz.no.dom (dial1-23.netcologne.de [194.8.196.23]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id MAA09224 for ; Fri, 16 Oct 1998 12:43:13 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Oct 1998 12:44:45 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: Missing set? Content-Length: 2131 Lines: 71 Hi, On 16-Oct-98 Thomas Riemer wrote: > Looking at int-handler.S the code testing the CAUSE register($12) against > the STATUS register($13). It only processes if both bits in the > two registers are set. Somehow the clock is being set in the STATUS > register and I am getting hardware interrupts - which is a good sign. > > After having looked for about an hour for where the STATUS register is > set, I seem to be unable to find where that happens. In the case > of the dz driver, I believe that the kernel is generating interrupts, but > because the STATUS register is not set, the kernel is ignoring these > interrupts. > > I would think the STATUS register should be set in request_irq - but > it isn't. > > Where is the code that sets the STATUS bit for the clock? and in general > for irqs? This is indeed somewhat tricky. I had to find a way to manipulate the status register within a save_and_cli(flags); ... restore_flags(flags); code sequence. save_flags saves the content of the status register in flags and restore_flags restores it, so enabling or disabling interrupts within a save/restore pair wouldn't work. arch/mips/dec/irq.c: request_irq() -> setup_dec_irq() setup_dec_irq: ... save_and_cli(flags); *p = new; if (!shared) { unmask_irq_flags(irq, &flags); } restore_flags(flags); .... and unmask_irq_flags looks basicly like (leaving the IOASIC stuff aside): static inline void unmask_irq_flags(unsigned int irq_nr, unsigned long *flags) { ... *flags |= dec_interrupt[irq_nr].cpu_mask; } That means, the bits in the status register are set (or reset) by setting (or resetting) bits in flags and restore_flags(flags) does the trick. I _know_ this is dirty and if you have a better idea without adding a performance penalty, I'd love to implement it. People, when writing device drivers for DECstations, DO NEVER EVER use code like: save_flags(flags); [disable or enable interrupts with en/disable_irq(irq)] restore(flags); That simply doesn't work and will cause endless headache. --- Regards, Harald From harald.koerfgen@netcologne.de Fri Oct 16 12:43:28 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA26712; Fri, 16 Oct 1998 12:43:22 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 12:43:22 +0200 (MET DST) Received: from franz.no.dom (dial1-23.netcologne.de [194.8.196.23]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id MAA09228 for ; Fri, 16 Oct 1998 12:43:15 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Oct 1998 12:44:47 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: decstation 2100 Content-Length: 577 Lines: 19 Hi all, On 16-Oct-98 Thomas Riemer wrote: > Has anyone ever had interrupts running in the decstation 2100 port? Yes, _you_ have. At least the timer interrupts are running well on your DS2100 :-). > I'm looking at the setup.c and int-handler.s code and it sort of looks > like it might not work for the 2100... > > Anyone have any thoughts on the matter? Well, the DECstation interrupt handler is only tested on IOASIC machines and it may happen that the part for the other machines is a little rough around the edges. Suggestions are always welcome. --- Regards, Harald From rajko@mech.math.msu.su Fri Oct 16 17:05:23 1998 Received: from mech.math.msu.su (mech.math.msu.su [158.250.33.65]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id RAA28508; Fri, 16 Oct 1998 17:05:21 +0200 (MET DST) Received-Date: Fri, 16 Oct 1998 17:05:21 +0200 (MET DST) Received: (from rajko@localhost) by mech.math.msu.su (8.6.10/8.6.10/sasha.040695) id TAA01082; Fri, 16 Oct 1998 19:04:49 +0400 Date: Fri, 16 Oct 1998 19:04:48 +0400 (MSD) From: "Gleb O. Rajko" To: linux-mips@fnet.fr cc: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com Subject: Re: get_mmu_context() In-Reply-To: <19981015222100.E2079@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2836 Lines: 59 On Thu, 15 Oct 1998 ralf@uni-koblenz.de wrote: > > The performance hit will come into the game as soon as one tries to > build a generic kernel for both R3000 and R4000. The R3000 PID and the > R4000 ASID mechanism are slightly different and the simple approach > to fix that is to use global variables. Which affects both your version > and the current version. We are going to provide support for building generic kernels in the near future if somebody who holds r4k will help us and will try our patches on a r4k box. I think the best time to start is when r3k will be synced with the main branch. Perhaps, Harald may answer when it might occur. > > Which I want to avoid because in worst case that means we'll have to eat > a latency of over 1400ns per cache line to fetch from memory. This number > is measured on a R4000SC with 100Mhz. That is enough to show up right > away on the context switch times which now look fairly nice as long as we > don't have to swallow cache faults. > Perhaps, we may use global vars in most cases and patch code at bootup for critical ones. > > So, I don't understand why idea of using all free upper bits as asid > > extension is bad -- same time it increases security it allows to > > increment > > version automatically when asid overflow occurs. > > No. It gives us a view bits more, but way not enough. The mmu context code > we have has been copied almost unmodified from the Alpha which from EV5 on > also supports ASNs. The big difference between the Alpha and the MIPS > implementation is that on the Alpha the type ``unsigned long'' which is > used for counting ASN and ASN version number has 64 bit. Assuming UP and > the worst case which is 2^7 ASNs they still have 2^57 versions before a > version overflow will happen. In other words, assuming 1,000,000 context > switches per second they still have almost 600,000 years before an ASN > collission may occur. > > The MIPS implementation does worse, especially for the R3000 where waste the > lowest 6 bits which effectivly truncates our ASID (or PID) to 26 bits. > Assuming just 100,000 context switches we'll wrap around after just a bit > more than 11 minutes. I think we can do more than 100,000 context switches > per second on a reasonable R3000 system. > As I understand the only place where change the version is in get_new_mmu_context(). Thus, if the version overflows we may create a new process which will share its address space with other due to the same ASID and varsion pair. Am I right ? > Btw, is any of the R3000 machines stable enough to run lmbench? I'm > interested to get results, best the raw result file from > lmbench/results/mips-linux/. Reminds me to run lmbench on my RS3230. Ok. I will try to run lmbench while Vladimir will think about your ideas :-) Regards, Gleb. From ralf@lappi.waldorf-gmbh.de Sat Oct 17 03:11:50 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA04794; Sat, 17 Oct 1998 03:11:48 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 03:11:48 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-06.uni-koblenz.de [141.26.249.6]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id DAA21536 for ; Sat, 17 Oct 1998 03:11:24 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id AAA04470; Sat, 17 Oct 1998 00:44:08 +0200 Message-ID: <19981017004408.E3370@uni-koblenz.de> Date: Sat, 17 Oct 1998 00:44:08 +0200 From: ralf@uni-koblenz.de To: Vladimir Roganov , linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu Subject: Re: get_mmu_context() References: <19981013215927.A2692@uni-koblenz.de> <3625D799.7D923FA9@niisi.msk.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mP3DRpeJDSE+ciuQ X-Mailer: Mutt 0.91.1 In-Reply-To: <3625D799.7D923FA9@niisi.msk.ru>; from Vladimir Roganov on Thu, Oct 15, 1998 at 03:08:09PM +0400 Content-Length: 11203 Lines: 352 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Ok, here is the first working and tested version of my runtime patched get_mmu_context thing. While writing the code I noticed that the code patching stuff is actually already a part of what I was intending to implement since long time like for example getting rid of function pointers and can be used to optimize many more things throughout the kernel. So while some parts already look somewhat generic I'd like to make them really generic. The thing is probably going to look somewhat similar to the Sparc btfixup code which I'm going to read now. Ralf --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=asid-patch Index: linux/arch/mips/mm/andes.c diff -u linux/arch/mips/mm/andes.c:1.5 linux/arch/mips/mm/andes.c:1.6 --- linux/arch/mips/mm/andes.c:1.5 Fri May 1 08:33:13 1998 +++ linux/arch/mips/mm/andes.c Fri Oct 16 21:22:42 1998 @@ -1,9 +1,8 @@ -/* +/* $Id: andes.c,v 1.6 1998/10/16 19:22:42 ralf Exp $ + * * andes.c: MMU and cache operations for the R10000 (ANDES). * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - * - * $Id: andes.c,v 1.5 1998/05/01 06:33:13 ralf Exp $ */ #include #include @@ -13,6 +12,7 @@ #include #include #include +#include extern unsigned long mips_tlb_entries; @@ -104,6 +104,7 @@ flush_tlb_mm = andes_flush_tlb_mm; flush_tlb_range = andes_flush_tlb_range; flush_tlb_page = andes_flush_tlb_page; + andes_asid_setup(); add_wired_entry = andes_add_wired_entry; Index: linux/arch/mips/mm/fault.c diff -u linux/arch/mips/mm/fault.c:1.10 linux/arch/mips/mm/fault.c:1.11 --- linux/arch/mips/mm/fault.c:1.10 Thu Sep 17 00:50:44 1998 +++ linux/arch/mips/mm/fault.c Fri Oct 16 21:22:42 1998 @@ -1,4 +1,4 @@ -/* $Id: fault.c,v 1.10 1998/09/16 22:50:44 ralf Exp $ +/* $Id: fault.c,v 1.11 1998/10/16 19:22:42 ralf Exp $ * * arch/mips/mm/fault.c * @@ -26,7 +26,7 @@ extern void die(char *, struct pt_regs *, unsigned long write); -unsigned long asid_cache = ASID_FIRST_VERSION; +unsigned long asid_cache; /* * Macro for exception fixup code to access integer registers. Index: linux/arch/mips/mm/init.c diff -u linux/arch/mips/mm/init.c:1.12 linux/arch/mips/mm/init.c:1.13 --- linux/arch/mips/mm/init.c:1.12 Thu Sep 17 00:50:44 1998 +++ linux/arch/mips/mm/init.c Fri Oct 16 21:22:42 1998 @@ -1,4 +1,4 @@ -/* $Id: init.c,v 1.12 1998/09/16 22:50:44 ralf Exp $ +/* $Id: init.c,v 1.13 1998/10/16 19:22:42 ralf Exp $ * * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive @@ -33,6 +33,7 @@ #ifdef CONFIG_SGI #include #endif +#include /* * Define this to effectivly disable the userpage colouring shit. @@ -463,4 +464,36 @@ val->totalram <<= PAGE_SHIFT; val->sharedram <<= PAGE_SHIFT; return; +} + +/* Fixup an immediate instruction */ +__initfunc(static void __i_insn_fixup(unsigned int **start, unsigned int **stop, + unsigned int i_const)) +{ + unsigned int **p, *ip; + + for (p = start;p < stop; p++) { + ip = *p; + *ip = (*ip & 0xffff0000) | i_const; + } +} + +#define i_insn_fixup(section, const) \ +do { \ + extern unsigned int *__start_ ## section; \ + extern unsigned int *__stop_ ## section; \ + __i_insn_fixup(&__start_ ## section, &__stop_ ## section, const); \ +} while(0) + +/* Caller is assumed to flush the caches before the first context switch. */ +__initfunc(void __asid_setup(unsigned int inc, unsigned int mask, + unsigned int version_mask, + unsigned int first_version)) +{ + i_insn_fixup(__asid_inc, inc); + i_insn_fixup(__asid_mask, mask); + i_insn_fixup(__asid_version_mask, version_mask); + i_insn_fixup(__asid_first_version, first_version); + + asid_cache = first_version; } Index: linux/arch/mips/mm/r2300.c diff -u linux/arch/mips/mm/r2300.c:1.6 linux/arch/mips/mm/r2300.c:1.7 --- linux/arch/mips/mm/r2300.c:1.6 Tue Aug 18 22:45:08 1998 +++ linux/arch/mips/mm/r2300.c Fri Oct 16 21:22:43 1998 @@ -1,9 +1,8 @@ -/* +/* $Id: r2300.c,v 1.7 1998/10/16 19:22:43 ralf Exp $ + * * r2300.c: R2000 and R3000 specific mmu/cache code. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - * - * $Id: r2300.c,v 1.6 1998/08/18 20:45:08 ralf Exp $ */ #include #include @@ -14,6 +13,7 @@ #include #include #include +#include extern unsigned long mips_tlb_entries; @@ -274,6 +274,7 @@ flush_tlb_mm = r2300_flush_tlb_mm; flush_tlb_range = r2300_flush_tlb_range; flush_tlb_page = r2300_flush_tlb_page; + r3000_asid_setup(); load_pgd = r2300_load_pgd; pgd_init = r2300_pgd_init; Index: linux/arch/mips/mm/r4xx0.c diff -u linux/arch/mips/mm/r4xx0.c:1.29 linux/arch/mips/mm/r4xx0.c:1.30 --- linux/arch/mips/mm/r4xx0.c:1.29 Wed Oct 14 22:29:59 1998 +++ linux/arch/mips/mm/r4xx0.c Fri Oct 16 21:22:43 1998 @@ -1,4 +1,4 @@ -/* $Id: r4xx0.c,v 1.29 1998/10/14 20:29:59 ralf Exp $ +/* $Id: r4xx0.c,v 1.30 1998/10/16 19:22:43 ralf Exp $ * * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive @@ -2791,6 +2791,7 @@ flush_tlb_mm = r4k_flush_tlb_mm; flush_tlb_range = r4k_flush_tlb_range; flush_tlb_page = r4k_flush_tlb_page; + r4xx0_asid_setup(); load_pgd = r4k_load_pgd; pgd_init = r4k_pgd_init; Index: linux/arch/mips/mm/r6000.c diff -u linux/arch/mips/mm/r6000.c:1.5 linux/arch/mips/mm/r6000.c:1.6 --- linux/arch/mips/mm/r6000.c:1.5 Tue Aug 18 22:45:09 1998 +++ linux/arch/mips/mm/r6000.c Fri Oct 16 21:22:44 1998 @@ -1,4 +1,5 @@ -/* $Id: r6000.c,v 1.5 1998/08/18 20:45:09 ralf Exp $ +/* $Id: r6000.c,v 1.6 1998/10/16 19:22:44 ralf Exp $ + * * r6000.c: MMU and cache routines for the R6000 processors. * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) @@ -13,6 +14,7 @@ #include #include #include +#include __asm__(".set mips3"); /* because we know... */ @@ -180,6 +182,7 @@ flush_tlb_mm = r6000_flush_tlb_mm; flush_tlb_range = r6000_flush_tlb_range; flush_tlb_page = r6000_flush_tlb_page; + r6000_asid_setup(); load_pgd = r6000_load_pgd; pgd_init = r6000_pgd_init; Index: linux/arch/mips/mm/tfp.c diff -u linux/arch/mips/mm/tfp.c:1.5 linux/arch/mips/mm/tfp.c:1.6 --- linux/arch/mips/mm/tfp.c:1.5 Fri May 1 08:31:34 1998 +++ linux/arch/mips/mm/tfp.c Fri Oct 16 21:22:44 1998 @@ -1,4 +1,5 @@ -/* +/* $Id: tfp.c,v 1.6 1998/10/16 19:22:44 ralf Exp $ + * * tfp.c: MMU and cache routines specific to the r8000 (TFP). * * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) @@ -13,6 +14,7 @@ #include #include #include +#include extern unsigned long mips_tlb_entries; @@ -104,6 +106,7 @@ flush_tlb_mm = tfp_flush_tlb_mm; flush_tlb_range = tfp_flush_tlb_range; flush_tlb_page = tfp_flush_tlb_page; + tfp_asid_setup(); add_wired_entry = tfp_add_wired_entry; Index: linux/include/asm-mips/mmu_context.h diff -u linux/include/asm-mips/mmu_context.h:1.2 linux/include/asm-mips/mmu_context.h:1.3 --- linux/include/asm-mips/mmu_context.h:1.2 Tue May 5 12:22:01 1998 +++ linux/include/asm-mips/mmu_context.h Fri Oct 16 21:22:54 1998 @@ -1,4 +1,4 @@ -/* $Id: mmu_context.h,v 1.2 1998/05/05 10:22:01 ralf Exp $ +/* $Id: mmu_context.h,v 1.3 1998/10/16 19:22:54 ralf Exp $ * * Switch a MMU context. * @@ -11,29 +11,61 @@ #ifndef __ASM_MIPS_MMU_CONTEXT_H #define __ASM_MIPS_MMU_CONTEXT_H -#define MAX_ASID 255 - +/* Fuck. The f-word is here so you can grep for it :-) */ extern unsigned long asid_cache; -#define ASID_VERSION_SHIFT 16 -#define ASID_VERSION_MASK ((~0UL) << ASID_VERSION_SHIFT) -#define ASID_FIRST_VERSION (1UL << ASID_VERSION_SHIFT) - -extern inline void get_new_mmu_context(struct mm_struct *mm, unsigned long asid) -{ - /* check if it's legal.. */ - if ((asid & ~ASID_VERSION_MASK) > MAX_ASID) { - /* start a new version, invalidate all old asid's */ - flush_tlb_all(); - asid = (asid & ASID_VERSION_MASK) + ASID_FIRST_VERSION; - if (!asid) +/* I patch, therefore I am ... */ +#define ASID_INC(asid) \ + ({ unsigned long __asid = asid; \ + __asm__("1:\taddiu\t%0,0\t\t\t\t# patched\n\t" \ + ".section\t__asid_inc,\"a\"\n\t" \ + ".word\t1b\n\t" \ + ".previous" \ + :"=r" (__asid) \ + :"0" (__asid)); \ + __asid; }) +#define ASID_MASK(asid) \ + ({ unsigned long __asid = asid; \ + __asm__("1:\tandi\t%0,%1,0\t\t\t# patched\n\t" \ + ".section\t__asid_mask,\"a\"\n\t" \ + ".word\t1b\n\t" \ + ".previous" \ + :"=r" (__asid) \ + :"r" (__asid)); \ + __asid; }) +#define ASID_VERSION_MASK \ + ({ unsigned long __asid; \ + __asm__("1:\tli\t%0,0\t\t\t\t# patched\n\t" \ + ".section\t__asid_version_mask,\"a\"\n\t" \ + ".word\t1b\n\t" \ + ".previous" \ + :"=r" (__asid)); \ + __asid; }) +#define ASID_FIRST_VERSION \ + ({ unsigned long __asid = asid; \ + __asm__("1:\tli\t%0,0\t\t\t\t# patched\n\t" \ + ".section\t__asid_first_version,\"a\"\n\t" \ + ".word\t1b\n\t" \ + ".previous" \ + :"=r" (__asid)); \ + __asid; }) + +#define ASID_FIRST_VERSION_R3000 0x1000 +#define ASID_FIRST_VERSION_R4000 0x100 + +extern inline void +get_new_mmu_context(struct mm_struct *mm, unsigned long asid) +{ + if (!ASID_MASK((asid = ASID_INC(asid)))) { + flush_tlb_all(); /* start new asid cycle */ + if (!asid) /* fix version if needed */ asid = ASID_FIRST_VERSION; } - asid_cache = asid + 1; - mm->context = asid; /* full version + asid */ + mm->context = asid_cache = asid; } -extern inline void get_mmu_context(struct task_struct *p) +extern inline void +get_mmu_context(struct task_struct *p) { struct mm_struct *mm = p->mm; @@ -72,5 +104,31 @@ get_mmu_context(tsk); set_entryhi(tsk->mm->context); } + +extern void __asid_setup(unsigned int inc, unsigned int mask, + unsigned int version_mask, unsigned int first_version); + +extern inline void r3000_asid_setup(void) +{ + __asid_setup(0x40, 0xfc0, 0xf000, ASID_FIRST_VERSION_R3000); +} + +extern inline void r6000_asid_setup(void) +{ + panic("r6000_asid_setup: implement me"); /* No idea ... */ +} + +extern inline void tfp_asid_setup(void) +{ + panic("tfp_asid_setup: implement me"); /* No idea ... */ +} + +extern inline void r4xx0_asid_setup(void) +{ + __asid_setup(1, 0xff, 0xff00, ASID_FIRST_VERSION_R4000); +} + +/* R10000 has the same ASID mechanism as the R4000. */ +#define andes_asid_setup r4xx0_asid_setup #endif /* __ASM_MIPS_MMU_CONTEXT_H */ --mP3DRpeJDSE+ciuQ-- From robert.slover@Rose-Hulman.Edu Sat Oct 17 01:35:11 1998 Received: from po.nextwork.rose-hulman.edu (pandora.rose-hulman.edu [137.112.4.196]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA04034; Sat, 17 Oct 1998 01:35:10 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 01:35:10 +0200 (MET DST) Received: from Rose-Hulman.Edu ([137.112.2.75]) by po.nextwork.rose-hulman.edu (8.8.8/8.8.8) with ESMTP id SAA17754 for ; Fri, 16 Oct 1998 18:35:01 -0500 (EST) Sender: slover@nextwork.rose-hulman.edu Message-ID: <3627D886.911CDEAA@Rose-Hulman.Edu> Date: Fri, 16 Oct 1998 23:36:39 +0000 From: "Robert J. Slover" Organization: Rose-Hulman Institute of Technology X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: MIPS/Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1082 Lines: 30 Greetings, I just today acquired for my collection a MIPS workstation, a MIPS branded MIPS/RS2030 (Model M/12) machine. I has an R2000 processor, appears to have Adaptec 6250 onboard SCSI and a Western Digital floppy interface. The machine had the hard disk stripped from it years ago and there is therefore no OS. It never had the floppy drive. I have a mouse, but have no keyboard for it (though it has a suspiciously-close to PC connector and Award keyboard bios). My question is, is there as yet any effort to port to this specific machine? If not, is there a reasonable starting point somewhere for me to attempt to boot an existing kernel on the thing, and see where it breaks? I've not done much kernel hacking (fixed a SCSI driver and an ethernet driver...simple fixes to get an existing driver to detect slightly strange hardware that was otherwise totally supported by the driver). I'm willing to help where I can, time permitting. Any clues would be most welcome. --Robert -- Robert J. Slover Administrative Systems Manager Rose-Hulman Institute of Technology From triemer@apt4g.a3nyc.com Sat Oct 17 02:18:46 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA04298; Sat, 17 Oct 1998 02:18:43 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 02:18:43 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id UAA07270; Fri, 16 Oct 1998 20:18:52 -0400 Date: Fri, 16 Oct 1998 20:18:52 -0400 (EDT) From: Thomas Riemer To: Harald Koerfgen cc: linux-mips@fnet.fr Subject: RE: Missing set? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3029 Lines: 99 This was exactly what I needed to get stuff working... irq_request has some very strange behavior if it is nested within a save_flags /restore_flags construction. Consider the snippet: ..... save_flags(flags); cli(); request_irq(SERIAL, dz_interrupt, SA_INTERRUPT, "DZ", lines[0]); restore_flags(flags); ...... It turns out that this manages to leave the state of the status register unchanged. Move the restore_flags before the call to request_irq and you make progress - and indeed the dz.c driver code actually generates characters across the serial line. -Tom ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. On Fri, 16 Oct 1998, Harald Koerfgen wrote: > Hi, > > On 16-Oct-98 Thomas Riemer wrote: > > Looking at int-handler.S the code testing the CAUSE register($12) against > > the STATUS register($13). It only processes if both bits in the > > two registers are set. Somehow the clock is being set in the STATUS > > register and I am getting hardware interrupts - which is a good sign. > > > > After having looked for about an hour for where the STATUS register is > > set, I seem to be unable to find where that happens. In the case > > of the dz driver, I believe that the kernel is generating interrupts, but > > because the STATUS register is not set, the kernel is ignoring these > > interrupts. > > > > I would think the STATUS register should be set in request_irq - but > > it isn't. > > > > Where is the code that sets the STATUS bit for the clock? and in general > > for irqs? > > This is indeed somewhat tricky. I had to find a way to manipulate the status > register within a > > save_and_cli(flags); > ... > restore_flags(flags); > > code sequence. save_flags saves the content of the status register in flags and > restore_flags restores it, so enabling or disabling interrupts within a save/restore > pair wouldn't work. > > arch/mips/dec/irq.c: > > request_irq() -> setup_dec_irq() > > setup_dec_irq: > > ... > save_and_cli(flags); > *p = new; > > if (!shared) { > unmask_irq_flags(irq, &flags); > } > restore_flags(flags); > .... > > and unmask_irq_flags looks basicly like (leaving the IOASIC stuff aside): > > static inline void unmask_irq_flags(unsigned int irq_nr, unsigned long *flags) > { > ... > *flags |= dec_interrupt[irq_nr].cpu_mask; > } > > That means, the bits in the status register are set (or reset) by setting (or > resetting) bits in flags and restore_flags(flags) does the trick. > > I _know_ this is dirty and if you have a better idea without adding a performance > penalty, I'd love to implement it. > > People, when writing device drivers for DECstations, DO NEVER EVER use code like: > > save_flags(flags); > [disable or enable interrupts with en/disable_irq(irq)] > restore(flags); > > That simply doesn't work and will cause endless headache. > --- > Regards, > Harald > From imp@village.org Sat Oct 17 08:13:34 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id IAA06920; Sat, 17 Oct 1998 08:13:32 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 08:13:32 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zUPcA-0004Zv-00; Sat, 17 Oct 1998 00:13:22 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA11929 for ; Sat, 17 Oct 1998 00:13:13 -0600 (MDT) Message-Id: <199810170613.AAA11929@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: MIPS/Linux In-reply-to: Your message of "Fri, 16 Oct 1998 23:36:39 -0000." <3627D886.911CDEAA@Rose-Hulman.Edu> References: <3627D886.911CDEAA@Rose-Hulman.Edu> Date: Sat, 17 Oct 1998 00:13:13 -0600 From: Warner Losh Content-Length: 435 Lines: 11 In message <3627D886.911CDEAA@Rose-Hulman.Edu> "Robert J. Slover" writes: : I has an R2000 processor, appears to have Adaptec 6250 : onboard SCSI The aic-62*5*0 chip is what is in the aha-1542 series of cards. However, the 1542 cards have a Z80 onboard to do lots of stuff, so I'm not sure that a 1542 reference manual would help or hurt your quest. Too bad the OS is gone because MIPS shipped the driver sources typically... Warner From alhaz@xmission.com Sat Oct 17 08:33:42 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id IAA07020; Sat, 17 Oct 1998 08:33:40 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 08:33:40 +0200 (MET DST) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zUPvl-0003Hd-00 for linux-mips@fnet.fr; Sat, 17 Oct 1998 00:33:37 -0600 Sender: alhaz@fnet.fr Message-ID: <36283A29.4A102CF8@xmission.com> Date: Sat, 17 Oct 1998 00:33:13 -0600 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: MIPS/Linux References: <3627D886.911CDEAA@Rose-Hulman.Edu> <199810170613.AAA11929@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 709 Lines: 21 Warner Losh wrote: > > In message <3627D886.911CDEAA@Rose-Hulman.Edu> "Robert J. Slover" writes: > : I has an R2000 processor, appears to have Adaptec 6250 > : onboard SCSI > > The aic-62*5*0 chip is what is in the aha-1542 series of cards. > However, the 1542 cards have a Z80 onboard to do lots of stuff, so I'm > not sure that a 1542 reference manual would help or hurt your quest. > Too bad the OS is gone because MIPS shipped the driver sources > typically... > > Warner Oh come on, it shouldn't be too difficult to come by a copy of RISCos 4.52+. I have an RS2030 here that has atleast a partial installation. Unfortunately I don't forsee actually getting to use the thing for anything. - Eric From triemer@apt4g.a3nyc.com Sat Oct 17 19:50:15 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA10753; Sat, 17 Oct 1998 19:50:14 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 19:50:14 +0200 (MET DST) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id NAA08149 for ; Sat, 17 Oct 1998 13:50:18 -0400 Date: Sat, 17 Oct 1998 13:50:18 -0400 (EDT) From: Thomas Riemer To: linux-mips@fnet.fr Subject: Standalone Shell source Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 454 Lines: 12 Where can I find the source for the standalone shell that is being run when the I boot up the kernel? -Tom P.S. progress on dz11 driver - transmit generates interrupts that produce characters on the serial line - however, the other direction seems not to generate interrupts. (i.e. receiving characters doesn't seem to work) ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From R.vandenBerg@inter.NL.net Sat Oct 17 20:28:32 1998 Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA11166; Sat, 17 Oct 1998 20:28:31 +0200 (MET DST) Received-Date: Sat, 17 Oct 1998 20:28:31 +0200 (MET DST) Received: from dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-37.Hoorn.NL.net [193.79.46.201] with ESMTP for id UAA20251 (8.8.8/3.28); Sat, 17 Oct 1998 20:28:29 +0200 (MET DST) Received: from whale.dutch.mountain(really [192.168.1.1]) by dutch.mountain via in.smtpd with smtp id for ; Sat, 17 Oct 1998 20:27:15 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Sat, 17 Oct 1998 20:27:14 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: Standalone Shell source In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 204 Lines: 11 Hello Tom, On Sat, 17 Oct 1998, Thomas Riemer wrote: > Where can I find the source for the standalone shell that is being > run when the I boot up the kernel? Have you tried sunsite? Regards, Richard From toddmvohs@uswest.net Sun Oct 18 05:33:14 1998 Received: from phnxpop2.phnx.uswest.net (phnxpop2.phnx.uswest.net [206.80.192.2]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA16897; Sun, 18 Oct 1998 05:33:13 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 05:33:13 +0200 (MET DST) Received: (qmail 28938 invoked by alias); 18 Oct 1998 03:32:22 -0000 Delivered-To: fixup-linux-mips@fnet.fr@fixme Received: (qmail 28921 invoked by uid 0); 18 Oct 1998 03:32:22 -0000 Received: from dsl141.phnx.uswest.net (HELO cambria) (207.225.190.141) by phnxpop2.phnx.uswest.net with SMTP; 18 Oct 1998 03:32:22 -0000 From: "Todd M. Vohs" To: Cc: , Subject: Port for NEC RiscServer 2200 Date: Sat, 17 Oct 1998 20:29:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 9.0, Build 4.71.2233.5 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Content-Length: 292 Lines: 10 Hi. I've got a dual processor NEC RiscServer 2200 that I'd like to get Linux running on. I have downloaded and successfully ran the milo files. Now I need to know where I can actually get a usable port from, and some directions on how to install it to my system. Can you help? Thanks! From mmarch@mindspring.net Sun Oct 18 10:08:47 1998 Received: from db.indirect.com (root@db.indirect.com [165.247.198.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA17995; Sun, 18 Oct 1998 10:08:46 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 10:08:46 +0200 (MET DST) Received: from cowmix (dsld213.phnx.uswest.net [209.180.145.212]) by db.indirect.com (8.8.8/8.8.5) with SMTP id BAA30928 for ; Sun, 18 Oct 1998 01:09:11 -0700 Reply-To: From: "Michael F. March" To: Subject: Kernel modules Date: Sun, 18 Oct 1998 01:06:07 -0700 Message-ID: <000501bdfa6e$28cfde60$d491b4d1@cowmix.eng.mindspring.net> 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 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Length: 93 Lines: 7 I am new to MIPS Linux... Does anyone know the status of kernel modules? Thanks. From ralf@lappi.waldorf-gmbh.de Mon Oct 19 01:13:18 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA28712; Mon, 19 Oct 1998 01:13:17 +0200 (MET DST) Received-Date: Mon, 19 Oct 1998 01:13:17 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-12.uni-koblenz.de [141.26.249.12]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id BAA12464 for ; Mon, 19 Oct 1998 01:12:33 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id LAA07358; Sun, 18 Oct 1998 11:52:28 +0200 Message-ID: <19981018115228.M4768@uni-koblenz.de> Date: Sun, 18 Oct 1998 11:52:28 +0200 From: ralf@uni-koblenz.de To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: lmbench results for RISC/os Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 337 Lines: 9 Hi, if anybody has results of a preferably current lmbench running on a Magnum 4000 and/or Magnum 4000SC under RISC/os then I'd appreciate a copy of the raw result file. The comparison of Linux with RISC/os maybe unfair now that RISC/os is dead for a couple of years but it's still the official UNIX for these machines, so ... Ralf From harald.koerfgen@netcologne.de Sun Oct 18 16:06:26 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA21377; Sun, 18 Oct 1998 16:06:24 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 16:06:24 +0200 (MET DST) Received: from franz.no.dom (dialp2-105.netcologne.de [195.14.235.105]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id QAA02929 for ; Sun, 18 Oct 1998 16:06:14 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 18 Oct 1998 16:07:45 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: Standalone Shell source Content-Length: 220 Lines: 10 On 17-Oct-98 Thomas Riemer wrote: > Where can I find the source for the standalone shell that is being > run when the I boot up the kernel? ftp://sunsite.unc.edu/pub/Linux/system/shells/sash.tar.z --- Regards, Harald From matt@molnir.demon.co.uk Sun Oct 18 17:12:23 1998 Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA22506; Sun, 18 Oct 1998 17:12:21 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 17:12:21 +0200 (MET DST) Received: from [193.237.65.231] (helo=molnir.our.house) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zUuVB-0005vU-00; Sun, 18 Oct 1998 15:12:13 +0000 Received: from molnir.demon.co.uk (matt@cook.our.house [192.168.100.1]) by molnir.our.house (8.9.1/8.9.1) with ESMTP id QAA07395; Sun, 18 Oct 1998 16:10:37 +0100 Received: (from matt@localhost) by molnir.demon.co.uk (8.9.1/8.9.1) id QAA00328; Sun, 18 Oct 1998 16:10:30 +0100 From: Matt Foster Message-Id: <199810181510.QAA00328@molnir.demon.co.uk> Subject: Re: Turbo Channel To: Jay.Estabrook@digital.com Date: Sun, 18 Oct 1998 16:10:30 +0100 (BST) Cc: linux-mips@fnet.fr In-Reply-To: <199810101734.NAA01413@alpha1.estabrook.org> from "Jay.Estabrook@digital.com" at Oct 10, 98 01:34:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1313 Lines: 36 > >>> Matt Foster said: > > > > I've just inherited an Alpha 3000 (300LX I think). 125 MHz Alpha, > > and Turbo channel. Last I read 3000 are not much use for Linux, > > is this still the case? Would the work being done on the Decstation > > port help with the TC drivers? > > Yes, your best alternate at the moment is one of the *BSDs. > > And yes, work being done on the Decstation port *will* help the case for > TC support under LINUX, but the drivers and TC code will still have to be > made 64-bit clean for Alpha. > > Sounds to me like a good volunteer opportunity... :-) > > --Jay++ Hi, I have the 300LX loaded with NetBSD at the moment, but it has a spare hard disk for TC driver testing. My device driver coding could be said to be rusty in a generous mood and non existant in a cynical one. However, I'm willing to help and a UN*X admin/developer by profession. I have access now to a DS5000/25 (personnel) DS5000/240 and quite possibly a something else fairly soon for the MIPS port testing. As for getting the TC drivers to work on Alpha as well as MIPS, who should I talk to? I'll have most of the kit home by the end of next week, so should be able to start making more useful contributions to the port (been a little tied up getting married the past month or so...) Cheers, Matt From harald.koerfgen@netcologne.de Sun Oct 18 21:52:08 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA26091; Sun, 18 Oct 1998 21:51:54 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 21:51:54 +0200 (MET DST) Received: from franz.no.dom (dial9-197.netcologne.de [194.8.195.197]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA16051 for ; Sun, 18 Oct 1998 21:51:42 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 18 Oct 1998 21:53:12 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: WTB: R4400SC CPU upgrade for a DS5000/240 Content-Length: 366 Lines: 12 Fellow MIPS hackers, I apologize in advance for bothering you, but it appears to be of invaluable help to have a R4000 based DECstation for comparison and evaluation purposes. Does anybbody have an idea where I could get an R4400SC CPU upgrade for turning a DS5k/240 into a DS5k/260 for a reasonable amount of money? Thanks for your patience. --- Regards, Harald From harald.koerfgen@netcologne.de Sun Oct 18 21:52:06 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA26093; Sun, 18 Oct 1998 21:52:04 +0200 (MET DST) Received-Date: Sun, 18 Oct 1998 21:52:04 +0200 (MET DST) Received: from franz.no.dom (dial9-197.netcologne.de [194.8.195.197]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA16055; Sun, 18 Oct 1998 21:51:51 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 18 Oct 1998 21:53:18 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: get_mmu_context() Cc: linux@engr.sgi.com, Vladimir Roganov Content-Length: 1466 Lines: 33 On 16-Oct-98 Gleb O. Rajko wrote: > On Thu, 15 Oct 1998 ralf@uni-koblenz.de wrote: > >> >> The performance hit will come into the game as soon as one tries to >> build a generic kernel for both R3000 and R4000. The R3000 PID and the >> R4000 ASID mechanism are slightly different and the simple approach >> to fix that is to use global variables. Which affects both your version >> and the current version. > We are going to provide support for building generic kernels in the near > future if somebody who holds r4k will help us and will try our patches > on a r4k box. I think the best time to start is when r3k will be synced > with the main branch. Perhaps, Harald may answer when it might occur. Hmmm, I'm not shure about this. If we really want to support generic kernels, that'll shurely needs some more work than a little patching in get_mmu_context. Remember, Vladimir, we needed to make changes in extremely performance critical parts of the kernel which Ralf propably won't like to have for the R4000 case. Most of them are actually compiled conditionally. To make those changes generic needs either a reasonable amount of hacking or avoidable code duplication. In fact, if we really don't care about self modifying code we should be able to remove some code duplication, for example in the fpu stuff. I'd personally prefer to have a few things sorted out before I check the R3000 stuff in. What's common opinion on this? --- Regards, Harald From bmenglan@subcorp.com.au Mon Oct 19 01:36:00 1998 Received: from gateway.subcorp.com.au (gateway.subcorp.com.au [203.28.5.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA29381; Mon, 19 Oct 1998 01:35:54 +0200 (MET DST) Received-Date: Mon, 19 Oct 1998 01:35:54 +0200 (MET DST) Received: (from uucp@localhost) by gateway.subcorp.com.au (8.7.6/8.7.3) id JAA18339 for ; Mon, 19 Oct 1998 09:19:39 +0930 (CST) Received: from unknown(69.10.0.8) by gateway.subcorp.com.au via smap (V1.3) id sma018331; Mon Oct 19 09:19:20 1998 Received: from marge.asc.com.au ([69.10.150.5]) by zaphod.asc.com.au (8.8.2/8.7.3) with SMTP id JAA05383 for ; Mon, 19 Oct 1998 09:05:15 +0930 (CST) Received: by marge.asc.com.au with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BDFB3F.C00DE750@marge.asc.com.au>; Mon, 19 Oct 1998 09:06:25 +0930 Message-ID: From: "England, Brett" To: "'linux-mips@fnet.fr'" , "'linux@engr.sgi.com'" , "'linux-mips@vger.rutgers.edu'" , "'linux-kernel@vger.rutgers.edu'" Date: Mon, 19 Oct 1998 09:06:23 +0930 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 29 Lines: 1 unsubscribe brett@myself.com From ralf@lappi.waldorf-gmbh.de Tue Oct 20 02:50:15 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16764; Tue, 20 Oct 1998 02:50:13 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 02:50:13 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA02555 for ; Tue, 20 Oct 1998 02:50:10 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id DAA01895; Mon, 19 Oct 1998 03:15:24 +0200 Message-ID: <19981019031524.C1880@uni-koblenz.de> Date: Mon, 19 Oct 1998 03:15:24 +0200 From: ralf@uni-koblenz.de To: "Michael F. March" , linux-mips@fnet.fr Subject: Re: Kernel modules References: <000501bdfa6e$28cfde60$d491b4d1@cowmix.eng.mindspring.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <000501bdfa6e$28cfde60$d491b4d1@cowmix.eng.mindspring.net>; from Michael F. March on Sun, Oct 18, 1998 at 01:06:07AM -0700 Content-Length: 285 Lines: 10 On Sun, Oct 18, 1998 at 01:06:07AM -0700, Michael F. March wrote: > I am new to MIPS Linux... > > Does anyone know the status of kernel modules? Fully supported and reliable. You'll need to use the modutils version from vger's CVS and a recent kernel to get them working. Ralf From ralf@lappi.waldorf-gmbh.de Tue Oct 20 02:50:17 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16770; Tue, 20 Oct 1998 02:50:16 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 02:50:16 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA02566 for ; Tue, 20 Oct 1998 02:50:11 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id DAA01921; Mon, 19 Oct 1998 03:29:46 +0200 Message-ID: <19981019032946.F1880@uni-koblenz.de> Date: Mon, 19 Oct 1998 03:29:46 +0200 From: ralf@uni-koblenz.de To: "Gleb O. Rajko" , linux-mips@fnet.fr Cc: Vladimir Roganov , linux@engr.sgi.com Subject: Re: get_mmu_context() References: <19981015222100.E2079@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Gleb O. Rajko on Fri, Oct 16, 1998 at 07:04:48PM +0400 Content-Length: 2148 Lines: 48 On Fri, Oct 16, 1998 at 07:04:48PM +0400, Gleb O. Rajko wrote: > We are going to provide support for building generic kernels in the near > future if somebody who holds r4k will help us and will try our patches > on a r4k box. I think the best time to start is when r3k will be synced > with the main branch. Perhaps, Harald may answer when it might occur. If you are in doubt about any R4k related changes feel free to send them to me. > > Which I want to avoid because in worst case that means we'll have to eat > > a latency of over 1400ns per cache line to fetch from memory. This number > > is measured on a R4000SC with 100Mhz. That is enough to show up right > > away on the context switch times which now look fairly nice as long as we > > don't have to swallow cache faults. > > > Perhaps, we may use global vars in most cases and patch code at bootup > for critical ones. Yes. We can actually do even more in that direction like for example eleminating calls via pointers as used throughout the mm. We insert jal instructions and patch the address as needed. Or we even overwrite the call by nops if the routine is emtpy. > > The MIPS implementation does worse, especially for the R3000 where waste the > > lowest 6 bits which effectivly truncates our ASID (or PID) to 26 bits. > > Assuming just 100,000 context switches we'll wrap around after just a bit > > more than 11 minutes. I think we can do more than 100,000 context switches > > per second on a reasonable R3000 system. > As I understand the only place where change the version is in > get_new_mmu_context(). Thus, if the version overflows we may create a new > process which will share its address space with other due to the same > ASID and varsion pair. Am I right ? Correct. > > Btw, is any of the R3000 machines stable enough to run lmbench? I'm > > interested to get results, best the raw result file from > > lmbench/results/mips-linux/. Reminds me to run lmbench on my RS3230. > Ok. I will try to run lmbench while Vladimir will think about your ideas :-) :-) Btw, lmbench has in the past helped me to kill several interesting bugs. Ralf From ralf@lappi.waldorf-gmbh.de Tue Oct 20 02:50:28 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16822; Tue, 20 Oct 1998 02:50:26 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 02:50:26 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA02658 for ; Tue, 20 Oct 1998 02:50:22 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id DAA01928; Mon, 19 Oct 1998 03:41:28 +0200 Message-ID: <19981019034128.G1880@uni-koblenz.de> Date: Mon, 19 Oct 1998 03:41:28 +0200 From: ralf@uni-koblenz.de To: Harald Koerfgen , linux-mips@fnet.fr Subject: Re: Missing set? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harald Koerfgen on Fri, Oct 16, 1998 at 12:44:45PM +0200 Content-Length: 1045 Lines: 23 On Fri, Oct 16, 1998 at 12:44:45PM +0200, Harald Koerfgen wrote: > People, when writing device drivers for DECstations, DO NEVER EVER use code like: > > save_flags(flags); > [disable or enable interrupts with en/disable_irq(irq)] > restore(flags); > > That simply doesn't work and will cause endless headache. Which is the proof that the implementation is broken. Since restore_flags is only ever used to restore one single bit, the interrupt enable bit is actually the only bit that needs to be restored. The current implementation deliberately ignores this because on the so far supported platforms there is no need to deal with this problem which saves a couple of instructions. The second possibility to fix this is to modify enable_irq/disable_irq such that they don't actually fiddle around with the status register bits but either do nothing at all or use an interrupt disable bit in the external interrupt source. The bits in the status register will then be set on bootup and will stay unchanged after that. Ralf From ralf@lappi.waldorf-gmbh.de Tue Oct 20 02:50:25 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16808; Tue, 20 Oct 1998 02:50:23 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 02:50:23 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA02624 for ; Tue, 20 Oct 1998 02:50:17 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id DAA01935; Mon, 19 Oct 1998 03:44:47 +0200 Message-ID: <19981019034447.H1880@uni-koblenz.de> Date: Mon, 19 Oct 1998 03:44:47 +0200 From: ralf@uni-koblenz.de To: Harald Koerfgen , linux-mips@fnet.fr Subject: Re: R3000 and wbflush (was: DZ-11 interrupts) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harald Koerfgen on Fri, Oct 16, 1998 at 12:44:42PM +0200 Content-Length: 1645 Lines: 45 On Fri, Oct 16, 1998 at 12:44:42PM +0200, Harald Koerfgen wrote: > Your problem might be another one. The R3000 Family processors (including the R2000) > have a four word writeback buffer which usually is transparent to memory accesses, > but may have side effects when dealing with hardware registers. > > Example: Let's assume data and status to be two hardware registers and writing > something to data has an influence on the content of the status register. A code > snippet like: > > data = whatever; > if (status == OK) > do_something(); > > might fail because it cannot be guaranteed that the write access to data happens > before the read access from status. > > The solution to this problem is to wait until the writeback buffer is empty i.e., > all write accesses are done. Unfortunately the mechanism for this is hardware > implementation specific and the DECstation engineers chose four different ways to do > this. You might want to look at arch/mips/dec/wbflush.c. > > To make a long story short, the above code snippet should look like: > > #include > > data = whatever; > wbflush(); > if (status == OK) > do_something(); > > > If you have to write to several hardware registers in a certain sequence, you have > to wait for the writeback buffer to be empty too. For example: > > reg_1 = a_value; > wbflush(); > reg_2 = another_value; > > when the access to reg_1 should be done before the access to reg_2. Harald, will this problem make any changes to code used also for the R4000 necessary? Ralf From ralf@lappi.waldorf-gmbh.de Tue Oct 20 02:50:20 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16780; Tue, 20 Oct 1998 02:50:18 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 02:50:18 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA02584 for ; Tue, 20 Oct 1998 02:50:13 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA02318; Mon, 19 Oct 1998 12:18:04 +0200 Message-ID: <19981019121804.F387@uni-koblenz.de> Date: Mon, 19 Oct 1998 12:18:04 +0200 From: ralf@uni-koblenz.de To: Harald Koerfgen , linux-mips@fnet.fr Cc: linux@cthulhu.engr.sgi.com, Vladimir Roganov Subject: Re: get_mmu_context() References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harald Koerfgen on Sun, Oct 18, 1998 at 09:53:18PM +0200 Content-Length: 4771 Lines: 101 On Sun, Oct 18, 1998 at 09:53:18PM +0200, Harald Koerfgen wrote: > > We are going to provide support for building generic kernels in the near > > future if somebody who holds r4k will help us and will try our patches > > on a r4k box. I think the best time to start is when r3k will be synced > > with the main branch. Perhaps, Harald may answer when it might occur. > > Hmmm, I'm not shure about this. If we really want to support generic kernels, > that'll shurely needs some more work than a little patching in There is a number of machines, most popular some DECstation, which are available with both CPU architectures. > get_mmu_context. Remember, Vladimir, we needed to make changes in extremely > performance critical parts of the kernel which Ralf propably won't like to > have for the R4000 case. Most of them are actually compiled conditionally. The other location for which patching might be useful are primarily the differences between the R3000 and R4000 status register, especially the KU rsp. KSU bits. What other places do you have in mind? > To make those changes generic needs either a reasonable amount of hacking or > avoidable code duplication. In fact, if we really don't care about self > modifying code we should be able to remove some code duplication, for > example in the fpu stuff. People should consider that we'll be able to hide the self modifications in C code very nicely. I would not go for anything which I consider a maintenance problem or major uglyness. Let me explain how the approach from my recent patch works: #define ASID_INC(asid) \ ({ unsigned long __asid = asid; \ __asm__("1:\taddiu\t%0,0\t\t\t\t# patched\n\t" \ ".section\t__asid_inc,\"a\"\n\t" \ ".word\t1b\n\t" \ ".previous" \ :"=r" (__asid) \ :"0" (__asid)); \ __asid; }) This macro will be used in a place where the C compiler is known to produce an addiu instruction. The trick is now that we collect the instruction's address in a special section, __asid_inc in that case. As a special service the GNU linker will generate the symbols __start_ and __stop_ if the section name is a valid C symbol name. So after boot we can easily insert the right operands into the instruction: /* Fixup an immediate instruction */ static void __i_insn_fixup(unsigned int **start, unsigned int **stop, unsigned int i_const) { unsigned int **p, *ip; for (p = start;p < stop; p++) { ip = *p; *ip = (*ip & 0xffff0000) | i_const; } } #define i_insn_fixup(section, const) \ do { \ extern unsigned int *__start_ ## section; \ extern unsigned int *__stop_ ## section; \ __i_insn_fixup(&__start_ ## section, &__stop_ ## section, const); \ } while(0) void __asid_setup(unsigned int inc, unsigned int mask, unsigned int version_mask, unsigned int first_version) { i_insn_fixup(__asid_inc, inc); [...] The technique itself can be used in quite a number more of places. All variables which are computed at boot time and never again changed later on are good candidates. Think for example of the variables dcache_size, icache_size, scache_size, dcache_lsize, icache_lsize, scache_lsize. Todo: we don't want a separate section per patched instruction. Easy to fix. We also want to get rid of the special section just like other initfunc stuff. The next class of things to patch are the zillion of function calls using function pointers. We can insert a jal instruction and patch it's destination address. Candidates for that include calls to flush_cache_all, flush_cache_mm, flush_cache_range, flush_cache_page, flush_cache_sigtramp, flush_tlb_all, flush_tlb_mm, flush_tlb_range, flush_tlb_page, add_wired_entry, clear_page, copy_page. Both parts, patching immediate opperands and function calls can be dealt with similar to the approach in the userland dynamic linker, that initially the function called is the dynamic linker's kernel equivalent which will choose the right thing to do. Extra goodie for the R3000 fraction: Many functions called via above mentioned pointers are empty, calls to them may be eleminated by overwriting the calling jal with nops. Say goodbye to another hand full of cycles. Ralf From roganov@niisi.msk.ru Mon Oct 19 12:52:18 1998 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA06858; Mon, 19 Oct 1998 12:52:00 +0200 (MET DST) Received-Date: Mon, 19 Oct 1998 12:52:00 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id OAA13389; Mon, 19 Oct 1998 14:51:32 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA16897; Mon, 19 Oct 1998 13:57:46 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA04474; Mon, 19 Oct 1998 14:42:47 +0300 (MSK) Sender: vladimir@niisi.msk.ru Message-ID: <362B18AA.334B21D3@niisi.msk.ru> Date: Mon, 19 Oct 1998 14:47:06 +0400 From: Vladimir Roganov Organization: NIISI RAS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ralf@uni-koblenz.de, linux-mips@fnet.fr Subject: Ralf's ideas: inline generic functions ? References: <19981013215927.A2692@uni-koblenz.de> <3625D799.7D923FA9@niisi.msk.ru> <19981017004408.E3370@uni-koblenz.de> Content-Type: multipart/mixed; boundary="------------E6A1031C79C34D37676A54AF" Content-Length: 10850 Lines: 425 This is a multi-part message in MIME format. --------------E6A1031C79C34D37676A54AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ralf@uni-koblenz.de wrote: > > Ok, here is the first working and tested version of my runtime patched > get_mmu_context thing. While writing the code I noticed that the code > patching stuff is actually already a part of what I was intending to implement > since long time like for example getting rid of function pointers and can > be used to optimize many more things throughout the kernel. So while some > parts already look somewhat generic I'd like to make them really generic. > The thing is probably going to look somewhat similar to the Sparc btfixup > code which I'm going to read now. > > Ralf > > ------------------------------------------------------------------------ > > asid-patch Name: asid-patch > Type: Plain Text (text/plain) Hi Ralf, Hi others ! Looking to code switches across Linux sources, I also think about idea to implement emulation of generic functions (method dispatchers), for GCC which are self-(re)inlining at runtime. Really, this think can reasonable express any quantity of machine/processor/other_condition specific, same time code using one will looks okey and run faster. It looks You mean something analogical, so it should be nice thing. What about BTFIXUP, it looks less flexible as I understand from sources. We have i386,R3000,Sparc computers under Linux, so we are able (and interesting) to help with testing such thing. Please send ideas/proposals/code. Attached code contains few ideas (or, for optimistic people, prototype) of "Generic Function Inliner", working (as a little demo) at i386. It allows to define generic function, any time to add methods and (re)inline best candidate from methods using priority-based scheme. It should be enforced and extended many ways to be useful in practice... It is also interesting to receive comments about this idea. In hope to be useful, With best regards, Vladimir --------------E6A1031C79C34D37676A54AF Content-Type: text/plain; charset=us-ascii; name="gfi.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gfi.c" /* * Generic Function Inliner (prototype!) * * GCC supports smart asm(...) directive, so it looks able to use it * for runtime code inlining. To support inline 'methods' * few structures for code manipulation are created. * During initialization and work somebody can define their method for * any generic function, what will hook reinlining using priority-based * scheme. */ #include #include #include /* * The body of generic function, containing self-inliner stuff. * The important parameters of code are: * 1) reserved size (10 bytes for this example) * 2) convention for parameter pass, value return and regs/mem changes * All methods must have same interface (signature). */ #define generic3(fun,a,b,c) ({ \ register unsigned long out asm("eax"); \ register unsigned long aa asm("ebx") = a; \ register unsigned long bb asm("ecx") = b; \ register unsigned long cc asm("edx") = c; \ asm ("call __generic_inliner; .asciz \"" fun "\"; .asciz \"\""\ : "=r" (out) \ : "r" (aa), "r" (bb), "r" (cc) \ : "eax", "ebx", "ecx", "edx" ); \ out; \ }) /* * Structures needed to store functions/methods/usages */ typedef int (*pred_t)(); /* Priority predicate (using global vars) */ struct method { struct method* next; char *name; char *from; char *to; pred_t pred; }; struct usage { struct usage *next; char *from; char *to; }; struct generic { struct generic *next; char *fun; struct method *best_method; struct method *methods; struct usage *usages; int usage_count; } *generics = NULL; /* Utility */ void *xmalloc (int size) { void *m = malloc(size); if (!m) printf("memory exceeded\n"); memset(m,0,size); return m; } /* Find generic or return last link address */ struct generic **find_generic(char *fun) { struct generic **g = &generics; while (*g) { if (!strcmp(fun,(*g)->fun)) break; g = &(*g)->next; } return g; } /* Return or create new generic */ struct generic *intern_generic(char *fun) { struct generic **g = find_generic(fun); if (!*g) { *g = xmalloc(sizeof(**g)); (*g)->fun = fun; } return *g; } /* Icache invalidation (for test only ) */ static flush_icache_range (char* from, char *to) { mprotect((void*)((unsigned long)from & ~0xfff), 0x1000, PROT_EXEC|PROT_WRITE); } /* * Inline given method to given usage place */ #define NOP_CODE 0x90 static void do_inline (struct method *m, struct usage* u) { if (m->to-m->from > u->to-u->from) /* In this case we can generate trampoline with call ?! */ printf ("unable to inline: method too long\n"); flush_icache_range (u->from, u->to); // to be able to modify code ! printf("Inlining code from %x to %x\n", u->from, u->to); printf("%s:%d\n", __FUNCTION__, __LINE__); memset(u->from, NOP_CODE, u->to-u->from); printf("u->from=%x, m->from=%x, m->to-m->from=%d\n", u->from, m->from, m->to-m->from); memcpy(u->from, m->from, m->to-m->from); printf("code: %x %x %x %x %x %x\n", u->from[0], u->from[1], u->from[2], u->from[3], u->from[4], u->from[5]); flush_icache_range (u->from, u->to); } /* * Reinline given function choosing best candidate */ void reinline_generic(char *fun) { struct generic *g = *find_generic(fun); struct method *m, *old_best = NULL; struct usage *u; int max = 0; int val; if (!g) printf ("no methods for '%s'", fun); old_best = g -> best_method; g -> best_method = NULL; m = g -> methods; while(m) { val = m->pred(); if (val > max) { g -> best_method = m; max = val; } m = m->next; } u = g -> usages; if (!g->best_method && u) printf("no candidates for '%s' function usages\n", fun); if (old_best != g->best_method) while(u) { do_inline(g->best_method, u); u = u -> next; } } /* Define new method */ void __defmethod(char *fun, pred_t pred, char *name, char* code_start, char* code_end) { struct generic *g = intern_generic(fun); struct method *m = xmalloc(sizeof(*m)); m->next = g->methods; m->from = code_start; m->to = code_end; m->pred = pred; m->name = name; g->methods = m; reinline_generic(fun); } #ifndef __STR #define __STR(x) #x #endif #ifndef STR #define STR(x) __STR(x) #endif /* Macro used to define method as asm(...) inline code */ #define defmethod(fun,pred,code) {\ register char* code_start asm("eax"); \ register char* code_end asm("ebx"); \ asm ("movl $start_" STR(pred) ", %%eax\n" \ "movl $end_" STR(pred) ", %%ebx\n" \ "jmp end_" STR(pred)"\n" \ "start_" STR(pred)":\n" \ code "\n" \ "end_" STR(pred)":\n" \ : \ : "r" (code_start), "r" (code_end)); \ __defmethod(fun,pred,STR(pred),code_start,code_end); \ } /* * Function called from usage places, which register * generic function usage and overlaps itself by best method */ #define CALL_SIZE 5 static unsigned char* _generic_inliner (char* address) { unsigned char* fun = address; unsigned char* from = address - CALL_SIZE; unsigned char* to = address; while (*to) to++; // Skip name to++; while (*to) to++; // Skip NOPs to++; printf ("fun = %s, address = %x, size = %d, to = %x\n", fun, from, to-from, to); { struct usage *u; struct generic *g = *find_generic(fun); if (!g) printf ("Undefined generic '%s'\n", fun); if (!g->best_method) printf("No best method for '%s'\n", fun); u = xmalloc(sizeof(*u)); u -> from = from; u -> to = to; u -> next = g -> usages; g -> usages = u; g -> usage_count++; do_inline (g->best_method, u); } printf("%s:%d\n", __FUNCTION__, __LINE__); if (address) /* To prevent GCC optimization */ return from; /* __generic_inliner is a trampoline for above */ asm(".globl __generic_inliner; __generic_inliner:\n" "call _generic_inliner\n" "pop %%ebx\n" "jmp %%eax\n" : : : "eax", "ebx"); return "Impossible to be here"; } /* * Control routine, printing some statistic */ void show_generics(void) { struct generic *g = generics; printf ("Generic functions in use:\n"); while (g) { printf("\t%s:\tbest_method=%s\tusages=%d\n", g->fun, g->best_method ? g->best_method->name : "(NULL)", g->usage_count); g = g -> next; } printf ("----------------------------------------------\n"); } /* ------------------------------------------ * All above should have simple interface, * to make it's usage as simple as possible /* ------------------------------------------ /* Something in headers: */ #define fun(a,b,c) generic3("fun",a,b,c) /* Module code */ #define R3000 1 #define R4000 2 int cpu = R3000; static int r3000_fun() { return cpu == R3000; } static int r4000_fun() { return cpu == R4000; } void r3000_init(void) { printf("%s:%d\n", __FUNCTION__, __LINE__); defmethod("fun", r3000_fun, "movl $12345, %%eax"); printf("%s:%d\n", __FUNCTION__, __LINE__); } /* Code users */ main () { show_generics(); r3000_init(); show_generics(); printf ("%d\n", fun(1,2,3)); cpu = R4000; defmethod("fun", r4000_fun, "movl $54321, %%eax"); show_generics(); printf ("%d\n", fun(1,2,3)); show_generics(); } --------------E6A1031C79C34D37676A54AF Content-Type: text/plain; charset=us-ascii; name="gfi.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gfi.out" Generic functions in use: ---------------------------------------------- r3000_init:311 r3000_init:313 Generic functions in use: fun: best_method=r3000_fun usages=0 ---------------------------------------------- fun = fun, address = 8048a42, size = 10, to = 8048a4c Inlining code from 8048a42 to 8048a4c do_inline:112 u->from=8048a42, m->from=80489e8, m->to-m->from=5 code: ffffffb8 39 30 0 0 ffffff90 _generic_inliner:242 12345 Inlining code from 8048a42 to 8048a4c do_inline:112 u->from=8048a42, m->from=8048a6d, m->to-m->from=5 code: ffffffb8 31 ffffffd4 0 0 ffffff90 Generic functions in use: fun: best_method=r4000_fun usages=1 ---------------------------------------------- fun = fun, address = 8048a9f, size = 10, to = 8048aa9 Inlining code from 8048a9f to 8048aa9 do_inline:112 u->from=8048a9f, m->from=8048a6d, m->to-m->from=5 code: ffffffb8 31 ffffffd4 0 0 ffffff90 _generic_inliner:242 54321 Generic functions in use: fun: best_method=r4000_fun usages=2 ---------------------------------------------- --------------E6A1031C79C34D37676A54AF-- From engel@math.uni-siegen.de Mon Oct 19 13:11:36 1998 Received: from fourier.numerik.math.uni-siegen.de (fourier.numerik.math.uni-siegen.de [141.99.2.230]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA07441; Mon, 19 Oct 1998 13:11:35 +0200 (MET DST) Received-Date: Mon, 19 Oct 1998 13:11:35 +0200 (MET DST) Received: (from engel@localhost) by fourier.numerik.math.uni-siegen.de (Mailhost) id NAA24394 for linux-mips@fnet.fr; Mon, 19 Oct 1998 13:12:03 +0200 (MET DST) From: Michael Engel Message-Id: <199810191112.NAA24394@fourier.numerik.math.uni-siegen.de> Subject: Re: WTB: R4400SC CPU upgrade for a DS5000/240 To: linux-mips@fnet.fr Date: Mon, 19 Oct 1998 13:12:02 +0200 (MET DST) In-Reply-To: from "Harald Koerfgen" at Oct 18, 98 09:53:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 480 Lines: 14 Hi Harald, > I apologize in advance for bothering you, but it appears to be of invaluable > help to have a R4000 based DECstation for comparison and evaluation purposes. > > Does anybbody have an idea where I could get an R4400SC CPU upgrade for > turning a DS5k/240 into a DS5k/260 for a reasonable amount of money? Sven Rudolph has offered to lend me a R4000 based DECstation, most probably a 5000/150. We'll just have to arrange shipping from Dresden. regards, Michael From imp@village.org Mon Oct 19 22:51:46 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id WAA12534; Mon, 19 Oct 1998 22:51:43 +0200 (MET DST) Received-Date: Mon, 19 Oct 1998 22:51:43 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zVMFj-0007jp-00; Mon, 19 Oct 1998 14:50:07 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id OAA29162; Mon, 19 Oct 1998 14:50:06 -0600 (MDT) Message-Id: <199810192050.OAA29162@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: Port for NEC RiscServer 2200 Cc: schwim@earthlink.net, todd.vohs@gecits.ge.com In-reply-to: Your message of "Sat, 17 Oct 1998 20:29:01 PDT." References: Date: Mon, 19 Oct 1998 14:50:06 -0600 From: Warner Losh Content-Length: 687 Lines: 16 In message "Todd M. Vohs" writes: : I've got a dual processor NEC RiscServer 2200 that I'd like to get Linux : running on. I have downloaded and successfully ran the milo files. Now I : need to know where I can actually get a usable port from, and some : directions on how to install it to my system. Can you help? First, modify milo[1] to grok the NEC RiscServer. Next, modify Linux to grok the NEC RiscServer. Boot. :-) Alternatively, find someone else to do the port for you. Where are you located? I'm in Boulder Colorado if you are looking for someone local. Warner [1] or the new boot blocks that are being worked on. From matt@molnir.demon.co.uk Tue Oct 20 00:53:31 1998 Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA14633; Tue, 20 Oct 1998 00:53:30 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 00:53:30 +0200 (MET DST) Received: from [193.237.65.231] (helo=molnir.our.house) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zVOB5-0006w4-00 for linux-mips@fnet.fr; Mon, 19 Oct 1998 22:53:28 +0000 Received: from molnir.demon.co.uk (matt@cook.our.house [192.168.100.1]) by molnir.our.house (8.9.1/8.9.1) with ESMTP id XAA10058 for ; Mon, 19 Oct 1998 23:51:56 +0100 Received: (from matt@localhost) by molnir.demon.co.uk (8.9.1/8.9.1) id XAA09932 for linux-mips@fnet.fr; Mon, 19 Oct 1998 23:51:59 +0100 From: Matt Foster Message-Id: <199810192251.XAA09932@molnir.demon.co.uk> Subject: Problems building 2.1.121-r3000 To: linux-mips@fnet.fr Date: Mon, 19 Oct 1998 23:51:58 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 738 Lines: 21 Hi, I'm having problems compiling " mipsel-linux-ld -static -G 0 -T arch/mips/ld.script.little arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \ arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a drivers/scsi/scsi.a drivers/video/video.a \ arch/mips/lib/lib.a /usr/src/linux-2.1.121-r3000/lib/lib.a arch/mips/lib/lib.a \ -o vmlinux drivers/video/video.a: could not read symbols: Archive has no index; run ranlib to add one make: *** [vmlinux] Error 1 " Doubtless something dumb, but can someone point me in the right direction? Cheers. Matt From pork_dude@hotmail.com Tue Oct 20 04:51:39 1998 Received: from hotmail.com (f26.hotmail.com [207.82.250.37]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id EAA20796; Tue, 20 Oct 1998 04:51:38 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 04:51:38 +0200 (MET DST) Received: (qmail 16180 invoked by uid 0); 20 Oct 1998 02:51:03 -0000 Message-ID: <19981020025103.16179.qmail@hotmail.com> Received: from 209.160.171.168 by www.hotmail.com with HTTP; Mon, 19 Oct 1998 19:51:02 PDT X-Originating-IP: [209.160.171.168] From: "Matthew Bean" To: linux-mips@fnet.fr Subject: Porting Lunix to Sony Playstation? Content-Type: text/plain Date: Mon, 19 Oct 1998 19:51:02 PDT Content-Length: 233 Lines: 5 I would like to know where i could get the sources to the R3051a version of Linux/MIPS. I can't get anywhere without it. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From mmarch@mindspring.net Tue Oct 20 05:34:02 1998 Received: from db.indirect.com (root@db.indirect.com [165.247.198.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA21930; Tue, 20 Oct 1998 05:34:01 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 05:34:01 +0200 (MET DST) Received: from cowmix (dsld50.phnx.uswest.net [209.180.145.49]) by db.indirect.com (8.8.8/8.8.5) with SMTP id UAA17230 for ; Mon, 19 Oct 1998 20:34:49 -0700 Reply-To: From: "Michael F. March" To: Subject: RE: Kernel modules Date: Mon, 19 Oct 1998 20:31:04 -0700 Message-ID: <000c01bdfbda$112ac5a0$3191b4d1@cowmix.eng.mindspring.net> 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 8.5, Build 4.71.2377.0 In-reply-to: <19981019031524.C1880@uni-koblenz.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Length: 558 Lines: 21 how do I get to the CVS server? thanks! > -----Original Message----- > From: ralf@uni-koblenz.de [mailto:ralf@uni-koblenz.de] > Sent: Sunday, October 18, 1998 6:15 PM > To: Michael F. March; linux-mips@fnet.fr > Subject: Re: Kernel modules > > > On Sun, Oct 18, 1998 at 01:06:07AM -0700, Michael F. March wrote: > > > I am new to MIPS Linux... > > > > Does anyone know the status of kernel modules? > > Fully supported and reliable. You'll need to use the modutils > version from > vger's CVS and a recent kernel to get them working. > > Ralf > From imp@village.org Tue Oct 20 06:07:31 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id GAA22545; Tue, 20 Oct 1998 06:07:29 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 06:07:29 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zVT4o-0000EI-00; Mon, 19 Oct 1998 22:07:18 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id WAA03233; Mon, 19 Oct 1998 22:07:26 -0600 (MDT) Message-Id: <199810200407.WAA03233@harmony.village.org> To: ralf@uni-koblenz.de Subject: Re: get_mmu_context() Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com In-reply-to: Your message of "Mon, 19 Oct 1998 12:18:04 +0200." <19981019121804.F387@uni-koblenz.de> References: <19981019121804.F387@uni-koblenz.de> Date: Mon, 19 Oct 1998 22:07:26 -0600 From: Warner Losh Content-Length: 553 Lines: 13 Wouldn't it be easier to have ld to have variant fixup records? That way you could patch all instances at run time, much like we do when we load stuff now... You are basically duplicating the functionality of the linker here for no good reason. Actually, besides the non-standard aspect of it, there is a good reason: it is easier to hack like this than to do battle with the bfd and/or boot blocks to get this to happen. :-) It is a way cool hack, don't get me wrong, but it just seems that it would be more useful to be generic like that. Warner From davem@dm.cobaltmicro.com Tue Oct 20 06:14:25 1998 Received: from dm.cobaltmicro.com (davem@dm.cobaltmicro.com [209.133.34.35]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA23056; Tue, 20 Oct 1998 06:14:24 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 06:14:24 +0200 (MET DST) Received: (from davem@localhost) by dm.cobaltmicro.com (8.8.7/8.8.7) id VAA13477; Mon, 19 Oct 1998 21:13:18 -0700 Date: Mon, 19 Oct 1998 21:13:18 -0700 Message-Id: <199810200413.VAA13477@dm.cobaltmicro.com> From: "David S. Miller" To: imp@village.org CC: ralf@uni-koblenz.de, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com In-reply-to: <199810200407.WAA03233@harmony.village.org> (message from Warner Losh on Mon, 19 Oct 1998 22:07:26 -0600) Subject: Re: get_mmu_context() References: <19981019121804.F387@uni-koblenz.de> <199810200407.WAA03233@harmony.village.org> Content-Length: 386 Lines: 13 Date: Mon, 19 Oct 1998 22:07:26 -0600 From: Warner Losh Wouldn't it be easier to have ld to have variant fixup records? That way you could patch all instances at run time, much like we do when we load stuff now... See sparc32's btfixup in the kernel sources for the best implementation I've ever seen. Later, David S. Miller davem@dm.cobaltmicro.com From ppoyhone@tirion.ntc.nokia.com Tue Oct 20 06:58:38 1998 Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA23711; Tue, 20 Oct 1998 06:58:38 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 06:58:38 +0200 (MET DST) Received: from tirion.ntc.nokia.com (tirion.ntc.nokia.com [131.228.148.148]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id HAA16095 for ; Tue, 20 Oct 1998 07:58:08 +0300 (EET DST) Received: from localhost (ppoyhone@localhost) by tirion.ntc.nokia.com (8.7.5/8.7.3) with SMTP id HAA08496 for ; Tue, 20 Oct 1998 07:49:25 +0300 (EET DST) Date: Tue, 20 Oct 1998 07:49:25 +0300 (EET DST) From: Petteri P|yh|nen To: linux-mips@fnet.fr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 37 Lines: 3 unsubscribe ppoyhone@tele.nokia.fi From ppoyhone@tirion.ntc.nokia.com Tue Oct 20 06:59:06 1998 Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA23737; Tue, 20 Oct 1998 06:59:05 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 06:59:05 +0200 (MET DST) Received: from tirion.ntc.nokia.com (tirion.ntc.nokia.com [131.228.148.148]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id HAA16161 for ; Tue, 20 Oct 1998 07:58:36 +0300 (EET DST) Received: from localhost (ppoyhone@localhost) by tirion.ntc.nokia.com (8.7.5/8.7.3) with ESMTP id HAA08499 for ; Tue, 20 Oct 1998 07:49:53 +0300 (EET DST) Date: Tue, 20 Oct 1998 07:49:53 +0300 (EET DST) From: Petteri P|yh|nen To: linux-mips@fnet.fr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Length: 515 Lines: 14 subscribe ppoyhone@tirion.ntc.nokia.com -Petteri P=F6yh=F6nen- ______________________________________________________ Nokia Telecommunications Oy SWP/R&D/NSCYMH (HW Configuration Management) (Valimotie 13A/6, Hki) P.O. Box 318, FIN-00045 NOKIA GROUP Tel/Fax : +358 9 511 69042 Gsm : +358 40 5627347 VAX : TNCLUS::PPOYHONEN E-mail : Petteri.Poyhonen@ntc.nokia.com ______________________________________________________ From R.vandenBerg@inter.NL.net Tue Oct 20 06:59:35 1998 Received: from grootstal.nijmegen.inter.nl.net (grootstal.nijmegen.inter.nl.net [193.67.237.11]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA23763; Tue, 20 Oct 1998 06:59:35 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 06:59:35 +0200 (MET DST) Received: from whale.dutch.mountain by grootstal.nijmegen.inter.nl.net via hn51-58.Hoorn.NL.net [193.79.46.222] with SMTP for id GAA25132 (8.8.8/1.6); Tue, 20 Oct 1998 06:59:33 +0200 (MET DST) Date: Tue, 20 Oct 1998 06:59:33 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: Problems building 2.1.121-r3000 In-Reply-To: <199810192251.XAA09932@molnir.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1040 Lines: 26 On Mon, 19 Oct 1998, Matt Foster wrote: > I'm having problems compiling > > " > mipsel-linux-ld -static -G 0 -T arch/mips/ld.script.little arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \ > arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ > fs/filesystems.a \ > net/network.a \ > drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a drivers/scsi/scsi.a drivers/video/video.a \ > arch/mips/lib/lib.a /usr/src/linux-2.1.121-r3000/lib/lib.a arch/mips/lib/lib.a \ > -o vmlinux > drivers/video/video.a: could not read symbols: Archive has no index; run ranlib to add one > make: *** [vmlinux] Error 1 > " For which machine are you trying to compile a kernel? > Doubtless something dumb, but can someone point me in the right direction? linux-2.1.121-r3000-pre1.tgz is meant for Baget and DECstation machines, and for DECstations right now only promconsole and serial console are supported, nothing in drvers/video. Regards, Richard From ralf@lappi.waldorf-gmbh.de Tue Oct 20 17:59:34 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA05791; Tue, 20 Oct 1998 17:59:27 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 17:59:27 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-10.uni-koblenz.de [141.26.249.10]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id RAA14585 for ; Tue, 20 Oct 1998 17:59:16 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA05625; Tue, 20 Oct 1998 12:40:36 +0200 Message-ID: <19981020124035.L676@uni-koblenz.de> Date: Tue, 20 Oct 1998 12:40:35 +0200 From: ralf@uni-koblenz.de To: Warner Losh , linux-mips@fnet.fr Cc: schwim@earthlink.net, todd.vohs@gecits.ge.com Subject: Re: Port for NEC RiscServer 2200 References: <199810192050.OAA29162@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810192050.OAA29162@harmony.village.org>; from Warner Losh on Mon, Oct 19, 1998 at 02:50:06PM -0600 Content-Length: 478 Lines: 13 On Mon, Oct 19, 1998 at 02:50:06PM -0600, Warner Losh wrote: > [1] or the new boot blocks that are being worked on. No boot blocks. As per standard ARC does not support boot blocks. Not that I know of _any_ ARC implementation that doesn't massively violate the ARC standard. Did I mention that the ARC standard document is (C) by MS ... The new solution will be a single file which can be executed from the ARC command line without having to use a tool like Milo. Ralf From ralf@lappi.waldorf-gmbh.de Tue Oct 20 17:59:48 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA05813; Tue, 20 Oct 1998 17:59:47 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 17:59:47 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-10.uni-koblenz.de [141.26.249.10]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id RAA14782 for ; Tue, 20 Oct 1998 17:59:40 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id MAA05629; Tue, 20 Oct 1998 12:43:40 +0200 Message-ID: <19981020124340.M676@uni-koblenz.de> Date: Tue, 20 Oct 1998 12:43:40 +0200 From: ralf@uni-koblenz.de To: Matt Foster , linux-mips@fnet.fr Subject: Re: Problems building 2.1.121-r3000 References: <199810192251.XAA09932@molnir.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810192251.XAA09932@molnir.demon.co.uk>; from Matt Foster on Mon, Oct 19, 1998 at 11:51:58PM +0100 Content-Length: 539 Lines: 15 On Mon, Oct 19, 1998 at 11:51:58PM +0100, Matt Foster wrote: > drivers/video/video.a: could not read symbols: Archive has no index; run ranlib to add one > make: *** [vmlinux] Error 1 > " > > Doubtless something dumb, but can someone point me in the right direction? > Cheers. This typically happens for archives generated using the wrong ar archiver, that is for example the i386-linux-ar. It may also be cause by a corrupt archive (try to remove drivers/video/video.a and re-make) or in some cases even zero-length archives. Ralf From matt@molnir.demon.co.uk Tue Oct 20 13:00:20 1998 Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA02590; Tue, 20 Oct 1998 13:00:05 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 13:00:05 +0200 (MET DST) Received: from [193.237.65.231] (helo=molnir.our.house) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zVZWB-0001Wu-00 for linux-mips@fnet.fr; Tue, 20 Oct 1998 11:00:00 +0000 Received: from molnir.demon.co.uk (matt@cook.our.house [192.168.100.1]) by molnir.our.house (8.9.1/8.9.1) with ESMTP id LAA11744 for ; Tue, 20 Oct 1998 11:58:52 +0100 Received: (from matt@localhost) by molnir.demon.co.uk (8.9.1/8.9.1) id LAA00144 for linux-mips@fnet.fr; Tue, 20 Oct 1998 11:58:52 +0100 From: Matt Foster Message-Id: <199810201058.LAA00144@molnir.demon.co.uk> Subject: Re: Problems building 2.1.121-r3000 To: linux-mips@fnet.fr Date: Tue, 20 Oct 1998 11:58:51 +0100 (BST) In-Reply-To: from "Richard van den Berg" at Oct 20, 98 06:59:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6571 Lines: 306 > > On Mon, 19 Oct 1998, Matt Foster wrote: > > > I'm having problems compiling > > > > " > For which machine are you trying to compile a kernel? Decstation 5000/25 (Personal) > > > Doubtless something dumb, but can someone point me in the right direction? > > linux-2.1.121-r3000-pre1.tgz is meant for Baget and DECstation machines, > and for DECstations right now only promconsole and serial console are > supported, nothing in drvers/video. > binutils2.8.1 and gcc 2.7.2 from the decstation website. Below is .config Thanks, Matt # # Automatically generated make config: don't edit # # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Machine selection # # CONFIG_ACER_PICA_61 is not set # CONFIG_MIPS_MAGNUM_4000 is not set # CONFIG_OLIVETTI_M700 is not set # CONFIG_SGI is not set # CONFIG_SNI_RM200_PCI is not set # # CPU selection # CONFIG_CPU_R3000=y # CONFIG_CPU_R6000 is not set # CONFIG_CPU_R4300 is not set # CONFIG_CPU_R4X00 is not set # CONFIG_CPU_R5000 is not set # CONFIG_CPU_NEVADA is not set # CONFIG_CPU_R8000 is not set # CONFIG_CPU_R10000 is not set # # General setup # CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ELF_KERNEL=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_SYSCTL is not set # CONFIG_PARPORT is not set # # Loadable module support # # CONFIG_MODULES is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_IDEDISK is not set # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_IDE_CHIPSETS is not set # # Additional Block Devices # # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_RAM=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BLK_DEV_XD is not set CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE is not set # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y CONFIG_NETLINK=y # CONFIG_RTNETLINK is not set # CONFIG_NETLINK_DEV is not set # CONFIG_FIREWALL is not set # CONFIG_NET_ALIAS is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_IP_ROUTER is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_ALIAS is not set # CONFIG_SYN_COOKIES is not set # # (it is safe to leave these untouched) # # CONFIG_INET_RARP is not set CONFIG_IP_NOSR=y # CONFIG_SKB_LARGE is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # # Network device support # CONFIG_NETDEVICES=y # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_EQUALIZER is not set CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_BAGETLANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_NET_ISA is not set # CONFIG_NET_EISA is not set # CONFIG_NET_POCKET is not set # CONFIG_FDDI is not set # CONFIG_DLCI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_RADIO is not set # CONFIG_TR is not set # CONFIG_WAN_DRIVERS is not set # CONFIG_LAPBETHER is not set # CONFIG_X25_ASY is not set # # AX.25 network device drivers # # CONFIG_MKISS is not set # CONFIG_6PACK is not set # CONFIG_BPQETHER is not set # CONFIG_DMASCC is not set # CONFIG_SCC is not set # CONFIG_BAYCOM_SER_FDX is not set # CONFIG_BAYCOM_SER_HDX is not set # CONFIG_BAYCOM_PAR is not set # CONFIG_BAYCOM_EPP is not set # CONFIG_SOUNDMODEM is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # CD-ROM drivers (not for SCSI or IDE/ATAPI drives) # # CONFIG_CD_NO_IDESCSI is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_UNIX98_PTYS is not set # CONFIG_MOUSE is not set # CONFIG_QIC02_TAPE is not set # CONFIG_APM is not set # CONFIG_WATCHDOG is not set # CONFIG_RTC is not set # CONFIG_VIDEO_DEV is not set # CONFIG_NVRAM is not set # CONFIG_JOYSTICK is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # # Filesystems # # CONFIG_QUOTA is not set CONFIG_MINIX_FS=y CONFIG_EXT2_FS=y # CONFIG_ISO9660_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set CONFIG_PROC_FS=y CONFIG_NFS_FS=y # CONFIG_NFSD is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_CODA_FS is not set # CONFIG_SMB_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_AUTOFS_FS is not set CONFIG_UFS_FS=y CONFIG_BSD_DISKLABEL=y # CONFIG_SMD_DISKLABEL is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_MAC_PARTITION is not set # CONFIG_NLS is not set # # Sound # # CONFIG_SOUND is not set # # Kernel hacking # CONFIG_CROSSCOMPILE=y # CONFIG_REMOTE_DEBUG is not set # CONFIG_MAGIC_SYSRQ is not set From R.vandenBerg@inter.NL.net Tue Oct 20 15:42:24 1998 Received: from grootstal.nijmegen.inter.nl.net (grootstal.nijmegen.inter.nl.net [193.67.237.11]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA04290; Tue, 20 Oct 1998 15:42:19 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 15:42:19 +0200 (MET DST) Received: from whale.dutch.mountain by grootstal.nijmegen.inter.nl.net via hn51-38.Hoorn.NL.net [193.79.46.202] with SMTP for id PAA14575 (8.8.8/1.6); Tue, 20 Oct 1998 15:42:10 +0200 (MET DST) Date: Tue, 20 Oct 1998 15:42:10 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: Problems building 2.1.121-r3000 In-Reply-To: <199810201058.LAA00144@molnir.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-1882929066-908890930=:726" Content-Length: 8765 Lines: 161 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811839-1882929066-908890930=:726 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Oct 1998, Matt Foster wrote: > > For which machine are you trying to compile a kernel? > Decstation 5000/25 (Personal) That's easy, I've one too. > binutils2.8.1 and gcc 2.7.2 from the decstation website. > Below is .config That's allright too, I've attached a diff of your config against mine. You should boot with `boot 3/tftp root=/dev/ram`. If you want to play with networking code remove initrd and enable nfsroot + bootp (easiest done with `make menuconfig` and boot with `boot 3/tftp root=/dev/nfs`. Have fun. Regards, Richard ---1463811839-1882929066-908890930=:726 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=config-diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: configuration diff MmMyDQo8ICMgQXV0b21hdGljYWxseSBnZW5lcmF0ZWQgbWFrZSBjb25maWc6 IGRvbid0IGVkaXQNCi0tLQ0KPiAjIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVk IGJ5IG1ha2UgbWVudWNvbmZpZzogZG9uJ3QgZWRpdA0KOGM4DQo8ICMgQ09O RklHX0VYUEVSSU1FTlRBTCBpcyBub3Qgc2V0DQotLS0NCj4gQ09ORklHX0VY UEVSSU1FTlRBTD15DQoxM2ExNCwxNg0KPiAjIENPTkZJR19BTEdPUl9QNDAz MiBpcyBub3Qgc2V0DQo+ICMgQ09ORklHX0JBR0VUX01JUFMgaXMgbm90IHNl dA0KPiBDT05GSUdfREVDU1RBVElPTj15DQozOGE0Mg0KPiAjIENPTkZJR19C SU5GTVRfSkFWQSBpcyBub3Qgc2V0DQo0M2Q0Ng0KPCAjIENPTkZJR19QQVJQ T1JUIGlzIG5vdCBzZXQNCjUxYzU0DQo8ICMgQmxvY2sgZGV2aWNlcw0KLS0t DQo+ICMgRnJhbWUgQnVmZmVyIHN1cHBvcnQNCjUzLDU0YzU2DQo8ICMgQ09O RklHX0JMS19ERVZfRkQgaXMgbm90IHNldA0KPCBDT05GSUdfQkxLX0RFVl9J REU9eQ0KLS0tDQo+ICMgQ09ORklHX0ZCIGlzIG5vdCBzZXQNCjU3YzU5DQo8 ICMgUGxlYXNlIHNlZSBEb2N1bWVudGF0aW9uL2lkZS50eHQgZm9yIGhlbHAv aW5mbyBvbiBJREUgZHJpdmVzDQotLS0NCj4gIyBUVVJCT2NoYW5uZWwgc3Vw cG9ydA0KNTksNjZjNjENCjwgIyBDT05GSUdfQkxLX0RFVl9IRF9JREUgaXMg bm90IHNldA0KPCAjIENPTkZJR19CTEtfREVWX0lERURJU0sgaXMgbm90IHNl dA0KPCAjIENPTkZJR19CTEtfREVWX0lERUNEIGlzIG5vdCBzZXQNCjwgIyBD T05GSUdfQkxLX0RFVl9JREVUQVBFIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdf QkxLX0RFVl9JREVGTE9QUFkgaXMgbm90IHNldA0KPCAjIENPTkZJR19CTEtf REVWX0lERVNDU0kgaXMgbm90IHNldA0KPCAjIENPTkZJR19CTEtfREVWX0NN RDY0MCBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX0lERV9DSElQU0VUUyBpcyBu b3Qgc2V0DQotLS0NCj4gQ09ORklHX1RDPXkNCjY5YzY0DQo8ICMgQWRkaXRp b25hbCBCbG9jayBEZXZpY2VzDQotLS0NCj4gIyBCbG9jayBkZXZpY2VzDQo3 MGE2Niw2OA0KPiAjIENPTkZJR19CTEtfREVWX0ZEIGlzIG5vdCBzZXQNCj4g IyBDT05GSUdfQkxLX0RFVl9JREUgaXMgbm90IHNldA0KPiAjIENPTkZJR19C TEtfREVWX0hEX09OTFkgaXMgbm90IHNldA0KNzVjNzMNCjwgIyBDT05GSUdf QkxLX0RFVl9JTklUUkQgaXMgbm90IHNldA0KLS0tDQo+IENPTkZJR19CTEtf REVWX0lOSVRSRD15DQo4NCw4N2M4Miw4Mw0KPCBDT05GSUdfUEFDS0VUPXkN CjwgQ09ORklHX05FVExJTks9eQ0KPCAjIENPTkZJR19SVE5FVExJTksgaXMg bm90IHNldA0KPCAjIENPTkZJR19ORVRMSU5LX0RFViBpcyBub3Qgc2V0DQot LS0NCj4gIyBDT05GSUdfUEFDS0VUIGlzIG5vdCBzZXQNCj4gIyBDT05GSUdf TkVUTElOSyBpcyBub3Qgc2V0DQoxMDEsMTA0ZDk2DQo8IA0KPCAjDQo8ICMg KGl0IGlzIHNhZmUgdG8gbGVhdmUgdGhlc2UgdW50b3VjaGVkKQ0KPCAjDQox MDgsMTExYzEwMA0KPCANCjwgIw0KPCAjICANCjwgIw0KLS0tDQo+ICMgQ09O RklHX0lQVjYgaXMgbm90IHNldA0KMTEzYTEwMywxMTINCj4gIyBDT05GSUdf WDI1IGlzIG5vdCBzZXQNCj4gIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0DQo+ ICMgQ09ORklHX0JSSURHRSBpcyBub3Qgc2V0DQo+ICMgQ09ORklHX0xMQyBp cyBub3Qgc2V0DQo+ICMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0DQo+ICMg Q09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldA0KPiAjIENPTkZJR19ORVRf RkFTVFJPVVRFIGlzIG5vdCBzZXQNCj4gIyBDT05GSUdfTkVUX0hXX0ZMT1dD T05UUk9MIGlzIG5vdCBzZXQNCj4gIyBDT05GSUdfQ1BVX0lTX1NMT1cgaXMg bm90IHNldA0KPiAjIENPTkZJR19ORVRfU0NIRUQgaXMgbm90IHNldA0KMTE4 LDE2M2MxMTcNCjwgQ09ORklHX1NDU0k9eQ0KPCANCjwgIw0KPCAjIFNDU0kg c3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pDQo8ICMNCjwgQ09O RklHX0JMS19ERVZfU0Q9eQ0KPCAjIENPTkZJR19DSFJfREVWX1NUIGlzIG5v dCBzZXQNCjwgIyBDT05GSUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0DQo8ICMg Q09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNldA0KPCANCjwgIw0KPCAjIFNv bWUgU0NTSSBkZXZpY2VzIChlLmcuIENEIGp1a2Vib3gpIHN1cHBvcnQgbXVs dGlwbGUgTFVOcw0KPCAjDQo8ICMgQ09ORklHX1NDU0lfTVVMVElfTFVOIGlz IG5vdCBzZXQNCjwgQ09ORklHX1NDU0lfQ09OU1RBTlRTPXkNCjwgQ09ORklH X1NDU0lfTE9HR0lORz15DQo8IA0KPCAjDQo8ICMgU0NTSSBsb3ctbGV2ZWwg ZHJpdmVycw0KPCAjDQo8ICMgQ09ORklHX1NDU0lfNzAwMEZBU1NUIGlzIG5v dCBzZXQNCjwgIyBDT05GSUdfU0NTSV9BSEExNTJYIGlzIG5vdCBzZXQNCjwg IyBDT05GSUdfU0NTSV9BSEExNTQyIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdf U0NTSV9BSEExNzQwIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfU0NTSV9BSUM3 WFhYIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfU0NTSV9BRFZBTlNZUyBpcyBu b3Qgc2V0DQo8ICMgQ09ORklHX1NDU0lfSU4yMDAwIGlzIG5vdCBzZXQNCjwg IyBDT05GSUdfU0NTSV9BTTUzQzk3NCBpcyBub3Qgc2V0DQo8ICMgQ09ORklH X1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJX0RU QzMyODAgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJX0VBVEFfRE1BIGlz IG5vdCBzZXQNCjwgIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0 DQo8ICMgQ09ORklHX1NDU0lfRUFUQSBpcyBub3Qgc2V0DQo8ICMgQ09ORklH X1NDU0lfRlVUVVJFX0RPTUFJTiBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX1ND U0lfR0RUSCBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX1NDU0lfR0VORVJJQ19O Q1I1MzgwIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfU0NTSV9OQ1I1M0M0MDZB IGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfU0NTSV9QQVMxNiBpcyBub3Qgc2V0 DQo8ICMgQ09ORklHX1NDU0lfUENJMjAwMCBpcyBub3Qgc2V0DQo8ICMgQ09O RklHX1NDU0lfUENJMjIyMEkgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJ X1BTSTI0MEkgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJX1FMT0dJQ19G QVMgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJX1NFQUdBVEUgaXMgbm90 IHNldA0KPCAjIENPTkZJR19TQ1NJX1QxMjggaXMgbm90IHNldA0KPCAjIENP TkZJR19TQ1NJX1UxNF8zNEYgaXMgbm90IHNldA0KPCAjIENPTkZJR19TQ1NJ X1VMVFJBU1RPUiBpcyBub3Qgc2V0DQotLS0NCj4gIyBDT05GSUdfU0NTSSBp cyBub3Qgc2V0DQoxNjlkMTIyDQo8ICMgQ09ORklHX0FSQ05FVCBpcyBub3Qg c2V0DQoxNzEsMTgzZDEyMw0KPCAjIENPTkZJR19FUVVBTElaRVIgaXMgbm90 IHNldA0KPCBDT05GSUdfTkVUX0VUSEVSTkVUPXkNCjwgIyBDT05GSUdfTkVU X1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfTEFOQ0UgaXMg bm90IHNldA0KPCAjIENPTkZJR19CQUdFVExBTkNFIGlzIG5vdCBzZXQNCjwg IyBDT05GSUdfTkVUX1ZFTkRPUl9TTUMgaXMgbm90IHNldA0KPCAjIENPTkZJ R19ORVRfVkVORE9SX1JBQ0FMIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfTkVU X0lTQSBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX05FVF9FSVNBIGlzIG5vdCBz ZXQNCjwgIyBDT05GSUdfTkVUX1BPQ0tFVCBpcyBub3Qgc2V0DQo8ICMgQ09O RklHX0ZEREkgaXMgbm90IHNldA0KPCAjIENPTkZJR19ETENJIGlzIG5vdCBz ZXQNCjwgIyBDT05GSUdfUFBQIGlzIG5vdCBzZXQNCjE4NSwyMTNjMTI1LDEy Ng0KPCAjIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldA0KPCAjIENPTkZJ R19UUiBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX1dBTl9EUklWRVJTIGlzIG5v dCBzZXQNCjwgIyBDT05GSUdfTEFQQkVUSEVSIGlzIG5vdCBzZXQNCjwgIyBD T05GSUdfWDI1X0FTWSBpcyBub3Qgc2V0DQo8IA0KPCAjDQo8ICMgQVguMjUg bmV0d29yayBkZXZpY2UgZHJpdmVycw0KPCAjDQo8ICMgQ09ORklHX01LSVNT IGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfNlBBQ0sgaXMgbm90IHNldA0KPCAj IENPTkZJR19CUFFFVEhFUiBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX0RNQVND QyBpcyBub3Qgc2V0DQo8ICMgQ09ORklHX1NDQyBpcyBub3Qgc2V0DQo8ICMg Q09ORklHX0JBWUNPTV9TRVJfRkRYIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdf QkFZQ09NX1NFUl9IRFggaXMgbm90IHNldA0KPCAjIENPTkZJR19CQVlDT01f UEFSIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfQkFZQ09NX0VQUCBpcyBub3Qg c2V0DQo8ICMgQ09ORklHX1NPVU5ETU9ERU0gaXMgbm90IHNldA0KPCANCjwg Iw0KPCAjIElTRE4gc3Vic3lzdGVtDQo8ICMNCjwgIyBDT05GSUdfSVNETiBp cyBub3Qgc2V0DQo8IA0KPCAjDQo8ICMgQ0QtUk9NIGRyaXZlcnMgKG5vdCBm b3IgU0NTSSBvciBJREUvQVRBUEkgZHJpdmVzKQ0KPCAjDQo8ICMgQ09ORklH X0NEX05PX0lERVNDU0kgaXMgbm90IHNldA0KLS0tDQo+ICMgQ09ORklHX1BQ UCBpcyBub3Qgc2V0DQo+IENPTkZJR19ERUNMQU5DRT15DQoyMTZjMTI5DQo8 ICMgQ2hhcmFjdGVyIGRldmljZXMNCi0tLQ0KPiAjIERFQ3N0YXRpb24gQ2hh cmFjdGVyIGRldmljZXMNCjIxOCwyMTljMTMxDQo8IENPTkZJR19WVD15DQo8 IENPTkZJR19WVF9DT05TT0xFPXkNCi0tLQ0KPiAjIENPTkZJR19WVCBpcyBu b3Qgc2V0DQoyMjBhMTMzLDEzNA0KPiAjIENPTkZJR19EWiBpcyBub3Qgc2V0 DQo+IENPTkZJR19aUz15DQoyMjIsMjIzYzEzNg0KPCAjIENPTkZJR19TRVJJ QUxfRVhURU5ERUQgaXMgbm90IHNldA0KPCAjIENPTkZJR19TRVJJQUxfTk9O U1RBTkRBUkQgaXMgbm90IHNldA0KLS0tDQo+IENPTkZJR19QUk9NX0NPTlNP TEU9eQ0KMjI0YTEzOA0KPiAjIENPTkZJR19LRVlCT0FSRCBpcyBub3Qgc2V0 DQoyMjYsMjI4ZDEzOQ0KPCAjIENPTkZJR19RSUMwMl9UQVBFIGlzIG5vdCBz ZXQNCjwgIyBDT05GSUdfQVBNIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfV0FU Q0hET0cgaXMgbm90IHNldA0KMjMwLDIzN2QxNDANCjwgIyBDT05GSUdfVklE RU9fREVWIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfTlZSQU0gaXMgbm90IHNl dA0KPCAjIENPTkZJR19KT1lTVElDSyBpcyBub3Qgc2V0DQo8IA0KPCAjDQo8 ICMgRnRhcGUsIHRoZSBmbG9wcHkgdGFwZSBkZXZpY2UgZHJpdmVyDQo8ICMN CjwgIyBDT05GSUdfRlRBUEUgaXMgbm90IHNldA0KMjQzYzE0Ng0KPCBDT05G SUdfTUlOSVhfRlM9eQ0KLS0tDQo+ICMgQ09ORklHX01JTklYX0ZTIGlzIG5v dCBzZXQNCjI2NCwyNjdjMTY3LDE3MA0KPCBDT05GSUdfVUZTX0ZTPXkNCjwg Q09ORklHX0JTRF9ESVNLTEFCRUw9eQ0KPCAjIENPTkZJR19TTURfRElTS0xB QkVMIGlzIG5vdCBzZXQNCjwgIyBDT05GSUdfU09MQVJJU19YODZfUEFSVElU SU9OIGlzIG5vdCBzZXQNCi0tLQ0KPiAjIENPTkZJR19VRlNfRlMgaXMgbm90 IHNldA0KPiAjIENPTkZJR19FRlNfRlMgaXMgbm90IHNldA0KPiAjIENPTkZJ R19BREZTX0ZTIGlzIG5vdCBzZXQNCj4gIyBDT05GSUdfUU5YNEZTX0ZTIGlz IG5vdCBzZXQNCjI3MiwyNzZkMTc0DQo8ICMgU291bmQNCjwgIw0KPCAjIENP TkZJR19TT1VORCBpcyBub3Qgc2V0DQo8IA0KPCAjDQoyODJkMTc5DQo8IA0K ---1463811839-1882929066-908890930=:726-- From matt@molnir.demon.co.uk Tue Oct 20 18:00:21 1998 Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA05861; Tue, 20 Oct 1998 18:00:19 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 18:00:19 +0200 (MET DST) Received: from [193.237.65.231] (helo=molnir.our.house) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zVeCV-0002Di-00 for linux-mips@fnet.fr; Tue, 20 Oct 1998 16:00:00 +0000 Received: from molnir.demon.co.uk (matt@cook.our.house [192.168.100.1]) by molnir.our.house (8.9.1/8.9.1) with ESMTP id QAA12490 for ; Tue, 20 Oct 1998 16:59:49 +0100 Received: (from matt@localhost) by molnir.demon.co.uk (8.9.1/8.9.1) id QAA08925 for linux-mips@fnet.fr; Tue, 20 Oct 1998 16:59:55 +0100 From: Matt Foster Message-Id: <199810201559.QAA08925@molnir.demon.co.uk> Subject: Console problems? To: linux-mips@fnet.fr Date: Tue, 20 Oct 1998 16:59:54 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 558 Lines: 21 Thanks to Richard for all your help so far.... The thing is now booting , (with initrd) well almost. The last couple of messages are : VFS : Mounted root (ext2 filesystem) Freeing unused kernel memory : 40k freed Stan And then it hangs. I guess this is the standalone shell kicking in? I'm running with a vt100 on the end of the serial port of the DS5000/25. Could this be the problem (expecting the graphics console?) console is set to 1 and osconsole to 3, although it doesn't seem to matter much what I set osconsole to. Any ideas? Cheers, Matt From R.vandenBerg@inter.NL.net Tue Oct 20 19:00:18 1998 Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA07084; Tue, 20 Oct 1998 19:00:17 +0200 (MET DST) Received-Date: Tue, 20 Oct 1998 19:00:17 +0200 (MET DST) Received: from dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-35.Hoorn.NL.net [193.79.46.199] with ESMTP for id TAA20737 (8.8.8/3.28); Tue, 20 Oct 1998 19:00:14 +0200 (MET DST) Received: from whale.dutch.mountain(really [192.168.1.1]) by dutch.mountain via in.smtpd with smtp id for ; Tue, 20 Oct 1998 18:59:49 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Tue, 20 Oct 1998 18:59:48 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: Re: Console problems? In-Reply-To: <199810201559.QAA08925@molnir.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1285 Lines: 38 On Tue, 20 Oct 1998, Matt Foster wrote: > Thanks to Richard for all your help so far.... > > The thing is now booting , (with initrd) well almost. > The last couple of messages are : > > > VFS : Mounted root (ext2 filesystem) > Freeing unused kernel memory : 40k freed > Stan Congratulations! Right now only the 5000/1xx runs single user. > And then it hangs. I guess this is the standalone shell kicking in? > I'm running with a vt100 on the end of the serial port of the DS5000/25. > Could this be the problem (expecting the graphics console?) > console is set to 1 and osconsole to 3, although it doesn't seem to matter > much what I set osconsole to. The osconsole enviroment variable is set by the system, the console enviroment variable determines what is used as a console, generally: s for a connected terminal, * let the system determine; if a keyboard is connected then it will be used together with the framebuffer in the lowest numbered TURBOchannel slot, with no keyboard connected the serial port is used. All these goodies and more are explained in the maintenance manual available at decstation.unix-ag.org, thanks to Michael. > Any ideas? Improve the serial driver or write a framebuffer + keyboard + mouse driver. Welcome to the club. Regards, Richard From ralf@lappi.waldorf-gmbh.de Wed Oct 21 00:38:16 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA14317; Wed, 21 Oct 1998 00:38:15 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 00:38:15 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-24.uni-koblenz.de [141.26.249.24]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA20770 for ; Wed, 21 Oct 1998 00:38:10 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id TAA01121; Tue, 20 Oct 1998 19:31:16 +0200 Message-ID: <19981020193116.C478@uni-koblenz.de> Date: Tue, 20 Oct 1998 19:31:16 +0200 From: ralf@uni-koblenz.de To: Warner Losh Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: get_mmu_context() References: <19981019121804.F387@uni-koblenz.de> <19981019121804.F387@uni-koblenz.de> <199810200407.WAA03233@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810200407.WAA03233@harmony.village.org>; from Warner Losh on Mon, Oct 19, 1998 at 10:07:26PM -0600 Content-Length: 1973 Lines: 46 On Mon, Oct 19, 1998 at 10:07:26PM -0600, Warner Losh wrote: > Wouldn't it be easier to have ld to have variant fixup records? That > way you could patch all instances at run time, much like we do when we > load stuff now... > > You are basically duplicating the functionality of the linker here for > no good reason. Actually, besides the non-standard aspect of it, > there is a good reason: it is easier to hack like this than to do > battle with the bfd and/or boot blocks to get this to happen. :-) > > It is a way cool hack, don't get me wrong, but it just seems that it > would be more useful to be generic like that. Neither compiler, assembler nor linker can solve the problem for us because it requires knowledge of facts which we usually don't know before running on the target machine. On the other side as soon as we run on the machine we know these details. They're constants, so why not making optimal use of them? As alternative to achieve the same level of efficience imagine the following configuration dialogue: # # Cache configuration # Does your machine have a second level cache (CONFIG_L2_CACHE) [N/y] y Is your CPU an Indy R4600SC or R5000SC (CONFIG_L2_INDY) [N/y] l2 linesize (16, 32, 64, 128) [128] Split Scache (CONFIG_L2_SPLIT) [N/y] Do your VCE exceptions work (CONFIG_R4000SC_V2) [N/y] Primary instruction cache linesize (16, 32) [16] Primary data cache linesize (16, 32) [16] Oh, there is more fun we'd need to ask for like DRAM controller versions for Magnums etc. Cool vomit bag, isn't it ;-) Things look different for fixed configuration systems like for example the Cobalt Qube. But we have to deal with zillion of system variants. You're right in that things should become more generic and I have ideas to make them more generic. For the moment being I don't want to continue on that since 2.2 is coming soon and more important things are still to do. That's should however be an interesting 2.3 project. Ralf From imp@village.org Wed Oct 21 01:37:18 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id BAA15704; Wed, 21 Oct 1998 01:37:05 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 01:37:05 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zVlKN-0000kW-00; Tue, 20 Oct 1998 17:36:35 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id RAA29729; Tue, 20 Oct 1998 17:36:54 -0600 (MDT) Message-Id: <199810202336.RAA29729@harmony.village.org> To: ralf@uni-koblenz.de Subject: Re: get_mmu_context() Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com In-reply-to: Your message of "Tue, 20 Oct 1998 19:31:16 +0200." <19981020193116.C478@uni-koblenz.de> References: <19981020193116.C478@uni-koblenz.de> <19981019121804.F387@uni-koblenz.de> <19981019121804.F387@uni-koblenz.de> <199810200407.WAA03233@harmony.village.org> Date: Tue, 20 Oct 1998 17:36:53 -0600 From: Warner Losh Content-Length: 942 Lines: 23 In message <19981020193116.C478@uni-koblenz.de> ralf@uni-koblenz.de writes: : running on the target machine. On the other side as soon as we run on : the machine we know these details. They're constants, so why not making : optimal use of them? I'm confused then... : You're right in that things should become more generic and I have ideas : to make them more generic. For the moment being I don't want to continue : on that since 2.2 is coming soon and more important things are still to do. : That's should however be an interesting 2.3 project. Yes. Basically something has load the kernel, and that something could do the fixups. Basically it would be a relocation record with a "tag" on it that said what systems to do it on. However, I do see your point that when you want to have the varients based on cache size, memory controller, cache line size, etc it gets really ugly.... It would be a cool project, however... Warner From ralf@lappi.waldorf-gmbh.de Wed Oct 21 03:31:10 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA17927; Wed, 21 Oct 1998 03:31:09 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 03:31:09 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-09.uni-koblenz.de [141.26.249.9]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id DAA27158 for ; Wed, 21 Oct 1998 03:31:06 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id BAA02181; Wed, 21 Oct 1998 01:50:47 +0200 Message-ID: <19981021015047.G1830@uni-koblenz.de> Date: Wed, 21 Oct 1998 01:50:47 +0200 From: ralf@uni-koblenz.de To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Haifa scheduler bug in egcs 1.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Content-Length: 1953 Lines: 49 Hi all, I've resolved a bug report of Ulf Carlson whose kernel compiles resulted died with: gcc -D__KERNEL__ -I/home/ulfc/kernels/sgi-lin/linux/include -Wall \ -Wstrict-prototypes -O2 -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic \ -mcpu=r4600 -mips2 -pipe arch/mips/mm/r6000.c -o arch/mips/mm/r6000 {standard input}: Assembler messages: {standard input}:385: Warning: Unmatched %hi reloc {standard input}:488: Internal error! Assertion failure in tc_gen_reloc at ./config/tc-mips.c line 10203. Please report this bug. make: *** [arch/mips/mm/r6000] Error 1 This is caused by bad assembler code like: [...] lui $11,%hi(r6000_flush_cache_mm) # high lui $12,%hi(r6000_flush_cache_range) # high lui $17,%hi(r6000_flush_tlb_all) # high lui $2,%hi(r6000_flush_tlb_mm) # high lui $3,%hi(r6000_flush_tlb_range) # high lui $4,%hi(r6000_flush_tlb_page) # high lui $5,%hi(r6000_load_pgd) # high lui $6,%hi(r6000_pgd_init) # high lui $7,%hi(r6000_update_mmu_cache) # high lui $8,%hi(r6000_show_regs) # high lui $9,%hi(r6000_add_wired_entry) # high lui $10,%hi(r6000_user_mode) # high [...] Relocating the code generated from this source later on will not be possible for ld. As knows this and dies ungracefully. I was able to track this down to the Haifa scheduler which seems to be incompatible with the -msplit-addresses used for kernel compiles. For now I suggest to recompile egcs without the Haifa scheduler. Egcs by default doesn't enable the Haifa scheduler and there is a reason why. This egcs 1.0.2 bug is a platform independent bug. Since currently egcs does not support -msplit-addresses for PIC code, that is all userland this bug will only hit some low level stuff. Alex or somebody else, could you make an update to the egcs package with the haifa scheduler disabled? Thanks! Ralf From davem@dm.cobaltmicro.com Wed Oct 21 03:40:32 1998 Received: from dm.cobaltmicro.com (davem@dm.cobaltmicro.com [209.133.34.35]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA18009; Wed, 21 Oct 1998 03:40:30 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 03:40:30 +0200 (MET DST) Received: (from davem@localhost) by dm.cobaltmicro.com (8.8.7/8.8.7) id SAA22458; Tue, 20 Oct 1998 18:39:21 -0700 Date: Tue, 20 Oct 1998 18:39:21 -0700 Message-Id: <199810210139.SAA22458@dm.cobaltmicro.com> From: "David S. Miller" To: ralf@uni-koblenz.de CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu In-reply-to: <19981021015047.G1830@uni-koblenz.de> (ralf@uni-koblenz.de) Subject: Re: Haifa scheduler bug in egcs 1.0.2 References: <19981021015047.G1830@uni-koblenz.de> Content-Length: 437 Lines: 14 Date: Wed, 21 Oct 1998 01:50:47 +0200 From: ralf@uni-koblenz.de Relocating the code generated from this source later on will not be possible for ld. As knows this and dies ungracefully. Then why is this a supposed bug in Haifa? It looks to me there is a problem with how %hi relocs are assosciated with %lo ones in binutils. The code you showed me looks perfectly legal. Later, David S. Miller davem@dm.cobaltmicro.com From ulfc@bun.falkenberg.se Wed Oct 21 07:59:57 1998 Received: from calypso.saturn (root@dialup248-1-43.swipnet.se [130.244.248.43]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id HAA22553; Wed, 21 Oct 1998 07:59:55 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 07:59:55 +0200 (MET DST) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Wed, 21 Oct 1998 08:01:21 +0200 (CEST) Message-ID: <19981021080121.B14340@zigzegv.ml.org> Date: Wed, 21 Oct 1998 08:01:21 +0200 From: Ulf Carlsson To: linux-mips@fnet.fr, linux@engr.sgi.com, linux-mips@vger.rutgers.edu Subject: Re: Haifa scheduler bug in egcs 1.0.2 References: <19981021015047.G1830@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <19981021015047.G1830@uni-koblenz.de>; from ralf@uni-koblenz.de on Wed, Oct 21, 1998 at 01:50:47AM +0200 Content-Length: 480 Lines: 13 > This egcs 1.0.2 bug is a platform independent bug. Since currently > egcs does not support -msplit-addresses for PIC code, that is all userland > this bug will only hit some low level stuff. > > Alex or somebody else, could you make an update to the egcs package > with the haifa scheduler disabled? Thanks! I've actually been messing with egcs (crosscompiler) during the last few days, and I already have the sources installed. I'll build that later today. Thanks, Ulf From ulfc@bun.falkenberg.se Wed Oct 21 13:45:20 1998 Received: from calypso.saturn (root@dialup248-4-55.swipnet.se [130.244.248.247]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA26363; Wed, 21 Oct 1998 13:44:16 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 13:44:16 +0200 (MET DST) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Wed, 21 Oct 1998 13:45:44 +0200 (CEST) Message-ID: <19981021134544.A30452@zigzegv.ml.org> Date: Wed, 21 Oct 1998 13:45:44 +0200 From: Ulf Carlsson To: ralf@uni-koblenz.de Cc: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <19981020103052.G676@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <19981020103052.G676@uni-koblenz.de>; from ralf@uni-koblenz.de on Tue, Oct 20, 1998 at 10:30:52AM +0200 Content-Length: 5325 Lines: 126 Hi Ralf, I have performed a little test: First of all I check free memory: ulfc@dione:~$ free total used free shared buffers cached Mem: 28488 19056 9432 8708 4 14108 -/+ buffers/cache: 4944 23544 Swap: 0 0 0 Then I start my test program: ulfc@dione:~$ ./test failed to allocate 512 bytes (6307840 bytes already allocated) spinning ... And while my test program is spinning I press shift-scroll lock: Mem-info: Free pages: 3184kB ( Free: 796 (256 512 768) 0*4kB 0*8kB 1*16kB 13*32kB 9*64kB 17*128kB = 3184kB) Swap cache: add 0/0, delete 0/0, find 0/0 Free swap: 0kB 40959 pages of RAM 33837 reserved pages 2175 pages shared 0 pages swap cached 14 pages in page table cache 901 free pages Buffer memory: 4kB Buffer heads: 20 Buffer blocks: 4 Networking buffers in use : 0 Total network buffer allocations : 2683812 Total failed network buffer allocs : 0 IP fragment buffer size : 0 And even ctrl-scroll lock: free sibling task PC stack pid father child younger older init 1 S 8804CFAC 4384 1 0 5811 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X kflushd 2 S 00000020 6976 2 1 3 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X kswapd 3 S 8803B4E0 6064 3 1 4 2 sig: 0 00000000000000000000000000000000 ffffffffffffffffffffffffffffffff : X rpciod 4 S 880B1690 3104 4 1 171 3 sig: 0 00000000000000000000000000000000 fffffffffffffffffffffffffffffeff : X syslogd 9 S 8804CFAC 2656 171 1 180 4 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X klogd 10 R 00000000 0 180 1 191 171 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X atd 8 S 00000000 1744 191 1 202 180 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X crond 12 S 897F4E40 0 202 1 213 191 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X portmap 13 S 8804CFAC 1888 213 1 224 202 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X inetd 14 S 8804CFAC 8 224 1 235 213 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X sshd 15 S 8804CFAC 0 235 1 246 224 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X rpc.mountd 16 S 8804CFAC 0 246 1 255 235 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X rpc.nfsd 17 S 8804CFAC 0 255 1 269 246 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X sendmail 18 S 8804CFAC 0 269 1 281 255 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X gpm 19 S 8804CFAC 0 281 1 294 269 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X login 6 S 89BBC000 8 294 1 299 296 281 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X update 7 S 7FFFFEA4 0 296 1 5793 294 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X bash 20 S 880D76C8 0 299 294 sig: 0 00000000000000000000000000000002 89e7100089cfffae0000000189b97862 : X login 5 S 89E9C000 0 5793 1 5794 5811 296 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X bash 26 S 88F4E000 0 5794 5793 5856 sig: 0 00000000000000000000000000000000 00000000000000000000000000020000 : X login 11 S 89B8C000 32 5811 1 5812 5793 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X bash 32 S 893D2000 0 5812 5811 5858 sig: 0 00000000000000000000000000000000 88eba0000000540e0000000100020000 : X test -29 R current 832 5856 5794 sig: 0 00000000000000000000000000000000 00000000000000000000000000000000 : X cat 21 S 89A4B2D8 0 5858 5812 sig: 0 00000000000000000000000000000000 88eba0000000540e0000000100000000 : X That last doesn't make much sense, but it's included anyway.. My little test program (which is a bif fan of the digit 3, its goal is to fill the whole memory with them) look like this: #include #include #include #define BLOCK 512 int main(void) { int i; void *p; for (i = 0;;i++) { if (!(p = malloc(BLOCK))) { printf("failed to allocate %d bytes (%d bytes already allocated)\n", BLOCK, BLOCK * i); printf("spinning ... \n"); for (;;) ; } memset(p, 3, BLOCK); /* do it .. */ } return 0; } Doesn't look like an interpreter error to me.. - Ulf From imp@village.org Wed Oct 21 21:13:12 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id VAA00846; Wed, 21 Oct 1998 21:13:10 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 21:13:10 +0200 (MET DST) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zW3gp-0001J3-00; Wed, 21 Oct 1998 13:12:59 -0600 Received: (from imp@localhost) by harmony.village.org (8.9.1/8.8.3) id NAA17146 for linux-mips@fnet.fr; Wed, 21 Oct 1998 13:13:27 -0600 (MDT) Date: Wed, 21 Oct 1998 13:13:27 -0600 (MDT) From: Warner Losh Message-Id: <199810211913.NAA17146@harmony.village.org> To: linux-mips@fnet.fr Subject: Linux/MIPS on TV Content-Length: 197 Lines: 5 OK, They didn't say Linux/MIPS by name, but I saw a piece on New Media News on Cobolt Micro and their cute little blue boxes. I wonder if Dave was in the shots of the engineers or not :-) Warner From harald.koerfgen@netcologne.de Wed Oct 21 21:30:16 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA01069; Wed, 21 Oct 1998 21:30:14 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 21:30:14 +0200 (MET DST) Received: from franz.no.dom (dial1-22.netcologne.de [194.8.196.22]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA09382; Wed, 21 Oct 1998 21:30:05 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981019121804.F387@uni-koblenz.de> Date: Wed, 21 Oct 1998 21:31:40 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: get_mmu_context() Cc: Vladimir Roganov , linux@cthulhu.engr.sgi.com Content-Length: 2580 Lines: 62 On 19-Oct-98 ralf@uni-koblenz.de wrote: > On Sun, Oct 18, 1998 at 09:53:18PM +0200, Harald Koerfgen wrote: [...] > There is a number of machines, most popular some DECstation, which are > available with both CPU architectures. Yup. > The other location for which patching might be useful are primarily the > differences between the R3000 and R4000 status register, especially the > KU rsp. KSU bits. What other places do you have in mind? Agreed. There are indeed other places where code could be reintegrated, r2300_switch.S and r4k_switch.S come to mind. On the other hand, there is code which should be seperated for performance reasons, mainly the RESTORE_ALL macros thus affecting entry.S and scall_o32.S. Actually these problems are solved by conditional compiling. >> To make those changes generic needs either a reasonable amount of hacking or >> avoidable code duplication. In fact, if we really don't care about self >> modifying code we should be able to remove some code duplication, for >> example in the fpu stuff. > > People should consider that we'll be able to hide the self modifications > in C code very nicely. I would not go for anything which I consider a > maintenance problem or major uglyness. Good. > Let me explain how the approach from my recent patch works: [explanation snipped] > Todo: we don't want a separate section per patched instruction. Easy to > fix. We also want to get rid of the special section just like other > initfunc stuff. That sounds great. We could even put all ISA dependant code into seperate sections and get rid of all the ISA sections, which aren't needed. > The next class of things to patch are the zillion of function calls using > function pointers. We can insert a jal instruction and patch it's > destination address. Candidates for that include calls to flush_cache_all, > flush_cache_mm, flush_cache_range, flush_cache_page, flush_cache_sigtramp, > flush_tlb_all, flush_tlb_mm, flush_tlb_range, flush_tlb_page, add_wired_entry, > clear_page, copy_page. > > Both parts, patching immediate opperands and function calls can be dealt > with similar to the approach in the userland dynamic linker, that initially > the function called is the dynamic linker's kernel equivalent which will > choose the right thing to do. > > Extra goodie for the R3000 fraction: Many functions called via above > mentioned pointers are empty, calls to them may be eleminated by overwriting > the calling jal with nops. Say goodbye to another hand full of cycles. That sounds even better :-). --- Regards, Harald From harald.koerfgen@netcologne.de Wed Oct 21 21:30:22 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA01074; Wed, 21 Oct 1998 21:30:17 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 21:30:17 +0200 (MET DST) Received: from franz.no.dom (dial1-22.netcologne.de [194.8.196.22]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA09386 for ; Wed, 21 Oct 1998 21:30:10 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981019034447.H1880@uni-koblenz.de> Date: Wed, 21 Oct 1998 21:31:45 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: R3000 and wbflush (was: DZ-11 interrupts) Content-Length: 321 Lines: 14 Hi, On 19-Oct-98 ralf@uni-koblenz.de wrote: [wbflush ...] > Harald, will this problem make any changes to code used also for the > R4000 necessary? The current implementation is R4000 clean. Although, like in other places, I've used conditional compiling. Just another case for MIPS-btfixup[tm]. --- Regards, Harald From harald.koerfgen@netcologne.de Wed Oct 21 21:30:25 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA01092; Wed, 21 Oct 1998 21:30:22 +0200 (MET DST) Received-Date: Wed, 21 Oct 1998 21:30:22 +0200 (MET DST) Received: from franz.no.dom (dial1-22.netcologne.de [194.8.196.22]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id VAA09394 for ; Wed, 21 Oct 1998 21:30:18 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.2.p0.Linux:981021203014:757=_" In-Reply-To: <199810201559.QAA08925@molnir.demon.co.uk> Date: Wed, 21 Oct 1998 21:31:53 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: Console problems? Content-Length: 2185 Lines: 79 This message is in MIME format --_=XFMail.1.2.p0.Linux:981021203014:757=_ Content-Type: text/plain; charset=us-ascii Hi Matt, On 20-Oct-98 Matt Foster wrote: > Thanks to Richard for all your help so far.... > > The thing is now booting , (with initrd) well almost. > The last couple of messages are : > > > VFS : Mounted root (ext2 filesystem) > Freeing unused kernel memory : 40k freed > Stan > > And then it hangs. I guess this is the standalone shell kicking in? That's absolutely correct. Unfortunately your machine won't get any further. This particular bug has been identified and fixed, but there remain to be bugs in drivers/tc/zs.h. At least my DS5000/240 shows "Stand-alo" and then hangs. Please apply the attached patch to zs.c. The bug appeared to be a save_flags(flags); cli(); ... request_irq(...); ... restore_flags(flags); construction. > Any ideas? Well, to be honest, not at the moment :-). Happy hacking. --- Regards, Harald --_=XFMail.1.2.p0.Linux:981021203014:757=_ Content-Disposition: attachment; filename="zs-patch" Content-Transfer-Encoding: 7bit Content-Description: zs-patch Content-Type: text/plain; charset=us-ascii; name=zs-patch; SizeOnDisk=886 --- zs.c~ Mon Oct 19 18:44:51 1998 +++ zs.c Mon Oct 19 20:26:11 1998 @@ -1729,6 +1729,13 @@ if (tty_register_driver(&callout_driver)) panic("Couldn't register callout driver\n"); + for (channel = 0; channel < zs_channels_found; ++channel) { + if (request_irq(SERIAL, rs_interrupt, SA_SHIRQ, + "SCC", &zs_soft[channel])) + printk(KERN_ERR "decserial: can't get irq %d\n", + SERIAL); + } + save_flags(flags); cli(); for (channel = 0; channel < zs_channels_found; ++channel) { @@ -1739,11 +1746,6 @@ #endif zs_soft[channel].clk_divisor = 16; zs_soft[channel].zs_baud = get_zsbaud(&zs_soft[channel]); - - if (request_irq(SERIAL, rs_interrupt, SA_SHIRQ, - "SCC", &zs_soft[channel])) - printk(KERN_ERR "decserial: can't get irq %d\n", - SERIAL); /* If console serial line, then enable interrupts. */ /* if (zs_soft[channel].is_cons) { --_=XFMail.1.2.p0.Linux:981021203014:757=_-- End of MIME message From tsbogend@alpha.franken.de Thu Oct 22 00:04:10 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA02024; Thu, 22 Oct 1998 00:04:10 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 00:04:10 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA05328; Thu, 22 Oct 1998 00:04:03 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id XAA03217; Wed, 21 Oct 1998 23:38:15 +0200 Message-ID: <19981021233814.A3030@alpha.franken.de> Date: Wed, 21 Oct 1998 23:38:14 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981020103052.G676@uni-koblenz.de> <19981021134544.A30452@zigzegv.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981021134544.A30452@zigzegv.ml.org>; from Ulf Carlsson on Wed, Oct 21, 1998 at 01:45:44PM +0200 Content-Length: 649 Lines: 16 On Wed, Oct 21, 1998 at 01:45:44PM +0200, Ulf Carlsson wrote: > ulfc@dione:~$ ./test > failed to allocate 512 bytes (6307840 bytes already allocated) > spinning ... that's pretty normal for a 2.1 kernel, when running without swap. I've tried it on a 64MB P5 system and test was able to get about 7MB memory. With swap enabled I had to stop test to avoid running out of swap space (which wasn't desired at that time:-)). Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From ralf@lappi.waldorf-gmbh.de Thu Oct 22 02:45:19 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA06473; Thu, 22 Oct 1998 02:45:18 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 02:45:18 +0200 (MET DST) Received: from lappi.waldorf-gmbh.de (pmport-23.uni-koblenz.de [141.26.249.23]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA15079 for ; Thu, 22 Oct 1998 02:45:14 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id CAA00469; Thu, 22 Oct 1998 02:44:08 +0200 Message-ID: <19981022024408.A360@uni-koblenz.de> Date: Thu, 22 Oct 1998 02:44:08 +0200 From: ralf@uni-koblenz.de To: "David S. Miller" Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Haifa scheduler bug in egcs 1.0.2 References: <19981021015047.G1830@uni-koblenz.de> <199810210139.SAA22458@dm.cobaltmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810210139.SAA22458@dm.cobaltmicro.com>; from David S. Miller on Tue, Oct 20, 1998 at 06:39:21PM -0700 X-Mutt-References: <199810210139.SAA22458@dm.cobaltmicro.com> Content-Length: 1603 Lines: 33 On Tue, Oct 20, 1998 at 06:39:21PM -0700, David S. Miller wrote: > Relocating the code generated from this source later on will not be > possible for ld. As knows this and dies ungracefully. > > Then why is this a supposed bug in Haifa? It looks to me there is a > problem with how %hi relocs are assosciated with %lo ones in binutils. It's not necessarily a bug in Haida itself but it gets visible when Haifa is enabled. I haven't looked closely at the involved egcs code yet. > The code you showed me looks perfectly legal. For ECOFF and ELF, relocations against symbols are done in two parts, with a hi16 relocation and a lo16 relocation. Each relocation has only 16 bits of space to store an addend and a carry may have to be propagated between the two. This means that in order for the linker to handle carries correctly, it must be able to locate both the hi16 and the lo16 relocation. Object files which don't contain any other information except the order in the relocation table which could be used to find the hi16 / lo16 relocs which belong together. The code I showed cannot be represented in a ELF or ECOFF object such that the linker still knows which hi16 and which lo16 relocations are associated with each other. Therefore it is not possible for the linker to correctly do the hi16 relocations. Btw, all MIPS assemblers I know of will warn or even error about that fragment. The ABI is quite strict in that aspect, it wants one lo16 per hi16 for the same symbol. Binutils relax that by allowing an arbitrary number of hi16 and one lo16 for the same symbol. Ralf From davem@dm.cobaltmicro.com Thu Oct 22 06:28:00 1998 Received: from dm.cobaltmicro.com (davem@dm.cobaltmicro.com [209.133.34.35]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA10235; Thu, 22 Oct 1998 06:27:59 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 06:27:59 +0200 (MET DST) Received: (from davem@localhost) by dm.cobaltmicro.com (8.8.7/8.8.7) id VAA03414; Wed, 21 Oct 1998 21:26:50 -0700 Date: Wed, 21 Oct 1998 21:26:50 -0700 Message-Id: <199810220426.VAA03414@dm.cobaltmicro.com> From: "David S. Miller" To: ralf@uni-koblenz.de CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu In-reply-to: <19981022024408.A360@uni-koblenz.de> (ralf@uni-koblenz.de) Subject: Re: Haifa scheduler bug in egcs 1.0.2 References: <19981021015047.G1830@uni-koblenz.de> <199810210139.SAA22458@dm.cobaltmicro.com> <19981022024408.A360@uni-koblenz.de> Content-Length: 581 Lines: 18 Date: Thu, 22 Oct 1998 02:44:08 +0200 From: ralf@uni-koblenz.de The ABI is quite strict in that aspect, it wants one lo16 per hi16 for the same symbol. Binutils relax that by allowing an arbitrary number of hi16 and one lo16 for the same symbol. I completely understand how hi16/lo16 relocations work on MIPS, but thanks for reiterating it to me once more. All you have shown me is a bug in the MIPS ABI, one of thousands. Therefore, there is no reason binutils cannot handle this sanely, and be fixed to do so. Later, David S. Miller davem@dm.cobaltmicro.com From ulfc@bun.falkenberg.se Thu Oct 22 09:04:06 1998 Received: from ruvild.bun.falkenberg.se (root@[194.236.80.7]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA11310; Thu, 22 Oct 1998 09:04:04 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 09:04:04 +0200 (MET DST) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Thu, 22 Oct 1998 09:09:33 +0200 (CEST) Message-ID: <19981022090933.A879@bun.falkenberg.se> Date: Thu, 22 Oct 1998 09:09:33 +0200 From: Ulf Carlsson To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981020103052.G676@uni-koblenz.de> <19981021134544.A30452@zigzegv.ml.org> <19981021233814.A3030@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <19981021233814.A3030@alpha.franken.de>; from Thomas Bogendoerfer on Wed, Oct 21, 1998 at 11:38:14PM +0200 Content-Length: 532 Lines: 14 > > ulfc@dione:~$ ./test > > failed to allocate 512 bytes (6307840 bytes already allocated) > > spinning ... > > that's pretty normal for a 2.1 kernel, when running without swap. > I've tried it on a 64MB P5 system and test was able to get about 7MB > memory. With swap enabled I had to stop test to avoid running out of > swap space (which wasn't desired at that time:-)). Anyhow, it isn't normal to have every program complaining about OOM at 14 out of 32 megabytes allocated, no matter if you have swap enabled or not. - Ulf From alhaz@xmission.com Thu Oct 22 19:22:20 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA15752; Thu, 22 Oct 1998 19:22:13 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 19:22:13 +0200 (MET DST) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zWOR5-0005dR-00 for linux-mips@fnet.fr; Thu, 22 Oct 1998 11:22:07 -0600 Sender: alhaz@fnet.fr Message-ID: <362F69B5.AB94E713@xmission.com> Date: Thu, 22 Oct 1998 11:21:57 -0600 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981020103052.G676@uni-koblenz.de> <19981021134544.A30452@zigzegv.ml.org> <19981021233814.A3030@alpha.franken.de> <19981022090933.A879@bun.falkenberg.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4283 Lines: 83 Ulf Carlsson wrote: > > > > ulfc@dione:~$ ./test > > > failed to allocate 512 bytes (6307840 bytes already allocated) > > > spinning ... > > > > that's pretty normal for a 2.1 kernel, when running without swap. > > I've tried it on a 64MB P5 system and test was able to get about 7MB > > memory. With swap enabled I had to stop test to avoid running out of > > swap space (which wasn't desired at that time:-)). > > Anyhow, it isn't normal to have every program complaining about OOM at > 14 out of 32 megabytes allocated, no matter if you have swap enabled > or not. Yes and no. Personally I find the concept of running a modern system without available swap somewhat perilous. I don't think there's much reason for kernel developers to make sure they keep in mind that the lunatic fringe is going to try it when they write the mmu code. True, you shouldn't be getting error messages when you have 18 megs free. Logic doesn't dictate that at all. But on the other hand, think about your reasoning for running without swap. The argument I usually hear is "I have 128 megs of ram and I don't want anything hitting the swapper". I'm an OS/2 user (yes, we still exist, much that IBM treats us like vermin) and I hear this from a lot of novice OS/2 users. Under OS/2, it's an extremely bad idea to run without swap space available because of the archetecture of the dynamic loader. The folks who designed the memory manager in os/2 were mainframe geeks, who used the logic that harddrive is cheaper than memory, and that it's faster to load library functions from swap than it is to execute them from the filesystem. Therefore, one of the big reasons for OS/2 loading so slowly is that on bootup, it loads as many DLL's as it can. It just keeps going and going, wether you need them or not. And for the first hour or two of usage, OS/2 is fairly sluggish as it swaps DLL's to disk to free up memory for applications. This has the effect of annoying the average Windows user who expects a big chunk of memory available immediately after bootup, and expects to reboot within 6 hours of usage. But OS/2 was designed to run unattended for weeks or months at a time (80+ % of the ATM machines in north america are running OS/2 on modified PS/2 hardware) and after a few hours of normal usage, OS/2 is a lean, mean, dynamic-loading machine. You keep the functions you actually use in active memory, and the ones you don't use so often are waiting in the swapper. To give you some raw numbers, for about a year I was running with 48 megs of ram. On bootup, I would have 512k of ram free. After 3 hours use, if I then closed all my applications, I would have 28 megs free. And about 34 megs in use in the swapper. But it gets yet more interesting. The archetects of OS/2 foresaw that there would be libraries almost nobody uses. So there is an entire class of library that loads directly into swap, never touching active memory unless you try to use them. These days, most people end up needing them once or twice a day. If you're running without swap, no matter how many megs of ram you have, when it comes time to use one of those functions, OS/2 will lock up. Unfortunate but true. OS/2 is an extreme example of an agressive memory managment scheme. Linux isn't anywhere near that involved. But the fact remains, you are going to be loading code into memory that you are not going to use. Where do you want that code to reside? Do you want it taking up $1/meg RAM or do you want it taking up the slightly slower but far more affordable disk space? You can set up a swap partition that's atleast 128 megs - how much does that 128 megs cost you? Clearly, any memory managment scheme is going to be based on checks and balances and have to be designed to make sure that things get used efficently. Running without swap isn't efficent, and it's not logical to design a managment structure that doesn't include it, so any memory managment scheme is going to end up eventually making some assumptions about it's presence. The moral of the story is: You shouldn't be running without swap. Complaining that something doesn't work when you do something you shouldn't, isn't likely to illicit a response other than "stop doing that thing you shouldn't be doing" - Eric From tsbogend@alpha.franken.de Thu Oct 22 22:26:12 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA17415; Thu, 22 Oct 1998 22:26:11 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 22:26:11 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id WAA14048; Thu, 22 Oct 1998 22:26:08 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id WAA02560; Thu, 22 Oct 1998 22:20:10 +0200 Message-ID: <19981022222010.A2556@alpha.franken.de> Date: Thu, 22 Oct 1998 22:20:10 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981021233814.A3030@alpha.franken.de> <19981022090933.A879@bun.falkenberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981022090933.A879@bun.falkenberg.se>; from Ulf Carlsson on Thu, Oct 22, 1998 at 09:09:33AM +0200 Content-Length: 597 Lines: 15 On Thu, Oct 22, 1998 at 09:09:33AM +0200, Ulf Carlsson wrote: > Anyhow, it isn't normal to have every program complaining about OOM at > 14 out of 32 megabytes allocated, no matter if you have swap enabled > or not. maybe, but what I tried to tell you is that you are barking at the wrong corner. This is not a Linux/MIPS problem (if any), but a generic Linux problem. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From ulfc@bun.falkenberg.se Thu Oct 22 23:05:24 1998 Received: from calypso.saturn (root@dialup38-3-52.swipnet.se [130.244.38.180]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA17641; Thu, 22 Oct 1998 23:05:23 +0200 (MET DST) Received-Date: Thu, 22 Oct 1998 23:05:23 +0200 (MET DST) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Thu, 22 Oct 1998 23:06:54 +0200 (CEST) Message-ID: <19981022230654.B32660@zigzegv.ml.org> Date: Thu, 22 Oct 1998 23:06:54 +0200 From: Ulf Carlsson To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981021233814.A3030@alpha.franken.de> <19981022090933.A879@bun.falkenberg.se> <19981022222010.A2556@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <19981022222010.A2556@alpha.franken.de>; from Thomas Bogendoerfer on Thu, Oct 22, 1998 at 10:20:10PM +0200 Content-Length: 1248 Lines: 30 > > Anyhow, it isn't normal to have every program complaining about OOM at > > 14 out of 32 megabytes allocated, no matter if you have swap enabled > > or not. > > maybe, but what I tried to tell you is that you are barking at the wrong > corner. This is not a Linux/MIPS problem (if any), but a generic Linux > problem. This is _certainly_ a linux/MIPS problem, and _not_ a generic Linux problem. Maybe I should have explained myself better. I would be able to run a ls in another console if I had 18 Mb free RAM. shift-scroll lock shows me that I have enough free pages. When I have around 14 Mb RAM used (summary of all programs, in free) I can't allocate any more in any application. So, if this was a 2.1 generic Linux problem I wouldn't be able to use more than 14 Mb RAM on a PC having 32 Mb either, no matter if I split the that memory into several applications. (note: this is not any limit problem, I'm running unlimited - and as root) My Indy acts like it had just 14 Mb of RAM. I can't compile the kernel, I can't compile egcs, I can't do anything which requires lots of memory.. Yes, I think you are barking at the wrong corner, I haven't seen anything like this on a 32 Mb intel machine. Swap isn't working yet, right? - Ulf From tsbogend@alpha.franken.de Fri Oct 23 00:54:10 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA20591; Fri, 23 Oct 1998 00:54:09 +0200 (MET DST) Received-Date: Fri, 23 Oct 1998 00:54:09 +0200 (MET DST) Received: from alpha.franken.de (tsbogend@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA15169; Fri, 23 Oct 1998 00:54:07 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA03894; Fri, 23 Oct 1998 00:51:34 +0200 Message-ID: <19981023005132.A3866@alpha.franken.de> Date: Fri, 23 Oct 1998 00:51:32 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981022222010.A2556@alpha.franken.de> <19981022230654.B32660@zigzegv.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981022230654.B32660@zigzegv.ml.org>; from Ulf Carlsson on Thu, Oct 22, 1998 at 11:06:54PM +0200 Content-Length: 612 Lines: 16 On Thu, Oct 22, 1998 at 11:06:54PM +0200, Ulf Carlsson wrote: > Yes, I think you are barking at the wrong corner, I haven't seen anything like > this on a 32 Mb intel machine. and I've tried your test on a 64MB _Intel_ machine at work, and the behaviour was the same as on your Indy. it works perfect at least on my Olli. If you don't have a spare partition you can use a swapfile. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From ralf@lappi.waldorf-gmbh.de Tue Oct 27 16:37:03 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA07663; Tue, 27 Oct 1998 16:36:39 +0100 (MET) Received-Date: Tue, 27 Oct 1998 16:36:39 +0100 (MET) Received: from lappi.waldorf-gmbh.de (pmport-15.uni-koblenz.de [141.26.249.15]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id QAA17938 for ; Tue, 27 Oct 1998 16:36:33 +0100 (MET) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id CAA00392; Fri, 23 Oct 1998 02:32:32 +0200 Message-ID: <19981023023232.A375@uni-koblenz.de> Date: Fri, 23 Oct 1998 02:32:32 +0200 From: ralf@uni-koblenz.de To: Thomas Bogendoerfer , linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981022222010.A2556@alpha.franken.de> <19981022230654.B32660@zigzegv.ml.org> <19981023005132.A3866@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981023005132.A3866@alpha.franken.de>; from Thomas Bogendoerfer on Fri, Oct 23, 1998 at 12:51:32AM +0200 Content-Length: 504 Lines: 15 On Fri, Oct 23, 1998 at 12:51:32AM +0200, Thomas Bogendoerfer wrote: > On Thu, Oct 22, 1998 at 11:06:54PM +0200, Ulf Carlsson wrote: > > Yes, I think you are barking at the wrong corner, I haven't seen anything like > > this on a 32 Mb intel machine. > > and I've tried your test on a 64MB _Intel_ machine at work, and the behaviour > was the same as on your Indy. > > it works perfect at least on my Olli. If you don't have a spare partition > you can use a swapfile. Can you say diskless? Ralf From mitch@execpc.com Fri Oct 23 02:44:33 1998 Received: from mailgw02.execpc.com (mailgw02.execpc.com [169.207.3.78]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA22200; Fri, 23 Oct 1998 02:44:29 +0200 (MET DST) Received-Date: Fri, 23 Oct 1998 02:44:29 +0200 (MET DST) Received: from earth.execpc.com (mitch@earth.execpc.com [169.207.16.1]) by mailgw02.execpc.com (8.9.0) id TAA22563 for ; Thu, 22 Oct 1998 19:44:00 -0500 (CDT) Received: (from mitch@localhost) by earth.execpc.com (8.9.0) id TAA22683; Thu, 22 Oct 1998 19:44:42 -0500 (CDT) Message-ID: <19981022194442.27891@execpc.com> Date: Thu, 22 Oct 1998 19:44:42 -0500 From: Mitchell Blank Jr To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981020103052.G676@uni-koblenz.de> <19981021134544.A30452@zigzegv.ml.org> <19981021233814.A3030@alpha.franken.de> <19981022090933.A879@bun.falkenberg.se> <362F69B5.AB94E713@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e-execpc In-Reply-To: <362F69B5.AB94E713@xmission.com>; from Eric Jorgensen on Thu, Oct 22, 1998 at 11:21:57AM -0600 Content-Length: 655 Lines: 15 Eric Jorgensen wrote: > Yes and no. Personally I find the concept of running a modern system > without available swap somewhat perilous. What about if you don't have any disk nor any rw filesystems? Not unusual in imbedded applications. The only way to get around it now apparently is to set up a ram disk and swap to that -- hardly effecient or useful (except in the case where some RAM is slower). A typical UNIX workstation or server should always have swap -- there are always some gettys or something that might as well be swapped out to make room for more disk cache. There are applications, however, where swap is just not an option. -Mitch From engel@math.uni-siegen.de Sun Oct 25 11:37:42 1998 Received: from fourier.numerik.math.uni-siegen.de (fourier.numerik.math.uni-siegen.de [141.99.112.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA17919; Sun, 25 Oct 1998 11:37:41 +0100 (MET) Received-Date: Sun, 25 Oct 1998 11:37:41 +0100 (MET) From: engel@math.uni-siegen.de Received: (from engel@localhost) by fourier.numerik.math.uni-siegen.de (Mailhost) id LAA10030; Sun, 25 Oct 1998 11:37:47 +0100 (MET) Date: Sun, 25 Oct 1998 11:37:47 +0100 (MET) Message-Id: <199810251037.LAA10030@fourier.numerik.math.uni-siegen.de> To: linux-mips@fnet.fr Subject: (fwd) Urgently needed: DECstation, MIPS-based (pmax) Content-Length: 827 Lines: 23 Just found this posting in misc.forsale.computers.workstation. Can anyone in the SF Bay Area help this guy ? regards, Michael Engel (engel@numerik.math.uni-siegen.de) -- forwarded message -- From: benco@flamingo.McKusick.COM (Ben Cottrell) Newsgroups: misc.forsale.computers.workstation Subject: Urgently needed: DECstation, MIPS-based (pmax) Date: 25 Oct 1998 01:08:36 PST I'm in the San Francisco Bay Area, and my DECstation 3100 just bit the dust. I need this machine, and I'm willing to pay a premium for a replacement. I don't need a monitor, disk, or RAM, just the CPU. Any model in the DECstation line will do, from the 2100 all the way up to the 5000/240. No Alphas please. I'll pay whatever you want if you can get me a machine *fast*. Thanks!!! ~Ben Cottrell benco@mckusick.com -- end of forwarded message -- From lembark@wrkhors.com Mon Oct 26 09:42:59 1998 Received: from bird.wrkhors.com (bird.wrkhors.com [206.180.156.161]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA26318; Mon, 26 Oct 1998 09:42:57 +0100 (MET) Received-Date: Mon, 26 Oct 1998 09:42:57 +0100 (MET) Received: from wrkhors.com (poolf2-008.wwa.com [207.241.63.73]) by bird.wrkhors.com (8.8.5/8.8.5) with ESMTP id CAA11138 for ; Mon, 26 Oct 1998 02:41:45 -0600 Sender: lembark@wrkhors.com Message-ID: <36343600.C5942788@wrkhors.com> Date: Mon, 26 Oct 1998 02:42:40 -0600 From: Steven Lembark Organization: Workhorse Computing X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.35 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: (fwd) Urgently needed: DECstation, MIPS-based (pmax) References: <199810251037.LAA10030@fourier.numerik.math.uni-siegen.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB15F590410E6A4A73EFBF4C8" Content-Length: 5195 Lines: 84 This is a cryptographically signed message in MIME format. --------------msB15F590410E6A4A73EFBF4C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I'm in the San Francisco Bay Area, and my DECstation 3100 just bit the > dust. I need this machine, and I'm willing to pay a premium for a > replacement. I don't need a monitor, disk, or RAM, just the CPU. Any > model in the DECstation line will do, from the 2100 all the way up to > the 5000/240. No Alphas please. I'll pay whatever you want if you if you still need the machine i can forward the address of one gent at Queen's College in Canada. they were dumping a fair bit of hardware this summer and [i think?] had some leftover, stripped down 3100's left. very good prices (basically a few bucks over shipping). -- Steven Lembark 2930 W. Palmer St. Workhorse Computing Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 --------------------------------------------------------------------- The opinions expressed here are those of this company. I am the company. --------------------------------------------------------------------- --------------msB15F590410E6A4A73EFBF4C8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKnQYJKoZIhvcNAQcCoIIKjjCCCooCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CNYwggQgMIIDiaADAgECAhBVDFTJrYx0lb7N/7Wcab/6MA0GCSqGSIb3DQEBBAUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05ODAyMTMwMDAw MDBaFw05OTAyMTMyMzU5NTlaMIIBHDERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MTMwMQYDVQQLEypEaWdpdGFsIElEIENs YXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMTDlN0ZXZlbiBMZW1iYXJr MSIwIAYJKoZIhvcNAQkBFhNsZW1iYXJrQHdya2hvcnMuY29tMFwwDQYJKoZIhvcNAQEBBQAD SwAwSAJBALIZkLcDVrYlAXaMuzHZgRNl8sXENgQpWOY1y/qQ3zr28bz2wx58G6nAUE8Ua9ua 3jSATooRSELXWxt+wyguwwECAwEAAaOCAV0wggFZMAkGA1UdEwQCMAAwga8GA1UdIASBpzCA MIAGC2CGSAGG+EUBBwEBMIAwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidz IENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduAAAA AAAAMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0 NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVk M2YyMTQxYmVhZGIyYmQyZTg5MjE1YWE2OWYxZDQxMTQ5OTdhMWIzNDNmNGU1OTc2NTQxMA0G CSqGSIb3DQEBBAUAA4GBAEWNZJ2oEw1sqpCyiYNc0DCoG3ytfJcWz/yvDSNWIdVcau0WkIq3 xTTyml4GUxR8/nqbPwy/Ye9q24Lf9az3DVMTVaaw0dgnSrExrfzSuEYuFPyMi4cYr1NAbfyu ZRHx5ckbJUU9UyPQPjuTF8NjdrggAAPlTz8vK1NBhUJ/Xm9pMIICeTCCAeKgAwIBAgIQUh81 HfJwfgArvspZhwTVOTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3MDAwMDAwWhcNOTkwNjI3MjM1OTU5WjBiMREw DwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1Zl cmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALYUps9N0AUN2Moj0G+qtCmSY44s+G+W1y6ddksRsTaNV8nD/RzG uv4eCLozypXqvuNbzQaot3kdRCrtc/KxUoNoEHBkkdc+a/n3XZ0UQ5tul0WYgUfRLcvdu3LX TD9xquJA8lQ5vBbuz3zsuts/bCqzFrGGEp2ukzTVuNXQ9z6pAgMBAAGjMzAxMA8GA1UdEwQI MAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIF AAOBgQDB+vcC51fKEXXGnAz6K3dPh0UXO+PSwdoPWDmOrpWZA6GooTj+eZqTFwuXhjnHymg0 ZrvHiEX2yAwF7r6XJe/g1G7kf512XM59uhSirguf+2dbSKVnJa8ZZIj2ctgpJ6o3EmqxKK8n gxhlbI3tQJ5NxHiohuzpLFC/pvkN27CmSjCCAjEwggGaAgUCpAAAATANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5 MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOUZv22jVmEtmUhx9mfe uY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiHmgabEKFz37RYOWtuwfYV1aio P6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF4Ncth3uhtzKwezC6Ki8x qu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAUnO6mlXc3D+CfbCQmGIqgkx2AG4lPdXC CXBXAQwPdx8YofscYA6gdTtJIUH+p1wtTEJJ0/8o2Izqnf7JB+J3glMj3lXzzkST+vpMvco2 81tmsp7I8gxeXtShtCEJM8o7WfySwjj8rdmWJOAt+qMp9TNoeE60vJ9pNeKomJRzO8QxggGP MIIBiwIBATB2MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJl cgIQVQxUya2MdJW+zf+1nGm/+jAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTAyNjA4NDI0MFowIwYJKoZIhvcNAQkEMRYEFLKR IsYiJiUO9rRpkkSYkRAqGoNuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABECP2uwm7aDg0SBxZDCeb9iYyfJdDB5o6A45AiEdcWW8StwiRvuTtyA2iHUt y2pkF8+HReYw8URs5mcab/+ojiWM --------------msB15F590410E6A4A73EFBF4C8-- From imp@village.org Tue Oct 27 00:35:15 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id AAA02582; Tue, 27 Oct 1998 00:35:12 +0100 (MET) Received-Date: Tue, 27 Oct 1998 00:35:12 +0100 (MET) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zXwA8-000502-00; Mon, 26 Oct 1998 16:35:00 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id QAA12729; Mon, 26 Oct 1998 16:35:05 -0700 (MST) Message-Id: <199810262335.QAA12729@harmony.village.org> To: linux-mips@fnet.fr Cc: linux@linus.linux.sgi.com Subject: MIPS R3230? Date: Mon, 26 Oct 1998 16:35:05 -0700 From: Warner Losh Content-Length: 363 Lines: 9 I've seen lots of traffic about people asking for various MIPS systems. Today, I saved a R3230 from an ignoble fate in a dumpster... It is running RISC/OS 4.52B (or was that 4.50B) and has the source to all the driver on the disk.... I also have the boot tapes and 3' of documentation. Has anybody actually tried to get Linux working on this machine? Warner From alhaz@xmission.com Tue Oct 27 00:59:52 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA02744; Tue, 27 Oct 1998 00:59:51 +0100 (MET) Received-Date: Tue, 27 Oct 1998 00:59:51 +0100 (MET) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zXwXt-0001lH-00 for linux-mips@fnet.fr; Mon, 26 Oct 1998 16:59:34 -0700 Sender: alhaz@fnet.fr Message-ID: <36350CDA.2546DFBD@xmission.com> Date: Mon, 26 Oct 1998 16:59:22 -0700 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: MIPS R3230? References: <199810262335.QAA12729@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1037 Lines: 24 Warner Losh wrote: > > I've seen lots of traffic about people asking for various MIPS > systems. Today, I saved a R3230 from an ignoble fate in a > dumpster... It is running RISC/OS 4.52B (or was that 4.50B) and has > the source to all the driver on the disk.... I also have the boot > tapes and 3' of documentation. > > Has anybody actually tried to get Linux working on this machine? I also have one of these things. That's 4.52B alright. The version on mine is refered to as "4.52+" I think. It is considered the last stable MIPS co release. Tho the source is all there, there's some question as to how much it could be used. While MIPS nolonger maintains RISCos, Controll Data Corp. still maintains their own OEM version of it, which they refer to as "EP/IX". Controll Data sold several Mips systems relabled as their own and still has a lot of customers using RC3240's and similar boxes. However, I hardly think MIPS or CDC would complain if the source was ogled a bit in the process of writing Linux drivers. - Eric From alhaz@xmission.com Tue Oct 27 01:03:54 1998 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA02813; Tue, 27 Oct 1998 01:03:53 +0100 (MET) Received-Date: Tue, 27 Oct 1998 01:03:53 +0100 (MET) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail.xmission.com with esmtp (Exim 2.04 #1) id 0zXwbQ-00026A-00 for linux-mips@fnet.fr; Mon, 26 Oct 1998 17:03:12 -0700 Sender: alhaz@fnet.fr Message-ID: <36350DB4.3CC01730@xmission.com> Date: Mon, 26 Oct 1998 17:03:00 -0700 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: MIPS R3230? References: <199810262335.QAA12729@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 643 Lines: 16 Warner Losh wrote: > > I've seen lots of traffic about people asking for various MIPS > systems. Today, I saved a R3230 from an ignoble fate in a > dumpster... It is running RISC/OS 4.52B (or was that 4.50B) and has > the source to all the driver on the disk.... I also have the boot > tapes and 3' of documentation. Scratch that. I have a 2030 and a 3240. But I don't use either of them. I'd love to use the 3240 tho. On the other hand, I don't have a complete distribution of RISCos on either of them. They both mounted most of the /usr tree (or whatever it is on riscos) via NFS, some machine they can't talk to anymore. - Eric From ralf@lappi.waldorf-gmbh.de Tue Oct 27 16:33:57 1998 Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA07622; Tue, 27 Oct 1998 16:33:51 +0100 (MET) Received-Date: Tue, 27 Oct 1998 16:33:51 +0100 (MET) Received: from lappi.waldorf-gmbh.de (pmport-15.uni-koblenz.de [141.26.249.15]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id QAA17629 for ; Tue, 27 Oct 1998 16:33:41 +0100 (MET) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.8.7/8.8.7) id FAA07433; Tue, 27 Oct 1998 05:47:54 +0100 Message-ID: <19981027054754.G5892@uni-koblenz.de> Date: Tue, 27 Oct 1998 05:47:54 +0100 From: ralf@uni-koblenz.de To: Warner Losh Cc: linux-mips@fnet.fr, linux@engr.sgi.com Subject: Re: MIPS R3230? References: <199810262335.QAA12729@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199810262335.QAA12729@harmony.village.org>; from Warner Losh on Mon, Oct 26, 1998 at 04:35:05PM -0700 Content-Length: 0 Lines: 0 From imp@village.org Tue Oct 27 06:43:58 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id GAA04702; Tue, 27 Oct 1998 06:43:56 +0100 (MET) Received-Date: Tue, 27 Oct 1998 06:43:56 +0100 (MET) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zY1uu-00059O-00; Mon, 26 Oct 1998 22:43:40 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id WAA14178 for ; Mon, 26 Oct 1998 22:43:49 -0700 (MST) Message-Id: <199810270543.WAA14178@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: MIPS R3230? In-reply-to: Your message of "Mon, 26 Oct 1998 16:59:22 MST." <36350CDA.2546DFBD@xmission.com> References: <36350CDA.2546DFBD@xmission.com> <199810262335.QAA12729@harmony.village.org> Date: Mon, 26 Oct 1998 22:43:49 -0700 From: Warner Losh Content-Length: 1242 Lines: 24 In message <36350CDA.2546DFBD@xmission.com> Eric Jorgensen writes: : Tho the source is all there, there's some question as to how much it : could be used. While MIPS nolonger maintains RISCos, Controll Data Corp. : still maintains their own OEM version of it, which they refer to as : "EP/IX". Controll Data sold several Mips systems relabled as their own : and still has a lot of customers using RC3240's and similar boxes. I was told that MIPS formally donated the MIPS CO hardware driver sources to BSD for inclusion in their releases. However, the drivers/port never made it into the tree for reasons I've never been able to figure out. According to my sources inside mips, they should have been. : However, I hardly think MIPS or CDC would complain if the source was : ogled a bit in the process of writing Linux drivers. True. Also, the hardware for it is bog standard hardware: LANCE ethernet, NCR 53C96, PC Keyboard controller (with different non-keyboard goo than the PC has), an ISA bus (one slot, and lots of restritions), and a few other chips that looked familiar. Even if I didn't have source to all the drivers, the hardware reference manual is very complete in its description of non-off the shelf hardware. Warner From imp@village.org Tue Oct 27 06:44:42 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id GAA04727; Tue, 27 Oct 1998 06:44:40 +0100 (MET) Received-Date: Tue, 27 Oct 1998 06:44:40 +0100 (MET) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zY1vi-00059U-00; Mon, 26 Oct 1998 22:44:30 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id WAA14203 for ; Mon, 26 Oct 1998 22:44:40 -0700 (MST) Message-Id: <199810270544.WAA14203@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: MIPS R3230? In-reply-to: Your message of "Mon, 26 Oct 1998 17:03:00 MST." <36350DB4.3CC01730@xmission.com> References: <36350DB4.3CC01730@xmission.com> <199810262335.QAA12729@harmony.village.org> Date: Mon, 26 Oct 1998 22:44:40 -0700 From: Warner Losh Content-Length: 517 Lines: 14 In message <36350DB4.3CC01730@xmission.com> Eric Jorgensen writes: : Scratch that. I have a 2030 and a 3240. But I don't use either of them. : I'd love to use the 3240 tho. I see... : On the other hand, I don't have a complete distribution of RISCos on : either of them. They both mounted most of the /usr tree (or whatever it : is on riscos) via NFS, some machine they can't talk to anymore. Hmmm. That's too bad. I'd dup the two QIC-150 tapes that I have, but I don't want to violate anybody's IP. Warner From imp@village.org Tue Oct 27 06:48:13 1998 Received: from rover.village.org (rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id GAA04776; Tue, 27 Oct 1998 06:48:11 +0100 (MET) Received-Date: Tue, 27 Oct 1998 06:48:11 +0100 (MET) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zY1z7-00059f-00; Mon, 26 Oct 1998 22:48:01 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id WAA14350 for ; Mon, 26 Oct 1998 22:48:11 -0700 (MST) Message-Id: <199810270548.WAA14350@harmony.village.org> To: linux-mips@fnet.fr Subject: Re: MIPS R3230? In-reply-to: Your message of "Mon, 26 Oct 1998 22:44:40 MST." <199810270544.WAA14203@harmony.village.org> References: <199810270544.WAA14203@harmony.village.org> <36350DB4.3CC01730@xmission.com> <199810262335.QAA12729@harmony.village.org> Date: Mon, 26 Oct 1998 22:48:10 -0700 From: Warner Losh Content-Length: 292 Lines: 7 I do have one specific question that doesn't appear to be in the hardware reference. Can someone help me on where to find the entry points to the MIPS ROM/firmware? I've not been able to find a vector table or anything like that in my hunting trought the hardware reference manual. Warner From alhaz@xmission.com Tue Oct 27 07:57:20 1998 Received: from mail (mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id HAA05140; Tue, 27 Oct 1998 07:57:18 +0100 (MET) Received-Date: Tue, 27 Oct 1998 07:57:18 +0100 (MET) Received: from alhaz.users.xmission.com ([207.135.128.199] helo=xmission.com ident=alhaz) by mail with esmtp (Exim 2.04 #1) id 0zY341-0001hd-00 for linux-mips@fnet.fr; Mon, 26 Oct 1998 23:57:09 -0700 Sender: alhaz@fnet.fr Message-ID: <36356EB8.D3925E6F@xmission.com> Date: Mon, 26 Oct 1998 23:56:56 -0700 From: Eric Jorgensen X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: MIPS R3230? References: <36350CDA.2546DFBD@xmission.com> <199810262335.QAA12729@harmony.village.org> <199810270543.WAA14178@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1604 Lines: 33 Warner Losh wrote: > : However, I hardly think MIPS or CDC would complain if the source was > : ogled a bit in the process of writing Linux drivers. > > True. Also, the hardware for it is bog standard hardware: LANCE > ethernet, NCR 53C96, PC Keyboard controller (with different > non-keyboard goo than the PC has), an ISA bus (one slot, and lots of > restritions), and a few other chips that looked familiar. Even if I > didn't have source to all the drivers, the hardware reference manual > is very complete in its description of non-off the shelf hardware. The 3240 is very similar. The only difference I can think of is the presence of 4 ISA slots. I was told by a MIPS engineer that those slots were designed specificly with Digiboard serial port boards in mind. In case you wanted to use the thing as a terminal server. So, yes, they would be considerably limited. I haven't turned on either of them in about 2 years. the 3240 is serving as a glorified bookend. It weighs so much I'm using it to sandwitch a full tower case that lacks feet up against a cabinet. Rather unfortunate since I have a whopping 40 megs of ram installed in it. Two 16-meg boards and one 8-meg. Naturally, the battery in the RTC has died long ago as well. I hear I can order a new one from Mouser for about $20, but, bookends don't need to know what time it is. But I keep the 3240 around for sentimental reasons. I had a "borrowed" account on it many years ago. Was my first shell account. The university that owned it surplused it, and for $100 i figured it was worth completing the circle. - Eric From tsbogend@alpha.franken.de Tue Oct 27 20:58:29 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA09049; Tue, 27 Oct 1998 20:58:28 +0100 (MET) Received-Date: Tue, 27 Oct 1998 20:58:28 +0100 (MET) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id UAA23905; Tue, 27 Oct 1998 20:58:25 +0100 (MET) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id UAA02488; Tue, 27 Oct 1998 20:20:28 +0100 Message-ID: <19981027202028.A2430@alpha.franken.de> Date: Tue, 27 Oct 1998 20:20:28 +0100 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981023005132.A3866@alpha.franken.de> <19981023023232.A375@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981023023232.A375@uni-koblenz.de>; from ralf@uni-koblenz.de on Fri, Oct 23, 1998 at 02:32:32AM +0200 Content-Length: 1760 Lines: 44 On Fri, Oct 23, 1998 at 02:32:32AM +0200, ralf@uni-koblenz.de wrote: > On Fri, Oct 23, 1998 at 12:51:32AM +0200, Thomas Bogendoerfer wrote: > > it works perfect at least on my Olli. If you don't have a spare partition > > you can use a swapfile. > > Can you say diskless? yes it's spelled NBD (network block device). But before telling me that the current behaviour isn't good for diskless machines, go and fix it. I'm no longer convinced that it's a generic Linux problem. The Intel machine, where I did the test first, doesn't show the problem anymore. My Alpha doesn't do it and my P5 SMP system works as expected. And now the big news, it doesn't happen on the Olli: [root@mips /root]# free total used free shared buffers cached Mem: 30340 6068 24272 6248 964 1952 -/+ buffers/cache: 3152 27188 Swap: 0 0 0 [root@mips /root]# ./xx failed to allocate 512 bytes (23890432 bytes already allocated) spinning ... It only happens on the Indy: [root@indy /root]# free total used free shared buffers cached Mem: 60448 11676 48772 9308 772 6580 -/+ buffers/cache: 4324 56124 Swap: 0 0 0 [root@indy /root]# ./xx failed to allocate 512 bytes (40519680 bytes already allocated) spinning ... On all other platforms I get about the memory (minus some kbytes), what was free at the time I started the test. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From ulfc@bun.falkenberg.se Tue Oct 27 23:01:45 1998 Received: from calypso.saturn (root@dialup145-1-2.swipnet.se [130.244.145.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA09919; Tue, 27 Oct 1998 23:01:42 +0100 (MET) Received-Date: Tue, 27 Oct 1998 23:01:42 +0100 (MET) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Tue, 27 Oct 1998 23:03:30 +0100 (CET) Message-ID: <19981027230330.A23744@zigzegv.ml.org> Date: Tue, 27 Oct 1998 23:03:30 +0100 From: Ulf Carlsson To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981023005132.A3866@alpha.franken.de> <19981023023232.A375@uni-koblenz.de> <19981027202028.A2430@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <19981027202028.A2430@alpha.franken.de>; from Thomas Bogendoerfer on Tue, Oct 27, 1998 at 08:20:28PM +0100 Content-Length: 599 Lines: 20 > It only happens on the Indy: > > [root@indy /root]# free > total used free shared buffers cached > Mem: 60448 11676 48772 9308 772 6580 > -/+ buffers/cache: 4324 56124 > Swap: 0 0 0 > [root@indy /root]# ./xx > failed to allocate 512 bytes (40519680 bytes already allocated) > spinning ... Do you suffer from Unable to load interpreter Segmentation fault (core dumped) when you try to run something else (fore example 'free') in another console while running xx as well? - Ulf From tsbogend@alpha.franken.de Wed Oct 28 01:16:48 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA11684; Wed, 28 Oct 1998 01:16:47 +0100 (MET) Received-Date: Wed, 28 Oct 1998 01:16:47 +0100 (MET) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id BAA26034; Wed, 28 Oct 1998 01:16:45 +0100 (MET) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA04144; Wed, 28 Oct 1998 00:34:22 +0100 Message-ID: <19981028003421.A4093@alpha.franken.de> Date: Wed, 28 Oct 1998 00:34:21 +0100 From: Thomas Bogendoerfer To: linux-mips@fnet.fr Subject: Re: R5000 Unused memory (was: R4000SC...) References: <19981013220043.A2620@uni-koblenz.de> <19981015195141.A1697@zigzegv.ml.org> <19981016132433.C3370@uni-koblenz.de> <19981017104618.A3076@zigzegv.ml.org> <19981018111145.J4768@uni-koblenz.de> <19981019111501.A16024@zigzegv.ml.org> <1998102010305 <19981027202028.A2430@alpha.franken.de> <19981027230330.A23744@zigzegv.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981027230330.A23744@zigzegv.ml.org>; from Ulf Carlsson on Tue, Oct 27, 1998 at 11:03:30PM +0100 Content-Length: 681 Lines: 21 On Tue, Oct 27, 1998 at 11:03:30PM +0100, Ulf Carlsson wrote: > > [root@indy /root]# ./xx > > failed to allocate 512 bytes (40519680 bytes already allocated) > > spinning ... > > Do you suffer from > > Unable to load interpreter > Segmentation fault (core dumped) > > when you try to run something else (fore example 'free') in another console > while running xx as well? yes, this time it happens for both MIPS boxes, but not on Intel nor Alpha. Thomas. -- This device has completely bogus header. Compaq scores again :-| It's a host bridge, but it should be called ghost bridge instead ;^) [Martin `MJ' Mares on linux-kernel] From bglenn@sar.usf.edu Wed Oct 28 00:55:18 1998 Received: from virtu.sar.usf.edu (virtu.sar.usf.edu [131.247.152.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA11546; Wed, 28 Oct 1998 00:55:03 +0100 (MET) Received-Date: Wed, 28 Oct 1998 00:55:03 +0100 (MET) Received: from sar.usf.edu (sarppp41.net.usf.edu [131.247.152.200]) by virtu.sar.usf.edu (8.8.7/8.6.5) with ESMTP id SAA10657 for ; Tue, 27 Oct 1998 18:54:47 -0500 (EST) Message-ID: <36365D37.B4387861@sar.usf.edu> Date: Tue, 27 Oct 1998 18:54:31 -0500 From: Brian Glenn Organization: New College X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: dECstation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 209 Lines: 3 I have a Decstation 5000//240 that has been unsuccessful at running NetBSD (it always hangs on the comport) has this port been completed for such a system and if so where would be a how-to on what to install? From harald.koerfgen@netcologne.de Wed Oct 28 18:08:59 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA16550; Wed, 28 Oct 1998 18:08:57 +0100 (MET) Received-Date: Wed, 28 Oct 1998 18:08:57 +0100 (MET) Received: from franz.no.dom (dial4-111.netcologne.de [195.14.233.111]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id SAA00183 for ; Wed, 28 Oct 1998 18:08:53 +0100 (MET) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810270548.WAA14350@harmony.village.org> Date: Wed, 28 Oct 1998 18:10:24 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: MIPS R3230? Content-Length: 833 Lines: 21 Hi Warner, On 27-Oct-98 Warner Losh wrote: > I do have one specific question that doesn't appear to be in the > hardware reference. Can someone help me on where to find the entry > points to the MIPS ROM/firmware? I've not been able to find a vector > table or anything like that in my hunting trought the hardware > reference manual. >From what I have been able to find out, the PROM entry points for MIPS ROMs and the PMAX PROMS (DS2100/DS3100) are pretty much the same. In that case you might want to have a look at arch/mips/dec/boot/prom.h and whichprom.c available in linux-2.1.121-r3000.tar.gz from http://decstation.unix-ag.org. If your MIPS Box is R3000 based you should use this source tree anyway because the R3000 changes aren't part of the official Linux/MIPS source tree yet. Hope this helps. --- Regards, Harald From triemer@apt4g.a3nyc.com Fri Oct 30 05:40:46 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA00345; Fri, 30 Oct 1998 05:40:45 +0100 (MET) Received-Date: Fri, 30 Oct 1998 05:40:45 +0100 (MET) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id XAA18550 for ; Thu, 29 Oct 1998 23:40:58 -0500 Date: Thu, 29 Oct 1998 23:40:57 -0500 (EST) From: Thomas Riemer To: linux-mips@fnet.fr Subject: More DZ Serial driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1632 Lines: 36 I've worked through all the details of getting characters to be received on the DZ serial driver... I've also worked through the details of getting characters to transmit on the DZ serial driver line... But I can't get them both working at the same time. Here's the problem that I'm running into: 1. register TZ_TCR has LNENB[3-0] - pins which when high are supposed to enable the transmitter logic for the outgoing lines. Setting these seems to generate an infinite number of interrupts on empty buffer condition. I would have expected a single interrupt - but it seems to generate them continuously. Everything in documentation indicates that there should be a single interrupt. 2. register TZ_LPR has pin RXENAB that needs to be set in order to receive characters. (as well as the line pins to indicate which line to receive on) For some reason, the LNENB line from TCR need to be set in order to receive characters... 3. The problem I run into is that the continuous interrupts are kicking in before the standalone shell ever gets a chance to do anything. The code was set up to turn off LNENB if there were no characters waiting to be queue - but in the process this seems to be violating the requirement #2. None of these hypotheses really make much sense standing alone - and don't really explain what I'm seeing. Having pounded my head hard on this for about 2 weeks - I'm in need of some suggestions on how to approach the problem. -Tom Riemer ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. From rajko@mech.math.msu.su Fri Oct 30 09:43:51 1998 Received: from mech.math.msu.su (mech.math.msu.su [158.250.33.65]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id JAA01798; Fri, 30 Oct 1998 09:42:56 +0100 (MET) Received-Date: Fri, 30 Oct 1998 09:42:56 +0100 (MET) Received: (from rajko@localhost) by mech.math.msu.su (8.6.10/8.6.10/sasha.040695) id MAA22938; Fri, 30 Oct 1998 12:42:51 +0300 Date: Fri, 30 Oct 1998 12:42:49 +0300 (MSK) From: "Gleb O. Rajko" To: linux-mips@fnet.fr Subject: lmbench results for Baget/MIPS Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------98E7AAC2FA78DD8C254DFDF1 Content-ID: Content-Length: 3735 Lines: 75 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------98E7AAC2FA78DD8C254DFDF1 Content-Type: TEXT/PLAIN; CHARSET=koi8-r Content-ID: There are lmbench summary for the Baget/MIPS box as I promised to measure. My comments are o I didn't ever try to measure fs performance, now Baget/MIPS is diskless and I guess nobody want to measure NFS over 10Mb/s Ethernet. o There are no results for several context switching tests, Baget has only 16 MB of RAM without swap at all. Regards, Gleb. --------------98E7AAC2FA78DD8C254DFDF1 Content-Type: TEXT/PLAIN; CHARSET=koi8-r; NAME="lmbench.r3k" Content-ID: cd results && make summary percent 2>/dev/null | more make[1]: Entering directory `/tmp/lmbench-2alpha10/results' L M B E N C H 1 . 9 S U M M A R Y ------------------------------------ (Alpha software, do not distribute) Processor, Processes - times in microseconds - smaller is better ---------------------------------------------------------------- Host OS Mhz null null open selct sig sig fork exec sh call I/O stat clos inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ---- mips-linu Linux 2.1.121 25 6.5 15. 4805 4886 0.83K 29.0 115 10.1K 154K 543K Context switching - times in microseconds - smaller is better ------------------------------------------------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ----- ------ ------ ------ ------ ------- ------- mips-linu Linux 2.1.121 13 230 404 758 *Local* Communication latencies in microseconds - smaller is better ------------------------------------------------------------------- Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP ctxsw UNIX UDP TCP conn --------- ------------- ----- ----- ---- ----- ----- ----- ----- ---- mips-linu Linux 2.1.121 13 155 251 508 813 3180 File & VM system latencies in microseconds - smaller is better -------------------------------------------------------------- Host OS 0K File 10K File Mmap Prot Page Create Delete Create Delete Latency Fault Fault --------- ------------- ------ ------ ------ ------ ------- ----- ----- mips-linu Linux 2.1.121 127778 13 *Local* Communication bandwidths in MB/s - bigger is better ----------------------------------------------------------- Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem UNIX reread reread (libc) (hand) read write --------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- ----- mips-linu Linux 2.1.121 10 5 4 7 12 13 12 12 33 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) --------------------------------------------------- Host OS Mhz L1 $ L2 $ Main mem Guesses --------- ------------- --- ---- ---- -------- ------- mips-linu Linux 2.1.121 25 80 200 310 make[1]: Leaving directory `/tmp/lmbench-2alpha10/results' --------------98E7AAC2FA78DD8C254DFDF1-- From ulfc@bun.falkenberg.se Fri Oct 30 13:31:57 1998 Received: from calypso.saturn (root@dialup49-4-27.swipnet.se [130.244.49.219]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA02778; Fri, 30 Oct 1998 13:31:55 +0100 (MET) Received-Date: Fri, 30 Oct 1998 13:31:55 +0100 (MET) Received: by bun.falkenberg.se via sendmail from stdin id (Debian Smail3.2.0.101) for linux-mips@fnet.fr; Fri, 30 Oct 1998 13:33:19 +0100 (CET) Message-ID: <19981030133319.A3845@bun.falkenberg.se> Date: Fri, 30 Oct 1998 13:33:19 +0100 From: Ulf Carlsson To: ralf@uni-koblenz.de Cc: linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com Subject: ksymoops support for MIPS Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=oyUTqETQ0mS9luUI X-Mailer: Mutt 0.93.2 Content-Length: 4689 Lines: 187 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Hi Ralf, I've modified arch/mips/kernel/traps.c to support ksymoops, and Keith Owens has modified ksymoops to support MIPS. A new version of ksymoops will show up within a few days at ftp://ftp.ocs.com.au/pub/ksymoops.tar.gz. I have a later version of ksymoops which works, but I prefer not to spam you :) Can't you please include this patch in the CVS tree? - Ulf --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="traps.c.diff" --- linux/arch/mips/kernel/traps.c-orig Thu Oct 29 17:23:19 1998 +++ linux/arch/mips/kernel/traps.c Fri Oct 30 13:25:21 1998 @@ -6,6 +6,7 @@ * * Copyright 1994, 1995, 1996, 1997, 1998 by Ralf Baechle * Modified for R3000 by Paul M. Antoine, 1995, 1996 + * Complete output from die() by Ulf Carlsson, 1998 */ #include #include @@ -80,50 +81,61 @@ * This routine abuses get_user()/put_user() to reference pointers * with at least a bit of error checking ... */ -void show_registers(char * str, struct pt_regs * regs, long err) +void show_stack(unsigned int *sp) { - int i; - int *stack; - u32 *sp, *pc, addr, module_start, module_end; - extern char start_kernel, _etext; + int i; + unsigned int *stack; - sp = (u32 *)regs->regs[29]; - pc = (u32 *)regs->cp0_epc; + stack = sp; + i = 0; - show_regs(regs); + printk("Stack:"); + while ((unsigned long) stack & (PAGE_SIZE - 1)) { + unsigned long stackdata; - /* - * Dump the stack - */ - printk("Process %s (pid: %ld, stackpage=%08lx)\nStack: ", - current->comm, current->pid, (unsigned long)current); - for(i=0;i<5;i++) - printk("%08x ", *sp++); - stack = (int *) sp; + if (__get_user(stackdata, stack++)) { + printk(" (Bad stack address)"); + break; + } - for(i=0; i < kstack_depth_to_print; i++) { - unsigned int stackdata; + printk(" %08lx", stackdata); - if (((u32) stack & (PAGE_SIZE -1)) == 0) - break; - if (i && ((i % 8) == 0)) - printk("\n "); - if (get_user(stackdata, stack++) < 0) { - printk("(Bad stack address)"); + if (++i > 40) { + printk(" ..."); break; } - printk("%08x ", stackdata); + + if (i % 8 == 0) + printk("\n "); } - printk("\nCall Trace: "); - stack = (int *)sp; - i = 1; +} + +void show_trace(unsigned int *sp) +{ + int i; + unsigned int *stack; + unsigned long kernel_start, kernel_end; + unsigned long module_start, module_end; + extern char _stext, _etext; + + stack = sp; + i = 0; + + kernel_start = (unsigned long) &_stext; + kernel_end = (unsigned long) &_etext; module_start = VMALLOC_START; module_end = module_start + MODULE_RANGE; - while (((unsigned long)stack & (PAGE_SIZE -1)) != 0) { - if (get_user(addr, stack++) < 0) { - printk("(Bad address)\n"); + + printk("\nCall Trace:"); + + while ((unsigned long) stack & (PAGE_SIZE -1)) { + unsigned long addr; + + if (__get_user(addr, stack++)) { + printk(" (Bad stack address)\n"); break; } + /* * If the address is either in the text segment of the * kernel, or in the region which contains vmalloc'ed @@ -132,26 +144,33 @@ * down the cause of the crash will be able to figure * out the call path that was taken. */ - if (((addr >= (u32) &start_kernel) && - (addr <= (u32) &_etext)) || - ((addr >= module_start) && (addr <= module_end))) { - if (i && ((i % 8) == 0)) - printk("\n "); - printk("%08x ", addr); - i++; + + if ((addr >= kernel_start && addr < kernel_end) || + (addr >= module_start && addr < module_end)) { + + printk(" [<%08lx>]", addr); + if (++i > 40) { + printk(" ..."); + break; + } } } +} - printk("\nCode : "); - if ((KSEGX(pc) == KSEG0 || KSEGX(pc) == KSEG1) && - (((unsigned long) pc & 3) == 0)) - { - for(i=0;i<5;i++) - printk("%08x ", *pc++); - printk("\n"); +void show_code(unsigned int *pc) +{ + long i; + + printk("\nCode:"); + + for(i = -3 ; i < 6 ; i++) { + unsigned long insn; + if (__get_user(insn, pc + i)) { + printk(" (Bad address in epc)\n"); + break; + } + printk("%c%08lx%c",(i?' ':'<'),insn,(i?' ':'>')); } - else - printk("(Bad address in epc)\n"); } void die(const char * str, struct pt_regs * regs, unsigned long err) @@ -162,6 +181,12 @@ console_verbose(); printk("%s: %04lx\n", str, err & 0xffff); show_regs(regs); + printk("Process %s (pid: %ld, stackpage=%08lx)\n", + current->comm, current->pid, (unsigned long) current); + show_stack((unsigned int *) regs->regs[29]); + show_trace((unsigned int *) regs->regs[29]); + show_code((unsigned int *) regs->cp0_epc); + printk("\n"); do_exit(SIGSEGV); } --oyUTqETQ0mS9luUI-- From jeff@ix.netcom.com Sat Oct 31 08:38:10 1998 Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id IAA10259; Sat, 31 Oct 1998 08:38:09 +0100 (MET) Received-Date: Sat, 31 Oct 1998 08:38:09 +0100 (MET) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id BAA11059 for ; Sat, 31 Oct 1998 01:37:35 -0600 (CST) Received: from spr-mo3-01.ix.netcom.com(204.32.183.97) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma011010; Sat Oct 31 01:37:14 1998 Date: Sat, 31 Oct 1998 01:27:49 -0600 (CST) From: Jeffery Douglas Waddell X-Sender: jeff@family.wadsoft.com Reply-To: jwaddell@ix.netcom.com To: linux-mips@fnet.fr Subject: MIPS Linux kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3305 Lines: 122 Hello, I found your Linux/MIPS porting page and am wondering if this could possibly work with a Tektronix XTerminal. It appears that these beasts are MIPS boxes. The kernel from tektronix is "MIPSEB COFF executable (paged) stripped - version 0.214" Can a Linux kernel of this type be made? I'm trying to download some of your crossdev and filesystem tools so I can play with this as we speak, but I'm on a slow connection and I'm not sure I can get all of it (at least not tonight). Might be time to haul the zip drive back to work (at least it has a fractional T1) and download it all to zip disk and then bring it home. Anyway, what I have is a XP114C Xterminal from Tektronix. It has a very nice PROM that allows you to boot from NFS (over ethernet), tftp, or ROM. It is not equipped with the ROM. Here are some of the specs I get from looking at the machine. Chips inside: ------------- Tektronix 160-9461-00 9429KVA62 ------------- LSI LR33020MC-33 GRAPHX PROC WK70762P NNG 9425 * 5A13FNWJFAAPQ HONG KONG ------------ * above is triangle graphic TI Video TLC34075 -85AFN 3188405 94238N ----------- Obviously a Texas Instruments chip (has the logo) S9430AB C4 PATENTED (c)(m) 1993 DP83934BVUL TM SONIC-T --------------No clue on this one. All those are approximately the same size (square and about the size of a intel 386 chip) and wired directly to the board. The board is Copyrighted 1993 by Tektronix I don't see anything I recognize as a clock chip, but there is a FLASH chip (I assume this is the NVRAM), and a PHOENIXBIOS chip (it's says AKB (c)PHOENIX 1985-1993 K065542 and there are 8 NEC (424400-70, is this a 70 ns 512K memory chip perhaps) that look like memory chips. There are two internal expansion slots, both appear to be 72 pin memory expansion. One has RAM next to it, and the other has FLASH next to it. External Connectors Ethernet AUI THINNET (10Base2) 10BaseT Serial Port 0 Port 1 PS/2 Mouse Keyboard When it boots you get a nice Tektronix log and a bunch of info about the machine which includes that it has 4096 bytes of RAM (from info I seen elsewhere it can be upgraded to 20M so I assume that you just drop a 16M 72 Module in the internal RAM slot. It then attempts to boot over NFS (because it was apparently set to this previously). If you wait until it fails, or hit a key it will give you a prompt. Help gives you information about all the boot prom commands. I set it up to boot of of THINNET via NFS and it failed because it could find os.350. So I went and searched the net, I found os.350 on tektronix site, so I downloaded it. And the machine will now boot load the os.350 kernel from my linux box (ix86) and then it fails to load Xge8.350. I was wanting to run Linux instead of Tektronix's stuff anyway, so I did `file os.350` and determined the output you see above and so here I am. I've already tried the dec.vmlinuz base binary but the terminal says it's a bad magic number, so I assume that that binary was little endian and I need big endian. Anyway, let me know if any of what I have said is useful, and if your porting efforts can help me. Sincerely, Jeff Waddell jwaddell@ix.netcom.com President Southern Missouri Linux User's Club http://www.oznet.com/luc Coming soon www.smluc.org!!!!! From harald.koerfgen@netcologne.de Sat Oct 31 15:56:48 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA12471; Sat, 31 Oct 1998 15:56:45 +0100 (MET) Received-Date: Sat, 31 Oct 1998 15:56:45 +0100 (MET) Received: from franz.no.dom (dial10-45.netcologne.de [195.14.235.45]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id PAA26241 for ; Sat, 31 Oct 1998 15:56:42 +0100 (MET) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 31 Oct 1998 15:58:13 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: lmbench results for Baget/MIPS Content-Length: 489 Lines: 20 Hi, On 30-Oct-98 Gleb O. Rajko wrote: > > There are lmbench summary for the Baget/MIPS box as I promised to > measure. My comments are > > o I didn't ever try to measure fs performance, now Baget/MIPS is > diskless and I guess nobody want to measure NFS over 10Mb/s Ethernet. > > o There are no results for several context switching tests, Baget has > only 16 MB of RAM without swap at all. > > Regards, > Gleb. Congrats. Did you need any patches to run lmbench? --- Regards, Harald From harald.koerfgen@netcologne.de Sat Oct 31 15:56:51 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA12475; Sat, 31 Oct 1998 15:56:50 +0100 (MET) Received-Date: Sat, 31 Oct 1998 15:56:50 +0100 (MET) Received: from franz.no.dom (dial10-45.netcologne.de [195.14.235.45]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id PAA26249 for ; Sat, 31 Oct 1998 15:56:46 +0100 (MET) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 31 Oct 1998 15:58:18 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: RE: More DZ Serial driver Content-Length: 1250 Lines: 50 On 30-Oct-98 Thomas Riemer wrote: > I've worked through all the details of getting characters to > be received on the DZ serial driver... > > I've also worked through the details of getting characters to > transmit on the DZ serial driver line... > > But I can't get them both working at the same time. > [snip] > > None of these hypotheses really make much sense standing alone - and > don't really explain what I'm seeing. Having pounded my head hard on > this for about 2 weeks - I'm in need of some suggestions on how > to approach the problem. Are you shure you are "flushing" the writeback buffer after writing to the DZ registers? If not, you may want to try the following patchlet. --- snip here --- --- dz.c.orig Sat Oct 31 15:21:05 1998 +++ dz.c Sat Oct 31 15:21:55 1998 @@ -44,6 +44,7 @@ #include #include +#include #include #include #include @@ -77,6 +78,7 @@ volatile unsigned short *addr = (volatile unsigned short *)(info->port + offset); *addr = value; + wbflush(); } /* --- snip here --- I'm not shure if this really addresses your problem, but it might help anyway. --- Regards, Harald From triemer@apt4g.a3nyc.com Sat Oct 31 16:46:36 1998 Received: from apt4g.a3nyc.com (triemer@apt4g.a3nyc.com [166.84.184.179]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA12874; Sat, 31 Oct 1998 16:46:35 +0100 (MET) Received-Date: Sat, 31 Oct 1998 16:46:35 +0100 (MET) Received: from localhost (triemer@localhost) by apt4g.a3nyc.com (8.8.7/8.8.7) with SMTP id KAA20435 for ; Sat, 31 Oct 1998 10:46:43 -0500 Date: Sat, 31 Oct 1998 10:46:42 -0500 (EST) From: Thomas Riemer To: linux-mips@fnet.fr Subject: RE: More DZ Serial driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1885 Lines: 68 That may help... I've come up with an alternate hypothesis that seems to fit the facts better - I'm apparently not generating an interrupt on receiving characters. Why, I don't know... It looks like I've done everything according to the docs.... but apparently not. It even looks like I've done it in the same was as the guy who wrote the dc.c from freebsd. -Tom ----------------------------------------------------------------------- Given enough eyeballs all bugs seem shallow. On Sat, 31 Oct 1998, Harald Koerfgen wrote: > > On 30-Oct-98 Thomas Riemer wrote: > > I've worked through all the details of getting characters to > > be received on the DZ serial driver... > > > > I've also worked through the details of getting characters to > > transmit on the DZ serial driver line... > > > > But I can't get them both working at the same time. > > > [snip] > > > > None of these hypotheses really make much sense standing alone - and > > don't really explain what I'm seeing. Having pounded my head hard on > > this for about 2 weeks - I'm in need of some suggestions on how > > to approach the problem. > > Are you shure you are "flushing" the writeback buffer after writing to the DZ > registers? > > If not, you may want to try the following patchlet. > > --- snip here --- > > --- dz.c.orig Sat Oct 31 15:21:05 1998 > +++ dz.c Sat Oct 31 15:21:55 1998 > @@ -44,6 +44,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -77,6 +78,7 @@ > volatile unsigned short *addr = (volatile unsigned short *)(info->port + offset); > > *addr = value; > + wbflush(); > } > > /* > > --- snip here --- > > I'm not shure if this really addresses your problem, but it might help anyway. > > --- > Regards, > Harald >