From Hoyer@t-online.de Sun Feb 13 09:52:58 2000 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.de [194.25.134.82]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA20642; Sun, 13 Feb 2000 09:52:57 +0100 (MET) Received-Date: Sun, 13 Feb 2000 09:52:57 +0100 (MET) Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.de with smtp id 12JulV-00078T-00; Sun, 13 Feb 2000 09:52:25 +0100 Received: from oclasen (320000535988-0001@[212.184.140.196]) by fwd00.sul.t-online.de with smtp id 12JulK-1d1p3oC; Sun, 13 Feb 2000 09:52:14 +0100 Message-ID: <001501bf75ff$c9b11840$c48cb8d4@oclasen.rhein-zeitung.de> From: Hoyer@t-online.de (Peter Hoyer) To: Subject: MILO Date: Sun, 13 Feb 2000 09:53:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BF7608.252411C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Sender: 320000535988-0001@t-dialin.net This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BF7608.252411C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear sir or madam, I would like to install LINUX on my Siemens RM200 MIPS-PC. Therefore I = tried to download MILO, but I could not get access to the download path = (ftp://ftp.fnet.fr/linux-mips/src/boot) on your server. What I can I do in order to get MILO? Sincerely Yours Peter Hoyer ------=_NextPart_000_0012_01BF7608.252411C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear sir or = madam,

I would like to install = LINUX on my=20 Siemens RM200 MIPS-PC. Therefore I tried to download MILO, but I could = not get=20 access to the download path (ftp://ftp.fnet.fr/linux-m= ips/src/boot)=20 on your server.

What I can I do in = order to get=20 MILO?

Sincerely = Yours

Peter=20 Hoyer

------=_NextPart_000_0012_01BF7608.252411C0-- From R.vandenBerg@inter.NL.net Sun Feb 13 12:23:21 2000 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 MAA21293; Sun, 13 Feb 2000 12:23:20 +0100 (MET) Received-Date: Sun, 13 Feb 2000 12:23:20 +0100 (MET) Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-49.Hoorn.NL.net [193.79.46.213] with ESMTP id MAA01204 (8.8.8/3.41); Sun, 13 Feb 2000 12:23:19 +0100 (MET) Received: from whale(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Sun, 13 Feb 2000 12:20:19 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Sender: R.vandenBerg@inter.NL.net Message-ID: <38A69372.642CF3C9@inter.NL.net> Date: Sun, 13 Feb 2000 12:20:18 +0100 From: Richard van den Berg X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i486) MIME-Version: 1.0 To: Peter Hoyer CC: linux-mips@fnet.fr Subject: Re: MILO References: <001501bf75ff$c9b11840$c48cb8d4@oclasen.rhein-zeitung.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Hoyer wrote: > I would like to install LINUX on my Siemens RM200 MIPS-PC. Therefore I > tried to download MILO, but I could not get access to the download > path (ftp://ftp.fnet.fr/linux-mips/src/boot) on your server. > > What I can I do in order to get MILO? Go to a more up to date HOWTO at http://www.linux.sgi.com/mips/mips-howto.html which has points to sources. Regards, Richard From LD393847@wg.ns.onet.pl Mon Feb 14 05:57:52 2000 Received: from icsi.net (icsi.net [199.1.96.110]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA00326; Mon, 14 Feb 2000 05:57:41 +0100 (MET) Received-Date: Mon, 14 Feb 2000 05:57:41 +0100 (MET) Received: from warhol. ([199.1.96.120]) by icsi.net ; Sun, 13 Feb 2000 22:44:59 -0600 Received: from shinertx.com by warhol. (SMI-8.6/SMI-SVR4) id WAA29632; Sun, 13 Feb 2000 22:44:34 -0600 From: @wg.ns.onet.pl@icsi.net Date: Sun, 13 Feb 00 17:15:00 EST To: linux-mips@fnet.fr Subject: Save up to 75% on International Calling Message-ID: <1099702070015.GAB07055@wg.ns.onet.pl> Dear linux-mips@fnet.fr, Save Up To 75% on International Calling ...for residents inside AND outside the USA Here is a sample of our rates To/From the USA: Rates(US$) COUNTRY 0.14/min. Australia 0.23/min. Brazil - Sao Paolo 0.12/min. Canada 0.36/min. China 0.14/min. France 0.12/min. Germany 0.10/min. Hong Kong 0.78/min. India 0.14/min. Japan - Tokyo 0.14/min. New Zealand 0.35/min. Philippines 0.29/min. Russia - Moscow 0.17/min. S. Korea 0.12/min. UK - Rates apply 24 hrs/day, 7 days per week - NO sign-up fees, NO monthly fees, and NO surcharges - Billing is in 6 second increments - You DO NOT have to SWITCH your current provider - Ideal for Home and Business - For residents OUTSIDE the USA, we have INT'L CALLBACK Contact us for complete rate table Agents Wanted Worldwide: We are also looking for agents worldwide to market our services. Very attractive commissions! Contact us for more information and complete rate table at: jyedwards@bigfoot.com For service information, please type "info" in the subject line. For agent information, please type "agent" in the subject line. Please include your full name when requesting agent information. Thank You! From Geert.Uytterhoeven@sonycom.com Mon Feb 14 10:03:06 2000 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA01985; Mon, 14 Feb 2000 10:03:02 +0100 (MET) Received-Date: Mon, 14 Feb 2000 10:03:02 +0100 (MET) Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA20776; Mon, 14 Feb 2000 10:01:44 +0100 (MET) Date: Mon, 14 Feb 2000 10:01:44 +0100 (MET) From: Geert Uytterhoeven Sender: geert@sonycom.com To: Ralf Baechle cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes In-Reply-To: <20000203021018.A25786@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 3 Feb 2000, Ralf Baechle wrote: > Today I exchanged the R5000 CPU module in my Indy against a R4600 module > and found that on R4600SC the kernel runs reliable while it crashs pretty > soon after booting on a R5000SC module. This is consistent with the > reports that I've looked at. That could explain the crashes I see on the DDB Vrc-5074 as well, which has a NEC VR5000. I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From jobs@agnet.com.au Mon Feb 14 21:57:09 2000 Received: from mcnultycentral.McNultynet.co.uk (host-03-132.mcnultynet.co.uk [194.164.42.132]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA08809; Mon, 14 Feb 2000 21:57:03 +0100 (MET) Date: Mon, 14 Feb 2000 21:57:03 +0100 (MET) Received-Date: Mon, 14 Feb 2000 21:57:03 +0100 (MET) From: jobs@agnet.com.au Received: from ip5.margate.fl.pub-ip.psi.net by mcnultycentral.McNultynet.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1461.56) id 18NJZQKT; Mon, 14 Feb 2000 20:53:39 -0000 To: jobs@agnet.com.au Subject: HOT OPENINGS IN AUSTIN, TEXAS!!! ************************************* ************************************* HOT JOB OPENINGS IN AUSTIN, TEXAS ************************************* ************************************* Exciting opportunities have just opened up in Austin, Texas. If you are thinking of making a career change or know of anyone else who might be interested, please forward these excellent opportunities to them. _________________________________________________________ Web Developers are needed with strong knowledge of HTML, JAVAscript, Perl, CGI methodology, Unix, and Sun Solaris. Salaries up to $90,000 No contractors accepted on this position. ************************************* _________________________________________________________ Several JAVA Programmers also needed to develop & deploy a web-based integrated work flow management & sales tool for mid range products. Salaries up to $90,000. Contractors will be paid $48.00 per hour. ************************************* _________________________________________________________ Sr. JAVA Developer needed to work on fast growing web enabled private line networking products. Will work as part of a highly skilled team. JAVA plus solid development methodology, Enterprise JAVA Beans (EJB), and BEA's Web Logic EJB Server needed. Salaries up to $90,000 or $48.00 per hour. ************************************* _________________________________________________________ C++/JAVA Programmers needed to work on 8-10 member team within a Linux environment. Expert knowledge of Linux/Unix/AIX needed. Salaries up to $68,000. Contractors paid up to $38.00 per hour. ************************************* _________________________________________________________ AIX Support Delivery Technical Specialists needed. Shell scripting/programming in an AIX/UNIX environment (Perl or C) needed. _________________________________________________________ OS/2 Technical Support. Must be able to travel to client sites when needed. Must also have some OS/2 LAN Manager. Salaries up to $78,338. Contractors will be paid $45.00 per hour. ************************************* _________________________________________________________ Instructional Designer/Developer needed to design and help with course development. Will develop and coordinate training and develop course material on the company's products and sales. Any experience with JAVA, JAVA Beans will be a plus. This is a contractor postion only and will pay up to $30.00 per hour. ************************************* _________________________________________________________ Visual C++ Developers needed as part of a development team for a telecommunications company. Will perform all phases of the development life cycle. Must have Visual C++, MFC, Object Oriented Design and SQL. Salaries up to $50,000 or $26.00 per hour. ************************************* _________________________________________________________ Software Test Engineers needed to help design, develop, code and execute functional test plans. Salaries are open. _________________________________________________________ Disk Drive Engineer needed to provide world wide product engineering support for a variety of disk drivers on the RS/6000. Salary up to $50,000 or $30.00 per hour. ************************************* _________________________________________________________ Device Driver Developers needed to perform new development and technical Level 2.5/3.0 support of the AIX operating system. Salary up to $73,000 or $40.00 per hour. ************************************* _________________________________________________________ AIX Kernel Developers to perform support and serviceability using AIX, Virtual Memory Manager, Unix Configuration, Unix Security, Printer Device Drivers. Will pay up to $68,000 or $38.00 per hour. ************************************* AIX Performance Testers also needed. _________________________________________________________ SQL Server DBA's needed for three projects. Salaries up to $47,000 or $26.00 per hour. ************************************* _________________________________________________________ DB2 Database Manager needed to develop and manage a database for partner commerce/servers. Will be responsible for database backup and recovery procedures. Will access security and database integrity. Salary up to $93,596 or $51.00 per hour. ************************************* _________________________________________________________ ADABAS DBA needed for a short term contract. Must have ADASMP. Will pay top dollar to find the right person. ************************************* _________________________________________________________ QA Manager needed to Manage Test group. Salary up to $72,000 or $40.00 per hour. ************************************* _________________________________________________________ _________________________________________________________ For detailed information on these and other openings please CONTACT us at our toll free =============================== =============================== DP West Incorporated Professional Recruiting and Services 1-888-664-2388 or 623-374-0030 =============================== =============================== _________________________________________________________ _________________________________________________________ Note: This mail has been directed to computer professionals seeking employment. It is not intended to be spam mail. We have received your reference from fellow business partners. If you do not want to receive this mail in the future please let us know the e-mail ID this message was received at and any aliases and we will take you off our list. We appreciate your patience and regret the inconvenience. From kevink@mips.com Mon Feb 14 22:13:30 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA09402; Mon, 14 Feb 2000 22:13:29 +0100 (MET) Received-Date: Mon, 14 Feb 2000 22:13:29 +0100 (MET) Received: from newman.mips.com (newman [206.31.31.8]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA19215; Mon, 14 Feb 2000 13:13:13 -0800 (PST) Received: from satanas (satanas [192.168.236.12]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA23690; Mon, 14 Feb 2000 13:13:09 -0800 (PST) Message-ID: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> From: "Kevin D. Kissell" To: , "Ralf Baechle" Cc: , , Subject: Re: Indy crashes Date: Mon, 14 Feb 2000 22:15:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >On Thu, 3 Feb 2000, Ralf Baechle wrote: >> Today I exchanged the R5000 CPU module in my Indy against a R4600 module >> and found that on R4600SC the kernel runs reliable while it crashs pretty >> soon after booting on a R5000SC module. This is consistent with the >> reports that I've looked at. > >That could explain the crashes I see on the DDB Vrc-5074 as well, which has a >NEC VR5000. > >I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38. The problem may be in the assumption made even in the most recent 2.3.x code that a hit-writeback-invalidate cache operation on the secondary cache automagically affects the primary. That's the way it is on the R4000/4400, but that's not the way the R5000 is specified. So rather than set dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc or r4k_dma_cache_wback_inv_pc, depending on the presence or absence of a primary cache, in the MIPS Technologies I bound it to a function: static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size) { r4k_dma_cache_wback_inv_pc(addr, size); if(sc_present) r4k_dma_cache_wback_inv_sc(addr, size); } However, I have not had the opportunity to test this code on an R5000SC platform. Looking at the R5000 spec, it is a little ambiguous. The special case of sc HWIs affecting the primary isn't there, but then again sc HWIs aren't even called out in the table of defined cache operations. Indeed, one *could* interpret the spec to mean that HWI on the *primary* flushes the secondary, the reverse of the R4000, but it's by no means clear. Thus I suggest hitting 'em both. Does anybody on this list have an R527x manual? How is HWI of the primary/seconday caches defined there? Regards, Kevin K. From wje@liveoak.engr.sgi.com Mon Feb 14 22:57:39 2000 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 WAA09666; Mon, 14 Feb 2000 22:57:38 +0100 (MET) Received-Date: Mon, 14 Feb 2000 22:57:38 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA09088; Mon, 14 Feb 2000 13:53:03 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA11954; Mon, 14 Feb 2000 13:57:29 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id NAA26704; Mon, 14 Feb 2000 13:57:23 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14504.31299.82555.477086@liveoak.engr.sgi.com> Date: Mon, 14 Feb 2000 13:57:23 -0800 (PST) To: "Kevin D. Kissell" Cc: , "Ralf Baechle" , , , Subject: Re: Indy crashes In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> X-Mailer: VM 6.74 under Emacs 20.3.1 Kevin D. Kissell writes: ... > However, I have not had the opportunity to test this code on > an R5000SC platform. Looking at the R5000 spec, it is a > little ambiguous. The special case of sc HWIs affecting > the primary isn't there, but then again sc HWIs aren't even > called out in the table of defined cache operations. Indeed, > one *could* interpret the spec to mean that HWI on the > *primary* flushes the secondary, the reverse of the R4000, > but it's by no means clear. Thus I suggest hitting 'em both. > > Does anybody on this list have an R527x manual? How > is HWI of the primary/seconday caches defined there? I am very familiar with how the R5000 and similar processors works. The secondary cache is essentially independent of the primary caches, and is write-through. It hangs on the SysAD bus and captures cache lines being read, and returns a captured cache line on a later read. You must separately invalidate the primary and secondary caches. If you care about instruction cache coherency (as when reading in executable pages), you have to invalidate the primary instruction cache, not just the primary data cache. Since the secondary cache is write-through, you need only invalidate it on reads; you can ignore it on writes. From ralf@oss.sgi.com Tue Feb 15 00:12:52 2000 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 AAA10626; Tue, 15 Feb 2000 00:12:51 +0100 (MET) Received-Date: Tue, 15 Feb 2000 00:12:51 +0100 (MET) Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA23489; Tue, 15 Feb 2000 00:12:43 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Mon, 14 Feb 2000 18:13:46 +0100 Date: Mon, 14 Feb 2000 18:13:46 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Ralf Baechle , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000214181346.I30488@uni-koblenz.de> References: <20000203021018.A25786@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr On Mon, Feb 14, 2000 at 10:01:44AM +0100, Geert Uytterhoeven wrote: > On Thu, 3 Feb 2000, Ralf Baechle wrote: > > Today I exchanged the R5000 CPU module in my Indy against a R4600 module > > and found that on R4600SC the kernel runs reliable while it crashs pretty > > soon after booting on a R5000SC module. This is consistent with the > > reports that I've looked at. > > That could explain the crashes I see on the DDB Vrc-5074 as well, which has a > NEC VR5000. > > I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38. I made a silly mistake during my tests and will have to retry. Ralf From dom@algor.co.uk Tue Feb 15 00:45:39 2000 Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [193.117.190.25]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA11757; Tue, 15 Feb 2000 00:45:38 +0100 (MET) Received-Date: Tue, 15 Feb 2000 00:45:38 +0100 (MET) Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [193.117.190.129]) by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id XAA05734; Mon, 14 Feb 2000 23:45:04 GMT Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.8.5/8.8.5) id XAA00626; Mon, 14 Feb 2000 23:45:06 GMT Date: Mon, 14 Feb 2000 23:45:06 GMT Message-Id: <200002142345.XAA00626@gladsmuir.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "William J. Earl" Cc: "Kevin D. Kissell" , , "Ralf Baechle" , , , Subject: Re: Indy crashes In-Reply-To: <14504.31299.82555.477086@liveoak.engr.sgi.com> References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> <14504.31299.82555.477086@liveoak.engr.sgi.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid William J. Earl (wje@cthulhu.engr.sgi.com) .... is of course right. > The secondary cache is essentially independent of the primary > caches, and is write-through. The R5000 and QED RM527x share this kind of secondary cache. It's becoming obsolete - partly because it's not very efficient, and partly because it depends on some special tag RAMs which nobody makes any more. [But it does work quite well in internet routers where a big secondary can hold large chunks of routing table...] QED's RM7000 has an internal secondary cache which is more like (but not compatible with) an R4000. As part of our Linux familiarisation we'll try to get that working. It's 4-way set associative, 256Kbytes big, unified and write-back; so that should shake out some more bugs. MIPS started off with the (fairly sound) argument that software should manage the caches because software-invisible snoopy caches (x86-style) cost a lot of hardware complication but don't buy any performance. The argument is based on the observation (correct, then as now) that the cache is so busy that snooping invariably makes the CPU wait. I used to be an advocate of the MIPS position; but what this argument ignores is the difficulty of maintaining a portable software base, particulary an OS which (like Linux) has grown up with invisible x86 caches. To make sure that Linux/MIPS kernels are and remain robust we have to convince lots of people to take the trouble to learn about visible caches - even though the systems they're working on don't have them. And we have to hope that driver writers will do the right thing, even though they've never used a system which needs cache management code and have none at hand to test their drivers with... This would be unlikely even if we all agreed what the word 'flush' meant (does it mean "invalidate"? or "write-back"? or perhaps "both, if necessary"? and can you build a robust OS without knowing the answer?) It *could* happen. MIPS are not the only family of CPUs with visible caches - though I think they probably have by far the most complicated ones, because of their high-end history. The meeting of Linux and MIPS is in this respect really good for Linux - great at finding portability problems. But it's not particularly good for MIPS. For now, Linux/MIPS kernels will only be reliable if maintained by people who understand this stuff, keep a safe distance from the x86 mainstream, and use only sanity-checked drivers. Kevin, I think you'd better tell your colleagues who design the chips that they'd better put some snooping in, and soon... Dominic Sweetman Algorithmics Ltd From ralf@oss.sgi.com Tue Feb 15 01:17:20 2000 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 BAA11957; Tue, 15 Feb 2000 01:17:19 +0100 (MET) Received-Date: Tue, 15 Feb 2000 01:17:19 +0100 (MET) Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA29181; Tue, 15 Feb 2000 01:17:10 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Tue, 15 Feb 2000 01:13:46 +0100 Date: Tue, 15 Feb 2000 01:13:46 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: geert@linux-m68k.org, Ralf Baechle , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000215011346.D828@uni-koblenz.de> References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> X-Accept-Language: de,en,fr On Mon, Feb 14, 2000 at 10:15:02PM +0100, Kevin D. Kissell wrote: > The problem may be in the assumption made even in the > most recent 2.3.x code that a hit-writeback-invalidate cache > operation on the secondary cache automagically affects the > primary. That's the way it is on the R4000/4400, but that's Yep. > not the way the R5000 is specified. So rather than set > dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc > or r4k_dma_cache_wback_inv_pc, depending on the > presence or absence of a primary cache, in the MIPS > Technologies I bound it to a function: I don't even pretend that Linux is running on a R5000 with L2 except on Indy R5000SC's. These R5000 modules are different in that they don't use the L2 support which is part of the processor but rather use the same external cache implementation as the R4600SC CPU modules do. Ralf From ralf@oss.sgi.com Tue Feb 15 01:38:22 2000 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 BAA12148; Tue, 15 Feb 2000 01:38:22 +0100 (MET) Received-Date: Tue, 15 Feb 2000 01:38:22 +0100 (MET) Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA00820; Tue, 15 Feb 2000 01:38:12 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Tue, 15 Feb 2000 01:37:39 +0100 Date: Tue, 15 Feb 2000 01:37:39 +0100 From: Ralf Baechle To: Dominic Sweetman Cc: "William J. Earl" , "Kevin D. Kissell" , geert@linux-m68k.org, Ralf Baechle , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000215013739.E828@uni-koblenz.de> References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> <14504.31299.82555.477086@liveoak.engr.sgi.com> <200002142345.XAA00626@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002142345.XAA00626@gladsmuir.algor.co.uk> X-Accept-Language: de,en,fr On Mon, Feb 14, 2000 at 11:45:06PM +0000, Dominic Sweetman wrote: > QED's RM7000 has an internal secondary cache which is more like (but > not compatible with) an R4000. As part of our Linux familiarisation > we'll try to get that working. It's 4-way set associative, 256Kbytes > big, unified and write-back; so that should shake out some more bugs. [...] > I used to be an advocate of the MIPS position; but what this argument > ignores is the difficulty of maintaining a portable software base, > particulary an OS which (like Linux) has grown up with invisible x86 > caches. > > To make sure that Linux/MIPS kernels are and remain robust we have to > convince lots of people to take the trouble to learn about visible > caches - even though the systems they're working on don't have them. > And we have to hope that driver writers will do the right thing, even > though they've never used a system which needs cache management code > and have none at hand to test their drivers with... > > This would be unlikely even if we all agreed what the word 'flush' > meant (does it mean "invalidate"? or "write-back"? or perhaps "both, > if necessary"? and can you build a robust OS without knowing the > answer?) Yes. > It *could* happen. MIPS are not the only family of CPUs with visible > caches - though I think they probably have by far the most complicated > ones, because of their high-end history. Sparc. > The meeting of Linux and MIPS is in this respect really good for Linux > - great at finding portability problems. But it's not particularly > good for MIPS. For now, Linux/MIPS kernels will only be reliable if > maintained by people who understand this stuff, keep a safe distance > from the x86 mainstream, and use only sanity-checked drivers. No longer. With Linux 2.3.41 Linux received a number of new software interfaces which also could easily be backported to previous kernels. As the side effect you even get scatter gather capabilities for every driver. Btw, please take a look at the new interfaces, they're documented in Documentation/DMA-mapping.txt. They're not yet cast into stone, so if anybody has something to complain about these interfaces, better do it soon. > Kevin, I think you'd better tell your colleagues who design the chips > that they'd better put some snooping in, and soon... For I/O isn't not that bad to handle except a few cases like the NCR 53c8xx driver. And there is always the silver bullet solution of using uncached accesses. Things like mmap() and read/write right in the presence of virtual indexed caches are the real vomit bag. Linus & Co. so far refuse to accept any of the optimal solutions. And while I'd of course would like to such a solution to get into the kernel I can well understand Linus' refusal. >From that point of view the RM7000 is the first MIPS CPU that got caches right since the R6000 ... Ralf From express34@bigfoot.com Tue Feb 15 04:41:03 2000 Received: from prokom.rzeszow.medianet.pl (prokom.rzeszow.medianet.pl [195.116.187.3]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA16549; Tue, 15 Feb 2000 04:41:02 +0100 (MET) Received-Date: Tue, 15 Feb 2000 04:41:02 +0100 (MET) From: express34@bigfoot.com Received: from 195.116.187.3 (05-057.020.popsite.net [216.4.120.57]) by prokom.rzeszow.medianet.pl (8.8.8/8.8.5) with SMTP id EAA14876; Tue, 15 Feb 2000 04:41:35 +0100 (CET) Date: Mon, 14 Feb 00 22:12:48 EST To: Friend@public.com Subject: $$$International Reps Needed$$$ Message-ID: <> Reply-To: 103636.2203@compuserve.com We are accepting applications for sophisticated International Reps in your country. No experience is necessary because we will train the right person. This opportunity is not for everyone. The pay is based on commission with unlimited income potential! We are an on-line auction site for high-ticket items in the aviation, oil & gas, shipping and real estate, resort properties, and other items. The right business associate will be working with prospective clients in your local country. For further information: Visit our web site: http://home.earthlink.net/~hal945/ Fax: 1-918-582-6203 Email: 103636.2203@compuserve.com Additional E-mail Reception: hal@tradedays.org From Geert.Uytterhoeven@sonycom.com Tue Feb 15 10:33:02 2000 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA25381; Tue, 15 Feb 2000 10:32:57 +0100 (MET) Received-Date: Tue, 15 Feb 2000 10:32:57 +0100 (MET) Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA12980; Tue, 15 Feb 2000 10:30:52 +0100 (MET) Date: Tue, 15 Feb 2000 10:30:52 +0100 (MET) From: Geert Uytterhoeven Sender: geert@sonycom.com To: "Kevin D. Kissell" cc: Ralf Baechle , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 14 Feb 2000, Kevin D. Kissell wrote: > >On Thu, 3 Feb 2000, Ralf Baechle wrote: > >> Today I exchanged the R5000 CPU module in my Indy against a R4600 module > >> and found that on R4600SC the kernel runs reliable while it crashs pretty > >> soon after booting on a R5000SC module. This is consistent with the > >> reports that I've looked at. > > > >That could explain the crashes I see on the DDB Vrc-5074 as well, which has a > >NEC VR5000. > > > >I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38. > > The problem may be in the assumption made even in the > most recent 2.3.x code that a hit-writeback-invalidate cache > operation on the secondary cache automagically affects the > primary. That's the way it is on the R4000/4400, but that's In that case it doesn't affect the NEC DDB Vrc-5074, since there's no L2. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From raiko@niisi.msk.ru Tue Feb 15 13:59:04 2000 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 NAA26493; Tue, 15 Feb 2000 13:58:26 +0100 (MET) Received-Date: Tue, 15 Feb 2000 13:58:26 +0100 (MET) 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 PAA00565 for ; Tue, 15 Feb 2000 15:58:36 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id QAA12471 for linux-mips@fnet.fr; Tue, 15 Feb 2000 16:06:56 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA13754 for ; Tue, 15 Feb 2000 12:27:02 +0300 (MSK) Message-ID: <38A91E19.CE7A9890@niisi.msk.ru> Date: Tue, 15 Feb 2000 12:36:26 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: -fno-strict-aliasing problem in the latest 2.3 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hello, There is a problem with the way main Makefile determines whether the compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC and tries to feed this option to it. Unfortunately, we set CC to proper mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile just checks against native gcc. On RH6.1 with latest cross tool rpms installed, I get cc1: Invalid option `-fno-strict-aliasing' during comppilation, obviously. I can't offer an elegenat solution to resolve this problem. Basically, I see three choices: 1. Move logic that sets CC from arch/mips/Makefile to the main Makefile (Nightmare for Ralf who have to either feed it to Linus or add this logic in the main Makefile every merge, I think.) 2. Filter CFLAGS to remove -fno-strict-aliasing in arch/mips/Makefile (Nasty.) 3. Fix the mips compiler :-) (Looks good for me despite the fact I don't understand exctly how much work it costs, but can imagine...) Any ideas ? Regards, Gleb. From rabeeh@galileo.co.il Tue Feb 15 16:17:15 2000 Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA28598; Tue, 15 Feb 2000 16:17:11 +0100 (MET) Received-Date: Tue, 15 Feb 2000 16:17:11 +0100 (MET) Received: from galileo.co.il ([10.2.20.126]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id RAA08312 for ; Tue, 15 Feb 2000 17:17:20 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <38A9D0CB.FF958043@galileo.co.il> Date: Tue, 15 Feb 2000 17:18:51 -0500 From: Rabeeh Khoury X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: boot memory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm having trouble with my embedded system initializing the ram ; I do the following for initializations in kernel_entry - { mips_machgroup = MACH_GROUP_GALILEO; mips_memory_upper = 0x81000000; // not needed any more galileo_mem_init(); } void __init galileo_mem_init(void) { unsigned long bootmap_size; max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the embedded bootmap_size = init_bootmem(0, max_low_pfn); free_bootmem (0 , 0x01000000); reserve_bootmem(0, 0x01000000); } but the kernel is stuck in the alloc_bootmem_node which is called from free_area_init_core . do you know what is the problem ? am I doing right memory initializations for embedded board with 16 MByte ? ((start addr 0x80000000 - end addr 0x81000000) p.s. I'm running in 32 bit MIPS - QED 5271 thank you From R.vandenBerg@inter.NL.net Tue Feb 15 16:47:21 2000 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 QAA28797; Tue, 15 Feb 2000 16:47:15 +0100 (MET) Received-Date: Tue, 15 Feb 2000 16:47:15 +0100 (MET) Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-30.Hoorn.NL.net [193.79.46.194] with ESMTP for id QAA15964 (8.8.8/3.41); Tue, 15 Feb 2000 16:47:13 +0100 (MET) Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Tue, 15 Feb 2000 16:46:21 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Tue, 15 Feb 2000 16:46:20 +0100 (MET) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: 2.3.38 on DECstation (was Re: CVS Update@oss.sgi.com: linux) In-Reply-To: <20000213205210Z305156-11638+65@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 13 Feb 2000, Harald Koerfgen wrote: > Log message: > o bootmem fixes for DECstations > o declarations in pgtable.h fixed > o cache management for R3000 improved [ravdberg@dolce ravdberg]$ uname -a Linux dolce 2.3.38 #5 Mon Feb 14 19:13:31 CET 2000 mips unknown [ravdberg@dolce ravdberg]$ cat /proc/cpuinfo cpu : MIPS cpu model : R3000A V3.0 system type : Digital Personal DECstation 5000/xx BogoMIPS : 24.84 byteorder : little endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : no hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available Thank you Harald! Regards, Richard From Harald.Koerfgen@home.ivm.de Tue Feb 15 18:14:05 2000 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA29336; Tue, 15 Feb 2000 18:14:05 +0100 (MET) Received-Date: Tue, 15 Feb 2000 18:14:05 +0100 (MET) Received: from franz.no.dom (port44.duesseldorf.ivm.de [195.247.65.44]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id SAA26487; Tue, 15 Feb 2000 18:13:55 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.3 [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: Tue, 15 Feb 2000 18:14:36 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Richard van den Berg Subject: RE: 2.3.38 on DECstation (was Re: CVS Update@oss.sgi.com: linux) Cc: linux-mips@fnet.fr On 15-Feb-00 Richard van den Berg wrote: > On Sun, 13 Feb 2000, Harald Koerfgen wrote: > >> Log message: >> o bootmem fixes for DECstations >> o declarations in pgtable.h fixed >> o cache management for R3000 improved > > [ravdberg@dolce ravdberg]$ uname -a > Linux dolce 2.3.38 #5 Mon Feb 14 19:13:31 CET 2000 mips unknown > [ravdberg@dolce ravdberg]$ cat /proc/cpuinfo > cpu : MIPS > cpu model : R3000A V3.0 > system type : Digital Personal DECstation 5000/xx > BogoMIPS : 24.84 > byteorder : little endian > unaligned accesses : 0 > wait instruction : no > microsecond timers : no > extra interrupt vector : no > hardware watchpoint : no > VCED exceptions : not available > VCEI exceptions : not available Never mind, but, beware, swapping is broken for 2.3.38 with R3000. While talking about the subject, I've put some assumptions into the optimisation which seem to be valid for R3000As, but I am not exactly shure if they are true for other R2000/R3000 variants. Thus, I'd like to have some feedback from other boxes, for example DS2100/3100 or Bagets. --- Regards, Harald From wje@liveoak.engr.sgi.com Tue Feb 15 18:49:39 2000 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 SAA00524; Tue, 15 Feb 2000 18:49:37 +0100 (MET) Received-Date: Tue, 15 Feb 2000 18:49:37 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04597; Tue, 15 Feb 2000 09:45:02 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA36528; Tue, 15 Feb 2000 09:49:26 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id JAA11519; Tue, 15 Feb 2000 09:49:19 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14505.37279.164044.582169@liveoak.engr.sgi.com> Date: Tue, 15 Feb 2000 09:49:19 -0800 (PST) To: Ralf Baechle Cc: "Kevin D. Kissell" , geert@linux-m68k.org, linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes In-Reply-To: <20000215011346.D828@uni-koblenz.de> References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> <20000215011346.D828@uni-koblenz.de> X-Mailer: VM 6.74 under Emacs 20.3.1 Ralf Baechle writes: > On Mon, Feb 14, 2000 at 10:15:02PM +0100, Kevin D. Kissell wrote: ... > > not the way the R5000 is specified. So rather than set > > dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc > > or r4k_dma_cache_wback_inv_pc, depending on the > > presence or absence of a primary cache, in the MIPS > > Technologies I bound it to a function: > > I don't even pretend that Linux is running on a R5000 with L2 except on > Indy R5000SC's. These R5000 modules are different in that they don't use > the L2 support which is part of the processor but rather use the same > external cache implementation as the R4600SC CPU modules do. ... If someone wants to do the real R5000SC (and RM5271 and RM7000) cache routines, for some other platform, I can supply the required details. From kevink@mips.com Tue Feb 15 23:22:07 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA14596; Tue, 15 Feb 2000 23:22:06 +0100 (MET) Received-Date: Tue, 15 Feb 2000 23:22:06 +0100 (MET) Received: from newman.mips.com (newman [206.31.31.8]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA17249; Tue, 15 Feb 2000 14:21:55 -0800 (PST) Received: from satanas (satanas [192.168.236.12]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA03662; Tue, 15 Feb 2000 14:21:53 -0800 (PST) Message-ID: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> From: "Kevin D. Kissell" To: "Geert Uytterhoeven" Cc: "Ralf Baechle" , , , Subject: Re: Indy crashes Date: Tue, 15 Feb 2000 23:23:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >> The problem may be in the assumption made even in the >> most recent 2.3.x code that a hit-writeback-invalidate cache >> operation on the secondary cache automagically affects the >> primary. That's the way it is on the R4000/4400, but that's > >In that case it doesn't affect the NEC DDB Vrc-5074, since there's no L2. If it isn't the cache, and it tracks the CPU type, the next thing I suspect is a pipe hazard. The R5000 manual states that there should be "at least two integer instructions between" any instruction modifying the PageMask, EntryHi, or EntryLo[01] registers and the subsequent tlbw[ir] or tlbp. That's different from the R4000. In the current Linux arch/mips/head.S file, this interval does not seem to be respected by any of the TLB miss handlers. Indeed, the default except_vec0_r4000 handler, which I believe is what is used if an R5000 is detected, has the sequence mtc0 k1, CP0_ENTRYLO1 # load it b 1f tlbwr # write random tlb entry 1: nop eret wherin the purpose of the branch is obscure (I imagine it fixed a bug seen somewhere on some CPU but it makes me rather queasy) but wherein in any case we do not seem to be assured 2 issues between the mtc0 and the tlbwr. It should be OK for an R4000, but not for an R5000. So someone with the ability to reproduce the R5000 problem should really try sticking a nop between the mtc0 and the branch (sigh) to see if that stabilizes the system. Regards, Kevin K. __ Kevin D. Kissell MIPS Technologies European Architecture Lab kevink@mips.com Tel. +33.4.78.38.70.67 FAX. +33.4.78.38.70.68 From ralf@oss.sgi.com Wed Feb 16 01:16:12 2000 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 BAA16262; Wed, 16 Feb 2000 01:16:12 +0100 (MET) Received-Date: Wed, 16 Feb 2000 01:16:12 +0100 (MET) Received: from cacc-22.uni-koblenz.de (cacc-22.uni-koblenz.de [141.26.131.22]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA02764; Wed, 16 Feb 2000 01:15:59 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 01:13:37 +0100 Date: Wed, 16 Feb 2000 01:13:37 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Geert Uytterhoeven , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000216011337.C4633@uni-koblenz.de> References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> X-Accept-Language: de,en,fr On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote: > If it isn't the cache, and it tracks the CPU type, the next thing > I suspect is a pipe hazard. The R5000 manual states that there > should be "at least two integer instructions between" any > instruction modifying the PageMask, EntryHi, or EntryLo[01] > registers and the subsequent tlbw[ir] or tlbp. That's different > from the R4000. In the current Linux arch/mips/head.S file, > this interval does not seem to be respected by any of the TLB > miss handlers. Indeed, the default except_vec0_r4000 handler, > which I believe is what is used if an R5000 is detected, has > the sequence > > mtc0 k1, CP0_ENTRYLO1 # load it > b 1f > tlbwr # write random tlb entry > 1: > nop > eret > > wherin the purpose of the branch is obscure (I imagine > it fixed a bug seen somewhere on some CPU but it > makes me rather queasy) but wherein in any case we > do not seem to be assured 2 issues between the mtc0 > and the tlbwr. It should be OK for an R4000, but not for > an R5000. No, it's not a bug workaround. The reason for this branch is that the R4000 and R4400 have a penalty of three cycles for a taken branch. So the branch above is equivalent with mtc0 k1, CP0_ENTRYLO1 nop tlbwr nop nop nop eret Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand but as I understood them the above code should also work just perfect for them. > So someone with the ability to reproduce the R5000 > problem should really try sticking a nop between the > mtc0 and the branch (sigh) to see if that stabilizes > the system. Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty workaround. I think I only put the workaround into the Cobalt kernel. Of course IDT doesn't admit that this bug even exists ... Ralf From wje@liveoak.engr.sgi.com Wed Feb 16 02:17:05 2000 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16651; Wed, 16 Feb 2000 02:17:04 +0100 (MET) Received-Date: Wed, 16 Feb 2000 02:17:04 +0100 (MET) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA00515; Tue, 15 Feb 2000 17:19:47 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA33395; Tue, 15 Feb 2000 17:16:52 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA09994; Tue, 15 Feb 2000 17:16:46 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14505.64125.564813.333784@liveoak.engr.sgi.com> Date: Tue, 15 Feb 2000 17:16:45 -0800 (PST) To: Ralf Baechle Cc: "Kevin D. Kissell" , Geert Uytterhoeven , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes In-Reply-To: <20000216011337.C4633@uni-koblenz.de> References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> <20000216011337.C4633@uni-koblenz.de> X-Mailer: VM 6.74 under Emacs 20.3.1 Ralf Baechle writes: > On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote: ... > > mtc0 k1, CP0_ENTRYLO1 # load it > > b 1f > > tlbwr # write random tlb entry > > 1: > > nop > > eret ... > Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand > but as I understood them the above code should also work just perfect > for them. There is a need for a workaround on the R5000 for a "bad $badvaddr" problem. The except_vec0_r45k_bvahwbug() variation does not appear to be enabled for the R5000. (It should not be needed for the RM7000 or the RM5271.) From ralf@oss.sgi.com Wed Feb 16 02:24:13 2000 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 CAA16714; Wed, 16 Feb 2000 02:24:13 +0100 (MET) Received-Date: Wed, 16 Feb 2000 02:24:13 +0100 (MET) Received: from cacc-22.uni-koblenz.de (cacc-22.uni-koblenz.de [141.26.131.22]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA06438; Wed, 16 Feb 2000 02:24:04 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 02:23:34 +0100 Date: Wed, 16 Feb 2000 02:23:34 +0100 From: Ralf Baechle To: "William J. Earl" Cc: Ralf Baechle , "Kevin D. Kissell" , Geert Uytterhoeven , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000216022334.A1070@uni-koblenz.de> References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> <20000216011337.C4633@uni-koblenz.de> <14505.64125.564813.333784@liveoak.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <14505.64125.564813.333784@liveoak.engr.sgi.com> X-Accept-Language: de,en,fr On Tue, Feb 15, 2000 at 05:16:45PM -0800, William J. Earl wrote: > Ralf Baechle writes: > > On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote: > ... > > > mtc0 k1, CP0_ENTRYLO1 # load it > > > b 1f > > > tlbwr # write random tlb entry > > > 1: > > > nop > > > eret > ... > > Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand > > but as I understood them the above code should also work just perfect > > for them. > > There is a need for a workaround on the R5000 for a "bad $badvaddr" > problem. The except_vec0_r45k_bvahwbug() variation does not appear to be > enabled for the R5000. (It should not be needed for the RM7000 or the RM5271.) I don't have this bug in my erratas documented, can you elaborate on it? Ralf From wje@liveoak.engr.sgi.com Wed Feb 16 02:46:33 2000 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16836; Wed, 16 Feb 2000 02:46:32 +0100 (MET) Received-Date: Wed, 16 Feb 2000 02:46:32 +0100 (MET) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA02385; Tue, 15 Feb 2000 17:49:21 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA08518; Tue, 15 Feb 2000 17:46:26 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA11942; Tue, 15 Feb 2000 17:46:20 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14506.350.713324.113307@liveoak.engr.sgi.com> Date: Tue, 15 Feb 2000 17:46:06 -0800 (PST) To: Ralf Baechle Cc: "Kevin D. Kissell" , Geert Uytterhoeven , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes In-Reply-To: <20000216022334.A1070@uni-koblenz.de> References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> <20000216011337.C4633@uni-koblenz.de> <14505.64125.564813.333784@liveoak.engr.sgi.com> <20000216022334.A1070@uni-koblenz.de> X-Mailer: VM 6.74 under Emacs 20.3.1 Ralf Baechle writes: > On Tue, Feb 15, 2000 at 05:16:45PM -0800, William J. Earl wrote: ... > > There is a need for a workaround on the R5000 for a "bad $badvaddr" > > problem. The except_vec0_r45k_bvahwbug() variation does not appear to be > > enabled for the R5000. (It should not be needed for the RM7000 or the RM5271.) > > I don't have this bug in my erratas documented, can you elaborate on it? Sometimes you get a utlbmiss exception when there is already matching TLB entry. If you then blindly drop in the TLB entry, you get a duplicate, which leads to Bad Things (tm). The workaround is to probe for a duplicate, and skip the tlbwr if an entry already exists. It should be enabled on any real R5000. This is from the R5000 Errata list of 30 October 1997: ---------------------------------------------------------------------- 3. An erroneous JTLB miss exception will be taken under these conditions. a) An instruction which does not cause an exception or stall is 8 bytes away from the end of a page. b) A load or store instruction is the last instruction of that page. c) The load/store target address has a matching but invalid JTLB entry d) The next sequential page is not mapped in the JTLB In this situation, when the load/store instruction is executed, a JTLB invalid exception should be taken, instead a JTLB miss exception is incorrectly taken. If the exception handler does a random TLB write to resolve the exception, this will in general insert a duplicate TLB entry for each erroneous exception. If the first instruction is a jump or branch, this will cause an infinite loop of JTLB miss exceptions to occur upon the return from the exception handler. Otherwise, there will be only one erroneous exception, followed by a correct exception, leaving one duplicate entry in the TLB. A software fix is for the JTLB miss handler to detect this situation, by probing for a matching TLB entry (treating a hit as being this case), ignore the JTLB miss and treat the exception as an JTLB invalid exception. Errata 3 is fixed in Rev 2.0. ---------------------------------------------------------------------- It is not clear to me that Errata 3 is fixed in all cases in Rev 2.*, so IRIX has the workaround enabled for all R5000 revisions. In Linux, just use except_vec0_r45k_bvahwbug() for any R5000. From agx@gandalf.physik.uni-konstanz.de Wed Feb 16 10:07:34 2000 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.30]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA21302; Wed, 16 Feb 2000 10:07:33 +0100 (MET) Received-Date: Wed, 16 Feb 2000 10:07:33 +0100 (MET) Received: from gimli.physik.uni-konstanz.de [134.34.144.35] by gandalf.physik.uni-konstanz.de with esmtp (Exim 2.05 #1 (Debian)) id 12L0Qm-0001eq-00; Wed, 16 Feb 2000 10:07:32 +0100 Received: from agx by gimli.physik.uni-konstanz.de with local (Exim 2.05 #1 (Debian)) id 12L0Ql-0000Jw-00; Wed, 16 Feb 2000 10:07:31 +0100 Date: Wed, 16 Feb 2000 10:07:31 +0100 From: Guido Guenther To: linux-mips@fnet.fr Subject: Indy: reboot after HardHat installation fails Message-ID: <20000216100731.A1220@gimli.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Sender: Guido Guenther Hi, after installing HardHat on an R4600 Indy I'm unable to boot with: bootp()nfsserver:/vmlinux root=/dev/sdb1 I get a "unable to open console". The mailing list archives say that I have to get the device numbers in /dev right. This seems reasonable since the installation of the dev-rpm (along with many others) died with a "unable to execute script". Unfortunately I can't use "upgrade" in the hardhat installation programm to mount /dev/sdb1 (as suggested in the mailing list archives) since it always dies with "signal 11". Any chance to mount /dev/sdb1 to fix the device numbers? Regards, -- Guido -- PGP-Public Key: http://honk.physik.uni-konstanz.de/~guido/gunther.asc GPG-Public Key: http://honk.physik.uni-konstanz.de/~agx/guenther.gpg.asc From raiko@niisi.msk.ru Wed Feb 16 10:32:38 2000 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 KAA21467; Wed, 16 Feb 2000 10:32:34 +0100 (MET) Received-Date: Wed, 16 Feb 2000 10:32:34 +0100 (MET) 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 MAA08481 for ; Wed, 16 Feb 2000 12:33:11 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA28577 for linux-mips@fnet.fr; Wed, 16 Feb 2000 12:37:17 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA10656 for ; Wed, 16 Feb 2000 12:27:05 +0300 (MSK) Message-ID: <38AA6F91.3DF9825C@niisi.msk.ru> Date: Wed, 16 Feb 2000 12:36:17 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 CC: "linux-mips@fnet.fr" Subject: Re: boot memory References: <38A9D0CB.FF958043@galileo.co.il> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Rabeeh Khoury wrote: > I'm having trouble with my embedded system initializing the ram ; I do > the following for initializations in kernel_entry - > > void __init galileo_mem_init(void) > { > unsigned long bootmap_size; > > max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the > embedded > bootmap_size = init_bootmem(0, max_low_pfn); > free_bootmem (0 , 0x01000000); > reserve_bootmem(0, 0x01000000); > } > > but the kernel is stuck in the alloc_bootmem_node which is called from > free_area_init_core . > > do you know what is the problem ? > am I doing right memory initializations for embedded board with 16 MByte > ? ((start addr 0x80000000 - end addr 0x81000000) > Bootmem allocator needs __free__ memory. By specifing start pfn as 0 you just poison exception handlers. Basically, you need to specify next pfn __after__ the end of the kernel data as staring pfn, something like UP(&end), look at i386 for example. The bootmem allocator stores its bitmap at start pfn. Regards, Gleb. From kevink@mips.com Wed Feb 16 11:40:43 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA21788; Wed, 16 Feb 2000 11:40:42 +0100 (MET) Received-Date: Wed, 16 Feb 2000 11:40:42 +0100 (MET) Received: from newman.mips.com (newman [206.31.31.8]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA00085; Wed, 16 Feb 2000 02:40:38 -0800 (PST) Received: from satanas (satanas [192.168.236.12]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA22938; Wed, 16 Feb 2000 02:40:31 -0800 (PST) Message-ID: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "Geert Uytterhoeven" , , , Subject: Re: Indy crashes Date: Wed, 16 Feb 2000 11:42:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Ralf Baechle writes: >On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote: >> The R5000 manual states that there >> should be "at least two integer instructions between" any >> instruction modifying the PageMask, EntryHi, or EntryLo[01] >> registers and the subsequent tlbw[ir] or tlbp. That's different >> from the R4000. In the current Linux arch/mips/head.S file, >> this interval does not seem to be respected by any of the TLB >> miss handlers. Indeed, the default except_vec0_r4000 handler, >> which I believe is what is used if an R5000 is detected, has >> the sequence >> >> mtc0 k1, CP0_ENTRYLO1 # load it >> b 1f >> tlbwr # write random tlb entry >> 1: >> nop >> eret >> >> wherin the purpose of the branch is obscure (I imagine >> it fixed a bug seen somewhere on some CPU but it >> makes me rather queasy) but wherein in any case we >> do not seem to be assured 2 issues between the mtc0 >> and the tlbwr. It should be OK for an R4000, but not for >> an R5000. > >No, it's not a bug workaround. The reason for this branch is that the >R4000 and R4400 have a penalty of three cycles for a taken branch. So >the branch above is equivalent with > > mtc0 k1, CP0_ENTRYLO1 > nop > tlbwr > nop > nop > nop > eret > >Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand >but as I understood them the above code should also work just perfect >for them. No. Not as I read the specs. There are three problems here. First, the question is *not* one of no-ops between the TLBWR and the ERET, but of no-ops between the MTC0 and the TLBWR - re-read the quoted text above from my previous message. So the code may well be broken as I conjectured even if your assumption about the branch delay was valid. Second, the R5000 and R4600 piprlines are not as deep as those of the R4000/4400. The R5000 documentation calls out a branch implementation with a *single* delay cycle. I quote: "The one cycle branch delay is a result of the branch comparison logic operating during the 1A pipeline stage of the branch. This allows the branch target address calculated in the previous stage to be used for the instruction access in the following 1I phase." So even if the execution of the branch were inserting delay between the MTC0 and the TLBWR as you seemed to assume, it might not be inserting as much delay as you think. Thirdly, this whole thread underscores why "clever" solutions that depend on implementation features of particular CPUs should be avoided whenever possible. If you want to be assured of getting a delay cycle in a MIPS instruction stream, you should use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0), which forces delays even in superscalar implementations. >> So someone with the ability to reproduce the R5000 >> problem should really try sticking a nop between the >> mtc0 and the branch (sigh) to see if that stabilizes >> the system. I still think this would be a good idea. Further, from Bill Earl's comment on this same thread, it sounds like, to be conservative, trap_init() in arch/mips/kernel/traps.c needs to detect the R5000 case and patch in except_vec0_r45k_bvahwbug instead of except_vec0_r4000, and that furthermore a nop (or ssnop) be added between the MTC0 and the branch of except_vec0_r45k_bvahwbug. >Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty >workaround. I think I only put the workaround into the Cobalt kernel. >Of course IDT doesn't admit that this bug even exists ... Um, why should they, when IDT didn't do the R5230? ;-) Seriously, did you mean to refer to the R323xx from IDT, or to QED as the design house for the R5230? I have been running 2.2.12 on an R5260 for months and it has been very stable. To which bug and which workaround are you referring? Regards, Kevin K. __ Kevin D. Kissell MIPS Technologies European Architecture Lab kevink@mips.com Tel. +33.4.78.38.70.67 FAX. +33.4.78.38.70.68 From flo@rfc822.org Wed Feb 16 12:25:34 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA22033; Wed, 16 Feb 2000 12:25:33 +0100 (MET) Received-Date: Wed, 16 Feb 2000 12:25:33 +0100 (MET) Received: by noose.gt.owl.de (Postfix, from userid 10) id DA79A7F3; Wed, 16 Feb 2000 12:25:31 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8F8298FC4; Wed, 16 Feb 2000 12:22:50 +0100 (CET) Date: Wed, 16 Feb 2000 12:22:50 +0100 From: Florian Lohoff To: linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr Subject: oss.sgi.com CVS kernel doesn compile for DEC Message-ID: <20000216122250.A898@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Organization: rfc822 - pure communication Sender: flo@rfc822.org Just a small note - probably most of the people already stumbled on this. ar rcs lib.a csum_partial.o csum_partial_copy.o floppy-std.o floppy-no.o ide-std.o ide-no.o kbd-std.o kbd-no.o rtc-std.o rtc-no.o memcpy.o memset.o strlen_user.o strncpy_user.o strnlen_user.o watch.o dump_tlb.o make[2]: Leaving directory `/data/kernel/linux/arch/mips/lib' make[1]: Leaving directory `/data/kernel/linux/arch/mips/lib' ld -static -G 0 -T arch/mips/ld.script.little -Ttext 0x80040000 arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/dec/dec.o \ net/network.a \ drivers/block/block.a drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/parport/parport.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/video/video.o drivers/tc/tc.a \ arch/mips/lib/lib.a /data/kernel/linux/lib/lib.a arch/mips/dec/prom/rexlib.a \ --end-group \ -o vmlinux drivers/char/char.o: In function `setkeycode': keyboard.c(.text+0x848c): undefined reference to `pckbd_setkeycode' keyboard.c(.text+0x848c): relocation truncated to fit: R_MIPS_26 pckbd_setkeycode drivers/char/char.o: In function `getkeycode': keyboard.c(.text+0x84a8): undefined reference to `pckbd_getkeycode' keyboard.c(.text+0x84a8): relocation truncated to fit: R_MIPS_26 pckbd_getkeycode drivers/char/char.o: In function `handle_scancode': keyboard.c(.text+0x85c8): undefined reference to `pckbd_translate' keyboard.c(.text+0x85c8): relocation truncated to fit: R_MIPS_26 pckbd_translate keyboard.c(.text+0x8634): undefined reference to `pckbd_unexpected_up' keyboard.c(.text+0x8634): relocation truncated to fit: R_MIPS_26 pckbd_unexpected_up drivers/char/char.o: In function `kbd_bh': keyboard.c(.text+0x9ab0): undefined reference to `pckbd_leds' keyboard.c(.text+0x9ab0): relocation truncated to fit: R_MIPS_26 pckbd_leds drivers/char/char.o: In function `misc_register': misc.c(.text.init+0x910): undefined reference to `pckbd_init_hw' misc.c(.text.init+0x910): relocation truncated to fit: R_MIPS_26 pckbd_init_hw make: *** [vmlinux] Error 1 (root@193)/data/kernel/linux# egrep -i "KEY|KBD" .config # CONFIG_KEYBOARD is not set Flo -- Florian Lohoff flo@rfc822.org +49-5241-470566 "Technology is a constant battle between manufacturers producing bigger and more idiot-proof systems and nature producing bigger and better idiots." From Harald.Koerfgen@home.ivm.de Wed Feb 16 18:24:10 2000 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA28576; Wed, 16 Feb 2000 18:24:09 +0100 (MET) Received-Date: Wed, 16 Feb 2000 18:24:09 +0100 (MET) Received: from franz.no.dom (port85.duesseldorf.ivm.de [195.247.65.85]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id SAA21781; Wed, 16 Feb 2000 18:23:20 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.3 [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: <38A9D0CB.FF958043@galileo.co.il> Date: Wed, 16 Feb 2000 18:24:02 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Rabeeh Khoury Subject: RE: boot memory Cc: "linux-mips@fnet.fr" On 15-Feb-00 Rabeeh Khoury wrote: > Hi All > > I'm having trouble with my embedded system initializing the ram ; I do > the following for initializations in kernel_entry - > > { > mips_machgroup = MACH_GROUP_GALILEO; > > mips_memory_upper = 0x81000000; // not needed any more > galileo_mem_init(); > } > > void __init galileo_mem_init(void) > { > unsigned long bootmap_size; > > max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the > embedded > bootmap_size = init_bootmem(0, max_low_pfn); > free_bootmem (0 , 0x01000000); > reserve_bootmem(0, 0x01000000); > } > What about something like: #define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) void __init galileo_mem_init(void) { extern char _end; unsigned long bootmap_size; start_pfn = PFN_UP((unsigned long)&_end); mem_size = 0x01000000; /* Register all the contiguous memory with the bootmem allocator and free it. Be careful about the bootmem freemap. */ bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); free_bootmem(start_pfn + bootmap_size, mem_size - start_pfn - bootmap_size); } ? --- Regards, Harald From raiko@niisi.msk.ru Wed Feb 16 18:47:23 2000 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 SAA29142; Wed, 16 Feb 2000 18:47:21 +0100 (MET) Received-Date: Wed, 16 Feb 2000 18:47:21 +0100 (MET) 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 UAA04161 for ; Wed, 16 Feb 2000 20:48:01 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id UAA02587 for linux-mips@fnet.fr; Wed, 16 Feb 2000 20:55:20 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id UAA22649 for ; Wed, 16 Feb 2000 20:44:59 +0300 (MSK) Message-ID: <38AAE462.86F225D8@niisi.msk.ru> Date: Wed, 16 Feb 2000 20:54:42 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: Re: boot memory References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Harald Koerfgen wrote: > What about something like: > > #define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) > > void __init galileo_mem_init(void) > { > extern char _end; > unsigned long bootmap_size; > > start_pfn = PFN_UP((unsigned long)&_end); > mem_size = 0x01000000; > > /* Register all the contiguous memory with the bootmem allocator > and free it. Be careful about the bootmem freemap. */ > bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); > free_bootmem(start_pfn + bootmap_size, mem_size - start_pfn - bootmap_size); > } > More easy :-), w/o PFN_UP. Just implemented for baget today: /* endmem - highest address of phys memory, passed by Baget Linux loader */ static void __init prom_meminit(unsigned long endmem) { extern int _end; unsigned long bootmap_size; unsigned long start_pfn, max_pfn; unsigned long free_start = PAGE_ALIGN((unsigned long)&_end); start_pfn = MAP_NR(free_start); max_pfn = MAP_NR(endmem); bootmap_size = init_bootmem(start_pfn, max_pfn); free_bootmem(__pa(free_start), endmem - free_start); /* reserve bootmem allocator's bitmap */ reserve_bootmem(__pa(free_start), bootmap_size); } From Harald.Koerfgen@home.ivm.de Wed Feb 16 19:02:56 2000 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29288; Wed, 16 Feb 2000 19:02:55 +0100 (MET) Received-Date: Wed, 16 Feb 2000 19:02:55 +0100 (MET) Received: from franz.no.dom (port216.duesseldorf.ivm.de [195.247.65.216]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id TAA24531; Wed, 16 Feb 2000 19:02:37 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.3.p0.Linux:000216190255:1753=_" In-Reply-To: <38A91E19.CE7A9890@niisi.msk.ru> Date: Wed, 16 Feb 2000 19:03:19 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: "Gleb O. Raiko" Subject: RE: -fno-strict-aliasing problem in the latest 2.3 Cc: linux-mips@fnet.fr, SGI Linux This message is in MIME format --_=XFMail.1.3.p0.Linux:000216190255:1753=_ Content-Type: text/plain; charset=us-ascii Hi, On 15-Feb-00 Gleb O. Raiko wrote: > There is a problem with the way main Makefile determines whether the > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC > and tries to feed this option to it. Unfortunately, we set CC to proper > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile > just checks against native gcc. On RH6.1 with latest cross tool rpms > installed, I get cc1: Invalid option `-fno-strict-aliasing' during > comppilation, obviously. I am not exactly shure if it has ill side effects or if this may not be wanted for some reason, but the attached patch fixes that for me. OK to commit? --- Regards, Harald --_=XFMail.1.3.p0.Linux:000216190255:1753=_ Content-Disposition: attachment; filename="Makefile-patch" Content-Transfer-Encoding: 7bit Content-Description: Makefile-patch Content-Type: text/plain; charset=us-ascii; name=Makefile-patch; SizeOnDisk=835 --- /nfs/cvs/linux-2.3/linux/Makefile Wed Feb 16 18:40:57 2000 +++ Makefile Wed Feb 16 18:53:13 2000 @@ -96,9 +96,6 @@ CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer AFLAGS := $(CPPFLAGS) -# use '-fno-strict-aliasing', but only if the compiler can take it -CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) - # # if you want the RAM disk device, define this to be the # size in blocks. @@ -252,6 +249,9 @@ endif include arch/$(ARCH)/Makefile + +# use '-fno-strict-aliasing', but only if the compiler can take it +CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) .S.s: $(CC) -D__ASSEMBLY__ $(AFLAGS) -traditional -E -o $*.s $< --_=XFMail.1.3.p0.Linux:000216190255:1753=_-- End of MIME message From rabeeh@galileo.co.il Wed Feb 16 19:03:15 2000 Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29309; Wed, 16 Feb 2000 19:03:08 +0100 (MET) Received-Date: Wed, 16 Feb 2000 19:03:08 +0100 (MET) Received: from galileo.co.il (rabeeh@[10.2.20.126]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA08696 for ; Wed, 16 Feb 2000 20:03:21 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <38AB4936.79483F98@galileo.co.il> Date: Wed, 16 Feb 2000 20:04:54 -0500 From: Rabeeh Khoury X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: NFS - Root Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm running diskless embedded system which mounts root-NFS over a PC running RedHat v.6. The embedded executes all initab functions but when it gets to login ; it displays the contents of the file /etc/issue , runs /bin/login then it doesn't log in at all ; the file passwd contains : root::0:0:root:/root:/bin/sh and there is no file /etc/shadow. the gid and uid of all the files in the directory are 0 , 0 . p.s. if I run the kernel over the embedded with "init=/bin/sh" option it runs with no problem even executes some binaries. what could be the problem ? if you encountered such a problem please email me. thank you Rabeeh From laneb@bcstec.ca.boeing.com Wed Feb 16 19:39:06 2000 Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29953; Wed, 16 Feb 2000 19:39:05 +0100 (MET) Received-Date: Wed, 16 Feb 2000 19:39:05 +0100 (MET) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA27277 for ; Wed, 16 Feb 2000 12:39:02 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id MAA29183 for ; Wed, 16 Feb 2000 12:39:01 -0600 (CST) Received: from [136.240.231.86] by stl-hub-01.boeing.com with ESMTP for linux-mips@fnet.fr; Wed, 16 Feb 2000 12:38:54 -0600 Sender: laneb@bcstec.ca.boeing.com Message-Id: <38AAEEBD.1638AF47@bcstec.ca.boeing.com> Date: Wed, 16 Feb 2000 10:38:53 -0800 From: Bruce Lane Organization: BCAG, RS/6000 (Unix) Systems Support X-Mailer: Mozilla 4.51 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: NEC RISCServer Support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NOTE: This is being sent from work. Please direct responses to: kyrrin@bluefeathertech.com With that said... Gentlemen, I currently have a spare NEC RISCServer 2200 with two R4000 CPU's that I would love to resurrect. My coding skills are practically nil, but I would be happy to (time allowing) try and assist with testing a Linux port for the system. Has there been any further progress on SMP support? Thanks in advance. -- -=-=-=-=-=-=-=-=-=- Bruce Lane, RS/6000 Single-Glass (Unix) Support BCAG Renton, 10-20.5, Cubie 5C1-1, (425) 234-2113 http://bcstec.ca.boeing.com/~laneb The opinions and views expressed are strictly my own. They do not necessarily represent the views of Boeing as a company, other employees, or any domestic or exotic animals contained therein. You have now been officially disclaimed. *beeeep* From wje@liveoak.engr.sgi.com Wed Feb 16 19:51:19 2000 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 TAA00179; Wed, 16 Feb 2000 19:51:17 +0100 (MET) Received-Date: Wed, 16 Feb 2000 19:51:17 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24465; Wed, 16 Feb 2000 10:46:42 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA25988; Wed, 16 Feb 2000 10:50:54 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id KAA16521; Wed, 16 Feb 2000 10:50:47 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14506.61831.733915.236157@liveoak.engr.sgi.com> Date: Wed, 16 Feb 2000 10:50:47 -0800 (PST) To: "Kevin D. Kissell" Cc: "Ralf Baechle" , "Geert Uytterhoeven" , , , Subject: Re: Indy crashes In-Reply-To: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com> References: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com> X-Mailer: VM 6.74 under Emacs 20.3.1 Kevin D. Kissell writes: > Ralf Baechle writes: > >On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote: ... > >No, it's not a bug workaround. The reason for this branch is that the > >R4000 and R4400 have a penalty of three cycles for a taken branch. So > >the branch above is equivalent with > > > > mtc0 k1, CP0_ENTRYLO1 > > nop > > tlbwr > > nop > > nop > > nop > > eret > > > >Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand > >but as I understood them the above code should also work just perfect > >for them. > > No. Not as I read the specs. There are three problems here. > > First, the question is *not* one of no-ops between the TLBWR > and the ERET, but of no-ops between the MTC0 and the > TLBWR - re-read the quoted text above from my previous > message. So the code may well be broken as I conjectured > even if your assumption about the branch delay was valid. Empirically, this does not appear to be the case. Here are the handlers for the r4600 and r5000 on IRIX, which have been stable for years: eutlbmiss3_250mhz: [1023] 0x880849b0: 40 1a 20 00 mfc0 k0,context [1023] 0x880849b4: 00 1a d0 43 sra k0,k0,1 utlbmiss_r4600: [1031] 0x880849b8: 8f 5b 00 00 lw k1,0(k0) [1031] 0x880849bc: 8f 5a 00 04 lw k0,4(k0) [1032] 0x880849c0: 00 1b d9 80 sll k1,k1,6 [1032] 0x880849c4: 00 1b d9 82 srl k1,k1,6 [1033] 0x880849c8: 40 9b 10 00 mtc0 k1,tlblo [1034] 0x880849cc: 00 1a d1 80 sll k0,k0,6 [1034] 0x880849d0: 00 1a d1 82 srl k0,k0,6 [1035] 0x880849d4: 40 9a 18 00 mtc0 k0,tlblo1 [1036] 0x880849d8: 00 00 00 00 nop [1037] 0x880849dc: 42 00 00 06 c0 tlbwr [1038] 0x880849e0: 00 00 00 00 nop utlbmiss_eret_3: [1039] 0x880849e4: 0a 01 c9 59 j _r4600_2_0_cacheop_eret [1039] 0x880849e8: 00 00 00 00 nop _r4600_2_0_cacheop_eret: [ 211] 0x88072564: 00 00 00 00 nop [ 211] 0x88072568: 00 00 00 00 nop [ 211] 0x8807256c: 00 00 00 00 nop [ 211] 0x88072570: 00 00 00 00 nop [ 211] 0x88072574: 00 00 00 00 nop [ 211] 0x88072578: 00 00 00 00 nop [ 211] 0x8807257c: 00 00 00 00 nop [ 211] 0x88072580: 00 00 00 00 nop _r4600_2_0_cacheop_eret_inst: [ 211] 0x88072584: 42 00 00 18 c0 eret eutlbmiss3_250mhz: [1023] 0x880849b0: 40 1a 20 00 mfc0 k0,context [1023] 0x880849b4: 00 1a d0 43 sra k0,k0,1 utlbmiss_r5000: [1061] 0x8007ede8: 8f 5b 00 00 lw k1,0(k0) [1061] 0x8007edec: 8f 5a 00 04 lw k0,4(k0) [1062] 0x8007edf0: 42 00 00 08 c0 tlbp [1063] 0x8007edf4: 00 1b d9 00 sll k1,k1,4 [1063] 0x8007edf8: 00 1b d9 02 srl k1,k1,4 [1064] 0x8007edfc: 40 9b 10 00 mtc0 k1,tlblo [1065] 0x8007ee00: 40 1b 00 00 mfc0 k1,index [1066] 0x8007ee04: 00 1a d1 00 sll k0,k0,4 [1066] 0x8007ee08: 00 1a d1 02 srl k0,k0,4 [1067] 0x8007ee0c: 07 61 00 04 bgez k1,0x8007ee20 [1068] 0x8007ee10: 40 9a 18 00 mtc0 k0,tlblo1 [1069] 0x8007ee14: 42 00 00 06 c0 tlbwr [1070] 0x8007ee18: 00 00 00 00 nop [1071] 0x8007ee1c: 42 00 00 18 c0 eret Note that, in the R4600 case, the "j _r4600_2_0_cacheop_eret" is replaced with an eret on the R4600 Rev. 1.*. (The code is patched at system startup time.) Also notice that IRIX does not index a segment table directly. Instead, a second level TLB miss handler drops a mapping into a reserved part of K2SEG for the PTE page required, where the base of that reserved area is loaded into $context at startup time. > Second, the R5000 and R4600 piprlines are not as deep > as those of the R4000/4400. The R5000 documentation > calls out a branch implementation with a *single* delay cycle. > I quote: "The one cycle branch delay is a result of the branch > comparison logic operating during the 1A pipeline stage of > the branch. This allows the branch target address calculated > in the previous stage to be used for the instruction access in > the following 1I phase." So even if the execution of the > branch were inserting delay between the MTC0 and the > TLBWR as you seemed to assume, it might not be inserting > as much delay as you think. As you can see from the above examples, the IRIX handlers for these processors are indeed different. The R4000 and R4400 require more nops in other places: utlbmiss_prolog_up: [ 144] 0x88084600: 40 1a 20 00 mfc0 k0,context [ 144] 0x88084604: 00 00 00 00 nop [ 145] 0x88084608: 00 1a d0 43 sra k0,k0,1 utlbmiss: [ 219] 0x88084680: 8f 5b 00 00 lw k1,0(k0) [ 219] 0x88084684: 8f 5a 00 04 lw k0,4(k0) [ 223] 0x88084688: 00 1b d9 80 sll k1,k1,6 [ 223] 0x8808468c: 00 1b d9 82 srl k1,k1,6 [ 224] 0x88084690: 40 9b 10 00 mtc0 k1,tlblo [ 225] 0x88084694: 00 1a d1 80 sll k0,k0,6 [ 225] 0x88084698: 00 1a d1 82 srl k0,k0,6 [ 236] 0x8808469c: 40 9a 18 00 mtc0 k0,tlblo1 [ 237] 0x880846a0: 00 00 00 00 nop [ 238] 0x880846a4: 42 00 00 06 c0 tlbwr [ 239] 0x880846a8: 00 00 00 00 nop [ 239] 0x880846ac: 00 00 00 00 nop [ 239] 0x880846b0: 00 00 00 00 nop [ 246] 0x880846b4: 42 00 00 18 c0 eret Notice that the R4000 requires a nop after the mfc0 from $context, and also requires extra nops after the tlbwr. Also, here is the utlbmiss for the 250 MHZ R4400, with another workaround: utlbmiss_prolog_up: [ 144] 0x88084600: 40 1a 20 00 mfc0 k0,context [ 144] 0x88084604: 00 00 00 00 nop [ 145] 0x88084608: 00 1a d0 43 sra k0,k0,1 eutlbmiss3: [ 805] 0x88084830: 8f 5b 00 00 lw k1,0(k0) [ 805] 0x88084834: 8f 5a 00 04 lw k0,4(k0) [ 809] 0x88084838: 00 1b d9 80 sll k1,k1,6 [ 809] 0x8808483c: 00 1b d9 82 srl k1,k1,6 [ 810] 0x88084840: 40 80 10 00 mtc0 zero,tlblo [ 811] 0x88084844: 40 9b 10 00 mtc0 k1,tlblo [ 812] 0x88084848: 00 1a d1 80 sll k0,k0,6 [ 812] 0x8808484c: 00 1a d1 82 srl k0,k0,6 [ 824] 0x88084850: 40 80 18 00 mtc0 zero,tlblo1 [ 825] 0x88084854: 40 9a 18 00 mtc0 k0,tlblo1 [ 826] 0x88084858: 00 00 00 00 nop [ 827] 0x8808485c: 42 00 00 06 c0 tlbwr [ 828] 0x88084860: 00 00 00 00 nop [ 828] 0x88084864: 00 00 00 00 nop [ 828] 0x88084868: 00 00 00 00 nop [ 829] 0x8808486c: 42 00 00 18 c0 eret Emprirically, it appears that the manual is incorrect in regard to the number of nop instructions. The above sequences are known to work (via years of testing, and also via validation in discussions with people familiar with the hardware pipelines). > Thirdly, this whole thread underscores why "clever" solutions that > depend on implementation features of particular CPUs should > be avoided whenever possible. If you want to be assured of > getting a delay cycle in a MIPS instruction stream, you should > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0), > which forces delays even in superscalar implementations. This is not realistic, given the number of workarounds required for various processors, unless you are willing to have most processors run quite a bit slower. (Extra cycles in utlbmiss are noticeable.) From elmion@yahoo.com Wed Feb 16 20:49:36 2000 Received: from web1003.mail.yahoo.com (web1003.mail.yahoo.com [128.11.23.93]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id UAA00681; Wed, 16 Feb 2000 20:49:34 +0100 (MET) Received-Date: Wed, 16 Feb 2000 20:49:34 +0100 (MET) Received: (qmail 9172 invoked by uid 60001); 16 Feb 2000 19:17:28 -0000 Message-ID: <20000216191728.9171.qmail@web1003.mail.yahoo.com> Received: from [195.84.7.210] by web1003.mail.yahoo.com; Wed, 16 Feb 2000 11:17:28 PST Date: Wed, 16 Feb 2000 11:17:28 -0800 (PST) From: Christer Eliasson Subject: Mips Magnum R4000 To: linux-mips@fnet.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi all Im in possession of a Mips R4000 Magnum 100Mhz After having tried everything it still wont Bootup. It hangs in POST So .... If anyone wants it its yours (real cheap) for under 100$US (With Cabinet if you want it) No Memory FB Card Soundcard Ethernet Card You pay the freight Mail me if you want it Best Regards Christer __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From kevink@mips.com Wed Feb 16 23:34:14 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA03848; Wed, 16 Feb 2000 23:34:13 +0100 (MET) Received-Date: Wed, 16 Feb 2000 23:34:13 +0100 (MET) Received: from newman.mips.com (newman [206.31.31.8]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA13459; Wed, 16 Feb 2000 14:34:06 -0800 (PST) Received: from satanas (satanas [192.168.236.12]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA16552; Wed, 16 Feb 2000 14:34:03 -0800 (PST) Message-ID: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com> From: "Kevin D. Kissell" To: "William J. Earl" Cc: , , Subject: Re: Indy crashes Date: Wed, 16 Feb 2000 23:33:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >Emprirically, it appears that the [R5000] manual is incorrect in regard >to the number of nop instructions. The above sequences are known >to work (via years of testing, and also via validation in discussions >with people familiar with the hardware pipelines). In principle, I could check it against the RTL, but I probably won't bother. Many thanks for sharing the IRIX disassembly! > > Thirdly, this whole thread underscores why "clever" solutions that > > depend on implementation features of particular CPUs should > > be avoided whenever possible. If you want to be assured of > > getting a delay cycle in a MIPS instruction stream, you should > > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0), > > which forces delays even in superscalar implementations. > > This is not realistic, given the number of workarounds required >for various processors, unless you are willing to have most processors >run quite a bit slower. (Extra cycles in utlbmiss are noticeable.) I agree that it is not realistic to hav a single binary TLB miss handler for all possible MIPS CPUs, but that's not what I was getting at. I just consider it unwise to use the fact that one "knows" that branches "always" delay three cycles to avoid hazards. Such tricks are obscurantist, and lead, in my experience, to errors. Kevin K. From ralf@uni-koblenz.de Thu Feb 17 11:33:39 2000 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 LAA10735; Thu, 17 Feb 2000 11:33:38 +0100 (MET) Received-Date: Thu, 17 Feb 2000 11:33:38 +0100 (MET) Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09124; Thu, 17 Feb 2000 11:33:29 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 18:23:15 +0100 Date: Wed, 16 Feb 2000 18:23:15 +0100 From: Ralf Baechle To: "Gleb O. Raiko" Cc: linux-mips@fnet.fr Subject: Re: -fno-strict-aliasing problem in the latest 2.3 Message-ID: <20000216182315.A6252@uni-koblenz.de> References: <38A91E19.CE7A9890@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38A91E19.CE7A9890@niisi.msk.ru> X-Accept-Language: de,en,fr On Tue, Feb 15, 2000 at 12:36:26PM +0300, Gleb O. Raiko wrote: > There is a problem with the way main Makefile determines whether the > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC > and tries to feed this option to it. Unfortunately, we set CC to proper > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile > just checks against native gcc. On RH6.1 with latest cross tool rpms > installed, I get cc1: Invalid option `-fno-strict-aliasing' during > comppilation, obviously. > > I can't offer an elegenat solution to resolve this problem. Basically, I > see three choices: > > 1. Move logic that sets CC from arch/mips/Makefile to the main Makefile > (Nightmare for Ralf who have to either feed it to Linus or add this > logic in the main Makefile every merge, I think.) This is a generic problem which affects all architectures so there is no reason why to put it to somewhere else than into the main Makefile. > 2. Filter CFLAGS to remove -fno-strict-aliasing in arch/mips/Makefile > (Nasty.) Definately nastissimo. > 3. Fix the mips compiler :-) Don't fix what isn't broken. > (Looks good for me despite the fact I don't understand exctly how > much work it costs, but can imagine...) The fix is trivial, move the offending lines: # use '-fno-strict-aliasing', but only if the compiler can take it CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) down below the ``include arch/$(ARCH)/Makefile'' statement and you're set. I'll send this to CVS. Ralf From ralf@uni-koblenz.de Thu Feb 17 11:33:41 2000 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 LAA10741; Thu, 17 Feb 2000 11:33:40 +0100 (MET) Received-Date: Thu, 17 Feb 2000 11:33:40 +0100 (MET) Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09176; Thu, 17 Feb 2000 11:33:36 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 18:45:22 +0100 Date: Wed, 16 Feb 2000 18:45:22 +0100 From: Ralf Baechle To: Rabeeh Khoury Cc: "linux-mips@fnet.fr" Subject: Re: boot memory Message-ID: <20000216184522.B6252@uni-koblenz.de> References: <38A9D0CB.FF958043@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38A9D0CB.FF958043@galileo.co.il> X-Accept-Language: de,en,fr On Tue, Feb 15, 2000 at 05:18:51PM -0500, Rabeeh Khoury wrote: > void __init galileo_mem_init(void) > { > unsigned long bootmap_size; > > max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the > embedded > bootmap_size = init_bootmem(0, max_low_pfn); This will put the allocation bitmap at physical address zero where trap_init() will overwrite it with the exception handlers. *boom*. > free_bootmem (0 , 0x01000000); This frees the entire physical memory ... > reserve_bootmem(0, 0x01000000); > } ... and declares it as in use once again -> No free memory left for the kernel. > but the kernel is stuck in the alloc_bootmem_node which is called from > free_area_init_core . Fix the above bugs, then retry. With what you did above free_area_init() isn't supposed to work. Ralf From ralf@oss.sgi.com Thu Feb 17 11:33:47 2000 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 LAA10773; Thu, 17 Feb 2000 11:33:45 +0100 (MET) Received-Date: Thu, 17 Feb 2000 11:33:45 +0100 (MET) Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09185; Thu, 17 Feb 2000 11:33:39 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 19:24:27 +0100 Date: Wed, 16 Feb 2000 19:24:27 +0100 From: Ralf Baechle To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: 32-bit MIPS with > 512mb mem Message-ID: <20000216192427.A6330@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1 window? So far I haven't ever seen such a machine. For 64-bit CPUs the right thing to do is easy - use a 64-bit kernel. But for 32-bit CPUs the Intel highmem stuff in the memory managment now gives us a sane way to use the memory of such configuration with just a little bit of extra code. So if anybody wants support for such a configuration, please drop me a note. Thanks, Ralf From raiko@niisi.msk.ru Thu Feb 17 12:02:28 2000 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 MAA11029; Thu, 17 Feb 2000 12:02:25 +0100 (MET) Received-Date: Thu, 17 Feb 2000 12:02:25 +0100 (MET) 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 OAA10107 for ; Thu, 17 Feb 2000 14:02:48 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA15973 for linux-mips@fnet.fr; Thu, 17 Feb 2000 14:07:36 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA08164 for ; Thu, 17 Feb 2000 13:55:08 +0300 (MSK) Message-ID: <38ABD5D7.8EF12364@niisi.msk.ru> Date: Thu, 17 Feb 2000 14:04:55 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: Re: boot memory References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Ralf, While we are discussing bootmem allocator, is there any plans to fix the allocator in order to be friendly for initrd on all arches ? Or do you have any ideas how to init bootmem w/o poisoning initrd image ? Call init_bootmem_node/core directly ? Also, why do not call init_bootmem in the machine independent place, somewhere in setup ? Regards, Gleb. From raiko@niisi.msk.ru Thu Feb 17 12:12:15 2000 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 MAA11113; Thu, 17 Feb 2000 12:12:13 +0100 (MET) Received-Date: Thu, 17 Feb 2000 12:12:13 +0100 (MET) 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 OAA10172; Thu, 17 Feb 2000 14:12:50 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA16133; Thu, 17 Feb 2000 14:19:48 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA08394; Thu, 17 Feb 2000 14:08:29 +0300 (MSK) Message-ID: <38ABD8F8.E25D670F@niisi.msk.ru> Date: Thu, 17 Feb 2000 14:18:16 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ralf Baechle CC: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: 32-bit MIPS with > 512mb mem References: <20000216192427.A6330@uni-koblenz.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > > Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or > to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1 > window? > > So far I haven't ever seen such a machine. For 64-bit CPUs the right > thing to do is easy - use a 64-bit kernel. But for 32-bit CPUs the Intel > highmem stuff in the memory managment now gives us a sane way to use > the memory of such configuration with just a little bit of extra code. > > So if anybody wants support for such a configuration, please drop me a > note. Not exactly > 512 mb, but related things. On Baget and DECstations, if memory serves correctly, there is IO space mapped on KSEG2. Now, Baget uses kseg2_allocate_io for it, DECstation also has something similar. IO space on Jazz and Co. are located in virtual address window too, can't remember where. In princple, access to such IO spaces may be done by using highmem. Regards, Gleb. From Geert.Uytterhoeven@sonycom.com Thu Feb 17 13:21:05 2000 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA11476; Thu, 17 Feb 2000 13:21:04 +0100 (MET) Received-Date: Thu, 17 Feb 2000 13:21:04 +0100 (MET) Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA11747; Thu, 17 Feb 2000 13:20:31 +0100 (MET) Date: Thu, 17 Feb 2000 13:20:31 +0100 (MET) From: Geert Uytterhoeven Sender: geert@sonycom.com To: Harald Koerfgen cc: "Gleb O. Raiko" , linux-mips@fnet.fr, SGI Linux Subject: RE: -fno-strict-aliasing problem in the latest 2.3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Feb 2000, Harald Koerfgen wrote: > On 15-Feb-00 Gleb O. Raiko wrote: > > There is a problem with the way main Makefile determines whether the > > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC > > and tries to feed this option to it. Unfortunately, we set CC to proper > > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile > > just checks against native gcc. On RH6.1 with latest cross tool rpms > > installed, I get cc1: Invalid option `-fno-strict-aliasing' during > > comppilation, obviously. > > I am not exactly shure if it has ill side effects or if this may not be wanted > for some reason, but the attached patch fixes that for me. > > OK to commit? Apart from the fact that your mailer breaks long line, even in attachments, it seems to work fine. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From rabeeh@galileo.co.il Thu Feb 17 15:49:55 2000 Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA13898; Thu, 17 Feb 2000 15:49:51 +0100 (MET) Received-Date: Thu, 17 Feb 2000 15:49:51 +0100 (MET) Received: from galileo.co.il (rabeeh@[10.2.20.126]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id QAA08130 for ; Thu, 17 Feb 2000 16:44:52 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <38AC6C30.8F8412F9@galileo.co.il> Date: Thu, 17 Feb 2000 16:46:24 -0500 From: Rabeeh Khoury X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: filesystem problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I managed to mount NFS for my embedded system over a PC running linux RedHat 6.0 all the files on the filesystem are uid=0 (root) and gid=0 ; when I try to create any new file on the embedded system it creates the file with gid and uid 65534 ??!! bash# id uid=0(root) gid=0(root) groups=0(root) bash# cd /lib bash# ls -la libcra* -rwxrwxrwx 1 root 73628 Feb 8 2000 libcrack.so -rwxrwxrwx 1 root 73628 Feb 8 2000 libcrack.so.2.7 bash# ldconfig bash# ls -lan libcra* -rwxrwxrwx 1 0 0 73628 Feb 8 2000 libcrack.so lrwxrwxrwx 1 65534 65534 15 Feb 17 2000 libcrack.so.2 -> libcrack.so.2.7 -rwxrwxrwx 1 0 0 73628 Feb 8 2000 libcrack.so.2.7 do you know what is the problem ? thank you From R.vandenBerg@inter.NL.net Thu Feb 17 16:23:44 2000 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 QAA16270; Thu, 17 Feb 2000 16:23:43 +0100 (MET) Received-Date: Thu, 17 Feb 2000 16:23:43 +0100 (MET) Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net via hn51-12.Hoorn.NL.net [193.79.46.176] with ESMTP id QAA19145 (8.8.8/3.41); Thu, 17 Feb 2000 16:23:41 +0100 (MET) Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Thu, 17 Feb 2000 16:23:06 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Thu, 17 Feb 2000 16:23:05 +0100 (MET) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: Rabeeh Khoury cc: "linux-mips@fnet.fr" Subject: Re: filesystem problems In-Reply-To: <38AC6C30.8F8412F9@galileo.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Feb 2000, Rabeeh Khoury wrote: > I managed to mount NFS for my embedded system over a PC running linux > RedHat 6.0 > all the files on the filesystem are uid=0 (root) and gid=0 ; when I try > to create any new file on the embedded system it creates the file with > gid and uid 65534 ??!! $ man 5 exports ... By default, nfsd tries to obtain the anonymous uid and gid by looking up user nobody in the password file at startup time. If it isn't found, a uid and gid of -2 (i.e. 65534) is used. These values can also be overridden by the anonuid and anongid options. ... Guess you have to edit /etc/exports to change the behaviour. Regards, Richard From ralf@oss.sgi.com Thu Feb 17 17:27:15 2000 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 RAA07702; Thu, 17 Feb 2000 17:27:13 +0100 (MET) Received-Date: Thu, 17 Feb 2000 17:27:13 +0100 (MET) Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24549; Thu, 17 Feb 2000 17:27:05 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 14:25:29 +0100 Date: Thu, 17 Feb 2000 14:25:29 +0100 From: Ralf Baechle To: Harald Koerfgen Cc: "Gleb O. Raiko" , linux-mips@fnet.fr, SGI Linux Subject: Re: -fno-strict-aliasing problem in the latest 2.3 Message-ID: <20000217142529.A5423@uni-koblenz.de> References: <38A91E19.CE7A9890@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr On Wed, Feb 16, 2000 at 07:03:19PM +0100, Harald Koerfgen wrote: > On 15-Feb-00 Gleb O. Raiko wrote: > > There is a problem with the way main Makefile determines whether the > > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC > > and tries to feed this option to it. Unfortunately, we set CC to proper > > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile > > just checks against native gcc. On RH6.1 with latest cross tool rpms > > installed, I get cc1: Invalid option `-fno-strict-aliasing' during > > comppilation, obviously. > > I am not exactly shure if it has ill side effects or if this may not be wanted > for some reason, but the attached patch fixes that for me. > > OK to commit? Yes, my solution is identical, so who commits first commits first :) Ralf From ralf@uni-koblenz.de Thu Feb 17 17:27:18 2000 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 RAA07708; Thu, 17 Feb 2000 17:27:16 +0100 (MET) Received-Date: Thu, 17 Feb 2000 17:27:16 +0100 (MET) Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24566; Thu, 17 Feb 2000 17:27:09 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 14:49:29 +0100 Date: Thu, 17 Feb 2000 14:49:29 +0100 From: Ralf Baechle To: Rabeeh Khoury Cc: "linux-mips@fnet.fr" Subject: Re: NFS - Root Message-ID: <20000217144928.A5436@uni-koblenz.de> References: <38AB4936.79483F98@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38AB4936.79483F98@galileo.co.il> X-Accept-Language: de,en,fr On Wed, Feb 16, 2000 at 08:04:54PM -0500, Rabeeh Khoury wrote: > I'm running diskless embedded system which mounts root-NFS over a PC > running RedHat v.6. > > The embedded executes all initab functions but when it gets to login ; > it displays the contents of the file /etc/issue , runs /bin/login then > it doesn't log in at all. What does that mean, what happens exactly? You get back to the login: prompt or maybe an error message? > ; the file passwd contains : > > root::0:0:root:/root:/bin/sh > > and there is no file /etc/shadow. > > the gid and uid of all the files in the directory are 0 , 0 . > > p.s. if I run the kernel over the embedded with "init=/bin/sh" option it > runs with no problem even executes some binaries. > > what could be the problem ? if you encountered such a problem please > email me. Checkout if /etc/securetty (stupid concept ...) has an entry for the tty on which you try to login. Afair it's also ok. Ralf From ralf@uni-koblenz.de Thu Feb 17 17:27:18 2000 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 RAA07709; Thu, 17 Feb 2000 17:27:17 +0100 (MET) Received-Date: Thu, 17 Feb 2000 17:27:17 +0100 (MET) Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24576; Thu, 17 Feb 2000 17:27:12 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 14:56:08 +0100 Date: Thu, 17 Feb 2000 14:56:07 +0100 From: Ralf Baechle To: kyrrin@bluefeathertech.com Cc: linux-mips@fnet.fr Subject: Re: NEC RISCServer Support Message-ID: <20000217145607.C5436@uni-koblenz.de> References: <38AAEEBD.1638AF47@bcstec.ca.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38AAEEBD.1638AF47@bcstec.ca.boeing.com> X-Accept-Language: de,en,fr On Wed, Feb 16, 2000 at 10:38:53AM -0800, Bruce Lane wrote: > NOTE: This is being sent from work. Please direct responses to: > kyrrin@bluefeathertech.com > > With that said... That's what god made Reply-To: for. With that said ;-) > I currently have a spare NEC RISCServer 2200 with two R4000 CPU's that > I would love to resurrect. My coding skills are practically nil, but I > would be happy to (time allowing) try and assist with testing a Linux > port for the system. > > Has there been any further progress on SMP support? SMP yes but not for these systems. Initially SMP will be supported only for SGI Origins. Ralf From ralf@oss.sgi.com Thu Feb 17 17:27:31 2000 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 RAA07768; Thu, 17 Feb 2000 17:27:28 +0100 (MET) Received-Date: Thu, 17 Feb 2000 17:27:28 +0100 (MET) Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24597; Thu, 17 Feb 2000 17:27:20 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 15:27:11 +0100 Date: Thu, 17 Feb 2000 15:27:11 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "William J. Earl" , linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: Indy crashes Message-ID: <20000217152711.E5436@uni-koblenz.de> References: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com> X-Accept-Language: de,en,fr On Wed, Feb 16, 2000 at 11:33:33PM +0100, Kevin D. Kissell wrote: > > > Thirdly, this whole thread underscores why "clever" solutions that > > > depend on implementation features of particular CPUs should > > > be avoided whenever possible. If you want to be assured of > > > getting a delay cycle in a MIPS instruction stream, you should > > > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0), > > > which forces delays even in superscalar implementations. > > > > This is not realistic, given the number of workarounds required > >for various processors, unless you are willing to have most processors > >run quite a bit slower. (Extra cycles in utlbmiss are noticeable.) > > I agree that it is not realistic to hav a single binary TLB miss handler > for all possible MIPS CPUs, but that's not what I was getting at. > I just consider it unwise to use the fact that one "knows" that branches > "always" delay three cycles to avoid hazards. Such tricks are > obscurantist, and lead, in my experience, to errors. Maybe but then again TLB exception handles aren't supposed to be hacked by Joe Random Hacker. There is more to know about the real silicon beaviour than what the manuals say. So for example some of the documentation regarding c0 hazards on the R4000 is plain wrong for certain CPU revisions. The TLB exception handlers really deserve a rewrite. Somebody at QED once called them the longest ones he has ever seen. Ralf From ralf@oss.sgi.com Thu Feb 17 17:29:03 2000 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 RAA07812; Thu, 17 Feb 2000 17:29:02 +0100 (MET) Received-Date: Thu, 17 Feb 2000 17:29:02 +0100 (MET) Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24602; Thu, 17 Feb 2000 17:27:23 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 17:07:44 +0100 Date: Thu, 17 Feb 2000 17:07:44 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Geert Uytterhoeven , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Indy crashes Message-ID: <20000217170744.F5436@uni-koblenz.de> References: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com> X-Accept-Language: de,en,fr On Wed, Feb 16, 2000 at 11:42:29AM +0100, Kevin D. Kissell wrote: > >Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand > >but as I understood them the above code should also work just perfect > >for them. > > No. Not as I read the specs. There are three problems here. > > First, the question is *not* one of no-ops between the TLBWR > and the ERET, but of no-ops between the MTC0 and the > TLBWR - re-read the quoted text above from my previous > message. So the code may well be broken as I conjectured > even if your assumption about the branch delay was valid. Exactly _that_ is the trick. The pipeline will execute the two extra branch penalty cycles _after_ the tlbwr instruction. That is exactly what according to my reading of the manual is necessary in order to guarantee correct operation. The c0 hazard between the mtc0 and tlbwr is also taken care of by the branch instruction itself, there is only one instruction necessary and as per r4k manual any instruction does. Yes, it's obfuscating. However David Miller put this in the code, I guess he took this trick from IRIX and I took it from him. I think it's highly unlikely that we all made the same mistake - and that nobody got bit by this for a the past few years. That said, the whole TLB exception handling is sometimes very performance sensitive. We've got good reason to optimize it at almost any price. So the whole thing should be rewritten anyway. > Second, the R5000 and R4600 piprlines are not as deep > as those of the R4000/4400. The R5000 documentation > calls out a branch implementation with a *single* delay cycle. > I quote: "The one cycle branch delay is a result of the branch > comparison logic operating during the 1A pipeline stage of > the branch. This allows the branch target address calculated > in the previous stage to be used for the instruction access in > the following 1I phase." So even if the execution of the > branch were inserting delay between the MTC0 and the > TLBWR as you seemed to assume, it might not be inserting > as much delay as you think. On the R4600 and R5000 the branch will be taken with a delay of a single cycle, that is the instruction in the branch delay slot and no additional penalty. That's exactly what we want. > Thirdly, this whole thread underscores why "clever" solutions that > depend on implementation features of particular CPUs should > be avoided whenever possible. That's why we have a number of implementations of TLB exception handlers. Let me reiterate that they are extremly performance sensitive. > If you want to be assured of > getting a delay cycle in a MIPS instruction stream, you should > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0), > which forces delays even in superscalar implementations. > > >> So someone with the ability to reproduce the R5000 > >> problem should really try sticking a nop between the > >> mtc0 and the branch (sigh) to see if that stabilizes > >> the system. > > I still think this would be a good idea. Further, from Bill Earl's > comment on this same thread, it sounds like, to be conservative, > trap_init() in arch/mips/kernel/traps.c needs to detect the R5000 > case and patch in except_vec0_r45k_bvahwbug instead > of except_vec0_r4000, and that furthermore a nop (or ssnop) > be added between the MTC0 and the branch of > except_vec0_r45k_bvahwbug. Indeed, and I'll do that. The fact that we do not handle this bug is simply an omission on my side. The conditions that need to be true for this bug to actually hit a system are sufficiently rare that I don't wonder why nobody ever got hit by this. > >Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty > >workaround. I think I only put the workaround into the Cobalt kernel. > >Of course IDT doesn't admit that this bug even exists ... > > Um, why should they, when IDT didn't do the R5230? ;-) > Seriously, did you mean to refer to the R323xx from IDT, > or to QED as the design house for the R5230? I have been > running 2.2.12 on an R5260 for months and it has been very > stable. To which bug and which workaround are you referring? Sorry, I permanently missattribute the R5230 to IDT even though the manual says different in big letters on the frontpage. This is the exception handler from the Cobalt kernel. /* * This version has a bug workaround for the Nevada. It seems * as if under certain circumstances the move from cp0_context * might produce a bogus result when the mfc0 instruction and * it's consumer are in a different cacheline or a load instruction, * probably any memory reference, is between them. This is * potencially slower than the R4000 version, so we use this * special version. */ LEAF(except_vec0_nevada) .set mips3 mfc0 k0, CP0_BADVADDR # Get faulting address mfc0 k1, CP0_TAGLO srl k0, k0, 22 # get pgd only bits sll k0, k0, 2 addu k1, k1, k0 # add in pgd offset lw k1, (k1) mfc0 k0, CP0_CONTEXT # get context reg srl k0, k0, 1 # get pte offset and k0, k0, 0xff8 addu k1, k1, k0 # add in offset lw k0, 0(k1) # get even pte lw k1, 4(k1) # get odd pte srl k0, k0, 6 # convert to entrylo0 mtc0 k0, CP0_ENTRYLO0 # load it srl k1, k1, 6 # convert to entrylo1 mtc0 k1, CP0_ENTRYLO1 # load it tlbwr # write random tlb entry nop nop eret # return from trap END(except_vec0_nevada) Note that this is a handler for Cobalt's 2.0 so it's not a drop in replacement for what we have in other kernels. What we observed was that the first access of the kernel to virtual memory, that was buffer_init() which was still using vmalloc'ed memory somehow was not being processed correctly. We've never observed that the bug hits at some other place. The explanation given in above comment is a possible explanation of what I suspect after playing with exception handler modifications for a few hours. Since the CPU is a blackbox for me I cannot guarantee that this explanation is correct or even close to reality. Two people at Cobalt did run independently into this problem and found that c0_context was corrupted. However when later on some of there other at Cobalt were talking to QED they denied the possible existence of a bug like this in their silicon. Having an empirically correct workaround for this problem we then stopped further tracking this problem. Ralf From rabeeh@galileo.co.il Thu Feb 17 19:53:31 2000 Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA11779; Thu, 17 Feb 2000 19:53:29 +0100 (MET) Received-Date: Thu, 17 Feb 2000 19:53:29 +0100 (MET) Received: from galileo.co.il (rabeeh@[10.2.20.126]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA24765 for ; Thu, 17 Feb 2000 20:53:42 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <38ACA682.DE01FB8C@galileo.co.il> Date: Thu, 17 Feb 2000 20:55:14 -0500 From: Rabeeh Khoury X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: RPM installation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm trying to install RPM on my embedded system over NFS ; when I try installing some of the RPM's the system starts transmitting endless lookup requests over the NFS and it doesn't stop. for example the RPM rootfiles-1.5-3.noarch.rpm did any one see problem like this in the past ? thank you Rabea From ralf@uni-koblenz.de Fri Feb 18 00:16:05 2000 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 AAA16748; Fri, 18 Feb 2000 00:16:04 +0100 (MET) Received-Date: Fri, 18 Feb 2000 00:16:04 +0100 (MET) Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27772; Fri, 18 Feb 2000 00:16:01 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 18:38:35 +0100 Date: Thu, 17 Feb 2000 18:38:35 +0100 From: Ralf Baechle To: "Gleb O. Raiko" Cc: "linux-mips@fnet.fr" Subject: Re: boot memory Message-ID: <20000217183835.A5988@uni-koblenz.de> References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de> <38ABD5D7.8EF12364@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38ABD5D7.8EF12364@niisi.msk.ru> X-Accept-Language: de,en,fr On Thu, Feb 17, 2000 at 02:04:55PM +0300, Gleb O. Raiko wrote: > While we are discussing bootmem allocator, is there any plans to fix the > allocator in order to be friendly for initrd on all arches ? Or do you > have any ideas how to init bootmem w/o poisoning initrd image ? Call > init_bootmem_node/core directly ? You won't poison the initrd image. The {init,free,reserve}_bootmem() functions will only change the bootmem bitmap but nothing else. > Also, why do not call init_bootmem in the machine independent place, > somewhere in setup ? free_bootmem / reserve_bootmem obviously need to be called from arch dependent code and putting init_bootmem somewhere else is plain ugly. If your only worry is the initrd you can still reserve the memory for it in setup_arch(). Ralf From ralf@uni-koblenz.de Fri Feb 18 00:16:23 2000 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 AAA16816; Fri, 18 Feb 2000 00:16:21 +0100 (MET) Received-Date: Fri, 18 Feb 2000 00:16:21 +0100 (MET) Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27802; Fri, 18 Feb 2000 00:16:18 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 18:41:43 +0100 Date: Thu, 17 Feb 2000 18:41:43 +0100 From: Ralf Baechle To: Richard van den Berg Cc: Rabeeh Khoury , "linux-mips@fnet.fr" Subject: Re: filesystem problems Message-ID: <20000217184143.B5988@uni-koblenz.de> References: <38AC6C30.8F8412F9@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr On Thu, Feb 17, 2000 at 04:23:05PM +0100, Richard van den Berg wrote: > $ man 5 exports > > ... > > By default, nfsd tries to obtain the anonymous uid and gid > by looking up user nobody in the password file at startup > time. If it isn't found, a uid and gid of -2 (i.e. 65534) > is used. These values can also be overridden by the > anonuid and anongid options. > > ... > > Guess you have to edit /etc/exports to change the behaviour. He is looking for the no_root_squash export option which disables uid / gid remapping as you describe above. Like: # cat /etc/exports / victim(rw,no_root_squash) # Ralf From ralf@oss.sgi.com Fri Feb 18 00:17:04 2000 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 AAA16852; Fri, 18 Feb 2000 00:17:03 +0100 (MET) Received-Date: Fri, 18 Feb 2000 00:17:03 +0100 (MET) Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27832; Fri, 18 Feb 2000 00:16:50 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 17 Feb 2000 17:44:32 +0100 Date: Thu, 17 Feb 2000 17:44:32 +0100 From: Ralf Baechle To: "Gleb O. Raiko" Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: 32-bit MIPS with > 512mb mem Message-ID: <20000217174432.B5659@uni-koblenz.de> References: <20000216192427.A6330@uni-koblenz.de> <38ABD8F8.E25D670F@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38ABD8F8.E25D670F@niisi.msk.ru> X-Accept-Language: de,en,fr On Thu, Feb 17, 2000 at 02:18:16PM +0300, Gleb O. Raiko wrote: > Not exactly > 512 mb, but related things. On Baget and DECstations, if > memory serves correctly, there is IO space mapped on KSEG2. Now, Baget > uses kseg2_allocate_io for it, DECstation also has something similar. IO > space on Jazz and Co. are located in virtual address window too, can't > remember where. In princple, access to such IO spaces may be done by > using highmem. I've only been refering to RAM where an efficient solution is much more difficult. Devices on some R4k machines are special anyway because sometimes they reside at physical addresses outside the lowest 4gb which means we cannot even address them using our current page tables. And changing those in general isn't a good idea unless we also have RAM at >= 512mb. Ralf From bleggett@sofamordanek.com Fri Feb 18 01:52:54 2000 Received: from mail.sofamordanek.com (server5.sofamordanek.com [208.14.121.5]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA20058; Fri, 18 Feb 2000 01:52:53 +0100 (MET) Received-Date: Fri, 18 Feb 2000 01:52:53 +0100 (MET) Received: by SERVER5 with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Feb 2000 18:52:45 -0600 Message-ID: From: Bruce Leggett To: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Linux on O2? Date: Thu, 17 Feb 2000 18:52:52 -0600 Return-Receipt-To: Bruce Leggett MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hello, How many folks are actually out there working on the Linux on mips port? Is there any work going on towards running Linux on the O2 specifically? cheers, bruce From brett@madhouse.org Fri Feb 18 02:14:23 2000 Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id CAA20200; Fri, 18 Feb 2000 02:14:22 +0100 (MET) Received-Date: Fri, 18 Feb 2000 02:14:22 +0100 (MET) Received: (qmail 1485 invoked by uid 509); 18 Feb 2000 01:14:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2000 01:14:25 -0000 Date: Thu, 17 Feb 2000 17:14:25 -0800 (PST) From: brett To: Bruce Leggett cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Im still wainting to hear anything about the indigo i hear alot of talk about the indigo2 but nothing about the original blue boxes ----------------------------------------------- brett wagner | brett@madhouse.org get committed! | http://www.madhouse.org ----------------------------------------------- On Thu, 17 Feb 2000, Bruce Leggett wrote: > Hello, > > How many folks are actually out there working on the Linux on mips port? > > Is there any work going on towards running Linux on the O2 specifically? > > cheers, > bruce > From wje@liveoak.engr.sgi.com Fri Feb 18 02:33:08 2000 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA20306; Fri, 18 Feb 2000 02:33:06 +0100 (MET) Received-Date: Fri, 18 Feb 2000 02:33:06 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA03267; Thu, 17 Feb 2000 17:32:58 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA48331; Thu, 17 Feb 2000 17:32:50 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA24858; Thu, 17 Feb 2000 17:32:44 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14508.41276.408855.988727@liveoak.engr.sgi.com> Date: Thu, 17 Feb 2000 17:32:44 -0800 (PST) To: brett Cc: Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: References:

X-Mailer: VM 6.74 under Emacs 20.3.1 brett writes: > Im still wainting to hear anything about the indigo i hear alot of talk > about the indigo2 but nothing about the original blue boxes ... The original Indigo was R3000-based. The I/O is an earlier generation of that used in Indy and Indigo2, so some of the driver work could be reused, but it is hard to find documentation at this point. The Indigo R4000 is pretty close to Indy and Indigo2, so it would not be too hard. On the other hand, there is no work done so far on supporting the "starter" graphics on the Indigo R4000. From ralf@uni-koblenz.de Fri Feb 18 02:34:34 2000 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 CAA20334; Fri, 18 Feb 2000 02:34:33 +0100 (MET) Received-Date: Fri, 18 Feb 2000 02:34:33 +0100 (MET) Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA03445; Fri, 18 Feb 2000 02:34:29 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 02:34:06 +0100 Date: Fri, 18 Feb 2000 02:34:06 +0100 From: Ralf Baechle To: Rabeeh Khoury Cc: "linux-mips@fnet.fr" Subject: Re: RPM installation Message-ID: <20000218023406.C5234@uni-koblenz.de> References: <38ACA682.DE01FB8C@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <38ACA682.DE01FB8C@galileo.co.il> X-Accept-Language: de,en,fr On Thu, Feb 17, 2000 at 08:55:14PM -0500, Rabeeh Khoury wrote: > I'm trying to install RPM on my embedded system over NFS ; when I try > installing some of the RPM's the system starts transmitting endless > lookup requests over the NFS and it doesn't stop. for example the RPM > rootfiles-1.5-3.noarch.rpm > > did any one see problem like this in the past ? Nope, seems you invented a new bug :-) Maybe your driver is broken and you're just re-transmitting the same requests again and again but the server keeps droping them because they corrupted? Like that. Ralf From brett@madhouse.org Fri Feb 18 02:42:24 2000 Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id CAA20422; Fri, 18 Feb 2000 02:42:21 +0100 (MET) Received-Date: Fri, 18 Feb 2000 02:42:21 +0100 (MET) Received: (qmail 1519 invoked by uid 509); 18 Feb 2000 01:42:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2000 01:42:25 -0000 Date: Thu, 17 Feb 2000 17:42:25 -0800 (PST) From: brett To: "William J. Earl" cc: Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: <14508.41276.408855.988727@liveoak.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII well all i care about is the R4000 indigos with "elan" graphics. i just happen to have a couple of them kicking around the shop. b ----------------------------------------------- brett wagner | brett@madhouse.org get committed! | http://www.madhouse.org ----------------------------------------------- On Thu, 17 Feb 2000, William J. Earl wrote: > brett writes: > > Im still wainting to hear anything about the indigo i hear alot of talk > > about the indigo2 but nothing about the original blue boxes > ... > > The original Indigo was R3000-based. The I/O is an earlier generation > of that used in Indy and Indigo2, so some of the driver work could be reused, > but it is hard to find documentation at this point. The Indigo R4000 > is pretty close to Indy and Indigo2, so it would not be too hard. On the > other hand, there is no work done so far on supporting the "starter" graphics > on the Indigo R4000. > From flo@rfc822.org Fri Feb 18 10:29:46 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA23960; Fri, 18 Feb 2000 10:29:45 +0100 (MET) Received-Date: Fri, 18 Feb 2000 10:29:45 +0100 (MET) Received: by noose.gt.owl.de (Postfix, from userid 10) id 99BDF7F5; Fri, 18 Feb 2000 10:29:39 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 09AED8FC4; Fri, 18 Feb 2000 10:25:06 +0100 (CET) Date: Fri, 18 Feb 2000 10:25:05 +0100 From: Florian Lohoff To: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Current cvs kernerl fails to compile for decstation Message-ID: <20000218102505.B369@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Organization: rfc822 - pure communication Sender: flo@rfc822.org On Decstation: make[3]: Entering directory `/data/kernel/linux/drivers/net' gcc -D__KERNEL__ -I/data/kernel/linux/include -Wall -Wstrict-prototypes -O2 -fom it-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -pipe -DEXPOR T_SYMTAB -c slhc.c In file included from slhc.c:74: /data/kernel/linux/include/net/tcp.h:343: #error HZ != 100 && HZ != 1024. make[3]: *** [slhc.o] Error 1 make[3]: Leaving directory `/data/kernel/linux/drivers/net' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/data/kernel/linux/drivers/net' make[1]: *** [_subdir_net] Error 2 make[1]: Leaving directory `/data/kernel/linux/drivers' make: *** [_dir_drivers] Error 2 ------------ #if HZ == 100 #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) #elif HZ == 1024 #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) #else #error HZ != 100 && HZ != 1024. #endif ------------- Hrmpf ... Flo -- Florian Lohoff flo@rfc822.org +49-5241-470566 "Technology is a constant battle between manufacturers producing bigger and more idiot-proof systems and nature producing bigger and better idiots." From raiko@niisi.msk.ru Fri Feb 18 11:07:55 2000 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 LAA24173; Fri, 18 Feb 2000 11:07:49 +0100 (MET) Received-Date: Fri, 18 Feb 2000 11:07:49 +0100 (MET) 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 NAA20506; Fri, 18 Feb 2000 13:07:59 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA01686; Fri, 18 Feb 2000 13:17:39 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA02056; Fri, 18 Feb 2000 13:04:06 +0300 (MSK) Message-ID: <38AD1B65.ED8D9B5D@niisi.msk.ru> Date: Fri, 18 Feb 2000 13:13:57 +0300 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ralf Baechle CC: "linux-mips@fnet.fr" Subject: Re: boot memory References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de> <38ABD5D7.8EF12364@niisi.msk.ru> <20000217183835.A5988@uni-koblenz.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > > On Thu, Feb 17, 2000 at 02:04:55PM +0300, Gleb O. Raiko wrote: > > > While we are discussing bootmem allocator, is there any plans to fix the > > allocator in order to be friendly for initrd on all arches ? Or do you > > have any ideas how to init bootmem w/o poisoning initrd image ? Call > > init_bootmem_node/core directly ? > > You won't poison the initrd image. The {init,free,reserve}_bootmem() > functions will only change the bootmem bitmap but nothing else. > But initrd image is located just after _end. From arch/mips/kernel/setup.c tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8; if (tmp < (unsigned long)&_end) tmp += PAGE_SIZE; initrd_header = (unsigned long *)tmp; if (initrd_header[0] == 0x494E5244) { initrd_start = (unsigned long)&initrd_header[2]; We call init_bootmem with aligned &_end as start pfn. i.e. the same address as tmp points to. Then, init_bootmem stores its bitmap exactly at start pfn and overwrites initrd image. Am I missing the point ? I think, pointing init_bootmem after initrd image isn't appropriate, is it ? Regards, Gleb. From grant67@email.com Fri Feb 18 13:05:18 2000 Received: from maebashi-it.ac.jp (inside.maebashi-it.ac.jp [202.236.152.2]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id NAA24790; Fri, 18 Feb 2000 13:05:16 +0100 (MET) Received-Date: Fri, 18 Feb 2000 13:05:16 +0100 (MET) Received: from P5bYezD21 (1Cust242.tnt23.tpa2.da.uu.net [63.22.138.242]) by maebashi-it.ac.jp (SMI-8.6/3.6W) with SMTP id UAA12547; Fri, 18 Feb 2000 20:50:57 +0900 From: @email.com@maebashi-it.ac.jp DATE: 18 Feb 00 7:01:56 AM Message-ID: SUBJECT: Generation Y Stock Explosion Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Wall-Street�s J-Bird Music Group Ltd. (symbol JBRD -OTCBB) has teamed up with Blockbuster, AT&T, CD-Now and Microsoft to revolutionize the music industry in E-commerce. Record sales are expected to take a quantum leap in year 2000. You�re invited to see how J-Bird will capitalize on its expanding catalog of artists and music. CLICK HERE http://216.248.198.134/jbird1.html To be permanently removed from our database click here; mailto:eric22@altavistausa.com?subject=REMOVE From marc@mucom.co.il Fri Feb 18 14:07:37 2000 Received: from biff.ibm.net.il (biff.ibm.net.il [192.115.72.164]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA25122; Fri, 18 Feb 2000 14:07:12 +0100 (MET) Received-Date: Fri, 18 Feb 2000 14:07:12 +0100 (MET) Received: from moose (host13.mucom.co.il [192.115.216.45]) by biff.ibm.net.il (Postfix) with ESMTP id 469B1121C; Fri, 18 Feb 2000 15:06:38 +0200 (IST) Date: Fri, 18 Feb 2000 15:05:18 -0200 (GMT+2) From: Marc Esipovich To: Florian Lohoff Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Current cvs kernerl fails to compile for decstation In-Reply-To: <20000218102505.B369@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > #if HZ == 100 > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) > #elif HZ == 1024 > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) > #else > #error HZ != 100 && HZ != 1024. > #endif > Without looking or knowing the source, my recommendation is, see where HZ is defined, and find out why it's not defined as either 100 or 1024, but you know that already ;) Marc. From rabeeh@galileo.co.il Fri Feb 18 14:36:39 2000 Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA25276; Fri, 18 Feb 2000 14:36:35 +0100 (MET) Received-Date: Fri, 18 Feb 2000 14:36:35 +0100 (MET) Received: from galileo.co.il ([10.2.3.3]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id PAA16449; Fri, 18 Feb 2000 15:36:02 +0200 (GMT-2) Message-ID: <38AD4E50.4CB08751@galileo.co.il> Date: Fri, 18 Feb 2000 15:51:13 +0200 From: Rabeeh Khoury X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "linux-mips@fnet.fr" , kossay@galileo.co.il Subject: Re: RPM installation References: <38ACA682.DE01FB8C@galileo.co.il> <20000218023406.C5234@uni-koblenz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All The driver can't be broken ; firstly because I built it !!!!! :-) secondly because only specific RPMs are always stuck ; and I can install other RPM and do lots of network stuff before every retry. Can it be that the RPM installer tries performing other stuff than copying the files in the package and updating it's database in /var/lib/rpm ? maybe /proc stuff ? or dns or gateways checks ? other RPM that is stuck is also bash.... - what is in common between bash and rootfiles RPMs ? p.s. regarding my former mails about checksum error in kernel 2.0.34 ; the problem is that I'v used CHECKSUM_HW which returns bad checksum in the udp layer. Instead we should use CHECKSUM_NONE which performs the right checksum. what is the differnce between CHECKSUM_HW and CHECKSUM_NONE ; does CHECKSUM_NONE makes kernel perform checksum on the 4 octets of the ethernet packet ? Regards Rabea Ralf Baechle wrote: > On Thu, Feb 17, 2000 at 08:55:14PM -0500, Rabeeh Khoury wrote: > > > I'm trying to install RPM on my embedded system over NFS ; when I try > > installing some of the RPM's the system starts transmitting endless > > lookup requests over the NFS and it doesn't stop. for example the RPM > > rootfiles-1.5-3.noarch.rpm > > > > did any one see problem like this in the past ? > > Nope, seems you invented a new bug :-) > > Maybe your driver is broken and you're just re-transmitting the same > requests again and again but the server keeps droping them because > they corrupted? Like that. > > Ralf From niessena@natlab.research.philips.com Fri Feb 18 16:35:54 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA25861; Fri, 18 Feb 2000 16:35:54 +0100 (MET) Received-Date: Fri, 18 Feb 2000 16:35:54 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA25573; Fri, 18 Feb 2000 16:35:26 +0100 (MET) (envelope-from niessena@natlab.research.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma025569; Fri, 18 Feb 00 16:35:45 +0100 Received: from natlab.research.philips.com (prle.natlab.research.philips.com [130.139.161.112]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id QAA21351; Fri, 18 Feb 2000 16:35:23 +0100 (MET) Received: by natlab.research.philips.com; Fri, 18 Feb 2000 16:35:22 +0100 Received: by hpas13.natlab.research.philips.com ; Fri, 18 Feb 2000 16:35:21 +0100 (MET) Date: Fri, 18 Feb 2000 16:35:21 +0100 From: Arnold Niessen To: linux-mips@fnet.fr, kevink@mips.com, carstenl@mips.com, linux-porters@algor.co.uk Subject: Linux on Algorithmics P4032 dev.board Message-Id: <20000218163521.A21181@hpas13.natlab.research.philips.com> Reply-To: Arnold.Niessen@philips.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Dear Chris, Kevin, and other Linux/MIPS-ers, I have just started to work on a port of Linux (with the intention of RT-Linux in a later stage) to the Algorithmics P4032-board, based on the newly released MIPS port for the P5064 and Atlas boards. Dominic Sweetman already told me there are more people interested in or working on this P4032 port. I would be obliged if you could help me with a status overview so far, and where work is still needed mostly. Although MIPS and P4032 are new to me, I am surrounded by pSOS-oriented colleagues with lots of P4032 experience, and I am willing to invest time in this port. And to start with a silly question: So far I have not found a ready-to-use cross compilation environment; I have just started to build a gcc-2.95.2 mips cross compiler; monday I will try to solve the first errors which stopped the compilation... Any pointers (other than the CrossGCC FAQ and gcc doc) that I should be aware of ? Best regards, Arnold. -- A.J. Niessen | Philips Research Laboratories Building WL 1.613 | Prof. Holstlaan 4 Phone: (+31-40-27)42715 | 5656 AA Eindhoven Fax: (+31-40-27)44004 | The Netherlands E-Mail: arnold.niessen@philips.com E-Mail on mailing lists: niessen@iae.nl E-Mail old (still works): niessena@natlab.research.philips.com ^ From <@Cologne.DE:karsten@excalibur.cologne.de> Fri Feb 18 21:42:35 2000 Received: from fileserv2.Cologne.DE (fileserv2.cologne.de [193.29.188.3]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id VAA27709; Fri, 18 Feb 2000 21:42:33 +0100 (MET) Received-Date: Fri, 18 Feb 2000 21:42:33 +0100 (MET) Received: from localhost (1749 bytes) by fileserv2.Cologne.DE via rmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Fri, 18 Feb 2000 21:42:32 +0100 (CET) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19) Received: (from karsten@localhost) by excalibur.cologne.de (8.9.3/8.8.7) id TAA04565; Fri, 18 Feb 2000 19:10:52 +0100 Message-ID: <20000218191052.A3634@excalibur.cologne.de> Date: Fri, 18 Feb 2000 19:10:52 +0100 From: Karsten Merker To: Arnold.Niessen@philips.com Cc: linux-mips@fnet.fr Subject: Re: Linux on Algorithmics P4032 dev.board Mail-Followup-To: Arnold.Niessen@philips.com, linux-mips@fnet.fr References: <20000218163521.A21181@hpas13.natlab.research.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <20000218163521.A21181@hpas13.natlab.research.philips.com>; from Arnold Niessen on Fri, Feb 18, 2000 at 04:35:21PM +0100 X-No-Archive: yes On Fri, Feb 18, 2000 at 04:35:21PM +0100, Arnold Niessen wrote: > So far I have not found a ready-to-use cross compilation > environment; I have just started to build a gcc-2.95.2 > mips cross compiler; monday I will try to solve the > first errors which stopped the compilation... > Any pointers (other than the CrossGCC FAQ and gcc doc) that > I should be aware of ? Take a look at ftp://bolug.uni-bonn.de/mips/crossdevel/. According to my knowledge gcc-2.95.2 does not yet work correctly for MIPS, so you will have to stick with the egcs-1.0.3a- and egcs-1.0.2-packages on bolug.uni-bonn.de, which contain mips-specific patches. HTH, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From ralf@oss.sgi.com Fri Feb 18 22:29:27 2000 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 WAA28208; Fri, 18 Feb 2000 22:29:27 +0100 (MET) Received-Date: Fri, 18 Feb 2000 22:29:27 +0100 (MET) Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA01864; Fri, 18 Feb 2000 22:29:20 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 03:53:35 +0100 Date: Fri, 18 Feb 2000 03:53:35 +0100 From: Ralf Baechle To: brett Cc: Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? Message-ID: <20000218035335.F5234@uni-koblenz.de> References:

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: > Im still wainting to hear anything about the indigo i hear alot of talk > about the indigo2 but nothing about the original blue boxes The problem is that the origin docs are gone by now and SGI can't just go and ship the IRIX source to hackers ... Ralf From ralf@oss.sgi.com Fri Feb 18 22:29:34 2000 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 WAA28232; Fri, 18 Feb 2000 22:29:33 +0100 (MET) Received-Date: Fri, 18 Feb 2000 22:29:33 +0100 (MET) Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA01867; Fri, 18 Feb 2000 22:29:22 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 13:59:07 +0100 Date: Fri, 18 Feb 2000 13:59:07 +0100 From: Ralf Baechle To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: copy_from_user() bugfix Message-ID: <20000218135907.A21082@uni-koblenz.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Appended are two patches, one for Linux 2.2 and one for 2.3, which fix a bug copy_from_user / __copy_from_user. When used in a module these two functions may return a wrong result in the error case. Ralf --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.2" Index: include/asm-mips/uaccess.h =================================================================== RCS file: /usr/src/cvs/linux/include/asm-mips/uaccess.h,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 uaccess.h --- uaccess.h 1999/10/21 21:26:27 1.16.2.1 +++ uaccess.h 2000/02/18 12:43:41 @@ -322,10 +322,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ + __MODULE_JAL(__copy_user) \ "addu\t$1, %2, %3\n\t" \ ".set\tat\n\t" \ - __MODULE_JAL(__copy_user) \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ @@ -369,10 +371,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ + __MODULE_JAL(__copy_user) \ "addu\t$1, %2, %3\n\t" \ ".set\tat\n\t" \ - __MODULE_JAL(__copy_user) \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.3" Index: include/asm-mips/uaccess.h =================================================================== RCS file: /usr/src/cvs/linux/include/asm-mips/uaccess.h,v retrieving revision 1.18 diff -u -r1.18 uaccess.h --- uaccess.h 1999/11/19 20:35:48 1.18 +++ uaccess.h 2000/02/18 12:44:43 @@ -323,10 +323,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ + __MODULE_JAL(__copy_user) \ "addu\t$1, %2, %3\n\t" \ ".set\tat\n\t" \ - __MODULE_JAL(__copy_user) \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ @@ -370,10 +372,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ + __MODULE_JAL(__copy_user) \ "addu\t$1, %2, %3\n\t" \ ".set\tat\n\t" \ - __MODULE_JAL(__copy_user) \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ Index: include/asm-mips64/uaccess.h =================================================================== RCS file: /usr/src/cvs/linux/include/asm-mips64/uaccess.h,v retrieving revision 1.4 diff -u -r1.4 uaccess.h --- uaccess.h 1999/11/19 20:35:49 1.4 +++ uaccess.h 2000/02/18 12:48:43 @@ -261,10 +261,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ - "addu\t$1, %2, %3\n\t" \ - ".set\tat\n\t" \ __MODULE_JAL(__copy_user) \ + "daddu\t$1, %2, %3\n\t" \ + ".set\tat\n\t" \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ @@ -308,10 +310,12 @@ "move\t$4, %1\n\t" \ "move\t$5, %2\n\t" \ "move\t$6, %3\n\t" \ + ".set\tnoreorder\n\t" \ ".set\tnoat\n\t" \ - "addu\t$1, %2, %3\n\t" \ - ".set\tat\n\t" \ __MODULE_JAL(__copy_user) \ + "daddu\t$1, %2, %3\n\t" \ + ".set\tat\n\t" \ + ".set\treorder\n\t" \ "move\t%0, $6" \ : "=r" (__cu_len) \ : "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \ --AqsLC8rIMeq19msA-- From ralf@oss.sgi.com Fri Feb 18 23:29:50 2000 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 XAA28570; Fri, 18 Feb 2000 23:29:50 +0100 (MET) Received-Date: Fri, 18 Feb 2000 23:29:50 +0100 (MET) Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05003; Fri, 18 Feb 2000 23:29:45 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 22:46:09 +0100 Date: Fri, 18 Feb 2000 22:46:09 +0100 From: Ralf Baechle To: Marc Esipovich Cc: Florian Lohoff , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Current cvs kernerl fails to compile for decstation Message-ID: <20000218224609.C24098@uni-koblenz.de> References: <20000218102505.B369@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr On Fri, Feb 18, 2000 at 03:05:18PM -0200, Marc Esipovich wrote: > > #if HZ == 100 > > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) > > #elif HZ == 1024 > > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) > > #else > > #error HZ != 100 && HZ != 1024. > > #endif > > Without looking or knowing the source, my recommendation is, see where HZ > is defined, and find out why it's not defined as either 100 or 1024, but > you know that already ;) It's 64 because it's not possible to program the DECstation RTC to 100Hz or 1024Hz. Ralf From ralf@oss.sgi.com Fri Feb 18 23:30:10 2000 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 XAA28614; Fri, 18 Feb 2000 23:30:09 +0100 (MET) Received-Date: Fri, 18 Feb 2000 23:30:09 +0100 (MET) Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05023; Fri, 18 Feb 2000 23:29:59 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 22:36:28 +0100 Date: Fri, 18 Feb 2000 22:36:28 +0100 From: Ralf Baechle To: Florian Lohoff Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Current cvs kernerl fails to compile for decstation Message-ID: <20000218223628.A24098@uni-koblenz.de> References: <20000218102505.B369@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000218102505.B369@paradigm.rfc822.org> X-Accept-Language: de,en,fr On Fri, Feb 18, 2000 at 10:25:05AM +0100, Florian Lohoff wrote: > #if HZ == 100 > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) > #elif HZ == 1024 > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) > #else > #error HZ != 100 && HZ != 1024. > #endif How about making that: #if HZ == 100 #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) #elif HZ == 64 #define TCP_TW_RECYCLE_TICK (6+2-TCP_TW_RECYCLE_SLOTS_LOG) #elif HZ == 1024 #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) #else #error HZ != 100 && HZ != 1024. #endif Without further reading the context that would by my first attempt. > Hrmpf ... Imagine, and tomorrow I'm going to break all networking drivers :-) Ralf From brett@madhouse.org Sat Feb 19 00:26:02 2000 Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id AAA29006; Sat, 19 Feb 2000 00:14:28 +0100 (MET) Received-Date: Sat, 19 Feb 2000 00:14:28 +0100 (MET) Received: (qmail 2447 invoked by uid 509); 18 Feb 2000 22:13:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2000 22:13:11 -0000 Date: Fri, 18 Feb 2000 14:13:11 -0800 (PST) From: brett To: Ralf Baechle cc: Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: <20000218035335.F5234@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII why not put a couple of hackers under nda and ship them the source. b ----------------------------------------------- brett wagner | brett@madhouse.org get committed! | http://www.madhouse.org ----------------------------------------------- On Fri, 18 Feb 2000, Ralf Baechle wrote: > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: > > > Im still wainting to hear anything about the indigo i hear alot of talk > > about the indigo2 but nothing about the original blue boxes > > The problem is that the origin docs are gone by now and SGI can't > just go and ship the IRIX source to hackers ... > > Ralf > From wje@liveoak.engr.sgi.com Sat Feb 19 00:33:12 2000 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA00144; Sat, 19 Feb 2000 00:33:11 +0100 (MET) Received-Date: Sat, 19 Feb 2000 00:33:11 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA08871; Fri, 18 Feb 2000 15:36:02 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA72706; Fri, 18 Feb 2000 15:33:03 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id PAA19290; Fri, 18 Feb 2000 15:32:58 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14509.54953.882688.741736@liveoak.engr.sgi.com> Date: Fri, 18 Feb 2000 15:32:57 -0800 (PST) To: Ralf Baechle Cc: brett , Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: <20000218035335.F5234@uni-koblenz.de> References:

<20000218035335.F5234@uni-koblenz.de> X-Mailer: VM 6.74 under Emacs 20.3.1 Ralf Baechle writes: > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: > > > Im still wainting to hear anything about the indigo i hear alot of talk > > about the indigo2 but nothing about the original blue boxes > > The problem is that the origin docs are gone by now and SGI can't > just go and ship the IRIX source to hackers ... We might be able to help out with some Indigo R4000 information, if someone is seriously interested, since the Indigo R4000 is close to Indigo2 and Indy. Indigo R3000 is probably hopeless (that development project was something like 12 years ago, after all). The graphics is a tougher problem, since all but Newport and Starter (Indigo) graphics have geometry engines with relatively complex interfaces. Ralf is quite right about the IRIX source. Since it is based on source licensed from SCO, Sun, and others, we do not have the right to hand it out without cost to others. From ralf@oss.sgi.com Sat Feb 19 01:41:56 2000 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 BAA00675; Sat, 19 Feb 2000 01:41:55 +0100 (MET) Received-Date: Sat, 19 Feb 2000 01:41:55 +0100 (MET) Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA09782; Sat, 19 Feb 2000 01:41:25 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Sat, 19 Feb 2000 01:03:31 +0100 Date: Sat, 19 Feb 2000 01:03:31 +0100 From: Ralf Baechle To: "William J. Earl" Cc: Ralf Baechle , brett , Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? Message-ID: <20000219010331.B19004@uni-koblenz.de> References:

<20000218035335.F5234@uni-koblenz.de> <14509.54953.882688.741736@liveoak.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <14509.54953.882688.741736@liveoak.engr.sgi.com> X-Accept-Language: de,en,fr On Fri, Feb 18, 2000 at 03:32:57PM -0800, William J. Earl wrote: > Ralf Baechle writes: > > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: > > > > > Im still wainting to hear anything about the indigo i hear alot of talk > > > about the indigo2 but nothing about the original blue boxes > > > > The problem is that the origin docs are gone by now and SGI can't > > just go and ship the IRIX source to hackers ... > > We might be able to help out with some Indigo R4000 information, > if someone is seriously interested, since the Indigo R4000 is close to > Indigo2 and Indy. Indigo R3000 is probably hopeless (that development > project was something like 12 years ago, after all). The graphics is > a tougher problem, since all but Newport and Starter (Indigo) graphics > have geometry engines with relatively complex interfaces. > > Ralf is quite right about the IRIX source. Since it is based > on source licensed from SCO, Sun, and others, we do not have the right > to hand it out without cost to others. How about if myself and possibly others who currently are under NDA for SGI would support such projects by describing things via email where neither docs nor uncontaminated source is available and possibly some source where it's (C)-clean and managment aproved. Could something like that be made working? It's a shame that still nobody so far has had an actual chance to start working on an O2 port or something like that. Ralf From wje@liveoak.engr.sgi.com Sat Feb 19 04:43:03 2000 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA03597; Sat, 19 Feb 2000 04:43:02 +0100 (MET) Received-Date: Sat, 19 Feb 2000 04:43:02 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00463; Fri, 18 Feb 2000 19:45:54 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA22751; Fri, 18 Feb 2000 19:42:56 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id TAA03086; Fri, 18 Feb 2000 19:42:50 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <14510.4410.177164.703052@liveoak.engr.sgi.com> Date: Fri, 18 Feb 2000 19:42:50 -0800 (PST) To: Ralf Baechle Cc: brett , Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: <20000219010331.B19004@uni-koblenz.de> References:

<20000218035335.F5234@uni-koblenz.de> <14509.54953.882688.741736@liveoak.engr.sgi.com> <20000219010331.B19004@uni-koblenz.de> X-Mailer: VM 6.74 under Emacs 20.3.1 Ralf Baechle writes: ... > How about if myself and possibly others who currently are under NDA = for SGI > would support such projects by describing things via email where > neither docs nor uncontaminated source is available and possibly som= e > source where it's (C)-clean and managment aproved. Could something = like > that be made working? It's a shame that still nobody so far has had= an > actual chance to start working on an O2 port or something like that.= That should be ok; we have approval to do so (and I have sometimes supplied information on that basis), at least for Indigo, Ind= igo2, Indy, and Origin. (There was some question about Octane and Onyx,=A0es= pecially in regard to graphics.) =20 If someone is seriously interested in doing an O2 port, I will h= elp with explanations of the major issues, and we can make documentation av= ailable under the same restrictions as Indy documentation (no redistribution, n= o warranty, documentation is known to be inaccurate in various details). = =20 As I have described earlier, however, an O2 port is a major undertaking= . (It would be quite an interesting and challenging project, but it is not simple.) Again, Indigo documentation, except via the method Ralf suggests= , is going to be hard to come by. The O2 documentation, albeit somewhat inaccurate, is on the other hand readily available. From marc@mucom.co.il Sat Feb 19 05:31:52 2000 Received: from biff.ibm.net.il (biff.ibm.net.il [192.115.72.164]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA05541; Sat, 19 Feb 2000 05:31:51 +0100 (MET) Received-Date: Sat, 19 Feb 2000 05:31:51 +0100 (MET) Received: from moose (host13.mucom.co.il [192.115.216.45]) by biff.ibm.net.il (Postfix) with ESMTP id 525921004; Sat, 19 Feb 2000 06:31:43 +0200 (IST) Date: Sat, 19 Feb 2000 06:30:22 -0200 (GMT+2) From: Marc Esipovich To: Ralf Baechle Cc: brett , Bruce Leggett , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: Linux on O2? In-Reply-To: <20000218035335.F5234@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: > > > Im still wainting to hear anything about the indigo i hear alot of talk > > about the indigo2 but nothing about the original blue boxes > > The problem is that the origin docs are gone by now and SGI can't > just go and ship the IRIX source to hackers ... > > Ralf > Wow, what do you mean gone by now? are you saying there's no chance in hell to obtain the documentation? it can't be gone. Marc. From Harald.Koerfgen@home.ivm.de Sat Feb 19 13:26:42 2000 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA10217; Sat, 19 Feb 2000 13:26:41 +0100 (MET) Received-Date: Sat, 19 Feb 2000 13:26:41 +0100 (MET) Received: from franz.no.dom (port33.duesseldorf.ivm.de [195.247.65.33]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id NAA02745; Sat, 19 Feb 2000 13:26:14 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.3 [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: <20000218224609.C24098@uni-koblenz.de> Date: Sat, 19 Feb 2000 13:26:54 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Ralf Baechle Subject: Re: Current cvs kernerl fails to compile for decstation Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com, Florian Lohoff , Marc Esipovich On 18-Feb-00 Ralf Baechle wrote: > On Fri, Feb 18, 2000 at 03:05:18PM -0200, Marc Esipovich wrote: > >> > #if HZ == 100 >> > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG) >> > #elif HZ == 1024 >> > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG) >> > #else >> > #error HZ != 100 && HZ != 1024. >> > #endif Well, I changed that to #if HZ == 100 || HZ == 128 HZ has been changed to 128 somewhere in the early 2.3.x series... > It's 64 because it's not possible to program the DECstation RTC to 100Hz > or 1024Hz. Well, 1024 Hz would be possible but certainly total overkill for a DECstation 2100 with a 12.5 Mhz R2000 :-) --- Regards, Harald From Harald.Koerfgen@home.ivm.de Sat Feb 19 13:29:17 2000 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA10679; Sat, 19 Feb 2000 13:29:16 +0100 (MET) Received-Date: Sat, 19 Feb 2000 13:29:16 +0100 (MET) Received: from franz.no.dom (port88.duesseldorf.ivm.de [195.247.65.88]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id NAA02870; Sat, 19 Feb 2000 13:29:06 +0100 X-To: linux-mips@fnet.fr Message-ID: X-Mailer: XFMail 1.3 [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: <20000219010331.B19004@uni-koblenz.de> Date: Sat, 19 Feb 2000 13:29:46 +0100 (MET) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: Ralf Baechle Subject: Re: Linux on O2? Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com, Bruce Leggett , brett , "William J. Earl" On 19-Feb-00 Ralf Baechle wrote: > On Fri, Feb 18, 2000 at 03:32:57PM -0800, William J. Earl wrote: > >> Ralf Baechle writes: >> > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote: >> > >> > > Im still wainting to hear anything about the indigo i hear alot of talk >> > > about the indigo2 but nothing about the original blue boxes >> > >> > The problem is that the origin docs are gone by now and SGI can't >> > just go and ship the IRIX source to hackers ... >> >> We might be able to help out with some Indigo R4000 information, >> if someone is seriously interested, since the Indigo R4000 is close to >> Indigo2 and Indy. Indigo R3000 is probably hopeless (that development >> project was something like 12 years ago, after all). The graphics is >> a tougher problem, since all but Newport and Starter (Indigo) graphics >> have geometry engines with relatively complex interfaces. >> >> Ralf is quite right about the IRIX source. Since it is based >> on source licensed from SCO, Sun, and others, we do not have the right >> to hand it out without cost to others. > > How about if myself and possibly others who currently are under NDA for SGI > would support such projects by describing things via email where > neither docs nor uncontaminated source is available and possibly some > source where it's (C)-clean and managment aproved. Could something like > that be made working? It's a shame that still nobody so far has had an > actual chance to start working on an O2 port or something like that. Well, if someone is willing to ship me an O2 I'll see what I can do :-) --- Regards, Harald From mh@cs.tu-berlin.de Sat Feb 19 15:12:56 2000 Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA13311; Sat, 19 Feb 2000 15:12:55 +0100 (MET) Received-Date: Sat, 19 Feb 2000 15:12:55 +0100 (MET) Received: from elverum.cs.tu-berlin.de (mh@elverum.cs.tu-berlin.de [130.149.17.27]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id PAA00848; Sat, 19 Feb 2000 15:03:18 +0100 (MET) From: Matthias Heidbrink Received: (from mh@localhost) by elverum.cs.tu-berlin.de (8.9.3/8.9.3) id PAA07765; Sat, 19 Feb 2000 15:03:16 +0100 (MET) Message-Id: <200002191403.PAA07765@elverum.cs.tu-berlin.de> Subject: Re: Current cvs kernerl fails to compile for decstation In-Reply-To: from Harald Koerfgen at "Feb 19, 2000 01:26:54 pm" To: Harald Koerfgen Date: Sat, 19 Feb 2000 15:03:16 +0100 (MET) CC: linux-mips@fnet.fr X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hallo Harald, > > It's 64 because it's not possible to program the DECstation RTC to 100Hz > > or 1024Hz. > > Well, 1024 Hz would be possible but certainly total overkill for a DECstation > 2100 with a 12.5 Mhz R2000 :-) I remember that problems with these "odd" 64 Hz have been discussed on this list several times before. Maybe it would not be such a bad idea to go to a "standard" value. How expensive is the interrupt handler for the timer, I mean, how large would the loss in performance be when going to 1024 Hz? Or would it make sense to modify the clock setup and interrupt handler to run the clock with 1024 Hz, but run the complete timer interrupt handling code only every 10 ms/at 100Hz (in average)? I used this method some years ago under DOS because my application required a fine timer resolution and DOS required a timer interrupt every 55ms. On a 386-33 (which should be roughly equivalent in performance to an old MIPS CPU with a bit less than half of the clock speed) it showed no remarkable loss in performence. Even quite the opposite because the application that had some delays in it ran smoother because of the finer granularity of the delays. Ciao, Matthias -- Matthias Heidbrink E-Mail: Bundesratufer 12 Matthias_Heidbrink@b.maus.de 10555 Berlin, Germany mh@cs.tu-berlin.de Tel. +49-30-8536361 mh@carano.de (at work; http://www.carano.com) From spock@mgnet.de Sat Feb 19 16:16:13 2000 Received: from obelix.hrz.tu-chemnitz.de (obelix.hrz.tu-chemnitz.de [134.109.132.55]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA14061; Sat, 19 Feb 2000 16:16:12 +0100 (MET) Received-Date: Sat, 19 Feb 2000 16:16:12 +0100 (MET) Received: from sunnyboy.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de with Local SMTP (PP); Sat, 19 Feb 2000 16:15:39 +0100 Received: from scotty.mgnet.de (stampede.csn.tu-chemnitz.de [134.109.96.133]) by sunnyboy.informatik.tu-chemnitz.de (8.8.8/8.8.8) with SMTP id QAA07017 for ; Sat, 19 Feb 2000 16:15:37 +0100 (MET) Message-Id: <200002191515.QAA07017@sunnyboy.informatik.tu-chemnitz.de> Received: (qmail 6379 invoked from network); 19 Feb 2000 15:15:30 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 19 Feb 2000 15:15:30 -0000 Date: Sat, 19 Feb 2000 16:15:37 CET From: Klaus Naumann To: linux-mips@fnet.fr Subject: Bug in timex.h Reply-To: spock@mgnet.de X-Mailer: Spruce 0.5.16 for X11 w/smtpio 0.7.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="spruceBYXTSDUBBJTFZKFDYEQY" This is a multi-part message in MIME format. --spruceBYXTSDUBBJTFZKFDYEQY Content-Type: text/plain Content-Transfer-Type: 8bit Hi, while compiling glibc (cross compile) I think I encountered a bug in include/asm-mips/timex.h . It uses the define CP0_COUNT and the function read_32bit_cp0_register() which are defined in mipsregs.h . But the timex.h does _not_ include this file. At least my compiler complained about undefined CP0_COUNT. I've appended a patch for the problem (Well, I hope it's fixing the problem in a correct way ;) ). Later , Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/3661/675457 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt --spruceBYXTSDUBBJTFZKFDYEQY Content-Type: application/octet-stream; name="timex.h.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="timex.h.diff" LS0tIHRpbWV4Lmgub3JpZwlTYXQgRmViIDE5IDE2OjA4OjE3IDIwMDAKKysrIHRpbWV4LmgJU2F0 IEZlYiAxOSAxNjowOTo0NiAyMDAwCkBAIC0xMSw2ICsxMSwxMCBAQAogI2lmbmRlZiBfX0FTTV9N SVBTX1RJTUVYX0gKICNkZWZpbmUgX19BU01fTUlQU19USU1FWF9ICiAKKyNpZm5kZWYgX19BU01f TUlQU19NSVBTUkVHU19ICisjaW5jbHVkZSA8YXNtL21pcHNyZWdzLmg+CisjZW5kaWYKKwogI2Rl ZmluZSBDTE9DS19USUNLX1JBVEUJMTE5MzE4MCAvKiBVbmRlcmx5aW5nIEhaICovCiAjZGVmaW5l IENMT0NLX1RJQ0tfRkFDVE9SCTIwCS8qIEZhY3RvciBvZiBib3RoIDEwMDAwMDAgYW5kIENMT0NL X1RJQ0tfUkFURSAqLwogI2RlZmluZSBGSU5FVFVORSAoKCgoKChsb25nKUxBVENIICogSFogLSBD TE9DS19USUNLX1JBVEUpIDw8IFNISUZUX0haKSAqIFwK --spruceBYXTSDUBBJTFZKFDYEQY-- From brianm@moffetimages.com Sat Feb 19 22:04:19 2000 Received: from moffetimages.com (alar.scruz.predictive.com [207.251.1.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA19752; Sat, 19 Feb 2000 22:04:17 +0100 (MET) Received-Date: Sat, 19 Feb 2000 22:04:17 +0100 (MET) Received: from brianm.moffetimages.com (dhcp8.moffetimages.com [10.0.1.8]) by moffetimages.com (8.9.3/8.9.3) with SMTP id NAA18338; Sat, 19 Feb 2000 13:04:48 -0800 (PST) (envelope-from brianm@moffetimages.com) Message-Id: <3.0.5.32.20000219130000.007af280@orac.moffetimages.com> X-Sender: brianm@orac.moffetimages.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 19 Feb 2000 13:00:00 -0800 To: "Harald Koerfgen" , Ralf Baechle From: "Brian D. Moffet" Subject: Re: Linux on O2? Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com, Bruce Leggett , brett , "William J. Earl" In-Reply-To: References: <20000219010331.B19004@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:29 PM 2/19/00 +0100, Harald Koerfgen wrote: >Well, if someone is willing to ship me an O2 I'll see what I can do :-) I own an O2, and would be willing to work on a port, once my life gets more free time... :-) Of course I would need to get as much hardware doc as possible, but my time isn't gonna free up for at least another 6 - 9 months, probably longer... Brian Brian D. Moffet www.moffetimages.com brianm@ricochet.net photographer, pilot, musician, programmer From ralf@uni-koblenz.de Sat Feb 19 22:43:06 2000 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 WAA20480; Sat, 19 Feb 2000 22:43:05 +0100 (MET) Received-Date: Sat, 19 Feb 2000 22:43:05 +0100 (MET) Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA27162; Sat, 19 Feb 2000 22:42:49 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Sat, 19 Feb 2000 12:27:14 +0100 Date: Sat, 19 Feb 2000 12:27:14 +0100 From: Ralf Baechle To: Arnold.Niessen@philips.com Cc: linux-mips@fnet.fr, kevink@mips.com, carstenl@mips.com, linux-porters@algor.co.uk Subject: Re: Linux on Algorithmics P4032 dev.board Message-ID: <20000219122714.B22339@uni-koblenz.de> References: <20000218163521.A21181@hpas13.natlab.research.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000218163521.A21181@hpas13.natlab.research.philips.com> X-Accept-Language: de,en,fr On Fri, Feb 18, 2000 at 04:35:21PM +0100, Arnold Niessen wrote: > And to start with a silly question: > So far I have not found a ready-to-use cross compilation > environment; I have just started to build a gcc-2.95.2 > mips cross compiler; monday I will try to solve the > first errors which stopped the compilation... Do not try to build a Linux kernel based on egcs 2.95.x. While the compiler is ok it is known other platforms to overoptimize the kernel in interesting way. > Any pointers (other than the CrossGCC FAQ and gcc doc) that > I should be aware of ? http://oss.sgi.com/mips/, go to the Linux/MIPS FAQ. For shrink wrapped compiler packages here my announcment from Jul 1, 1999 again: Ralf -----BEGIN PGP SIGNED MESSAGE----- Hi, I've uploaded new patches to build native and cross binutils and compilers for mips-linux and mipsel-linux targets for Linux/MIPS on ftp.linux.sgi.com into /pub/linux/mips/crossdev/src/ rsp. /pub/linux/mips/crossdev/src/egcs/. Binaries of binutils and egcs are available for the following types of hosts are available in /pub/linux/mips/crossdev/ - Linux/i386 (glibc 2.1 required) - Linux/Alpha (glibc 2.0 or newer required) - Linux/Sparc (glibc 2.0 or newer required) - Linux/PPC (glibc 2.0 or newer required) Credits for providing the Alpha and Sparc binaries go to Arnaldo Carvalho de Melo (acme@conectiva.com.br). Please read the list of changes to the patch files and RPM packages below. Please report problems ralf@uni-koblenz.de or one of the Linux/MIPS mailing lists. Ralf Changes to egcs since egcs 1.0.2: - Fixed #ident operator to generate .ident, not .string. You must upgrade binutils to at least binutils-2.8.1-1.diff before you can use or build this compiler. You must installed this compiler release if you want to compile modutils; previous releases were producing bad code. Changes to binutils since version binutils-2.8.1-2.diff: - TLB instructions are now applied to the same instruction scheduling rules as other coprocessor instructions. - Rebuilt the binary RPM using the new patch. You must upgrade to binutils-2.8.1-2.diff if you wish to compile Linux/MIPS kernels for R3000 CPUs. Changes to binutils since version binutils-2.8.1-1.diff: - Fix the .ident pseudo op in gas to handle sections correctly. You must upgrade to at least this version before you want to upgrade to egcs-1.0.3a.diff. 66f22d90c7bdbf77035f35a4cffa0e63 binutils-2.8.1-3.diff.gz 24906a53ab1abc105256d29e4928a77e binutils-mips-linux-2.8.1-1.alpha.rpm 331bbbe37ec6005a429d8e5886ccba1c binutils-mipsel-linux-2.8.1-1.alpha.rpm 17c1a924b4934040e6a5d0f7eef42278 binutils-mips-linux-2.8.1-1.i386.rpm 1e45a295ec695b241434332721144b1e binutils-mipsel-linux-2.8.1-1.i386.rpm c3214c60813f045e72ca2162a23c717e binutils-mips-linux-2.8.1-1.ppc.rpm 30652af3c6d6daf390f1c8b682dcdbde binutils-mipsel-linux-2.8.1-1.ppc.rpm 289f49618cb1fd122c0a1080575e30b8 binutils-mips-linux-2.8.1-1.sparc.rpm 489e2e34bf8d1671645b85fb3c630f68 binutils-mipsel-linux-2.8.1-1.sparc.rpm ef30d241f81c13cf443631bcd5ab1914 cross-binutils-2.8.1-1.src.rpm e64f9950999f3e0850ba7f73e65b75e5 cross-egcs-1.0.3a-1.src.rpm 5f57e092d9b5f221054332fc039dc4ff egcs-1.0.3a-2.diff.gz 04b9084199eb234b588ae8fcdb930dac egcs-c++-mips-linux-1.0.3a-1.alpha.rpm f10ddf2c07d2fd36ad02bed7a3e3acc7 egcs-c++-mipsel-linux-1.0.3a-1.alpha.rpm bbcfe6b7b1594d639156b90687fb4a5c egcs-g77-mips-linux-1.0.3a-1.alpha.rpm 1ccb88ad648f1ee762f45788e4a61e79 egcs-g77-mipsel-linux-1.0.3a-1.alpha.rpm 67af9cea602b93b6d125e569a3f938b3 egcs-libstdc++-mips-linux-2.8.0-1.alpha.rpm f0d2a5c19cbaf63859405f725f41818b egcs-libstdc++-mipsel-linux-2.8.0-1.alpha.rpm e3bf275316b98adb6367304d9db01a1d egcs-mips-linux-1.0.3a-1.alpha.rpm 1ae65785a9deb0cdedb5a656ade821c4 egcs-mipsel-linux-1.0.3a-1.alpha.rpm 720e571214f8d9ba05a998a10704af6b egcs-objc-mips-linux-1.0.3a-1.alpha.rpm 32bc3f37365483d5b65bd1aa4c8e0876 egcs-objc-mipsel-linux-1.0.3a-1.alpha.rpm 3d0dc466d92175c121300bdef4881a33 egcs-c++-mips-linux-1.0.3a-1.i386.rpm c4272a37fe8e57b3f9bb8be738274836 egcs-c++-mipsel-linux-1.0.3a-1.i386.rpm c0de740218490e1b5256c002df724e9e egcs-g77-mips-linux-1.0.3a-1.i386.rpm 9d539da26bb07b7edca4c2106cb23d3a egcs-g77-mipsel-linux-1.0.3a-1.i386.rpm e6bd26ab57563f6d6e854325728fe3f2 egcs-libstdc++-mips-linux-2.8.0-1.i386.rpm 42300569bb1356d4c3209006700f1c6a egcs-libstdc++-mipsel-linux-2.8.0-1.i386.rpm 9d69a4a9bb481ff8bde126b58e13f184 egcs-mips-linux-1.0.3a-1.i386.rpm a84256a9295121d8042e0a5a8f1127ea egcs-mipsel-linux-1.0.3a-1.i386.rpm e5583f2486e5a87e4715e2a0757f316d egcs-objc-mips-linux-1.0.3a-1.i386.rpm 0a1d9166d05c40fe242ebf3e8e4c9d67 egcs-objc-mipsel-linux-1.0.3a-1.i386.rpm f0f1d54a00c61541326d7a9c6fabd856 egcs-c++-mips-linux-1.0.3a-1.ppc.rpm f28e90e7bf2494be0c55d85a15ed7763 egcs-c++-mipsel-linux-1.0.3a-1.ppc.rpm ee7eb7f1bb1a24ba024ef6b16eb140d1 egcs-g77-mips-linux-1.0.3a-1.ppc.rpm 599424fb7cb8c6f9c665b4724be07bc8 egcs-g77-mipsel-linux-1.0.3a-1.ppc.rpm bf4a42ed26188fd3deaceeaf864d7765 egcs-libstdc++-mips-linux-2.8.0-1.ppc.rpm 770888f1c4c2882c9e5d1c6627c3ab81 egcs-libstdc++-mipsel-linux-2.8.0-1.ppc.rpm be4bf0ac5d0804fcd6a31ec88cfe651e egcs-mips-linux-1.0.3a-1.ppc.rpm 679de1a46ea47ef7a829e6abcb47a257 egcs-mipsel-linux-1.0.3a-1.ppc.rpm 3ab9e864b8b3d58bcac6c07fa7363daf egcs-objc-mips-linux-1.0.3a-1.ppc.rpm c48aaeabd8b7373ee8fd3b358fa0869c egcs-objc-mipsel-linux-1.0.3a-1.ppc.rpm f5dacd4ad42184f57a8cff6ea650e4be egcs-c++-mips-linux-1.0.3a-1.sparc.rpm 09f2301fc208bf434fb83c6ccebe9752 egcs-c++-mipsel-linux-1.0.3a-1.sparc.rpm dd9630b77a2ec7fa057da244040b4d6d egcs-g77-mips-linux-1.0.3a-1.sparc.rpm 26c01a32ec26cbc1746bca05c9726e3b egcs-g77-mipsel-linux-1.0.3a-1.sparc.rpm f6c2debe62d93ddedf95a91ee98805fb egcs-libstdc++-mips-linux-2.8.0-1.sparc.rpm 3da0d34a7420762c75fe477416451b71 egcs-libstdc++-mipsel-linux-2.8.0-1.sparc.rpm2ab9227097946bfbd4e795a07cad82a1 egcs-mips-linux-1.0.3a-1.sparc.rpm 0f19e28546a185da5969442a6d35b495 egcs-mipsel-linux-1.0.3a-1.sparc.rpm 6cdcfe0d1b52d3fd033c64a289ee4836 egcs-objc-mips-linux-1.0.3a-1.sparc.rpm 32ca712e0aa483520afe39b87b0fc6ab egcs-objc-mipsel-linux-1.0.3a-1.sparc.rpm -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 iQCVAwUBN3qbV0ckbl6vezDBAQGUsgP9F1VrQQELRKgm5SuVG7z13235ZgBmRnhA dYkE9NQMY798XedAnuf7SmZZGeaqYivM1/td8AXaDG8gueMcAzOoIkNhdeOGBVj2 L7CilWqpW60iMdTsjbXYT+azD4/xAB8CoBnK7hgEeZIqkEgTXfxPuOeb8G+2NAGc QpMp1L5xE+k= =Spnq -----END PGP SIGNATURE----- From 1n15@1n15bz.net Sat Feb 19 23:40:27 2000 Received: from yuhosha.co.jp (fortknox.yuhosha.co.jp [210.254.19.162]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA21391; Sat, 19 Feb 2000 23:40:25 +0100 (MET) Received-Date: Sat, 19 Feb 2000 23:40:25 +0100 (MET) From: 1n15@1n15bz.net Received: from cen.bellsouth.net (localhost [127.0.0.1]) by yuhosha.co.jp (8.8.7/8.8.7) with SMTP id HAA03057; Sun, 20 Feb 2000 07:41:25 +0900 (GMT-9) Date: Sun, 20 Feb 2000 07:41:25 +0900 (GMT-9) Message-Id: <200002192241.HAA03057@yuhosha.co.jp> To: hello56@eastmail.com Subject: if under 21 please delete MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Fantasy Escape For ultra-explicit pictures in every imaginable category.. To get up close and personal with thousands of live video feeds.. For live interaction with our Internet models.. For stories that make your mind spin.. For material that's a little off the beaten track.. To become a secret spy using voyeurvision.. To explore places you have never seen before with our toycam or dildovision.. To nurture your dominant (or submissive side).. visit us at http://www.youngandsexy.com where you wildest fantasies become reality! WhiteHorse Mailing Service Charlestown Nevis, BWI